Insteon: ALDB Data3 is Incorrect for Controller Records

[krkeegan]

This was the initial bug report, closer inspection revealed that while a problem exists, this is not an accurate description of it. See #262 (comment) for a more accurate description of the problem

I am having a difficult time working through the logic and the code, but I think this is correct.

The current Hash Key structure for a controller in MH is:

Linked_Device_ID . This_Device's_Group . 01

For a long time that has been fine and dandy, but @pmatis may have found a glitch in this logic.

A single device or PLM Scene controlling multiple buttons on a single KPL. In this instance all of the ALDB Hash Keys would look like 112233A001. Which will mean only a single link will be added by MH and the rest will be seen as duplicates, even though there are multiple links, one to each button which is being controlled.

However, I haven't figured out if more than one controller link is actually needed. When a device is controlling a KPL data3 in the controlling devices ALDB equals the button number on the controlled device. However, when sending the All-Link command, I don't think data3 is ever used.

I suspect we just need to just look for one entry for all of these links and not try and create an ALDB entry for each one, but I don't really know what the purpose of data3 is then.

[krkeegan]

I manually linked the C button on a KPL two the C&D button on another KPL.

The Link on the controller looks like this:

27/09/2013 18:28:40  [Insteon::AllLinkDatabase] [0x0ED8] contlr(05) record to $s_st_lt_s1 (05), (d1:00, d2:1f, d3:05)

No other link was created on the controller.

The link on the responder looks like this:

27/09/2013 18:33:34  [Insteon::AllLinkDatabase] [0x0F98] rspndr(05) record to $f_kt_pad_lt_s0 (05): onlevel=on and ramp=none (d3:05)
27/09/2013 18:33:34  [Insteon::AllLinkDatabase] [0x0F38] rspndr(06) record to $f_kt_pad_lt_s0 (05): onlevel=on and ramp=none (d3:06)

Confusingly, I made the first link between both C buttons so data3 and group are both 05.

The controller also blinks as though it doesn't get confirmation, but that may just be my network issues.

So it looks like within Insteon only a single entry is made on the controller.

[pmatis]

Kevin,
You know a lot more about Insteon than I do, so don't take this as a
challenge. Sometimes a novice view can help get the master's head out of
the trenches to see it in a simpler light. Other times the novice simply
takes attention away from the task and shows his incredible ignorance.
I'm willing to take that risk so that I can learn and hopefully help
more in the future.

