I entered issue #122 for #1, and it’s been resolved.
To solve #2, I reinstalled the addon with a modified /addons/insteon-mqtt/config.json file. I changed the line
"startup": "services",
to
"startup": "application",
I will open an issue for #4 when I’ll have time to document it.
Thanks
Long time user of Insteon-MQTT. Thank you for all of your work!
I’ve now upgraded to v0.6.7 and am trying to figure out how to get HA to issue/respond to a fast on/off command. A basic example is the following:
- alias: turn livingroom fan on
trigger:
- entity_id: switch.livingroom_keypadlinc_2
from: 'off'
platform: state
to: 'on'
action:
- data:
entity_id: fan.livingroom_fanlinc_fan
speed: low
service: fan.set_speed
For the above automation, when you click on button 2 of the keypad, it sets the fanlinc to speed “low”. I would like to be able to have a fast on command set the speed to “medium”. What would this look like?
Here’s the example from the original github issue for triggering an automation for a fast click. You’ll have to add the fast flag to the output state template obviously. This example says if you see a fast off message for device 4e.d1.d4, then turn off some other entity.
- id: test_fast
trigger:
platform: mqtt
topic: "insteon/4e.d1.d4/state"
condition:
condition: template
value_template: '{{ trigger.payload_json.state == "OFF" and trigger.payload_json.fast == 1 }}'
action:
- service: light.turn_off
entity_id: light.den
Thank you!
@ billchurch - i would be very much interested in the add-on…please keep us posted. I am running a haas.io on a rpi with a ton of insteon switched and sensors. the Insteon component gave me a way to control the switches but not the leak and door sensors. I need to get this integrated…
@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
An example of the device override:
insteon:
port: /dev/ttyUSB0
device_override:
- address: 1a2b3c
cat: 0x10
subcat: 0x08 # Leak Sensor 2852-222
- address: 4d5e6f
cat: 0x10
subcat: 0x09 # Door Sensor 2843-232
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.
I modified the output state template for a KeyPad linc as follows:
keypad_linc:
btn_state_topic: 'insteon/{{address}}/state/{{button}}'
btn_state_payload: >
{ "state" : "{{on_str.upper()}}", "fast" : {{fast}} }
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.
state_value_template: "{{ value_json.state }}"
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):
keypad_linc:
btn_state_topic: 'insteon/{{address}}/state/{{button}}'
btn_state_payload: >
{ "state" : "{{on_str.upper()}}", "fast" : {{fast}} }
snippet from switch.yaml in HA:
- platform: mqtt
name: "livingroom keypadlinc 2"
state_topic: 'insteon/'aa.bb.cc/state/2'
command_topic: 'insteon/aa.bb.cc/set/2'
value_template: "{{ value_json.state }}"
Note that you do need to add the “value_template” to ALL keypadlinc switches defined as mqtt-insteon is now sending all updates as json payloads.
automation from HA:
- alias: turn livingroom fan on low
trigger:
platform: mqtt
topic: "insteon/aa.bb.cc/state/2"
condition:
condition: template
value_template: "{{ trigger.payload_json.state == 'ON' and trigger.payload_json.fast == 0 }}"
action:
- data:
entity_id: fan.livingroom_fanlinc_fan
speed: low
service: fan.set_speed
- alias: turn livingroom fan on medium
trigger:
platform: mqtt
topic: "insteon/aa.bb.cc/state/2"
condition:
condition: template
value_template: "{{ trigger.payload_json.state == 'ON' and trigger.payload_json.fast == 1 }}"
action:
- data:
entity_id: fan.livingroom_fanlinc_fan
speed: medium
service: fan.set_speed
Note that aa.bb.cc is the address of the KeypadLinc, not the FanLinc.
Kudos to @TD22057 for all their great work on Insteon-mqtt!
Hi,
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!
any advice?
thanks =)
@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.
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])
Fixed incorrect set-backlight command parsing ([Issue #136][I136])
Greetings,
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.
Thanks for any insight.
@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.