Electrolux Kelvinator ESE24HRA (Midea?)

[CRCinAU]

Version/revison of the library used

v2.5.5

I'm trying to identify the protocol used by this model unit. When I TX using the ir_Midea.h, when sending the following, all that happens is the display on the unit goes out. Hardware is a D1 Mini.

Extract of code:

#define IR_PIN D7
IRMideaAC ac(IR_PIN);
bool ac_on = false;

in setup():

// Set up the IR LED pin
pinMode(IR_PIN, OUTPUT);
ac.begin();

In a timer getting triggered every 15 seconds:

if ( ac_on ) {
    ac.off();
    ac.send(4);
    ac_on = false;
} else {
    ac.on();
    ac.setTemp(24, true);
    ac.setMode(kMideaACCool);
    ac.setFan(kMideaACFanAuto);
    ac.send(4);
    ac_on = true;
}

The remote control has a sticker on the back that says: R51K/BGE

This seems to be all over the place to purchase replacements etc - so I'm wondering if its somewhat already known - but I just can't find the right parameters... There also doesn't seem to be an example for this in the examples folder - so any pointers on if I've got the code totally wrong would be helpful!

Link to remote control manual: https://www.manualslib.com/products/Electrolux-R51k-Bge-3964606.html

[crankyoldgit]

The best way to determine what type it is, and if it is supported, is to try using the IRrecvDumpV2 example code and an IR demodulate circuit. It should help determine what it is, or at worst, you can give us the output and we can see if we can support it at all.

[CRCinAU]

I don't have a IR Receiver atm - so that's making life a bit hard - unless I destroy something to pull out an IR detector of some type to try and figure it out! I've got a couple of rtl2832u DVB-T dongles that could donate one, but there's no markings on them to figure out the pinouts.

I've been comparing the Midea code to this: https://github.com/sheinz/esp-midea-ir/blob/master/midea-ir.c

And also this: https://github.com/WiserUFBA/ArduMideaWrapper/blob/master/src/MideaIR.h

There seems to be a number of differences between those and the Midea stuff in IRremote. Especially in the protocol construction. I'm trying to reconcile the differences - but it seems quite difficult...

I wonder if there's anything specific I can try on a TX only method to confirm? Otherwise I'll have to try and hunt an IR receiver...

EDIT: Eh, quick hunt with a multimeter + plugging it in gives me a 3.3v pin, GND, and what looks to be a signal pin...

[crankyoldgit]

I really recommend getting an IR receiver module, they are only a dollar or so on Ebay/Aliexpress etc. Otherwise you are flying blind. They have a fairly standard pin-out. See our wiki for an example circuit.

Otherwise, try the examples for some ACs, and then try every protocol type?! e.g. replace the header/class etc. Which would suck, for want of a $1 component.

[CRCinAU]

Ok - so I got impatient and gutted the IR receiver off my RTL dongle (as I never use the remote anyway).

Pressed a button and got this:

