Voltas AC Remote IR Mapping

[manj9501]

Hola @crankyoldgit et al.
I have put in a day's work to try and reverse engineer my AC's IR Remote mapping and after necessary following the steps given in the two wiki articles explaining how to do so, I've come up with the following results:

Voltas AC map (Model no: 122LZF 4011252 Window AC)
(MSBF)
  
byte 0 
        b0 = Horizontal Swing(1 = On, 0 = Off) (Works with all Basic Modes) (not compatible with my AC)
	b7-1 = UNKNOWN, typically 0b1111100
	(Becomes Don't Care with value 0b00110011(0x33) if any other parameter is changed, reason unknown)

byte 1
	b3-0 = Basic Modes
                1000 (8) = Chill 
                0100 (4) = Dry (fixed Fan speed(Low), fixed Temperature(24C))
                0010 (2) = Cool
		0001 (1) = Fan	(Fixed fan speed(Hi), Temperature = Cool mode temperature)
	b4 = UNKNOWN, typically 0
	b7-5 = Fan speed
		100 (1) = Low
		010 (2) = Mid
		001 (4) = Hi
		111 (7) = Auto
		
byte 2
	b2-0 = Vertical Swing (Works with all Basic Modes)
		000 (1) = Off
		111 (7) = On
	b3 = WiFi bit(Toggles between 0 and 1 upon pressing the button labelled 'WiFi') (not compatible with my AC)
	b4 = UNKNOWN, typically 0
	b5 = Turbo mode(1 = On, 0 = Off) (Works only with Chill mode)
	b6 = Sleep mode(1 = On, 0 = Off) (Works only with Chill mode)
	b7 = Power Status(1 = On, 0 = Off)
	
byte 3
       b3-0 =  Temperature
		0000 (0) = 16C
		0001 (1) = 17C
		0010 (2) = 18C
		...
		1101 (13) = 29C
		1110 (14) = 30C
	b5-4 = UNKNOWN, typically 0b01
	b6 = Energy Saver mode (1 = On, 0 = Off) (Works only with Chill mode)
	b7 = TEMP bit, goes HIGH for a few seconds upon pressing TEMP button, then changes back to LOW automatically and remote sends the message(not compatible with my AC)
	
 byte 4 
	b0 = Timer 24 Hr. bit (Works for both On and Off timer)
		0 = Time is 24 Hr.
		1 = Otherwise
	b6-1 = UNKNOWN, typically 0b011101
        b7 = On Timer 12+(byte 7 lower nibble) bit (works in conjuction with byte 7)
		0 = On Time is 24 Hr or Time < 12 Hrs. 
		1 = On Time =>12 Hr.
	
byte 5
       b0 = Timer 24 Hr. bit (Works for both On and Off timer)
		0 = Time is 24 Hr.
		1 = Otherwise
	b6-1 = UNKNOWN, typically 0b011101
	b7 = Off timer 12+(byte 7 upper nibble) bit (works in conjuction with byte 7)
		0 = Off Time is 24 Hr or Off Time < 12 Hrs. 
		1 = Off Time =>12 Hr.
		
byte 6 = UNKNOWN, typically 0b00111011(0x3B)

byte 7 
	b3-0 = On Timer bits (works in conjuction with byte 4)
		0000 (0) = 12 Hr. / 24Hr.
		0001 (1) = 1 Hr. / 13Hr.
		0010 (2) = 2 Hr. / 14Hr.
		...
		1010 (10) = 10 Hr. / 22Hr.
		1011 (11) = 11 Hr. / 23Hr.
	b7-4 = Off Timer bits (works in conjuction with byte 5)
		0000 (0) = 12 Hr. / 24Hr.
		0001 (1) = 1 Hr. / 13Hr.
		0010 (2) = 2 Hr. / 14Hr.
		...
		1010 (10) = 10 Hr. / 22Hr.
		1011 (11) = 11 Hr. / 23Hr.
		
byte 8
	b4-0 = UNKNOWN, typically 0b00000
	b5 = Lamp bit(1 = On, 0 = Off) (not compatible with my AC)
	b6 = Off Timer status (1 = Activated, 0 = Deactivated)
	b7 = On Timer status (1 = Activated, 0 = Deactivated)
        (On Timer can only be activated when the AC has been powered OFF from the remote, Off Timer can only be activated when the AC has been powered ON from the remote,)
	
byte 9 = Check byte
	Calcuted using the following formula:
	checksum = ~(Sum of all preceding bytes)&0xFF

My setup is a NodeMCU connected to an IR receiver I salvaged from a digital photo frame.

A few of the IRrecvDumpV3 outputs after modifying the library are given below:

1. Dry Mode, No Swing, No Lamp, No Timer

Library   : v2.7.9

Protocol  : VOLTAS
Code      : 0x338488183B3B3B1100E6 (80 Bits)
uint16_t rawData[161] = {1002, 584,  1000, 586,  1000, 2568,  1002, 2570,  1002, 586,  998, 588,  1000, 2568,  1002, 2570,  1002, 2572,  1002, 584,  1002, 586,  1000, 584,  1000, 586,  1002, 2568,  1004, 584,  1000, 586,  1002, 2568,  1002, 584,  1002, 584,  1004, 584,  1000, 2568,  1002, 586,  1000, 586,  998, 590,  998, 584,  1002, 584,  1000, 586,  1000, 2570,  1002, 2568,  1004, 584,  1000, 584,  1002, 584,  1002, 582,  1004, 584,  1002, 2568,  1002, 2570,  1004, 2570,  1000, 586,  1002, 2568,  1004, 2568,  1006, 584,  1000, 584,  1002, 2568,  1002, 2570,  1002, 2568,  1002, 586,  1002, 2570,  1000, 2570,  1002, 588,  998, 586,  1000, 2568,  1004, 2568,  1004, 2568,  1002, 588,  998, 2570,  1002, 2568,  1004, 586,  1002, 584,  1000, 586,  1000, 2570,  1000, 586,  1000, 584,  1002, 586,  1000, 2568,  1004, 584,  1000, 586,  1000, 586,  1002, 584,  1002, 586,  1000, 586,  1000, 586,  1000, 586,  1000, 2568,  1002, 2568,  1002, 2568,  1004, 586,  1000, 584,  1000, 2570,  1004, 2568,  1004, 584,  1002};  // VOLTAS
uint8_t state[10] = {0x33, 0x84, 0x88, 0x18, 0x3B, 0x3B, 0x3B, 0x11, 0x00, 0xE6};

2. Chill mode(24C), no swing, Fan Auto, Turbo ON, No Timer, No lamp

Library   : v2.7.9

Protocol  : VOLTAS
Code      : 0x33E8A8183B3B3B110062 (80 Bits)
uint16_t rawData[161] = {1014, 574,  1012, 574,  1012, 2558,  1014, 2558,  1014, 574,  1014, 574,  1012, 2558,  1014, 2558,  1014, 2558,  1014, 2558,  1014, 2556,  1014, 574,  1012, 2558,  1014, 574,  1012, 574,  1012, 574,  1012, 2558,  1014, 572,  1014, 2558,  1014, 574,  1010, 2558,  1014, 574,  1012, 574,  1012, 574,  1012, 574,  1012, 572,  1014, 572,  1012, 2558,  1014, 2556,  1014, 572,  1036, 550,  1036, 550,  1012, 574,  1012, 576,  1010, 2556,  1038, 2534,  1038, 2534,  1016, 572,  1038, 2530,  1014, 2558,  1038, 548,  1012, 574,  1034, 2534,  1016, 2556,  1038, 2534,  1014, 574,  1012, 2558,  1014, 2558,  1014, 574,  1012, 572,  1012, 2558,  1014, 2556,  1014, 2558,  1014, 574,  1012, 2556,  1038, 2534,  1014, 572,  1012, 574,  1012, 574,  1036, 2534,  1012, 574,  1012, 574,  1012, 574,  1036, 2532,  1016, 572,  1014, 572,  1012, 574,  1012, 574,  1012, 572,  1014, 572,  1012, 574,  1012, 572,  1012, 574,  1012, 2556,  1014, 2556,  1014, 574,  1010, 574,  1012, 574,  1012, 2558,  1014, 572,  1014};  // VOLTAS
uint8_t state[10] = {0x33, 0xE8, 0xA8, 0x18, 0x3B, 0x3B, 0x3B, 0x11, 0x00, 0x62};

Also I've built an IR sender circuit and can confirm that the AC is responding to the change in parameters, with the correct checksum only.

Can you please confirm if I'm on the right path, so I can proceed towards the coding part, which admittedly, doesn't happen to be my strongest suit.

Voltas Remote pic:

[crankyoldgit]

Can you please confirm if I'm on the right path, so I can proceed towards the coding part, which admittedly, doesn't happen to be my strongest suit.

Yes, it looks like you're on the correct path. Given you've got a steadily increasing value for the temp in Byte 3, I'd say you've got the bit ordering correct. So, congrats! You're well on the way to having this all figured out, or already have enough to make it completely usable.

Feel free to submit a PR with what you've got so far and we can work on getting it as supported as we can.
As I say in the wiki/faq etc, if you do the decoding/reverse engineering of the protocol, I'll typically do the coding for you.
It looks like you've worked out enough of the protocol (inc the all-important checksum) that we can add support for it fairly simply. However, if you want to do the coding, feel free, I won't stop you. ;-)

