Hello,
I’m working on integration Weatheflow Tempsest (via REST) into Home Assistant.
I currently got the forecast data into Home Assistant via the better_forecast endpoint - but I’m confused also how I should expose sensors.
- REST APi (better forecast / or via one of the observation endpoints)
- Using web sockets?
I’m assuming I’ll use web sockets for Rain/Lightning Strikes - but I’m still unsure the best way to get sensor readings.
Does the current conditions of better_forecast take into account the /observations/xxx endpoints?
Thanks
I’m not sure I’m following what your question is for better_forecast? That endpoint just provides you with the forecast data that displays in the app. Here is the doc on what the Tempest forecast utilizes.
As for exposing the sensors, it depends on how you want to get the data. The options are REST, Websockets, or UDP.
Personally, I use Websockets. I have a websocket listener waiting for data to come in and when it does, broadcasts it to my SmartThings instance via MQTT.
Lightinging strikes are one you’ll want to think about. The lightning sensor on the Tempest is not very good. In my testing, it only detects about 25% of the lightning strikes and it isn’t capable of telling you how far away the strike hit, only how far away the front edge of the storm is. I’d only suggest using UDP if you are dead set on knowing when your specific sensor detected a strike. Because of that, I also use Websockets for lighting strike data. The websocket data has been manipulated by Weatherflow using other sensors. The strike data you get in the websocket will have other strikes that were detected by sensors other along with your own so it gets the ones your sensor misses. Since the strike data was collected by multiple sources, they can also triangulate were the strike happened and give you an actual distance.
If you want what your sensor emitted, use UDP. Lots of people feed MQTT from the UDP. My wfudptools listener can do that. Weewx plus the MQTT publisher can do it too. Many other packages exist.
If you want what WF massages your sensor data to look like, use websockets.
UDP can’t measure lightning worth diddly, and your lightning data available via the phone app and I think websockets is all made up from mysterious sources via WF’s magic math. Rain can be massaged the next day by RainCheck (if they still call it that). Forecast is only on their server too.
But UDP is what your sensors actually measured…
It is now NearCast Rain and happens in pseudo-real-time.
2 Likes
Will the REST endpoint take into account other sensors in the area? Like if mine went down?
I’m going to assume websockets is coming locally from the sensor
No, the endpoint is their server…UDP is what your sensor is broadcasting to your LAN and should match what their servers see (before they massage anything there)
So webaockets are not udp exposed via a wss interface?
Not understanding how that would be even possible.
wss://ws.weatherflow.com/swd/data?token=[your_access_token] opens a connection to the WF servers from whatever host you are querying from, either on your LAN or anywhere else that can reach the WF servers.
Good page is What are WebSockets? | Web Security Academy
UDP is the Hub broadcast on your LAN that you can choose to listen if so inclined. Broadcasts don’t route. You can’t even see them from a network ‘other’ than your LAN unless you do very special things for very special cases I won’t get into here.
UDP is what your sensor emits via the Hub. Other mechanisms are what WF received and potentially massaged or magically generated based on whatever data and algorithms they have.
Two different things.
My base station reports to weatherflow servers. Udp shows its local observations. I assume they get published to weatherflow no?
I guess I could watch the ws and udp concurrently and answer my own question.
It’s also possible the station opens a ws to weatherflow to deliver updates directly
I think the WF behavior is pretty well documented after all these years.
UDP broadcasts to LAN. Same data gets sent via a persistent connection to the WF servers. WF sends tuning and updates the other way through that persistent connection if my memory isn’t too hazy.
The WF servers permit queries via REST or Websockets if you want to bang on their servers for your data and do it that way.
I think there’s already a HA integration or ten for reading the WF UDP, but FWIW what I tend to do for HA is to get everything into MQTT and then have HA just subscribe to those topics.
I do have HA just hitting local REST endpoints for my PurpleAir and Davis Airlink AQI sensors since they make that local access easily available. Unfortunately WF doesn’t expose any REST endpoints on the Hub so you have to listen to the UDP broadcasts if you want to stay with local data as much as possible.
1 Like
There have been multiple hacs integrations. I got a local one into core few releases ago and rest forecasts will be coming out next release.
1 Like