New Insteon PLM modem integration option via MQTT

Tags: #<Tag:0x00007f7c5fedef30>

having re-introduced my repaired PLM to all other Insteon components, I’m now determined to make the keypadlinc buttons modify correctly when controlling the fanlinc, and also when the fanlinc is controlled by either Hass itself, or one of the wireless remotes.
I’m using a 6 button keypadlinc, where the button assignments look like:

1 on
3 4
5 6
1 off
Buttons 3-6 control the fan.
3 = low
4 = med
5 = off
6 = high

That part works. However, if I go from a state of off, where button 5 is lit, and I press button 3 to set the fan on low, button 5 is not extinguished. I understand that insteon-mqtt gives me the capability to use an automation to recognize that button 3 has been pressed, and then go back and turn out button 5’s light, but it seems like there should be a way for the KPL to do this on its own.
Beyond that, let’s say that while the fan is on low, and button 3 is lit, if I press button 3 again, which sets the fan to off, I would like to see that button 5 lights up, because however the fan is turned off, the KPL light should reflect the proper status.
Am I dreaming the impossible dream? Or can this only be done through an endless series of cleanups via automation?
I think I found where this was discussed before in the github issue list:

Odd issue on my new insteon-mqtt install. If I use the command line to do a refresh on a device, or a print db, etc. - pretty much anything I’ve tried- it always comes back with “Reply timed out”
However, if I have logging turned up to debug, and I tail -f /var/log/insteon_mqtt.log, I get tons of output:

2019-12-10 18:13:23 INFO Mqtt: MQTT message insteon/command/4a.98.6f b'{"cmd": "print_db", "session": "3069033633"}'
2019-12-10 18:13:23 UI Mqtt: Commanding keypad_linc device 4a.98.6f (master_br_kpl) cmd=print_db
2019-12-10 18:13:23 DEBUG Mqtt: MQTT publish insteon/command/4a.98.6f/session/3069033633 {"type": "MESSAGE", "data": "Commanding keypad_linc device 4a.98.6f (master_br_kpl) cmd=print_db"} qos=0 ret=False
2019-12-10 18:13:23 UI Base: 4a.98.6f (master_br_kpl) device database
2019-12-10 18:13:23 DEBUG Mqtt: MQTT publish insteon/command/4a.98.6f/session/3069033633 {"type": "MESSAGE", "data": "4a.98.6f (master_br_kpl) device database"} qos=0 ret=False
2019-12-10 18:13:23 UI Base: DeviceDb: (delta 2)
  0f47: 44.af.14 grp:   1 type: RESP data: 0xff 0x00 0x01
  0f4f: 44.af.14 grp:   2 type: RESP data: 0xfe 0x1c 0x01
  0f57: 49.23.d4 grp:   1 type: RESP data: 0x00 0x1c 0x01
  0f5f: 1a.78.24 grp:   8 type: RESP data: 0xff 0x00 0x08
  0f67: 1a.78.24 grp:   7 type: RESP data: 0xff 0x00 0x07
  0f6f: 1a.78.24 grp:   6 type: RESP data: 0xff 0x00 0x06
  0f77: 1a.78.24 grp:   5 type: RESP data: 0xff 0x00 0x05
  0f7f: 1a.78.24 grp:   4 type: RESP data: 0xff 0x00 0x04
  0f87: 1a.78.24 grp:   3 type: RESP data: 0xff 0x00 0x03
  0f8f: 1a.78.24 grp:   2 type: RESP data: 0xff 0x00 0x02
  0f97: 1a.78.24 grp:   8 type: CTRL data: 0x03 0x00 0x08
  0f9f: 1a.78.24 grp:   7 type: CTRL data: 0x03 0x00 0x07
  0fa7: 1a.78.24 grp:   6 type: CTRL data: 0x03 0x00 0x06
  0faf: 1a.78.24 grp:   5 type: CTRL data: 0x03 0x00 0x05
  0fb7: 1a.78.24 grp:   4 type: CTRL data: 0x03 0x00 0x04
  0fbf: 1a.78.24 grp:   3 type: CTRL data: 0x03 0x00 0x03
  0fc7: 1a.78.24 grp:   2 type: CTRL data: 0x03 0x00 0x02
  0fcf: 1a.78.24 grp:   1 type: CTRL data: 0x03 0x1c 0x01
  0fd7: 1a.78.24 grp:   1 type: RESP data: 0x00 0x1c 0x01
  0fdf: 49.23.d4 grp:   5 type: CTRL data: 0x03 0x1c 0x05
  0fe7: 49.23.d4 grp:   6 type: CTRL data: 0x03 0x1c 0x06
  0fef: 49.23.d4 grp:   4 type: CTRL data: 0x03 0x1c 0x04
  0ff7: 49.23.d4 grp:   3 type: CTRL data: 0x03 0x1c 0x03
  0fff: 49.23.d4 grp:   1 type: CTRL data: 0x03 0x1c 0x01
