I have rules that appear not to fire but perhaps my understanding of the conditions for firing are wrong.
These ones I think are obvious (but maybe I’m wrong):
Motion sensor - fires immediately on activity
Open\Close sensor, button or switch - fires immediately the state changes
But what about these?
3) Temperature Sensor - Does the rule fire each time the temp sensor reports the temperature (5 minutes). Or does it report every 5 minutes AND whenever the temperature value changes.
4) Do the same rules governing temp sensors apply to thermostat.
5) Smart Weather Station - Do rules fire when a particular data point changes or are these polled at a predetermined frequency?
6) What about a Rule where the Event Trigger is always True. For example a motion sensor that is always Inactive (in a drawer or dead battery) or a thermostat temperature that is less than 100. Do they fire every second, every minute, every 5 minutes?
Is there a resource that would answer these kinds of questions. Without knowing when Rules SHOULD fire it becomes even more difficult to troubleshoot.
I will file a bug report for the specific Rule issue I have but I think this would be a useful topic for people to understand more fully.
As shown in the screenshot above, Triggers can either be Event based or Time based - either way, those are instantaneous events that cause the trigger to be evaluated. If the trigger condition is met, the rule is run.
Note that Event Triggers are always OR’ed together. Meaning that when any of the triggers become active, the rule will be run.
Event Triggers
Event based triggers include the following options:
As you might infer from the name, these type of triggers occur based on events in the home. With events being the instantaneous moment that the state of the thing, mode, or alarm status changes to meet the specified condition. (This is different than If Conditions that we’ll talk about later that are based on checking what the current state is)
Device
When you select a Device based trigger, you’ll then be prompted to select the Device, Attribute, Operator, and Value.
These are evaluated anytime an event is reported from your hub to SharpTools
For most devices, this is anytime the attribute value changes - whether that Thing’s attributes update only based on events from the physical device or whether it polls the physical device for changes
These are triggered as soon as the attribute state changes to meet the condition you specify
For Example:
‘Motion is active’ - as soon as the motion changes from inactive to active, the rule is triggered
‘Temperature > 70’ - each time the temperature changes, the trigger is evaluated and if it’s above 70, the rule will then run. eg. 69=false → 70=false → 71=true → 72=true → 71=true → 70=false; So each time the temperature is reported and it’s above
Also keep in mind that you can set up two triggers for an attribute with exactly opposite conditions to trigger anytime the Thing’s attribute state changes
For example, setting up triggers with ‘Motion is active’ and ‘Motion is not active’ will cause the rule to trigger anytime the motion status changes
You typically will want to use this along with a condition inside the flow
Routine
These are triggered whenever a SmartThings Classic ‘Routine’ is executed.
As soon as the selected routine is executed, an event is sent to SharpTools and this is considered triggered
Mode
Whenever the SmartThings or Hubitat location’s mode changes to your desired mode, this will trigger.
SHM - Smart Home Monitor (SmartThings Classic)
Whenever the Smart Home Monitor state changes to your desired status, this will trigger
HSM - Hubitat Safety Monitor (Hubitat)
Whenever the Hubitat Safety Monitor state changes to your desired status, this will trigger
Time Triggers
Similar to Event triggers, Time Schedule triggers are instantaneous events that trigger a rule.
When the time ticks over to your configured time schedule, the rule will run.
Timer
When the time changes to the specific time, run the rule
Also has options for repeating on a daily basis, only on certain days, or one time (‘none’ repetition setting)
Note that these require that your approximate geo coordinates are set for your location, so the system can figure out your timezone.
Sunrise
When sunrise occurs at your location, run the rule
You can optionally specify an offset before or after sunrise - for example, 30 minutes before sunrise
Note that these require that your approximate geo coordinates are set for your location, so the system can determine the sunrise and sunset for your location
Sunset
When sunset occurs at your location, run the rule
You can optionally specify an offset before or after sunset - for example, 30 minutes before sunset
Note that these require that your approximate geo coordinates are set for your location, so the system can determine the sunrise and sunset for your location
Once a rule is triggered, the Flow is evaluated / executed.
So back to your specific questions:
Motion sensor - fires immediately on activity
The trigger condition is evaluated anytime the attribute value changes and if the trigger condition is met, the rule is triggered and run.
Keep in mind that some motion sensors have multiple attributes, so if you have something like ‘Kitchen Motion Sensor - motion is active’ as the trigger, the trigger will only be evaluated when the motion attribute changes and will only trigger the rule to run when the value specifically changes to ‘active’
Open\Close sensor, button or switch - fires immediately the state changes
Same comments as motion sensor.
Temperature Sensor - Does the rule fire each time the temp sensor reports the temperature (5 minutes). Or does it report every 5 minutes AND whenever the temperature value changes.
The trigger is evaluated each time the temperature sensor changes and triggers the rule every time if the condition is met. (See example in ‘Devices’ above)
Do the same rules governing temp sensors apply to thermostat.
Yes, anytime the attributes of a thermostat changes, the trigger is evaluated and if the trigger condition is met, the rule is triggered and run.
Smart Weather Station - Do rules fire when a particular data point changes or are these polled at a predetermined frequency?
The trigger is evaluated anytime the device reports an event and the rule is run if the trigger conditions are met.
There is no periodic polling done from the rules at all - it’s always event driven based on the events that the device driver reports.
What about a Rule where the Event Trigger is always True. For example a motion sensor that is always Inactive (in a drawer or dead battery) or a thermostat temperature that is less than 100. Do they fire every second, every minute, every 5 minutes?
They fire one time when the event is received. So if the motion sensor was already ‘inactive’ in the drawer when the rule is setup, the rule will not trigger until the motion sensor becomes inactive.
Thanks Josh, that is a great set of explanations. The key message is that all rules are event driven.
I do have one clarification. In the case of temperature it has a checkInterval of 720 (seconds I presume)
So if the temp remained constant at 70, an event where “Temperature=70” would be expected to fire every 720 seconds (because the hub has received an update even though the temperature remains the same) or only on the first instance of changing to 70?
It depends on the device handler, but events are generally only generated when the attribute value changes unless the device handler has specifically be coded to force report state changes each time.
That being said, if multiple forced temperature=70 events kept coming in, the trigger would be evaluated each time and the rule would run each time.
–
Note that Zigbee and Z-wave temperature sensors report back on their own whenever temperature values change. Sensors, especially battery powered ones, are inherently event driven.
Regarding the checkInterval, this is part of the new SmartThings Device Health feature. If the device has the Health Check capability, the Device Health feature uses the checkInterval to determine the maximum amount of time a device should go without reporting events.
If the device hasn’t reported any events within that time period, Device Health will try to ping that device and if it still doesn’t generate any events, then SmartThings marks it as offline.
Hi @Ezra_Goldberg, welcome to the community. You can add an If_condition as the first activity in the flow to determine if the flow should take any actions or just ends without doing anything. Ex: send notification when motion is triggered and I am not at home can be done by having the motion as trigger, and check my presence in If_condition (or more conditions here), and send notification when the condition(s) is met.
If I have a HERO TILE with temperature showing, and I want that tile to turn to the “Active” color if the temperature is outside the range I have set in a rule, how can I 'Activate" the tile? so it shows in color on the dashboard? For example, i have a freezer set with <= -10 or >= 0, with a rule to send an SMS if it activates. How can I ALSO make the tile turn to the active color on the dashboard?
Can you tell me more about the temperature device? We don’t currently support setting a temperature threshold for active colors in the Tile itself, but we’ve noted the feedback.
In the meantime, it might be possible by using a custom device handler. If the device could report temperature and another supported virtual capability (like a Switch)… then you could send a command to flip that virtual capability active or inactive accordingly.
Yes, regarding the feature request, temperature is temperature.
The reason I asked what type of device handler is being used was related to the second part of my comment around alternative approaches to achieve a custom active/inactive color highlighting (using a custom device handler as to set a custom active/inactive state).
Since the Hero Attribute tile allows you to specify which attribute you want to display as the Primary Attribute and a separate attribute to use for the Active Color, some people have used this in creative ways:
In the screenshot above, a custom ‘SHM Mapper’ device handler is being used which reports the current Smart Home Monitor state in an attribute called shmState and also maps the active/inactive state to a switch attribute.
This custom device handler let the user display whatever value they wanted to in the tile while also using external logic to separately flip the switch attribute on/off however they wanted to. The same concept could apply to temperature with a custom device - copy the temperature over to the custom device and then have a separate ‘switch’ on the device that you could flip on/off
For example, here’s a custom ‘Virtual Values’ device that lets you independently set a text, number, and switch value. In the GIF below, you’ll see that it’s used to independently set the numeric value and switch value.
I am new to Sharp Tools. This is probably a very simple topic but I’m a little hazy. I have a number of (automations/routines?) that wait for no motion for 10 - 20 minutes in a room and then shuts the lights and fans. The trigger event for my office is:
Office Motion - motion stays ‘inactive’ for 15 minutes
I find in order to trigger I have to have a physical event, such as motion sensor active. If I don’t then the trigger never occurs. My question is what causes non motion to be evaluated as a trigger.
It has to change from something other than inactive to inactive and then stay that way for 15 minutes.
In the case of a motion sensor, the only other value is active. So the sensor has to become active, then change to inactive and stay inactive for your specified duration. If it becomes active again during your specified duration, then the state stays timer is reset and starts over when the device becomes inactive again.
Thanks Josh, that makes sense. Normally when someone enters the room the motion sensor would change from inactive to active and back. However, there are times when the motion sensor doesn’t register after a light turns on, (via the dashboard or pushing a switch before tripping the motion sensor).
I’m guessing the solution to this issue is to provide an artificial trigger of some sort.
Hi @Marc_Orlick, yes, many motion sensors have “cool down” period that prevents another motion event from being reported during that short period. So if the motion sensor was tripped by the light turning on, it may not report another motion event if a person walks in shortly, and the cool down period varies among different sensors.
