I have a rule that is supposed to notify on alexa if the furnace hasn't turned on or off in 10 hours... i however get a notification in 5 hours. What am I doing wrong?
here is the rule
I got a notification on 9:37am
here is events..with last change well within 10 hours
Would this rule work? (I used my basement door contact sensor as an example). Every time the contact sensor changes state it should cancel the delay of the previous state's notify?
Logs would have been helpful, but I set up a test rule similar to your rule and can duplicate what is likely going on with your rule. It looks like the 'stays that way' timer keeps counting as the two triggers alternate being true.
I set up this rule:
In the logs below you can see that as I turn the outlet on and off, the time is counting down from the first activation.
So once your rule triggers on the first state change of the contact, the trigger will stay true and the notification will fire 10 hours later. I don't know if this is by design, or a bug. I can see how you would expect it to count each of the 'stays that way' timers separately.
I'm leaning towards 'bug', or at least, very un-intuitive results based on another test I just set up.
I changed the rule to use two different devices... "Outlet 1" and "Pantry Light", both with 'stays that way' timers. It should trigger when the pantry light stays on for 30 seconds or the outlet stays off for 30 seconds. Common sense would say that if either condition is true for 30 seconds, the rule should trigger, independent of whether the other condition is true.
The logs show that once the timer starts for one device, if the other condition goes true and then the original one goes false, the timer stops and the rule is not triggered.
The rule started a 30 second wait on the pantry light being turned on at about 11:49:06
I then turned off Outlet 1 around 11:49:20. That made that part of the trigger go true, but rather than counting down 30 seconds for that individual trigger, it shows it is waiting :16 seconds (based on the Pantry Light on time).
I then turned off the Pantry Light at around 11:49:30 and it logged that it didn't trigger due to that condition not remaining for 30 seconds.
However I would expect it to trigger at around 11:49:50, when the outlet had been off for 30 seconds. It did not.
So using multiple 'stay that way' triggers seems like a bad idea as they currently function.
The example posted by @KurtSanders looks like it should work for you.
EDIT: tagging @bravenel for his thoughts on whether multiple 'stays that way' timers are intended to work this way.
Previously reported, see below. The Wait for Events action is similarly problematic.
Hard to say without any logs, which are normally the best first step to try when troubleshooting anything. However, without that, the most likely explanation is that you're running into problems having two trigger events for the same attribute, which is not supported. See:
You could use two separate rules, or you could re-work your logic so the timers are in your actions, like removing the "and stays?" (sticky trigger) option and doing:
Wait for event: elapsed time --> 10:00:00
Notify ....
instead.
thanks for explaining two trigger events for the same attribute issue... I didnt realize that... I think this should work ...right ?
No, you will need to use the "Wait" as I suggested above, or you will need to make a couple additions to your rule (setting "Cancelable?" on this delay and adding a "Cancel Delayed Actions" action before it -- I normally recommend the approach I did originally because it's less work).
under actions -> wait for event ..I do not see the option for elapsed time ....u sure that exists?
Woops.... appreciate your patience. ....dunno how I missed it... so in the case above you don't have to worry about things being cancelled...
if it changes it should restart right with no need to cancel?
Thx again
Not sure what "it" refers to in both these cases, but if you mean that the contact sensor changing will cancel the wait, then yes, that is why I suggested this approach originally and is why you'd need the modifications to make yours above work if you wanted to use that actions instead. The RM docs explain more on how delays and waits work:
'
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
