Jump to content

Link record question


Techman

Recommended Posts

Hi Techman,

 

I do not quite remember either. But, whatever it is, it's NOT supposed to be there in your case and cannot be ignored.

 

With kind regards,

Michel

 

Well that's a conundrum.

Link to comment

Well that's a conundrum.

 

the conundrum just got a bit smaller, but hasn't gone away

 

I found this post from 2015   http://forum.universal-devices.com/topic/15336-device-links-table-corrupteds/

 

I just found an old version of the Developers guide. At the time the guide was printed the EA link wasn't being used. Seems it was reserved for I2CS.

Anyone have a current version of the guide?

Link to comment

What is an "EA" link record.

 

They frequently show up during a link record diagnostic / compare.

 

My recollection is that they can be ignored, but I still don't know what they represent or what creates them.

 

 

Hello Techman,

 

It looks like you found the correct post from Lee G.  As he documented I2CS controllers are capable of changing the cleanup hop count to "adapt" to their installed environment.  The "EA" link record is the result of a I2CS device increasing the default cleanup hop count to 1 hop.  Since the hardware device is modifying its cleanup count locally, the ISY should NOT consider this a record mismatch.

 

I had missed this post originally an am learning along with you.

 

To verify, I went through a series of tests with a "new" KPL.  The KPL was setup to "turn off" my 1st floor scene (~ 30 devices) using a non-toggle button.  As programmed by the ISY there were zero mismatches.  By varying the location of the KPL (wired to a cord) I could observe how it modified the cleanup hop counts for various scene members.  The KPL both increased and decreased the hop count depending on its location.

 

1) As programmed by the ISY - no mismatches

2) Location 1: 10 mismatches

3) Location 2: 11 mismatches

4) Location 3: 12 mismatches

post-135-0-44179100-1500752757_thumb.png

post-135-0-21792000-1500752853_thumb.png

post-135-0-23838200-1500816527_thumb.png

Link to comment

Hello Techman,

 

It looks like you found the correct post from Lee G.  As he documented I2CS controllers are capable of changing the cleanup hop count to "adapt" to their installed environment.  The "ES" link record is the result of a I2CS device increasing the default cleanup hop count to 1 hop.  Since the hardware device is modifying its cleanup count locally, the ISY should NOT consider this a record mismatch.

 

I had missed this post originally an am learning along with you.

 

To verify, I went through a series of tests with a "new" KPL.  The KPL was setup to "turn off" my 1st floor scene (~ 30 devices) using a non-toggle button.  As programmed by the ISY there were zero mismatches.  By varying the location of the KPL (wired to a cord) I could observe how it modified the cleanup hop counts for various scene members.  The KPL both increased and decreased the hop count depending on its location.

 

1) As programmed by the ISY - no mismatches

2) Location 1: 10 mismatches

3) Location 2: 11 mismatches

4) Location 3: 12 mismatches

 

IndyMike,

 

Thanks for the follow up. The developers guide I have is dated 2009 and doesn't include IC2S commands and shows the EA link as reserved.

 

Michel,

 

If you agree with this assessment could the EA link records be configured to not show in the diagnostics?

 

Techman

Link to comment

IndyMike,

 

Thanks for the follow up. The developers guide I have is dated 2009 and doesn't include IC2S commands and shows the EA link as reserved.

 

Michel,

 

If you agree with this assessment could the EA link records be configured to not show in the diagnostics?

 

Techman

Techman,

 

I also have the 2009 developers guide.  No help there.

 

The best information that I've seen on the subject is Lee G's post that you referenced above.

 

Just to be clear, it isn't just the "EA" record that will show as a record mismatch.  Since the hop count can increment from 0 to 3, you have three values that can create a mismatch.  Better to simply mask the bits out of the comparison

 

0 Hop: E2

1 Hop: EA

2 Hop: F2

3 Hop: FA

 

By the way, thank you for bringing this up.  I don't have many I2CS devices and had been restoring them (incorrectly) when I noticed these mismatches.  I feel a lot better now that I understand that the devices are modifying themselves.

Link to comment

Found by a search. Not too sure if this will help.

It has some information on what they call "Smart Hops"

http://cache.insteon.com/developer/i2CSdev-022012-en.pdf

 

Thank you.  The big problem is that Smarlabs is constantly updating their firmware and doesn't provide release notes.

What makes sense today may not be the case tomorrow. Maybe the new owners will be a little more sympatric to our frustrations.

Link to comment

Archived

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


×
×
  • Create New...