Why did I have to recreate my scene?

[oh2bnMaine]

First off, I fixed it, but I am still curious if somebody can explain what happened.

I have recessed lights in the kitchen connected to a 2477D (Switch A). I have two other 2477Ds (Siwitch B, Switch C) that controlled the 'live' switch. This has been working for approximately 2 years now. 

This morning, my wife actuated one of the controller switches (not the one that is physically wired to the lights) and the scene seemed to break. The two controller switches stopped working as expected.

1. Turn lights ON using Switch A
2. Note that the LEDs on Switch B & Switch C did NOT change position (this used to work)
3. Actuate Switch B (from OFF to ON) to try to get it in sync with the scene
   • Lights turn OFF
   • Switch A LEDs go from ON to OFF
   • Switch B LEDs go from OFF to ON 
   • Switch C LEDs do not change
4. I removed the three switches from my ISY and re-adding them.
5. I recreated the scene in the admin console. 
6. I then created the scene at the switches.

I'm not sure if I HAD to do both #5 & #6, but just doing #5 did not seem to fix the issue.

I have ~40 scenes. This is the only one (that I have found) that broke.

Any thoughts on what happened?

Two months ago, I migrated from my ISY994 to an eISY. Other than that, I haven't made any changes that I would think could have impacted this aspect of the ISY. None of those changes were in the last few days and we've been using the kitchen lights every day.

[paulbates]

Would this be the first time you tried that particular combo, it may have been "broken" in migration?

In my experience with insteon & plms on several different HA systems, links can break:

1. From migrations from one controller/plm to another
2. Sometimes powerline fluctuations and/or age of device can cause a controller to forget some of its scene programming. For me it was mostly keypads, but it happened with other devices too

[Guy Lavoie]

Insteon works in strange and wonderful ways...  No idea really, but the first thing I would have tried would have been to "Restore Device" on the affected switches. This rewrites the links to them, without losing the references in programs and scenes.

[oh2bnMaine]

20 minutes ago, Guy Lavoie said:

Insteon works in strange and wonderful ways...  No idea really, but the first thing I would have tried would have been to "Restore Device" on the affected switches. This rewrites the links to them, without losing the references in programs and scenes.

I didn't think of using the Restore function until it was too late. That would have been a good test. 

[oh2bnMaine]

Well!! It happened again yesterday evening! I Just found out have performed the Restore Devices function on all three switches.

The first switch I did, the ISY Admin Console restarted itself and I had to re-log in.

Further attempts did NOT restart the ISY console.

Unfortunately, this did not fix the issue.

Any other thoughts? I'll leave it as is for now to see if anybody can help me get to the bottom of this (since it seems like it will come back)

[Guy Lavoie]

Are you able to turn the devices on and off from the Admin Console?

Sounds like something is getting corrupted, or a device is becoming intermittent.

[hart2hart]

Well!! It happened again yesterday evening! I Just found out have performed the Restore Devices function on all three switches.
The first switch I did, the ISY Admin Console restarted itself and I had to re-log in.
Further attempts did NOT restart the ISY console.
Unfortunately, this did not fix the issue.
Any other thoughts? I'll leave it as is for now to see if anybody can help me get to the bottom of this (since it seems like it will come back)

My guess is the switch connected to the fixture is going bad and losing its link table. I would have restored it only to see the impact. Or maybe one of switches is going bad and generating noice on that circuit to which I’d air gap them one at a time to see if problem goes away. First the two controller only and then one connected to fixture. If it’s the one connected to the fixture turning other two on and off will show in their LEDs but fixture will not be controlled.

[paulbates]

2 hours ago, hart2hart said:

My guess is the switch connected to the fixture is going bad and losing its link table. I would have restored it only to see the impact.

Another possibility is that the PLM is going bad. How old is it? There's a sticker on it with 4 numbers that documents the mfg dates, you can post those.

[Brian H]

The sticker should also have a revision number on it. That also may give us information on the PLM.

[oh2bnMaine]

16 hours ago, Guy Lavoie said:

Are you able to turn the devices on and off from the Admin Console?

Sounds like something is getting corrupted, or a device is becoming intermittent.

I can control all three switches from UDI phone app. While controlling the switches, I can see that they are switching on to the correct brightness levels -- I have a routine that changes these from day to night. The switch that is wired to the light is the only one that is actually turning the lights on.

When I have a minute, I'll look for a spare 2477D to change the switches one at a time to see what happens. 

I'll get the PLM information later this morning.

[Andy P]

This is a shot in the dark, but I had an issue kind of like this where the remote switches work but didn't turn on the load switch. Turns out that in the scene definition, somehow those remote switches were set to turn the remote on to 0% instead of 100%. When I fixed the scene, the remote switches worked as expected. Just another quick thing to check.

[lilyoyo1]

