All un-edited scenes fail "Scene Test", and all un-edited devices do not respond to All On or Off after migration

[Oakland Jeff]

Boy, did I speak too soon about being done with Migrate Madness! As I'm unraveling all the things that are broken after the migration, including ALL of my scenes and ALL of my program's inability to be triggered by control changes, I'm hoping that there is a magic bullet utility that will clean up all the links that seem to be broken? I really don't want to have to recreate every single scene and every single program one at a time. Please, pitch me some salvation here. Any and all ideas are welcome. Yes, I have backups of previously working configurations on the old ISY before migration to the current... That's what I used that landed me in this spot though. Should I try restoring a current backup from the new eisy? Is there code to vet the config file as it imports and correct anything wonky?

All of my 50 scenes, except for the ones that I've been working on and have recreated already, look like this pic when I Scene Test.

I also noticed that in the Network list of all my devices, if I do All On's and All Off's, the only devices that correctly respond are the ones that I've been modifying by hand. Everything else just stubbornly sits there in its current state. The thing is, as with this example, the device IDs match the physical hardware, so I don't know where the disconnect is.

[Techman]

Try doing a restore device on all the devices in your scene, then do a scene test. Did that resolve the error?

Most newer devices will not respond to an all on as that function has been removed.

Are you using the same PLM that you had installed on the ISY?

Your issues are not typical, and may be related to an incomplete migration.

 

[Oakland Jeff]

So I'm noticing something very strange and potentially very cool... Before restore, the Device and the ISY have identical link tables with 12 or 13 links, but after restore, they are still identical, but they only have 3 or 4 links! This blows my mind since I thought the ISY was the source of truth, and how/why would a restore to the device from the source of truth affect the source of truth? Clearly, my assumptions were wrong. Please tell me this is some cool clean-up function of Restore and not a symptom of failed comms!!

Here is an example of a short one. some of the links that were Identical but not Ignore are gone. 10 down to 4!

Edited August 10, 2023 by Oakland Jeff
Added pics

[Techman]

What else is, or supposed to be, linked to the device that now has less links. i.e. scenes, devices, etc. 

Are your scene tests now working?

Take a look at any related programs. It's possible that some devices are not properly represented in the programs.

[Oakland Jeff]

The switch above is part of a simple 3-way circuit and a motion sensor. I restored both switches and the sensor. All 3 shed about half their links after the restore, as above. They are part of programs that manage auto-off, but as per instructions I disabled all the programs before testing the scene. The test still failed.

[Techman]

Right click on the Laundry Room Recessed switch, then do a show ISY device links and post the results

[Oakland Jeff]

HA, OK, I just discovered that if any of my devices in the scene are set to Default, the test returns a failure for them. So my updated scene, with both switches set to an Insteon command, succeeds! I had previously left the slave switch as Default before, since it wasn't caring any load and was just coming along for the ride. I thought doing so would reduce traffic, but maybe it's best practice to control them as part of a scene too?

 

[Oakland Jeff]

[Techman]

So, is the scene now working correctly?

[Oakland Jeff]

Yes, it is now!

 

[Techman]

Excellent. Yes they need to be set to Insteon. 

[IndyMike]

4 hours ago, Oakland Jeff said:

 

Here is an example of a short one. some of the links that were Identical but not Ignore are gone. 10 down to 4!

 

Glad you got things working.

For reference - the "Identical/Ignore" entries shown above that have the ": 22" are devices that were deleted from a scene.  When a device is deleted from a scene the ISY writes a "22' to the entry to get the device to ignore it.  Much quicker than re-writing the entire link table.

When you do a restore, the ISY "consolidates" the link table and removes the "22" entries.

 

[Oakland Jeff]

I didn't notice that! Thanks for the info. That still leaves a mystery consolidation from 6 to 4 links after the restore though. 

[Techman]

See IndyMike's explanation above. 

[Oakland Jeff]

Thanks Techman. I understood IndyMike's explanation to cover only the 22's, and accounting for those 3 lines being gone after the restore, I expected to see 7 lines left, but there were only 4. In the end I don't care. If everything works with fewer links, all the better. And that seems to be the case.

I've restored every device in my setup, and tested every scene. About 70% of the scenes had at least one failed device, so I deleted the failing ones from the scenes, then replaced them again and reconfigured all their on levels and ramp rates, and now all my scenes are working as expected. 

Phew!

HOWEVER... My sensors are still not triggering my programs. I've tried the same trick... changing the sensor in the program to something else, saving, then putting it back to what it should be, and saving. But this trick didn't work for the programs.

Since sensors not triggering the programs is the only remaining issue I know of, I'm going to close this thread as resolved and just work on that other thread.

Thanks for all the help!

Edited August 13, 2023 by Oakland Jeff