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 - that would be obscene (offense intended).

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 not 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