I don't this is Plm issue since this only happens with the same set of devices. Besides that, Insteon links are stored on the devices themselves so a bad Plm wouldn't affect local operation of the devices. I agree with Guy that a switch is probably going bad. I'd start with the controlled switch when you start your tests

[hart2hart]

I recreated the scene in the admin console. 

I then created the scene at the switches.

I'm not sure if I HAD to do both #5 & #6, but just doing #5 did not seem to fix the issue.

To be clear, did you define the scene in the Admin Console and then create the same scene using device to device method?

[oh2bnMaine]

As a result of these two responses, I got to thinking about what my Programs do. The routine I run to change On Level via the scene uses variables to accomplish this. For some reason, the INIT level of the AM (Day) routine was 0. This doesn't explain why things are working intermittently, though. But it is a step forward. I changed the INIT & VALUE to 75% and I'll monitor the system today.

Here's what I do in the program. This is the first program I wrote to control a scene, so I'm open to improvements!

 

11 hours ago, hart2hart said:

 

To be clear, did you define the scene in the Admin Console and then create the same scene using device to device method?

 

I wouldn't bet my life on this order, but I most likely added them to the scene in Admin Console and then recreated the scene at the switches when things still didn't work. 

23 hours ago, Andy P said:

This is a shot in the dark, but I had an issue kind of like this where the remote switches work but didn't turn on the load switch. Turns out that in the scene definition, somehow those remote switches were set to turn the remote on to 0% instead of 100%. When I fixed the scene, the remote switches worked as expected. Just another quick thing to check.

 

 

[IndyMike]

4 hours ago, oh2bnMaine said:

Here's what I do in the program. This is the first program I wrote to control a scene, so I'm open to improvements!

Wow, that's a lot of updating for day/night on levels.

I'll confess that I've never really used the "Adjust Scene" program feature.  I prefer to generate specific scenes for different levels and call them through a program.

I'll admit that what you are trying to do would result in an "elegant" changeover in device on levels.  The price you pay is an extreme amount of communication and many writes to device and PLM EEprom memory.  The high communication level opens the door for errors.  Excessive EEprom writes can actually wear out the memory devices.  

You also need to be very careful that you are writing to ALL the scene controllers as well as the Admin Console scene (in case the scene is called by a program).

At a minimum, you should insert some wait statements to allow the link table writes to complete.  Based on what I'm seeing with PLM write timing, the wait should be around 5 seconds.

Try opening the Event Viewer (level 3) and manually running your program.  You'll be amazed how much communication results.

I tried adjusting 1 scene with 1 controller - the program and Event viewer communication are shown below.  You will have MANY times this amount of communication.

Answering "Why did I have to Re-create my Scene" - 

1. Communication errors during link table writes - or -
2. Worn out EEprom memory (PLM or Devices).

Hopefully it's #1.

 

Test - [ID 0071][Parent 0003]
If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 Then
        In 'Basement / SC BSMT Entry' Set 'Basement / BSMT Fam Rm Sconce' To '$IOnLevel %' in 2.0 seconds
        Wait  5 seconds
        $IOnLevel  = 100
        In 'Basement / BSMT Stair' Set 'Basement / BSMT Fam Rm Sconce' To '$IOnLevel %' in 0.5 seconds
 Else
   - No Actions - (To add one, press 'Action')

 