Things I'll ask in advance:

1. What is the model number of the remote (if any)?
2. Is there a heat mode on the remote? (if so, what code does it produce)
3. Re: Byte[0], does "any other parameter is changed" apply to the entire IR message, or just Byte[0]?
4. In your notation/description, is b0 the LEAST significant bit, or the MOST?
5. Re: Byte[3] b7, does the unit still change the temp if a message has a different temp & b7 is 0? i.e. do we have to have this flagged if we change the temp? And how does the unit behave if it was always 1?
6. Re: Byte[4 & 5], b0, Can you elaborate on what you mean here? It isn't immediately obvious.

[manj9501]

1. What is the model number of the remote (if any)?

I've probably misplaced the manual for this AC, so I can't really help you with the model number of the remote right now.

2. Is there a heat mode on the remote? (if so, what code does it produce)

No, there is no such mode on the remote.

3. Re: Byte[0], does "any other parameter is changed" apply to the entire IR message, or just Byte[0]?

It applies to the entire IR message. Peculiar behavior!

4. In your notation/description, is b0 the LEAST significant bit, or the MOST?

b0 is the LSB.

5. Re: Byte[3] b7, does the unit still change the temp if a message has a different temp & b7 is 0? i.e. do we have to have this flagged if we change the temp? And how does the unit behave if it was always 1?

