[Released] Rule 4.0

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?

Sorry y'all - is this the right way to do this, or is there a way to bridge the 2 simple conditions "sunset to sunrise" ?

Yea just do.

IF (time is between sunset and sunrise) THEN
Turn ON hallway lights
Notify tams phone pushover and speak on kitchen at 40%
Notify tams phone pushover and speak on kitchen at 60%
1 Like

@pjam73 You could just code app/driver in Groovy. One of the staff stated a while back RM was added for non programmers to make it easy for them.

It’s actually pretty easy once you get past all the boiler plate, docs, etc.

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.

Read this post: Introduction to Automation

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)

1 Like

@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?

But see, you have to change your thinking slightly. You are putting the conditions first or you're mixing your rules with your conditions. Think of it this way, The phone rings, so you pick it up. It's a robot call, so you hang it up. The phone ringing is the event that cause the something to happen, you picking up the phone. Who's on the other end is the condition that you evaluate and then take action on. So, in your example, arriving home wuld be the trigger. The condition you're going to evaluate is what time of the day (or mode) the system is in.

Ultimately, something has to cause the rule to begin it's work. All of that is based on events generated by devices. If you can think of it that way, you can usually find the correct trigger to use in your rule. Just ask yourself, when I want this to happen, what was the last event that occurred? That will be your trigger. You'll get it...just keep plugging away at it.

I would not put it that way Combining the trigger and the condition with AND is probably going to confuse people. If I were you, I would separate the trigger from the action. I usually put it this way.

TRIGGER:  Presence Arriving

If Mode is Night  Then
     Turn on light

Separate the trigger from the condition and I think you might find it easier for people to understand.


Fair point, just wanted to distinguish the condition from the action, but it logically flows the way you have put it.

Since AND links two conditions together using it to link the trigger and the conditions might cause confusion, that's all.


And was there for the mental logic, not actual rule logic. i.e. I come home and it's night, so my lights turn on.

As opposed to his iteration which was It's night and I come home.

1 Like


1 Like

Ok, I know I need a cancel in here somewhere...

Trigger: Switch A or Switch B changed
Rule: If
Switch A is ON
Switch B is OFF
THEN Turn Switch A OFF - delay 10mins

But I want to cancel the OFF action if either switches changes again.

Okay, I think I may have a working solution:


So immediately after trigger I cancel delayed actions (should just be the off?)

The light is normally triggered by motion - so its status is usually correct. The fan is ZW (not Plus) switch and often doesn't report physical changes. So I added the refresh and delayed processing for 10 seconds to allow it to correct.

Any thoughts?

What do you want this Rule to do exactly? Having the Cancel Delayed Actions at the top it will always cancel the delay, I believe.

If Fan is on, but Light is off
Turn Fan off after 10 minutes
BUT if Light turns back on - reset the delay