New Insteon PLM modem integration option via MQTT

Ok, so I have run into another problem. I set up a FanLinc and a 6button Keypadlinc. It seems like the scene isn’t being triggered when the dimmer is turned on/off. I set it up based on the documentation, and the lights on the keypad change, but the associated scene never gets called, so the fanlinc doesn’t respond.

Here is my KeypadLinc;

keypad_linc:
  
    
    btn_state_topic: 'insteon/{{address}}/state/{{button}}'
    btn_state_payload: '{{on_str.upper()}}'

   
    dimmer_state_topic: 'insteon/{{address}}/state/1'
    dimmer_state_payload: >
       { "state" : "{{on_str.upper()}}", "brightness" : {{level_255}} }

   
    btn_on_off_topic: 'insteon/{{address}}/set/{{button}}'
    btn_on_off_payload: '{ "cmd" : "{{value.lower()}}" }'

    
    dimmer_level_topic: 'insteon/{{address}}/set/1'
   
    dimmer_level_payload: >
       { "cmd" : "{{json.state.lower()}}",
         "level" : {% if json.brightness is defined %}
                      {{json.brightness}}
                   {% else %}
                      255
                   {% endif %} }

    btn_scene_topic: 'insteon/{{address}}/scene/{{button}}'
    btn_scene_payload: '{ "cmd" : "{{value.lower()}}" }'

And from my config file:

    - platform: mqtt
    schema: json
    name: "MB_KeypadLincDimmer"
    state_topic: "insteon/39.46.f1/state/1"
    command_topic: "insteon/39.46.f1/set/1"
    brightness: true

And the output when I click that light:

2019-06-25 22:02:02 INFO KeypadLinc: KeypadLinc message insteon/39.46.f1/set/1 b’{“state”: “ON”}’
2019-06-25 22:02:02 INFO KeypadLinc: KeypadLinc message insteon/39.46.f1/set/1 b’{“state”: “ON”}’
2019-06-25 22:02:02 DEBUG MsgTemplate: Input template render: ‘{ “cmd” : “on”,
“level” :
255
}’
2019-06-25 22:02:02 INFO KeypadLinc: KeypadLinc input command: {‘cmd’: ‘on’, ‘level’: 255}
2019-06-25 22:02:02 INFO KeypadLinc: KeypadLinc 39.46.f1 cmd: on 255
2019-06-25 22:02:02 DEBUG MsgHistory: Average hops 0.0, using 0
2019-06-25 22:02:02 INFO Protocol: Write message to modem: Std: 39.46.f1, Type.DIRECT, 11 ff
2019-06-25 22:02:02 DEBUG Protocol: Write bytes to modem: b’\x02b9F\xf1\x00\x11\xff’
2019-06-25 22:02:02 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2019-06-25 22:02:02 INFO Protocol: Read 0x62: Std: 39.46.f1, Type.DIRECT, 11 ff ack: True
2019-06-25 22:02:02 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
2019-06-25 22:02:02 DEBUG StandardCmd: 39.46.f1 got msg ACK
2019-06-25 22:02:02 INFO Protocol: Read 0x50: Std: 39.46.f1->48.ef.3f Type.DIRECT_ACK cmd: 11 ff
2019-06-25 22:02:02 DEBUG Protocol: Setting next write time: 1561525322.561842
2019-06-25 22:02:02 DEBUG MsgHistory: Received 0 hops, total 0 for 11 entries
2019-06-25 22:02:02 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
2019-06-25 22:02:02 DEBUG KeypadLinc: KeypadLinc 39.46.f1 ACK: Std: 39.46.f1->48.ef.3f Type.DIRECT_ACK cmd: 11 ff
2019-06-25 22:02:02 INFO KeypadLinc: Setting device 39.46.f1 (mbkeypadlinc) grp=1 on=255 normal
2019-06-25 22:02:02 INFO KeypadLinc: MQTT received button press 39.46.f1 (mbkeypadlinc) = btn 1 at 255 normal
2019-06-25 22:02:02 DEBUG Mqtt: MQTT publish insteon/39.46.f1/state/1 { “state” : “ON”, “brightness” : 255 } qos=1 ret=1
2019-06-25 22:02:02 DEBUG Protocol: Write handler finished
2019-06-25 22:02:02 DEBUG Mqtt: MQTT writing

