fixed function support_color

[helldog136]

that wasn't working due to a change in the API

This broke of course HomeAssistant integration resulting in the color picker not showing because the SUPPORT_COLOR wasn't set.

I don't know if this breaks other lights but this fixes my Lumary LED Strip

[helldog136]

This could fix #17

[zonque]

It doesn't seem to suffice.

May 30 16:30:03 alarmpi hass[3314026]: Traceback (most recent call last):
May 30 16:30:03 alarmpi hass[3314026]:   File "/usr/lib/python3.8/site-packages/homeassistant/helpers/entity.py", line 284, in async_update_ha_state
May 30 16:30:03 alarmpi hass[3314026]:     self._async_write_ha_state()
May 30 16:30:03 alarmpi hass[3314026]:   File "/usr/lib/python3.8/site-packages/homeassistant/helpers/entity.py", line 327, in _async_write_ha_state
May 30 16:30:03 alarmpi hass[3314026]:     attr.update(self.state_attributes or {})
May 30 16:30:03 alarmpi hass[3314026]:   File "/usr/lib/python3.8/site-packages/homeassistant/components/light/__init__.py", line 414, in state_attributes
May 30 16:30:03 alarmpi hass[3314026]:     if supported_features & SUPPORT_COLOR and self.hs_color:
May 30 16:30:03 alarmpi hass[3314026]:   File "/usr/lib/python3.8/site-packages/homeassistant/components/tuya/light.py", line 50, in hs_color
May 30 16:30:03 alarmpi hass[3314026]:     return tuple(map(int, self.tuya.hs_color()))
May 30 16:30:03 alarmpi hass[3314026]: TypeError: 'NoneType' object is not iterable

[zonque]

So now, support_color() returns True but hs_color returns None, and homeassistant is not amused about that.

[zonque]

I just had another look at what is being returned from the API and it's really bogus. The mode reflects what is set in the Tuya smartphone app and toggles between colour and white. The brightness value however is the brightness I set in the white mode, and it isn't updated when the mode is changed to colour. The colour itself is missing altogether.

So there is simply no way of reading back or setting the colour with this API endpoint, and that needs fixing on the server side.

Now I'm wondering whether @PaulAnnekov or anyone else is in contact with the API provider, because after all, the API was apparently specifically designed for HomeAssisant.

[StefanoGiu]

I wrote many times to Tuya support center, I'm also in contact with one of their account managers, but they seem not to be willing to listen...

They are not interested in fixing this...

Maybe they should get more of those requests asking to fix their APIs from more users....

[helldog136]

Just sent them this last night:

Hello tuya team,

I fount this e-mail address because you are maintainer of the Following project : https://pypi.org/project/tuyapy/
But it seems outdated.
A fork has been created : https://github.com/PaulAnnekov/tuyaha to try to maintain it as best as possible.

The goal of this API was to provide integration for home-assistant with tuya devices. https://www.home-assistant.io/
Home assistant is used by many people accross the globe and it would be a great advantage for your company to maintain a full compatibilty of your services with this platform.

https://www.home-assistant.io/integrations/tuya/

You provide services to a large collection of IoT devices.
These devices can be connected with automations or other devices through home-assistant and by making so, this would encourage all the users of home-assistant to buy the products that integrate with tuya.

Please consider maintaining a fully available API (RESTFUL ?) so that your customers can easily control them via other softwares than a smarphone app.

Usually the best way to do this is provide an API token via your smartphone app when the user is authenticated.
This token can then be inserted in the home-assistant configuration and will be used to securely exchange HTTP messages via an endpoint that your servers expose.
At the moment it seems that the prvious implementation required to provide username and password directly to the python Library…
This, whilst working, is kind of a bad practice…

If you need help or want some advices on how to create such API I’m willing to help you !

Kind regards,

(Yes i'm treating them like they don't know what they're doing by explaining how an API key works)

[StefanoGiu]

The guy mantaining the code left Tuya company...

[helldog136]

In the meantime, my last commit should bring back some functionnalities for tuya lights without breaking anything. Please review it :)

(also it would be a good idea to add some form of unit testing to be sure that everything still works after a dev :D )

[PaulAnnekov]

@zonque can you test the last commit, please? Because I don't have a light bulb from Tuya.

