Irremoteesp8266: Carrier 48-bit modification request

[treedog56]

Version/revision of the library used

2.7.7

Actual behavior

Successfully Followed the https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol and added support for a Carrier 48 bit remote.

(Great document, and easy to follow. Thanks for the auto_analyse_raw_data.py tool !!)

Can successfully capture and send IR code from the remote, and have been able to test sending the codes though SmartIRRepeater.ino and other program calling the IRremoteESP8266 library.

Example code used

My updated code is in the the forked repository treedog56 / IRremoteESP8266 under the new branch .

The break out spread sheet of the captured IR codes is located at // https://docs.google.com/spreadsheets/d/1Et618X2dL10q0ESxuNRlSr7ePcRY1LaxBnSi8dCRKtI/edit?usp=sharing

From what I can tell from reverse engineering the IR codes it looks like the following.

There are 12 Hex codes captured, the first 6 seem to contain the the actual data, and the second 6 is an inverse of the first six.

So going right to left in the first set,
Set 6 contains the hex code for the checksum.
Set 5 contains the hex code for the Timer on value.
Set 4 contains the hex code for the Time off value.
set 3 contains the hex code for the Temperature value.
Set 2 contains the hex code for the Mode value.
Set 1 contains the hex code for the Main or the Alt functions.

Given that, I have come up with the following for ir_carrier.h.

const uint8_t kCarrierAc48ChecksumOffset = 0;
const uint8_t kCarrierAc48ChecksumSize = 8;
const uint8_t kCarrierAc48ModeOffset = kCarrierAc48ChecksumOffset +
kCarrierAc48ChecksumSize; // 8 bites

const uint8_t kCarrierAc48TimerSize = 8;
const uint8_t kCarrierAc48TimerMax = 24; // Hours.
const uint8_t kCarrierAc48TimerMin = .5; // .5 Hours increments up tp 9.5

const uint8_t kCarrierAc48OnTimersize = 8;
const uint8_t kCarrierAc48OnTimerOffset = kCarrierAc48OnTimersize; // 16 bites

const uint8_t kCarrierAc48OffTimersize = 8;
const uint8_t kCarrierAc48OffTimerOffset = kCarrierAc48OffTimersize; // 24 bites

const uint8_t kCarrierAc48TempSize = 8;
const uint8_t kCarrierAc48MinTemp = 62; // Fahrenheit
const uint8_t kCarrierAc48MaxTemp = 86; // Fahrenheit
const uint8_t kCarrierAc48TempOffset = kCarrierAc48TempSize ; // 32 bites

const uint8_t kCarrierAc48ModeSize = 8;

const uint8_t kCarrierAc48PowerOff = 0b00000010;
const uint8_t kCarrierAc48Auto = 0b10100010; // 0
const uint8_t kCarrierAc48Cool = 0b10100000; // 1
const uint8_t kCarrierAc48Dry = 0b10000001; // 2
const uint8_t kCarrierAc48Heat = 0b10100011; // 3
const uint8_t kCarrierAc48Fan = 0b10100100; // 4
const uint8_t kCarrierAc48FanAuto = 0b10100100; // 0
const uint8_t kCarrierAc48FanLow = 0b10001100; // 1
const uint8_t kCarrierAc48FanMedium = 0b10010100; // 2
const uint8_t kCarrierAc48FanHigh = 0b10011100; // 3
const uint8_t kCarrierAc48FanTemp = 0b01111110;
const uint8_t kCarrierAc48ModeOffset = kCarrierAc48ModeSize; // 40 bites

const uint8_t kCarrierAc48ModeMainSize = 8;
const uint8_t kCarrierAc48ModeMain = 0b10100001; // to call Main codes
const uint8_t kCarrierAc48ModeMainOffset = kCarrierAc48ModeMainSize; // 48 bites

const uint8_t kCarrierAc48ModeAltSize = 8;
const uint8_t kCarrierAc48ModeAlt = 0b10100010; // secondary functions
const uint8_t kCarrierAc48HswingToggel = 0b00000010;
const uint8_t kCarrierAc48HswingInc = 0b00000001;
const uint8_t kCarrierAc48VswingToggel = 0b00000100;
const uint8_t kCarrierAc48VswingInc = 0b00000011;
const uint8_t kCarrierAc48SelfClean = 0b00001101;
const uint8_t kCarrierAc48Ionize = 0b00000111;
const uint8_t kCarrierAc48Led = 0b00001000;
const uint8_t kCarrierAc48ModeMainOffset = kCarrierAc48ModeAltSize; // 48 bites

