Two groups in same room, one group does not change status

[Nastras]

I just noticed something else during testing where I suspect that it is not right.

If I create two groups in a room:

Group 1 = all lamps in the room.
Group 2 = individual lamps in the room not all

If I switch on group 2 where only a few lamps from the room are included and are also present in group 1, group 1 does not switch on.

Here I would have expected group 1 to switch on as all the lamps in group 1 are also included that are also in group 2.

If I try it the other way round and switch on group 1 first, group 2 will also switch on.
Is the behaviour intended?

Greeting Nastras

[ebaauw]

Are you looking at Apple’s Home app? Homebridge-hue exposes state.all_on as On and state.any_on as Any On. The latter is a custom characteristic, that Home doesn’t support. In Home, a group shows as on, only when all its lights are on.

[Nastras]

Good morning,

thank you for the explanation.
Yes, I tested it in the HomeApp and saw later that there is this anyone switch.

I just noticed something critical. I'm just not sure what caused it. I think it has something to do with creating and deleting groups in the background.

I just deleted several groups, created and edited them and created scenes. I don't have the homebridge-hue instance separate from Homekit.

After I finished I restarted the homebridge-hue instance and it updated itself and added the new groups and deleted the old ones.

After I wanted to test the groups in Homekit I noticed that the assignment of the names does not match with the groups that are switched.

I made you two screens and attached the homebridge-hue.json.gz.

homebridge-hue.json.gz

[Nastras]

After I have disconnected Homekit and deleted accessories and persist, the groups are displayed and switched correctly again.

Of course it is not nice later in the productive system when you change a group and the problem occurs -.-

[ebaauw]

You’ll have to take this one up with Apple. Like HomeKit rooms, groups, scenes, and automations, the names of accessories and services cannot be accessed over HAP. When exposing a new accessory, HomeKit copies the names as published by the accessory (i.c. homebridge). After that, they can only be changed by HomeKit apps.

[Nastras]

Okay, so a home kit bug probably. I'm just surprised that he deleted the old groups and added the new groups with wrong names. So the new added group has either the wrong name or the right name and switches the wrong lamp. Who knows.

I wish you a nice rest of the weekend !

[ebaauw]

I don’t think Apple would see this as a bug. The accessory and service names are under control of the end user, and shouldn’t be changing spontaneously.

HomeKit accessories are identified by their UUID. Homebridge-hue generates this UUID from the ZigBee mac address (for ZigBee devices) or from the resource ID (for other resources). Due to the static platform accessories model (see #4), homebridge-hue cannot tell the difference between a changed group and a newly created group with the same ID. It will expose the new group with the same UUID as the old group, and HomeKit will continue to see the same accessory (with the old name). To overcome this, you’d need to restart homebridge after deleting the old group, and then again after creating the new group.

[Nastras]

you’d need to restart homebridge after deleting the old group, and then again after creating the new group.

Good hint, thank you!