IndyMike

That's unfortunate. I thought it might be a difference in battery (mine) vs USB (yours) power. Tested the same configuration as above. After turning OFF, My MS II will respond with a ON within seconds. Wouldn't be the 1st time something was broken by a firmware/software change (just ask Delta, banks, hospitals...). Not sure it helps, but this is the configuration I'm running on the MS II's. I do turn off the Cleanup messages to cut down on traffic.

That's an excellent response. You must have a 5 V activated siren module. Please check to make sure that you are NOT using "trigger reversed" on the IOLinc. It produces erroneous indications when queried.

@arzoo, when you say you're connecting the "alarm siren" to the GND and S terminals, what type of output is this? The IOLinc terminals normally accept a contact closure type of input. The Sense terminal is capable of 5 Vdc max. It can't handle a speaker level AC input. Beyond that, most siren "Modules" that I've seen require a 12V input. There are probably ways that you can connect the IOLinc to your panel, but I don't think a Siren output is one of them.

You are correct - I do not see an OFF Duration. That would be rather annoying. I ran another test with the MS II set to 5 minutes. I extended the ON time by re-triggering the sensor. Sensor turned the light off after 6 Min 30 Sec. I was able to re-trigger the sensor back ON 5 seconds later. If you see something different it could be hardware/firmware revisions? My sensor is a V.46 unit R3.1 with a date code of 4317. Sun 08/18/2024 11:10:51 AM : [ 4A 72 A0 1] DON 1 6 Min 30 Sec Sun 08/18/2024 11:17:21 AM : [ 4A 72 A0 1] DOF 1 5 Sec Sun 08/18/2024 11:17:26 AM : [ 4A 72 A0 1] DON 1

@larryllix, I'm confused (it happens a lot these days). I am not sure what you would prefer the MS II to do under these conditions. If I set my MS II for 20 seconds and it doesn't see motion, it sends an OFF (as I would expect). The Event log below shows an off time of 27 seconds. A little late, but I normally use 30 seconds for hallways and stairs. Sat 08/17/2024 03:20:29 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 11 01 LTONRR (01) Sat 08/17/2024 03:20:29 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:20:29 PM : [D2D EVENT ] Event [4A 72 A0 1] [DON] [1] uom=0 prec=-1 Sat 08/17/2024 03:20:29 PM : [ 4A 72 A0 1] DON 1 Sat 08/17/2024 03:20:56 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 13 01 LTOFFRR(01) Sat 08/17/2024 03:20:56 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:20:56 PM : [D2D EVENT ] Event [4A 72 A0 1] [DOF] [1] uom=0 prec=-1 Sat 08/17/2024 03:20:56 PM : [ 4A 72 A0 1] DOF 1 The same sensor will extend the OFF command indefinitely if it continues to see motion. The following log is from my same sensor when it continues to see motion. The Off command was extended by 1:30. This is what I would expect. What was it that you were expecting? Sat 08/17/2024 03:21:16 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 11 01 LTONRR (01) Sat 08/17/2024 03:21:16 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:21:16 PM : [D2D EVENT ] Event [4A 72 A0 1] [DON] [1] uom=0 prec=-1 Sat 08/17/2024 03:21:16 PM : [ 4A 72 A0 1] DON 1 Sat 08/17/2024 03:23:18 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 13 01 LTOFFRR(01) Sat 08/17/2024 03:23:18 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:23:18 PM : [D2D EVENT ] Event [4A 72 A0 1] [DOF] [1] uom=0 prec=-1 Sat 08/17/2024 03:23:18 PM : [ 4A 72 A0 1] DOF 1 I do use a program to manage my Kitchen sensors I with a short timeout) to ensure that no one has been around for XX minutes prior to shutting down the lights/ That's an entirely different configuration that unfortunately consumes batteries.

