Yesterday, the power glitched on my eISY. I brought it back online, but the Insteon PLM wasn't working (or so I thought). I swapped it with another one as prescribed and started the restore PLM procedure. The power glitched again during the restore process, so I got everything back up and restarted the restore.

Now, none of the scenes can be controlled with the eISY. Each individual device responds perfectly, but I can't control any scenes.

If I remove a device from a scene then re-add it, it works fine, but I have to do that for every device in the scene. I have compared the device link tables before and after removing and adding it back to the scene and it does make a slight change in the link table an entry for the PLM so the device table is definetly current bad. The IoX link table matches the (incorrect) device link table before the manual scene delete/add so a device restore has no effect since it's just rewriting the bad information.

The IoX "database" seems to be aware of the scene relationships since they all appear correctly in the device tree. Also, each device entry in each scene it is a member of still has its correct "behavior" in it, but the bottom line is that all the device link tables are corrupt. Is there a way to have the eISY "rebuild" each scene/device correctly and restore each device?

I have over 63 scenes with 462 device entries across all of them. Just going through each one and documenting the device behavior in each scene will take hours. Removing and adding them one by one could take days. I'm feeling pretty defeated and am hoping someone has a miracle cure.

Thanks for any guidance.

-r

Incase case anyone is interested...

The back story (that makes me feel stupider than I look): The "power glitches" were me sloppily removing a bad UPS to replace it with a new one. No- I did not make any backups before I started all of this despite knowing way better. I'll take my licks. I have them coming.

Was the backup that you used for the restore recent? If it predates much of your scene creation, or worse: if it's a backup from a previous PLM, then there isn't much you can do. There is no "restore scene" utility.

1 hour ago, TheRydad said:

If I remove a device from a scene then re-add it, it works fine, but I have to do that for every device in the scene. I have compared the device link tables before and after removing and adding it back to the scene and it does make a slight change in the link table an entry for the PLM so the device table is definetly current bad. The IoX link table matches the (incorrect) device link table before the manual scene delete/add so a device restore has no effect since it's just rewriting the bad information.

Can you show us what the link tables look like:

1. Before and after you remove/re-add the devices to a scene.

2. IOX table vs a device that has Not been fixed via the scene delete/re-add procedure.

26 minutes ago, IndyMike said:

1. Before and after you remove/re-add the devices to a scene.

2. IOX table vs a device that has Not been fixed via the scene delete/re-add procedure.

I did this with the same device. The first picture is the before, and the second picture is the after. The scene could not be controlled by the eISY before and now it can. Note that the scene worked fine when either device was the controller, so the native Insteon scene remained intact (which makes sense).

Note: 58.22.7E is the PLM.

I'd love to hear any thoughts/ideas. Thanks!

@TheRydad , I apologize, but my thoughts and ideas are coming rather lame. The behaviour you are describing makes sense based on the link tables. I don't really understand why this occurred, and don't have an easy solution. It's possible the power interrupt resulted in a FUBAR event.

Regardless, I would suggest you open a ticket to see if UD can offer a recover path that doesn't involve deleting/adding 100's of scenes.

I've commented your original table below. What is significant is what is NOT shown.

1. Your device at 58.41.80 has group 0 responder links to the PLM at 58.22.7E (Addr 0FF8). It has no controller link (Flag E2) to the PLM. It can't communicate any local changes to the PLM.

2. Your device can control and respond to the device @58.41.BB - it is a scene member (Addr 0FF0 and 0FE8)

Count	Addr	Flag	Group	Addr	Data	Description
0	0FF8	A2	00	58.22.7E	FF1F01	Responder to Group0 PLM
1	0FF0	A2	01	58.41.BB	FF1F01	Responder to Group1 58.41.BB
2	0FE8	E2	01	58.41.BB	010001	Controller of Group1 58.42.BB
3	0FE0	AA	00	58.22.7E	FF1B01	Duplicate responder to Group 0 PLM
4	0FD8	00	06	58.31.9E	001B01	End of record

The Scene delete/add fix a couple of things (highlighted):

1. Your device at 58.41.80 has group 0 responder links to the PLM at 58.22.7E (Addr 0FF8). It has a controller link (Flag E2) to the PLM at Addr 0FF0.

2. Your device is a responder to Group 16 as controller by the PLM (Addr 0FE8). This is the scene link you were missing.

3. Your device can control and respond to the device @58.41.BB - it is a scene member (Addr 0FE0 and 0FD8)

