# [Released] Rule 4.0

IF contact is open
ANDIF time is this
THEN
set dimmer to 75%
wait 1 min
turn off dimmer

That's the way it should be done. Here is using the ORIF.

IF contact is open
ANDIF time is this
ORIF light is on
ANDIF time is this
THEN
set dimmer to 75%
wait 1 min
turn off dimmer

I do appreciate your thoughtful and complete response, and yes, I do know thatās the way RM 4 handles things now. I merely opine that it isnāt logically consistent.

The rule that I was working with is to have Hubitat wake my butt up at 4 AM tomorrow, but this is a rare occasion. I normally donāt want a wake up call.

So I construct a rule where the ātriggerā is 4 AM, but the āconditionā is October 9th. It will take quite a bit of patience to explain to me why the time is a trigger but the date is a condition.

Donāt miss my main point, and that is that logic flow is not an action, and actions are not logic flow. These need to be separated.

What just did is a classic rule, where the contact opening is the trigger. You could just as easily said āWhen the contact opensā IF time is this ...

For those who donāt understand the difference between an event and a condition, try this clarification: An event is something that happens, a condition is something that is. A contact opening is an event, a contact that is open is a condition. Every condition is the aftermath of an event.

Consider how you would describe a button press as a condition. Are you constantly holding down the button? No, because it is only an event. How about time between sunrise and sunset? Is that an event? No, because it is a condition that is true or false and is such for a long period of time.

2 Likes

I think you just said why everyone is confused. You now have introduced a new word...Event.

IF is a trigger
ANDIF is a condition
ORIF is a trigger

So,

IF the door is opened
ANDIF the light is on
THEN
Turn off the light

IF the door is opened
ANDIF the light is on

ORIF a switch is turned off
ANDIF the light is on

THEN
turn off the light

1 Like

OK, you're stubborn I see.

At 4:00 PM is the event and door-is-open is a condition. It would be true if the door was already open, it doesn't require the event of the door opening.

See this for further explanation of the importance of events and conditions as clearly distinct:

See this is the "event" trigger not the IF

I am not being stubborn but I have been using this in HS for years without any problem. We will just have to say that Rule 4 is much different than HS.

This just for grins. As far as using your example.

IF the time is 4pm
ANDIF the door is open
ANDIF the light is on
THEN
Sound the alarm

What is HS?

You know, you can go back to Rule 3.0 if you'd be more comfortable not thinking about events.

It is probably software you all don't like to hear about... Homeseer

LOL. Well, there's no pleasing everyone! We've done our best here; sorry if it isn't up to your expectations coming from HS.

1 Like

It wasn't meant as a comparison, it is because usually no one likes to talk about the competition. That is if you can really call them competition. Not trying to start anything or cause ill feelings. You guys have done a fantastic job and just for the record I have moved everything to HE and have shut down HS except for a couple of things.

No, you created a rule that does something entirely different. Mine turns on the dimmer when the contact senor is opened, then turns it off one minute after it closes. Yours turns the dimmer on when the contact sensor is opened, then turns it off one minute later, and it keeps this "scheduled" off even if you close and re-open it in the meantime (so say you open it at time zero, close it soon after, re-open it 59 seconds after the first time; you'll observe the dimmer turns off on 1 second instead of 60--and that's not all, since you now still have another "off" scheduled from the second opening that may bite you in the future).

Key differences include the fact that this rule doesn't wait for the sensor to be closed (this is a common mistake people make in new motion lighting rules: they schedule an "off" for so many seconds/minutes after a sensor becomes active, not inactive) and that it doesn't cancel these delays and the following actions (here, an "off") when the sensor changes states again. Both of these problems are solved with the rule the way I wrote it, unless this is really your desired outcome--but again, that's a different rule.

EDIT: OK, so I think I should maybe interpret this as the way you think RM should work. You'd still need an equivalent of webCoRE's "task cancellation policy" to eliminate the pileup of delays, I think. I don't mean to debate whether one way is better--but I can definitely say that this is how Rule 4.0 does work, and if you have trouble finding the right triggers or actions, lots of people are willing to help. I'm so used to this now I think I might have a hard time with that way now.

I didn't take it that way (hard to tell with written language!). But, seriously, really mastering the capabilities of Hubitat Elevation does require some learning of new concepts. Read the linked article above.

I will. Thanks for the patience.

I see what you are saying. As I said to Bravenel I have moved everything and have dozens of rules, in 4 by the way, and for the most part I have no problem getting my rules to work. I still struggle a bit with the, delay and repeat, stuff but that is for another time. When you do something for years it is hard to change sometimes. I will continue to read and learn.

@arnoud -- here's a bit of one rule I have that looks for ranges of illumination with gaps between the ranges. This might help.

@bravenel I am in awe of how useful and powerful Hubitat and RM are, so please don't take my comments as more than a healthy intellectual discussion.

But I do find the difference being drawn between triggers/events/things that happen and conditions/states/they way things are is a little bit contrived. I'd just as soon write a rule that says "If the door opens" rather than "If the door changes then if it is now open after the change, then". But I do see some power in the ability to conditionalize what happens based on whether the door is open or shut, whether or not that had anything to do with launching that rule. I get it.

It isn't as clear to me in the time being a trigger but date being a condition. Why not "If it becomes time on date" .. then?

Perhaps my frustration in this instance is with the way the editor building rules works. It hurts my brain to add an IF/THEN construct and call that an action. And in this case also, all I wanted to do was edit the condition (i.e. change the date), but there appears to be no way to edit a condition.

Thanks! for every false you move on the next ELSE-IF, it surely helps understanding RM 4.0 its a more steep learning curve then RM 2 and 3. And interesting to see that END-IF is not really needed for the ELSE-IFs. I guess only when you want to add a new IF statement below the code you must use END-IF I think. Anyway slowly learning here..much appreciated.

Yeah the interface and the lack of editing options is not really convenient. I think I read somehwere that the web interface redesign would require a lot of changes in the Hubitat webserver itself.
I hope that they will add an editor for the whole code itself in the future.
I would make it that you have an input screen and an options screen that has all the pulldown menus. and where the cursor is..there it will paste the different menu options and devices. And you could copy paste the device name and previous rules and edit wherever. But that would require a lot of changes and a smart parser.

1 Like