Thanks to the responders to my recent posts about communication issues related to scenes and a wireless motion sensor.

I've glanced through some of the documents available for troubleshooting communication issues. I have a few questions:

1. Does noise on one circuit affect communications throughout the entire house or just segments of it?  I'm asking this question because some scenes pass the scene test without any issues, while others fail completely, with all devices failing. Yet, some of the scenes that fail the scene test work perfectly. I also have scenes where one device out of two or three fail in the test. What exactly does that mean?

2. If the noise affects the entire house, then I can understand the idea of turning all the breakers off in a house and turning them back on one by one and running scene tests that are in the areas where the breakers are on. What if it's mixed though? What is one device in a scene is on a circuit turned off?

3. How can you tell if there is a communication failure due to noise vs. a PLM failure?

I thought dual band communication was supposed to make things like scene tests more reliable by offering a different avenue for communication between source and destination. Is this the case?

4. Are there patterns of failure visible in device communication logs that can be identified and characterized through automation? Is this type of failure analysis ripe for an AI model to simplify the process of diagnosing communication failures and fixing them? (i.e. communication failure from faulty devices, noise or a bad PLM - provide input to the model on the devices on each circuit.)

My current process for addressing communication problems is to find any plugs with switching power supplies connected to it and adding a filter module, restoring devices that have failed the scene test, and observing if I've made headway into reducing communication failures.

Thanks.

Edited August 30Aug 30 by matapan

10 hours ago, matapan said:

1. Does noise on one circuit affect communications throughout the entire house or just segments of it?  I'm asking this question because some scenes pass the scene test without any issues, while others fail completely, with all devices failing. Yet, some of the scenes that fail the scene test work perfectly. I also have scenes where one device out of two or three fail in the test. What exactly does that mean?

Not necessarily but it can. One way to approach it is to turn breakers off one at a time to see if the problem is solved. Do it in order of suspects first... things with motors, big transformers, big electronics. You can even start by unplugging those things, where possible. Takes time, note taking and discipline. 

For the devices not responding to scene test... that's the scene test doing its job.

• Have you had a major powerline incident (blackout, brown out, nearby lightening strike?)
• Are they on the same circuit?
• How old are they?
• Are they powerline only (might have to replace if Yes)
• Try restore device
• Try factory reset and restore device
   

10 hours ago, matapan said:

3. How can you tell if there is a communication failure due to noise vs. a PLM failure?

I thought dual band communication was supposed to make things like scene tests more reliable by offering a different avenue for communication between source and destination. Is this the case?

Not always. I automated my 12 volt yard lights. The transformer I bought for them, only 60watts, almost completely blinded the i3 outlet I plugged it into. I was able to move the switching function to a switch that powered the circuits and was 30 yards away from the outlet. I should note that the transformer noise ultimately killed the i3 outlet. It's been a couple of seasons since moving automation to the switch and it never misses.

These problems are not always easily discoverable or visible. It's one part thinking through "what have I changed or added", one part diagnostics: same circuit, older devices, etc. and one part discipline... come up with an order to test and move through it.

I don't remember your other post on this but an aging or damaged PLM could be responsible by writing bad data its created to the devices over and over again.

Edited August 30Aug 30 by paulbates

The Event Viewer at level 3 may also give you a clue. Like if the if the PLM had to retry a command. If the module did not ACK the message.

Older power line only modules also have to get the message. Like something is making noise, signal sucking or the PLM is on one phase of the home and the module is on the other phase and coupling is poor. Dual band also uses RF so it is not as big  problem these days. I also remember some modules may wait for a message or noise on the power line as it tried to be polite.

1 hour ago, paulbates said:

For the devices not responding to scene test... that's the scene test doing its job.

• Have you had a major powerline incident (blackout, brown out, nearby lightening strike?)
• Are they on the same circuit?
• How old are they?
• Are they powerline only (might have to replace if Yes)
• Try restore device
• Try factory reset and restore device
   

So I experienced a blackout recently. The Insteon modules are all probably from the 2015-2017 era. They are all dual band devices.

The scenes work as they should. Are you suggesting the modules have somehow failed?

So the original post here cast a wide net asking what could it be. I have experience with Insteon (an other things electronic) getting flaky and/or dying based on  significant power events.

If you can trace the difficulties you're experiencing back to starting around that time, it's possible that the power event did more than just black out and some devices were damaged. That would give you a path to focus on.

I lost Insteon (and other) devices in the past after black outs/brown outs. Some Insteon device were recoverable with a restore device. Some had to be factory reset and restored. Some had to be replaced. Afterwards, I added a whole house power conditioner to my panel.

I'm also confused in that the original other post was about scenes not working correctly?

Edited August 30Aug 30 by paulbates

Most of the Dual Band Modules including the 2413S/U PLM. 
Have a built in communications test.
Called four tap, communications or beacon test. Full users manual usually has the information.
Basically you start the test in a module then you go and look at other modules LED.
The LED patterns give you information.
Like same, opposite line phase, not seeing any signal.
On the PLM. Four taps on the set button starts the test. It should start sounding its beeper.
Then you check other modules LED patterns.
Some will not show anything as it can't directly see the test from the PLM. I use the tests on my now not  totally needed 2443 Access Points and the 2922-222 Range Extender.  As I am old school almost all single band power line only
Not extremely important. As long as one of the modules can successfully communicate the PLM to the tested module.