Count	Addr	Flag	Group	Addr	Data	Description
0	0FF8	A3	00	58.22.7E	FF0101	Responder to Group0 PLM
1	0FF0	E2	01	58.22.7E	010001	Controller of Group1 PLM
2	0FE8	A2	16	58.22.7E	FF1A01	Responder of Group 16 PLM
3	0FE0	E2	01	58.41.BB	010001	Controller of Group1 58.42.BB
4	0FD8	A2	01	58.41.BB	FF1F01	Responder of Group1 58.42.BB
5	0FD0	00	00	00.00.00	000000	End of record

Edited 4 hours ago4 hr by IndyMike

5 hours ago, Guy Lavoie said:

Was the backup that you used for the restore recent? If it predates much of your scene creation, or worse: if it's a backup from a previous PLM, then there isn't much you can do. There is no "restore scene" utility.

Yeah- the backup I have is about 2 years old. It would theoretically work to get all the devices talking via a "Restore PLM", but having the devices communicating to each other or the eISY isn't my problem. I started added a ton of scenes and done a lot of programmed automations since then which would be lost.

My question was more asking about whether the eISY could "rebuild" the scenes internally and send them to all devices. The eISY knows all the scenes along with the scene actors and their roles in each scene. It seems theoretically possible, but I understand that it's not available.

3 hours ago, IndyMike said:

@TheRydad , I apologize, but my thoughts and ideas are coming rather lame. The behaviour you are describing makes sense based on the link tables. I don't really understand why this occurred, and don't have an easy solution. It's possible the power interrupt resulted in a FUBAR event.

Regardless, I would suggest you open a ticket to see if UD can offer a recover path that doesn't involve deleting/adding 100's of scenes.

I've commented your original table below. What is significant is what is NOT shown.

1. Your device at 58.41.80 has group 0 responder links to the PLM at 58.22.7E (Addr 0FF8). It has no controller link (Flag E2) to the PLM. It can't communicate any local changes to the PLM.

2. Your device can control and respond to the device @58.41.BB - it is a scene member (Addr 0FF0 and 0FE8)

Count	Addr	Flag	Group	Addr	Data	Description
0	0FF8	A2	00	58.22.7E	FF1F01	Responder to Group0 PLM
1	0FF0	A2	01	58.41.BB	FF1F01	Responder to Group1 58.41.BB
2	0FE8	E2	01	58.41.BB	010001	Controller of Group1 58.42.BB
3	0FE0	AA	00	58.22.7E	FF1B01	Duplicate responder to Group 0 PLM
4	0FD8	00	06	58.31.9E	001B01	End of record

The Scene delete/add fix a couple of things (highlighted):

1. Your device at 58.41.80 has group 0 responder links to the PLM at 58.22.7E (Addr 0FF8). It has a controller link (Flag E2) to the PLM at Addr 0FF0.

2. Your device is a responder to Group 16 as controller by the PLM (Addr 0FE8). This is the scene link you were missing.

3. Your device can control and respond to the device @58.41.BB - it is a scene member (Addr 0FE0 and 0FD8)

Count	Addr	Flag	Group	Addr	Data	Description
0	0FF8	A3	00	58.22.7E	FF0101	Responder to Group0 PLM
1	0FF0	E2	01	58.22.7E	010001	Controller of Group1 PLM
2	0FE8	A2	16	58.22.7E	FF1A01	Responder of Group 16 PLM
3	0FE0	E2	01	58.41.BB	010001	Controller of Group1 58.42.BB
4	0FD8	A2	01	58.41.BB	FF1F01	Responder of Group1 58.42.BB
5	0FD0	00	00	00.00.00	000000	End of record

Thanks for the thorough reply. I am quite rusty with the actual packets in the transmission logs but do know enough to know that the wrong data were being communicated. I was just hoping there was a way to rebuild the interconnections correctly and send them to the devices. I really appreciate you taking a look at this.

I have already started the process of manually rebuilding everything. Just documenting which devices are in which scenes and what their roles are took many hours. Luckily everything still communicates and I know what each device is. Rebuilding the complex scenes with many dozens of actors is a good brain exercise to keep it all straight!

Next step: Proper backup procedures!

16 minutes ago, TheRydad said:

Next step: Proper backup procedures!

As I like to say: there are two groups of computer users, those who have lost data, and those who will.

11 minutes ago, Guy Lavoie said:

As I like to say: there are two groups of computer users, those who have lost data, and those who will.

Well sh$t, I had not had you pegged as an optimist. Go figure...