The following is the Event Viewer Communication generated by the above program
Mon 03/31/2025 10:28:40 AM : [        Time] 10:29:02 21(0)
Mon 03/31/2025 10:28:40 AM : [26898]->[41 1E 9 1] link updated
Mon 03/31/2025 10:28:40 AM : [41 1E 9 1   ] Link    4 : 0FD8 [A24353BC3AFF1B01] Saving  [..........FF....]
Mon 03/31/2025 10:28:40 AM : [41 1E 9 1   ] Link    4 : 0FD8 [A24353BC3AFF1B01] Saving  [............1B..]
Mon 03/31/2025 10:28:44 AM : [All         ] Writing 2 bytes to devices
Mon 03/31/2025 10:28:44 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
Mon 03/31/2025 10:28:44 AM : [INST-ACK    ] 02 62 41.1E.09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
Mon 03/31/2025 10:28:44 AM : [INST-SRX    ] 02 50 41.1E.09 53.BC.3A 2F 2F 00           (00)
Mon 03/31/2025 10:28:44 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 03/31/2025 10:28:44 AM : [INST-ERX    ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 39 01 76 FF 1F 01 31 
Mon 03/31/2025 10:28:44 AM : [Ext-Direct  ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1
Mon 03/31/2025 10:28:44 AM : [41 1E 9 1   ] Link    4 : 0FD8 [A24353BC3AFF1B01] Writing [..........FF1B..]
Mon 03/31/2025 10:28:44 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 02 0F DF 08 A2 43 53 BC 3A FF 1B 01 90
Mon 03/31/2025 10:28:44 AM : [INST-ACK    ] 02 62 41.1E.09 1F 2F 00 00 02 0F DF 08 A2 43 53 BC 3A FF 1B 01 90 06        (00)
Mon 03/31/2025 10:28:44 AM : [INST-SRX    ] 02 50 41.1E.09 53.BC.3A 2F 2F 00           (00)
Mon 03/31/2025 10:28:44 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 03/31/2025 10:28:44 AM : [All         ] Writing 0 bytes to devices
Mon 03/31/2025 10:28:45 AM : [1A 5D 6D 1]->[41 1E 9 1] link updated
Mon 03/31/2025 10:28:45 AM : [41 1E 9 1   ] Link    1 : 0FF0 [A2011A5D6DFF1C01] Saving  [..........FF....]
Mon 03/31/2025 10:28:45 AM : [41 1E 9 1   ] Link    1 : 0FF0 [A2011A5D6DFF1C01] Saving  [............1C..]
Mon 03/31/2025 10:28:45 AM : [All         ] Writing 2 bytes to devices
Mon 03/31/2025 10:28:45 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
Mon 03/31/2025 10:28:45 AM : [INST-ACK    ] 02 62 41.1E.09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
Mon 03/31/2025 10:28:46 AM : [INST-SRX    ] 02 50 41.1E.09 53.BC.3A 2F 2F 00           (00)
Mon 03/31/2025 10:28:46 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 03/31/2025 10:28:46 AM : [INST-ERX    ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 39 01 76 FF 1F 01 31 
Mon 03/31/2025 10:28:46 AM : [Ext-Direct  ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1
Mon 03/31/2025 10:28:46 AM : [41 1E 9 1   ] Link    1 : 0FF0 [A2011A5D6DFF1C01] Writing [..........FF1C..]
Mon 03/31/2025 10:28:46 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 02 0F F7 08 A2 01 1A 5D 6D FF 1C 01 1E
Mon 03/31/2025 10:28:46 AM : [INST-ACK    ] 02 62 41.1E.09 1F 2F 00 00 02 0F F7 08 A2 01 1A 5D 6D FF 1C 01 1E 06        (00)
Mon 03/31/2025 10:28:47 AM : [INST-SRX    ] 02 50 41.1E.09 53.BC.3A 2F 2F 00           (00)
Mon 03/31/2025 10:28:47 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 03/31/2025 10:28:47 AM : [All         ] Writing 0 bytes to devices
 

[oh2bnMaine]

Hmm. So, maybe I shouldn't be doing it this way regardless whether it is the issue or not? -- all the writing to EEprom memory? I never had issues with this program, which has been running for just over a year. 

Since I fixed the INIT value for the variable, my isuses have gone away. I'll leave it as is for another few cycles, though. That should confirm that the issue was a changed variable -- probably I fat fingered something.

[IndyMike]

44 minutes ago, oh2bnMaine said:

Hmm. So, maybe I shouldn't be doing it this way regardless whether it is the issue or not? -- all the writing to EEprom memory? I never had issues with this program, which has been running for just over a year. 

Since I fixed the INIT value for the variable, my isuses have gone away. I'll leave it as is for another few cycles, though. That should confirm that the issue was a changed variable -- probably I fat fingered something.

I missed the fact that you located an incorrect INIT value...

Beyond that, I'll admit that the scene adjust method produces elegant results.  I personally don't care for the overhead involved. 

In terms of the write cycles involved, you probably will not wear out the EEprom before something else dies (power supply, etc).  Most EEprom devices are rated at 100,000 cycles.  At 2 writes (AM/PM) per memory location per day your device EEprom would last 137 years.  Sorry - I should have used my Maths before my previous post.

The raw amount of communication required is a concern.  Communication errors could result in corrupted device link tables and scene errors.  You can check this by performing a link table "compare" from the admin console.  

You can use a time qualified program to call a scene and produce similar results.  Use the scene controllers as the program triggers.  My example scene above would look like the following.

Note that I inserted a second wait After the Trigger and before calling the Scene - This is because the trigger (BSMT Stair) is part of the Scene (BSMT ENTRY).  Best practices call for the wait to prevent potential communication collisions at the PLM which can in turn trigger the dreaded "ALL ON" phenomena.

The event viewer communication for the command is shown at the end. 

 

Test - [ID 0071][Parent 0003]
If
        From     9:30:00PM
        To       7:05:00AM (next day)
    And 'Basement / BSMT Stair' is switched On
Then
        Wait  2 seconds
        Set 'Basement / SC BSMT Entry' On
Else
        Set 'Basement / SC BSMT Entry' On
 

 

Scene On communication

Mon 03/31/2025 11:56:07 AM : [INST-TX-I1  ] 02 62 00 00 43 CF 11 00
Mon 03/31/2025 11:56:07 AM : [INST-ACK    ] 02 62 00.00.43 CF 11 00 06          LTONRR (00)