I’ve been happily running with Tempest, Weewx, WeatherFlowUDP driver 1.13 for almost a year.
A few days ago, everything came to a screeching halt. Weewx refuses to start. I changed nothing at all.
Took some time to dig in and here’s as far as I’ve gotten:
The crash comes during an immediate attempt to obtain catch-up data from the WF REST API, using a URL of approx: /swd/rest/observations/device/nnnnn2?token=xyzzy&time_start=aaa&time_end=bbb HTTP/1.1
There is a device id for the hub (HB-nnnnn) and for the Tempest sensor (ST-nnnnn) so that’s fine. If you look at the REST and UDP API you will see that each piece of hardware provides some data, so the whole picture is basically additive. Basically a ‘station’ is the combination of a hub and whatever sensors (plural, possibly) are linked to that hub.
I’m not sure what perceived bug in the weewx driver you’re speaking of, in the absence of you providing any weewx logs.
Seeing a version of 1.13 leads me to believe that you’re using a forked driver rather than the @vreihen reference driver (which stopped at 1.10) which is basically bulletproof. I know there was at least one fellow who was trying to add support for the REST interface, but I don’t have any experience with it so I can’t speculate how stable it might be, especially since the WF servers seem to get bouncy occasionally according to some other threads I’ve seen.
Regardless, nobody can help trying to fix ‘it broke’ reports without seeing some debug=1 logs from weewx. Set that and restart weewx and provide your logs wherever your driver’s support forum or thread or github issues location might be.
If you’re not going to provide the actual weewx logs with debug=1, you’re just going to keep on guessing by yourself and nobody’s going to be able to help. Best of luck.
Vince is right that having a link to the driver (via github) and some debug logs would be good. If the driver is assuming the order of the devices returned in the API call it could be the use of a positional argument rather than naming it or checking the ID for the correct format.
I’d love to see the logs that Vince is talking about along with the driver github too!
I also have 500 errors with the same version of the driver when starting (I’m the author of the branch that version comes from) but I’ve been away for the christmas holidays so haven’t had a chance to look into this yet. I’m assuming your problems are the same as mine, but at this point I haven’t done any triaging yet so that’s just guessing.
I hope to look into this soon, hopefully tonight, but no promises But I do want my station up and running again, so I suppose I’ll find the time soonish
Thanks for the investigations, I’ll look into that in more detail later on
I think I’ve fixed it although I’ve not yet made it into an official release.
I suspect the problem actually is caused by a bug in the WeatherFlow api. The driver requests for every device it the list the observations. This by default includes the hubs even though they normally don’t have any observations (the UDP packages do contain an observation: the wifi strenght. But that’s not available through the api). Recently, this call returns a 500 error with some text suggesting a Java NullReference error somewhere. This is a server problem and not a client problem. Which is why I strongly suspect this is a bug in the WeatherFlow api.
I’ve fixed it by checked the type of device and if it is either a hub or unknown it assumes there’s no point in asking its observations. That could potentially break if in the future the hub does have observations (it might get expanded with an indoor temperature sensor, or it might provide the wifi strength…) but if that happens I suppose I need to change the driver anyway to provide these new fields, so…
Given that the problem is caused by requesting data from the hub, you should be able to circumvent the problem also using the current driver and adding the configuration ‘devices = TS-12345678’ in the WeatherFlowUDP section of the weewx.conf file (replacing TS-12345678 with the serial number/name of the device (or devices, comma separated) you have.
I’ll see if I can make a proper release of it, but that will not happen this evening. I also noticed also a couple of issues in the github page and a pull request I hadn’t been aware of until now. Uuups.
My apologies, my forgettory kicked in and I neglected to come back here to update in the community!
Here’s an update: over in github, we’ve fully resolved the issue.
The WeatherFlow API officially lacks support for observation data requests relating to the Hub (HB) device in a Tempest; yet it returns the HB as one of the devices in a list of station devices.
As a result, it is necessary now to filter out the HB device when requesting data from the API.
With such filtering in place, all is well!
@jjvdgeer has updated his version of the driver to rev 1.14, incorporating a fix.
(BTW, WeatherFlow recommends use of the direct/local UDP data stream only as a backup for the cloud-based REST and WebSockets API’s. Personally, I’m grateful for the local stream: not only is it a bit more timely, but in my life I’ve been off-grid let alone off-internet quite a few times. Nice to know this can function well without internet at all )
THANK YOU all for coming alongside on this. A great community.
It’s been a while since I was last here, but anyway: They may say it’s not a bug but from a purists view any reproducable way to create a 500-error from a website or web-api is a bug… If they don’t support it they should have returned some 400-series error. 500 means server error, that’s never the correct thing to return.
But I do want my station up and running again, so I suppose I’ll find the time soonish 