RM rules not firing when rule-truth conditions change

@jason0x43 yeah i understand, as mentioned more than one way to do things so I’m sure someone else might have the magic. I have a pretty simple setup so going into it just configued as my ST was as it worked. Hopefully it’s something simple.

I’ve been using CoRE and webCoRE for a while now on ST, and thought it’d be fun to re-implement things in RM when I was setting up my Hubitat. I was using some webCoRE features that RM doesn’t directly support, like “global” variables, so my setup there doesn’t port directly over.

It’s been interesting coming up with equivalent ways of doing things. I like RM’s comparative simplicity; it gives you some basic building blocks that you can do most anything with (at least it seems that way so far), while keeping the overall system pretty easy to reason about (barring my apparent inability to reason about what’s going on with my breaking rules).

OK, a couple of things: You are right that it should work the way you have it. The reason something happens when you click Done in the rule is that forces an evaluation of the rule. Since the rule is true, clicking done will cause the Actions for True to happen.

I’m going to try something similar, and see if I can reproduce what you’re seeing.

Remember this key point, rule truth must change for a rule to do anything. Based on what you showed above, that should be happening in both rules. First, the time hits sunset - 60 and first rule becomes true. Assuming second rule was false prior to that, it should change to true and do it’s true action. Then when it’s 11:00 pm, the opposite should occur. The first rule will become false, and that should cause the second rule to become false. Nothing will happen at 11 pm as there are no Actions for False in either rule. But the rule truth of both should now be false, so the next day at sunset-60 it should all work.

Like I said, I will check it out and see if something is messed up in RM or not.

That’s what I was thinking. When “It’s evening” becomes true, the state change should cause any rules that depend on it to be evaluated.

Hmmm… the only condition for “Good evening” is the rule truth of “It’s evening” – is there a way “Good evening” could be true when “It’s evening” is false?

Thanks for taking a look!

I can confirm that there is a bug somewhere. Now to dig it out. It appears that the second rule is firing it’s true action when the first rule goes false, which is obviously wrong.

This bug has been identified and fixed, should be in the next release.

This one was very interesting. Turns out that the code worked fine in ST, but not in Hubitat. In Hubitat there was a race condition caused due to our multi-threaded architecture. Solution was quite simple.

Excellent!

Always the most fun things to debug. At least the failure case was the common case. :slight_smile:

A case of the left hand not knowing quickly enough what the right hand was doing. Fix is to only use one hand. :sunglasses:

This bug has been fixed in the latest release.

1 Like

Rules seem to be firing now for rule truth changes, but I'm seeing at least one case where a rule that's using another rule's truth as a condition isn't seeing the rule's current state (or I'm not fully understanding how that should work).

Here I have an "It's day" rule that doesn't do anything itself, it's just used a truth source in other rules:

And here's a rule that uses it. Note that although the "It's day" rule says it's condition is true, this rule says "It's day" is not true.

This is because a triggered rule is only evaluated when it is triggered.

Ah, then “rule truth” won’t really work as a global state variable. I was assuming that using ‘rule truth’ as a condition would be like using ‘switch state’ as a condition, where the ‘truth’ value would always just be the evaluation of the rule. (Essentially, I imagined a rule as having an internal state variable that was set to ‘true’ when the rule became true, and ‘false’ when the rule became false, and that ‘rule truth’ was just the value of this variable.)

No, it will work that way. But you were looking at it from the perspective of a triggered rule. If that triggered rule were triggered, and the rule evaluated, it would get the correct value for the rule truth. When rule truth is a condition of a rule, there is in fact an internal state variable that is set as you describe. I’m not sure at the moment why the display above did not show [TRUE] for the rule in your second rule. I guess it would depend on when that rule was setup and the evaluation done that yielded [FALSE]. What happens when you go into the condition (Rule truth of it’s day true) and hit Done?

That was the issue I was running into – the triggering condition was happening, but the actions weren’t firing, and the “truth” value shown in the condition didn’t change (it still said ‘FALSE’ after the trigger). It looks like the trigger rule is never re-evaluating the condition rule.

I tried going into the “It’s day” rule and clicking Done and then looked at the “Turn on Jason’s…” rule – it still reported the “It’s day” rule truth as “FALSE”. Then I clicked Done for the “Turn on Jason’s…” rule, and it continued reporting the “It’s day” rule truth as “FALSE”.

Would you try deleting the second rule, and re-entering it. See if that fixes it or not. If not, there is a bug somewhere.

I deleted the dependent rule (“Turn on Jason’s bathroom light in the day”) and re-created it. The new rule still shows the state of “Rule truth of It’s day true” as [FALSE] (although the actual state of “It’s day” is currently true), and it doesn’t run its actions when there’s motion or the bathroom door is closed.

Interestingly, when I change the condition to be “Rule truth of It’s day false”, the condition state is still reported as [FALSE]. It doesn’t look like the condition is ever being evaluated (it’s constantly null).

I created a virtual switch to hold the state of the “It’s day” rule (so that when the rule becomes true it turns the switch on, and when it becomes false it turns the switch off), and modified the “Turn on Jason’s…” rule to use that switch state instead of “Rule truth”, and the rule works properly.

Also, my standard rules that use ‘Rule truth’ as a condition (rather than this triggered rule) seem to be working. At least, my “Good morning” rule ran this morning. However, my “Good day” rule, a standard rule that uses “It’s day” as a condition, shows the value of “Rule truth of It’s day true” to be [FALSE], even after clicking ‘Done’ in the “Good day” rule.

I should have mentioned that any dependent rule needs to be opened and hit Done. I’m out of the office today and can’t check the code until tonight. Because the way rule truth is updated to dependent rules, it’s probably a good idea to open dependent rule first, hit Done, and the the source rule, hit Done.

I am having similar issue even after 706 update.
I have 2 rules one checks if I am present between at 5-50A - 5-55AM, if true mode changes to HOME.
Second rule checks if I am not present between 6AM - 6-10AM , if true mode changes to Away.
Neither worked today.

This is not related to the subject of this thread. You would need to show some logging of these events, and other supporting information (app state, rule screen shot, device detail, etc) for us to diagnose your situation.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.