Question re: ELSE event not triggering

🛎️ Get Help
3

The problem is that your trigger is the sensor value becoming greater than 102. This is the only event that will make your actions run. (The only triggers in RM are ones you specify. If you're coming from ST/webCoRE, there are no "if"s that create triggers/event subscriptions for you.) This means the condition you're testing in your ELSE will never be true, so that part of the actions will never run.

One ways to fix this is to change the trigger to "changed" instead of "> 102." However, this will create a notification every time it changes and is above 102, so you'll likely want a way to filter that noise out. One way is to add a test for the current fan switch state and only send the message if it's different (probably easier to do this before you change it). Likewise for turning it off.

4

I would add a second trigger event:
Temperature of Attic () becomes < 97.0

I used 97 as an example to put some dead band in the system. That should prevent the fan from turning on and off many times if the temp is bouncing around 102.

1 Like
5

Does this mean that if the “else” statement was changed to “else-if” then that would fix it because the “else-if” would be another expressly defined event subscription?

I think I’m still wrapping my head around an event driven logic.

Good idea re: dead space I’ll do that.

6

No.... Simply remember:

TRIGGER = WHEN the rule will run
ACTION = WHAT the rule will do when it runs

If you want the rule to run at some point when <102F (to turn off the fan), you need a TRIGGER that will tell the rule to run at that condition. Otherwise the code will never run/be evaluated below 102F (as there is no TRIGGER to make it do so)...

Your IF-ELSE is fine the way it is.

Think of it in plain English first -

  1. WHEN temp >102, WHAT I want to do is turn ON the fan.
  2. WHEN temp <96, WHAT I want to do is turn OFF the fan.

Based on that, it is obvious you need 2 triggers (as there are 2 WHENs), and 2 actions (as there are 2 WHATs).

For the actions you can make 2 IFs, 1 for each action, or when they are related to each other as in this case an IF-ELSE or IF-ELSE IF can work. But it is still technically 2 actions either way.

7

Couldn't you simplify it by just triggering on Temperature becomes > 102 and on True turn on the fan and notify and on false turn off the fan and notify and skip the if else statement altogether. I believe it would only turn on and notify when it crosses the 102 threshold and then turn off and notify when it drops below again. I know there are times the if else are needed but it doesn't seem like they are in this case.

8

No, there is no RULE true/false any more in RM 4.0... So that wouldn't work. (that would work in RM 3.0 though).

In RM 4.0 there are just TRIGGERS that say when to run the action code. So in your post, in RM 4.0 it would run once when temp > 102, and never again until the temp goes <102 and back >102 again - as that is the only trigger specified.

Remember in Rule 4.0 - there is no overall rule true/false concept any more. For each time you want it to run, you need a TRIGGER (except in cases of repeat, delay, wait - but that is another topic altogether, and not applicable to this example).

1 Like
9

If it helps, I have a similar type of rule set up for one of our upstairs bedroom ceiling fans. In my case I have it turn on when the bedroom temperature is greater than the main floor thermostat by a certain amount. Otherwise it turns off. A couple of things I added are:

  • A delayed cancellation. This prevents the fan from turning on/off multiple times in a short time due to small temperature fluctuations.

  • A Private Boolean variable that sets to false once the fan turns on and true when it's turned off. Per notes from the RM4.0 release, this prevents the turn on event from firing over and over again. Probably not a huge issue but I added it nonetheless.

image
image.png899Ă—335 17.9 KB

10

No, there are no event subscriptions in Rule Machine except for what you define as triggers. (That's actually a bit of a lie since there are effectively subscriptions or schedules created for certain rule actions like "Wait for...," but I'm talking about things that force your rule actions to run anew. Conditionals in RM do not create subscriptions; you need triggers, which in RM are explicitly defined.)

If you haven't read the Rule 4.0 docs yet, I'd suggest taking a look. (There is a bit about Rule Machine history in there and some assumption you knew Rule 3.0, but you can ignore the history lesson and just see how things work in the current version.)

11

Unless the temp is changing every second, probably not really needed. That said, I do that a lot too because I think it is more technically correct and it is easy to do. :+1:

EDIT: Of course the way you are doing it, it WILL repeatedly send an OFF command to the fan... The most technically correct way to do it is nested IF - check temp first then private boolean, since each temperature state has 2 different actions depending on the private boolean value.

12

Yeah I'm okay with it repeatedly sending an off command to make sure it turns off.

My main concern was it turning on/off many times in a short period. I had an older rule with my thermostat that didn't allow for small fluctuations and started changing modes constantly. I then added more conditions with ranges of temperatures between modes and cancellation delays. This stopped the 'flickering' modes. :blush:

13

OK, you know your logic better than I do.

I'll just point out that if someone can turn the fan ON manually, that code will turn it back off again if the temp is lower than the rule condition. I don't like automations overriding manual control, which is why I point that out.

It might be totally fine for how you use it, though.

14

Oh man...
any idea of the logic on how you would implement this sort of hot attic fan concept, but then also have some sort of override which you could trigger by hitting the physical switch button (while you were in the attic) that could get it to run (let’s say for an hour or two) despite the then current temp being below the “hot attic” threshold?

15

If you want it turn run for a minimum time after turning it on via automation or manually, you could make the cancel longer, perhaps 1 or 2 hours. I do this for my roof deicing system. It won't turn off at least 6 hours after turned on for any reason. This ensures any snow has melted completely.

16

Excellent point. In my case this rule is for my kids' bedrooms. They're more likely to complain than just turn on the fan themselves, so the automation is for my benefit as much as theirs! :laughing:

1 Like
17

Depends on how fool proof you want it to be.

There are a lot of ways to do it, none more right/wrong than the other.

Assuming you have a smart switch on the fan that reports physical on/off events separately from digital on/off events, I would do it as 2 rules + a global variable.

Rule 1 - Manual control
Triggers: Fan switch ON (physical), Fan switch OFF (physical or digital)
Action for ON: Set Global Variable to "manual"
Action for OFF: Set Global Variable to "none"

Rule 2 - Automatic control
Triggers: Temp>102, Temp<96
Action for hot: If temp>102 AND global variable = "none", set global variable to "auto", turn on fan
Action for cold: If temp<96 AND global variable = "auto", set global variable to "none", turn off fan

If your switch doesn't distinguish from physical and digital events, then you would need to be a little more careful on the logic - just use all on events in rule 1, and use global variable="none" as an ON condition. Then make sure there is a delay between setting the global variable and turning on the fan in rule #2. Like this:

Rule 1 - Manual control
Triggers: Fan switch ON, Fan switch OFF
Action for ON: IF global variable="none", Set Global Variable to "manual"
Action for OFF: Set Global Variable to "none"

Rule 2 - Automatic control
Triggers: Temp>102, Temp<96
Action for hot: If temp>102 AND global variable = "none", set global variable to "auto", delay 5 seconds (to make sure global variable gets updated before rule 1 sees the ON event), turn on fan
Action for cold: If temp<96 AND global variable = "auto", set global variable to "none", turn off fan

Technically that makes the global variable get set to "none" 2x every time the fan is turned off, but I don't see that as a big deal. If you are OCD and don't like that, add a IF global variable <> "none" on the Rule 1 OFF action.

18

Someone once told me there was no cost to rules. I just took the simplest approach (for my mind) and made two rules. One turns the fan on, one turns the fan off. Under the earlier version of RM this was one rule.

On:

image
image.png876Ă—530 19.2 KB

Off:

image
image.png882Ă—524 19.6 KB

19 
Trigger Event:  Temperature of Attic Sensor *changed*
Actions:
   IF (Temperature of Attic Sensor >= 100.0) On: Attic Fan
   IF (Temperature of Attic Sensor < 100.0) Off: Attic Fan

or

Trigger Event:  Temperature of Attic Sensor *changed*
Actions:
   IF (Temperature of Attic Sensor >= 100.0) THEN
      On: Attic Fan
   ELSE
      Off: Attic Fan
   END-IF

Two ways to do the same automation in a single rule.

20

Thanks!

21

@bravenel, is that not triggering the rule every time there's a tenth-of-a-degree temp change, even if the temp's nowhere near the 100.0 "care-about" point? Is that not a great deal of unnecessary processor power, as opposed to two rules? Or, does that not actually matter, to any significant degree?

(pun intended)

22

It's going to be triggered either way on every temperature event. How else could it check the value relative to 100? Those comparisons don't just happen magically, or in the device -- but in RM. Irrespective, if you look at your logs you'll see that the temperature isn't reported all that often anyway.