Well, I’m glad someone got a patch working but I just went with the nuclear option and used tuya-convert to flash Tasmota on my bulbs. Now they’re all controlled locally with MQTT so I don’t have to deal with their cloud nonsense. They have color control back and work much snappier now.
1 Like
I’m about to rollout Tasmota too. This is one of the 2 devices in my house that aren’t locally controlled and both have issues with broken cloud crap.
Sounds like you already researched it but I’ll drop you a couple links I found helpful. Here’s a list of Tasmota templates for different devices. After you apply the template and configure the MQTT just follow the instructions here to get it integrated with the Home Assistant MQTT addon. Also there’s some interesting stuff in the list of commands worth looking at.
1 Like
I have spent the past 24 hours trying to get this to work, I know it is something I am doing.
I cannot run sudo, as my login is not in the sudo group. as it is hassio I cannot access as root via ssh. I have installed the ssh plugin and that does not let me execute docker exec -it homeassistant /bin/bash.
getting desperate now, as I have so many automations based on the lights.
is it possible to run tuya convert without an RPI?
Yes it is. Follow the documentation and use kali linux in a VM.
Maybe via WinSCP? But if you don’t have sudo you may hit the same roadbloack.
Perhaps you can you use the Samba component in Hassio?
For Hassio, i ran into the same issue that took lots of research and unfortunately no luck with the methods mentioned above or too much of a headache for it to work. However, it was helpful and I did find a workaround with some of the info from above but in my own learning.
FYI, This does not fix the lovelace ui color picker but allows my automations, states to work and now shows up available every reboot and that is what i truly care about.
On your hassio instance, go to the /config/custom_components/ either via standard ssh 22 or samba. Create /config/custom_components/ if you dont already have one. Here is the documentation that references hassio method of overriding the env.
https://developers.home-assistant.io/docs/en/creating_component_loading.html
Once you have done that, clone/download the home assistant git repo anywhere you choose. We just need to get the tuya directory from the page.
copy over the tuya entire directory to hassio /config/custom_components/ Should look like this afterwords.
/config/custom_components/tuya# ls -al
total 60
drwxr-xr-x 3 root root 4096 Dec 26 14:12 .
drwxr-xr-x 10 root root 4096 Dec 26 14:09 …
-rw-r–r-- 1 root root 5077 Dec 26 14:08 init.py
drwxr-xr-x 2 root root 4096 Dec 26 14:12 pycache
-rw-r–r-- 1 root root 4667 Dec 26 14:08 climate.py
-rw-r–r-- 1 root root 1685 Dec 26 14:08 cover.py
-rw-r–r-- 1 root root 2696 Dec 26 14:08 fan.py
-rw-r–r-- 1 root root 4392 Dec 26 13:55 light.py
-rw-r–r-- 1 root root 198 Dec 26 14:08 manifest.json
-rw-r–r-- 1 root root 902 Dec 26 14:08 scene.py
-rw-r–r-- 1 root root 183 Dec 26 14:08 services.yaml
-rw-r–r-- 1 root root 1134 Dec 26 14:08 switch.py
Replace the light.py with the following light.py that @gadgetchnnel was kind enough to supply.
once you replace it restart home assistant and you should see that error go away and you will no longer receive the unavailable for your lights like we have been for the past week or two.
Hopefully you find this information helpful/gets you by with what you need to get done.
2 Likes
This worked for me, thank you.
@terkman how did you do it? I copied the tuya folder in my custom components folder and replaced the lights.phy with the one above. I’m not getting the device nonresponsive error any longer but if the lights are any color other than white I can’t control through HA. Am I missing something?
Are you getting anything in your logs that may be related? Nothing comes back when you to try to change them from white either?
If they are white everything works fine. If they are a color the lights don’t respond.
2019-12-29 22:44:03 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 286, in async_update_ha_state
self._async_write_ha_state()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 327, in _async_write_ha_state
attr.update(self.state_attributes or {})
File “/usr/src/homeassistant/homeassistant/components/light/init.py”, line 418, in state_attributes
data[ATTR_BRIGHTNESS] = self.brightness
File “/config/custom_components/tuya/light.py”, line 46, in brightness
if self.tuya.brightness() is None:
File “/usr/local/lib/python3.7/site-packages/tuyaha/devices/light.py”, line 16, in brightness
brightness = int(self.data.get(‘color’).get(‘brightness’) * 255 / 100)
AttributeError: ‘NoneType’ object has no attribute ‘get’
Just realized mine are all not working either. I can change them in Tuya app but just showing brightness control in HA. May have to Tasmosizes them.
I had these problems and did get them working again with the new version of the script, but who knows when it’ll break again. I bit the bullet and learned how to use tuya-convert to get them out of the cloud, on my network, and working with HA. I have to say they work 10x better this way. Response time for a manual toggle is before my mouse has returned up from the click.
That database @colecooper mentioned is an amazing resource for finding your bulbs. I had three models that were not in it, but was able to get them working and submitted templates to the site to help out others.
I’m in the process of doing my smart plugs now, but don’t know if I’ll do my wall switches because I’d have to pull them out to get model numbers off the backs. They work well enough in the cloud… for now.
Switched to esphome, after successfully getting tuya-convert to work. Work flawlessly now as well as having access to programmable effects!
I wasn’t getting color support but the icons changed to white so I knew it was doing something.
I slightly changed @gadgetchnnel 's file a tiny bit to force color support, and to stop any attempt to read the color data from tuya, which was causing an error. (basically just commented out a couple of lines that were causing issues for me).
Here’s the file that is working for me: https://gist.github.com/bradcrc/edb40a157ab44215f37b2b81312306d6
Using the method from @nkreadly07 after a few tries everything seems to be working great for me now.
I have color support again and all my automations and color work fine.
I’ve disabled my google and alexa integrations with tuya, so the bulbs are controlled through home assistant even when using voice control with alexa or google and things seem to work ok.
Just sharing the file with these slight changes in case they might help someone else.
6 Likes
Thanks for sharing that fixed my problem with color support!
1 Like
I copied your file to mine. It does bring up the color picker but once i select the color the light changes but then becomes unresponsive until i change it back to white in the original app.
bummer 
Just tested my setup again and it’s still working for me. Perhaps different bulb types work differently? That behavior sounds like what was happening in the original setup for me before adding the custom_components folder.
Only other advice I can offer is check your Home Assistant logs, they can be useful in showing exactly what isn’t working right.
Has anyone successfully fixed the Lovelace interface to show bulb color again?