"truer" light type for lights with restricted capabilities such as found in alarm clocks

[avg-I]

I have a Tuya alarm clock that was sold as Smart Wake Up Light without a specific brand.
In Smart Life application it was discovered under a name Smart Wake Up Light II.
Tuya Local supports it as Moes Smart Wake Up Light ("moes_zcjk_alarmclock").

The device has a dimmable main light and it also has "ambient light" mode where one of a fixed number of colors can be selected. The light is not dimmable in that mode.

In moes_zcjk_alarmclock.yaml the ambient light is described like this:

  - entity: light
    name: Ambient
    dps:
      - id: 129
        type: boolean
        name: switch
      - id: 132
        type: string
        name: named_color
        mapping:
          - dps_val: "1"
            value: white
          - dps_val: "2"
            value: red
...

In Home Assistant the ambient light is seen like this:

          "state": {
            "entity_id": "light.wakeup_light_ambient",
            "state": "off",
            "attributes": {
              "supported_color_modes": [
                "hs"
              ],
              "color_mode": null,
              "brightness": null,
              "hs_color": null,
              "rgb_color": null,
              "xy_color": null,
              "friendly_name": "WakeUp Light Ambient",
              "supported_features": 0
            },

Because of this, the interface shows the ambient light as if it supports setting arbitrary colors and as if its brightness level could be controlled. Both are not true, so the interfaces misleads and confuses a bit.

I think that its should be easy for the integration to see that the light does not have any brightness control or true color control.
What if instead of setting supported_color_modes to "hs", the integration would set it to simply "onoff" ?
And then add effect_list to expose the predefined colors as "effects"?

Could that work?

P.S.
Not really important to the topic at hand and I probably should open a separate discussion (or even an issue) about that,
but my device does not have 8 colors as defined in moes_zcjk_alarmclock.yaml. Instead, it has 7 colors plus a cycle colors effect.
So, for it, color control is even closer to effects than to true color control.

[avg-I]

After having a closer look,maybe it would be better to just change the device definition so that it uses effects instead of named_color?
The only advantage of named_color is that color selection buttons have have matching colors, but otherwise it gives the wrong information about light capabilities in this case.