IndyMike

From a communication standpoint, I would agree that "Status" and "Control" triggers should be equivalent. The difference is programmatic, both in the triggering and the ISY knowledge of scene membership. Example below - 2 switches (A and B) in a scene. Switch A is manually activated and the following events occur: PLM receives a Group 1 broadcast On from the switch @0B.B7.F8 ISY Notes the On status for the Switch ISY notes the On Level for the Switch (this is a relay unit) The Status change triggers programs 0023 and 0093 The ISY notes that switch 16.5C.BF is a scene member and sets its' status to on @255. Note that no communication has been received from this unit. The status change in 16.5C.BF triggers program 0093 PLM receives a direct cleanup request from switch A In different words, the Status trigger does rely on the ISY knowledge of scene membership. There is actually a lot that goes on under the hood here. It's also a good reason why the ISY is rather insistent on being THE controller in the system. It can't infer the status of devices that were linked outside it's knowledge. The control trigger will operate only on the device communication itself - no inferring of scenes as related to the trigger. The ISY will still assess scene membership and status of other devices and may trigger other programs. Program A may trigger based on a control event while program B triggers due to a status event with the same device communication. Wed 05/13/2026 08:31:17 AM : [INST-SRX ] 02 50 0B.B7.F8 00.00.01 CF 11 00 LTONRR (00) Group 1 Broadcast ON from Switch 1) Switch A Turned On Wed 05/13/2026 08:31:17 AM : [Std-Group ] 0B.B7.F8-->Group=1, Max Hops=3, Hops Left=3 Wed 05/13/2026 08:31:18 AM : [D2D EVENT ] Event [B B7 F8 1] [DON] [0] uom=0 prec=-1 2) ISY Notes On status Wed 05/13/2026 08:31:18 AM : [ B B7 F8 1] DON 0 Wed 05/13/2026 08:31:18 AM : [D2D EVENT ] Event [B B7 F8 1] [ST] [255] uom=100 prec=0 3) ISY Notes On Level Wed 05/13/2026 08:31:18 AM : [ B B7 F8 1] ST 255 (uom=100 prec=0) Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0023] STS [B B7 F8 1] ST Converted values Event=100 Condition=0 prec=0 4) Program status Triggers Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0023] STS [B B7 F8 1] ST op=6 Event(val=255 uom=100 prec=0) != Condition(val=0 uom=51 prec=0) --> true Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [B B7 F8 1] ST Converted values Event=100 Condition=0 prec=0 Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [B B7 F8 1] ST op=6 Event(val=255 uom=100 prec=0) != Condition(val=0 uom=51 prec=0) --> true Wed 05/13/2026 08:31:18 AM : [D2D EVENT ] Event [16 5C BF 1] [ST] [255] uom=100 prec=0 5) ISY Notes Scene B Switch On Wed 05/13/2026 08:31:18 AM : [ 16 5C BF 1] ST 255 (uom=100 prec=0) Scene Member Switch noted as On Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [16 5C BF 1] ST Converted values Event=100 Condition=0 prec=0 6) Program Status Triggers Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [16 5C BF 1] ST op=6 Event(val=255 uom=100 prec=0) != Condition(val=0 uom=51 prec=0) --> true Wed 05/13/2026 08:31:18 AM : [INST-SRX ] 02 50 0B.B7.F8 53.BC.3A 45 11 01 LTONRR (01) 7) Switch A Cleanup to PLM Wed 05/13/2026 08:31:18 AM : [Std-Cleanup ] 0B.B7.F8-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Wed 05/13/2026 08:31:18 AM : [INST-DUP ] Previous message ignored.

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.

@Guy Lavoie , You are absolutely correct. I did not think that one through.

@Guy Lavoie , Rather than placing your motion sensors in linking mode, you can use a program to write updates to your motion sensors. The program watches for the device to "wake up", then writes the updates (thank you UD). Saves a lot of angst. I would think this would work for other battery devices as well (I have not tried it). In the past I have put all my motion sensor "Program" routines in a folder and disabled the folder. I enable the folder only when I want to write updates. BSMT Stair Sensor Program - [ID 0036][Parent 0066][Not Enabled] If 'Motion/RF / BSMT Stair.1 Motion' is switched On Or 'Motion/RF / BSMT Stair.1 Motion' is switched Off Then Set 'Motion/RF / BSMT Stair.1 Motion' Write Changes Else - No Actions - (To add one, press 'Action')

@hspindel , The instructions for the SH!)A are located here: http://www.authinx.com/manuals/X10/SH10A.pdf The indicate that you can use the device as an annunciator by pressing Unit Code-On followed by Bright or Dim on an X10 controller. I read that as the following: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Send X10 'H6/On (3)' Wait 1 second Send X10 'H/Bright (7)' Else - No Actions - (To add one, press 'Action')Not sure if the wait is necessary. Since you are trying to mimic and button controller some sort of delay may be required.

@hspindel , Let me start by saying that I'm using the ISY994. It does allow me to send the "Bright" with only a House code as shown below. The result is different and allows a delay between the two commands. I can't say for certain that this option is still available on the EISY, but UD normally keeps items like this consistent across their platforms. I also cannot say that it will help with your problem. Which specific X10 siren are you using? Wed 04/08/2026 07:58:45 AM : [ Time] 07:58:47 4(0) Wed 04/08/2026 07:58:45 AM : [ X10] H6 Wed 04/08/2026 07:58:45 AM : [X10-RSP ] 02 63 D9 00 06 Wed 04/08/2026 07:58:55 AM : [ X10] H6/Bright (7) Wed 04/08/2026 07:58:55 AM : [X10-RSP ] 02 63 D5 80 06

