I have had it only happen twice in the last 7 days. Looking at the two records it's not the same fields each time.
I wondered if they did some software update somewhere, and it is not resetting thing properly. Not really sure, only saw the bad data, and rebooted the wifi device, that did not fix it, so then rebooted the outdoor device and it did fix it.
From what I'm told this is expected behavior, Tempest voltage level versus power save mode - Owners - Tempest Weather System check your battery voltage and see if it aligns with that chart.
Based on this it sounds like this is behavior the driver should deal with. And maybe display the battery info?
1 Like
perhaps, but my voltages were fine when I had the issue, and it did not correct over several sunny days. Switch off/on solved it immediately. It seems the states they describe change frequency of reports (at least initially) vs. bad data.
I don't know exactly, all I know is they are saying nulls are valid and should be handled. Possible Bug - WebSocket API Missing Data Sometimes - Developers - Tempest Weather System
1 Like
I just pushed an update that adds a check for null values and logs a warning with the field name. I don't do this for rain_accumulation_final or local_day_rain_accumulation_final as they often appear to be null.
Battery voltage is already published as a state variable. Since the driver also supports Sky and Air, I didn't use an attribute as I didn't see a way to handle multiple devices.
To calculate the modes I would need to keep track of the previous ones, so to keep it easy I'm just appending good (>= 2.455) vs low to the battery state variable.
1 Like
While waiting for my Tempest to be delivered, I was looking for HE integration and found your post. Really happy someone already made a driver for it. 
Some basic questions:
- As I understood, your driver uses local network communication by listening to the UDP broadcasts sent by the device, it doesn't need internet at all to work, correct?
- The driver made by @snell provides more info but it pulls data from WeatherFlow cloud?
- Is there a complete list of attributes where I can compare the differences between the drivers?
Thanks a lot to both you and @snell for your work, really appreciated, can't wait to test them.
Both of our drivers use the WeatherFlow cloud, so you will need an internet connection. This driver uses a WebSocket and due to its nature, observations are PUSHED to the driver where as the other driver polls the API at a specified interval. If you want immediate rain and strike events, you'll want to use this driver.
I have a screenshot at the top of the post that lists the attributes this driver publishes. You can look at attribute definitions in the code of the other driver.
Have fun!
1 Like
@alexdelprete:
As @augoisms mentioned my driver is designed to poll on a regular interval from the WeatherFlow API, just like all my other API-based drivers (with an exception for the Ecowitt portion of my AmbientEcowittWeather driver).
As for attributes, I currently have all "known" attributes from the API supported. Obviously if WeatherFlow changes that new ones can be added and such. I try to stay on top of such things but since I do not actually have a WeatherFlow-based device myself I may not catch a new attribute right away. But just bring it up in my driver thread if something is missing and I will try my best to get it in there right away.
2 Likes
So the observations are pushed to the driver through UDP broadcast on the local network, correct? Internet is needed for some kind of authentication? I just want to understand how the communication flows with your driver and the other one.
so the other one polls WF cloud to check for new data and pulls it. There's no communication with the device, it's just HE that retrieves data from WF cloud. Correct?
Thanks a lot, I will make a comparison in order to decide which driver to use.
Ideally, the perfect driver would be a merge of the two: UDP for all attributes possible on that channel, and, if the user needs more attributes (option) the driver can use the API/Cloud to pull the rest.
I try to stick to HE approach of not being dependent on the internet for my home automation. It's a pity WF devices require access to internet in order to retrieve data.
Thanks for the answers.
Thanks, I will check the code of your driver to try to compare the list of attributes of the UDP driver vs yours.
I also read in one of your posts that WF recommends the API approach over the UDP one. But from my perspective, the more the communication is local, the better, at least for home automation.
Thanks for your answers and your work, it is highly appreciated.
This driver does not use UDP. It uses WebSockets, which is communication protocol that is used to connect to the WeatherFlow cloud (like HTTP but always on/connected). It not currently possible to listen to UDP broadcasts on the Hubitat. If/when that functionality becomes available I will definitely look into it! I don't know what post you're referring to, but I don't think that WF recommends one approach over the other.
Both drivers communicate directly with the cloud and not the local device. Both drivers use a similar authentication method. With this driver, data is PUSHED from the cloud to Hubitat over the always on WebSocket connection, and with the other driver data is PULLED from the cloud by issuing HTTP request at a specified interval.
As far as combining the drivers. I specifically made this one because I wanted fewer attributes (hence the 'lite') and wanted to use WebSockets. There is nothing wrong with the other driver, it's just different. I could have just as many attributes in my driver, but I chose not to have them. If you're interested you should check out the WeatherFlow API documentation.
Hopefully this helps.
Now it makes perfectly sense. Thanks a lot for the clarification.
So both drivers collect data from WF cloud, but one uses a polling+pull method and the other establishes a websocket and data gets pushed to the driver by WF cloud.
Question: if HE could read the UDP broadcast data from the device on the local network, there should be no need for internet communication, right? If so, a sort of local proxy could be implemented with which the driver could establish a WebSocket, the proxy could collect all UDP broadcasts from the local device and push it to the driver through the WebSocket.
It was a post wrote by @snell in another thread, he was in contact with WF techs, and it seems they told him to "prefer" API vs the UDP broadcast.
Actually, they have sorta been increasingly discouraging use of the UDP interface as their AI is developed. Some of the UDP data types (lightning for one) really benefit from the WeatherFlow mothership link.
FWIW, you can use the available WeeWX WeatherFlow UDP station driver on a Raspberry Pi, Docker container, or Linux box on your local network, along with the WeeWX driver for Hubitat. I know the guy who wrote the WeeWX WeatherFlow UDP driver, 
but sadly am feeding my HE from WeeWX using my Davis VP2 so I don't know if/how the solar radiation, rain start, or lightning strike events are sent to HE.....
2 Likes
Are you referring to this driver? [RELEASE] WeeWX (weather station) to Hubitat driver
Thanks to the guy that developed the UDP driver. 
1 Like
I agree based on my exchange with the WeatherFlow guys the UDP stream is the raw data before the Machine Learning processes are added. UDP would be great for local data but then you remove the processing power of their cloud for enhancing your stations observations.
At work we have been moving away from poling for web service data and have moved to websockets and kafaka queues/topics which has made writing apps much easier and reduced overhead at the application layer but does require a good chuck on infrastructure to make it work.
1 Like
Just to clarify, the reason no one is doing this is because Hubitat doesn't support it. There is no way for the hub to process UDP broadcasts.
I am sure a big part of this is because they want our data. The fact that their default is to report all our data publicly makes me think they see the value in having a huge network of PWS data...
1 Like
Yes, that's the one to feed HE from WeeWX.
On a side note, you can probably also use the HE MQTT driver and have WeeWX feed a local mosquitto instance with live updates. I'm using MQTT/mosquitto for real-time updates in the WeeWX Belchertown skin on a wall-mounted tablet.....
I believe that their true reason to discourage UDP is because they have realized that the local raw sensor output needs their smart weather station AI back-end processing to correct anomalies and incorrect measurements.
On the topic of the value of PWS data, they rocked the PWS world by publishing an actual value ($15/year) on the price of a PWS' station data in the Tempest's Kickstarter campaign:
I have no idea if this only applies to Kickstarter backers, or if it also applies to subsequent Indiegogo backers and retail purchasers.....
To answer the question about UDP from the Hubitat side, Hubitat does not support just getting unrequested data EXCEPT for HTTP on port 39501. It cannot just monitor UDP for unsolicited information. It can perform a request over UDP and expect an answer to that request, but WeatherFlow's equipment does not support that. I asked and it is not going to happen.
So... your options are:
- Monitor UDP which Hubitat cannot do but a RasPi using WeeWX can, and lots of people seem to use WeeWX to receive their PWS data.
- Check the WeatherFlow API either by Websocket or polling, which the above-mentioned drivers can provide for you.
2 Likes
