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

config_entry-tuya-01J59FD7RAWQ4KDPXCADH5MM4G.json

@frenck Sorry for the late reply. I forgot I commented on this

@frenck Hi. Just checking in to see if you've had a chance to look at the additional 7 .json diagnostics.

Can you provide an update?

Hope you had a good Holiday.

Running 2024.9.1. Still no progress on this.
I can't upgrade from 2024.3.3 due to this issue, and I can't upgrade my zigbee2mqtt either (dependency).
Unfortunately I did this unintentionally and as a result certain zigbee lights stopped responding.

Same with HA: in a fit of overconfidence I upgraded and my whole house was an amusement park (when dimming all the bulbs turned to color mode)

Downgraded again, but it is a bit ironic that Home Assistant claims to be a cloud-independent solution, and that I had to rely on the cloud Tuya app to control my lights at that moment...

Please, fix this. We really need a solution and I think this is not that hard as some smart people already pinpointed the root cause in the code.

Let me know if I can be of any help!

kind regards,
Bart

Just another user signing in, ever since #110327 Tuya bulbs with a single CCT chip are broken.

Same problem here.

Just another user signing in, ever since #110327 Tuya bulbs with a single CCT chip are broken.

Same problem here.

Remember to upload your diagnostic .json file for the Tuya Integration. Please.

Just another user signing in, ever since #110327 Tuya bulbs with a single CCT chip are broken.

Same problem here.

Remember to upload your diagnostic .json file for the Tuya Integration. Please.

Here you go:
config_entry-tuya-01J3QW7PE016BJH48GWZMS3VMJ.json

Just noticed that my Tuya garden lights constantly turn on with blue as default color instead of the warm white (which I configured last year winter). I'm experiencing the same issue and I've been unable to set the lights to (warm) white [color mode] via the different ways HA provides (device -> turn on light / Lights: Turn on -> select entitiy, tried to add some extra data, but wasnt succesfull / tried to force set the state via developer tools, didnt work).

Attaching my diagnostics file here as well for the affected device. Tried to set the correct color using the default (cloud based) Tuya integration.

tuya-3077369237d3a6a2922f767502c275a0-Tuinverlichting-c4485b26f5183b96b0043f45ccb732b1.json

I do see 'white' being a work mode in the json file, next to colour, but am not able to use/set it:

"work_mode": {
        "type": "Enum",
        "value": {
          "range": [
            "white",
            "colour",
            "scene",
            "music"
          ]
        }
      },

Looking into the issue to hopefully help anyone working on this.

First thing I notice is that the bulbs support "work_mode": "white", but neither the "function" nor "status_range" have the "temp_value" or "temp_value_v2" in them. This would prevent color_modes from having COLOR_TEMP, since find_dpcode would not be able to get the color temp details for it. I'm not sure if this is a bug or not for these bulbs since they technically don't support color temperature. They only have 1 temperature for the white mode. It is possible that whatever process creates the device info should add this info but with a max/min as the same value.

Additionally, I don't see anywhere in the TuyaLightEntity.__init__ where ColorMode.WHITE is added. I believe it probably should be added. This may not be necessary as long as COLOR_TEMP can be added for these bulbs without temp adjustability.

The light can never be changed to WorkMode.WHITE because the only way this can happen is in the turn_on function, but it is dependent on passing this check: if self._color_temp and ATTR_COLOR_TEMP in kwargs. self._color_temp will always be None because it was never set due to find_dpcode not finding the temp_value or temp_value_v2 values as described above.

Looking further, I thought I could find a workaround by deliberately bypassing the section of the turn_on function that adds a command to set the work mode to "colour", but I am unable to. I thought I could skip past the condition:

        if self._color_data_type and (
            ATTR_HS_COLOR in kwargs
            or (
                ATTR_BRIGHTNESS in kwargs
                and self.color_mode == ColorMode.HS
                and ATTR_COLOR_TEMP not in kwargs
            )
        ):

By performing a "Light: Turn on" action from the UI that did not set the hs_color, did set brightness, and did set color_temp like so:

color_temp: 2700
brightness: 125

I thought that even though self.color_mode == ColorMode.HS, because I sent color_temp: 2700, it would not pass this condition, and go to the next branch that would only send a brightness command.
It appears that this is not the case, because after performing this action, the color mode still gets set to "colour".

I expected it to not touch the color mode, leaving it as it was in the "white" mode before, and only sending the commands to turn on the light and to set the brightness.
Somehow, the color mode is still changing.
To me, this must be due to the color_temp: 2700 action data being ignored somehow, making ATTR_COLOR_TEMP not in kwargs return True, meaning that the colour work_mode command would be sent as well.
I am unable to figure out how the action is actually processed and what data ends up in the kwargs argument in turn_on. This would be very useful info to find the issue.