If we press the TEMP button, Byte[3] b7 is SET but when we change the temperature on the remote, before letting Byte[3] b7 return to RESET, the remote sends Byte[3] with this flag RESET.
Also I did some research on this TEMP function. It has to do with temperature display on the AC unit showing the ambient temperature for 5 secs before coming back to showing the temperature set using the remote. But as I mentioned, my AC is a rather dumb one and it doesn't show ambient temperature.
So, I suppose it'll take some more research for me to properly answer this question.

6. Re: Byte[4 & 5], b0, Can you elaborate on what you mean here? It isn't immediately obvious.

Following table may make it clear:

Also, there's something I wanna add w.r.t. the OFF Timer functionality. The time bits will always be according to the time that was there on the remote before the OFF Timer is deactivated.
Say, the OFF Timer was previously activated and was set to 13 hours. After a while, we deactivated the OFF Timer with the remote still showing 13 hours. Now the time signature that will be sent with each command will be of 13 hours, even though the OFF Timer bit is RESET.

[manj9501]

Coming back to Byte[3] b7, I did some testing by modifying the IRsendDemo.
I hard coded this bit to SET and played around with the temperature bits.
What I noticed was that the temperature was definitely being updated on my AC unit, despite the bit being SET all the time.

[crankyoldgit]

I've probably misplaced the manual for this AC, so I can't really help you with the model number of the remote right now.

No worries. If there isn't one printed on the remote (sometimes in the battery compartment) then we will just do without. ;-)

[manj9501]

I've looked in the battery compartment too, though without any breakthroughs.
Once I lay my hands on the manual and the remote model no. does happen to be there, I'll definitely revert back.

Plus, I hope I was able to clear your previous doubts with regards to the state mapping.

[crankyoldgit]

I've looked in the battery compartment too, though without any breakthroughs.
Once I lay my hands on the manual and the remote model no. does happen to be there, I'll definitely revert back.

No rush & not urgent.

Plus, I hope I was able to clear your previous doubts with regards to the state mapping.

Yep. All good. I won't know more till I start coding. Speaking of which, can you please send what you've got working so far? Preferably in the form of a Pull Request (PR). Once I have it I'll start working on it.

[crankyoldgit]

Now I've cleaned up & merged your PR, I'll start on the detailed support for the protocol.

[crankyoldgit]

@manj9501 I'm adding detailed support in branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/detailed_voltas
Feel free to follow along & download + test while I add to it. It's far from finished at the moment, so don't expect much.

[manj9501]

Feel free to follow along & download + test while I add to it.

Yes, doing it now!