Any help is much appreciated.

That’s not how insteon works - calling “set” on a button doesn’t trigger the scene - it just turns the button on. Physically pressing the button the device is a scene trigger. If you want to duplicate that affect from HASS, change the command topic to be /scene/. For dimmers, I’m not sure how to control the dimmer level in that case because I don’t think I ever thought of trying to change the dimmer level as a way to trigger a scene. I’ve only ever seen something like linking a fan to one of the other (non-dimming) buttons. I’d need to do some experimenting with sending a brightness level command along with a scene trigger as that isn’t supported right now.

Thank you, that makes sense.

So I have a fanlinc controller hooked up to a keypadlinc 6 button. I have the fanlinc light as a responder in a scene controlled by the on/off button of the keypadlinc, and I am trying to control that. Changing the command topic to /scene/ I get the following error:

2019-06-27 14:44:00 DEBUG KeypadLinc: KeypadLinc scene 1 message insteon/39.46.f1/scene/1 b'{"state": "ON"}'
2019-06-27 14:44:00 DEBUG MsgTemplate: Input template render: '{ "cmd" : "{"state": "on"}" }'
2019-06-27 14:44:00 ERROR MsgTemplate: Invalid JSON message { "cmd" : "{"state": "on"}" } from template { "cmd" : "{{value.lower()}}" }
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/mqtt/MsgTemplate.py", line 177, in to_json
    return json.loads(value)
  File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.6/json/decoder.py", line 355, in raw_decode
    obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 14 (char 13)

Am I missing something here? Is there a better way to accomplish this?

Again, this module is amazing, and I really appreciate your help.

I’m not at a computer so I can’t really make and example. Look at your template, it’s expecting just an on or off but your HA config is sending a json message. So adjust the HA or already the instructions template so they match.

Ok, will do. One last thing… when trying to delete a device as a controller of another device:

{ "cmd" : "db_del_ctrl_of", "addr" : 00.00.00, "group" : 248, "two_way" : true, "refresh" : true }

I am getting this error:

2019-06-27 15:18:02 ERROR Mqtt: Error decoding command payload: b'{ "cmd" : "db_del_ctrl_of", "addr" : 00.00.00, "group" : 248, "two_way" : true, "refresh" : true }'
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/mqtt/Mqtt.py", line 206, in handle_cmd
    data = json.loads(message.payload.decode("utf-8"))
  File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.6/json/decoder.py", line 355, in raw_decode
    obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 43 (char 42)

The address isn’t valid json. Needs to be a string. I strongly recommend you use the command line script to send commands. It will work check the args and format then correctly.

Awesome. Thanks again!

ok all in need of some direction. I am currently running the larizzo docker on an Unraid box with plenty of power and memory talking to a HASSio install on a Ubuntu server VM. The MQTT broker is on another docker and is working fine with other tasmota devices connected to HA. I did a dum dum and upgraded the docker and everything went south. I tried to figure it out with no success, so I tried starting all over and that didn’t work either. I am sure that it is something that I am missing so here is the first part of the new insteon-mqtt.yaml file (only started with two devices and the modem)

type or paste code here#==========================================================================
#
# Insteon <-> MQTT bridge configuration file.
#
# NOTE: the loader supports using a !include tag to load other as a
# item entry so you can do things like this:
#
# insteon:
#    devices: !include devices.yaml
#
#==========================================================================

#==========================================================================
#
# Optional logging configuration (can also be set via the command line)
#
#==========================================================================
logging:
  # 10=DEBUG, 20=INFO, 30=WARNING, 40=ERROR
  level: 10

  # Print messages to the screen.
  #screen: False

  # Print messages to a file.
  #file: /var/log/insteon_mqtt.log

