In the documentation for notifications there is this - Choose for how long the event must be true before a notification is sent.
Is this just for Booleans?
I keep getting false notifications for one off bad reading of some temp sensors.
I could write a rule to filter if needed.
If I understand your question, you're setting up a notification to be sent if a reading is bad? Are you programming a cancel if the next reading is ok? I don't set up my notifications like that, but let me clarify using something that I use as an example. Motion sensor goes quiet and you want the light to turn off if it's quiet so you delay it for 2 minutes. But leaving it at that would just turn off the light after two minutes after it went quiet even though it's active within a minute. If there's nothing to cancel that request, then it will perform that request without prejudice.
Sounds like they are using the Notifications app, not Rule Machine. The Notifications app has a "for how long?" option that is supposed to wait so many minutes before sending a notification.
To answer the OP's question, the docs are a little confusing because "events" cannot be "true," but presumably what they mean is something more like "choose for how long the condition caused by the event must be true before a notification is sent." This is straightforward for things like door locks or motion sensors, which I assume is what you mean with "boolean" (sensors that have binary states; this setting in the Notifications app is, of course, always something that evaluates to a boolean value). I'd assume that with continuous values like temperature sensors, if you say something like "< 50 degrees" and "for 2 minutes" would definitely work if a reading of 49 is reached and stays there for at least 2 minutes, and I'd expect but can't say for sure that a reading of 49 for one minute and 48 for one minute after that would do the same (two events but still meeting the requirement; if this isn't the case, then I guess what they meant was more like "choose for how long another event for the same device attribute must not be generated before the notification is sent").
Is your problem that you have a setup like this but get notifications immediately? Or do you get repeated notifications for each new reading below the threshold, every time it is met? I could understand that happening (e.g., 49 for 2 minutes followed by 48 for two minutes would both send notifications because they meet a very simple, naive interpretation of the condition...but probably not what most people want). The former would be quite mysterious. Rule Machien could be used as suggested above to work around either, but we might want to verify with staff that Notifications is behaving as expected, so your exact issue would be good to know.
2 Likes
Boy I'm glad you could put what I was thinking into words. I just knew why it might not be working. I think you nailed that.
1 Like
Sorry, I wasn't clearer.
Big freezer in garage, Aeon multi sensor with thin USB cable in freezer.
Don't want rotten food.
Here is the notification:
Works as advertised only one notification per hour.
Problem is this and other temp sensors output bad values every once in awhile.
So I get Garage freezer temp = 1790 degrees or master bedroom is 4 degrees when they are not.
What I'm looking for is a way to filter the few bad readings I get with most of my sensors. I noticed in the documentation for a lock there was a delay i.e. lock had to be open more than 2 min to cause the notification to trigger.
maybe create filtering global variables, set some calculations to eliminate false readings from the sensors and set your warning rule related to those variables instead of the real sensors.
example (not related): my zooz ZEN sometimes generate false reading. I added a condition to filter the highest (impossible) values before continuing the rule
Huh, apparently that setting does disappear when you are using attributes that aren't essentially binary. I guess that's probably for the reasons I mentioned before about how you might want to handle successive events--definitely an easy way out of that problem. 
My suggestion would be to use Rule Machine since you know you can make that work. If you know what bad readings look like, you can create something to exit the rule or otherwise filter out notifications when those happen. Of course, the best thing to do would probably be to get rid of those readings from the sensor in the first place, but I understand that sometimes devices just have quirks that might be easier to work around than address in some other way (but if this is a Xiaomi temperature/humidity sensor, a recent community driver update should have addressed that, but the readings were likely due to low-battery messages from the device).
Something like this will notify you once when the temperature gets below 40, skip values below 4 (so say that's the weird reading you get), and "reset" things when temperatures go above 40 so you'll again get notified if it goes below. You could also modify the ELSE to be something like ELSE-IF (Sensor temperature > 41) if you want to leave a little "dead zone" in the middle to avoid repeated notifications for fluctuations around 40.
Trigger: Sensor temperature *changed*
Actions:
IF (Sensor Temperature < 40) THEN
IF (Sensor Temperature < 4) Exit Rule
IF (Private Boolean True) Send Notification "%device% is %value%"
Set Private Boolean False
ELSE
Set Private Boolean True
END-IFOK this is the way I would skin this cat:
Only question is will the Hubitat use the old value for the freezer or will request a new value in the IF statement.
OK, this works. Old notification tripped but rule didn’t
That rule won't really check that it stayed there for 15 minutes. It will just send a notification 15 minutes after it does so once. To get that, you could add a delay to my rule above, mark it as "Canceable," then add a Cancel Delayed by action in the ELSE.
That’s not what just happened with this rule.
Notification tripped and sent me that the freezer was 57.
Rule never sent a notification, which is good. Either there was a another reading during the wait or another reading when the conditional was evaluated.
Is there a way to force a read of the temp in a rule?
Edit:
Bert just had a rule behave as you predicted.
Thermostat sent 4 Deg. And rule tripped.
Looked at the thermostat and it was still 4 Deg.
Sent a refresh and it read normally.
I can add a refresh to the thermostat so I did.
On the freezer there is no reset available, hub thinks it’s battery powered. Checked the logs and it’s showing activity every minute or so. So I’m good with a delay in that rule.
Slowly climbing up the learning curve......
