New Insteon PLM modem integration option via MQTT

Share your Projects!
141

@parkercat Interesting idea. I think it’s possible - but it will require changes to the library. Insteon devices have basically two ways for a device to change. 1) if a button is pressed and 2) when the device responds to a scene. So I can add a “reason” tag or something like similar that could be added to the json payload to track the difference between a button press or scene response. It should also be possible to have an optional input reason field in the MQTT payload which could also be passed through and show up in the output state message. That would add a 3rd reason category which is somewhat user set’able since whatever reason you pass in via the MQTT could show up in the state change.

I think that would allow your automations to respond differently depending on the context by setting the reason field when sending commands and checking it in automations to decide whether to respond or not.

If you think that sounds ok, I’ll open a github issue to track this as an enhancement.

142

Your first solution – “reason” being scene or button – would easily solve my current situation.

Your other idea about a pass-through “reason” being supplied with the trigger would provide a great deal of flexibility – for example, I have a few lights that are controlled by 3 KeypadLinc buttons. In my old system I had an Insteon scene that controlled the light and all the buttons, which I’ve somewhat replicated in HA/insteon-mqtt (*). But to do it entirely from HA, an automation could watch the buttons, sending its name to the light as the reason. Then another automation could watch the light, and update all the buttons except the originator. There are other ways to do this, of course, but it does seem pretty flexible.

(*) Keypadlinc button lights in Insteon scenes are pretty unreliable in my setup, so in the past I’ve had re-sync scripts to update all the button lights for each keypad on a timer. This is one of the use cases for this “reason” functionality: in HA, such a script actually kicks off other automations, which is not desirable.

143

OK - enhancement ticket created: https://github.com/TD22057/insteon-mqtt/issues/138

1 Like
144

@parkercat. See the github issue for an update:

If anyone wants to help test the reason field, I’ve added an initial cut for the Switch device and it appears to be working. I still need to add support for the other devices and add docs and tests. These updates are available on the ‘reason’ branch in github.

Changes include:

  • Added output reason field to the json templating for the state messages.
  • Added reason inputs to on(), off(), set(), and scene() commands on the device.
  • Default reasons are:
    • ‘device’ : when a button is pressed (or the device triggers the state change)
    • ‘scene’ : when the device is a responder to a scene trigger
    • ‘command’ : when the state changes from a direct on/off command
    • ‘refresh’ : when the state is reported from a refresh call
  • Added option reason input field to inbound MQTT on/off and scene commands. This can be set by adding “reason” = “text” to the json packet or using “-r text” on the command line. This reason overrides the default reasons above.

So you can add {{reason}} to the state template to see the reason in the output state MQTT message. Then you can pass input reasons in via MQTT for customization or just use the standard reasons shown above in automation processing.

145

Sweet! I’ll play around with this tomorrow.

146

@TD22057 OK… I can confirm that the Insteon-MQTT side of things seems to be working fine. Sample config snippet that I used for insteon-mqtt’s config.yaml:

state_topic: 'insteon/{{address}}/state'
state_payload:  >
    { "state" : "{{on_str.upper()}}", "reason" : "{{reason}}" }
on_off_topic: 'insteon/{{address}}/set'
on_off_payload: '{ "cmd" : "{{json.state.lower()}}" }'

For those of my Insteon switches that are actually lights, something like the following is working well:

light:  
  - platform: mqtt
      schema: json
      name: "Patio Sconces"
      state_topic: "insteon/22.a4.5b/state"
      command_topic: "insteon/22.a4.5b/set"
      json_attributes_topic: "insteon/22.a4.5b/state"

The “reason” shows up as an attribute on the light.patio_sconces entity due to the “json_attributes_topic” option. This is usable from automations, accomplishing my original request. With a proper on_off_payload config I was also able to publish a custom reason to on/off commands and have it echoed back and show up in an attribute (though see below). So yeah, I’d say what you implemented is working fine. Thanks!