The values for Hex 1 to 5 seem straight forward, but I can not figure out how the check sum is being calculated.

I have followed the steps in the Troubleshooting Guide & read the FAQ

Yes, I tried all the variations of calculating the checksum from the wiki, and some of my own, but still no luck.

Other useful information

If you can decipher the checksum at an easy go, and add the rest of the class for CARRIER_AC48 to the ir_carrier.h that would be great. If not no worries, I will mainly be turning the unit on and off with a preset temp.

I did not do any unit testing. I looked at the ir_carrier.cpp to see if I could do it, but could not figure out where you got the string values for the Expect EQ ( ) parts.

Short Request, Peer review, test, and add CARRIER_AC48 support to the main branch.

Thanks

[crankyoldgit]

(Great document, and easy to follow. Thanks for the auto_analyse_raw_data.py tool !!)

Thanks!
Congrats on getting it (mostly) working!

My updated code is in the the forked repository treedog56 / IRremoteESP8266 under the new branch .

If you've got (mostly working) code, please send it in form of a Pull Request (PR) (See https://opensource.com/article/19/7/create-pull-request-github)
This makes it easier for us to review/make comments on it, and make changes to your code etc so it can be merged.

The break out spread sheet of the captured IR codes is located at // https://docs.google.com/spreadsheets/d/1Et618X2dL10q0ESxuNRlSr7ePcRY1LaxBnSi8dCRKtI/edit?usp=sharing

Can you make this doc publicly available (read-only)?

If you can decipher the checksum at an easy go, and add the rest of the class for CARRIER_AC48 to the ir_carrier.h that would be great. If not no worries, I will mainly be turning the unit on and off with a preset temp.

I'll do so when I can access your spreadsheet, and you send it in the form of a PR. ;-)

[treedog56]

If you've got (mostly working) code, please send it in form of a Pull Request (PR) (See https://opensource.com/article/19/7/create-pull-request-github)
This makes it easier for us to review/make comments on it, and make changes to your code etc so it can be merged.
Ok, Pull request #1138 created for this.
The break out spread sheet of the captured IR codes is located at // https://docs.google.com/spreadsheets/d/1Et618X2dL10q0ESxuNRlSr7ePcRY1LaxBnSi8dCRKtI/edit?usp=sharing
Can you make this doc publicly available (read-only)?
Done. I think

[treedog56]

Opps, missed copying one line in IRSend.h. missed the #endif to

if SEND_CARRIER_AC48

void sendCarrier_AC48(const unsigned char data[], uint16_t nbits = kCarrierAc48Bits,
uint16_t repeat = kNoRepeat);

endif

That's what I get for not validating after my coping and pasting in the latest code.

[treedog56]

just noticed that I also did not include the updated default.h in the local dircrtory
I will get this github thing figured out eventually.

[NiKiZe]

just noticed that I also did not include the updated default.h in the local dircrtory
I will get this github thing figured out eventually.

Is this your first time using git? Let us know if there is anything that you want help with.
How are you editing the files, and how do you add them to git?

[treedog56]

Yeah, first time using Git in a meaningful way.

Normal, I get the files from Git in in a zip and then unzip them into my aurdino library. and only need to make minor tweaks to run what ever DYI project I am playing with.

When I make changes I do it by opening notepad and edit the file and save it.

I did the same process for adding support for the for the 48 bit code, but started with version behind 2.7.7

I figured that my work could contribute to the project, so I started my git journey making lots of mistakes.

things I learned

1. don't use notepad to edit a file in a local file, and then drop and drag it to the local repository
2. don't copy and past from a working file to a repo file and not recompile to test.
3. be careful when uploading files on the github website to a repository, too easy for a file to end up in the wrong place.

think I understand the correct process and tools to use after some google time.

Sorry for the extra work, my learning caused.

[crankyoldgit]

things I learned

1. don't use notepad to edit a file in a local file, and then drop and drag it to the local repository
2. don't copy and past from a working file to a repo file and not recompile to test.
3. be careful when uploading files on the github website to a repository, too easy for a file to end up in the wrong place.

think I understand the correct process and tools to use after some google time.

Sorry for the extra work, my learning caused.

Haha. Yeah, we've all been there.
No problems. We are just glad you're actively contributing. We'll help/babysit you through doing things. Git can be quite daunting at first. Heck, 3+ years later and I'm still learning things (and having to look up stuff that I've forgotten)

I really recommend Visual Studio Code or Atom + PlatformIO. It will help you on your Software Development journey. Even if it is just hobby stuff. Both are "free".

[NiKiZe]

