Hi @snell
According to my Station device, it is at v0.8.14 after updating from HPM, is that correct?
Also, is the Sensor ID for Parent data the same as the child's device_id?
The DriverVersion entry only has 2 ways to change. If you Save Preferences for the device OR once a day when it checks for any updates to the driver. So if you updated with HPM it should be fine and you will likely see the version change tomorrow. Plus, there was nothing major that changed in the WeatherSensorChild that the main driver depends on.
As for the Sensor's ID, there are 3 places you can find it on a child device:
- In the child Device Name.
- In the child DNI.
- In the State Variables labeled device_id.
The parent device also has a list in it's State Variables as "SensorIDs". One of those is the hub (since the API reports it as a sensor) and any other(s) is/are sensor(s).
@snell I noticed the current air temperature and heat index on my Tempest WeatherFlow app quit refreshing, even though other variables were successfully updating. Upon updating to the current version 0.4.12, I no longer see the current air temperature nor the current heat index. The only temperatures I see are the forecasted high and low for today and tomorrow. How do I get the current temperature(s)? I use these to set my thermostat mode and setpoints.
As a test, I created a new device using the updated driver. Here's what I'm seeing. Air Temperature and Heat Index are missing from the top of the list of state values.
Do you have anything set in the "Sensor ID for Parent data" Preference? That can be left blank if you have only one sensor. If you have more than one sensor you should set it whichever sensor you want the data from ( for the parent device, it does not impact data sent to child devices).
If you have more than one sensor and it is blank, the values would be overwritten by each other.
If it has a wrong ID (whether you have one sensor or more) it would not match and you would not get any value displayed (which sounds like this scenario).
I only have one sensor, so I've never set the Sensor ID for Parent Data. Looking at the original device (I deleted the test device to ensure no overlapping issues), I see the Air Density, Air Temperature, and Heat Index state values. However, all three of them quit refreshing as of 6/2/2024, whereas all of the other state values are continuing to refresh.
So I dug into the public data my station is generating and noticed the air temperature quit generating values as of 6/2/2024. The station status also shows the temperature sensor as failing.
However, the Google app home page shows a temperature and feels like value that seems about right given current conditions. Is it using other station(s) data when my station isn't generating refreshed values? Either way, that appears to be the culprit, but is being masked due to app behavior I don't understand. I guess I'll contact Tempest support to see if I can get a replacement. 
From the limited knowledge I have of the Tempest system; if your Tempest is using its data as public for a weather station page (as an example) and for some reason the station goes off line, then data from forecast models will be used for that purpose. Ask WeatherFlow support for more info. Try turning the power switch off/on on the Tempest device itself first to see if it comes back to life. I just had a similar situation, but alas, the unit failed. My 2 cents.....
1 Like
If the sensor had an error and does not provide all the data (my oldest stopped providing wind data) the driver would not have anything to refresh the old with. If I went and nulled out EVERY attribute and state variable each refresh so such things would become obvious, it would massively increase the events (on an already event-heavy device depending on your refresh rate).
However... as I think about it I might be able to monitor if certain fields are coming back null, but you already have data there... in which case raise a status for the user to check their device. I am surprised the WeatherFlow people do not have that built into their app. My device was malfunctioning for some time and nothing warned about it anywhere. As soon as a support person checked the data they were "oh yeah, X module appears to have failed, let's get you a replacement..." They dealt with it right away but a bit more proactive warning in the app AND API would be nice.
1 Like
Updated Version(s):
- WeatherFlow.groovy = 0.4.13
Change(s):
- Correction to Parent device's SensorID checks that were being performed, the ID was being treated as the wrong variable type and was not passing the if statements properly. This may account for part of what @cdallum was seeing (although it still would not help with the null data yet). Not sure why ANY of them showed up at first and why my initial tests worked...
- Correction for humidity value not being copied to parent properly if it was using an "air" sensor type (and older type, not the current Tempest sensor).
1 Like
I installed the WeatherFlow driver using Hubitat Package Manager for a new Tempest device and I have been getting system alerts that "Some devices are generating excessive events."
Every data refresh the error log shows 41 duplicates of the following message:
[error]WeatherFlow - Failure to add child because child name was null
HPM shows that I am currently using WeatherFlow v0.4.13 (driver) and WeatherSensorChild v0.8.15 (driver).
I entered the values for "Token for WeatherFlow" and "Station ID to be checked", set the "Data Refresh Rate" to "1 minute" and turned on "Enable Child Devices?" when I configured the device.
In the device list under WeatherFlow I have a "Hub" WeatherSensorChild and a "Station" WeatherSensorChild listed.
The "Current States" and "State Variables" attributes on the device page are updating correctly.
How can I fix this issue?
If you disable the child devices it should not try anymore... But I do not know what is causing it. Something I will have to look at Sunday (I am away from home right now).
I did not think I did anything that would alter child naming but I must have made a typo somewhere that did not show up in my testing.... Sorry.
Thank you.
My initial install with HPM was using the previous driver (that was current at the time). I didn't notice the alerts until a few hours later and when I checked for updates again in HPM it installed the newer version. Whatever the issue is it was also happening with the previous version.
Ok. I do not feel QUITE as bad then. Can you capture a Trace log of the refresh response and send it to me as a message? There must be something that looks like a sensor to the driver, but does not have an ID to generate the name.
The way the driver works each time it gets data that should go for a child it attempts to generate the child. The errors happen each time it tries to send a single value over.
The excessive events overall would not be impacted by that (errors do not count towards events). This driver CAN generate a lot of events because there are a lot of data the API sends back.
Besides disabling the child devices at first, you could also set your refresh interval to 5 minutes or up the warning limit for events on the device.
Updated Version(s):
- WeatherFlow.groovy = 0.4.14
Change(s):
- Revised how device ID was being handled when processing data. While I did not spot a distinct problem, hopefully this will help with what @james.allman was hitting with the error about a null name child. No matter what it made some code a bit more consistent.
I just upgraded and reenabled child devices and I do not see the null id errors now.
Thanks!
2 Likes
I am a little confused about the purpose of the main and child devices.
Should I be referencing the WeatherFlow, Hub, or Station devices in my automation rules? I only have one Tempest if that makes a difference.
If I turn off child devices will the Forecast child device still be created?
Meant to message…sorry.