There are a couple of sticking points, though:

  1. HomeAssistant’s MQTT Switch object does not natively support “schema: json” – it’s expecting a raw payload as the state (which you can get around with the “value_template” config), and publishing a raw payload as the command (which supposedly you can also override but I have not had success today). It does support the json_attributes_topic. Ideally, in future the MQTT Switch component will gain full JSON support, but in the interim it might be less disruptive if Insteon-MQTT could publish two state topics that can be separately specified, at least for switches: one that could be used for the primary state, and one that could contain all manner of attributes; example:

     attributes_topic:  'insteon/{{address}}/state'
 attributes_payload:  >
     { "state" : "{{on_str.upper()}}", "reason" : "{{reason}}", "mode" : "{{mode}}" }
 state_topic: 'insteon/{{address}}/rawstate'
 state_payload: 'on_str.upper()'

Or have the two state topics called ‘state’ and ‘raw_state’. Or something. Clearly this issue can be worked around on the HA side (if I can figure out the right syntax to configure the Switch object’s commands) but it’s something to consider. I don’t relish adding the correct magic sauce to every single Insteon device in my config, even those for which I don’t have a need for reason.

  1. The other sticking point is that if I tell Insteon-MQTT to expect an input reason on the on_off_payload, it fails to parse the command if the json dict lacks the “reason” entry. Is there a way to make it optional? Realistically I think the easiest way to use a custom reason will be sending raw MQTT messages anyway.

Again, thanks for the work and for the early preview. This is a very promising development!

147

@parkercat I don’t think there is a need for that. See this post here - it’s look at the fast attribute the logic is identical to using reason. Use the state_value_template to pull out the json command attribute for HA. The rest of the json data is still there and can be used in automations or anything else using payload_json.

For the 2nd item, reason is already a fully optional field inside insteon-mqtt so I’m assuming you mean it failed in template resolution. If you put reason in the config.yaml template input, it must exist or the template will fail - you have to adjust the template logic to make it optional. See the default dimmer mqtt inputs in config.yaml for an example of how to do this.

ps: It might be easier to post questions/comments/test results in the github issue: https://github.com/TD22057/insteon-mqtt/issues/138

148

Aha, yes, I see… there’s a few smart ideas in those pointers. Thanks, I’ll give those a shot. I’ll report back over on GitHub – it’ll probably be a couple of days.

149

@TD22057 thanks for 0.6.8!
Is there a repo for the reason branch on hub.docker.com? I think that function would help with how I’m trying to use a keypadlinc button for my garage door. The button controls an iolinc relay but it also indicates whether the door is open(button lit) or closed(button not lit), so I run into a loop when I try to keep the button in sync with the door position. Or is there another way to turn a keypadlinc button light on/off without actually causing the button change state?

150

Nope - you’ll have to build it yourself, wait until it’s fully tested and delivered, or switch to not using hassio/docker.

151

Did this addon disappear? I’m stuck on: 1. Install the Local Insteon MQTT addon through the hass.io addon store.

  • If you do not see the ‘Local Add-ons’ repository or the Insteon MQTT add-on, click the refresh button in the top right corner on the Hass.io Add-ons page, and it should show up.

The addon does not show. Even after a reboot.

152

Hello all, I am trying to get off the ground with home automation using home-assistant and need some clarity regarding the use of the “td22057/aarch64-insteon-mqtt” container. First, I need to know proper direction (docker or no) and if yes, setup parameters to pass to the container. I have spent quite a bit of time looking for the correct path but I haven’t made enough progress.

I am using a board from FriendlyARM - the H5 based NanoPi NEO Core2-LTS, Armbian as the platform along with the included (via softy menu) Docker implementation. I want to use Home Assistant, node red, Insteon lighting devices, keypads and of course the USB PLM, 1-wire (via I2C host adapter) for temperature and some I/0, direct GPIO, and other device types as well. It appears there is some benefit to using docker to help limit propagation of problems between parts of the system. Of course, I understand there are limits to how effective docker can be in this regard.

