IndyMike

Right with you my friend... I can't begin to remember what I've forgotten. Google is my friend... The Wiki link that @Techman posted offers useful techniques for mitigating the issue. I have 7 motion sensors and Many KPL's. Since implementing the mitigations, I'm down to around 1-2/year events. There are a number of posts around that detail All-On detectors. Having said that, I can't locate any. I use a 2457D2 LampLinc located next to my PLM. The LampLinc is linked to the PLM, but is not part of any scene or program. The thinking here is that the only way this device turns on is if an All-ON event occurred. I use a program to poll the device every 5 minutes. If the program sees an ON status, it shuts down MyLighting. Note that this is not foolproof. It assumes that the LampLinc will be turned on during an even. There have been reports of "partial" all-on events. The protocol supports commands to any scene #, so it is certainly possible to have random scenes activated. Query 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') Shutdown Program All on response - [ID 0013][Parent 000A][Run At Startup] If 'All On Detect' Status > Off Then Set 'My Lighting' Off Else - No Actions - (To add one, press 'Action') Another theory is that the events became prevalent after the introduction of the 2413S PLM with RF. The RF interface allows MS's and other devices to bombard the PLM out of synch with the powerline. I have tried disabling the RF receiver on PLM's with inconclusive results. In the end, I can't reliably re-produce the problem, so I can't reliably say that I've fixed it. In other words, I got tired and lost interest. It seems that some of the older posts on All-On events have been removed or locked. Here's a walk down memory lane for anyone interested. how-to-test-insteon-devices-for-all-on-vulnerability all-on-removed-in-what-firmware-version-of-switchlinc-dimmers all-on-all-off-incidents considering-disabling-isy-due-to-all-on-bug-process-to-remove-it another-all-on-event devices-turn-on-or-off-unexpectedly random-all-on-event

In a couple of words - yes and yes. No one has actually documented an All-On collision. There are numerous theories about how and where the collisions occur. My personal favorite is that they occur at the serial interface between the ISY and PLM. As far as I know, current PLM still contain the all-on command. Many modules have had the all-on response removed, but there is no clear listing of devices/firmware revisions. You can test to see which of your devices is susceptible by issuing an All-On command from the admin console - All-On Susceptibility Testing

