I am on SmartThings but it should be the same in Hubitat. Cutting out the cloud to cloud connection by eliminating the Hue hub should definitely reduce the response time. Binding may be even faster, but you’ll have to experiment.
So I would not say you don’t need binding. Try it both ways and see which you prefer. I think that binding eliminates the issue with keeping the LED syncd to the bulb state.
I think Eric (H.?) did a video comparison a while back, and bindings were slightly faster than a hub-involved integration. Maybe that was Z-Wave with Z-Wave Association…I can’t remember. But I guess it would be pretty similar either way (I tend to think of Zigbee as faster, if anything, but that’s mostly a general observation of Z-Wave vs. Zigbee motion sensors and less to do with the protocols themselves).
So it will probably be faster; whether it’s noticeable or not, I don’t know. The most odd thing here seems to be that it’s so slow for you now…
Is it not because of the Hue hub? And I just checked, my button delay is on 100ms and “Disable physical on/off delay” is set to No. This video shows the delay that I’m trying to minimize in my bathroom, the other rooms are as slow but they are larger rooms so it feels like a better speed, if that makes sense.
My switches control the bulbs through a webcore piston.
Shoudn’t be, because I’m using one too, and I really can’t imagine it being any faster. I still get a few hundred milliseconds of “delay” with the Inovellis due to the multi-taps (you can disable this if you really want, and then the push will register instantly), but with other automations, like a Lutron Pico with the Fast Pico driver, the lights are usually on before my finger even gets off the device — and there’s even an extra step here compared to Z-Wave (Lutron/ClearConnect to the Lutron Bridge, then that to Hubitat over the LAN and everything as before).
webCoRE is a fairly large app and may take some time to run this automation. I use a small custom app on Hubitat, but you could also try a simple built-in option like Basic Rule, Button Controller (not exactly small but it should still be faster than webCoRE), or Room Lighting (also not exactly small and not as easy to set up), then temporarily pause your piston while you test.
I guess if you’re concerned that the Hue Bridge is the bottleneck, you could also try this: run the On, Off, Set Color, etc. commands on the Hue bulb device directly from its device detail page on Hubitat to see how fast it responds. Or leave Z-Wave out of the picture but all of your other automations in it by running the “Pushed” command (or “Held” or whatever) with the appropriate button number directly from the Inovelli dimmer device detail page, which will create a simulated/digital button even on Hubitat, as if you pressed the paddle, and trigger all your automations — without needing to get the switch itself or anything with Z-Wave involved.
Doing On/Off in hubitat is instant. Doing Push/Hold (managed by webcore) is instant. The delay is only when I physically press the button on the switch. I’m guessing this means it’s Z-Wave?
I guess that leaves it as the most likely culprit. Zigbee is theoretically faster (Z-Wave maxes out at 100 Kpbs but gets cut in half for each hop, and not every device will connect at that speed, depending on distance and other factors), but with the amount of data that gets sent for this kind of event, the difference should be negligible. But there could be other things happening on your hub or Z-Wave network that might make Zigbee different. 
Z-Wave Association and Zigbee Bindings do bypass the hub, so they should be faster for you, though it seems unusual for the hub to be that slow regardless.
This thread is confusing me, but it boils down to this. Order of speed:
I think that’s missing local hub with hue hub, like I have currently.
I think we determined the delay is from switch to hub (the zwave transmission), as the direct control in hubitat is instant with both on/off commands and through push/hold with webcore. I really don’t think hue hub/cloud is adding much time.
Regardless, my blue series came today and I’ll hopefully get a chance to test this and see if I can do anything to remove this delay. I’ll probably just try swapping zwave for zigbee first, then adding bulbs directly to hub, then binding bulbs to switch.
EDIT: Isn’t the hue bridge local?
Is the hue zigbee mesh issue hubitat specific, like would it be as much of an issue in home assistant? I’m currently waiting for skyconnect.
Anyways…
I’m quite hesitant to pair the bulbs directly to Hubitat. I only see this thread: Using Philips Hue bulbs with HE without Hue Bridge - #9 by razorwing - 🛎️ Get Help - Hubitat and there are lots of people cautioning everyone to keep bulbs on the bridge. Is performance still that bad? I will only have hue bulbs, blue switches, and a couple smartthings outlets using zigbee.
ZLL devices do not typically play well in ZHA meshes - this is why most folks keep them separate.
Is that hubitat specific or any non-hue hub? Like, would I experience the potential same issues if I used home assistant with something like zigbee2mqtt?
I know I’m kind of all over the place with this and I won’t know anything until I just test it. I do have home assistant though, I just don’t have a zigbee stick (yet).
I was under the impression that because hue bulbs are zigbee, Blue series switches would be able to control them faster than zwave Red series. The videos posted with them showed response times that would be acceptable to me so I purchased them. I did not know that they had to be bound directly to Hubitat and that that would cause a lot of other issues. If it works better in home assistant I’ll just do that.
Videos are with everything in home assistant using a USB stick and local bridging. It’s FAST.
I know, but that’s also possible with hubitat now. Would it not be the same?
I know there are issues that can arise to the zigbee network on hubitat if you don’t use a hue bridge, is that also on home assistant?
I don’t have Hubitat so I can’t answer that. HA via ZHA works well with hue and blue series both.
Just installed my first Blue switch, I can confirm that it is faster at controlling Hue bulbs, even with Hue bulbs still on the Hue hub.
So you left the Hue bulbs on the Hue hub, paired the Blue switch to hubitat, and still see a noticable difference in response time when controlling the bulbs?
Yes. It’s probably not as fast as if I were to pair the bulbs to Hubitat and bind them to the switch, but in my use case it seems like the Zigbee switch is faster than Zwave, just by switching the switches out. YMMV of course, but there is a noticeable improvement in my case.
Personally, I don’t think an improved response time would be worth moving my Hue bulbs to pair directly to Hubitat. I like to keep the hue bulbs on the hue hub, for a few reasons:
Don’t get me wrong, I love my Hubitat, but for some things it can be work to replicate the full functionality of devices when using them outside of their native ecosystem.
Thanks for the update. I’m definitely going to attempt the “work with existing Hue” setup first since I agree with @NeighborGeek’s reasonings below… I’m pretty sure it’ll be fine. I have a couple INNR bulbs standing by for binding if needed, and even if the non-bound Hue response times are fine, I’ll probably try binding those at some point just to experiment.
This is really great news! I’ve been on the fence but I think I might try the Blue with such great feedback about speed while keeping Hue lights paired to Hue Hub.
Another question – did you find the need to install a bypass? Or you have a neutral wire setup already? Thanks!
P.S. I’m a noob with inovelli so a simple question, if at some point I swap out Hue lights on a circuit by “dumb bulbs” how hard is it to reprogram the inovelli blue to operate as a regular switch? Can it be done directly using the inovelli switch itself, or it’s done via HASS or Hubitat?