Unused:
Last:
  0f3f: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
  1 -> ['49.23.d4', '1a.78.24']
  3 -> ['49.23.d4', '1a.78.24']
  4 -> ['49.23.d4', '1a.78.24']
  6 -> ['49.23.d4', '1a.78.24']
  5 -> ['49.23.d4', '1a.78.24']
  2 -> ['1a.78.24']
  7 -> ['1a.78.24']
  8 -> ['1a.78.24']

I get the same log output if I send a mqtt message to print_db. However, using the command line is not only more concise, it doesn’t require turning up the logging first.
Any idea why this is happening the way it is, and what I can do to fix it?

Check your MQTT server. The command line output works by subscribing to a session topic which the server then publishes to (that’s why there is a session ID in the input command - so they can agree on the name of the topic). That’s how the “output” passes from the server back to the command line client. If the MQTT server is locked down for some reason, it might prevent this session topic from working. You can also try using mosquitto_sub to subscript to all topics and see if the session messages are flowing through the server.

Thanks for the response @TD22057. Using mosquitto_sub, subscribing to ‘#’ I do see the session topic in the command. Based on the fact that I see the response in the insteon-mqtt debug, I’m inclined to believe insteon-mqtt is successfully subscribed to that session topic. It also appears to my sleepy eyes that all the data is present. For the purpose of brevity, I printed the db of a switchlink that is only paired with the PLM, nothing else.
Here is what I see in the output of mosquitto_sub:

insteon/command/50.b8.39 {"cmd": "print_db", "session": "197502235"}
insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "Commanding switch device 50.b8.39 (foyer chandelier) cmd=print_db"}
insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "50.b8.39 (foyer chandelier) device database"}
insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "DeviceDb: (delta 0)\n  0ff7: 1a.78.24 grp:   1 type: CTRL data: 0x03 0x1c 0x01\n  0fff: 1a.78.24 grp:   1 type: RESP data: 0xff 0x00 0x01\nUnused:\nLast:\n  0fef: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)\nGroupMap\n  1 -> ['1a.78.24']\n"}
insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "Complete"}
insteon/command/50.b8.39/session/197502235 {"type": "END", "data": null}

And here is what I see in insteon-mqtt.log (debug level 10):

2019-12-11 05:36:35 INFO Mqtt: MQTT message insteon/command/50.b8.39 b'{"cmd": "print_db", "session": "197502235"}'
2019-12-11 05:36:35 UI Mqtt: Commanding switch device 50.b8.39 (foyer chandelier) cmd=print_db
2019-12-11 05:36:35 DEBUG Mqtt: MQTT publish insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "Commanding switch device 50.b8.39 (foyer chandelier) cmd=print_db"} qos=0 ret=False
2019-12-11 05:36:35 UI Base: 50.b8.39 (foyer chandelier) device database
2019-12-11 05:36:35 DEBUG Mqtt: MQTT publish insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "50.b8.39 (foyer chandelier) device database"} qos=0 ret=False
2019-12-11 05:36:35 UI Base: DeviceDb: (delta 0)
  0ff7: 1a.78.24 grp:   1 type: CTRL data: 0x03 0x1c 0x01
  0fff: 1a.78.24 grp:   1 type: RESP data: 0xff 0x00 0x01
Unused:
Last:
  0fef: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
  1 -> ['1a.78.24']

