Support for Lennox AC mini-split

[efficks]

I've reversed engeneer the Lennox AC mini-split remote control (https://www.lennox.com/products/heating-cooling/mini-split-systems) and i'm able to made it work on a Raspberry Pi with a Python code that generate pulse/space file for lirc (https://www.lirc.org/). I'm now trying to made it work on a ESP32 and I figured it would be nice to integrate it in this library. I'm not able to figure if the protocol is already supported in the library or not. Also, the Lennox protocol seems really strange and I don't know how to implement it with the current implementation. Is somebody have a tip for me?

I've started documenting the protocol at https://github.com/efficks/lennoxir

1      8 9     16 17    24 25    32 33    40
00000000 00000000 00000000 00000000 00000000
10100001 P0FFFMMM 0100TTTT 11111111 11111111

M : mode, T: temperature, P: power Other bits for swing and other features I'm not using for now I need to send an intro message pulse: 4350, space: 4350 I need to add an 8 bits checksum to this data (I figured out the algorithm) Add a middle message space: 5150, pulse: 4350, space: 4350 Send the same data again with the checksum but with bits reversed (1 become 0 and 0 become 1) And a final message, pulse: 550

A 1 bit is pulse: 550, space: 1550 A 0 bit is pulse: 550, space: 550

Do you have a place I can read, or examples to how to implement this? I've checked code like the Carrier that use sendGeneric functions. But it does not seems to be what I need.

Thank you,

[crankyoldgit]

Our Wiki has some helpful documents for you, have a read of: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol & https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol

If you have the complete list of pulse (mark) and gap (space) timings for a given message, we have tools to help construct the code for sending & decoding the message.

sendGeneric() will probably do what you need. Basic capture/sending is the first step which utilises a routine and a numeric code to represent the low-level message. i.e. the raw 0s and 1s of the message.

Once that is available/done, we add a class to produce & further decode those "basic" messages using higher level things like temperature, operation mode, fan speed, power etc etc.

Have a read of those docs. They will point you in the right direction. There are also some tools in the tools directory to help you see if the library already recognises the protocol, if you supply the timing data to them correctly.

A 1 bit is pulse: 550, space: 1550 A 0 bit is pulse: 550, space: 1550

Um, that's not going to work. I think you may have a mistake/typo. It looks like a 1 and a 0 are exactly the same timing wise.

[efficks]

@crankyoldgit Yes. I've a typo. I'm fixing it right now. Thank you for the hints. I will read everything and try to made it works.

[crankyoldgit]

@crankyoldgit Yes. I've a typo. I'm fixing it right now. Thank you for the hints. I will read everything and try to made it works.

Remember, we are here to help. Get us the data in the right format, and it's a fairly easy process. Especially as you seem to have reverse engineered it all so far.

[normanr]

Check out the Midea protocol. I have some Lennox AC mini-splits and it matches almost 100% (with KAYSUN_AC defined). The remotes I got with them are model RG57A6/BGEFU1 (same as in #1318).

[normanr]

Also I haven't tried, but some Midea units also have an RS232/485 interface, https://community.home-assistant.io/t/support-for-midea-a-c/265236 has (a lot) more information (via https://github.com/kpishere/homie_heatPump/issues/5#issuecomment-929550163).

[efficks]

@normanr , I confirm the Lennox MiniSplit use the Midea protocol. Can I just submit a merge request with this hardware in the protocol list. Or do you want the entire analysis?

[NiKiZe]

Any chance that you can post a capture from IRrecvDumpV3 then that would be great (for the sake of documentation)

But a PR with just the model of unit + remote is fine as well. (one row for the unit + one for remote).

[crankyoldgit]

@efficks Chasing up on this. Have you tried IRrecvDumpV3 or the MIDEA protocol as suggested?

[crankyoldgit]

@efficks Another chase up ping.

[crankyoldgit]

Closing this issue as it appears stale.

[efficks]

@crankyoldgit Sorry for the delay. I will do the PR for the documentation. This is the output for one command :

Timestamp : 002046.073
Library   : v2.8.1    

Protocol  : MIDEA
Code      : 0xA19B46FFFF42 (48 Bits)
Mesg Desc.: Type: 1 (Command), Power: On, Mode: 3 (Heat), Celsius: On, Temp: 23C/73F, On Timer: Off, Off Timer: Off, Fan: 3 (High), Sleep: Off, Swing(V): -, Econo: -, Turbo: -, Quiet: Off, Light: -, Clean: -, 8C Heat: -
uint16_t rawData[199] = {4408, 4322,  578, 1560,  572, 496,  578, 1558,  572, 522,  554, 514,  550, 518,  548, 520,  544, 1566,  574, 1564,  578, 488,  576, 518,  546, 1564,  578, 1584,  546, 496,  580, 1556,  574, 1562,  578, 490,  576, 1562,  578, 488,  576, 492,  574, 520,  544, 1566,  574, 1562,  580, 488,  576, 1560,  570, 1592,  550, 1562,  580, 1582,  548, 1562,  578, 1558,  572, 1590,  550, 1560,  570, 1566,  574, 1562,  580, 1558,  574, 1562,  578, 1558,  572, 1564,  578, 1560,  570, 1566,  576, 518,  546, 1564,  578, 490,  574, 494,  572, 522,  554, 488,  576, 1560,  570, 498,  578, 5128,  4408, 4320,  580, 488,  576, 1560,  572, 496,  578, 1556,  574, 1562,  578, 1558,  572, 1564,  578, 490,  574, 494,  572, 1564,  576, 1560,  570, 496,  578, 490,  576, 1560,  570, 524,  552, 490,  574, 1562,  580, 514,  550, 
1560,  570, 1564,  576, 1560,  572, 496,  578, 488,  576, 1560,  570, 496,  578, 488,  576, 492,  574, 520,  544, 496,  580, 488,  576, 518,  548, 520,  544, 526,  550, 514,  550, 518,  548, 520,  546, 522,  
554, 488,  576, 518,  548, 520,  544, 1564,  576, 492,  574, 1562,  578, 1556,  574, 1562,  578, 1556,  574, 494,  570, 1566,  576};  // MIDEA A19B46FFFF42
uint64_t data = 0xA19B46FFFF42;

Do you need anything else?

[crankyoldgit]

I assume the Mesg Desc is correct for the message? If so, no. We don't need anything else. It looks like the others guessed correctly. It's an MIDEA protocol device

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.8.2 release of the library.