@james.allman: You can disable the children if you want. The benefit is allowing you to choose if you DO have more than one device. Also, some things (HD+ for example) only create one tile per device. So you can use the WeatherFlow parent for some values and the Station child for others.
@TArman - I think it is a TOUCH off to recommend using someone else's driver in a driver's thread, since it is not like this is defunct...
Would it be possible to emit TimestampEpoch as an event instead of a state? My use case is to control fans/water chilling based on outside temperature, but I need to fallback to time based control if the Tempest station is offline for any reason.
So if "TimestampEpoch" is an event instead of a state, I can use Rule Machine to check the latest update timestamp and set a global liveness variable that allows me to either a) control fans based on temp or b) control based on time ranges as a fallback.
(Note: Rule Machine seems to allow you to see states as device attributes, but always shows a "null" value. When I change the code to emit an event, Rule Machine is properly able to see the latest value.)
Sure, I can switch that over to an attribute/event. Unfortunately, I am away from home/computer for the week so I will not be able to make the change until I get back next week.
Awesome, thanks!!
Updated Version(s):
Change(s):
Mind sharing your rule for fans once you have it completed? Thank you.
why does my tile not show the wind direction properly?
LJ
the state shows:
and the setting shows:
I am not sure why that tile would not show the direction. I do not know who made that tile or what attribute(s) it is using to display the values. Since the WindDirectionString is an attribute I added for my driver it is not entirely surprising they do not support that... but the driver also provides the windDirection attribute which I know other things use just fine (Hubitat's dashboard for one).
So first, check to make sure you have the windDirection in your Current State list. Then ask whoever makes the tile what attribute they are looking at for wind direction and why it is not working?
Snell,, so sorry. I feel embarrassed that I bothered you with this. I was thinking at the time that the tile was part of your Weatherflow driver, but I remembered incorrectly. It is a Hubigraph standard tile that can integrated into weather devices on Hubitat. Sorry to bother you with this.
LJ
No need to feel embarrassed. It is TOTALLY possible for my driver to have an error or provide data in a way something else could have issue with.
BUT, I do not know why Hubigraph would have an issue with windDirection if Hubitat does not. Might be worth asking them specifically which attribute they use for wind direction and (if it does not include any of the ones I do) could they add support.
I did figure this out shortly after my last note to you. Apparently, the Hubigraph tile expects a numeric wind direction in degrees and it converts it to cardinal alpha directions. The strangeness on the screen I posted was due to me trying to feed the wind direction string from your driver. It worked fine when I sent it your numeric data.
Thanks again,
LJ
I have vers 0.4.15 of the driver. My illuminance value is 0 at 4pm in the afternoon. It is not sunny out, but it is also not dark. Is that expected? What is the range of that value? I'd like to use that to gauge cloudiness and turn on some lights if the value is too low, but 0 does not seem to be a valid number in the middle of the day even in a thunderstorm.
No, that does not sound correct. You have the correct driver version for the parent. So... Few questions:
I'm not sure what changed, but I did reboot the hub and disabled my mesh WiFi. It now seems to be giving me umbers for illuminance. It is cloudy out and the current value is: 11290.
I have another issue. I want to determine when the Tempest driver updates its data. I'm trying to use the TimestampDate variable in a piston but it always returns a blank string, even though I can see the data in the State Variables section in the device info. Is there a problem retrieving that data?
That is an error on my part. A new version will be posted momentarily. There should NOT be a TimestampDate. It should have been TimestampString. Since TimestampDate did not exist as an attribute (it does not show up in the Current States list for example) it cannot be used by other code (things outside the driver cannot use State Variables). Another one that was working was TimestampEpoch. But the TimestampString fix should be published in a few minutes.
Updated Version(s):
Change(s):
Yea, TimestampString now works. Thanks Snell for the quick response. The only issue I now found is that the driver version in the Device Detail page still shows as 0.4.15 even though TimestampString works. BTW, TimestampDate also works.
DriverVersion and DriverStatus are only updated once per day as part of the DailyCheck, so it will not change those until then OR if you Save Preferences. There is no way for a driver to "know" it has been updated and I chose not to just spam the driver data as part of ever data return or such. So those will fix themselves.
TimestampDate might be there (since it was mistakenly in the code before) but it will not get updated from now on. The only reference to it in the driver is in the change log for this last change, saying it was being replaced. Variables can stick around for quite some time like this, but it will not change in value.
Download the Hubitat app
