MQTT RGB + CCT light color_mode gets overridden

[joryvd]

The problem

I have some RGB + CCT light bulbs that are controlled via MQTT. These bulbs are set up via auto discovery on MQTT. They are reporting their states back on a separate states topic on the MQTT bus. When setting an RGB value, this is correctly reported back to home assistant, and reflected in the state. However when a CCT value is set, this is not reflected back to Home Asssistant correctly. In the Dev tools --> States the color mode stays on HS rather than color_temp. The color_temp_kelvin and color_temp stay on null. The last known RGB/XY/HS values are kept. On the MQTT command topic, the following values are reported, when changing from an RGB color to a CCT color: { "state": "ON", "color_temp": 358 } On the states topic the following values are reported: { "state": "ON", "brightness": 201, "level": 79, "kelvin": 94, "color_temp": 357, "bulb_mode": "white", "color_mode": "color_temp" } When manually removing RGB/XYHS state info in the dev tools --> states window, and then sending only kelvin/color_temp values on the MQTT bus, the RGB/XY/HS values are automatically added back, but this might be intended behaviour.

Home Assistant does not properly recognize when a bulb is switched to color_temp mode, and adjusts the appropiate states to reflect this in the UI

What version of Home Assistant Core has the issue?

core-2023.11.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

light

Link to integration documentation on our website

https://www.home-assistant.io/integrations/light/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (light) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `light` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign light` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

light documentation light source _{^{(message by IssueLinks)}}

[Sirmike2]

Same problem for me. When I change the color temp in card it will not change to color_mode=color_temp. MQTT messeges are the same like above.

[jbouwh]

States are set by the MQTT entity. So when an MQTT state update is received, this will also update the entity. So the behavior is by design. An MQTT light can process updates in the color mode, but that requires a correct config. More info: https://www.home-assistant.io/integrations/light.mqtt/

[home-assistant[bot]]

