Support for LG AKB74955603 remote

[kzagatti]

Hi @crankyoldgit

I'm following the steps on the Wiki to share with you the details to support this remote - although the current LG2 works to turn it on and off and change modes, the fan speeds and vertical swing sets are not OK.

I really hope I'm taking it right, but I apologize in advance if something is not as I'm not a developer and I'm doing my best to help.

AC External unit: A4UW30GFA2
AC Internal unit: AMNW09GSJA0
Remote: AKB74955603

Photos of the (original) remote and manual, just for reference:

Created a Google Sheet with the details from IRrecvDumpV2 available at https://docs.google.com/spreadsheets/d/1zF0FI2ENvbLdk4zaWBY9ZYVM3MB_4oxro9wCM7ETX4Y/edit?usp=sharing with comments enabled.

Thank you for your support!

[NiKiZe]

Could you write the model number of both AC and remote (we want to have it in text, and. It parse from pictures, but the pictures are great as verification)

[kzagatti]

Could you write the model number of both AC and remote (we want to have it in text, and. It parse from pictures, but the pictures are great as verification)

Sure, that was on the sheet but I forgot to mention here:

AC External unit: A4UW30GFA2
AC Internal unit: AMNW09GSJA0
Remote: AKB74955603

Thank you!

[crankyoldgit]

Okay looking at the spreadsheet, some of this is easy. e.g. Light sends the same code, so it's a toggle. That's an easy-ish add.

As this is an already supported protocol, just a different model the procedure will be slightly different.
Can you please include what the text description is from IRrecvDumpV2 or V3 and highlight (pref with a colour) when it is wrong etc.?

If we are lucky, we can find something that can tell us the difference between the existing AKB75215403 LG2 model and your new one, so we can automatically detect the difference etc.

the fan speeds and vertical swing sets are not OK.

Are they the only settings that don't work correctly and are not supported? e.g. Light button isn't currently supported.

[kzagatti]

Thank you all, I wasn't expecting to see these replies so fast.

@crankyoldgit I created a new tab on the sheet (named "Fan and Swing errors") and highlighted in red the errors comparing the description from IRrecvDumpV2 with the actual aircon behavior.

It's clear the main issue with this remote is with the vertical swing commands, fan only has 1 issue.

I really appreciate your support!

[crankyoldgit]

Turns out fan speed had multiple issues. I think I've got it .. not sure.

Please download and test out branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/AKB74955603 Let me know how it goes please.

It has required a new LG/LG2 model of AKB74955603. You may need to set that to get any transmission of generated codes to work as you expect.

Now, on to things like light, it seems it is a specialised "Off" message. Not sure. We will need to do more testing, data collection, & analysis to be sure.

The swing settings on the other hand are a weird kettle of fish. You are going to have to do some data analysis to get support for them.

If you look here:

IRremoteESP8266/src/ir_LG.h

Lines 34 to 46 in 7006b9f

	/// Native representation of a LG A/C message.
	union LGProtocol{
	uint32_t raw; ///< The state of the IR remote in IR code form.
	struct {
	uint32_t Sum :4;
	uint32_t Fan :4;
	uint32_t Temp :4;
	uint32_t Mode :3;
	uint32_t :3;
	uint32_t Power:2;
	uint32_t Sign :8;
	};
	};

You'll see our existing mapping of message bits to functions etc. i.e. data code left to right: Signature (8 bits), then Power (2 bits), then UNKNOWN (3 bits), then Mode (3 bits), then Temperature (4 bits), then Fan speed (4 bits), then lastly the Checksum (4 bits).

It seems the swing overlaps with existing setting bits & uses some unknown ones too.
e.g.
Fan speed is controlled by the second last nibble/octet/digit of 0x880A341. i.e. 4 which is the max fan speed.

However, if you look at this range of swing values you'll see that value also changes. So I think it has dual purpose on your model/protocol.
e.g. 0x8813048 & 0x8813059

I think the answer lies with the 3rd & 4th nibble/octet/digit. i.e. 0x8813048 & 0x8813059 i.e. 0x13 or 0b00010011
Of those digits (2 nibbles; 8 bits), we expect the first two bits (0bxx010011) is the power. (0b00 is power on, 0b11 is power off), the next three bits 0b00xxx000 we have no clue about their use. You need to work this out, what they do, what they affect, how it changes the use of the fan speed bits, etc etc. The last 3 bits 0b00000xxx are the operating mode of the A/C. In those data values, that equates to 0b011 or 3 which is kLgAcAuto.

So, of that 0x13 value, those mystery bits are 0b010. You need to explain any result that is not 0b000 for those bits, and how anything else that changes is linked to them.
e.g. Is it that 0b010 in those three bits, plus a fan of 4 means it's the swing middle position? e.g. 0x8813048

