This Insteon integration has been working fine for me through multiple upgrades so I suspect a configuration error.
So I’m using the default insteon implementation that is with Home Assistant, and have never used MQTT before. Will using this integration help with the speed of the responses? It seems as though everything works really slow with the default implementation. I turn on a light from the app, and then 1-2 seconds later the device turns on/off. Same with motion sensors, when triggered, it takes a while for the light to turn on and by then I could already be at the switch or I am done with what I need to in that room.
I have a USB insteon device with RF, and probably around 40-50 insteon devices.
Thank you for your response. I very much appreciate your guidance helping me focus my efforts. I understand the error msg in a simplistic way but I did not have clarity on the flow.
@parkercat You are, no doubt, correct.
Focusing on the first error traceback - File /usr/lib/python3.6/site-packages/insteon_mqtt/mqtt/MsgTemplate.py I went looking for it scanning the entire system for that file. Results:
/opt/insteon/insteon_mqtt/mqtt/MsgTemplate.py
/opt/insteon/lib/python3.5/site-packages/insteon_mqtt/mqtt/MsgTemplate.py
I note the error message sepcifies …/python3.6/… This folder does not exist. My level of confusion rises once again because the message specifies further a line number within code in a file that does not exist!
I also find that the dimmer “component” seems to have a common issue. None of mine work. Keypads do.
I tried uninstalling insteon-mqtt and re-installing using quickstart hassio directons and get this error when I click on install:
...
19-10-15 17:39:31 INFO (MainThread) [hassio.store] Load add-ons from store: 64 all - 0 new - 0 remove
19-10-15 17:39:36 INFO (SyncWorker_2) [hassio.docker.interface] Pull image td22057/aarch64-insteon-mqtt tag 0.6.8.
19-10-15 17:39:37 ERROR (SyncWorker_2) [hassio.docker.interface] Can't install td22057/aarch64-insteon-mqtt:0.6.8 -> 500 Server Error: Internal Server Error ("received unexpected HTTP status: 503 Service Unavailable").
The first line and others not included suggest to me that the issue for (re)install is not on my end but what to do now?
Any suggestions on how to clean this up?
Thanks again,
Q
Progress. I will edit my post to remove irrelevant noise ASAP. I had an error in my configuration.yaml :
command_topic: "insteon/1a.e0.bd/set"
Should be:
command_topic: "insteon/1a.e0.bd/level"
As to the issue with re-install after removal, the pull image now works so Insteon-MQTT is re-installed. but with errors on startup (I think). Still don’t understand references to python3.6 as above when I can’t find that path. My searches don’t turn up anything that explains.
Thanks for the comments, sorry for the noisy post and happy for the progress!
Regards to all.
Q
Can someone post an example for a dimmer to keep 3 switches in sync. Only one controls the load, the others are just dummies. I think I need to use the scene, but don’t know how.
I try to connect my venstar thermostat 2441V with no luck.
It work via the insteon-terminal, but no luck with insteon-mqtt
I tried to test with mosquitto_pub but no luck, might be me, or simply the thermostat “driver” , insteon-terminal have 2 type of thermostat and maybe only the 2441TH is currently configured
Anyone would be kind to post a working mosquitto_pub command to set the temperature, so I could validate on my side
Regards
Thanks very much for posting this link. I was able to recover my PLM for nothing but the cost of a few capacitors.
Interestingly, the link database was wiped out, which of course should have nothing to do with those capacitors. Out of curiosity, did that happen to anyone else?
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.