IndyMike

I have to agree that this is a very elegant solution. I had previously used 2 programs to test for "All OFF" in a scene (device1 and device2 and... OFF) along with a "Any On" program (device1 or device2 or .... > 0 ). I learned something today - that's a good day. My one comment would be that polling devices is not without merit depending on the communication level and criticality of the system. I would not, however, implement the polling based on a state change. The thinking here is that, if you have marginal communications, you may miss the state change from the device. Better to have a free running program that polls the devices in the scene. Case in point, my X10 floodlamps. I have a X10 booster near the PLM. Communications from the PLM to the X10 floodlamps are VERY reliable. Communications from the Flood lamps back to the PLM are less than stellar. Because of this I poll the Floodlamps at regular intervals to determine their status. The same issue can result in Insteon systems (less prevalent) depending on local PLM/Device line loading. I use the following for polling the floodlights during the day. It runs freely during the timeframe note at 15 minute intervals. Make sure "run at startup" is enabled. For Insteon, substitute a "Query scene XX" for the "Send X10 Status Request" Flood Daytime Poll - [ID 0041][Parent 0002][Not Enabled][Run At Startup] If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Flood Daytime 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)'

It's simply difficult to detect with a program. You have to add specific tests (triggers) for Fade Up/Fade Down. I don't happen to use the feature, but many of my family members do. I've been out-voted (even though I've declared our household a Monarchy).

