Good Day
I put a temp sensor in my deep freezer that is fairly sensitive to change. It will rise fairly rapid even with a door opening. I wanted to create push notification once it got above a certain temp for a length of time. Seeing as there is no time setting in the notification app for length of time above a certain temp I created a RM rule rule with a sticky trigger. The problem is it does not wait the allocated time before sending the notification. It is less than a minute when I have it set to ten. It also sends a new notification every time the temp changes when above the threshold. Below is the rule and am wondering if I am missing something simple.
Thanx, Abe
@abe.doerksen Try this. In your rule every time the temp changes it sends a message.
It might be helpful to switch on all logging for the rule and screenshot what happens when it triggers so we can see.
One thing to check - is the temperature selected as a custom attribute of a device or directly as a temperature sensor? The reason I ask is that I found and reported a bug a couple of weeks ago where sticky trigger was ignoring the "stays that way" when it was a custom attribute. It was going to be fixed "in the next version" but I didn't see any reference to it in the next version release notes, so I'm not sure whether it is still an active bug.
@rlithgow1 Shoot me if I'm talking rubbish but...
Won't something similar happen with your rule though? Each time the temperature changes it triggers and if the temperature is over 15 starts a delay of 10 minutes to the notification. So with every temperature report that is over 15 another instance with a delay of 10 mins occurs. Once it drops back to the correct temperature all of those 10 minute delays will end and send the report repeatedly. Using a wait wouldn't work either, as with every report over 15 the notification would be further away.
I'd have thought the best way to do it would be to set a boolean true/false based on the temperature in one rule, then use that boolean as the trigger. The below was suggested to me for another rule (thanks to @bertabcd1234) to capture the lux passing a specific value and would need to be reversed.
Use that boolean changing as the trigger. Then if boolean is false exit rule else if true wait elapsed time 10 minutes, notify dads phone end if.
I liked this way of doing at as the rule is not continually triggering and being evaluated with every temperature report (or lux in my example). It'll only fire on the boolean changing,
I used a wait on the rule. So it will basically just notify every 10 mins until it goes below 15 degrees regardless of the temp change. If I used delay then it would reset every change (someone please correct me if I'm wrong because I very well could be)
Not a custom attribute but off the temp reading.
After looking at the logs it does look like the timer tries to restart after every temp change.
Not sure why it sends a notification before the ten minutes regardless.
I have since written a more complicated rule 
that seems to work.
1 Like
Just noticed my double cancel so got rid of the one in required expression.
Thank you everyone for the suggestions.
Even though the more complex rules get the job done I am still curious as to why the simple sticky trigger rule does not work as I understand it.
My understanding is that it should not even send any notification until the 10 minutes is elapsed if the temperature is above the threshold. Knowing now that it appears to reset the timer every time the temperature changes I should probably not get any notifications at all as the chances of the temperature staying steady are quite small. Instead I get a notification every time the temperature changes with no regard to the stays that way timer.
It is my first use of a sticky trigger so it could very well be my understanding that is the issue here.
Any insight would be appreciated.
Thanx, Abe
Probably that is an @bravenel question
I will look into it.
Please turn on Event and Trigger logging for the sticky trigger rule. When I try this it works as expected.
This with multiple temperature events all above the trigger level. It triggered 30 seconds after the first event.
Here, the temperature did not stay above the threshold for the required time, and it did not trigger at all:
And here I used minutes just to show that the amount of time isn't relevant to it working or not:
The temperature threshold for this rule is 30.
Well Bruce I don’t know what to say.
Over the last couple days I built the sticky trigger rule at least three times and with various sensors and multiple sensors. Each time I would delete the rule and start over thinking I corrupted it somehow. All rules would send a fairly immediate notification and after every temperature change which is what prompted me to seek help. I gave up as I thought I was misunderstanding sticky triggers. I then wrote the slightly more complex rule to accomplish what I wanted.
Tonite after your request I rewrote another sticky trigger rule as below.
It works exactly as I understood it should work. No immediate message, no message after every temperature change. Only after 5 minutes of above threshold does it send a notification. Perfect. The logs don’t even look any different from the other day.
Not sure what magic you worked but damn you’re good.
Thanx for your time and patience. Abe
2 Likes
Morning update
Last nite after the successful test run I put the rule into service.
I made 2 changes though. I increased the length of stay from 5 to 15 min. and noticed I had not added device etc to the notification. Added %device% %value% %date% %time% in the message to send and hit done. All was good in the world.
….or so I thought
This morning the wife was in the deep freeze for a period of time and the temperature sensed went up. Got the initial notification way to early again and notifications again on every temperature change.
Going back on the changes made last nite I deleted the rule and made a new one but without the %device% etc. in the message to send.
Works fine now again.
So it appears that adding %xxxx% in the message to send causes the unexpected behaviour. All is good again.
Now I just need to find them little bits of my mind I lost somewhere.
Seriously though thanx again for your time, assistance and patience.
Abe
When I was trying out the sticky triggers, with selection of multiple devices like you have here, I found a lot of unpredictability when the multiple devices have overlapping events and start different sticky timers and/or cancel each others' sticky timers. I didn't put too much effort in trying to understand what was going on, but rather I just created one rule per device.
Well the plot thickens
Just turned off event and trigger logging and goes back to the unexpected behaviour.
Added %xxx% back in and left logging on and it behaves as expected. Turn logging off and reverts back to the unexpected.
Hopefully this helps.
Thanx, Abe
Interesting suggestion so I just tried it with one sensor and still behaves with logging on and unexpectedly with logging off.
Thanx for the suggestion. Abe
