search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
69.47k stars 28.66k forks source link

Tuya Switch Not Keeping Its State When Toggled #36744

Closed homecb closed 3 years ago

homecb commented 4 years ago

The problem

Tuya switch component works, but the toggle does not keep its state. The issue is a resurrection of https://github.com/home-assistant/core/issues/25992 I couldn't comment on that thread (locked), thus created a new one.

Environment

Traceback/Error logs

Additional information

acs-lux commented 4 years ago

I would also like to plead that the unknown state is simply ignored and only the remaining 2 states open / closed are used. When closing a shutter the state is closed even if the shutter is closing, same for opening so the unknown state just ruins the integration. Better to ignore unknown and keep last state.

akusokuzan commented 4 years ago

Yeah same issue here popped 2 days ago maybe 3 days ago before the 0.111.1 update. And the issue is still there with 0.111.2 that I just installed. Running Hassio in a VM on a NUC device. Also note that it isn't just switches also lights are doing the same thing. I can go and change the state manually and do that every time to make it work. Also if i restart hassio it will read the new changes and if it sits for a few minutes it will notice a state change seems like 3 minutes or so. Glad I'm not the only one.

ghost commented 4 years ago

Happening for me as well. Didn't update HASS, issue cropped up out of nowhere.

NDNELSON commented 4 years ago

Same issu with 0.111 home assistant core(Docker install not hassio) . How can I fix it?

donnaran commented 4 years ago

I am having same issue. All my 20 plus Tuya switches were working nicely since year & half but 3 days ago all of sudden my Tuya switches stopped keeping its state. I have tried 111.1, 111.2 but same issue.

No issue when controlling switches with Tuya smartlife app.

I also build a brand new HA to verify if the issue was related to my existing HA setup but brand new setup is also having same issue.

No errors in HA log.

Something has change suddenly (3 days ago) which is impacting this tuya state changes.

donnaran commented 4 years ago

same issue reported here #36740

cr8tor456 commented 4 years ago

Same problem: call the service, switch turns ON, then 2-3 seconds later it toggles back off, but the switch is still on. I have been chasing this problem all day, started yesterday (2020-06-14) mid day or so. Installation: home assistant core (installed in docker) version 0.111.2 (no hassio)

ghost commented 4 years ago

Looks like there's some sort of rate limiting happening. The API only allows 3-4 queries before it starts to throttle requests. Rate limit bucket window is probably around 10 seconds?

If this is indeed the case I don't know if there's any way around this.

estebanz01 commented 4 years ago

I'm seeing a similar behaviour. I had to remove my integration to avoid IP ban from tuya API. I believe it's related to #36713

com-xuonghuynh commented 4 years ago

Got same issue

rmayron commented 4 years ago

the behaviour I am seeing is a very very slow update of the front end. I can turn on a light using a button, but the state won't change in the front end, and subsequent operations don't work until the front end is refreshed, which can take 5 to 10 minutes.

I am running hassio and core 111.2 on RPi4. the issue started couple of days ago, but I cannot tell if it's related to the latest updates.

this is what I am seeing in the logs:

requests.exceptions.SSLError: HTTPSConnectionPool(host='px1.tuyaus.com', port=443): Max retries exceeded with url: /homeassistant/skill (Caused by SSLError(SSLError("bad handshake: SysCallError(-1, 'Unexpected EOF')")))

I assume this issue is related to the others mentioned in this thread.

Regards - Ran

Yonny24 commented 4 years ago

Same issue here. I'll update to 0.111.2 tonight to see if it improves but nothing in the release notes about a fix yet.

Thanks

cr8tor456 commented 4 years ago

Caused by SSLError

huh, i wonder if this is related to SSL certificates expiring on old or poorly maintained IOT devices?

Yonny24, im on 0.111.2 and the issue persists.

cvroque commented 4 years ago

I'll add that I'm also having the same issue and even reverting to older snapshots didn't fix it. My HA seems to be trying to connect to px1.tuyaus.com ALL the time.

cannondale0815 commented 4 years ago

Just chiming in that I am experiencing the same problem since this morning on all seven (7) of my Tuya devices. Home Assistant doesn't see state changes. Or when it does, they come in with a delay of several minutes. And when I try to switch on or off Tuya devices through the toggle in Home Assistant, the action succeeds, but the toggle goes right back into its previous position (on or off, wherever it was before, without actually triggering an action then).