@SMonk , this all depends on how fine you want to slice this onion... If you want to detect state changes then @dbwarner5 advice will perform well. For the ON state this will catch: Standard on (to preset level) Additional button press (to 100% level Fast ON It will not catch fade up (or analogous fade down). While these are rare, I do have guests that regularly tap and hold switches to brighten lights. After many years I have given up on educating family/friends on proper dimmer usage and have incorporated fade up/down in my programming. To be fair, they have acquiesced on a multitude of my failings... Fair is fair

@SMonk , I've used "master" KPL buttons for years to indicate/control the status of different scenes in my home. I typically use things like 1st Floor, 2nd Floor, Basement, and outside. The setup is very similar to what you described. I typically use the KPL buttons in non-toggle-off mode since I only use them to turn things off, but the concept is the same. Your query program is adding a failsafe that I never implemented. My one comment would be that this does become a maintenance item when you add/delete things from your Rec Room scenes. You will need to update your programs the monitor the device(s) status accordingly. This has tripped me up frequently over the years. If you happen to be a Home Assistant user, there is an easier solution to the programming.

Hey @aLf , The on thing that jumps out is the following error from your event viewer - I've seen this error reported on the forum, but have not experienced it myself. Seems to be a missing "REC" file for your device at address 3BDFFC. Ive seen forum posts where this error was associated with writing "Scene level commands" to devices. I haven't seen it associated with writing LED backlight levels, but that is a very similar operation. Solutions that I've seen on the forum involve deleting the device and re-adding to recreate the file structure. If you have a recent EISY backup that should restore the file system. Past that, you may want to consider opening a ticket.

@Smonk, I was referring to the Restore operation for the EISY itself (restore from backup). This is similar to restoring any computer system from backup. The difference in this instance is that your Insteon system is "distributed" with software in the ISY, PLM, and your devices. The ISY does a good job of coordinating things, buy they can get out of synch. Here's the scenario - I backup the ISY to file At this point the backup file contains a copy of all device tables I modify a device by adding (or deleting) it from a scene I restore the ISY from the backup in step 1 (backup now invalid). The ISY now believes the device in step 3 has a "different" link table. Any future operation (restore, add to scene, remove from scene) will cause the scene links to be overwritten. The confusing factor here is that the device will operate normally (it has the correct link table) until you restore/add to a scene/ remove from a scene after which the link table will be overwritten with outdated information. Step 1: Backup ISY Step 2: contents of "test device" vs ISY table (things match") Step 3: Add Device to scene - ISY and Device table match (links added) Step 4: Restore ISY from earlier backup (backup now outdated) Step 5: After restore, ISY device table no longer matches actual device. The device will operate properly, but future operations (add to scene, restore, etc) will overwrite links after the ISY end of record address (x0FD8)

@aLf , the phenomena that @hart2hart is referring to is actually "wear out" of the memory location. If this is the case, a reset would not work. It's always possible that the devices have been "upset" by a power anomaly. A quick power cycle could help. It's also possible that the devices are not correctly linked after your transition to the EISY. If you could provide a Level 3 Event Viewer capture of the communication when you manually change the backlight we may be able to help diagnose. The following is a capture from changing one of my 2477S to max backlight [7F] and back to min [00]. Memory location is 0x0264. Sun 05/10/2026 06:24:44 AM : [All ] Writing 1 bytes to devices Sun 05/10/2026 06:24:44 AM : [INST-TX-I2CS] 02 62 1F BE 7A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Sun 05/10/2026 06:24:44 AM : [INST-ACK ] 02 62 1F.BE.7A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Sun 05/10/2026 06:24:45 AM : [INST-SRX ] 02 50 1F.BE.7A 53.BC.3A 2F 2F 00 (00) Sun 05/10/2026 06:24:45 AM : [Std-Direct Ack] 1F.BE.7A-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sun 05/10/2026 06:24:45 AM : [INST-ERX ] 02 51 1F BE 7A 53 BC 3A 15 2F 00 00 01 0F FF 00 A2 00 53 BC 3A FF 1F 01 B8 Sun 05/10/2026 06:24:45 AM : [Ext-Direct ] 1F.BE.7A-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Sun 05/10/2026 06:24:45 AM : [1F BE 7A 1 ] Memory : Write dbAddr=0x0264 [7F] cmd1=0x2E cmd2=0x00 Sun 05/10/2026 06:24:45 AM : [INST-TX-I2CS] 02 62 1F BE 7A 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C Sun 05/10/2026 06:24:45 AM : [INST-ACK ] 02 62 1F.BE.7A 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Sun 05/10/2026 06:24:46 AM : [INST-SRX ] 02 50 1F.BE.7A 53.BC.3A 2F 2E 00 (00) Sun 05/10/2026 06:24:46 AM : [Std-Direct Ack] 1F.BE.7A-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sun 05/10/2026 06:24:46 AM : [All ] Writing 0 bytes to devices Sun 05/10/2026 06:25:31 AM : [All ] Writing 1 bytes to devices Sun 05/10/2026 06:25:31 AM : [INST-TX-I2CS] 02 62 1F BE 7A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Sun 05/10/2026 06:25:31 AM : [INST-ACK ] 02 62 1F.BE.7A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Sun 05/10/2026 06:25:31 AM : [INST-SRX ] 02 50 1F.BE.7A 53.BC.3A 2F 2F 00 (00) Sun 05/10/2026 06:25:31 AM : [Std-Direct Ack] 1F.BE.7A-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sun 05/10/2026 06:25:31 AM : [INST-ERX ] 02 51 1F BE 7A 53 BC 3A 11 2F 00 00 01 0F FF 00 A2 00 53 BC 3A FF 1F 01 B8 Sun 05/10/2026 06:25:31 AM : [Ext-Direct ] 1F.BE.7A-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 05/10/2026 06:25:32 AM : [1F BE 7A 1 ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00 Sun 05/10/2026 06:25:32 AM : [INST-TX-I2CS] 02 62 1F BE 7A 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB Sun 05/10/2026 06:25:32 AM : [INST-ACK ] 02 62 1F.BE.7A 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB 06 (00) Sun 05/10/2026 06:25:32 AM : [INST-SRX ] 02 50 1F.BE.7A 53.BC.3A 2F 2E 00 (00) Sun 05/10/2026 06:25:32 AM : [Std-Direct Ack] 1F.BE.7A-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sun 05/10/2026 06:25:32 AM : [All ] Writing 0 bytes to devices

@SMonk, Pauls' scenario is certainly plausible. God knows I've thumb fingered setting often enough and turned scenes off (0%) when I intended on. Unfortunately, from your description, the error would need to occur on multiple 2477S's. Since a restore did not work, the eisy believed the switch programming was correct. The only thing I can come up with is a eisy restore from a backup that dated prior to the switches being added to the original scene. The EISY device table would not have had the links to that scene. Adding the devices to a new scene would have over written the scene that the EISY didn't have knowledge of. Have you performed any EISY restores lately?

As others have indicated, the ISY wants to be THE controller in the system. It maintains an image of each device memory table. You can view a device link table by right clicking the device in the Admin tree and selecting: Diagnostics/Show device links table: reads from the physical device Diagnostics/Show ISY Links Table: displays what the ISY believes the device link table should contain (the image) The following is a table comparison (read vs image) for a test lamplinc I have. It contains only two links and an "End OF Record" entry @0FE8. If I link the device to my houselinc installation (without informing the ISY), the ISY994 now shows mismatched records when performing a table read/compare. Further performing an ISY scene add on this device Does overwrite the link records to the Houselinc install (links to 58.4A.A5 overwritten). This is because the ISY image shows the previous END OF Record being @0FE8 The ISY994 will allow you to import links contained in a Device, HOWEVER this must be done when you 1st add the device to the ISY. After that, the ISY wants to be in control. Manual links (outside the ISY knowledge) will be overwritten when adding scenes or restoring devices. Lamplinc added with existing links to Houslinc PLM @58.4A.A5. ISY PLM @53.BD.3A correctly added afterward.

@kvolger , glad that you've thought through a few of the failure scenarios. It sounds like you are comfortable with the system risks. I hope things work well for you.

Your description of the pumping system concerns me. It sounds like you are transitioning from a dedicated system with hardwired sensors/safeties to a distributed system with communicating sensors/safeties. This doesn't sound like something that I would trust to home automation devices. At least not without backup sensors and over-rides (yes I've been burned). The 2450 IOLinc may seem like a handy solution, but it is powerline only communication (prone to communication errors) and will respond to Insteon All-on errors. I am not sure that the All-on matters if you are using it in a "sensor only" configuration. The micro ON/OFF switches are more recent technology and MAY be immune to All-On/OFF commands. Please do test this. Beyond the above, you need to think through failure modes: What happens if an micro on/off doesn't receive communication and doesn't turn on/off? Same for the 2450 - it doesn't transmit the contact open/close. What happens if the system is running and power fails? What happens when power is restored (many modules will default to the last power state). Sorry to be Debbie Downer here, but I'm concerned the "criticality" of this system. What happens when something doesn't turn on/off as planned? Is it a minor inconvenience, a moderate cost, or a major explosion? If the answer is an inconvenience, then by all means proceed. If other, then not as much.

I'm glad I'm not the only one. It's really bad when things suddenly break for some unknown/unfathomable reason. It's worse when I realize that I AM THE Reason. Like @dbwarner5, I use the find/replace feature often. I also disable programs and folders to prevent things from running unintentionally. Stuff still happens. More and more I am finding that my Home Assistant "test" programs are being re-enabled (me again) and running when they shouldn't. I have to say that UD did things right with their program/folders/variable organization setup. I wish HA would adopt something similar.

I just tried this on my ISY994 and it works as expected (I have not used the "Init to" previously). Since you have other programs working properly, I'm going to guess that your program didn't save properly for some reason. When this has happened in the past I've found it easiest to simply delete the program and start over. Do NOT copy the program. The visual representation will look correct, but the XML may be incorrect.

When in doubt, re-boot?

@pinlawr , thanks for the update. Please keep us posted as things go forward.