WeatherFlowUDP: should ignore HB device type!

[MrPete]

My Weewx now crashes continually, due to a new problem in the link from WeatherFlowUDP to the WeatherFlow REST API:

* I'm getting crashes due to a 500 error returning from the API

* Turns out the Weewx driver is attempting to retrieve observations from all "devices" in the station... but the station has both a Hub and a Sensor device... in my case the Hub is now listed first, and returns a 500 error if an attempt is made to retrieve observations :(

I'm not sure how to code the fix; all I know is the returned json in the api has device_type "HB" ;)

[vince]

I answered you over in the WF forums a couple times.

The reference WF UDP driver (https://github.com/captain-coredump/weatherflow-udp - last changed 2.5 years ago) doesn't even talk REST so you must be using a forked variant from some of the efforts to add REST support.  You'll likely need to contact that author for support.   If you want people here to try to help, set debug=1 in weewx.conf, restart weewx, and provide us some logs to look at.

[MrPete]

THANKS!

I now understand more. that yes, it's a fork to add REST support (so it can catch up... and because WeatherFlow highly recommends making use of REST instead of UDP whenever possible ;) ).
I connected with WeatherFlow support. Turns out, accessing the Hub in the REST API simply is not supported.
I've now got a workaround, and will connect with those developing REST support for the driver, so they can fix it. (Or, perhaps it's time to learn enough so I can provide a proper patch myself... I supposedly am a semi-retired dev myself LOL!)

I think we're done here. Appreciate the feedback muchly.

Pete

[vince]

If you simply run the stock UDP listener, it will hear whatever the Hub emits as catchup 'to' the WF servers when your power comes back up and you'll catch up that way, although the data will be what your sensor 'heard', not whatever readings the WF servers 'alter' based on their proprietary math on the server side.

The only value I can think of re: REST for a weewx user is that the WF servers have calculated data not available on the UDP broadcasts (ugh) like modified lightning and rain data.  Otherwise personally I'd run LAN-only with the reference UDP driver...

[MrPete]

Interesting on the "calculated" data... my Tempest needs serious recalibration of the raw rain data. Collected a whole season last year; will soon submit it to them.

I'm wondering if "modified" rain data from REST includes recalibrated rain, while UDP rain is uncalibrated?

[MrPete]

Oh, the nice thing about using REST for catchup is it can request all missing data. The local hub only sends what it thinks is needed, as there can be no requests.

Power outages aren't the only things that cause data gaps ;)

[vince]

REST is whatever WF has stored on their servers.  UDP is whatever your station sent them to begin with.

The UDP is 'always' what the sensors (Tempest/Air/Sky) read at their current tunings, and it indicates what the Hub transmits to WF.

The sensors have limited storage for when they can't reach the Hub (hub down, usually), and the Hub has larger storage for when it can't reach the WF servers (power/internet outages, etc.) so both catch up gracefully.  The effect is the Hub will emit appropriate catchup UDP to the LAN and transmit the same info to WF as needed.

The weewx reference UDP driver hears whatever UDP the Hub emits, whenever it emits it, and does the right thing.