IndyMike

Paul's suggestion of checking the PLM links is a good one. It will give you a general idea of the health of your PLM. In order to get an accurate count of the PLM links, you need to keep the system quiet (disable programs, no powerline or RF activity). That's not necessary here as you are simply trying to asses if the PLM has totally dumped it's link table (10 link records = bad, over 100 link records probably ok). The 3 Inst-TX messages that you see in the event viewer sound like the Eisy is sending messages and getting no-response (timeout) and retrying the transmission. For each TX you should see an INST-ACK (plm Acknowledging) as follows. This is a query of a device that I removed from my system: Mon 03/04/2024 08:52:10 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 03/04/2024 08:52:10 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 03/04/2024 08:52:19 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 03/04/2024 08:52:19 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 03/04/2024 08:52:28 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 03/04/2024 08:52:28 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 03/04/2024 08:52:32 AM : [D2D EVENT ] Event [54 A1 F5 1] [ERR] [1] uom=0 prec=-1 Mon 03/04/2024 08:52:32 AM : [ 54 A1 F5 1] ERR 1 Please post an example of your event viewer query (level 3). If you are not seeing the ACK's, try power cycling the PLM. Also post examples of the periodic X10 communication. I never like seeing this in a system with no X10 devices. At best, it slows down insteon communication. At worst, it corrupts the powerline. Since you are seeing widespread communication issues, the most likely culprit is the PLM - or at least something near it. You could try moving the PLM, or using an extension cord to plug it in somewhere else.

If your switch is the controller of a Scene - the flashing red is indicating that it can't communicate with one (or more) of the scene members. If your switch is NOT a scene controller - the flashing red indicates that it can't communicate with the PLM. If you were to say "isn't the dual band Insteon feature supposed to eliminate this?", you would be absolutely correct. Unfortunately, nothing is perfect. There are situations where noise/signal absorption will prevent a device from hearing both powerline/rf. Looking into the HdHomeRun and Garage LED's are both solid ideas as you know that these have changed. Don't discount the possibility that you have a device that's on it's last legs (failing EMI capacitor, failing triac, etc) that is causing this (#2 on the list to check). If all else fails you'll need to identify which circuits (breaker panel) are being affected and what devices are installed - the old process of elimination. Best of luck - let us know how your experiments go.

I'm sorry, but the above statement is simply incorrect. In a "perfect home installation" with a PLM and 100 devices - activating the "Beacon Test" on the PLM would cause 50 devices to flash green (opposite phase) and 50 devices to flash red (same phase). Red flashing does not imply improper bridging.

@Techman - the document you linked is for the range extenders and it is dealing with "bridging" the phases. In that context it's rather misleading. A Red flashing LED indicates the receiving device is on the SAME PHASE as the transmitter. A Green flashing LED indicates the receiving device is on the OPPOSITE PHASE. It's a bit more clear in the On/Off Module Manual: Phase Bridge Detect Beacon/RF Range Test On/Off Outdoor Module automatically bridges the electrical phases in your home (via communications with other dual-band devices on the “other phase”). This is only important in 2-phase homes with powerline-only INSTEON products or buildings with both 2- and 3- phase circuits. The phase bridge detect beacon can also be used as an RF range test to see if your devices are within communication range. You will need at least one other INSTEON dual-band device installed. 1) Quickly tap Set button four times On/Off Outdoor Module will start beeping once per second LED will turn solid green 2) Check the LED behavior of other dual-band devices Phase Bridge Detect Beacon • If the other dual-band device is blinking green, it is on the other phase: Device provides a phase bridge to Micro module • If the other dual-band device is blinking red, it is on the same phase: Device does not provide a phase bridge to Micro module Relocate if necessary (and practical) • If the other dual-band device is not blinking: Device is not within RF range of Micro module so it does not provide a phase bridge Relocate if necessary (and practical) or add an additional dual-band device RF Range Test • RF range test: if LED is blinking: Device is within RF communication range • RF range test: if LED is not blinking: Device is not within RF communication range Relocate if necessary (and practical) or add an additional dual-band device 3) Tap Set button On/Off Outdoor Module will stop beeping Other device LEDs will stop blinking https://cache.insteon.com/documentation/2634-222-en.pdf

