Odd Rule Machine behavior observed last night

Running a C5 on 2.4.2.134 currently. House was shutting down for the evening but the bedroom lights didn't go off. Take a look at the logs below for times 11:09:02.093PM (occupancy sensor contact open = occupied), 11:09:02.274PM (the very next test thinks its closed!), and 11:55:36.107 (when the close event actually occurred).

Rule machine bug here? Definitely would be intermittent if it was because I've not seen this behavior before. Here's the referenced logs snippet:

Two things first: it's Rule Machine, I believe, and the time is 11:55 not 11:35.
Writing "Rule Machine" gets a certain person's attention, lol.

Now, I have no idea if this would help or not, but have you tried the "Command Retry" option in Settings? I find it interesting how many times it's used, especially on multiple device actuations.

Thanks for spotting the typo/error! Its early in the morning here. Fixed. Don't think that command retry would have done anything here since the state change didn't actually occur until some time later.

According to that log screenshot, MB Motion Sensor contact is "open" at both of those times. The value in parenthesis indicates the current state (open).

1 Like

Take a closer look. at 11:09:02.274 the actual value is shown as closed which makes that test false "closed(F)". The same exact test is done both times "if master bedroom motion sensor contact(open)". What is shown after the test is the actual value. in the first test its showing "open(T)" (a correct assessment) and in the second it's showing "closed(F)" (bug?)

But it's not the "exact same test" though... What happens at those 2 times correspond to 2 unique conditional statements in your rule -- the first one (at 11:09:02.093) is checking to see if the sensor is open, and it is.

The second one (at 11:09:02.274) is checking to see if the sensor is closed -- it's not -- it still shows as open (which is expected since nothing between those 2 times show any state change of that sensor).

How about posting a screenshot of the actual rule's build -- that'll show conclusive evidence about how you set up those 2 corresponding conditional statements.

3 Likes

Ahh... Understood. I was reading the logs wrong. So the problem appears to be that hubitat wasn't in sync with the bedroom overhead light state which is why the second test was skipped. Thanks for pointing this out.

1 Like

problem is with the switch. It's suddenly not recognizing the off command from the rule. I just checked and that light is still, in fact, on...

Right on, it can get confusing especially when you're in chin-deep muddling with it.

In the logs, the device value in parenthesis will always indicate that device's actual state at that particular point in time.

Good luck with troubleshooting the switch - hopefully it's some kind of easy fix!

Its an Inovelli Blue dimmer. Did a configure all and it seems to be happy now.

1 Like

Might want to turn on "command retry" for this kind of problem as @velvetfoot stated above. This will at least retry if the switch does not respond within some preset times until it does, then it will log an error if it did not respond and you will be able to see these errors to let you know that is the problem. I've turned it on on all my lights and plugs, this made things a lot more reliable!

2 Likes

I also think it's good for troubleshooting. I adjusted hub/antenna positions with success after getting the "5 retries and you're out" warning. :slight_smile:

2 Likes

I'll consider it for sure. Currently trying to understand why this switch started acting up in the first place.

Maybe router "optimized" it's WiFi channel, which now interferes with Zigbee