stillwater

You can use IoX to test for connectivity and only reboot the router when connectivity to the portal been lost. I have done this in the past. It will reboot extra when the portal goes down but this is not common.

I don't know, maybe do a factory reset on the PLM and then try restore PLM again. Before that you could do a count of the links in the PLM (from the tools/show PLM links table box) and see how that compares to the complexity of your insteon system. Something seems to be going wrong in the refresh of the PLM. If your IoX/ISY backup is current you could restore from backup again before doing the PLM restore, just to be sure that the scenes are accurately reflected in the IoX links table that would be transferred to the new PLM by the PLM restore. But this is clearly clutching at straws on my part.

I was just saying that the fact that the scenes run from keypads means nothing about the status of the PLM links table. Not suggesting you actually unplug the PLM. You haven't said whether you can turn the scenes on and off from the Admin Console but I assume based on the diagnostic that the answer is no. This means either that the EISY is not communicating with the PLM (the fact that the diagnostic says specific links not found probably means that this is NOT the case. Also the fact that recreating the scene worked suggests that the connection between EISY and PLM is working. ) OR more likely that the PLM does not have the proper links in it to activate the scenes. I would try rerunning the restore PLM procedure following the instructions exactly. Maybe restore the EISY from backup again first. But again others know more than I about all this.

Again my understanding is that scenes will run from keypads with no PLM plugged in. (Unless they need programs on IoX to run properly.). Of course EISY wouldn't know whether they have run or not or have any idea about changes in device status.

I thought your problem was that Alexa wasn't causing scenes to tun -- so now I don't understand what is working and what isn't. The device table compare shows what links are in the devices but not what is in the PLM's link table. It sounds like that is where the problem lies. Under Tools in the Admin Console there is a show PLM links table but I wouldn't know how to analyze what's there. (There's no "compare" button.) Clarification-- there are 3 types of link tables. The IoX keeps a record of the links that are supposed to be in each device and also the links that are supposed to be in the PLM links table. So you did a compare of the IoX "should be" device table with the actual device table, for particular devices. The restore device re-writes the device link table to reflect what's in IoX. I don't think restore device affects what's in the PLM device table (but it might be intended to--I am not an expert).

The scenes still run from the keypads because the keypads have the scene links in them as a controller. So they work without the PLM being in the loop. Presumably ALexa is interacting with the IoX on Eisy, probably via REST, and then the IoX on EISY goes through the PLM to all the devices in the scene to activate the scene. So either the EISY isn't seeing the PLM or the PLM doesn't have the links for the scene responders defined properly. Maybe try following the instructions for restoring the PLM again. When I click on a scene (not right click) the main part of the page has buttons along the bottom including On OFF FastOff and FastOn. That's what I meant by running the scene from the admin console. Scene test does turn the scene on and then off and reports.

Do the scenes run from the admin console or the Eisy-UI? I am not familiar with running scenes from Alexa. There are people usually on the forums who are much more expert than I; perhaps one of these will know what to suggest.

Did you check all the devices that your error log says can't be contacted?

Yes. There is also the "restore devices" command from the File menu that restores all devices but somehow this didn't work entirely for me. You can check afterward by doing the link table compare again. If the links are still not identical the next step is to do a factory reset on the device and do restore device again. On a KPL keypad the factory reset is to push the airgap button at the bottom and hold until it stops beeping.

I'd look at the device tables for the devices in the scenes -- right click and then choose device table under diagnostics. Then use compare button to compare to the iox links table. Use restore device to eliminate discrepancies. Hopefully that will restore communication between devices and PLM and fix the issue. (This assumes you used Restore Modem (PLM) to accomplish the replacement of the PLM--otherwise first follow instructions for that. )

Success!! Exporting and Restoring the Network Resources made them all work. I hadn't noticed these options previously.

Copying each network resource to a new one seems to create a working network resource -- test button works and result is as expected. I only have 25 so if i have to copy them and then reset the names in programs that use them it's not horrible but obviously the wiki was not correct in my case that the network resources would transfer seamlessly and only need opening and saving to make them work.

Also the test button for network resources doesn't seem to do anything.

This was an upgrade from ISY 994i 5.3.4. Communications event viewer shows failure to connect. I did open and re-save all the network resources as advised in the wiki somewhere. I wrote the network resources a long time ago and they were working with tcp. Is there something in the EISY that needs to be switched on to allow the network resources to work?

I never had an all-on event but I did have random individual devices turning on when they shouldn't during the "factory query." I had few/no insteon comms issues and dealt with this problem by disabling the nightly query all. It didn't seem to be doing any good for me.