jasonacox / tinytuya

Python API for Tuya WiFi smart devices using a direct local area network (LAN) connection or the cloud (TuyaCloud API).
MIT License
1.03k stars 181 forks source link

IR base64 codes via API not decoding properly #395

Open reactormonk opened 1 year ago

reactormonk commented 1 year ago

The combination of receive_button => base64_to_pulses => pulses_to_head_key => send_button works as expected. However, downloading the buttons via c.cloudrequest(f"/v2.0/infrareds/{infrared_id}/categories/{category_id}/brands/{brand_id}/remotes/{remote_index}/rules") and then sending them via the above pipeline makes the device restart after a few keys. The TV never reacts to any signal. Using the key from the device logs via https://github.com/jasonacox/tinytuya/blob/master/examples/cloud_ir.py#L85 works just fine. I had to pull the key via webinterface though, the API returned empty.

uzlonewolf commented 1 year ago

Can you post one of those downloaded buttons?

reactormonk commented 1 year ago

Here's the one I'm currently looking at:

{'head': '010e0400000000000600100020003000620c4b0c5b',
 'key1': '002%#000490#000D0010#000100@^',
 'base64': '9R2t8MIjZxe3vwRMEunX3CQcD+PbMNgt3+SF7fGNiCIDatHZ3g2lJCIHg9EH90G1vuFDWAmM1jW7ClRmQPTEawcgQkc1laE8xPrv6NE4MI8='}

Decoding that to pulses gives a weird result:

[7669, 61613, 9154, 5991, 49079, 19460, 59666, 56535, 7204, 58127, 12507, 11736, 58591, 60805, 36337, 8840, 27139, 55761, 3550, 9381, 1826, 53635, 63239, 46401, 57790, 22595, 35849, 13782, 2747, 26196, 62528, 27588, 8199, 18242, 38197, 15521, 64196, 59631, 14545, 36656]

From the other side (the head/key version), I'm getting:

[2731, 892, 446, 892, 446, 446, 446, 446, 446, 892, 892, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 446, 892, 446, 446, 892, 446, 446, 446]

So something's weird on the decoder side.

Same pulse, recorded (twice for good measure):

[2685, 895, 437, 906, 437, 438, 437, 438, 437, 907, 876, 437, 438, 469, 438, 437, 438, 469, 438, 438, 437, 438, 438, 469, 437, 438, 438, 469, 438, 437, 438, 438, 437, 469, 876, 437, 438, 907, 438, 437, 438, 30000]
[2678, 863, 469, 875, 437, 469, 437, 438, 1312, 1343, 438, 468, 438, 437, 437, 438, 437, 469, 437, 437, 438, 468, 438, 437, 437, 438, 469, 437, 437, 438, 437, 469, 874, 438, 437, 906, 438, 437, 437, 30000]

Roundtripping through the pulses function works nicely:

ir.send_key(*IRRemoteControlDevice.pulses_to_head_key(IRRemoteControlDevice.head_key_to_pulses("010e0400000000000600100020003000620c4b0c5b", "02%#000490#000D0010#000100@^")))

Feel free to hit me up via @reactormonk:matrix.org, I've got a bunch more codes flying around.

uzlonewolf commented 1 year ago

Looking at some of your codes and a few of mine, I suspect those "/rules" key values are encrypted, compressed, or both. Looking at a Samsung remote of mine, only a few code bits are different yet the "/rules" values are nothing alike:

button head_key1 "/rules" as hex
Power 010ed20000000000040015004000ad0730_002$$0020E0E040BF@% 5afe4e24178e54ae6394db00ae00fca2d822388202e1ab76eec7a692b0858448
OK 010ed20000000000040015004000ad0730_002$$0020E0E016E9@% 512ed74bbfd7561501a0eb00e6b25d9ca33ba52107619423137602a21bb80caf
Back 010ed20000000000040015004000ad0730_002$$0020E0E01AE5@% d3e75bf8a26aa8c17023651b0a70092b5e2d8fb0fe52739daaa25519a2cfb9a3
exit ?? 98b03c9acbb2efb14339c78e680632835d612b3497396f3f6355bffe35349209