cant get keypadlinc to communicate with ISY

[someguy]

Okay, still having problems. I deleted a number of scenes and my number of links is now down to about 500. I did a "restore PLM" and my ISY still doesnt get status updates from keypadlinc button presses. (just in case that isn't clear, when I press buttons on the keypadlinc, nothing happens to the ISY on/off status for the button until I Query the keypadlinc) I still think it is a bug.

 

After deleting the scenes and doing the "restore PLM", I get this:

[LeeG]

Run Show PLM Links Table and look for 8 link records that look like

 

A2 01 1D.99.7F xx xx xx

A2 02 1D.99.7F xx xx xx

A2 03 1D.99.7F xx xx xx

A2 04 1D.99.7F xx xx xx

A2 05 1D.99.7F xx xx xx

A2 06 1D.99.7F xx xx xx

A2 07 1D.99.7F xx xx xx

A2 08 1D.99.7F xx xx xx

 

These are the Responder link records that allow the PLM to see the button press messages from the KeypadLinc.

 

Are you certain this is the only device that is not showing status changes?

[LeeG]

Had wanted to post this yesterday

 

There are four things that must exist for the ISY to be aware of a KPL button press.

 

1 KPL must have Controller link records for each button = Show Device Links Table shows these

2 PLM must have Responder link records for each button – verified visually

3 KPL must send a message when button is pressed

4 Insteon mesh network must get message to the PLM

 

1 & 2 have been verified.

To verify 3 define a Scene with a KPL button as Controller and some other device a Responder. Does the KPL button control that device? If yes the Insteon network to the PLM is in question. If the KPL button does not control the responder either the KPL is defective or the Insteon network is in question.

To verify 4 put the KPL on an Appliance cord and plug the KPL into PLM circuit.

[someguy]

There are four things that must exist for the ISY to be aware of a KPL button press.

 

1 KPL must have Controller link records for each button = Show Device Links Table shows these

2 PLM must have Responder link records for each button – verified visually

3 KPL must send a message when button is pressed

4 Insteon mesh network must get message to the PLM

 

(yes, I'm still working on this. it has been a busy week and thanks, LeeG)

 

I keep running the "Show PLM links table" and usually get 500-700 links. When I look through them all, I find NO links that have the address for the Keypadlinc that is giving me trouble (1D.99.7F). I've tried removing the KPL from ISY and then re-adding it and my PLM still doesnt seem to get the link record in there. I can't help but to think that my ISY is to blame, he's handling the transaction between my KPL and my PLM, isn't he?

 

As far as number 4 (above), I don't think that this is the issue, because I have two other insteon devices on the same circuit and both of them aren't having any problems. BTW: one of them is a 6 button KPL and it works fine and it DOES have a link record in the "Show PLM Links table".

[someguy]

okay, after running the PLM link table again, I came up with this:

 

 

 

I understand that 992 may be the maximum number of links. Despite the fact that my KPL is on the list here (1C.8C.74, which is my other 8 button KPL) when I press the KPL buttons (I've tested them all), the ISY doesn't know the status of any of them until I "query" the KPL with the ISY.

 

Any thoughts?

[LeeG]

The KeypadLinc with 1C.8C.74 is missing 3 of its link records in the PLM. Need a Show Device Links Table for that device to see if it has the required E2 xx link records.

 

The number 992 in combination with the missing last 3 link records for button F,G,H tells me the PLM is full. The varying number of PLM link records (500-700) is the result of the PLM seeing inbound Insteon traffic during the Show PLM. The ISY uses a PLM Serial command that requests the Next Link Record. The problem is the PLM alters the Next Link Record pointer to match the link record that matches an inbound Insteon message. Either groups of link records are skipped or groups are read multiple times depending on whether the inbound message matches a link record past or before the current Next Link Record pointer. That is why I indicated a Show PLM must produce a consistent result for the result to be considered accurate.

 

The solution to the 1D.99.7F problem is to reduce the number of link records. The PLM will not pass a message on to the application (ISY in this case) unless the inbound message matches one of the Responder (A2) link records that also matches the button Group number and Insteon address of the device.

 

Need to see a Show Device Links Table result for the other KeypadLinc to begin to analyze that. Would have thought the first few buttons would have worked if the KeypadLinc has the required link records.

[Michel Kohanim]

Hi someguy, in addition to LeeG's comments right above, would you please do a quick browse through of your PLM links table and see if you have many IDENTICAL records. By identical I mean truly identical: everything is identical!

 

Lately, we have had many reports of PLMs with identical records (which should be an impossibility) and thus contributing to large number for link count.

 

With kind regards,

Michel

[IndyMike]

Michel,

 

Your comment on "repeated records" caught my attention. I decided to perform some testing on my 2412S PLM.

 

The results of very different from what I remember. I performed multiple scans with the PLM in different configurations and downloaded the link table results to excel. Using excel, I was able to delete duplicate records. The unique record count is consistent across the runs. The reported record count varies wildly.

 

What I learned:

• [*:voshzmdg]I had thought that incoming transmissions interrupted the PLM causing an understatement of the link records. What I found was that when the PLM was interrupted, it would repeat records causing an overstatement of total records.
  [*:voshzmdg]I had previously thought that only powerline of RF (in the case of a 2413S) would interrupt the link count. From testing I found that scheduled programs (queries and the like) would also interrupt the count.
  [*:voshzmdg]Run 7 showed an overstatement due to a powerline command making it through my double filters. I was logging events in the viewer and saw a device communication register.

 

What I don't know -

• [*:voshzmdg]I disabled programs, weatherbug, and time updates. The programs defiantly had an effect. Not sure about weatherbug or the internet time updates.
  [*:voshzmdg]My connection to the Elk was active during the scans. I did not see an Elk status change during the PLM link read. Don't know if this could affect the count.

 

Based on the above, I would guess that someguys link count is below what is being reported. Since he is using a 2413S with RF, the likelihood of obtaining a UN-interrupted count is far lower than mine.

 

IM

[Michel Kohanim]

Hello IM,

 

Thanks so very much for this thorough analysis.

 

The problems we are finding are that:

1. Link count is much larger than what it should be (>800)

2. Devices do not send status updates

 

The only commonality in this case is duplicate link records. Sometimes, a PLM restore removes some of the duplicate records but, in most cases, the duplicates are the same (i.e. same devices). Was this the case with your 2412S as well?

 

With kind regards,

Michel

[IndyMike]

Hello Michel,

 

I do not believe that my 2412S contains duplicate records. When I was able to isolate the PLM and shut down programs I received a consistent 407 records.

 

During times of traffic or program activity, the PLM would report duplicate records but there were only 407 unique. The ISY appears to be requesting the "next link record" rather than using absolute addressing. I believe my 2412S is getting confused with inbound communication and repeating previously transmitted data.

[LeeG]

IM, Michel

 

That is exactly what happens. As the PLM is retrieving link records sequentially it relies on what I have been calling the Next Pointer which is the location of the next link record to be read by a Get Next request. This Next Pointer is altered by a link database search resulting from inbound traffic. If the inbound traffic results in the Next Pointer being set to a location already read by the Get Next Process the same link records are read twice. They are not physically duplicate, but logically duplicate from being read more than once.

 

If the link database search generated from inbound message matches a link record that has not yet been read by the Get Next process, link records are skipped by the Get Next process because the search alters the Next Pointer to a point later in the link database.

 

I have reproduced this condition at will. It is not intermittent. It happens every time an inbound message is received during the Get Next processing. Either the link record count is high because some link records are read twice (or more if more than one inbound message is received) or the count is low because some of the link records are skipped.

 

When I ran tests to determine how many link records actually fit in a 2413 PLM, during reading the link records back I could consistently create a false high count or false low count simply by when I sent the inbound message to the PLM relative to how far the Get Next process had progressed.

 

The only solution is to use the Serial PLM commands that access PLM link records by specific address rather than just asking for Get Next.

[Michel Kohanim]

Hello IM/LeeG,

 

Thanks so very much. This is indeed great news and, at the same time, not such great news since we now have to figure out why some devices (at the end of the database) do not send status updates.

 

Thanks again so very much to both.

 

With kind regards,

Michel

[IndyMike]

Michel,

 

Agree that this is somewhat bittersweet news... I am also not sure that we can say that it's devices near the end of the link database that have issues. I have 407 links in my plm but, as Lee indicated, I can generate link pretty much any link count by interrupting the process with a simple device "on" communication. I've been testing with a specific Icon relay - each time I activate the relay the PLM re-starts transmitting links from the same location (again, as Lee stated).

 

In short, we may need to get back to an address based link interrogation method before we can say what is happening with someguy's link table.

[Michel Kohanim]

Hi IM,

 

Yes, I agree.

 

With kind regards,

Michel

[someguy]

I have solved my problem with my ISY not knowing what buttons I am pressing on my 8 button KPL. I did this by deleting a number of scenes and then doing a "Restore PLM". I've read the other discussion and I have some questions:

 

1) Is the process of "Restore PLM" as delicate as "Show PLM Links Table"? (i.e. will insteon traffic screw up the restore process?)

 

2) How does the "Restore PLM" prioritize what it restores to the PLM? (i.e. are the latest added scenes left out when it fills the PLM)

 

3) Is there a way to add a PLM record to the PLM without using "Restore PLM"?

 

