Can't connect to device when Tuya Servers are blocked

[meluvalli]

Very concerning...

When device is blocked from accessing the internet, you can't add the device using this integration.

If the device can connect to Tuya servers, then I can add it as normal and control it supposedly locally.

I tested with tinytuya and it works fine regardless of connected to Tuya Servers or not. Why would this integration not be able to control it locally when it can't connect to Tuya servers?

[make-all]

This integration does not make any connections to the Tuya servers, and it uses tinytuya underneath, so if tinytuya can connect, so can this integration. I don't have any explanation for what you experienced but you seem to have jumped to a conclusion that is not backed up by the facts.

[meluvalli]

I'm not sure how I could prove it.. But, tinytuya does indeed connect.. But this plugin does not. But this is ONLY the case if I block my Tuya device from the internet.

[meluvalli]

Ok. After more research, I apologize, but I may have figured out the issue partly. It appears it's the device. The device when I run this command with tinytuya:

# Connect to Device
d = tinytuya.OutletDevice(
    dev_id='[My Device ID]',
    address='[My Tuya Device IP]',      # Or set to 'Auto' to auto-discover IP address
    local_key='[My Local Key]', 
    version=3.3)

data = d.status() 
print('set_status() result %r' % data)

I get the below response:

set_status() result {'dps': {'11': 0, '12': False, '14': 0, '15': 0, '19': True, '101': 'ac_power_on', '103': 'real_time_mode', '112': 3}}

However, if I block it from the internet, and reboot the device... Then re-run the same command, it gives me:

set_status() result {'dps': {}, 'type': 'query', 't': 180}

So, it appears it doesn't work while it's not connected to Tuya :( The strange thing is... I can still manually control the device with commands like:

data = d.set_status(3, 3)

This is a cat feeder and if I run that, it triggers the cat feeder and fees them 3 servings as expected! So, I wonder why I can't pull the device info without it connected? Either way, I apologize for assuming your program wasn't working and tinytuya was. When I was testing tinytuya, I was just using the command to for the feeder to trigger 3 servings and it was working. This is why I assumed TinyTuya worked, and your device didn't.

[robinhood-code]

Is it related to NOTE 2 of this link?

https://github.com/rospogrigio/localtuya?tab=readme-ov-file#usage

[meluvalli]

Yep. That's it! Dumb! Haha! So no way around this as of now apparently :( Thank you for pointing me in the correct direction! I guess I'll just use rospogrigio/localtuya for now so that I can get the device working offline. I'm scared to let it go online all the time because you never know if they'll push an update that'll block local access.

[robinhood-code]

I think you can still use Tuya-Local, but you have to allow the internet access first just to add the device. After you've added the device then you can proceed to block the internet access, as well as connection to the local DNS server (which is usually your router).

[meluvalli]

If I add the device with internet access, it does indeed work. So, I then blocked it. Now the problem is, if the feeder looses power and/or reboots, I have to allow internet access again. If I don't the device stays in "Unavailable" mode in HA. :( This is because again, the device looses all DPS values :(. Even though I can manually still set them with tinytuya.

[make-all]

Did you block the device from using DNS (possibly not an easy option to configure on most consumer routers)?

[meluvalli]

On my DHCP server, I forced it a reservation IP and set the DNS to be IP 127.0.0.1. I could leave it to my actual DNS server and block its access, but I seriously doubt that would make a difference in this case as seeing it drops the dps no matter what.

…

On Mon, Feb 12, 2024 at 7:12 AM Jason Rumney ***@***.***> wrote: Did you block the device from using DNS (possibly not an easy option to configure on most consumer routers)? — Reply to this email directly, view it on GitHub <#1644 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCTHBAEG2RKKBZKXIUZEWLYTIPONAVCNFSM6AAAAABDDV44CGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINBSGIYTG> . You are receiving this because you authored the thread.Message ID: ***@***.***>