FYI - version 0.6.6 has been released to fix a bug in a Switch component calling sequence.
Fixes
- Fixed incorrect Switch.set() calling sequence. ([Issue #119][I119])
Hello, this is my first post on this forum. I’ve been running this addon for about a week and so far it’s been great! But I do have a few questions/problems. I searched quite a bit but did not find answers to them.
I am running version 0.6.5 of insteon-mqtt on Hassio on a Raspberry Pi 2 B. I use a PLM 2413U I bought last week. My Insteon scenes/links were created long ago using an Insteon Hub 2245-222.
- The hass.io quick-start guide indicates that to upgrade, one simply needs to “replace your
/addons/insteon-mqtt/config.jsonwith the most recent `hassio/config.json”. I did that, restarted Hassio and then I see the prompt to update. But if I click on the Update button, nothing happens. I must be missing a key step? - After a reboot of my Raspberry Pi, insteon-mqtt does not work. The log complains that it can’t access the PLM. Restarting the addon fixes the problem until the next reboot. :
serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: ‘/dev/ttyUSB0’
- To mitigate problem 2, I tried to use an automation to “manually” start the addon shortly after a startup, but that does not work. Here is the automation I tried:
- alias: Start insteon-mqtt on Startup trigger: platform: homeassistant event: start action: - delay: '00:00:10' - service: hassio.addon_start data: addon: "local_insteon_mqtt"
- Minor annoyance: one of my scenes is controlled by a switch that turns on a light and turns off another. If I double-click on the switch, the scene turns on both lights in the scene. But in this case, insteon-mqtt reports the second light as off even though it is on.
That’s all for now! Thanks a lot for this very nice addon!
Sorry - I don’t use hassio so I can’t help you with 1-3. Running under Ubuntu, I use a USB alias to insure that the device path doesn’t move around (which can happen w/ USB). I also have the service set to start after the network is up which seems to work fine.
For #4, please open an issue on github with the sections of the config for those entities and the database records for those items that define the scene and I’ll reproduce it locally and fix it. Double-click is a fast on/off which was just added in 0.6.5 so it could be something with that not triggering the scene properly.
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
1 Like
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.
[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]) -
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.
1 Like