[Released] Rule 4.0

You can use date as a trigger (with a time, since a date is rather a long period of time). Check out Periodic Schedule as the trigger.

It's not contrived at all. It's the logic of an automation system. It's how they work. There are discrete events (e.g. a button being pushed), and there are conditions that are not events at all (the door being left open). You cannot build automations with only one or the other.

The original Rule Machine had Rules with Conditions. In effect, IF (door is open) THEN do something ELSE do something else. However, for that to work there had to be two events to trigger it -- two implied events: the door opens and the door closes. The rule would be true if what triggered it was the door opening, and it would be false if what triggered it was the door closing.

Now, you can certainly create that same rule now, with both triggers. We added changed to simplify the rule. In either case you would still need to test if the door is open or not, just as in the old approach. What we did in Rule 4.0 was to make these things explicit, instead of implicit. The reason for that change was that people were always confused by things that were implicit, that could not be seen.

What we know now is that everyone thinks in a different way. Some people are very comfortable with one approach and can't figure out the other. What to do? I suppose we could have both approaches at the same time, but then that would totally confuse people. So we settled on making things explicit. In the old approach, the implicit things worked exactly the same way the explicit things do now. The underlying logic is identical. One is hidden, and one is in the open. I figure it's better to have things in the open. But, alas, not everyone thinks that way...


At the bottom of the panel where you edit/add Actions, there's a "Manage or Create Conditions" link that lists all of the conditions for that rule. Click on it and it will take you to a panel where you can add/edit/delete conditions.


The IF / ELSE-IF / ELSE-IF ... END-IF construct the way I'm using it in that snip of rule is a simple case statement. That is, it evaluates one value (illuminance of Virtual Lux Average) against a number of possible values and stops when one of the "cases" is true. It's all one big "question" so the END-IF is needed at the end. I could have done the same sort of thing with multiple IF statements:

IF illuminance is < 2500 THEN
    set percent to 100
IF illuminance is > 2600 AND
  illuminance is < 3100 THEN
    set percent to 80

Etc. I need the END-IF after each IF because each is a complete "question."

If there's no following statements, the END-IF is technically optional. But it's really best practice to put it in every time so it's clear where the question ends. It also makes it easier if you go back later and add more into the rule.

Learning this, for me, made it a whole new ball game!

Read fully before answering, as I kind of figured it out myself.

Thanks. I tried this, and it didnt turn off. Should "cancel wait" preclude the rest of the rule (after the wait) from running. If so, what is the correct command?

I want the 3 lines to run after the wait is over, OR if the wait is cancelled. The others are superflous.

Here are the logs. You can see that the cancel wait resulted in the rule not processing any more commands.

Then I read your post again, and realised that I needed to add back in the timeout. So I did, and tested with 2 minutes, and it worked.

My questions are:
Cancel wait is for the case where the event did not occur.
What is the timeout in yellow doing? Why did my first rule above not work, when that was not included? Do you need both timeout and cancel wait for the event not occuring?

If I use a custom attribute in RM and use the "contains" option is it possible to input multiple values for RM to check or do I need to add a condition for each custom attribute? If I can add multiple values how are they separated? Trying to setup weather conditions for lights and trying to avoid added a bunch of conditions for each weather condition.

To answer your question, you don't need both a cancel wait and a wait with a timeout. The timeout (the part in yellow) is what makes the wait "expire." Your "cancel" is, at best, not doing anything (in an ideal world it happens at the same time the wait would have ended anyway due to the timeout) or at worst cancelling the execution of both the remainder of the wait and everything after it (this seems more likely to me: being before the wait, I'm guessing it's more likely for this delayed cancellation to run a few milliseconds before the wait's own timeout actually runs out). Like a standalone "Cancel Delayed Actions" (if you are familiar) on a standalone "Delay" action, a "Cancel Wait" action will cancel both the wait and everything after it.

The general paradigm you're looking for to wait for either an event or elapsed time and then proceeding with different actions depending on which happened is this:

Wait for events: XYZ turns off --> timeout: 0:02:00 
IF (XYZ is off) THEN
  /* do things here you want to do because the switch turned off */
  /* do things here you want to do because the timeout elapsed */

So you wait for the event, then check a condition that would have resulted from that event--here the switch being on or off. If it's off after the wait, we assume that the wait event happened (though technically a "Wait for events" based on that would also catch it if the switch already happened to be off in the first place and then the timeout just happened to expire). If it's on, the ELSE runs, so it must have been the timeout that made the wait expire.

PS - In related news, I know you didn't really ask for help with your rule, but it looks a bit messy. Does the switch report multiple sprurious "off" events if already off, i.e., is that an issue you're trying to solve with an on trigger and pausing/resuming this rule based on that? If not, you could use an off trigger and get rid of all these waits and just do what you want then, unless there is more complexity to this elsewhere.

1 Like

you could select the trigger to be just OPENED if you want (providing you only want the rule to run on open only) or OPENED and CLOSED or just changed which in a two state device is just both. So if your rule needs to evaluate if the door is open AND if its closed then its easiest to select "changed" but if it makes sense to use to select them all manually then you can.

Then the time would be the "trigger", the date the condition because you want it to run at the specified time but only on this "date" or i believed there is also a calendar trigger which would be better if its only firing once a year.

there is a way its at the bottom manage conditions

Thanks. However, there are actually two rules.

This rule: Lighting and Fan - Ensuite Bathroom
Another rule: Lighting - Ensuite Bathroom

I'm attempting with this rule to have the fan turn off after 20 minutes of turning on, and also turn off any lights that were turned on by the other rule (which would have already triggered, since it's wholly based on motion). So, as soon as I press the fan button (activating this rule), it pauses the other rule (which is auto off after 5 mins), it cancels the other rules timed actions, and then after the 20 minutes expires in this rule, it resumes the other rule ready for next time.

Thanks! It helps understanding the system!

Are we likely to ever get a way of editing rules that allows typing, copy-paste etc?

As a programmer for 25 years I get extremely frustrated trying to work out what state I need to get the UI into to do something simple like adding an extra action to the third else-if clause. Something that would take 1.5 seconds if I could edit the code.

I realise that programmers are not the target market and that editing would have to be carefully managed to ensure actions and parameters were actually valid choices in the correct scope, but is this something that’s likely to happen?