Rules for a window A/C

💡 Lighting
1

I made a simple rule to control a window a/c that uses an IR remote. The z-wave switch in this case is a ZXT-120, which can send simple on/off commands that are mapped to my A/C remote's power toggle button.

image
image757×783 36.5 KB

The IR code to the A/C is the same for on and off, so it can be easy to get out of sync. I want to create one or two other rules, with other temperature setpoints. But I can't see a way to enable/disable rules in a way that would transition between setpoints without extra on/off commands being sent to the A/C.

For example, if it's 78 degrees, this rule becomes true and turns on the A/C. But let's say right now I want the A/C to stay on until it's 75 degrees (not 77 degrees as the rule is written). Is there a way to create another rule like this one that I can enable with, say a button press, while also disabling this one?

2

Yes. What you can use is called Private Boolean. It is a flag that each rule possesses. The rule can set it to true or false, and the rule can be disabled if it's false. Other rules can set it also. So you could have the rule that responded to the button press flip the Private Boolean of your 77-off rule to false, and flip the Private Boolean of the 75-off rule to true. First one disabled, second one enabled. Presumably you'd have some method to revert.

Sometimes the reversion can be handled by the second rule. In your case, you could revert in the 75-off rule false part, where it is turning off the AC, making itself disabled and the 77-off rule enabled. That might make sense, as you've just cooled things way down. Play with it, you'll see alternatives as well.

3

Thanks. I was thinking that private boolean is the way to link two rules like what I'm describing.

But I want to make sure I'm clear on one thing.

Let's say the setpoint 77 rule is true and the a/c is turned on. Then I use my button-press rule to flip setpoint 77 PB to false and setpoint 75 PB to true.

Once the setpoint 75 rule becomes enabled by PB, does it evaluate it's own truth? If so, it would send another "on" action (which would actually turn my A/C off).

4

Not as long as PB is not in a condition (which it could be). Instead, if you use it in a Restriction, no the rule is not evaluated by setting it.

5

Am I able to create a trigger that sets PB of one rule to false, and another rule to true?

It seems like I have the option to set only true or false for other rules, but not mix and match.

6

Argh, you are right. Create a separate Action in RM, and then run that Action from the rule. It can do the opposite PB set. Will look at adding ability to set both ways in that action, instead of just one.

7

Thanks, been messing around with this. I'm also trying out switches to enable/disable rules.

When a rule is disabled by a switch being off, or by PB being set to false, does it continue to update itself on whether it is true or false? Obviously the actions don't execute when disabled. But I think it doesn't even evaluate it's own truth while disabled as well. Is that correct?

In other words, if the rule was false when its PB was set to false, the conditions for the rule could change several times, but the rule would not know that until it's PB is set back to true and then the conditions change again after PB is true.

I think this is causing a problem I'm noticing when switching between these temperature setpoints, but wanted to make sure I'm correctly interpreting how the rules are evaluating themselves.

8

This is correct. If a Restriction is in place, none of the events of a rule are even looked at, it is not evaluated, and nothing happens to its rule-truth state.

9

What about if another rule runs an action to evaluate the rule that currently is disabled by switch and/or private Boolean? Or update rule? Not sure how that’s different from evaluate rule.

I think I’m trying to figure out a way to keep rule truth evaluations up to date even while some rules are disabled so their actions do not occur. If that makes sense.

10

Restrictions stop everything about a rule from happening.

So, what you could do is to split the actions off into their own Actions. Then you run those Actions from your main rule, the one you want to keep rule-truth going with. If you don't want the Actions to happen, then you can restrict it with Private Boolean. So when the main rule evaluates (no longer restricted) it updates its rule truth, attempts to run those Actions, but they don't run when restricted.

Splitting off the actions like this gives you more refinement over how things happen.

11

Thanks, this might be what I'm looking for.

This whole setup is quickly becoming a bit much for my non-developer brain to keep a grasp on.

I ended up creating two rules each for three temperature "modes."

For each mode, I needed a separate temperature setpoint for on and off, I found that one rule with actions to turn the a/c on/off based on true/false for one temperature setpoint resulted in the a/c compressor cycling on/off too quickly.

Each rule that causes the a/c to turn on or off has a switch and PB controlling it. Here are screen shots of the two rules for one of my temperature modes.

Turn a/c on

image
image753×1073 29.7 KB

Turn a/c off

image
image747×1077 31.5 KB

The disable with switch allows me to use dashboard switches to change between these temperature modes, I have simple lighting automations that toggle one mode on and the other two off.

