group::optimistic question

[SHxKM]

In the documentation it’s said that if group:optimistic is true then a single device turning on, will change the group state to on, and that changing the group state will change all devices state.

I want to inquire about optimistic false, are these statements correct?:

1. Only if ALL devices in the group are on, the group state is on.
2. A single command to turn the group on STILL changes all devices state to on.

[RaNo99]

Hi, I'm facing the same confusion. I raised an issue to have this explained: #12104

[SHxKM]

@Koenkk your input here is invaluable as this has been reported as a confusion in multiple places by multiple people.

[Koenkk]

If optimistic is false, the group will not change state anymore based on state changes of its members. It will only change its state when you control the group.

[SHxKM]

If optimistic is false, the group will not change state anymore based on state changes of its members. It will only change its state when you control the group.

Thanks. Would you mind me opening a PR with this explanation?

Just to be sure, when optimistic is false:

1. if the group state is off, and ALL members are turned on (individually), then group state stays off.
2. Controlling the group’s state still affects the state of all of its members.

Are these statements correct?

[Koenkk]

Yes, both are correct.

@RaNo99 are you questions also answered by this?

[SHxKM]

@Koenkk sorry to revive an old question but I've just gotten to implement optimistic: false on one of my groups and I think I'm getting unexpected behavior:

I have two groups:

outdoors-all and outdoors-schedule. outdoors-all contains all lights in outdoors-schedule, but not vice-versa.

Basically what I want is this, if I toggle on outdoors-schedule, outdoors-all does not toggle on. This is working as expected after changing outdoors-all to optimistic: false. However, When I then turn off outdoors-all (for example), outdoors-schedule still show as on, even though I haven't changed its optimistic boolean flag, and all of its members are actually off.

Why would one group's optimistic behavior affect another's?

[SHxKM]

@Koenkk any insights on this? any way to achieve what I want?

[Koenkk]

Why would one group's optimistic behavior affect another's?

I would expect not, would you be comfortable by adding some console.log() statements to

zigbee2mqtt/lib/extension/groups.ts

Line 102 in f5f5b03

@bind async onStateChange(data: eventdata.StateChange): Promise<void> {

to debug this?

[SHxKM]

Why would one group's optimistic behavior affect another's?

I would expect not, would you be comfortable by adding some console.log() statements to

zigbee2mqtt/lib/extension/groups.ts

Line 102 in f5f5b03

@bind async onStateChange(data: eventdata.StateChange): Promise<void> {

to debug this?

@Koenkk Unfortunately I wouldn't know how to do this, however there's a really quick way to reproduce this on any environment. All you need are two lights:

"1000": # large ID numbers to avoid collision
  friendly_name: all_lights_test_group
  optimistic: false
  devices:
    - light_1 # mutual member
    - light_2
"1001":
  friendly_name: some_of_all_lights_test_group
  devices:
    - light_1 # mutual member

1. Turn on some_of_all_lights_test_group, and you will see that all_lights_test_group does not turn on - correct behavior.
2. Now turn on all_lights_test_group.
3. Now turn off all_lights_test_group, the lights turn off, but some_of_all_lights_test_group state remains on - unexpected behavior.

The documentation says about optimistic:

Publish optimistic state after set, e.g. when a brightness change command succeeds Zigbee2MQTT assumes the brightness of the device changed and will publish this (default true).

So I wonder if all_lights_test_group, having optimistic: false, is simply not propagating its state to members, and therefore some_of_all_lights_test_group is not getting "notified" that its member-devices are now off.

[SHxKM]

As I think this is a bug, and the other question has already been address, I've opened an issue and will close this discussion:

#18457