It’s not necessary to specify the switch domain element imported from ISY in either automation – once all the devices are off, the switch is updated to off (as you can confirm if you don’t hide it with a customization), and once even one device is turned on, the switch element (corresponding to the ISY scene) is set to state “on”.
Actually, it only takes one automation per group of switches - you can use the homeassistant.turn_on service to set brightness to 0, which updates the state to off:
Is the brightness reflected on the secondary switches? I use the paddle switches and there is a vertical row of LEDS that light up that reflect the current on level. That is the one thing that is out of sync on my ISY only approach.
Yup! It works like a charm. For dimmer switches, anyways. For switchlinc devices, I use two programs, since you can’t pass brightness data to a switch.
Just to clarify, for dimmer switches, like the “2477d” you use one program, and for the toggle only switches, the “2477s” is what you use a 2 program solution for?
I would really, really like to duplicate this over on the ISY itself, but until they get their 5.0 release stable, I don’t think you can, in a program, set the brightness or on level of one device to that of another. 5.0 is not stable at the moment and at the rate they are going, it’ll be another year before it is stable.
I might have to implement this solution. And then, start looking at zwave alternatives so I can ditch the ISY.
works to detect when the first switch (the only one that you would leave un-hidden in HA) changes state, and adjusts the brightness of all the other switches (and therefore their indicator pips) in the same scene. I have multiple n-way INSTEON dimmer setups in my home, and this has worked great to keep all their indicators in sync. In HA, I simply hide all the non-load-bearing switches in the scene, together with the switch that’s imported from ISY to represent the scene, and the only remaining switch that it visible works to control the whole scene.
For Switchlinc 2477S devices, where dimming is not possible, they show up in HA as switches instead of as lights. Therefore, the automation programs that I wrote for the multiple-dimmer-scene won’t work (since you can’t pass brightness data to a switch in HA). For those, I use this pair of automations:
- alias: 'Indicator Fix Garage On'
trigger:
platform: state
entity_id: switch.garage_lights_1_by_side_yard
to: 'on'
action:
service: homeassistant.turn_on
entity_id:
- switch.garage_lights
- alias: 'Indicator Fix Garage Off'
trigger:
platform: state
entity_id: switch.garage_lights_1_by_side_yard
to: 'off'
action:
service: homeassistant.turn_off
entity_id:
- switch.garage_lights
And then I hide the non-load bearing switch (in this case, switch.garage_lights) and the scene-representing switch imported from ISY.
I’m guessing it would work with the keypads as the non-load bearing devices such as the 2334-222 (8 button) and the 2334-232 (6 button). It looks like I’ll be busy this weekend writing a bunch of automations.
Now to figure out the best way to get my fans with the fanlinc (2475f) working correctly in HA with the 2334-232 as the controller.
I can confirm it does work with the keypads – the example I posted for my garage lights uses one 2477S (switch.garage_lights_1_by_side_yard) and one 2334-232, where the top and bottom buttons are, collectively, one switch (switch.garage_lights). I believe that there are some additional switches associated with the keypad (in HA, each of the four middle buttons of the 2334-232 is imported as a switch, and each scene that separately controls the illumination of each of those four keypad buttons is also imported, as a different switch), but I think the principle of the automation should be applicable across those devices.
Ah, well, I’ll have to play around because my 2334-222 buttons are also a controller for scenes with a 2477D (dimming). I need to verify I entered everything correctly, but my first shot worked at updating the secondary non-load 2477D but it didn’t turn on the button for the 2334-222. It might be I didn’t enter the entity correctly or something.
Ok, so it looks like only the main button on a KPL can be controlled with a direct command. I will have to put all the secondary buttons in their own scene and send an on/off to that scene to get the secondary KPL buttons to stay in sync…
Edit: So what I did was go back to what I was doing earlier, but only for KPL secondary buttons. Those are all handled in ISY with a program and scenes. I used your program for my 2 different 3 ways to keep the dim levels in sync with the primary.
I think, with 5.0, if it is ever stabilized would allow us to put all this logic in the ISY. I’ll revisit when it is released.
With a little sober reflection, I realized that two-program automation solution for switches is unnecessary – instead of exposing the load-bearing switch and hiding both the non-load-bearing switches and the scene of which they are all controllers, I hide all the switches and expose the scene. Since there’s no lights involved, there never can be a brightness level sent (my keypad is the switch-style, not the dimmer-style), so just using the ISY scene is the simplest and fastest solution for that n-way arrangement.
Did it start working for you with v38? I am having some issues after upgrading to v38. I see this in my log:
17-02-21 13:07:57 ERROR (MainThread) [homeassistant.core] Invalid service data for light.turn_on: expected int for dictionary value @ data[‘brightness’]. Got ‘’
I confirmed I still have an entity ‘light.kitchen_lights’ and it has a brightness attribute. Is the attributes not making it across in the to_state property of the trigger?
Sorry to Necro this old thread but was wondering if anyone got this all dialed in.
The issue I’m having is that if I control the ISY scene in Home Assistant, everything works fine BUT I can’t dim. If I control the load, that also had a KPL button in it and try to send turn the lights on to say 50%, when Home Assistant turns on the KPL button to match the states, it also turns the load on to 100%.
It seems that this code works well if you only have switches OR lights but not a mix. Has anyone gotten this figured out?
So – playing around with this some more, I decided I didn’t like HA sending a second command every time I controlled that light (via HA, ISY, Alexa, or–dun, dun, dun–the physical switches. I decided to move things back to the ISY (using 5.0.13 beta):
Using some inspiration from this post:
For this sample scene, I have a light controlled physically controlled by a 6-button keypad’s main output, a slave “paddle” dimmer as a 3-way switch, and a button on an 8-button keypad upstairs that also controls the scene and shows the status.
To keep things in sync across the ISY, HA, Alexa, and the physical switches:
State variable to hold the brightness value. In this example it’s s.First_Floor_Hall_Dim_Level.
A program that follows the switch with the load and keeps the variable up to date:
A program that watches the variable compared to the slave device–if it doesn’t match, it waits 2 seconds in case the scene was controlled (if the scene was controlled, then it should sync up in a moment and cancel the program). If after 2 seconds, the scene hasn’t updated–update the slave devices.
Since I’m using one of the non-“controllable” buttons on a 3rd keypadlinc, I have a scene with just the button as a responder. When this is called by the program with a %, it will either go on or off.
My only concern with a 2 program approach is, is there any race conditions between the program in step 2 and step 3?
If the scene is adjusted, do we know that the program in step 2 will trigger before step 3? How would it handle local dimming, wait a second, then dim some more.
These types of scenarios are what makes me feel the ISY as a program platform is severely limited, and the Insteon protocol.
There will be a bit of a race between the two when controlled locally by one of the switches, since the direct Insteon commands will be trying to update the other devices in the scene; hence the 2 sec delay. That 2 sec delay is variable in my head… A balance between getting out of the way of the direct Insteon commands and how long you’re willing to accept as a delay in updating switches that are usually across the room.
That being said, so far I haven’t seen any negative impacts. Every time program 1 updates the variable, program 2 is re-fired and the 2 sec timer resets. So if I’m dimming from the ‘slave’ device, it always has 2 seconds for the master to update (should be near instant since it’s a direct insteon command), the isy to see the change, update the state var, and look back at the slave to see if it matches (it should, since it initiated the whole thing).
I agree there are some severe limitations in ISY Automation and Insteon scenes. So far this workaround is working, for me. I don’t know how multiple slave dimmers would keep up. And I’m definitely open to better ideas…
This is the part that interests me and then, in my head, wondered if ISY would do that. I might have to play around a bit. The reset/cancel is exactly what I would like to happen.
I might do some searching over on their forums to refresh/update my understanding of program triggering.
This is the principle I use for a lot of my ISY programs (HVAC timeouts, motion timeouts, ‘group’ keypad linc buttons–e.g. turn on if any light in the group is on):
ISY re-evaluates the conditional (the “IF”) of the program, and if it has changed during the Wait period, the “Then” code won’t continue executing from the line of code following the Wait.
When the conditional changes during Wait, the program reevaluates and restarts.