@Michaelv, I divided the results of one of your Scene tests into sections to make the results a bit easier to follow. This is shown below. You appear to have at least 3 issues with your system. Only 1 of your scene members is responding to the scene test. Section 1 shows Device responding to the group status request, and section 2 shows the summary. The remaining devices (8) appear to be having communication issues. The scene test can actually be rather difficult to pass. I have a number of "problem" devices that work acceptably in scenes, but fail the scene test. Since you can restore/read link tables from these devices, they are communicating reasonably. Just not good enough to pass a scene test. You may want to look at location differences between the device that passes and the others. Section 3 is odd. I have never seen this before in relation to a scene test. If may not actually be related to the test itself, but rather triggered by it. Since the section is complaining about a missing link record for devices that you just restored (including 51.AA.15 which passed the test), I can only assume that the missing record is in the PLM or ISY. I'm with @paulbates on this one - open a ticket with UDI. Section 4 is not part of the Scene test. You likely have "automatic writes" enabled. The ISY is trying to update links on devices with the 1010. The writes are being triggered by the scene test. Try turning off "automatic writes" to simplify things. Unfortunately, the ISY is unable to update all 4 of the devices. This is a far more serious communication issue than the scene test. The PLM and ISY both retry commands during link table updates. If the update fails, you have a rather severe communication issue. Last thought - you appear to have communication issues with a number of devices. If these devices are on the same circuit, you may have a local problem. If they are wide spread, you may have an issue near the PLM. Section 1: ISY is requesting group members update their status. Only the device 52.AA.15 responds Sat 12/14/2024 06:01:06 PM : [GRP-RX ] 02 61 2C 13 00 06 Sat 12/14/2024 06:01:07 PM : [INST-SRX ] 02 50 52.AA.15 70.17.C1 61 13 2C LTOFFRR(2C) Sat 12/14/2024 06:01:07 PM : [Std-Cleanup Ack] 52.AA.15-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Section 2: ISY summary showing device 52.AA.15 has passed test <html><font color="red">----- 3rd Floor lights Off Test Results -----</font></html> <html><font color="red">[Failed]</font> 3rd Floor Pendant Lights (39 85 F1 1)</html> <html><font color="red">[Failed]</font> 3rd Floor Bath Fan Light (38 EA 62 1)</html> <html><font color="red">[Succeeded]</font> 3rd Floor Daybed Area Lights (52 AA 15 1)</html> <html><font color="red">[Failed]</font> 3rd Floor Bath Recessed Light (41 99 B5 1)</html> <html><font color="red">[Failed]</font> F-Loft All Off (44 C8 17 6)</html> <html><font color="red">[Failed]</font> 3rd Floor Bathroom Mirror Fix (33 48 89 1)</html> <html><font color="red">[Failed]</font> 3rd Floor Desk Spots (70 BC A 1)</html> <html><font color="red">[Failed]</font> 3rd Floor North HVAC Room (70 F0 25 1)</html> <html><font color="red">[Failed]</font> 3rd Floor Plan Table Spots (70 C3 23 1)</html> <html><font color="red">----- 3rd Floor lights Off Test Results -----</font></html> SECTION3 The following is Not Normal: I am guessing that the ISY is saying that the either the ISY or the PLM does not have a responder link. This should not happen. Consult UDI – a ISY/PLM restore may be required. Sat 12/14/2024 06:01:15 PM : [INST-TX-I1 ] 02 62 00 00 2C CF 13 00 Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 52 AA 15 1 not found Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 44 C8 17 6 not found Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 39 85 F1 1 not found Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 70 C3 23 1 not found Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 33 48 89 1 not found Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 41 99 B5 1 not found Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 38 EA 62 1 not found Sat 12/14/2024 06:01:15 PM : [LINK-INFO ] Link for responder 70 F0 25 1 not found Sat 12/14/2024 06:01:15 PM : [INST-ACK ] 02 62 00.00.2C CF 13 00 06 LTOFFRR(00) Sat 12/14/2024 06:01:15 PM : [Ext MH ] Unexpected Ack imCmd=62 cmd1=LTOFFRR 0x13 Section 4: ISY Attempts to write updates to devices in the following. This is unrelated to the scene test. Devices 39.86.90, 10.9C.17, 10.91.24, and 4B.ED.C1 all fail updates. Poor communication to these devices. Sat 12/14/2024 06:01:16 PM : [INST-TX-I2CS] 02 62 39 86 90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Sat 12/14/2024 06:01:16 PM : [INST-ACK ] 02 62 39.86.90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Sat 12/14/2024 06:01:25 PM : [INST-TX-I2CS] 02 62 39 86 90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Sat 12/14/2024 06:01:25 PM : [INST-ACK ] 02 62 39.86.90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Sat 12/14/2024 06:01:29 PM : [10 9C 17 1 ] Link 11 : 0FA0 [A20170A3DBFF1F01] Writing [A20170A3DBFF1F01] Sat 12/14/2024 06:01:29 PM : [INST-TX-I1 ] 02 62 10 9C 17 0F 28 0F Sat 12/14/2024 06:01:29 PM : [INST-ACK ] 02 62 10.9C.17 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:01:38 PM : [INST-TX-I1 ] 02 62 10 9C 17 0F 28 0F Sat 12/14/2024 06:01:38 PM : [INST-ACK ] 02 62 10.9C.17 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:01:47 PM : [INST-TX-I1 ] 02 62 10 9C 17 0F 28 0F Sat 12/14/2024 06:01:47 PM : [INST-ACK ] 02 62 10.9C.17 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:01:51 PM : [10 9C 17 1 ] Link 11 : 0FA0 [A20170A3DBFF1F01] *Failed Writing [A20170A3DBFF1F01] Sat 12/14/2024 06:01:52 PM : [10 91 C 1 ] Link 11 : 0FA0 [A20170A3DBFF1F01] Writing [A20170A3DBFF1F01] Sat 12/14/2024 06:01:52 PM : [INST-TX-I1 ] 02 62 10 91 0C 0F 28 0F Sat 12/14/2024 06:01:52 PM : [INST-ACK ] 02 62 10.91.0C 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:02:01 PM : [INST-TX-I1 ] 02 62 10 91 0C 0F 28 0F Sat 12/14/2024 06:02:01 PM : [INST-ACK ] 02 62 10.91.0C 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:02:10 PM : [INST-TX-I1 ] 02 62 10 91 0C 0F 28 0F Sat 12/14/2024 06:02:10 PM : [INST-ACK ] 02 62 10.91.0C 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:02:14 PM : [10 91 C 1 ] Link 11 : 0FA0 [A20170A3DBFF1F01] *Failed Writing [A20170A3DBFF1F01] Sat 12/14/2024 06:02:14 PM : [10 91 24 1 ] Link 12 : 0F98 [A20170A3DBFF1F01] Writing [A20170A3DBFF1F01] Sat 12/14/2024 06:02:14 PM : [INST-TX-I1 ] 02 62 10 91 24 0F 28 0F Sat 12/14/2024 06:02:14 PM : [INST-ACK ] 02 62 10.91.24 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:02:23 PM : [INST-TX-I1 ] 02 62 10 91 24 0F 28 0F Sat 12/14/2024 06:02:23 PM : [INST-ACK ] 02 62 10.91.24 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:02:32 PM : [INST-TX-I1 ] 02 62 10 91 24 0F 28 0F Sat 12/14/2024 06:02:32 PM : [INST-ACK ] 02 62 10.91.24 0F 28 0F 06 SET-MSB(0F) Sat 12/14/2024 06:02:36 PM : [10 91 24 1 ] Link 12 : 0F98 [A20170A3DBFF1F01] *Failed Writing [A20170A3DBFF1F01] Sat 12/14/2024 06:02:36 PM : [INST-TX-I2CS] 02 62 4B ED C1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Sat 12/14/2024 06:02:36 PM : [INST-ACK ] 02 62 4B.ED.C1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Sat 12/14/2024 06:02:45 PM : [INST-TX-I2CS] 02 62 4B ED C1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Sat 12/14/2024 06:02:45 PM : [INST-ACK ] 02 62 4B.ED.C1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Sat 12/14/2024 06:02:54 PM : [INST-TX-I2CS] 02 62 4B ED C1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Sat 12/14/2024 06:02:54 PM : [INST-ACK ] 02 62 4B.ED.C1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00)

