FYI I’ve pushed 0.6.4 to the master branch on github. This includes a fix for a bug introduced in 0.6.3 that would cause output messages to Insteon devices to be lost if multiple messages were sent in rapid succession (like in a refresh-all). FYI I haven’t been able to get my local docker to work properly so I can’t build/update the hassio files.
Additions
Added on_level flag support for dimmers and KeyPadLinc’s to set the light
level when the on button is pressed ([Issue #70][I70]).
Fixes
Multiple output messages queued to the Insteon devices causes some messages
to be lost ([Issue #86][I86]).
My first post here. A novice. I have HA 0.81.2 working with the current Insteon component using a 2414U PLM. I also have a 2245 Hub2 working with Alexa and the Insteon App. The Hub2 is from my start with Insteon about 2 years ago. The PLM and HA (on a P12B with Hassbian) is recent and I intend it to be the base for some future automations.
Like lizaoreo has posted above I would like to use both the PLM and the HUB2 concurrently. My reasons are:
(1) I have them both. (2) the Hub2/Alexa/Insteon setup has been stable and reliable, (3) Using both avoids a single point of failure at little extra hardware cost. The behaviour of the two is also just as [lizaoreo](https://community.home-assistant.io/u/lizaoreo) described. The PLM side does not see device changes done by the HUB2 side. This is confirmed by the HA Insteon component docs as follows:
You cannot use both Home Assistant and the INSTEON app. If you do, the changes made in the app will not appear in Home Assistant. Changes made in Home Assistant will appear in the app after a period of time, however.
I have checked and the Insteon app does see changes made via HA/PLM, but not the reverse Seems to me the difference in behaviour here has to be a coding/design choice, not a fundamental defect. Both see all Insteon message traffic yet what they do with it is slightly different.
The HomeSeer product has a forum thread on this issue HERE
It seems the 3rd party Insteon plug-in has a configuration option that may provide the desired symmetrical behaviour.
I would like some feedback. Could a config option be added so HA Insteon ?
@Wes: This isn’t a thread for the HA Insteon component - please check the original post if you’re interested in what this thread is about. You should post your questsion over here: Insteon_PLM on Hass.io, Anyone have it working?
@david1: It’s about modularity and features - some of this is explained in the first few posts of the thread. When I started this project, the HA Insteon component didn’t really work and wasn’t being maintained. Rather than build a new one or try to take that one over, I decided to go this route. Having a separate service allows for a lot more control of the Insteon devices, makes it easier to test, and allows it to work with any home automation system. A separate service allows for commands that HA doesn’t know anything about - this tool allows you to create and modify Insteon scenes on the devices, query the device databases, and modify internal Insteon flags that control behavior. In the future, it will able to back up and restore all of the Insteon scenes and allow for restoring devices that fail and are replaced.
Thanks for the reply. It was easier to get HA going for me using the built in Insteon component, but your MQTT may be better for me longer term. Thus the question about the possibility of “symmetrical” two controller operation of an Insteon network using your option.
If it is possible, I think the best argument for doing it is to eliminate a single point of failure. The cost of two controllers is small compared to the cost of 20 or so various Insteon devices.
Somewhat related is the “feature” of gradually polling to correct any “out of sync” conditions caused by lost network messages (noise) or another controller.
Finally, I saw a You-Tube video about weak Insteon protocol security. Listening for ACKs from a linked device but to an unknown controller (rather than a configured other controller) would be a good security check.
@Wes I have created a new thread regarding the Hub and PLM coexisting. Please feel free to add your comments. I would like to start this discussion to see how much interest there is in this feature. I believe you are the second person to request it. Insteon PLM and Hub coexist
FYI - HA 0.84 made a breaking change to the MQTT JSON API. When you update to >= 0.84, you’ll need to change your HA config file for any dimmers that you defined.
Old way:
light:
platform: mqtt_json
...
New way:
light:
platform: mqtt
schema: json
...
I’ll update the docs and example file in the repo later this weekend.
FYI - Version 0.6.5 has been released. This includes initial support for Insteon thermostats, fast on/off messages, and manual mode messages.
Additions
Initial support for Insteon thermostats has been added (thanks @krkeegan).
Support for fast on and off commands and reporting has been added. The on/off mode (normal, fast, instant) is now a command input as well as an output flag in the state templates. This allows double-clicking of switches to be used in automation triggers (thanks @NickWaterton). (Issue #66).
Added support for manual mode state reporting (holding buttons down). Supported by dimmer, keypadlinc, remote, and switch (thanks @NickWaterton). (Issue #104).
New command ‘get_model’ added to the command line tool to retrieve and save the Insteon device cat, sub_cat, and firmware revision (thanks @krkeegan). (Issue #55).
New command ‘join’ added to the command line tool to perform a two-way pairing and refresh to link a device to the modem. This combines the previous linknig and pair command into a single command (thanks @krkeegan). (Issue #97).
New improved NAK error response codes makes it easier to understand errors when the devices can’t communicate (thanks @krkeegan). (Issue #95).
Added a new command line input (get-devices) to get a list of the curren Insteon devices in JSON format. (Issue #84).
Added a new command line input to factory reset the modem.
Fixes
Added better messages when the pair command fails because the modem db is out of date (Issue #69).
Updated docs and example config file because of breaking HomeAssistant MQTT light change for dimmers (Issue #88).
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.json with 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:
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.
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.
@ 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
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!