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.

[kzagatti]

@crankyoldgit

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.

I understand and I really appreciate your work!

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.

And you got it, again! Tested turning the A/C unit on, set a specific swing position, turned it off, covered the remote to turn it on + set another swing position + turned off and finally turned the A/C unit on. It went on with the first swing position, confirming this setting is fixed (the AC remembers the last swing position).

So now we have the fan speed, swing positions and AC light worked out. Do you want me to debug other remote options (Jet Mode, Timer...)?

[crankyoldgit]

Speaking of light, can you please test the "light" button with other modes/settings, to see if it changes at all from the code in the sheet? If it doesn't, you don't need to record it. Only need to if it changes.

[kzagatti]

No changes. Every time I press any button (mode, temperature, swing) the light comes back on and you have to press Light Off again.

[crankyoldgit]

No changes. Every time I press any button (mode, temperature, swing) the light comes back on and you have to press Light Off again.

Interesting. So, any "normal" message will reset "light" to on. Correct?
i.e. If we want it to be off, we need to send a "light" toggle message after every "normal" command. Correct?

[kzagatti]

Interesting. So, any "normal" message will reset "light" to on. Correct?
i.e. If we want it to be off, we need to send a "light" toggle message after every "normal" command. Correct?

Exactly! (quite annoying, but that's how this A/C behaves)

[crankyoldgit]

Does the "light" toggle/button work when the power is off?. i.e. Can you change the light/led/display/whatever when the A/C is off, and it it actually changes the "light" on the A/C without it powering the A/C back up?
And of course, does the hex value change?

[crankyoldgit]

And can you please test the latest update to that branch, it has experimental support for the light setting/toggle etc.

[kzagatti]

Does the "light" toggle/button work when the power is off?. i.e. Can you change the light/led/display/whatever when the A/C is off, and it it actually changes the "light" on the A/C without it powering the A/C back up?
And of course, does the hex value change?

The A/C unit "beeps" when I press the light button with the power is off, but nothing actually happens (no light is turned on). And the hex is always the same as we have on the sheet, 0x88C00A6.

And can you please test the latest update to that branch, it has experimental support for the light setting/toggle etc.

Added to the sheet (tab Light Tests) just to have it documented, but it's OK. Just a suggestion to the text, if it was only "Light Toggle" or "Light Off" that'd represent better because the name on the remote is "Light Off" and every other command you send turns the light on, so you basically press this button to turn the light off.

And just to confirm, this version did not bring anything related to the swing positions, right?

[crankyoldgit]

The A/C unit "beeps" when I press the light button with the power is off, but nothing actually happens (no light is turned on). And the hex is always the same as we have on the sheet, 0x88C00A6.

Noted. Thanks for that.

Added to the sheet (tab Light Tests) just to have it documented, but it's OK. Just a suggestion to the text, if it was only "Light Toggle" or "Light Off" that'd represent better because the name on the remote is "Light Off" and every other command you send turns the light on, so you basically press this button to turn the light off.

Excellent. I was going with Toggle, as you spreadsheet data indicated that multiple consecutive presses changed the state each time. Is that not the case?

And just to confirm, this version did not bring anything related to the swing positions, right?

Correct. But I'm almost finished ...

[crankyoldgit]

Now ... can you please download and test the branch again? Hopefully Vertical Swing should work. 🤞

[kzagatti]

Excellent. I was going with Toggle, as you spreadsheet data indicated that multiple consecutive presses changed the state each time. Is that not the case?

Toggle is fine! Button name on the remote is "Light Off", but you press it to toggle on/off so Toggle is more accurate than the original remote 🤪

Now ... can you please download and test the branch again? Hopefully Vertical Swing should work. 🤞

Confirmed, everything is working correctly with IRrecvDumpV2!

[crankyoldgit]

No worries.

[kzagatti]

Hi @crankyoldgit

IRMQTTServer is awesome, I've been playing/testing it before moving away from Tasmota and, for now, there is one issue (that I'd probably post on IRMQTTServer git):

• Flashed a NodeMCU with IRMQTT directly from the Arduino IDE, checked the flash size to make sure we still have room for OTA;
• It boots up ok, I'm able to configure wifi and etc... it comes to life!
• I go to the admin page and try to upload tasmota-minimal via OTA (to test the plan B).... Nothing happens