acs-lux commented 4 years ago

This morning i switched on a light and it switched straight away. Then i have the same issues. The logs say uncaught exception in utils.py and a lot of SSL errors with max tries exceeded.

donnaran commented 4 years ago

issue still in new release 111.03. very frustrating....all of sudden 20+ tuya switches cannot be controlled with HA.

Zkaning commented 4 years ago

I'm having the same problem that popped up out of nowhere a few days ago. The smartlife app works as before but the HA frontend is not working, also tried to upgrade to .111 but did not help. Very frustrated when running 25+ tuya devices in HA. Please solve this!

GBCRAS1 commented 4 years ago

This issue has been manifested since yesterday also on my HA 0.111.0 without any changes performed. I tried and updated to 0.111.2 and 0.111.3 without any luck. I also gone back to 0.110.x versions. No joy.

What is the cause of this issue ?

oooshk commented 4 years ago

the behaviour I am seeing is a very very slow update of the front end. I can turn on a light using a button, but the state won't change in the front end, and subsequent operations don't work until the front end is refreshed, which can take 5 to 10 minutes.

I am running hassio and core 111.2 on RPi4. the issue started couple of days ago, but I cannot tell if it's related to the latest updates.

this is what I am seeing in the logs:

requests.exceptions.SSLError: HTTPSConnectionPool(host='px1.tuyaus.com', port=443): Max retries exceeded with url: /homeassistant/skill (Caused by SSLError(SSLError("bad handshake: SysCallError(-1, 'Unexpected EOF')")))

I assume this issue is related to the others mentioned in this thread.

Regards - Ran

Exactly the same issue with me. Fine two days ago, now I press any button or light, the lamp will trigger, but the state remains the same for 5 minutes at a time before changing. Interestingly, if I ask amazon echo to trigger it on or off, it does it no problem.

a2gin2 commented 4 years ago

I am having this problem as well. All has been working fine since setup in December 2019. Problems started a few days ago. Running HA 0.111.3 with HassOS 4.10. All the entities work with the Tuya app without issue. Very frustrating...

AdmiralStipe commented 4 years ago

Same issue here, my HA is connecting to px1.tuyaeu.com in average 15 times per minute (2100 requests in last 5 hours). Hopefully solution is on the way as my whole Tuya setup is unusable as it is...

akusokuzan commented 4 years ago

Quick update for me. This got me worried so I decided to take the plunge and finally get my devices out of the cloud. Flashed all 20+ devices with Tasmota.

Devices that worked (as of this post): TreatLife SS02S Switch, TreatLife DS01 Dimmer, TreatLife SS01S Switch, Gosund WP6 Plug, Gosund WP3 Plug, Aoycocr SW1 Switch.

Device that didn't work (as of this post): Treatlife SS01 3-Way Switch firmware main module/mcu: 1.1.4 both. Not sure why odd the non 3 way worked. but all 3 of these failed to flash.

Good lucky hopefully this isn't an issue on the cloud side.

cannondale0815 commented 4 years ago

Quick update for me. This got me worried so I decided to take the plunge and finally get my devices out of the cloud. Flashed all 20+ devices with Tasmota.

Devices that worked (as of this post): TreatLife SS02S Switch, TreatLife DS01 Dimmer, TreatLife SS01S Switch, Gosund WP6 Plug, Gosund WP3 Plug, Aoycocr SW1 Switch.

I have a few of the SS01S switches, too. Which tutorial did you follow to flash Tasmota, if I may ask?

akusokuzan commented 4 years ago

The tutorial I used was from DigiblurDIY on youtube. Just search tuya convert. He even shows, in the second video he references, how to get it connected to home assistant. I was surprised how easy it was. Do note Alexa and google assistant do not work unless you sign up for HA cloud or setup your own.

oooshk commented 4 years ago

I've been holding off flashing tasmota for so long because normally I struggle to root a phone! But I think I'm going to have to attempt it.

Thrasher2020 commented 4 years ago

I am experiencing the same issue. 24 devices :( Some can't be flashed so I would hope we get a resolution soon. As above Alexa can control them with no issues...

GBCRAS1 commented 4 years ago

Same for me. I have my Tuya Switches which can't be flashed. I've updated HA this morning to version 0.111.4, but seems like the issue has not been solved yet ...

oooshk commented 4 years ago

Update, as others have said, flashing to tasmota really is quite easy. Unfortunately, not all of my smart sockets changed over. Two have bricked, and four more are stuck on tuya, but the remaining twenty have new firmware. The guide I followed said they were using a RPi4 to do this, but I used a 1 and a WiFi dongle and it was fine. The donated phone is used simply to connect to the RPi created access point, presumably to keep it alive, not sure... And I found I had to run the program as su root, otherwise I was getting all sorts of file permission errors. But, it worked, and it was easy. Now I have to figure out if I can update the remaining four units. They are the TP24 type smart sockets (most of which did flash correctly), the only discernable difference I could see was when putting them into pairing mode, fast flash, the units that converted flashed constantly, whereas the ones that didn't flashed for a second or two, then a noticeable pause, then continued flashing as in pairing mode. The intermediate firmware failed on these units. Like I said, for info. Tasmota is much more reliable now.

Example socket that failed.
DSC_0029

I should also say that a couple of these switches looked like they didn't go into pairing. They just switched out the led. They did however pair in this state.

estebanz01 commented 4 years ago

@oooshk the devices are not bricked, they are in a state called "intermediate firmware". If resuming the tuya-convert process won't work, you need to open it and flash it via pin headers.

oooshk commented 4 years ago

@oooshk the devices are not bricked, they are in a state called "intermediate firmware". If resuming the tuya-convert process won't work, you need to open it and flash it via pin headers.

That's what I thought as well. But you know, for the sake of £20 I'm just going to buy some more right now and tinker with these at a later date. I have the two types of smart socket. The TP24s, and BSD29s. The latter were much more reliable at the flashing process. The 24s gave me some issues.

Ryan-J commented 4 years ago

Not all Tuya devices are based on ESP8266 and therefore flashing Tasmota or ESP Home isn't always an option. I would hope the solution to this bug isn't to stop supporting Tuya devices directly anymore.

cannondale0815 commented 3 years ago

@ollo69 just a friendly nudge, in case you haven't seen these issue reports :)

nao-pon commented 3 years ago

In my environment (Hass.io 0.111.4) the following fix was able to resolve this issue. However, I'm new to Python, so there might be something wrong.

cannondale0815 commented 3 years ago

In my environment (Hass.io 0.111.4) the following fix was able to resolve this issue. However, I'm new to Python, so there might be something wrong.

  • /usr/local/lib/python3.7/site-packages/tuyaha/tuyaapi.py L.145-
    def device_control(self, devId, action, param=None, namespace="control"):
        if param is None:
            param = {}
        response = self._request(action, namespace, devId, param)
        if response and response["header"]["code"] == "SUCCESS":
            success = True
            if action == "turnOnOff":
                device = self.get_device_by_id(devId)
                if param["value"] == "1":
                    device.data["state"] = True
                else:
                    device.data["state"] = False
        else:
            success = False
        return success, response

Very clever fix to add that additional check for turnOnOff.

FYI for others: On my Ubuntu server with Hass.io, the tuyaapi.py was found in a different folder structure underneath "/var/lib/docker/overlay2/" somewhere.

But the fix immediately resolved the state issue and also any automations I set up against state changes.

Now how do we get this change to the right people so it can be incorporated into the main build?

AdmiralStipe commented 3 years ago

In my environment (Hass.io 0.111.4) the following fix was able to resolve this issue. However, I'm new to Python, so there might be something wrong.

Perfect, just tried it in docker on Raspberry and it works!

Yonny24 commented 3 years ago

I just hope they fix it soon rather than having to alter python scripts myself. I can manage in the meantime using my smartlife app.

cannondale0815 commented 3 years ago

Actually, that fix still doesn't work 100%. It works fine when triggering the state changes from within the HA interface, but when I turn on or off my smart light switch manually (by pushing it), HA often doesn't recognize the state change still. So the fix is incomplete still.

cr8tor456 commented 3 years ago

Where does one find the place to perform this edit in a non hassio (Core / Docker) install? Looking all sorts of places, but im green enough i dont know where to check, apparently.

cannondale0815 commented 3 years ago

Where does one find the place to perform this edit in a non hassio (Core / Docker) install? Looking all sorts of places, but im green enough i dont know where to check, apparently.

Find it as follows:

sudo find / -name "tuyaapi.py"

ollo69 commented 3 years ago

In my environment (Hass.io 0.111.4) the following fix was able to resolve this issue. However, I'm new to Python, so there might be something wrong.

  • /usr/local/lib/python3.7/site-packages/tuyaha/tuyaapi.py L.145-

Not still clear to me if issue is library side or HA side. It's more logical thinking about HA, because some version ago was ok and library never changed. For which reason you work on library? You now about some specific issue? Real problem is that library codeowner seems not active from some time so I don't know when he will be able to integrate change.

cr8tor456 commented 3 years ago

Not still clear to me if issue is library side or HA side.

On my installation (Docker / Core 0.111.2 install) it seems that eventually the switches "catch up" almost like the replies from the server on the other side of the internet is slow in replying. Could this be an issue on tuya's side of things?

I say this because if i just leave things alone, the switches eventually do change as they should, but that time frame seems really sporadic since a few days ago when this seems to have started for everyone.

Also, thanks cannondale for the note on how to find the file to edit.

estebanz01 commented 3 years ago

In my environment (Hass.io 0.111.4) the following fix was able to resolve this issue. However, I'm new to Python, so there might be something wrong.

  • /usr/local/lib/python3.7/site-packages/tuyaha/tuyaapi.py L.145-

Not still clear to me if issue is library side or HA side. It's more logical thinking about HA, because some version ago was ok and library never changed. For which reason you work on library? You now about some specific issue? Real problem is that library codeowner seems not active from some time so I don't know when he will be able to integrate change.

I checked both tuyaha and HA for possible breaking changes. There's only one PR that might have introduce this issue: #34057 but after inspecting the code, I didn't find anything obvious that suggest something is wrong with requests. This might give us a clue: It could be a dependency problem. Requests was bumped to 2.24.0, but that was 2 days ago and both requests and urlib3 doesn't have any broken change in their two released versions that might point to the culprit.

So, IMHO: it's a dependency problem or better error handling implemented in #34057 broke the integration 😅 .

cc @ollo69

ollo69 commented 3 years ago

This PR just introduce error handling during startup and was create to allow component creation delay in case of network issue on startup, so for sure are not connected to current issue that occur when component is already started. We also have to consider that HA introduce a lot of change from version 0.111, so may be exist a correlation. Do we know if issue is present with HA 0.110.x?

GBCRAS1 commented 3 years ago

This PR just introduce error handling during startup and was create to allow component creation delay in case of network issue on startup, so for sure are not connected to current issue that occur when component is already started. We also have to consider that HA introduce a lot of change from version 0.111, so may be exist a correlation. Do we know if issue is present with HA 0.110.x?

Is present also in HA 0.110.4. I have tested it a few days ago.

estebanz01 commented 3 years ago

This PR just introduce error handling during startup and was create to allow component creation delay in case of network issue on startup, so for sure are not connected to current issue that occur when component is already started. We also have to consider that HA introduce a lot of change from version 0.111, so may be exist a correlation. Do we know if issue is present with HA 0.110.x?

Replicated on 0.110.3.

AdmiralStipe commented 3 years ago

Actually, that fix still doesn't work 100%. It works fine when triggering the state changes from within the HA interface, but when I turn on or off my smart light switch manually (by pushing it), HA often doesn't recognize the state change still. So the fix is incomplete still.

Yeah, I noticed the same after short testing... and also, after an hour or so it stopped working and the issue re-appeared, despite this patch :(.

estebanz01 commented 3 years ago

I found this: https://github.com/urllib3/urllib3/pull/840. According to that, there's no real way to downgrade or keep requests in the IPV4 spectrum. Can someone try to disable IPV6 to see if that solves the issue?

EDIT: For course, it is necessary to wait some minutes, so the API allows you to do requests again.

ollo69 commented 3 years ago

I found this: urllib3/urllib3#840. According to that, there's no real way to downgrade or keep requests in the IPV4 spectrum. Can someone try to disable IPV6 to see if that solves the issue?

EDIT: For course, it is necessary to wait some minutes, so the API allows you to do requests again.

On my RaspBerry this afternoon I disabled IPV6, reboot and issue was still there. Probably some checks copyng library local are required. I'm also not so confident on cloud services provided by Tuya. This are based on special API provided by Tuya for HA but probably not mainteined anymore...

ollo69 commented 3 years ago

Putting all piece togheter seems logic to think that the tuya cloud service dedicated to HA is not able to handle all the requests. Probably the library should be reviewed to not query every single device but perform a single query for all. I don't know if this is really possible, I have to do more deep analysys.