Followup to my previous post. Using a wait after the trigger will NOT work. The motion sensor goes into sleep mode very quickly after it transmits it's On/Off status. I played around a bit and found that the following 2 programs seem to work well with my ISY994. The "enable program" runs a timer on the "last run time" for the query program. After one hour, it enables the query program. After the enable, the next time the sensor is triggers (and turns off) the 2nd program will query it. The query program is normally disabled to prevent over polling the motion sensor. After an enable and a Off trigger, it runs a query. 10 sec's later (time allowed for the query) the program disables itself. This program is set to "run at startup" to reset the "last run time" in the 1st program. I've had roughly 85% success with this program. Querying the motion sensor is a time sensitive process. Other Insteon activity can delay the query and allow the sensor to go into sleep mode. Nor worries, after another 1 (or xx) hours you can try again. I really don't know how much functionality this adds. I've seen temperatures ranging from -25 to 130+ on the same sensor. Illumination also seems to vary substantially. Hopefully battery level is consistent. I'm currently monitoring 3 battery sensors and will report back. Test Sensor Enable - [ID 005C][Parent 004E] If Time is Last Run Time for 'Test Sensor Query' + 1 hour Then Enable Program 'Test Sensor Query' Else - No Actions - (To add one, press 'Action') Test Sensor Query - [ID 0053][Parent 004E][Not Enabled][Run At Startup] If '4A.72.A0.1 Motion' is switched Off Then Set '4A.72.A0.1 Motion' Query Wait 10 seconds Disable Program 'Test Sensor Query' Else - No Actions - (To add one, press 'Action')

When I looked at this previously, I attributed the on/off behavior to activity on the power line + the load. When you tested with the "new" extension cord, was the LL plugged into the same outlet? If so, that's rather damning. You might want to give it a little more time to increase your confidence. After that - extension cords are cheap. I would cut the ends off (make sure no one else tries to use it) and dispose of it.