Edit: tried with both .bin and .bin.gz files, results are the same. And there is free memory (Free Sketch Space: 368k).

After hitting "update" it never comes back up. I see the default AP again but when I connect to it, I can't access 192.168.4.1.
The only way to get it back to life is flashing it again from the Arduino IDE (and it's worth mentioning it comes back with the previous configs).

Turned the debug on and this is what I get from the serial monitor:

0000340.506: Update:
0000340.507: tasmota-minimal (1).bin.gz
0000347.663: Update Success:
0000347.664: 284410
0000347.664: Rebooting...
0000347.665: Attempting firmware update & reboot
0000348.669: Post firmware reboot.

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3460, room 16 
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4 
tail 4
chksum 0xc9
csum 0xc9
v0008d6e0
@cp:0
ld

Well, this the plan B, but I'm doing some other tests too. Would you like me to keep posting that here?

Thanks!

[crankyoldgit]

0000340.507: tasmota-minimal (1).bin.gz

There is probably your problem. IRMQTTServer's OTA is expecting a .bin file, not a .bin.gz file.
Tasmota added the ability to handle compressed (.gz) binaries. IRMQTTServer doesn't have that. Thus you need to decompress it before OTA flashing it.

[crankyoldgit]

Edit: tried with both .bin and .bin.gz files, results are the same. And there is free memory (Free Sketch Space: 368k).

Hmm. Not sure. IRMQTTServer is using the standard/original OTA upload method. How have you built the tasmota binary? And what ESP8266 variant are you uploading to? e.g. How much flash? What memory format/partitioning/FS size did you chose?

[kzagatti]

Hmm. Not sure. IRMQTTServer is using the standard/original OTA upload method. How have you built the tasmota binary? And what ESP8266 variant are you uploading to? e.g. How much flash? What memory format/partitioning/FS size did you chose?

Just downloaded the files from http://ota.tasmota.com/tasmota/release/
Even tried with an older (smaller) version...

It's a standard NodeMCU v3, 1MB and I'm using flash size 1MB FS:64kb

[kzagatti]

Ah, also tried with a larger file just to confirm the debug message and when it fails (due to space) it shows up an "update failed, not enough space" on the serial screen...

[crankyoldgit]

It's a standard NodeMCU v3, 1MB and I'm using flash size 1MB FS:64kb

Odd. I thought all NodeMCU boards were 4Mb of flash.

The standard builds of Tasmota are made for 1Mb devices. (Which in theory should just work). It may be that the flash needs to be fully erased.

So, what is the serial output of you loading (via IRMQTTServer) a Tasmota .bin file. (i.e. Not a .bin.gz file)?

[crankyoldgit]

ie. serial of it loading it and the subsequent reboots etc.

[kzagatti]

It was the same before, I even copied the debug message...

But I tried again with the .bin file and got a not enough space message - so this is probably due to the size of the memory. I confirmed this NodeMCU (v3 lol1n) has only 1M but it usually works with Tasmota (I'm using tasmota-ir.bin so when I want to change it via OTA I have to upload the minimal version to free up the space).

0000192.159: Update:
0000192.162: tasmota-minimal-8.5.1.bin
ERROR[4]: Not Enough Space
ERROR[4]: Not Enough Space
ERROR[4]: Not Enough Space
ERROR[4]: Not Enough Space
ERROR[4]: Not Enough Space
ERROR[4]: Not Enough Space
0000202.176: Attempting firmware update & reboot
0000203.180: Post firmware reboot.

Well, I'm going all-in with IRMQTTServer and if I have to come back I'll just hook up the pins :-)
Thanks for your quick reply @crankyoldgit, I'll let you know about the other tests!

[crankyoldgit]

Yeah, I'd say there isn't enough space on 1M to do the OTA. Tasmota jumps through a lot of hoops to try to still allow it on a 1M platform.

How big is the Tasmota minimal.bin file?

Options are:

• Compile a smaller version of IRMQTTServer (by disabling protocols etc), upload that, and it might give you space for the tasmota minimal.
  • This is probably a wise thing to do as your board is 1M, and if you want to OTA upgrade it later, you need to get it (IRMQTTServer's .bin file well below 512kb) See:
    

    IRremoteESP8266/src/IRremoteESP8266.h

    Lines 63 to 105 in 9a473c9

    	// Do we enable all the protocols by default (true), or disable them (false)?
    	// This allows users of the library to disable or enable all protocols at
    	// compile-time with `-D_IR_ENABLE_DEFAULT_=true` or
    	// `-D_IR_ENABLE_DEFAULT_=false` compiler flags respectively.
    	// Everything is included by default.
    	// e.g. If you only want to enable use of he NEC protocol to save program space,
    	// you would use something like:
    	// `-D_IR_ENABLE_DEFAULT_=false -DDECODE_NEC=true -DSEND_NEC=true`
    	//
    	// or alter your 'platform.ini' file accordingly:
    	// ```
    	// build_flags = -D_IR_ENABLE_DEFAULT_=false
    	// -DDECODE_NEC=true
    	// -DSEND_NEC=true
    	// ```
    	// If you want to enable support for every protocol *except* _decoding_ the
    	// Kelvinator protocol, you would use:
    	// `-DDECODE_KELVINATOR=false`
    	#ifndef _IR_ENABLE_DEFAULT_
    	#define _IR_ENABLE_DEFAULT_ true // Unless set externally, the default is on.
    	#endif // _IR_ENABLE_DEFAULT_
    	// Supported IR protocols
    	// Each protocol you include costs memory and, during decode, costs time
    	// Disable (set to false) all the protocols you do not need/want!
    	// The Air Conditioner protocols are the most expensive memory-wise.
    	//
    	// Semi-unique code for unknown messages
    	#ifndef DECODE_HASH
    	#define DECODE_HASH _IR_ENABLE_DEFAULT_
    	#endif // DECODE_HASH
    	#ifndef SEND_RAW
    	#define SEND_RAW _IR_ENABLE_DEFAULT_
    	#endif // SEND_RAW
    	#ifndef DECODE_NEC
    	#define DECODE_NEC _IR_ENABLE_DEFAULT_
    	#endif // DECODE_NEC
    	#ifndef SEND_NEC
    	#define SEND_NEC _IR_ENABLE_DEFAULT_
    	#endif // SEND_NEC

• Upload/use a very small intermediate OTA program. e.g. https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266HTTPUpdateServer/examples/WebUpdater/WebUpdater.ino
  Load this between using IRMQTTServer and Tasmota
• Move to a bigger ESP8266 Flash. ;-)
• Resort to serial uploading :-(

[kzagatti]

How big is the Tasmota minimal.bin file?

368kb. But don't worry, if I ever need to come back I'll flash it via serial.

As for the tests with IRMQTTServer, I set the Protocol for LG2 and Model 3 on the Air Conditioner Control page and I'm able to control the A/C properly, the only command that doesn't work is power on/off (but it works when I select it from the Mode input). With Home Assistant the setup was straightforward, as per the description on the .ino file. But when I turn the A/C on (fan_only, for example), I see that two commands are actually sent to the A/C:

Message 1 received on ir_server_quarto/ac/cmnd/mode at 11:59 PM:
fan_only
QoS: 0 - Retain: false
Message 0 received on ir_server_quarto/ac/cmnd/power at 11:59 PM:
ON
QoS: 0 - Retain: false

The first one, power, is exactly what's not working via Air Conditioning Control.... And the beep I hear from the A/C is as if the unit was being turned off - maybe something with the codes or model? Can't debug exactly what's being sent in this case...

Anyway, I just changed the power topic to something that will not trigger anything and so far... so good! Moving the other IR devices (TV, etc) to IRMQTTServer too :-)

If you want me to keep debugging, just let me know! But thanks for your hard work.

EDIT: If it helps, this is the configuration I'm using:

climate:
  - platform: mqtt
    name: Ar Quarto MQTT
    modes:
      - "off"
      - "cool"
      - "heat"
      - "fan_only"
    fan_modes:
      - "Auto"
      - "Min"
      - "Low"
      - "Medium"
      - "High"
      - "Max"
    swing_modes:
      - "Off"
      - "Auto"
      - "Highest"
      - "High"
      - "Middle"
      - "Low"
      - "Lowest"
    power_command_topic: "not_used/ac/cmnd/power"
    mode_command_topic: "ir_server_quarto/ac/cmnd/mode"
    mode_state_topic: "ir_server_quarto/ac/stat/mode"
    temperature_command_topic: "ir_server_quarto/ac/cmnd/temp"
    temperature_state_topic: "ir_server_quarto/ac/stat/temp"
    fan_mode_command_topic: "ir_server_quarto/ac/cmnd/fanspeed"
    fan_mode_state_topic: "ir_server_quarto/ac/stat/fanspeed"
    swing_mode_command_topic: "ir_server_quarto/ac/cmnd/swingv"
    swing_mode_state_topic: "ir_server_quarto/ac/stat/swingv"
    min_temp: 18
    max_temp: 30
    temp_step: 1
    retain: false

[kzagatti]

Well, last for today - tried to send a MQTT Discovery message but from the log listener I'm getting the following message:

Message 0 received on ir_server_quarto/log at 12:16 AM:
MQTT climate discovery FAILED to send.
QoS: 0 - Retain: false

[crankyoldgit]

I've just added a minimal OTA build option (via PlatformIO) at 380496 bytes (371k) vs a "full" version at 549032 bytes.
See branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/IRMQTTServer_minimal

That's as small as I can easily make it without going to a lot of effort.

[crankyoldgit]

Well, last for today - tried to send a MQTT Discovery message but from the log listener I'm getting the following message:

Message 0 received on ir_server_quarto/log at 12:16 AM:
MQTT climate discovery FAILED to send.
QoS: 0 - Retain: false

I honestly haven't used this feature in ages. I'll try to take a look to see what I can see.

[crankyoldgit]

Oh and yeah, this is now kind of not the same original issue. Should probably create a new one(s) for these.

[crankyoldgit]

How big is the Tasmota minimal.bin file?

368kb. But don't worry, if I ever need to come back I'll flash it via serial.

As for the tests with IRMQTTServer, I set the Protocol for LG2 and Model 3 on the Air Conditioner Control page and I'm able to control the A/C properly, the only command that doesn't work is power on/off (but it works when I select it from the Mode input). With Home Assistant the setup was straightforward, as per the description on the .ino file. But when I turn the A/C on (fan_only, for example), I see that two commands are actually sent to the A/C:

Message 1 received on ir_server_quarto/ac/cmnd/mode at 11:59 PM:
fan_only
QoS: 0 - Retain: false
Message 0 received on ir_server_quarto/ac/cmnd/power at 11:59 PM:
ON
QoS: 0 - Retain: false

The first one, power, is exactly what's not working via Air Conditioning Control.... And the beep I hear from the A/C is as if the unit was being turned off - maybe something with the codes or model? Can't debug exactly what's being sent in this case...

Anyway, I just changed the power topic to something that will not trigger anything and so far... so good! Moving the other IR devices (TV, etc) to IRMQTTServer too :-)

