Multiple trigger rule question

Basically I am trying to do the following (I had this set up in WebCore in my SmartThings, but cannot figure it out here)....

If MyDevice is home
AND if time is after sunset but before sunrise (so night)
AND if tempSensor <= 69 degrees
TURN ON SWITCH

(Basically in a nut shell I have a smart plug with a little fireplace heater thing. And if it is night, and I am home, and my bedroom drops below a certain temp, it kicks on)

Bonus points ... I had it so that the outlet would ALWAYS shut off after 2 hours, period. This is in case the room doesn't heat up or the temp sensor stops reporting I don't want a heater running all night etc.

I can't for the life of me figure out how to automate all of this in HE. Had it working great in Webcore for ST

HE has webCore also...

The things that you have listed are states of being .. you are at home, it is night, it is chilly. States of being belong in conditions. That said you want the rule to become meaningful if any of those states of being change. So

Trigger: Your presence changes OR the sun rises OR the sun sets OR the temperature crosses the threshold in either direction.

Then within actions, conditionalize on all three of those things being true at once. If all true, turn heater on, else turn heater off.

Or use @bptworld's excellent Event Engine which enables AND logic triggers to be created.

The way RM works is the rule will not run if a trigger does not become changed. Not sure how the above mentioned Event Engine works. However RM triggers are things like:

Time becomes 11: PM
OR
Garage door becomes OPEN
OR
Humidity sensor becomes > 55%

In the actions section you add actions you want to occur and the conditions you wish them to occur under.
For Instance:

Trigger:
Garage door becomes OPEN

Action:
If (time between sunset and sunrise) then
Turn on all front lights
ENDIF

You need not use a condition if you don't need it:

Trigger:
Garage door becomes OPEN

Action:
Unlock Side Door

The hard part is probably going to be to decide what you want to set this rule into motion (Trigger). You could trigger off one of those things you list, or something completely different like a button or even something totally unrelated to this rule. Triggers don't get, nor do they need an "AND".

The logic is evaluated in the actions part of the rule, and it can have multiple conditions involved. What you have written is almost perfectly suited for the actions section of Rule Machine.

With that being said, I would think you want to trigger off temperature being less than or equal to 69 degrees. Here is what I think I would do if I were you. I added a second thing you didn't specifically ask for, a cutoff for high temperature, but I think I would include it as long as you are writing a rule.

Maybe there is a scenario I am not thinking of, and you probably are going to have to tweak it to your liking, but this should get you started.

Let's try this again, lol. This should work:

This rule will only run once every night and will shut-off after 2 hours. You could possible delete the first two triggers, it your temperature sensor is reporting frequently, but I would probably leave them in. Sunset only happens once a day so no big deal and the presence sensor you should change to "arrives" as opposed to "changed". Leaving the presence as a trigger is probably only required for rare circumstances, so you could also remove it all together.

The rule only runs when it meets all the conditions and one of the conditions is for a local variable I called "Only run once" to be true. As soon as the heater starts this variable is changed to false which prevents the rule from running again. The rule can only run again when the variable is changed back to true. In my rule above this happens after a 16 hour delay, but you probably want to change this to something lower, it really depends on your latitude and the months of the year you plan to use this automation (the length of your night). Just realize the rule can't run again till this variable flips back to true.

Also, wasn't sure if you wanted the heater to turn off if the temperature rises above 69 before the 2 hours is up. If this is the case just add an else-if (this would require the temperature trigger to be changed to "changed" as opposed to <=69.

