Davis Vantage Pro2 on RPI, problem with console time adjustment

[Zeky91]

Hi.

lately i started to use RPI with Raspbian Stretch(last version) to send data from Davis console with data logger online.

Equipment is at my place at the moment, im testing it and it will go in remote location soon.

Everything is working nice, I have adjusted to send archives from Davis every 5 minutes, and ftp, wunderground, cwop...Everything working great, no errors.

I have just one problem. I simulated power outages(which will happen, location is solar powered) and when powering rpi wewx starts BEFORE ntp has finished checking and updating time! So soon after boot, weewx adjusts time on Davis to his time(which is wrong, its last time RPI was online). I have removed fake clock, and it seems that its still working? Because after boot, i always get this time when RPI was shut off. So, that leads to wrong archive time, and that could be a big problem because many power outages.

I was searching, and seems that weewx should wait for ntp to adjust time, and start after that, but that is not working correctly. 

I made a workaround by adjusting max_drift to big value, like 864000 so time will never update by itself(i can do it mannualy over team viewer with wee_device commands.

Is there any way to delay console time update, so rpi has few minutes of time to update ntp?

Or even, not to start weewx until ntp has finished updating(I checked weewx filein ini.d folder, ntp is listed as start requirment.

Is this some type of bug, and is there any way to prolong davis time synchronization, or to start weewx after time has been upgraded?

Regards

Željko from Croatia

[mwall]

weewx will not process data until the time is after 00:00:00 01jan2000 utc.  so perhaps your pi is reverting/starting at a time that is later than that.

you can make the weewx time check a bit more robust by modifying engine.py

change this:

    while weewx.launchtime_ts < 946684800:

to a more recent value.  however, that approach can only go so far.

the init systems also have mechanisms for delaying the start of weewx.  unfortunately, those may not do exactly what you expect.  for example, you might make weewx start after ntp, but just because ntp has started, the system may not have a valid time.  you'll have to dig deeper to tell your init system that weewx should not start until after ntp has started AND after ntp has set the system time.

or put a real-time clock on the pi.

m

[Thomas Keffer]

If you removed the fake clock, it should start at unix epoch time zero. If it's not, it's because the module was not removed properly. See the Wiki.

In any case, the running an RTC is the right thing to do, particularly with a remote location that may have intermittent, or very delayed, access to NTP.

-tk

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Keffer]

Incidentally, before you purge the fake clock, see if the file /etc/fake-hwclock.data is still around. That would cause your symptoms. Purging should remove the file. If it's not, remove it manually:

sudo rm /etc/fake-hwclock.data

-tk

[Zeky91]

Hm

I used purge command. 

And i dont have file /etc/fake-hwclock.data 

I am using latest Raspbian edition,stretch.

Tomorrow we are going on location, so for now will need to work like this ;) In the meantime, i hope to arrange something.

Internet on location is ok, so everything should work fine except this problem. Or even if there was workaround to skip first console time update, that would solve my problem, because console is not so bad at timekeeping, its important that its within few minutes, few seconds doesnt matter.

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[Andrew Milner]

What does the log show when you start up after a power outage??  

The rp should have time set to epoch 0 - jan 1970 or whatever following the power outage - assuming that all references to fake hardware clock have been correctly removed/purged

weewx will start, but should detect the time is not > 2000 and so wait for a better time - which will not happen until after NTP has set the rpi time

once time is set > 2000 weewx should then start to process the data and sart by retrieving logged data from the davis

weewx should then start the main packet loop

[gjr80]

Hi,

Since you are running Stretch is systemd-timesyncd enabled? I understand can do a similar thing to the fake hardware clock (ie save and restore an old system time) but can also sync via ntp. Quite possibly it can be configured to not save the time as the fake hardware clock and just sync via ntp, that is left as an exercise for the inquisitive :) Try disabling it via

$ sudo systemctl disable systemd-timesyncd

Gary

[John]

for setups with a Davis console it would be nice to configure the rpi to get time from the console as an alternate option to a RTC.  

Once time is updated from an NTP source, then both the rpi and the console could be updated.

[Andrew Milner]

The simplest (and most correct) way, IMHO, for 10-15 bucks, is to fit a RTC to the RPi to turn a board computer like the Pi into a real computer if that is what it is going to be used as.  The cost of coding and testing even a one line program change is far far more expensive!!

[John]

IMO, adding a RTC to an internet connected device seems redundant and doubly redundant when already connected to a device with a battery backed RTC like the Davis Vantage console. 

browsing the vantage drive source there is already code for retrieving the console time. 

compare the retrieved time from the console to rpi system time, if more than max_drift make a call to set system time. this would remedy the OP's problem.  

when the rpi gets a time update from an NTP source weewx will compare and update the time on the console. 

[vince]

On Monday, January 22, 2018 at 7:06:48 PM UTC-8, John wrote:

for setups with a Davis console it would be nice to configure the rpi to get time from the console as an alternate option to a RTC.  

Once time is updated from an NTP source, then both the rpi and the console could be updated.

Just disable fake-hwclock on the pi and run a NTP client.  Done and done.

[Thomas Keffer]

A pull request that does this, while not breaking compatibility with other weather stations that do not have this feature (i.e., most), would be welcome.

-tk

--

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+unsubscribe@googlegroups.com.

[Zeky91]

I understand this, but after power on, RPI (stretch) clock is on latest time while it was on, no matter i have purged fake clock. I tried DietPi OS, without any addon, and it is the same again. 

RPI is now working on 1630m ASL, so I will not test on it now, for now I update it manually every now and then.

I have another test RPI at home(DietPi running with Davis Vantage Pro2 connected) so when I have time, I will try your ideas. On this one, setup is default, and internet was down for 30 minutes, and while changing router RPI was restarted, and now i have again wrong time on console(test setup at home) Is there possible that strech has some other type of clock(not fake clock)?

Maybe I should install older version of Raspbian? Or there is some other way.

Best regards

Željko from Croatia

[gjr80]

So did you disable systemd-timesynd as I suggested?

Gary

[Zeky91]

Yes, i have tried that but its again the same.
If I disconnect power for 5 minutes on RPI, when I reconnect rpi updates time on Davis to old time(5minutes ago) and after few seconds more to one minute rpi gets real time! If I reboot rpi after this with reboot comand, after that time is normal.
Or thru wee_device --set-time
Regards

[vince]

Again, if you are on a pi and you get good behavior after a 'reboot' and bad behavior after a power disconnect, then your pi is coming up and trying to start weewx before it knows correct time.  This historically has been that fake-hwclock thing, but perhaps systemd has something equivalent doing the same bad behavior.

Just for a test, disable weewx via systemctl and power the pi off then on.   Then manually start weewx after it powers back up.  I suspect things will work correctly.   This will verify that it's the pi os feeding incorrect time after a powerup.

[Praveen Chandrasekaran]

I used to have similar issue where on powerup sometimes it used to start at 1970 and at other times in Nov 3 2016. Googled and found few others also reporting same issue. For now have modifed weewx to check if time is in 2018 before starting. Still got one issue few days back with time corruption but it has become more infrequent now. I have a RTC ready though, just dont have time to install it yet.

[Thomas Keffer]

For now have modifed weewx to check if time is in 2018 before starting. 

Since V3.4, ​weeWX has​ looped until the time is after 1 January 2000 before starting.

-tk

[Praveen Chandrasekaran]

I knew that but my rpi was at times starting up with time in 2016. Hence I changed the check to 2018 instead of 1 Jan 2018 instead.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/2zZOIBaUoKk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Zeky91]

Which OS do you use, Raspbian? Which version? Newest stretch, older stretch, jessie? Maybe its problem because I have last stretch version and app was made for older?
Regards

[Praveen Chandrasekaran]

I use the latest version of stretch. Going through forum yesterday I realized best way to fix the problem is to disable stdTimeSync in weewx. Done that now. Maybe you can also do that. 

On 6 Feb 2018 2:54 a.m., "Zeky91" <zek...@gmail.com> wrote:

Which OS do you use, Raspbian? Which version? Newest stretch, older stretch, jessie? Maybe its problem because I have last stretch version and app was made for older?
Regards

[Zeky91]

Me too, I just increased parameter off error below which there is no need to check. How to disable it fully?
I am thinking of installing jessie or some other(older) version of stretch, so if this problem is not happening on older versions, please let me know :-)

Regards

[Praveen Chandrasekaran]

Search for prep_services in weewx.conf and remove StdTimeSynch from the same.

Regards

[Zeky91]

Thanks.

Just now i realised that its possible to disable it fully.

I got not perfect workaround.

I used crontab -e and added 33 0   *   *   *    sudo wee_device --set-time % y -r

This is the same command which I used manually to update time. Sometimes it doesnt manages to update because its fighting with weewx hah. But every few days is still ok ;)

I will leave it like this, and one more station will be running on weewx soon.

btw. i use crontab for one more thing 33 0   *   *   *    sudo wee_device --set-time % y -r

That is scheduled restart at midnight(2 minutes later so data can be sent at 00:00). I got advice to do so, so I didnt wanted to risk some problem with the remote location RPI 

Location is highest automatic station in Croatia, solar powered so there is no place for stupid errors. You can see it here http://pljusak.com/dinara/

For now this is not bad solution, I will explore further. Thank you for your cooperation.

Regards

On Tuesday, February 6, 2018 at 9:25:59 AM UTC+1, Praveen Chandrasekaran wrote:

Search for prep_services in weewx.conf and remove StdTimeSynch from the same.

On 6 February 2018 at 13:46, Zeky91 <zek...@gmail.com> wrote:

Me too, I just increased parameter off error below which there is no need to check. How to disable it fully?
I am thinking of installing jessie or some other(older) version of stretch, so if this problem is not happening on older versions, please let me know :-)

Regards

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/2zZOIBaUoKk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.