Understand completely. That's why I asked the question. Insteon can work on a 3 phase system. Unfortunately, PLM's will not be able to communicate X10 on 3 phase. The older X10 CM15a interfaces would communicate @120 degrees for 3 phase applications. On the flip side, I have 3 phase motor controllers that operate off split single phase 240V power. Again, that's why I asked for clarification on the house/fan power.

The XPF is a rather capable in-line filter. It's rather large, normally requires a 3-gang box to install. The XPNR is a shunt filter. As such, it's rather small and does not have a specific current specification. It will absorb both Insteon and X10 signals. It can be effective if placed near the offending device with a good line length back to the electrical panel (higher impedance). You mentioned that your fan was 3-phase. That's rather unusual for a home install. Is your home also 3-phase, or is this a 240V powered fan with a 3-phase inverter? I ask because Insteon PLM's are not configured to provide X10 in a 3 phase installation (120 degree phase separation).

You are correct that there is no direct method to detect a "fast on" in home assistant. @Guy Lavoie's technique is the best way of informing HA of a fast on event. EDIT: Incorrect - See @shbatm response below Fast on events will always send a device to 100%. If your normal On/scene operation is less than 100%, you can trigger on the 100% level as a FAST ON. Using the "entity" trigger, the following will interpret a 100% ON as a fast on. The 100% level is 255, so you are testing for something above 254. Yaml: alias: Test Fast ON description: "" triggers: - trigger: numeric_state entity_id: - light.bsmt_fam_cans attribute: brightness above: 254 conditions: [] actions: [] mode: single

