IndyMike

@lhranch, At this point you have confirmed that the PLM can communicate with at least some devices on both phases of your electrical system (red vs green flashing). Unfortunately 0 entries in the event viewer when you switch a device on/off, sounds like a EISY problem. A typical command/response sequence looks like the following Line 1: ISY command to the PLM Line 2: PLM Acknowledge to the ISY Line 3: Device response to the command (I sent an OFF) Line 4: ISY summary of response Since you are not seeing anything, it appears the EISY isn't sending anything. Unfortunately, I am not well versed on the EISY itself. I would normally tell people to power cycle or reset their ISY994. I am hesitant to give guidance on the EISY as I don't have first hand experience. The wiki guide for the EISY is here: https://wiki.universal-devices.com/Eisy:User_Guide. The configuration screen has system check boxes for various things. Make sure that INSTEON support is checked. There are others on the forum who are very well versed on the EISY. If all else fails, you can submit a ticket to the UDI team. They are very good.

So, that's not actually a link table mismatch. As stated by LeeG, this began occurring in I2CS devices when "smart Hops" were incorporated : https://forum.universal-devices.com/topic/15336-device-links-table-corrupteds/?do=findComment&comment=130684 This is NOT the source of your problem and will likely re-occur.

Interesting - your firmware is the same as my Ver 2.5 PLM with a date code of 1619. I use both send/receive X10 on a ISY994

If you still have a X10 Transceiver active in your system it could be the Motion sensor. If you don't have a transceiver it can't be the motion sensor - no way to transceive the RF onto the powerline. Try manually activating the sensor (MS11?) to see if it transmits an address. The fact that the transmission repeats multiple times makes me think it is the Motion sensor. Unfortunately, if it's not the motion sensor, it may be difficult to find. While Insteon devices can be programmed with X10 addresses, it does not show up in the link table area. It's in a separate section of memory where the device on level, ramp rate, etc. are stored. The was a way to view that region of the device memory, but the option seems to have been removed (or I forgot how). If it is a Insteon device with an programmed X10 address, the device will send the X10 code each time it is activated. You'll need to walk around activating/deactivating devices while watching the event viewer for X10 addresses. If you find a device with an X10 address, you will need to factory reset the device to remove the address. Simply "restoring" the device WILL NOT WORK. A restore re-writes the link table. On levels, ramp rates, and x10 Addresses are not affected. Back in the day, there were numerous cases where new in box devices would have x10 addresses programed from the factory. It was advised that all devices be factory reset as step 1 during installation. Keep us posted.

@kzboray, As Michel indicated earlier, the problem exists between the PLM and the ISY. I am paraphrasing here - when the PLM is hit by multiple requests/transmissions (like a RF motion sensor) while a scene/program is being activated by the ISY a collision can result. The resulting collision corrupts the scene command and can produce the all-on/all-off or A DIFFERENT SCENE COMMAND. As I posted earlier, the differences in commands is slight. The first command below turns on 3 devices in my basement scene. The second command activates any Insteon device linked to the PLM. I can go into far more detail if needed... Wed 08/02/2023 12:10:09 PM : [INST-TX-I1 ] 02 62 00 00 27 CF 12 00 Wed 08/02/2023 09:17:29 AM : [INST-TX-I1 ] 02 62 00 00 FF CF 12 00 I had thought that the All-on/all-off command had already been removed from the PLM. In retrospect, this may not be an easy thing to accomplish. For users however, it is ABSOLUTELY the easiest path to remediation. Far easier to replace 1 PLM vs 100's of devices (stating the obvious). I do agree that Insteon devices are inappropriate for applications that are critical (pumps, gas valves) or require security (door locks, garage doors, etc). If Insteon eliminates the ALL-On command from devices, that does not make them secure. It does make them somewhat more reliable. There are some home automation technologies that are secure

@kzboray, Very curious about the "ALL ON bit IN FW" that you referenced above. Can you elaborate?

@dbwarner5, I you have a single power meter, your breaker boxes are wired in parallel - you need only 1 signalinc on the legs of 1 box. If you have two separate power meters, you are correct that you need a sginalinc on each panel. You would also need RF linking between the panels.

