Scene.create and Scene.turn_on not correctly restoring MQTT RGBW / RGBWW bulb state

[stevenjev]

Home Assistant release with the issue:

0.103.6

Last working Home Assistant release (if known):

Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io system through Docker

Integration:

Description of problem: The new scene snapshot does not properly work with my RGB+W bulbs (running 6.5.0(release-sonoff), through MQTT). After creating the snapshot (of the bulb at a color_temp using only the white LED) and then restoring, it attempts to set the bulb back to white. However, the white that it sets it to uses only the RGB LEDs, when really it needs to restore to using the W LED.

Therefore, the scene snapshot feature is not correctly resetting RGB+W bulb color temperature. I successfully call scene.create and scene.turn_on.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

[stevenjev]

As example, reading the console on the bulb itself, this is the state I set the bulb before calling the snapshot (scene.create): {"POWER":"ON","Dimmer":100,"Color":"0,0,0,123,131","HSBColor":"0,0,0","Channel":[0,0,0,48,51],"CT":332}

And this is the state that the bulb is sent after restoring the snapshot (scene.turn_on): {"POWER":"ON","Dimmer":100,"Color":"255,255,255,0,0","HSBColor":"0,0,100","Channel":[100,100,100,0,0],"CT":499}

[probot-home-assistant[bot]]

Hey there @home-assistant/core, mind taking a look at this issue as its been labeled with a integration (scene) you are listed as a codeowner for? Thanks!

[balloob]

What are the state attributes of the light stored in the scene? It means that either the light is not represented correctly in the state machine or it is not reproduced correctly.

[stevenjev]

These are the attributes of the light:

min_mireds: 153
max_mireds: 500
effect_list: 0,1,2,3,4
brightness: 255
color_temp: 353
hs_color: 0,0
rgb_color: 255,255,255
xy_color: 0.323,0.329
effect: 0
friendly_name: Front Porch
supported_features: 23

and these are the attributes of the light when stored in a scene (I tested further and if I create a scene with the light in the scene creator, the same issue occurs):

name: Front Proch
entities:
light.front_porch:
  brightness: 255
  color_temp: 353
  effect: '0'
  effect_list:
  - '0'
  - '1'
  - '2'
  - '3'
  - '4'
  friendly_name: Front Porch
  hs_color:
  - 0
  - 0
  max_mireds: 500
  min_mireds: 153
  rgb_color:
  - 255
  - 255
  - 255
  state: 'on'
  supported_features: 23
  xy_color:
  - 0.323
  - 0.329

[balloob]

So this seems like a bug in your light then. It contains an rgb_color while the MQTT message doesn't contain one.

[stevenjev]

I'm not sure if its a bug in my light because the MQTT messages sent from Home Assistant when I go to save the scene seem odd:

If I manually choose white on the RGB color wheel: {"POWER":"ON","Dimmer":100,"Color":"255,255,255,0,0","HSBColor":"0,0,100","Channel":[100,100,100,0,0],"CT":499}"

If I manually choose a color temperature on the color temperature slider: {"POWER":"ON","Dimmer":100,"Color":"0,0,0,130,125","HSBColor":"0,0,0","Channel":[0,0,0,50,49],"CT":324}

Both ^ of these function as expected.

If I create the scene and within the scene editor pick a color temperature on the slider, this functions as expected: {"POWER":"ON","Dimmer":100,"Color":"0,0,0,130,125","HSBColor":"0,0,0","Channel":[0,0,0,40,59],"CT":360}

If I save the scene and then go back to the main page of the scene editor, this MQTT command is sent without any user interaction. The act of saving the scene sends this command: {"POWER":"ON","Dimmer":100,"Color":"255,255,255,0,0","HSBColor":"0,0,100","Channel":[100,100,100,0,0],"CT":499}

So it looks like it successfully can send the right MQTT message when I edit the scene, but as soon as the scene is saved, it defaults back to sending RGB white.

[balloob]

Yes, that's because the MQTT Light is not representing your light correctly in the state machine. It's still including RGB Color although the white LED is making the light.

[probot-home-assistant[bot]]

Hey there @home-assistant/core, mind taking a look at this issue as its been labeled with a integration (mqtt) you are listed as a codeowner for? Thanks!

[stevenjev]

Ah I see what you mean. For all of my MQTT lights whenever I set the white LED, the RGB Color values always go to [255,255,255] in the state machine. The state that the bulbs are sending back do not include any RGB value (all zeros):

