Change to daylight saving time stops data update

[Stephen]

I have two Davis Vantage Pro 2 weather stations at different locations. Both stations stopped updating their web pages at 2.00am last night, the moment daylight saving started.

I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles are configured to automatically change to DST.

There is an old thread from 2017 about this problem here https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.

Taking the advice in that thread I've got one of the stations working again by executing  weectl device --dump.  I've left the other station as it is at the moment.

This has never happened before, but I wasn't running v5.0.1 this time last year.

Any idea what's going on?

[Tom Keffer]

Issue #247 explains the problem.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/bc83e9f6-5231-4702-8afc-758c645061cdn%40googlegroups.com.

[Devonian]

Regular 'issue' for me in UK too.

I do this as I'm not yet on v5...amend as req'd.

sudo service weewx stop

sudo /home/weewx/bin/wee_device --dump  (or wherever your wee_device (or weectl device --dump) command is located)

sudo /home/weewx/bin/wee_device --clear  (or wherever your wee_device (or weectl device --clear) command is located)

sudo service weewx start

Never lost any data yet and to speed things up after clocks change. I try to remember the night before clocks change to clear the logger if all current data is saved to the db.

HTH

Nigel

[Simon Duane]

From what I've read, it involves an interaction between a Weewx service which adjusts the VP2 console clock to eliminate drift  - by default, it checks every 5 hours and applies the correction when the error is bigger than 5 seconds. I would suggest that if the error is close to 1 hour rather than a little more than 5 seconds, then the correction should simply not be applied, because of the risk of this happening. Fixing it on the next cycle will be good enough.

It happened to my Weewx v 4.9.1 + VP2 (for the first time) yesterday too and, because I have that archive parameter set to hardware, clearing the datalogger memory meant I lost about a day's data.

[John Kline]

I’ve successfully fixed the time change issue on a fork of the vantage driver:

It assumes a one hour change for daylight savings and one is required to enter DST enter and exit times in the VantageNext section of weewx.conf.

During the time change window, set time is a no-op (since one cannot specify whether the time is in DST or not).  Also, during the window, get time will auto correct if the time is about 1 hour off.  Lastly, when the driver converts the archive records time, it is auto-adjusted if about an hour off.

I don’t recommend switching to this driver as the vantage driver in weewx is better supported; but perhaps a similar approach could be taken.  It is tricky because it is hard to test this stuff.

 

On Apr 1, 2024, at 8:00 AM, Simon Duane <simon...@gmail.com> wrote:



--

You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/09e0d95f-ec44-4782-989f-d4ef3217ddadn%40googlegroups.com.

[Tom Keffer]

If the key is to not mess with the console time near the DST boundary, why not just arrange for clock synchronization to only happen once a day at noon?

[John Kline]

> If the key is to not mess with the console time near the DST boundary, why not just arrange for

> clock synchronization to only happen once a day at noon?

It is not the key.  You have to get unlucky to check the time during the window.  The main problem is when time is set back one hour (leaving DST).  I’ve found the archive record code creating a timestamp from Vantage time gets it wrong in the “fall back” hour—thinking we’re still in DST, thus getting duplicates when trying to insert archive records.

On Apr 1, 2024, at 11:02 AM, Tom Keffer <tke...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/241ad3cb-213d-44d3-937a-bea2dabbb441n%40googlegroups.com.