Smart meter online and offline at the same time!

[elljay234]

Hi, I've got a "Smart Meter" device (https://www.ebay.co.uk/itm/127004481161) that has been working fine for months. Just after I went on holiday it started returning:

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

I've tried power cycling it. It shows as Online and reports readings fine in the SmartLife app, but when I look on the Tuya Development Platform it shows as Offline. Running a tinytuya scan finds the device but Polling fails with No Response.

Any ideas?! Thanks :)

[cpapado]

I have 2 similar devices which I am trying to connect to with tinytuya and they both give me the same error as above while all my other devices work fine. It seems that the socket connection cannot successfully complete the key negotiation. If anyone can help I would appreciate it!!!

[uzlonewolf]

Initially working fine but then stops usually means either a) the local key changed or b) the device does not respond to status requests after a power cycle until after some condition is met (usually it needs a set command, but I'm not sure if any DP can be set on an energy monitor).

So, I'd first run the Wizard again to make sure it has the correct local key. If it still isn't working I'd then try d.set_value(1, True) and/or d.updatedps([...]). If it still isn't working then please enable debug mode (d.set_debug()) and post the output of a status request.

[elljay234]

Thanks for the reply.

Triple checked the keys and the wizard is still reporting the same:

Smart Meter Product ID = v5jlnn5hwyffkhp3 [Valid Broadcast]:
Address = 192.168.123.127 Device ID = bfaf182aad247aa99d6epp (len:22) Local Key = 1yuB0wKEX|bK6J-< Version = 3.4 Type = default, MAC = 38:a5:c9:42:df:9f
Polling 192.168.123.127 Failed: No response

Tried set.value:

import tinytuya
d = tinytuya.OutletDevice( dev_id='bfaf182aad247aa99d6epp', address='192.168.123.127', local_key='1yuB0wKEX|bK6J-<', version=3.4, persist=False)
d.set_value(1, True)

It runs and returns after a few seconds, but d.status() still returns:

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

Not sure if I got the syntax of the d.updatedps command right - the first permutation that didn't give a python error was:

d.updatedps([1])

It ran and returned after a few seconds, but d.status() still returns the same Err 914.

Running:

tinytuya.set_debug()
data = d.status()
print("%s" % data)

Gives:

DEBUG:TinyTuya [1.12.11]

DEBUG:Python 3.9.2 (default, Mar 20 2025, 02:07:39)
[GCC 10.2.1 20210110] on linux
DEBUG:Using PyCrypto (3, 19, '0')
DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for 'bfaf182aad247aa99d6epp' ('v3.4'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'protocol': 5, 't': 'int', 'data': {}}, 'command_override': 13}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {}, 'command_override': 16}, 13: {'command': {'protocol': 5, 't': 'int', 'data': {}}}, 16: {'command': {}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{}'
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'000055aa000000010000000300000044ac72f4dcce6514f7f58769024f31e0d715ac375acd04a70c2039b3e3e1e8fdc303fc626d52fe5c5df668b4f195209405d39924da0478d2649195b2f2f0a2f0900000aa55'
DEBUG:received data=b'000055aa0000375c00000004000000680000000059160c5d418e618747507b1d23fc6614671303694838f26ec43c9d4558aba607c7c96e823b8edd40a5129b18e759be1c15ac375acd04a70c2039b3e3e1e8fdc30ca5ec0d90641e31c5467be45064dcf68767ed8769c4b1a95b4ab7475d4b064c0000aa55'
DEBUG:decrypting=b'Y\x16\x0c]A\x8ea\x87GP{\x1d#\xfcf\x14g\x13\x03iH8\xf2n\xc4<\x9dEX\xab\xa6\x07\xc7\xc9n\x82;\x8e\xdd@\xa5\x12\x9b\x18\xe7Y\xbe\x1c\x15\xac7Z\xcd\x04\xa7\x0c 9\xb3\xe3\xe1\xe8\xfd\xc3'
DEBUG:decrypted session key negotiation step 2 payload=b'cf891932b496309d\xe8\x04\xd189S\x80\xce,;[8\xc5_\xcbi\xa1;\xbf7\x04\x84tA\xce\xe3\x91(|6i\x19'
DEBUG:payload type = <class 'bytes'> len = 48
DEBUG:session local nonce: b'0123456789abcdef' remote nonce: b'cf891932b496309d'
DEBUG:sending payload quick
DEBUG:final payload: b'y\x9b\x9e\xf1\x84\xfc0\xc5\xb4G]\x1a\xf7\x03\x97\x97H\x06\xd2a\x90\xd1\xebK>S\x8e\x9e1\x15g\xd0'
DEBUG:payload encrypted=b'000055aa00000002000000050000005443515ebdf9b61af966a8951d5912a403259bfd713490ee47fae81da3962375a115ac375acd04a70c2039b3e3e1e8fdc3f6b67062d4aed81c487fedc69383c734c8cded18390cac6fcd5f5c7ff38740fe0000aa55'
DEBUG:Session nonce XOR'd: b'SW\n\n\x05\x0c\x05\x05Z\rXTPT\\x02'
DEBUG:Session key negotiate success! session key: b'\xe9\x17\xff\x9c\x8f\\xb5=\\xbb\xca\x00\xf6]5\xc3'
DEBUG:sending payload
DEBUG:final payload: b'{}'
DEBUG:payload encrypted=b'000055aa000000030000001000000034524c5302e358e755f0cd1a6437878342c15e61220336a6ae039dba4034cb1b71bbbfd1eba4a4b263d22546abbc2686290000aa55'
DEBUG:received data=b'000055aa0000375d0000001000000048000000012161c0dacfa5948cd0b329fd9b1be23be246a61c7390ad722e2152248a040c708fe5c276b335ad638c8a354a87c5f52a595ac3c0742fb238044624068733381c0000aa55'
DEBUG:received message=TuyaMessage(seqno=14173, cmd=16, retcode=1, payload=b'!a\xc0\xda\xcf\xa5\x94\x8c\xd0\xb3)\xfd\x9b\x1b\xe2;\xe2F\xa6\x1cs\x90\xadr.!R$\x8a\x04\x0cp', crc=b'\x8f\xe5\xc2v\xb35\xadc\x8c\x8a5J\x87\xc5\xf5YZ\xc3\xc0t/\xb28\x04F$\x06\x8738\x1c', crc_good=True, prefix=21930, iv=None)
DEBUG:raw unpacked message = TuyaMessage(seqno=14173, cmd=16, retcode=1, payload=b'!a\xc0\xda\xcf\xa5\x94\x8c\xd0\xb3)\xfd\x9b\x1b\xe2;\xe2F\xa6\x1cs\x90\xadr.!R$\x8a\x04\x0cp', crc=b'\x8f\xe5\xc2v\xb35\xadc\x8c\x8a5J\x87\xc5\xf5YZ\xc3\xc0t/\xb28\x04F$\x06\x8738\x1c', crc_good=True, prefix=21930, iv=None)
DEBUG:decode payload=b'!a\xc0\xda\xcf\xa5\x94\x8c\xd0\xb3)\xfd\x9b\x1b\xe2;\xe2F\xa6\x1cs\x90\xadr.!R$\x8a\x04\x0cp'
DEBUG:decrypting=b'!a\xc0\xda\xcf\xa5\x94\x8c\xd0\xb3)\xfd\x9b\x1b\xe2;\xe2F\xa6\x1cs\x90\xadr.!R$\x8a\x04\x0cp'
DEBUG:decrypted 3.x payload=b'json obj data unvalid'
DEBUG:payload type = <class 'bytes'>
DEBUG:'data unvalid' error detected: switching to dev_type 'device22'
DEBUG:decode_payload() failed!
DEBUG:Device22 detected and updated (default -> device22) - Update payload and try again
DEBUG:ERROR Device22 Detected: Retry Command - 908 - payload: null
DEBUG:status() received data={'Error': 'Device22 Detected: Retry Command', 'Err': '908', 'Payload': None}
DEBUG:status() rebuilding payload for device22
DEBUG:final payload_dict for 'bfaf182aad247aa99d6epp' ('v3.4'/'device22'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'protocol': 5, 't': 'int', 'data': {}}, 'command_override': 13}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {'devId': '', 'uid': '', 't': ''}, 'command_override': 13}, 13: {'command': {'protocol': 5, 't': 'int', 'data': {}}}, 16: {'command': {}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{"devId":"bfaf182aad247aa99d6epp","uid":"bfaf182aad247aa99d6epp","t":"1761033429","dps":{"1":null}}'
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'000055aa000000040000000300000044ac72f4dcce6514f7f58769024f31e0d715ac375acd04a70c2039b3e3e1e8fdc36634786216b89120a8c64c2be3bc5e70c8cf58a75deb1435b08688270de2a2ff0000aa55'
DEBUG:received data=b'000055aa0000ff8c00000004000000680000000061db0dbbff35549b58c5a19a9d0e8443671303694838f26ec43c9d4558aba607c7c96e823b8edd40a5129b18e759be1c15ac375acd04a70c2039b3e3e1e8fdc34ee4b2472ead43b7aa18493597fa3d27b7f218b894bc8a1c692cd88f3c89c5eb0000aa55'
DEBUG:decrypting=b'a\xdb\r\xbb\xff5T\x9bX\xc5\xa1\x9a\x9d\x0e\x84Cg\x13\x03iH8\xf2n\xc4<\x9dEX\xab\xa6\x07\xc7\xc9n\x82;\x8e\xdd@\xa5\x12\x9b\x18\xe7Y\xbe\x1c\x15\xac7Z\xcd\x04\xa7\x0c 9\xb3\xe3\xe1\xe8\xfd\xc3'
DEBUG:decrypted session key negotiation step 2 payload=b'f2bd9696a807b19c\xe8\x04\xd189S\x80\xce,;[8\xc5\xcbi\xa1;\xbf7\x04\x84tA\xce\xe3\x91(|6i\x19'
DEBUG:payload type = <class 'bytes'> len = 48
DEBUG:session local nonce: b'0123456789abcdef' remote nonce: b'f2bd9696a807b19c'
DEBUG:sending payload quick
DEBUG:final payload: b'\xa8\xcb\x97\xea\xc5S\xb4\x04\xceG\xc2\xb5)~\xc4\xa1\xcd\xf3\xf9\xd7\x16\xc3\xacpOv\xe3(98X\xe9'
DEBUG:payload encrypted=b'000055aa0000000500000005000000540b8def5aec3f72c2f658fe890e002f29a239ca62c31263aba9d9bca1f56c1aa115ac375acd04a70c2039b3e3e1e8fdc3dd448171797ed159ec00d841738b398c883348c33e08d398b14d25485e7834e60000aa55'
DEBUG:Session nonce XOR'd: b'V\x03PW\r\x03\x0f\x01Y\x01QU\x01U\\x05'
DEBUG:Session key negotiate success! session key: b'\x9f*P`)d\xbd\x8a\x80\xa5\xe6\xc5\xb6\x9a\xebn'
DEBUG:sending payload
DEBUG:final payload: b'3.4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00{"devId":"bfaf182aad247aa99d6epp","uid":"bfaf182aad247aa99d6epp","t":"1761033429","dps":{"1":null}}'
DEBUG:payload encrypted=b'000055aa000000060000000d000000a4c8584e4050526678845e4ff48480623b8ecde46759bcaaf5d769399b9684ab77c094d3505a3905b559e85d34476b71bf6cc14012a1543494bf3bcb1e7309d89ba08da4526a2541743fdb9f84a31d2e5f556b2cdfec4ae57d6aafcc6af60a76ac68645416525fc27bd72b1852aed9df7e3597c2c7fe5ac12f5ecaa064a956ff4471358f9112fe961dbe394e84354c47db7e7b8a6020c39342d23a00f4b44850df0000aa55'

[uzlonewolf]

Thank you for that, it helps a lot.

It looks like this is another device that returns json obj data unvalid when the device has no data to report with .status(), and this is erroneously triggering TinyTuya's 'device22' detection. Setting d.disabledetect = True before calling status() will allow it to return the proper ERR_PAYLOAD instead, but you're still not going to get any data as the device simply does not have anything to give you.

If you add d.disabledetect = True to something like the monitor example and let it run for a while, does the device eventually return data?

I have one of these devices on order but it will not get here for a few days.

[elljay234]

Glad it helps :)

