jasonacox / tinytuya

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

IR base64 codes via API not decoding properly #395

Open reactormonk opened 10 months ago

reactormonk commented 10 months 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 10 months ago

Can you post one of those downloaded buttons?

reactormonk commented 10 months 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 10 months 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