Am I missing something? No color on light in scene

Configuration
, ,
1

I feel like I am missing something simple. I have 4 wifi rgbcw flood lights in front of the house I am using as accent lights. I would like to eventually create a script that will change the color of the lights based on holidays and ribbon awareness days/months. I am working in the scenes.yaml but have the same problem when I tried the scene editor. I have one scene that works fine named FA Year Round that is the default. It is simply a warm white light.

name: FA Year Round
  entities:
    light.front_accent_lights: 
      supported_color_modes:
      - brightness
      - color_temp
      - hs
      - onoff
      color_mode: color_temp
      brightness: 22
      color_temp: 348
      state: 'on'

This works just fine. When I add a scene that has color it will come on and set the brightness but won’t change the color from white to whatever it should be. Example scene

name: FA October Breast Cancer 
  entities:
    light.front_accent_lights:
      supported_color_modes:
      - brightness
      - color_temp
      - hs
      - onoff
      color_mode: hs
      brightness: 45
      hs_color: [330, 100]
      state: 'on'

So if I activate the first scene it runs fine… I turn off the lights and then run the second scene it comes on as white but with the designated brightness.

I have gone to the light, set it using the tuya app and then checked the state. I copied that state into the scene and it does the same thing. It comes on white with the brightness set correctly. I can go to the light itself in ha and set the color and that works but not with a scene.

Anything I am missing?

2

Something to try in the UI for Scenes is pick a device instead of the entity. Don’t know why, but I had similar issues with my WiZ bulbs. Selecting by device fixed my issues.

1 Like
3

Hi,

Maybe you have the same problem as I discovered with the Tuya Led Strip.
The Contrast setting is always set to 26% so the lights seem to be white and not the color chosen.

You can test this when setting the Contrast in the Smart Life App. Set the contrast to 100%. The lights should be the right bright color.
Now change the color in Home Assistant. Then the light appear white.
Check the contrast status in the Smart Life App. I guess it is set to 26%.

There is an issue about the brightness. But also the contrast looks like to be wrong.

4

I tried that several times and no joy!

5

The contrast is 100% in the smart life app.

One thing I have noticed is that in the cloud explorer the work mode value is never set to colour instead of white. The integration does not change this mode. I can’t find the code to the integration to see where this is set. It seems like a bug in the integration.

6

Well I take back what I said earlier about the work mode getting sent. Here is the log. It shows the work_mode being set to colour but coming back as white.

