I have the same problem with Alexa. Curiously it works fine through Siri/Homekit, just not Alexa at my house. I assumed it was something with the quirky way the thermostat is configured in HA. Ideally there would just be one setpoint for heating and cooling but not sure if that’s possible.
Terry
Version 0.7.0 has been released to github and docker for hassio users. Huge thanks to krkeegan for developing the scene management system. This allows complete syncing of all the Insteon scenes and links from a configuration file. Check out the docs here: https://github.com/TD22057/insteon-mqtt/blob/b93732de4c7e62d358c0e3a9deecf9668f9a4adf/docs/scenes.md
Thanks to @krkeegan, scene management and syncing are now supported. This
allows you to define all of your Insteon scenes in a configuration file and
have the system sync your devices to that file. ([Issue #25][I25],
[Issue #179][I179])
Enable software control of motion sensor flags ([Issue #184][I184])
(thanks @krkeegan)
Added support for single button remotes ([Issue #185][I185])
(thanks @krkeegan)
Added an option to skip battery devices when doing a refresh and a new
command to get the engine version (for older I1 devices) ([Issue #189][I189])
(thanks @krkeegan)
Fixed an error in the Thermostat MQTT code preventing user specified topics
([Issue #182][I182]) (thanks @krkeegan)
Fixed issues with handling housekeeping messages sent to the model during
a scene command. ([Issue #183][I183]) (thanks @krkeegan)
Thanks to both @TD22057 and @krkeegan. This was one major issue for this project, I have updated to 7.0. I have imported all scenes from the modem using mqtt topic insteon/command/48.ef.b1 and payload { “cmd” : “import_scenes_all”, “dry_run” : true} creating a scene file with all of this. Some of it makes sense but I am really at a loss of how to edit it per the scene example to make it readable. Any help would be appreciated and thanks again for all your hard work on this project. My repo is https://github.com/djryan012/homeassistant-config/
- controllers:
- switch2:
data_2: 31
- switch1:
data_2: 31
responders:
- switch1:
data_2: 31
- switch2:
data_2: 31
- controllers:
- 3c.d1.ec
responders:
- switch1:
data_1: 0
data_2: 28
- controllers:
- dimmer2:
data_2: 31
- dimmer3:
data_2: 31
responders:
- dimmer3
- dimmer2:
ramp_rate: 2
- controllers:
- keypad1:
group: 4
data_2: 31
responders:
- fanlinc1:
group: 2
on_level: 66.7
data_2: 28
- controllers:
- keypad1:
group: 5
data_2: 31
responders:
- fanlinc1:
group: 2
data_2: 28
- controllers:
- keypad1:
group: 6
data_2: 31
responders:
- fanlinc1:
on_level: 20.0
ramp_rate: 2
group: 1
- controllers:
- keypad1:
data_2: 31
group: 1
responders:
- fanlinc1:
ramp_rate: 0.5
group: 1
- controllers:
- keypad1:
group: 3
data_2: 31
responders:
- fanlinc1:
group: 2
on_level: 33.3
data_2: 28
- controllers:
- keypad2:
data_2: 28
group: 1
responders:
- fanlinc2:
ramp_rate: 2
group: 1
- controllers:
- keypad2:
group: 6
data_2: 28
responders:
- fanlinc2:
on_level: 29.8
ramp_rate: 2
group: 1
- controllers:
- keypad2:
group: 5
data_2: 28
responders:
- fanlinc2:
group: 2
data_2: 28
- controllers:
- keypad2:
group: 3
data_2: 28
responders:
- fanlinc2:
group: 2
on_level: 33.3
data_2: 28
- controllers:
- keypad2:
group: 4
data_2: 28
responders:
- fanlinc2:
group: 2
on_level: 66.7
data_2: 28
- controllers:
- keypad3: 3
responders:
- fanlinc3:
group: 2
on_level: 33.3
data_2: 28
- controllers:
- keypad3: 5
responders:
- fanlinc3:
group: 2
data_2: 28
- controllers:
- keypad3: 4
responders:
- fanlinc3:
group: 2
on_level: 66.7
data_2: 28
- controllers:
- keypad3: 6
responders:
- fanlinc3:
group: 2
on_level: 0.0
data_2: 28
- controllers:
- keypad3:
data_2: 28
group: 1
responders:
- fanlinc3:
ramp_rate: 0.5
group: 1
- controllers:
- modem: 242
responders:
- keypad1: 2
- keypad2: 2
- keypad3: 2
- controllers:
- modem: 243
responders:
- keypad1: 3
- keypad2: 3
- keypad3: 3
- controllers:
- modem: 244
responders:
- keypad1: 4
- keypad2: 4
- keypad3: 4
- controllers:
- modem: 245
responders:
- keypad1: 5
- keypad2: 5
- keypad3: 5
- controllers:
- modem: 246
responders:
- keypad1: 6
- keypad2: 6
- keypad3: 6
- controllers:
- modem: 247
responders:
- keypad1: 7
- keypad2: 7
- keypad3: 7
- controllers:
- modem: 248
responders:
- keypad1: 8
- keypad2: 8
- keypad3: 8
- controllers:
- fanlinc3: 2
responders:
- keypad3:
ramp_rate: 0.5
group: 1
@djryan012 If you find an issue, please file a github ticket. AFAIK, krgeegan doesn’t read these forums. I didn’t write any of that code and haven’t had a chance to go through it all so it will be faster if you @ him on the ticket.
@TD22057 Thanks, I hate creating ticket issues when its a comprehension issue and not a bug issues. But I will create one and hopefully and hopefully it can help anyone else trying to understand what our PLM are set up as.
Version 0.7.1 has been released on github and to docker for hass.io.
Sorry for the multiple releases (think of it as a feature 
). Version 0.7.2 has been released on github and to docker.
Greetings all.
Still working on getting my HA up to speed. Having trouble with getting scenes off the ground in this integration. Using V0.7.2
configuration.yaml has : scenes: /opt/hassio/homeassistant/scenes.yaml (file editor did not like scenes: !rel_path scenes.yaml). Also tried scenes: /home/mk1/homeassistant/scenes.yaml. No diff.
publishing to this topic: insteon/command/modem
this payload: { "cmd": "import_scenes_all", "dry_run" : false}
I haven’t been able to make commands work from the command line so I am using dev tools to publish to mqtt.
Also startup refresh is true and have do reboot now after saving changes as well as waiting for refresh to finish before starting import.
Yields:
2020-03-27 12:28:27 UI Mqtt: Commanding Modem device 1b.49.85 (modem) cmd=import_scenes_all
2020-03-27 12:28:27 INFO Modem: Device 1b.49.85 (modem) cmd: import_scenes
2020-03-27 12:28:27 UI Modem: Importing Scenes from 1b.49.85 (modem) device
2020-03-27 12:28:27 UI Modem: No changes necessary.
2020-03-27 12:28:27 UI Modem: Import Scenes Done.
2020-03-27 12:28:30 INFO Base: Device 21.72.28 (os_lights_back_switch_din_rail_on_off) cmd: import_scenes
2020-03-27 12:28:30 UI Base: Importing Scenes from 21.72.28 (os_lights_back_switch_din_rail_on_off) device
2020-03-27 12:28:30 UI Base: Adding the following scenes :
2020-03-27 12:28:30 UI Base: 0fc7: 31.24.90 grp: 1 type: CTRL data: 0x03 0x1c 0x01
.
.
.
And a final result of:
2020-03-27 12:25:01 UI Base: Import Scenes Done.
2020-03-27 12:25:04 UI Stack: Compressing Scenes 1/3
2020-03-27 12:25:08 UI Stack: Compressing Scenes 2/3
2020-03-27 12:25:21 UI Stack: Compressing Scenes 3/3
2020-03-27 12:25:28 ERROR Stack: Error in executing stack function, stopping all remaining functions in the group
There are no changes to scenes.yaml and it makes no diff if the file exists, is empty, or not. Permissions as low as 666 and ownership is HA user.
Any suggestions?
Be advised I am still smart as a post about nearly every aspect of HomeAssistant. Am trying to learn but most of my time is consumed by making confusion and mistakes so please don’t hesitate to be as pedantic as your time will allow and thanks in advance.
Q
Again thanx for all the hard work on this interface. I have an issue that I am not sure how to address. I have a number of devices throughout the house, as I have been on this home automation journey for a while a lot of older insteon devices. Some of the devices are very old but most still apparently work. Now however I have a couple of issues. 1. even without the modem connected when any of the switches are turned on/off one set of lights flash on,off, then on. I don’t see any mqtt traffic there is nothing in the logs to reflect the activity so I don’t know who is doing it. I have went through all the db’s for each device but no one seems to have any links. that brings me to 2. each time I try to send a command to any device I get three additional tries (see log) and then a fail.
So below id dis a ‘print_db’ which worked, and then a ‘on’ command which worked but Failed, not sure what that’s about. BTW the light actually went on immediately (like it should)
2020-04-09 13:09:12 INFO Mqtt: MQTT message insteon/command/task b'{ "cmd" : "print_db" }'
2020-04-09 13:09:12 UI Mqtt: Commanding dimmer device 0e.4e.33 (task) cmd=print_db
2020-04-09 13:09:12 UI Base: 0e.4e.33 (task) device database
2020-04-09 13:09:12 UI Base: DeviceDb: (delta None)
0ff7: 0f.e0.a5 grp: 1 type: RESP data: 0xff 0x1f 0x01
0fff: 0f.e0.a5 grp: 1 type: CTRL data: 0x03 0x00 0x01
Unused:
Last:
0fef: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
1 -> ['0f.e0.a5']
2020-04-09 13:09:12 UI Mqtt: Complete
2020-04-09 13:09:43 INFO Mqtt: MQTT message insteon/command/task b'{ "cmd" : "on" }'
2020-04-09 13:09:43 UI Mqtt: Commanding dimmer device 0e.4e.33 (task) cmd=on
2020-04-09 13:09:43 INFO Dimmer: Dimmer 0e.4e.33 cmd: on 255
2020-04-09 13:09:43 DEBUG MsgHistory: Average hops 2.0, using 2
2020-04-09 13:09:43 INFO Protocol: Write message to modem: Std: 0e.4e.33, Type.DIRECT, 11 ff
2020-04-09 13:09:43 DEBUG Protocol: Write bytes to modem: b'\x02b\x0eN3\n\x11\xff'
2020-04-09 13:09:43 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2020-04-09 13:09:43 INFO Protocol: Read 0x62: Std: 0e.4e.33, Type.DIRECT, 11 ff ack: True
2020-04-09 13:09:43 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
2020-04-09 13:09:43 DEBUG StandardCmd: 0e.4e.33 got msg ACK
2020-04-09 13:09:49 WARNING Base: Handler timed out 1 of 3 sent: Std: 0e.4e.33, Type.DIRECT, 11 ff
2020-04-09 13:09:49 DEBUG Base: Increasing max_hops to 3
2020-04-09 13:09:49 INFO Protocol: Write message to modem: Std: 0e.4e.33, Type.DIRECT, 11 ff
2020-04-09 13:09:49 DEBUG Protocol: Write bytes to modem: b'\x02b\x0eN3\x0f\x11\xff'
2020-04-09 13:09:49 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2020-04-09 13:09:49 INFO Protocol: Read 0x62: Std: 0e.4e.33, Type.DIRECT, 11 ff ack: True
2020-04-09 13:09:49 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
2020-04-09 13:09:49 DEBUG StandardCmd: 0e.4e.33 got msg ACK
2020-04-09 13:09:55 WARNING Base: Handler timed out 2 of 3 sent: Std: 0e.4e.33, Type.DIRECT, 11 ff
2020-04-09 13:09:55 DEBUG Base: Increasing max_hops to 3
2020-04-09 13:09:55 INFO Protocol: Write message to modem: Std: 0e.4e.33, Type.DIRECT, 11 ff
2020-04-09 13:09:55 DEBUG Protocol: Write bytes to modem: b'\x02b\x0eN3\x0f\x11\xff'
2020-04-09 13:09:55 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2020-04-09 13:09:55 INFO Protocol: Read 0x62: Std: 0e.4e.33, Type.DIRECT, 11 ff ack: True
2020-04-09 13:09:55 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
2020-04-09 13:09:55 DEBUG StandardCmd: 0e.4e.33 got msg ACK
2020-04-09 13:10:01 WARNING Base: Handler timed out 3 of 3 sent: Std: 0e.4e.33, Type.DIRECT, 11 ff
2020-04-09 13:10:01 DEBUG Base: Increasing max_hops to 3
2020-04-09 13:10:01 INFO Protocol: Write message to modem: Std: 0e.4e.33, Type.DIRECT, 11 ff
2020-04-09 13:10:01 DEBUG Protocol: Write bytes to modem: b'\x02b\x0eN3\x0f\x11\xff'
2020-04-09 13:10:01 DEBUG Serial: Wrote 8 bytes to serial /dev/ttyUSB0
2020-04-09 13:10:01 INFO Protocol: Read 0x62: Std: 0e.4e.33, Type.DIRECT, 11 ff ack: True
2020-04-09 13:10:01 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
2020-04-09 13:10:01 DEBUG StandardCmd: 0e.4e.33 got msg ACK
2020-04-09 13:10:07 WARNING Base: Handler timed out - no more retries (3 sent)
2020-04-09 13:10:07 ERROR Mqtt: Command timed out
Any time I send a MQTT command I get something that in part looks like the above. I can however always read the device db. So I know that it is reachable. On this particular device I was able to establish links both directions (which on some devices is has been impossible). I am not sure what is going on but now that I have lots of time on my hands just trying to iron some HA things out. As stated most of the devices are older but I do have some newer devices and they do the same thing. Just looking for a little of the collective insight from the group. I hope it is something trivial. If anyone has any questions about the system please just ask.
System Overview:
hassio on a Ubuntu 14.04 (server) Unraid VM
MQTT server Docker with Ip, user and pw
USB PLM on a PCIe card passed through to the Ubuntu VM (only)
Insteon devices 25+ various
ThanX again for the help
Michael
I am unable to adjust set the timeout flag of my motion sensor.
Am I doing something wrong?
Sending
insteon/command/4f.94.3b { “cmd” : “set_flags” , “timeout” : “300” }
Get below error
2020-04-25 21:37:03 INFO Mqtt: MQTT message insteon/command/4f.94.3b b’{ “cmd” : “set_flags” , “timeout” : “300” }’
2020-04-25 21:37:03 UI Mqtt: Commanding battery_sensor device 4f.94.3b (motionsenor) cmd=set_flags
2020-04-25 21:37:03 ERROR Mqtt: Unknown command ‘set_flags’ for device type battery_sensor. Valid commands: dict_keys([‘db_add_ctrl_of’, ‘db_add_resp_of’, ‘db_del_ctrl_of’, ‘db_del_resp_of’, ‘print_db’, ‘refresh’, ‘linking’, ‘join’, ‘pair’, ‘get_flags’, ‘get_engine’, ‘get_model’])
Ignore I fixed my own problem.
I upgraded to .72 from .69 and the problem was resolved.
Anyone happen to have an EZrain working?
I have a question about how to use scenes defined via scenes.yaml
I currently have several Insteon scenes that I defined manually before the support for a scenes file was added. From the examples I think it is pretty clear how to duplicate the functionality I have today in a scenes file which will make things much easier to maintain in the future. My question revolves around how to access these scenes within HA. For my current scenes, I define a switch in my ha config file like so:
# Switch that activates insteon scene
- platform: mqtt
name: "Den Lamps Scene MQTT"
command_topic: "insteon/modem/scene"
payload_on: '{ "cmd" : "on", "group" : 24 }'
payload_off: '{ "cmd" : "off", "group" : 24 }'
I then use this switch to turn the scene on and off. However, looking at the documentation for scenes management, it is highly discouraged to assign your own group numbers to modem scenes as they will be assigned automatically so I don’t know what the scene numbers will be. Do I have to look up the scene numbers manually and then update my ha config file for my scene switches or is there another way to do it (possibly using the scene name)?
@TD22057
I’ve been exploring how the scene management works a little further and came across some confusing results. I built a small scene.yaml file that looks like this:
- name: Rec_Room
responders:
- rec_room_lights
- rec_room_slave
controllers:
- rec_room_lights
- rec_room_slave
- modem
- name: Foyer
responders:
- foyer_lamps: 1
- foyer_lamps: 2
- den_overhead: 5
controllers:
- den_overhead: 5
- modem
I then did a restart of insteon mqtt which apparently causes it to process the scenes.yaml file. After insteon-mqtt starts, I look at the scenes.yaml file and it looks like this:
- name: Rec_Room
responders:
- rec_room_lights
- rec_room_slave
controllers:
- rec_room_lights
- rec_room_slave
- modem: 20
- name: Foyer
responders:
- foyer_lamps
- foyer_lamps: 2
- den_overhead: 5
controllers:
- den_overhead: 5
- modem: 20
I was surprised to see a group number of 20 for both of these scenes as I would have expected them to be unique.
I haven’t looked at this in a while since I had a workaround but now I am trying to integrate scenes management into my system and I think I ran into this again. I have the following scene defined in my scenes.yaml file
- name: Foyer
responders:
- foyer_lamps: 1
- foyer_lamps: 2
- den_overhead: 5
controllers:
- den_overhead: 5
- modem: 21
If I run a sync command on foyer_lamps (dry_run) and look at the output I see this
2020-10-16 18:56:44 UI Base: Would Add 0fef: 53.bd.2e grp: 21 type: RESP data: 0xff 0x00 0x01:
2020-10-16 18:56:44 DEBUG CommandSeq: Running command 8 of 8
2020-10-16 18:56:44 UI Base: Would Add 0fe7: 53.bd.2e grp: 21 type: RESP data: 0xff 0x00 0x01:
2020-10-16 18:56:44 UI Mqtt: Sync complete
It looks like the code is going to insert a responder for group 1 twice instead of separate responders for group 1 & 2
This seems allot like the original issue but maybe not.
Edit:
This seems to be an issue with how on/off outlets are defined in the config file.
With this in scenes.yaml
- name: Foyer
responders:
- foyer_lamps: 1
- foyer_lamps: 2
- den_overhead: 5
controllers:
- den_overhead: 5
- modem: 21
If foyer_lamps is defined like this in config.yaml:
# KeypadLinc switches (on/off+scene controller).
keypad_linc_sw:
- 46.59.84: 'foyer_lamps'
The sync output looks like this (which looks correct to me):
2020-10-17 13:28:46 UI Base: Would Add 0fef: 53.bd.2e grp: 21 type: RESP data: 0xff 0x00 0x01:
2020-10-17 13:28:46 DEBUG CommandSeq: Running command 9 of 9
2020-10-17 13:28:46 UI Base: Would Add 0fe7: 53.bd.2e grp: 21 type: RESP data: 0xff 0x00 0x02:
2020-10-17 13:28:46 UI Mqtt: Sync complete
If foyer_lamps is defined like this in config.yaml:
# On/off ouetlets
outlet:
- 46.59.84: 'foyer_lamps'
The sync output looks like this:
2020-10-16 18:56:44 UI Base: Would Add 0fef: 53.bd.2e grp: 21 type: RESP data: 0xff 0x00 0x01:
2020-10-16 18:56:44 DEBUG CommandSeq: Running command 8 of 8
2020-10-16 18:56:44 UI Base: Would Add 0fe7: 53.bd.2e grp: 21 type: RESP data: 0xff 0x00 0x01:
2020-10-16 18:56:44 UI Mqtt: Sync completeI also posted this in the github issues. Not really sure which one is preferred for support. Or maybe something else??
I have some devices that aren’t joining/pairing. They operate fine with other scenes and with my ISY (all external from insteon-mqtt), so I know they are communicating and working. They are all recent model dual band (wired & wireless). For example, I have seen that when I join my gym switch, a dual band 2477S, v.45, the PLM chirps a couple of times. But when I add my study switch, also a 2477S dual band, v.45, nothing happens at all. No chirping, and no responses in node-red. I’m doing all of my joining/pairing in Node Red. Any idea why some devices may not want to add?
Also, probably unrelated, I tried the import_scenes_all and I see a bunch of activity in the log. From the docs, it sounded like this command would also generate a scenes.yaml file, but nothing is happening to my /root/config/scenes.yaml file. Am I missing something?
Looking at the log for insteon-mqtt, when I try to publish a command for my study switch, I get an error:
2020-11-17 08:20:08 INFO Mqtt: MQTT message insteon/command/49.7b.d0 b’{\n “cmd”: “join”\n}’
2020-11-17 08:20:08 ERROR Mqtt: Unknown Insteon device ‘49.7b.d0’
This device works fine from the Universal Devices Admin Console
There are other switches in the house that work fine with insteon-mqtt. I can control the light with mqtt and when I manually operate the switch, it sends the mqtt messages as expected.
I have a second PLM, but it is older. I tried it, and it works exactly the same (same working switches as before, and same non-working switches).
Because this switch works fine manually, and works fine from the ISY Admin console, I really don’t think it is something wrong with the switch. Anyone have any other ideas?
Maybe try the linking procedure again with Insteon-MQTT? I’d also double check the config for Insteon-MQTT to make sure the ID is right, though I’m sure you’ve done that. Generally when I’ve had issues with new devices it was a linking issue. Also do a full refresh on Insteon-MQTT after the linking is done.
Answered in the github issues. I forgot to add the mis-behaving devices in the config.yaml.
I’ve been using this for several years now… thank you @TD22057!
Recently, I was re-reading the documentation and found that you can turn on/off the backlights through MQTT. I created the following 2 automations for a 6-button keypadlinc in a bedroom to limit the amount of light:
- alias: switch backlights on
trigger:
- platform: time
at: '05:45'
action:
- service: mqtt.publish
data_template:
topic: insteon/command/X.X.X
payload: '{ "cmd" : "set_flags", "backlight" : "0x1f" }'
qos: 1
retain: true
- alias: switch backlights off
trigger:
- platform: time
at: '20:00'
action:
- service: mqtt.publish
data_template:
topic: insteon/command/X.X.X
payload: '{ "cmd" : "set_flags", "backlight" : "0x00" }'
qos: 1
retain: true
This has worked great, however once you turn the backlights on again, it appears that all the backlights are on, not just those of the buttons currently “on”. You can see the difference in the 2 pictures at the bottom of this post where the first has all the buttons backlit, and the second only the “on” buttons backlit.
Is there a way to tell the keypadlinc to only turn on the “on” buttons again?
