> 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 <tkef...@gmail.com> wrote:


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?

On Monday, April 1, 2024 at 6:34:46 AM UTC-7 jo...@johnkline.com wrote:
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:


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.

On Sunday 31 March 2024 at 23:56:23 UTC+1 Stephen wrote:
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?

--
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.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/241ad3cb-213d-44d3-937a-bea2dabbb441n%40googlegroups.com.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/EB142EE0-83B8-43DF-A251-5574AC3EACDC%40johnkline.com.

Reply via email to