vantage driver stop working when clock changes from GMT to BST

[gearoidgit]

When OS clock changes from GMT to BST data transfer stops for the vantage driver.
weewx-users post

There's no specific message in /var/log/syslog at the time, debug=0, but it stops posting reports to external services (like Windguru).
When restarting, with debug=1, the following is in the log

Mar 26 09:48:44 weewx[2286]: vantage: Getting archive packets since 2017-03-26 02:00:00 IST (1490490000)
Mar 26 09:48:44  weewx[2286]: manager: Daily summary version is 2.0
Mar 26 09:48:44  weewx[2286]: vantage: gentle wake up of console successful
Mar 26 09:48:45  weewx[2286]: vantage: Retrieving 91 page(s); starting index= 0
Mar 26 09:48:45  weewx[2286]: vantage: DMPAFT complete: page timestamp 2017-03-16 22:00:00 GMT (1489701600) less than final timestamp 2017-03-26 02:00:00 IST (1490490000)
Mar 26 09:48:45 meteo weewx[2286]: vantage: Catch up complete.

Running wee_device --clear-memory does get it working again.

weewx version 3.7.1
Python 2.7.12 
Linux-4.4.0-62-generic-i686-with-Ubuntu-16.04-xenial
vantage: driver version is 3.0.10

[tkeffer]

Dealing with the daylight savings changes has been a persistent problem with the Vantage stations. The root problem is that the stations store time in local time, with no indication of whether DST is active or not.

However, it rarely causes a problem in the springtime. The reason is that time jumps forward, so there is no ambiguity in times.

By contrast, in the fall, time jumps backwards, so there will be two identical timestamps in the logger's memory.

My Vantage station has no problems in the spring, yet yours does. Could you check something for me? Run the following and post the results. Paths may have to be adjusted, depending on your install method.

cd /home/weewx
./bin/wee_device weewx.conf --info

We are looking for how your Vantage is configured for adjusting DST.

[gearoidgit]

      Use manual or auto DST?       AUTO
      DST setting:                  N/A
      Use GMT offset or zone code?  ZONE_CODE
      Time zone code:               18
      GMT offset:                   N/A

[gearoidgit]

I wonder if using manual and/or GMT offset would make it easier to determine in weewx?

[tkeffer]

Well, setting the Vantage to UTC would certainly make it easier, but I don't think most people would be willing to do that.

Another thing you can do is set record_generation to software.

[tkeffer]

I am open to proposed solutions, but none has occurred to me.

As you can imagine, you only get once a year to test an algorithm, which doesn't make it any easier. Even setting up a test environment is not easy. In addition to setting up an isolated computer with a clock set to the springtime boundary, it also requires at least 2 days to fill up the Vantage logger with old data.

One thing I will do is call the Davis engineers to see if they have any magic ideas.

[gearoidgit]

If we can get any information from Davis on what the incoming data is like at those time boundaries I'm happy to take a look at the code and see can we figure something out.

[r0w4n]

This issue has happed to my setup today.

Computer: Raspberry PI 4
OS: Raspbian Buster
Weewx version: 3.9.2
Driver: Vantage driver version 3.1.1

The daemon status looks good:

`sudo service weewx status
● weewx.service - LSB: weewx weather system
Loaded: loaded (/etc/init.d/weewx; generated)
Active: active (running) since Sun 2020-03-29 02:01:11 BST; 15h ago
Docs: man:systemd-sysv-generator(8)
Process: 1482 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4035)
Memory: 24.7M
CGroup: /system.slice/weewx.service
└─1496 python /usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /etc/weewx/weewx.conf

Mar 29 17:45:20 weatherstation weewx[1496]: copygenerator: copied 0 files to /mnt/ram
Mar 29 17:45:33 weatherstation weewx[1496]: ftpgenerator: ftp'd 36 files in 12.46 seconds
Mar 29 17:50:19 weatherstation weewx[1496]: cheetahgenerator: Generated 8 files for report SeasonsReport in 0.90 secon
Mar 29 17:50:20 weatherstation weewx[1496]: imagegenerator: Generated 28 images for SeasonsReport in 1.59 seconds
Mar 29 17:50:20 weatherstation weewx[1496]: copygenerator: copied 0 files to /mnt/ram
Mar 29 17:50:33 weatherstation weewx[1496]: ftpgenerator: ftp'd 36 files in 12.08 seconds
Mar 29 17:55:17 weatherstation weewx[1496]: cheetahgenerator: Generated 8 files for report SeasonsReport in 0.89 secon
Mar 29 17:55:19 weatherstation weewx[1496]: imagegenerator: Generated 28 images for SeasonsReport in 1.58 seconds
Mar 29 17:55:19 weatherstation weewx[1496]: copygenerator: copied 0 files to /mnt/ram
Mar 29 17:55:30 weatherstation weewx[1496]: ftpgenerator: ftp'd 36 files in 11.49 seconds`

