Tuya devices stopped changing state

Configuration
1

Hey everyone

Real head scratcher here. 2 days ago my tuya devices stopped reflecting state changes in hassio (if I turn on/off at device or using Alexa), if I change the state manually using the toggle in hassio ui, it works fine.

It was happening on all of my tuya devices initially and after some digging in here, I found that some people had issues with tuya last year and migrating the devices from smart life to tuyas own app worked. So I did it. And it partly worked. My smart switches now reflect state changes.

However, none of my tuya smart plugs will reflect state changes still. I’ve restarted and rebooted everything. I’ve deleted the tuya integration and reinstalled.

I’d like to avoid flashing if I can as I’ve never done it, not an engineer and not massively comfortable opening the devices to solder either.

Anyone any ideas where I am going wrong here?

Edit * I dont believe I have made any config changes that could/should be causing this.

Edit edit* I’ve not yet updated to the latest version of home assistant.

1 Like
2

I THINK I might have figured this out. So in the Alexa app - two devices for each device is discovered. For example - I have “hall light” configured in the Tuya app, Alexa discovers this. HA will then discover it and then Alexa discovers the HA device of the same name. When I ask Alexa to turn it off, it is changing the Alexa device/entity and not the one in HA.

I changed the names of the alexa devices and now the changes are being reflected in HA (for all but one plug).

I’ve yet to test if turning on/off at source will reflect in Ha but I am getting there…I hope.

3

Nope, still no change when state is changed from switch. (Or from tuya app).

4

I’d love to hear if this is just me and I’ve messed something up, or if this is a Tuya API thing. Not being able to check the state has really messed up a lot of my automations!

5

The below is showing up in the logs: Log Details (ERROR)
Logger: homeassistant.helpers.entity
Source: components/tuya/init.py:254
First occurred: August 22, 2020, 12:02:13 AM (684 occurrences)
Last logged: 11:03:20 PM

