Temporarily disabling individual bulbs in a light group - best pattern

Hi, I’m trying to figure out the best pattern to dynamically disable and enable individual bulbs in a light group (representing a single fixture). Has anyone tried setting up something like this? Any suggestions what would be the best approach here?

Assumptions:

  1. Each bulb is controlled individually
  2. Bulbs are powered all the time (i.e. device won’t go offline)
  3. Each fixture has only two possible bulb enablement states - either all bulbs are enabled, or only a predefined, constant subset is enabled.

Requirements:

  1. A single light entity represents the light fixture, no matter how many bulbs are enabled
  2. The light entity allows for the same level of control as a standard light entity - on/off, brightness & color
  3. Bulbs react to commands immediately after being reenabled

What I’ve tried/considered so far:

  • Dynamically disable entity or device of the bulbs
    • Fails requirement 3 as the bulbs are unresponsive for a while after reenabling
  • Set up an artificial light entity as a “front” and then have separate logic which relays the command only to non-disabled bulbs
    • Meets requirements
    • Adds complexity & lag for all commands sent to the fixture
    • Feels like a worse reimplementation of light groups
  • Dynamically add/remove bulbs from the light group
    • Meets requirements
    • Feels quite hacky (requires direct operations on undocumented HA API)
    • Forces the use of HA groups, instead of the more performant Zigbee groups (as those must always have at least 2 members)

I would have a script that s used to turn those lights on. (The group concept may be getting in your way here.)
The script will accept a field that will decide what light config you want. This could be driven by a select statement in a card, or whatever.
Each value of the variable that is passed in represents a light configuration. feed it into a choose statement so that when you send it ‘mid-dim’ or ‘34’ or whatever code you like it select that and turns on and off the lights in a parallel action statement in the right configuration.

Very easy to maintain and understandable. This could also be done like this if you set each light config in separate permanent scenes, or groups, then call the scenes or groups instead of the parallel service call right in that script.

I want to still be able to control the fixture via a light entity that I can expose on the dashboard. This is not only on/off but brightness and color as well so this simplistic solution won’t work. I’ll edit the original post to make this clearer

This would not interfere with any other control point, it would be it’s own.
My example covered on and off. Brightness, color, temp, effects are all sub functions of the turn_on service and can be added into your list of selects or front-ended any way you like. (Like with additional fields or whatever)

So essentially that’s the solution I’ve described above

Set up an artificial light entity as a “front” and then have separate logic which relays the command only to non-disabled bulbs

With the modification that it’d be more complex as I would have to basically reimplement UI controls for lights.

Why not set an override attribute on each individual bulb in the group then check that attribute when turning on the lights using some type of for loop?

That’s again a variant of the general solution above, with all the listed drawbacks, isn’t it?

Which Zigbee integration are you using?

I’m using ZHA