search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.12k stars 4.79k forks source link

Migrate IRremoteESP8266-2.6.0 to IRremoteESP8266-2.6.4 #6286

Closed hristo-atanasov closed 5 years ago

hristo-atanasov commented 5 years ago

There are newer HVACs included and it supports more than 64 bits code receiving

ascillato2 commented 5 years ago

Great Thanks!

Please, do a Pull Request.

Thanks!

s-hadinger commented 5 years ago

I'm preparing a PR to make it easier to add HVAC devices from IRREMOTEESP8266. Stay tuned.

@arendst Would you be Ok to publish a firmware dedicated to IR blasters, including (almost) all protocols from IRREMOTEESP8266? I know they use a lot of space but if we trim down the code space for IR it's manageable.

arendst commented 5 years ago

Dedicated IR. Give it a try.

hristo-atanasov commented 5 years ago

I'm not actually in need of all new HVACS. I'm interested in receiving more bits, as this way your software would become the most powerful tool I have ever seen. This way everyone will not only have the ability to use Tasmota for controlling ACs ,but in fact could track their state change if the ACs status was changed by its original remote too. This will allow people to fully ingrate all their not so smart devices to smart home hubs like Home Assistant and Open Hab. :) Like my case - I wrote integration for my AC but I can track their state only when they were controlled by HA, if someone change their state with the remote, this change remains hidden from HA. I already have one dedicated NodeMCU for controlling the AC. Adding a second device only for tracking the state would be too much - no place where to hide it anymore .. :)

hristo-atanasov commented 5 years ago

Well actually your software is already the most powerful for me .. But these additional bits, even if you can add them without migrating to new version of IRremote would be very nice. :) If I have to be honest, initially I decided to not bother you with this, and tried to change the code by myself, but the only thing I achieved was sh*ting my pants (and device) in C (as I don't know much about it) .. :D

Jason2866 commented 5 years ago

Since there are now and then people asking for support all kind of HAVACs it is a great idea from @s-hadinger to do a special IR build supporting this.

s-hadinger commented 5 years ago

Use case makes sense, I didn't think about capturing manual changes from the remote.

@arendst One more question. For Hex codes, each byte is sent MSB first which makes manual calculation a bit more complex. Most IR codes actually expect LSB first. I'm not talking about little-endian but how each bit is sent to the IR led. Is there any hard reason to have MSB first instead of LSB? I will had a flag to send LSB first too.

arendst commented 5 years ago

I guess the only reason for MSB/LSB is the response you get from IrRemote and how it wants to have it's input.

arendst commented 5 years ago

BTW regarding HVAC decoding you might want to look at the examples with IrRemote.

hristo-atanasov commented 5 years ago

I still can't get the idea for special build just for HVAC .. It is already integrated .. Just capturing should allow more more bits. :) As for the other HVACS - the code is included in IRREMOTEESP266, but I guess it should be adapted for Tasmota ..

hristo-atanasov commented 5 years ago

@arendst is it too hard to make it receive up to 128 bit codes with the current version (actually I need 104)?

s-hadinger commented 5 years ago

It's one thing to capture the bits, it's another to decode/encode it. Recording all combinations of hvac ir codes wouldn't make sense because of combinatorial explosion.

Please be patient.

Also ESP8266 does not handle 128 bits integer so it's not a simple patch.

hristo-atanasov commented 5 years ago

OK, it seems that I can't explain my question, because I'm not too deep in the IR codes thing, so I'll ask in different way .. Is it too hard to receive this: 0xC0A0000000002000402C60F9C3 instead of this: .............................. 0x2000402C60F9C3

Both are captured using ESP8266, and both are captured by IRremoteESP266. The shorter is from Tasmota, the longer is from: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRrecvDumpV2/IRrecvDumpV2.ino

hristo-atanasov commented 5 years ago

@s-hadinger As a person that does not have any knowledge about C and C++ (and how Tasmota works internally), it took me 30 minutes (testing included), to read part the code of IRremoteESP8266, part of the code in Tasmota and change line 160 in 'xdrv_05_irremote.ino' from: snprintf_P(svalue, sizeof(svalue), PSTR("\"%s\""), hvalue); to: snprintf_P(svalue, sizeof(svalue), PSTR("\"%s\""), resultToHexidecimal(&results).c_str());

And 'my_user_config.h' Line 429: #define IR_RCV_BUFFER_SIZE 100 to: #define IR_RCV_BUFFER_SIZE 250 (222 is enough for me but I made it a little bigger)

Without migrating to the newest release.

You wrote so much excuses and self explanations, that (may be) it would took you way less time for you to search and see what is wrong and why Tasmota truncates the code. I hope you get better in programming and thinking out-of-the-box.

@arendst Thank you for your great software! :)

s-hadinger commented 5 years ago

@hristo-atanasov Thank you so much for finding an easy way to solve your issue. This is the beauty of open-source, you can solve your problem yourself.

This is not code I wrote so I apologies if I lead you to wrong conclusions. I will keep quiet next time you ask a question and will let you find your solution yourself.

Now the purpose of my discussion above is to find a solution for all users, not just for you.