Thanks for this driver. I got my TEMPEST siting done yesterday and now setting up the integration in the Hubitat.
I know that the dev's at Hubitat has stated that listening for UDP is not available but would make it more of a event / real-time integration. But polling I guess is the next best thing. The bad thing is that the Weatherflow API requires an active internet connection which prevents a offline mode and that is where their UDP interface comes into play.
I confirmed with WeatherFlow that they will not work with a query/response method, nor do they plan to implement it (they already have the UDP broadcast and API after all).
It would be better to keep it all local of course, but until that is possible...
Hi I saw your posts on the WeatherFlow boards, there a few developers looking for a simple "GET" request from their hardware for local and some MQTT requests also.
I was able to test the lux readings yesterday with all the dark clouds and storms coming though and I was able to calibrate my indoor luminance against what the station was reporting. When the second line of storms came I had already updated my room schedules to turn on lights account for stations Lux readings and it worked. Without this driver I would have spend weeks doing this.
Glad it helped you out.
Early on I specifically reached out to WeatherFlow about the GET request. Talked with their people via a couple emails back and forth (it was more than just that I was asking about) but the request/response at the time was a definite "no". But... it is all software so who knows someday that may change. Maybe some reseller will say "we want to sell X thousands of your units but we REALLY do not want it sending UDP all the time... can you..." and it will change.
If it does, hopefully I will be around to update the driver. 
On the subject of inflatables, I found using a 30lbs fishing line and some stakes work really well. I use them instead of the black cords so it looks like the things are really standing up on their own. Plus I can get a few more angles to prevent any kind of flopping around. We get gusts north of 60mph and, surprisingly, I haven't had to collect the bits and pieces across the neighborhood after a really good set of winds.
I used to have some super heavy-duty fishing line around that I used for Halloween props (for example, the ghost that is my icon) but ran out. I would be hesitant to put it for the inflatables as I already trip over the tethers enough now as is 
.
But it certainly would be stronger.
This is another example of why you can't rely on just one hub or brain for your home automation.
Using Node Red getting that UDP data stream is trivial as is splitting the info up for use elsewhere. Only things currently missing that i have noticed from the UDP stream is the lightning strike data, and the firmware update for that is supposed to be getting pushed out any day now.
Granted the crowd sourced correction data will be unavailable if you use these offline, which also means your system won't be getting re-calibrated as needed based on that crowd data (which weatherflow says is critical to these units remaining accurate)
Just received and mounted mine, used a 3 ft pvc pipe and a flagpole mount on the highest point of our eaves. For a total of about 13ft off the ground. I have Netatmo rain and wind sensors on the roof already and a Netatmo outdoor sensor in the shade on the other side of the house at about 7’ off the ground, will be interesting to compare them. My tesla model 3 also has a temp sensor that I monitor as well, but it’s in the sun and on concrete so it always runs hotter temps than anything else.
Looks great!! Congrats
@snell when you said their would be child devices, I assumed they would be for each sensor type "Lux" "Moisture" "Wind Speed" etc. but what I have is two sensors
One shows info about the device itself (geoloc, IDs, etc. ) the other seems to just be a duplicate of the parent device.
I don't NEED child devices for each sensor type, just curious what the thought process for doing it the way you did is.
Those are the only devices their API reports. The Tempest and it's base station. There is no breakdown below that in their data unless I split them up into groupings myself (which might never match what people want) OR I split them up per every data type reported back... so you would have... about 30+ child devices?
They combined a bunch of sensor types into each device. So no real thought process on my end, I just matched the API. Similar to how I do with my other API-based drivers, try to keep it as close to how the API reports it as possible.
I've got a recommended change for you. Out here in Western US, 2 decimal places of precision for Inches of rain basically rounds all our rain down to 0 (at least for short term values). This makes detecting when it's raining impossible. As a point of reference, we got 0.00235 inches of rain yesterday, which is just enough to ruin the wood floors but not enough to water the garden. I modified your ConvertInches function to use 2 digits precision for Inches -> mm, but upped it to 5 digits for mm -> Inches. I started down the path of making the precision variable so it could be tweaked by use case, but ended up ditching that when I realized this function is only ever used for precip values.
Do you have this in Github or somewhere that I could fork? I've got a few other tweaks in mind that would be easier to manage that way than in pasting code snippets.
// Converts measurements between inches and mm
def ConvertInches( String BaseScale, Number Value ){
if( Value != null ){
def ReturnValue = Value as double
if( BaseScale == "Metric" && MeasurementStandard == "Imperial" ){
ReturnValue = ( Value / 25.4 )
def TempInt = ( ReturnValue * 100000 ) as int
ReturnValue = ( TempInt / 100000 )
} else if( BaseScale.toUpperCase() == "Imperial" && MeasurementStandard == "Metric" ) {
ReturnValue = ( Value * 25.4 )
def TempInt = ( ReturnValue * 100 ) as int
ReturnValue = ( TempInt / 100 )
}
return ReturnValue
}
}I can make changes for such things in the driver. I doubt most people would be upset with it being more accurate, especially if they are using it for rules where it is a simple number comparison (if > 0.1).
Unfortunately I host all my drivers on my own website, not GitHub. I am happy to take feedback and try to incorporate improvements though. Plus, people can always make changes to their own or make a derivative version.
Just so you know this is still on my list to do. I hope to have a revised driver this weekend as it looks like I will actually have time to work on such things this weekend and not have all my time digging up the yard or repairing our shed.
UPDATE:
Version 0.3.3 is now posted.
Updated Version(s):
Change(s):
Not at this time. It would mean a lot more maintenance on my part to keep that up to date, and none of my drivers (I have 12 or so published and more unpublished) have any apps (and most do not have children). So they are pretty easy to just run an import on. Plus every single one checks if there are any updates for them and puts a notice in the driver.
Just not sure how much easier it really would make it for people. Plus I am kind of hoping that Hubitat just picks it up and adds the capability in.
Updated Version(s):
Change(s):
I really like this driver, Any plans to update the driver to also pull weather forecast using the Tempest API "Get Forecast" My goal is to be able to have a HE display the same current and forecast information as the Tempest App.
Now that I know of it (I do not have any WeatherFlow devices so I am not kept awares of what they make available). Quick look shows it should not be too bad so you should be able to expect it in the next couple days.
Thanks for letting me know!
Download the Hubitat app