{"Time":"2020-01-11T16:25:44","Uptime":"4T17:17:32","Vcc":3.053,"SleepMode":"Dynamic","Sleep":0,"LoadAvg":121,"POWER":"ON","Dimmer":100,"Color":"0,0,0,130,125","HSBColor":"0,0,0","Channel":[0,0,0,48,51],"CT":332,"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"****","BSSId":"****","Channel":6,"RSSI":70,"LinkCount":3,"Downtime":"0T00:00:17"}}

I'm using the built in MQTT integration and running the MQTT Server & Web client add-on, all on the same machine. The Tasmota lights were found through MQTT Discovery (auto-discovery).

[balloob]

0,0,0 is still a valid rgb color, and so MQTT will consume that.

[stevenjev]

Right, where do I go from here then? How can I diagnose this issue further? It seems that there's an issue between the received MQTT RGB state and the stored RGB state in the state machine.

[balloob]

You should investigate if this is a problem with the MQTT light integration that you use or that your message producer shouldn't include RGB.

[stevenjev]

Here's what I see in the Home Assistant logs:

2020-01-15 15:05:12 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on bedside_lamp/tele/STATE: b'{"Time":"2020-01-15T21:05:12","Uptime":"4T23:57:02","Vcc":3.165,"SleepMode":"Dynamic","Sleep":0,"LoadAvg":1005,"POWER":"ON","Dimmer":100,"Color":"0,0,0,108,146","HSBColor":"0,0,0","Channel":[0,0,0,42,57],"CT":352,"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"***","BSSId":"***","Channel":6,"RSSI":72,"LinkCount":4,"Downtime":"0T00:00:15"}}' and the next line: 2020-01-15 15:05:12 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=light.bedside_lamp, old_state=<state light.bedside_lamp=on; min_mireds=153, max_mireds=500, effect_list=['0', '1', '2', '3', '4'], brightness=255, color_temp=499, hs_color=(0.0, 0.0), rgb_color=(255, 255, 255), xy_color=(0.323, 0.329), effect=0, friendly_name=Bedside Lamp, supported_features=23 . . .

The light is sending the correct MQTT command, but home assistant core is not interpreting that message correctly and sets the rgb_color to 255,255,255. Looking at the Tasmota Home Assistant integration, rgb_value_template is set by: "{{value_json.Color.split(',')[0:3]|join(',')}}". So the MQTT command from Tasmota looks correct. I really am unsure why home assistant is not correctly setting the rgb value from that MQTT command.

[stevenjev]

Testing this further... If I just make a service call of light.turn_on, with the service data:

entity_id: light.xx_lamp
rgb_color: [0,0,0]

and then look in the home assistant state machine, the rgb_color state for that the light is not [0,0,0] but is actually [255,255,255]. I know the service call is working because I can set other RGB values, just not all 0’s. If I can’t get the state machine to accept rgb_color equal to [0,0,0], then using the scene snapshot and restore features restore the bulb back to an RGB value of 255,255,255, which is RGB white, when I really want the W LED to be used.

I know in the latest 0.104 release, for WLED, pure white support was improved #30477 by setting the the RGB channels to 0's (turning them off) and just using the W channel only. It looks like this might be a similar issue, only with the built in light integration. If I send a service call rgb_color = [0,0,0], this is a valid RGB color, and home assistant should accept it and turn the RGB channels off accordingly.

[marknl]

I'm fairly new to HA and all of it's related techniques, so bare with me.

I'm running into the exact same issue. HA says that when you save a scene, the states of all linked devices in the scene will be saved as how they are at the moment of saving the scene. So when I add a light to a new scene, set it's color to white and color temp to full I see correct values being handled by MQTT and the light, this is how I want my light in this scene. So we can assume HA knows how to create a correct message for the light to set a warm white light. Then I save the scene and on the Homepage I press "Activate" on the newly created scene. I expect HA to send the state what it was when I pressed "save", but now it turns into RGB white.

To me, it looks like the generated scene config is either not correct (although, looking at it, it seems to be fine) or the scene configuration is incorrectly interpreted by HA so an incorrect message is created to set the light.

[carsten-h]

Hello!

I am having the same issue here. I can set whatever colour I like with the color chooser and the LED will use that colour. When I create a scene with a colour configuration (e.g. full green 0,255,0) and save it and afterwards activate this scene, the LED is always showing a white light where RGB values are all set to 255.

[holoduke]

the problem with most 5 channel bulbs is that when you use color_temp channel, the rgb values are ignored and only the CT command is send. when you store the bulb state in a scene and reactivate it later, it will also send the rgb values and therefor the CT is probably ignored on the device. I have lots of tasmota (mqtt) firmware devices with similar issues. What you ideally would like to have is once the CT value is > 0, then the rgb values must be not send. If the RGB values are > 0 and the CT value is in the middle then CT is ignored.

[dlashua]

I can confirm this is happening for me too with both ZHA and Zigbee2MQTT.

I can't debug ZHA as well as I can Zigbee2MQTT. In the case of Zigbee2MQTT, I can see both xy color and color_temp in the saved scene. However, when turning the scene on, only the xy color is sent. When setting the color temp manually, only color_temp is sent. When an xy color is sent, my bulb attempts to show this color using the the RGB LEDs. When a color_temp is sent, the bulb shows the color using the dedicated white LEDs.

Again, I can't debug the ZHA commands very easily, but, using the same bulb with both ZHA and Zigbee2MQTT I can see that the result is the same (as the brightness of the bulb is dimmer when using RGB LEDs, the color is slightly different, and if I look into the bulb closely I can see the colors of the RGB LEDs). Therefore, I assume the operation is the same as well between both of them.

@balloob for Zigbee2MQTT, are you saying it should send ONLY color_temp when white light is being used and ONLY xy color when RGB LEDs are being used and, if it does so, Home Assistant's scenes will sort it out correctly and save/restore the intended bulb settings? If this is the case, I can make that happen in Zigbee2MQTT. How do I accomplish this with ZHA?

The bulb in question is labelled as "Sylvania SMART+ 73693". It is showing under ZHA as "LEDVANCE A19 RGBW" and in Zigbee2MQTT as "Sylvania LIGHTIFY LED RGBW A19 (73693)".

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Thyself17]

