PLM or Plug-in limitation for insteon links?

[mnsandler]

I do have a bunch of these links " (Bad Link Entry, unreferenced group #)", so this process is cleaning those up too.

yes, you should delete those as well.

[jono]

Another update:
1. I deleted all the links for "controlled by HomeSeer using RF PLM Group" that were not for the load buttons (A on an 8KPL, On/load on a 6KPL). I also deleted all the "Bad Link Entry" links.

2. Remarkably, the count up of programmed links (on a reset and reprogram) did not change. It counted up to 1300 again even though I took out many more links. The Main page stats are still the same. So I didn't really change the count but I have much cleaner links.

3. It would be great if you could add alerts for "Bad Link Entry" to the main page just like the warning for "unregistered device". I don't know what causes Bad Link Entry or how common it is. Maybe it is called by a full PLM?

4. In the past I have put non-load Keypad buttons (B through H) in groups to match when its linked load is in that group. For example if button C is linked to a kitchen light, I would check both the button C and the kitchen light in my group. Should I only put the kitchen light in the group and make sure the synch linked responders tick box is selected on kitchen light? That would eliminate more KPL links that might be redundant. I did this just to make sure the buttons stayed in sync, but maybe it is redundant and possibly makes things worse.

5. Same as #4 above, but what if the KPL non load button is actually the controller for a group? I would think I want the controller for the group in the group to keep the button in synch with the group.

[mnsandler]

2. i'll check the kpl programming code to see if the count is affected by the ini setting change. i can make code changes related to this in the new hs4 plugin.

3. the "Bad Link Entry" is usually related to a link with a group number that isn't registered with the interface anymore. the plugin keeps track of those.

4. i would keep this setup. otherwise things will get out of sync (others have tried to write a bunch of events to do this, but is just trouble; too hard to debug/maintain)

5. if a kpl btn is an optional controller, it doesn't add links to PLM (to make that work) but the plm will always be a controller to the same set of participants. otherwise you would have no way of controlling the group from an event action. Insteon never had a good command for triggering a group/scene that was only controlled by a single device. they actually tried, and removed it from most kpls after a while. and it was never implemented in any switches or other devices with buttons.

question: how many links show up in the display interface table now?

[jono]

2. i'll check the kpl programming code to see if the count is affected by the ini setting change. i can make code changes related to this in the new hs4 plugin.

3. the "Bad Link Entry" is usually related to a link with a group number that isn't registered with the interface anymore. the plugin keeps track of those.

4. i would keep this setup. otherwise things will get out of sync (others have tried to write a bunch of events to do this, but is just trouble; too hard to debug/maintain)

5. if a kpl btn is an optional controller, it doesn't add links to PLM (to make that work) but the plm will always be a controller to the same set of participants. otherwise you would have no way of controlling the group from an event action. Insteon never had a good command for triggering a group/scene that was only controlled by a single device. they actually tried, and removed it from most kpls after a while. and it was never implemented in any switches or other devices with buttons.

question: how many links show up in the display interface table now?

Only 269 links show up in the display links table. I never clicked that button to update the main page figures! Here is the new display:
"You have 193 internal Insteon device(s) registered in the system, 5 external device(s), and 34 group(s).
These devices and groups currently consume 269 link database entries in your interface.*
You have 190 unused outbound link addresses out of 254 total available.

* Click the Display Interface Links button below to update this number."

So this appears to be a big improvement! The number will probably go up a significantly when I re-instate links based on #4 above as I think the process knocked most of those out. I think the easiest way to do that will be to click "reprogram groups".

[mnsandler]

i would run the display links again. 269 seems low

[jono]

you are right; I ran it several times and got very different numbers: 26, 78,157, 372, 811,112
So I rebooted the PC, power cycled the PLM, reset/reprogrammed the PLM and I still get different numbers every time.

[mnsandler]

the process will abort if there is other messages/commands that the plm needs to process.

try running it at night when the house is quiet.

[jono]

I will do that later tonight. Separately, I can confirm that Reprogramming Group does put the links back in to the KPLs, at least if the B-H buttons are checked in the Group. Sounds like you recommend I continue to do that. This will give me a lot of my links back again as most of my non-load buttons are associated with a load somewhere or scene somewhere.

