IndyMike

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.

Thanks - that helps. As @Techman indicated, the 14.72.B6 sensor shows up a lot. It appears to have an on/off time of 30 seconds. It is being evaluated by 8 separate programs. One (or two) of those programs is turning on scene 25 and then immediately turning it off again. Some of these may be disabled - they will still show up in the log. There appears to be a second sensor (14.7B.DF) that is also activating. This one appears to have an on/off interval of 1 minute. It is also being evaluated in 8 separate programs with two shared programs (highlighted green below). Again, there is a program turning on scene 25 and the immediately turning it off again. There is a 3rd device that is turning on/off multiple scenes. I can't tell the device type. The device is evaluated by 6 different programs. All three of the above devices were active at the 12:51:59 mark when things went out the window. You should be able to search for programs where these devices are used by using the "find" feature as @Geddy described. I have a feeling you have multiple programs firing at the same time and causing issues. Motion sensors are notorious for firing multiple communications per event. Both of your devices send 2 On messages + 1 cleanup per event. As a precaution, you may want to add a wait to your programs to prevent collisions. I still do not see a smoking gun anywhere that would indicate what triggered the "event". Try some precautionary changes and things may become clearer. This could also be caused by a non-insteon event (PG3, rest interface, Home Assistant) that would not show up in the Event Viewer.

@carealtor, My IOLincs are very old. I consider the devices as very unreliable and totally unsuited for the task they were marketed for. As an input device it's barely acceptable. As an output/control device it's a problem waiting to happen. I have no personal knowledge of an IOLinc with corrected firmware. I do not understand how HA could reflect the IOLinc status correctly. The IOLinc is actually reporting it's status incorrectly during the Query. If you are using the HA/ISY integration, I can't see how HA could get this correct unless it's ignoring the ISY query. I'd be very interested in hearing any theories on how this could occur.

@carealtor, This issue has been around for some time. For some reason the IOLinc itself reports the incorrect status during a query when the trigger is reversed. I just replicated exactly what you are describing using my ISY994 and a old V.36 IOLinc. Not sure why you would not see this issue with the Polisy. It's possible that Smartlabs fixed the later versions of the IOLinc. Easiest way to rectify is to replace the magnetic switch with one that doesn't require the reversed trigger - or better yet, replace the IOLinc. From the archives: Trigger Reversed Query

Can you provide the Insteon address for the motion sensor? I can check your event log to see if it sent something odd. I agree with @paulbates regarding the factory reset of the MS1's. This has become standard practice for me whenever I replace a battery.

@larryllix, I don't really see this as an issue. Over the years I've seen numerous requests for scenes/programs that identify dimmer on levels @0%. I don't use them, but understand that others do. Applying a 0% level to a relay seems to be a natural extension. If I wanted to activate a scene with a relay OFF, this would be of use. I'll admit to not noticing this until you brought it up. I am using the ISY994 @V5.3.4. All of my On/Off devices show the same option for On @0%. This includes both my most recent On/OFF modules (same vintage as yours) as well as my ancient Icon On/Off switch. I think this has been around for some time. We just haven't picked up on it (until you noticed).

I've never had issues fitting multiple Insteon switches side by side in a 3 gang box. Since they should fit side by side, I assume your box does not have enough depth to accommodate the wiring. The being the case, you should checkout switches that use screw terminal connections. I like the Zooz Z-wave switches, but that would require you to purchase a new Z-wave stick (not recommended). I believe that the Phillips Hue line is Zigbee. I normally try to stay within the same communication protocol when using motion sensors/switches. I use Zigbee for sensors but have 0 experience with Zigbee switches. Hopefully someone else with experience with screw terminal Zigbee switches can chime in.

That's unfortunate. Do you have any programs that re-trigger on an hourly basis? The start times can drift if delayed by other events or if they are qualified by sunrise/sunset. I've seen programs "drift together" and cause issues. I have a number of programs that Poll devices throughout the day - Flood Night Poll - [ID 006E][Parent 0002][Run At Startup] If From Sunset + 1 minute To Sunrise - 10 minutes (next day) And Time is Last Run Time for 'Flood Night Poll' + 15 minutes Then Send X10 'F1/Status Request (10)' Wait 9 seconds Send X10 'F3/Status Request (10)' Wait 9 seconds Send X10 'F5/Status Request (10)' Else - No Actions - (To add one, press 'Action')