The AirTV and HDHomeRun are different devices with different power supplies. I have used the HDHomeRun and it wasn't problematic for me. The may have changed the power supply. 110V Led shop lights also use power supplies. They would be my main suspect. Since your problem appears intermittent, look for chargers and things that move around or are activated at particular times of day. This doesn't necessarily have to be a new device. I've had multiple solar sensors die on my post lamp. When they nosing over they tend to flood the powerline with noise. I've stopped using them and switched to a bulb with a solar sensor. The 4 tap test in the PLM is still a good troublshooting tool. Tap the button 4 times rapidly and all dual band devices in range will flash red or green. If a device does not flash, it's either old or it can't hear the PLM. Try this with your problem devices when they are working properly to see how it functions. When things stop operating correctly, try it again. The start looking for items on the circuit that could be absorbing the signal or generating noise.

If you have "hundreds" of devices that function and 3 the do not, it's probably not the PLM. Try moving one of your on/off modules to the same outlet as the PLM. Assuming that works, start looking for signal absorbers or coupling problems on your problematic circuit. You can also try running a 4-tap test on your PLM. If your devices support the test, and can hear the plm, they will flash green or red.

Glad to hear that you are not using the IOLinc to operate your furnace. Hopefully, your wall heater has over temperature protection. Please do consider the consequences of the heater being left on due to a communication error, or activating without the EISY knowing about it (All-on phenomena). This can be mitigated to a degree by polling the IOlinc regularly to test for an uncommanded on condition.

Hello @Tom Carmody, I looked up the installation instructions for your GC-TBZ48. The thermostat is completely capable of controlling the Furnace heat/cool cycles through it's hardwired interface. Since you are trying to control the appliance (Heat/Cool) using Insteon, I am assuming that you are using the GC-TBZ48 in battery mode with no hardwired interface to the appliance. PLEASE DO NOT DO THIS - There are many failure modes that can erroneously turn your appliance off or (Worse) turn it on and leave it on. It sounds like you are using a Insteon 2450 I/O Linc to activate the appliance. The 2450 is a powerline only device (not dual band) that is susceptible to erroneous turn on/off (search spontaneous All-On). There is no automation device that I would trust for this application. Please run the wiring, and install the thermostat as it was designed to be used. I'll apologize in advance if I'm incorrect in my assumptions above. Please post back and clarify if that is the case. IM

FWIW, I moved a couple of Aqara zigbee sensors to my basement refrigerator/freezer. The are working well. Top two plots are the Zigbee temp/humidity/pressure sensors. Inexpensive and have good battery life. The bottom plot is a Zooz energy monitoring plug. The spike around 6:00 pm is due to the defrost cycle. Note that the defrost may make it difficult to set alarms based on temperature.

@larryllix, I will agree that a malfunctioning device can erroneously activate devices that it is LINKED to. It cannot activate devices that are not linked. Therefor it can't be the source of problems for people that have had every device in their home activate. In that regard we should rename the problem to "All Linked devices ON/OFF". For most people, the only device in their system that is linked to a large number of other devices is the PLM. If you don't want a device to be activated by the "All Linked Devices command" don't link it to the PLM. I've done this many times with my two PLM's. The ISY and my primary PLM control my house. I have a second Test PLM that I use for experimenting. I can issue "all on" commands on the test PLM and it will not affect my home install because the devices are NOT LINKED to it. Conversely, it will turn on all devices linked to it that have not had the "All On/Off" code removed. The Insteon communications do use CRC to verify the data. It's not computed the way the white paper claims, but it does exist.

That should eliminate your home wiring and coupling. What we do not know is whether a V2.7 PLM can receive X10, OR whether the current EISY can display X10 in the event viewer. I can't help with either. We need other forum members to help here... I anyone has a V2.7 PLM that receives X10, OR a EISY - please reply to this thread.

@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