If you want me to keep debugging, just let me know! But thanks for your hard work.

EDIT: If it helps, this is the configuration I'm using:

climate:
  - platform: mqtt
    name: Ar Quarto MQTT
    modes:
      - "off"
      - "cool"
      - "heat"
      - "fan_only"
    fan_modes:
      - "Auto"
      - "Min"
      - "Low"
      - "Medium"
      - "High"
      - "Max"
    swing_modes:
      - "Off"
      - "Auto"
      - "Highest"
      - "High"
      - "Middle"
      - "Low"
      - "Lowest"
    power_command_topic: "not_used/ac/cmnd/power"
    mode_command_topic: "ir_server_quarto/ac/cmnd/mode"
    mode_state_topic: "ir_server_quarto/ac/stat/mode"
    temperature_command_topic: "ir_server_quarto/ac/cmnd/temp"
    temperature_state_topic: "ir_server_quarto/ac/stat/temp"
    fan_mode_command_topic: "ir_server_quarto/ac/cmnd/fanspeed"
    fan_mode_state_topic: "ir_server_quarto/ac/stat/fanspeed"
    swing_mode_command_topic: "ir_server_quarto/ac/cmnd/swingv"
    swing_mode_state_topic: "ir_server_quarto/ac/stat/swingv"
    min_temp: 18
    max_temp: 30
    temp_step: 1
    retain: false

I'll also need to know the "state" of the MQTT topics too to debug this. e.g. Is the model topic set etc? and what the "web page" thinks things are set too.

[kzagatti]

Moving to #1542

[crankyoldgit]

FYI, the changes mentioned above have been included in the just released v2.7.20 of the library.