extra info: after some investigation, I noticed that this problem only occurs with Tuya lights that only support [white + color]
I have some other Tuya bulbs that support [white with colortemp + color], here the above problem does not occur...

set to White (CCT in Tuya App)

Are you sure this light has the capability to change color temperature? Or does it have only white + color?
In my experience:

• lights with (white + CCT, and RGB) do not have any problem
• lights with (white and RGB) experience the above problem

Seems that HA is not aware anymore of the white capabilities of the bulb if it does not support colortemp (CCT)

Hi everyone,

I installed a previous version of HA (2023.3.1) on my proxmox server. Here this problem does not occur.

On following screenshot:

• left image: HA 2024.3.1
• right image: HA 2024.4.2

What I did:

• in HA changed color of the bulb to blue
• in TUYA-app, I changed back to white

Version 2024.3.1: shows the correct state of the bulb
Version 2024.4.2: state of bulb is NOT updated and remains blue

In example, following screenshots from my Tuya app

TYPE 1

This bulb supports white with CCT and color:

You can see that you can select a warm white on the left side of the arc, and a cool white (more blue) on the right side of the arc. The light still remains in “white modus”, but you can modify the correlated color temperature (CCT)
Beside this, you can also choose the “color modus” (on the top, select “kleur”).
In that case, you can choose any RGB color that you want

TYPE 2

This bulb only supports white and color:

You can see that there is no difference in color temperature in the arc. The white modus supports only one temperature of white.
Beside this, you can also choose the “color modus” (on the top, select “kleur”).

The problem we are dealing with does only occur on bulbs of type 2.
As far as I can see on your screenshot, is that in your “CCT” modus, there is no possibility to change the color temp. It seems that you can only activate one colortemp. So it looks like it’s also a “type 2” bulb.

FYI @Kelso-Utah
I downgraded to HA 2024.3.3
This version has no problems with this kind of Tuya lights

Here is some other interesting thing:
I have 2 concurrent instances of HA running on my ProxMox server. Both have the Tuya integration running

What you can see here: same light, but other version of HA:

HA 2024.3.3

HA 2024.4.2

So it seems that HA 2024.4.x does not recognize the "brightness" modus of this tuya bulb!

I got same problem.

Created a new issue on
tuya/tuya-home-assistant#987

Yup, I started suffering from this recently, "supported_modes" comes back only with "hs", whereas a few weeks ago it was coming back with "brightness" as well. Except even then I couldn't actually change to "brightness" from turn_on - once HA set the light to "hs", it was stuck in "hs". Now it's stuck in "hs" every single time I make any sort of change from HA.

I am suspicious of 770e48d.

With 770e48d, it looks like WORK_MODE must be "white" to get brightness. How do I work out what device.category is of my particular devices?

EDIT: looks like category == "dj" from device info > device diagnostics.

And I can see data.status.work_mode = "white" whenever the tuya app was the last set to white, and HA hasn't come along and fiddled with the settings yet. Alas, as soon as HA fiddles with the brightness (not just power - power toggle leaves the settings as they were), data.status.work_mode reverts to "colour" (I praise the developers for their proper spelling of "colour").

I can't find a way of getting work_mode back into "white". Also, the GUI can't do it, which tells me it's not my fault.

device info > device diagnostics
Same light, same integration, different versions oh HA:

2023.3.3

tuya-2023.3.3.json

2024.4.3

tuya-2024.4.3.json

@spacelama
With 770e48d,

To me it seems that following logic is missing in latest version

hi @emontnemery, @kamaradclimber, @lellky , @Orhideous , @MartinHjelmare

Do you mind taking a look at this issue?
I have a feeling that this problem was introduced with
#110327
resulting in
770e48d

Hi!

Sorry, but I don't think I can help. I review the linked PR, but I have no understanding of the inner workings here.

/Lellky

FYI. Problem still exist in 2024.4.4

hi @homeassistant , is there any way to add the label "integration: tuya" to this issue? On other issues, I see

Maybe the bot is not triggered because initialy I forgot to mention the integration in the OP...?

