You should be using Insteon scenes for any cases where you want to toggle more than 2 or so devices simultaneously. All Insteon scenes show up as switch entities in Hass via the ISY994 integration.
The only thing we could do at the integration level is put a longer delay between each light being told to turn on, but that’s a band-aid. The Insteon protocol doesn’t love a ton of rapid commands being sent in sequence, and you shouldn’t really ever need to due to the excellent scene support.
I agree somewhat and do use scenes where they make sense, but when it comes to home assistant groupings of devices it doesn’t… for example, my kitchen has 7 lights… If i want to turn the kitchen group off in HA i would need to create a scene in ISY also, and then there is conflict with the HA groups toggle… Could the ISU integration not queue or listen for a batch of calls? In my kitchen scenario, its mostly a problem with the alexa integration where when using it to trigger things like “Turn on X room lights” , it usually gets 5 of the total lights, a second request gets the remainder… but in the scene logic, I would need to create scenes for every group of rooms or light/switch cluster in each HA grouping.
@OverloadUT . Could there be anything in the ISY component that would be causing HA to crash that changed between .91 and .99? I upgraded recently and HA crashes all the time, I rebuilt the VM and am now running 100.2 and it still randomly crashes… I’ve stripped my config down to only ISY and AQUALINK… still crashes… I have these errors in the log but nothing close to the time when it crashes.
2019-10-31 16:45:36 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.east_wing is taking over 10 seconds
2019-10-31 16:45:36 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.west_wing_thermostat_operation_mode is taking over 10 seconds
2019-10-31 16:45:36 WARNING (MainThread) [homeassistant.helpers.entity] Update of binary_sensor.upstairs_thermostat_has_leaf is taking over 10 seconds
2019-10-31 17:57:46 WARNING (SyncWorker_3) [urllib3.connectionpool] Connection pool is full, discarding connection: 169.254.169.254
2019-10-31 17:57:46 WARNING (SyncWorker_18) [urllib3.connectionpool] Connection pool is full, discarding connection: 169.254.169.254
2019-10-31 17:57:46 WARNING (SyncWorker_17) [urllib3.connectionpool] Connection pool is full, discarding connection: 169.254.169.254
2019-10-31 22:14:28 ERROR (SyncWorker_3) [homeassistant.components.python_script.gmc.py] Hello lock
2019-10-31 22:14:28 ERROR (SyncWorker_3) [homeassistant.components.python_script.gmc.py] Hello canyon
2019-10-31 22:14:28 ERROR (SyncWorker_4) [homeassistant.components.python_script.gmc.py] Hello lock
2019-10-31 22:14:28 ERROR (SyncWorker_4) [homeassistant.components.python_script.gmc.py] Hello acadia
2019-10-31 22:14:29 WARNING (SyncWorker_18) [homeassistant.components.isy994] Bad ISY Request: http://192.168.254.21:80/rest/nodes/4C%20E6%203A%201/cmd/DOF
2019-10-31 22:14:29 WARNING (SyncWorker_18) [homeassistant.components.isy994] ISY could not turn off node: 4C E6 3A 1
2019-10-31 22:14:30 WARNING (SyncWorker_13) [homeassistant.components.isy994] Bad ISY Request: http://192.168.254.21:80/rest/nodes/4C%20DF%201B%201/cmd/DOF
2019-10-31 22:14:30 WARNING (SyncWorker_13) [homeassistant.components.isy994] ISY could not turn off node: 4C DF 1B 1
I created a few scenes on the ISY and they do show up as switches within HA. However if one of the lights in the ISY scene is on, the state on the switch entity in HA on. So how do I overcome this when I create an automation?
Is the only solution to turn the ISY scene switch in HA off first, then turn it right back on?
You can customize the switch entities with assumed_state: true and it will show up as 2 buttons for on/off instead of a sliding switch. Then you always have the “on” button available to press.
If you’re talking about automations then there is no concern: you can send turn_on and turn_off events to an entity even if they are already on or off.
@OverloadUT If you’re still looking for ISY suggestions, there is one thing that drives me nuts - the fact that you can only turn scenes on and off, but not dim them. Most of my scenes are either groups of lights, lights with multiple dimmers, or lights and KeypadLinc devices. All of these are dimmable as far as the ISY is concerned, but not via. HassIO.
This could probably be fixed on the HassIO side by allowing a way to specify lights that are switch devices are dimmable.
As an example, here is one off my light devices that I have created from an ISY scene of a 3-way switch:
light:
- platform: switch
name: Hall Light Scene
entity_id: switch.hall_light
In HassIO this still shows up as non-dimmable (as expected from the docs at https://www.home-assistant.io/integrations/light.switch/):
| Entity | State | Attributes |
|---|---|---|
| light.hall_light_scene | off | friendly_name: Hall Light Scene supported_features: 0 |
Unfortunately, the assertion that scenes are dimmable in the ISY is not exactly true.
It’s a fundamental limitation of the Insteon protocol that scenes cannot be dimmed to a specific percentage. There is no way to say “Dim scene XYZ to 25%”.
What you can do is issue a single DIM or BRIGHTEN command, which lowers or raises the brightness of all lights in the scene by 3%. This functionality could be added to Home Assistant, but it would be a custom service call as it’s doesn’t match the behavior of anything else in Hass. The scenes would still need to be switch entities, because all of the dimming features in Hass can’t be supported.
I’ve considered adding it, and it wouldn’t be difficult, but the value there is pretty low. You’d have to rapidly click the button to have any useful effect, which is going to cause Insteon protocol congestion, which would be made even worse if you wrote automations to rapidly send dim or brighten commands.
This really is the one shortcoming of the Insteon protocol that I wish didn’t exist.
Edit: The one thing that we could do is make it so that scenes show up as dimmable, and when you try to dim them, the Hass component will issue explicit “Dim to %” commands to each individual device in the scene. The problem here is that it encourages bad behavior and will not always work consistently due to the issues when trying to issue commands to devices in rapid succession.
I agree I wish it were possible but for the reasons Greg stated I don’t think it’s feasible to add to Home Assistant. However, there might be some options you can implement to achieve the same effect for simple 3-way switch setups (e.g. https://www.insteon.com/support-knowledgebase/2016/8/15/installing-multi-way-circuits).
Since only the one switch is actually connected to a load (the light), you really only need to control that one switch. I’ll call that switch the “primary” and the other(s) “secondary”. In my setup I only expose the “primary” to Home Assistant instead of the scene. The downside of this is that the LEDs on the “secondary” won’t follow the LEDs on the “primary” when you make changes from Home Assistant. You can choose to ignore that the LEDs on the “secondary” are wrong but I’m a bit O.C.D so that doesn’t work for me.
Option 1: Simply turn off the LEDs on the “secondary”. In ISY set the backlight to 0% and ignore the fact that the “level” of the “secondary” is wrong because it ultimately doesn’t matter if you don’t see it.
Option 2: I like having the feedback of the LEDs at each location so I decided Option 1 wasn’t good enough. I ended up with a solution that is a bit complex but has been shown to work.
To try to simplify this discussion I’ll use my Kitchen Light 3-way as an example. In ISY I have dimmers “Kitchen Light” and “Kitchen Light (Secondary)” and the scene (which is irrelevant for this).
HIDDEN folder that is hidden from HA using the “ignore_string” option provided by the ISY integration.'Kitchen Light' Status is not '$KitchenLightValue %'$KitchenLightValue = 'Kitchen Light' Status 'HIDDEN / Kitchen Light (Secondary)' Status is not '$KitchenLightValue %'Wait 1 secondSet 'HIDDEN / Kitchen Light (Secondary)' On '$KitchenLightValue %'I’ve found that the 1 second wait really helps make it more stable and a 1 second delay in the secondary updating is certainly acceptable to me. Also, for good measure, I have both programs set to run when the ISY starts up.
This pattern has worked very well for me. I even use a similar setup for ensuring the KeypadLinc associated with my FanLinc stay in sync when I use HA to control the FanLinc. There are several nuances that are slightly different about that setup but the concept of controlling the FanLinc directly from HA and having the ISY sync up the KeypadLinc after is the same. (If anyone is interested in the Keypad/FanLinc programs let me know and I can detail those too).
(For all of this I should note I’m on ISY 5.0.15 firmware. I wanted to mention it in case there is a feature difference between our firmware versions that would cause you problems)
I probably could have done this automation purely in HA, but I liked the idea of hiding the complex details in the ISY so my HA configuration stays simpler. The ISY is certainly capable and given that it has direct visibility over the Insteon network, it is probably more stable to handle it this way.
I hope this helps.
I think the real issue is that it makes the UI inconsistent. I can define a scene to look like a light like I did above, but when I put that light into lovelace I can only turn it on and off, not dim or brighten it. It comes down to what used to be referred to as “the WAF” (Wife Approval Factor) in the old Usenet automate groups. 
I would like to be able to avoid doing this with programs in the ISY, as I have run into issues with race conditions trying to do this for KPLs in the past. While it isn’t directly a lighting issue, I got into a situation at one point where one of my ceiling fan motors was cycling on and off due to a program updating a KPL caused a different program to trigger. Doing the same thing with a scene resolved the issue since it is all handled at the Insteon level. Most of my scenes involve KPLs, typically with the light being controlled by a FanLinc or Micro Dimmer, and the KPL just being a visual indication of the light. There are also multiple cases of KPL buttons that are controllers and/or indicators for lights that you can’t see from where the KPL is located, typically for my outdoor lights.
Let me think about this for a bit and see if there is a better option. I’m looking at using the IOS HassIO app as a replacement for MobilLinc on my phones and tablets. However, if I can’t do something as simple as dim a light in a scene, that may be a show stopper (and yes, I realize that “simple” is relative and that there are limitations in the protocol, but the user shouldn’t have to know that). MobiLinc for example gives me the same dim/brighten buttons on a scene that it does on the raw device.
@bradleywehmeier I have had enough trouble with FanLincs and KPLs that I would love to see your programs for keeping those in sync. Even using scenes they sometimes lose sync.
If all you want is dim/brighten buttons in the Hass UI, you could do that if we add the service call to call dim and brighten, and you’d just configure Lovelace with buttons to do the dim/bright. But they would still be switches rather than lights in Hass, as you will still not be able to dim to a target %.
I definitely want to make this better, but even the most elegant solution I can think of would be a jumbled hacky mess and I worry about its reliability.
With my setup for the standard 3-way, since Home Assistant is directly commanding the dimmer device, you get the full capabilities of the dimmer. Home Assistant sees it as a native light entity with supported_features: 1 so when you tap on the item in Lovelace you get the slider bar so you can set an arbitrary percentage.
For a KeyPadLinc and FanLinc, best example I have is the office. I have a 6 button KPL with the typical 4 fan buttons and the on/off controlling the light. I want the KPL LEDs to sync up with the fan speed. KPL Button A is High and D is Off.
I have 4 scenes defined in ISY for the 4 fan speeds. Each scene is controlled by its corresponding button and the 3 other buttons are responders and turn off when the scene is activated.
Example Scene: ‘Office Fan - High’
For the programs there are 4 programs (you guessed it) one for each speed. The programs react to the changes to the Office Fan speed then trigger the corresponding scene. It doesn’t cause a loop because the if the device is already in the desired state it doesn’t re-trigger.
Example Program: Office Fan - High
'Office Fan' Status is High
Set 'Office Fan - High' On
Note: For Low I couldn’t just say 'Office Fan' Status is Low because the percentage that gets set in 1% off from what “Low” is considered so in stead its 'Office Fan' Status < Medium AND 'Office Fan' Status > Off
For the light, it’s pretty easy since if the light is on to any level, I wanted the On button on KPL to illuminate.
Program: “Office Light”
'Office Fan Light' Status > Off
Set 'Office KPL' On
Set 'Office KPL' Off
Then for Home Assistant, hide the KPL and scenes, and have Home Assistant directly control the 2 FanLinc entities (which show up as native light and fan entities in Home Assistant). So from Lovelace you can set the fan to the 4 speeds, and the light to any percentage. Once Home Assistant sets the FanLinc, the appropriate ISY program will update the KPL to match.
@OverloadUT from what I’ve read it sounds like this has been fixed. Is it in the native HA code. Meaning I don’t have to do anything special other than update HA to get the fix? Because my ISY scenes are still taking 5 seconds to execute when called from HA.
I have started playing with converting some of the scenes to just use the lights in Hass and have programs set the other devices as @bradleywehmeier mentioned. I’m going to try doing the same thing with my some of my KPLs tomorrow if I can carve out some time to play.
Next I need to figure out if there is a way to have a callback for dim/bright on lights in the Floorplan Loverlace card w/o adding two buttons to every light…
FWIW, using the raw light devices and adding code to deal with keeping the scene elements in sync is what I’m going with for now. My biggest concern is that I’m going to have to remember to change one or more programs every time I change a scene, but that shouldn’t happen too often as I don’t plan on adding many more devices in the house.
@altersis @OverloadUT (or anyone else), I have 0.103.0 installed. Is this fix supposed to be in my version? It still takes about 5 seconds when I use HA to send an on/off command to a scene on my ISY.
My ISY scenes appear in HA as switches btw. Is that how you’re supposed to control an ISY scene from HA?
Hi there. Although a bit awkward, the best way to handle ISY scenes in HASS is via switches, due to the fact that ISY scenes can be ON or OFF, so what you see is what is supposed to happen. The fix that @OverloadUT is referring to in your citation, is about receiving an event in Home Assistant from the ISY, not about improving the speed in which requests are sent to the ISY. Around the same time, on a parallel PR, a small delay while sending requests was introduced to prevent the ISY from getting too many consecutive requests it cannot handle. The delay is about 1/2 a second, so the five seconds you are referring to sound a bit too much. This leads me into thinking that you may have another type of situation there, can you rule out a network issue?
Are you by any chance using https/ssl to connect to the ISY? Sometimes this can introduce delays.
No, http only. @OverloadUT do you have any suggestions on how I might be able to debug this? Is there a way to “catch” when commands are being received on the ISY?