[gadgetchnnel]

I mentioned this on the issue, but the constructor for TuyaLight should call the init method of the base class like this:

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

Otherwise, you get the error:

TypeError: __init__() takes 1 positional argument but 3 were given

I've tested it with that change and it works, but it will still give the error TypeError: 'NoneType' object is not iterable if Home Assistant hasn't been used to set the colour since last startup.

This looks like it can be possibly avoided by changing self.last_hs_color = None to self.last_hs_color = 0,0 so it has a valid (if wrong) colour value on startup.

[helldog136]

Done, i provided a valid default value for all "last_" variables.
They will be wrong at startup if tuya doesn't provide a value but will be correct as soon as the user uses this api to control his lights.

[scaytrase]

If you give me (or point to) some instruction how I can test the PR on my HA instance - I will be glad to help, since I have an RGB tuya (smart life) bulb.

I suppose I should replace some code in my instance, yes?

[JoelMSawyer]

I would also be happy to test, as I have several tuya RGB bulbs across multiple instances of HA. It would be brilliant if this could be resolved, as several users I introduced to HA were dissuaded by the lack of RGB control of tuya bulbs.

[helldog136]

I'm not exactly sure on how to test... I guess that the best way is to duplicate the tuya integration from HA core, place it in the custom_component folder along with the modified version of the python library.

By doing so i think that HA will take the custom_component version in priority instead of the one present in the core and thus use the modified version.

Never tried it though because i decided to migrate my RGB strip (only tuya device) to a shelly RGB.
I only wanted to create a good fix for other tuya users.

[scaytrase]

Looks like this patch does nothing for me. I've patch the runtime and deleted the __pycache__ from lib (didn't do this on previous msg, sorry for false alarm) and restarted the HA instance. After restart I've checked that patch is still applied but there is no difference for me in UI

[gadgetchnnel]

@scaytrase The way I understand it, this fix will return support_color as true if the light is in colour mode, so try either switching it to colour mode outside of Home Assistant (e.g. in the Smart Life/Tuya app) or by using a script in Home Assistant which turns it on to a specific colour.
(Also, the colour picker in Home Assistant will only show if the light is on).

[scaytrase]

so try either switching it to colour mode outside of Home Assistant (e.g. in the Smart Life/Tuya app)

wow, that worked! Yea, looks great! UI is still a bit unresponsive, but as far as I understand it's the problem of tuya integration itself

thanks @gadgetchnnel !

[scaytrase]

but looks like I found a problem. Picking white colour from the cirle turns off the colour mode, so I have to go back to app to restore it.

[StefanoGiu]

Is this fix updating the colour status in HA if I change che colour from Smart Life app? As I understand no, right? As the tuya API doesn't support it...

Btw I'm chasing one of the Tuya account manager and he promised me they are going to fix the APIs....

[scaytrase]

As I understand no, right

no, it's not

[helldog136]

Is this fix updating the colour status in HA if I change che colour from Smart Life app? As I understand no, right? As the tuya API doesn't support it...

Correct, it won't actualize data if the tuya API doesn't return it. if some day the tuya API returns that data, it will be returned as expected.

but looks like I found a problem. Picking white colour from the cirle turns off the colour mode, so I have to go back to app to restore it.

I suppose that when you put the light to "white" it switches from "colour" mode to "temperature" or something else. This will then tell HA that the bulb no longer supports "color"... I'll look at what i can do to fix this but this could be tricky...

[helldog136]

@scaytrase could you send me the content of self.data for the light when you put it on "color_temperature" mode? This would help me improve the cache for the cache of "color_temp_mode"

[TwoD]

Not sure if this is helpful but I've noticed that if I force my lights to use the larger brightness range (10-1000) in the integration settings in HA I can force them to switch back from color mode to white mode. If already in RGB mode you lower the brightness down to about 20-25%, then pick white (you'll get the semi-white from the RGB combination, but at a very low brightness value), and lastly increase brightness until it goes over to just white. Switching back to RGB just requires picking a color since the color wheel stays. ( I did not need to force color support except for some lights which did not announce it at all).

Once I did this it seems to remember the last brightness used in white mode and switching to it just requires selecting white on the color wheel.

I'm on the 2020.12.1 HA release with stock Tuya integration code.