Great library!

[CalinBunea]

Hello,
First of all I would like to donate at least a coffee for this library. If you have a link for donations please do share it.

A friend of mine asked me to create some modules which will measure the PV production (during the winter), and if there is electricity produced by the panels, to turn on the AirConditioner in heat mode. I was thinking to simply clone the IR Remote control in order to perform the job. I bought few different TSOPxxx38 (38 Khz) IR receivers and started to record the data received from RC. Odd enough, the bytes I received are not always exactly the same. Every byte here and there is slightly different. For example, out of 15 reads the byte number ~8 had in 6 cases the value 0x13 in other 5 cases 0x15 and in other 4 case 0x11 and other value whatsoever. This situation was valid for multiple bytes so it was impossible to make all combinations or to extract the "dominant" values. 90% of the bytes were always the same but still the other 10% was bothering me.... At some point I also tried to send the bytes that I received but I knew there might be all kind of problems on the sender side as well like unappropriated LED light length, or LED too far away from the unit etc. So I haven't invested yet time in the transmission part since the readings were not consistent.

I have tested for 2 full days all kind of libraries, replaced the TSOP receivers and so on, until I tested this library as well. This library has identified the so called "COOLIX" protocol and it decoded the temperature sent from remote control together with mode (heating) and fan speed (auto). An interesting aspect is the fact that using this library I can still see the same problem with some bytes not being the same even when exactly the same parameters are sent from the remote control. I still don't get it why is happening...

Anyway, I moved straight to using the IR Coolix sender class utility together with an IR LED. Initially it didn't worked because I used a direct GPIO from ESP board so the total power of the LED was quite low and given the distance from my desk to the AC unit, it seems that it was too far away to do the job. I took the LED closer to the AC unit (like 100 cm) and it worked. I avoid to give more power to the LED because being an infrared light(which the human eye cannot see) I thought it might be dangerous for my eyes if I would use a powerful LED. To be honest, I have no idea which values are safe or not. My LED can sustain 87 mW power... I would probably want to increase the range from 1 meter to 2-3 meters but no more than that. I would appreciate if somebody can provide me a value which is safe.

Anyway, really great work!
Out of curiosity do you know why the bytes received from the remote control are slightly different here and there but seems to be valid (at least the library can recognize the protocol and the parameters sent by the remote control)?
Oh, and please don't forget the link for donation :).

[NiKiZe]

There is no (known) unsafe power levels of IR LEDs, follow the wiki and add a transistor. I would go for 2 LEDs in series with a transistor or mosfet for driving from 5v rail (but do check your datasheets)

Could there be a temp sensor in the remote? Maybe some unknown feature.

Do you have exact model of remote and AC unit?

[crankyoldgit]

You can see what the bits of the "hex" protocol map to here:

IRremoteESP8266/src/ir_Coolix.h

Lines 100 to 112 in a295f87

	struct { // Only 24 bits are used.
	// Byte
	uint32_t :1; // Unknown
	uint32_t ZoneFollow1:1; ///< Control bit for Zone Follow mode.
	uint32_t Mode :2; ///< Operation mode.
	uint32_t Temp :4; ///< Desired temperature (Celsius)
	// Byte
	uint32_t SensorTemp :5; ///< The temperature sensor in the IR remote.
	uint32_t Fan :3; ///< Fan speed
	// Byte
	uint32_t :3; // Unknown
	uint32_t ZoneFollow2:1; ///< Additional control bit for Zone Follow mode.
	uint32_t :4; ///< Fixed value 0b1011 / 0xB.

It is most likely the temp sensor in the remote.

Note: If you are looking at the protocol via some other method than our library, you need to understand the protocol is really only 24 bits long. However when looking at the raw signal, it will appear 48 bits long, as it sends the first 8 bits normal, then the same 8 bits inverted, then proceeds to the next 8 bits etc ...

[CalinBunea]

Thank you for explanations. I will investigate one day what are those bytes which are slightly different. If is the temperature, it makes sense. Unfortunately I have too many things to work on and for now I don't have time to investigate...
I will get back to this project when I will implement a generic AC commands module.