Update Whynter codes to be more reliable #144
Conversation
- codes are now generated algorithimically to be millisecond accurate
|
Hello, than you for your PR. everything seems to be in order, so I will merge it. If you like to provide support also for other Wynter devices, you are welcome. Regarding your code. Do you think you would be able to help me with code, which would be able to convert between different code types (at least between some) on demand? I would integrate this into Controller class. ;-) |
|
@litinoveweedle I see the helper class already has some converter functions. Right now the helpers are used to convert ENC_PRONTO to ENC_BASE64 for Broadlink controller by using lirc as an intermediary For universal support I would add https://pypi.org/project/irgen/ (https://github.com/elupus/irgen) as a dependency to your project. It has all the converters you need:
You could then use raw as a universal intermediary between all controllers. In the future I plan on moving from a Broadlink controller to ESPHome, as I like that it can also receive commands from the actual remote. When I do that I could test using my Broadlink codes from this PR with the ESP32. I don't know when I would be doing the changeover, and I am likely to put my AC away for the season soon. If nobody else tackles this, I might take a look in the spring. |
|
Thank you for pointing to this project, it looks rather promising. I am just not sure, if raw encoding data are actually interchangeable between different controller types. I also don't have currently device to test it (I ma only having Broadlink as well). |
|
FYI - nice article which help me to understand topic a bit: https://tasmota.github.io/docs/IRSend-RAW-Encoding/#converting-broadlink-ir-codes-to-tasmota |
|
You can see the supported formats are defined in controller_const.py: Seems everything except Broadlink supports raw, but I did not review all the implementations. If you want to see how the functions I mentioned work the source code is here: You could also integrate code directly as it is MIT licensed. |
|
I know, I created that struct myself. :-) what I lack is understanding of the IR formats. I also checked the irgen and it seems better for long term maintenance to just use it as dependency. |
|
Great! Let me know if you need any help in testing. I already have an ESPHome IR transmitter that I can use. |
|
I am just checking different code files and I am afraid I was correct what RAW encoding in the device files really means. fan/1175.json fan/7040.json What RAW seems to seems to mean at least in the first example is |
|
One more example: climate/4380.json This loo more like ENC_HEX, but is again marked as ENC_RAW, while Xiaomi controller is supposed to handle only ENC_PRONTO, and ENC_RAW. |
|
The same for ZHA: climate/1705.json Again look more like ENC_BASE64, but is marked as ENC_RAW . |
|
@thewade Any thoughts? |
|
The ESPHome ones are raw as I know it. Which is the positive number being the number of milliseconds the IR led is on, and the negative number is the time it is off. This was the format I used in my script before converting to Broadlink. MQTT is only used in 1175.json. For that example, you have is NEC format in 1175.json, but given the way the JSON is structured I assume it might support other encodings. Zigbee2MQTT is just an interface to devices so maybe the codes are not universal. You can encode decode NEC with the library I shared if you want to handle this one case, although it might not be worth the effort. I would change the datatype from RAW to something like MqttDataStructure. For Xiaomi those codes appear to be Base64, decoding them we see what looks like raw: Credit to https://pro-domo.ddns.net/blog/hack-application-android-xiaomi-mi-remote-partie-1.html for this. I didn’t read the whole thing but you can try using Google Translate to read it yourself. I think in the case the integer just alternates between milliseconds on an off. More testing would be need to confirm if any of this is true. In this case I would call the format XiaomiBase64Raw cause it is unique. ZHA is Zigbee to Home Assistant just another interface to the devices and I am again unsure if the codes are universal. Given it is only used in one file I wouldn’t focus to must on it. I would also suggest that you look into building an ESPHome IR transmitter/receiver. You can make one for under $20 and would help in your testing and maintenance of this project. The receiver can also be used to decode lots of different devices, this can help you very confirm if your translations are correct on devices you don't own. More info here: Hope this help getting you started. |
|
Hi, maybe I can help you with IR codes. Going to SmartIR, today a code file for Broadlink starts with: To use it with ESPHome I had to change: then I had to add In my idea the code file for a device should not be binded to a specific controller so either: "supportedControllers": ["Broadlink","ESPHome",.....] or just skip this setting and set the controller somewhere else. Not a fun of Python but let me know if I can assist. |
|
@thewade I'd just like to clarify that Xiaomi's base64 code does indeed contain The example of code you picked exposes that discovery because the entropy of what we obtain Here's the One-Liner presented in this chapter: import base64
import gzip
from Crypto.Cipher import AES
PATTERN_SECRET_KEY = "fd7e915003168929c1a9b0ec32a60788"
encoded_pattern = <my_base64_xiaomi_code>
json.loads(gzip.decompress(AES.new(PATTERN_SECRET_KEY.encode(), AES.MODE_ECB).decrypt(base64.b64decode(encoded_pattern)).rstrip()))I don't know where you sourced your IR code example but It doesn't seem to follow the rules I discovered. Feel free to post your findings in a issue on https://github.com/ysard/mi_remote_database/ :p (maybe this project will interest you btw). |
|
@litinoveweedle do you want to enable discussions so people can collaborate on things like this? |
|
Hello @thewade and @ysard sorry for the delay in response, I had to manage some of my other tasks first. Now when those task are behind me I would really love to finish our discussion about IR code translations and implement it. I enabled discussion, so we can either continue here or there - up to you. I am looking forward hearing from you. |
I am the original contributor of this file, however the learned codes never seem to be reliable.
So I adapted https://github.com/esphome/esphome/blob/dev/esphome/components/whynter/whynter.cpp to generate to codes in raw form and used https://github.com/elupus/irgen to convert to Broadlink.
My adapted Python code:
https://gist.github.com/thewade/5f0d87a5e3e69455410015f4105593c0
I should also be able to generate codes for Whynter devices that support heating if someone wants it.