Problems after a PLM replacement

[eric_allman]

Add me to the list of folks having problems after a PLM replacement, and because I've had many PLM failures, it's probably the case that I screwed up one of the updates, so please don't tell me to "read the fine manual" — I've done that, mea culpa. My issues seem to be weird enough that I suspect that there may be multiple contributing factors:

• All device link tables have at least one link to the new PLM, but some of them also have links to what I believe to be the old PLM. The old one is dead and the address is not printed on it, so I can't verify that, but I have reason to believe it is true. Note that the ISY version of the link tables do match the devices, so resetting and restoring from a backup is just going to leave me in the same place.
• The ISY can query and control every device (mostly, see below), but doesn't update it's status when activity occurs (e.g., manually turning on a switch doesn't show up in the admin console. Note however that the Event Viewer does show that it receives protocol. I still haven't been able to understand the details of the Event Viewer, despite doing a lot of reading.
• The exception is the secondary buttons (A, B, C, and D) on keypadlincs, which can not be queried or updated. The primary on/off buttons can do both. But if I set up a scene (through the ISY) such that one button controls another, it works locally.
• Several other mysteries exist that I hope will be resolved when I fix other things.

So, my questions are:

• Is there some way to repair the link tables, i.e., remove entries that link to devices that have died, of which there have been a disturbing number? Or do I just need to factory reset everything and start over?
• Is there any explanation for why the primary circuit on the keypadlincs work (sort of) but the secondary buttons do not?

Any other sage advice would be appreciated. There's probably something more in the Forum already but I wasn't able to find it.

eric

[Techman]

Hi eric

In order to help you please answer the following questions

What is your firmware and UI versions

Do you have a current ISY backup that was made prior to replacing your current PLM

Are the devices that you mention died the older single band or newer dual band devices.

How old is your ISY and have you ever replaced its SD card

Did you exactly follow the replace PLM instructions ( see attached). It's highly unusual to have the numerous PLM failures that you're experiencing.

 

 

Replace PLM.pdf

[eric_allman]

Techman, thanks for the quick response.

Firmware and AI are both Insteon_UD994 v4.9.0 ( 2020-12-22-11:51:19 )

I have an ISY backup from before I updated this, but at this point it isn't current. In particular, there are some devices that I had to replace after I installed the new PLM.

I've had both single- and dual-band devices die. Most of them were Icon switches, but I've had particularly bad luck with PLMs. I think I'm my fourth one now.

I'm not sure of the age of my ISY, but it has been several years. I upgraded from an ISY 99. I vaguely recall replacing the SD card because I needed more space, but I'm not certain about that.

As I said in my earlier posting, I'm not at all sure I followed the instructions precisely. Given how many times I've had to replace them, it's not impossible that I got sloppy.

eric

[Techman]

It's difficult to diagnose your problem not knowing what you did or didn't do both before and after you replaced the PLM. Your ISY firmware and UI are not current, but for now I don't think you should update.

If you click on TOOLS | DIAGNOSTICS | PLM INFO, does the plm address match that of your current PLM?

Clear you java cache, including checking all 3 boxes, then download the current IoX Launcher (the admin console) from here: https://isy.universal-devices.com/start.jnlp

You can also try clicking on file, then RESTORE DEVICES. 

 

 

 

[IndyMike]

12 hours ago, eric_allman said:

• All device link tables have at least one link to the new PLM, but some of them also have links to what I believe to be the old PLM. The old one is dead and the address is not printed on it, so I can't verify that, but I have reason to believe it is true. Note that the ISY version of the link tables do match the devices, so resetting and restoring from a backup is just going to leave me in the same place.

@eric_allman, you noted that the ISY believes your device link tables are correct.  If you are sure that there are addresses listed in link tables that are no longer present in your system (addresses are not present in your ISY device tree) - that's a tough nut to crack.  If your device happens to be a scene controller, it will be trying to communicated with devices that are no longer there and will be slow and very displeased.  As you noted, a restore will not accomplish anything.

You might be able to remove affected devices from various scenes to eliminate the dead device links, but you may have scenes that no longer exist in the ISY as well.

Easiest method would be to delete the device from the ISY, factory reset, and add as a new device.  Make sure to note scenes and programs where the device is used.

Please ensure that you have good communication (hops remaining >=2 in the event viewer) BEFORE deleting.

12 hours ago, eric_allman said:

• The ISY can query and control every device (mostly, see below), but doesn't update it's status when activity occurs (e.g., manually turning on a switch doesn't show up in the admin console. Note however that the Event Viewer does show that it receives protocol. I still haven't been able to understand the details of the Event Viewer, despite doing a lot of reading.

Many devices will allow the PLM to control them without any links in their table.  All that is required is the address.

The normal reason for the ISY/PLM not "hearing" manual switch activation's is a missing responder link entry in the device (PLM isn't listed as a responder).  

I'm confused by the fact that you see activity in the event viewer.  That implies that the device is communicating to the PLM.

Could you post a level 3 event log of this activity along with your device link table?

13 hours ago, eric_allman said:

• The exception is the secondary buttons (A, B, C, and D) on keypadlincs, which can not be queried or updated. The primary on/off buttons can do both. But if I set up a scene (through the ISY) such that one button controls another, it works locally.

Insteon protocol does not allow you to "query" or directly control KPL secondary buttons.  They can be added to scenes and controlled through the scene. 

Are you indicating that your secondary buttons CAN'T be controlled by ISY scenes?  If so, please again post event viewer data and link tables for the device.

13 hours ago, eric_allman said:

• Is there some way to repair the link tables, i.e., remove entries that link to devices that have died, of which there have been a disturbing number? Or do I just need to factory reset everything and start over?

The ISY does not provide a method to manually add/delete link table entries.  No one in their right mind would consider doing this outside the ISY environment (I have, but am disqualified by the "right mind" qualifier).  As mentioned above, delete from the ISY, factory reset device, re-link.  Make sure you have good communication prior to proceeding.

13 hours ago, eric_allman said:

• Is there any explanation for why the primary circuit on the keypadlincs work (sort of) but the secondary buttons do not?

KPL's are rather complicated devices that require a buttload (technical term) of links to operate.  They are normally the first devices affected when a upgrade/replacement experiences hiccups.  I think I covered your questions on the secondary buttons above.  If not, please educate me.

As a general note on PLM replacements...

The UDI team has done a masterful job of making a PLM replacement reasonably painless and error free.  I can remember a time where a automated PLM replacement was not available - the scars are hardly visible.

If you have ever performed a firmware upgrade on your PC, think about the PLM replacement process:

• writing firmware to many devices
• with many different hardware/software versions
• across a distributed network
• with uncontrolled activity on the network
• with questionable communication
• over a long time period
• with questionable power input

I could go on, but the point is I amazed that this works so unbelievably well.  Unfortunately, when it doesn't work it can be a real mess to recover.  ...but you can recover.

[eric_allman]

On 8/8/2024 at 6:02 PM, Techman said:

It's difficult to diagnose your problem not knowing what you did or didn't do both before and after you replaced the PLM. Your ISY firmware and UI are not current, but for now I don't think you should update.

If you click on TOOLS | DIAGNOSTICS | PLM INFO, does the plm address match that of your current PLM?

Clear you java cache, including checking all 3 boxes, then download the current IoX Launcher (the admin console) from here: https://isy.universal-devices.com/start.jnlp

You can also try clicking on file, then RESTORE DEVICES.

At some point I tried to upgrade the firmware and UI, but it failed. At the time (quite a while back) it didn't seem urgent so I abandoned the project. I do like to stay up to date though, so I should add that back to the list for later.

PLM INFO does have the address matching what is printed on the PLM.

Clearing the cache and restoring devices seems to have made some difference, but it's even weirder now: on one of my keypads, one of the buttons works (and reports to the ISY) but the other three do not report to the ISY, although they do control devices to which they are linked. Also, when I did the restore the progress bar only went to 3%, at which point it finished without error.

[eric_allman]

On 8/9/2024 at 5:37 AM, IndyMike said:

@eric_allman, you noted that the ISY believes your device link tables are correct.  If you are sure that there are addresses listed in link tables that are no longer present in your system (addresses are not present in your ISY device tree) - that's a tough nut to crack.  If your device happens to be a scene controller, it will be trying to communicated with devices that are no longer there and will be slow and very displeased.  As you noted, a restore will not accomplish anything.

You might be able to remove affected devices from various scenes to eliminate the dead device links, but you may have scenes that no longer exist in the ISY as well.

Easiest method would be to delete the device from the ISY, factory reset, and add as a new device.  Make sure to note scenes and programs where the device is used.

Please ensure that you have good communication (hops remaining >=2 in the event viewer) BEFORE deleting.

I was hoping to avoid factory resetting everything, but I suspected that isn't an option for me, sigh.

So far as I can tell, there are no links to orphaned devices EXCEPT for the old PLM.

On 8/9/2024 at 5:37 AM, IndyMike said:

Many devices will allow the PLM to control them without any links in their table.  All that is required is the address.

The normal reason for the ISY/PLM not "hearing" manual switch activation's is a missing responder link entry in the device (PLM isn't listed as a responder).  