You have 18.28.40:05 that's controlling 18.33.34:05 and 18.33.34:06
(If I'm reading this right).

18.28.40:05
->18.33.34:05
->18.33.34:06

I believe this is accomplished with a broadcast that sends out the
target scene ID, and the responders have to be told ahead of time what
to do (if anything) when this scene is activated. If that's the case,
then this one scene, but two links in the ALDB - more if there are
reciprocal links, too. Given this, probably the only way to ensure a
link is only seen as a duplicate when it really is, is to expand the
hash key to include the linked decice group.

I think this has to be implemented on the scan AND sync. I'll beta
test for you...

So, did this help in any way, or did I only say something to show my
ignorance? LOL

Best regards,
Steve Switzer

[krkeegan]

There is no need to apologize. I learned everything I know in the last year and the only way I learned was doing the same thing you did.

I think we may be saying the same thing, but I can't quite be sure. So I will explain my current theory and see if we agree.

So when an Insteon device sends a scene command it sends a message with its device ID and the group number of the controller. This initial message is a broadcast. Then the controller sends individual messages to each linked responder. These individual messages again only contain the group id of the controller. To my knowledge the controller never sends any message that contains the button/group number of the responder. Likewise, I dont believe that any of the acknowledgements from the responder to the controller contain the responder's button/group id. As a result, the responder button/group id is useless to the controller, yet the data3 detail in the ALDB contains the responder's button/group. Why?

So the test above was a manual test to see how Insteon devices themselves handle this. It appears that similar to MH the controller only has a single entry. I would like to test this again with another device and it may be worthwhile to see how the HouseLinc software handles this. My goal is usually to make MH handle everything in the same manner that Insteon does, not just necessarily in a manner that works.

If everything checks out, we can simply look for a single entry on the controller for the appropriate group and then skip checking/adding any more.

Does that make sense?

[krkeegan]

Test from another device, again using one button on a KPL to control two different buttons on a single KPL responder:

28/09/2013 11:46:59  [Insteon::AllLinkDatabase] [0x0F30] contlr(06) record to $f_kt_pad_lt_s0 (06), (d1:fe, d2:1f, d3:06)

28/09/2013 11:45:43  [Insteon::AllLinkDatabase] [0x0ED0] rspndr(03) record to $s_st_lt_s1 (06): onlevel=off and ramp=none (d3:03)
28/09/2013 11:45:43  [Insteon::AllLinkDatabase] [0x0EC8] rspndr(04) record to $s_st_lt_s1 (06): onlevel=off and ramp=none (d3:04)

The button I liked on the controller was D or 6, but the linked buttons on the responder were A and B. Notice that data3 is set to 06. So it looks like maybe we have data3 on the control links wrong, instead of being the responder button how we currently have it, it should be the controller button.

[krkeegan]

Another test. For this test, I put a scene(A0) in manual linking mode and then manually linked a KPL button(D). The resulting controller link on the PLM was

[Insteon::ALDB_PLM] cntlr(a0) record to 09.9B.F4 (d1=01, d2=09, d3=2b)

This is in contrast to a MH created link that looks like:

[Insteon::ALDB_PLM] cntlr(a0) record to $f_kt_pad_lt_s0_b (d1=01, d2=00, d3=04)

Not sure where the data3 value comes from in the first one, but it clearly isn't how we do it.

[pmatis]

What happens if you force data3 on the controller to another number? Does the broadcast generated from that button use data3 as the target group? Maybe this field is to override the group, if desired...
Does the Insteon WhitePaper help at all?

[krkeegan]

The Insteon documents on all of this are pretty vague. Best I can synthesize together from everything I have read and seen, Data1-3 in an ALDB records are defined by Insteon as follows:

Responder Records
Data 1    Link-specific data (e.g. On-Level) 
Data 2    Link-specific data (e.g. Ramp Rates, Setpoints, etc.) 
Data 3    Link-specific data (listed by Insteon as "normally unused" 
                     but for multi-function items, we know that this is set to 
                     the linked "group" on the responding device)

Controller Records
Data 1    Number of retries (Normally set to 03, FF = no retries, 00 = Broadcast for cleanup)
Data 2    Listed as Ignored??  
Data 3    Listed as 00 for switchlinc type devices and 01-08 for KPL type devices

Best I can tell, when the Insteon code was added to MH, it looks like the original author believed that the Data3 of a controller link referred to the Responder device group and not the Controller device group.

I am about 99% confident that this was an incorrect interpretation:

• Manually created links assign the Controller's group number to data3 (rather persuasive evidence)
• None of the All Link messages are capable of transmitting this data to the responder, the messages just don't have the payload to do it.

Setting data3 on a controller to a random number seems to have no ill effects. Indeed, the PLM seems to pick random numbers for data3 when manually creating a link.

I will start a new branch in which MH sets data3 on controller links to the controller's group #. This will take some time as these functions are spread throughout MH.

[peloy]

Hi Kevin,

On 09/30/2013 04:02 PM, Kevin Robert Keegan wrote:

[...]

Best I can tell, when the Insteon code was added to MH, it looks like
the original author believed that the Data3 of a controller link
referred to the Responder device group and not the Controller device group.

I am about 99% confident that this was an incorrect interpretation:

• Manually created links assign the Controller's group number to data3
  (rather persuasive evidence)
• None of the All Link messages are capable of transmitting this data
  to the responder, the messages just don't have the payload to do it.

Setting data3 on a controller to a random number seems to have no ill
effects. Indeed, the PLM seems to pick random numbers for data3 when
manually creating a link.

I will start a new branch in which MH sets data3 on controller links to
the controller's group #. This will take some time as these functions
are spread throughout MH.

Is all this perhaps related to issue #176 in hollie/misterhouse?

I created that issue following the email thread "KeypadLinc button does
not control In-lineLinc; can't figure out why" -- if you recall, a
MH-created responder link on an InlineLinc failed to be controlled by a
KeypadLinc or by the PLM (PLM scene) because of the value of the data3
byte that MH was putting in the responder record. The results of my
tests are recorded in the Github issue, if anyone wants a refresher.

Cheers,

Eloy Paris.-

[krkeegan]

Agree, they sound bizarrely similar, but I do not think they are related. This issue is with the data3 value in a Controller record, while #176 is in a Responder record.

I actually made a test branch to see what would happen if I changed the default data3 value in a Responder link to 01 for I2CS devices. I haven't tested it extensively yet, but the code is at least ready in concept and should solve tha #176 problem:

https://github.com/krkeegan/misterhouse/tree/insteon_data3

[krkeegan]

This is becoming more complicated. To recap, currently MH sets data3 on controller records to the group of the responding device. But data3 should actually be set to the group of the controlling device.

A problem arises in the delete_orphans routine, in that routine when MH finds a controller record it checks to see if a responder record exists on the device. However, if we fix data3 on the controller records, we will no longer know what the group/button is supposed to be in data3 on the responding device and therefore we can't test to see if the link exists.

The solution is probably checking the mht file to look for the correct responder button/group, but I haven't fully thought through the ramifications of this. There are likely to be other issues like this.

On top of that, Delete_Orphans and Sync_Links are monstrously confusing routines. I have an inclination to do a massive rewrite of them, but I don't know if I really have a better solution.