I have been breaking my head on this all day. I cant figure out why im getting this error.
This rule runs 2 ultrasonic foggers on intervals. The rule is run on a loop using hub variable Ultra LoopVar.
-Ultra Loop is a virtual switch that can stop the loop.
-Humidity of Atlus is a humidity sensor used as a backup to trigger the rule incase the humidty drops below 90. Sensor is saturated and shows 100+ values in the logs.
I specifically created this with Waits instead of Delays so that the waits will be canceled when the rule is re triggered.
Would love to get some extra eyes on this!
Im also noticing that sometimes when i exit the actions sections the conditons show up as "unused". However, clearly you can see in the actions section that they are used. If i click into the actions and out a few times they seem to reset back to normal.
That's odd; I don't see any reason for that error either.
I suspect there may be a bug related to this, although it's not obvious to me just what it is. Meanwhile, this is a damage-free error; this rule should work fine even with the error. I'll see what I can track down about the error (I have a suspicion).
1 Like
Thanks for the quick response.
Graphs show the switches going on/off correctly with no buggy actions. However, last night at 4am the rule just stopped running. This caused one of foggers to be left on few few hours...things got a bit wet. I can only assume this error had something to do with it....but if your implying its a damage free error im thinking there might be something else at play. I did triple check that all devices here are only controlled by this rule.
Do you think duplicating by cloning, or by rebuilding from scratch, can have any effect?
In theory, no. But, I don't know why you got this in the first place, and that is sort of worrisome. The other thing you could try is to break this into two rules, and get rid of the IF-THEN-ELSE, and trigger those with on and off instead of *changed*. The 'error' happens at the END-IF.
2 Likes
First thing that came to my mind is to ask, do you have the optional "Ignore Trigger Events While Running" enabled? I did not see one way or the other in the pictures above. I used to get a lot of multiple simultaneous rule execution errors until I enabled this feature.
I suspect that due to the trigger "changed" your rule is doing something, changing this vswitch, which triggers the rule again. If this is the case And you do not have the Ignore Trigger feature enabled, would you be able to test it with that enabled?
In addition, do you have anything in your triggers that would be false while the rule is running? If so, you could setup a Required Expression to also help limit when the triggers fire.
Good luck.
FYI this feature is being deprecated/removed in the next release:
1 Like
before creating this post i did experiment with setting "Ignore Trigger Events While Running" to true. It made no difference. I have left it on now.
The vswitch (Ultra Loop) always stays on. I am sure There is no other app or rule that is currently commanding this switch on/off during the loop of this rule. Its an option i built in to disable this interval loop.
checking the logs now, it seems that the error is occurring on every other run of this cycle.
Since this is only happening on the last step i just added "command only switches that are on" for the last Off Action. going to see if this makes any change.
After 3 loops with no error the 4th loop did show the error again.
I created another clone of the rule for testing. I added an Exit right at the end of the rule and it seems to do the trick. So now, is this buggy behavior or should there be an exit in the case of such a loop-type rule.
-
Additionally, The first two lines in the rule are local variables set to false. One is a Private Beoleon, the other is a new local variable i created. At the end of the rule they are set to true in order to retrigger the loop. Simply put, this does not work! They dont trigger, not once.
I created a new hub variable, testhubloop, and this hub variable does re-trigger the rule as expected. This has to be a bug right?
-
Also, as i stated before you can see that conditions in the Manage Conditions container is showing (unused again). This happened after going into Triggers and removing a hub-variable trigger for testing.
(I have removed the hub-variable as a trigger in this image)
Can anyone else reproduce the effect of 1. ?
It seems that a Local Variable cannot be used as a trigger in it's own rule. Is this done by design to prevent re-occurring loops? Or is this a bug?
To use a local variable as a watchdog function im pretty sure this would need to be enabled right?
No, a local variable cannot be used as a trigger. A local variable is local to the rule, but a trigger has to come from outside the rule.
4 Likes
Noted. thanks for the info.
Edit: and what about the logic behind putting an Exit at the end of the rule? Since its addition there has been no issues or errors.
There is no need for Exit at end of rule. It's going to exit when it reaches the end of the Actions. Exit is useful when wanting to end Action execution early, in some place other than the end of the Actions. At the end, it's redundant and harmless.
1 Like
but my point was that with the EXIT not in the rule I get the error. Once i add the EXIT back, the error does not come up.
I don't know what's going on with your rule. I don't know why you're getting that error, but you should be aware that in this case it is harmless. If you want me to investigate, export the rule, and email the downloaded file to me.
3 Likes
I am able to reproduce this problem, although I have to say that I still don't know what is actually going on here. We are digging a bit deeper to see what we can find. Apparently, part of the rule's state is becoming corrupted when it returns from one of the Waits.
5 Likes
We were able to find and fix a subtle race condition that caused the problems you reported. This will be fixed in the next beta release.
2 Likes
You guys are awesome! Just because im curious, can you share the details of the issue? unless its a really internal issue.
Not really, as it is deep internal. We found that there was some sort of race condition involving saving and reloading state. You discovered that Exit Rule at the end made the problem go away, and we figured out that was a change to some timing. The rule re-triggers itself, and then immediately exits. When a rule exits, it writes state to the database. When a rule starts, it reads state from the database. There was a weird timing issue with your rule, seemingly related to the juxtaposition in time of those two things. I could see that just before it threw the error, it had loaded the wrong state, and working backwards from that, it may have failed to write the state when it should have for one of the Wait for Elapsed Time. It was very odd, because it wouldn't fail right away, or consistently. Now, with the fix, it doesn't fail, period.
7 Likes
