FR: easier linking for KeyPadLinc devices

[rspier]

KeyPadLinc devices require setting the link group (and possibly the D3 data) when linking. It would be cool if there was a cleaner way of doing it than ic device edit and hoping not to totally mess things up.

I think there are some standards, where d1 is target brightness, d2 is ramp rate, and for keypads d3 is which button.

[abates]

Is this issue related to using the PLM to link a KeyPadLinc device to another device, or to link the PLM to a KeyPadLinc device?

[rspier]

Using the PLM to link a KeyPadLinc device to another device. The 8 (or 6) buttons make things slightly more complicated. My long-term goal is to be able to re-program my entire setup without HomeLinc, which was instrumental in making it happen. Right now if I have to replace a module, it'll be problematic to get everything back together.

[abates]

My approach in this package has been to implement device specific capabilities as a Device. There are currently switch and dimmer devices as well as base i1, i2 and i2cs devices.

I think the approach I would choose would be to create a KeyPadLinc type that has functions to create all-links for the specific buttons. This would then be called by a KeyPadLinc function in the command. Presumably, the KeyPadLinc device would be composed of a DimmableDevice.

Thoughts?

[rspier]

Your approach seems reasonable, and fits the current model. I'm a little concerned about the CLI having a billion slightly different commands, with the duplication that sometimes entails. It's too easy to use the wrong one. I might go with flags, although they add their own complexity. Right now only the device and plm commands support linking. It would be weird to add it to the dimmer or switch commands.

[abates]

Your point about bloating the CLI is completely valid and I agree.

Right now the CLI doesn't actually have any capability to write links directly to a device ALDB. The CLI can put a device into linking/unlinking mode (same as holding the set button) which allows for remote linking using the same method as physically pushing the buttons. This is how PLM linking/crosslinking works (device is put into linking mode, then plm is put into linking mode thus automatically adding all-link records in each device database).

I think the first step towards building ALDB entries directly is to create a utility function in linkdb.go that accepts the controller and responder devices as well as the expected d1, d2 and d3 values for each device. This function would simply write ALDB entries to the corresponding device databases.

We would also need to have some way to determine the default d1, d2 and d3 values depending on the device type. I have toyed with the idea of adding a function to the linkable interface that returns default values.

Finally, we need a clear/concise way to call these functions from the CLI. I want to keep the existing link/unlink functionality, because there are times when you want to emulate a set-button press from the command line.