2019-12-11 05:36:35 DEBUG Mqtt: MQTT publish insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "DeviceDb: (delta 0)\n  0ff7: 1a.78.24 grp:   1 type: CTRL data: 0x03 0x1c 0x01\n  0fff: 1a.78.24 grp:   1 type: RESP data: 0xff 0x00 0x01\nUnused:\nLast:\n  0fef: 00.00.00 grp:   0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)\nGroupMap\n  1 -> ['1a.78.24']\n"} qos=0 ret=False
2019-12-11 05:36:35 UI Mqtt: Complete
2019-12-11 05:36:35 DEBUG Mqtt: MQTT publish insteon/command/50.b8.39/session/197502235 {"type": "MESSAGE", "data": "Complete"} qos=0 ret=False
2019-12-11 05:36:35 DEBUG Mqtt: MQTT publish insteon/command/50.b8.39/session/197502235 {"type": "END", "data": null} qos=0 ret=False
2019-12-11 05:36:35 DEBUG Mqtt: MQTT writing

Based on my reading of how you described the process, I think that everything is here that I should expect to be here. Is anything missing?

I just converted over from my previous HA system to HASS.IO and this fantastic integration for managing my Insteon devices. Thanks for all your work on this!!

I’m only having one issue, which is most assuredly my fault. I have two Insteon thermostats but cannot seem to have them correctly represented in Hass. Can someone please post a known-working yaml configuration? I’ve tried the one commented-out in the config.ysml for insteon-mqtt, but it doesn’t seem to work for me.

Firstly, running Hass.io on top of Ubuntu on a dedicated PC. Hass version 0.103.4. Using Insteon-mqtt as a custom addon, version 0.6.8, Installed per hass.io quick start on GitHub. USB PLM at /dev/ttyUSB0

This is what I currently have in my hass configuration.yaml:

climate: 
  - platform: mqtt
     name: Downstairs
     unique_id: downstairs_hvac
     mode_state_topic: "insteon/22.18.1e/mode_state"
     modes: ["OFF", "AUTO", "HEAT", "COOL", "PROGRAM"]
     current_temperature_topic: "insteon/22.18.1e/ambient_temp"
     fan_mode_state_topic: "insteon/22.18.1e/fan_state"
     fan_modes: ["AUTO", "ON"]

When using a thermostat card in Lovelace and pointing to the 'stat above (climate.downstairs), I get the following blank thermostat card:

Lastly, I get the following log errors, that are potentially contributing factors:

2019-12-24 15:05:02 DEBUG ThermostatCmd: This handler doesn't handle this device 22.18.1e
2019-12-24 15:05:02 ERROR Serial: Serial read error from /dev/ttyUSB0
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/network/Serial.py", line 184, in read_from_link
    self.signal_read.emit(self, data)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Signal.py", line 47, in emit
    slot(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 325, in _data_read
    self._process_msg(msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 428, in _process_msg
    status = handler.msg_received(self, msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/handler/ThermostatCmd.py", line 94, in msg_received
    self.device.signal_humid_change.emit(self.device, int(msg.cmd2))
AttributeError: 'Thermostat' object has no attribute 'signal_humid_change'
2019-12-24 15:05:48 INFO Protocol: Read 0x50: Std: 22.18.1e->44.85.06 Type.DIRECT cmd: 6f 34
2019-12-24 15:05:48 DEBUG Protocol: Setting next write time: 1577221548.790814
2019-12-24 15:05:48 DEBUG MsgHistory: Received 0 hops, total 0 for 11 entries
2019-12-24 15:05:48 DEBUG ThermostatCmd: This handler doesn't handle this device 22.18.1e
2019-12-24 15:05:48 ERROR Serial: Serial read error from /dev/ttyUSB0
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/network/Serial.py", line 184, in read_from_link
    self.signal_read.emit(self, data)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Signal.py", line 47, in emit
    slot(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 325, in _data_read
    self._process_msg(msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 428, in _process_msg
    status = handler.msg_received(self, msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/handler/ThermostatCmd.py", line 94, in msg_received
    self.device.signal_humid_change.emit(self.device, int(msg.cmd2))
AttributeError: 'Thermostat' object has no attribute 'signal_humid_change'
2019-12-24 15:06:06 INFO Protocol: Read 0x50: Std: 22.18.1e->44.85.06 Type.DIRECT cmd: 6f 33
2019-12-24 15:06:06 DEBUG Protocol: Setting next write time: 1577221566.784460
2019-12-24 15:06:06 DEBUG MsgHistory: Received 0 hops, total 0 for 11 entries
2019-12-24 15:06:06 DEBUG ThermostatCmd: This handler doesn't handle this device 22.18.1e
2019-12-24 15:06:06 ERROR Serial: Serial read error from /dev/ttyUSB0
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/network/Serial.py", line 184, in read_from_link
    self.signal_read.emit(self, data)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Signal.py", line 47, in emit
    slot(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 325, in _data_read
    self._process_msg(msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 428, in _process_msg
    status = handler.msg_received(self, msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/handler/ThermostatCmd.py", line 94, in msg_received
    self.device.signal_humid_change.emit(self.device, int(msg.cmd2))
AttributeError: 'Thermostat' object has no attribute 'signal_humid_change'
2019-12-24 15:06:28 INFO Protocol: Read 0x50: Std: 22.18.1e->44.85.06 Type.DIRECT cmd: 6f 32
2019-12-24 15:06:28 DEBUG Protocol: Setting next write time: 1577221588.777018
2019-12-24 15:06:28 DEBUG MsgHistory: Received 0 hops, total 0 for 11 entries
2019-12-24 15:06:28 DEBUG ThermostatCmd: This handler doesn't handle this device 22.18.1e
2019-12-24 15:06:28 ERROR Serial: Serial read error from /dev/ttyUSB0
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/network/Serial.py", line 184, in read_from_link
    self.signal_read.emit(self, data)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Signal.py", line 47, in emit
    slot(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 325, in _data_read
    self._process_msg(msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 428, in _process_msg
    status = handler.msg_received(self, msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/handler/ThermostatCmd.py", line 94, in msg_received
    self.device.signal_humid_change.emit(self.device, int(msg.cmd2))
AttributeError: 'Thermostat' object has no attribute 'signal_humid_change'
2019-12-24 15:06:52 INFO Protocol: Read 0x50: Std: 22.18.1e->44.85.06 Type.DIRECT cmd: 6f 33
2019-12-24 15:06:52 DEBUG Protocol: Setting next write time: 1577221612.783966
2019-12-24 15:06:52 DEBUG MsgHistory: Received 0 hops, total 0 for 11 entries
2019-12-24 15:06:52 DEBUG ThermostatCmd: This handler doesn't handle this device 22.18.1e
2019-12-24 15:06:52 ERROR Serial: Serial read error from /dev/ttyUSB0
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/network/Serial.py", line 184, in read_from_link
    self.signal_read.emit(self, data)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Signal.py", line 47, in emit
    slot(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 325, in _data_read
    self._process_msg(msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 428, in _process_msg
    status = handler.msg_received(self, msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/handler/ThermostatCmd.py", line 94, in msg_received
    self.device.signal_humid_change.emit(self.device, int(msg.cmd2))
AttributeError: 'Thermostat' object has no attribute 'signal_humid_change'
2019-12-24 15:07:02 INFO Protocol: Read 0x50: Std: 22.18.1e->44.85.06 Type.DIRECT cmd: 6f 34
2019-12-24 15:07:02 DEBUG Protocol: Setting next write time: 1577221622.780263
2019-12-24 15:07:02 DEBUG MsgHistory: Received 0 hops, total 0 for 11 entries
2019-12-24 15:07:02 DEBUG ThermostatCmd: This handler doesn't handle this device 22.18.1e
2019-12-24 15:07:02 ERROR Serial: Serial read error from /dev/ttyUSB0
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/network/Serial.py", line 184, in read_from_link
    self.signal_read.emit(self, data)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Signal.py", line 47, in emit
    slot(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 325, in _data_read
    self._process_msg(msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/Protocol.py", line 428, in _process_msg
    status = handler.msg_received(self, msg)
  File "/usr/lib/python3.6/site-packages/insteon_mqtt/handler/ThermostatCmd.py", line 94, in msg_received
    self.device.signal_humid_change.emit(self.device, int(msg.cmd2))
AttributeError: 'Thermostat' object has no attribute 'signal_humid_change'

Thanks in advance!
Terry

@roussell: That’s been fixed in this new version

Version 0.6.9 has been delivered to github and to docker (I don’t run hassio myself so hopefully this works). Here are the changes and fixes:

[0.6.9]

Additions

  • Added a catalog of known device category and sub-category information. Just used for display in the get-model command for now. (thanks @mooshee)

  • Added an optional reason string to the state change reporting payloads and as an optional input for input commands. This allows for automations to change behavior based on why something changed. ([Issue #138][I138])

  • Added KeypadLinc low level set_flags commands to modify: load (de)attached, button follow masks, button off masks, non-toggle buttons. (thanks @jrevans).

  • Added KeypadLinc support for turning of the backlight completely (thanks @jrevans).

Fixes

  • Fixed bug in message emits for battery sensors. ([Issue #157][I157])

  • Fixed bug in thermostat not reporting humidity changes ([Issue #160][I160])

  • Updated hassio config file to include the required arch listing. ([Issue #139][I139])

  • Added docker builds for hassio from my repo (td22057) ([Issue #148][I148])

  • Fixed bug in motion sensor replies to a model info request ([Issue #163][I163]).

  • Fixed bug in thermostat ambient temperature calculation ([Issue #142][I142]) (thanks @krkeegan).

  • Fixed bug in KeypadLinc, FanLinc, and Outlet for non-group 1 links ([Issue #159][I159]) (thanks @chris153002).

@TD22057 Thanks! That seemed to clear up the errors in the log, and I subscribe to the various tops to see the 'stats in action.

Edit: Seems as though I spoke too soon. I am still seeing this error in the logs:

`DEBUG ThermostatCmd: This handler doesn't handle this device 22.18.1e`

The stat is a regular Insteon 2441TH, and not a Venstar/Insteon model…

Does anyone have a working YAML config (configuration.yaml) for the thermostats they can share? I’ve had no luck getting it to show correctly, especially with the heat/cool setpoints. It seems as though the MQTT thermostat entity expects a single setpoint rather than separate setpoints for heat/cool. I feel like this is where a template might be used, but I’ve avoided those like the plague for some reason… Any clues, examples, or even a hard shove in the right direction will be appreciated!

Terry

Figured out that deleting and re-linking fixed the above, as well as a similar issue with a motion sensor.

Terry

@TD22057 noticing a new bug(?) with 0.6.9 - again running as a hassio add-on. Every day or two, the service will stop responding to commands from HA and stop reporting status. Restarting the add-on immediately corrects the problem. I don’t see anything noticeably wrong in the add-on’s log and have log-level set to ‘debug’. I realize you don’t run hassio, but is there anything I can look at to shed more light on what might be happening?

Terry

@roussell Not that I can think of. It works fine for me running months at a time. There are several steps and you should check all of them (Insteon->IM->Mosquitto->HA and the reverse). Check the MQTT broker logs. Check the HA logs (search backwards to find the last mention). Manually send an MQTT message to IM and look in the logs to see if it was received. Click an Insteon button that you know works and check the IM logs to see if it reads the Insteon message and handles it. If you see it read the message, then check the HA logs to see if anything shows up. Manually subscribe to insteon/# in the broker and see what messages are being passed around.

I just tried to get this working because I was unhappy with the native support for insteon (no messages for all devices in a triggered scene). I am using hassio, so I installed mosquitto from the addons repository, then yours.

Everything is connecting ok - the logfile shows the PLM (I have an old 2241 that connects via network, port 9761), and I have all the devices in my config. That’s all good until I get to the point where the startup guide wants me to issue “join” and “pair” commands for each device, where I’m supposed to use the command line tool.

What command line tool? Under hassio at least, there’s no insteon-mqtt executable visible (you just get a not found when you try it in an ssh session). Is there a port I need to telnet to? How to I issue these commands?

Lacking any idea how to send commands natively, I installed an mqtt message utility via good old homebrew on the mac. That ALSO connects just fine (the mqtt broker log shows it logging in with the ID I created for it), but I can send messages to insteon/command/device all day, and there no response from the mqtt server or mqtt-insteon in their logs to the messages (join/pair), and the command line utility (mqtt-cli) simply shows it published a message with no idea what happened with it.

Just for laughs, to see if anything at all was working, I went over to one of my insteon switches and held in the setup button. THAT got a rise out of mqtt-insteon, there were a bunch of messages about the device I press, by it’s proper name in the config file, so I THINK I have everything configured right, I just can’t seem to figure out how to join, pair, and set up the database records. Can anyone help?

Also - I have two X10 devices (old wiring, no neutral line), and nothing I tried lets me put them in the configuration, I just get an error that G2 and G5 (the two device addresses) are invalid. Since it wants a hex address that makes sense, I’m wondering if there’s a section for X10 devices that wasn’t in the template config file, since you say you do support them in another answer.

Please note: this is not a new setup. I had it working on openhab for two years, and also working (as good as it DOES work) under native insteon support. All of this is functional and not new hardware.

A quick update: I’ve been flipping some switches on and off, and each time I do, a bunch of messages showing the insteon command for each device shows in the insteon-mqtt log, under their configured names. I am SO close.

I went back to the integrations config in home assistant, just to see if the devices had been discovered (I have discovery turned on already). Nothing there.

The IM system doesn’t support MQTT device discovery - you have to configure them yourself in HA following the examples in config.yaml. If your devices were already configured (paired w/ the modem in BOTH directions), then you just need to issue a refresh command to each device so that IM can download the device database. See the docs here: https://github.com/TD22057/insteon-mqtt/blob/fdfe9a4991349e240f43d9532ed76ad7b24fab0a/docs/mqtt.md

You can send refresh or pair commands that way. I’m pretty certain that HA can be used to send MQTT messages or you can use any external utility to do it. So if you send to the topic insteon/command/aa.bb.cc the payload { "cmd" : "refresh" }, it will get the db for that device. You can try sending the cmd refresh-all to do them all at once. If you have battery devices that won’t work (they have to be awake to see the command) and I have a few devices that don’t respond that well (IOLinc) so you may have to send the refresh command a couple of times before it works.

Thanks for replying so quickly!

I read the documentation you linked already, and I tried (as my first message explained) to send MQTT messages, but nothing is happening in the Mosquitto logs when I do it, and nothing is showing in the Insteon-MQTT logs either. It shows I logged in, but there’s no response to my publishes.

That’s really the part that’s driving me crazy right now - all of the components are installed and can be connected to, but they don’t seem to be listening to each other. Either that or I am not sending a message correctly. I’m not very familiar with MQTT internals, but it seems simple enough with the utilities I’ve tried. Any suggestions? Right now I just want to have Mosquitto and IM communicating, I’ll worry about homeassistant’s device config later.

Let me clarify - IM is connecting successfully to Mosquitto, there’s a successful connection showing in both logs. There’s just no responses to poking MQTT messages into Mosquitto, or any response to events generated by IM in Mosquitto.

It’s quite possible it’s actually Mosquitto is the problem, but I have no idea where to start there since it’s more or less a one liner installation, other than setting up the user Id (which I know I did right because it won’t let the command line tool log in unless the I’d/password is right).

I did find a place for sending mqtt from home assistant itself (in developer tools/services), but when I fill in the mqtt.publish like so:

topic: insteon/command/40.63.c9
payload: ‘{ “cmd” : “refresh” }’
qos: 1
retain: true

Nothing happens. The message doesn’t error out (I was getting that before I put the payload in single quotes), but it doesn’t elicit a response from mosquitto either.

Here’s how I have mosquitto configured:

{
  "logins": [
    {
      "username": "mozzie",
      "password": "(password)"
    }
  ],
  "anonymous": true,
  "customize": {
    "active": false,
    "folder": "mosquitto"
  },
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem",
  "require_certificate": false,
  "plain": true,
  "ssl": false
}

and here’s how I have my devices setup (the x10 ones are commented out because I can’t figure out how to enter their house and unit codes):

 logging:
  level: 10

insteon:
  port: 'socket://192.168.1.64:9761'
  address: 25.e8.e4
  storage: 'data'

  devices:
    switch:
#      - g2.00.00: 'traffic'       
      - 35.40.18: 'floor'
#      - g5.00.00: 'bedroom'                                               

    dimmer:
      - 26.9d.19: 'table'
      - 41.0e.c9: 'bathroom'
      - 41.14.0a: 'hallway'
      - 24.e4.85: 'dining'
      - 40.63.c9: 'kitchen'
      - 43.c7.bb: 'office'

    motion:
      - 4f.88.a7: 'garagemotion'

    keypad_linc_sw:
      - 39.45.a1: 'keypad'

    outlet:
      - 4e.6d.ef: 'garage'

mqtt:
  broker: core-mosquitto
  port: 1883
  username: mozzie
  password: (password)
  keep_alive: 30
  qos: 1
  retain: 1

  cmd_topic: 'insteon/command'

Everything after that is unchanged from the default yaml configuration.

The IM log shows it’s connecting to mosquitto:

2020-01-16 12:23:39 DEBUG poll: Link connection attempt MQTT core-mosquitto:1883
2020-01-16 12:23:39 INFO Mqtt: MQTT device opened core-mosquitto 1883 with keepalive=30
2020-01-16 12:23:39 DEBUG poll: Link connection success MQTT core-mosquitto:1883
2020-01-16 12:23:39 DEBUG poll: Link added: MQTT core-mosquitto:1883
2020-01-16 12:23:39 DEBUG Mqtt: MQTT subscribe insteon/command/+ qos=1
2020-01-16 12:23:39 DEBUG Mqtt: MQTT subscribe insteon/modem/scene qos=1
(many subscribe messages not shown)

And likewise, mosquitto shows it was connected to from both HA itself and IM:

1579199324: New connection from 172.30.32.1 on port 1883.
[INFO] found homeassistant on local database
1579199325: New client connected from 172.30.32.1 as auto-632408A8-6010-CD04-EC18-317156CF4E0E (p2, c1, k60, u'homeassistant').
1579199327: New connection from 172.30.33.1 on port 1883.
[INFO] found mozzie on local database
1579199327: New client connected from 172.30.33.1 as insteon-mqtt (p2, c0, k30, u'mozzie').

Edit: Woo, progress! I was apparently missing a bit of stuff in the master config.yaml for home assistant. I added this:

mqtt:
  broker: hassio.local
  port: 1883
  username: mozzie
  password: (password)

And now messages are passing between mosquitto and IM succesfully! I sent a refresh all command, and lots and lots of stuff happened.

I’m going to poke around and see if I can actually get lights to work, but it appears my only open question is how do I configure my two X10 devices. Thanks a lot for all the help so far!

Note to Randall (I am limited to the number of replies, I had to edit instead, that’s annoying!:
I can help with this one!

If you’re using hassio, there’s no place for a command line utility. Instead, you need to open up the developer tools, click on “services”, and under service name on the page that opens, put “mqtt.publish”. Inside the message box, you would put your topic and payload. For example, if I want to turn on my hallway light, I would do this:

topic: insteon/41.14.0a/set
payload: on
qos: 1
retain: true

If you want to do that refresh-all command, it looks like this:

topic: insteon/command/modem
payload: '{ "cmd" : "refresh", "force": true}'
qos: 1
retain: true

Alternatively, you can set up an MQTT client utility (such as mqtt-cli, or MQTTBox) and send the messages that way. mqtt-cli is handy if you need to send a bunch of messages multiple times and don’t want to keep cutting and pasting.

Read this message for some more clues (like what you need to do in config.yaml) on the config process.

Edit: If you install the ssh server, you can also do this right from the hassio shell:

[Iris]pv: ssh [email protected]
Enter passphrase for key '/Users/pv/.ssh/id_rsa': 

  _    _                 _       
 | |  | |               (_)      
 | |__| | __ _ ___ ___   _  ___  
 |  __  |/ _` / __/ __| | |/ _ \ 
 | |  | | (_| \__ \__ \_| | (_) |
 |_|  |_|\__,_|___/___(_)_|\___/ 
                                 


Our Cli:
$ hassio help

~ $ mosquitto_pub -h 'core-mosquitto' -t 'insteon/43.c7.bb/set' -m 'on'
~ $ 


Hi, just started with insteon-MQTT on hassio. I keep seeing references to a command line version of insteon-MQTT for sending commands etc to devices but I cant seem to locate it on my system anywhere. Is this script installed as part of the hassio addon or do I need to install it a different way? I’ve gotten switches/dimmers working using the developer MQTT but now I’m trying to set my modem as a controller of a scene and command line seems like the best/only way to do this.

Ah, cool, I didn’t think of using the shell. I’ll give it a try. Thanks!

OK, another question. I have a scene in my office that was set up a long time ago using the insteon app and hub. It consists of the main overhead light and two lamps. The overhead is controller of the scene so if you turn it on the two lamps turn on as well. If I look in the app it is group 23. I’m trying to figure out how to make the modem a controller/responder of this scene so that I can trigger the scene from HA-mqtt. I see this command in the doc that makes a device a controller of another device:

{ "cmd" : "db_add_ctrl_of", "local_group" : ctrl_group,
  remote_addr" : aa.bb.cc, "remote_group" : resp_group,
  ["two_way" : true/false], [refresh" : true/false],
  ["local_data" : [D1,D2,D3]], ["remote_data" : [D1, D2,D3]] } }

Is that what I need?  I don't understand the local_group & remote group.  Wouldn't the groups be the same i.e 23 on both ends?  Does this have to be done for each device in the group?

Can you explain in further details your fix?

I too have the thermostat icon/card only showing like your screenshot.

Thx