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, 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.
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.....
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.
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...
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:
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.
Yes, that is now finally clear. And thanks also to you for the clarification.
For what is worth, as a user, I chose HE for cloud independence whenever possible, so I really prefer local UDP communication, and in this moment the only way is through WeeWX WeatherFlow UDP Driver and WeeWX Driver for HE. But I'll keep an eye on your driver for further developments, until WF decides to drop UDP broadcast support.
Thanks again to all of you for these posts, I'm learning a lot from this community, and it's one of the main reasons I chose HE.
If there's a direct driver that can feed WeeWX data to HE, I don't see the benefit of doing it via MQTT. I have Mosquitto running on my Synology, where I have a Debian 10 docker container that I use to run things like WeeWX, your driver and small utilities/proxies for other automation stuff.
I'm really new to WeeWX, so before installing everything I need to go a litte more in depth. But I have time, my Tempest has not yet been shipped.
Thanks for your work on the UDP driver, without it I would've had no other choice than rely on cloud communication, which I always try to avoid whenever possible.
Has anyone come up with a better template (vs. the default weather template) that displays more of the key attributes in one tile? I haven't yet found out how to create a custom template but figured others have already solved this issue for Weatherflow.
Bummer. I hate to have to use a 3rd party utility for something that should be part of the basic functionality. I was hoping I just missed something. Thanks
@rlithgow1 The temperature value is suppose to be a number, but there is unit parameter. It's up to the tile to display that. I don't use the built in dashboard, so unfortunately I can't provide any guidance on that.
Was my fault. I was using the attribute instead of the template. The only other thing I'm getting is excessive events alerts from the lightning strike portion.
What attribute should I use for a rule to detect the onset of rain? PrecipitationType? Will that change from “none” to something else upon precipitation? And then change back to “none” if it stops raining later that day?
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.....
