rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
2.85k stars 546 forks source link

Device unavailable when powered on while internet not available #501

Closed joe-sydney closed 2 years ago

joe-sydney commented 3 years ago

The problem

My Kogan smart plug is unavailable when it is started (powered on) without Internet.

(The specfic smart plug is this: Kogan SmarterHome Smart Plug With Energy Meter & 5V 2.4A USB Ports)

When I power on the device when internet is available (unblocked), the device appears available. When I subsequently block Internet from the device, the device continues working as expected under localtuya.

ie this problem only occurs when the device is powered on while Internet is blocked. I have tested this on 2 plugs of the same type.

I have a few other devices using localtuya that has Internet blocked and they are working well.

Environment

Steps to reproduce

  1. Block internet from device (via firewall configuration)
  2. Unplug the device from mains
  3. Plug it back in

Configuration configuration.yaml or config_flow

ID: 1 Friendly name: testy Current: 18 Current consumption: 19 Voltage: 20

DP dump

Provide Home Assistant taceback/logs

2021-06-09 22:42:17 ERROR (MainThread) [custom_components.localtuya.common] [xxx...xxx] Connect to X.X.X.X failed Traceback (most recent call last): File "/usr/local/lib/python3.9/asyncio/locks.py", line 413, in acquire await fut asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.9/asyncio/tasks.py", line 487, in wait_for fut.result() asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last): File "/home/homeassistant/.homeassistant/custom_components/localtuya/common.py", line 149, in _make_connection status = await self._interface.status() File "/home/homeassistant/.homeassistant/custom_components/localtuya/pytuya/init.py", line 472, in status status = await self.exchange(STATUS) File "/home/homeassistant/.homeassistant/custom_components/localtuya/pytuya/init.py", line 467, in exchange return await self.exchange(command, dps) File "/home/homeassistant/.homeassistant/custom_components/localtuya/pytuya/init.py", line 451, in exchange msg = await self.dispatcher.wait_for(seqno) File "/home/homeassistant/.homeassistant/custom_components/localtuya/pytuya/init.py", line 240, in wait_for await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout) File "/usr/local/lib/python3.9/asyncio/tasks.py", line 489, in wait_for raise exceptions.TimeoutError() from exc asyncio.exceptions.TimeoutError

joe-sydney commented 3 years ago

Home Assistant logs added to 1st message above.

joe-sydney commented 3 years ago

OK, after going through a few other issues from others, I think mine is related to the zombie-fix one... however, I tried the zombie-fix but it didn't work for me.

On the other hand, I was able to get the switch working without this zombie issue using the node-red tuya-local node, but didn't continue using it because the energy values were not being updated... which is another common issue. I was able to poll by issuing Command 18 via tinytuya, but of course if I couldn't run the node-red node at the same time (more than one connection doesn't work).

python3 ./energymon.py

Request Update for DPS indexes 18, 19 and 20 < Fetch Status Again < Energy Mon: {'devId': 'xxxxxxxxxxxxxx', 'dps': {'18': 76, '19': 80, '20': 2439}}

So I am optimistic my issue will eventually be fixed because the bits and pieces are there :)

david-collett commented 3 years ago

I appear to have the same issue with mirabella lightbulbs.

I haven't found any specific advice for internet blocking tuya other than the comment about DNS in the main README. I've tried blocking the domains *.tuya[cn|eu|us].com via DNS in the following ways:

  1. return NXDOMAIN
  2. return 127.0.0.1
  3. iptables REJECT 53/UDP.
  4. iptables DROP 53/UDP.

In all 3 cases, the bulb is not available after a restart. This is despite seeing some 2-way traffic between HA and the bulb on port 6668. Any ideas?

amorsen commented 3 years ago

I have a "Lilon Tuya 20A Water Heater Switch" with the same issue.

When all traffic is blocked on startup, the device tries to look up m2.tuyaeu.com. When the name resolution fail, the device drops its IP address and requests a new one with DHCP. Port 6668 stays blocked.

If name resolution is permitted (but nothing else), the device contacts 35.156.44.172 port 8886 and starts announcing itself on the LAN on UDP port 6667. However, port 6668 still stays blocked.

Only when m2.tuyaeu.com gives the go-ahead does the device unlock itself and allow connections on port 6668.

This somewhat defeats the purpose of localtuya :(

BSmith-66 commented 3 years ago

same problem with same device as @joe-sydney if i block internet access the smart plugs don't show up (dns not enough) but if allow internet access they work as per normal restarting integrations didn't help

shtrom commented 2 years ago

Dupe of #445 (which has an open PR: #491)?

joe-sydney commented 2 years ago

closing because this issue is reported multiple times in other open issues