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

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:

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 88 (38 by maintainers)

Most upvoted comments

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.

Thyself17 on Aug 3, 2020

@emontnemery I will implement this soon. I guess this issue can be closed since it has been solved from the HA side?

Koenkk on Feb 16, 2021

@FransTwisk Thanks a lot for the patience, it’s clear why it’s not working. Your best option right now is to split the light in two by using SetOption37 128 in Tasmota console. After Tasmota has rebooted, your light should show up as one RGB light and one CT light.

emontnemery on Nov 2, 2020

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

gaussey on Aug 25, 2020

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 on Jan 15, 2020

I created an architecture issue: https://github.com/home-assistant/architecture/discussions/519

emontnemery on Feb 22, 2021

The zigbee2mqtt issue is discussed at length in #45145, with an improvement for Home Assistant in #45522. However, zigbee2mqtt also needs to be updated to use the new feature. @Koenkk When do you think zigbee2mqtt will be updated? #45522 made it to Home Assistant 2021.2, so it should be OK to use the new feature by now.

emontnemery on Feb 16, 2021

@marknl Let’s keep this issue about the MQTT integration. Please open a new issue about the Tasmota integration failing to restore state. 👍

emontnemery on Nov 5, 2020

@ASNNetworks Right, the problem is basically that Home Assistant expects the lights to be either in white mode or in color mode. However, there’s no defined way to specify which mode the light is in using MQTT basic schema (used by Tasmota) or MQTT JSON schema (used by Zigbee2MQTT). It means the state stored in the scenes is ambiguous, and running the scene does not work.

emontnemery on Nov 2, 2020

Sure, the direct integration will work (once #42772 is merged, so earliest in 0.117.3)

emontnemery on Nov 2, 2020

@ASNNetworks Let’s hold it a bit with the issue on zigbee2mqtt, I think there will need to be changes also in HomeAssistant core 😓

emontnemery on Nov 2, 2020

availability_topic: zigbee2mqtt/bridge/state
brightness: true
brightness_scale: 254
color_temp: true
command_topic: zigbee2mqtt/Raam/set
device:
  identifiers:
    - zigbee2mqtt_0x7cb03eaa0a0749ed
  manufacturer: OSRAM
  model: LIGHTIFY LED CLA60 E27 RGBW (AC03645)
  name: Raam
  sw_version: Zigbee2MQTT 1.15.0
hs: true
json_attributes_topic: zigbee2mqtt/Raam
name: Raam_light
schema: json
state_topic: zigbee2mqtt/Raam
unique_id: 0x7cb03eaa0a0749ed_light_zigbee2mqtt
platform: mqtt

ASNNetworks on Oct 26, 2020

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?

emontnemery on Aug 27, 2020