Hello all - I’m trying to automate an HVAC unit to turn off when there is no motion for a preset amount of time. In some original testing where I had one sensor, the behavior is as expected, and in another instance where I have multiple sensors and set the timeout to be very short, it also works appropriately. But once I set the timeout to 1 hour and have multiple sensors, the rule isn’t triggering, it seems to think that the condition that all sensors are motionless for 1 hour is not true. Any advice on how to fix this?
I grabbed the log, here is the testing of the If conditions for a time it did not trigger, but I knew from manually accessing the sensors that the motion was inactive for the 1 hour (I blanked out the location and device IDs). Note I made a small change versus the above; I split the two sensors out and had them as two separate tests in the “if” statement:
[
{
“type”: “state”,
“subtype”: “device”,
“data”: {
“platform”: “samsung-smartthings”,
“locationId”: " ",
“deviceId”: " ",
“attribute”: “motion”,
“state”: {
“attribute”: “motion”,
“value”: “inactive”,
“timestamp”: “2024-09-23T17:27:17.000Z”,
“isStateChange”: null
}
}
},
{
“type”: “state”,
“subtype”: “device”,
“data”: {
“platform”: “samsung-smartthings”,
“locationId”: " ",
“deviceId”: " ",
“attribute”: “thermostatMode”,
“state”: {
“attribute”: “thermostatMode”,
“value”: “auto”,
“timestamp”: “2024-09-23T09:41:23.970Z”,
“isStateChange”: null
}
}
},
{
“type”: “state”,
“subtype”: “time”,
“data”: {
“localTime”: “2024-09-23T14:27:18-04:00”,
“timezoneId”: “America/New_York”
}
},
{
“type”: “state”,
“subtype”: “device”,
“data”: {
“platform”: “samsung-smartthings”,
“locationId”: " ",
“deviceId”: " ",
“attribute”: “motion”,
“state”: {
“attribute”: “motion”,
“value”: “inactive”,
“timestamp”: “2024-09-23T18:15:21.000Z”,
“isStateChange”: null
}
}
}
]
Here is a time that it did work.
[
{
“type”: “state”,
“subtype”: “device”,
“data”: {
“platform”: “samsung-smartthings”,
“locationId”: " ",
“deviceId”: " ",
“attribute”: “motion”,
“state”: {
“attribute”: “motion”,
“value”: “inactive”,
“timestamp”: “2024-09-23T19:58:04.000Z”,
“isStateChange”: null
}
}
},
{
“type”: “state”,
“subtype”: “device”,
“data”: {
“platform”: “samsung-smartthings”,
“locationId”: " ",
“deviceId”: " ",
“attribute”: “thermostatMode”,
“state”: {
“attribute”: “thermostatMode”,
“value”: “auto”,
“timestamp”: “2024-09-23T09:41:23.970Z”,
“isStateChange”: null
}
}
},
{
“type”: “state”,
“subtype”: “time”,
“data”: {
“localTime”: “2024-09-23T16:58:05-04:00”,
“timezoneId”: “America/New_York”
}
},
{
“type”: “state”,
“subtype”: “device”,
“data”: {
“platform”: “samsung-smartthings”,
“locationId”: " ",
“deviceId”: " ",
“attribute”: “motion”,
“state”: {
“attribute”: “motion”,
“value”: “inactive”,
“timestamp”: “2024-09-23T19:15:57.000Z”,
“isStateChange”: null
}
}
}
]
Near as I can tell, they look exactly the same, not sure why one triggers and the other does not
If I understand the intended rule design correctly, your current design is setting you up for a race condition where even a very slight deviation in the timing of the state stays trigger evaluation and the if condition evaluation can cause variances.
Some alternatives would be to use separate state stays rule triggers for each sensor and flag a variable accordingly, then check the variables for the condition instead… or reduce the state stays condition slightly compared to the state stays trigger to allow for some buffer to avoid the race condition.
So, would that be 2 new rules:
-
One triggered by either sensor being inactive for 1 hr, setting a variable to True
-
Second rule triggered by one of the sensors being active, setting that same variable to False
Is that correct? Wouldn’t that itself potentially conflict, if one sensor goes inactive while another goes active?
At any rate, the condition that failed had both motion sensors inactive for well over the 1 hour trigger, so there should not have been a conflict.
Actually I think I know what you are referring to.
A separate rule like this that changes based on the “presence” (in this case, defined as no one being in the ktichen for 120 min).
Rule is triggered by any changes (motion or not motion) in the relevant sensors
Condition tests if the relevant sensors have been inactive for the last 120 minutes, if so sets Presence variable to false, otherwise sets that variable to true.
Question: would this type of rule trigger too often? Everytime someone moves, even it its not a change of presence, will trigger it. Usually on my other lighting sensors I add a condition that the relevant light is on/off, but I can’t do that here because that’s what’s causing the race condition?
Thanks for the reply and examples (apologies for not sharing my own as I’m on vacation at the moment). I meant a separate rule for each individual trigger. Basically a rule for each device that would individually set a variable flagging if that particular device had stayed your desired value for your desired duration.
The latter approach of reducing your IF Condition’s state stays duration slightly is probably the easier approach and is likely accurate enough for your use case and it would allow you to use your existing rule design.
The challenge you are running up against is the evaluation of the timing in a distributed system. When the event first comes in, the system enqueues a check in one hour to check if the triggering event stayed the same value. Note that the timing of distributed systems is not perfectly precise, so it’s possible that it evaluates not perfectly on the hour, but potentially a second or two late or even a second or two early. Then when it runs the IF Condition, it’s checking the the timestamps reported by SmartThings for each of the devices in your condition to determine when the last state change was. Again, the timing can vary slightly even within SmartThings as well, so it’s possible that the trigger evaluates to true as it waits the hour and doesn’t see any newer events, but when it checks the condition it looks at the timing of the state and if its not at least an hour, it would evaluate to false.
That’s why adjusting the IF Condition timing down a bit can solve the timing issue (eg. 55 minutes instead of an hour… or probably even just 59 minutes instead of 60 would provide enough flexibility).
Thanks for the explanation. For future reference I wanted to try the variable method, and I also can see future automations that can piggyback off a “presence” variable that indicates whether a room is occupied or not. My prior version wouldn’t work because the trigger was a change in state of any sensor but the condition was a state stay on all triggers. So I change it to below - the trigger is still change in state, only the condition is now whether all sensors are also inactive (e.g. the last sensor to turn inactive will cause the condition to be “true” and the variable to switch to “unoccupied.”
Then the rule itself looks only to the variable state, which is resolving only the timestamps within the Sharptools system, and so you don’t have the same conflict?
Do you think this works? I haven’t had a chance to test it but at the same time wanted some expert input.
Would a rule like this trigger too often for the Sharptools server - wouldn’t want to get flagged as hogging server resources? Although I have a similar rule that checks the light level each time motion is detected and adjusts a dimmer accordingly
