Is there information about the difference between "Current States" and "State Variables"? I initially thought they were duplicate lists, but I just noticed that some of the values were different (wind gust, wind direction, etc.) were different.
So this is the general bit:
- Current States are what most people think of as Events. They are able to be used by other areas (such as Rules), and have an underlying attribute built into the driver (via capabilities or specifically defined). They are published using the SendEvent command.
- State Variables are data that are only available within the driver (and back and forth between parent and children). They cannot be used by Rules and do not need to have attributes. They are not published but rather just set as a state.xyz value.
For my drivers:
- Almost all Current States will have a matching State Variable. I put both so I can test if the value has changed (against the state variable) to decide if I should push an event BEFORE pushing the event.
- There are additional State Variables that will exist when they are used for "internal" purposes in the driver but do not need to be pushed as an event. Things like cookies or authentication tokens for example.
- There may be things that are similar looking "windgust" and "Wind Gust". In cases like they are actually separate values. "windgust" is returned by the API (or local data) and has some specific format or measurement (for example, mph). But that is not meaningful to all users because some may want km/h. So the "Wind Gust" attribute exists to provide them with a converted value, while the "windgust" is still around so it can be the raw data (just in case someone wants to see that).
1 Like
Hey @snell . Love your work. Thanks so much for doing this. I have found a bug (or maybe I don't understand the way these variables -- or hubitat -- work). Not complaining, just helping out.
See the triggers I have set up for a task I want to run. The bottom two triggers run every time the device updates. Not sure why. You can see that the values are such that the event should not trigger the rule, but it does.
Look pretty straightforward to me, no idea why they would trigger your Rule. Maybe @bravenel would have an idea?
Which version of firmware is your Hubitat and what Rule Machine version?
I am on 2.3.2.135 and RM5.1
The only thing I could think of was whether there was something weird about the device update process that changes those values for a microsecond to something that would trigger the rule. Like, if "dewpoint" flashes to 0 during the update process, before it posts the actual number, that might trigger the rule. But then that would not explain why the "feelsLike" event gets triggered. Unless it flashed to something above 100.
@snell , another question... I tried switching from "feelsLike" to "HeatIndex", but that is showing up as "null" in my variable value, but I see that it has a value on the State Variables list.
I have created a new rule with those triggers and a dummy action. It is working properly, so there must be a bug in the rule somewhere. Going to try to copy all the actions over to the new rule.
ETA: Just found out you cannot copy and paste from one rule to another. Looks like I have to rebuild the rule from the ground up.
I've been trying to use my lightning sensor to trigger various things - and no matter what I seem to do, the lightning_hour/lightning_day counts don't seem to want to do anything when I try and expose them to a rule.
In the device, they show up correctly:
- lightning_day : 77
but when I try and use them as a custom attribute in a rule, I get a null value.
Am I doing this wrong?
You could try cloning the rule.
As for HeatIndex, that is only calculated if the overall temperature is over 80 degrees. If it is not in the Current States list, you will not be able to use it (because there is not a current event for it) and it will be listed as null. The State Variables list are not values that can be used by Rules or such. But it could still have a value because it has been sitting around since the last time it was calculated.
That is likely a bug... I should clear it when it is no longer being calculated. Maybe sometime over the week I will get that cleaned up.
Thanks. Tried that, but the error came with the clone too.
After recreating all the variables/actions/triggers on the new rule, the error started again. So I wonder if there is something going on with my actions that is triggering the rule? But not sure why that isn't showing up in the logs? I'll go through each action one by one and see what I find.
It was showing "Null" while the temp was over 80.
Hmm... So looks like a bug regarding HeatIndex... I will look into that. Sorry.
Hopefully the Rule oddity gets figured out. Your logs showed what it was triggering on, so I have no idea why they would trigger on values that clearly were not in the range to trigger.
I'm not sure if I need to create a separate post for my troubles. I did some more troubleshooting and it keeps getting weirder.
So after I created the "test" rule and it set there without triggering for hours, I copied the actions/variables from the old rule to the test rule and the errors started again. Then I went and disabled every action except for a notification action to notify me if the rule was triggered. Every 5 minutes, the rule triggered.
So then I created a 2nd "test" rule that had the same triggers, but no actions/variables, just a notify action to let me know if the rule runs. That rule does not trigger, even though the triggers for both test rules are identical.
I updated to the latest firmware this morning but it still continues.
I guess at this point I add actions/variables one at a time to the 2nd test rule to see what causes it to trigger?
I'd leave Rule Machine out of this for a second in case this is a platform-level event issue. Take a look at the events themselves on your AmbientWeather device. Go to the device detail page, then click/tap the "Events" button at the top to see the history (the info/descriptionText entries in Logs should also show this information, but Events is definitive). Do you see unexpected entries here that correspond to the times when the rule triggered? If so, the device/driver is considering these state changes and generating an event, even if the value is the same as it was before. This seems unlikely to me, but it's worth looking into. (If it is, this could be addressed in the driver.)
...but if it's not, then you're likely not dealing with an issue related to this device. 
It could be a Rule thing, possibly something related to custom-attribute triggers, possibly only with certain data types. If your original rule wasn't Rule 5.1 (or you've never gone in and hit "Done" in the old one if it is), perhaps there were some changes/fixes since you created yours, and that might explain the difference. I can't recall anything specific to something that sounds like this problem, but maybe.
1 Like
Thanks for the response! I checked out the events page for the device and don't see anything out of the ordinary. (On a related note, @snell, I see that HeatIndex is properly showing up on this event page, and is properly showing up in the States Variables list, but not the Current States list.
Just to doublecheck, I have posted the Events page below, along with the rule that is getting triggered (which also shows the "null" value for HeatIndex, and the log. So, if I am looking at this properly, it does not seem to be a device issue? So what do I do now? Should I create a separate post somewhere so we don't junk up this thread with this issue?
If you can reproduce it with a new rule, it may be worth asking. If you can't, then...a since-fixed bug, maybe?
Yes, I can reproduce it with a new rule. But then I have another rule (with different actions) where it does not reproduce. Very strange. I will take this to another topic. Is there a forum just for bug reporting or just ask the question in "Rule Machine"?
I'd just ask in Rule Machine, but I wouldn't be overly concerned with where you post. It's easy to "move"/re-categorize something after you post, and Discourse (the forum software) makes it easy to see posts in pretty much any category, so lots of people read things from all over, even if that's not where they started. 
1 Like
I currently have it set up as a cloud API, but would like to switch to the local version. Can I simply change the preferences in the device settings (and then setup the forwarding info on awnet)? Or do I need to remove and restart?
From the driver side there are two steps:
- Change the Weather Method preference to be Ambient Local then Save Preferences
- Change the DNI (Device Network Id) to match the Ambient's MAC address (without any : between the segments) then Save Device
From there it should start receiving the data as soon as the Ambient starts sending it.
Thanks. I had a little trouble getting it to work but then I wondered if the MAC address was case sensitive. After fixing that, it works fine. Thanks! (again)
