-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IR/receiver unification #4198
Comments
Hi, I think we cannot re-implement the IR receiver code, and I'm not a fan of "slicing a library" to just use the code we want. Compilers are able to remove unused functions (dead code) when creating the binary. However the de-facto standard library from ArminJo does support 8266 and esp32 since a long time. 🤔 Maybe it has a smaller FLASH footprint. |
Any reason for that? The behaviour would need to be identical to current, just over the API. Or is the problem providing the json files in OTA? I think "fetch them from github" is out of the question...
I agree, but on the other hand using a library that uses that much flash has become a bit of an issue.
That is a good input. I can check if it can be a 1:1 replacement. |
Sorry, maybe this was a misunderstanding. My statement was related to the second part, so "re-implement the receiver code" for me meant "create our own IR driver". This would be very low-level and a tricky thing to achieve. For sure we can replace all the hard-coded commands with IR.json. People can already upload their custom IR.json from the UI. What's missing right now is a possibility to pre-populate the LittleFS partition with files during install - neither OTA nor online web install currently allow this. |
Might not be a 1:1 replacement, because the API changed a bit in arduino-irremote version 3, while irremote8266 still implements the older "v2" api. Also the IR codes from arduino-irremote might be different because they fixed some bitorder decoding problems in v3. |
AFAIK WLED only needs decoding IR signal. All other processing is done in WLED. |
I am all in favour of using JSON for IR remotes. However... Not all users are savvy enough to upload correct JSON file and many would like to use remote OOB with no intervention. For me, I created an universal JSON file. It contains commands for multiple different remotes I use. Unfortunately some generic remotes re-use same key ID for different buttons, i.e. "brightness up" on one remote has the same key ID as "red" on another. So you cannot have a truly universal JSON file. |
I was thinking about this problem a bit. regarding the IR library: I will look at that in the coming days to check if any other library would be better or if we should just spin our own code. Reading the signal is very easy, the library currently uses a pin interrupt and micros() to timestamp (if I interpret the code correctly) which is just a few lines of code. The magic happens in the decoding, that I did not yet look at. BTW: in the 40key blue remote json file in the KB there is an error (or in WLED code): Won and Woff codes are defined differently in WLED code and that json file, found this by accident where I randomly picked a file and commands to look at how the json IR works. also behaviour is slightly different (lastwhite vs. full bright). |
That's what I'm proposing in
There are a few issues with this:
Also, do not forget there is also ESP-NOW support for Wiz remotes (albeit flaky ATM). |
I mean explicitly NOT generating a file but more or less keep it the way it is now but instead of calling functions it generates a string with a single command and passes that to the "API interpreter". The Idea is that this "interpreter" extends the command such that the normal JSON decoder can read it. WIZmote could use that API decoder too. |
Are you talking about |
Yes. Plus the function that currently handles ir.json. There is no real benefit, just unification of how things work. RN there is two ways for IR, json and the local IR functions doing the same thing. |
I am opening this issue for a discussion on how to improve / unify the (IR) remote handling.
The IR receiver currently uses around 20kB of flash which is excessive. Parts of that is coming from the special-case handling of IR commands, the other (larger) part from the bloated IR receiver library IRremoteESP8266. I think there is much room for improvement.
Here are my suggestions / questions:
Making all receivers use the API would also enable users to easily change IR key functionality by editing the corresponding file.
The text was updated successfully, but these errors were encountered: