Davis Vantage Pro2 no data

[Asherah]

Hi,

after an update to the lastet version of weewx it does not get any data from my station anymore. With —info I get

Using configuration file /etc/weewx/weewx.conf
Using Vantage driver version 3.1.1 (weewx.drivers.vantage)
Unable to wake up console... sleeping
Unable to wake up console... retrying
Traceback (most recent call last):
File "/usr/bin/wee_device", line 66, in <module>
main()
File "/usr/bin/wee_device", line 62, in main
device.configure(config_dict)
File "/usr/share/weewx/weewx/drivers/__init__.py", line 69, in configure
self.do_options(options, parser, config_dict, prompt)
File "/usr/share/weewx/weewx/drivers/vantage.py", line 1972, in do_options
station = Vantage(**config_dict[DRIVER_NAME])
File "/usr/share/weewx/weewx/drivers/vantage.py", line 489, in __init__
syslog.syslog(syslog.LOG_DEBUG, "vantage: Hardware name: %s" % self.hardware_name)
File "/usr/share/weewx/weewx/drivers/vantage.py", line 1255, in hardware_name
raise weewx.UnsupportedFeature("Unknown hardware type %d" % self.hardware_type)
weewx.UnsupportedFeature: Unknown hardware type 10

As I am lost I am looking for help. Thank you

[Thomas Keffer]

Your logger is responding with an unknown hardware type. I doubt this has anything to do with the upgrade.

Try power cycling:  unplug the power supply from your Vantage and take out its batteries. While you are at it, reseat the logger. Then put everything back together and try again.

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

[Asherah]

Unfortunately this did not help. I removed batteries, power and and the usb data logger overnight, restarted my Pi and still get

wee_device --info

Using configuration file /etc/weewx/weewx.conf

Using Vantage driver version 3.1.1 (weewx.drivers.vantage)

Unable to wake up console... sleeping

Unable to wake up console... retrying

Traceback (most recent call last):

  File "/usr/bin/wee_device", line 66, in <module>

    main()

  File "/usr/bin/wee_device", line 62, in main

    device.configure(config_dict)

  File "/usr/share/weewx/weewx/drivers/__init__.py", line 69, in configure

    self.do_options(options, parser, config_dict, prompt)

  File "/usr/share/weewx/weewx/drivers/vantage.py", line 1972, in do_options

    station = Vantage(**config_dict[DRIVER_NAME])

  File "/usr/share/weewx/weewx/drivers/vantage.py", line 489, in __init__

    syslog.syslog(syslog.LOG_DEBUG, "vantage: Hardware name: %s" % self.hardware_name)

  File "/usr/share/weewx/weewx/drivers/vantage.py", line 1255, in hardware_name

    raise weewx.UnsupportedFeature("Unknown hardware type %d" % self.hardware_type)

weewx.UnsupportedFeature: Unknown hardware type 79

If I try it repeatedly I do get data

Using Vantage driver version 3.1.1 (weewx.drivers.vantage)

Querying...

Unable to wake up console... sleeping

Unable to wake up console... retrying

Davis Vantage EEPROM settings:

    

    CONSOLE TYPE:                   Vantage Pro2

    

    CONSOLE FIRMWARE:

      Date:                         Jun  3 2013

      Version:                      3.15

    

    CONSOLE SETTINGS:

      Archive interval:             300 (seconds)

      Altitude:                     27 (meter)

      Wind cup type:                large

      Rain bucket type:             0.01 inches

      Rain year start:              1

      Onboard time:                 2019-03-04 11:20:46

      

    CONSOLE DISPLAY UNITS:

      Barometer:                    hPa

      Temperature:                  degree_C

      Rain:                         mm

      Wind:                         km_per_hour

      

    CONSOLE STATION INFO:

      Latitude (onboard):           +53.3°

      Longitude (onboard):          +10.3°

      Use manual or auto DST?       AUTO

      DST setting:                  N/A

      Use GMT offset or zone code?  ZONE_CODE

      Time zone code:               20

      GMT offset:                   N/A

      Temperature logging:          LAST

      Retransmit channel:           OFF (0)

        

    TRANSMITTERS: 

      Channel   Receive   Repeater  Type

         1      active      none    (N/A) 

         2      active      none    (N/A) 

         3      inactive    none    (N/A) 

         4      inactive    none    (N/A) 

         5      inactive    none    (N/A) 

         6      inactive    none    (N/A) 

         7      inactive    none    iss 

         8      inactive    none    (N/A) 

    RECEPTION STATS:

      Total packets received:       802

      Total packets missed:         4

      Number of resynchronizations: 0

      Longest good stretch:         316

      Number of CRC errors:         1

      

    BAROMETER CALIBRATION DATA:

      Current barometer reading:    28.939 inHg

      Altitude:                     89 feet

      Dew point:                    42 F

      Virtual temperature:          50 F

      Humidity correction factor:   1.8

      Correction ratio:             1.003

      Correction constant:          +0.000 inHg

      Gain:                         -1.000

      Offset:                       -1.000

      

    OFFSETS:

      Wind direction:               +0 deg

      Inside Temperature:           +0.0 F

      Inside Humidity:              +0 %

      Outside Temperature:          +0.0 F

      Outside Humidity:             +0 %

But weewx still does not get any data. It stopped working shortly after updating to the latest version. 

[Asherah]

I just had success with

wee_device --set-interval=1

as it cleans all the old data. Now weewx does get the new data. Might it be that my USB Logger has a defect? I will keep you posted.

[Thomas Keffer]

When you changed the logging interval to one minute, you also cleared the memory in the logger. It's possible that your problem all along was corrupt logger memory, but I would be surprised if that showed itself as an unknown hardware type. 

If it fails again, you probably have a bad logger. It's rare, but we've seen a couple through the years.

-tk

[John]

I have been experiencing similar problems recently with my Vantage Pro 2 console and RPI (Zero W) setup, typically after a prolonged (1+ hours) power outage.  My only recovery method so far has been to clear the logger which unfortunately leaves me without the storm data that initiated the power outage.

I have a theory, uninvestigated, that upon restart the logger is getting corrupted with date-time changes as the RPI starts up with the incorrect time and communicates with the logger, trying to sync time,  before obtaining the correct time from a time server.  When I have extended power outages, my internet provider is often offline as well so getting my lan back to the correct time has been problematic. I think I have remedied this by adding a battery backed RTC into my lan setup. One of my recovery problems was rooted in DNS queries for time servers failing because of gross time differences.   I briefly explored using the vantage console as a battery backed time source.

John

[David Beach]

I spent a fair bit of time on what I believe is the same issue. I even installed an Adafruit RTC and that didn't seem to solve the issue. At the moment, I have the system on a UPS (which is huge and probably uses more power than my Console, Adapter/Logger module and the RPi Zero W). My UPS battery is dying so I will have to replace it soon if I plan to continue to use it.

I am not so much worried about losing data - though I can understand preserving the data is important for many people - but I just want the darn thing to start working again when the power comes back on. If I'm not around, it may go for many hours after the power has been restored, not working properly, until I clear the logger memory.

I'll be interested in seeing the comments!

David

[John]

so looking at the vantage driver it seems that if the weewx host (raspberry pi zero without a RTC) has an incorrect time like after a restart and syncs it's bad (early) time with the vantage console, then records being added to the vantage console will have an earlier timestamp than existing records. when weewx goes to read the records and finds a "decreasing timestamp" it stops reading more records. manually clearing all the records AND setting the correct time is a solution.

I propose changing the vantage driver to avert setting the console time, during a routine sync, earlier than the last record in the console. This should prevent weewx from adjusting the console time until the weewx host has had an opportunity to successfully acquire the time from an external source (ntp server).   I suppose setting the console to a future time could cause a problem, preventing weewx from correcting the console time without first clearing the last (errant) record.

[Andrew Milner]

I would recommend you doing the CORRECT solution and installing an RTC on your Pi zero.  Weewx relies HEAVILY on accurate time synchronisation between weather station and controlling PC - so ensuring your pi EITHER has an RTC onboard OR prevents weewx starting until time has been synchronised is ESSENTIAL for correct operation.

There are many many users of weewx with Davis stations, and many many of us with various models of RPi.  There are also many instances of logger corruptions and other anomolies.. so fudging the driver for one situation may open a can of worms in another situation - you have been warned!!!!!

[John]

The instructions for delaying weewx from starting on the Raspberry Pi until time is synced don't seem to be working with stretch and timesyncd as the network time client.  If I "systemctl disable systemd-timesyncd"  it never updates from the ntp server and weewx spins away with "engine: Waiting for sane time. Current time is  ... "

I have a local ntp server with a battery backed rtc. A raspberry pi with a rtc that is running as my dns/dhcp server, and pi-hole.

