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?
@rlithgow1 There isn’t much logic to the strike events. I’m just publishing them as the come, so I would guess that Weatherflow is sending them down the pipe. It will report lightning from quite far away.
@JustinL Yes, I would use precipitationType . It will return to none after it stops raining.
Maybe a switch in the driver to turn off the strike events recording would be possible? BTW if I haven't said, thanx for doing the driver in the first place!!!
I have been doing 3 years of lightening strike data directly from my Tempest and comparing from the WeatherFlow API and there is a major difference. Based on the documentation on the site it seems that they are aggregating strike data from other stations to give more accurate readings. I guess it all depends on what sources and distance from the monitored station in addition to the local station's ligtening sensor.
I have removed strike data from my WeeWx site due to the need for the cloud to provide the reporting accuracy.
So there definitely seems like a lot of aggregation going on. For my own purposes I don't think I need strike data or rather I don't need strikesdetected for hubitat... (Well not unless I set something like if strike distance >3 then flash childrens' bedroom lights and speak echo speaks "spooooooooooky" just to mess with the kids lol)
I get Strike_Count and Strike_Distance when I read in the raw UDP feed from the Tempest. As stated these values are directly from my Tempest not the aggregated values from their API. Looks like Strike_Count isn't accounted for.
I suppose if there are thunderstorms there could be a lot of events. After a quick search of the weatherflow forums I found one person showing 6k strike events in a 3 hour period.
For the time being you can comment out (or remove) the following lines to disable strike event reporting.