#==========================================================================
#
# Insteon configuration
#
#==========================================================================
insteon:
  # Serial device:
  # USB PLM modem
  port: '/dev/ttyUSB0'
  #baudrate: 19200

  # Network socket:
  # Insteon HUB PLM network
  #port: 'socket://192.168.1.5:9761'

  # PLM modem Insteon hex address
  address: 4c.16.49

  # Device database file storage location.
  #storage: '/var/lib/insteon-mqtt'
  storage: 'data'

  # Automatically refresh device states and databases (if needed) at
  # startup.  This may be slow depending on the number of devices.
  startup_refresh: False

  #------------------------------------------------------------------------
  # Devices require the Insteon hex address and an optional name. Note
  # that MQTT address topics are always the lower case hex address or
  # the input name depending on how they are configured below.
  devices:
    # On/off switch devices (outlets, wall switches, appliance modules, etc).
    switch:
#      - 3a.29.84: 'xmas tree'
#      - 26.48.ff: 'xmas stairs'
#      - 37.2d.20: 'xmas deck'

    # Dimming devices (outlets, wall switches, lamp modules, etc).
    dimmer:
      - 0d.77.2c: 'landing'
      - 14.37.2b: 'table_lamp'
#      - 3a.29.84: 'lamp2'
#      - 48.3d.46
#      - 48.b0.ad: 'dim1'

    # Battery powered sensors (door, hidden door, window).
    battery_sensor:
#      - 94.a9.12

    # Battery powered motion sensors.
    motion:
#      - 21.d6.d9: 'door'

    # Battery powered mini remotes.
    mini_remote4:

    mini_remote8:
#      - 3f.07.d4: 'remote1'

    # Smoke bridge module.
    smoke_bridge:
#      - 44.a3.79: 'smoke alarm'

    # FanLinc fan controller (dimmer+fan).
    #fan_linc:
    #  - 9a.a1.b3

    # KeypadLinc dimmers (dimmer+scene controller).
    keypad_linc:
#      - 46.7b.bc: 'porch'

    # KeypadLinc switches (on/off+scene controller).
    keypad_linc_sw:
#      - 3c.42.9b: 'kp2'

    # Leak sensors.
    #leak:
    #  - 21.d6.d9: 'bathroom'

    # IOLinc relay controllers
    io_linc:
#      - 45.33.d4: 'garage'

    # On/off ouetlets
    #outlet:
    #  - aa.bb.cc: 'outlet'

    # Thermostatus
    thermostat:
    #  - aa.bb.cc: 'downstairs'

  #------------------------------------------------------------------------
  # FUTURE: Insteon scene definitions.
  #scenes:
  #  - scene_01:


#==========================================================================
#
# MQTT configuration
#
#==========================================================================
mqtt:
  broker: 192.168.0.247
  port: 1883
  # Optional broker login data.
  #username:
  #password:

  # Keep alive time in seconds.  This should be smaller than the
  # server setting (which is usually ~60 seconds) to insure that
  # connections aren't dropped.
  keep_alive: 30

  # Outbound messages configuration.  Retain should generally be 1
  # so that the current state is available when someone subscribes.
  qos: 1
  retain: 1

 

and each time I issue a command the handler retries three times and fails. I am sure its something I am missing. Its been working fine since the early versions. Here is a brief section of the log

type or paste code here

