Interesting. It's the last one in the sequence where there is a failure. It says the rule became False, but it did not execute the False actions. I will see if I can reproduce this. Are you running 2.0.9.133?
1 Like
This is what I'm seeing too, but have been unable to prove it. I'm running 2.0.9.133
I can't get it to fail, so have to keep digging to find what is different between my rule and yours.
This may be true, although I cannot reproduce it. If you have one of these that misbehaves, look at the app state at those two variables. If the rule hasn't run for some time (i.e., all delays have expired) they should both be empty, look like . If not, there is a problem with that rule and it should be removed and recreated. One thing we don't want to do is to chase after a broken rule acting broken. Of course, we do want to figure out how it gets broken in the first place.
Yes, but I'm seeing this all over the place. I've been saying this for a week, but not getting any traction.
Edit: here is my example...
1 Like
@bravenel I will give it a go deleting and recreating the rules (10 in total). They were all created with this newest firmware, not the previous one
I have deleted and re-created multiple rules all of which still exhibit the issue intermittently. This issue isn't limited to false actions either, I've got the same problem with true actions that use the "cancel on truth change". Unfortunately, I've been unable to pinpoint a specific series of events that causes the issue, short delay/long delay, rule change infrequently/frequently, etc, doesn't seem to matter.
This has nothing to do with True and False. It is all about the cancelList possibly becoming corrupted. If all delays have expired, it should look like this:
If the delays have expired, and there is anything on those lists, there is corruption.
Understood, only thing I can say is that if I select update rule or done with rule the states clear and the rule works again (at least until it doesn't). The randomness of the failure the real dilemma, as you have stated "the code should either work or not work everytime.
Update Rule does clear those lists. Now the challenge is to find what corrupts them.
No need to remove and recreate them.
2 Likes
This would explain why it's only intermittent.
I have another rule, no corruption, lights didnt turn off.
Logging is not enabled on this rule, but rule truth went to false at 7:55:26 (as Global variable was false). Lights didnt turn off, and are still on.
Does this only happen on Delayed actions? Have you tried using an Action of delay and see if it still fails? Not a solution...just another piece of info that might be helpful and a workaround till Bruce figures it out.
Yes, unfortunately same issue.
My experience with leads me to believe that the "corruption" was present, but that the update rule was either pressed or since there was only one incorrect cancelList state present the canceling of the action cleared the incorrect state but left the light on, I've seen this occasionally too.... At least in this state the next time the rule became false the action will run, unlike when the state remains persistent it would just canceling as there would be an "extra" cancel.
I definitely did not hit update rule for this particular rule but the other scenario you describe may have happened.
Believe me when I say I've been battling this problem for several weeks (throughout the entire beta of RM 3.0) unfortunately since Bruce and Chuck haven't been able to reproduce the issue they haven't been able to fix it. Fortunately, since users like yourself are now reporting it I'm sure it will gain the much needed attention it needs to resolve it.
It would be soooo much easier to identify if the "corruption" occurred every time the rule runs or if it threw some type of errors in the logging, but that isn't the case. RM 3.0 is a huge step forward for HE, but with such a major rewrite bugs are unavoidable.
1 Like
Yes, the rewrite introduced some new challenges. The fact that you can have multiples of a single action, e.g. turn off a switch, fundamentally changed how cancel on truth change works. So that’s one thing.
But, the action not running on false is another kettle of fish, as that part of RM did not change, and is much harder to understand. I seriously don’t think this problem has anything to do with delays and cancel on truth change, but I could be proven wrong about that — this is, after all, an unsolved bug, which means I don’t know what is wrong or why, and have only symptoms to go on. For most bugs, I can reproduce them and then easily discover the cause. For ones that I cannot reproduce, a much larger set of variables comes into play.
@bravenel I’m more than happy for someone to jump onto my hub remotely and have a look at the other set of logs if that helps? For now, I’ve disabled all the light rules apart from one (kitchen as displayed in my earlier posts).
One of my old rules that’s been hanging around for a while (I haven’t sent anything to the support email address about it) shows an error when I go into it so I can’t delete it, edit etc. Is there any chance that that rule could be having a knock on effect and be causing the corruption? I doubt it but just thought I would mention just in case
