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
END-IF
IF illuminance is > 2600 AND
illuminance is < 3100 THEN
set percent to 80
END-IF
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.
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.
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 */
ELSE
/* do things here you want to do because the timeout elapsed */
END-IF
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.
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
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.
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?
IF (time is between sunset and sunrise) THEN
Turn ON hallway lights
Notify tams phone pushover and speak on kitchen at 40%
ELSE
Notify tams phone pushover and speak on kitchen at 60%
END IF
I'm new here and have been using logic statements for 20 years. Previous versions of Rule Machine were easy to understand. To re-learn syntax on a function that was so intuitive in the previous tutorials for the rule machine is counter intuitive. I understand the programming efficiencies, (well don't understand but trust they are there), however perhaps using the original WYSIWYG on windows and the subsequent user adoption for a case study. Hopefully, a simple tutorial like those I saw online when deciding on this product will be forthcoming. I'm guessing ultimately mass adoption is the goal so ... Truthfully if there was some kind of intuitive compiler that said if this, then that, else, it would go a long way as most can write a spreadsheet.
Simple confusion to me is when I choose a second trigger (condition) as Mode/ Night the description makes it an OR statement and shows Night as False. It also changes from a condition to an event "Mode Becomes Night" which makes sense under triggers but when I go into Conditions under the Action Section and Choose Mode/ Night it makes the Condition FALSE. I want the Action to occur at Night so this is confusing.
First thing is to understand the difference between an event and a condition. That post is a starting point to get that understanding. Also, read this: [Released] Rule 4.0 (the top of this topic).
That post will help you understand the transformation of the original Rule Machine to the current Rule 4.0, and the reasons for the changes. The idea is to make things explicit that had been implicit. What we learned is that lots of users would stumble over anything that was implicit, and ended up mistakenly adding explicit things. For example, since the events that fired a rule were implicit in the conditions, users would create a Triggered Rule, and effectively break the whole thing. Ultimately, one has to come to understand this distinction between events and conditions. Both are necessary to create automations, and the two are very similar. But, there is an importance distinction that must be appreciated.
An event happens from a device in an instant, and the result of that event becomes the condition of the device. A switch turns on (the event), the light becomes on (its condition). If we want to automate something when the switch turns on, we need an event to trigger that automation. If we want to decide what to do based on whether or not the light is on, we need a condition to test the state of the light. These are two different concepts, both essential, yet still, different.
It also makes the underlying nature of the subscription clearer as well, as we can see what event we are subscribed to and then the rule evaluation occurs based on the conditions described.
Personally, I have always grouped the arguments for an Event and then triggered the action or series of actions following. "IF mode=night is TRUE AND arrived home THEN turn on light. Same as "IF arrived home THEN turn on lights IF mode=night is TRUE. I guess it is a preference on how each mind works.
If mode=night is TRUE is not an event. Hubitat uses an Event / Subscription model for automation, which is why I think Bruce has made changes to Rule Machine to improve clarity around that.
If Presence Changes (Event) and mode is Night (Condition) do THIS (Action)
@bravenel The only thing I was pondering Bruce was about the possibility of dynamically controlling the subscribing and unsubscribing to events to prevent rules from being evaluated unnecessarily.
Like let's say with the mode change above, that I could actually subscribe/unsubscribe rules based on that event. Is that a silly idea?
Edit: Or it could even be a pause/unpause rules based on Mode change, that probably would already work?
