@snell wow that would be great if you can make the forecast data that is published on Tempest site for my station Tempest available in Hubitat. Then I can create rules such as delay running sprinkers if forecast for tomorrow is > 50% chance of rain or if Wind is forecasted tomorrow to be > 15 MPH between 3 a.m. and 6 a.m. in addition to having an HE dashboard that looks very similar to Tempest station homepage. BTW it looks like Tempest is planning native local integration with Smartthings Tempest Integrations - WeatherFlow so maybe down the road they will add native HE local integration
1 Like
I was able to build in what SHOULD have worked for the Forecast last night (based on their example)... but have no way of testing it as it does not work for the old station ID they provided me. Looking into things I have found they substantially changed the API (does not even use an API Key but moved to Token/Oauth) but left the old one "working" so existing stuff does not appear to be impacted (like my driver). However, the new samples do not work for me and their instructions fail as well (they have required steps that do not exist in my account for example).
So... I am waiting on a couple responses from their support. I would really like to provide the "latest greatest" but until I can prove it works at least initially I am hesitant to publish it. Plus it looks like I will have to do a rework of much of the underlying login/authentication code (not sure if the Forecast is dependent on that, and thus part of the problem). But when I cannot even get their sample webpage to reply properly when following their steps... there are things outside my control that are not working. 
1 Like
Have had some talks with their support people and hopefully by next weekend I should be able to publish something... Also, they said there is no need to switch the login/authentication, that they are going to leave the current stuff working for the foreseeable future they just wanted new options going forward to focus people on.
So I will probably switch that at some point but it is not as much of an immediate need as getting their forecast built in.
2 Likes
Updated Version(s):
- WeatherFlow.groovy = 0.4.0
- WeatherSensorChild.groovy = 0.8.2
Change(s):
- To get it out of the way, the child driver was updated to handle added attributes.
- WeatherFlow API authorization has been updated to use their new Token method instead of the old API Key. If you do not have a token, the driver will no longer work if you update to the new version. You can create a token easily, go into your Tempestwx.com account, under Settings... then under Data Authorizations.
- Child devices have been reworked to better identify them and get rid of some erroneous ones that could be generated. If you have child devices now those will not go away but they will not be updated. The easiest way is to disable Child Devices in Preferences, Save Preferences (which will remove existing child devices) then re-enable and Save again.
- Forecasts are now possible. It is set to poll the Forecast every day (~midnight, this will be scheduled after you Save Preferences) OR you can manually poll them. It will bring in the forecast for that day and the next day. If you are using child devices it will generate a Forecast child as well.
- Removed the 1 minute refresh rate to minimize punishing WeatherFlow's servers and added an Hourly option.
- Added a GetStationList command. This will create a State Variable "StationList" that will be a list of all the stations your account (Token) has. This can be useful if you do not know your station ID (put a bogus one in the Preferencs, Save, run the GetStationList to get the real one, etc...). I debated about making it automatically run this after you enter the Token and then using that to poll... but thought it might be trouble if anyone has more than one. Still debating about doing it and turning the existing station field into an "override".
- Improved the battery reporting for sensors. Found that WeatherFlow has a list of the expected voltage levels for Tempest (none specified for Sky or Air, so I used the same values for now). So now they will have a battery % value that Hubitat prefers instead of just the voltage (which is still around, just relabeled).
- General cleanup and fixes of some of the code.
2 Likes
When clicking Refresh:
This looks odd as well:
Request:
Can you add a 1 minute update interval? I currently have my own integration to my Tempest in webcore, and use it primarialy for detecting lightning in case anyone is in the pool. 5 minutes is too long an interval.
I also use it to detect when it starts raining, in case one of us (usually my wife 
) leaves the car windows open.
Ha! I removed the 1 minute because I thought nobody used it and it would be a bit excessive on the WeatherFlow servers... Guess I will add it back in (that is easy).
The scheduled job info is correct. It is now all using the cron-based schedule capability rather than "RunEvery". I did this so that it based it on when people Save Preferences. This way it spreads out the "hits" on WeatherFlow (and my site) a bit throughout the day/time periods selected. It looks funny, but that is the way cron is set. You can see that the Next Run Time is 5 minutes more than the Prev Run Time (for the refresh) and it keeps the seconds you saved it at.
As for the label error... Darnit... I am guessing it is trying to set a label on a child device that does not exist yet although I am not sure why that is the case. I will add some more checks into that section when I add the 1 minute back in. Should see something when I get my lunch break.
EDIT:
Updated Version(s):
- WeatherFlow.groovy = 0.4.1
Change(s):
- Added 1 minute refresh rate back into the driver.
- Added checks around device labels. It was not checking if the Child were even enabled, let alone if the Child existed yet.
I've been doing this since shortly after I got my Tempest last summer, and the calls always have worked so apparently they're not doing any rate limiting, or they don't consider polling every minute excessive.
Agree it would be excessive under normal circumstances, but thunderstorms can appear very quickly down here in S. Florida, especially in the summer, so I wouldn't want to wait every 5 minutes before issuing a warning. Thanks for adding it back in!
Would be nice if we didn't have to hit the cloud to get this info. My HE hub and the Tempest hub are inches away from each other, but they can't talk. Sigh...
I know, I meant talk directly to each other. Despite my attempts to keep my HA system simple, it seems to keep growing in complexity. I think my desire for a single-hub system is an excercise in futility.
@anon81541053 already wrote a driver/system for the UDP broadcasts, but like he said you need the additional system/hardware at this time to listen for the UDP to begin with.
I have talked to WeatherFlow about a local poll method and it is not something they are really interested in doing so I would not count on it. They feel the UDP broadcast is good enough (and I am inclined to agree on their behalf). Of course the UDP does not have Forecast data because they provide that as a "predicted" thing from their compiled data. The station itself does not know it of course.
I've already got an RPi 3 and 4 sitting on my desk for a totally unrelated project I'm trying to find time to work on.
I have node-red running in Docker on my NAS, which has tons of spare computing power; I could set up a UDP listener as well, but there's only so many hours in day and getting rid of the cloud connection to weatherflow isn't going to make a whole lot of difference. Still need the cloud in order to play announcements on my Echos (until someone figures out a local interface).
Sometimes it feels like my ha system is a house of cards.
1 Like
Thanks for your work in putting this driver together. I just installed the hardware and your driver today and had a question about lightning strike distance. I have only had one instance and the data from the API showed the distance at 31 and the Tempest app showed it at 18-21. The time frame looks to be the same on both and I have only had one instance of a lightning strike.
Any ideas why the discrepancy?
I think the API returns distance in KM, so maybe that is what you are seeing?
https://weatherflow.github.io/Tempest/api/ws.html
1 Like
It does appear to be returned in km (31km would work out to about 19 miles) which would be consistent with the websocket description. However, the API has different formatting and my driver is only using the API at this time.
The API has a units section within the response that indicates what it is sending back in what units.
"station_units": {
"units_temp": "f",
"units_wind": "mph",
"units_precip": "in",
"units_pressure": "mb",
"units_distance": "mi",
"units_direction": "cardinal",
"units_other": "imperial"
},
I do not normally display the units information but if you want to check what yours is you can set the device for Trace logging, open a log window, and perform a Refresh at the device. The log window will have all the raw data and you can find the units_distance.
The driver itself performs no calculation on this specific field and does not attempt to convert it. In fact I do not even have it passing the units along, just the number provided. I can start looking into doing that if things like this start acting weird.
Thanks to you both. I'll perform the check tonight and let you know. I was building a rule to alert based on a minimum distance and I guess I could just use a KM number that would represent the distance I was looking for.
What is funny on mine is that my app does not show a distance... Maybe that is because we have not had any recently, but it does report it in the API.
I could convert km to miles. The problem is knowing if I should or not. I have the preference so I know what people want... So I could just compare that to the units reported I guess. I already do that for temperature and some readings. Just need to do it for these. Maybe I can get it done tonight.
Updated Version(s):
- WeatherFlow.groovy = 0.4.2
Change(s):
- Lightning strike distance is now converted from km to miles (if needed). Despite the unit distance being "mi" (representing miles) for some data the actual value returned was in km. So now I am just always converting it (from km to miles if needed) regardless of what the station returns for it's units_distance field.
2 Likes
I may be wrong, but I think the API is always returning all data in metric. The details of the REST API for Get Observations (stationID) (is that what you are using?) say:
The station_units values represent the units of the Station's owner, not the units of the observation values in the API response.
The previous Get Observations (deviceID) describes the measures and it looks like they are all in metric. (Tempest API)
Thank you.
Yes, that is true. I already had the driver handling the conversions needed for just about everything but never did the lightning distance for some reason. Oversight on my part I guess.
2 Likes
