IndyMike

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)

Change your if statement from "switched on" to "status on". The "switched on" statement is for manually activating a device on/off. You are turning the device on using a scene. It will not trigger the "switched on" if clause.

Bingo - your program triggered at 4:26 PM but evaluated to false. It did not modify the backlight on your KPL. Next run time is correctly shown as 1:00 am.

Unfortunately the answer is NO. If a program is triggered by a Insteon device you can see the logic path the ISY uses in the IF section, and any device communication that is sent in the Then/Else section. The "time" entries are normally an indication that something is being executed on the ISY, but has not resulted in an Insteon communication. Can you post one of the suspect programs? As an example, if I manually execute the IF clause on the following program, it does not generate any Insteon communication. It does show a time marker in the event viewer. The same would be true when a program is triggered and executes the "else" path with no statements.

@eric_allman, you noted that the ISY believes your device link tables are correct. If you are sure that there are addresses listed in link tables that are no longer present in your system (addresses are not present in your ISY device tree) - that's a tough nut to crack. If your device happens to be a scene controller, it will be trying to communicated with devices that are no longer there and will be slow and very displeased. As you noted, a restore will not accomplish anything. You might be able to remove affected devices from various scenes to eliminate the dead device links, but you may have scenes that no longer exist in the ISY as well. Easiest method would be to delete the device from the ISY, factory reset, and add as a new device. Make sure to note scenes and programs where the device is used. Please ensure that you have good communication (hops remaining >=2 in the event viewer) BEFORE deleting. Many devices will allow the PLM to control them without any links in their table. All that is required is the address. The normal reason for the ISY/PLM not "hearing" manual switch activation's is a missing responder link entry in the device (PLM isn't listed as a responder). I'm confused by the fact that you see activity in the event viewer. That implies that the device is communicating to the PLM. Could you post a level 3 event log of this activity along with your device link table? Insteon protocol does not allow you to "query" or directly control KPL secondary buttons. They can be added to scenes and controlled through the scene. Are you indicating that your secondary buttons CAN'T be controlled by ISY scenes? If so, please again post event viewer data and link tables for the device. The ISY does not provide a method to manually add/delete link table entries. No one in their right mind would consider doing this outside the ISY environment (I have, but am disqualified by the "right mind" qualifier). As mentioned above, delete from the ISY, factory reset device, re-link. Make sure you have good communication prior to proceeding. KPL's are rather complicated devices that require a buttload (technical term) of links to operate. They are normally the first devices affected when a upgrade/replacement experiences hiccups. I think I covered your questions on the secondary buttons above. If not, please educate me. As a general note on PLM replacements... The UDI team has done a masterful job of making a PLM replacement reasonably painless and error free. I can remember a time where a automated PLM replacement was not available - the scars are hardly visible. If you have ever performed a firmware upgrade on your PC, think about the PLM replacement process: writing firmware to many devices with many different hardware/software versions across a distributed network with uncontrolled activity on the network with questionable communication over a long time period with questionable power input I could go on, but the point is I amazed that this works so unbelievably well. Unfortunately, when it doesn't work it can be a real mess to recover. ...but you can recover.

@arzoo, A number of items from your log: No evidence of your motion sensors triggering. The program that was calling scene 25H is no longer active. You appear to rest activity that is firing every 5 minutes. I'm not sure what this is, and cannot say that it's related. Wed 08/07/2024 02:57:23 AM : Create REST U7 [/rest/profiles/ns/1/connection] Wed 08/07/2024 02:57:23 AM : Create REST U7 [/rest/profiles/ns/0/connection] Wed 08/07/2024 03:02:21 AM : Create REST U7 [/rest/profiles/ns/1/connection] Wed 08/07/2024 03:02:21 AM : Create REST U7 [/rest/profiles/ns/0/connection] I concur that you had some "events" @2:52 and 7:52. I do not see and obvious trigger for the events. There was no incoming Insteon traffic at that time. Disabling the programs did appear to work for the time period you specified. I'm not sure that's long enough to be conclusive. Aside from the above, I believe it was @paulbates (not me) that suggest you try disabling program sub folders to further isolate things. I think that's an excellent idea. I would just caution that you wait "long enough" with all programs disabled be sure that it's a program causing the issue. @Techman mentioned that disabled programs would still run if executed by another program. This is exactly correct. As always there is a BUT. I you disable the program FOLDER, you cannot execute a program regardless of how it is called. In other words, disabling a program folder is a safe and conclusive method to prevent it from running. Lastly, I'm not sure if we ever discussed the "crazy stuff" that happens during the event. Could you describe this a bit? Is it always the same devices? There is some activity in the logs at the end of the event. The ISY is sending out a series of On/Off commands to multiple scenes. I don't see an obvious trigger for the event.

That one is a bit of an OUCH. Devices will sometimes loose their link tables if you have a voltage upset while the device (EEPROM) is being updated. If you haven't had power glitches, and the device is still dumping it's memory, it's more than likely a failing power supply. I'm not a fan of firing the replacement parts cannon. Keep trying to isolate things, but remember this symptom. You may get to a point where nothing else makes sense.

Not quite correct, scene numbers in the Event log and the plm are 2-digit hex (0 - FF, 0 to 255 dec). But you did give me an idea... If you use the rest interface to query the isy you can show the scene members in XLM format - https://wiki.universal-devices.com/ISY_Developers:API:REST_Interface The specific command I used in my browser was - "xxx.xxx.xx.xx/rest/nodes/scenes" where the "xxx.xxx.xx.xx" is your ISY ip address. This should display all of the scenes in your device. The following is a small section of the scene listing for my ISY. I believe the <device group> number corresponds to the event viewer/ PLM group numbers. The <address> corresponds to the # listed in the topology report. Ex from my topology report - address 50269 shows 3 of my devices as scene members. Address 50269 in the reset scene xml shows the same members and a <device group> of 25. @arzoo, you need to reverse this process. Access the rest scene listing from your browser as I showed above - xx.xx.xx/rest/nodes/scenes. You will be prompted to login to the Eisy. Search for the "<device group>25<device group>" "<deviceGroup>37<deviceGroup>" entry. Correction: the scene #25 in the ISY Event Viewer is in Hexadecimal. The deviceGroup entries in the Rest scene output are in Decimal ( 25 Hex = 37 Dec). Note the <address> entry associated with the above <device group> Search your topology report for the <address> that you noted. This should be the scene that is being activated. Security / Security Front Entry (50269): Security / BSMT KPL A House Secure / BSMT KPL C - Front Entry: Responder 2nd Floor / Master Fan KPL A / Master Fan KPL C - Front Entr: Responder Security / Stair KPL A House Secure / Stair KPL - D Front: Responder REST XML Output: <group flag="132" nodeDefId="InsteonDimmer"> <address>50269</address> <name>Security Front Entry</name> <family>6</family> <parent type="3">22260</parent> <deviceGroup>25</deviceGroup> <pnode>50269</pnode> <ELK_ID>M06</ELK_ID> <members> <link type="0">19 21 42 4</link> <link type="0">C 8A E3 4</link> <link type="0">19 21 FF 3</link> </members> </group> <group flag="4" nodeDefId="InsteonDimmer"> <address>1455</address> <name>SC 2nd Floor Status</name> <family>6</family> <parent type="3">44910</parent> <deviceGroup>60</deviceGroup> <ELK_ID>J09</ELK_ID> <members> <link type="0">29 4C 9F 4</link> <link type="0">58 CB 74 6</link> <link type="0">58 D0 2B 3</link> <link type="0">1C DE 23 4</link> <link type="0">1D FD 42 3</link> </members> </group> <group flag="4" nodeDefId="InsteonDimmer"> <address>24859</address> <name>SC 2nd Floor</name> <family>6</family> <parent type="3">44910</parent> <deviceGroup>61</deviceGroup> <ELK_ID>J08</ELK_ID> <members> <link type="0">29 53 3C 1</link> <link type="0">29 53 3C 2</link> <link type="0">29 53 3C 3</link> <link type="0">29 53 3C 4</link> <link type="0">14 78 B2 1</link> <link type="0">14 6C F0 1</link> <link type="0">1B F4 54 1</link> <link type="0">1F BD EE 1</link> <link type="0">41 D 9E 1</link> <link type="0">1A 4F 6B 1</link> <link type="0">58 D0 2B 1</link> <link type="0">58 D0 2B 2</link> <link type="0">58 D0 2B 4</link> <link type="0">F D7 F1 1</link> <link type="0">29 53 3C 5</link> <link type="0">29 53 3C 6</link> <link type="0">19 21 FF 1</link> <link type="0">19 21 FF 2</link> <link type="0">1D FD 42 1</link> <link type="0">1D FD 42 2</link> <link type="0">1D FD 42 4</link> <link type="0">1D FD 42 6</link> <link type="0">1D FD 42 8</link> </members> </group>

Unfortunately I don't have an easy answer there. There may be an easy way to interrogate the ISY for group / scene numbers. I don't know what that is. When I have done this in the past, I have downloaded the contents of the PLM and searched for the group / scene numbers there. It's rather painful.

1 possibility down and xx to go... I'm sure it doesn't feel like it, but this is progress. Please also try the following: Disable Sensor 14.7B.DF. It is also triggering repeatedly and calling similar programs. You have many programs. I'm focused on the one that's turning Scene 25 On and then Immediately OFF (the RED highlighted entries above). This should never happen. Please try to locate this program and correct it or disable it. Identify device 50.AD.58 and the programs that it triggers. The program activity is also suspicious in that multiple on/off scenes are being executed. Do try disabling the periodic programs you mentioned above. Look at your Log file (/tools/log) to see if you have any patterns that show up @12:52. Try disabling all programs (put a condition on the folder to disable it). If the problem still shows up you've learned a lot about what it isn't. As you disable sensors and things, feel free to post additional logs. Hopefully things will begin to make sense. Please also post any programs that you suspect may be an issue.