4) Is there any better way to count and compare links? Looking through hundreds of links for a certain insteon address is cumbersome.

 

5) Are there plans to make a PLM that holds more data? kind of ridiculous that it only holds 992 (or so?) links. (If no, then can we hereby put in a request?)

 

btw: I do very much appreciate the help. My KPL is working now. Much obliged, sirs

[LeeG]

1) Is the process of "Restore PLM" as delicate as "Show PLM Links Table"? (i.e. will insteon traffic screw up the restore process?)

 

I don’t think so because the add process is searching for an existing link with the same information. It is not just dumping the next add at a preset next point. That is what I think rather than what I know from explicit tests.

 

2) How does the "Restore PLM" prioritize what it restores to the PLM? (i.e. are the latest added scenes left out when it fills the PLM)

 

The last Restore Modem (PLM) restored by Insteon address in ascending order. However, there were two different blocks of addresses. Not sure why there were two different blocks of Insteon addresses. Both blocks were in ascending order.

 

3) Is there a way to add a PLM record to the PLM without using "Restore PLM"?

 

Adding a new ISY Scene will do that.

 

4) Is there any better way to count and compare links? Looking through hundreds of links for a certain insteon address is cumbersome.

 

The Show PLM Links Table display can be saved to a file. I used WordPad to view that file. The problem is the data is stored in decimal, not hex so values have to be converted. For example, the Insteon address would have to be converted to decimal with the decimal value used in the Find.

 

