KELON168: Add initial detailed support for Kelon168 (Kelon/Hisense)

[leonardfactory]

Hello, based on the Excel documents shared here #1903, I'm trying to implement a full driver for the Kelon168 protocol (Hisense/Kelon A/C). The protocol seems very similar to Whirlpool A/C, even the remotes share a similar format (DG11R2-01 for Kelon vs DG11J1-91 for Whirlpool).

After some experimentations, I'm sharing here this preliminary version in order to gather feedback, suggestions and to see if my code makes sense (I'm sorry - back to C++ after a very long time).

Right now the send function is working with these features: super, quiet, fan speed, set temperature, mode, power on/off, lights, clock. Timers should be equal as Whirlpool A/C. Swing needs an update.

Things that I'm still working on:

• Swing support
• Checking other codes
• Fix lint & unit tests

Regarding the following points I'm a bit confused:

• Do you have any hint to implement the decoder in a way that it matches correctly? Right now it is very similar to Whirlpool, the only "common" difference is in Byte 18, where bits n.3 & n.5 are always one instead of zero. (see here). Is there any way to use this info to enhance the decoder?
• It seems every command (set temperature, set mode, set fan speed, etc.) are encoded as a full byte individually. But it works even if I just send every time the "Power" command (in the code it's not like this, it is handled by the latest "setXYZ" method called by the end-user, inherited from Whirlpool class): is this ok?
• Should I add unit tests? Not really sure how to test it / what to test, but I'll check other tests
• I left all the code in the ir_Kelon file, is it ok or should we make a ir_Kelon168 / ir_Hisense file?

[NiKiZe]

What differs from whirlpool in terms of timing? Is Kelkon168 a possible conflict? If yes then it should probably be removed, and whirlpool fixed instead.

[leonardfactory]

Hi @NiKiZe , I didn't implement the effective protocol (sendKelon168 and decodeKelon168) - it was already there, implemented by @crankyoldgit in #1745.
I added the struct & the IRKelon168Ac implementation.
Given this, I'm not really sure about the timing differences, and I don't know how to identify this difference. I'd like to ask to @mhp3-10 who worked out the protocol and @crankyoldgit who implemented it.

In case your suspects are confirmed, and those protocol are the same, I can merge everything in the Whirlpool class (is there a way to "alias" the protocol?)

[mp3-10]

@leonardfactory @NiKiZe I didn't save timings provided by IRDecode, so I need do that again ;) I will provide that soon ;)

[Hcreak]

This fork is very useful. It perfectly adapts to my Hisense air conditioner. Why hasn't it been merged yet?

[emcd39]

Why hasn't it beenThis PR has improved the class of the kelon168 protocol. Why hasn't it been merged yet? merged yet? @NiKiZe

[NiKiZe]

Why hasn't it beenThis PR has improved the class of the kelon168 protocol. Why hasn't it been merged yet? merged yet? @NiKiZe

If this Protocol is identical to something that we already have, but needs to have timings adjusted, then it would be much more efficient to adjust the existing protocol.