Philips Hue are zigbee. For working devices Zigbee2MQTT or Database of Zigbee devices compatible with ZHA, Tasmota, Zigbee2MQTT, deCONZ, ZiGate and ioBroker
well, letās agree people all have their own reason to make choices. I for one never liked the aqara devices for being too fragile and unreliable.
And yes, having a large(r) Zigbee mesh could have its advantages.
I would not however classify the Hue polished interface, reliability and options galore to be solely beginner friendly. On the contrary.
But, I take it, you havenāt tasted those using a Zigbee stick 
And Iād hate to see the efforts in HA to re-create the live scenes we have nowadays in the native Hue settings, which HA simply imports and doesnāt use any HA resource. Just like the groups and zones. No need to do anything in HA, its simply all there.
I simply donāt trust philips. I spent a lot of cash on a starter kit. At that stage lots of 3rd party devices worked with their hub. Then philips put a stop to that. Then they released a new hub and sidelined my older one. What will they take next?
I trust the devs of z2m, but as you say each to his own.
3 Likes
yes, you are right, using a non proprietary solution has many merits. Thatās why I also bought a zigbee stick. Just in case. But in all honesty, and after 3 years of testing, tinkering and what have you, thereās no way that comes close to the current Hue experienceā¦ I didnāt even mention the option to import all in Google Home.
I might have been unlucky, but it feels so clunky to use that z2m interface (not even speaking of the Conbee interface) and backend logic. Maybe its because its way more acceptant of other brands, they cant be as polished.
But we can not blame Signify for being favorable to Signifyā¦
Call me silly, but I also use the Ikea Gateway
Agreed. The reason I chose ZW over Zigbee in the beginning, despite it being slower, is the fact it was on a different frequency. I didnāt want to deal with WiFi saturation and interference. ZW is great and there are tons of cool devices for it.
@petro, yes, some Hue products require the Bridge to work, but your standard light bulb type lights which I chose for table lamps and torchieres are Zigbee standard and work fine with ZHA. The Philips site is pretty good at indicating which products require the bridge.
1 Like
I for one never liked the aqara devices for being too fragile and unreliable.
But that is just one brand, Signify has quite the restrictions in what you can use. As they naturally want you to stick with their products, even if they donāt even offer an alternative.
And yes, having a large(r) Zigbee mesh could have its advantages.
Goes without saying.
I would not however classify the Hue polished interface, reliability and options galore to be solely beginner friendly. On the contrary.
But, I take it, you havenāt tasted those using a Zigbee stick
Oh I do, I got one in my closet that I test out whenever Signify release new features, to see if itās something worthwhile. I do like the dynamic scenes, and I have managed to recreate them in HA natively, but itās not something that is being used in our household. But Iām interested to hear, what specific benefits do you think the bridge bring to the table besides the live scenes?
I donāt trust any of the big companies but Iām willing to try the product to see for myself
1 Like
Thanks. Thatās what I was looking for.
Well, never mind I guess maybe you donāt really want to hear. Letās just summarize the main advantage being the direct communication between Bridge and bulbs. No stress on the Ha processor (at all).
And these new scenes, you canāt have done that in core, simply because of that. Itās all directly on device (bulb).
Same for the hue groups/zones, which are even more efficient than Ha light groups .
And other functionality: hmm let me see, I set sensitivity, (light level and motion) , schedules etc etc.
Lastly, I am glad they keep their ecosystem clean, and promote their own products to be supported. What else would we expect from a Brand. Open it up to the many threats of badly programmed/behaving 3D party devices?
I understand the downside of a single brand (maybe even cloud, though this is all local) . Fully relate and respect the reservations we should have in that regard.
But I also have an open mind, and see the many benefits of that in the case of Hue. For now, the balance is 100% in their favor if you ask me.
Well, never mind I guess maybe you donāt really want to hear.
No I was actually curious, being honest here, apologies if you read it any other way.
direct communication between Bridge and bulbs. No stress on the Ha processor (at all).
Unless you toggle lighting from the dashboard, or automations based in HA I suppose?
Nevertheless I use a Raspberry Pi and there is no discernible difference in resource consumption.
new scenes
Do you mean akin to this?
There is no reason you canāt do that in HA natively. If you mean the dynamic scenes where the colours slowly change, I have been able to do that in HA as well.
Same for the hue groups/zones, which are even more efficient than Ha light groups .
Please elaborate, how it is more efficient than a ZHA set group.
sensitivity, (light level and motion) , schedules etc etc.
Which I can do in HA?
Lastly, I am glad they keep their ecosystem clean, and promote their own products to be supported. What else would we expect from a Brand. Open it up to the many threats of badly programmed/behaving 3D party devices?
Fair point, coming back to the beginner friendliness. Less things that can go wrong, but also more restrictions. It is definitely suited for a large group of users.
When using native zigbee groups, a single command with just a simple identifier is send across the zigbee network. The to-be-applied light bulb settings (brightness, rgb values, transition time, etc.) are stored in the light bulb itself. So, whenever this single message appears, each bulb knows directly what to do with it.
When not using native zigbee groups, every bulb involved in a scene will need to receive its own specific command: bulb identifier, brightness setting, rgb values, transition time, etc. So, you have more commands and the content of the command is also more complex.
In short: native zigbee groups wonāt flood the zigbee network (single short message), not-native zigbee groups can flood the zigbee network (many longer messages).
From my experience, this makes a huge difference (light bulbs not or delayed responding when activating bigger scenes). I am not using Home Assistant scenes anymore because of exactly this reason. I just activate the native zigbee scenes as programmed in Phoscon (Conbee II stick).
edit: in regard to ZHA set group, i donāt know if this is creating native zigbee groups or not (iām not using it), but the documentation should give you the answer.
we might have to take this elsewhere (not wanting to crash/diverge the release topic). But I was actually talking about the newer active āEffectsā, sorry. But even the dynamic scenes, yes, you can mimic that in HA, but itās just that. You have to constantly control the HA and have it interact with the lights. (I used that for my party lighting for a long time) where simply activating that scene in the Bridge now does nothing more in Ha, and all is done between bridge/bulb, or even on the bulb only. Which is also much easier on the HA/Bridge communication (admittedly something that could be too tasking for the Bridge in the past)
Same goes for the groups and zones in those groups, the ordering/organization of which is a breeze in the App, and which are now immediately available/actionable in HA.
Sure as do I, but not without the Bridge? Or can you control those from within the Z2M/ZHA interface directly too (never gotten around to that)
Will try a bit later to see the difference, if at all ofc.
and @pimw correct. I wasnāt talking HA scenes btw, but native Hue scenes. And, what you describe comes close to the HA light groups ofc.
And maybe itās me, but the Conbee II stick is a real nuisance. the interface, the connection, heck, it even blocks the Pi from rebooting correctly. Thatās why I tried another (Sonoff) lately. the dear people at HA Discord zigbee seemed to agree on that 
my biggest issue with all the HUE stuff is the absolutely obscene pricing.
7 Likes
And maybe itās me, but the Conbee II stick is a real nuisance. the interface, the connection, heck, it even blocks the Pi from rebooting correctly. Thatās why I tried another (Sonoff) lately. the dear people at HA Discord zigbee seemed to agree on that
My Conbee II stick has been rock-solid from the very first day; itās plugged in a RPI4 USB2 port with an extension cable. When looking at all the issues reported about ZHA, iām happy i went with Deconz + Phoscon. Even though iām not big fan either about the Deconz and Phoscon interfaces. Iām wondering what caused the issues for you.
Iām quite sure that scenes set up in Phoscon are implemented in software (by deCONZ), not in hardware (by the devices).
They will still leverage Zigbee groups (well, in theory at least, but in my experience grouping with deCONZ doesnāt always work on a Zigbee level), but the scene parameters are stored in deCONZās database and when you activate a scene deCONZ will send those parameters to the group.
Myabe i should be a little bit more specific: Zigbee Group Scenes are by definition stored in the light bulbs. Software is only used to:
-create/modify those Zigbee Group Scenes within the light bulbs (and other devices)
-send a signal to activate a zigbee group scene
Phoscon is making use of Zigbee Group Scenes. And those scenes can be called from Home Assistant. That works flawlessly for me.
Well I went from 2022.3.x to 2022.4.4 and all was fine. Iāve since updated to each step release since without any issue.
Stress less dude. Worse case scenario is that you roll back to a previous release with a backup.
3 Likes
I havenāt had a single issue at all with my Conbee2 using ZHA.
5 Likes
please add support for device_tracker in the helpers groups. Currently itās only available through .yaml
1 Like
sorry for my wording. Ive nuanced it to be my experience in the post above.