When you got that worked out on your spreadsheet/documented etc. Let me know.

[kzagatti]

It's been great pushing my limits trying to understand the more technical side of this, thanks for the opportunity.

I understood the approach with ir_LG.h and as you can see on the sheet (created a new tab named Fan Speed debug (branch code)), it is showing UNKNOWN when it reads "9" but the other modes are named OK - maybe need to declare the kLgAcFanLowAlt variable elsewhere? I didn't get that well.

For the swing, I must confess I tried to understand but I'll really need to dig deeper on that - I'm a fast learner and I'll do my best next weekend.

[crankyoldgit]

It's been great pushing my limits trying to understand the more technical side of this, thanks for the opportunity.

Anytime. ;-)

I understood the approach with ir_LG.h and as you can see on the sheet (created a new tab named Fan Speed debug (branch code)), it is showing UNKNOWN when it reads "9" but the other modes are named OK - maybe need to declare the kLgAcFanLowAlt variable elsewhere? I didn't get that well.

Nope, that's my fault. I didn't handle the output well. Fixed in a new commit to that branch. Please download/build/test with the latest in that existing branch.

For the swing, I must confess I tried to understand but I'll really need to dig deeper on that - I'm a fast learner and I'll do my best next weekend.

Cool. Take your time. Yeah, it's not simple or easy, but it is doable. It comes slightly easier for me as I've done so many of them, but they all take considerable time, data, & testing to reverse-engineer. I've only got so much spare time & energy. ;-) Hence: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Can_you_reverse_engineer_my_AirCon_protocol_for_me

[kzagatti]

@crankyoldgit

Nope, that's my fault. I didn't handle the output well. Fixed in a new commit to that branch. Please download/build/test with the latest in that existing branch.

Fan speed seems to be working perfectly, tried with all fan speeds and the data for the 2 modes that you highlighted on the sheet is updated. Tried only the "receive" mode with IRrecvDumpV2, but I'm wondering how'd I send the proper command with IRsend on Tasmota (if/when this is merged 🤪)...

One thing I couldn't find on the FAQ, how can I send you a beer/coffee? I really appreciate your work and would like to collaborate :-)

Now about the swing, I created a new tab (Swing Tests) and did a lot with the codes (uint64_t data and uint16_t rawData[59]) I got from IRrecvDumpV2. At first my conclusion was that the codes (uint64_t data) were fixed (you can see it doesn't matter the mode/temperature they're always the same, even on power on they're resolved the same). But if that was true, turning the A/C on with the swing at a specific point wouldn't work and the A/C would always turn on at a default position - I tried that with the actual A/C unit and "there's more between the heaven and land", as it turns at the position displayed on the remote. Maybe need to dig the raw data? Not sure how to do that, I tried to compare with the sheet examples but they show hex/binary codes that I can't get with IRrecvDumpV2. Would you give me some guidance on how to do it?

Thanks in advance!

[crankyoldgit]

One thing I couldn't find on the FAQ, how can I send you a beer/coffee? I really appreciate your work and would like to collaborate :-)

So far, I've only accepted in person beer offers. Ask @sheppy99 🍺
My intention is to never ask for or accept money etc for this project. It's free Open Source. Just my way of paying back to the Open Source movement etc.

Now about the swing, I created a new tab (Swing Tests) and did a lot with the codes (uint64_t data and uint16_t rawData[59]) I got from IRrecvDumpV2. At first my conclusion was that the codes (uint64_t data) were fixed (you can see it doesn't matter the mode/temperature they're always the same, even on power on they're resolved the same). But if that was true, turning the A/C on with the swing at a specific point wouldn't work and the A/C would always turn on at a default position - I tried that with the actual A/C unit and "there's more between the heaven and land", as it turns at the position displayed on the remote. Maybe need to dig the raw data? Not sure how to do that, I tried to compare with the sheet examples but they show hex/binary codes that I can't get with IRrecvDumpV2. Would you give me some guidance on how to do it?

Having fixed messages for some settings is fairly common. Especially on short bit length protocols. From you analysis, it seems that is the case here.

Regarding powering on etc.: It's likely the case the A/C unit remembers that last swing position, and it isn't sent again. If it was sent at the same time as two back-to-back messages, I'd expect the raw data to be longer than 59 entries.

A way to test that theory would be to set the position to the highest, then turn off the a/c. Then cover the remote (or take it to another room etc) and change the position to the lowest on the remote, Then uncover the remote, and turn the a/c back on etc.

If the a/c doesn't change position, then it should be that the a/c just remembers the last position it saw. (Most likely scenario)
If it does change to the lowest, then there is something in the signal or message we are not seeing/working out etc.

FYI, unless the raw data changes in length, it's highly unlikely there is any hidden data in it that the uint64_t data isn't representing.