I’m building a display using local data from the UDP messages and would like to show rain accumulation for the day. I’ve currently implemented this by keeping a running sum of the “previous minute” rain accumulation numbers, but this is proving to be lossy in practice. My numbers are pretty consistently lower than the values shown in the app (without RainCheck), so I’m probably missing messages due to network flakiness.
I’m aware that I can get a more accurate accumulation number via the REST API, but I’m trying to keep this restricted to local data (it’s the main reason I got a Tempest!). Any chance this could be tracked at the hub/station and added to the UDP API?
If you run weewx you can get everything the UDP sees handled basically for free.
If you find you are missing UDP messages, move the computer that is listening to them to a wired connection perhaps. I found that local neighbors with misconfigured wifi had a pretty significant effect on my gear missing observations. With a wired listener (on a pi) it always heard 100% of the messages.
You cannot run a Tempest without an internet connection to the WF servers. While you can listen for UDP locally for whatever is broadcast via that API, you can’t simply block all communications to Internet and have a working Tempest. There are a zillion threads here for years explaining the gory details.
First pass would be to listen for obs_st messages and simply count them and see if you missed any vs. what you calculate you should have had. Assuming your battery isn’t drained too much you should see those once per minute.
Odds of the UDP API being extended are probably as close to zero as you can imagine. It hasn’t changed in years at this point.
The computer that is listening is hard wired, but the hub is not. It’s currently located somewhere with a clear line of sight to the station but with no available Ethernet hookup. I could move it, and might do so at some point, but WiFi reliability is only one of the many reasons that I could miss a broadcast and I can’t solve all of them.
Some other reasons that come to mind: power brownout/blackout, router downtime (updates or configuration changes), computer downtime (again, updating things, like weewx), hub downtime (fiddling with power cables or physically moving it). If any of these happen while it’s raining, then I’ll miss a broadcast. I assume that the station/hub has a more robust batching/retry mechanism for communicating between themselves and the WF servers, so that pipeline is more resilient to temporary outages like this.
I recognize that this is pretty unimportant in the grand scheme of things, my numbers are generally close enough so far, but just figured I’d ask! I saw a couple other posts here from people inquiring about daily rain accumulation, so it might be worth improving this at some point.
Hi @mattprecious
The hub is only able to connect to internet using wifi 2.4Ghz. It has no ethernet socket. @GaryFunk built a display using UDP which operated without a connection to the internet but it was developed for the Air and Sky which were an early version of the Tempest.
You can learn more about it here:
FWIW my network here is down only for router/switch firmware updates that I choose to do (maybe a couple minutes per year) and a weewx host can generally run many months without outages unless you’re fiddling around for the fun of it there.
So if you have hub and listening computer and wifi AP on a UPS you’d likely not miss anything locally, depending on how you have your LAN set up.
The Tempest does have some storage for when it can’t reach the Hub (ie, hub not powered up) and the Hub has some storage for when it can’t reach the WF servers (router/gateway or internet down), and the Hub does do some catchup UDP broadcasts if I recall correctly from ancient other threads here. Precise details would be in those other threads.
If you have typically pretty stable power, I’d just do nothing and if you miss a few readings, not a big deal probably…
accumulation should be done by adding the (received rate of the previous received value, with the current received value ) divided by 2 and multiplied by the time interval.
For various reasons the time interval might not be 1 minute every time. You might have missed a message, or the device might have gone into powersave.
