Support for Vailland / Gree AC

[chkr1011]

Hi,

I recently got an AC installed. The manufacturer is "Vaillant" (German brand, which seems to use Gree devices).

I tested this library and I am able to control the AC when using either Kelvinator or Gree components. But unfortunately not all features are available in this library. I someone able to help me out with the missing stuff? I will provide any information required including dumps etc.

What I know so far:
Device responds to "Kelvinator" and "Gree" commands.
Brand: Vaillant
Model: VAI5-035WNI
Remote Model: YACIFB
Remote: https://www.amazon.de/Calvas-Universal-Electrolux-Klimaanlage-Fernbedienung/dp/B07W7YMCZ4
Manual: https://www.vaillant.de/documents/download/423203

[crankyoldgit]

Hey Christian, Please have a read of https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol
and https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#can-you-reverse-engineer-my-aircon-protocol-for-me

You'll need to work out what bits & bytes correspond to the (new) features you want supported, and how they work.
If you look in the header (*.h) files for those two protocols you'll find a breakdown of what has already been worked out.
e.g.

IRremoteESP8266/src/ir_Gree.h

Lines 36 to 77 in 21e7dd4

	/// Native representation of a Gree A/C message.
	union GreeProtocol{
	uint8_t remote_state[kGreeStateLength]; ///< The state in native IR code form
	struct {
	// Byte 0
	uint8_t Mode :3;
	uint8_t Power :1;
	uint8_t Fan :2;
	uint8_t SwingAuto :1;
	uint8_t Sleep :1;
	// Byte 1
	uint8_t Temp :4;
	uint8_t TimerHalfHr :1;
	uint8_t TimerTensHr :2;
	uint8_t TimerEnabled:1;
	// Byte 2
	uint8_t TimerHours:4;
	uint8_t Turbo :1;
	uint8_t Light :1;
	uint8_t ModelA :1; // model==YAW1F
	uint8_t Xfan :1;
	// Byte 3
	uint8_t :2;
	uint8_t TempExtraDegreeF:1;
	uint8_t UseFahrenheit :1;
	uint8_t unknown1 :4; // value=0b0101
	// Byte 4
	uint8_t Swing:4;
	uint8_t :0;
	// Byte 5
	uint8_t DisplayTemp :2;
	uint8_t IFeel :1;
	uint8_t unknown2 :3; // value = 0b100
	uint8_t WiFi :1;
	uint8_t :0;
	// Byte 6
	uint8_t :8;
	// Byte 7
	uint8_t :4;
	uint8_t Sum:4;
	};
	};

Once you've got that analysis done, we'll write the code if you can't.

In the meantime, I'll update the supported model info you've provided. Thanks!

[NiKiZe]

You should probably start with capturing the existing and original remote to collect the data for your ACs structure, it will also tell you which protocol, if any that is already supporting.

"Testing" which protocol it "responds to" is unreliable at best.

[chkr1011]

Thanks for your reply. I will give it a try and come back when I encounter problems.

[crankyoldgit]

"Testing" which protocol it "responds to" is unreliable at best.

Oh so very true. I forgot to say/recommend that. There are a number of A/Cs that respond to multiple different protocols, but the remote's one is different.

[crankyoldgit]

@chkr1011 How are you going with this?

[chkr1011]

I prepared my hardware (ESP32) and now started reverse engineering. I also have a list what is working so far and now I am playing around with the raw state (changing bits etc.). I also built a receiver for my remote and capturing the raw state.

Current state is: I can basically use the Gree code but things like the "ModelA" are used for the Ion filter instead. I wonder if I should modify the Gree code or better copy it as a new "IRVaillant_AC" class. What do you recomment?

Please do not expect a final result within the next 2-3 weeks. I will let you know when I have more results.

[crankyoldgit]

I wonder if I should modify the Gree code or better copy it as a new "IRVaillant_AC" class. What do you recomment?

That depends on the data and how different it is.
Eg. Is there any way to consistently tell the difference between the two "structures"? Eg. Different bits or bytes that can be used to tell which device/model a message belongs to.
And if there are only a few bits different, I try to combine the two classes/structure. If not, then separate is probably best.

In short, it depends.

[chkr1011]

OK then I will create a pull request which uses a modified Gree class copy as "IRVAillant_AC. Then you can decide how it fits best.

[crankyoldgit]

Looking forward to it

[crankyoldgit]

Friendly ping. How did you go with this?

[chkr1011]

I already found some new bits which I use already. I had some hard times trying to decode the signal from the remote. I tried the code from the samples but unfortunately the receiver gets a lot of noise. So I often have to guess. Do you have a recommendation for me? Should I change tolerance etc.? I also tried a pull-up resistor and capacitor but no success.

