I'm working on merging several old rules into one RM4 for my dishwasher monitor and I think I have come across a potential issue with quick firing triggers.
My testing suggests that the rule stops wherever it has got to if it is triggered again. Is this expected behaviour?
In my example sometimes the door contact trigger has a bit of a jitter and sends open/closed/open in quick succession. My initial version of this rule had the door contact if/then section at the bottom of the script. Watching the logs for this when this happened suggested that the rule triggered fine on the first "open" but didn't get to process the door contact if/then section by the time the second "open" started the rule again. Moving that part of the code to the top (as it is now, see below) solved the problem.
Although in my case this is only a problem because the contact sensor location isn't great, but I guess there are other cases with multiple triggers that might fire one after another with not enough time between for the rule to complete it's script. If so I guess it's something to bear in mind when creating longish rules?
It is quite possible to have multiple simultaneous instances of a rule either running, or in the process of running. By the latter, I mean for example a rule that is fired and then has a delay, so it is pending that delay to come back to life.
In theory there can be many instances of a single rule. But each instance is unaware of this, and all instances share a single set of state variables. In some cases, this multiplicity is intended and works as expected. For example, a simple motion rule that has a delay with cancel where one side of an if is waiting for motion to recur and the other is waiting to turn off a light (but gets cancelled).
Where it breaks down is in complex rules, especially ones with nested IF-THENs that have embedded delays and have multiple triggers. The rule must use a state variable to know where it is in the nesting structure. If a second instance of that rule starts up, that second instance will trample on the first instances state it needs to process the nested IF-THEN. You will see this failure in the logs as an error about not being able to "pop from a null".
So, Rule 4.0 affords a great deal of power to the rule author, but that power can lead to things that just won't work. You have to think through what happens every time the rule is triggered. If you have complex multiple triggers, you are more likely to get into trouble. Resist the temptation to bake everything into one rule. If you need to deal with complexity, use Global Variables to link multiple rules, each of which is relatively simple, simple enough that you can think through the consequences of what happens. If the complexity is such that you can't think through all of the possible variations, then it is too complex. This is not necessarily easy stuff. This is the result of an event driven 'engine', that is simply responding to events as you instruct it.
I wanted to merge my several rules into one mainly in the interests of keeping everything in one place and tidying it up, but in terms of functionality, maybe that was not the best plan.
Tidying up should not motivate the design of your automations. Think about it, you're placing importance on how an administrative interface looks. You don't live in the administrative interface, you live in the house. Make the house work, and put up with the admin interface as needed. Use consistent naming, but don't dwell on the apps list appearance.
Thanks, but when I finish setting, hit Done and come back to edit , I did not see where I can delete " Local variables " ( i.e : I want delete CompTemp1 and CompTemp2 , because I can not change the Type ) ?
@bravenel I know you've mentioned before about some parts of rules not having the ability to "edit" I'm not sure if this is one that you were referring to. If it's not one then there is a bug here.
Somehow my hub's "modes" got out of whack since this last release, (I had 2 Day modes and Night was missing) but after noticing this hopefully getting it lined out my mode based rules had to now be fixed.
So in the above screen shot I wanted to "edit" IF (Mode is Away change it to IF(Mode is Night
But upon clicking "edit" I get the above screenshot to select And, Or, or Xor with no way to change the Mode.
Does this need to be deleted and reconfigured completely?
Click on done with conditions and a window appears at the bottom that has your conditions. Click on that and then you can select edit and pick the the mode and change it.
I did not realize that you could change a condition within the expression that way. I thought you had to click "Erase Expression" and add the conditions back in from your list of available conditions, adding the missing condition in by choosing New Condition.
I think I stumbled on two bugs related to setting variables. One, if I try to set a global variable from device attribute, the dropdown fails when picking a device. Seems like a graphical glitch, but it does cause a broken rule.
Secondly, the list of available attributes when setting local from a thermostat seems to be missing SetCoolingSetpoint:
In all other automations 'coolingSetpoint' does not work, but in this case I am able to retrieve this value to set my virtual dimmer to achieve voice-controlled thermostat.
You can see in the last screenshot, that when I've tried to use a global variable, the only reaction when clicking the "Select device" dialogue box is that it gets a blue shadow. If I choose a local variable from the first list, then this works just fine. My virtual-to-real and real-to-virtual thermostat control works fairly well. Other than the odd behavior of the Zen thermostat in general. It tends to bounce around a lot, and require multiple setpoint pushes to ensure reliability. I did a repeat-actions loop to hit it a few times just to make sure.
