In-LineLink Relay is not responding to PLM scene

[mstovenour]

The changes for Issue #262 partially fixed the In-LineLink Relay responder issues but there was a small defect when looking at the engine version. The result is that responder links to a PLM scene continue to have data3=00 for the In-LineLinc Relay (probably other devices as well).

[peloy]

Thanks a lot for catching this, Michael. Is a sync links/delete orphan links required after applying this fix?

Cheers,

Eloy Paris.-

[mstovenour]

I'm working on a 2nd fix that will improve the update but you can force an update for now by:

1. Commenting out the affected SCENE_MEMBER entries in your .mht file
2. restart MH and run delete orphan links
3. Add SCENE_MEMBER entries back to your .mht file
4. restart MH and run sync all links

The current sync links or delete orphan links code doesn't catch this discrepancy. I'm looking at it now.

[krkeegan]

I don't know for sure (not looking at the code ATM), but I suspect the change is not being caught because MH currently does not distinguish internally between the data3 value of 00 or 01. In order to force the change to occur, you would need to reset the device and add the links again.

[peloy]

Easier said than done :-( -- this thing is "buried alive" above the
ceiling of my front porch so it's not easy to get to it (I need to
unmount a ceiling fan before I can get to it).

I'll give Michael's suggestion of deleting the SCENE_MEMBER entries +
running delete orphan links a try ;-)

I had not noticed that something was broken because I hadn't turned on
from MisterHouse the fan in the front porch that is controlled by this
InlineLinc in a while. But I just gave it a try and indeed it is not
working.

Cheers,

Eloy Paris.-

On 12/06/2013 09:31 PM, Kevin Robert Keegan wrote:

I don't know for sure (not looking at the code ATM), but I suspect the
change is not being caught because MH currently does not distinguish
internally between the data3 value of 00 or 01. In order to force the
change to occur, you would need to reset the device and add the links again.

—
Reply to this email directly or view it on GitHub
#327 (comment).

[mstovenour]

I've been looking at how to adapt sync_links() / delete_orphan_links(). I can add code to has_link() so that it considers more than the output from get_linkkey(). The new code would be similar to what was added already to add_link() and update_link(). But now I wonder.... would it be better to add data1(), data2(), and data3() functions to Insteon::BaseDevice that we could call to fill out those values? 1st it would put this code in one place vs. spreading it out in four or more places. 2nd it would allow us to override the BaseDevice functions in specific devices that inherit from BaseDevice.

I've been experimenting with manually created links; I also read about experiments you all performed with the keypad links. From my empirical testing the devices have significantly different behavior when manually linking. For instance my PLM's controller links have the responder's Device Category, Device Subcategory, and firmware version for D1-D3. Why? I don't know. Some of my devices use the most recent MH interpretation of d1=app retries(03), d3=controller's group; but d2 is some undetermined value (e.g. 1c). Some devices record local responder links with d3=00 while others use d3=01. ALL of my device are 2012 and later I2CS. The current MH behavior seems to work for the PLM controller links and for the I2CS devices (when using d3=01) even when the device would create d3=00 responder links manually. I don' t know that we need per device settings but it seems like a good probability that we will find more, device specific requirements in the future.

What do you all think?

[krkeegan]

I agree with the data1() - data3() concept, I had thought about that before as well. If you are willing to undertake it, I am in favor.

PLM Controller Links - Ahh devcat details, I could never figure out what all that garbage was. Nice find.

D2 On Device Controller Links - This is listed as a "smart hop" I have no idea what this means, but I think it is some way of setting the initial hop count. I seem to recall the insteon dox stating that this should be set to 00, but I can't recall if a device is able or does alter this value over time.

D3 - I agree, the values are bizarre. Eloy had an issue with a device that very strictly required D3=01, but other than his device, I have not encountered any other device that seems to care about this value.

[mstovenour]

For D3, I have the same issue as Eloy; I have two In-LineLinc Relays wired to the eaves of my house. I found the issue above when I tried to turn on my Christmas lights. It looks like only the In-LineLinc Relay has this behavior in my house.

[peloy]

The device I had this problem with is an InlineLinc relay as well. It's an i2CS device. From the testing I did back then, it doesn't look like any other devices (including other i2CS devices) exhibit this problem.

Cheers,

Eloy Paris.-

-------- Original message --------
From: Michael Stovenour notifications@github.com
Date: 12/09/2013 8:44 AM (GMT-05:00)
To: hollie/misterhouse misterhouse@noreply.github.com
Cc: Eloy Paris gh@chapus.net
Subject: Re: [misterhouse] In-LineLink Relay is not responding to PLM scene (#327)

For D3, I have the same issue as Eloy; I have two In-LineLinc Relays wired to the eaves of my house. I found the issue above when I tried to turn on my Christmas lights. It looks like only the In-LineLinc Relay has this behavior in my house.

—
Reply to this email directly or view it on GitHub.

[mstovenour]

I merged changes into master that should fix this issue and give us an easy way to have unique behaviors for each Insteon device type in the future. Hopefully all Insteon device types (thermostat, etc.) inherit from base device or this will dump errors for those devices. It would be good if someone could test with the following devices:
In-LineLinc Relay i1
SwitchLinc Relay i1
SwitchLinc Relay i2CS
Other non-lighting Insteon devices

[mstovenour]

Code has been modified to support switch linc relay type devices using responder link endpoint 01 vs. 00 (data3).

[krkeegan]

I tested this out on a Switchlinc (i1) and (i2cs) and it worked perfectly.

This was patched in #328