This is still an issue as of v113. I'm using the Tasmota 8.3.1, and may set the color and brightness of my 4 channel bulb. When saving to a scene, Home Assistant does not retain the White color, and instead just shows a dim RGB-mixed white.

This is a fairly severe issue for my use case as I use scenes extensively.

[gaussey]

Does anyone know an alternative way of reverting an entity back to its state before an automation? This has been ongoing for so long that I think it might be an unsolvable problem.

[marknl]

I couldn't wait, so I've benched HA and are now running Domoticz, where this scene stuff works fine. I really like HA, but this feature not working made me switch. When this is fixed I might give HA another go.

[gaussey]

Never really looked into Domoticz, will take a peek.

[guilllex]

Same exact probleme here, I create a scene, add a device and set the desire state of color temperature, saved, when activate the scene the light is rgb white. Is there a way to send the correct color temperature other than seting the state in the scene manager ?

[Thyself17]

@emontnemery Is this still being worked?

[emontnemery]

@stevenjev for the MQTT light in your examples, can you confirm how it's setup? Please paste the MQTT discovery message.

[tachyon142]

I believe I'm experiencing this issue as well, attempting to use snapshot scenes in HA 0.112.4 with RGBW bulbs running Tasmota 8.3.1. One difference for me is the use of Tasmota's RGBWWTable for rolling the white channel into Color commands on my RGBW bulbs (CT is disabled, as Tasmota doesn't currently support CT using RGBW bulbs). Snapshot seems to work correctly for brightness, but restoration always changes the color back to white.

[stevenjev]

@stevenjev for the MQTT light in your examples, can you confirm how it's setup? Please paste the MQTT discovery message.

Unfortunately I've since moved to using ESPHome for these bulbs. When I originally set it up, I was running Tasmota with Setoption19 enabled. Hence, the bulbs were auto discovered and configured. I do not have the MQTT discovery messages.

The bulbs are a Globe brand, RGBWW. The fact that they can be set to white using the RGB leds and also the separate white leds is what I think is the issue. Realistically, I'm not sure why someone would want to use RGB white and not the real white.

[emontnemery]

For those affected by this issue, please help confirm light type and integration:

Light type:

• (RGB + W, color temperature NOT adjustable)
• (RGB + WW, color temperature adjustable)

Integration:

• MQTT + Tasmota
• MQTT + Zigbee2MQTT
• ZHA
• Something else?

[gaussey]

(RGB + WW, color temperature adjustable) MQTT + Tasmota

[tachyon142]

My situation is:

• (RGB + W, color temperature NOT adjustable) [specific product HERE]
• MQTT + Tasmota
• Using RGBWWTable mix the White channel in to Color for white correction.

The MQTT Info for one such device (I'm seeing the same on several of the same type/configuration) from HA is:

'Livingroom Lamp' (light.livingroom_lamp) MQTT discovery data: Topic: homeassistant/light/ED1ED6_LI_1/config Payload name: Livingroom Lamp Livingroom Lamp state_topic: sbLivingroomLamp/tele/STATE availability_topic: sbLivingroomLamp/tele/LWT payload_available: Online payload_not_available: Offline command_topic: sbLivingroomLamp/cmnd/POWER value_template: '{{value_json.POWER}}' payload_off: 'OFF' payload_on: 'ON' unique_id: ED1ED6_LI_1 device: identifiers:

• ED1ED6 brightness_command_topic: sbLivingroomLamp/cmnd/Dimmer brightness_state_topic: sbLivingroomLamp/tele/STATE brightness_scale: 100 on_command_type: brightness brightness_value_template: '{{value_json.Dimmer}}' rgb_command_topic: sbLivingroomLamp/cmnd/Color2 rgb_state_topic: sbLivingroomLamp/tele/STATE rgb_value_template: '{{value_json.Color.split('','')[0:3]|join('','')}}' effect_command_topic: sbLivingroomLamp/cmnd/Scheme effect_state_topic: sbLivingroomLamp/tele/STATE effect_value_template: '{{value_json.Scheme}}' effect_list:
  • '0'
  • '1'
  • '2'
  • '3'
  • '4' white_value_command_topic: sbLivingroomLamp/cmnd/White white_value_state_topic: sbLivingroomLamp/tele/STATE white_value_scale: 100 white_value_template: '{{value_json.Channel[3]}}' platform: mqtt

[Thyself17]

@emontnemery I have a RGBW (4channel) mixed with the Tasmota RGBWWTable configuration to 255,255,255,255,0 I am using MQTT and Tasmota.

Here is the device state as reported by Home Assistant.

min_mireds: 153
max_mireds: 500
effect_list:
  - '0'
  - '1'
  - '2'
  - '3'
  - '4'
brightness: 255
color_temp: 500
hs_color:
  - 284.941
  - 100
rgb_color:
  - 190
  - 0
  - 255
xy_color:
  - 0.299
  - 0.115
effect: '0'
friendly_name: RecessedBulb4 RecessedBulb4
supported_features: 23

I'm not sure how to get the MQTT discovery message offhand...

[jay-hankins]

I have RGBWW bulbs running ESPHome that exhibit this issue. In the meantime, I’ve created “scenes” using NodeRED flows which set the WW values then the RGB values as separate calls.

[carsten-h]

(RGB + WW, color temperature adjustable) MQTT + Tasmota

[emontnemery]

@jay-hankins Please confirm if the RGBWW bulbs are connected to Home Assistant via the MQTT integration or vie the ESPHome integration

[jay-hankins]

@emontnemery directly via the ESPHome integration.

[emontnemery]

@Thyself17 You can find the MQTT discovery message from the HA frontend: Configuration->Devices->->MQTT Info

@thyself17, @tachyon142: It would be interesting to see the interaction between Home Assistant and Tasmota, could you get a log covering the following:

• Open scene editor, and configure the scene as you want it (the correct light state for the RGBW bulb)
• Save the scene and apply it (resulting in the wrong state for the RGBW bulb)

Enable these logs:

logger:
  default: info
  logs:
    homeassistant.core: debug
    homeassistant.components.mqtt: debug

[Thyself17]

@emontnemery Here's my discovery message. Thanks for the assist in finding it:

name: RecessedBulb4 RecessedBulb4
state_topic: tele/tasmota/STATE
availability_topic: tele/tasmota/LWT
payload_available: Online
payload_not_available: Offline
command_topic: cmnd/tasmota/POWER
value_template: '{{value_json.POWER}}'
payload_off: 'OFF'
payload_on: 'ON'
unique_id: 246228_LI_1
device:
  identifiers:
    - '246228'
brightness_command_topic: cmnd/tasmota/Dimmer
brightness_state_topic: tele/tasmota/STATE
brightness_scale: 100
on_command_type: brightness
brightness_value_template: '{{value_json.Dimmer}}'
rgb_command_topic: cmnd/tasmota/Color2
rgb_state_topic: tele/tasmota/STATE
rgb_value_template: '{{value_json.Color.split('','')[0:3]|join('','')}}'
effect_command_topic: cmnd/tasmota/Scheme
effect_state_topic: tele/tasmota/STATE
effect_value_template: '{{value_json.Scheme}}'
effect_list:
  - '0'
  - '1'
  - '2'
  - '3'
  - '4'
color_temp_command_topic: cmnd/tasmota/CT
color_temp_state_topic: tele/tasmota/STATE
color_temp_value_template: '{{value_json.CT}}'
platform: mqtt

I'll post some logs soon.

[Thyself17]

Here's a log for creating a new scene, setting the scene up, saving, setting color to a new (non-white) color, and then applying the scene.

I'll note that the "recessedbulb4" that I posted the MQTT discovery for above is part of a greater light group, so you may see multiple messages sent out when one is changed.

home-assistant_mqtttasmota.log

[Thyself17]

Ooh I have an update I changed the RGBWWTable to be 255,255,255,255,0 (Basically, set the bulb to only use 4 channels) and rediscovered all the devices. When I created a new scene, all the bulbs seem to hold the white color of the scene correctly.

I can mark this as resolved for my 4 channel use. I'd be happy to try some more testing to help out others

[emontnemery]

@Thyself17 In the discovery message you pasted here https://github.com/home-assistant/core/issues/30618#issuecomment-680940016, the light is actually announced as an RGBWW light, not an RGBW light. After you changed the configuration and scenes started working, did the discovery message change?

[Thyself17]

@Thyself17 In the discovery message you pasted here #30618 (comment), the light is actually announced as an RGBWW light, not an RGBW light. After you changed the configuration and scenes started working, did the discovery message change?

My discovery message looks exactly the same (still showing color temperature, etc) I would consider my case as noise right now. I'll revert my configuration and see if I can replicate the problem again before reporting back

[emontnemery]

To make this issue manageable, I suggest to split out the problems with ESPHome and ZHA to separate issues. @jay-hankins , @dlashua can you please create new issues mentioning ESPHome and ZHA respectively?

[emontnemery]

Tasmota + RGBW: I am not able to reproduce the problem, @tachyon142 can you reproduce it and if so attach a log please? Tasmota + RGBWW: Caused by Tasmota not announcing the white value control for RGBWW lights, should be fixed by arendst/Tasmota#9175 Zigbee2MQTT: @dlashua Do you still have this problem with zigbee2mqtt?

[gaussey]

Updating the bulb(s) to the latest Tasmota firmware fixed this issue for me.

[ASNNetworks]

I came here because I'm having the same issues. I use the LIGHTIFY LED CLA60 E27 RGBW (AC03645). It shows the same RGB value when changing to a kelvin color command. I also tested this with a OSRAM Flex RGBW strip. That one changes the RGB to something that looks like the value, but even that saves RGB, while I send a kelvin command. The color of the RGB value is also different since its RGB instead of the W led. So restoring that one also shows different coloring. It needs to restore to the color temp instead of the RGB.

The strange thing is: I used deCONZ untill now and it worked flawlessly with handling states. But the same lights have this issue with zigbee2mqtt... So how can I say the lights are at fault in this case. That doesn't make sense to me...

[emontnemery]

@ASNNetworks Can you please share the MQTT discovery message sent by zigbee2mqtt for the RGBW light?

[Twanislas]

This looks very similar to #37807

[emontnemery]

@Twanislas You're also using zigbee2mqtt according to #37807, can you please share the MQTT discovery message sent by zigbee2mqtt for the offending RGBW light?

[ASNNetworks]

The light was first set to Kelvin 3600 with service call. This is the log when that was set (don't pay attention to the time, I did this again after to get the log)

INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":203,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:48:10+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'

Then I created a snapshot and sent the RGB value.

Snapshot

INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":203,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:45:57+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'
INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":203,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:45:58+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'
INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":253,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:45:58+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'
INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":210,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:45:59+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'

light.turn_on service call with this data:

{
    "rgb_color": [
        255,
        63,
        0
    ],
    "brightness_pct": "80"
}

After that I waited a few seconds and restored the snapshot.

Restore

INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":203,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:46:04+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'
INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":246,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:46:04+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'
INFO: MQTT publish: topic 'zigbee2mqtt/Raam', payload '{"brightness":246,"color":{"h":14.824,"s":100,"x":0.399310247889814,"y":0.387626553413704},"color_temp":277,"last_seen":"2020-10-26T16:46:05+01:00","linkquality":86,"state":"ON","update":{"state":"idle"},"update_available":false}'

I hope this is clear enough. The strange part is though: I used deCONZ untill yesterday. The same lights work fine under deCONZ and the snapshots...