[jono]

It seems to cap out at 992 again.
But I think I am well beyond that actual number, which makes me wonder what is happening to all the other links?

[mnsandler]

Jono,
the links we discussed earlier (to be deleted) were only related to the plm controlling kpl btns.

kpl btns controlling groups is unrelated. these don't take space in the plm.

i think the links written after 992 just keep overwriting the last link in the database.

if you have detailed logging enabled, and write a link to the plm (either registering a device or group), do you see any errors or messages?

are you able to control the devices or groups that were created most recently?

[jono]

Here is a log snippet after the 992 links (this is around 1100) during a reset and reprogram. I don't think it looks any different than the earlier ones.

Jan-26 9:35:56 AM

Insteon

..waiting 198ms

Jan-26 9:35:56 AM

Insteon

Sending command 02 6F 40 F2 51 1A 1F DE 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:35:56 AM

Insteon

Calling AddRecord for 1A.1F.DE 81 False

Jan-26 9:35:56 AM

Insteon

..Time to send message: 849.4052

Jan-26 9:35:56 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 51 18 63 E0 00 00 00 15

Jan-26 9:35:55 AM

Insteon

..waiting 198ms

Jan-26 9:35:55 AM

Insteon

Sending command 02 6F 40 F2 51 18 63 E0 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:35:55 AM

Insteon

Calling AddRecord for 18.63.E0 81 False

Jan-26 9:35:55 AM

Insteon

..Time to send message: 849.3564

Jan-26 9:35:55 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 51 17 E1 FE 00 00 00 15

Jan-26 9:35:55 AM

Insteon

..waiting 198ms

Jan-26 9:35:55 AM

Insteon

Sending command 02 6F 40 F2 51 17 E1 FE 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:35:55 AM

Insteon

Calling AddRecord for 17.E1.FE 81 False

Jan-26 9:35:55 AM

Insteon

..Time to send message: 865.3297

Jan-26 9:35:55 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 51 16 45 8A 00 00 00 15

Jan-26 9:35:54 AM

Insteon

..waiting 198ms

Jan-26 9:35:54 AM

Insteon

Sending command 02 6F 40 F2 51 16 45 8A 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:35:54 AM

Insteon

Calling AddRecord for 16.45.8A 81 False

Jan-26 9:35:54 AM

Insteon

..Time to send message: 849.4534

Jan-26 9:35:54 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 51 15 B2 32 00 00 00 15

Jan-26 9:35:53 AM

Insteon

..waiting 199ms

Jan-26 9:35:53 AM

Insteon

Sending command 02 6F 40 F2 51 15 B2 32 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Here is an earlier one (around 667 links):

Jan-26 9:29:31 AM

Insteon

667 Links programmed...

Jan-26 9:29:31 AM

Insteon

..Time to send message: 692.0963

Jan-26 9:29:31 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 0A 56 CC CF 00 00 00 06

Jan-26 9:29:30 AM

Insteon

..waiting 199ms

Jan-26 9:29:30 AM

Insteon

Sending command 02 6F 40 F2 0A 56 CC CF 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:29:30 AM

Insteon

Calling AddRecord for 56.CC.CF 10 False

Jan-26 9:29:30 AM

Insteon

..Time to send message: 699.4317

Jan-26 9:29:30 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 0A 55 D9 04 00 00 00 06

Jan-26 9:29:29 AM

Insteon

..waiting 199ms

Jan-26 9:29:29 AM

Insteon

Sending command 02 6F 40 F2 0A 55 D9 04 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:29:29 AM

Insteon

Calling AddRecord for 55.D9.04 10 False

Jan-26 9:29:29 AM

Insteon

..Time to send message: 691.4073

Jan-26 9:29:29 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 0A 55 CE 55 00 00 00 06

Jan-26 9:29:28 AM

Insteon

..waiting 199ms

Jan-26 9:29:28 AM

Insteon

Sending command 02 6F 40 F2 0A 55 CE 55 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:29:28 AM

Insteon

Calling AddRecord for 55.CE.55 10 False

Jan-26 9:29:28 AM

Insteon

..Time to send message: 691.404

Jan-26 9:29:28 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 0A 1A 28 3A 00 00 00 06

Jan-26 9:29:28 AM

