Device Links Table Corrupteds

[justin.cool]

Device Links Table Corrupted

 

I have been trying to chase down some reliability issues with a particular pair of KPLs that are on the same branch circuit, and in very close physical proximity.  Both KPLs are Dual Band KPL 8s, converted to KPL-6’s. 

 

Restore Device on both and perform a Show Dev Links Table and both report that all records are present and a 100% match.  The reliability issues are gone at this point. 

 

24 hours later I ran Show Dev Links table and get corrupted tables again. In one case, it is one mismatch and nine records missing and in the other it is two mismatches, but all records there.  

 

Perform Restore Device again on both, Show Device links show all records present and 100% match for both KPLs.

 

A few days later I run Show Device Links Table again and one KPL is fine, all records are present and they all match and the other has been corrupted, 2 mismatches.  And just to make sure I run the Show Device Links Table twice on each and got the exact same results both times. 

 

What could be causing the mismatches / corrupted tables?  Power drop outs?  Other noise in my system?

 

NOTE:  When a mismatch occurs with these two KPLs, 95% of the time it is in the first two bytes, what should be “E2” is an “EA”. 

 

 See attached Event Viewer run for the Show Dev Links Table for the KPL with 2 mismatches. 

Event Viewer Show Device Links Table for Lv Rm KPL2.doc

[LeeG]

The 0x08 bit (0xEA - 0x08 - 0xE2) is something new with I2CS.  I do not know what the 0x08 bit means but it is not necessarily an indicator of an error.

 

What are the KPLs firmware level.   the insteondetails.pdf manual has been updated since the last time I looked for that bit definition, I'll do another search for that bit definition. . 

 

Are there actual KPL failures?

[justin.cool]

LeeG,

 

Thanks for the quick response.  I am not following your first two sentences......must be a bit thick this evening....a short explanation would really be appreciated. 

 

The 0x08 bit (0xEA - 0x08 - 0xE2) is something new with I2CS.  I do not know what the 0x08 bit means but it is not necessarily an indicator of an error.

 

Both KPLs are v.43 per the Admin Console.  Is that the firmware version, or do I have to remove the switchplate and read a version number there?

 

As for failures.......yes, failures do occur, but not everytime I see a "mismatch".  But when they do, the take the form of not turning the scene ON/OFF as expected.  In any case, the failures go away when the Restore Device has taken place. 

[LeeG]

The 0x10 and 0x08 bits have new uses for I2CS devices which the KPLs are.

Note: Bits 3 and 4 of the database FLAGS byte contain a smart hop count. These bits are set for controller records and can update every time the local device cleans up that record based on the cleanup ACKs received hop count. This is to pick the “best” starting hop count for a device. Hop counts can be either 0,1,2 or 3. bits 3 and 4 should be cleared when manipulating the database and they will ratchet up if needed.

Example:

0xAA = 1010 1010 = (Active, controller, 1, smarthop = 1, so start cleanup at 1 hop, 0, high water set, 0

There is also a chart that makes this a little easier to understand but was not able to copy from Developers Information for I2CS.

Go to http://www.insteon.com/developer/#devdocsand select Insteon I2CS - Developer Notes

Pages 7 & 8

The example is for a Responder link (0xAA) but bits 3 & 4 apply to Controller links as well

[LeeG]

Here are images of the area in the I2CS Developer Notes

 

 

[justin.cool]

LeeG,

 

I think I got it now.....Getting an 0xEA in the first byte of an All-Link Database Controller Record (instead of an 0xE2) could be expected per the I2CS Developer's notes, page 8, in particular.  And thus your statement:  "...0x08 bit means but it is not necessarily an indicator of an error."  So the SmartHop two bit values start out as cleared, then can be "ratcheted up" based on an update from the local device on cleanup of ACKs received hop count.  But then those two bits go back to cleared when a Restore Device is done, for example. 

 

Did I get that right?

 

Next question:  It would appear that this is NOT really a mismatch error, but rather an acceptable mismatch.  So given that, why does the ISY declare it as a mismatch?  Or is this not the way it works? 

[LeeG]

"Did I get that right?"  

 

Your conclusions are right on, good work.   

 

Don't know what UDI thinks about this.   The link records do not physically match what was originally written which could be useful information for a user.  The Responder found addition Hops were required by the Controller so starting there should improve comm.  Could indicate a comm issue that a user might want to investigate.  I would vote to leave the mismatch message as I prefer to know where to look rather than searching through an entire link database.  Others may not want to know about the workings of Insteon.

[justin.cool]

LeeG,

 

I agree, better to leave the mismatch detected, and know that a possible com issue exists.  But it does limit using the Show Dev Links Table function as a tool to determine com issues, to those of us that understand this very subtle "mismatch" is OK.

 

In any case, I have a number of other com issues to try and understand, or knock down.  This one was precipitated by a power outage, that forced RESTORE DEVICE.  It is now clear to me that the restore worked fine and no further issues exist with these devices. 

 

I will generate a seperate thread for those......stay tuned! 

 

Thanks again!

 

Justin

[Michel Kohanim]

LeeG and Justin,

 

Thanks so very much for the feedback!

 

With kind regards,

Michel

[justin.cool]

LeeG,

 

I have done some further testing with the same KPLs and the mismatches. 

 

I have one scene ALL LIGHTS OFF that has about 65 devices.  About 1/2 to 1/3 are KPL buttons in the scene as followers to keep them sync'd up. 

Both of the KPLs in this thread have a button that is non-toggle OFF just for this ALL OFF scene.  Both KPLs are dual band, one is mounted in a switch box, with another older unrelated KPL (non dual band) next to it.  The second KPL (Lv Rm KPL2 Shadow) is a test KPL, in a table top enclosure and plugged into an outlet within about 18 inches of the first KPL, (Lv Rm KPL2) and is on the same branch circuit. 

 

Ran Show Dev Links Table on Lv Rm KPL2 Shadow

100% Match

Pressed button B, the ALL LIGHTS OFF scene

 

Ran Show Dev Links Table

Got 10 mismatches

 

In KPL

[Record mismatch] 0F88 : EA 03 11.26.21 01 00 03

[Record mismatch] 0F50 : EA 04 0F.FD.95 01 00 04

[Record mismatch] 0F48 : EA 04 10.03.96 01 00 04

[Record mismatch] 0F30 : EA 04 10.04.F8 01 00 04

[Record mismatch] 0F20 : EA 04 10.92.08 01 00 04

[Record mismatch] 0F10 : EA 04 11.26.21 01 00 04

[Record mismatch] 0EB8 : FA 04 14.CD.BA 01 00 04

[Record mismatch] 0EA8 : EA 04 16.A0.2B 01 00 04

[Record mismatch] 0E78 : EA 04 25.7D.08 01 00 04

[Record mismatch] 0E48 : EA 04 29.46.C0 01 00 04

 

In ISY

14 : 0F88 : E2 03 11.26.21 01 00 03   Lv Rm Ceiling Mains

21 : 0F50 : E2 04 0F.FD.95 01 00 04

22 : 0F48 : E2 04 10.03.96 01 00 04

25 : 0F30 : E2 04 10.04.F8 01 00 04

27 : 0F20 : E2 04 10.92.08 01 00 04

29 : 0F10 : E2 04 11.26.21 01 00 04

40 : 0EB8 : E2 04 14.CD.BA 01 00 04

42 : 0EA8 : E2 04 16.A0.2B 01 00 04

48 : 0E78 : E2 04 25.7D.08 01 00 04

54 : 0E48 : E2 04 29.46.C0 01 00 04

 

NOTE:  9 mismatches are in the first byte, 0xEA vs 0xE2 (2 SmartHops vs 0) .  10th mismatch is 0xFA vs 0xE2 (3 SmartHops vs 0). 

 

Pressed ALL OFF button twice and ran Show Dev Links again on same KPL

10 mismatches again

2 mismatches changed

One New Mismatch

One previous Mismatch went away

 

[Record mismatch] 0F20 : F2 04 10.92.08 01 00 04

[Record mismatch] 0EB8 : EA 04 14.CD.BA 01 00 04

[identical] 0E78 : E2 04 25.7D.08 01 00 04  This was a mismatch before

New Mismatch:  [Record mismatch] 0E68 : EA 04 28.91.99 01 00 04

 

Further, I ran Show Dev Links on Lv Rm KPL2. 

Two mismatches were noted.  Both mismatches were in the first byte, 0xEA vs 0xE2. 

I turned ON all devices in the scene, then pressed the ALL OFF button on this KPL.

Ran Show Device Links, then Compare, 100% Match. 

 

Conclusion

 

The SmartHop 2 bit field is updated up and down based on the experience for a particular scene.  I was not quite expecting that the SmartHop would be ratcheted down, but that appears to be what is happening.

 

Does this make sense and/or is it consistent with your understanding? 

 

Justin

 

 

 

[LeeG]

I was not sure about the ratchet down but it does follow the functional statement about changing on each Cleanup ACK

 

Messages from KPL button press

 

Group Broadcast - no responder response

Group Clean Direct

 

From responder

 

ACK for Group Cleanup Direct - updates the Smarthop count up or down

 

The changing of the first byte has been known for a long time (since I2CS became available) but what it meant was not explained by SmartLabs until they released the Developer Notes recently.  That was considered Confidential information, released only to users who subscribed to that Confidential information which they were prohibited from sharing with us normal folks.

 

It suggests the responder device that started at E2, went to EA and then FA has some variation in what it takes to receive the Group Cleanup Direct.  Could be something on that circuit that is producing noise or reducing the Insteon signal level.   

[justin.cool]

LeeG,

 

Thanks for the response. It all becomes much clearer......until I start in on the next Insteon noise issue mystery! 

[Scyto]

Are your 2334-222 reliable? I have had a nightmare of a time programming my 2334-232 where when writing multiple scenes involving each of the buttons as being a controller for one or more scenes and a responder to multiple scenes I seem to often get write errors and odd and strange behavior like the ISY insisting an ABCD button was lit when it wasn't....

 

I am convinced the v.43 key pad dimmers are just odd....

[Jimbo.Automates]

Mine are very reliable once they are programmed. But I have had them exhibit bizarre behavior while setting them up a couple times which required a factory reset and restore device. This was likely caused by bad communication at the time I set them up which I have since resolved with some filterlincs.

 

Sent from my Nexus 7 using Tapatalk

[justin.cool]

I have the same experience as Jimbo.  Sometimes when setting them up I got some screwy results......but after doing the factory reset, etc etc they seemed to level out and be reliable.....EXCEPT when I get power drop outs...ie whole neigborhood loses power.  Which happens often....

 

When I get one of those, I can almost guarantee that I will have to go around the house and look for switchlinc's and KPLs that are flaky.....and do one of two things:

 

1.  Pull out the SET tab for 10 seconds and push it back in.

 

OR

 

2.  Factory RESET and then RESTORE DEVICE. 

 

Then things are OK until the next round of drop outs.

 

Justin

[Scyto]

Jimbo, on 08 Feb 2015 - 07:53 AM, said:

Mine are very reliable once they are programmed. But I have had them exhibit bizarre behavior while setting them up a couple times which required a factory reset and restore device. This was likely caused by bad communication at the time I set them up which I have since resolved with some filterlincs.

 

Sent from my Nexus 7 using Tapatalk

 

Yes yours and Justin's experiences match mine entirely, I have had no issues like this with any other devices.

I wonder if it is the devices that are weird, the way the PLM addresses them or the way the ISY chooses to program them...

[justin.cool]

Scyto

 

Not to sound patronizing to Univ-Dev, but in my experience since 2008, with 110+ devices, and the ISY-99 and now 994Pro, and hundreds of hours trouble shooting and installing, it is my humble opinion that the likelihood of it being an ISY related problem is relatively low. 

 

Justin

[Michel Kohanim]

Hello guys,

 

If you do not use Adjust Scenes in any ISY programs, then it would be rather impossible for ISY to automatically update link tables.

 

With kind regards,

Michel