I am an occasional user of Linux but my knowledge of docker is only conceptual. Adding the additional complexity of docker can’t be at the cost of many more weeks of not getting to the task at hand - that being home automation. I recognize the need to invest some time but the well is only so deep…

Of course, finding a recently updated “td22057/aarch64-insteon-mqtt” container is encouraging. I read comments that indicate that there is support for light controls, keypads, and scenes. These are the basics that I need. There are also containers for most of the other things I need. So, Docker would appear to be a reasonable option. To that end, I am trying to adapt instructions found here https://www.reddit.com/r/homeassistant/comments/895iw6/my_home_assistant_setup_rpi_3b_docker_compose/ . Since I am not using RPI some things need to be changed to reflect my hardware. I have made my way through some of that. The key question is if Docker <-> insteon via MQTT is viable. The activity in this thread suggest that TD22057’s project is but comments near the end make me wonder if docker is going to create more problems for me.

Assuming docker is viable for me, I understand that compose (according to the link above) can be used to streamline docker workings, providing a means to coordinate much of the ins, outs, whens, etc of container activity. What I need and haven’t yet found is the configuration data I would need to pass to the aarch64-insteon-mqtt container in the docker-compose.yaml file. All I have at the moment is:

insteon_mqtt:
container_name: aarch64-insteon-mqtt
image: td22057/aarch64-insteon-mqtt

First, I need to know proper direction (docker or no) and second, setup parameters to pass to the container. Then I expect I need to add some commands to coordinate which other modules must start before / after as well as error handling but that can come later.

I should also add that Armbian has added both Docker and Home Assistant to their Softy menu recently. Armbian documentation pages miss Home Assistant but it is there in the menu. I assume that the HA install is not Docker’d but at this stage I am pretty cluless about Docker so I don’t know how to tell.

Any help would be appreciated.

Q

153

@quanta AFAIK, what you’re looking at are not general docker containers - they are Hass.io plugins (which are docker containers). I’m the author and I don’t run HA using Hass.io - I just install it in a virtualenv (or a conda env) and run it directly so my support for Hass.io is pretty limited and mostly relies on others. If you’re willing to just install it (w/o a docker container), the quickstart instructions should get you up and running with it.

154

Thanks for the quick response TD22057. Using the directions at the reddit link, I was able to get homeassistant to load and run:

docker-compose pull using image: homeassistant/aarch64-homeassistant

docker-compose up -d homeassistant

I went to the About page and get the info below:
System Health
arch aarch64
dev false
docker true
hassio false
os_name Linux
python_version 3.7.3
timezone America/New_York
version 0.93.0b2
virtualenv false
Lovelace

So it looks like I am at least somewhat aligned with your approach. I don’t know about conda.

I will try to wade through the thread for insights. I know I need to get HA properly configured because right now it is just an empty shell. To do that have to get clarity on how docker influences the tutorials.

Also can’t get NodeRed to work in Docker. That is for another thread though.

Thanks again.

Q

155

Hi,
First I want to thank Ted and everyone involved with this great Insteon MQTT bridge. I have been using Insteon for quite a while but I am new to Hass and YAML files. I have my dimmers working and can update my Keypadlinc entities in Hass but I cannot control the button states. It’s likely I don’t have them set up correctly in the configuration.yaml file.

Here is what I have in the configuration.yaml file:

switch:
  - platform: mqtt
#    schema: json
    name: "Stair Keypad_1"
    state_topic: "insteon/0a.d3.6c/state/1"
    command_topic: "insteon/0a.d3.6c/set/1"
#    json_attributes_topic: "insteon/0a.d3.6c/state/1"

  - platform: mqtt
#    schema: json
    name: "Stair Keypad_2"
    state_topic: "insteon/0a.d3.6c/state/2"
    command_topic: "insteon/0a.d3.6c/set/2"
#    json_attributes_topic: "insteon/0a.d3.6c/state/2"

Here is a manual button press which updates Hass properly:

May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO Protocol: Read 0x50: Std: 0a.d3.6c Type.ALL_LINK_BROADCAST grp: 02 cmd: 13 00
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Protocol: Setting next write time: 1558623966.556967
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG MsgHistory: Received 1 hops, total 8 for 8 entries
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO Broadcast: Handling all link broadcast for 0a.d3.6c 'stair'
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO KeypadLinc: KeypadLinc 0a.d3.6c broadcast grp: 2 on: False mode: normal
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO KeypadLinc: Setting device 0a.d3.6c (stair) grp=2 on=0 normal
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO KeypadLinc: MQTT received button press 0a.d3.6c (stair) = btn 2 at 0 normal
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Mqtt: MQTT publish insteon/0a.d3.6c/state/2 OFF qos=1 ret=1
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Base: Found 0 responders in group 2
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Base: Group 2 -> []
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Mqtt: MQTT writing
May 23 08:06:06 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO Protocol: Read 0x50: Std: 0a.d3.6c Type.ALL_LINK_CLEANUP grp: 02 cmd: 13 02
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Protocol: Setting next write time: 1558623966.648430
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG MsgHistory: Received 1 hops, total 9 for 9 entries
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO Protocol: Read 0x50: Std: 0a.d3.6c Type.ALL_LINK_CLEANUP grp: 02 cmd: 13 02
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Protocol: Setting next write time: 1558623966.935667
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG MsgHistory: Received 1 hops, total 10 for 10 entries
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO Broadcast: Handling all link broadcast for 0a.d3.6c 'stair'
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO KeypadLinc: KeypadLinc 0a.d3.6c broadcast grp: 2 on: False mode: normal
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO KeypadLinc: Setting device 0a.d3.6c (stair) grp=2 on=0 normal
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 INFO KeypadLinc: MQTT received button press 0a.d3.6c (stair) = btn 2 at 0 normal
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Mqtt: MQTT publish insteon/0a.d3.6c/state/2 OFF qos=1 ret=1
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Base: Found 0 responders in group 2
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Base: Group 2 -> []
May 23 08:06:07 hassbian insteon-mqtt[10395]: 2019-05-23 08:06:06 DEBUG Mqtt: MQTT writing

Here is an attempt to control button 2 of a i1 Keypadlinc:

May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 INFO KeypadLinc: KeypadLinc btn 2 message insteon/0a.d3.6c/set/2 b'OFF'
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 DEBUG MsgTemplate: Input template render: '{ "cmd" : "off" }'
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 INFO KeypadLinc: KeypadLinc btn 2 input command: {'cmd': 'off'}
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 INFO KeypadLinc: KeypadLinc 0a.d3.6c cmd: off
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 INFO KeypadLinc: KeypadLinc setting LED 2 to False
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 DEBUG MsgHistory: Average hops 1.0, using 1
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 INFO Protocol: Write message to modem: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 01 09 00 00 00 00 00 00 00 00 00 00 00 00
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 DEBUG Protocol: Write bytes to modem: b'\x02b\n\xd3l\x15.\x00\x01\t\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc8'
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 INFO Protocol: Read 0x62: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 ack: True 01 09 00 00 00 00 00 00 00 00 00 00 00 c8
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
May 23 07:29:38 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:38 DEBUG StandardCmd: 0a.d3.6c got msg ACK
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 WARNING Base: Handler timed out 1 of 3 sent: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 01 09 00 00 00 00 00 00 00 00 00 00 00 00
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 DEBUG Base: Increasing max_hops to 3
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 INFO Protocol: Write message to modem: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 01 09 00 00 00 00 00 00 00 00 00 00 00 00
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 DEBUG Protocol: Write bytes to modem: b'\x02b\n\xd3l\x1f.\x00\x01\t\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc8'
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 INFO Protocol: Read 0x62: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 ack: True 01 09 00 00 00 00 00 00 00 00 00 00 00 c8
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
May 23 07:29:44 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:44 DEBUG StandardCmd: 0a.d3.6c got msg ACK
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 WARNING Base: Handler timed out 2 of 3 sent: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 01 09 00 00 00 00 00 00 00 00 00 00 00 00
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 DEBUG Base: Increasing max_hops to 3
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 INFO Protocol: Write message to modem: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 01 09 00 00 00 00 00 00 00 00 00 00 00 00
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 DEBUG Protocol: Write bytes to modem: b'\x02b\n\xd3l\x1f.\x00\x01\t\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc8'
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 INFO Protocol: Read 0x62: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 ack: True 01 09 00 00 00 00 00 00 00 00 00 00 00 c8
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
May 23 07:29:50 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:50 DEBUG StandardCmd: 0a.d3.6c got msg ACK
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 WARNING Base: Handler timed out 3 of 3 sent: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 01 09 00 00 00 00 00 00 00 00 00 00 00 00
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 DEBUG Base: Increasing max_hops to 3
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 INFO Protocol: Write message to modem: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 01 09 00 00 00 00 00 00 00 00 00 00 00 00
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 DEBUG Protocol: Write bytes to modem: b'\x02b\n\xd3l\x1f.\x00\x01\t\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc8'
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 DEBUG Serial: Wrote 22 bytes to serial /dev/ttyUSB0
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 INFO Protocol: Read 0x62: Ext: 0a.d3.6c, Type.DIRECT ext, 2e 00 ack: True 01 09 00 00 00 00 00 00 00 00 00 00 00 c8
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 DEBUG Protocol: Passing msg to write handler: StandardCmd handler
May 23 07:29:56 hassbian insteon-mqtt[10395]: 2019-05-23 07:29:56 DEBUG StandardCmd: 0a.d3.6c got msg ACK
May 23 07:30:02 hassbian insteon-mqtt[10395]: 2019-05-23 07:30:02 WARNING Base: Handler timed out - no more retries (3 sent)

I realize my keypadlincs are “vintage” and use the i1 protocol.

Thanks,
Patrick

156

Your config looks ok to me. It’s clearly sending the messages to the keypad but it doesn’t look like the keypad is doing anything with them or it isn’t replying with the expected message with the result. I don’t own any i1 devices so it’s hard for me to test anything. As far as I can see, the programmers guide doesn’t say anything about older devices being different than newer ones for that command.

Did you get a successful pairing? Try running the command line tool using the print-db command for the keypadlinc and the modem and make sure that the device and modem have group 2-8 links configured. If those don’t exist, it won’t report state updates. If the don’t exist, run the pair command on the keypadlinc to create them.

157

Hello, reading through the post I noticed this might not work with HUB V2. Is this still the case? Also using this add on would I be able to triger my insteon scenes on/off. (using hassio group turns the lights one by one, which is no good)

158

@fxcoolby Correct - the hub doesn’t provide the functionality needed to implement the features that insteon-mqtt provides. Unless Insteon changes that, it won’t be supported. And yes - you can create and trigger scenes using it. Just assign the scene as the mqtt topic on the switch (see the default config.yaml file for examples) .

159

To add a little bit of insight on the 2245 Hub…
A little more than a year ago, I cloned and modified this code to work for a 2245 Hub.
It worked “fairly” well, but did have some annoyances that in the end were due to the way Insteon architect-ed the 2245 and the software that runs with it. Every month or two, I would find a device not showing its state correctly in HA, and in most cases I could see from the debug logs that the 2245 was overwriting the read buffer that you have to use to extract out received Insteon messages.

My 2245 has since died (a couple of months ago), so i bought a USB serial PLM and things are much better now :slight_smile:

1 Like
160

Thank you so much for your insight. I am very new to HA, used to use stringify, but they are discontinuing hence I am exploring HA. I can achieve everything using HA node red and Insteon component with the exception of turning on and off the scenes locally. People suggest grouping the entities together but that will comes with the popcorn effect where every light takes its turn to turn on or off rather than all of them come on at the same time. Hopefully, they include the scenes in the Insteon component in the future.