IndyMike

@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')

@Algorithm, Ive been bitten by this a number of times in the past. Typically occurred after a power outage. I don't have a solution for the button being re-enabled. What I can offer is an easy method for updating motion sensors (actually this is all UDI). Some time back UDI gave us the ability to write updates to sensors when they detect motion - BSMT Sensor Program - [ID 004A][Parent 0066] If 'Motion/RF / BSMT-Sensor' is switched 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') Works like a charm. I normally keep the program(s) disabled and re-enable when I notice a pending write... I also keep the automatic writes to battery devices disabled (until they reset).

This works for Insteon motion sensors. Does it apply to Zigbee/Z-wave?

@paulbates - My apologies, I misunderstood your comment. The program that @Michaelv posted was already using scenes. From his comments my understanding was that the program was not triggering correctly for some reason.

75 devices in a scene is not a problem. Your "My Lighting" is essentially a scene. Your ISY queries it every night at 3:00 AM using the Schedule 1 program (unless you have modified it). Schedule 1 - [ID 0005][Parent 0002] If From 3:00:00AM For 10 minutes Then Set 'My Lighting' Query Else - No Actions - (To add one, press 'Action') Alternatively, I would not create a large scene and assign a Device as a controller. The device (switchlinc, KPL, Etc) will execute the Scene ON command that I posted above, but will then perform "group cleanup commands" to every device in the scene. For a large scene, this can take quite a long time. When your device flashes red, it is trying to tell you that it was unsuccessful in communicating with a scene member. A device can only be a controller for 1 scene (except for the PLM). A device may be a responder to many scenes.

I'm sorry, but I respectfully disagree... The ISY uses a rather specialized method of controlling scenes - it does not perform "group cleanup commands". In order words, it does not request scene devices respond to the scene command. The ISY ASSUMES that the scene command was properly received and acted upon. The following is a copy of the event viewer when I turned off my basement scene (group 00.00.27). There are 17 devices in the scene. NO status or confirmation is requested from any of the devices. Sat 07/06/2024 09:37:22 AM : [INST-TX-I1 ] 02 62 00 00 27 CF 14 00 ISY Command to PLM Sat 07/06/2024 09:37:22 AM : [INST-ACK ] 02 62 00.00.27 CF 14 00 06 LTOFF-F(00) PLM Acknowledge I could just as easily have replaced group 00.00.27 with 00.00.FF and turned on every device in the house. As a result, there should not be an issue with "chaining" multiple scene commands together. There is no return traffic that would create a collision. Device Direct commands do request a status. As a result, there is a possibility of a collision. Older discussion of scenes and retries: https://forum.universal-devices.com/topic/11690-understanding-retries-in-isy/

@MrEstateManager, I looked though the PLM record file you provided hoping to understand what happened. I am no smarter as a result. I imported your XLM table to Excel (left side) and then converted to HEX (right side) below What I did learn - You have 65 link records - they are all to unique devices. All of the records are for group 0, with the PLM as the controller (flag E2). There are no devices listed as a controller for the PLM (flag A2) and no scenes listed. The device that you showed above as non-responsive (Entry cans @40.CF.51) is included in the table. This is likely a I2CS device that is missing the PLM link and refuses to respond as a result (security reasons). Because you have no scenes listed in your PLM, you will not be able to control them. Because you have no devices listed as controller for the PLM (flag A2), no devices will be able to control the PLM (can't fire programs with a button press, device initiated on/off tracking won't work). In short - that's a very messed up PLM. The second set of figures shows my plm with various groups (scenes) and control records from different devices. If I had to guess, I'd say that you had a partial PLM restore and possibly an erroneous backup. You could go back through your older backups and try to find a good one to restore from (ISY Restore). You may need to restore your PLM after the ISY Restore. https://forum.universal-devices.com/topic/3999-how-do-i-replace-my-isyplm/?do=findComment&comment=30953 In any event, the most expedient route would be to follow @hart2hart's advice and create a support ticket.

So you posted a program and logs from actions that you knew WOULD NOT WORK. Thanks for including that little detail in your post. Have a nice life.

Your program is written to trigger on "FAST ON". You are executing a standard "ON" at the switch.

@John Chen, the simple answer is "NO". In my opinion, there is nothing better than the ISY for managing Insteon devices. Like you, I use the ISY994. When I get to the point where I need to replace it, I'll upgrade to the current Universal Devices product (likely the EISY). I use Home Assistant for managing my Z-Wave and Zigbee devices. I would not suggest using Home Assistant to replace the ISY for Insteon. From what I understand, you will loose a lot in terms of scene management. I have no doubt that Universal Devices will be able to solve your issue - they really are quite good.

@John Chen, I do not use the web portal or google Home. I can't troubleshoot this from my end. Your description definitely points to a problem with the google home connectivity. I did not realize that affected links in hardware devices. I have been seeing an increase in the number of posts about devices that mysteriously become unavailable and require re-linking. You may have uncovered the cause. My apologies for the short hand. UDI = Universal Devices Inc. You can submit a support ticket here : https://www.universal-devices.com/contact-us/. Please do make sure to inform Universal Devices of this issue. It likely affects many others.