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.
Hello It’s ok for me too. I hope it will work for good.
Not For me. Anything in particular that we have to do?
Kind Regards,
I did not do anything
1 Like
Hello all, (sorry for my English)
What do you mean with ‘every thing is working’ ? Should all Tuya devices switches and sensors (triggers) work normally? Not here (Netherlands (Europe)) at the moment.
With my Switches and Vacuum I had not specially problems but with the Door/Window (Tuya Wifi) sensors I still have problems. On the trigger/automation of open/close door/window I have also a TTS (text to speech) on my Google Nest Mini. Problem here is that the trigger does not happen. I do get a notify in Tuya app so that’s working.
Only on restart the Tuya integration, with the scripts above, I get on the strangest times a notification in HA and Google Nest that a door or window is closed/opened. But that was way in the past!
I’m relative new with my HA setup (few weeks now) and come from Domoticz. Sinds I have HA my home automation is not as stable and are a bit disappointed about stability. It looks great but stability is No1.
Hope to get a normal working setup otherwise im going back to Domoticz.
I also ordered a Z-Wave door sensor to replace Tuya Wifi sensor hope these will be more stable like the PIR sensors I have.
Developer mode at Tuya IOT only lasts one year. Then you have to reactivate it for 6 months with this link: Tuya Smart Developer Center
This may be the source of your problem.
1 Like
Switches status, values of sensors (e.g. open/closed, on/off, motion/no-motion) as well as measured values like temperature, humidity, voltage, power etc. are transmitted (or should I say broadcast) to HA again. It is still a bit unsteady but they are on a good way.
It is not the case that the subscription has expired. This is what we all here check in the first place, I presume.