Configure what a Zigbee "heterogeneous" group "exposes" through Z2M

[SHxKM]

Is your feature request related to a problem? Please describe

Yes.

Here's a scenario:

• Assume we have 3 Philips Hue lights, 1 of them supports hue-saturation, while the other two only support color-temperature.
• Now assume all of these 3 lights are in the kitchen, and we'd like to control them uniformly.
• Assume we add them to a group, which gets exposed to HA as light.kitchen_lights_group.

Both from HA and from integrations like HomeKit, I am then allowed to set a hue/color for this group. What actually ends up happening is that only the 1 light that supports hue-saturation gets updated, and the other two are left alone. In HomeKit this becomes extra annoying since even when you choose a circle that looks like it's only going to update the color temperature, it actually sends a color update, which only applies to lights that support hue-saturation in the group.

Describe the solution you'd like

For some reason I have a feeling a solution for this already exists, but I've been Googling for a while now.

Essential my suggestion is: let me decide whether a group (or/especially a "heterogeneous" where different members expose different properties) can receive color state mutations (xy, etc...) or only color_temp ones.

Then I could change the color temperature of my kitchen lights from HomeKit, and keep my marriage intact.

Describe alternatives you've considered

I'm not sure there are.

[SHxKM]

@Koenkk maybe you can give a hint on where to start looking for this in the source code so I can maybe explore a bit deeper?

[Koenkk]

It is possible to override the HA discovery payload from the configuration.yaml, example: https://www.zigbee2mqtt.io/guide/usage/integrations/home_assistant.html#exposing-switch-as-a-light

[SHxKM]

It is possible to override the HA discovery payload from the configuration.yaml, example: https://www.zigbee2mqtt.io/guide/usage/integrations/home_assistant.html#exposing-switch-as-a-light

Can the same be applied to groups though? I don’t want to necessarily hide the color-functionality of the devices themselves.

For example: Device A is color-enabled while Device B is temperature-only. They are both members of group 1.

I want group 1 to only expose temperature capabilities, and Device A to still expose its color capabilities.

[SHxKM]

@Koenkk is it possible with zigbee2mqtt/bridge/request/device/options? Given device is really a group?

[SHxKM]

I've tried using the options and publish this MQTT message:

{
  "id": "4",
  "options": {
    "color_mode": "color_temp"
 }
}

But I get this in Z2M's logs:

Request 'zigbee2mqtt/bridge/request/device/options' failed with error: 'Device '4' does not exist'

[SHxKM]

OK, now I've tried with the correct endpoint: zigbee2mqtt/bridge/request/group/options and the request succeeds but has no effect, I can still see the color-wheel in HA, and I still get inconsistent behavior.

[Koenkk]

Should also work for group, but make sure to use the correct structure, just color_mode is not enough, it has to start with homeassistant like the example on https://www.zigbee2mqtt.io/guide/usage/integrations/home_assistant.html#exposing-switch-as-a-light

[SHxKM]

@Koenkk The example shows only action-like customizations. How do I say what the group exposes? And if I don’t specify other attributes, I assume they stay default?

[SHxKM]

In group.yaml (which is included in configuration.yaml, I've tried all of these without success (restarted both Z2M and HA after each change):

"4":
  friendly_name: kitchen_lights
  devices:
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
  homeassistant:
    light:
      supported_color_modes: ["color_temp"]

"4":
  friendly_name: kitchen_lights
  devices:
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
  homeassistant:
      supported_color_modes: ["color_temp"]

"4":
  friendly_name: kitchen_lights
  devices:
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
  homeassistant:
    light:
      color_mode: true
      supported_color_modes: ["color_temp"]

They have no effect.

While this setting:

  homeassistant:
    light:
      color_mode: "color_temp"

disables the entity and makes it "orphan".

Even stopping Z2M and deleting the group's xy from the state.json doesn't help.

[Koenkk]

I found that lists were not overridable yet, fixed this now.

"4":
  friendly_name: kitchen_lights
  devices:
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
    - XXXXXX/11
  homeassistant:
    light:
      supported_color_modes: ["color_temp"]

should do it

[SHxKM]

@Koenkk should I be on the dev branch to use this?

[Koenkk]

yes

[SHxKM]

yes

Alright. I think I’m gonna wait for a release, but I will update here once I try this regardless. Thanks so much for your great work!

[SHxKM]

@Koenkk Very happy to update that this is now solved/supported in Z2M v1.22.2. Thanks!

For HomeKit specifically, I had to "un-expose" the group and then re-expose it (remove it from yaml, restart HA, re-add it, restart HA) so it appeared with the correct (reduced) capabilities in HomeKit, otherwise HomeKit still thinks the group is color-enabled and you get "No response" when you try to choose any color option from the palette.