2022-01-02 14:50:37 DEBUG (SyncWorker_1) [homeassistant.components.tuya.base] Sending commands for device redacted: [{'code': <DPCode.SWITCH_LED: 'switch_led'>, 'value': True}, {'code': <DPCode.WORK_MODE: 'work_mode'>, 'value': <WorkMode.COLOUR: 'colour'>}, {'code': <DPCode.COLOUR_DATA_V2: 'colour_data_v2'>, 'value': '{"h": 330, "s": 1000, "v": 176}'}, {'code': <DPCode.BRIGHT_VALUE_V2: 'bright_value_v2'>, 'value': 185}]
2022-01-02 14:50:37 DEBUG (SyncWorker_5) [homeassistant.components.tuya.base] Sending commands for device redacted: [{'code': <DPCode.SWITCH_LED: 'switch_led'>, 'value': True}, {'code': <DPCode.WORK_MODE: 'work_mode'>, 'value': <WorkMode.COLOUR: 'colour'>}, {'code': <DPCode.COLOUR_DATA_V2: 'colour_data_v2'>, 'value': '{"h": 330, "s": 1000, "v": 176}'}, {'code': <DPCode.BRIGHT_VALUE_V2: 'bright_value_v2'>, 'value': 185}]
2022-01-02 14:50:37 DEBUG (SyncWorker_0) [homeassistant.components.tuya.base] Sending commands for device redacted: [{'code': <DPCode.SWITCH_LED: 'switch_led'>, 'value': True}, {'code': <DPCode.WORK_MODE: 'work_mode'>, 'value': <WorkMode.COLOUR: 'colour'>}, {'code': <DPCode.COLOUR_DATA_V2: 'colour_data_v2'>, 'value': '{"h": 330, "s": 1000, "v": 176}'}, {'code': <DPCode.BRIGHT_VALUE_V2: 'bright_value_v2'>, 'value': 185}]
2022-01-02 14:50:37 DEBUG (Thread-6) [homeassistant.components.tuya] Received update for device redacted: {'switch_led': True, 'work_mode': 'white', 'bright_value_v2': 185, 'temp_value_v2': 438, 'colour_data_v2': '{"h":330,"s":1000,"v":176}', 'scene_data_v2': '{"scene_num":1,"scene_units":[{"bright":200,"h":0,"s":0,"temperature":0,"unit_change_mode":"static","unit_gradient_duration":13,"unit_switch_duration":14,"v":0}]}', 'countdown_1': 0, 'music_data': '', 'control_data': '', 'sleep_mode': 'AAA=', 'wakeup_mode': 'AAA='}
2022-01-02 14:50:37 DEBUG (Thread-6) [homeassistant.components.tuya] Received update for device redacted: {'switch_led': True, 'work_mode': 'white', 'bright_value_v2': 185, 'temp_value_v2': 438, 'colour_data_v2': '{"h":330,"s":1000,"v":176}', 'scene_data_v2': '{"scene_num":1,"scene_units":[{"bright":200,"h":0,"s":0,"temperature":0,"unit_change_mode":"static","unit_gradient_duration":13,"unit_switch_duration":14,"v":0}]}', 'countdown_1': 0, 'music_data': '', 'control_data': '', 'sleep_mode': 'AAA=', 'wakeup_mode': 'AAA='}
2022-01-02 14:50:37 DEBUG (Thread-6) [homeassistant.components.tuya] Received update for device redacted: {'switch_led': True, 'work_mode': 'white', 'bright_value_v2': 185, 'temp_value_v2': 438, 'colour_data_v2': '{"h":330,"s":1000,"v":176}', 'scene_data_v2': '{"scene_num":8,"scene_units":[{"bright":0,"h":0,"s":1000,"temperature":0,"unit_change_mode":"gradient","unit_gradient_duration":70,"unit_switch_duration":70,"v":1000},{"bright":0,"h":120,"s":1000,"temperature":0,"unit_change_mode":"gradient","unit_gradient_duration":70,"unit_switch_duration":70,"v":1000},{"bright":0,"h":240,"s":1000,"temperature":0,"unit_change_mode":"gradient","unit_gradient_duration":70,"unit_switch_duration":70,"v":1000},{"bright":0,"h":61,"s":1000,"temperature":0,"unit_change_mode":"gradient","unit_gradient_duration":70,"unit_switch_duration":70,"v":1000},{"bright":0,"h":174,"s":1000,"temperature":0,"unit_change_mode":"gradient","unit_gradient_duration":70,"unit_switch_duration":70,"v":1000},{"bright":0,"h":275,"s":1000,"temperature":0,"unit_change_mode":"gradient","unit_gradient_duration":70,"unit_switch_duration":70,"v":1000}]}', 'countdown_1': 0, 'music_data': '', 'control_data': '', 'sleep_mode': 'AAA=', 'wakeup_mode': 'AAA='}

This is the only place I see in the code that the work mode gets set. I’m not a python coder but I have been coding for 25+ years. Guess it’s time to learn it.

Tuya / light.py

7

I’ve had this issue, ever since 2021.9 of 2021.10. It’s driving me nuts. I’ve been searching to see if anyone has made a bugreport about this or how to do this myself, but kinda get lost as to where/how.

8

I found this issue filed on Github but looks like it is getting ignored. I added to the issue.

(Tuya RGBCCT bulb not switching to color mode from Google Home / Assistant · Issue #60476 · home-assistant/core · GitHub)

1 Like
9

Fixed this for me, thank you Nameless :slight_smile:

1 Like
10

I just found out.
You need to remove :

      brightness: 255

Example:

  name: Red
  entities:
    light.escri_1:
    #  supported_color_modes:
    #  - brightness
    #  - color_temp
    #  - hs
   #   - onoff
   #   brightness: 255
      color_name: red
      friendly_name: escri 1
      state: 'on'

Most of the code are “default” so no need to keep them.

The following examples will works

    light.corre_3:
      transition: 3
      color_mode: hs
      hs_color:
      - 360
      - 100
      friendly_name: corre 3
      state: 'on'

    light.corre_3:
      color_name: red
      friendly_name: corre 3
      state: 'on'

For brightness I’m making a separated scene:

    light.corre_3:
      brightness: 60
      friendly_name: corre 3
      state: 'on'
11

This has been driving me nuts the last few months as well… but I finally found a solution that has been working for me!

In the Tuya app, I created 2 tap-to-run scenes for each bulb or group of bulbs: one to switch the bulb(s) on and to color mode and another to switch on and to white mode (I added “turn on” as a safeguard - I didn’t feel like testing if the mode switch would work if I was turning lights on in HA vs switching colors with light already on). When triggering the scenes back and forth, the color mode automatically goes to the last color; the white mode goes to the last temperature.

I restarted HA and the new scenes created in Tuya appeared in the HA scenes list. Fortunately, I had set up my HA scenes as scripts - they’re more versatile. In automations and scripts, I can now trigger the bulb’s Tuya white or color scene in the sequence before setting the specific color/mired and brightness. I find I get more consistent results if I add a short delay after triggering the Tuya scene - right now I’m using 100ms.

I still need to set color/mired and brightness in separate events - setting both in one event doesn’t work - Tuya tends to set only one or the other.

It’s pretty ridiculous that the Tuya bulb need 4-5 events to set it: run Tuya color or white scene, delay, set new color or mired, then set brightness. I found that sometimes a 5th event - changing brightness before setting color mode - made for a more pleasant transition. A dim orange, for example, looks very green when bright. So if I’m transitioning from a brighter white color to dim orange, that split second of green is eliminated if I dim the white first. For some reason I still needed to set brightness after that - even though the brightness is the same, if I removed the final brightness setting, the final results were hit and miss again.

PS - I did try the suggestion to select the bulbs as devices instead of entities - that did not work for me either.

PSS - If you’re using scenes instead of scripts - whatever is triggering the scene could trigger the tuya white/color scene first. I can think of a few other creative work-arounds. I saw advice when setting up HA to skip the scene feature, using scripts instead, so it’s easy to add in other commands. I share the scripts with Alexa, and they are automatically labeled as and function like scenes.

12

Ok - ran into issues with a bulb on motion sensor that uses time of day to determine color or temp and brightness. Yesterday I focused on toggling from white to color - that setup when turning an off light on and changing mode didn’t work.

I ran a lot more tests and learned a lot watching the real-time state of the bulb in Tuya. Here are some lessons learned - and it seems that every mode/event type has some caveat/inconsistent behavior. Maybe these details can help resolve the issue one day so that working around it isn’t so complicated.

  • First thing to know: there are two occasions when Tuya MAY run its own processes, so if you HA triggers new settings too quickly, Tuya will run its process after that, immediately changing the bulb back to some other state. 1) Tuya has a “power on” setting for each bulb: last state, default state, or custom state. 2) When toggling between white and color mode, Tuya wants to reset to the last state when last in that same mode. Add~100ms delay into your sequence to allow Tuya do its thing before you send new directions.

  • You can read in my last post that you can create scenes in the Tuya app that switch bulb modes to white or color. It is necessary to set these up for both the white and color modes for each bulb or group of bulbs. Do not include “turn on” like I had suggested, though.

  • If you run a single event that identifies white temp and brightness: Tuya will follow the directions, regardless of the bulb’s last state when turning an off light on. But if changing an already on light from color mode, Tuya will usually change to white mode and set the temp, but will ignore brightness. Once the bulb is in white mode, running temp+brightness event will usually set both. It’s a safer bet to run color/temp and brightness in separate events, though.

  • The toggle routine described in my previous post failed when turning an off light to on because after running the brightness event, Tuya needed ~100ms delay to set its “power on” setting. Since I said setting brightness was optional, if the first event triggered Tuya’s scene to set the mode, it also failed because right after that Tuya would still run its “power on” setting.

  • An event that identifies both color and brightness may work, but will only consistently if the bulb’s last state was color. I’ve been able to transition from white to color after triggering events multiple times, but using the Tuya scene to officially toggle modes, this re-trigger nonsense has ended.

  • I also spotted that sometimes there’s a mode mis-match between HA and Tuya. When in color mode, if you trigger a very warm white OR used a color that is essentially a warm white, Tuya may switch to white mode while HA shows that the light is still in color mode. Since Tuya is in white mode now, you’ll see the same buggy behavior switching to color again.

  • Using the HA device UI (white mode slider and color mode wheel) always works. I curious what HA is sending Tuya when using this and why that can’t be mimicked in events or scenes.