Added the disabledetect and indeed it now reports:

{'Error': 'Invalid JSON Response from Device', 'Err': '900', 'Payload': 'json obj data unvalid'}

I've added it to a script that runs every 10s when my solar panels are generating and every 30s when they're not. So far it's just reporting data unvalid, but I'll keep an eye on it...

Looking again at SmartLife it looks like the reported data isn't changing, so I guess it's just showing the final reading it received. All the graphs in SmartLife fall to zero from the middle of last month...

Was wondering if it's worth pressing the reset button on the device for 10 seconds or whatever it is to see if that brings it back to life... Got nothing to lose I guess as it's effectively bricked at the moment!

[uzlonewolf]

I was asking about the monitor example because some devices do not respond to .status() and instead just broadcast their updates unsolicited.

If even the data in SmartLife isn't updating however it's likely part of the device died; most of these devices use a microcontroller to control their main functions and have a completely separate module to handle the WiFi, and if the main micro died then that would explain the WiFi module not having any data to give to you. Resetting it is definitely worth a shot to see if that brings it back.

[elljay234]

Ah, sorry missed that the monitor example looks at broadcasts!

Pressed the button on the device for 10s and the LED started flashing green. Tried to re-add the device into SmartLife but it times out. Tried a couple of times but no joy. Now SmartLife and the Tuya website show the device as offline and TinyTuya has reverted to Err 914. Have just ordered two devices from eBay!! Hopefully the next one will last longer than six months!

Thanks for your help @uzlonewolf 👍