If it was my rule, I would do the triggers differently. (I don't like rules being triggered frequently). I would simply have the rule trigger every half hour between sunset and sunrise and also trigger the instant I go to bed (I press a button when I go to bed and a whole host of automations run). It may sound like triggering every half hour is frequent, but think about how many times a temperature sensor might report temperature.

The flaw here is, for example, if the temperature drops to below the threshold for the first time just minutes before sunrise. Then the heater will continue running after sunrise.

As I said above, you need to trigger on and conditionalize on all three - presence, change in temperature, and time - for it to cover all the scenarios stated for both turning on and off. However, you can possibly simplify if you eliminate some of the eight scenarios presented by the three conditions. Also, a slightly different approach as @Stephan.J suggests in the last paragraph could be more practical than OP's initial thinking.

So I got this all set up in EventEngine. No clue if it is working since this is more of an "emergency situation" type thing that rarely happens (my normal HVAC keeps it warm enough)

Event Engine Cog - ver. 2.4.4

Conditions
***** Cog will fire when ALL Condition are true (Using AND)
- Sunset to Sunrise - Sunset Offset: NA, BeforeAfter: true - Sunrise Offset: NA, BeforeAfter: false - with Restriction: false
- By Presence Sensor: [SM-N986U] - PresentNotPresent: false, ANDOR: false
- By Temperature Setpoints: [Aeon Multisensor 6] - setpoint High: false NA, setpoint Low: true 68
- Rolling Average: false - Use Whole Numbers: false - ResetTime: NA

Actions
- Switches to turn On: [Fireplace]
- Delay: 500

I am glad you found a solution. There are a lot of great apps other than the ones that are native to Hubitat. Event Engine is one of those apps, if you are happy with it by all means use it.

Realize though that Rule Machine explicitly states what events will fire up and cause it to run. It may not do anything (if the conditions you define in your actions are not met), but it still fires up and checks those conditions. This is what a "trigger" is and ALL apps do this. In some apps this is not explicit, Event Engine is one of those apps, since the app allows you to put in "states" where you would normally have triggers (this was the way Rule Machine worked some time ago). You don't actually know when the app is loading up and running, it will do this even when the cog doesn't fire since its triggers are not "explicit".

Some users (myself included) would always do an automation like this in RM, since we want to define when the app fires up and uses hub resources. A RM trigger is exactly that, it should probably be called: "When any of these events take place, load up the app and run the code that was created by the parameters that are entered below". This is what is meant by the triggers being "explicit", you always know when the app is gonna load up and run the code (no automation may happen, if the conditions you entered aren't met, but the app still loads up and checks to see if this is the case). This is great for controlling the frequency of a RM app loading up and running, it is also great for troubleshooting, it has been argued that it is not so great for users that don't have a solid understanding of logic and it is not so great as a user interface.

Event Engine takes another route, its triggers are not explicit, and by explicit I mean: you don't explicitly define when the app runs and puts a processing load on your hub (again by "runs" I don't just mean when the automation runs (cog fires), by "runs" I mean when any part of the app runs, this could happen to determine if a "state" in the trigger is now true or false). There is nothing wrong with this route, and I applaud the creator of the app, I could never create something like this. This route is arguably more user friendly and a simpler way to create an automation, you just lose the explicit knowledge that RM triggers provide. It also requires "translation" to take place, home automation is "event" based, not "state" based. When you define your rule (cog) in terms of "states" their needs to be background translation taking place that determines if the events that home automation is based on, is changing the states that you define in the rule (cog). This, I believe, is somewhat of a minefield and I would imagine that an app like Event Engine has probably required two or three updates since it was released.

In the past, there has been a few debates about this and I don't want to restart any of them. Users should use whatever they are most comfortable with. What I like to use may be different from what you like to use. Rule Machine and Event Engine are both great apps. Just because I would always use RM (for reasons I mentioned above) does not mean everyone should. Some people will use Event Engine for the same automation and their reasons are no less valid than mine.

1 Like

Very well stated, @Stephan.J. I was close to starting an academic discussion in the lounge as to whether RM would be better if it didn't have the concept of triggers at all, but instead created implicit triggers for each device/sensor/etc. mentioned in any condition.

The home automation system I used for decades prior to SmartThings, then Hubitat, initially had the concept of a Scheduler, which ran through the event rules just as fast as it could, testing each one every cycle. That worked, but wasn't scalable. Then it introduced "Fast Events" which was a lot better, as those rules were tested only when the device/sensor changed state. This way of thinking makes a lot more sense.

Would RM be easier to understand if it just implicitly created its triggers? Yes. But I like the power of taking out one (or more, if "any of" logic) and help the rule out by specifying that there's no point thinking about the inside of the rule if none of these things have changed state. Where there are multiple triggers OR'ed, the rule may benefit by using the one that has the least volatility, or the lesser duration of state.

Food for thought: Maybe trigger should be the last thing that you think about when creating a rule. Write the rule with conditions. Now examine those conditions and then decide what an effective trigger would be,

OK so this could explain why my garage door thing I created did not work, and most likely the fireplace thing (original question here) will end up not working too.

The confusion is .... how do I get my automations to just "run" periodically to check things.

So for example I wanted a garage thing that notified me if I left the garage door open....
Event Engine Cog - ver. 2.4.4

Conditions
***** Cog will fire when ALL Condition are true (Using AND)
- By Garage Door: [Garage Door] - ClosedOpen: true, ANDOR: false
- By Presence Sensor: [SM-N986U] - PresentNotPresent: true, ANDOR: false

Actions
- Delay: 100

Notifications
- Send Push: [SM-N986U]
- Message: %whoHappened% is detected as %whatHappened%

I tried that today and it did not work. I was gone for hours today and purposely left it open (I have family in town they were still home) to see if it would alert me and it did not. I am going to assume that my "app" never ran to check if I was out of the presence radius and if the door was open.

So I am assuming the same thing is going to happen with the fireplace. I wanted it to see if I was home, if it was night, and if the room was too cold. But according to what I am gathering from your reply here, that routine is never going to 'just run' and check on those parameters?

So I have not done a single thing in rule machine yet. It is pretty confusing. So does it have ways to force things to periodically fire off? Maybe I set those two routines I described to like run every 5 min or so? The fireplace one could run every 15 for all I care. The garage door more frequently since that can be sort of an emergency type situation I would want to remedy quickly.

So I tried my hand at creating this in RM .... Will this work?

Yes, I hear you, it gets easier with time. You will probably pick it up faster than I did.
One thing that helped me with RM, was to write down the rules on a piece of paper before using the HE interface and instead of the word trigger, I would write down: When any of these events take place, load up the app and run the code that was created by the parameters entered in the actions section below. Home automation (not just HE), is event based. An event has to happen for an automation to run (when the event happens or at some time thereafter). So if you garage door should always be closed 15 minutes after it is opened. Then your trigger is simply the garage door has been opened. Have the first action to be wait 15 minutes and then check to see if the garage door is closed, if it is not then do this.....

Not sure if that meets your needs and you may want to figure how to put in the conditions when you want the garage door to stay open, but it is a start.

That will work, but that will turn your fireplace on and there is nothing in your rule to shut it back off. Realize too that the rule only runs when the temperature sensor reports below 69, but how often a temperature sensor reports is variable. I would go with the rule I posted above, possible with some modifications. Do you want the heater to shut-off once the temperature rises above 69 or do you want it to simply run for 2 hours (only once) and then shut-off? If the heater comes on 5 minutes before sunrise, do you want it to run for the full two hours or do you want it to shut-off at sunrise? Do you want to continue checking for presence after sunset? By this I mean if you are not home at sunset you don't want the heater to run, but if you arrive home at midnight and the other conditions are met then you want it to turn on.

As you can see, it is difficult for me to write the rule for exactly what you want, unless I know exactly what you want. I am at work at the moment, but when I get home tonight, I could provide another example of how I would make the rule, if you answer the questions above.

I have an "AutoOff" app tied to the fireplace so that it always turns off after 90 minutes.

But here is what I was trying for ....

If temp drops below or equal to 69.0
AND IF my phone is detected as present
AND IF it is between sunset and sunrise
THEN
TURN ON fireplace

Then I could do another rule ....
IF temp is above or equal to 73
AND IF fireplace switch status is ON
THEN
TURN OFF fireplace

Is it O.K. if your fireplace is turned on 5 minutes before sunrise? If so, do you want it to turn off at sunrise, or continue running till the 90 minutes is over?

You can do it all in one rule, no need to make two rules.

You could also do the "off in 90 minutes" in the rule, this is the best way if you only want the rule to turn on once per night. How many times do you want the rule to possibly run in the course of one night, only once, twice, three times?
What is the temperature sensor you are using? How often is it set to report temperature? What is the required change in temperature required for the sensor to report?

Devices like temperature and humidity (as opposed to devices like switches and motion), can be a little trickier to work with. A switch is either on/off, a motion sensor is either motion/no motion, but temperature and humidity are always changing. For example this past instant it was 22.1236548 degrees Celsius in the room I am sitting in. One second later it was 22.1236599 degrees Celsius. Obviously, my HE temperature sensor didn't report this change (it's too small). But since temperature by definition is always changing (not like a switch), how often it reports, and the change required to send a report is often a setting made by the user. The same goes for humidity. When you use a temperature and/or humidity sensor as a trigger it is good to know how often it reports a change, as every report will cause the rule to run and check the conditions.

