I’ve been having the same problem. After a length of time Tuya and HA don’t communicate any longer. I was tired to restarting HA to fix this mess, so I switch to Local Tuya tonight. Problem solved.
1 Like
I also facing the same issue. Tuya devices not updated after updating to v2021.12.xx. I have to restart HA , then it will update the status. seems like the it does not receiving notification from the tuya server.
1 Like
I have to admit I am really dissapointed with this whole TUYA situation lately. The image I have is that they came with much bravado and showmanship to this whole ordeal. They had huge plans for make to ultimate integration with local support etc. I don’t doubt it is still coming at some point, but it seems that couldn’t deliver or are not really interested. Frenck did a lot of work to fix the integration all by himself (thank you Frenck like always), I am not mistaken, and somehow feel that Tuya itself is just lacking in participation. It is not just on HA side they give a bad image, but it makes question should I buy their products anymore.
And I might be wrong many ways, but this just how I feel.
2 Likes
I completely agree with you. The issues only started with the official Tuya integration so the buck stops right at Tuya’s door. I had my concerns when I had to endure a painful sign up process to the Tuya cloud application but persevered. I have not been rewarded… I definitely won’t be buying any more Tuya related products as there’s far more to life than beta (alpha?) testing for a company that has badly dropped the ball.
there seems to be a pending fix for this issue on github already Use the documented API method to refresh auth token by bpfoster · Pull Request #51 · tuya/tuya-iot-python-sdk · GitHub
heres my solution as well: Tuya actions get's stuck - #4 by andreasc
i find it more reliable to reload config entries than reload entities. entities also were getting stuck. now it have been resolved.
I haven’t had to reload the Tuya integration for almost 24 hours. Anyone know if there was progress on the implementing the fix? Or, have I just been lucky? 
Update: 
Had to reload again at just about the 24-hour mark.
the PR fixing the issue has been merged today, so it’s likely to be included in the 12.6 release. in the meantime the manual fix is easy.
Unfortunately, the manual fix of restarting or reloading the integration also screws with the logs and makes the items unavailable for a moment, and resets the last state to the current time.
As I have automation that uses a time delta since the last state, this resets the delta.
One of those automations is a heater in the garage fridge to avoid my fridge malfunctioning due to the cold, as it sits right now if I use the reload integration it rests the time since last switched and may cause the heater to run longer than needed, thereby warming the refrigerator up to the point that it can spoil food.
So while the fix may be easy, it is not useful for all.
I hope the PR merge fixes the issue.
I think @molnart might have been referring to the PR as the manual fix. It can be applied in just a few minutes. Two small changes need to be made in the /usr/local/lib/python3.9/site-packages/tuya_iot/openapi.py file. The changes can be seen here:
It took me longer to figure out how to access the file than to make the changes. In case it helps anyone, I use portainer which makes it easy to launch a shell in the homeassistant container. Since I didn’t want to mess with installing an editor in the container shell, I copied the file to my homeassistant directory, edited it with WinSCP, then copied it back to the proper location. After a server restart, the Tuya integration seems to be stable, although time will tell if that fix worked. Hope this helps.
Where did you find the file? I’ve spent some time trawling through my HA server but haven’t been able to locate it anywhere let alone in directory tree shown.
TIA
anyone any idea how to get to the openapi.py file on HAOS (the default for Pi) install?
Latest HA update seems to have fixed this issue. I’ve just installed it hence my cautiousness but it’s looking good with button states correctly reflected on the dashboard.
HA 2021.12.6 solved it for me. See release notes (Update tuya-iot-py-sdk to 0.6.6): 2021.12: New configuration menu, the button entity, and gorgeous area cards! - Home Assistant
Running 2021.12.10. Occasionally I had this issue that status of tuya bulb in HA doesn’t sync to the actual status of the bulb. Not sure how to solve it.
Same as @henry8866 here.
Status of TUYA bulbs get out of sync with HA but it gets fixed after a TUYA/HA reload/reset.
Really thinking about moving to LocalTuya at this point 
I was moving from localtuya. It’s no better. When I was using localtuya, devices were randomly became unavailable, had to remove it and add it back to fix it.
Just reloading that particular device through:
Settings → Integrations → LocalTuya integration → Device → Hamburger Menu → Reload
should be enough. No need to remove and adding it back.
I experienced similar with Local Tuya at the beginning but this phenomenon stopped after a while. Just give it enough time to settle in.
1 Like
Thanks for the information. I may try it later if localTuya is stable.
Do you know if there is service that I can use in NodeRed to do the “reload” as you described?
I am sorry but I can not help you with this one. I am doing nearly all through yaml and config-flow thus I am a novice when it comes to NodeRed 
Anyway, while the first couple of month after having installed Local Tuya I had to reload some devices after every restart of the host or after reloading just Supervisor (no clear pattern which devices failed to load correctly, seemed to be random) this got more and more infrequent over time.
Since quite a while now that reloading hassle is not necessary anymore at all (I maintain 5 installations at different locations which have tuya-based devices). Local Tuya is just working flawlessly and devices/entities based on it survive reboots, even after extended power outages without me having to do anything 
PS. Make sure your tuya devices get sufficient wlan connection strength. Additionally I always assign static ip addresses to each device through the router (since those devices simply not need dynamically assigned ip addresses).