Error accessing device after a few hours working

[vjbutt]

I am getting the status from a WiFi Dual Meter every 10s using tinytuya. Everything works fine for a few hours. Then I start getting the following error:

Unexpected error: <class 'KeyError'>

I can still read the meter data using the Smart Life app whilst I am getting this error. However, in order to get the status working again using tinytuya, I have to power cycle the WiFi Dual Meter. Any idea what could be wrong?

[jasonacox]

Hi @vjbutt can you detail or link about the Tuya device (WiFi Dual Meter)?

I have had a few older devices that would stop responding to the local network requests but would continue to work with the cloud (Smart Life). Power cycling them was the only that that would fix them.

It would be interesting to see if you could run a monitoring loop with a persistent connect to see if that helps. See https://github.com/jasonacox/tinytuya/blob/master/examples/monitor.py as an example.

[vjbutt]

@jasonacox thanks for your suggestions, I will try that plus a few other things. It seems that I have bought one of these older devices :(.

The error that I reported above is wrong (that was actually due to a missing DP ID in one of the returned data). The actual error that I am getting when the WiFi Dual Meter gives up on the local connection is:

{'Error': 'Check device key or version', 'Err': '914', 'Payload': None}

The device key is definitely correct, because when I power cycle the device it works. I will next check the version. I am currently setting this to 3.4, as is reported by the device, but maybe I should set this to 3.3.

[vjbutt]

@jasonacox I have tried setting the version 3.3, but tinytuya does not even manage to get the status. So the correct value to set is actually 3.4.

I still need to find some time to check with a monitoring loop over a persistent connection.

BTW the device is this one - https://www.amazon.co.uk/Energy-Electricity-Monitor-Control-Management/dp/B0CDXF3J1K/ref=cm_cr_arp_d_product_top?ie=UTF8

Haven't managed to find a link to the manufacturer though :-(

[uzlonewolf]

I have some v3.4 devices which do this, and my suspicion is memory corruption within the device is causing it to "forget" what the correct local key is. How often it happens is pretty random; one day it may do it 3 times that day, and then it will be fine for a month. I haven't found a solution other than rebooting it.

[vjbutt]

@uzlonewolf that was exactly what I was thinking, that somehow there must be some memory corruption. However, today I was surprised to note that the device started to respond to status updates again after about 1 hour of giving {'Error': 'Check device key or version', 'Err': '914', 'Payload': None} (without necessitating a power cycle). So maybe it is not memory corruption.

Furthermore, just before it started to respond correctly again to status queries, it returned the following status:

{'protocol': 4, 't': 20, 'data': {'dps': {'2': 1887}}, 'dps': {'2': 1887}}

It seems to me that the device is somehow switching to protocol 4. Why should it do this is beyond me. The problem is that tinytuya does not support version 4, so maybe those error messages were being generated because the device switched to version 4. Note that these protocol 4 messages are being received also in between correctly received status updates. They seem to be returned quite at random.

One other thing to note is that the time stamp ('t':20) returned in the above status seems to indicate that the device had rebooted. From previous protocol 4 status messages, it is clear that this is a Unix timestamp. So a timestamp of 20 seems to indicate that not even the real-time clock on board of the device had yet been updated before this status was returned. This may indicate a more serious case of memory corruption.

Will keep monitoring.

[uzlonewolf]

The 'protocol' in the payload does not do anything as far as I can tell and is only present in packets which contain a "protocol version" header directly before the payload. Devices set it to 4 while the SmartLife app sets it to 5.

[vjbutt]

@uzlonewolf, indeed that is now my impression as well. The presence of these protocol 4 packets increases drastically when I've set set_socketPersistent(True). They basically contain a very small subset of the DPS data that eventually follows in a full data payload.

Interestingly, setting a persistent connection also seems to have solved my problem in that the device is still alive and supplying "valid" data after more than 24 hours of continuous operation. However, it has now created a new problem. The status command is returning repeated payloads. I still see the measurements being updated on the Smart Life app, but not in tinytuya. As a consequence the returned data is practically useless. I have tried to force the update of the DPS using the function updatedps() but this does not seem to resolve the issue.

Why would a persistent connection cause repeated payloads and not return the actual data being measured? Note that I am only reading the status every 10s, which is compatible with the value set in the report rate control.