2019-07-04 22:24:22 INFO Mqtt: MQTT message insteon/command/0d.77.2c b'{ "cmd" : "off" }'
2019-07-04 22:24:22 UI Mqtt: Commanding dimmer device 0d.77.2c (landing) cmd=off
2019-07-04 22:24:22 INFO Dimmer: Dimmer 0d.77.2c cmd: off
2019-07-04 22:24:22 INFO Protocol: Write message to modem: Std: 0d.77.2c, Type.DIRECT, 13 00
2019-07-04 22:24:22 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x0f\x13\x00'
2019-07-04 22:24:22 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2019-07-04 22:24:28 WARNING Base: Handler timed out 1 of 3 sent: Std: 0d.77.2c, Type.DIRECT, 13 00
2019-07-04 22:24:28 DEBUG Base: Increasing max_hops to 3
2019-07-04 22:24:28 INFO Protocol: Write message to modem: Std: 0d.77.2c, Type.DIRECT, 13 00
2019-07-04 22:24:28 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x0f\x13\x00'
2019-07-04 22:24:28 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2019-07-04 22:24:34 WARNING Base: Handler timed out 2 of 3 sent: Std: 0d.77.2c, Type.DIRECT, 13 00
2019-07-04 22:24:34 DEBUG Base: Increasing max_hops to 3
2019-07-04 22:24:34 INFO Protocol: Write message to modem: Std: 0d.77.2c, Type.DIRECT, 13 00
2019-07-04 22:24:34 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x0f\x13\x00'
2019-07-04 22:24:34 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2019-07-04 22:24:40 WARNING Base: Handler timed out 3 of 3 sent: Std: 0d.77.2c, Type.DIRECT, 13 00
2019-07-04 22:24:40 DEBUG Base: Increasing max_hops to 3
2019-07-04 22:24:40 INFO Protocol: Write message to modem: Std: 0d.77.2c, Type.DIRECT, 13 00
2019-07-04 22:24:40 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x0f\x13\x00'
2019-07-04 22:24:40 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2019-07-04 22:24:46 WARNING Base: Handler timed out - no more retries (3 sent)
2019-07-04 22:24:46 ERROR Mqtt: Command timed out'

and a few mins later tried this:

2019-07-04 22:26:05 INFO Mqtt: MQTT message insteon/command/0f.e0.a5 b'{ "cmd" : "linking" }'
2019-07-04 22:26:05 UI Mqtt: Commanding Modem device 0f.e0.a5 (modem) cmd=linking
2019-07-04 22:26:05 INFO Protocol: Write message to modem: Modem linking: grp: 1 Cmd.EITHER
2019-07-04 22:26:05 DEBUG Protocol: Write bytes to modem: b'\x02d\x03\x01'
2019-07-04 22:26:05 DEBUG Serial: Wrote 4 bytes to serial /dev/ttyUSB0
2019-07-04 22:26:11 WARNING Base: Handler timed out - no more retries (0 sent)
2019-07-04 22:26:11 ERROR Mqtt: Command timed out

If there is something that I didn’t post and might be needed just let me know.

ThanX
Michael

Are you sure your Insteon modem is on /dev/ttyUSB0?

Oddly enough I was having the same issue today… When I looked at my Insteon Modem and the light on the side was off. I had to unplug it and plug it back it and everything is back to normal.

I am sure it is on the correct port it seems that I can talk to the modem with insteon-mqtt …almost. Originally I thought it might be bad modem so I ordered a new one but it did the same thing. here is a recent snip-it from a linking failure and a print_db success or at least an apparent success:

