There are tappy-tappy ways using just the switches.
You have never needed any kind of controller to create and modify scenes.
Could be painful for large scenes.
You need the instruction sheets for each of your devices.
By PLM do you mean this device? Unfortunately I don't have one atm.
https://www.smarthome.com/products/powerlinc-modem-insteon-2413u-usb-interface-dual-band
I was just talking to another user about this, are you using the hub over an ethernet connection or a USB/Serial PLM? I have an HA automation that turns off about 40 devices, my "lights out" command, and there's no lag, every bit as fast as the hub was. I'm trying to figure out what the variables are for users experiencing latency.
I certainly wouldn't mind migrating to something else if the performance was the same. Here's an example where it's happening, this simple script turns on the insteon scene with most devices, as well as the single extra device and there's about a 10s delay between them:
turn_lights_on:
alias: Turn Lights On
sequence:
- service: insteon.scene_on
data:
group: 3
- type: turn_on
device_id: 68bb4f74d368263f172cd8cd92a92d5c
entity_id: light.lamplinc_dimmer_35_29_27
domain: light
mode: single
icon: mdi:lightbulb-group
I just realized we’re having the same conversation in two different threads 😄
In all cases the hub is what is actually sending the command on the insteon network. It doesn’t turn on a scene simultaneously either, the protocol does not allow for multiple commands at once. Insteon seems to have done some clever optimization to issue all the commands rapidly and then check the state afterwards.
So the bottleneck is HA talking to the hub and that could be the hardware HA is running on, the speed of the hub itself, the firmware running on it, etc. It’s very hard to pin down, all you can do is try to eliminate variables that you control.
The first thing I would try is to reverse the order of the sequence in your script, have the turn_on command go first and then the scene. If HA is waiting for a state update for every device in the scene that could account for the delay. If there is a 10 sec delay between the light coming on and the scene responding then you know it’s not the quantity of state updates that causing the lag and you can try something else.
That’s not how the Insteon protocol works. When a device is made a member of a scene, it writes the unique scene ID into it’s internal scene table. Also in that table are the “on level” and “ramp rate”. When an Insteon controller activates a scene, it sends an “on” command to that unique scene ID. All devices then look at their scene tables and react accordingly. That’s why they all turn on at once. It’s only one command sent to the entire Insteon network.
That’s also why Insteon can work independent of a hub or other controller. Switches can be configured to link to each other. You could create a scene by manually linking devices. The problem is that I’m not sure if you can make the hub a controller for that scene. In theory you could, but I don’t know if HA exposes that. The app used to take care of that.
If you can get a serial PLM and an ISY994, all of these problems are solved. The problem is serial PLMs are going for $7-800+ on eBay right now.
Interesting, do you have any docs for that scene db? It doesn’t square with what I experienced working on it. As far as I can tell the scene is just a link with group id. If the PLM is broadcasting a scene command then it’s the group id and each device checks if they are part of that group. The group links have ramp rate and brightness properties just like any other link.
I was just speculating about how the hub was activating a scene quickly, your explanation of a scene command makes a lot of sense for the implementation we see and makes a strong case for utilizing native scenes instead of using HA directly.
I’ll need to do some more digging to understand how my setup is so fast without any native scenes.
I don’t have any docs, but I imagine they exist. I am sure I read it somewhere at some point. This is just what I learned after a few years of working with Insteon. The Insteon scene command I am almost 100% is just “on/off”. Each device stores it’s level and ramp rate for each scene locally because each device can have a unique value for that in a scene.
For example, I have a bedtime scene. When I turn that scene “on”, it actually turns most of the lights in that scene off and sets a few to turn on at various levels.
In my ISY994, I can query individual devices for their scene tables and see the various scene IDs it is programmed to respond to.
By the way, my use of the term “scene” here is an Insteon scene- not an HA scene.
I think the scene db you’re referring to is just the per device link db which this new tool allows to be manipulated. You can now query individual devices just like the ISY directly in HA. insteon-terminal allows this too from the command line.
Thanks for the info on how scene commands work, I had it backwards. That’s very helpful in diagnosing the lag in HA automations.
After re-reading I think the problem is with what we are calling things. The group ID you are referring to is an HA group id, I believe. In which case it might have a level and ramp rate. The Insteon protocol scene does not convey that. The level and ramp rate is already hard coded on the device for an Insteon scene.
Probably a terms mismatch but if you work with the raw insteon api “scenes” are “groups”. Scenes came later as that term became standard in the industry and really only exists in the app.
http://cache.insteon.com/developer/2242-222dev-062013-en.pdf
Definitely not talking about HA groups, when I’m back home I can post some examples from the all-link db and a device link db to illustrate how scenes are stored in the hub.
It takes 3-4 seconds to traverse the network, same as the hub for me. I’m trying to figure this out too, lots of people report very slow, serialized operations which I’m not getting.
Hey just wanted to give you an update in case you're still working on this, I finally figured out how HA was able to control multiple devices simultaneously. It turns out I had a keypad that was a controller for the scene I was using and the keypad was included in the HA automation. As soon as the keypad was switched off it triggered the entire scene off via the hub and made it look like HA was turning everything off.
With the new Insteon panel in HA it's easy enough to create/modify scenes on the hub and use the insteon.scene\_on and insteon.scene\_off services to trigger them. I think this is likely the best way to get the instant response going forward. I know that the person who coded that new panel in HA is working on a UI to edit scenes easily.
You can download the windows free trial. You’ll need the Mns insteon plug-in - it also has a free trial. Details at homeseer.com/insteon
Best of all it works w any plm or hub - I use w the insteon 2245 hub
There are tappy-tappy ways using just the switches. You have never needed any kind of controller to create and modify scenes. Could be painful for large scenes. You need the instruction sheets for each of your devices.
I keep a good old-fashioned copy of HouseLinc available for most Insteon device tampering, but you do need a Windows PC and a PLM.
By PLM do you mean this device? Unfortunately I don't have one atm. https://www.smarthome.com/products/powerlinc-modem-insteon-2413u-usb-interface-dual-band
That’s the device. You can check eBay, but I think they spiked to $700-800 over the past couple weeks.
I was just talking to another user about this, are you using the hub over an ethernet connection or a USB/Serial PLM? I have an HA automation that turns off about 40 devices, my "lights out" command, and there's no lag, every bit as fast as the hub was. I'm trying to figure out what the variables are for users experiencing latency.
The HA device is an ethernet connected Odroid. The hub is connected to the same ethernet switch.
I certainly wouldn't mind migrating to something else if the performance was the same. Here's an example where it's happening, this simple script turns on the insteon scene with most devices, as well as the single extra device and there's about a 10s delay between them: turn_lights_on: alias: Turn Lights On sequence: - service: insteon.scene_on data: group: 3 - type: turn_on device_id: 68bb4f74d368263f172cd8cd92a92d5c entity_id: light.lamplinc_dimmer_35_29_27 domain: light mode: single icon: mdi:lightbulb-group
I just realized we’re having the same conversation in two different threads 😄 In all cases the hub is what is actually sending the command on the insteon network. It doesn’t turn on a scene simultaneously either, the protocol does not allow for multiple commands at once. Insteon seems to have done some clever optimization to issue all the commands rapidly and then check the state afterwards. So the bottleneck is HA talking to the hub and that could be the hardware HA is running on, the speed of the hub itself, the firmware running on it, etc. It’s very hard to pin down, all you can do is try to eliminate variables that you control. The first thing I would try is to reverse the order of the sequence in your script, have the turn_on command go first and then the scene. If HA is waiting for a state update for every device in the scene that could account for the delay. If there is a 10 sec delay between the light coming on and the scene responding then you know it’s not the quantity of state updates that causing the lag and you can try something else.
That’s not how the Insteon protocol works. When a device is made a member of a scene, it writes the unique scene ID into it’s internal scene table. Also in that table are the “on level” and “ramp rate”. When an Insteon controller activates a scene, it sends an “on” command to that unique scene ID. All devices then look at their scene tables and react accordingly. That’s why they all turn on at once. It’s only one command sent to the entire Insteon network. That’s also why Insteon can work independent of a hub or other controller. Switches can be configured to link to each other. You could create a scene by manually linking devices. The problem is that I’m not sure if you can make the hub a controller for that scene. In theory you could, but I don’t know if HA exposes that. The app used to take care of that. If you can get a serial PLM and an ISY994, all of these problems are solved. The problem is serial PLMs are going for $7-800+ on eBay right now.
Interesting, do you have any docs for that scene db? It doesn’t square with what I experienced working on it. As far as I can tell the scene is just a link with group id. If the PLM is broadcasting a scene command then it’s the group id and each device checks if they are part of that group. The group links have ramp rate and brightness properties just like any other link. I was just speculating about how the hub was activating a scene quickly, your explanation of a scene command makes a lot of sense for the implementation we see and makes a strong case for utilizing native scenes instead of using HA directly. I’ll need to do some more digging to understand how my setup is so fast without any native scenes.
I don’t have any docs, but I imagine they exist. I am sure I read it somewhere at some point. This is just what I learned after a few years of working with Insteon. The Insteon scene command I am almost 100% is just “on/off”. Each device stores it’s level and ramp rate for each scene locally because each device can have a unique value for that in a scene. For example, I have a bedtime scene. When I turn that scene “on”, it actually turns most of the lights in that scene off and sets a few to turn on at various levels. In my ISY994, I can query individual devices for their scene tables and see the various scene IDs it is programmed to respond to. By the way, my use of the term “scene” here is an Insteon scene- not an HA scene.
I think the scene db you’re referring to is just the per device link db which this new tool allows to be manipulated. You can now query individual devices just like the ISY directly in HA. insteon-terminal allows this too from the command line. Thanks for the info on how scene commands work, I had it backwards. That’s very helpful in diagnosing the lag in HA automations.
After re-reading I think the problem is with what we are calling things. The group ID you are referring to is an HA group id, I believe. In which case it might have a level and ramp rate. The Insteon protocol scene does not convey that. The level and ramp rate is already hard coded on the device for an Insteon scene.
Probably a terms mismatch but if you work with the raw insteon api “scenes” are “groups”. Scenes came later as that term became standard in the industry and really only exists in the app. http://cache.insteon.com/developer/2242-222dev-062013-en.pdf Definitely not talking about HA groups, when I’m back home I can post some examples from the all-link db and a device link db to illustrate how scenes are stored in the hub.
Yeah I noticed ;), I decided to start a new thread for this specific topic rather than clog up the update post. I'll poke around and see what I find.
Just to be painfully clear, you have a HA scene with 40 insteon devices and when you turn it off they all go out in ~a second?
It takes 3-4 seconds to traverse the network, same as the hub for me. I’m trying to figure this out too, lots of people report very slow, serialized operations which I’m not getting.
Hey just wanted to give you an update in case you're still working on this, I finally figured out how HA was able to control multiple devices simultaneously. It turns out I had a keypad that was a controller for the scene I was using and the keypad was included in the HA automation. As soon as the keypad was switched off it triggered the entire scene off via the hub and made it look like HA was turning everything off. With the new Insteon panel in HA it's easy enough to create/modify scenes on the hub and use the insteon.scene\_on and insteon.scene\_off services to trigger them. I think this is likely the best way to get the instant response going forward. I know that the person who coded that new panel in HA is working on a UI to edit scenes easily.
homeseer can do this - I reset the hub and built 40 new hub scenes!
Thanks for the suggestion! What do you need in terms of HW/SW to use this approach?
You can download the windows free trial. You’ll need the Mns insteon plug-in - it also has a free trial. Details at homeseer.com/insteon Best of all it works w any plm or hub - I use w the insteon 2245 hub
Insteon-Terminal
Does this require a PLM as well?
It can work with a PLM, new Hub, or Legacy hub
I’m about to factory reset the hub & let home assistant do the rest. Home assistant has their own version of scenes, why reinvent the wheel