karwas Posted March 6, 2016 Posted March 6, 2016 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 Posted March 6, 2016 Posted March 6, 2016 Network communication interferes with PLM Link Table reads. Try and chose a period of inactivity. Jon...
stusviews Posted March 6, 2016 Posted March 6, 2016 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 Posted March 6, 2016 Author Posted March 6, 2016 (edited) 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 Edited March 6, 2016 by karwas
paulbates Posted March 6, 2016 Posted March 6, 2016 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 Posted March 6, 2016 Author Posted March 6, 2016 @Paul -- It was purchased few month ago (smarthome.com) and deployed to the network 2 or 3 months ago. Przemek
paulbates Posted March 6, 2016 Posted March 6, 2016 (edited) 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 Edited March 6, 2016 by paulbates
karwas Posted March 6, 2016 Author Posted March 6, 2016 @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 Posted March 6, 2016 Posted March 6, 2016 (edited) 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 Edited March 6, 2016 by paulbates
jerlands Posted March 6, 2016 Posted March 6, 2016 Here a link to ISY PLM Link Calculator which will give you a rough idea. Jon...
karwas Posted March 6, 2016 Author Posted March 6, 2016 @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 Posted March 6, 2016 Posted March 6, 2016 (edited) 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 Edited March 6, 2016 by paulbates
LeeG Posted March 6, 2016 Posted March 6, 2016 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 Posted March 6, 2016 Author Posted March 6, 2016 @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 Posted March 6, 2016 Posted March 6, 2016 (edited) 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. Edited March 6, 2016 by LeeG
Recommended Posts