Update for switch.43300007bcddc2677a2b_2 fails
Update for switch.bf51f149fc36aa8ccapcoc fails
Update for switch.83886640bcddc266fcee fails
Update for switch.bf110650d38b958dfb0ykp fails
Update for switch.0320018160019477df2a fails
Traceback (most recent call last):
File “/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 670, in urlopen
httplib_response = self._make_request(
File “/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 426, in _make_request
six.raise_from(e, None)
File “”, line 3, in raise_from
File “/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 421, in _make_request
httplib_response = conn.getresponse()
File “/usr/local/lib/python3.8/http/client.py”, line 1332, in getresponse
response.begin()
File “/usr/local/lib/python3.8/http/client.py”, line 303, in begin
version, status, reason = self._read_status()
File “/usr/local/lib/python3.8/http/client.py”, line 272, in _read_status
raise RemoteDisconnected(“Remote end closed connection without”
http.client.RemoteDisconnected: Remote end closed connection without response

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/local/lib/python3.8/site-packages/requests/adapters.py”, line 439, in send
resp = conn.urlopen(
File “/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 726, in urlopen
retries = retries.increment(
File “/usr/local/lib/python3.8/site-packages/urllib3/util/retry.py”, line 403, in increment
raise six.reraise(type(error), error, _stacktrace)
File “/usr/local/lib/python3.8/site-packages/urllib3/packages/six.py”, line 734, in reraise
raise value.with_traceback(tb)
File “/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 670, in urlopen
httplib_response = self._make_request(
File “/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 426, in _make_request
six.raise_from(e, None)
File “”, line 3, in raise_from
File “/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 421, in _make_request
httplib_response = conn.getresponse()
File “/usr/local/lib/python3.8/http/client.py”, line 1332, in getresponse
response.begin()
File “/usr/local/lib/python3.8/http/client.py”, line 303, in begin
version, status, reason = self._read_status()
File “/usr/local/lib/python3.8/http/client.py”, line 272, in _read_status
raise RemoteDisconnected(“Remote end closed connection without”
urllib3.exceptions.ProtocolError: (‘Connection aborted.’, RemoteDisconnected(‘Remote end closed connection without response’))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 272, in async_update_ha_state
await self.async_device_update()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 465, in async_device_update
await self.hass.async_add_executor_job(
File “/usr/local/lib/python3.8/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/src/homeassistant/homeassistant/components/tuya/init.py”, line 254, in update
self._tuya.update()
File “/usr/local/lib/python3.8/site-packages/tuyaha/devices/switch.py”, line 29, in update
devices = self.api.discovery()
File “/usr/local/lib/python3.8/site-packages/tuyaha/tuyaapi.py”, line 117, in discovery
response = self._request(“Discovery”, “discovery”)
File “/usr/local/lib/python3.8/site-packages/tuyaha/tuyaapi.py”, line 163, in _request
response = self.requestSession.post(
File “/usr/local/lib/python3.8/site-packages/requests/sessions.py”, line 578, in post
return self.request(‘POST’, url, data=data, json=json, **kwargs)
File “/usr/local/lib/python3.8/site-packages/requests/sessions.py”, line 530, in request
resp = self.send(prep, **send_kwargs)
File “/usr/local/lib/python3.8/site-packages/requests/sessions.py”, line 643, in send
r = adapter.send(request, **kwargs)
File “/usr/local/lib/python3.8/site-packages/requests/adapters.py”, line 498, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: (‘Connection aborted.’, RemoteDisconnected(‘Remote end closed connection without response’))

6

I’ve built a workaround for this using nodered alexa-remote-2 and some iinput_booleans. It’s not pretty and it’s processor heavy but short of flashing the devices there was little else I could do.

Attempted to install Tuya custom but it wouldn’t install for me. If anyone come across this issue in the future, I’d be glad to share the workaround.

7

I have the same issue.
Using tuya switch via HA works perfectly but when I toggle on/off directly from physical switch or Tuya app, HA don’t sync the correct state.
For example:

  • Light is ON (HA shows ON)
  • Toggle off from Tuya App (or manually), HA still shows ON
    How can I fix that?
2 Likes
8

Same here. I just discovered this misbehavior. If I toggle the switch through Alexa HA doesn’t sync it accordingly.
I’ll check what Alexa’s devices has discovered for duplicates, but I exposed only scripts to her. So, I think it is a integration issue.

9

I believe it is an issue with the API that Tuya are in zero rush to change. It’s a pity because the workaround is slow and clunky.

10

same here :frowning:

11

I have the same issue, does anyone know if there is any been any update to this issue, or any expected change in the near future?

12

Same issue here, any progress on a fix?

13

I’m seeing the same issue. Contrary to some of the notes above, I think this is an issue with the HA integration rather than the Tuya API, as the status of the devices show fine in both Alexa and Google Home. If the API didn’t support status updates, then neither Alexa nor Google would see the status.

Also - if I reload the Tuya integration from the HA admin interface then this triggers an update to the correct status, which suggests that HA is able to read the device status, but isn’t doing so unless manually triggered.

14

I switched to using Localtuya integration and it has now given me full control of the tuya lights in real time via voice control and HASS and all entities update as originally expected.

You need to do a little node.js command line work to extract the keys from the bulbs/devices themselves but its a quick process

15

Thanks, that should work a lot better and also avoid some of the processing delays that occur in the basic internet based Tuya integration.
However - not having worked before with custom components I think I must be making a beginner mistake or two here as localtuya doesn’t seem to show up as an available integration.

I followed the instructions on one of the github sources (https://github.com/rospogrigio/localtuya) and copied the files to my custom_components folder, then re-started HA as per instructions, but this doesn’t seem to actually make the integration available.

I’ve tried this with a couple of different sources on github (which one is the best?) and also on 2 different installations of HA (HA Core on Ubunutu / Docker on Synology) but get the same result with any of these combinations. Any ideas how to make this active? Most of the notes seem to suggest that the extraction of keys to configure individual lights/switches is the potentially difficult part, as localtuya should find the devices - but I’m not even getting to that stage.

16

Very strange - I just came back to this the next day, and not having changed anything, the Tuyalocal integration is now appearing. Something just seems to have made HA take a very long time (12 hours or more) to load the custom component.
Is this normal ? The same delay seems to have occurred on both the Core/Ubuntu and Docker based versions.

1 Like
17

Having discovered the local keys, this is now working very well for WiFi based Tuya devices but is failing for those which are connected via the Tuya Zigbee hub/gateway.
I’m wondering whether I am missing something in the configuration which is hub specific, as when I use the scripts to get the local keys, I am finding that the Zigbee hub, and the sub-devices linked through that seem to share the same local key - though the device ids are different.

The configuration below works fine for the WiFi based switch - and updates to the status in HA are now instant - which is great:
localtuya:

  • host: 192.168.1.203
    device_id: !secret KitchenDeviceID
    local_key: !secret KitchenLocalKey
    friendly_name: Kitchen Light
    protocol_version: “3.3”
    entities:

    • platform: binary_sensor
      friendly_name: KItchen Light
      id: 1
      device_class: power
      state_on: “true” # Optional
      state_off: “false” # Optional

    • platform: switch
      friendly_name: KItchen Switch
      id: 1
      current: 18 # Optional
      current_consumption: 19 # Optional
      voltage: 20 # Optional

However, a similar configuration for the Zigbee device just results in entities which show as “unavailable”. As the Zigbee switch does not have it’s own IP address, I am using the address of the hub + the device ID of the switch and their shared local key.
If I try to configure this using the UI rather than configuration.yaml, then I only see it detect the device IDs for the WiFi switch and the hub (though the hub shows no data properties). The device ID for the ZIgbee device is not shown at all.
Does this mean that LOCALTUYA (or at least the version on https://github.com/rospogrigio/localtuya)doesn’t support the Tuya Zigbee hubs and associated devices?
Thanks

18

Have you solved the issue? Just thinking, is it because you had link tuya apps with Alexa/google and HA. Have you try unlink with Alexa/google. Let HA do the exchange of states. Which nabucasa will handle the exchange with Alexa/google.

19

I haven’t actually, that’s a good shout. Will try that tonight.

20

having the same issue!! not working yet