Another issue is that self.color_mode will always return HS because _fixed_color_mode is set to HS. This is because _attr_supported_color_modes only has 1 value due to filter_supported_color_modes removing ONOFF and BRIGHTNESS.

Other people have pointed to filter_supported_color_modes removing those modes as the root of the issue, but I believe this would not be a problem if COLOR_TEMP were correctly added to the list of color_modes. It seems that the point of filter_supported_color_modes is to narrow down which modes are actually "color" modes. BRIGHTNESS I think is "technically" not a "color" mode, because it's not a color, it's a generic (and is described as much in the light integration). Also, changing how filter_supported_color_modes would affect all integrations that use it, not just Tuya.

After looking at all this, I think one of the issues is that the device info, as shown in all the attached diagnostics, does not have the "temp_value" or "temp_value_v2". These bulbs are probably a special case though because they have the white work_mode, but do not support actually adjusting the color_temp. I would bet that somewhere during the device discovery, it chokes on the fact that the bulb has a white mode without a color temp, leaving out those details. Not sure though since IDK where that code is.
Alternatively, if it's not a problem for it to not have the temp_value, then the bulb needs to have proper integration for ColorMode.WHITE. The mode is never added to the color_modes during __init__, and is never handled in turn_on, since the work mode can only be set to white if the color_modes contains COLOR_TEMP.

I thought I could find a workaround by deliberately bypassing the section...

Can you explain in detail how you were able to override, the Tuya Integration with your changes?
I have tried to load an integration to override the Tuya integration, but I am unable to load it for testing.

I thought I could find a workaround by deliberately bypassing the section...

Can you explain in detail how you were able to override, the Tuya Integration with your changes? I have tried to load an integration to override the Tuya integration, but I am unable to load it for testing.

I was not able to bypass it. I thought I could by passing in the described action data, but it did not work. the bulb still changed to color mode.

I am very confused as to why it still changed to color mode though. I do not have visibility into what the kwargs contains at the time it gets to turn_on

I thought I could find a workaround by deliberately bypassing the section...

Can you explain in detail how you were able to override, the Tuya Integration with your changes? I have tried to load an integration to override the Tuya integration, but I am unable to load it for testing.

I was not able to bypass it. I thought I could by passing in the described action data, but it did not work. the bulb still changed to color mode.

I am very confused as to why it still changed to color mode though. I do not have visibility into what the kwargs contains at the time it gets to turn_on

Maybe my question wasn't 100% clear? I am wondering how you load the custom integration to be able to test any of these procedures.

Did you copy the entire Tuya component to the custom_components folder? If so, how did you load the custom component? Was it through HACS?

I am wondering how you load the custom integration to be able to test any of these procedures.

I did not do this. I was simply digging through the code to try to understand where the issue(s) could be.

I am wondering how you load the custom integration to be able to test any of these procedures.

I did not do this. I was simply digging through the code to try to understand where the issue(s) could be.

Ok. I've seen comments on other posts about "overriding" integration components but when attempting to override the Tuya, I am not successful.

I've been trying to install the integration from v3.3 (last working version) while maintaining the current upgrades to H.A.

I will see if i can install a custom version of tuya and then tinker with it. I would like to add logging to see more of what's going on.

I was able to add tuya as a custom integration and I added a log line to the beginning of turn_on like so:

import logging #at the top of the file
...
LOGGER = logging.getLogger(__package__) #at the top of the file after all the imports
...
LOGGER.warning("Tuya light.py kwargs: " + json.dumps(kwargs))

The output shows that there is no color_temp attribute in the kwargs, but the temp got converted to an HS color.
By performing action "Light: Turn on" from the developer tools with yml:

action: light.turn_on
target:
  device_id: bbd37b384fd7fa750f224ff0d61837ce
data:
  brightness_pct: 50
  kelvin: 2700

I get the following log statement:

2024-09-18 16:15:24.669 WARNING (SyncWorker_7) [custom_components.tuya] Tuya light.py kwargs: {"brightness": 128, "hs_color": [28.395, 65.723]}

With the relevant portion being the kwargs:

{
  "brightness": 128,
  "hs_color": [
    28.395,
    65.723
  ]
}