I'm confused by the fact that you see activity in the event viewer.  That implies that the device is communicating to the PLM.

Could you post a level 3 event log of this activity along with your device link table?

I know that pretty much anything can be controlled if the address is known. Insteon is not designed for security, and in fact I can control some (but not all) of the devices from the ISY.

I did check and find that every device seems to have at least one entry in the link table that refers to the PLM. I assume that they have it as a responder, but I don't know how to read the link table to verify that.

At this point I can't seem to reproduce the activity appearing even when nothing happens.

One odd thing that I noticed when working on this: in some cases I can turn on a scene (by which I mean that the ISY thinks it has turned on) with Fast On but not with On. Off and Fast Off both work.

On 8/9/2024 at 5:37 AM, IndyMike said:

Insteon protocol does not allow you to "query" or directly control KPL secondary buttons.  They can be added to scenes and controlled through the scene. 

Are you indicating that your secondary buttons CAN'T be controlled by ISY scenes?  If so, please again post event viewer data and link tables for the device.

Yes, I know that you have to control secondary buttons through scenes, but that isn't working. Here is the link table for one of my keypadlincs:

Controls A and C do not directly control anything (but programs look at them). B and D do control other devices.

On 8/9/2024 at 5:37 AM, IndyMike said:

The ISY does not provide a method to manually add/delete link table entries.  No one in their right mind would consider doing this outside the ISY environment (I have, but am disqualified by the "right mind" qualifier).  As mentioned above, delete from the ISY, factory reset device, re-link.  Make sure you have good communication prior to proceeding.