5) Are there plans to make a PLM that holds more data? kind of ridiculous that it only holds 992 (or so?) links. (If no, then can we hereby put in a request?)

 

This forum will not have that answer. Even if SmartLabs had plans for that they would not make it public. The Smarthome forum has a category for making Insteon product requests.

 

The 2412 PLM physically held 2000+ links. There were reports that the PLM could not search the entire link database for a matching inbound record before the next inbound record arrived. Some reports links over 800/900 links could be a problem. I have no hard evidence of that.

 

The 2413 PLM has a faster processor and supports a much smaller link database. Only speculation that was done to solve the 2412 link search problem.

[someguy]

On this question:

 

3) Is there a way to add a PLM record to the PLM without using "Restore PLM"?

 

How about a device that doesn't have a link record? Is there a way to get one in the PLM without "Restore PLM"? will removing it from ISY and then re-adding it be expected to work if I haven't reached my maximum number of link records?

[LeeG]

The device should be Deleted from the ISY and added back. The ISY generates the required link(s) in the device and the PLM during device add. Would be a good idea to factory reset the device before adding it back.

 

Theoretically the PLM can be connected to a Serial port on a PC and write an application that creates the PLM link record. Requires knowledge of the PLM Serial command set, serial command interface protocol with the PLM in additional to the ISY requirements for link records in the PLM. I think Deleting the device and adding it back is best approach.