Yeah, first time using Git in a meaningful way.

things I learned

1. don't use notepad to edit a file in a local file, and then drop and drag it to the local repository
2. don't copy and past from a working file to a repo file and not recompile to test.
3. be careful when uploading files on the github website to a repository, too easy for a file to end up in the wrong place.

think I understand the correct process and tools to use after some google time.

Sorry for the extra work, my learning caused.

No problem! Git are in some cases considered a dark art, It's a big hurdle at times, but then later it is all worth it.

I would say that you should work with git on your disk.
There should be no copy files, you should do the work in the repository,
You then commit the files, and then push this to github.

Feel free to ask if there is anything that you want help with, take a look at the comments in #1138, and let us/me know if you want help with anything.

[NiKiZe]

Can you add a few parts of what you get from IRrecvDumpV2 ?
This is to get the source for your timings, and also to be able to add and verify unittest.

From the comment https://github.com/crankyoldgit/IRremoteESP8266/pull/1138#discussion_r429601117

If this does conflict with Midea then maybe we want to rethink this?

[crankyoldgit]

If this does conflict with Midea then maybe we want to rethink this?

I'm beginning to suspect this _is_ the same protocol as Midea, based on some of the comments made by @treedog56 and looking at the decodeMidea code & comments.

Ref: https://github.com/crankyoldgit/IRremoteESP8266/pull/1138#discussion_r429606451

[treedog56]

I'm beginning to suspect this _is_ the same protocol as Midea, based on some of the comments made by @treedog56 and looking at the decodeMidea code & comments.

Ref: #1138 (comment)

Confirmed that my remote is using the Midea Protocol.

Issue turned out to be that with my setup, when Serial.print is used, it conflicts with sending the IR code.

comment out the Serial.print lines in and had no issues relaying the comands from the remote to the AC Unit.

As the codes are already accounted and no additional work is needed, I am closing this request.

[crankyoldgit]

@treedog56 Was it this line causing the issue?!? It's the only serial print line in the body of the program.
https://github.com/crankyoldgit/IRremoteESP8266/blob/9e232977168e140d415f5c46d6d8e85581237fe5/examples/SmartIRRepeater/SmartIRRepeater.ino#L140-L143

As far as I can tell this shouldn't cause problems with transmission. If it does, then there may be a bug.

If however, you added a Serial.print in the middle of one of the send routines (e.g. sendMidea()), then yes, that will significantly throw off the timing & cause a message to fail.

[treedog56]

I commented out the following lines in the code also,

Serial.begin(kBaudRate, SERIAL_8N1);
while (!Serial) // Wait for the serial connection to be establised.
delay(50);
Serial.println();

Serial.print("SmartIRRepeater is now running and waiting for IR input "
"on Pin ");
Serial.println(kRecvPin);
Serial.print("and will retransmit it on Pin ");
Serial.println(kIrLedPin);

In addition to

https://github.com/crankyoldgit/IRremoteESP8266/blob/9e232977168e140d415f5c46d6d8e85581237fe5/examples/SmartIRRepeater/SmartIRRepeater.ino#L140-L143

and it would work.

I think it is related to my model of ESP8226 ( included pics of it), I just got a new version of a ESP8662 and that one works just fine with the example with the serial. Print enabled.

Again thanks for following and helping me with my miss adventures. I learned several things during this adventure.

John Holt

From: David Conran [e-mail]
Sent: Tuesday, May 26, 2020 7:03 PM
To: crankyoldgit/IRremoteESP8266 [e-mail]
Cc: treedog56 [e-mail]; Mention [e-mail]
Subject: Re: [crankyoldgit/IRremoteESP8266] Carrier 48-bit modification request (#1136)

@treedog56https://github.com/treedog56 Was it this line causing the issue?!? It's the only serial print line in the body of the program.
https://github.com/crankyoldgit/IRremoteESP8266/blob/9e232977168e140d415f5c46d6d8e85581237fe5/examples/SmartIRRepeater/SmartIRRepeater.ino#L140-L143

As far as I can tell this shouldn't cause problems with transmission. If it does, then there may be a bug.

If however, you added a Serial.print in the middle of one of the send routines (e.g. sendMidea()), then yes, that will significantly throw off the timing & cause a message to fail.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/crankyoldgit/IRremoteESP8266/issues/1136#issuecomment-634362058, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AL6VZIERYMN236FHSESZDWLRTRRF5ANCNFSM4NIFI7IQ.

[crankyoldgit]

Weird, but okay. Thanks for updating me. I shall stop worry that I've got a bug somewhere. ;-)