core: Tuya switch component works, but the toggle does not keep its state

I have this same issue, but only with Tuya smart plugs with multiple sockets. When I change an outlet to “on,” the outlet turns on but a few seconds later the Home Assistant representation of the switch state turns back to off. The outlet remains on. I’m using version 0.97.2 and I suspect it has something to do with a firmware update to the smart plug itself rather than some change in Home Assistant. The single socket smart plugs work fine. I really do hope the keepers of the tuya component in home assistant can address the issue.

I’m just tagging some people i’m seeing commiting to the TuyaInc org, maybe they have some input/can provide some feedback. I also tweeted the link to the issue to them.

@chenjingTY @chainsaw @tiamohummer @hughcoder @tuyaLang - any input/help guys ?

This fix works for me on hass.io I used Portainer to get a command prompt in the HA container and edited the file at /usr/local/lib/python3.7/site-packages/tuyaha (running 0.97.2)

Can confirm same issue here. I have some TUYA Based WiFi glass panel touch light switches, the 2 & 3 Gangs are affected, single gangs are fine.

Have the same problem as sasukebinbin. It also affects only the power strip, the individual plugs and the LED bulbs are displayed correctly. Hope the problem can be solved! Many thanks to all who sacrifice their free time here and work so hard on Home Assistant !!! greetings

@Scope666, thanks for the follow-up, that lead me down the right path! Apparently the Hass.io Portainer add-on hides most of its containers, so the homeassistant container just needs to be unhidden before this can be implemented.

For anyone else trying to get this going, the Known issues and limitations section of the Portainer add-on README tells you how to unhide the homeassistant container.

A special thanks to @niladam for all the work he did on this issue!

Here’s some quick help guys (i don’t know about hass.io, but maybe someone else can help - also, some instructions might work with the Docker container as well) in case you can’t/don’t want for the official update.

• Navigate to your homeassistant installation folder (in my case, with virtualenv, it’s in /srv/homeassistant, but i’ve seen locations like /opt/homeassistant too);
• In the folder above you should have a lib/ folder. cd into it.
• In this folder you should have (depends on your python version) a folder named: python3.X - (where X is 7 in my case). cd into it.
• In this folder you should have a folder named site-packages. cd into it.
• If you’re using the tuyaha component, in this folder you should see a folder named tuyaha. cd into it.
• Now navigate to the folder named devices, where you should see your switch.py file; You can remove it and recreate it with the code above in my comment;

