Colour control for light bulbs stopped working

[zonque]

The colour control for light bulbs used to work a few weeks ago, but no longer does. I traced what is reported by the API in support_color() and I see to following in self.data:

{
  "brightness": "255",
  "color_mode": "colour",
  "online": true,
  "state": "true",
  "color_temp": 1000
}

And hence the function will consequently return False. Controlling the colour works fine in the Tuya app however. Has the API changed? Let me know if I can I help debug this further.

[zonque]

Controlling the brightness still works fine, btw.

[xremix]

@zonque I experience the same issue. I got my light bulb pretty new, so I can't say if this worked before, but I tried to debug this on the HTTP-level and could see the same issue. When I discover my device I get the following response:

{
                    "brightness": "255",
                    "color_mode": "colour",
                    "online": true,
                    "state": "true"
}

When I try to set the color, I receive the following response:

{
    "payload": {},
    "header": {
        "code": "DependentServiceUnavailable",
        "payloadVersion": 1
    }
}

When I try to set the color temperatur (what seem to work for you?) I receive the following response:

{
    "payload": {},
    "header": {
        "code": "DependentServiceUnavailable",
        "payloadVersion": 1
    }
}

I appreciate any help.

[josemalena]

Same here!!

[JoelMSawyer]

I have also been experiencing this issue since mid-december, like many others.

[josemalena]

I used tuya-convert and now I use tasmota with MQTT and Hue Emulation, so I can use it with Alexa and Apple Home (vía Homebridge, but can be with Home assistant too) without internet and is faster!

On Thu, Apr 9, 2020 at 8:52 PM JoelS04 notifications@github.com wrote:

I have also been experiencing this issue since mid-december, like many others.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PaulAnnekov/tuyaha/issues/17#issuecomment-611821831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFBKG46UTCX3Y3DBWEXOMMTRLZUVZANCNFSM4KCAFVXQ .

-- José Alberto de la Cruz Malena (829) 696-6336

[StefanoGiu]

Same issue for me. Any update?

[StefanoGiu]

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

[StefanoGiu]

This is the API that is supposed to return the color, right?

{ "header": { "name": "QueryDevice", "namespace": "query", "payloadVersion": 1 }, "payload": { "accessToken": "TOKEN", "devId": "ID" } }

[xremix]

Yes and that stoped returning the color, as well as it cannot be set anymore.

[StefanoGiu]

This is the reply I got on Tuya website: "Hello, not all features are supported. All of our support is announced on github, if not, it is not supported"

[Faboor]

Setting colour still works, however it looks like that tuya stopped returning the color in the response, which is what is currently used to check support_color.

Using set_color() still works without issues. I don't know how to fix support_color. Maybe worth adding a override on HA side, but that feels kinda wrong.

[xremix]

Good that you said that @Faboor ! Indeed I double checked it and everything works like you said.

This is a sample JSON that can be sent to the lamp:

{
  "header": {
    "name": "colorSet",
    "namespace": "control",
    "payloadVersion": 1
  },
  "payload": {
    "accessToken": "???",
    "devId": "???",
    "color": {
        "hue": "40",
        "saturation": 255,
        "brightness": 255
    }
  }
}

Just brightness is getting ignored from my lamp, but this is exactly what I needed for my home automation.

[Faboor]

Hey, @xremix! Brightness gets ignored for me too when using set_color. Well, not entirely. As I wrote in #33, when setting the color to white, then values 100 and less set the "white mode" and values above 100 set "colour mode" with 0 saturation.

Why? Probably the same reason, why you can use "saturation" on the scale [0..1] or (1..255] interchangeably (although with the latter, 1.01 gets me 6% and there is no way of getting it lower - so I'd have to use 0.01 for 1%)

[PaulAnnekov]

@Faboor I don't have any tuya light device, so it will be nice if you will review this https://github.com/PaulAnnekov/tuyaha/pull/34 PR and decide whether to merge it.

[helldog136]

It seems that tuya changed his API without notice... The only solution i see (beside flashing with tasmota) is to try to reverse-engineer the available methods of the API (some of them seem to still be working...) and have, for example, a cache of the last set color for each light...

[zloi-litovets]

It seems there is the same issue for RGB bulbs in 'white' mode: no way to set colour temperature.

[xremix]

@zloi-litovets yeah same for me :(

[gadgetchnnel]

@PaulAnnekov @helldog136

I've tried the the light.py ffrom that PR, but it fails with the error:

File "/srv/homeassistant/lib/python3.7/site-packages/tuyaha/tuyaapi.py", line 44, in init
    self.discover_devices()
  File "/srv/homeassistant/lib/python3.7/site-packages/tuyaha/tuyaapi.py", line 118, in discover_devices
    SESSION.devices.extend(get_tuya_device(device, self))
  File "/srv/homeassistant/lib/python3.7/site-packages/tuyaha/devices/factory.py", line 15, in get_tuya_device
    devices.append(TuyaLight(data, api))
TypeError: __init__() takes 1 positional argument but 3 were given

I think this is probably because the init method in TuyaLight (which takes no parameters) is overriding the one in TuyaDevice (which takes data and api parameters). As I understand it, it should be something like this (so it will call the constructor on the base class):

class TuyaLight(TuyaDevice):
    def __init__(self, data, api):
        super(TuyaLight, self).__init__(data, api)
        self.last_hs_color = None
        self.last_brightness = None
        self.last_color_temp = None
        self.last_state = None

[StefanoGiu]

What about this warning?

2020-06-09 09:36:24 WARNING (MainThread) [homeassistant.components.light] Light is deprecated, modify TuyaLight to extend LightEntity

[helldog136]

@StefanoGiu this warning is for the HA component, not the python tuyaha library. It seems that this integration needs a good refactoring to follow the changes in the ha core.

[gadgetchnnel]

@StefanoGiu The standard Tuya integration in Home Assistant shouldn't give that warning. Are you using a custom component to override the standard Tuya component in Home Assistant? If you are, you should either remove it and use the standard one or change:

from homeassistant.components.light import (
    ...truncated...,
    Light,
)

to

from homeassistant.components.light import (
    ...truncated...,
    LightEntity,
)

and

class TuyaLight(TuyaDevice, Light):

to

class TuyaLight(TuyaDevice, LightEntity):

in /config/custom_components/tuya/light.py

[JoelMSawyer]

Colour control suddenly started working again for me - anyone else seeing the same? Looks like Tuya might have fixed their API?

[LouisMT]

I've been watching this issue since it was created, and it's sad to see that they're probably not going to add RGB support back to the API. I just sent an email to their support email address to ask about this, but probably they're not going to respond.

Now, all my other lights are using Zigbee, and recently Tuya started selling cheap Zigbee lights in the Netherlands (at LIDL). So I'll probably get some of those. The great advantage of Zigbee devices is that they can be controlled completely offline. So no dependency on third party APIs.

I hope they'll add RGB support back into the API for everyone waiting for this. Maybe if we all start sending emails. :)