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.
Interesting. Mine is still broken. After I saw your message I checked and mine had not started working again. I restarted the Tuya integration (disable/enable) which got all the sensors responding, but only for a few hours. Now that I check after leaving it overnight I’m back to everything being unresponsive.
Frustrating…
Today it seems that also for me Tuya devices are working properly (again). I do get instant notifications on my HA (and Google Home Nest) at the time I also get notifications in Tuya app when opening door/window sensor. Happy. Hope it wil stay that way.
(I’ve a 6 month Tuya subscription and active for just few weeks)
I don’t know if it has to do with this: I logged in in the developer portal and went to my device and looks at the device debug log. This could also triggered something. Hope it was not this and someone woke up in Tuya to turn on something… 
What? Developer mode? Yes, I checked and that’s not the problem. Presumably they wouldn’t work at all in that case, rather than working for a couple of hours and then stopping?
As others have said it is for me just the sensors that don’t work. I can turn on/off Tuya connected lights just fine, so the basic connection is working. I just don’t get data from temp or motion sensors.
New version: Tuya Test v2.5
The following automation is a workaround, which has proven for months to be a working solution for the complete Tuya lock-up problem. This will mainly test and only executes a reload when there is really a lock-up, because every reload creates a “Tuya outage” of 20 seconds where you might loose data.
It requires some tinkering: define helpers and define the device.entity in the automation and modify or delete the reporting (I used Telegram), if needed. There is now also logging written to the syslog, so you can always verify the functioning.
Rough steps to take:
I made a little dashboard with the two counter entities (unit is minutes):
The automation (copy into a new automation and disable immediately, after saving, until you are ready setting up the helpers and defining the “master test sample” Tuya device-entity ):
alias: Tuya Test v2.5
description: >-
This automation is a work-around to reload the Tuya integration when the Tuya
process locks up. This is tested by setting and probing an entity every 5
minutes. When a test fails, there will be one additional retry after one
minute, before the decision to reload. This approach, sees to it, that a
reload is only performed when really necessary, because a reload creates a
Tuya "outage" of more than 20 seconds. You can scan the system-log for entries
with: [Automation][TuyaTest2.5]
trigger:
- platform: time_pattern
minutes: /1
condition:
- condition: or
conditions:
- condition: template
value_template: "{{ ((now().strftime('%M')|int(0) % 5) == 0) }}"
- condition: template
value_template: "{{ states('counter.tuya_failed')|int(0) == 1 }}"
action:
- service: telegram_bot.send_message
data:
message: >-
Debug: Check started{{'\r\n'}}Success-counter =
{{states('counter.tuya_success')}} min Failed-counter =
{{states('counter.tuya_failed')}} min
disable_notification: true
enabled: false
- service: system_log.write
data_template:
message: >-
[Automation][TuyaTest2.5] Check started: Success-counter =
{{states('counter.tuya_success')}} min Failed-counter =
{{states('counter.tuya_failed')}} min
level: debug
enabled: false
- if:
- condition: state
entity_id: switch.yyyyy_child_lock
state: unavailable
then: null
else:
- if:
- condition: device
type: is_on
device_id: xxxxx
entity_id: switch.yyyyy_child_lock
domain: switch
then:
- service: input_boolean.turn_on
data: {}
target:
entity_id: input_boolean.tuya_test_tempstate
else:
- service: input_boolean.turn_off
data: {}
target:
entity_id: input_boolean.tuya_test_tempstate
- type: toggle
device_id: xxxxx
entity_id: switch.yyyyy_child_lock
domain: switch
- delay:
hours: 0
minutes: 0
seconds: 30
milliseconds: 0
- choose:
- conditions:
- condition: or
conditions:
- condition: state
entity_id: switch.yyyyy_child_lock
state: unavailable
- condition: and
conditions:
- condition: device
type: is_off
device_id: xxxxx
entity_id: switch.yyyyy_child_lock
domain: switch
- condition: state
entity_id: input_boolean.tuya_test_tempstate
state: "off"
- condition: and
conditions:
- condition: device
type: is_on
device_id: xxxxx
entity_id: switch.yyyyy_child_lock
domain: switch
- condition: state
entity_id: input_boolean.tuya_test_tempstate
state: "on"
sequence:
- if:
- condition: template
value_template: "{{ states('counter.tuya_failed')|int(0) >= 1 }}"
then:
- if:
- condition: template
value_template: "{{ states('counter.tuya_failed')|int(0) == 1 }}"
then:
- service: counter.reset
data: {}
target:
entity_id: counter.tuya_success
- service: counter.decrement
entity_id: counter.tuya_failed
- service: telegram_bot.send_message
data:
message: >-
Error: No Tuya reaction anymore{{'\r\n'}}Success-counter
= {{states('counter.tuya_success')}} min Failed-counter
= {{states('counter.tuya_failed')}} min
disable_notification: true
enabled: true
- service: system_log.write
data_template:
message: >-
[Automation][TuyaTest2.5] No Tuya reaction anymore:
Success-counter = {{states('counter.tuya_success')}}
min Failed-counter = {{states('counter.tuya_failed')}}
min
level: error
- repeat:
count: 5
sequence:
- service: counter.increment
entity_id: counter.tuya_failed
- service: telegram_bot.send_message
data:
message: "Warning: Reload Tuya integration in progress{{'\r\n'}}Success-counter = {{states('counter.tuya_success')}} min Failed-counter = {{states('counter.tuya_failed')}} min"
disable_notification: true
enabled: true
- service: system_log.write
data_template:
message: >-
[Automation][TuyaTest2.5] Reload Tuya integration in
progress: Success-counter =
{{states('counter.tuya_success')}} min Failed-counter =
{{states('counter.tuya_failed')}} min
level: warning
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- service: homeassistant.reload_config_entry
data: {}
target:
entity_id: switch.yyyyy_child_lock
- delay:
hours: 0
minutes: 0
seconds: 20
milliseconds: 0
else:
- service: counter.increment
entity_id: counter.tuya_failed
- service: system_log.write
data_template:
message: >-
[Automation][TuyaTest2.5] Retry, Tuya Test failed once:
Success-counter = {{states('counter.tuya_success')}} min
Failed-counter = {{states('counter.tuya_failed')}} min
level: warning
- service: telegram_bot.send_message
data:
message: "Warning: Retry, Tuya Test failed once{{'\r\n'}}Success-counter = {{states('counter.tuya_success')}} min Failed-counter = {{states('counter.tuya_failed')}} min"
disable_notification: true
enabled: false
default:
- if:
- condition: template
value_template: "{{ states('counter.tuya_success')|int(0) == 0 }}"
then:
- service: counter.reset
data: {}
target:
entity_id: counter.tuya_failed
- service: telegram_bot.send_message
data:
message: >-
"Warning: Tuya is active again{{'\r\n'}}Success-counter =
{{states('counter.tuya_success')}} min Failed-counter =
{{states('counter.tuya_failed')}} min"
disable_notification: true
enabled: true
- service: system_log.write
data_template:
message: >-
"[Automation][TuyaTest2.5] Tuya active again: Success-counter =
{{states('counter.tuya_success')}} min Failed-counter =
{{states('counter.tuya_failed')}} min"
level: warning
- if:
- condition: template
value_template: "{{ states('counter.tuya_failed')|int(0) == 1 }}"
then:
- service: counter.reset
data: {}
target:
entity_id: counter.tuya_failed
else:
- repeat:
count: 5
sequence:
- service: counter.increment
entity_id: counter.tuya_success
- if:
- condition: state
entity_id: switch.yyyyy_child_lock
state: unavailable
then: null
else:
- if:
- condition: state
entity_id: input_boolean.tuya_test_tempstate
state: "on"
then:
- type: turn_on
device_id: xxxxx
entity_id: switch.yyyyy_child_lock
domain: switch
else:
- type: turn_off
device_id: xxxxx
entity_id: switch.yyyyy_child_lock
domain: switch
mode: single
Where have you got this from? I raised a ticket with them, describing the problem in detail and explaining that loads of people all over the world are seeing the problem, but all I got back was “can you send a video of the problem please”.
I to was having problems with Tuya PIR Sensors and more recently smart plugs. I’m now happy to report this problem is going away… As I change over to WiZ products, all sorted now. Tuya was fun to mess with as I set up Home Assistant, but WiZ just works for my mission critical automations… you dont win points with the wife if it’s pitch black on the stairs at night!!
It looks like Tuya delivered on their promise to fix this in May. I upgraded my HA instance to 2023.5.1 almost as soon as it was out and as expected the Tuya sensors started working again after the restart but stopped a few hours later as has been happening for a while now. But a couple of days later they magically sprang into life and have been working ever since. This seems to happen on May 5th at about 10:30am BST.
So, thanks Tuya!
Steve.
Good for you. But I’m still getting 5-7 Reloads/day but I’m at (latest?) version 2023.3.3.
Don’t know how get your 2023.5.1 version.
Still broken here. I have a node red flow that checks it by operating a plug, waiting a few seconds, and then seeing if the status in HA is as expected. If not, it reloads the integration. This fires about 6 times a day, still doing it.
2023.5.1 (now 2023.5.2) is just the latest version - you should be able to get it however you normally get your upgrades. For me running it in Docker, I just had to pull the latest stable docker image.
But I didn’t think the HA upgrade is what fixed it. In fact, after the upgrade it was still as broken as before and it wasn’t until a few days later that everything started working properly again. But maybe whatever Tuya did (nothing changed at my end to make it start working so it must have been something Tuya did, right?) is dependent on the new version? I don’t know how to tell, now. I don’t have my old version anymore.
I hope you get it sorted out soon. It was certainly very frustrating for the few months it was broken for me.
Steve.
It has slowly dawned on me that I haven’t seen my tuya auto-reload fire for the past couple of days, the problem seems to have gone away… Anyone else seeing no failures now? I have updated to 2023.5.3, is that what has fixed it?
Yes, you’re right. I was already costumed to neglect the messages which I received in my Telegram each reload. Last one is 16th may. Hope I will stay that way.
I’m also curious what changed.
some months have passed and my tuya devices start becoming unresponsive again.
How about you guys?
Now it is 3 days ago that I got an hick-up, but the week before that last occasion was terrible, it made me activate my “auto-reload-on-Tuya-stuck” (Tuyatest) automation again.
as of today, what type of automated reload mechanism would be the best?
update: Just tried your Tuya Test v2.2 automations script 
Can you tell me where in the script the tuya integration gets reloaded? I cannot find it.
It is loaded by this mechanism (you can find it in the just updated script in message 31 above):
- service: homeassistant.reload_config_entry
data: {}
target:
entity_id: switch.yyyyy_child_lock