IRrecvDumpV2 is now running and waiting for IR input on Pin 13
Timestamp : 000004.090
Encoding  : COOLIX
Code      : B2BF20 (24 bits)
Mesg Desc.: Power: On, Fan: 5 (AUTO), Mode: 0 (COOL), Temp: 20C, Zone Follow: Off, Sensor Temp: Ignored
Library   : v2.5.5
Raw Timing[199]:
+  4400, -  4412,    +   542, -  1606,    +   544, -   584,    +   516, -  1606,
+   544, -  1632,    +   544, -   558,    +   516, -   584,    +   518, -  1606,
+   544, -   584,    +   516, -   558,    +   516,-  1632,    +   544, -   558,
+   516, -   584,    +   516, -  1606,    +   542, -  1634,    +   542, -   558,
+   516, -  1634,    +   540, -  1634,    +   516, -   586,    +   512, -  1636,
+   512, -  1664,    +   510, -  1666,    +   510, -  1640,    +   510, -  1666,
+   510, -  1640,    +   510, -   592,    +   508, -  1640,    +   510, -   592,
+   508, -   566,    +   508, -   592,    +   508, -   566,    +   508, -   592,
+   508, -   566,   +   510, -   592,    +   508, -   566,    +   510, -  1666,
+   510, -   566,    +   508, -   592,    +   508, -   566,    +   508, -   566,
+   508, -   592,    +   510, -  1640,    +   510, -  1666,    +   510, -   566,
+   536, -  1640,    +   510, -  1666,    +   510, -  1640,    +   510, -  1666,
+   510, -  1640,    +   508, -  5260,    +  4366, -  4446,    +   508, -  1640,
+   510, -   592,    +   508, -  1640,    +   510, -  1666,    +   510, - 566,
+   508, -   592,    +   508, -  1640,    +   510, -   592,    +   510, -   564,
+   508, -  1668,    +   508, -   566,    +   508, -   592,    +   508, -  1640,
+   508, -  1668,    +   508, -   566,    +   508, -  1668,+   508, -  1668,
+   508, -   566,    +   508, -  1668,    +   508, -  1640,    +   508, -  1668,
+   508, -  1642,    +   508, -  1668,    +   508, -  1668,    +   508, -   566,
+   508, -  1668,    +   508, -   566,    + 508, -   594,    +   506, -   592,
+   484, -   566,    +   508, -   618,    +   482, -   592,    +   484, -   616,
+   484, -   592,    +   482, -  1692,    +   484, -   592,    +   482, -   618,
+   484, -   590,    +   484,-   618,    +   484, -   590,    +   484, -  1692,
+   482, -  1666,    +   484, -   618,    +   482, -  1668,    +   482, -  1692,
+   484, -  1666,    +   482, -  1692,    +   482, -  1694,    +   482
uint16_t rawData[199] = {4400, 4412,  542, 1606,  544, 584,  516, 1606,  544, 1632,  544, 558,  516, 584,  518, 1606,  544, 584,  516, 558,  516, 1632,  544, 558,  516, 584,  516, 1606,  542, 1634,  542, 558,  516, 1634,  540, 1634,  516, 586,  512, 1636,  512, 1664,  510, 1666,  510, 1640,  510, 1666,  510, 1640,  510, 592,  508, 1640,  510, 592,  508, 566,  508, 592,  508, 566,  508, 592,  508, 566,  510, 592,  508, 566,  510, 1666,  510, 566,  508, 592,  508, 566,  508, 566,  508, 592,  510, 1640,  510, 1666,  510, 566,  536, 1640,  510, 1666,  510, 1640,  510, 1666,  510, 1640,  508, 5260,  4366, 4446,  508, 1640,  510, 592,  508, 1640,  510, 1666,  510, 566,  508, 592,  508, 1640,  510, 592,  510,564,  508, 1668,  508, 566,  508, 592,  508, 1640,  508, 1668,  508, 566,  508, 1668,  508, 1668,  508, 566,  508, 1668,  508, 1640,  508, 1668,  508, 1642,  508, 1668,  508, 1668,  508, 566,  508, 1668,  508, 566,  508, 594,  506, 592,484, 566,  508, 618,  482, 592,  484, 616,  484, 592,  482, 1692,  484, 592,  482, 618,  484, 590,  484, 618,  484, 590,  484, 1692,  482, 1666,  484, 618,  482, 1668,  482, 1692,  484, 1666,  482, 1692,  482, 1694,  482};  // COOLIX B2BF20
uint64_t data = 0xB2BF20;

[CRCinAU]

Playing around with the functions, this bit seems accurate for every function I use:

Mesg Desc.: Power: On, Fan: 0 (AUTO0), Mode: 2 (AUTO), Temp: 21C, Zone Follow: Off, Sensor Temp: Ignored

As such, this is probably supported by the Coolix library and you can add the R51K/BGE remote type to the supported functions on this library :)

[CRCinAU]

In fact, there's still something strange going on..... When I use the following, the display on the A/C turns off, it clicks (like its set something), but the fan keeps going.

if ( ac_on ) {
    ac.setPower(false);
    ac.send(1);
    ac_on = false;
} else {
    ac.setPower(true);
    ac.setTemp(24);
    ac.setMode(kCoolixCool);
    ac.setFan(kCoolixFanAuto);
    ac.send(1);
   ac_on = true;
}

Is there something else I'm not quite getting? :confused:

[CRCinAU]

Hmm - it seems the order of the commands matters? I'm using this and it seems to work now:

if ( ac_on ) {
    ac.setPower(false);
    ac.send(1);
    ac_on = false;
} else {
    ac.setMode(kCoolixCool);
    ac.setTemp(24);
    ac.setFan(kCoolixFanAuto);
    ac.send(1);
    ac_on = true;
}

[crankyoldgit]

Can you simplify the problem situation any further? I.e. remove the if ( ac_on ) condition. For example, can you substitute what you want to do into one of the AC examples, so we can eliminate possible problems from the rest of your code?

[CRCinAU]

It seems to be if I called it as setTemp, setMode, setFan, send that the A/C didn't like what it received and didn't seem to respond. In the order of my last post, it seemed to be fine. I'm not sure if there is a re-ordering of commands within the framework - or if its just bytes added to a buffer (I haven't dug that deep yet).

My current issue is that I can't seem to drive my IR LEDs hard enough to get decent range out of them... I've tried with a NPN transistor driven from an 8266 (3.3v) via 2.2k (also tried 1k) resistor with LED between +5v and collector and emitter to ground. Doesn't get anywhere near the range of the stock handheld remote... Not sure what I'm doing wrong here...

[crankyoldgit]

Can you please capture the code (e.g. 0xB2BF20) from the actual remote for the desired settings you are trying to reproduce in the code? From your code, that should be On, Cool mode, 24C, Fan auto. I can then compare what real remote's code is, and what the library would generate.

[Warning, I'm no electrical engineer! On my best days, I'm at hobbyist at best ;) So trust anyone else with electronics experience before me. :)] As for LED power etc, I get about 5m of transmitting distance. using a setup with a 5V->IRLED->GND (i.e. no resistor) path through a NPN transistor. That's from a single cheap-o IR LED from ebay etc. If there is direct sunlight streaming from a window in the target area, I probably only get an 80% transmission success rate. Outside of that, it works 99% of the time. So ... maybe try a different IR LED or a different variant/manufacturer etc. Or maybe the transistor is limiting current for some reason? I've not been able to get the power & range from my normal TV remotes but the setup works for my needs. e.g. TV remotes seem to be able to be powerful enough some times to reflect of walls/ceilings and still control a device. I can't replicate that power, I have to aim the IR LED moderately well to get it to work. Or maybe it's your power supply not delivering enough current? That's unlikely, but a capacitor should help if that's the case.

[CRCinAU]

I thought about the power supply - and stuck a 2000uF cap on the 5v side of things to try and offset any draws from the IR pulse. I'm thinking it may be the LED - currently I'm using a Motorola MLED71 - as its all I could get locally - but got more coming to test with.

I guess what it means right now is that my testing can be somewhat hit and miss.

I asked the 'brains trust' here: https://www.reddit.com/r/esp8266/comments/az4b7d/help_driving_ir_leds_on_esp8266_d1_mini/

What NPN do you use and do you use a resistor between the GPIO pin and the base?

[sheppy99]

I’ve had the most success controlling IR devices with stick on LED’s attached to the front of the controlled units. It’s also possible if you didn’t include a current limiting resister in series with the IR LED that it’s fried. On a meter using the diode test function all my good IR LED’s measure around 0.97V. On saying that this hasn’t worked as well with my Daikin unit which over a week went from working to not working at all. All LED’s have a maximum power they can take, and a 5V supply with a good transistor directly driving an LED without any current limiting will likely exceed this considerably. Then again I always over engineer things as I don’t like repeating work

[crankyoldgit]

According to my ancient Ebay email, it's a 2N3904 NPN Transistor in a TO-92 package. I just google'd it's specs, and it seems it has a 200mA max current, so that's probably why I can't really drive the IR LED very hard. (and why when I tried to drive several in parallel it didn't perform well at all)

No, I don't use any resistors between the GPIO and the base. If you are seeing/getting any signal from the IR LED (i.e. you can see it pulse with your phone camera) then you don't need to play with gpio-resistor-base combinations. AFAIUI, the base operates literally as a binary switch. It only needs a sniff of a current to trigger. When it does, the current flows between collector and emitter etc. That latter current flow is independent of the current/voltage at the base (as long it is enough to trigger it of course)

