Open reactormonk opened 1 year ago
Can you post one of those downloaded buttons?
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.
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 |
The combination of
receive_button
=>base64_to_pulses
=>pulses_to_head_key
=>send_button
works as expected. However, downloading the buttons viac.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.