Here is a snipped from my C# code. There you can see the new field like "Energy Saver" and "Horizontal Swing". I still need to find more bits. The ! sign means that the purpose of the bit is verified by me. I still need to find how 5 fan levels are managed (1-3 are working already with the existing code).

	// Byte 0 -------------------------------
	bits[0] = true; // Mode 1 !
	bits[1] = false; // Mode 2 !
	bits[2] = false; // Mode 3 !
	bits[3] = true; // Power !
	bits[4] = true; // Fan 1 !
	bits[5] = false; // Fan 2 !
	bits[6] = false; // SwingAuto
	bits[7] = false; // Sleep
	
	// Byte 1 -------------------------------
	bits[8] = true; // Temp !
	bits[9] = true; // Temp !
	bits[10] = true; // Temp !
	bits[11] = false; // Temp !
	bits[12] = false; // TimerHalfHr
	bits[13] = false; // TimerTensHr
	bits[14] = false; // TimerTensHr
	bits[15] = false; // TimerEnabled
	
	// Byte 2 -------------------------------
	bits[16] = false; // TimerHours
	bits[17] = false; // TimerHours
	bits[18] = false; // TimerHours
	bits[19] = false; // TimerHours
	bits[20] = false; // Turbo !
	bits[21] = true; // Light !
	bits[22] = true; // ION filter?
	bits[23] = false; // XFan ?
	
	// Byte 3 -------------------------------
	bits[24] = false;
	bits[25] = false;
	bits[26] = false; // TempExtraDegreeF
	bits[27] = false; // UseFahrenheit !
	
	bits[28] = true; // MUST BE TRUE !
	bits[29] = false; // MUST BE FALSE !
	bits[30] = true; // MUST BE TRUE !
	bits[31] = false; // MUST BE FALSE !
	
	// Byte 4 -------------------------------
	bits[32] = false; // SwingV !
	bits[33] = false; // SwingV !
	bits[34] = false; // SwingV !
	bits[35] = false; // SwingV !
	
	// 0 = Off, 1 = LtR, 2 = L, 3 = L+, 4 = C, 5 = R+, 6 = R
        // L = Left, C = Center, R = Right, LtR = Left to Right Auto mode.
	bits[36] = false; // SwingH !
	bits[37] = false; // SwingH !
	bits[38] = false; // SwingH !
	bits[39] = false; // SwingH !

	// Byte 5 -------------------------------
	bits[40] = false; // DisplayTemp !
	bits[41] = false; // DisplayTemp !
	bits[42] = false; // IFeel
	bits[43] = false;
	bits[44] = false;
	bits[45] = false;
	bits[46] = false; // WiFi SwingV?
	bits[47] = false; // MUST BE FALSE!

	// Byte 6 -------------------------------
	bits[48] = false; // SwingV?
	bits[49] = false; // SwingV?
	bits[50] = false;
	bits[51] = false;
	bits[52] = false; // SwingV?
	bits[53] = false;
	bits[54] = false; // SwingV?
	bits[55] = false;

	// Byte 7 -------------------------------
	bits[56] = false;
	bits[57] = false;
	bits[58] = false; // Energy Saver !
	bits[59] = false;
	bits[60] = false; // SUM !
	bits[61] = false; // SUM !
	bits[62] = false; // SUM !
	bits[63] = false; // SUM !

[crankyoldgit]

bits[0] = true; // Mode 1 !
bits[1] = false; // Mode 2 !
bits[2] = false; // Mode 3 !

Are the modes the same as existing models?

bits[40] = false; // DisplayTemp !
bits[41] = false; // DisplayTemp !

What are the values for this, and what do they do?

// 0 = Off, 1 = LtR, 2 = L, 3 = L+, 4 = C, 5 = R+, 6 = R

What does L+ and R+ mean?

General:
I'll need some test data (states) with descriptions so I can verify my code etc. eg. is it handling swingh correctly

For capture issue, have you tried everything in the troubleshooting guide?

[chkr1011]

Are the modes the same as existing models?

Yes they are the same.

What are the values for this, and what do they do?

They are controlling the display at the wall mounted device. They are already implemented in the "Gree" class properly. Values are the same.

What does L+ and R+ mean?

L+ = Between left and center position. Something in between.
R+ = Between center and right position.
My remote basically has 5 possible positions, off and auto mode (which will move from very left to very right and backwards).

For capture issue, have you tried everything in the troubleshooting guide?

Basically yes. It seems that I have a bad device. I will try to tweak some values and order some alternative IR receivers.

[crankyoldgit]

@chkr1011 I've created branch https://github.com/crankyoldgit/IRremoteESP8266/tree/Vailland / PR #1653 that should add the SwingH & Econo settings you've documented. Can you please download that branch, test it out, and let me know what works and doesn't etc?

[chkr1011]

Sure thing...

[crankyoldgit]

Any luck/results?

[chkr1011]

Sorry I had no time yet to proceeded. I hopefully get some time this weekend. Sorry for the delay.

[crankyoldgit]

Merging the PR based on no feedback/confirmation. We can change it later.

[crankyoldgit]

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

[crankyoldgit]

Closing this due to no response or update.

[chkr1011]

@crankyoldgit I finally had some time testing your changes. They look good from API declaration perspective but I have one issue.

The swing states are combined with a automatic mode for vertical swing (setSwingVertical). The modes are either fixed positions OR automatic. There is no way to combine auto mode with a position. I have to choose either a position OR full auto mode. My remote shows that I am able to active a mode like "automatic and moving from top to center only" but my device only moves the full range regardless of the state shown at the remote.

Also the "ModelA" feature must be removed completely because this flag is used for the ion filter (which I still need to verify but unfortunately my device has no icon for this. Only the remote shows if it is active and while reverse engineering the received data I seems that my assumption is correct.). I am wondering if the "ModelA" detection is required due to this comment: " // May not be needed. See #814".

[crankyoldgit]

Can you please supply some captures using IRrecvDumpV2 or V3 etc and document what each state is meant to be etc. for all the situations where you think it behaving badly. I need this so I can make tests and check for certain what bits do what.

I've reviewed #814 and this issue again, and I notice I'm not getting a lot of ground-truth data from our tools, so I'm not sure what to trust.

[chkr1011]

I will collect some sample data within the next days and share it here.

[crankyoldgit]

I will collect some sample data within the next days and share it here.

Friendly chase up for this data. It's been three weeks.

[crankyoldgit]

@chkr1011 Another chase up ping.

[crankyoldgit]

@chkr1011 Another chase up ping. It's getting close to two months. If we dont hear from you soon, we will close this issue.

[chkr1011]

I will close the ticket because I do not have the required hardware yet and not much time to work on this ticket. The current integration works currently fine for me. Maybe I will come back to this issue in several month.