@johnjces, I'm curious what features are not working for you? You mentioned the Led On/Off setting. I can confirm that this setting DOES work using my ISY994. I was able to disable the LED on 2 of my MS II's using both battery and powered mode. You also mentioned the EISY GUI. Most of the features in the GUI were designed for USB Powered devices. As @paulbates indicated, the MS II performs nicely on USB. Like you, I use battery mode on my devices. Since the MS II's don't actively send Level information, you will normally see an empty screen as follows. I'm guessing that's what you're referring to. The MS II can be queried for this information, but it must be done when the device is awake. I normally don't worry about the temp and luminance, but battery level would be nice. The following program can be used to query the MS II after it detects motion. It does work, but I would be very careful using this since it generates a good deal of communication with the sensor. I had initially tried this with the sensor switching ON (not recommended). The query worked, but the sensor was trying to send Off commands while the ISY was querying it (not good). If you want to deploy this, I would put time constraints on it (don't execute more than X times/day) and experiment with "waits" after the trigger. Polling too often will run down your battery and runs the risk of communication collisions. Not trying to talk you out of "different" motion sensors. I have both Zwave (Zooz ZSE 40) multisensor and am test driving some Zigbee mmWave occupancy sensors. The have nice features that include accurate temperature and light monitoring. In the mean time the Insteon sensors are still serving me well for basic motion detection. BSMT Stair Sensor Query - [ID 0044][Parent 0066] If 'Motion/RF / BSMT Stair.1 Motion' is switched Off Then Set 'Motion/RF / BSMT Stair.1 Motion' Query Else - No Actions - (To add one, press 'Action') After program query

Please perform your due diligence before jumping to a new technology/protocol. You're accustomed to Insteon and it's very different from the "other" protocols. Rather than jade you with my preconceptions, I would encourage you to read up on WIFI, Zigbee and Zwave protocols. They all have their + and - and I use all of them. Insteon is extremely effective for lighting (scenes and the like). Very few other protocols can match it. Other protocols are far better at security and power (battery devices).

Thanks, I'll set up a test rig. I'm curious if this was the same thing that I had blamed on low wattage dimmable LED's. I'm assuming "lamp cord" the the AWG. My LampLinc is pretty old - V.3B/ R1.5 Date Code 0211.

@paulbates, makes a good point. My judgement is likely clouded by my disdain for the 2450. I could not find any entries in your logs for the address 70.7B.5B. That's a very "high" address for an IOLinc. It's newer than anything in my system. Are you sure it's correct? If it is correct, your logs do not show any IOLinc activity.

@arzoo, can you describe how you're using the IOLinc sensor input. You mention that it's "Hardwired" to the alarm siren?? Voltage sensing? Contact closure? Do you have any Zwave or Zigbee devices in your system?

If I understand you correctly, you are saying that you have an EMPTY extension cord plugged into the LampLinc. It's possible that the extension cord presents enough of a capacitive load that it's confusing the LL. I'd call that a bad extension cord. Can you describe the cord (2 wire, 3 wire, length, AWG)? I'd like to run some tests - never tried this previously.

I do hope you've found your culprit. It's difficult for me to describe my dislike for the IOLinc without using language that would get me banned from this forum. I would very much advise that you find a different sensor to use as the trigger. Describe the application and there are many members that can help. As you indicated, I don't see any reason that having the sensor in the same outlet as the PLM would be a problem. The real problem is using the IOLinc ANYWHERE in your system. They are simply failure prone devices. Could you provide the address for the IOLinc - I'd like to check your event viewer posts for activity.

I have a few of these around the house. I've re-purposed switches with bad triacs and bad paddle switches in areas where I don't need them. I do "try" to put notes on the back of the switches to prevent me from re-re-purposing them (yes, this has bit me).

@eric_allman, Sorry, I know it's painful rebuilding scenes (particularly for a KPL). I wish there was a neat trick to help with all the On-Levels and Ramp Rates - I don't have one. I've spent a good amount of time looking through the rest interface and the ISY SD card. I honestly don't know where the ISY stores this information for scenes. You can interrogate the ISY for Scene Members and Controllers using the rest interface : /your.ISY.IP Ad/rest/nodes/scenes This will open a XML file in your browser (you'll probably be prompted to login first). You can open the file in Excel as a table. That allows you to sort device addresses to determine which scenes they are members of. It does not include brightness or Ramp Rate information. The following is the scene listing for one of my 8 button KPL's @15.C6.C7. Notes: All devices are members of the My Lighting Scene Type 16 is a controller, 32 is a responder. The Device Group is what is stored in the PLM/Device Link tables. This listing shows decimal, the Link Tables and Event Viewer will show Hexadecimal. That's about all I can offer. Be patient, methodical, and take your time. I find that drowning bait and killing brain cells reduces the tension. But then that's my answer to many problems.

@arzoo, I agree with @Geddy that it's probably time to submit a ticket. We've not been able to identify an Insteon trigger for your events. Possible that things are being initiated by a node server/rest event. Best to get the experts involved.

@arzoo, you appear to have a program firing every 30 seconds and generating the timestamps. That's a pretty tight loop. You should be able to locate the program by looking at the program summary tab. You also have a REST command executing every 5 minutes. I'm not sure if this is program related or an external communication.

The program comparison is being performed (IF statement check on 55.FF.B6). If the program or folder is disabled, the THEN/ELSE will NOT be run. This is not an error. My 994I does the same.

@eric_allman, thanks for posting the table. It explains a lot. Probably not going to be a news item, but it's messed up. I'm guessing that your PLM is address 70.8B.6C. I can see a Main button responder record on line 1: 0FF0 (the PLM can control the main button). The only controller record I see for the PLM is on line 5 : 0FD0 for button 5 (only the c btton can control the PLM). The "F2" record on lines 3 and 4 is rather odd. I've never seen bit 4 set to 1 before (normally a E2). Bit 4 is defined by protocol to be "product dependent" (see below) so it may not cause problems - I've just never seen it used. Rather than detailing everything wrong with your table, I think it would be easier to show how "minimum" table should look for a 5 button KPL. The table below is from a "factory reset" KPL that I added to the ISY. My PLM address is 53.BC.3A. The KPL shows 1 responder link to the PLM and Controller links for all of the KPL buttons. Getting back to the point, you need to delete/factory reset/re-link this device. Make sure to make note of the scenes and programs where it's used prior to deleting. I would also delete/reset/re-link any devices that you believe have links to your old PLM. If these are control links, they will bog down your system while your devices try to communicate with a PLM that no linger exists. Feel free to post additional tables if you wish. For anyone interested, the link table data is listed in the modem developers guide (among other places): https://cache.insteon.com/developer/2242-222dev-062013-en.pdf

I understand venting. I do it often - it's a healthy release... I understand your thought process regarding the programs. The difficult part is we don't understand the trigger, so we can't really asses whether the problem has gone away without significant time. There may also be more than 1 program that is being activated (more than 1 folder affected). I am not well versed on plug-ins, mobile-linc and the like. I don't know if these could be the trigger for the 52 after events. What type of alarm are you using? What type of input devices (hardwired or rf)? Your "powering down" to time shift polling programs is a good thought. Please do report back on the results. Since the "beep" seems common to the occurrence, you could search programs that perform this function and work backward. Just saw @Javi's response. Please pay particular attention - these are next level "failure mode" types of upsets that most of us never consider. Lastly - I would consider opening a ticket before you replace the PLM. My comment about replacing the PLM was based on the fact that it was loosing it's link tables. That doesn't appear to have happened to your recently and I would discount this as the source of your current issues. At this point I feel that replacing the PLM would only further confuse things.

Not my place to disagree, but I thought the process of disabling programs was showing promise. I don't know of any PLM function that would automatically activate programs at 52 past the hour. The PLM is just a hardware modem. It has no timer capability. If you proceed with the PLM replacement I would advise 3 things in addition to the normal procedures (backup, etc): Make sure you have good communications going in (Hops remaining >= 2 when querying devices). Pick a low activity time so people aren't tripping motion sensors and activating lights (early AM is good around my house). Use your "program disable" to make sure that the 52 after event doesn't activate during the replacement.

@gregkinney, I've had similar issues using dimmer modules (LampLincs) with dimmable LED bulbs. In my opinion, the LL's can get confused by varying powerline/load conditions and turn on/off EVEN WITH LOAD SENSING DISABLED. If you were to look at the event viewer you would likely see the LL activating itself and informing the PLM similar to the following. The "02 50" indicates that the device is communicating with the PLM. The 54.A1.F5 is the LL address. The 53.BC.3A is my plm address. Sat 08/10/2024 09:40:06 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A 40 11 01 LTONRR (01) Sat 08/10/2024 09:43:39 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A 40 13 01 LTOFFRR(01) You can try a factory reset to see if it helps. If you want to diagnose the problem you could switch off the lamp or remove the bulb. If the problem goes away, it's a load interaction problem. You can try different dimmer modules, but I have not had much luck. Changing to a higher load may help. I have had good luck with relay Lamp modules. They don't appear to get fooled in to activating due to changing Line/Load conditions.

I apologize, I missed your second question. In this context, red devices can be CONTROLLERS or RESPONDERS. Apparently your Pump device can only be a responder (output only device). This device cannot be used to control a scene. I actually have very few devices like this. One example would be a 2450 IOLinc. The relay on this device can only be a Responder.. You can see similar examples of Controllers/Responders in your scenes (Red=controller/Blue=responder).

Sorry, I missed this yesterday... An alarm program may make sense if it is triggered by a non-insteon device. The Event viewer would not "see" the trigger. The event log shows many scenes being turned off, and 1 device being Beeped (55.FF.B6). Since this is a device direct command with a specific address, you should be able to use the "Find/Replace" function to locate programs that call this device. Wed 08/07/2024 02:52:11 AM : [INST-ACK ] 02 62 55.FF.B6 0F 30 00 06 BEEP (00)