core: New Tuya device not shown - due to brightness / color conflict

Here is my modified light.py from the Tuya component.

To use this, you will need to download the Tuya component from here and add the folder to your custom_components folder, replacing light.py with my modified version.

As a bonus, here is another version which also maps brightness levels if, like me, you have Tuya bulbs which only support brightness levels of 29-255 instead of the full range of 1-255 (setting the brightness to 28 or less turns the light off). This code maps brightness levels from to 0-255 range to the 29-255 range when setting brightness and vice versa when retrieving the brightness. The mapping isn’t exact, and sometimes the retrieved brightness will not quite match what you set it to (which I think is due to the Tuya API actually using percentage brightness) but I find it is close enough.

Any progress on this? Where can I donate money to get this fixed 😂

@G33kDude Thanks for that, that allowed me to to get it working without errors. The only issue being that Home Assistant can’t keep track of what the colour is set to.

I worked around this (in a rather hacky way) by downloading the Tuya component and adding it to the custom_components folder with the following changes to light.py

Change from . import DATA_TUYA, TuyaDevice to from . import DATA_TUYA, TuyaDevice, DOMAIN

Change the hs_color property to this:

@property
    def hs_color(self):
        """Return the hs_color of the light."""
        if "entity_data" in self.hass.data[DOMAIN] and self.tuya.object_id() in self.hass.data[DOMAIN]["entity_data"]:
          return self.hass.data[DOMAIN]["entity_data"][self.tuya.object_id()]["color"]
        else:
          return tuple(map(int, self.tuya.hs_color()))

and in the turn_on method change this:

        if ATTR_HS_COLOR in kwargs:
            self.tuya.set_color(kwargs[ATTR_HS_COLOR])

to this:

        if ATTR_HS_COLOR in kwargs:
            self.tuya.set_color(kwargs[ATTR_HS_COLOR])
            if not "entity_data" in self.hass.data[DOMAIN]:
              self.hass.data[DOMAIN] = {"entity_data": {}}
            self.hass.data[DOMAIN]["entity_data"][self.tuya.object_id()] = {"color": kwargs[ATTR_HS_COLOR]}

This keeps track of the current colour in hass.data. This will obviously only work if you only control the lights through Home Assistant.

Welp, rather than bothering with patching, just replaced the light.py file with yours and things are honkey dory. Color changing works and they always show up too. Pretty good patch if you ask me 😃

I am running Hassio through Hassbian, so you will just need to ssh into it, then get inside your homeassistant container: sudo docker exec -it homeassistant /bin/bash Then navigate to /usr/local/lib/python3.7/site-packages/tuyaha/devices/ backup the light.py that’s there and replace the light.py with G33kDude’s above. Restart HA and you are all set!

Copy of my notes from duplicate issue #30007, with a patched tuya api light file (light_patch.py) to re-enable color settings for tuya lights (though it force-shows color settings for all tuya lights whether they support color or not).

Best I can tell, the Tuya home-assistant API is not returning color information anymore, and HA gets confused by seeing a color capable bulb without color status information.

I was able to get most of the functionality back by patching /usr/local/lib/python3.7/site-packages/tuyaha/devices/light.py to handle missing color information more gracefully and override all bulbs to assume color capability (originally determined by presence of color information). However, it’s not a perfect patch. The missing bulbs will become visible again, but all Tuya bulbs will show a color picker even if they’re not colored bulbs.

Here’s a diff of the original file vs my patched file (light_patch.py)

geek@homeserver:~/docker/homeassistant$ diff light.py light_patch.py
15c15
<         if work_mode == 'colour':
---
>         if work_mode == 'colour' and 'color' in self.data:
23c23
<         if work_mode == 'colour':
---
>         if work_mode == 'colour' and 'color' in self.data:
29,32c29,30
<         if self.data.get('color') is None:
<             return False
<         else:
<             return True
---
>         # Override color support
>         return True
41,43c39,42
<         if self.data.get('color') is None:
<             return None
<         else:
---
>         # Override color support
>         #if self.data.get('color') is None:
>         #    return None
>         #else:
45c44
<             if work_mode == 'colour':
---
>             if work_mode == 'colour' and 'color' in self.data:

I’m running HA through docker-compose, so I’ve applied this patch by specifying a new volume in the docker-compose.yml that overlays the patched file (light_patch.py) on top of the original library file.

version: '2'
services:
  ha:
    image: homeassistant/home-assistant:stable
    volumes:
      - ./config/:/config/
      - ./light_patch.py:/usr/local/lib/python3.7/site-packages/tuyaha/devices/light.py
    environment:
      - TZ=America/New_York
    restart: always
    network_mode: host

Once the change to docker-compose.yml was in place, I had to remove and recreate the container docker-compose rm --stop && docker-compose up -d (⚠️ If your config volume isn’t configured correctly this could drop all your HA data). When the web interface came back up my lights were visible and controllable again.

Once the root cause is resolved you will need to remove the patch. It is a temporary stop-gap until something more permanent comes along. In my setup that will involve me removing the volume line I added to docker-compose.yml and then recreating the container again.

If you just need the color or brightness parameter, in your customize section just add something like this:

light.8859gf59329894c: supported_features: 49 That will add color palette to your light, for other setting look this post: https://community.home-assistant.io/t/device-supported-features/168499

Le lun. 6 juill. 2020, à 13 h 12, skynet01 notifications@github.com a écrit :

Any update on this or word when a patch might be available?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/28602#issuecomment-654361592, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPIGULV2LEQM7FIKAPLYMLR2IAXFANCNFSM4JKDEQAA .

There is the Status API offered by tuya.

GET /v1.0/skills/devices/{device_identity}/status

I think this is the key to retrieve the current color value…

https://docs.tuya.com/en/iot/open-api/api-list/api/skill-service?id=K95zu0id1md0g

Hello, I got this reply from tuya about the color issue…

Copy to clipboard Hello, that’s because color_mode is based on work_mode [“white”, “colour”,] to get the value. The string of code I provided to you above is to get the color: { “header”: { “name”: “colorSet”, “namespace”: “control”, “payloadVersion”: 1 }, “payload”: { “color”: { “hue”: 0, “saturation”: 0, “brightness”: 1 }, “accessToken”: “token”, “devId”: “devId” } } Does it help to understand the issue?

I applied the fixes suggested here, but HA is not able to read the original status of the light and its color (it only stores the new color when changed from HA, but it’s not able to read it if changed from somewhere else…)

Hi sir, I’ve had same issue, and I tried to modify line 15 like you did but I didn’t find script : light.py in the location that is mentioned in log: /usr/local/lib/python3.7/site-packages/tuyaha/devices/light.py? if you have any idea how can I reach this path I appreciate it if you show me how. I’m using hassio image , I think is a docker but I don’t get any clue to get to the hypervisor to update this light.py

I’m not using hassio, but a manual installation, so the path is relative to your base directory (which I don’t know for hassio) - to get started: if you’re connected via ssh you can try installing locate and try to find the installation path by:

apt install locate
updatedb
locate tuyaha

If you already know the base directory you can cd there and try find tuyaha or directly find <yourbasedirectory> tuyaha (Hint: you might have to add sudo in front of every command, depending on the user you are connected to.) For editing via samba-shares, … sorry, I don’t know the layout, but I assume the installation (and that’s what your looking for) is not shared there.