@arzoo, your log took awhile to decipher. There's a lot going on. I've tried to categorize things below to make them a little more understandable. Section 1 shows the ISY transmitting an ON command to group 25 IMMEDIATELY followed by an OFF command. This was likely a program executing because the commands were processed so quickly. Normal processing would show the ISY command [INST-TS-I1] immediately followed by the PLM ACK [INST-ACK]. This may have been a programming typo where you intended to execute a scene OFF command 2x. If not, you may have 2 programs that are triggering each other. Section 2 shows the ISY bookkeeping the On/Off states for the devices in Group 25. By my count, there are 65 unique devices in that group. I find it odd that the ISY is statusing the Ramp Rate and On Level, but that could be a new feature of the EISY (I have the ISY994). I also find it odd that all of the KPL sub buttons appear to be in Group 25. As I said, there's a lot going on. Keep in mind that NO commands are issued in section 2. There's 600 lines of log entry that occurs in 0 elapsed time with no commands issued or received. Section 3 I flat don't understand. Many OFF commands to different groups multiple times. NONE of these are acknowledged by the PLM. I don't understand why they are not acknowledged - they appear to be valid commands. I also don't understand why you would turn that many scenes off in rapid succession, mutiple times. Again, because they happened to quickly, these are probably coming from a program. Very ODD to say the least. Section 4 shows a device direct command requesting that the device BEEP. It's very normal with both a PLM and Device Acknowledge. Conclusion: This does not appear to be a classic All-On event. A all on event is purportedly caused by a command collision at the PLM. Because the event is the result of a collision, the ISY DOES NOT HAVE KNOWLEDGE of the event. Your logs show that the EISY does have knowledge of the event and is trying to reflect that status of the devices. Since the event appears program related I would start by inspecting/disabling programs that work with Group 25 (On/OFF in Section 1). You may also want to inspect the program(s) that are issuing the multiple group OFF commands in Section 3. I don't understand why, but the PLM is not responding to these commands. Section 1 - Group 25 turned on then immediately turned off Fri 07/26/2024 12:51:42 PM : [INST-TX-I1 ] 02 62 00 00 25 CF 11 00 Group 25 On Fri 07/26/2024 12:51:42 PM : [INST-TX-I1 ] 02 62 00 00 25 CF 13 00 Group 25 Off Fri 07/26/2024 12:51:42 PM : [INST-ACK ] 02 62 00.00.25 CF 11 00 06 LTONRR (00) PLM Ack Fri 07/26/2024 12:51:42 PM : [INST-ACK ] 02 62 00.00.25 CF 13 00 06 LTOFFRR(00) PLM ACK Section 2 - ISY bookkeeps the on/off status of 65 unique devices + secondary buttons Fri 07/26/2024 12:51:42 PM : [55 FF B6 6 ] ST 255 (uom=100 prec=0) ISY Book keeping ON/OFF Fri 07/26/2024 12:51:42 PM : [55 FF B6 6 ] ST 0 (uom=100 prec=0) 65 Unique devices Fri 07/26/2024 12:51:59 PM : [50 AD 58 1 ] RR 28 (uom=25 prec=0) Fri 07/26/2024 12:51:59 PM : [50 AD 58 1 ] OL 255 (uom=100 prec=0) Fri 07/26/2024 12:51:59 PM : [50 AD 58 1 ] ST 255 (uom=100 prec=0) Section 3 - Multiple scenes turned off - PLM doesn not respond to these commands Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 3A CF 13 00 Group 3A Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 42 CF 13 00 Group 42 Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 43 CF 13 00 Group 43 Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 41 CF 13 00 Group 41 Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 41 CF 13 00 Group 41 Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 42 CF 13 00 Group 42 Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 43 CF 13 00 Group 43 Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 25 CF 13 00 Group 25 Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 4B CF 13 00 Group 4B Off Fri 07/26/2024 12:51:59 PM : [INST-TX-I1 ] 02 62 00 00 25 CF 13 00 Group 25 Off Section 4 ? Odd beep command to device 55.FF.B6 both PLM and Device Ack Fri 07/26/2024 12:51:59 PM : [INST-ACK ] 02 62 55.FF.B6 0F 30 00 06 BEEP (00) Fri 07/26/2024 12:51:59 PM : [INST-SRX ] 02 50 55.FF.B6 43.6E.51 2F 30 00 BEEP (00) Fri 07/26/2024 12:51:59 PM : [Std-Direct Ack] 55.FF.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Group 25 Devices - Does not include sub-buttons 1 14 72 B6 2 14 7B DF 3 15 C7 F5 4 16 9E 2F 5 16 9E E 6 16 A0 74 7 16 A2 45 8 16 C5 51 9 16 C7 9B 10 16 CA DA 11 16 CC 2A 12 16 CC 31 13 16 CC E 14 16 CD 0 15 16 CD D9 16 18 0 1E 17 18 9F 2E 18 19 CE BC 19 1A 1E BD 20 1A 21 CA 21 1A 27 8A 22 1A 53 6A 23 1A 5F DC 24 1A AC 83 25 1A AF 70 26 1F 73 67 27 20 E7 6D 28 20 EA 46 29 24 6B C1 30 24 96 D7 31 25 4E C2 32 25 5B FA 33 25 B8 99 34 27 6E 30 35 27 70 AE 36 27 70 D6 37 29 40 87 38 2B 58 31 39 2B 5C F0 40 2B 65 B4 41 2B 6E 7E 42 3A FB D4 43 3D F4 FF 44 3D F9 1B 45 3D FE D6 46 3E 10 47 47 3E 8 E1 48 3E E EF 49 4B DE 4E 50 4C 85 3D 51 4E 27 F9 52 4E 29 6F 53 4F A0 20 54 50 AD 58 55 50 B0 CA 56 50 B9 76 57 51 74 E5 58 52 E0 A6 59 53 28 E5 60 53 29 8B 61 54 55 53 62 54 57 A3 63 54 E3 2F 64 55 FF B6 65 70 7B 5B

@arzoo, RR = Ramp rate (28 = .5 sec) OL = On level (255 = max) ST = current status (0=off) For some reason the status of every device is being refreshed. I have never seen this. A few notes: What you see here is NOT insteon communication. It is the ISY book keeping current setting for devices. Your event viewer is set to level 1. It will not catch a command/communication that triggered this event. Try level 3. Rather than taking a screen shot, try clicking "copy to clipboard" to save the entire file. Not sure what's causing this, but if you can post a complete event viewer on level 3 we might have a better shot at figuring it out.

@DHouse02, welcome to the forum... Your EZIO8SA includes both the PLM (J2 connection) and a power supply (J3 connection). Both would be suspect due to the high temp exposure you describe. Rather than powering down the entire panel to reset things, you could try powering down the individual devices to see which is going "offline". Personally, I would start with the PLM. If you can provide the markings on the PLM (date code, firmware revision, model) we should be able to tell you how old it is.

@CoolToys, If I understand you correctly, your KPL C button was a scene responder and in turn activating the KPL A button. That is very odd unless there is another program involved (something that monitors the C button status), or possibly the buttons are manually linked or buttons are grouped. I don't have experience with button grouping. You can search for programs that might operate on the KPL A button. Manual links should show up if you do a device link table scan/compare. I am not sure how button grouping would show up. You may need to factory rest/restore the KPL to delete.

@Techman, I understand the thought process. The fact that multiple (repetitive) on commands are NOT recorded in the logs is not intuitive. Some would call it a bug (or a feature). Regardless, I would encourage everyone to try this for themselves to understand how/what events are logged. Events that show up in the "Event Viewer" do not necessarily show up in the logs. It's confusing until you gain a knowledge of how the ISY treats events and triggers. ...and I will confess to re-learning from time to time...

@Techman, I don't believe you are understanding the point that @ELA is trying to make. If you configure your Motion sensor for "ON Only" commands, the Log will show ONLY the 1st on command. Following 'ON" commands will NOT show up in the log. Please do try this for yourself... The ISY LOG resembles a state machine. If a device (relay, door switch, motion sensor) turns on 40x and off 1x the log will show 2 entries. Dimming devices are different due to the 255 different states they can attain. ELA is EXACTLY correct in saying that he doesn't have motion sensor entries in the log. The initial "on" may have been many months ago (years?) when the ISY was last re-booted.

I had a feeling that you knew about the motion sensor programming feature. I figured it was worth a shot. I often forget about the older features and "re-discover" things by looking though old posts. Good to see you on the forum again.

As @Techman indicated, the logs do not identify programs for Insteon device (I get program identifications for X10, but that's not helpful here). On the flip side, you should absolutely be able to see motion sensor On/Off activity in your logs. I don't see that type of activity in the file you posted. Actually, I can't identify a program trigger in the file. If you could post your program, we might be able to assist further.

Refer to @Geddy's post for how to implement the "Switched On/Off". Status on/off will also work for triggering the program: BSMT Sensor Program - [ID 004A][Parent 0066] If 'Motion/RF / BSMT-Sensor' Status is On Or 'Motion/RF / BSMT-Sensor' is switched Off Then Set 'Motion/RF / BSMT-Sensor' Write Changes Else - No Actions - (To add one, press 'Action')