Is there currently any way to disable the hue groups (allow_hue_groups) whilst using the new HA integration UI?
As far as I know you can only change this when you do it manually.
Well … that sucks … maybe I just try to delete the groups within Hue
UI wise there has to be done a lot for HA to reach v1.x …
Why give up this feature just because it is not configurable through the UI?
It’s only a few lines in your configuration.yaml…
because I have to remove Hue via the integration so I can add it in the config? Otherwise I’ll have Hue two times in HA …
Problem is, I have renamed all Hue entities so I’d have to this again …
I only want the Hue groups to be gone in HA because I have other non Hue lights, so I’ve to create specific groups in HA anyway …
I would say keep the Hue groups and leverage them as you’ll get better Hue performance. The Hue bridge will throttle incoming traffic and by using groups, you reduce that traffic (especially if making calls to a lot of lights). This comes in really handy for things like good night or leaving home routines where you are addressing a lot of devices at once.
What I do is create groups and zones in Hue and then leverage them in my groups in HA. This way, if I need to modify a mixed group, it is calling my HA lights and the Hue group, thereby reducing the number of calls needed to go to the Hue bridge (1 call for a group/zone versus multiple calls for lights). I renamed all my Hue groups and zones to use Hue - [room/zone] - [function]. So, my outside lights group is Hue - Outside Porch Lights and shows up in HA as light.hue_outside_porch_lights. Then, I have a group in HA called group.outside_lights. This is the definition for that group:
outside_lights:
name: Outside Lights
entities:
- light.hue_outdoor_porch_lights
- group.carport_lights
- group.pathway_lights
1 Like
Thank you, I think I’ll try that. Is this a Hue bridge limitation or Zigbee in general?
(Longterm plan is to ditch the Hue bridge and replace it with a Zigbee LAN gateway or some sort of open source Zigbee hub … but they are hard to find, best I’ve found ist ZiGate but it’s WiFi not LAN, and some industrial ones but they are missing the software part, maybe I just throw an RPi with Zigbee in a nice box and run some sort of Zigbee2MQTT)
That is exactly how I had it configured. I initially added Hue via UI and then (at some point later) also added it to configuration.yaml in order to override the allow_unreachable and allow_hue_groups parameters. It worked perfectly. Hue was not shown twice, just once with all devices listed in the Integrations section. And the groups were gone.
P.S. I have switched from Hue to Zigbee2MQTT a few weeks ago and couldn’t be happier with it 
It’s a Hue limitation. A few years ago, they introduced throttling because when they enabled 3rd party integrations, there were TONS of user complaints about the performance of the hub. It made sense as at one point, I had something like 7 or 8 different platforms all querying my Hue systems (Alexa, GH, SmartThings, HA, etc) and often times, one system or another would fail to query or issue commands due to the amount of traffic the hub had to process.
This has always been a goal of mine as well, but until the Zigbee alliance comes out with a reliable method of ZLL/ZHA profile interoperability, I’ll stick with the Hue hub as it is the only hub on the market (right now) that is 100% ZLL compliant. The issue that I want to avoid is message drops from ZLL ↔ ZHA devices (which is why a lot of times mixing ZLL and ZHA devices causes headaches for those of us with large Zigbee networks).
I can confirm that like @sashamik mentioned it’s possible to add the yaml configuration after you have added the bridge via the integration.
After moving everything from HA to Hass.io I decided to ditch the hue groups, mostly because you can’t rename them (the entity_id). I’ll give it 2-3 weeks to see how it performs