IndyMike

Similar to @Goose66's approach - you can create a "conditional folder" use the "status" of your Ecobee thermostat to enable it. Place your trigger program in the conditional folder. This will give you a visual of when the folder is enabled (Green - Enabled, Red - Disabled). Running a disabled program will absolutely work, but I'm old and often forget that some programs SHOULD be disabled (it hurts my brain).

@gregkinney, Glad to hear you tracked the offender down. For the other forum readers, would you mind providing a few more details on how you located/isolate the PC as the problem? Intermittent problems are normally the worst. It can be extremely difficult to isolate the problem to a circuit or device.

Hi @piconut, Paul and Techman both have good points. I am however curious about two things: You stated that your devices are controlled by programs - not in scenes. The fact that the ISY "thinks" that your devices are at one lighting level when they are actually at another make it sound like you are using scenes. Could you post your programs? Normally the ISY polls all devices @3:00am. If your PLM is failing, this query will fail miserably. You will be greeted by a host of "cannot communicate with...device" when you log in. If you are not seeing these communication failures and the (!) on your devices, I would say that your PLM has not given up (yet). Have you seen signs that the ISY has tagged devices as being offline?

There are a couple of Insteon troubleshooting tools that are out of production, but can still be found. Diagnostic Keypadlinc. These can be found from time to time on ebay. I have not used one, but they use features that are similar to Houselinc Signaling Diagnostics. Pro's - It's mobile, small and non-invasive (you don't have to link it to your devices for most tests). Cons - availability/price, no graphical interface. https://cache.insteon.com/documentation/2993-222-en.pdf. Houselinc Signaling diagnostics (part of Houselinc). This I do use (infrequently). Pro's - decent graphical interface, nice tools, cheap (if you have a spare PLM). Con's - Not supported since 2016 (many devices not supported), learning curve, you need to link Houselinc to devices under test, Cost of a PLM if you don't have a spare. https://cache.insteon.com/pdf/HouseLinc-Network-Diagnostics.pdf The Houselinc package can be downloaded from: https://www.insteon.com/houselinc Also download the device definitions from: https://www.insteon.com/support-knowledgebase/tag/HouseLinc There are instructions mid way down the page on where to put the definitions XML file. Neither of these tools will tell you what/where a noise source or signal absorber is. They will identify devices that are having problems. It's then up to you to isollate the problem. Houselinc WILL MESS with link tables in your devices. Not a huge deal. When you get done troubleshooting, restore the device using the ISY. If you do not restore the device, it will not behave properly for the ISY.

Since you are having very isolated problems (3 devices out of 100's) it is likely that the noise/signal absorber is on the same circuit. If you can determine which circuit(s) are having issues, begin removing loads (chargers, UPS, TV's) until the problem cleans. If you are looking at circuits in your breaker panel - remember that the phases are the same horizontal and alternate as you go down the panel vertically. Typical Panel Layout

1500VA is a large UPS. Unless you are willing to build your own, the only thing that I know of that is currently available is the XTB-F15+ from Jeff Volp. The filter is advertised for X10, but will work for Insteon as well. https://jvde.us/xtb-f10/ Insteon is very good at bridging the phases - assuming you have dual band modules. X10, on the other hand, will have great difficulties in crossing phases without a dedicated coupler or 220V resistive path (oven, dryer). Again, not sure if the UPS is absorbing Insteon signals to the point where they are at the noise floor, or generating noise in the Insteon band (or both). It's certainly worth testing by moving one of the two to another circuit.

The UPS is a relevant piece of information. Most of them have a EMI filter that will absorb Insteon signals. Other units have been found to be noise generators. Either way it should probably be installed on a filterlinc. Check the current draw of the UPS before installing a filter. If you don't want to move your PLM to the garage circuit, you could move your UPS and equipment to that circuit as a test.

As Paul indicated, this doesn't necessarily have to be an Insteon device producing the traffic. I had an old (10+ years) Homelink receiver in my garage that was capable of Transmitting X10 - It went nuts one day and began spamming the powerline on housecode P. It happens. You could try air gapping (not resetting) your Insteon devices to see if the communication stops. Unfortunately there are two that are difficult to access. I still think your best approach is to turn off breakers one at a time until the noise goes away. If you cycle through all the breakers except the circuit the PLM is on and still have the noise - move the PLM to another circuit and check the breaker on the former.

I might agree that there is a Low risk in doing a device restore. Unfortunately it WILL NOT eliminate X10 address programming and it is likely to fail with the X10 traffic present on your system. AFAIK, the ISY cannot "un-program" an X10 address. There are devices that can (Houselinc) but you don't have them. The "easy" way to eliminate a X10 address in an Insteon device would be to perform a factory reset (eliminate the x10 address) and then restore it. I would not factory reset anything while the X10 traffic is present. As I said above, the restore is likely to fail (just as your queries are failing). You need to locate the source of the traffic and eliminate it. Since this just started happening recently, chances are that you have a device that is dying or just in an unhappy state. Cycling power may correct things. I think the best approach is to shut off breakers until the offender goes silent. As far as why Insteon devices would have X10 addresses - there was a period of time where new devices were received with X10 address from the factory. Not sure why, test escapes or whatever. It became so prevalent that "best practice" was to factory reset every device prior to installation. This was probably many years ago (seems like yesterday), not sure if it applies to any of your devices. Used devices could have had X10 addresses programmed by their previous owners. The addresses would NOT be eliminated by linking to the Eisy. They are in a section of memory that is separate from the device link table.

Wow, that's a lot of X10 traffic. That alone can bring your system to it's knees. It may also explain why wireless devices function while powerline is intermittent. The Status request isn't a normal X10 device - that's a controller function. If you don't have any X10 controllers installed (garage door, alarm panel, etc) you may have an Insteon device that's failing (although I've never seen one put out Status requests). Unless you can come up with a list of likely suspects, the normal way of isolating is to start turning off breakers until the X10 transmission stops. One you find the suspect circuit inspect/remove devices until you find the culprit. It's time consuming, but now all that hard. Best to do when family members are not around to avoid plummeting approval factors.

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.