If you’re having problems finding these folders, i suggest you use find to locate your tuyaha folder. A copy/paste version of the find command (i’m searching in /opt and /srv – but you can change this to / to search the entire system (this will print the folder if it finds any or nothing if it can’t find it):

find /opt /srv -type f -name tuyaapi.py | sed 's|/[^/]*$||'

After all the changes have been applied, it’s time to restart your HA and enjoy !🎉 🎉 🎉 🎉

Hello everyone,

TL;DR - required changes at the bottom of the post.

Since my last update, and the ETA provided by Paul seemed not a really great one, i decided to take matters into my own hands.

I managed to fix the switches (please keep in mind, i have a double switch) - can’t test for the single ones.

I have already requested a pull from PaulAnnekov/tuyaha#4 - hopefully this will put him on the right track to fix the other devices.

If you have any questions and/or comments please use the above specified link (to the pull request) to keep this tidy.

For a really, quick fix, open up your tuyaha/devices/switch.py and replace the contents with the following:

from tuyaha.devices.base import TuyaDevice

class TuyaSwitch(TuyaDevice):

    def state(self):
        devices = self.api.discover_devices()
        state = None
        for device in devices:
            if device['id'] == self.obj_id:
                state = device['data']['state']
                return state
        if state is None:
            return None
        return state

    def turn_on(self):
        self.api.device_control(self.obj_id, 'turnOnOff', {'value': '1'})

    def turn_off(self):
        self.api.device_control(self.obj_id, 'turnOnOff', {'value': '0'})

This should work as i’ve already tested it.

EDIT: the update (when using the app to toggle the switch) is a little slow, and my skills to improve that aren’t what i’d like them to be 😃

EDIT2: For some quick help, navigate to my comment below.

Hey @balloob - can you maybe reach out to Tuya about this ? I noticed you said in an earlier PR that you have some contacts with them ?

Thank you!

sorry, I had posted the wrong link. the correct link is here

extract the tuya folder and copy it into custom_components

@niladam thanks for you

After a while, it works flawlessly. Everything running smoothly!

You made my day @niladam !!!

@Scope666, are you 100% sure on the path? I’m running the newest Hass.io but when I use the Portainer console my /usr/local/lib directory is completely empty.

I just looked at your screenshot, you’re in the wrong container. You’re in hassio_dns when it should be “homeassistant”

Hello everyone,

TL;DR - required changes at the bottom of the post.

Since my last update, and the ETA provided by Paul seemed not a really great one, i decided to take matters into my own hands.

I managed to fix the switches (please keep in mind, i have a double switch) - can’t test for the single ones.

I have already requested a pull from PaulAnnekov/tuyaha#4 - hopefully this will put him on the right track to fix the other devices.

If you have any questions and/or comments please use the above specified link (to the pull request) to keep this tidy.

For a really, quick fix, open up your tuyaha/devices/switch.py and replace the contents with the following:

from tuyaha.devices.base import TuyaDevice

class TuyaSwitch(TuyaDevice):

    def state(self):
        devices = self.api.discover_devices()
        state = None
        for device in devices:
            if device['id'] == self.obj_id:
                state = device['data']['state']
                return state
        if state is None:
            return None
        return state

    def turn_on(self):
        self.api.device_control(self.obj_id, 'turnOnOff', {'value': '1'})

    def turn_off(self):
        self.api.device_control(self.obj_id, 'turnOnOff', {'value': '0'})

This should work as i’ve already tested it.

EDIT: the update (when using the app to toggle the switch) is a little slow, and my skills to improve that aren’t what i’d like them to be 😃

@niladam, you just made my day. Thank you! Confirmed working with my (WIFIP310FWT) switch.

@javiges you can possibly find the file here /usr/local/lib/python3.7/site-packages/tuyaha/devices if you are using the official docker image.

It does seem like the tuya API has changed and the dev of the tuyaha component that HA uses for its tuya integration needs to update that before it will work again. I see someone has posted the issue on his repo so hopefully he will fix soon. Also as an FYI some Devs mark being tagged blindly in issues as spam, so be cautious when tagging ppl in here

I am also having this issue…4 port outdoor plug, individually addressable. Works fine in Smart Life app and HA can toggle the state to ‘ON’ but the toggle button returns to ‘OFF’ in a few seconds.

HA 95.4, Docker.

I have the same problems, with a Tuya multiple sockets: the toggle does not keep its state and so I can only switch it on, but can’t switch it off anymore.

Hassio 0.97.2

Hope we can find a solution, thanks

Interesting - i have the same type of switches - and yes - single gang seems ok (although slow)

2/3 gang dont keep state.

Hi, I’m using version 0.93.1. I have Tuya Plug and Switch for lights. They all recognised as switch in HA. Currently Plug still works fine, can update realtime status. But Switch for lights, if I turn on in HA, it will maintain for few seconds then automatically show off but actually the light is still on. If I turn on the light manually, the status will not update.

I believe there is something change in Tuya server which not compatible with the component built in HA.

Hope someone can help!!! I just purchased 5 switches from Tuya and still shipping. OMG~~~

Hi,

I’m using latest version 0.97.2, also tried many workarounds but nothing worked, in my case problem is just related to power strips (multiple switch per device), in single plugs there is no apparently problem.

Also some plugs devices appears as “unavailable”, after a HA restart devices work fine, few seconds later status fail, and some devices appears again unavailable.

No log errors are reported in HA

I think we should start looking at overriding the force_update service to install custom firmware like ESPHome or Tasmota to the ESP devices, this way we will have complete control and can also utilize the additional feature the ESP8266 chip would provide inside the devices

Me same issue happened this two days.

Glad this was resolved, though I hate how slow it is. I’m using local control for scenes, I wish it was fixed though as it takes ages to return the state! https://github.com/mileperhour/localtuya-homeassistant/

Unfortunately I can’t have the best of both worlds, Normal Tuya Integration, slow at on/off but, tuya local instant on/off but slllooooowwww at returning a state…

@javiges - @PaulAnnekov (thank you!) has just merged the PR i created 😃 – and already released the last version which is now available. I guess this just needs to propagate to everyone 😃

Thanks everyone for testing and suggesting things – and reporting things !😃

@javiges i’m sorry. I don’t know. First, it needs to be accepted by @PaulAnnekov in the main tuyaha repo and he can then make a new PR for this to be included in the next update 😃

thanks, implemented the fix as well…

FYI, if you’re on HA < .96 where they updated from tuyapy to tuyaha, you’ll have to edit the new switch.py and change the line:

from tuyaha.devices.base import TuyaDevice

to

from tuyapy.devices.base import TuyaDevice

and of course the directory is

/usr/local/lib/python3.7/site-packages/tuyapy/devices

instead of

/usr/local/lib/python3.7/site-packages/tuyaha/devices

@chetcuti - it was my pleasure buddy!😃

@niladam Thanks for the help. Works great now.

@niladam Yeah. Finally I get it work. The path you provide is correct. I should not edit file under usr/src/app/homeassistant/component/tuya/switch.py. Correct path is go into container by command: sudo docker exec -it 14bf4ecdb931 /bin/bash then go to /usr/local/lib/python3.7/site-packages/tuyaha/devices “14bf4ecdb931” is container ID.

Here’s a screenshot if it helps:

@Scope666, are you 100% sure on the path? I’m running the newest Hass.io but when I use the Portainer console my /usr/local/lib directory is completely empty.

That path is correct, but you have to be INSIDE the container, not on the host system. That’s why I suggested Portainer is it can provide a command prompt in your browser into any of your containers.

Scope666 can you please tell me how to use Portainer? Is it an addon or what?

It’s been awhile since I set it up, but I did something like the below:

https://www.howtoforge.com/tutorial/ubuntu-docker-portainer/

You would ignore the parts about initially setting up Docker since you probably have that already.

Portainer is a great browser-based UI that allows you to fully manage your docker images, containers, etc.

@elchanly my quickfix, only applies to the switches. I suggest you use the developer console, and run a tuya.pull_devices - this might get you sorted.

Also, do a run on tuya.force_update 😃

Same issue here HA 0.97.2

I am running HA 0.923 version on Docker. also, I have the same issue with you. Only multi-socket products have problems. Single-socket products work well.

It doesn’t seem to be an HA version issue. I had the same problem with the latest version 0.97.2. I hope it’ll be solved soon.

there are many devices of yours that have a home assistant, I guess they will fix it I guess

if the devs of home assistant can fix it in the next version, but I put esphome

@MattiasPie - actually, i’ve been running this initially on a PC, running Ubuntu, and a really old version of HA (something like 0.74.*) - when the issue first arose. The first thing i did was upgrade to the latest version, and the issue still happened. I will test tomorrow again on the PC about this specific issue and see if it still happens…

I got the same problem when I migrated my environment to PI4 (docker 0.97.2). However I also have the old environment on Synology Nas (docker 0.96.4) and on there Tuya is still running fine. Same credentials, config and everything. To me this must be on the client side as I have one client working and one that is not working. Both using the same server. I’m happy to send more information and comparisons between the both clients if someone wants more input on this.

I’m unable to get correct status of the device I’m using (WIFIP310FWT). The four switches status is always off no matter what I do. I can however partially control the switches by using switch.turn_on and switch.turn_off. This will mostly switch the selected entity on or off. But the status does not change in HA.

switch.toggle on the other hand does nothing.

I’m on the latest HA 0.97.2.

Side note: Platform: smart_life just doesn’t work. No matter how I configure it. It always reports auth issues in the HA logs. I have an account and I am able to control the switches with the Nedis app.

Anyone who’s subscribed to this, yeah I’m just saying I also have the issue. I have a few different kinds of Tuya switches, all with this issue. The one Tuya bulb I have works fine though

Docker on Ubuntu

I can confirm same issue on my setup. I have a mixture of double and single light switches and also 240v power outlets. This is currently only effecting a few devices (not isolated to a type, all variants are effected). Currently not effecting my automations as I don’t use ‘toggle’ but effects my front end as I use ‘toggle’ for manual control.

I’m also hoping someone can get onto this bug quickly, thanks in advance.

***Correction: after more testing it seems dual gang light switches and dual power outlets are effected.

I concur with slim0287, the plugs I’m having issues with are 2 outlet outdoor models. They must have changed something about how the individual outlets are addressed.

I have same problem with tuya component

Same here as well, seems to vary by device. Some look correct, others are showing off when they’re actually on. It seems to be a change with the Tuya API because I reverted to a known working Snapshot and there was no change in behavior.

I have same problem with tuya component 😦

I’m on 0.95., using the standard tuya integration - similar issue - turning a light /switch/ on/off via GUI works, but the state isn’t kept and after a few seconds changes to off. Regardless of the switch setting

the number of “Updating tuya switch took longer than the scheduled update interval 0:00:30” hasn’t changed. There are no (apparently) related errors in the log file

@chetcuti - thank you for your really good report! I’m hoping someone picks this up and we’ll be able to sort it out.

IMHO, to me it sounds like this is an API change and/or modification…

I’m having the exact same issue with Tuya switches (Tuya bulbs seem to be working fine) which started about 30 hours ago. When I start HA everything displays properly in the UI, but then slowly every Tuya switch toggle turns off, and the states section of the UI shows them as off, even though the actual switches themselves stay on. If I check the Tuya app the states are correct. Here’s a screencast of what happens after a reboot: https://www.screencast.com/t/c0pC9CnUmxx

I first started experiencing this on Hass.io v0.95.4 running in a Proxmox VM (which had previously been working fine for over a month and a half). I then upgraded to v0.97.2 and the problem persisted. I then tried installing v0.97.2 on a completely new Proxmox VM and only set up two Tuya switches for testing purposes, and the problem remained. I also tried using the VM file from the recommended installation steps and used that on my local computer in VirtualBox, with the same two switches as my previous test, and yet again this odd problem persisted.

As a test I turned on debug logging and restarted HA, and after everything started up, about 25 seconds later the two Tuya switch toggles shut themselves off, and these entries were recorded in the log.

2019-08-16 11:30:30 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=switch.03487135cc50e3cb9eaa_1, old_state=<state switch.03487135cc50e3cb9eaa_1=on; friendly_name=Switch 1 @ 2019-08-16T11:29:59.264659-07:00>, new_state=<state switch.03487135cc50e3cb9eaa_1=off; friendly_name=Switch 1 @ 2019-08-16T11:30:30.686297-07:00>>

2019-08-16 11:30:30 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140484409570768] Sending {'id': 2, 'type': 'event', 'event': <Event state_changed[L]: entity_id=switch.03487135cc50e3cb9eaa_1, old_state=<state switch.03487135cc50e3cb9eaa_1=on; friendly_name=Switch 1 @ 2019-08-16T11:29:59.264659-07:00>, new_state=<state switch.03487135cc50e3cb9eaa_1=off; friendly_name=Switch 1 @ 2019-08-16T11:30:30.686297-07:00>>}

