Add enter link mode command for all devices

[TD22057]

Standard command with cmd1=0x09, cmd2=GROUP will put device in all-link mode (same as touching set button). For some devices (leak sensor at least), 0x08 will cancel the mode.

[larizzo]

Oh this would be nice as I have two micro sensors that I can't get to without remove light fixture!

[TD22057]

Another option if 0x09 doesn't work is to send 0x25 0x01 which looks like it simulates pressing the set button once.

[TD22057]

Insteon dev guide is wrong - it shows 0x09 as as a standard message for doing this but that doesn't work for any device that I have. Found a forum post that says after 2012, it requires an extended command. This does work:

msg = message.OutExtended.direct( 0x09, GROUP, bytes([0x00]*14) )

which is the same as pushing the set button on the device. Found another forum post that says you can link a device not seen before by doing this:

• send message.OutAllLinkStart to modem w/ modem as controller
• send 0x09 extended message as above to device

This should link the new device to the modem. Then the device.pair() command can be sent to add the device->modem pairings. This could lead to a new command line command for adding a new device to the system I think would be:

• edit config file to add new device address to the right type and restart insteon-mqtt
• run insteon-mqtt new-device aa.bb.cc command which would run the above pairing to set the modem as a controller and the device as a responder (so the modem can send commands), then run device.pair() to configure any other links. Or maybe just replace the existing pair command with the above which should work even if the device is already linked to the modem.

[TD22057]

FYI - I've been working on getting this to work. This is pretty crucial to automatically pairing up devices. I've added a "linking" command to the command line tool (and mqtt cmd dictionary) which trips the devices set button for linking. It works fine, but sometimes the links don't actually work.

I was trying to get a new device set up by doing: 1) start modem linking (controller), 2) start device linking (responder), 3) call device pair command (to set the device->modem link and any other links for multi-button devices). That fails because the pair command gets a NAK. The link is there, but the device won't respond to the commands from the modem.

It turns out that the 3 byte data fields are important for some devices. I used 0,0,0 for the smoke bridge and it works perfectly. But, a dimmer fails completely. I've been hunting through the misterhouse code and found several explanations (though reading perl is giving me a headache).

hollie/misterhouse#262

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 tothe 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

hollie/misterhouse#327

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.

hollie/misterhouse#293

The Data3 value on control links is now properly set to the same value as the group value. (This will cause all old control links for buttons 2 and higher on devices to be deleted and resynced. Links on the PLM will not be touched as Data3 doesn't appear to have any ill effects if it is improperly set. All new controller links on the PLM will have the correct data3 value.) The default Data3 value for responder links is set to 01 for i2cs devices, but remains 00 for non i2cs devices for the root device.

I don't have a hard plan for these yet, here are the values from the devices I have (and have paired manually to the modem) and they seem to follow the issue 327 comment above - at least on the modem.

Motion sensor:
   modem  RESP: 0x01 0x0e 0x43
   device CTRL: 0x03 0x00 0x00

Switch:
   modem  RESP: 0x01 0x0e 0x43
   modem  CTRL: 0x02 0x37 x048
   device RESP: 0xff 0x1c 0x01
   device CTRL: 0x03 0x1c 0x01

Dimmer:
   modem  RESP: 0x00 0x00 0x00
   modem  CTRL: 0x01 0x0e 0x43
   device RESP: 0xff 0x1c 0x01
   device CTRL: 0x03 0x1c 0x01

Remote:
   modem  RESP: 0x00 0x00 0x00
   device CTRL: 0x03 0x00 0x00  (same for all groups)

Smoke bridge:
   modem  RESP: 0x01 0x0e 0x43 (grp 1 - others are 0x00 and work)
   modem  CTRL: 0x10 0x0a 0x43
   device RESP: 0xff 0x1c 0x00
   device CTRL: 0x00 0x00 0x01

IO Linc:
   modem  RESP: 0x00 0x00 0x00
   modem  CTRL: 0x07 0x00 0x41
   device RESP: 0x00 0x00 0x00
   device CTRL: 0x03 0x00 0x00

[TD22057]

This works now. There is new command 'linking' which works for the modem and devices to put them in linking mode. The message format is:

Topic: insteon/command/aa.bb.cc
Payload: { "cmd" : "linking", ["group" : group] }

I factory reset a lamp module and did this from the command line. This is basically the software procedure to add a new device without ever touch any of the devices.

[edit config.yaml to set 37.2d.35 as a switch and restart insteon-mqtt]

# Set the modem as the controller of the device (so we can send commands)
./insteon-mqtt linking config.yaml modem
./insteon-mqtt linking config.yaml 37.2d.35
[device beeps]

# Set the device as a controller to the modem (so we get group broadcasts)
./insteon-mqtt linking config.yaml 37.2d.35
./insteon-mqtt linking config.yaml modem
[device beeps]

# Get the device database so we know what was created, then build 
# any extra links the device needs to work.
./insteon-mqtt refresh config.yaml 37.2d.35
./insteon-mqtt pair config.yaml 37.2d.35

I don't know how to automate this step at this point but I'll think about that for another enhancement. I tried just linking the modem->device and then running db-add to make the reverse link by hand but that fails for unknown reasons.

I also updated the db-del-ctrl- and db-del-resp so that individual links on the modem can be removed. So now the devices and modem have the same api for database management. I added a link_data() method to return the "correct" link data for each device to use when building links. In theory this will avoid issues with links that are there but don't work. I haven't done extensive testing with this yet though.

I also updated all the mqtt inputs so that "nice" names from the config file can be used for all inputs (including the mqtt topic). "modem" will work to reference the modem.

[TD22057]

One more note for future doc regarding multi group linking. D3 on the responder must be the group on the local device. So the if I link a remote button 6 to a keypadlinc button 3, the following is created:

keypadlinc:
  0fd7: 3f.07.d4 grp:   6 type: RESP data: 0xff 0x1c 0x03
Remote:
  0f8f: 46.7b.bc grp:   6 type: CTRL data: 0x03 0x00 0x00

So link group is the controller group number (and the group number in the broadcast messages). D3 on the responder is the local group number to map that message to. So a broadcast group 6 gets mapped to local button 3 on the keypadlinc.

[krkeegan]

The Data1-3 fields on modem controller links that are paired manually with the modem are generally the DevCat, SubCat, and Firmware bytes of the responding device. But my experience is that having these wrong doesn't seem to cause any issues.