@fxcoolby - you could use the library of the thread you’re posting in. Insteon-mqtt allows you to trigger scenes as if they were switches.
1 Like
This module is really great. I am having a problem creating a mqtt switch in homeassistant to trigger a virtual scene on my plm.
I copied your code directly from the config.yaml:
switch:
- platform: mqtt
name: “scene #10”
command_topic: “insteon/modem/scene”
payload_on: { “cmd” : “on”, “group” : 10 }
payload_off: { “cmd” : “off”, “group” : 10 }
But I am getting this error and I am too dumb to figure it out:
Invalid config for [switch.mqtt]: value should be a string for dictionary value @ data[‘payload_off’]. Got OrderedDict([(‘cmd’, ‘off’), (‘group’, 10)])
value should be a string for dictionary value @ data[‘payload_on’]. Got OrderedDict([(‘cmd’, ‘on’), (‘group’, 10)]). (See ?, line ?). Please check the docs at https://home-assistant.io/components/switch.mqtt/
Try placing a single quote around the payload entries. I just tried this and it worked:
- platform: mqtt
name: "test 10"
command_topic: "insteon/modem/scene"
payload_on: '{ "cmd" : "on", "group" : 10 }'
payload_off: '{ "cmd" : "off", "group" : 10 }'
I’ll update the sample config file.
That seems to have worked. Thank you so much. I really want to understand this more. Do you have a suggestion for where to read to get a grip on this?
When I trigger that scene on the PLM, it doesn’t update the state of the lights in HA. Any thoughts?
It should if insteon-mqtt has that information. If the modem and device databases are current in insteon-mqtt, it will notify HA of the state change. Be sure the db’s are up to date (run a refresh from the command line on the devices and modem). I’m in the middle of reworking my home network and I’m going to be on vacation for a few weeks so I can’t get to my server right at the moment - I’ll try and test it when everything is connected and I have time but it could be a few weeks.
Ok, I will give that a try. Thank you for all your help.
Thanks for working on this! I’ve finished setting this up yesterday and so far I’m quite happy with the result.
My only remark is that it’s annoying to have to enter the device’s address in multiple files (in insteon_mqtt.yaml and in home assistant). Having a script that automatically read a config file and generates these 2 files would be great (bonus point if it also generate a .items file for OpenHab!). I’ll maybe work on this if I can find some spare cycles…
And is there a way to automatically refresh the device state? I can refresh the state of all my devices at startup but they go out of sync as soon as I use a switch directly, I’m trying to find a way for the switch state to update automatically in the MQTT broker.
If that’s happening, something is wrong. The whole point of insteon-mqtt is to keep them in sync. Debugging it in stages like anything else. Subscribe to the insteon/ topic (mosquitto_sub -v -t ‘insteon/#’) and see if insteon-mqtt is sending out the state updates - you should see all the messages going between HASS and insteon-mqtt. If the messages like OK, then you have a problem in your HASS config such that’s not updating correctly. If not, then you have a problem in insteon-mqtt in either the format of the message (fix that in the config) or that it’s not sending a message. In that case, you need look at the logs and see if the insteon message is coming in when the state changes. If it’s not, then the device isn’t paired to the modem correctly - go back to the docs and read them - devices have to be paired w/ group 1 between the modem and device to receive commands and updates.
Start w/ clicking the device itself and see if updates. Get that to work. Then click the device in HASS and get that to work. Then you can worry about scenes and making sure devices in the scene update properly.
Thanks for the quick reply, I’ve confirmed that the problem is that insteon-mqtt doesn’t receive the update from the hub (a 2242-222). I’ve run the following commands and it doesn’t fix the issue:
insteon-mqtt insteon_mqtt.yaml join 45.e4.69
insteon-mqtt insteon_mqtt.yaml pair 45.e4.69
insteon-mqtt insteon_mqtt.yaml linking -g 1 45.e4.69
insteon-mqtt insteon_mqtt.yaml refresh-all -f
FYI Here’s what I get when I do a refresh on the device I’m testing with (I’m trying to get one switch to work and I’ll work on the rest after that):
bash-4.4# insteon-mqtt insteon_mqtt.yaml refresh -f 45.e4.69
Commanding switch device 45.e4.69 (lumiere bureau) cmd=refresh
Switch 45.e4.69 (lumiere bureau) refresh on=True
Device 45.e4.69 db out of date (got 0 vs 0), refreshing
Entry: 0fff: 26.14.01 grp: 0 type: RESP data: 0xff 0x1c 0x01
Entry: 0ff7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
45.e4.69 database download complete
DeviceDb: (delta 0)
0fff: 26.14.01 grp: 0 type: RESP data: 0xff 0x1c 0x01
Unused:
Last:
0ff7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
Handler timed out 1 of 3 sent: Std: 45.e4.69, Type.DIRECT, 10 00
Device 45.e4.69 received model information, dev_cat: 0x2, sub_cat: 0x2f, firmware: 0x48
Device refreshed
The MQTT server also see all these messages when I do any operation via insteon-mqtt (which confirms that the MQTT connection works well), e.g.:
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Commanding switch device 45.e4.69 (lumiere bureau) cmd=refresh"}
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Switch 45.e4.69 (lumiere bureau) refresh on=True"}
insteon/45.e4.69/state ON
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Device 45.e4.69 db out of date (got 0 vs 0), refreshing"}
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Entry: 0fff: 26.14.01 grp: 0 type: RESP data: 0xff 0x1c 0x01"}
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Entry: 0ff7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)"}
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "45.e4.69 database download complete\nDeviceDb: (delta 0)\n 0fff: 26.14.01 grp: 0 type: RESP data: 0xff 0x1c 0x01\nUnused:\nLast:\n 0ff7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)\nGroupMap\n"}
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Handler timed out 1 of 3 sent: Std: 45.e4.69, Type.DIRECT, 10 00 "}
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Device 45.e4.69 received model information, dev_cat: 0x2, sub_cat: 0x2f, firmware: 0x48 "}
insteon/command/45.e4.69/session/1588210015 {"type": "MESSAGE", "data": "Device refreshed"}
I’ll take another look at the doc tomorrow to see if I’m missing something obvious…
I’ve re-paired my device and it seems to work fine now! Thanks for writing so much documentation btw.
I can use the plm modem and the Hub v2 at the same time?
I have a massive amount of devices (54), and need time to convert everything, maybe both can work in the crossover?
It’s anyway to use the insteon_plm file on HA where automatically record every device to get the work shorter?
I found this new insteon USB RF dongle, anyone has test it with this project? https://www.smarthome.com/insteon-2448a7-portable-usb-adapter.html
The modem it’s fastest than the hub? I know the limitations are due the power like communication protocol so RF in theory (like clear connect) can be instant (almost).
Speed has nothing to do with RF. The modem might be faster than the hub because it’s a direct serial line to the modem instead of an HTTP call to the hub. State updates with the modem are MUCH faster than the hub because there is no need for polling. This library only works with the modem because the hub doesn’t provide notifications that are required to keep everything in sync. I have no idea what will happen if you try and use a hub and modem in the system setup. Things will probably get out of sync and you might see strange behavior. I think someone said the USB device worked for them but I’m not 100% sure.
1 Like
If I understand correctly, you’re currently using the 2245 to control your devices
(using HA, and or Insteon App).
You can use the PLM Modem and the Hub at the same time during the transition.
The only issue you may encounter is if you try to control the same device with both the PLM and the Hub…for example you will run into synchronization issues say when the Hub is used to turn on a switch. That same switch will not report the update to the PLM modem and thus that switch’s state will not be updated using insteon-mqtt. But since you are transitioning this should not be too much of an issue.
You can move a few devices at a time from the Hub to the PLM. You should completely unlink/remove the insteon devices from the Hub once they have been added to the PLM.
Ok, so, if a need to unlink the devices from the hub and link to the PLM I cannot use both at the same time.
It’s possible to register the devices using the address directly on the code and not going one by one, as I said I have the inteon_plm.yaml from the hub and HA with every single device, cat, sub cat and address.
Maybe this can be super clear for you guys but I never worked before with this plm or the code to make it work so, sorry if it’s obvious.
All of this is cos i already spend hours of my life (a lot) programming all the 3w on NodeRed and works but slow slow slow.
Hi,
I’m making progress with my setup and one of the last things I need to setup is my garage door IO Linc… I’ve looked at the issues on the Github repo and it looks like the IO Linc is quite hard to control…
As a reference, it’s working well when using OpenHab with this kind of config in my .items file:
{ insteonplm="41.EF.E2:0x00001A#switch", autoupdate="false" }
I’ve paired the device and it seems to be setup properly in insteon-mqtt:
$ insteon-mqtt insteon_mqtt.yaml pair 41.ef.e2
Commanding io_linc device 41.ef.e2 (bouton porte garage) cmd=pair
Device database is current at delta 19
IOLinc 41.ef.e2 (bouton porte garage) refresh on=True
Device 41.ef.e2 add db already exists for 26.14.01 grp 1 RESP
Device 41.ef.e2 add db already exists for 26.14.01 grp 1 CTRL
Modem add db already exists for 41.ef.e2 grp 1 RESP
IOLinc paired
$ insteon-mqtt insteon_mqtt.yaml refresh 41.ef.e2
Commanding io_linc device 41.ef.e2 (bouton porte garage) cmd=refresh
IOLinc 41.ef.e2 (bouton porte garage) refresh on=True
Device 41.ef.e2 db out of date (got 15 vs 13), refreshing
Entry: 0fff: 26.14.01 grp: 0 type: RESP data: 0x00 0x00 0x00
Entry: 0ff7: 26.14.01 grp: 10 type: RESP data: 0x00 0x00 0x00
Entry: 0fef: 26.14.01 grp: 1 type: CTRL data: 0x03 0x00 0x01
Entry: 0fe7: 26.14.01 grp: 1 type: RESP data: 0x00 0x00 0x01
Entry: 0fdf: 26.14.01 grp: 20 type: RESP data: 0xff 0x00 0x01
Entry: 0fd7: 26.14.01 grp: 21 type: RESP data: 0xff 0x00 0x01
Entry: 0fcf: 26.14.01 grp: 22 type: RESP data: 0xff 0x00 0x01
Entry: 0fc7: 26.14.01 grp: 23 type: RESP data: 0xff 0x00 0x01
Entry: 0fbf: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
41.ef.e2 database download complete
DeviceDb: (delta 15)
0fc7: 26.14.01 grp: 23 type: RESP data: 0xff 0x00 0x01
0fcf: 26.14.01 grp: 22 type: RESP data: 0xff 0x00 0x01
0fd7: 26.14.01 grp: 21 type: RESP data: 0xff 0x00 0x01
0fdf: 26.14.01 grp: 20 type: RESP data: 0xff 0x00 0x01
0fe7: 26.14.01 grp: 1 type: RESP data: 0x00 0x00 0x01
0fef: 26.14.01 grp: 1 type: CTRL data: 0x03 0x00 0x01
0ff7: 26.14.01 grp: 10 type: RESP data: 0x00 0x00 0x00
0fff: 26.14.01 grp: 0 type: RESP data: 0x00 0x00 0x00
Unused:
Last:
0fbf: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
1 -> ['26.14.01']
Looking at this log it seems to be properly linked to the modem on group 1 (both as a responder and controller).
It’s also configured as “momentary C”:
$ insteon-mqtt insteon_mqtt.yaml get-flags 41.ef.e2
Commanding io_linc device 41.ef.e2 (bouton porte garage) cmd=get_flags
Device 41.ef.e2 operating flags: 11011010
Program lock : 0
Transmit LED : 1
Relay linked : 0
Trigger reverse: 1
Relay latching : momentary C
Operation complete
However I just can’t get it to work, I’ve tried sending some packets manually to ‘insteon/41.ef.e2/scene’ but it doesn’t do anything (I’ve tried both the on and off commands as I’ve ‘Trigger reverse: 1’ in my flags) :
mosquitto_pub -t 'insteon/41.ef.e2/scene' -m 'off'
mosquitto_pub -t 'insteon/41.ef.e2/scene' -m 'on'
One thing to note about my setup, my relay is connected directly to the switch poles on my garage door, and I’ve my garage opening button connected to the same switchs in parallel (in other words, the physical switch doesn’t use the IO Linc to control the door). I don’t have any remote to control the IO Linc (I’ve always used OpenHab in the past), so my only way to trigger the relay right now is to use the Insteon app but I had some issues when doing this in the past as it looks like there can only be one connection to the hub (and so using the app would break the OpenHab binding’s connection, or something like that), so I’m not sure on how to test this… I’m using a 2242-222 hub btw.
Fyi the switch is configured like this in insteon_mqtt.yaml:
io_linc:
- 41.ef.e2: 'Bouton porte garage'
It looks like I might want to flip the ‘on_str’ definition to |on_str = ‘on’/‘off’| (rather than ‘off’/‘on’) to reflect the fact that my trigger is reversed but I’m not sure where I should do this (are the variables meant to be configured in insteon_mqtt.yaml?).
Thanks for the awesome work on this.
(please let me know if I should move this to a bug report in your Github repo, I’m not sure if it’s a bug or an user error).
You can have an Insteon device linked to both the PLM and Hub at the same time, but you may run into synchronization issues.
Ok! I’m going to start the experiment and I’ll let you know!