One quick question. . .Does this application support the INSTEON Dual Band 220V 30A Load Controller Normally Closed Relay (part 2477SA2)? If so, how? As a switch?
Yes - it’s a switch. Anything w/ an on/off uses the same switch commands.
Hi,
I would like to try this with my old Hub that has a network PLM. I was wondering two things :
1 - Can I use it with my hub as it is now, with no factory reset? Will it grab the configuration as it exist right now?
2 - Can I still continue to use my Insteon Hub app on my phone alongside this for the time I finish configuring all my stuff in Home Assistant?
Thanks a lot for this great component!
Yes and Yes. I can’t test a hub since I don’t own one but it should work. If you follow the instructions in the repo, it will work along w/ the existing hub. If you change scenes in the hub, you’ll need to send a refresh command (see the docs) to re-download the scene database.
I can confirm it works, I already tried it before getting a reply 
It seems the pair command sometime failed :
ERROR: Modem db updated failed: OutAllLinkUpdate: 42.7e.xx grp: 1 Cmd.ADD_CONTROLLER: ack: False
ERROR: Modem database update failed
But if I do it a couple of time, it get done correctly.
@djf_jeff Can you post that as an issue on the github repo and attach the logs for when the command failed? It’s either because a) your insteon network is flakey, b) the hub is flakey, c) the hub is slow and time it exceeded, or d) ???. If it’s c), I can increase the time outs in the software - not much I can do about the others I think.
@TD22057 I am pretty sure that it is either b or c in my case.
My insteon network is not a problem, never had any issue with it in 5+ years. However, I am seing message in insteon-terminal and I had to increase the timeout in OpenHab before to make it work with my Hub.
The message in insteon-terminal are :
10:06:07.327 [Thread-2] WARN us.pfrommer.insteon.msg.MsgReader - got unknown command code 02
10:48:54.938 [Thread-2] WARN us.pfrommer.insteon.msg.MsgReader - incoming message does not start with 0x02
Never found the root cause of them but I will be honest, they just show up and everything still work as usual.
I will open an issue with the logs and the issue repeat itself again.
Also, one small question. What is the difference between linking and pair?
In the quick start, it mention to run pair and refresh but in the detailed documentation, it also mention linking. Should I do both?
A device has to be linked to/from the modem (scene w/ group 1) to accept commands from the modem and to report state changes to the modem. Normally that’s done by holding the set button on the device, then then modem (and then doing the same in reverse). The link command creates those initial links. The pair command is run after the links are created to create any other links that a device needs. Some devices (fan linc, keypad linc, remotes, etc) have more than one group or broadcast message they support so the pair command creates those links as well. But pair only works if the device is already linked on group 1 or the device won’t accept the remote commands. So when adding a new device, you can do the steps in this linke to set everything up once.
I don’t know how that works w/ the hub. I’d assume the hub is already linked and paired with nay device that it can see. Basically try changing states (click buttons) and see if they’re reported in insteon-mqtt - if they are, then the links are there. Most likely w/ a hub you just need to do a refresh to let insteon-mqtt download the link database for each device one time.
@TD22057 is there a downside to do a linking just to make sure all the links are there?
I have seen in the past that some links were missing when using the Insteon app to do the initial linking. For example, the leak sensor did not have the necessary link to report the heartbeat each day. I needed to do them manually with insteon-terminal.
No - calling pair() will do a refresh (to get the current state and link database) and then only create the links for that device that don’t already exist.
@TD22057 If you don’t mind, I would like to have your guidance on two or three things. I will restart my whole Insteon environment (complete modem reset, factory reset of switches, etc), so I would like to get it correct the first time and not redo that
1 - For scenes, what do you recommend? Doing them in Insteon or directly in Home Assistant?
2 - For 3 way switch (1 with load, 1 with just current), do you recommend to handle that in Home Assistant or still use Insteon to do it (basically a scene that link both switches)?
3 - For Keypad button scenes, currently, I used Insteon scene for them. Can I just have a dummy button that launch nothing except trigger a scene in Home Assistant?
Thanks again for your help, you have giving me a new hope to really integrate Insteon and Home Assistant and leave the OpenHab middleman behind!
@djf_jeff It’s totally up to you. I personally keep insteon scenes in the insteon devices because then they update instantly and if I take down HA for some reason, my lights and scenes still work.
For 3, any insteon button press emits a scene message so you can set that up in HA as a switch and then use it to trigger what ever you want in a HA automation (In theory you could also model it in HA as a binary switch I think but I haven’t tried that).
@TD22057 Thanks a lot. I have now set everything back with my usb PLM and your project! Work like a charm and now integrate Insteon with my zwave, harmony and Google Home perfectly!!
Seriously, is there a place that you accept donation for this project? I would gladly do it and I am sure other people would too!
I have a single toggle mini-remote (model 2342-2). It seems to be working with insteon-mqtt when I set it up under the mini_remote4 section but I think it would be good to have a separate section for these remotes.
Also, there weren’t any examples of Home Assistant setup with a remote so I came up with this using an automation. I’m a HA newbie so there may be a better way to do this.
Anyway, the insteon-mqtt is working well for me, it covers a lot more functionality than is available in the standard HA setup.
- alias: insteon remote
trigger:
platform: mqtt
topic: "insteon/xx.xx.xx/state/1"
action:
- service_template: light.turn_{{ trigger.payload.lower() }}
entity_id:
- light.closet_light
@TD22057 Ok, second question about 3 way. I have linked both device together (so each is responder and controller to the other on group 1) and they work fine when I press the button. However, when I turn them on from Home Assistant, only the one that I turned on get switched on. The other remain off.
Here is my lights config :
-
platform: mqtt_json
name: “Bathroom Main Light”
state_topic: “insteon/48.xx.xx/state”
command_topic: “insteon/48.xx.xx/level”
brightness: true -
platform: mqtt_json
name: “Bathroom Vanity Light”
state_topic: “insteon/48.xx.yy/state”
command_topic: “insteon/48.xx.yy/level”
brightness: true
@djf_jeff That’s the difference between the device and a scene insteon. Clicking the switch triggers a scene and commanding the device changes the device - they are independent. Linking devices doesn’t actually link them - it creates a scene. The device is still an independent entity. If you want trigger the scene from HA, use the scene topic instead of the set topic. Or set up an automation in HA that sets the 2nd device to the same as the first when it changes. Note that triggering a scene includes a dimmer level (it’s programmed in the scene) - there is no easy way to have a dimmer slider control a scene in HA (though there is probably some automation way to do it).
@TD22057 I tried the automation way in Home Assistant but I didn’t like the lag between the two lights.
For now, I linked both switch with an Insteon scene to make them work like a real 3 way. In Home Assistant, I control them separately with the option to toggle both using the group control.
Same for Google Assistant, telling to turn on the bathroom lights turn them both on.
@TD22057 Another question on my side.
I see that in insteon-mqtt, we specify the option for QoS and retain. Personally, I choose qos=2 (so the command is only sent once and confirmed) and to retain message. My mqtt server is on the same host, so I am pretty sure no communication issue can arise.
However, I see that your example of Home Assistant configuration does not specify s QoS and retain option. As I understand, it means that Home Assistant use qos=0 (so whatever happen to the command) and does not retain message. The retain part seems to not be necessary as it seems insteon-mqtt take care of that. I am wondering on the QoS side of thing. Should I need to add qos=2 (and maybe retain=1) to every lights/switchs on the Home Assistant side?
Thanks,
So, I’m running into some weird issues. Some report (I see the MQTT updates and network chatter on the app when running from command line) when pressing the physical switch, some don’t. Seems all can be turned on/off via MQTT commands, at least based on those I’ve tested. The ones that respond on switch presses update the MQTT of state changes, those that don’t do not update since it doesn’t seem to see the state changes. None seem to recognize state changes via the Insteon hub app, Alexa (since it uses the hub), or HomeAssistant currently using the hub.
I’ve not been able to do any commands via the command line (ie, refresh-all, on, off, print_db), they all give me a connection timeout message, and the mosquitto broker show’s a failed connection. Only start command works. Until I set the refresh on start thing to true, it didn’t create files on the server in the data folder.
At the moment I’m about frustrated with it and think I’m going to wipe the Pi I’m using and reset it up. This is all I’ve put on it (set it up just for this), but I’ve tinkered and tweaked so many little things it’s possible I broke something.