Zigbee 2-1 Switch (On/Off & Dimmer) | Project New Horizon (Blue Series)

So Hot Right Now Projects & Roadmaps
, ,
#465

Get ‘em boys.

image
image1125×596 112 KB

#466

Great posts @BertABCD1234 and @chack - I have a Lutron non-pro bridge integrated with Home Assistant, and I have automations that use pico buttons to turn on/off and dim Hue lights. The on/off action is basically instant, it must be less than 200-300ms of delay, and is actually perceivably faster than the native Hue dimmers (both V1 and V2) connected via the Hue bridge. It’s remarkable how fast the action is considering the chain of events is the pico > Lutron bridge > HA > Hue bridge > bulb in the basement. If I wasn’t able to experience this first hand I would seriously doubt any accounts of “zero delay”.

By contrast, I have Flic buttons, which connect via bluetooth to the flic hub, and the hub connects to the Hue Bridge. Using a flic button to turn on and off the exact same lights, takes what feels like 1-3s of delay. The shortest feels like at least 500-750ms.

I think my question here is, for those of us who already have HA and Hue bridges all set up, whether the Blue series is superior to the Red series at all. Since the Blue series looks like it cannot connect to the Hue Bridge, I’m considering getting the Blue Series to connect to HA via Zigbee USB device, and rather than redo my entire Hue setup I would just use HA automations to control the lights that I want.

#467

@red930 – is there a setup you’d like me to test? I can rig something up (if it’s with HA, I may need some help from the crowd) and take some videos.

Here’s what I have at the office:

I also have some Innr RGBW bulbs.

Happy to take a shot at making some videos for demonstrations. I was planning on making some tutorial videos today and tomorrow anyway :slight_smile:

#468

I said RA2, not RA3? :smiley:

#469

I believe that honor is more appropriately bestowed on Wink. :smiley:

2 Likes
#470

Took a quick video of Smart Bulb Mode using scene control w/SmartThings. Likely this would be the slowest method of using SBM as it’s all processing in the cloud.

Setup:

  • Hue Bulb connected directly to SmartThings hub
  • Inovelli 2-1 connected directly to SmartThings hub
  • Inovelli aux switch connected to the 2-1

Automations:

  • Button 1 Pushed (Tap Up 1x) = Hue Light On to last level
  • Button 1 Held (Tap Down 1x) = Hue Light Off
  • Button 8 Pushed (Config Tap 1x) = Hue Light On to 100%
  • Button 9 Pushed (Config Tap 2x) = Hue Light On to 80%
  • Button 10 Pushed (Config Tap 3x) = Hue Light On to 60%
  • Button 11 Pushed (Config Tap 4x) = Hue Light On to 40%
  • Button 10 Pushed (Config Tap 5x) = Hue Light On to 20%
  • Button 11 Pushed (Config Hold) = Hue Light On to 1%
  • Button 2 Held (Tap Down 2x) = Hue Light On to 100% & Turn Red
  • Button 3 Held (Tap Down 3x) = Hue Light On to 100% & Turn Green
  • Button 4 Held (Tap Down 4x) = Hue Light On to 100% & Turn Blue
  • Button 5 Held (Tap Down 5x) = Hue Light On to 100% & Turn Warm White

Sorry for the heavy breathing – I just ate Mexican lol.

I will work on the quicker setups (bindings) – but I thought it was important to show one of the “slowest” methods first before moving to speed.

I’d say this is pretty quick, but I know we’re working against milliseconds here.

4 Likes
#471

If that’s slow, I want to know how most people perceive time.

2 Likes
#472

If that’s slow, I want to know how most people perceive time.

:rofl: guilty- that’s too slow for me to have my lights feel fully polished. I get it, though- I’m feeling that I’m definitely an outlier.

I actually just took a short clip demonstrating the latency I’m seeing on my setup (and it’s much less than Eric’s!):

[edit: important point that this is using a zigbee switch that doesn’t support multi-tap and, therefore, sends the zigbee signal immediately on the tap (unlike Eric’s that has a default delay for multitaps). This demonstration below contradicts my initial hypothesis more than it supports it: that is, the latency is likely to be imperceptible when on top of the default delay that multi-tap/scene supporting switches have (red series = 700ms).]

This shows 3 (ok 4, ignore the light directly under the nearest lamp) bulbs in frame that are being controlled by a GE Zigbee switch. From left to right:

  1. Upper left: Philips hue with a direct binding to the switch (i.e. the switch sends a signal to the bulb itself)
  2. Middle with the blue electric box: A “dumb” light directly wired to the switch (a perfect control for this experiment)
  3. Right in the foreground lamp: a hue bulb connected through the hue hub (i.e. the zigbee switch sends a command to my home assistant instance, which then relays it to the hue hub, which then relays it to the bulb).
    [ 4) a second hue bulb that is also a direct binding to the switch ]

Results:

you can see (and hear the physical relay in the switch kick on and off) that the direct binding to the hue bulb (left) turn on at EXACTLY the same time as the hardwired bulb (middle). Direct binding is insanely fast- essentially the same as hard wired. The lamp on the right (that relies on HA and the hue hub) turns on slightly after the others. It’s fast for what it’s doing, but still very perceptible. (or is it just me? :upside_down_face:)

Also to note- this is my utility room that also houses my HA server and hue hub so it’s probably best case scenario for that hue bulb on the right- very short path with no zigbee hops. Other lights of mine throughout the house have latency closer to what Eric is demonstrating.

2 Likes
#473

Haha, to each their own for sure. I remember when the 700ms delay was such a hot topic in the community and I thought everyone was insane that was annoyed by it. Then after we implemented some customization to allow instant on, now I literally cannot stand the 700ms delay. I guess you just don’t know what you don’t know and seeing binding is pretty awesome honestly. I didn’t know it could go that fast! I know the other beta testers have been testing it, but I’m new to HA so I haven’t personally tested it and seen it in real life.

I’m looking forward to testing it tonight or tomorrow. I want to be able to do at least 5 bulbs at a time so I need to rig up something tonight to test it. Preferably I want to test it where the bulbs are across the room from the switch.

I have 3x Hue bulbs and 2 Innr bulbs, so hopefully it will work. I may order a couple extra Hue’s to get the full experience.

Ok, off to Lowes!

3 Likes
#474

Looking forward to seeing your results!

#475
  • Product certification ZIGBEE/FCC
    • Estimated Completion Date: November 30, 2021 February 14, 2022 February 28, 2022
    • Status: IN PROGRESS
  • Product certification UL
    • Estimated Completion Date: March 28, 2022

@Eric_Inovelli Any updates on these certifications?

1 Like
#476

They’re so far behind. My inverter I want slipped from February to April to mid June/July timeframe. (UL listing)

1 Like
#477

At least you recognize it!! LOL
If 250ms is a perceptible delay, I feel even some hardwired switches that directly control the load may be “slow”. I’m pretty sure the default delay on an Inovelli Red for scene control is 400ms, and that’s before the switch even sends power to the load. If I drop mine any less than 300ms I can’t click the buttons fast enough to trigger a scene. So if your lights are being processed by the hub and turning on faster than I can double tap a switch… you are in a very good spot my friend!!

I feel like the power of the hardware definitely comes into play when running automations through the hub. I had smartthings and mostly had an increase in speed going local when I moved to Hubitat. I say mostly because of all the random Hubitat slowdowns. Then there was a drastic speed increase using Hubitat for it’s radios and HA for automations. When I moved 100% to HA on a NUC, my zwave devices definitely sped up. Then the SSD crashed on my NUC so I moved HA into a VM on my server running dual xeon processors. I can’t imagine going back to the delays of ST/HE now, I think I’d go insane lol

#478

Whoops, looks like I need to update those. I’m not sure on FCC/IC or ZigBee but last we heard from UL, they are targeting May 20th (yikes).

@Darwyn_Inovelli - I know your likely on a plane right now to the US, but when you get a second, can you let us know (or shoot me a message in Teams) where we’re at with FCC/IC and ZigBee?

700ms :sob:

–

Ok all, just finished building the OSHA approved test rig haha. Now time to figure out how to get HA to work with bindings!

20220407_201356
20220407_2013561920×1440 373 KB

Edit: hit a roadblock trying to figure out binding in ZHA.

1 Like
#479

You’ll have to fully move your switch off of ST and into HA for binding. If you go zigbee2mqtt it’s actually very simple to do binding, right from the GUI. Not sure on ZHA, never tried it there. Be warned though… you probably won’t ever want to put them back on ST afterwards :laughing:

3 Likes
#480

I’m pretty sure the default delay on an Inovelli Red for scene control is 400ms, and that’s before the switch even sends power to the load. If I drop mine any less than 300ms I can’t click the buttons fast enough to trigger a scene.

This is a good point! I admit that I may be fairly off base here altogether in my conclusions about latency. My own test above shows a pretty narrow gap, even. And it’s extremely important to call out that my test was done with a switch that doesn’t support multitaps: the zigbee signal fires immediately on the button press. Those who use scenes often will experience the default delay + the latency shown (and the latter is likely imperceptible vs the default delay)- I’ll edit my previous post to call this out.

Edit: I just tried dropping one of my red dimmer’s “[112-0-50] Physical Button Delay Period” from the default 700ms to 100ms and then 0ms and still seemed to have the exact same latency on a single press for all three settings :thinking: (red switch > HA > hue bridge > hue bulbs)

1 Like
#481

In theory that shouldn’t be possible. Initially the switch was delaying 700ms before sending off it’s command to HA to make sure you weren’t just clicking too slow. So you’ve shaved 700ms from the process just by changing that to 0. For everyday interaction with an object, a 1s response time is perceived by most as “instantaneous”

1 Like
#482

Agreed- I’m assuming something is not quite right on my end as 700ms should be pretty obvious.

#483

Are you on the latest firmware?

#484

I respectfully DISAGREE with that statement. 1s is an extremely noticeable delay and FAR from instantaneous

2 Likes