Feedback requested for my first (simple) rule for a garage heater

I've had a C-8 for about a week. The main reason I bought it was to turn off/on a new garage heater when garage doors are open/closed but I'm also moving existing WiFi devices from Alexa. It's been fun setting everything up and I'm finally to the point that I want to create a rule for the heater. This is what I came up with. If someone with more experience than me could give me some feedback, I'd appreciate it. Is it "safe" to activate the heater actions?

Nice start! My first reaction is that the WHILE - END-REP clause is unnecessary, because "Wait for Event" will just keep waiting once instantiated. If you only want it to "Wait" for a certain duration, use the "Timeout" feature associated with the "Wait" action.

Trigger:
     Any contact open

Actions:
     Turn off heater
     Wait for both contacts closed
     Turn on heater

The syntax will be different in the RM UI, but this is what I would do. Simple and clean. Your rule also has the problem with the private boolean. The only way it would ever execute is if you manually (or through another automation) toggle the private boolean.

Because your intention with this . . .


. . . is for the rule never to run IF Private Boolean == false, make that a Required Expression instead, and remove this conditional from Actions.

But I have two garage doors. My thought was wait for a close event and if there not both close wait for another close event.

I don't think I can wait for a close event if both doors happen to be open at the same time.

Thanks for the help!

I see the Required Expression now. How does that differ from the IF?

Worth exploring "Wait for Expression" then, with the Condition being Contact1 Closed AND Contact2 Closed.

Oh I see what you were saying. Is this going to poll the devices based on the while parameters? Isn't it more efficient to wait on the close events and then check the conditions?

Sorry, didn't really flesh that out far enough.

One of RM's coolest features is the (optional) "Required Expression" feature. After turning it on, you'll see a new section:


where you can declare what needs to be TRUE in order for the Rule to run. Here, I've chosen Private Boolean must be TRUE.

The purpose of this declaration is to prevent the Rule from firing multiple times (or again, anyway) after becoming active. I think you gleaned the value of that gauging from your choice to include a Set PV = false as your first Action, and Set PV = true as the rule's final Action.

Again, these are all optional steps, if you are not concerned about the Rule firing more than once. I consider it a best practice to use PB in almost every rule I write.

1 Like

Practically speaking, not much. BUT, if your actual goal is to minimize hub load and truly prevent the rule from even trying to run, "Required Expression" is the ticket.

Worth mentioning that one rule can set another rule's PB true or false, but save that kind of advanced shenanigans for later. :slight_smile:

That clarifies it. I'll change it. That's exactly the kind of thing I was looking for. Thanks.

Yay. Was standing in your shoes not all that long ago. Welcome!

1 Like

Clarifying this point, no. It evaluates the expression at the time the action is reached. If true, it continues. If false, it (temporarily) subscribes to whatever events could change the evaluation, re-evaluates them when one fires, and does one of these two things again as needed. There is no "polling," either of the reported device state (all any app like Rule Machine knows about) or the actual device itself (very rare and rarely necessary, some classic Z-Wave devices aside).

...in case this knowledge helps ease concerns you may have in the future.

(In general, Hubitat is normally described as an event-driven system, the above being one illustration of this point.)

1 Like

To beat a dead horse, here's a solution to do everything you want without worrying about a private boolean

Trigger:
	Double,Single any contact open ###Either contact opening will trigger the rule

Required Expression:
	Heater is on ###Make sure the heater is on to even warrant running the rule

Actions:
	Turn off heater ###Self explanatory; this will prevent the rule from running a second time
	Log: "Turning off garage heater" ###Self explanatory
	Wait for expression (double AND single closed) ###Wait for both contact sensors to be closed
	Log: "Turning on garage heater"###Self explanatory
	Turn on heater###Self explanatory

To answer this:

This depends on ordering of the rule actions. A required expression be evaluated every time an event the expression is based on occurs (@bertabcd1234 can correct me if I'm wrong here). So if your required expression is based on a contact sensor, then it will be evaluated every time the contact sensor state changes (open/close). Pretty simple there but is highlighted more if it's based on say a temp sensor where you're looking for a specific temperature (e.g., temp = 45). While evaluated as false, the rule actions are prevented from running completely.

So, if your actions are:

IF(Contact = Open)
	A bunch of stuff
END-IF

Then it's the equivalent of having a required expression of Contact = Open.

But, say your rule is

Log something
Turn off a switch
IF(Contact = Open)
	Stuff
END-IF

Then you'd still want the log to happen and switch to turn off when the rule is triggered, so making it a required expression wouldn't make sense.

2 Likes

That makes sense, it eliminates the need to use the Private Boolean.

I think this makes sense and is logically simpler. I didn't see the Wait action before reading your example. I'll give it a whirl.

Thanks for taking the time to explain!

2 Likes

You can use Wait for Event if both door are open.
Wait for event: Double, Single all contacts closed
The Wait will only be satisfied when both contacts are closed.

My preference is to use Wait for Events when both the Trigger and Wait are the same device(s). If not, I'll use Wait for Expression.

No it's not. The END REP separates the intended repeated events from everything that happens afterwards. Without the END REP, it will repeat the Log action everything else every 10 seconds, including the set private boolean true

I don't know why I'm having trouble distinguishing between Events and States/Conditions...

If the doors are in these states:
Double is open
Single is closed

And this occurs:
Double closes

Would 'Wait for event: Double, Single all contacts closed' be satisfied since there wasn't an event for Single close? Or, is the 'Wait for event' any event that causes 'Double, Single all contacts closed' to be evaluated/satisfied?

I think they were saying it would work but there's a better way to get the same behavior with a Wait so the WHILE 'loop' isn't necessary.

A simple example would be a door. A door has two states, it's either closed or opened. An event would be when you open the door and change the state from closed to opened. An event is instantaneous while a state can remain indefinitely.

In your example, when the Double closes (Single door already closed) the 'Wait for event: Double, Single all contacts closed" will be satisfied because the Wait will see that both the Double and Single contacts are now closed.

2 Likes