FWIW: The following Reddit post is related to Enphase communication issues due to a powerwall installation. The noise spectral plot shows noise peaks in/around the 120k to 130KHz region (X10/Insteon range). The noise appears to be Worse when the Powerwall is lightly loaded. As others have noted, not an easy problem to solve. Caveats - this is a power from 2019. Things may have changed on newer Powerwall versions/firmware updates. https://www.reddit.com/r/Powerwall/comments/sr2j2l/powerwall_and_line_noise_affecting_enphase/?rdt=64923

@Bladerunner, something still feels a bit odd here. The fact that you have two different brands on the same circuit with the same problem with BRT/DIM but not ON/OFF. It's possible that your problem X10 switch is a different "vintage" than the others that function. X10 had some supply problems over the years and wound up re-designing their units with no change to markings (other than date codes). These were referred to as soft-start dimmers. While this is possible, I don't remember a particular problem with Dim commands and have no explanation why your X10 controller would function. I'm wondering if your dim commands from the PLM are going though the ACT CR234. Some repeaters only place the 2nd X10 transmission on the opposite phase (all commands are sent twice). That could affect how your dimmers react. You mentioned that you had a 16 button X10 controller that worked well with these lights. If this is a HR12a, could you move the transceiver to the same outlet as the PLM as a test? Wondering if it will exhibit the same issues when the signal is forced to take the same path through your system. If it's more convenient, you could move the PLM to the same phase as the problem circuit to see if that corrects the problem.

Good sleuthing, I'm guessing this isn't your 1st rodeo. I didn't understand that the On/Off commands work but the dim commands don't. That is odd. I don't know of any theory that supports loss of dim/brt because of noise or loading. I'm thinking I sent you down a bad path there. I do vaguely remember having problems with Leviton dimmers on my old CM11a. If I remember correctly, it had something to do with the resume dim feature. Do you have a idea of which model dimmers work and which models don't? I can remember some of the higher end ACT, PCS, and Leviton dimmers had programmable features. Some could be set to emulate a traditional switch.

@Bladerunner, I have tried both the A10 and X10 generic types on the ISY994. I don't see a difference. One curious thing that I do NOT see in your event viewer - a response from the PLM. If you look at my log below, you'll see the "X10-RSP" from the PLM confirming the command. This could be a difference between your EISY and my old ISY994, but it's something to check out. Sat 11/09/2024 09:53:48 AM : [ X10] M3 Sat 11/09/2024 09:53:48 AM : [X10-RSP ] 02 63 02 00 06 Other than the fact that there is no PLM response, the commands look correct. You stated that the F2 command works but the G14 doesn't. If these are difference end devices, I would suspect communication issues. I'm assuming you've been using X10 in your system for some time. Any chance you lost your phase coupling/repeater. Any new signal absorbers - it is the season when all the Christmas decorations start coming out, wreaking havoc on us HA types.

After a little looking, I found an old LM465 lamp dimmer in the spare parts bin. Added it to the ISY as a Generic A10 device @address M3. Home Assistant brought the device in as a Switch - HOWEVER, it does allow me to send brighten/dim commands to the ISY node. The following script correctly brightens the LM465 (as shown by the ISY event monitor). So much for my educated guesses - always test Home Assistant script: alias: X10 Bright sequence: - action: isy994.send_node_command target: entity_id: switch.a10_device data: command: brighten description: "" ISY Event Monitor: Sat 11/09/2024 09:53:48 AM : [ X10] M3 Sat 11/09/2024 09:53:48 AM : [X10-RSP ] 02 63 02 00 06 Sat 11/09/2024 09:53:48 AM : [ X10] M3/Bright (7) Sat 11/09/2024 09:53:49 AM : [X10-RSP ] 02 63 05 80 06

