Fairy String Lights with scan results with unexpected payload=b'\xd0\ blahblah '

[joe-a-b]

I bought (nearly 20) EJ's SUPER CAR Led Fairy Lights for Bedroom-66Ft 20M RGBIC Plug in Work with Alexa Google Home,App Remote Controlled/Music, string lights for christmas (lightshowpi setup) - It's working fine enough outside to turn/on/off set modes with phone app. Sometimes few locations are a little unreliable on the wifi, i have mesh network out there, and 1 string for testing at my desk. using windows command line, (but also tried linux raspi4B). All that aside i think it's able to communicate. I pulled latest git code, and also tried latest pip install upgrade.

I was looking into seeing if i could do some kind of script to control the modes/colors during the show. (i've already got a few raspi4B's using shairport-sync from pc itunes streaming to some speakers/fm broadcast)

Reproduce steps: py -m tinytuya scan nocolor

it appears to show "d0" byte where the "3.3" version string would be in the payload. They all return that. I put wireshark on just to see the udp packets. it appears to be about at about byte position 21 in the result, where i think the version was supposed to be.

Unknown v Device   Product ID =   [Unknown payload]:
    Address = 192.168.1.94,  Device ID = , Local Key = ,  Version =
    No Stats for 192.168.1.94: DEVICE KEY required to poll for status
*  Unexpected payload=%r
 b'**\xd0**\x97fgo3i\xeb\x10\xb5\xe9\xf12\xfd\x80*\xcf\xeb\x87\x96\xc6v\x17%6\x99\\<L$\xc1;\x8c\xe4\x88\xe4\xf9\x8f9\xc1\xe5\x8d\xc3\xb8o&\xd4\xa7z\\\xc8\xa4\xfd\x97\xf8\xe9\x07p\xa2\x7f\xd7\xa5\xbe\xe3\xc2\xfb\x84Y\xb1\x15_\xc7]K\xf6i\x9f\x92\xcb\xa4\xc0\xbaR\x01H\x04^v\x05\xfa\x04\x98\xdf\xeaZ\xab\x99\xf6/&\xadX\xff-=\x84\x9f{s\x9a9\x10Y>K\x8f;\xec=\xf5?\xc8K)l\x0f\x91\xb1\x9fc\xf7\x12H\xa4\xecF\xb9\x1ba\xfd\x90\x9e\xce>\x02G\xa6\n\xbb)P\xde.\xa0\x80u\xf8\xf7\xf1\xd9'
Unknown v Device   Product ID =   [Unknown payload]:
    Address = 192.168.1.17,  Device ID = , Local Key = ,  Version =
    No Stats for 192.168.1.17: DEVICE KEY required to poll for status
*  Unexpected payload=%r
 b'\xd0\x97fgo3i\xeb\x10\xb5\xe9\xf12\xfd\x80*\xfcI\x9d&\xac\xe1\xde\xe5k\xb2"I=Ri\xa1\x90\x7f[\xb5<\xe1\x89\xc4\xef\xd0\x80P\x030UL\xc6b\t=\xab\x81\xd1\xb1\x94\xb0\xe1\xc3\xe8\xba\x19C\xc2\xfb\x84Y\xb1\x15_\xc7]K\xf6i\x9f\x92\xcb\xa4\xc0\xbaR\x01H\x04^v\x05\xfa\x04\x98\xdf\xeaZ\xab#\xedBxDo\x0eW\xeb\xf5\xb0jcKz\xf1\x187\xb6\xa4\x82\xac\x9bh\x96L$\x9e\x1a\x1a\x0eBn\xda\x8e\xea@\xe9;\x1e?\xc1J%p\xe1\x82y'
Unknown v Device   Product ID =   [Unknown payload]:

I was just trying to figure out what was different about all the lights return payloads during the scan (attached capture):

I manually collected list of macids/ip's, using router/and tuya app info to match them up. My next steps would be to try to figure out what command i would send to them to set the scene and rgb color (assuming i'm not blocked by the payload issue).

I suspect even if I have the local device key i may have trouble communicating if it can't decode/unencrypt the responses, is that correct?

[jasonacox]

Are you able to control these lights with the SmartLife app? Do you have other Tuya devices that do work? If so, two suggestions: 1) See if the device firmware can be upgraded 2) See if you can run py -m tinytuya wizard and still pull down the local key (will also create a tuya-raw.json file)

You may still be able to control these if you can get the local key (you have the IP address and the wizard will provide you with the ID and local key for all your devices).

Why are they not showing up right in the scan? It could be that they are using a new/different UDP key to encrypt the broadcast. TinyTuya listens for these broadcast packets during scan mode. If they changed the key, it would not be able to decrypt anything but the IP address which is what you are seeing. If that is something Tuya is doing for new devices, we will need to add that new key to TinyTuya if we can determine what it is. However, it could also be a bug in the firmware these particular lights are using. In any case, the UDP key is not the same as the Local device Key that is used to control and decrypt status messages from the device which is why I am hopeful that you can still control them.

For now, we will call this the d0 firmware Tuya device.

[joe-a-b]

Thank you! Yes, i'm able to control via the tuya smart app (connected to developer cloud account). I think the only part not working is the ip address detection (and payload) since they all say no ip found. However, I'm able to monitor and send values, if i use the examples and enter the ip. Received Payload: {'dps': {'25': '0503e8'}, 't': 1639295663}

Send Heartbeat Ping < Received Payload: {'dps': {'25': '0103e8'}, 't': 1639295667} Send Heartbeat Ping < Received Payload: {'dps': {'25': '0503e8'}, 't': 1639295669} Send Heartbeat Ping < Received Payload: {'dps': {'25': '1003e8'}, 't': 1639295672} Send Heartbeat Ping <

d = tinytuya.BulbDevice('DEVICE_ID_HERE', 'IP_ADDRESS_HERE', 'LOCAL_KEY_HERE'). d.set_version(3.3) d.set_value(25, sys.argv[1])

and i tried those values like '1003e8'.

How do i send the second 't' parameter?

[jasonacox]

The 't' timestamp parameter is part of the Tuya payload, it isn't a data point you can set.

Here is on you might try - one of my favorites :)

d.set_value(25, '07464602000003e803e800000000464602007803e803e80000000046460200f003e803e800000000464602003d03e803e80000000046460200ae03e803e800000000464602011303e803e800000000')

[jasonacox]

Hi @joe-a-b I'm closing this issue unless there is more to add or bugs we need to address. Thanks for your help.