After discovering all of this, I am using this following 6 events to set a light to color/white, which will work in every circumstance:

  1. Power on bulb identifying color/temp + brightness (under certain circumstances, this will set the bulb correctly; when it doesn’t the following events will fix it; if it does set, there is no visible affect to the bulb as the rest of the events trigger)
  2. Wait (for Tuya to run “power on” settings, just in case)
  3. Trigger Tuya scene (officially change color/white mode)
  4. Wait (for Tuya to revert to last state)
  5. Set color/temp
  6. Reset brightness (may be lost when reverting to last state; buggy behavior without it or when trying to pair with step 5)

Here’s a snippet of my code:

- service: light.turn_on
   data:
    color_temp: 460
    brightness_pct: 60
   target:
    entity_id: light.bath_tuya
- delay:
   hours: 0
   minutes: 0
   seconds: 0
   milliseconds: 100
 - service: scene.turn_on
   data: {}
   target:
    entity_id: scene.bath_white
- delay:
    hours: 0
   minutes: 0
   seconds: 0
   milliseconds: 100
- service: light.turn_on
   data:
    color_temp: 460
   target:
   entity_id:
    - light.bath_tuya
- service: light.turn_on
   data:
    brightness_pct: 60
   target:
    entity_id: light.bath_tuya
13

For whatever reason, my issue was setting brightness and color together at the same time, with tuya bulbs. For whatever reason brightness would just take precedence and make the bulb white, ignoring the color change.

14

Had this same problem. Found an alternative solution that makes the bulbs work as they should and locally.

Set up Local Tuya with HACS. Ensure you have the latest version (currently 4.0.1)

Add your bulbs as new devices with the following settings:
ID: 20
Brightness: 22
Color Temperature: 23
Brightness Lower Value: 0
Brightness Upper Value: 1000
Color Mode: 21
Color: 24
Minimum Color Temperature: 2701
Maximum Color Temperature: 6499
Scene: 25

5 Likes
15

I followed your script and it helped significantly. Thanks.
I also found another method that directly fixes the requirements for scenes and allows direct control in a single service call as it should be. It uses Local Tuya which takes a minute to set up. See my other post for more details. Thanks!

1 Like
16

Your method is the far superior solution!! It’s well worth taking the time to set it up - not only does it work with one service call as it should, but you also have the various effects available, including music. No need to use any scenes in the Tuya app. Thanks for sharing!

For others taking this on: To simplify the switch so that I didn’t have to update each automation, script, scene, and/or dashboard for each bulb, I first changed the original tuya light bulb name and unique ID, making sure NOT to allow updates to the automations they are in. Then, when I added the bulbs through Local Tuya, I named my devices so that the auto-generated unique ID would match the previous unique ID I had just changed. (Backstory: I had originally added _tuya to each of my tuya devices, using *_tuya in my alexa config to link only those devices to alexa - which only communicates with HA, not the tuya app.) Once the bulbs were added through Local Tuya, the matching unique ID then worked in all the previously created automations, dashboards, etc. Furthermore, they immediately work with Alexa - no need to reboot, find new devices, etc. I then went back and changed the names of my added Local Tuya devices to get rid of tuya in the name (so light.dining_light_tuya was back to being named “Dining Light” instead of “Dining Light tuya”. NOTE that when I first set up Local Tuya, I tried adding _tuya to the unique IDs after the fact, but that BROKE the connection through Local Tuya. Fortunately I was testing things with just one bulb first because I had to delete the integration completely (could not delete the non-working entity; deleting the integration and restarting HA cleared the error out, though) and start over, creating the bulb with the right unique ID from the get-go.

17

Thanks for this post. Not only for the idea of using LocalTuya, but also for listing the correct DP values to use. This worked for me and saved quite some time.

1 Like
18

This worked perfectly, was easy to set up too! Fantastic!
Thank you! - Should be pinned and highlighted