Your X10 dimmers are most likely 1-way (receive only) devices. There is no "status" or "query" available. There were very few X10 2-way units produced. Again - I do not have any X10 dimmers to verify. I did code a quick script for one of my Insteon Dimmers using the Visual Editor in HA. Two tricks in the following: For action, you need to select "Perform action ....." Do not use the "Device" or "Light" entries that are available. For Target - Select "entity". This will present a list of ISY entities on your system. Choose your X10 unit Command will bring up a list of commands available for your device. I chose "Brighten" The following works for Insteon devices. The Yaml code generated by the visual editor is shown below. There are some differences from your code (I'm not a Yaml master). The most significant item may be that your entity is labeled as a "switch". Chances are it will be On/OFF only. Not sure if there is a way for the X10 devices to come over as a "light" which would allow dimming. Yaml code generated: alias: Brighten sequence: - action: isy994.send_node_command target: entity_id: light.bsmt_fam_rm_sconce data: command: brighten description: ""

@Bladerunner, I do not have any X10 dimmers to verify, but Insteon dimmers do show "levels". Your logs will only reflect on/off. However there is an entity associated with Insteon dimmers that will show the current on level. Go to Settings/Devices and Services/Universal Devices ISY xxxx. Click on Entities and search for a dimmer on your system. The following is what I have for one of my 2477D's. Note that the dim # is 102 (102/255 = .4). You can use the dimmer level in automations as a trigger or a qualifier.

@CoolToys, Have a look at your motion sensor for the guest area. It can disable/interrupt your bedtime program if it fires at the wrong time. I just recently replaced batteries on two MS I sensors that were behaving badly (no low battery set). Aside from that, when programs fire without a trigger or re-enable themselves I start thinking about SDcards and the like. A program should Never spontaneously enable itself (you can enable a program with another program). I have no experience with the Eisy, so I will bow to others who do.

@gempro, not sure if you have been able to resolve your issues. Your event log did show an interesting detail that was not part of the scene test. After the test completed, the ISY attempted to write an update to your 46.2F.CA device (RemoteKP.F). This update failed with a Nack response from the KPL. The Nack indicates that your new PLM is not currently linked to this device. It looks like with update may have been automatically triggered after you performed the scene test. In a system that is having communication issues, that can complicate things. Try turning OFF the automatic writes (screen capture below) and restoring this device. If the restore completes successfully, perform a link table read/compare to double check. Continue in this manner with your other devices. If the restore does not work, come on back and we can develop a plan B. <html><font color="red">----- Keypad LED F Test Results -----</font></html> <html><font color="red">[Failed]</font> KeypadF (44 7D D7 6)</html> <html><font color="red">[Failed]</font> RemoteKP.F (46 2F CA 6)</html> <html><font color="red">----- Keypad LED F Test Results -----</font></html> Wed 10/23/2024 07:18:32 PM : [INST-TX-I1 ] 02 62 00 00 12 CF 13 00 Wed 10/23/2024 07:18:32 PM : [INST-ACK ] 02 62 00.00.12 CF 13 00 06 LTOFFRR(00) Wed 10/23/2024 07:18:32 PM : [Ext MH ] Unexpected Ack imCmd=62 cmd1=LTOFFRR 0x13 Wed 10/23/2024 07:18:32 PM : [46 2F CA 1 ] Link 27 : 0F20 [A22A711973FF1F01] *Failed Writing [A22A711973FF1F01] Wed 10/23/2024 07:18:32 PM : [All ] Writing 8 bytes to devices Wed 10/23/2024 07:18:32 PM : [INST-SRX ] 02 50 46.2F.CA 71.19.73 AB 2F FF (FF) Wed 10/23/2024 07:18:32 PM : [Std-Direct Nack] 46.2F.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Wed 10/23/2024 07:18:32 PM : [D2D EVENT ] Event [46 2F CA 1] [ERR] [1] uom=0 prec=-1 Wed 10/23/2024 07:18:32 PM : [ 46 2F CA 1] ERR 1