This driver polls the WeatherFlow API for information that your weather station or another has provided. The WeatherFlow API driver is REQUIRED and is the parent device (if both are used), and the WeatherSensorChild is OPTIONAL and is a child device driver. Now available within the Hubitat Package Manager (HPM).
REQUIRED:WeatherFlow API driver to poll the WeatherFlow API.
OPTIONAL:WeatherSensorChild driver is optional overall but required for child devices to work if you want to use the Enable Child Devices preference.
Setup:
Add the driver(s) to your Drivers Code. They can be copy/pasted in or Imported using the links above (which will always be the latest version). Then Save the driver.
"Add Virtual Device" from your device list.
Give it a Device Name then select WeatherFlow from the bottom of the Type dropdown (where user drivers show up).
Select "Save Device".
Enter the API Key you have obtained from WeatherFlow into the "API Key for WeatherFlow" field.
Enter the Station ID you want to be using into the "Station ID to be checked".
Make any other preferences changes you may desire.
Select "Save Preferences".
At this point your device is now ready. Unless you set it otherwise it will start polling the API regularly every 5 minutes (the default).
Other Preferences and what they mean:
Data Refresh Rate = Frequency the driver will poll the WeatherFlow API for information regarding the Station ID. The default value is 5 minutes but it can be set for 1, 5, 15, 30, or Manual refreshes.
Measurement Standard = Determines whether the driver will attempt to populate all units in Metric or Imperial standard. Default value is Metric (most stations report Metric by default, even in typically Imperial areas such as the United States).
Wind Direction Method = While degrees are useful most people think of wind coming from the points on a compass. This allows you to select which method will be represented in the WindDirectionString data. It allows a variety of choices from repeating the degree value (ex: 330°) to full words for all 16 points (ex: North-North-West).
Enable Child Devices = This will enable child devices, creating additional virtual devices using the WeatherSensorChild driver. There will be one created for each device tied to the station in the WeatherFlow data. Children are automatically created when this is enabled and a new device is detected in the data. Children will be deleted if this feature is disabled. The main benefit to this feature is that the children will contain their specific data. For example: an outdoor sensor can provide "temperature" and "humidity" attributes for use in the Dashboard or Rules that the API might otherwise note as "temp1" and "humidity1" or some other representation that would require using custom attributes and make things more complicated. Children are named based on the device ID provided in the data received.
Enable Logging = This sets what level of logging is provided to the Hubitat log from the driver. It defaults to Info, which only provides very basic logging for events. There are also options for None (only Errors would be provided) and Debug (which provides a fairly large amount of log entries and is only recommended when debugging a problem).
Show All Preferences = This sets whether the other Preferences are displayed on the device page. As there are a number of preferences and most will be set once and never changed, this allows a bit of screen area to be recovered by hiding the preferences, if desired. Hiding preferences has no impact on their values.
This could help. Plus it has about siting it and since you do not have yours yet you have some time to figure out what would be best and if you need to do anything to prepare for it.
It really doesn't though... this has been one of my biggest concerns with getting the tempest... They will not tell us where it is best to actually mount it, and how or if they are compensating for the differences in heights on the sensors where a standard system is supposed to have sensors at different heights for accurate/industry standard readings...
Normally your wind sensor is supposed to be about 35 feet in the air while your temp/humidity sensors are supposed to be about 5 feet off the ground. The tempest crew has not addressed this at all, beyond mentioning eventually they will sell add on sensors for the device.
If anyone else has actually come across any info relating to this issue please link me to it as i would really like to know how they are getting accurate readings for everything when not splitting the sensors to proper heights.
After all knowing the temperature 36 feet in the air is of no real use when trying to plan what to wear, and registering rain that evaporates before hitting the ground doesn't give a accurate report.
Granted I am not an expert on weather stations and am going based on what I've read over the last couple weeks about the proper placement of sensors and the reasons why they are placed that way.
I am not going to pretend to be an expert either. I have 2 different weather stations (an old Acurite and my Ambient) mounted on a PVC mast I made (originally intended for Christmas decorations) that puts them about 20ft high. Not going any higher than that and in general they have seemed to work for me.
My original purpose for a weather station was knowing whether it was too windy for my wife's Christmas inflatables. Still is. I have gotten in a hobby of making weather-related drivers for... Beats me why, to help people out I guess.
Well I for one, along with many others, am glad you did
OMG inflatables.... is your wife as obsessed with Christmas decorating as I am?
Tip for those inflatables and high winds... Open the zippers on them and place a few bricks into the feet/base of the inflatable. Keeps them from blowing away and will let her enjoy them even in 60+mph winds
We have... let's see... I need to check my website for last year's stats:
15 Inflatables ranging from 3' to 8' tall
20K+ LEDs on strings (icicle and normal)
Multiple other decorations
Yeah, I keep bricks in a couple of the larger ones and I have made my own tether system as well as reinforced the tethers, changed out incandescent bulbs for LED, etc... I have also started putting ZigBee on/off switches directly in them. The safest bet is to still have them deflate when it gets too windy in my experience.
Ok i have you beat on the inflatables... i have over 40 of them ranging from 3' to 12' tall... but you have me beat on lights, i only have about 15k of those, though this year i'll begin to transition sections of my displays from normal string leds to addressable leds... Its about time for a real light show
Thats not a bad idea. I have mine running of a handful of outdoor remote and timer controlled outlets. Granted I just got into automation this year so I imagine my lighting displays will rapidly get upgrades.. I'm already thinking about having them motion triggered so the lights only come on when there is someone to see them, the inflatables of course inflate way to slowly for motion triggering to be an option.
Lol. And I don't even put up Christmas lights. I make my wife put them up if she wants them up. I could care less.
Of course on the flip side, I like the floors cleaned more often than she does. Since it's important to me, and not her, I do it...
That's in general how it works in my house. For things we both care about, we share the load. For things only one of us cares about, that person get stuck doing it.
Ha! Neither of us like having to vacuum... so we have 2 Eufy Robovacs (one for each major floor, none for upstairs) that are controlled by the Hubitat so they clean twice a day.
I have been building up the lights over the last 10 years or so... I try to buy at least 1k each year on clearance, some years it is more, and sometimes there are gifts. No real display to it, it is all mostly on/off. You can check out my website sometime for some lousy pictures and slightly more detail. At the very least the neighbors all agree they like it so I am not annoying anyone.
I just started with the built-in ZigBee last year. Most of the rest are controlled by outdoor Z-Wave outlets and a LOT of extension cords...
Firstly, instructions are great. Easy to follow. Couldn't remember how to find the Station ID, but a quick google sorted that out.
Secondly, data is flowing through. Now I have to go and write some rules. Thank you.
Question - is there a way that info can be pushed on certain events vs polled/Refreshed? Currently I have a rule where if the music is playing in the pool, and lighting is detected, play a warning message. Ideally, under a new rule, this message would have the lightning distance included, and the message would vary dependant on how close the lightning is. This is obviously all dependant on each lightning detection.
Unfortunately there is no way to receive "pushed" data at this time. WeatherFlow devices DO send data out on the local network, but as UDP broadcasts. Hubitat works on a query/response method for everything but HTTP on port 39501. So the station is sending out those UDP broadcasts saying stuff like lightning and other changes that happened right then, but there is no way for Hubitat to monitor them directly.
Some people have made workarounds using NodeRed from what I think I saw, where they have a RasberryPi or other device watching for these types of broadcasts and then they push them to the Hubitat on the HTTP monitoring port so that a driver can see them.
Yes, to do something like real-time lightning notifications you would need to use a 3rd party app like node-red, and have it listen for the updates from weatherflow and write the update back to Hubitat.
Pretty simple to so, but it does take a other device running node-red to do it.
Enjoy the rabbit hole.... Beware once you see how much more stable/responsive NR is you may end up mainly using your hub as a device controller moving the logic over to NR
Version 0.3.1 is now posted, this requires WeatherSensorChild 0.6 or higher if you are using child devices.
Major changes include:
Rework of state/event processing and posting (thus the child change).
Update to logging methods to include Trace level logging (beyond Debug), which I had not even known existed.
Update to version control to be more in line with semver.
Still looking to do a major rework of how data is handled to make it much easier (like with the AmbientEcowittWeather driver) but the WeatherFlow data is proving a bit tougher. It works just fine now, as is, so I will not mess with that until I have a better method working entirely.
For those that want to try out a new feature with their child sensors, @anon81541053 has come up with a method of creating an HTML-based attribute (named "html") in the child, that can then be selected and displayed as a normal attribute in your dashboards.
The new version of the WeatherSensorChild.groovy file, 0.7.0, includes this new capability. Within the preferences for the CHILD device you can configure the HTML to include whichever attributes. For example: <p>Temperature: ${ temperature }°${ location.getTemperatureScale() }</p><p>Humidity: ${ humidity }%</p>
On my dashboard, for this child, that attribute shows up as:
This is an initial test of how this works and if people find it useful, so feedback is appreciated. I have included the steps to use it in the driver itself.
