Firing a notification when a temperature condition holds for 5 minutes

[Derek Atkins]

I'm trying to monitor the temperature in a fridge and warn me if the fridge goes above 40F for more than 5 minutes..  I have a Z-Wave Multilevel Sensor that reports back every 30-60 seconds , and I have the following program to monitor it:

If
   'Fridge Multilevel Sensor' Temperature > 40.0°F
  And 'Fridge Multilevel Sensor' Temperature <= 100.0°F

Then
   Wait  5 minutes
   Send Notification to 'Alarm' content 'High Temp'

When the fridge reports at, say 40.2 this fires off the timer.  GREAT.   But then a minute late the temp reports 40.6 and... it resets the 5-minute timer!  I wasn't expecting that to happen; the condition didn't change!  The temp is still > 40.0 and <= 100.0 -- so why did it reset my timer?  I would only have expected it to reset if the temp goes out of range, similar to Insteon "Status'" tests (versus Control tests).

I am running 5.1.0 in case that matters.

[kclenden]

Any change in the sensor temperature will cause the IF to be reevaluated and the THEN possibly run again.  That's just the nature of the IF THEN ELSE.  Consider if you had a motion sensor and you wanted to keep a light on if it detected motion.  In that case you would want the THEN to rerun starting the timer over again.

In your case, you can accomplish what you want with two programs and a state variable that we'll call $sFridgeHot.

Program MonitorHighFridgeTemp
If
   $sFridgeHot is 1

Then
   Wait  5 minutes
   Send Notification to 'Alarm' content 'High Temp'


Program CheckFridgeTemp
If
   'Fridge Multilevel Sensor' Temperature > 40.0°F
  And 'Fridge Multilevel Sensor' Temperature <= 100.0°F

Then
   $sFridgeHot = 1

Else
   $sFridgeHot = 0

In this case the change in the sensor temperature from 40.2 to 40.6 would cause the state variable to be set to 1 again which is not a change, so the IF in the other program would not be triggered and the WAIT wouldn't be interrupted.

[Derek Atkins]

Thanks, @kclenden

I don't feel like it was doing this in 5.0.16.  I'll point out this is exactly why we have the difference between Status Is vs Control Is for switches...

If I have a "Switch" Status Is On then the If does NOT refire if I hit the On button on the switch multiple times.  I.e., if it's already on and another "on" comes in, it does not re-fire the 'if' statement.  However, with ""Switch" is Switched On, then yes, every time you tap the switch "on" it re-fires and restarts the counter.  Indeed, I use that feature to turn exhaust fans off after 30 minutes, resetting the counter if you tap "on" again.

HOWEVER, I do not believe that same (control) logic makes sense for a temperature.  I think it should work like Status.  Your example of a motion sensor is like a switch, and I bet you can use both "Status Is" and "Control" with it to determine what to do.  But Sure, I can work around the bugs (or "features", I suppose).  So the follow up question:

In the Notification content I use various ${alert.XX} to get the subect, time, and details of the alert.  CURRENTLY that will give me, not surprisingly, the fridge temp!  BUT..  If I split this up into two programs, how do I copy the fridge-temp message into the $alert so the notification will send me the fridge temp properly?  (Or will it just work?  I honestly haven't tested this restructuring, yet).

Thanks.

[PhanTomiZ]

14 hours ago, Derek Atkins said:

I'm trying to monitor the temperature in a fridge and warn me if the fridge goes above 40F for more than 5 minutes..  I have a Z-Wave Multilevel Sensor that reports back every 30-60 seconds , and I have the following program to monitor it:

If
   'Fridge Multilevel Sensor' Temperature > 40.0°F
  And 'Fridge Multilevel Sensor' Temperature <= 100.0°F

Then
   Wait  5 minutes
   Send Notification to 'Alarm' content 'High Temp'

When the fridge reports at, say 40.2 this fires off the timer.  GREAT.   But then a minute late the temp reports 40.6 and... it resets the 5-minute timer!  I wasn't expecting that to happen; the condition didn't change!  The temp is still > 40.0 and <= 100.0 -- so why did it reset my timer?  I would only have expected it to reset if the temp goes out of range, similar to Insteon "Status'" tests (versus Control tests).

I am running 5.1.0 in case that matters.

Hi,

At the moment if the temperature goes above 40, you get your notification with temperature, but no other notifications will ever happen until the temperature goes back below 40 and then back up above 40, correct?   In your case the Multisensor is set to report 30-60 seconds which means the IF statement will re-evaluate in the same time period therefore your notification only gets sent out once if above 40. 

Easiest way to remedy this is to change your Multisensor Parameter 3 to anything above 5 minutes ( lets say 6 minutes).  With that change, the program will re-evaluate every 6 minutes giving your notification with variable temperature information.  This will flood your email or text devices with notifications, but this sounds like your goal.

Let me know if I got it right

PhanTomiZ

P.S.  I have 6 of these sensors.  I've found that if I let the Multisensors report sensor information too frequently, it affects the ISY response time.  

[Derek Atkins]

@PhanTomiZ -- no, the issue I am having (with 5.1.0) is that the temp comes in at 40.2 at 11:21:00 so it fires the program and sits in the Wait 5 Minutes.  Then at 11:21:30 I get another message that the temp is now 40.3.  This RESETS the program wait time.  Next at 11:22:00 I get another message, temp returned to 40.2.  This resets the wait time yet again.  Let's say the temp fluctuates for the next 3 minutes, but then stabilizes at 40.2 at 11:25:00.  Now let's say the temp stays at 40.2 for 5 minutes (so no messages reported).  I'll get a notification at 11:30:00, whereas I expected to get it at 11:26:00.

If, instead, I go with the idea that @kclendensuggested, my notification alert is wrong; it wont tell me the sensor OR the temp read in the notification.  See

 

Thanks!

[jfai]

Put the temperature into an integer variable and reference the variable in the notification. 

P.S. Temperature sensors (and other sensors, like luminance) have always worked this way in the V5 firmware. Not sure about V4 - didn't have any sensors until a few years ago... 

[jfai]

5 hours ago, Derek Atkins said:

HOWEVER, I do not believe that same (control) logic makes sense for a temperature.  I think it should work like Status.  Your example of a motion sensor is like a switch, and I bet you can use both "Status Is" and "Control" with it to determine what to do.  But Sure, I can work around the bugs (or "features", I suppose). 

How would you define "status" vs. "control" for a multi-valued sensor? It doesn't support the concept of "DON" and "DOFF", it just reports a measured value.

[Derek Atkins]

I don't recall it working like this in 5.0.16, but it's certainly possible I wasn't paying close-enough attention and didn't notice it.  But I certainly FEEL like this is "different" behavior than it was when I first programmed the notification.

If this is how it's going to work, I might go with an HA automation instead of ISY.  The extra delay of a second or two isn't going to affect me. 

[Derek Atkins]

1 minute ago, jfai said:

How would you define "status" vs. "control" for a multi-valued sensor? It doesn't support the concept of "DON" and "DOFF", it just reports a measured value.

Why would someone NEED a "control" for a mutli-valued sensor?  It's a thermostat, or humidostat, or something else; you either want to know when the value hits a threshold, or you want to know when the value hits a threshold for a period of time.

The logic seems simple to me:  If the multivalue portions of the 'if' remain true then don't re-fire the then.   For what it's worth, HA's automations can handle this case just fine, so if this is going to be pulling teeth from ISY then I'll just implement it there.

[jfai]

1. Every controller is implementing a defined programming model. The ISY evaluates the IF condition every time it hits a WAIT. That has always been that way since conception.

2. Sensors have many use cases, not just checking thresholds. For example, sometimes you'll want to know the rate of change, or just simply calculate a moving average for later graphing. 

3. You could move the threshold logic of your program into the sensor. Many of the temperature sensors out there allow programming of the minimum/maximum reporting range, as well as hysteresis behavior.

[Derek Atkins]

@jfai I am not an ISY n00b; I've actually been using and programming ISYs for almost a decade.  I think my first one was running 3.x which I quickly upgraded to 4.x, and nowadays I'm using 5.x.  Still, can you clarify what you mean by "controller" in this case?  For example, if I have an insteon switch that sends me DON/DOF messages, I can get the behavior I want by choosing Status vs Control.  But it is just one switch.  It's the ISY programming model that lets me decide whether two DON messages separated in time will cause my Wait timer to restart.  So is the controller the DON/DOF handler?  Is the controller the switch?  Or is the controller the ISY Status vs Control programming model?

Considering the ISY already has the Status vs Control programming model for DON/DOF, why can't it have it from multi-value sensors, too?  In this particular case, the value of the IF conditional doesn't change, technically.  Last I checked, both 40.2 and 40.3 are both >= 40.0 and <= 100.0.  So when it gets a new temp, the value of the IF doesn't change.  So really the issue here is whether a new temp should be treated as a Status or Control event in the programming processor.  I'll note that I *AM* using "Status* in the program (but Control only works for on/off style sensors, not the temp).

And by the way, I DO want to have lots of frequent recordings of sensor data (it reports every ~30 seconds) because I am collecting the history of it for graphic purposes.  So slowing down the inputs would cause that to break.

[jfai]

All your devices connected to the ISY and the ISY itself are controllers / microprocessors of some kind. I was writing about the ISY, since it's behavior in your use case was the topic of the thread.

UDI could change the programming model of the ISY to what you want - which isn't necessarily what other people want - with breaking changes for all existing programs that use sensors. I doubt that'll happen anytime soon.

You have many options at this point, including but not limited to:

1. Use more than one program for your use case - see above.
2. Write / Find a Polyglot Nodeserver that interfaces with your temperature sensors just the way you like. Maybe other people would like your Nodeserver and use it too.
3. Use a  different HA controller - with different quirks due to its unique programming model.
4. Rinse and repeat ?

[kclenden]

7 hours ago, Derek Atkins said:

I don't feel like it was doing this in 5.0.16.  I'll point out this is exactly why we have the difference between Status Is vs Control Is for switches...

I'm pretty sure it has worked this way for as long as I've had my ISY, which admittedly is not as long as you have had yours.  I'm not sure this scenario is why we have the difference between "Status" vs "Control".  "Control" has always been described to me to mean local control of the device.  Which is to say, if a switch is turned on by the ISY, or a linked device, the ISY does not see that as "Control" even though it often would be helpful if it did.

[Derek Atkins]

40 minutes ago, kclenden said:

I'm pretty sure it has worked this way for as long as I've had my ISY, which admittedly is not as long as you have had yours.  I'm not sure this scenario is why we have the difference between "Status" vs "Control".  "Control" has always been described to me to mean local control of the device.  Which is to say, if a switch is turned on by the ISY, or a linked device, the ISY does not see that as "Control" even though it often would be helpful if it did.

The difference between Status and Control is that Status only fires into THEN when it CHANGES, whereas Control fires every time the event comes in.   So as an example, if you have a program like:  "If Status 'Switch' is 'On' Then Wait 5 minutes ; Notify" and you turn the switch on at 11:00:00 and then you turn it on again at 11:02:00, and then at 11:03:00 it gets turned on again via a scene, the notification will still come at 11:05:00.  On the other hand, if you have a program "If Control 'Switch' is Turned On Then Wait 5 minutes; Notify", and you tap the switch on at 11:00:00 and then you tap on again at 11:02:00, and then at 11:03:00 it gets turned on yet again via a scene, the 11:02:00 tap will re-fire the Then, restarting the delay, whereas the 11:03:00 scene event wont affect it, so you'll get the Notify at 11:07:00.

There is a side effect with Control that it only fires from the source entity, so the scene turning on the switch wont trigger the Control event.

But go try it with a switch and you'll see that hitting the switch a second time will not reset a Wait counter if the if is Status, but will if it is Control.

And like I said, I *FEEL* like this is a change in behavior with my temp sensor from 5.0.16 to 5.1.0, but I admit I didn't pay close enough attention to the behavior before.

@jfai  Indeed, and the Home Assistant (which is what I meant by HA above) automations do give me the control I want, however right now I'm trying to figure out how to get it to fire *again* if the temp stays above my threshold for a longer period of time.  But that's a question for a different forum.