I've been accused of not being in my right mind as well, but I also understand that this would be like juggling running chainsaws. The main problem is that I have to restore any scenes that a deleted device participates in.

Frankly I'm not confident that I have good communication, although as near as I can tell devices can communicate with each other.

On 8/9/2024 at 5:37 AM, IndyMike said:

KPL's are rather complicated devices that require a buttload (technical term) of links to operate.  They are normally the first devices affected when a upgrade/replacement experiences hiccups.  I think I covered your questions on the secondary buttons above.  If not, please educate me.

As a general note on PLM replacements...

The UDI team has done a masterful job of making a PLM replacement reasonably painless and error free.  I can remember a time where a automated PLM replacement was not available - the scars are hardly visible.

If you have ever performed a firmware upgrade on your PC, think about the PLM replacement process:

• writing firmware to many devices
• with many different hardware/software versions
• across a distributed network
• with uncontrolled activity on the network
• with questionable communication
• over a long time period
• with questionable power input

I could go on, but the point is I amazed that this works so unbelievably well.  Unfortunately, when it doesn't work it can be a real mess to recover.  ...but you can recover.

Well, that's a relief. I'm hoping that I don't need to buy yet another PLM. I think I have four of them at this point, three (and perhaps four) of which are non-functional.

Thanks for your feedback.

[IndyMike]

12 hours ago, eric_allman said:

Yes, I know that you have to control secondary buttons through scenes, but that isn't working. Here is the link table for one of my keypadlincs:

Controls A and C do not directly control anything (but programs look at them). B and D do control other devices.

@eric_allman, thanks for posting the table.  It explains a lot.  Probably not going to be a news item, but it's messed up.

I'm guessing that your PLM is address 70.8B.6C.  I can see a Main button responder record on line 1: 0FF0 (the PLM can control the main button).  The only controller record I see for the PLM is on line 5 : 0FD0 for button 5 (only the c btton can control the PLM).

The "F2" record on lines 3 and 4 is rather odd.  I've never seen bit 4 set to 1 before (normally a E2).  Bit 4 is defined by protocol to be "product dependent" (see below) so it may not cause problems - I've just never seen it used.

Rather than detailing everything wrong with your table, I think it would be easier to show how "minimum" table should look for a 5 button KPL.  The table below is from a "factory reset" KPL that I added to the ISY. 

My PLM address is 53.BC.3A.  The KPL shows 1 responder link to the PLM and Controller links for all of the KPL buttons.

Getting back to the point, you need to delete/factory reset/re-link this device.  Make sure to make note of the scenes and programs where it's used prior to deleting.

I would also delete/reset/re-link any devices that you believe have links to your old PLM.  If these are control links, they will bog down your system while your devices try to communicate with a PLM that no linger exists.

Feel free to post additional tables if you wish.

 

 

For anyone interested, the link table data is listed in the modem developers guide (among other places): https://cache.insteon.com/developer/2242-222dev-062013-en.pdf

 

[eric_allman]

@IndyMike Thanks for the feedback. I have resigned myself to deleting and recreating all devices, one at a time. The ones that are not in complex scenes are easy, but since there seems to be no good way of summarizing scenes (including on levels, ramp rates, etc.) in a printable form, it's a bit of a slog for the devices in more complex scenes. But at least things are getting better (so far). I'm still having problems setting up parameters for scenes (on level, ramp rate, etc.) but that's a different topic.

Thanks for the advice. I'll be back if I get stuck again.

[IndyMike]

@eric_allman, Sorry, I know it's painful rebuilding scenes (particularly for a KPL).  I wish there was a neat trick to help with all the On-Levels and Ramp Rates - I don't have one.  I've spent a good amount of time looking through the rest interface and the ISY SD card.  I honestly don't know where the ISY stores this information for scenes.

You can interrogate the ISY for Scene Members and Controllers using the rest interface :

/your.ISY.IP Ad/rest/nodes/scenes

This will open a XML file in your browser (you'll probably be prompted to login first).  You can open the file in Excel as a table.  That allows you to sort device addresses to determine which scenes they are members of.  It does not include brightness or Ramp Rate information.

The following is the scene listing for one of my 8 button KPL's @15.C6.C7. 

Notes:

1. All devices are members of the My Lighting Scene
2. Type 16 is a controller, 32 is a responder.
3. The Device Group is what is stored in the PLM/Device Link tables.  This listing shows decimal, the Link Tables and Event Viewer will show Hexadecimal.

That's about all I can offer.  Be patient, methodical, and take your time.  I find that drowning bait and killing brain cells reduces the tension.  But then that's my answer to many problems. 

 

 

[eric_allman]

Just to get some closure on this: I ended up deleting and restoring all of the devices. This was a pain in the you-know-what, but everything seems to be working again, and there was even a silver lining. It forced me to look hard at stuff that accreted over the years — scenes that were unused, setups that could be simplified, etc. The only lingering problem is that I can't seem to get my IRlinc working again, but that is much less important than it used to be. Overall my system is much neater and easier to maintain (at least so far).

Thanks to everyone who helped out!

[IndyMike]

@eric_allman, glad you made it to the end of the long and winding road...

As far as the IRLinc is concerned, I believe these are powerline only devices.  You could try plugging it in next to the PLM to see if it will link.

[Brian H]

Yes both the IRLinc Transmitter or Receiver. Are both power line only. Faded memory here. I believe they where in the drop down list with other unique modules like the motion sensors.