Group "assume member state": colour-temperature commands never update members' colour mode

[zigpy-review-bot]

In _make_members_assume_group_state(), the colour-temperature and xy-colour blocks both write assumed_color_mode, and the second unconditionally overwrites the first:

https://github.com/zigpy/zha/blob/dev/zha/application/platforms/light/__init__.py#L1582-L1594

if color_temp is not None:
    assumed_color_mode = self._color_mode
    assumed_color_temp = self._color_temp
else:
    assumed_color_mode = None
    assumed_color_temp = None

if xy_color is not None:
    assumed_color_mode = self._color_mode
    assumed_xy_color = self._xy_color
else:
    assumed_color_mode = None
    assumed_xy_color = None

A colour-temperature command has xy_color is None, so the second else resets assumed_color_mode to None after the first block has just set it.

That value is consumed further down:

https://github.com/zigpy/zha/blob/dev/zha/application/platforms/light/__init__.py#L1643-L1644

if assumed_color_mode is not None and assumed_color_mode in supported_modes:
    platform_entity._color_mode = assumed_color_mode

so the guard fails and members never have their colour mode switched. assumed_color_temp survives and is applied by its own separate guard, so the member ends up with an updated colour temperature while still reporting whatever colour mode it had before.

This only affects the "assume member group state" path, and only for colour-temperature commands — an xy command sets the mode last and is unaffected.

Suggested fix

Only reset assumed_color_mode when neither branch has set it, for example by computing it once from whether either color_temp or xy_color was supplied, rather than assigning it in both blocks.

Found while reading this function for an unrelated reason; not reproduced against hardware.