Hey all, I have a weird issue that I can't figure out. Not sure if this is a problem with how I have created the rule or whether it is a bug in Hubitat. The background of this error was documented on another thread (starting at comment #662). It was determined that the error doesn't seem to be on the part of the driver, so they decided I start a new thread. (That's a great driver by the way...major thanks to @snell )
Here is the issue: I have created a rule that polls a device (Ambient Weather) and gathers some info from the device, then stores that info and takes certain actions based on that info. All the actions work as they should. The problem comes with the triggers. The rule has 4 triggers, two of which work fine (from what I can tell) and 2 triggers fire off every time the device updates (every 5 minutes), even if they should not. See the screenshot below.
As you can see, the triggers (marked by red arrows) should not fire. However, every 5 minutes, when the device refreshes, both triggers fire. See the log below.
What I have tried (which is even weirder): I tried different variations of the same trigger, but still got the error. Tried deleting the trigger and re-adding. Tried stopping and restarting the rule. Then I created a 2nd rule, which just those two triggers, with no variables and no actions (other than a "notify" action to let me know if the rule triggered). It did not trigger for several hours. So then I added all the variables and all the actions to the new test rule, and the false triggers started again. Then I disabled all the rules (except the "notify" action) and the false triggers continued. So then I created a 3rd rule, again with just the two triggers and no actions (except for a notify action) and this rule does not have the false triggers. so, I have two rules, with the same triggers, and throws false triggers and the other does not.
Latest version of Hubitat (2.3.2.136) and RM5.1
Update:
Now it is doing something completely different...
I had the rules off for several hours. Turned them back on after writing the post above. As you see in the logs below, they ran without any triggers (false or otherwise) for almost 30 mins. Then, at 2:39, both rules were triggered twice each. One trigger is correct ("feelsLike > 100), but the other trigger fired off as well. So, instead of each rule running once, each rule ran twice.
This is completely different behavior compared to before.
Changed the trigger to only fire when "feesLike" rises above 110, and the triggers stopped. So at least that is reliable.
Out of curiousity, I added back one of the other triggers from the original rule..."maxdailygust changed" and the rule fired again (and fired a duplicate instance as well). And over the next hour, an interesting pattern has developed. See below. The rule throws a false trigger every other update.
Please show the Event Subscriptions from the App Status page (gear icon).
See below. Also, I have done some more playing around...
The "false" triggers are coming from the first two triggers in the list above (in the original post), which are "changed" triggers. One of those triggers "maxdailygust" is showing in the event subscription below. When I remove those triggers, the rule does not trigger (the "events" still show up in the log). But when I put those triggers back (either one or both), the rule is triggered and runs a duplicate. I have found that one of those triggers causes a false trigger every 5 minutes, and the other one causes a trigger every 10 minutes. So I have to believe that the device is updating those attributes in some way that makes it trip the "changed" trigger.
Still don't understand why one trigger causes the rule to run twice based on the two untriggered events, but maybe there is more to learn.
Two events in quick succession, makes for two triggers, and if quick enough, two instances at the same time. But it seems as though there must be an issue with why "feelsLike" or "dewPoint" are triggering it, when they don't have changed triggers.
Are these Custom Attribute triggers?
Yes.
If I remove "maxdailygust" from the trigger list then the rule does not trigger. "feelsLike" and "dewPoint" show up as events in the log, but they don't trigger the rule. See the log below for the original rule I started with, after switch the two "change" triggers for basic variable comparison (less than/greater than) triggers.
Now, the next question would be...if I switched one of the changed triggers back to a "changed" trigger, and then had 3 comparison triggers, would I get three event triggers instead of two?
ETA: OK, no, it doesn't. It still just triggers the two "dewPoint" and "feelsLike" triggers.
I'm still investigating this. However, I know that multiple attributes being tested for changed on the same device is going to fail. I further suspect there are issues with multiple Custom Attribute triggers on the same device.
A work-around in the meantime is to use 4 different rules, only one of which has your actions, and each with one of your triggers. The other three run the actions of the one with the actions when triggered. That will side step the issues I'm investigating.
Thank you. I will break them out into individual rules and report back any weirdness.
I've chased down this bug. Only problem is that there is a lot of testing to do to make sure the fix didn't break anything else. If that proves out, then your original approach would work fine.
2 Likes
Awesome. Thanks so much. Just so I understand, the double-trigger was the bug? Even after that is fixed I may still experience some false triggers from multiple "changed" triggers on the same rule, correct?
No, it's not correctly discriminating between the different attributes to determine whether to trigger or not.
1 Like
Hey. Just saw the release notes for the latest update. Thanks for the quick response!
Let me know if this fixes your rule.
Sure did. Thanks so much! (still get the "feelsLike" and "dewPoint" event notifications, but that isn't a big deal.)
Is this a bug in RM? Or a bug in your rule?
Not sure I know enough to answer. Here is what my logs look like for that rule. It isn't triggering anything, it is just posting these events. The two other trigger events on this rule (the "changed" triggers) aren't showing up here, but these two are.
It logs events that it has subscriptions to when Event Logging is enabled. None of those resulted in the rule being triggered.
