My actual opinion agrees with yours, but this is one of those stats that has stuck in my head. I came across the article a few weeks back where they polled X number of people. Most perceive 1s as instant. 2s is an acceptable response. Any more than 10s the majority will assume it hasn’t worked. Me personally… I’d cut each of those at least in half.
1 Like
@terrence.bentley - quick update.
Caveat is that there is still a 100ms delay built in bc I still wanted scene control.
We are still working on group bindings and I had some issues when multiple bulbs were used, but we’re working through that.
I didn’t have a control of a hard wired light, but this seemed crazy fast.
2 Likes
In the first few seconds of the video showing just on and off, I find that really, really, really slow response time. It looks like 700ms+, maybe even 1s+.
This is likely Smartthings causing delay through cloud integration, plus the multitap delay.
This level of delay is to be endured, but I would hope to be able to achieve much better when I get the Blue switches.
@terrence.bentley 's video shows near instant response time. This is pretty much how fast my Pico feels when turning on Hue. Keep in mind my integration is Pico > Lutron bridge > HA (running Docker on a my Synology NAS) > Hue bridge > Hue Bulb.
Note that Pico has no multi press capability, and sends a button down and button release event (separately) instantly now with the latest firmware and using the LEAP API.
How fast does the Pico fire the button down versus release? I took a look through the Home Assistant event logs, and found this:
“time_fired”: “2022-04-08T03:22:48.958836+00:00”, <–press
“time_fired”: “2022-04-08T03:22:48.730685+00:00”, <–release
So pressing a button resulted in two events around 120ms apart, and that’s the Pico sending two separate events to the Lutron bridge to HA when it detects the button going down and coming back up.
My HA automations are set to fire on the “down” event.
To make matters more interesting, the distance from the pico to the Lutron bridge is probably 30feet. And the distance from the Hue Hub to the bulb is also 30 feet. Both hubs are wired to switches that are wired to HA.
Dude, watch the video again. From click to change in the light is damn near instant. Watch the toggle in HA vs the bulb.
Edit: Here is a frame where the light is ON and the toggle is still acting on the HA dashboard lol:
1 Like
Oh sorry, I just posted when you posted this new videos.
I’d say this is pretty fast, but slower than @terrence.bentley setup and my pico setup. Still, very very promising!
Could I ask how this is achieved?
And would we be able to achieve the same by binding to a Zigbee hub > HA > Hue Bridge > the bulb?
I feel like my pico experience suggests that using a Blue Switch > Zigbee hub > HA > Hue Bridge > Bulb could be near instant when using a 100ms delay. Could we speed that up even further by giving up multi tap on the paddle, retaining dimming, and only rely on the scene button to change scenes? Or does the dimming function rely on a delay to detect whether it is a press vs dim operation?
1 Like
I’d ask you to watch the video again. From actual trigger to actual action I can’t get more than 1 frame, which is 1/60 of a second (it’s a 60hz video per YouTube) or 16.6 ms. Imperceptible.
2 Likes
We may have to agree to disagree on this one bc I literally can’t tell the difference. I do wear glasses though lol.
Yeah definitely – here’s the setup:
- Home Assistant using a GoControl HUSBZB-1 ZigBee/Z-Wave stick
- Random ZigBee bulb I had laying around the office = Connected Directly to HA
- Inovelli 2-1 Switch = Connected Directly to HA
- Inovelli Aux Switch = Connected Directly to the 2-1
In ZHA, I created a binding of the Inovelli 2-1 to the ZigBee bulb
This part I don’t know – I don’t think this is possible bc the Inovelli switch can’t be paired directly to the Hue bridge, so I don’t think binding is possible if the bulbs are connected via Hue and the switch is connected via the ZigBee stick, but I could be wrong.
Yes definitely – the way the firmware is setup is that you have the ability to configure the delay between multi-taps. You can choose between 0s (instant) and 900ms. If you choose 0s, you will disable multi-taps from the paddle, but you will retain multi-taps from the config/favorites button (there are up to 5 taps available + hold/release) and you will also retain hold/release scenes on the paddle.
In other words, here’s what you will lose if you change the delay to 0s (the ones highlighted in green – the other ones will remain active):
The reason I kept the 100ms delay in there this time was bc I think there was a bug in the firmware that disabled smart bulb mode if the delay was set to 0s (this will be fixed in the next version).
I’ll respond to the comment regarding the newest video showing the very fast, but not (to my eye) instant response:
@kreene1987 - thanks for suggesting looking at this frame by frame, I hadn’t thought of that and is a clever way of trying to track the precise milliseconds of delay.
I counted at least 12 frames between when the finger starts leaving the button and when the light turns on. I can’t be 100% sure the exact frame where the button is depressed so I rely instead on when the finger starts to leave the switch. Here’s what I did:
- I visit the video at the 5s mark here
- I pause the video at the 5s mark, and use “.” to move forward frame by frame as I watch the finger move towards the switch. I go until I see the finger start to lift off the button, then I use “,” to move to the point right before the lift off.
- I count how many “.” presses it takes to see the light turn on. I can count at least 12-13 frames, but I think the reality is closer to 19 frames+ from the moment the switch is pressed. When you frame by frame you can see the finger has time to retract and form almost a fist before the light turns on.
Here’s a screenshot of the finger on the button:
And the screenshot of the hand retracting, this is the exact frame before the light turns on, and this is 12 frames from the top screenshot when the finger is starting to move away from the switch:
12-15frames on a 60Hz video is 200-250ms of delay. Which is fast, but not instant. And I’m pretty sure the delay is higher than that when I listen to the click vs seeing the light turn on. It’s much harder to tell when moving back frame by frame when the exact moment the button is clicked, but I am certain that the minimum is 12-15frames, and probably closer to 19-20 frames (which is near 320ms). I won’t bore you with how I determined the 20frames, which is when I think I see the top button moving by about 1px. I am also 100% certain my pico setup and I’m pretty certain @terrence.bentley setup is faster, without needing to do frame by frame counting.
I’m not trying to be pedantic, I am very good at spotting visual timing delays down to 200ms ranges. I understand many users cannot and may consider the video to be instant, and I do agree it’s very good. The definition of “near instant” is also going to vary from user to user. I am telling you with conviction that there are smart implementations out there are that are faster than depicted by the video, and also so that anyone pursuing “instant” response can know that a smart switch has in practice turned on a smart bulb faster than depicted in the video.
PS. I would not use the toggle in HA dashboard to determine when HA detects the event.
In HA, go to Developer Tools > Events and start to record the exact events. The UI toggle is much slower than the actual event detection by HA. For me the UI toggle can be 500ms or more behind the actual event.
Edit: I don’t want this to seem like I’m trying to to take away from how good the switch looks to perform. I, and I am sure everyone else, really appreciate @Eric_Inovelli’s responsiveness, passion and willingness to really engage with us for this project. Just look at the videos he’s making and the lengths he’s going to test these setups and respond to inquiries. Cheers and thank you.
2 Likes
I’ll say this… The human eye can indeed register delays as short as 13ms. So it’s possible that some will perceive anything faster than 13ms as “slow”.
Now don’t forget, there is a built-in 100ms delay that’s programmable and on. So if you’re saying 200-250ms, the switch is pausing for 100ms of that before doing anything at all. This is by design for multi-tap and can be disabled if a user doesn’t want it. So realistically that 200ms is really only 100ms.
Now I’m not a frequency expert, but from my understanding Lutron uses a frequency down in the RF range somewhere while Zigbee is in the 2.4ghz range. The higher frequency should transmit signal significantly faster. And since binding is sending the command direct from switch to bulb and bypassing the hub, I would expect any Zigbee binded switch/bulb combo to be faster than a Pico remote.
If I would’ve known my video would be under this much scrutiny, I would’ve gotten a manicure 
@red930 no offence taken, I promise. I actually am humbled that people are taking the time out to analyze data, make suggestions and push back. It’s what makes our products the best in market.
Guarantee you won’t see this passion from both sides at one of the big companies product development!
This would be amazing, and probably get the switch to near instant on/off for all intents and purposes. Even with 0s delay and no multi taps we’d be able to do on, off, dim up, dim down, and 6 scene selections.
If the switch is in “switch” mode instead of dimmer mode, and 0s delay is activated, would you be able to get:
tap on
tap off
hold on
hold off
config button - 5 taps and hold/release
When in HA, do you see distinct events for each of the above in the switch vs dimmer modes?
This would result in 8 scene possibilities with 0s delay in switch mode. And 6 scene possibilities in dimmer mode with 0s delay (assuming config btn hold can trigger a scene).
On another note, does the switch fire it’s “On” and “Off” event when the button is pressed or when it is released? Or does it fire a separate “press” and “release” event for each button press?
I didn’t realize you could hit period lol. I was sliding the slider.
I count 13.
Yeah exactly – I will take another video once we get the next round of firmware (just as a side note for others who are following along – we are able to submit to ZigBee for certification with the current firmware… we just cannot add new features, but we are able to fix bugs).
Actually, you get a bit more scene selections (NOTE: This applies in Dimmer or On/Off mode):
- 1-5 Taps on the config button = 5 scenes
- Hold Down & Release on the config button = 2 scenes
- Tap Up/Down on the paddle = 2 scenes
- Hold Down & Release Up/Down on the paddle = 4 scenes
So total of 13 scenes w/0s enabled (21 w/0s disabled).
I’m assuming so – I’ll verify shortly. I see this in SmartThings so I’m assuming it’s available in HA. I saw it when I was monitoring my SmartThings button presses in Home Assistant, so I’m assuming HA picks it up.
@EricM_Inovelli – can you answer this part:
@red930 please correct me if I’m wrong, but if you’re asking if you can join the switch to Home assistant and then control the bulb via the Hue bridge also integrated with Home Assistant, the answer should be yes (you’d just use scenes).
Binding as I understand it is used to control another device directly, so rather than binding the switch to the hub it’s really just joining it. You’d ideally bind the switch directly to the bulb, though that hasn’t happened to my knowledge with Hue bulbs yet, this thread obviously has more info around that.
If those Hue bulbs are on the Hue Bridge, then no this would not be possible. The Hue Bridge is essentially creating it’s own self-contained Zigbee network and you can’t bind across networks. Now if the Hue bulbs are on zigbee2mqtt or ZHA or whatever you use for your Zigbee network, then I would assume binding switch to bulb should work no problem.
Right, I believe the original question used the word binding in error as it called out binding the switch to the hub (joining it via ZHA/zigbee2mqtt, etc for HA) and then controlling the Hue bulb(s) joined via the Hue bridge. That would be doable via automations, etc and that’s what I meant to clarify.
As you stated though, direct binding from the switch to the Hue bulb requires them to be on the same network, etc.
2 Likes
For those of you testing these switches with Aqara sensors paired directly to them in your network, could you chime in if you’ve had any dropouts? Also, could you mention if you’re using ZHA or zigbee2mqtt? Aqara doesn’t typically play nice with rebuilding routes, but have any of you noticed if your sensors have changed which repeater they talk with?
This is a good reminder – I have them paired via SmartThings and they never used the switch as a repeater (and there was no way to force it). They are pretty far from the hub, but connected directly to it and I’ve never had any problems with them (use the button every night and it works great).
I’ll try using Home Assistant now and move the leak sensor across the house to see if I can force it somehow.
I believe @chack has been using ZHA, but I’ll let him chime in regarding if this is true and whether or not he’s seeing any dropouts.
I’ll report back tonight once I have mine setup and we can monitor it for the next 30 days or so.
2 Likes
My experience with Aqara sensors on zigbee2mqtt is that it’s probably best to put them on their own network. I struggled to keep them connected and was constantly having drop-offs. Ultimately I ended up grabbing a second coordinator and spun up a second instance of z2m using a different zigbee channel. I connected only my Aqara and Ikea devices to this second network and they’re finally rock solid. It’s actually made my Ikea blinds much more reliable as well which is a bonus. I’ve found even if these sensors aren’t routing through an incompatible device, even having that device on the network seems to make them drop off.
1 Like
I only have Ikea repeaters on network currently, I just don’t have enough of them yet haha. Curious to know how well the Aqara are playing with Ikea+Inovelli repeaters.