IndyMike

@ELA, There is no hardware handshaking (RTS/CTS, dRTS/dCTS) in the PLM serial interface: https://cache.insteon.com/documentation/2413Sqs-en.pdf. I am not sure that the problem is actually in the serial interface. The serial protocol requires the modem to acknowledge the input command with a 06 (ack) or a 15 (nak). This is their approach to verifying the data and preventing device overrun. If the PLM is receiving data from the ISY when a RF transmission comes in, it should probably respond to the ISY with a NAK (or at least do nothing). Since we have never been able to trace an actual all-on event, we are speculating. It's possible that the data transfer between the ISY/PLM is successful, and the PLM gets a RF interrupt while it's processing the requested communication resulting in a all-on (Total WAG). I am not trying to start a crusade here. Many of us have lived with these issues for over 10 years. The issues can be mitigated to a large degree by following the suggestins on the UDI Wiki. I am trying to warn people about the hazards of using automation devices in critical or secure applications (fireplaces, garage doors, motors).

@glacier991, Brian's point about the capacitor is a good one - caps do go bad. Unfortunately, you should not need the Signalinc with the XTB-II. The XTB is a much better coupler than any passive device will ever be. Let's focus on the X10 signals in the event viewer - you mentioned that you have a Maxi-Contoller. Please verify that it works (activate a lamp with it), then plug it into the same outlet as the PLM and activate it. 1) If you still don't see X10 events in the event viewer we'll call this a PLM/Eisy issue. 2) If you do see events we'll need to troubleshoot your wiring/coupling configuration.

@lhranch, I understood you perfectly. If you hit the ON/OFF for devices on the ADMIN console your should have seen communications in the event viewer similar to what I showed above. You showed nothing, so I am calling this an EISY issue. Please check to make sure that the "Insteon Support" checkbox is set in the configuration menu as shown. Click save, and then reboot. If the checkbox is already set, Hit reboot to see if that corrects the issue (safer than a power cycle).

@glacier991, It's possible that you have two separate power feeds. That would normally require two separate power meters. I doubt you have three phase. Your cross phase voltage would be down in the 208VAC range since you are running at 120 degree phase (not 180). Passive couplers (and possibly the XTB) would not function correctly. If you do have separate power drops from the utility, everything you said above does apply. Insteon can be RF coupled across drops. I have not done multi phase X10 coupling in 20 years. I think Brian is likely your expert here.

@ELA, I had originally thought that the data collisions occurred on the powerline as well. We always questioned whether the CRC shown in the Insteon protocol actually existed. In recent years I have re-read some of LeeG's posts and come to the realization that collisions at the PLM/ISY interface are far more likely. This would explain how corruption could occur with a correct CRC - the PLM ADDS the CRC after the corruption. When the ISY issues a broadcast group command to the PLM it takes the form (fast on): 02 62 00 00 XX CF 14 00 (Where XX is the group number to activate) The PLM transmits the following onto the power line (per the Insteon Message Summary above) YY YY YY 00 00 XX CF 14 00 ZZ (Where YY YY YY is the PLM address and ZZ is a CRC). For a random collision on the powerline to produce YY XX and ZZ would be extremely unlikely. If we assume a collision at the PLM powerline (assume the plm address YY YY YY is intact) we still need a valid XX and a correct ZZ (crc). Still rather unlikely. Is seems far more probable that the collision (at the plm/isy interface) affects the XX group number. Assuming it was a valid group number for the PLM, it would simply append the PLM address (YY) calculate the crc (ZZ) and put it on the powerline. That's where my head is today. But then I've rethought this many times over the past 10 years. I probably need a new hobby. I had not thought about preventing devices from repeating FF (all device) transmissions. Since all devices repeat transmissions regardless of whether they are addressed, I am not sure this is possible. Absolutely worth asking the question.

I believe @Brian Hindicated that the Rev 2.7 PLM's used the same firmware as my older Rev 2.1 PLM (V.9E date code 1514). It's been around a long time.

Agreed - I had thought that this was implemented years ago at the PLM level. I'm rather slow to update hardware. I had previously implemented mitigation as recommended by: https://wiki.universal-devices.com/INSTEON_Random_All_On_Events The procedures outlined did work for me. That was many years ago. Things started popping up again about one year ago. I ran a few tests, and was astounded to find that my "new" PLM still had the command in firmware, as did most of my Insteon devices. I have no idea whether newer "hubs" have the command removed.

Good news on the I3 device. So far they are clean. Disconcerting that a 2635-222 On/Off Module with firmware v.48 came on. I'm thinking that device was produced well after my V.45 dimmers with a date code of 1616. It means we don't know much about incorporation. Wondering if there is a database expert out there who would volunteer to take on the job of tabulating susceptible devices. I'm a simple ignorant Engineer, so I'm not even sure what I am asking. Here's my data to start - https://forum.universal-devices.com/topic/41651-all-on-removed-in-what-firmware-version-of-switchlinc-dimmers/?do=findComment&comment=369748

That's a rather large oh excrement... The I3 paddle and the On/Off module reacting are news items. If you don't mind a few additional questions - 1) Did you visually verify that the devices activated? 2) If not visually, did you perform a follow-up query on the devices to make sure they actually responded? Thanks - it's been many years since this first raised it's head. We're still learning, IM

@vbPhil, Old devices will activate. We don't have great answers on newer devices. So far I3 devices appear to be immune. I tested a number of Dimmers/relays/KPL's and devices with firmware v.45 were immune. You can test your system by using the "all-on/all-off" button in the My Lighting admin screen. It's best to disable programs prior to the test. Important: Also, the ISY will ASSUME that all devices turned on/off since it issued the command (you'll see all device on in the summary screen). You need to follow with a system query to see which devices were affected.

@HL3, I didn't know the answer to your question, so I tested it using a 2450 and the same settings. The event viewer below shows Line 1: ON command from ISY to PLM Line 2: PLM acknowledge back to the ISY Line 3: 2450 responding to the ON command Line 4: ISY summary Unfortunately, the 2450 does NOT send anything back to the ISY when the relay opens after the programmed delay time. The ISY therefore leaves the status at ON. If you Query the device, the 2450 will correctly report it's status as OFF. If you are doing this in a program, it's more efficient to send an off command. It's quicker, and gets you to the same place. Sending the off command does not change the relay status if it is already off (that's what I was testing for). On a side note - have a look around the forum at reports of garage doors opening by themselves.

@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.

Thanks for the update. I have one on order

@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.