rospogrigio / localtuya

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

Disconnect from Tuya Cloud #121

Closed TheFes closed 3 years ago

TheFes commented 4 years ago

Is it possible to disconnect the devices from Tuya Cloud, and only use them local? I tried to prevent them from connecting to the internet, but the devices became unavailable. A reboot did not help, and they were not showing as connected devices in my router anymore. After allowing internet access again, and reloading the integration, they were available again.

When the device is removed from the Tuya app (with internet access allowed) they will go to pairing mode (flashing light).

I would like to use them only locally, to make my network more secure.

postlund commented 4 years ago

You can create an account at tuya and register them locally with tuya-cli. Internet access is required when registering a new device, but not needed after that:

https://github.com/codetheweb/tuyapi/blob/master/docs/SETUP.md

rapi3 commented 4 years ago

IoT tuya devices will always try to connect to tuya home once they are connected to wifi. This is why "tuya" or better Chinese Government don't want you to be able to flash them with another firmware, it is used as a trojan horse in any network if required. Only chance once you have the keys is to block them from your firewall to go on www and allow communication only with your HA server IP. My recommendation for tuya IoT devices is to always use them on a separate wifi without access to your lan if can't be flashed with Tasomata firmware.

TheFes commented 4 years ago

I think my initial post was not clear. I was able to connect to my devices using localtuya (only my doorsensor is still missing, but there is work in progress on that) I got these devices working yesterday, and after that I blocked them from using the internet using the built in firewall in my router. After that they were not working with the Tuya app anymore, but they were working using localtuya (which was as expected) They were working fine after that, but somewhere during the night/morning they lost connection to my router. Maybe they automatically disconnect after some failed attempts to connect to the cloud. After I gave them access to the internet again, and reloaded the localtuya integration, I was able to connect to them again.

However, I was hoping that using localtuya I could block them from the internet.

rapi3 commented 4 years ago

This behavior only prove that this tuya devices will try to connect to home server and if case they know are blocked will render them unusable in lan also. This is not good and can be a newer/future tuya firmware behavior. I am testing 4 nooie plugs on local-tuya HA server only as I have the keys for them: I give them from firewall access to local NTP and DNS server and my HA server only, they are on separate vlan only for IoT from begining:

TheFes commented 4 years ago

These are fairly new devices, as otherwise I would have flashed them with tuya convert. I don't have the soldering skills to flash them in another way :)

postlund commented 4 years ago

Tuya devices are by definition cloud first, so that's something you accept when opening the box. The fact that we can control them locally like this is just a bonus. And I'm gonna stay out of the conspiracy theories.

I think all new hardware (or at least the majority of it) are based on Realtek circuits now. I tried to create a power socket in the tuya developer console yesterday and Realtek based SoCs were my only choice. So tuya-convert is gonna be less and less relevant as time goes by, unless they start to target other SoCs as well (same for tasmota or any other alternative firmware).

postlund commented 3 years ago

Not sure how to tackle this. Anyone else running tuya devices in an isolated network and have if working?

rapi3 commented 3 years ago

For me Nooie tuya plugs are still working OK until now locked in vlan. From firewall I also override ip address for host m1.tuyaeu.com, m2.tuyaeu.com, m3.tuyaeu.com as this is the DNS they request after set up so all communication MQTT ( and not only that ) will go to/from my HA server. Try to give to your devices TCP access to local: DHCP, NTP, DNS, HA server only and block all other, remove from main power and restart devices. p.s. my plugs are paired with original seller sw nooie and not smart life or another clone, long time ago I tried nooie plugs with another tuya app to test IFTTT and I had bad results and lost part of plugs feature.

pakordo commented 3 years ago

I have several type of switches (lights, curtain and plugs). I denied access to internet for all devices in router and all work as expected with ha. When i open smart life app connected to 4G all devices appears offline. When i open smart life app connected to local wifi, 3 devices appears online. I think that devices connect to cloud through the app.

TheFes commented 3 years ago

Just enabed the MAC filter in my router firewall again to disable outside connection for 1 light and switch. Will keep track if, and when they become unavailable again.