20A circuit with a small Refer and garage openers for a load - probably not a loading issue. My experience has been with Insteon devices with "other" loads. A HP printer/appliancelinc would cause trips in my basement when on the same circuit. Remove either and the problem went away. My Masterbuilt smoker will trip the GFCI without an Insteon load installed. If I power the smoker up and communicate with anything in the house, the breaker trips. I put a filter on the smoker to prevent trips. As I said, I don't completely understand the Aeotec repeater. I get that. I'm still happily running my 994i. I'll give up on it when it gives up on me. A friend on the forum recently shared his good experiences with YoLink. Interesting devices that tout their long communication range. Reasonably priced (requires a hub), I am looking at using sensors for my buddies outbuilding. They do have temperature sensors that supposedly will work in refrigerators.

A number of points regarding GFCI's, refrigerators, and Insteon/zwave: Refrigerators absolutely can trip GFCI breakers at both turn on and shut off. This is far more likely with older refrigerators which have higher inductive loading. GFCI's are not required for refrigerators in a Kitchen. They are absolutely required in garages and unfinished basements. I'm assuming your installation is one of these. If your refrigerator is on a dedicated circuit, a 15A GFCI is sufficient. If the circuit has branches (other outlets) a 20A circuit is required (2011 code - your location may differ). Insteon and Zwave devices/communication can CAUSE GFCI trips depending on the type of devices installed on the GFCI. The higher frequencies used by Insteon can activate "sneak paths" in devices that are interpreted as valid GFCI faults. The Zwave fault (Aetec repeater) I don't yet understand - If I plug the repeater in a GFCI and communicate via Zwave it will trip the breaker. To the points above, have a look at the devices on the circuit. If you are above 80% rated load, unplug/ move some items. It you have items that may include EMI filtering (chargers and the like), they may include sneak paths that can be activated by using Insteon communication. The idea of using the Zooz alarm is good for absolute power monitoring. No questions, you will be notified it the power fails. A similar method would be to monitor your refrigerator temperature. I've recently started monitoring my basement refrigerator temperature using a Aqara Zigbee sensor. It's accurate, low power, and is currently giving reliable communication from inside my refrigerator 35' away (still in the testing phase). Unfortunately, incorporating either Zigbee or Zwave will likely force you to upgrade from the ISY994.

