PLM Link Table -- not reliable at all

[karwas]

Hello,

 

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,

Przemek

 

[jerlands]

Network communication interferes with PLM Link Table reads.  Try and chose a period of inactivity.

 

 

Jon...

[stusviews]

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.

[karwas]

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,

Przemek

 

 

 

Edit:

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

 

Przemek

 

 

[paulbates]

Przemek

 

How old is your PLM? A varying, flaky link table can be the sign of  a dying PLM. Especially if its at, or over 2 years old.

 

Any suggestions how to troubleshoot this issue?

 

 

Paul

[karwas]

@Paul -- It was purchased few month ago (smarthome.com) 

and deployed to the network 2 or 3 months ago.

 

Przemek

[paulbates]

Przemek

 

I had a new one die last march, at almost 3 months to the day.

 

How many links are you seeing, approximate high count and low count? 

 

Paul

[karwas]

@Paul

 

High, and I believe correct, count is 141

Low vary -- sometimes 20, sometimes 116, some other time 67

 

Please note that I don't have 141 devices, but I do have several keypads

 

Przemek

[paulbates]

Przemek

 

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. 

 

Paul

[jerlands]

Here a link to ISY PLM Link Calculator which will give you a rough idea.

 

 

Jon...

[karwas]

@Paul

 

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.

 

Przemek

[paulbates]

Przemek

 

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...

 

Paul

[LeeG]

karwas

 

 

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. 

[karwas]

@LeeG

 

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....

 

Przemek

[LeeG]

karwas

 

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.