@postlund thanks for the efforts you are putting into localtuy and also responding on issues! Greatly appreciated!

postlund commented 3 years ago

Thanks for the reports! I assume that manufactures have some possibilities to decide how devices act if they don't have cloud connectivity. We will just have to accept the fact that some may not work without it - even locally.

Thanks @TheFes, appreciate It 👍 Hope you enjoy the work!

TheFes commented 3 years ago

According to the log in HA my devices got unavailable around 19:07, so it seems they disconnect after less than 3 hours

Log:

[05047501c82b964132e7] Heartbeat failed (), disconnecting
Traceback (most recent call last):
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 346, in heartbeat_loop
    await self.heartbeat()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 435, in heartbeat
    return await self.exchange(HEARTBEAT)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 407, in exchange
    msg = await self.dispatcher.wait_for(seqno)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 206, in wait_for
    await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
  File "/usr/local/lib/python3.8/asyncio/tasks.py", line 498, in wait_for
    raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

Like before, disabling the MAC filter in my router firewall, and reloading the integration got them back online in HA.

postlund commented 3 years ago

When this happened, are the devices till associated to your AP and have an IP address? Can you enable debug logs and attach them?

TheFes commented 3 years ago

Didn't check this time, but the first time I noticed they did not have an IP anymore in my AP. I will do another test tomorrow, as I will already be asleep in 3 hours.

postlund commented 3 years ago

What ponders me about that is: how do they know they have no connection to the cloud if they aren't even on the network?

TheFes commented 3 years ago

My first idea was that (at least on newer firmwares) there is a check which disconnects them from the network after several failed attempts. However, that does make me wonder how they are able to reconnect immediately after I remove the block, without having to power them down or anything.

Will send a log file tomorrow.

postlund commented 3 years ago

Yeah, they probably wake up every once in a while to phone home. Depending on your AP, maybe you can see that? Otherwise you can just assign them a static IP lease and ping the devices from another machine. Should reveal the wake up frequency.

TheFes commented 3 years ago

I did another test today (sorry, my weekend was a bit more full than expected). My AP is provided by my internet provider (KPN) and is limited in settings. It's an Experiabox 10A I have only two devices in local tuya now, but for some reason the MAC filter was not applied correctly to one of them. So it remained available in the tuya app, and was not disconnected from HA.

For the other device the timeline was like this: 14:18 - Enabled MAC Filter in firewall 17:50 - device became unavailable in HA 18:30 - Did a check, and the device was no longer connected to AP, not sure from which point, but I assume from 17:50 19:53 - MAC filter disabled in firewall 19:53 - Device was connected immediately to AP 19:55 - Device was connected to HA again

I have a debug log, but it is a bit polluted by the other device which kept working. So I will remove that one as well, and test with only one device again tomorrow. I will also run a ping command at the same time, so it will be visible when the device disconnects and reconnects exactly.

I'm also wondering if it could be my AP which disconnects the device, but I can't find anything about that online, and also don't see a relevant setting in the AP web interface.

postlund commented 3 years ago

To me it sounds like your MAC-filtering is used to disallow clients to connect at all, I.e. not just restrict access to internet. That is how my airports work too. So this of course explains why it doesn't work. One thing you can try is to change the DNS server your DHCP sets and put in a bogus one and then attach your device. Hopefully it should come online but fail to establish a cloud connection. You should see it in Home Assistant but not in smartlife.

TheFes commented 3 years ago

Hi @postlund

I did some additional tests, and it indeed seems to be the applied MAC-filter. I tested with another device, and it disconnect when the DHCP lease ended. So the problem is not in localtuya or tuya cloud.

I have to find another way to block external access.

Thanks for your support on this! As far as I'm concerned this issue can be closed.

postlund commented 3 years ago

Great to have it confirmed, thanks! The easiest solution is probably to run an internal DNS server (e.g. dnsmasq, which a believe you can run as an addon) and point the servers tuya uses to a bogus host (127.0.0.1 for instance). Best solution would of course be a separate network though.