Derek Atkins

@HABit What I would really like to do is have a single Insteon Micro On/Off that acts both as a controller and a responder, but separate those functions. Right now, when the IR trips (connected via yellow sense wire), yes, I get the DON command, but it also turns the load on -- and when the IR times out (I think I have it set at 1 minute) I get a DOFF and the load turns off. My issue is that if I want to manually turn the lights on and send the device a DON (e.g. from my ISY), if someone walks in front of the IR, the light turns off a minute later. At least, I am pretty sure that's what's going on. I'd like that not to happen; I'd like to separate the load on/off from the sense line emitting DON/DOFF.

Ahh, I see. So you're not using the motion sensor as an Insteon Input! You're using Insteon to power the whole fixture, so either it's just powered on (and motion sensor does its thing), or you do the On/Off/On to "turn the light on and hold it". Thanks for clearing that up.

@MrBillI am curious how you have your flood light / motion sensor wired to Insteon device(s)? Do you have one or two insteon devices in there? E.g., One connected to the motion sensor (to the sense line), and a second to the light (or possibly to the whole fixture)? I was under the impression (although I could be wrong) that it was power to the motion sensor equipment that performed the "hold on", which means you'd need to flip power to the whole fixture to do what you want? I admit I have not played with my installations to test this -- but I still would like to decouple the motion sensor sense from the flood light on/off using a single Micro On/Off device wired in. For the record, I wired mine like what you find at https://www.pinterest.com/pin/704320829205183155/

Thanks, Chris. Any chance someone might look at this bug which was in 5.1 and 5.2 (and I presume 5.3 as you say no changes were made)? It causes bogus XML to be sent from the ISY which buggers any compliant implementation because the data sent from the ISY is not UTF-8.

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.

@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.

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.

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.

@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!

So, due to a change in the way temperature changes are handled in programs I need to separate out my "wait 5 minutes before notifying of a high temp" program into two programs. See: My issue is that when I separate out the programs this way, instead of getting a notification that says "High Temp Alert: Fridge Temp : fridge Multilevel Sensor - Alert" with details that say "Value: 402" (for 40.2 degrees), I get a notification that says "High Temp Alert: Fridge Temp Notifier : Variable changed - Alert" with details "Value: 2.5". And it is ALWAYS 2.5. SO... How do I *save* the alert from the first program in order to send that as the notification in the second program? Before you answer, let me add that I have about 5 different programs that all use the same notification customization because I've got multiple temp sensors that I am monitoring, so I would really prefer not to have to have unique notification configurations for each sensor.

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.

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.

@nickster -- So long as you have power to where you want to place it, you can combine a Micro-On/Off with, e.g., a "replacement motion sensor" like this item from Home Depot for $22: https://www.homedepot.com/p/Lithonia-Lighting-Outdoor-180-Detection-Zone-Motion-Sensor-Retrofit-Kit-Bronze-OMS-1000-120-DDB-M6/205507283 Then you will need to wire it in a box. You will just use the Micro-On/Off as a sensor/controller -- and then have it send on/off to responders in the lights you want it to control. Note that if you want the light on/off to be separate from the motion detection then you *may* need two Insteon devices: one for motion detection and one for the light controller. I am not sure if you can use a single Micro On/Off to separate the sensor side from the On/Off side (but I would LOVE to learn that you can!) Hope this helps!

For what it's worth, I used the wiring from the link that @drmacro linked to above for all my flood lights. A few important things to note: 1) Pretty much any LED-integrated flood light WILL NOT WORK. These units either don't provide access to the wiring, or they step-down to low voltage *BEFORE* the motion sensor, such that you don't get line-voltage out of the motion sensor to connect to the sense line of the micro On/Off. I recommend you just buy the old-school "halogen" (although I used LED) bulb fixtures. 2) Do not have the line to the flood light switched; if you do this, then you will not be able to control the flood light if that switch is off. (I suppose you could have a "master" switch that forces them all off, but you would need to ensure that master switch is on). 3) I do believe that you can "disconnect" the sense from the On/Off part such that the controller does not automatically turn on (or off) the responder (light) when motion stops. At least I THINK you can do that -- I have not tried. For some reason, one of two of my units seem to get stuck on. I'm not sure why this is the case, and if I turn it off "by hand" (meaning from my ISY) then it stays off until the next night. I'm not sure if it's a busted motion sensor or busted day/night sensor or what. I haven't spent much time exploring it, but it is one specific unit that is behaving this way.

I confirmed it via Level 1, not Level 3. Running Level 3 my admin console would log off every few hours. But even in Level 1, it said DFOF and not DOF, which was confirmed as Fast Off. I've got an open report with UDI via their support system so @Michel Kohanim and crew aware of this.