@tima I don’t use hassio myself but there are a number of people who have been using the plug in since it’s release months ago. As far as I know it’s working fine so give it a try. If you run into any problems, feel free to post here or open a github issue.
The only annoyance with the plugin is that my Ubuntu16 system can’t run the cross compiler to build the container it for some reason. So there is a (usually very) short lag between when new updates are released and lnr0626 updates the plugin. Updating to Ubuntu18 is on my list of to-do items which I hope will allow me to build the plugin myself.
@tima the leak and door sensors work in the Insteon component. Because they are battery operated they do not auto-discover. You need to add them via a device_override to your configuration.yaml. Have a look at the documentation here: Insteon - Home Assistant
Door and Leak sensors are all cat: 0x10. The subcat is device dependent and can be found in your Insteon documentation that came with the device. If you can’t find it let me know and I can probably look it up.
The message is being sent by insteon-mqtt AND seen by HA. However, although I can trigger an automation as you suggested, HA is no longer updating the state of the actual Keypad linc button. I’m assuming HA is expecting the state updates in a specific format; if I add the full json payload, can HA no longer process it?
Please disregard this comment… I’ve found documentation on the MQTT switch component. I will report back on how I got this to work. Your insteon-mqtt is very powerful and flexible; I need to take the time to better understand it!
@Juggler: Correct. The current default config.yaml shows how to customize insteon-mqtt to match HA’s simplest requested syntax. If you want to add fast flags, you’ll need to change the state template in HA to extract the state component. From the MQTT light example in HA, something like this would pull out the “state” json attribute from the insteon-mqtt message.
I managed to get everything working and want to post here so others can benefit. My setup is an 8-button KeypadLinc and FanLinc. I have it configured so that a single press on button 2 will turn the fan on low, a fast-press (double) will turn the fan on medium.
snippet from config.yaml in insteon-mqtt (everything else same as default):
I just recently switched over from ISY to HA and so far so good thanks to @TD22057 ! So far the only thing I can’t do is control my garage door but sounds like 0.6.8 will fix that issue.
I’ve been working on a user interface to insteon-mqtt using a node-red dashboard, it’s a bit rough but working for what I need so far.
I’m running into 1 problem with the set_flags command and was wondering if anyone else has used set_flags to change the backlight value? The command seems to be running without any errors but so far I’ve not been able to successfully change the backlight. I did also try the on_level command to see if I’m using set_flags properly and that did work!
@mikeyrhd Just so there is no misunderstanding - on_level and set_flags are completely different commands. The on_level is for the dimmer level and get’s filtered through the MQTT templates since it’s designed to be used from HA. The low level set_flags backlight is for lights behind the LED’s in the switch and does not go through the templates. They have different payload formats AND must be sent to different topics.
Run a listener (mosquitto_sub -v -t '#') to watch MQTT messages go by. Then run the insteon-mqtt command line tool and tell it to set the backlight level: insteon-mqtt config.yaml set-flags aa.bb.cc backlight=0x11. You’ll see exactly what MQTT message is going out and the correct topic to send it to.
In the future, if you (or anyone else) as issues, post the MQTT topic and payload that was sent - that makes it trivial to debug. Without that, I’m just guessing what the issue might be.
@TD22057, sorry I should have been more clear. I’m running on hassio, here are the specific MQTT messages I’m sending:
Insteon/command/aa.bb.cc { “cmd” : “set_flags”, “backlight” : “0x15” }
Insteon/command/aa.bb.cc { “cmd” : “set_flags”, “on_level” : “0x15” }
I’ve tried this with a keypadlinc and a regular dimmer. On_level works fine but backlight has no effect. In the logs there are no errors it appears to be being executed properly.
I’m not sure if there is a way in hassio to use the command line version but this is the first/only command that I’ve had any issues with.
Thanks
Sorry - it’s a bug introduced in the last refactoring (copy/paste bug). I’ve opened a github ticket: https://github.com/TD22057/insteon-mqtt/issues/136 and will fix it tomorrow and push out a new delivery then.
Version 0.6.8 has been delivered. hass.io images will be up later on. This is a bug fix release.
[0.6.8]
Fixes
Fixed incorrect handling of FanLinc speed change ([Issue #126][I126])
Fixed incorrect exception log statement in Protocol ([Issue #132][I132])
Fixed incorrect scene names in the config loader for IOLinc, Outlet, and
Switch. This prevented customizing the MQTT scene topic and payload for
those devices ([Issue #130][I130])
I’ve been using insteon-mqtt with HA for about 3 months now. I switched over an existing Insteon network with about 25 devices including 7 KeypadLincs. I just followed the basic example in the docs and it’s been working great.
Recently I’ve been wanting to write some more advanced automations that can distinguish between a device’s state changing because it was commanded by HA, vs. a change due to a local button push.
As an example, I’d like to control one of the keypadlinc button lights to be “on” if another device’s brightness is above a threshold or “off” below (automation 1), and toggle the other device if the button is pressed (automation 2). With the naive approach I wind up with a problem where the two automations trigger each other in an infinite loop. I’ve worked around it with state input_boolean devices, delays, etc. but it’s pretty hackish. If automation 2 could trigger only if the button was actually pressed it could break the loop.
Right now my triggers are either watching the HA device’s state or listening to the MQTT state topic. I suspect what I want to do is to alter the MQTT state topic’s payload to include some additional information – maybe what device caused the state change, or maybe a boolean for whether it was insteon-mqtt that commanded the change – but I’m at a loss for how to accomplish this, or even if it’s the right approach.
@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.
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.
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.
@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:
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:
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:
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.
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!
@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.
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.