@nil13, The log for your BR light shows "classic" communication problems (low hops remaining) and timeouts (repeated requests from the ISY with no response from the BR Light) After 3 timeouts the ISY declares a fault. BR Light Log: Wed 01/17/2024 06:00:30 PM : [ 1D B5 9A 1] Preparing Device 'Bedroom Swag Lights' for Restore Wed 01/17/2024 06:00:30 PM : [ 1D B5 9A 1] Device 'Bedroom Swag Lights' ready for Full Restore Wed 01/17/2024 06:00:39 PM : [INST-TX-I1 ] 02 62 1D B5 9A 0F 0D 00 Wed 01/17/2024 06:00:39 PM : [INST-ACK ] 02 62 1D.B5.9A 0F 0D 00 06 (00) Wed 01/17/2024 06:00:41 PM : [INST-SRX ] 02 50 1D.B5.9A 70.8B.4D 27 0D 02 (02) Wed 01/17/2024 06:00:41 PM : [Std-Direct Ack] 1D.B5.9A-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Wed 01/17/2024 06:00:41 PM : [1D B5 9A 0 ] Calibrating engine version Wed 01/17/2024 06:00:41 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Wed 01/17/2024 06:00:41 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Wed 01/17/2024 06:00:41 PM : [INST-SRX ] 02 50 1D.B5.9A 70.8B.4D 23 0D 02 (02) Wed 01/17/2024 06:00:41 PM : [Std-Direct Ack] 1D.B5.9A-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Wed 01/17/2024 06:00:50 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Wed 01/17/2024 06:00:50 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:00:59 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Wed 01/17/2024 06:00:59 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Wed 01/17/2024 06:01:03 PM : [1D B5 9A 1 ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00 Wed 01/17/2024 06:01:03 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB Wed 01/17/2024 06:01:03 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB 06 (00) Wed 01/17/2024 06:01:03 PM : [INST-SRX ] 02 50 1D.B5.9A 70.8B.4D 27 2E 00 (00) Wed 01/17/2024 06:01:03 PM : [Std-Direct Ack] 1D.B5.9A-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Wed 01/17/2024 06:01:03 PM : [1D B5 9A 1 ] Memory : Write dbAddr=0x0032 [7F] cmd1=0x2E cmd2=0x00 Wed 01/17/2024 06:01:03 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C Wed 01/17/2024 06:01:03 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C 06 Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:01:12 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C Wed 01/17/2024 06:01:12 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:01:21 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C Wed 01/17/2024 06:01:21 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:01:25 PM : [1D B5 9A 1 ] Memory : Write dbAddr=0x0032 [7F] cmd1=0x2E cmd2=0x00 - Failed The Log for your LR light is confusing. The ISY did not attempt to send anything to the PLM. I'm honestly not sure what the issue is here. You might try power cycling the ISY and PLM. LR Light Log Wed 01/17/2024 05:53:50 PM : [ 1B 93 CD 1] Preparing Device 'Living Room Swag Lig' for Restore Wed 01/17/2024 05:53:50 PM : [ 1B 93 CD 1] Device 'Living Room Swag Lig' ready for Full Restore Wed 01/17/2024 05:55:01 PM : [1B 93 CD 1 ] Memory : Write dbAddr=0x0032 [9E] cmd1=0x2E cmd2=0x00 Wed 01/17/2024 05:55:23 PM : [1B 93 CD 1 ] Memory : Write dbAddr=0x0032 [9E] cmd1=0x2E cmd2=0x00 - Failed

@glacier991, This is a bit late, but It may help you in the future: https://wiki.universal-devices.com/ISY-994i_Series_INSTEON:Enhanced_A10/X10 Isy 994I User Guide: https://docs.universal-devices.com/production/ISY User Guide v3.3.10 a2.pdf I still use X10 for my out PR511 outdoor motion floodlights that refuse to die after 20+ years. I also have the optional X10 module installed which allows you to name X10 devices. I doubt that's available on the Eisy. Also have some old program code to query and send "preset dim" commands. Let me know if you're interested and I can dig it out.

You may have different mechanisms at play here - The Admin console calling out the outdoor modules as "Failed" is probably a result of your 3:00 AM system query. The Query uses device direct communication. The PLM will retry communication and the ISY will retry the command up to 3 times. Your indoor devices may be controlled by scenes. Scenes are group commands that do not have any followup (no confirmation) and therefor no retries. The ISY assumes the command was executed correctly. In summary, your outdoor devices may be completely offline with the indoor devices suffering from poor communication. Can you post an Event Viewer query (Level3) on both an outdoor device as well as indoor. That may give us a clue about what is going on. If you have Accesspoints or Signalincs you could run a "3-tap" test between them and the PLM. This will hopefully verify that they are still communicating.

Are you sure that your outdoor devices didn't trip GFCI breakers? Rain events are good for that.

Not dangerous - Insecure Unreliable - As you've already learned, the 2450 is powerline only. It has issues with communication in "problem areas" (no news here). In my experience, is it also susceptible to powerline transients activating the switch contacts. Transients are typically caused by inductive and capacitive loads activating/deactivating (motor loads, florescent, etc ). Many HA devices have problems with powerline spikes activating them. The 2450 seems "more" susceptible. I used on one my sprinkler controller to de-activate the system. The garage florescents would routinely activate the 2450 even though it was behind a filter. No Security - No Insteon device is "secure". You won't find an Insteon deadbolt on the market because the protocol does not support secure communication. Your garage door remote has rolling code encryption to prevent capturing and replaying the open close commands. The 2450 does not and can be easily defeated. Susceptible to All-On commands - Most (if not all) IOLinc modules are susceptible to all-on/all-off communication. This is a command built into the Insteon protocol that activates ALL LINKED UNITs. Unfortunately, the PLM can generate this command erroneously under certain conditions. I've had several occurrences, as have others - Another All ON EVENT. If you're lucky, your lights turn on. No great harm. If you're unlucky, your fireplace, house vent fan, and garage door activate. Edit: Wanted to be sure that the 2450 activated it's contacts due to an all-on. I verified that My 2450 with firmware v.36 responds to both All-on and All-off and activates it's contacts accordingly. This would absolutely open/close a garage door during a "All On Event".

Thanks for the input on the YoLink temp/humidity sensors. I looked at them for bathroom humidity and refrigerator monitoring. Would up going with Zigbee Aqara sensors since I already had the dongle on Home Assistant. I do have a friend who is looking at door sensors for his outbuilding 400 feet away from his house. We are looking hard at the YoLink. I assume that you are using their hub - correct?

Sorry, I completely missed this post. It sounds like your chargers may have large EMI caps installed. These are rather effective at absorbing Insteon signals. It's probably not just the chargers absorbing things. All devices installed on the circuit (and near the PLM) can contribute to noise and absorption. Unplugging one device may re-establish signal levels and look like a smoking gun. In actuality, what normally happens is you have improved signal levels just enough to allow things to operate (barely acceptable signal to noise ratio). Unfortunately good, easy tools for Insteon don't really exist. The best commonly available method I know of to assess communication is by removing and/or filtering loads and then monitoring communication with the Event Viewer. I normally choose the "Show Device Links Table" as this is rather communication intensive. You are looking for transmissions where "Hops Left" is the same as "Max Hops" or possibly one lower. Retries will be signified by multiple transmissions with no response from the device. Your 2450 could be an I1 device (uses Peek/Poke rather than I2 extended comm below) in which case the communication will be FAR more intensive. Good communication (I2 Extended Comms: One read returns 8 bytes of data) Mon 01/15/2024 08:56:09 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 08:56:09 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 08:56:10 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Mon 01/15/2024 08:56:10 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 08:56:10 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 15 2F 00 01 01 0F FF 01 A2 00 53 BC 3A FF 1F 01 C2 Mon 01/15/2024 08:56:10 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Mon 01/15/2024 08:56:10 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA Mon 01/15/2024 08:56:10 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA 06 (00) Mon 01/15/2024 08:56:11 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Mon 01/15/2024 08:56:11 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 08:56:11 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 11 2F 00 01 01 0F F7 01 22 47 53 BC 3A FF 1F 01 CA Mon 01/15/2024 08:56:11 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Mon 01/15/2024 08:56:11 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 Mon 01/15/2024 08:56:11 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 06 (00) Mon 01/15/2024 08:56:14 AM : [All ] Writing 0 bytes to devices Mon 01/15/2024 08:56:14 AM : [All ] Writing 0 bytes to devices Communication Re-tries (no INST-SRX 02 50 from device) Mon 01/15/2024 09:02:44 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:02:44 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:02:53 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:02:53 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:03:02 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:03:02 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:03:06 AM : [All ] Writing 0 bytes to devices Mon 01/15/2024 09:03:06 AM : [All ] Writing 0 bytes to devices I1 Communication ( 2 Operations required for 1 byte of data) Mon 01/15/2024 09:07:41 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 28 0F Mon 01/15/2024 09:07:41 AM : [INST-ACK ] 02 62 05.4B.4B 0F 28 0F 06 SET-MSB(0F) Mon 01/15/2024 09:07:41 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 28 0F SET-MSB(0F) Mon 01/15/2024 09:07:41 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:41 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 2B F8 Mon 01/15/2024 09:07:41 AM : [INST-ACK ] 02 62 05.4B.4B 0F 2B F8 06 PEEK (F8) Mon 01/15/2024 09:07:42 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 2B A2 PEEK (A2) Mon 01/15/2024 09:07:42 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:42 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 28 0F Mon 01/15/2024 09:07:42 AM : [INST-ACK ] 02 62 05.4B.4B 0F 28 0F 06 SET-MSB(0F) Mon 01/15/2024 09:07:42 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 28 0F SET-MSB(0F) Mon 01/15/2024 09:07:42 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:42 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 2B F9 Mon 01/15/2024 09:07:42 AM : [INST-ACK ] 02 62 05.4B.4B 0F 2B F9 06 PEEK (F9) Mon 01/15/2024 09:07:43 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 2B 00 PEEK (00) Mon 01/15/2024 09:07:43 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

@DwayneA, Both your 2450 and 2443's will flash their LED's on Insteon traffic. If you have Mobilinc you should be able to activate the 2450 remotely and watch for traffic on the LED's. This may help to isolate the problem further. Just noticed that you indicated that the 2450 is also CONTROLLING your garage door. Sorry, but I think that's a very bad idea. The 2450 is not the most reliable module. It's totally devoid of security, and it's susceptible to All-on/All-off communications. I understand to desire to monitor your garage door status, but please re-think controlling it with the 2450.

@paulbates, I would think your "If 'Sump Pump Monitor..." program would be triggered anytime there is a state change in the 2450 (including an Error). Nonetheless, specifically calling the "Sump Runtime program..." from you first program is Belt and Suspenders. I can't see any downsides. I am happy to see you building error handling around the 2450. They are not the most reliable devices and are susceptible to All-on/All-off communication. It looks like you are using the 2450 for notifications NOT control. I would not trust a 2450 to control things where damage could result. Let us know how it works.

Sounds more like a communication issue. Garages can be very problematic with all the devices that are plugged into outlets (chargers, etc). Since the 2450 is a plug-in device, try moving it closer to your PLM to check communication. If it works, you need to look for signal absorbers/noise generators on the garage circuit.

This is how I query my All-On detector. Make sure you have "run at startup" selected for the program All on Poll - [ID 0023][Parent 000A][Run At Startup] If Time is Last Run Time for 'All on Poll' + 5 minutes Then Set 'All On Detect' Query Else - No Actions - (To add one, press 'Action')

@Kentinada, It sounds like you would like to include a "Not switched" for the Ring camera to activate the Else section of a program as shown below for a motion sensor -Correct? Trying to understand the problem and am unclear on the following: 1) Is the option for testing the "not switched off" unavailable for the Ring camera? 2) is the option available but does not trigger when the camera stops sensing motion? Kitchen Motion On Copy - [ID 0012][Parent 0054] If 'Motion/RF / Kitchen Mud.1 Motion' is switched On And 'Motion/RF / Kitchen Mud.1 Motion' is not switched Off Then Wait 2 seconds Set '1st Floor / SC Bar Cans' On Else Set '1st Floor / SC Bar Cans' Off