2019-08-16 11:30:31 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=switch.03487135cc50e3cb9eaa_2, old_state=<state switch.03487135cc50e3cb9eaa_2=on; friendly_name=Switch 2 @ 2019-08-16T11:29:59.265471-07:00>, new_state=<state switch.03487135cc50e3cb9eaa_2=off; friendly_name=Switch 2 @ 2019-08-16T11:30:31.370631-07:00>>

2019-08-16 11:30:31 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=group.all_switches, old_state=<state group.all_switches=on; entity_id=('switch.03487135cc50e3cb9eaa_1', 'switch.03487135cc50e3cb9eaa_2'), order=0, auto=True, friendly_name=all switches, hidden=True @ 2019-08-16T11:29:59.268424-07:00>, new_state=<state group.all_switches=off; entity_id=('switch.03487135cc50e3cb9eaa_1', 'switch.03487135cc50e3cb9eaa_2'), order=0, auto=True, friendly_name=all switches, hidden=True @ 2019-08-16T11:30:31.371626-07:00>>

2019-08-16 11:30:31 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140484409570768] Sending {'id': 2, 'type': 'event', 'event': <Event state_changed[L]: entity_id=switch.03487135cc50e3cb9eaa_2, old_state=<state switch.03487135cc50e3cb9eaa_2=on; friendly_name=Switch 2 @ 2019-08-16T11:29:59.265471-07:00>, new_state=<state switch.03487135cc50e3cb9eaa_2=off; friendly_name=Switch 2 @ 2019-08-16T11:30:31.370631-07:00>>}