Experiencing this issue and it's only for lights that have white +RGB (no white temperature). Since upgrading to 2024.4, five of my lights only show HS colour mode and randomly go to the RGB lights when triggered by HA. The tuya app can change them back to white but goes back to RGB due to HA (even when the automation is only to turn on with no other settings)

same problem on 2024.5.0

Please can somebody give this some attention.
I'm also using zigbee2mqtt. There is a new release https://github.com/Koenkk/zigbee2mqtt/releases/tag/1.37.0 but ...
this release requires at least Home Assistant 2024.4.

I really want to upgrade, but this tuya issue prevents me from doing this :-(

Hi @Kelso-Utah ,

What do you exactly mean with Smartlife integration?
On my phone, I can use the Smartlife app and use this instead of the tuya app.
But on homeassistant, I can't find any smartlife integration.

So I'm a bit confused...

Hi @Kelso-Utah ,

thanx for pointing me in the good direction!
I managed to set things up in my test evironment...

The Good

• Indeed, with the smartlife integration, at least I can dim my lights again from within HomeAssistant without having them switched to color mode
• the smartlife integration can be installed in coexistance with the tuya integration

The Bad

• I needed to remove my problematic bulbs from the tuya app and add them into the smartlife app.

The Ugly

• the smartlife integration: "(...)This project has now officially been integrated into the Home Assistant official project core repository, corresponding to version 2024.2. This project will no longer continue to iterate (...)"

So it was good testing this, but it can't be the final solution.
However, maybe it can give some more background information to the developers that are willing to debug this issue.

Thanx again,
kind regards,
bart plessers

2024.5.1
Problem still exists.

I need some Xanax

the issue must be fixable, it's only become and issue recently.

I have a feeling that may be the cause
Simplify color mode logic in Tuya light (#110327)
resulted in
770e48d
and introduced in 2024.4.0b0

I think this is missing now:

However, I'm not a developer, otherwise I would revert this change and see what happens...

I too experience this since starting HA server right at version 2024.4 so I therefore never saw the White mode in those. In fact, it caused me some grief trying to figuring out what I was doing wrong until some search indicated the issue to be a newly introduced bug.

In Tuya, there is a specific tab for me to set White mode and brightness while the other allow color selection. The bulb switch automatically that way. If I use tuya to open white 80%, all is fine and I can switch to any color/level or use scene. In Tuya I can do any color and brighness but cannot activate while mode, when trying the bulb light up yellow 100% (which is way dimmer than white mode).

If I set the bulb in white in Tuya than only use Toggle/On/Off in HA it will allow to switch. But changing any parameter in HA cause the bulb to go into color mode instead without being able to return to white mode from within HA trigger. It just seem that White mode is not exposed to HA.

Zak

Given the fact that all of my Tuya bulbs are affected by this, this is extremely annoying. Had to downgrade to core 2024.3.1 to make this all work.

Would it be possible to fix this by some other way? Create a custom script or whatever that takes care of the Tuya bulbs?

I'm currently using 12 Gosund WB4 bulbs soooooooo yeah.

Has anyone had any luck setting up local Tuya with these?

2024.5.3. Still same problem

@bartplessers , since no one's actively working on the problem, updating this issue at every single release isn't going to achieve anything other than contribute noise to the issues database. I did briefly look at reverting the commit we brought into question, but reverting that and likewise going back to the previous version of the code didn't fix the problem for me, but I'm not yet confident that I was correctly running the code in my testing container.

but I'm not yet confident that I was correctly running the code in my testing container.

can you investigate this further?

I'm not a developer, but not afraid of VSCode and git. Is there a good newbie tutorial how to revert that piece of code and run it in a sandbox?

Grtz
Bartplessers

Tested on TY-02-4CH (RGBW controller) and works well

Looks like the issue is still ongoing, as no updates to Tuya integration seems to fix it.

For anyone waiting on this fix, I would just recommend installing my code change as a custom integration as described above until it is approved, merged, and released. It seems it can take a long time to get bugfixes merged.

Hey There,
I've just installed home assistant a few days ago, but I had the same problem as you all. Thanks to the fix you posted, I tried to install the fix, but it doesn't seem to work.
I followed the instructions of @Kelso-Utah and also tried to use the fix that @bartplessers used with @wedsa5 's code.
In Both cases I got an error and the protocol states the folowing.

Logger: homeassistant.config_entries
Quelle: config_entries.py:584
Erstmals aufgetreten: 19:22:39 (1 Vorkommnisse)
Zuletzt protokolliert: 19:22:39

Error setting up entry e@mail.com for tuya
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 584, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/tuya/init.py", line 93, in async_setup_entry
await hass.config_entries.async_forward_entry_setups(entry, PLATFORMS)
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1959, in async_forward_entry_setups
await integration.async_get_platforms(platforms)
File "/usr/src/homeassistant/homeassistant/loader.py", line 1156, in async_get_platforms
import_future.result()
File "/usr/src/homeassistant/homeassistant/loader.py", line 1156, in async_get_platforms
import_future.result()
File "/usr/src/homeassistant/homeassistant/loader.py", line 1156, in async_get_platforms
import_future.result()
[Previous line repeated 13 more times]
File "/usr/src/homeassistant/homeassistant/loader.py", line 1144, in async_get_platforms
platforms.update(self._load_platforms(platform_names))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1069, in _load_platforms
platform_name: self._load_platform(platform_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1243, in _load_platform
cache[full_name] = self._import_platform(platform_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1275, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/util/loop.py", line 144, in protected_loop_func
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/importlib/init.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 1387, in _gcd_import
File "", line 1360, in _find_and_load
File "", line 1331, in _find_and_load_unlocked
File "", line 935, in _load_unlocked
File "", line 995, in exec_module
File "", line 488, in _call_with_frames_removed
File "/config/custom_components/tuya/light.py", line 26, in
from . import TuyaConfigEntry
ImportError: cannot import name 'TuyaConfigEntry' from 'custom_components.tuya' (/config/custom_components/tuya/init.py)

I hope somebody can figure this out because I'm way to uninformed.
Thanks

Hey There, I've just installed home assistant a few days ago, but I had the same problem as you all. Thanks to the fix you posted, I tried to install the fix, but it doesn't seem to work. I followed the instructions of @Kelso-Utah and also tried to use the fix that @bartplessers used with @wedsa5 's code. In Both cases I got an error and the protocol states the folowing.

Not sure about that issue, but do you have all the following files in your tuya directory in the custom_components?

__init__.py
__pycache__
alarm_control_panel.py
binary_sensor.py
button.py
camera.py
climate.py
config_flow.py
const.py
cover.py
diagnostics.py
entity.py
fan.py
humidifier.py
icons.json
light.py
manifest.json
number.py
scene.py
select.py
sensor.py
siren.py
strings.json
switch.py
util.py
vacuum.py

Not sure about that issue, but do you have all the following files in your tuya directory in the custom_components?

__init__.py
__pycache__
alarm_control_panel.py
binary_sensor.py
button.py
camera.py
climate.py
config_flow.py
const.py
cover.py
diagnostics.py
entity.py
fan.py
humidifier.py
icons.json
light.py
manifest.json
number.py
scene.py
select.py
sensor.py
siren.py
strings.json
switch.py
util.py
vacuum.py

Oh, that could be the problem. In didn't change anything in the folder I downloaded, but the things that were said in this thread.
But still there are some files missing.

Missing Files:
pycache
entity.py
icons.json

Where do I get these?

dont worry about pycache. all the files should come from the main homeassistant core repo. then you just need to copy the modified light.py file from the PR, and update the version in the manifest json file.

Thanks for the Files. I added all of them, but it seems like the issue is still there.
But the error protocol got way shorter.
It now sas:

Logger: homeassistant.config_entries
Quelle: config_entries.py:584
Erstmals aufgetreten: 20:59:46 (1 Vorkommnisse)
Zuletzt protokolliert: 20:59:46

Error setting up entry e@mail.com for tuya
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 584, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/tuya/init.py", line 86, in async_setup_entry
device_registry.async_get_or_create(
TypeError: DeviceRegistry.async_get_or_create() got an unexpected keyword argument 'model_id'

Maybe you see the error here.

i am not sure... is HA updated to latest version?

I think so, on my updates page is nothing shown.
But I wouldn't be sure because I'm using Home Assistant as a docker and not Home Assistant OS.

Hi. Is there maybe a solution now integrated in recent 2025 version?

Hi. Is there maybe a solution now integrated in recent 2025 version?

Proposed fix is still not merged: #126242

Please put a 👍 on it

@wedsa5 did you say you had a short fix for this I have the same problem currently works through Alexa, but on the Home assistant dash ive limited it to only turn on turn off options on all my lights

Looks like it is finally under review...

@arturkonczalski where you seen this, I tried to do the Tuya local but I have over 100 bulbs would just take too long where Alexa does it anyway

Looks like it is finally under review...

#126242

Nothing has changed on this?

@arturkonczalski where you seen this, I tried to do the Tuya local but I have over 100 bulbs would just take too long where Alexa does it anyway

#126242

Looks like it is finally under review...

#126242

Nothing has changed on this?

Yeah, very little and slow progress...

Nope, it's been showing that for months, and no attempts to prod frenck in the pull request itself has been seen.

I actually suspect this is github at fault. Github user notifications are awful - I encountered this for my own projects, not getting notifications that people have opened up bugs against my stuff, or commented on existing bugs. You can't really tune what notifications are sent. One project whose list I'm subscribed to spams its notifications to my github inbox. I go to watch a particular bug in that project and find it thinks I'm already subscribed to it. No, no I'm not github!

I could easily see that someone isn't getting notifications for comments on some individual pull requests that person has responded to in the past. Once a notification drops below all your other notifications, you'll never see it again, and what's 1 open pull request waiting for your input against 1000 others?

(At least I hope it's not because he's employed by the competitor of Tuya)

I think it’s more insane that only one person can approve something like this, given the scale of the HA project.

Trying Why is a Pull request for a fix taking so long? in the community forum.

Trying Why is a Pull request for a fix taking so long? in the community forum.

Ah thankyou! So we're not waiting for frenck (won't tag him because: ) he's not maintainer responsible for tuya after resigning from tuya maintainership.

Pull request 133921

So @tuya, where are we now?

Seems it was counterproductive to bring the tuya plugin development under the umbrella of the home assistant project however. When this was an external integration, weren't bugs fixed?

So we're not waiting for frenck (won't tag him because: )

Ah, there is the problem, as frenck is tagged as responsible here...

@wedsa5 : HELP!
I upgraded today to HA 2025.3.2
I used your fix for my tuya lights
However, after upgrading "some" lights do NOT get update status from Tuya.

So my current situation is

a light that supports brightness and white with color temp (but no color)
I can turn light on/off with tuya app
I can turn light on/off with official tuya integration in HA
I can toggle light just once with your tuya hotfix integration because
when I reload custom integration: status of lights is correctly displayed in HA
I toggle light in HA --> light will effectively be toggled
but the new status is NOT reflected anymore in HA
This behavior does not occur in the official Tuya integration.
(but there the original problem stil remains: light with color, but no colortemp can not be dimmed )

So I'm a but stuck now :-(
I downgraded HA, and found this problem was introduced in HA2025.3.0. On HA2025.2.5 your fix is still working...

Would you mind taking a closer look at this?

kind regards,
bartplessers

@wedsa5 : HELP! I upgraded today to HA 2025.3.2 I used your fix for my tuya lights However, after upgrading "some" lights do NOT get update status from Tuya.

#126242

Is it possible that this could be fixed with Xtend Tuya (https://github.com/azerty9971/xtend_tuya) instead?

Is it possible that this could be fixed with Xtend Tuya (https://github.com/azerty9971/xtend_tuya) instead?

I tried installing Xtend Tuya and it didn't correct the issue. I also tried using Local Tuya to manually link with a non-color-control white setting, which actually didn't seem to exist at all in the Tuya Development portal. It makes me think that Tuya dropped support for that altogether, although it does still work in their Smart Life app.

I didn't mean to imply Xtend Tuya fixes the problem as-is. I mean could the fix be implemented in Xtend Tuya.