[Andrew Milner]

fitting a RTC is the best solution to make the RPi more like a 'normal' computer - especially when used for real world production use.  

[John]

I've disabled weewx from syncing the vantage console's clock. I had an another power outage yesterday for a bit over an hour and everything seemed to eventually recover without intervention. The battery backed clock in the vantage console seems to be adequate. Most routines for syncing battery backed clocks seem to protect against gross changes, requiring a manual/forced update if the time deltas are larger than a routine drift. 

[Andrew Milner]

John

the issue is not with syncing the clock as such.  The issues are caused by records in the database with weewx generated timestamps which will be incorrect if weewx is started with an incorrect time set on the rpi.  The solution is to install an rtc on the rpi and to be honest I just do not understand your reluctance since they only cost 10-12 dollars.  a computer needs a clock - a teaching aid (as the rpi was designed for originally) doesn't.  Give your RPi a clock!!!!!

[Oliver Giessler]

Just my 2 Cent as the thread opener:

I solved my problem by removing the batteries from my Vantage Pro2 and having just the powercord. Do not ask my why this solved it …

--
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/UM-q_RNK_Ps/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/32f79d61-7d81-4bc0-adab-6d1ad66de99c%40googlegroups.com.

[mwall]

On Tuesday, May 28, 2019 at 11:00:09 AM UTC-4, John wrote:

I propose changing the vantage driver to avert setting the console time, during a routine sync, earlier than the last record in the console. This should prevent weewx from adjusting the console time until the weewx host has had an opportunity to successfully acquire the time from an external source (ntp server).   I suppose setting the console to a future time could cause a problem, preventing weewx from correcting the console time without first clearing the last (errant) record.

merge requests are welcome!

it might help to clarify the scenarios before pushing for a specific solution.

scenario 1: standalone rpi.  options are to install a clock, depend on ntp, or both.  if network is flaky, then the clock might be preferred.  in either case, get rid of fakehwclock.  if you depend on setting time over the network, then absolutely get rid of the systemd timesync and install a real service such as ntp.

scenario 2: rpi on your own network where you can control time.  run an ntp server on your network, sync it to a other ntp servers or your own gps or other device with known reliable time.  get rid of any systemd rubbish and install ntp on the rpi, then configure it to use your time server.

scenario 3: use the weather station's clock to set the rpi clock.  this could be done independently of weewx, and probably in a pretty generic way that could work for many types of stations.  or it could be done in the weewx driver (less desirable).  or it could be done as a generic weewx service.  you'll probably never get it to be as accurate as ntp, but it might be good enough.

i am sure there are other scenarios...

m

[John]

Andrew,

I am not having a problem with records in the weewx database with incorrect timestamps. I am having a problem with weewx not downloading data from the console after an extended power outage.  The underlying problem seems to be that if weewx updates the console clock to something earlier than the last record in the console's data logger, then weewx will break.  The quick solution is to disable weewx from updating the console clock. 

[Liz]

On Thu, 30 May 2019 04:58:37 -0700 (PDT)
mwall <goo...@lancet.mit.edu> wrote:

> i am sure there are other scenarios...
>
> m

Thankyou mwall for a better discussion of the options.

Liz

[gjr80]

My recollection is that the 'incorrect system time at startup' issue has been one that seems to rear its head every now and then. Whilst the preferred solution is to have a battery backed RTC there have been various approaches taken in the WeeWX code base to ameliorate the situation where a battery backed RTC does not exist. These approaches have primarily been because of issues with the RPi but apply equally to any device. I believe the current approach is for WeeWX to block on startup until it sees a system date-time that is the same or more recent that than the weewx.conf file timestamp. The reasoning being that a system with no battery backed RTC or is yet to sync via NTP will revert to a system date-time of somewhere in the 1970s (epoch start ?) and weewx.conf will always be timestamped later than the startup date-time. The obvious issue here is the RPi fake hardware clock that will cause the RPi to reboot with a more recent system date-time, one that could be more recent than the weewx.conf timestamp, and hence could still cause issues with a near but not close enough system date-time. The solution thus relies on the RPi fake hardware clock being disabled.

Perhaps the issue is compounded by changes from jessie to stretch (systemd handling of time sync ?), but I don't see the point in going off down another rabbit hole until we know the current approach does not work. I agree the problem is likely system time related but I have not yet seen anything in any of the recent threads that shows that when properly implemented the current approach is failing.

Gary