Insteon

..waiting 199ms

Jan-26 9:29:28 AM

Insteon

Sending command 02 6F 40 F2 0A 1A 28 3A 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:29:28 AM

Insteon

Calling AddRecord for 1A.28.3A 10 False

Jan-26 9:29:28 AM

Insteon

..Time to send message: 699.1091

Jan-26 9:29:28 AM

Insteon

..Got RF PLM Response 02 6F 40 F2 0A 1A 1F DE 00 00 00 06

[jono]

And here are the final ones:

Jan-26 9:38:17 AM

Insteon

A total of 1301 records were programmed into the RF PLM Interface.

Jan-26 9:38:17 AM

Insteon

1301 Links programmed...

Jan-26 9:38:17 AM

Insteon

..Time to send message: 849.717

Jan-26 9:38:17 AM

Insteon

..Got RF PLM Response 02 6F 41 A2 04 22 0C 05 00 00 00 15

Jan-26 9:38:16 AM

Insteon

..waiting 198ms

Jan-26 9:38:16 AM

Insteon

Sending command 02 6F 41 A2 04 22 0C 05 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:38:16 AM

Insteon

Calling AddRecord for 22.0C.05 4 True

Jan-26 9:38:16 AM

Insteon

..Time to send message: 858.2927

Jan-26 9:38:16 AM

Insteon

..Got RF PLM Response 02 6F 41 A2 03 22 0C 05 00 00 00 15

Jan-26 9:38:15 AM

Insteon

..waiting 198ms

Jan-26 9:38:15 AM

Insteon

Sending command 02 6F 41 A2 03 22 0C 05 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:38:15 AM

Insteon

Calling AddRecord for 22.0C.05 3 True

Jan-26 9:38:15 AM

Insteon

..Time to send message: 864.413

Jan-26 9:38:15 AM

Insteon

..Got RF PLM Response 02 6F 41 A2 02 22 0C 05 00 00 00 15

Jan-26 9:38:14 AM

Insteon

..waiting 199ms

Jan-26 9:38:14 AM

Insteon

Sending command 02 6F 41 A2 02 22 0C 05 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:38:14 AM

Insteon

Calling AddRecord for 22.0C.05 2 True

Jan-26 9:38:14 AM

Insteon

..Time to send message: 859.5479

Jan-26 9:38:14 AM

Insteon

..Got RF PLM Response 02 6F 41 A2 01 22 0C 05 00 00 00 15

Jan-26 9:38:13 AM

Insteon

..waiting 198ms

Jan-26 9:38:13 AM

Insteon

Sending command 02 6F 41 A2 01 22 0C 05 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:38:13 AM

Insteon

Calling AddRecord for 22.0C.05 1 True

Jan-26 9:38:13 AM

Insteon

..Time to send message: 857.2591

Jan-26 9:38:13 AM

Insteon

..Got RF PLM Response 02 6F 41 A2 EF 22 0C 05 00 00 00 15

Jan-26 9:38:12 AM

Insteon

..waiting 198ms

Jan-26 9:38:12 AM

Insteon

Sending command 02 6F 41 A2 EF 22 0C 05 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

Jan-26 9:38:12 AM

Insteon

Calling AddRecord for 22.0C.05 239 True

Jan-26 9:38:12 AM

Insteon

..Time to send message: 865.5351

Jan-26 9:38:12 AM

Insteon

..Got RF PLM Response 02 6F 41 A2 04 45 83 B5 00 00 00 15

Jan-26 9:38:12 AM

Insteon

..waiting 198ms

Jan-26 9:38:12 AM

Insteon

Sending command 02 6F 41 A2 04 45 83 B5 00 00 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:True

[jono]

Mark, I'm not onsite to test today, but if you can tell me which part of the following is the device code I might be able to do some testing (even remotely through polling).
Sending command 02 6F 41 A2 04 22 0C 05 00 00 00

[mnsandler]

Mark, I'm not onsite to test today, but if you can tell me which part of the following is the device code I might be able to do some testing (even remotely through polling).
Sending command 02 6F 41 A2 04 22 0C 05 00 00 00

41 A2 04 are link data, and the next three 22 0C 05 should be a device address.

ps. posting html from the hs log into the forum gets messed up visually.