[crankyoldgit]

TL;DR: Using a current limiting resistor for the IR LED and using the correct voltage (i.e. keeping it in spec) is the correct thing to do if you want it to last.

I agree with @sheppy99. It's very easy to kill an LED, and it's less obvious when you've killed an IR LED.

My experience is you can drive most of them <cough>relatively safely</cough> with 5V(Vin) and no resistor with the typical pulses this library produces and the typical usage. e.g. pulses of ~16 usecs over a period of ~100 msecs. Mine have lasted 2+ years getting used ~30 times a day. Note: 5V is way way out of their spec. When I drove them from ESP8266's 3.3V(3v3) I didn't get much range. I am consciously over-driving them at 5V and fully expect them to fail sometime. My solution is an acceptable hack, not an engineered one. I'm no electrical engineer.

I've blown the same IR LEDs after just a few seconds of constant "on" in the same conditions.

@sheppy99 I've found relatively poor reception when having the transmitter too close to the receiver. It seems to screw with the hardware IR receiver module. or at least the ones I have. e.g. few cm's == bad, signals were more reliable with 30cm+ separation. No idea if that's contributing to your problem.

[sheppy99]

@crankyoldgit I've got stick on's on a Mitsubishi Electric Ducted with optional IR receiver, and a Fujitsu Floor Console Unit, both driven by a USB IR Dongle which have worked for just over a year now, yet the same unit on the Daikin ran from an ESP via transistor initially worked way better than an external one which happily works a Fujitsu High Wall Unit. Then over about a week it slowly stopped working. There's something weird about this Daikin unit so first of all I'll get a photo diode and a mates storage scope to check the carrier frequency before moving forward. Its possible the thing has simply come unstuck and slowly slipped off the detector as it has been a hot summer across the ditch, but I may as well cover all bases just to make sure this thing is as good as it can be. I'll also experiment with how far away the IR LED is, thanks for the tip

[crankyoldgit]

@sheppy99 My layman's theory is the cheapo IR demodulators can get over-driven by a really strong signal. Or maybe they get too many reflections with something too close. I don't know. All I know is from practical experience putting a TV etc remote to close to a module and getting very odd (and extra) timings which caused things to not match expected signals. The stick on ones you have are probably low-power etc so probably don't have that issue. But it's a simple tip to try and it's worked for me in the past.

