Is there a way how to re-initialise TinyTuya

[vjbutt]

I have encountered a problem. I have a script that gets the status from an Energy Meter every 10s. In most cases, I get the measurements in the correct format, something like this:

{'dps': {'1': 28123, '2': 11684, '101': 9099, '102': 'REVERSE', '104': 'REVERSE', '105': 12942, '106': 28123, '107': 3633, '108': 0, '109': 8051, '110': 92, '111': 4913, '112': 2496, '113': 3929, '114': 5186, '115': -22041, '116': 1000, '117': 1000, '118': 1000, '119': 1000, '121': 99, '122': 1000, '123': 1000, '124': 1000, '125': 1000, '127': 1000, '128': 1000, '129': 10}}

However, every now and then, I am getting the following value returned from a status call:

{'protocol': 4, 't': 1706791016, 'data': {'dps': {'112': 2519}}, 'dps': {'112': 2519}}

This is a reduced set of measurement values (just one in fact) with an additional protocol 4 header and a timestamp. I am not sure why this is happening. Any ideas?

When I get such a status, I am reading the status continuously (without any delay) until I receive a standard status.

This is working fine most of the time, however, sometimes TinyTuya gets stuck with status values starting with protocol 4, and therefore incomplete data. This can happen when I switch off and on my Energy Meter. The only way to get TinyTuya to return the correct status again is by restarting my script. Is there a clean way how I can re-initialise the class? I am using the OutletDevice class.

[uzlonewolf]

Packets with the 'protocol' header means it is either a response to a command or an asynchronous update.

Are you calling .receive() without an accompanying request anywhere? Async updates are going to mess with your flow if not. I recommend doing something like this to read all the unexpected async updates:

if [something about data is unexpected]:
    while data and 'Err' not in data:
        data = d.receive()

[vjbutt]

Thank you @uzlonewolf for your feedback.

I am not using any .receive() or .request() methods. Basically this is the algorithm that I am using:

# Connect to Device
d = tinytuya.OutletDevice(
    dev_id='DEVICE_ID_HERE',
    address='IP_ADDRESS_HERE',      # Or set to 'Auto' to auto-discover IP address
    local_key='LOCAL_KEY_HERE', 
    version=3.4)

# Get Status
while True:
  data = d.status() 
  # Use data
  time.sleep(10)

So I am not doing anything fancy, and I am not sure why I am getting these status updates with protocol 4 headers every now and then.

[jasonacox]

TinyTuya doesn't really care what the response payload is, it just give you the raw data. I suspect the device already had a "change update" packet queued up and sends it on occasion. You could monitor for those payloads and ignore them, or try adding a persistent connection (assuming the TCP handshake isn't helping):

# Connect to Device
d = tinytuya.OutletDevice(
    dev_id='DEVICE_ID_HERE',
    address='IP_ADDRESS_HERE',      # Or set to 'Auto' to auto-discover IP address
    local_key='LOCAL_KEY_HERE', 
    version=3.4, persist=True)

# Get Status
while True:
  data = d.status() 
  if "protocol" in data:
    continue
  # Use data
  time.sleep(10)

If we moved to a more async ways of processing, we would add logic to better sew together the requests/responses which would filter out these update.

[uzlonewolf]

I'm guessing it's attempting to be helpful by giving you a DP that recently changed. With you polling it every 10 seconds I would switch to persistent mode and use .receive() to clear any async updates. Edit: see my other post for a better example.

[uzlonewolf]

@jasonacox Sending new .status() requests without first doing a .receive() is going to stack up .status() responses in the socket receive buffer. Instead it should be something like:

# Get Status
while True:
  data = d.status() 
  while data and "protocol" in data:
    data = d.receive()
    if not data:
      data = d.status()
  # Use data
  time.sleep(10)

[jasonacox]

Ah, that's a good point! Good logic change.

[vjbutt]

I'm guessing it's attempting to be helpful by giving you a DP that recently changed. With you polling it every 10 seconds I would switch to persistent mode and use .receive() to clear any async updates. Edit: see my other post for a better example.

When I used persistent mode I found that status updates were delayed by several seconds, and lots of data points were simply dropped.

[vjbutt]

@jasonacox thanks for the feedback. @uzlonewolf I am taking up your suggestion and use .receive() to clear up these updates. Thanks for the suggestion.

I have noted that already with the updates that I have made, the Energy Meter requires fewer power cycles to keep it running.