Yes, that reboot - and the desire to avoid the amount of time that it takes - can hide demons.
For the record - a reboot makes no difference to the insteon-mqtt server. The only thing I can think of is that it’s running it as a service and it’s not being fully shut down and restarted. If anyone ever runs into this type of issue, I’d recommend stopping the service, check that it’s stopped (ps -ef | grep insteon) and then run the server manually which makes it a lot easier to debug things until you get any config inputs ironed out.
Good point, the RESTART I was referring to is HomeAssistant and NOT insteon-mqtt (which I have on separate computers for now because HomeAssistant is just for testing “on the side”),
I do not have to reboot insteon-mqtt.
I was assuming @mattcantu was referring to rebooting HA.
insteon-mqtt picked up the changes after I rebooted the Pi. In hindsight, as TD22057 pointed out, I could have stopped/started the insteon-mqtt service instead.
I have a new 6 button keypadlinc that controls a fanlinc. I wanted to get it, and then the fanlinc, paired with the PLM. To that end, I linked in both directions, and ran the pair command, which should add both-way links for the remaining buttons. Here’s the output:
bin/insteon-mqtt config.yaml print-db modem | grep 4a.98.6f <==my new keypadlinc ID
ID: 4a.98.6f grp: 1 type: CTRL data: 0x01 0x42 0x45
ID: 4a.98.6f grp: 1 type: RESP data: 0x00 0x00 0x00
1 -> [‘14.d4.79’, ‘13.ec.4c’, ‘12.02.64’, ‘4a.98.6f’]
I believe this indicates that the link in both directions is correct.
When I run the pair command, this seems to go sideways:
insteon-mqtt config.yaml pair 4a.98.6f
Commanding KeypadLinc device 4a.98.6f (master br kp1) cmd=pair
KeypadLinc 4a.98.6f setting LED bits 00001011
Dimmer 4a.98.6f refresh at level 255
Device 4a.98.6f db out of date (got 7 vs 6), refreshing
Entry: 0fff: 49.23.d4 grp: 1 type: CTRL data: 0x03 0x1c 0x01
Entry: 0ff7: 49.23.d4 grp: 3 type: CTRL data: 0x03 0x1c 0x03
Entry: 0fef: 49.23.d4 grp: 4 type: CTRL data: 0x03 0x1c 0x04
Entry: 0fe7: 49.23.d4 grp: 6 type: CTRL data: 0x03 0x1c 0x06
Entry: 0fdf: 49.23.d4 grp: 5 type: CTRL data: 0x03 0x1c 0x05
Entry: 0fd7: 1a.78.24 grp: 1 type: RESP data: 0xff 0x00 0x01
Entry: 0fcf: 1a.78.24 grp: 1 type: CTRL data: 0x03 0x1c 0x01
Entry: 0fc7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (LAST)
4a.98.6f database download complete
DeviceDb: (delta 7)
0fcf: 1a.78.24 grp: 1 type: CTRL data: 0x03 0x1c 0x01
0fd7: 1a.78.24 grp: 1 type: RESP data: 0xff 0x00 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:
0fc7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (LAST)
GroupMap
1 -> [‘49.23.d4’, ‘1a.78.24’]
3 -> [‘49.23.d4’]
4 -> [‘49.23.d4’]
5 -> [‘49.23.d4’]
6 -> [‘49.23.d4’]
Device 4a.98.6f add db already exists for 1a.78.24 grp 1 RESP
ERROR: Modem db updated failed: OutAllLinkUpdate: 4a.98.6f grp: 1 Cmd.UPDATE: ack: False
ERROR: Modem database update failed
I get that " 1 -> [‘14.d4.79’, ‘13.ec.4c’, ‘12.02.64’, ‘4a.98.6f’]" is one of the group lines in the modem config, and I see that relates to the error that causes the pair to fail, but I’m not sure how I did this other than just linking them back and forth with each other.
Any idea how I can fix this?
I’m guessing that the modem is 49.23.d4. The issue is that the device doesn’t have a group 1 entry for the modem as a responder. Without that group 1 RESP entry, the device won’t accept commands from the modem which triggers the failure. I’m not sure how that could happen but that’s the failure. You can try doing a factory reset on the device and then re-run the linking step (https://github.com/TD22057/insteon-mqtt/blob/master/doc/mqtt.md#activate-all-linking-mode) to add the group 1 links. Or you can just hold the set button down on the device and modem to re-link them (I forget which order you need). Then re-run the pair command.
Ya, I should have clarified- modem is 1a.78.24, fanlinc is 49.23.d4, keypadlinc is 4a.98.6f. So here the KPL is barking about the fact that the modem is a responder on group 1, which is a result of my using the procedure outlined in the insteon-mqtt docs. Or possibly mis-using that procedure.
At any rate, a print-db on the modem, grep’ing for the ID of the KPL shows:
insteon-mqtt config.yaml print-db modem | grep 4a.98.6f <==my new keypadlinc ID
ID: 4a.98.6f grp: 1 type: CTRL data: 0x01 0x42 0x45
ID: 4a.98.6f grp: 1 type: RESP data: 0x00 0x00 0x00
And a print-db on the KPL, grep’ing for the ID of the modem shows:
insteon-mqtt config.yaml print-db 4a.98.6f | grep 1a.78.24
0fcf: 1a.78.24 grp: 1 type: CTRL data: 0x03 0x1c 0x01
0fd7: 1a.78.24 grp: 1 type: RESP data: 0xff 0x00 0x01
GroupMap
1 -> [‘49.23.d4’, ‘1a.78.24’]
So both the KPL and modem report that they are linked in both directions, correct?
You’re right - that looks ok. Try running pair again - it will skip links that already exist and just make the ones that are missing (looks like it just needs group 2, 7, 8). Sometimes insteon commands fail (device wasn’t ready, other traffic on the network) so for long series of commands like the db updates, it might be necessary to do it twice. If that doesn’t work, can you file a bug on github and we can diagnose it over there?
Well, I was writing up the bug report, and ran the pair command for the umpteenth time, and of course it decided to pair. I have no idea why it failed there so many times, and no idea why it chose to complete now, but I’ll take it!
If you happen to have the logs (with debug level), can you send them to me (or post them to a github issue) - I’ll take a look and see if there is anything I can see that would help.
I didn’t have the logs cranked up to debug at the time. I’ll do so before installing the next KPL, whenever that may be.
Do I need to do anything special to get HA and insteon-mqtt to remember the state of Insteon switches across reboots? I installed MariaDB and added recorder to configuration.yaml. I added retain to each of the Insteon switches in configuration.yaml. However, when I reboot my Raspberry Pi, some Insteon switches that are currently on end up turning off and vice-versa.
@mattcandu I believe HA will remember things on it’s own but I’m not sure - you may need to have the recorder component on. Setting retain for the state messages in Insteon-MQTT will cause the last state value to be resent to HA when it reconnects. I believe the MQTT broker should persist those in between restarts but I’ve never tested that. Insteon-MQTT also has a start up option to rescan all the hardware device states which might help - but it could also be slow if you have a lot of devices so turning that on might depend on how many devices you have and how often you restart everything. All of this assumes that the brokern, Insteon-MQTT, and HA are on the same machine of course. You can always look at the HA and Insteon-MQTT logs to see why the state is changing at start up - that’s the best way to figure out what’s actually going on.
Hi everyone. I have an old hub (2242-222) and I am enjoying Insteon-MQTT so far. Is it possible to implement a ramp rate for controlling dimmers? Right now, the ramp rate is by default at 0.1 second. I can set the ramp rate for up to 9 minutes from the time when the level is at 0 to when it’s at full brightness.
It’s the D2 field in the link database in the responder. So it could be set when creating the link. I don’t think my library has any way to just update the data fields right now - you would have to delete the link and recreate it. That can be set using the command line tool ‘db-add’ command. Run ‘insteon-mqtt config.yaml db-add -h’ to see the help and look for the --ramp optional input. If you’d like, open an enhancement issue on the github repo and I can look at how to add a command to set that field when the link already exists.
FYI - I spent this morning merging some pull requests and other fixes into the dev branch on github. These include support for old (<5 years?) I1 devices and more optimal settings for how messages are sent on the network. The biggest change is a fix (see https://github.com/TD22057/insteon-mqtt/issues/33) to support keypadlinc’s that are switches instead of dimmers which required a change to the keypadlinc portion of the config file. If anyone can grab the dev branch and test out these changes - that would be great (feel free to post any issues to github or here). Once I feel like these changes didn’t break anything, I’ll merge them to the main branch and do a new release.
Not sure what I keep doing wrong with the install. Fresh install of Ubuntu Server 16.04 on i386 system. I have followed the System install and automatically starting the server
2018-07-07 18:40:55 DEBUG Mqtt: MQTT subscribe insteon/48.7a.4e/set qos=1
2018-07-07 18:40:55 DEBUG Mqtt: MQTT subscribe insteon/48.7a.4e/scene qos=1
2018-07-07 18:40:55 DEBUG poll: Link connection attempt Serial /dev/insteon
2018-07-07 18:40:55 ERROR Serial: Serial connection error to /dev/insteon
Traceback (most recent call last):
File "/opt/insteon-mqtt/lib/python3.5/site-packages/serial/serialposix.py", line 265, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: '/dev/insteon'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/insteon-mqtt/lib/python3.5/site-packages/insteon_mqtt/network/Serial.py", line 146, in connect
self.client.open()
File "/opt/insteon-mqtt/lib/python3.5/site-packages/serial/serialposix.py", line 268, in open
raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port /dev/insteon: [Errno 2] No such file or directory: '/dev/insteon'
2018-07-07 18:40:55 DEBUG poll: Link connection failed Serial /dev/insteon
2018-07-07 18:40:55 DEBUG Mqtt: MQTT writing
^CTraceback (most recent call last):
File "/opt/insteon-mqtt/bin/insteon-mqtt", line 5, in <module>
status = insteon_mqtt.cmd_line.main()
File "/opt/insteon-mqtt/lib/python3.5/site-packages/insteon_mqtt/cmd_line/main.py", line 272, in main
return args.func(args, cfg)
File "/opt/insteon-mqtt/lib/python3.5/site-packages/insteon_mqtt/cmd_line/start.py", line 52, in start
loop.select()
File "/opt/insteon-mqtt/lib/python3.5/site-packages/insteon_mqtt/network/poll.py", line 176, in select
events = self.poll.poll(time_out)
The error says “no file /dev/insteon” so do you have that file? You have to point the config file to your Insteon PLM modem USB or serial device. Unless you configured a USB sym link from /dev/insteon to the actual device, it won’t exist (google ‘usb device symlink’ or similar)
Thanks, @TD22057
I did not change “/dev/ttyUSB0” in my config file. I am no longer getting an error with serial, but am now in a connection disconnect loop with MQTT. I had your this working a long time ago when you just started and not all functionality was working that is why my MQTT has info with subscribe I am assuming. IP, Port U/P are all correct so not sure why it beeps trying to write and then disconnect, Did notice their is no colon between ip and port if that matters.
2018-07-07 19:53:51 INFO Mqtt: MQTT disconnection 192.168.0.110 1883
2018-07-07 19:53:51 DEBUG poll: Link removed MQTT 192.168.0.110:1883
2018-07-07 19:54:01 DEBUG poll: Link connection attempt MQTT 192.168.0.110:1883
2018-07-07 19:54:01 INFO Mqtt: MQTT device opened 192.168.0.110 1883 with keepalive=30
2018-07-07 19:54:01 DEBUG poll: Link connection success MQTT 192.168.0.110:1883
2018-07-07 19:54:01 DEBUG poll: Link added: MQTT 192.168.0.110:1883
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/command/+ qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/modem/scene qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/48.79.ba/set qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/48.79.ba/scene qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/3f.d9.93/set qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/3f.d9.93/scene qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/3f.d9.93/level qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/3f.d9.93/scene qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/3f.d9.93/fan/set qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/3f.d9.93/fan/speed/set qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/48.7a.4e/set qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/48.7a.4e/scene qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/level qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/1 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/1 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/2 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/2 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/3 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/3 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/4 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/4 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/5 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/5 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/6 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/6 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/7 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/7 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/set/8 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT subscribe insteon/46.fb.73/scene/8 qos=1
2018-07-07 19:54:01 DEBUG Mqtt: MQTT writing
2018-07-07 19:54:11 INFO Mqtt: MQTT disconnection 192.168.0.110 1883
2018-07-07 19:54:11 DEBUG poll: Link removed MQTT 192.168.0.110:1883
^CTraceback (most recent call last):
File "/opt/insteon-mqtt/bin/insteon-mqtt", line 5, in <module>
status = insteon_mqtt.cmd_line.main()
File "/opt/insteon-mqtt/lib/python3.5/site-packages/insteon_mqtt/cmd_line/main.py", line 272, in main
return args.func(args, cfg)
File "/opt/insteon-mqtt/lib/python3.5/site-packages/insteon_mqtt/cmd_line/start.py", line 52, in start
loop.select()
File "/opt/insteon-mqtt/lib/python3.5/site-packages/insteon_mqtt/network/poll.py", line 176, in select
events = self.poll.poll(time_out)
KeyboardInterrupt
(insteon-mqtt) david@SlimAce:/opt/insteon-mqtt$
Check your broker settings. It closed exactly 10 sec after the last comm. The keep alive in the broker should be 60 seconds. Or adjust the keep alive in the app to be 5 seconds though that will put more load in the system.