I have a fairly large Insteon setup with around 35 switches and 15 keypads.
Before I started using Home Assistant keeping the keypads in sync was fairly simple. I created a Scene for every light and added the keypad buttons to the lights they control. Turning the light on or off from the light or any keypad would control the scene and update all of the keypads. This works great but means that you must always control lights with by the scene and never control the light directly.
Now that I am using Home Assistant if I only use the Scenes (switches in HA) everything works but I can’t dim the lights. If I control the light (light in HA) then I can dim the light but the keypads are not updated and end up out of sync. The same thing happens if I create a Scene in HA with a light in it.
My first thought was to create 2 automations (on and off) for each light that updates the scene. The problem with this is that it won’t work with a dimmed light. If I turn the Scene on/off it will do the same to the light taking it to 100% or 0%. The solution for that would be to make a Scene for the keypad buttons that doesn’t include the light and use 4 automations each to key the light and Scene in sync.
This seems like a lot of work to setup and maintain. Am I missing something? Is there a better way to do this?
I have an isy and I did something similar to your idea. I created a second scene with everything as a responder and omitted the original controller switch. Then created an automation that basically did, is the device not off? Turn the “fix” group on. Is it off, turn the “fix” group off. I added a 2 second delay because I was afraid of the isy all on problem.
It works but for every scene I have, I have a duplicate “fix” scene.
The insteon protocol does not support a group dim command and the isy team would not make it in their API either, so this is my workaround.
Edit: typed on my phone. Please forgive the grammar and spelling.
I’m having a similar issue. I like the insteon hardware, IMO it’s the nicest looking and feeling. But the system seems to have some limitations when used from “outside” like from HASS. I’ve been using a PLM modem and feel like there also currently a lot of limitations w/ the current HASS PLM integration There is some good documentation out there (the MisterHouse insteon pages are excellent and the OpenHab insteon page has links to a lot device programmer manuals). In terms of looking at why devices respond the way they do, I’ve been using the insteon-terminal app to inspect the databases on the items (and OpenHab actually says you should use that to set up certain associations) and some simple python serial calls to send and receive commands to the modem for testing.
I set up a test with 2 decora dimmers and a lamplinc dimmer and hooked them all together with the modem using the set buttons (with the scene level set to full on). I tried the following:
Clicking any on/off button on a dimmer correctly updates all the other devices to full on.
Sending an on/off command via the PLM to a single device will only update that device to any level.
Sending a group on/off command via the PLM correctly updates all the devices to full on.
Holding the up or down button on any device to set the level manually correctly updates all the devices in a slow dim up or down.
Sending the same manual commands via the PLM also works correctly. But those commands say “start manual up/down” and “stop manual up/down” so there is no way to know the exact level being set other than guessing at the timing between the messages.
Sending a group on to level X command via the PLM doesn’t work, it always goes to the saved level for the scene (which is what the docs say it will do).
Sending 3 separate “on to level X” commands as one command block to the PLM (1 command for each device) and that fails. There has to be some send/response time built in for the modem to not timeout. A quick test seems to to be about 1.1 sec to update 3 devices with the same “set to level X”.
I tried every command I can find to try and set the level for all 3 devices to a specific dimmer level in a single command but as far as I can tell, there isn’t any way to say “set the brightness to level X for group Y” (group in this case is the same as scene) and have it work. Maybe someone who’s been hacking insteon longer than the couple of days I’ve been looking at it knows how to do that…
I have an ISY and have been using it for years but I did pick up an insteon hub on sale and played with it a little. I couldn’t get the insteon hub to work with ha.
Do you have 2 automations, one for on and one for off? Is there a way to do this in a single automation? I am mainly concerned about the maintenance.
I have considered playing with AppDaemon to see if I could use a naming scheme instead of defining every rule individually.
Sorry, I meant to say I have one ISY program, not HA automation.
One ISY Program
Two Scenes
Note: I don’t really control the ISY using scenes because everything I use is dimming. Because of that, I only control the the one device that is the “controller” and let the ISY program sync up the changes.
Example:
Scene - Stairs
Controller: Switch 1
Responder: Switch 2
Responder: KeyPad 1 - Button 1
Responder: KeyPad 2 - Button 2
Scene - Fix Stairs
Controller: None
Responder: Switch 2
Responder: KeyPad 1 - Button 1
Responder: KeyPad 2 - Button 2
ISY Program
If Switch 1 is Not Off
– Wait 2 seconds
– Set Scene Fix Stairs On
Else
– Wait 2 seconds
–Set Scene Fix Stairs On
Then I only expose Switch 1 to Alexa and HA (I put everything else, in [HIDE] folders (inside ISY) that I then use in the HA configuration to make hidden)
I can then say, Alexa set the stair lights to 50% (or use the slider inside HA) and the lights will turn on to 50% and the second switch in the virutal 3 way will turn on (note, the leds on it won’t reflect the correct level 50%, but at least it’ll register as on) and the buttons on 2 other keypads will show as on.
I am using ISY 4.6.2. If they ever get 5.0 out of beta, I might be able to fix the 2nd switch not representing the correct dim level later. For now, as long as it registers the on/off, that is good enough.
You could probably write a couple of automations, or something in appdaemon, but I regardless, there is going to be some issue, here or there to contend with.
Insteon, as a protocol, really needs to support a group dim command.
Of course it doesn’t actually have a solution, but it does verify that there really isn’t any way to do this other than having something (HASS/ISY/etc) update switch states for a “group” when one of them changes.
I guess the ISY programs are a little cleaner than all of the HA automations. I was really excited about a way to move all of my logic off of the ISY but this is a case that it makes some sense to keep it there.
At this point, I think I’m going to start developing my own solution. I don’t have an ISY and I’m not super thrilled at the existing offerings. The MisterHouse system seems like a good idea to me. It manages all the links and scenes and can program everything (and backup and restore the db’s). I don’t like having to use insteon-terminal to configure my associations and then manage them with automations in HA. So I’m thinking about writing a stand alone Python process that talks to my Insteon PLM modem and incorporates the db management of the insteon-terminal app and adds scene management and automatic updating of groups. To keep things simple, my initial plan is to put an MQTT interface on it as that would make it easy to add to HA or any other automation system I feel like. It’s going to take awhile to get everything in there, but I think I understand how the commands are working enough to make it happen.
FYI - I’ve made good progress on a new PLM modem integration library. I’ve written it as an Insteon to/from MQTT bridge so changes in the network are reported via MQTT and commands to change things can be sent via MQTT. It will download the local device database and keep that information. So when it sees a broadcast from a device, it looks up the associations in the device database and sends out an MQTT command for every device in the scene which keeps things in sync (working the other direction is also on my to-do list). The overall architecture is working very well - it should be easy to add new devices and the MQTT code is separate from the Insteon code so it could also be integrated into HASS at some point in the future (but it works fine now by defining MQTT sensors and actuators). I still have a decent amount of work to do especially to automatically setting up the links in the devices for things like the smoke bridge and thermostat. I’d still call it prototype code as this point (I’m still writing docs, a developers guide, and test cases) but if you want to try it out or just follow along, the repository is here: https://github.com/TD22057/insteon-mqtt
FYI - I have a fully working solution (for me anyway) using my insteon-mqtt bridge. Since it has the Insteon link database locally, it emits MQTT status message for every device that updates when an insteon scene is triggered. Here is the discussion thread.
I know this is an old post, but I wanted to thank you for the inspiration and ideas, and share how I’m managing this in ISYv5 beta to keep the brightness levels in sync:
I’m having problems with a Switch (from a scene) turning on after being turned off and came across this thread. Thought I’d share how I’m handling your situation in HA. This is for 2 insteon dimmer switches with one as the controller and a KPL button. Works for dim level too. I’d use ISY programs for more complicated things like one KPL button to show >0 lights on for another room and as an all off.
################## Hall Lights Fix ###################################
alias: ‘Dimmer Fix Hall Lights’
trigger:
platform: state
entity_id: light.hall_controller
action: