Hello,
I have configured the tuya integration and it works fine. But after any hours or days, the integration stops working. I must click „reload“ over integrations.
Why the integration stops?
Have anyone the same issue?
Thanks Daniel
Did you already find a solution? I have the same thing happening since a couple of days, once or twice a day (it was working for months), now I also have to reload the integration to activate my tuya devices again.
Trying now to capture with debug logging on.
Yes if it is Tuya Python SDK and their MQTT server related, see my pull request . There are some similar approaches to solve this issue as well, however, SDK repo maintainers don’t bother dealing with them.
Your pull-request failed (already in Dec 22), so that won’t make it (yet).
You are right, however, the test failed on pull request not related code. Of course I could repair it as well, but I don’t think this would change anything.
It is very annoying - after each HA OS update, I have to access its “homeassistant” container CLI and reinstall tuya-iot-py-sdk package with my fork. But after that, everything seems to work fine.
My system is now in such a state (tuya integration not executing), I don’t get any “actual power” values updated and I can’t toggle any energy-socket switch (it jumps back to its original position). While doing that, I captured the debug logging while logging one switch-toggle action, but I was astonished by the result (XXX and YYY are obfuscated IDs):
2023-03-31 13:05:01.452 DEBUG (SyncWorker_11) [homeassistant.components.tuya] Sending commands for device XXX: [{'code': <DPCode.SWITCH_1: 'switch_1'>, 'value': True}]
2023-03-31 13:05:01.453 DEBUG (SyncWorker_11) [tuya_iot] Request: method = POST, url = https://openapi.tuyaeu.com/v1.0/devices/XXX/commands, params = None, body = {'commands': [{'code': <DPCode.SWITCH_1: 'switch_1'>, 'value': True}]}, t = 1680260701453
2023-03-31 13:05:03.631 DEBUG (SyncWorker_11) [tuya_iot] Response: {
"result": true,
"success": true,
"t": 1680260703621,
"tid": "YYY"
}
According this it looks like there is nothing wrong, but there is, 2 seconds later it jumps automatically back (in my dashboard) in the “off”-position, without any reporting/logging of that action and the actual socket didn’t make any movement. These are all the log-lines I’m getting while performing the whole action and its reaction. Is there something else I also need to enable debug-logging for?
I know when I now reload the Tuya integration, everything will be fine again.
I have the same issues. I have Tuya and Localtuya both running, they have happily coexisted with devices known to both (different names of course) for many months. Now I have to keep reloading Tuya when it stops reflecting updates (operate a switch, it triggers the device but then status in HA flips back after a couple of seconds), and I also am having similar trouble with Localtuya, it is logging lots of connection errors and sometimes works, sometimes doesn’t, sometimes gets completely stuck until a reload of that gets it going again too. I don’t know if the problems with the two integrations are related at all…
1 Like
I was able to catch a log of the problem and filed an issue: Tuya integration locks up several times per day · Issue #90737 · home-assistant/core · GitHub .
2 Likes
I wonder if anyone is actually looking at solving this… I have circumvented the problem like this:
I did this in node red, an automation should work too… I have a spare tuya smart plug which I use:
turn on the plug
wait 10 seconds
check the reported state of the plug - if it’s not reporting on, reload the integration (call service reload_config_entry giving it the entity of the plug)
turn the plug off
I have set this to run every 10 minutes (I used an inject node in node red which you can configure to fire at regular intervals). It reloaded once overnight (it notifies my phone if it does the reload), and all tuya devices are responding properly this morning, so it had the desired effect.
I wanted a better way of spotting when there is a problem instead of the sledgehammer approach of just reloading the integration every 60/30/10 minutes or whatever. This method should catch the condition I get, where the device responds to a command but the status in HA flicks back after a few seconds, or indeed the problem some people seem to get where the device doesn’t respond at all either.
I have been testing the same approach for the last two days, with an automation at a 5 minute interval and that works. But I do agree that it is a kind of sledgehammer approach and I am looking for a more selective way using the debug logs (because there is no error logging, like last years problem with the “invalid token”, which symptoms look similar), I am looking of using the string “[tuya_iot] _on_subscribe: 1” (that is the end of the refresh cycle) as a trigger and do the check 10 seconds later. But at least I don’t have to restart manually anymore. The problem was there 7 times in the last 46 hours every time after the “refresh” at an interval of 1 hour and 59 minutes.
I can imagine that the devs are a bit hesitating here, there have been/are a lot of problems with the Tuya integration and there were also problems that had to be fixed by Tuya, Two examples were last years “invalid token” problem and the late “Tuya subscription expired” problem (which still happens a lot, but should be handled by the user on the Tuya platform). So sometimes it is very hard to see if there is a new problem.
New version Tuya Test v2.2 (work-around for Tuya lock-ups) here: Tuya integration hangsup - #31 by SvanGool
1 Like
Home Assistant 2023.4.1
Frontend 20230406.1
Running on Synology DS220+ DSM 7.1.1-42962 Update 4
Docker Container
I am having the following issues:
- TUYA devices do not trigger automations anymore, SmartLife always shows correct states of devices though
- PIR motion detectors do not report “no person detected”, this may or may not be related to the TUYA stalls, SmartLife automations always work and show correct detection states
My idea was to check the log file and see what could be used as a trigger when TUYA stalls. So maybe other triggers could be used as well as this is a first approach to find the correct one. I also see script errors occasionally.
For this to work, add these lines to your configuration.yaml
system_log:
fire_event: true
I came up with the following after doing some searches on the web:
alias: Tuya Reload
description: ""
trigger:
- platform: event
event_type: system_log_event
event_data:
level: ERROR
name: tuya_iot
condition:
- condition: template
value_template: "{{ \"Unexpected disconnection\" in trigger.event.data.message[0] }}"
enabled: true
action:
- service: homeassistant.reload_config_entry
data:
entry_id: XXXXXXXXX
mode: single
You will find XXXXXX for TUYA in the file core.config_entries in the hidden folder .storage (path see below).
@MacJoSch : that looks good ! There is only one problem: there is no ERROR logged when the link goes down, at least not in the cases I saw. For a problem last year that was a solution, but now it is not. The trigger doesn’t allow DEBUG messages, unfortunately.
SvanGool, you are right. I am now at a point that I won’t use Homeassistant anymore until the reliability issue is resolved. I have too many TUYA devices to change to another system like Homematic.
Only internal triggers still work, like helpers. My heating system relies on that (night/day mode and schedule) but summer is close…
I ordered some aquara PIRs and window switches with gateway. We’ll see how these work.
One last thing about the Tuya debugging. There is always traffic logged but at one point there is nor traffic but ping…
PING.
1 Like
That is exactly the problem ! With the automation I presented above, I only had two automatic reloads the last two days, which was a lot more in the beginning of the week (the weekend less traffic !?). The automation does allow my other automations to work with Tuya, with as less interruption as possible.
1 Like
I have had this problem occasionally (maybe once every few months) for a while, and have an automation to detect it (temperature sensor not changing for several hours) and notify me. Recently, though, it went from once every few months to once every few hours. Disabling and enabling the Tuya integration always fixed it, but now not for very long.
The change from months to hours happened when nothing else had changed on my HA instance. It is not connected to a HA upgrade. I was running 2023.3.0 at the time. Upgrades to 3.6 and 4.0 made no difference.
All the while, of course, the devices themselves are working just fine and reporting properly through the Smartlife app, and working with Smartlife’s Alexa integration.
I have so many Tuya/Smartlife devices that this problem essentially makes HA useless for me. Very frustrating.
If there’s a reliable workaround that would be great. All suggestions welcome. But do we need to think about moving away from Tuya devices?
1 Like
Hi Steve, same thoughts here. Just ordered some Aqara stuff (yet still Chinese) for trying (PIR, Window Contact, Gateway).
Automation still work when HA Helpers or non-Tuya sensors are involved. In other words Tyua devices as command receivers = actor work, but not as transmitters = triggers.
So, here we go: All is back to normal. I had a chat with TUYA and received a response as follows:
Is anybody else surprised that automations work again? Or is it related to my TUYA account only?
1 Like
They are indeed working again since a couple of hours. The sensor data is getting updated normally now.