2019-07-05 18:34:18 INFO Mqtt: MQTT message insteon/command/0d.77.2c b'{ "cmd" : "linking" }'
2019-07-05 18:34:18 UI Mqtt: Commanding dimmer device 0d.77.2c (landing) cmd=linking
2019-07-05 18:34:18 INFO Base: Device 0d.77.2c (landing) link mode grp 1
2019-07-05 18:34:18 INFO Protocol: Write message to modem: Ext: 0d.77.2c, Type.DIRECT ext, 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-07-05 18:34:18 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x1f\t\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf6'
2019-07-05 18:34:18 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
2019-07-05 18:34:24 WARNING Base: Handler timed out 1 of 3 sent: Ext: 0d.77.2c, Type.DIRECT ext, 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-07-05 18:34:24 DEBUG Base: Increasing max_hops to 3
2019-07-05 18:34:24 INFO Protocol: Write message to modem: Ext: 0d.77.2c, Type.DIRECT ext, 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-07-05 18:34:24 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x1f\t\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf6'
2019-07-05 18:34:24 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
2019-07-05 18:34:30 WARNING Base: Handler timed out 2 of 3 sent: Ext: 0d.77.2c, Type.DIRECT ext, 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-07-05 18:34:30 DEBUG Base: Increasing max_hops to 3
2019-07-05 18:34:30 INFO Protocol: Write message to modem: Ext: 0d.77.2c, Type.DIRECT ext, 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-07-05 18:34:30 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x1f\t\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf6'
2019-07-05 18:34:30 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
2019-07-05 18:34:36 WARNING Base: Handler timed out 3 of 3 sent: Ext: 0d.77.2c, Type.DIRECT ext, 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-07-05 18:34:36 DEBUG Base: Increasing max_hops to 3
2019-07-05 18:34:36 INFO Protocol: Write message to modem: Ext: 0d.77.2c, Type.DIRECT ext, 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-07-05 18:34:36 DEBUG Protocol: Write bytes to modem: b'\x02b\rw,\x1f\t\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf6'
2019-07-05 18:34:36 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
2019-07-05 18:34:42 WARNING Base: Handler timed out - no more retries (3 sent)
2019-07-05 18:34:42 ERROR Mqtt: Command timed out
2019-07-05 18:35:11 INFO Mqtt: MQTT message insteon/command/0f.e0.a5 b'{ "cmd" : "print_db" }'
2019-07-05 18:35:11 UI Mqtt: Commanding Modem device 0f.e0.a5 (modem) cmd=print_db
2019-07-05 18:35:11 UI Modem: 0f.e0.a5 modem database
2019-07-05 18:35:11 UI Modem: ModemDb:
GroupMap

2019-07-05 18:35:11 UI Mqtt: Complete

One seems not to work and the other seems to work but there appears to be nothing in the modem db. that’s why I was doing the linking. Also tried to do them manually with no success. Get all the happy signs, flashing light and appropriate beeps but no success. Just thinking, is there an issue with older devices? I am on the git master since that’s the one used by Shawn’s docker.
Going to try to spin up an instance of insteon-terminal and perhaps it can shed some light on things.

Michael

Were you able to solve this? Stuck in the same step.

Fixed it! still have to do some more testing to make sure that it all still works. You guys got me thinking, of course I have assigned the correct port, but is that the one that the system sees. NOT! to find out I did:

dmesg | grep tty

By looking at the list in time, this told me that there was another device that the system put on the /dev/ttyUSB0 for some reason. Once I got that fixed by removing the offending device (ESP8266) from that USB port it fixed it self and when I plugged it back it got the open port /dev/ttyUSB1 and left my /dev/ttyUSB0 free for the insteon modem. Not really sure when I was monkeying around with the ESP8266 devices but, oh well, lesson learned. I will investigate on a way to reduce the chance of this happening again for my system. It does however seem to be system specific. Unraid running a docker of insteon-mqtt. Perhaps just running it in a VM will solve it, will check it out. Again to all thanks for the queries it made me think a bit,

Michael

The following article may be helpful to you, to allow you to use persistent naming for your USB serial devices: http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/ . I myself have a Z-Wave modem on my system as well, and it’s a matter of chance which one gets to be ttyUSB0 at each boot.

One of my fanlincs has died and I will be replacing it with a new one. The current one is only linked with a single six-button keypad. What is the best/proper way to do this replacement? Should I “db_del_ctrl_of” the fanlinc from the keypad, then “join” and “pair” the new one prior to “db_add_ctrl_of”?

The device databases are currently:

PLM: 49.f9.87
broken fanlinc: 3f.85.1f
keypad: 41.e6.a0