[IndyMike]

4) Is there any better way to count and compare links? Looking through hundreds of links for a certain insteon address is cumbersome.

 

The Show PLM Links Table display can be saved to a file. I used WordPad to view that file. The problem is the data is stored in decimal, not hex so values have to be converted. For example, the Insteon address would have to be converted to decimal with the decimal value used in the Find.

 

If you have Microsoft Excel 2003 and above, you can import the XML file directly. Excel will create a table of the XML data in integer format (left table below). To convert to Hex, use the Hex2Dec function as shown in the right hand table below. Note that the "ix" column is still in integer - other values in Hex.

 

 

 

The real value in importing the data is the ability to search for duplicate records. To do this:

1) Copy the second data table (the one with the hex values).

2) Perform a "paste special" as "values" to a 3 table in your worksheet. This will cause the Hex2Dec functions to evaluate to simple values in this table.

3) Select your 3rd table and perform a "remove duplicates" from the Excel data tab. deselect the "ix" and "ad" columns from the duplicates scan.

 

Excel will remove any duplicate entries from the PLM scan. If the scan completed properly, there should not be any duplicates. In my case, the raw scans indicated anywhere from 407 to 743 records. After removing the duplicates, I had 407 records across nine runs.

 

[someguy]

so do you then reimport the new link table into the ISY?

 

(If so, would you expect the next time that you click "Restore PLM" that it would re-duplicate the links?)

[IndyMike]

so do you then reimport the new link table into the ISY?

 

Absolutely NOT! I'm sorry, but I may be confusing the real issue...

 

The duplicate links displayed are due to a problem with the PLM "get next record" process. The process can be interrupted, and as a result, the PLM begins reporting links that it has already sent to the ISY (the duplicates).

 

From what I can see, this is a problem with the PLM reporting method only. I do NOT believe that there are actually duplicate records in the PLM.

 

I used the Excel process to determine the "correct" number of links in the PLM by eliminating the duplicates. Unfortunately, it's not perfect. The PLM can "skip" link records as well as "duplicate" them. I performed the above 9 times before I was comfortable that I truly had 407 records.

 

Bottom line - the ISY writes and manages the link records in the PLM using a different process. I fully trust the ISY to perform this correctly. I am constantly creating and deleting test scenes and have not had an issue with lost or duplicate records.

 

I am a bit disappointed that the PLM has issues in correctly reporting the link records back to the ISY. As usual, the UD folks will be looking for a viable workaround to make this a usable feature.

[someguy]

4) Is there any better way to count and compare links? Looking through hundreds of links for a certain insteon address is cumbersome.

 

The Show PLM Links Table display can be saved to a file. I used WordPad to view that file. The problem is the data is stored in decimal, not hex so values have to be converted. For example, the Insteon address would have to be converted to decimal with the decimal value used in the Find.

 

If you have Microsoft Excel 2003 and above, you can import the XML file directly. Excel will create a table of the XML data in integer format (left table below). To convert to Hex, use the Hex2Dec function as shown in the right hand table below. Note that the "ix" column is still in integer - other values in Hex.

 

PLMscan3.PNG[/attachment]

 

I used this but skipped the Hex2Dec conversion. I'm guessing that this step can be skipped.

[IndyMike]

Someguy,

 

Sorry for the long delay in responding...

 

The Dec2Hex conversion was to allow you to look up the device addresses and compare them with the ISY listing. Not required otherwise.

 

Were you able to eliminate the duplicate entries and get to a consistent link count?

[someguy]

I've got two or three fairly consistent counts in the 350 range. I've gotten many counts less than 20 and others as high as 992 (which when I use this technique, gives me a number in the 350 range). It is difficult to get a good count. I'm still working on it. Thank you for your help.