Jump to content

PLM Link Table -- not reliable at all


Recommended Posts



I have an ISY 994i connected to PLM 2413S and several (50+)

various Insteon devices in the house.


My understanding is that ISY communicates with PLM directly over serial cable.

So I am surprised why whenever I try to read PLM Link Table, I am receiving

different number of records.

There is no Insteon network (powerline nor RF) involved in this scenario,

so why is it unreliable?


Any suggestions how to troubleshoot this issue?


Thank you,



Link to comment

The PLM and ISY using a serial protocol over a Cat5 cable. Any Insteon traffic will alter the count. Power the PLM from a filterLinc to keep inbound traffic out.

Link to comment

I see...


Ignore this, I was wrong.


So, basically, there are 2 kinds of data traveling on RS232 link between PLM and ISY:

1) pooling session, initiated by ISY, walking all records in the link table

2) unsolicited traffic, which is a reflection of network traffic.


Due to lack of data link protocol, like TCP or UDP ports, those streams can get mixed,

and as a result, the walking session of ISY reading PLM link database, is interrupted.


It is a pitty, that Insteon didn't implemented some kind of data link protocol,

to avoid such issues, and allow demultiplexing of multiple data streams... :-(


Thanks for your clarification,






I have just looked in Insteon Developer Guide, and if I understand it correctly,

this is a way how it works



All communication from ISY to PLM starts with:

(1) 0x02 (STX) octet as as start of message, then 

(2) 0x?? command code

(3-??) command specific


When PLM replies, it forms a message with:

(1) 0x02 (STX) octet as as start of message, then 

(2) 0x?? reply code

(3-??) reply data

(last) 0x06 (ACK) to terminate message


or when PLM is busy, it replies 

(1) 0x15 (NAK) to indicate negative acknowledgement.


So, even if there are some concurrent processes happening

at the same time, by looking at reply code and command code,

ISY should be able to demultiplex such data streams





Link to comment



You'll have more than one link per device.. as you indicate keypads might have 1 per key, and then also links for scenes.


The low number is too low.  If you are looking at this table because your programs are not initiating from activity from the network as they should, or insteon devices are not turning on from programs as they should... that's the sign its dying its time to request a warranty replacement. 



Link to comment



All programs and scenes are working properly.


Well, occasionally I see some glitches (red LED blinking) on new dimmers,

but those are mostly related to Insteon communication issues.


The problem with PLM link table is such, that I have just discovered

that on two consecutive PLM Link table reads, I got different count of records.

As nothing was changed in the network between those reads, it looked

suspicious to me. So I executed "Show PLM Link Table" few more times,

and every time I got different number of records.



Link to comment



I just ran mine, 47 devices, 3 times in a row, 221 links each time.


One other thing to check, is the serial cable to the ISY. Unplug both ends and snap back in, or see if you have a replacement cable.


If that doesn't change anything, I'm going stay with it being a defective PLM, new as it may be...



Link to comment




The ISY issues a Get Next command to read next PLM link record.   Any Insteon activity that reaches the PLM will adversely affect what link record the Get Next command retrieves.


Link 30

Link 31

Link 32

Link 33

Link 34

Link 35

Link 36


A Get Next reads Link 31.   An Insteon message is processed that is associated with Link 34.  The next Get Next command will read Link 35, skipping 32, 33, and 34, making the PLM link count appear less than is actually there.


The other case is Link 34 is read with a  Get Next.   An Insteon message is processed that is associated with Link 30.  The next Get Next reads Link 31, 32, 33 and 34 again. making the PLM link count appear more than is actually there.


When running a Show PLM Links Table no Insteon message must reach PLM.  Otherwise the PLM Link count will be too high or too low. 

Link to comment



Thanks for your explanation.


This is basically a problem of "state management" in basically "stateless" protocol.


Per your description, state (the knowledge which index to the table is used currently),

can be disturbed by some asynchronous event.


The simple remedy for this problem would be to modify "Get Next" in the way where

it will convey an expected state. Basically, Get Next should have a parameter,

which will be a last read index.


Then, you will issue set of commands like this



S: Get Next 31

R: Reply 32

S: Get Next 32

R: Reply 33



In this scenario, even if you would inject some disruption between  those commands,

next "Get Next" will put index into correct position.


It is an old technique, it was used since (forever) in computer networks.

(e.g. https://tools.ietf.org/html/rfc1157#section-4.1.3)


Too bad, that we are always trying to reinvent the wheel,

even if someone had done it already....



Link to comment



Those suggestions would be best communicated to Smartlabs who designed and own the PLM.  The PLM has always worked that way, at least for the many years I have been using them.


For now make sure the Insteon network is quiet during the Show PLM Links Table.

Link to comment


This topic is now archived and is closed to further replies.

  • Create New...