If I understand correctly, you are worried about "missing" a contact closure on the 2450 OR having it go offline. I don't see a device query anywhere. Is that contained in another program that runs at XX interval?

Snippet from the Insteon developers guide defining All-Link Groups (Group broadcast). Group broadcast is used Every time you activate a Scene. The All-on/All-off command is simply a Scene with a Group #FF (all linked devices).

I am currently using the ISY994 with firmware V5.3.4. It contains All-On/All-Off buttons on the "My Lighting" and "My Network" Tabs. Press either of these and you will get a Broadcast Group All-On/All-Off command to group "FF". For Insteon, group FF is ALL DEVICES. I checked again this AM. The following works like a charm. Hit All-On or All-Off and all of my older devices respond. My newer devices (V.45) do not. The short transmission in the event viewer is the Broadcast group command used (I used All Off) I highlighted the Group # (FF) in the command to show it was for all devices. This is not an error or deficiency. The broadcast group command is part of documented Insteon protocol and group xFF is defined as all devices. What is an anomaly is the "collision" or other event that causes the PLM to transmit the command when something else is being requested (I am assuming here). There are other serial port tools that will allow you to communicated directly with the PLM to generate to command shown below. I actually wrote one using VB years back. The good news is that you don't need them. The ISY994 can do this from the Admin Console. I'm hoping the PolyIsy and Eisy can also.

Curious that the Eisy treats your 2477s that way. I've tried my devices ranging from I1 through I2CS and the ISY994 only writes once. Are you sure you are not seeing an error or Nack when you are writing the 2477S? This could cause the ISY to write a second time when requested. As you inferred the backlight changes are written to EEprom memory on the device. There is a limit to the number of writes the device can undergo. This, I had thought, was the justification for not writing redundant information. I say redundant, because the command is device direct and is fully acknowledged by the device. There is no guessing whether the command was received. Try checking commands for On/Off. These are also device direct commands but do not involve the memory. I think you'll find that the ISY sends the command every time (my 994 does). If the Eisy does not send each command, that is an update. Not wrong, just an update.