But as you can see it doesn't show up on the website:

At 2 am I have a cron that updates the Vantage and I capture the output:

Using configuration file /etc/weewx/weewx.conf Using Vantage driver version 3.1.1 (weewx.drivers.vantage) Setting time on console... Current console time is 2020-03-29 02:00:14 BST (1585443614)

$ date Sun 29 Mar 18:40:23 BST 2020

Even with a service weewx restart, the website is still stuck on 2am

`wee_device /etc/weewx/weewx.conf --info
Using configuration file /etc/weewx/weewx.conf
Using Vantage driver version 3.1.1 (weewx.drivers.vantage)
Querying...
Davis Vantage EEPROM settings:

CONSOLE TYPE:                   Vantage Vue

CONSOLE FIRMWARE:
  Date:                         Oct 25 2010
  Version:                      2.14

CONSOLE STATION INFO:
  Latitude (onboard):           +50.8°
  Longitude (onboard):          +3.2°
  Use manual or auto DST?       AUTO
  DST setting:                  N/A
  Use GMT offset or zone code?  GMT_OFFSET
  Time zone code:               N/A
  GMT offset:                   +0.0 hours
  Temperature logging:          LAST
  Retransmit channel:           ON (2)`

Strange that it isn't working

[r0w4n]

Further trawling forums pointed to this link:
http://weewx.com/docs/usersguide.htm#html_generated_but_not_updated

Which basically says to clear the vantage's memory which works. So I've put together this cron.

10 02 25-31 3,10 * [ $(date +\%w) -eq '0' ] && /usr/bin/wee_device --clear-memory >/dev/null 2>&1

run at 02:10 on March and October, between 25 and the 31 then if it is a Sunday clear the memory - Hopefully this is helpful to some one like me trying to find a solution.

[ps-crawford]

Same thing has happened again. My ftp's results stopped at 02:00 this morning.

WeeWX still talking to the VantagePro, for example giving time adjustments, but no apparent new data even many hours after clock change.

[r0w4n]

Yep, my suggestion didn't work for me either...

[ps-crawford]

Initially I tried restarting WeeWX, but no success. Then tried:

sudo service weewx stop
sudo /usr/bin/wee_device --dump
sudo /usr/bin/wee_device --clear-memory
sudo service weewx start

That seemed to work!
Without stopping the WeeWX I got CRC time-out errors that killed the wee_device python routine before it completed.

[r0w4n]

I had a play too. I found two issues with my cron command:

1. That wee_device doesn't like to be run without weewx being stopped first
2. The wee_device --clear-memory requires user interaction via command prompt.

I've adapted my cron command to fulfil these:

00 02 25-31 3,10 * [ $(date +\%w) -eq '0' ] && /etc/init.d/weewx stop && /usr/bin/yes | /usr/bin/wee_device --clear-memory && /etc/init.d/weewx start >/dev/null 2>&1

Unfortunately once I've cleared the memory - it works - so to debug is difficult. See you next year if this doesn't work...

[datamgmt]

@r0w4n Exactly the same problem here and your solution worked - thanks

[ps-crawford]

This is STILL BROKEN with WeeWX but now the program /usr/bin/wee_device has gone, presumably after some update!

[tkeffer]

Presumably, you read the Upgrade guide??

[ps-crawford]

Alas, no I did not read the upgrading guide. I simple accepted the automated results of 'apt upgrade' and assumed all would be well. That process has, it seems, left some things like /etc/weewx/scripts/wee_device on my system that no longer work, and removed what I guess was the original /usr/bin/wee_device that actually did the job.

I see you have refused the request to re-open this issue. Fair enough but it seems that every year anyone using the Vantage hardware is faced with a broken system upon DST transition. You mention there "the only fix is to use software record generation" but that is not something that seems to be made clear as to how to fix it. There is no mention under the Vantage hardware guide about this, and things like the work-around above have been silently broken by the 5.x.x upgrade.

Yes, I get it that there is now a different device command, but it would have been nice to have upgrading from 4.x.x leaving simple scripts to replace /usr/bin/wee_device & /etc/weewx/scripts/wee_device that just invoke the new commands so things like cron jobs (example a couple of posts above), etc, still work.

[tkeffer]

Let me remind you: this is free software, created and maintained by hard working volunteers. You didn't pay anything for it and no one is getting paid.

Like all volunteer efforts, it follows a simple rule: if you don't contribute, you don't get to whine (especially with all caps and bold face).

Feel free to submit a PR with the changes that you suggest. That would be a more useful contribution.

[ps-crawford]

My apologies for that.