Some users don't consider this tricky at all, if your not worried about automation efficiency you don't need to consider this. Have RM or EE load up and run every 30 seconds when a new temperature is reported, no big deal. But a lot of other users like to consider how often the automation they create is required to be analyzed by Hubitat's processor. This is where RM shines, because this is by design "explicit", you define it in the trigger section of the rule.

Having said this, every time a device reports a new event, some processing goes on with the hub. I imagine (although I don't know) that it is simply updating a table of states and/or last reported values for each device. Although this requires processing power on the part of the hub, it would be less than having RM or EE load up and check to see if it should execute an automation.

It can turn on anytime. The only reason I do sunset to sunrise is because it is in the master bedroom so we don't really need it happening during the day when we are not in there

I don't mind if it runs the full 90 minutes. I'd rather it do a run until temp is >= 73 or it has been 90 minutes (so basically turn off at 73 or just turn off after 90 minutes if it doesn't reach 73)

And I'd want this to run as many times as is reasonable per night. It is very rare it dips below 69 in our room. But who knows when that would be or if it would happen more than once. But I would want this to fire up anytime it drops below 69

We use an Aeon Multisensor 6 not sure on how often it reports or does things. I honestly don't need HE checking the temp for this rule but maybe like every 15 min or so. Looking through my logs it looks like my sensor reports every minute?

Yes, it look like your sensor is reporting every minute. Based on this, I would not use temperature reporting as a trigger. You could and some people do, but I wouldn't want my RM app to load up and check conditions this frequently. For this automation you simply don't need to, you can write it differently with a lot less frequent running of the RM app and have no noticeable difference in how you perceive the automation to work. This is how I would write the rule:


Note the rule runs once every 20 minutes (72 times a day), this is less than every minute (1440 times a day). Also if its daytime the rule exits right away resulting in very little processing load. The heater will not turn on the instant it is sunset, since the rule only triggers every 20 minutes, but you are (on average) only going to be 10 minutes off and who would actually notice that in day to day life. I don't know my precise sunset time today.
Also, notice the rule fires every 20 minutes at nighttime, so lets say two of those times happen to be 1:00am and 1:20am. If the temperature at 1:00 am is 72.5 degrees, and the temperature at 1:10 am is 73 degrees, and the temperature at 1:20 am is 73.5 degrees. The rule won't execute at 1:10 am when it is 73 degrees and shut off the heater, rather it will execute at 1:20 am when it triggers and the temperature is 73.5 degrees, at this point the heater will shut-off. In the real world you would never notice this, so who cares.

This rule is actually a great example of why myself and many other people love Rule Machine. In RM you explicitly state when you want the rule to run and check your actions (this is what is meant by "triggers"). Below is another way you could achieve your desired result:


Notice in this rule the trigger is temperature reporting has changed, with your temperature sensor this is looking like it is happening every minute, so this rule would run and check its actions 1440 times a day. Would it work, I am sure it would, but you don't need to be loading an app up every 1 minute to check for conditions considering the automation you are trying to create. This is the beauty of Rule Machine, since its triggers are all events that can only be joined by "or", you can control the efficiency of the automation.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.