broken fanlinc
-----------------------------------------
3f.85.1f (office fanlinc) device database
DeviceDb: (delta 0)
  0fc7: 49.f9.07 grp: 254 type: RESP data: 0x00 0x1c 0x00
  0fcf: 41.e6.a0 grp:   7 type: RESP data: 0x00 0x1c 0x01
  0fd7: 41.e6.a0 grp:   6 type: RESP data: 0x00 0x1f 0x02
  0fdf: 41.e6.a0 grp:   5 type: RESP data: 0x01 0x1f 0x02
  0fe7: 41.e6.a0 grp:   4 type: RESP data: 0x80 0x1f 0x02
  0fef: 41.e6.a0 grp:   3 type: RESP data: 0xff 0x1f 0x02
  0ff7: 41.e6.a0 grp:   1 type: RESP data: 0xff 0x1c 0x01
Unused:
  0fff: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED)
Last:
  0fbf: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
6-button keypad
--------------------------------------------
41.e6.a0 (office keypadlinc) device database
DeviceDb: (delta 0)
  0f87: 49.f9.07 grp: 254 type: RESP data: 0x00 0x1c 0x00
  0f8f: 3f.85.1f grp:   7 type: CTRL data: 0x03 0x1f 0x07
  0f97: 3f.85.1f grp:   6 type: CTRL data: 0x03 0x1f 0x06
  0f9f: 3f.85.1f grp:   5 type: CTRL data: 0x03 0x1f 0x05
  0fa7: 3f.85.1f grp:   4 type: CTRL data: 0x03 0x1f 0x04
  0faf: 3f.85.1f grp:   3 type: CTRL data: 0x03 0x1f 0x03
  0fb7: 3f.85.1f grp:   1 type: CTRL data: 0x03 0x1f 0x01
  0fc7: 49.f9.07 grp:   8 type: CTRL data: 0x03 0x1f 0x08
  0fcf: 49.f9.07 grp:   7 type: CTRL data: 0x03 0x1f 0x07
  0fd7: 49.f9.07 grp:   6 type: CTRL data: 0x03 0x1f 0x06
  0fe7: 49.f9.07 grp:   4 type: CTRL data: 0x03 0x1f 0x04
  0fef: 49.f9.07 grp:   3 type: CTRL data: 0x03 0x1f 0x03
  0ff7: 49.f9.07 grp:   2 type: CTRL data: 0x03 0x1f 0x02
  0fff: 49.f9.07 grp:   1 type: CTRL data: 0x03 0x1f 0x01
Unused:
  0fbf: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED)
  0fdf: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED)
Last:
  0f7f: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
  1 -> ['3f.85.1f', '49.f9.07']
  2 -> ['49.f9.07']
  3 -> ['49.f9.07', '3f.85.1f']
  4 -> ['49.f9.07', '3f.85.1f']
  5 -> ['3f.85.1f']
  6 -> ['3f.85.1f', '49.f9.07']
  7 -> ['49.f9.07', '3f.85.1f']
  8 -> ['49.f9.07']

I was able to successfully join and pair the new fanlinc (47.98.38). I’m now trying to remove the old one from the keypad’s database, however have been unable to conjure the correct incantation.

I trie from both the CLI and through HA’s MQTT topic, but neither worked. In the latter case, I published the following:
topic: /insteon/command/41.e6.a0
payload: { "cmd" : "db_del_ctrl_of", "addr" : 3f.85.1f, "group" : 1, "two_way" : false, "refresh" : true }

Can someone point me to my error?

I don’t know so much about MQTT usage in this case, but I have used the “CLI” to remove database entries after my devices die. If you can use the insteon-mqtt CLI, you should be able to do something like the following (there may be an easier way, but this should work):

  1. insteon-mqtt config.yaml refresh <device with stale db entries>
  2. insteon-mqtt config.yaml db-delete <device with stale db entries> resp 3f.85.1f <group num>
    Repeat #2 for each group number using resp for 3f.85.1f
    Repeat #2 again but but this time use ctrl instead of resp.
1 Like

Thank you. I’ll try that tonight. I prefer using the CLI for these sorts of commands.

Slowly getting there, trying to understand how Insteon device databases work.

One other question… do I also need to delete the failed device from the PLM?

Yes, its a good practice to delete entries from failed devices, particularly for controllers that control the failed device (which would include the PLM).