Well then, thanks to @kclenden too! And, thanks to @Guy Lavoie and @paulbates who helped get the ball rolling.

The time frame of that errant code insertion, does match up with the observed faulting issue, so good circumstantial evidence.

I'm going to sit with just the few devices I have restored for now, and confirm that they stay fully working -- a day should do it. There are only 32 PLM table entries right now, so easy to download/compare.

If no further resets/issues, will do a full PLM restore, and as you suggest, follow that up with a DEVICE RESTORE on each device, for good measure!

Thanks again.

And, will report back.

Orest

Edited June 21Jun 21 by oskrypuch

35 minutes ago, oskrypuch said:

Well then, thanks to @kclenden too! And, thanks to @Guy Lavoie who helped get the ball rolling.

The time frame of that errant code insertion, does match up with the observed faulting issue, so good circumstantial evidence.

I'm going to sit with just the few devices I have restored for now, and confirm that they stay fully working -- a day should do it. There are only 32 PLM table entries right now, so easy to download/compare.

If no further resets/issues, will do a full PLM restore, and as you suggest, follow that up with a DEVICE RESTORE on each device, for good measure!

Thanks again.

And, will report back.

Orest

@oskrypuch , hope it helps. Please do report back. As I said, this is the 1st time I've seen this. Likely will not be the last.

And, I'll keep the device event viewer/log rolling for now.

Orest

Edited June 21Jun 21 by oskrypuch

Oh yes, looking forward to the conclusion on this. Kind of surprised that you can get communications errors between the Polisy and the PLM. I'd venture that it's more about message timing or buffering than actual comms, since serial or USB ports aren't a collision domain.

Question for those of you who have a PolISY or Eisy -

The ISY994 has a configuration shell that can be accessed through telnet. One of the items in the shell is a "CD" or "configure delay between requests. I interpret this to be a delay between successive requests to the PLM.

My ISY994 was originally set to a CD timing of 500mSec. I found this to be a very bad setting for my system. I have been using 1000 mSec for most of this year with good results.

My question is - does the PolISY or EISY have something similar to this timing feature? It can be extremely helpful in preventing overrunning the PLM when things don't go as planned.

I don't see any such setting in the configuration screen or menus.

That's unfortunate.

Thanks for checking

The few PLM entries I added did not change, or vanish, overnight, and function on these devices is preserved, so ...

Completed a full PLM restore (293 lines now), and now doing a full device restore.

Looking good, so far.

Orest

20 minutes ago, IndyMike said:

That's unfortunate.

Thanks for checking

Guy beat me to it (looking), but just wondering, have you tied the 1/2 sec (vice 1 sec) delay to errors in data Tx?

Orest

Edited June 22Jun 22 by oskrypuch

4 minutes ago, oskrypuch said:

Guy beat me to it (looking), but just wondering, have you tied the 1/2 sec (vice 1 sec) delay to errors in data Tx?

Orest

Yes - The following is a history of errors VS request delay for the restore of a KPL. The restore process requires ~800 I1 commands.

I tried increasing and decreasing delays. Also repeated delays multiple times and re-checked the 500 mSec because I couldn't believe what I was seeing. I don't understand why, but 500 mSec was the worst.

That is some impressive sleuthing.

The log files are all txt, so easy to manipulate. Did you write some code in C or python or something?

I have the original Insteon design white paper (somewhere), and was going to dig into it years ago, but got distracted by something else.

Orest

Edited June 22Jun 22 by oskrypuch

My second Python project. 1st was interrogating yahoo finance for stock dividends and the like.

I am an absolute hack when it comes to software. Background is Fortran IV, C, Pascal, and Cobol. Python was surprisingly easy to pick up. A friend from work set me up with a Spyder 6 package and I've been playing ever since.

Is I indicated earlier, it was @kclenden that put me on this path. He was the one that noted the errors in the event viewer.

Python is easy to pickup, quite powerful, and available on most every platform. Less popular these days, but still very handy with a rich library of code.

Orest

I'm slowly picking up Python. I hate the lack of braces for framing code sections. Depending on white space for proper grouping is ugly and error prone.

@IndyMike

Well, it has been a day or two, and all is running normally.

But, I did notice a difference in the PLM table. Same number of items, and the "id" three bytes, and the "data" two bytes are constant, but in a half dozen (of the 293 lines), the FL & GR values, which is the first two bytes, did change.

I am thinking that this is normal?

Orest

Edited June 23Jun 23 by oskrypuch

@oskrypuch , that actually doesn't look normal. I'm hoping that something simply moved around in the PLM. That could happen if you were adding/deleting scenes.

Would you mind posting your tables? I normally import to excel so I can see them in Hex.

Well, I have the UI's XML dump from the 22nd, 23rd and 25th. The latter two, the 23rd & 25th are identical, the initial one on the 22nd differs slightly, as I was commenting.

I've attached the two that differ.

Orest

PLM Links Table.v5.4.4__Mon 2026.06.22 11.57.31 AM.xml PLM Links Table.v5.4.4__Tue 2026.06.23 01.40.12 PM.xml

@oskrypuch , it looks like all your data is there. For some reason it's been re-ordered.

The following shows the entries for your device @46.7A.2B. The column names correspond to the XML entries -

1. ix - PLM record number (Dec)

2. ad - PLM record number (Hex)

3. fl - Flag (Hex). "E" = controller, "A" = Responder

4. gr - Group # (Hex)

5. id - Device address (Hex)

6. data - Device specific data (on level, ramp rate, varies by device/scene)

It looks like your second table was re-written in "group ascending" order. I don't know why this was done. I spot checked a couple of other devices - they were not altered.

In any event, it looks like your PLM is managing to hold onto its data

Ok, good to hear, and I now have the data dump so can review in future.

Thanks for checking it out. Looks like I am back in business!

Orest