Somewhere, somehow, the kelvin attribute in the action is getting converted to an HS color (fairly accurately also, it's not random).

If i only pass brightness in the action data, then the kwargs only have brightness, as expected. But this will still set the work mode to colour because the color_mode is HS (due to only having HS as a color mode)
Action data:

action: light.turn_on
target:
  device_id: bbd37b384fd7fa750f224ff0d61837ce
data:
  brightness_pct: 100

Resulting kwargs in the logs:

{
  "brightness": 255
}

To answer your earlier question, how did I add Tuya as a custom integration? I saw this comment then Git clone'd home assistant core. Modified the light.py file and added "version": "0.0.1" to the manifest.json file. I then ssh'd to my home assistant, added a folder tuya in the /config/custom_components folder, and then copied (scp'd) all the files from the cloned repo's tuya folder (including the 2 modified files) to the custom tuya folder. Then I restarted HA and (after crossing my fingers), the integration automatically loaded! I can see that it's my custom one because on the Tuya integration page, it shows my version 0.0.1 and it has a "Custom integration" label on it. Then I viewed the logs in Settings > System > Logs (or if in ssh, they're at /config/home-assistant.log)

To answer your earlier question, how did I add Tuya as a custom integration? I saw this comment then Git clone'd home assistant core. Modified the light.py file and added "version": "0.0.1" to the manifest.json file. I then ssh'd to my home assistant, added a folder tuya in the /config/custom_components folder, and then copied (scp'd) all the files from the cloned repo's tuya folder (including the 2 modified files) to the custom tuya folder. Then I restarted HA and (after crossing my fingers), the integration automatically loaded! I can see that it's my custom one because on the Tuya integration page, it shows my version 0.0.1 and it has a "Custom integration" label on it. Then I viewed the logs in Settings > System > Logs (or if in ssh, they're at /config/home-assistant.log)

This is perfect. I'm going to try this now.
Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.

Hello again, I have been tinkering with it and I have a working solution at least for the bulbs that I have.
Please take a look at this draft PR: #126242

I do not have any Tuya bulbs that support color temp, so I can't be sure that I didn't break any existing bulbs.

I am requesting here that people pull my code and test it out if they can as an initial functionality review. I will then submit it as an actual (non-draft) PR on the dev branch and have it formally reviewed.
You can use this modified code as a custom integration using the process I described above.

Please provide feedback!!

Hope it works for you!

@wedsa5 Thank you for submitting this info. If you want a version of the Tuya Light Integration to compare to the current (broken) version, you can download the attached .zip file below. I'm not the best programmer in the world but I believe this has something to do with the broken version.

@bartplessers This info may help.

@frenck Please provide guidance... or ANYTHING. Communication is important and being left in the dark about a 6 month-old issue is very frustrating.

Thanks to @wedsa5 explaining step-by-step how to correctly override the integration, here is what I did to get my bulbs working while maintaining the most current updates from Home Assistant (2024.9.2).
NOTE: This is not for everyone. If you have only bulbs and are experiencing this issue, follow the steps below, or download the .zip file and proceed from step # 5. While this does not fix the issue of setting the light back to WHITE, at least they don't change color when I set/change the brightness.

1. Download the [core-2024.3.3](https://github.com/home-assistant/core/tree/2024.3.3) as a zip file.
2. Extract the files.
3. Navigate to \core-2024.3.3\homeassistant\components\tuya
4. Modify manifest.json to include "version": "0.0.2", (or whatever number you desire - 0.0.69?) at the bottom below the line "iot_class" (be sure to include a comma at the end). This is a requirement for "custom components" or overriding core components.
5. Copy the tuya folder that contains the files for 2024.3.3 with the modified manifest.json to your Home Assistant server /config/custom_components using the method above. I have created a shared folder via SMB and transferred through Windows Explorer (Settings -> Add-ons -> Samba Share).
6. RESTART Home Assistant and verify the version is now 0.0.2 (or whatever you chose in step # 4).
7. If your Home Assistant and/or Operating System is not up to date, you can update it to the most current version without it affecting your custom_component\tuya integration.

2024.3.3 Tuya Integration - tuya.zip

@Kelso-Utah, thanks for the more detailed instructions for adding the custom integration. This should help others when installing it.

Additionally, could you please install the code from my PR to test if you can use all the functionality of your bulbs? I would like to have the feedback. Please comment on the PR once you've tested it to give feedback on how it functions and if you have any comments on my code.

I'm not the best programmer in the world but I believe #115056 (comment) has something to do with the broken version.

I actually don't think this is the issue as i described in my earlier comment. excerpt:

Another issue is that self.color_mode will always return HS because _fixed_color_mode is set to HS. This is because _attr_supported_color_modes only has 1 value due to filter_supported_color_modes removing ONOFF and BRIGHTNESS.
Other people have pointed to filter_supported_color_modes removing those modes as the root of the issue, but I believe this would not be a problem if COLOR_TEMP were correctly added to the list of color_modes. It seems that the point of filter_supported_color_modes is to narrow down which modes are actually "color" modes. BRIGHTNESS I think is "technically" not a "color" mode, because it's not a color, it's a generic (and is described as much in the light integration). Also, changing how filter_supported_color_modes would affect all integrations that use it, not just Tuya.

I believe brightness should actually not be included in the color modes, because it's not a color, it's generic like onoff is.

That's why my PR adds code to add the color_mode white in addition to hs when the bulb supports white mode but not adjusting the color temperature.

If you have a bulb that does support color temperature, then your bulb should get the color_mode color_temp in addition to hs allowing it to function properly.
I do not have a bulb with adjustable color temperature, so if someone does, please install my code and test it

Hi @wedsa5 , @Kelso-Utah ,

thanx a lot for all your efforts on this! much appreciated.

#1
With the manual of @Kelso-Utah , I succeeded to combine the Tuya integration of HA-2024.03.03 into HA-2024.09.02
Everything works back again.

#2
I followed same procedure, but

• I took the code of the Tuya integration of HA-2024.09.02
• modified manifest.json
• took the file light.py from @wedsa5
• restarted HA

--> Tuya could not start anymore.

Error:

(...)
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/config/custom_components/tuya/light.py", line 28, in <module>
    from .entity import IntegerTypeData, TuyaEntity
ModuleNotFoundError: No module named 'custom_components.tuya.entity'

#3
So I compared the file light.py from @wedsa5 with that from HA-2024.09.02 and modified following

from . import TuyaConfigEntry
from .const import TUYA_DISCOVERY_NEW, DPCode, DPType, WorkMode
from .base import IntegerTypeData, TuyaEntity
from .util import remap_value

rebooted, and yezz, up-and running

Findings for now: everything works at first sight!!!!

Small issues:

• icon differs from bulbs with "white with CCT": (1)
  bulb "white with CCT":
  
  bulb "white only":
  

• when selecting white modus "w" on GUI, the bulb changes effecetively to white, but on the GUI, the (previous selected) color mode seems to remain selected: (2)
  
  It would be nice if the GUI would switch to "brightness" also

Apart from those minor issues, I'm sooooooooooooo happy there is finally some progress on this issue.
So, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you,

kind regards,
bartplessers

@bartplessers , thank you for testing this!! I'm glad to hear that the CCT bulbs are working as expected.

Regarding the icon differences, I think this is as expected. CCT bulb will get ColorMode.COLOR_TEMP and white only bulb will get ColorMode.WHITE. HA will put different icons for those since they are different.

As for clicking the "W" for the white-only bulb while still looking at the color picker, I see the same behavior. I agree that it should switch over to the brightness slider rather than still showing the color picker, I believe this is functionality independent of the Tuya integration and would be at the UI or Light integration and I dont see this as a bug.

Finally, can you explain exactly what you changed about my light.py file to get it to work? It looks exactly the same to me. If there is something to fix, can you leave a comment on the PR? Thanks.

I am going to move the PR out of draft status for an official review. I am not sure if I'm required to add tests or not, and I've been having issues getting my dev environment correctly setup, so we'll see how that goes.

Thanks again!

@Kelso-Utah, thanks for the more detailed instructions for adding the custom integration. This should help others when installing it.

Additionally, could you please install the code from my PR to test if you can use all the functionality of your bulbs? I would like to have the feedback. Please comment on the PR once you've tested it to give feedback on how it functions and if you have any comments on my code.

@wedsa5
I will have time late tonight to test your PR (about 10 hours from now). I will put on my thinking cap and investigate any issues I come across.

Additionally, I saw in this thread that someone noticed they had an issue with their garden lights. I think I recall seeing a section of code related specifically to garden lights (line 260 - Smart Gardening System).

Do you think that section of code is an issue like our CCT lights or do you think the changes you have proposed addresses their issue also?

Thanks again,
Kelso

Hi @wedsa5

Finally, can you explain exactly what you changed about my light.py file to get it to work? It looks exactly the same to me. If there is something to fix, can you leave a comment on the PR? Thanks

The file you provided on
https://raw.githubusercontent.com/home-assistant/core/e8c8f3d0f0a40e6bdda3a4918cb0dcafca6a44fc/homeassistant/components/tuya/light.py
contained

from .entity import IntegerTypeData, TuyaEntity

I had to change this to

from .base import IntegerTypeData, TuyaEntity

@Kelso-Utah, I believe my change will fix the garden lights as well. The attached diagnostic is similar to my lights in that they have the white work mode, but do not have temp_value so they should get the ColorMode.WHITE.

@bartplessers, interesting that you had to change that. I am going to leave that import as-is in the PR since I did not need to modify that line from the original file and chalk it up to an environment thing on your end. 🤷‍♂️

What's the status of the proposed fix?

Unable to test as I am not going to move into development. When will this solution be implemented / looked at. Very frustrating having all the downlights in the loft not working correctly in HA.

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