Many of the papers and developer documents originally in an NDA; are now found here. https://github.com/pyinsteon/pyinsteon/commit/2533494a8b13b30b2d0938c9a18afe782b740410
There maybe different revisions there.

 

Edited August 30Aug 30 by Brian H
Fix a part number

@matapan

Take a look at this manual, it describes the 4 tap test. The test should work on almost all of the dual band modules

 

2992-222 Range Extender.pdf

Edited August 30Aug 30 by Techman

Thanks Techman. What does it mean when phases are not correctly bridged?

in my setup, I have a main panel with two auxillary panels connected to the main. I had the electrician install a phase bridging device on the main panel.

I assumed after doing this there would be no issues with devices connected to different phases.

I have two dual band Switchlincs in a two gang box, one flashing green and the other flashing red. Even if they are on separate phases I expected both devices to be flashing green.

can you help me understand how to interpret this?

In the tap test. If one is flashing Red and the other one is flashing Green. They are on different phases. Red is communicating and on the same phase as the one doing the test. Green is communicating on opposite phases and bridging the commands from one phase to the other phase. The Quick Start manual posted previously should explain the test. Not as critical thees days as the older power line only modules having issues.

I have the full manual if you need it but it doesn't say much more. FYI the range extender is a 2477D LampLinc with the dimmer parts missing. Even the same FCC Number.

Edited August 30Aug 30 by Brian H

@matapan

The phase bridging device your electrician installed may or may not be designed to pass the insteon powerline signals which are at 131.65Khz.

It's best to focus on using the Insteon dual band devices to bridge both legs of your powerline. This is accomplished by the devices on opposite legs of the powerline communicating with each other via RF.

Having more dual band devices in your system creates a reliable Insteon mesh network. The best devices to use are plug in modules because they have external antennas. Devices mounted in boxes in the walls have their antennas in the rear of the device which limits their RF range.

 

 

I have also seen LED flashing sometimes confusing. Depending on the LED color indicating modules on or off. When the test is run. Depending on the phase. The LED may alternate from module status indication and test indication. 

Thanks to all that have responded to my post.

What does a device failure look like? Versus a line noise induced issue?

If a scene test has a device which consistently fails, even after device restore and it doesn't appear to be a line noise related issue, does this point to a device failure?

When a scene test has members which all fail, what does that mean? I have scenes which appears to work fine under normal use conditions whose members fail the scene test. How does one interpret this result?

 

On 9/2/2025 at 10:17 PM, matapan said:

When a scene test has members which all fail, what does that mean? I have scenes which appears to work fine under normal use conditions whose members fail the scene test. How does one interpret this result?

You can think of the Scene Test as a worst case scenario.  Which is to say that if a device passes the Scene Test you should have no problems with it in real use.  But if a device fails the Scene Test it may still function fine in real use.

Here's why:

The reason that Insteon gets better the more devices you have is that with Insteon other devices actively help bridge communication between devices.  This is done via message forwarding.  Whenever a device receives a message not intended for itself, it will resend the message on the power-line.  While this gives a message a better chance of reaching its intended recipient, if left unconstrained, every message sent would loop endlessly on the power-line as intervening devices continued to resend it because it wasn't intended for them.

To control runaway messages, Insteon limits the number of times a message can be forwarded by other devices to 3.  After the message has been forwarded three times, no device will resend it.  Now to how this relates to the Scene Test being a worst case scenario.

When the ISY/Polisy/eISY does a Scene Test, it relies on responses from devices in the scene to determine whether the test was successful.  The particular response it uses is a scene cleanup message.  Since a single scene command could involve receiving scene cleanup messages from tens or hundreds of devices, those replies are limited to only being forwarded once by other devices, while the actual scene command can be forwarded three times by other devices.

So in real use, the ISY/Polisy/eISY sends a scene command which can be forwarded up to three times.  But during the Scene Test, the ISY/Polisy/eISY depends on receiving replies that can only be forwarded once.  This means the original scene command has a much better chance of getting through to a device than the scene cleanup replies from the devices have of getting back to the ISY/Polisy/eISY.

One more thing to consider.  When a device resends a power-line message via RF, that counts as a forward.  So if a device in the scene depends on another device to bridge the power-line phases via RF, that counts as its one forward for its scene cleanup message.

In the Event Viewer on Level 3, you can tell how many times a message has been forwarded by looking at the "Hops Left".  Hops Left start at 3, and are reduced by one every time a message is forwarded.  So messages in the Event Viewer that show Hops Left=3 have not been forwarded by any other device, while a Hops Left=0 would mean the message was forwarded three times before reaching the PLM.

Edited September 10Sep 10 by kclenden

Yes the scene test is worse case. Forces the Hop count to one if memory serves me.