Stale device status after disallowing internet access

[lankhaar]

I have a robot vacuum which I was able to control locally, but after cutting it off from the internet I no longer get any status updates...

Here's the script:

import tinytuya
import sys
import time

device = tinytuya.Device('DEVICE_ID', 'IP', 'LOCAL_KEY')
device.set_version(3.3)

request = sys.argv[1]

if (request == 'status'):
  print('Datapoints %r' % device.status())
  sys.exit()

if (request == 'start'):
  payload=device.generate_payload(tinytuya.CONTROL, {'1': True, '2': False})

if (request == 'pause'):
  payload=device.generate_payload(tinytuya.CONTROL, {'2': True})

if (request == 'charge'):
  payload=device.generate_payload(tinytuya.CONTROL, {'4': 'chargego'})

print('Control response %r' % device._send_receive(payload))
device.send(device.generate_payload(tinytuya.UPDATEDPS))

When the device is allowed to access the internet, this is the response I get:

 % python3 myscript.py start
Control response {'dps': {'1': True, '2': False}, 'type': 'query', 't': 1720469539}

Then I disconnect the device from the internet (in my firewall I block all outgoing and incoming requests to the vacuum, including the DNS requests) and now the reponse looks like this:

 % python3 myscript.py start
Control response None

The vacuum does start cleaning, it listens to all commands, however when requesting the status, it didn't update it's dps.

Later down the line I added the following to test stuff out, but I never received any dps updates untill I unblocked the device's internet connection. This however is quite an invasion to my privacy imo, so I want it to be disconnected from the WAN.

if (request == 'update_status'):
  while(True):
    device.send(device.generate_payload(tinytuya.UPDATEDPS))
    print('Datapoints %r' % device.status())
    time.sleep(1)

[jasonacox]

Hi @lankhaar - I understand. Unfortunately, Tuya devices are designed to be "cloud first". The fact that we have been able to use their local APIs is a nice feature and the motivation behind projects like TinyTuiya. However, some of the devices don't behave well or have only limited functionality without the cloud.

If you haven't done so already, you could try to switch to persistent connection mode and see if you get status updates: See https://github.com/jasonacox/tinytuya/blob/master/examples/monitor.py as an example.

[lankhaar]

Hi @jasonacox , thank you kindly for your response!

I have tried that already, unfortunately to no avail. Could this possibly be fixed in the future?

Could this be solved the hard and tedious way by proxying the requests to a local API to mimic tuya's response? If so I'm up to give that a go. Not sure if you have an idea already how Tuya handles that? Does Tuya just confirm the updated DPs? And does tuya do this synchronously or asynchronously? It might be unrelated, but my assumption is async because if I only block inbound traffick but allow outbound traffick it still doesn't work, so taht assumes that Tuya responds in an async way.

I'd love to hear from you!

[uzlonewolf]

I'm in the same boat with my thermostats - they stop sending updates if the cloud's disconnected. Unfortunately, as @jasonacox said, these are Cloud devices and local control is an afterthought.

Most complex devices like these usually have a main chip running the device and a 2nd chip just doing WiFi. The WiFi chip reports the cloud connection status to the main chip, and the main chip decides whether or not to send updates to the WiFi chip. Tuya's Cloud server is just MQTT and is secured by pre-shared key (PSK) TLS. As for work-arounds, there really aren't any good ones that I know of. The only options are:

1. Convince the device manufacturer to update the device main firmware to not care about the cloud connection status.
2. Patch the device main firmware yourself to not care about the cloud connection status.
3. Dump the WiFi chip firmware, extract the PSK, and roll your own cloud server.
4. Use something like Tuya CloudCutter to overwrite the WiFi chip PSK and roll your own cloud server.
5. Replace the WiFi chip firmware with something like OpenBeken.
6. Replace the whole WiFi chip with a different one.

Chip support for options 4 and 5 is going to be limited. The fact that the WiFi chip is separate from the main chip makes it easier to replace just the WiFi chip without needing to mess with the chip controlling the device functions.

[lankhaar]

Hi @uzlonewolf ,

I see, thanks a bunch for the thorough explanation. I've gotta say that all of the options seem such a hassle that none of them are worth it to me. I think for the time being I'll just program an interface in between my home assistant and my robot which will cache the states based on commands it got, assuming the commands where picked up. Only problem I'm left with then is that the battery level won't update because even for that it requires the Tuya Cloud.

It's not the most beautiful solution, but will do for now. I'm a software developer myself and software is my strong suit, hardware definitely isn't so disassembling the vacuum to replace the chip hoping for things to work really isn't for me lol. Also my robot isn't listed as a supported device. In the long run I guess I'll consider ditching the current device and replace it with one that support Valetudo to make it cloud free.