(P.S. Yes, it's hot over here too on the Western Island ... he says having turned on his A/C via this library and example code a few hours ago ;-)

[sheppy99]

@crankyoldgit that makes perfect sense. Swamping the front end was a definite problem years ago in my HF engineering days. The USB IR dongle and stick on’s were bought as a plug and play set which I just spliced a few metres of Cat5 into and all worked flawless until I swapped the bedroom heatpump. Unfortunately the dongle buffer overflows with the raw codes on the Daikin which is why I ventured into ESP land. However there may be a chink in its armour with one channel no longer seeming to work with the 2 LED’s in parallel I use to switch the TV on. I suspect a week of IR work is coming up assuming I have the energy which is very debatable. My guess is eventually the ESP may be gaining several sending channels

[crankyoldgit]

@CRCinAU Can you try out the code in branch: https://github.com/markszabo/IRremoteESP8266/tree/Issue624

Hopefully that will behave more like you expect.

The TL;DR: is yes, there is/was an issue with class method ordering. Some methods (like off/sleep/swing/etc) are special cases and could screw things up.

I'm still interested in the codes I requested though.

[CRCinAU]

Just read through the commits you did above - seems sane... Here's a ton of captures from the remote:

Mesg Desc.: Power: On, Fan: 5 (AUTO), Mode: 0 (COOL), Temp: 20C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BF20;

Mesg Desc.: Power: On, Fan: 4 (MIN), Mode: 0 (COOL), Temp: 20C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB29F20;

// Swing button:
Mesg Desc.: Power: On, Fan: 3 (UNKNOWN), Swing: Toggle
uint64_t data = 0xB26BE0;

// Swing button again:
Mesg Desc.: Power: On, Fan: 3 (UNKNOWN), Swing: Toggle
uint64_t data = 0xB26BE0;

//Economy button:
Mesg Desc.: Power: On, Fan: 7 (FIXED), Sleep: Toggle
uint64_t data = 0xB2E003;

// Economy button again:
Mesg Desc.: Power: On, Fan: 5 (AUTO), Mode: 0 (COOL), Temp: 20C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BF20;

// Display button:
Mesg Desc.: Power: On, Fan: 7 (FIXED), Led: Toggle
uint64_t data = 0xB5F5A5;

// Display button again:
Mesg Desc.: Power: On, Fan: 7 (FIXED), Led: Toggle
uint64_t data = 0xB5F5A5;

// Set to mode AUTO, fan AUTO, 20C
Mesg Desc.: Power: On, Fan: 0 (AUTO0), Mode: 2 (AUTO), Temp: 20C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB21F28

Is there anything else you want from this remote?

[crankyoldgit]

Is there anything else you want from this remote?

Yes, per my earlier request "On, Cool mode, 24C, Fan auto." please. Preferable with the current master branch.

Also, if you turn the unit off with the remote, do the captured code values change at all if you are switching it off from different settings? i.e. Is it truly only a single/static message for turning the unit off or are their multiple ones?

[CRCinAU]

Ok, I pulled down master on this repo, then built the IRrecvDumpV2 project in PIO.

Mesg Desc.: Power: On, Mode: 0 (COOL), Fan: 5 (AUTO), Temp: 24C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BF40;

Mesg Desc.: Power: Off
uint64_t data = 0xB27BE0;

Set to 20C and turned on:
Mesg Desc.: Power: On, Mode: 0 (COOL), Fan: 5 (AUTO), Temp: 20C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BF20;

Turned off again:
Mesg Desc.: Power: Off
uint64_t data = 0xB27BE0;

Turned on again in a different mode:
Mesg Desc.: Power: On, Mode: 2 (AUTO), Fan: 0 (AUTO0), Temp: 20C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB21F28;

Turned off again:
Mesg Desc.: Power: Off
uint64_t data = 0xB27BE0;

Turned on again in FAN only mode:
Mesg Desc.: Power: On, Mode: 4 (FAN), Fan: 5 (AUTO), Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BFE4;

Turned off again:
Mesg Desc.: Power: Off
uint64_t data = 0xB27BE0;

Set to HEAT / 24C / AUTO:
Mesg Desc.: Power: On, Mode: 1 (DRY), Fan: 0 (AUTO0), Temp: 24C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB21F44;

Turned off again:
Mesg Desc.: Power: Off
uint64_t data = 0xB27BE0;

Set to HEAT / 24C / AUTO:
Mesg Desc.: Power: On, Mode: 3 (HEAT), Fan: 5 (AUTO), Temp: 24C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BF4C;

Set to HEAT / 24C / FAN LOW:
Mesg Desc.: Power: On, Mode: 3 (HEAT), Fan: 4 (MIN), Temp: 24C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB29F4C;

[CRCinAU]

Interesting the FAN setting changes between the different modes while set to FAN AUTO....

[CRCinAU]

Just cycling through the modes while leaving the rest of the settings the same at 23C / FAN AUTO:

Mesg Desc.: Power: On, Mode: 2 (AUTO), Fan: 0 (AUTO0), Temp: 23C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB21F58;

Mesg Desc.: Power: On, Mode: 0 (COOL), Fan: 5 (AUTO), Temp: 23C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BF50;

Mesg Desc.: Power: On, Mode: 1 (DRY), Fan: 0 (AUTO0), Temp: 23C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB21F54;

Mesg Desc.: Power: On, Mode: 3 (HEAT), Fan: 5 (AUTO), Temp: 23C, Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BF5C;

Mesg Desc.: Power: On, Mode: 4 (FAN), Fan: 5 (AUTO), Zone Follow: Off, Sensor Temp: Ignored
uint64_t data = 0xB2BFE4;

[crankyoldgit]

Interesting the FAN setting changes between the different modes while set to FAN AUTO....

Yep. shrug Not how I would have implemented it but the manufacturers probably have their reasons.

[crankyoldgit]

V2.5.6 has just been release which includes the changes/improvements mentioned.