@hspindel , You can add a delay by executing the House Code and Dim commands separately. By sending only the "H6" command you can insert a delay and then then the "H/Bright" command as shown below. I have no clue if this is related to your issue. Difficult to troubleshoot without a Siren to test. X10 Dim - [ID 0019][Parent 0003][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Send X10 'H6/Bright (7)' (Normal Bright Method) Wait 5 seconds Send X10 'H6' (Housecode address) Wait 2 seconds Send X10 'H/Bright (7)' (Bright command) Tue 04/07/2026 09:44:22 AM : [ Time] 09:44:51 3(0) Tue 04/07/2026 09:44:22 AM : [ X10] H6 Tue 04/07/2026 09:44:22 AM : [X10-RSP ] 02 63 D9 00 06 Tue 04/07/2026 09:44:22 AM : [ X10] H6/Bright (7) Tue 04/07/2026 09:44:23 AM : [X10-RSP ] 02 63 D5 80 06 Tue 04/07/2026 09:44:27 AM : [ X10] H6 Tue 04/07/2026 09:44:27 AM : [X10-RSP ] 02 63 D9 00 06 Tue 04/07/2026 09:44:29 AM : [ X10] H6/Bright (7) Tue 04/07/2026 09:44:29 AM : [X10-RSP ] 02 63 D5 80 06

@hspindel , The EISY and plm appear to be doing their jobs. The Top 4 entries in the viewer (green) are the EISY sending the X10 commands to the PLM. The Bottom 4 entries (blue) are the PLM echoing the commands back to the EISY. Presumably the PLM put the commands on the powerline. As @Brian H and @oberkc have indicated, try moving the Siren closer to the PLM to rule out signal absorption. Not sure if you need a delay between the bright and dim commands.

@NewB , Suffice it to say that things have gotten a bit hosed (technical term). The PLM links table you posted is extremely short (21 entries). The PLM is listed as the controller for all the devices in the ID column. There are no scenes listed. It is possible that the PLM read process was interrupted. Try this a couple of times to see if you get the same result. If so, proceed with the "recovery below". The device table you posted indicates that the "Dining Vanity Mirror" is a Responder to the devices listed in the ID Column. It can't control anything. Recovery: Please verify that your PLM address is 71.18.59. Since your PLM link table is incorrect (after multiple PLM restores), you'll need to perform an ISY restore. LOOK at your backup file sizes. If you have a recent backup that is significantly different in size (from previous), it's suspect. Choose a recent backup that looks consistent. If you get socket errors during the restore (or a backup), do not trust it. Logout of the admin console, clear the cache, log back in and restart the process. When the restore ISY complete correctly, it will reboot the ISY. Log back in, turn off "writes to battery devices", and perform a "Restore Modem". This should re-write the PLM records. After the above completes, re-check your PLM records. If it's still very low (<100) post back and we'll rethink things. It's possible that that the ISY will not re-write the device link tables in step 3 (if it didn't detect a PLM change). The Only way to know for sure is to perform "link table read/compare's" on devices. You can address these individually by running a "device restore", but if there are many, it's may be easier to use the "restore devices" from the file menu.

The ISY is still sending a group 12 Off command that may be affecting things. A program is being triggered because of your "scene test". Likely not the cause of everything failing, but it's definitely complicating things. Can you open the event viewer on level 3 and perform "Link Table Read" on "Dining Vanity Mirror (4F 3A F7 1)"? Copy the event viewer to the clipboard and paste to the forum. Please also post the contents of the Link table. I'm curious if you are getting Nack responses. The following are examples of the event viewer and link tables for one of my simpler devices. I've edited the event viewer to show only the 1st two link table reads. Sat 04/04/2026 09:48:19 AM : [INST-TX-I2CS] 02 62 54 A1 F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Sat 04/04/2026 09:48:19 AM : [INST-ACK ] 02 62 54.A1.F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Sat 04/04/2026 09:48:20 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A 2F 2F 00 (00) Sat 04/04/2026 09:48:20 AM : [Std-Direct Ack] 54.A1.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sat 04/04/2026 09:48:20 AM : [INST-ERX ] 02 51 54 A1 F5 53 BC 3A 15 2F 00 00 01 0F FF 00 A2 00 53 BC 3A FF 1F 01 B8 Sat 04/04/2026 09:48:20 AM : [Ext-Direct ] 54.A1.F5-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Sat 04/04/2026 09:48:20 AM : [INST-TX-I2CS] 02 62 54 A1 F5 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA Sat 04/04/2026 09:48:20 AM : [INST-ACK ] 02 62 54.A1.F5 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA 06 (00) Sat 04/04/2026 09:48:21 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A 2F 2F 00 (00) Sat 04/04/2026 09:48:21 AM : [Std-Direct Ack] 54.A1.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sat 04/04/2026 09:48:21 AM : [INST-ERX ] 02 51 54 A1 F5 53 BC 3A 15 2F 00 00 01 0F F7 00 A2 06 29 53 3C FF 1F 01 4B Sat 04/04/2026 09:48:21 AM : [Ext-Direct ] 54.A1.F5-->ISY/PLM Group=0, Max Hops=1, Hops Left=1

Hey @NewB , The "scene test" is a nice tool, but is has some limitations. If there is activity on the powerline (motion sensors, devices activating) or Programs executing on the ISY, the PLM will exit the test. The red communication above looks like an ISY program ran and turned off group 13. It's generally best to disable programs to get consistent results. The communication above shows the ISY trying to write link records to the device @11.96.2A. The write operation times out because the device is not responding. This device should be tagged with the green "1011" in the admin console. The device isn't part of the scene that you tested, but if you have other devices with pending writes it indicates they do not have all of their links (scenes). Try resolving the pending writes to see if things resolve.