2019-08-16 11:30:31 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140484409570768] Sending {'id': 2, 'type': 'event', 'event': <Event state_changed[L]: entity_id=group.all_switches, old_state=<state group.all_switches=on; entity_id=('switch.03487135cc50e3cb9eaa_1', 'switch.03487135cc50e3cb9eaa_2'), order=0, auto=True, friendly_name=all switches, hidden=True @ 2019-08-16T11:29:59.268424-07:00>, new_state=<state group.all_switches=off; entity_id=('switch.03487135cc50e3cb9eaa_1', 'switch.03487135cc50e3cb9eaa_2'), order=0, auto=True, friendly_name=all switches, hidden=True @ 2019-08-16T11:30:31.371626-07:00>>}

Additional Notes:

• External triggers such as dash buttons, API calls from custom scripts, etc. all trigger the switches properly, however the state in HA still says off, and the toggle stays off
• Someone on Discord had me run the Tuya force update service but it didn’t change anything
• Someone on Discord suggested I try updating the Tuya firmware but no updates were available
• I’ve tried using a completely separate Tuya account, in case it was an issue with my specific Tuya account (corruption, etc.), with nothing but these two switches added, and the results were the same

Yup this is a new issue that’s been driving me mad thinking its something I’ve done. Hopefully a solution really soon.