My reasoning for adding the enable/disable by PB was based on the idea that once an "on" rule runs, it shouldn't run again until an "off" rule has run.

I have two other pairs of rules for the other two temperature modes, but they're basically identical to the screenshots I posted above.

As long as I stay in one temperature mode, it all seems to work fine. Where I've been getting into trouble is when switching between temperature modes.

I was finding that rules were executing at unexpected times, and I believe it's because they essentially "missed" an event that would have updated truth state while disabled. With a subsequent event that caused rule truth to be evaluated, a now-active rule ends up running and causing the a/c to get out of sync from what I intended (recall that the a/c has only a single IR code for on and off).

I appreciate your assistance with this, since I'm very much not used to thinking this way.

Does what I've posted so far make sense? Any thoughts on continuing down this route vs. starting over from scratch with a different paradigm?

12

You should see events in the Live Log. If there was something to "fix" you'd see it there first.

Here's an example:
app:393 2018-07-14 11:55:00.133:info Periodic POLL of certain devices (51) Triggered
app:393 2018-07-14 11:54:51.125:info Periodic POLL of certain devices (51) Triggered

I have a Rule that is set to Run on the 51st second of every minute. As the logs show, it runs on the 51st AND on :00

That would be a Rule that needed fixing (if it "hurt" - while in this case it's merely "chatty".) [I sent a Support email about this.. so I'll wait for professionals to fix it :slight_smile: ]

13

thanks, ill give you an example of why i added the PB restriction.

Temperature becomes 77.0 degrees (from some value less than that), rule to turn on a/c becomes true, a/c turns on.

Next update from temp sensor is 76.9 degrees, rule becomes false, nothing happens since there are no actions to run on false.

Next update from temp sensor is 77.0 degrees again, rule becomes true again, and it sends "a/c on" command.

That's a problem, because in reality it would've just turned the a/c off, since the a/c can't distinguish on from off commands.

Edit: admittedly, this doesn't happen very often, it just occurred to me that it's possible and I was trying to come up with a way to make sure that an "a/c on" rule only runs once and can't run again til an "a/c off" rule has run in the meantime.

14

Ahhh.. you're trying to create a "flip-flop" or latching because the a/c simply toggles. Every "push of the button" = a change in state, not an explicit state.

You've got a hysteresis in there, the diff between =76 and >=77 on one degree. Thus the temp must climb a whole degree (or fall) to change state. Here's hoping your temp sensor has less jitter than that. :slight_smile:

15

Correct. The z-wave device is capable of sending discrete on/off commands, but both commands are mapped to the same IR code for the a/c since it only does power toggle.

That’s whats making this particularly tricky for me, an errant on/off command totally messes things up, which wouldn’t be the case if the a/c was capable of ignoring an on command if already on, or vice versa for off.

16

Any chance you could add some sort of power monitoring on the mains to know whether or not the unit is on? With that bit of information in Hubitat, you could always toggle the AC power correctly.

I do something similar for know if my washer and dryer are running or not, in order to notify use when a laundry cycle is complete.

1 Like
17

Yeah that’s a good idea and I’ve actually been considering that. It would probably simplify things quite a bit. I don’t have a smart plug that could reliably handle the current draw of a decent sized window a/c like this one. I think zoos makes a pretty heavy duty appliance plug that would do ok so I’m considering getting one of those.

For now, I might try something similar with a spare ST multipurpose sensor I have lying around.

1 Like
18

Under the cover, inside the a/c the mains power is separated and a power monitor would provide the feedback. If it's old like mine, it rattles enough that a simpler vibration sensor would work at half the price :slight_smile:

AeonLabs-%20ZW095_1

1 Like
19

Adding the vibration sensor made it a lot easier to create a few rules for different temperature setpoints while restricting actions so that an on/off command doesn't get sent when the A/C is already in the same state.

Now I have just one rule that's an "on" action, and one rule that's an "off" action, each is restricted by a virtual switch that is tied by another rule to the vibration sensor being active or inactive. I wanted there to be a small lag so that a momentary glitch in the vibration sensor's active/inactive status doesn't get misinterpreted as a change in the A/C's actual power state.

The rule that links the virtual switch to the vibration sensor is this one:

image
image.png758×666 36.2 KB

@bravenel Is there any way to do an on or off pending cancellation for less than one minute?

20

Yes there is. Use Delay these actions instead of the delayed on/off pending cancellation. That gives you the option of seconds, and the option to cancel on truth change. Then you'd just use On and Off as the actions.

2 Likes