Hey there @emontnemery, mind taking a look at this issue as it has been labeled with an integration (mqtt) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `mqtt` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign mqtt` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

mqtt documentation mqtt source _{^{(message by IssueLinks)}}

[joryvd]

Thank for the reply! The light is changed from the UI and from there a MQTT message is sent outward. The message that is published on that point is: { "state": "ON", "color_temp": 358 } The lights are set up via MQTT discovery so no manual configuration has been done. Home Assistant did properly recognize the RGB + CCT bulbs as such. I'm also able to control everything of the bulb, both RGB as well as the CCT. To me, it seems Home Assistant isn't seeing when the bulb is switched to "white mode" and properly updating the state. That might also explain why it is not passed on in the MQTT message.

[jbouwh]

I understand the MQTT light is configured via discovery, but the discovery message is important for further diagnose. Also the payload that should have switched the light to the different color mode is important. Those payloads can be found when debug logging is turned on. To find the lights config payload, you can either look at the MQTT device info page. It has a MQTT Info link that shows some diagnostics, or you could use a tool like MQTT Explorer to see what payloads are received. With the it is important to write out the steps that enables us to reproduce the issue. Further it is important to open an issue at the developer/manufacturers site of the integration/service that publishes the MQTT config payloads for these lights. Common used software is Zigbee2MQTT, is that is used?

[joryvd]

Hi,

Please find below the payload of the discovery. (It doesn't seem to copy the newlines). This is in the topic homeassistant/light/milight_hub_16037728/rgb_cct_0x1_1/config

{ "dev_cla": "light", "schema": "json", "name": "Muur", "cmd_t": "milight/Muur", "stat_t": "milight/states/Muur", "uniq_id": "F4B760-Muur", "dev": { "name": "milight-hub", "sw": "esp8266_milight_hub v1.11.2", "mf": "espressif", "mdl": "d1_mini", "identifiers": "16037728", "cu": "http://192.168.5.50" }, "brightness": true, "effect": true, "fx_list": [ "night_mode", "white_mode", "0", "1", "2", "3", "4", "5", "6", "7", "8" ], "rgb": true, "color_temp": true, "max_mirs": 370, "min_mirs": 153 }

When I turn the light on from the home assistant UI, the following payload gets published in milight/muur {"state":"ON"}

The status gets updated in milight/states/Muur { "state": "ON", "brightness": 255, "level": 100, "hue": 16, "saturation": 100, "color": { "r": 255, "g": 67, "b": 0 }, "bulb_mode": "color", "color_mode": "rgb" }

When I switch to a CCT color/mode the following payload gets published in. What I do is I click the cct tab in the home assistant UI, and click on a value

milight/Muur

{ "state": "ON", "color_temp": 354 }

The following state gets reported in the states topic milight/states/Muur { "state": "ON", "brightness": 255, "level": 100, "kelvin": 92, "color_temp": 353, "bulb_mode": "white", "color_mode": "color_temp" }

I use a Milight bridge based on an ESP8266. I use the following repo for the software: https://github.com/sidoh/esp8266_milight_hub

Let me know if you need additional information! I'm also happy to open an issue on their repo, but not entirely sure what it should contain 😵

[jbouwh]

Thnx that will help. I have not been able to find time to walk through the steps, but I will come back to you ASAP as I found some time to work this through.

[jbouwh]

I have been able to replay the states and see the color_mode is not updated correctly. Next step is to find out why the color mode is not updated.

[joryvd]

Awesome! Let me know if I can be of assistance.

[jbouwh]

A quick analysis tells me the config payload misses two required options:

• supported_color_modes: A list of supported color modes. (See https://www.home-assistant.io/integrations/light.mqtt/#json-schema)
• color_mode: true.

Only color mode is detected with some deprecated code. Not sure when this deprecated code is to be removed. Probably I'll add some logging to ensure this gets visible in the logs, as it is not logged at the moment.

It seems a bit weird may be that these options are needed, but it is what it is.

[joryvd]

Ahh I see. I'll open up a issue at the other repo to see if they can add it into the discovery message. Hopefully that'll fix things. Thanks for the help!

[Sirmike2]

Just for information,

for my light it will discovered with supported_color_modes: color_temp, xy and color_mode: true , but as I told I have the same problem. In parallel I have this light manually configured via mqtt.yaml and default schema (not json or template). There is no problem. The light works as aspected.

[jbouwh]

Just for information,

for my light it will discovered with supported_color_modes: color_temp, xy and color_mode: true , but as I told I have the same problem. In parallel I have this light manually configured via mqtt.yaml and default schema (not json or template). There is no problem. The light works as aspected.

The basic schema or template schema have an other code base. The state of a light depends on what the light reports, not on the command that is sent. E.g. If a light receives { "state": "ON" } it will report it's current state back. Of course it is also possible to turn a light on with attributes. Those calls are fired when something changes, like the brightness or color_mode and color values. You can override the config by publishing another one withe the same state and command topics, so you can try out options. Great tool to use is MQTT explorer (Windows). You can also use the built-in tools that can be found at the MQTT entry page.

[jbouwh]

There is more wrong then the 2 options missing. The color state reporting also gives errors.

[joryvd]

Hmmm. I'll mess around a bit tomorrow. I'll tweak the discovery message some more. I'm familiar with mqtt explorer and used it to monitor all the traffic. There's also some options for the state fields that get reported back. I thought I had most (necessary) fields in there, but I'll mess around with that some more as well. Will keep you posted on my findings

[jbouwh]

This config works with both payloads:

{
  "dev_cla": "light",
  "schema": "json",
  "name": "Muur",
  "cmd_t": "milight/Muur",
  "stat_t": "milight/states/Muur",
  "uniq_id": "F4B760-Muur",
  "dev": {
    "name": "milight-hub",
    "sw": "esp8266_milight_hub v1.11.2",
    "mf": "espressif",
    "mdl": "d1_mini",
    "identifiers": "16037728",
    "cu": "http://192.168.5.50"
  },
  "brightness": true,
  "effect": true,
  "fx_list": [
    "night_mode",
    "white_mode",
    "0",
    "1",
    "2",
    "3",
    "4",
    "5",
    "6",
    "7",
    "8"
  ],
  "max_mirs": 370,
  "min_mirs": 153,
  "color_mode": true,
  "supported_color_modes": ["color_temp", "rgb"]
}

[jbouwh]

If it is desired to use hue and saturation, or a rgbw schema, it probably works better to use the basic schema, as this can use templates for the values to render.

[joryvd]

Cool, I'll give that a try tomorrow. I also made an issue on the repo of the bridge, so hopefully the good folks over there can work it into the firmware. Thanks for the good help so far!

[jbouwh]

As you can seem, I removed the color_temp and rgb options as they are replaced with color mode now. But what is weird that if they are specified why that will not pick up a color mode change. The availability of a color_mode field in the state payload should be enough to accept the new color mode imo. Why would supported_color_modes be needed if the rgb and color_temp options are set. IMO this might also be consired a bug. I'll discuss this with Erik. Any way the use of color_mode and suppported_color_modes is the recommended way to go. The use of the rgb and color_temp option is deprected, and we should log warnings when they are still used and remove them over some time.

[jbouwh]

I think I have found a bug in the handling of the deprecated color handling. I'll open a PR for a fix. This does not solve the deprecation of color_temp and rgb options, I will also open a PR to add warnings to the logs in case they are used, or register an issue in case they are manually configured.

[jbouwh]

The fix is accepted, so hopefully this gets fixed with HA Core 2023.12.1

[joryvd]

Awesome! Thanks for the help. I'll keep an eye out for the new HA Core and will report back. Thanks for the good work!