Voltas AC Remote IR Mapping #1238

manj9501 · 2020-08-14T11:49:48Z

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:

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};

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:

The text was updated successfully, but these errors were encountered:

crankyoldgit · 2020-08-14T12:52:09Z

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:

What is the model number of the remote (if any)?
Is there a heat mode on the remote? (if so, what code does it produce)
Re: Byte[0], does "any other parameter is changed" apply to the entire IR message, or just Byte[0]?
In your notation/description, is b0 the LEAST significant bit, or the MOST?
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?
Re: Byte[4 & 5], b0, Can you elaborate on what you mean here? It isn't immediately obvious.

manj9501 · 2020-08-14T14:50:37Z

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.

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

No, there is no such mode on the remote.

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!

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

b0 is the LSB.

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.

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 · 2020-08-14T15:23:05Z

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 · 2020-08-15T08:40:55Z

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 · 2020-08-15T10:24:20Z

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 · 2020-08-16T04:17:41Z

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.

* Basic send/decode for the Voltas A/C protocol. * Unit test coverage for above. These are all the changes I made on my end so far, to make the library capable of sending and recognizing the various states (as bytes) of the Voltas protocol. User-friendly functions for sending and decoding are yet to be implemented. Ref #1238 Co-authored-by: David <[email protected]>

crankyoldgit · 2020-08-16T11:47:52Z

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

* Checksum support. * Power, toString, toCommon, set/GetRaw etc. For #1238

crankyoldgit · 2020-08-16T14:16:20Z

@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 · 2020-08-16T14:25:01Z

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

Yes, doing it now!

manj9501 · 2020-08-16T15:14:05Z

No sooner did I upload the IRrecvDumpV3 example from detailed_voltas branch on to my NodeMCU setup than I discovered the significance of the 'don't expect much' part of your statement.

I encountered a rapidly, repeatedly crashing NodeMCU with the following Serial Log:

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3584, room 16 
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
~ld

User exception (panic/abort/assert)
--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Panic IRrecvDumpV3.ino:131 void setup(): Assertion 'irutils::lowLevelSanityCheck()' failed.

>>>stack>>>

ctx: cont
sp: 3fffff30 end: 3fffffc0 offset: 0000
3fffff30:  0000001c 0001c200 00000000 00000000  
3fffff40:  000000fe 00000000 00000000 00000000  
3fffff50:  00000000 00000000 00000000 4024fa30  
3fffff60:  3ffeee94 00000000 3ffeed38 3ffeee54  
3fffff70:  3fffdad0 00000000 3ffeed38 40216f36  
3fffff80:  0001c200 0000001c 00000002 40216f6a  
3fffff90:  12345678 00000000 3ffeed38 40201070  
3fffffa0:  feefeffe feefeffe 3ffeee14 40216af0  
3fffffb0:  feefeffe feefeffe 3ffe84e4 40100f79  
<<<stack<<<

crankyoldgit · 2020-08-16T20:40:03Z

Bugger. Please comment out the assert line at IRrecvDumpV3.ino:131 and try again.

Ref: #1238 (comment) X-Ref: #1232 Fixes #1244

manj9501 · 2020-08-16T21:17:12Z

Commenting that line out definitely helped and I can confirm that the basic functionality is working as expected.

Attaching some samples of the decoded signals below:

Protocol : VOLTAS
Code : 0x3328A01C08083B41005C (80 Bits)
Mesg Desc.: Power: On, Turbo: On, WiFi: Off, Light: Off
uint16_t rawData[161] = {1014, 574, 1012, 574, 1012, 2556, 1036, 2534, 1038, 548, 1012, 574, 1012, 2558, 1014, 2556, 1014, 574, 1012, 574, 1012, 2558, 1014, 574, 1012, 2558, 1014, 574, 1012, 574, 1012, 572, 1012, 2556, 1014, 574, 1036, 2534, 1014, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1014, 2556, 1038, 2534, 1014, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1014, 574, 1012, 574, 1010, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1014, 574, 1012, 574, 1012, 572, 1012, 574, 1012, 574, 1012, 2558, 1012, 2558, 1014, 2558, 1014, 572, 1012, 2558, 1014, 2558, 1012, 574, 1012, 2558, 1014, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 2556, 1014, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1014, 572, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1012, 574, 1012, 2558, 1012, 2558, 1012, 2558, 1014, 574, 1038, 550, 1010}; // VOLTAS
uint8_t state[10] = {0x33, 0x28, 0xA0, 0x1C, 0x08, 0x08, 0x3B, 0x41, 0x00, 0x5C};

Timestamp : 000066.157
Library : v2.7.9

Protocol : VOLTAS
Code : 0x3328A81C08083B410054 (80 Bits)
Mesg Desc.: Power: On, Turbo: On, WiFi: On, Light: Off
uint16_t rawData[161] = {1012, 576, 1012, 572, 1014, 2558, 1012, 2558, 1014, 574, 1012, 576, 1010, 2558, 1014, 2558, 1012, 576, 1010, 574, 1012, 2558, 1014, 574, 1012, 2558, 1014, 574, 1010, 574, 1012, 574, 1010, 2558, 1014, 574, 1012, 2558, 1038, 550, 1010, 2558, 1014, 574, 1012, 574, 1012, 574, 1010, 574, 1012, 574, 1012, 574, 1036, 2534, 1014, 2558, 1012, 2558, 1014, 574, 1010, 574, 1012, 574, 1010, 574, 1010, 576, 1012, 574, 1010, 2558, 1014, 574, 1012, 576, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1010, 574, 1012, 2558, 1036, 550, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1012, 2558, 1014, 2560, 1036, 550, 1036, 2534, 1012, 2558, 1012, 576, 1010, 2558, 1036, 552, 1012, 574, 1010, 574, 1012, 574, 1012, 574, 1012, 2558, 1012, 574, 1010, 574, 1010, 574, 1010, 576, 1010, 574, 1010, 574, 1036, 550, 1012, 574, 1010, 574, 1012, 2558, 1012, 574, 1012, 2556, 1012, 576, 1010, 2558, 1012, 576, 1010, 574, 1012}; // VOLTAS
uint8_t state[10] = {0x33, 0x28, 0xA8, 0x1C, 0x08, 0x08, 0x3B, 0x41, 0x00, 0x54};

Timestamp : 000067.093
Library : v2.7.9

Protocol : VOLTAS
Code : 0x3328881C08083B410074 (80 Bits)
Mesg Desc.: Power: On, Turbo: Off, WiFi: On, Light: Off
uint16_t rawData[161] = {1012, 576, 1010, 574, 1012, 2558, 1012, 2558, 1034, 552, 1010, 574, 1012, 2558, 1012, 2558, 1012, 574, 1012, 574, 1036, 2534, 1014, 574, 1010, 2558, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1036, 550, 1010, 574, 1010, 574, 1034, 2534, 1014, 574, 1010, 574, 1010, 574, 1012, 574, 1010, 574, 1012, 574, 1010, 2558, 1014, 2558, 1012, 2558, 1012, 574, 1010, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1010, 2558, 1014, 574, 1010, 576, 1010, 574, 1010, 574, 1010, 574, 1010, 576, 1010, 574, 1012, 2558, 1014, 574, 1012, 574, 1010, 574, 1010, 574, 1012, 574, 1010, 2558, 1012, 2558, 1012, 2558, 1014, 574, 1012, 2558, 1012, 2558, 1012, 574, 1012, 2558, 1014, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1012, 574, 1012, 574, 1012, 574, 1012, 572, 1012, 574, 1012, 574, 1010, 574, 1012, 574, 1010, 574, 1012, 2558, 1012, 2558, 1012, 2556, 1014, 574, 1010, 2560, 1012, 574, 1012, 574, 1012}; // VOLTAS
uint8_t state[10] = {0x33, 0x28, 0x88, 0x1C, 0x08, 0x08, 0x3B, 0x41, 0x00, 0x74};

Timestamp : 000075.465
Library : v2.7.9

Protocol : VOLTAS
Code : 0x3328801C08083B41007C (80 Bits)
Mesg Desc.: Power: On, Turbo: Off, WiFi: Off, Light: Off
uint16_t rawData[161] = {1014, 574, 1012, 574, 1012, 2556, 1014, 2556, 1014, 574, 1036, 548, 1012, 2558, 1038, 2534, 1014, 572, 1034, 552, 1010, 2558, 1014, 574, 1014, 2556, 1014, 574, 1012, 574, 1012, 572, 1012, 2558, 1014, 572, 1014, 572, 1012, 574, 1012, 574, 1012, 572, 1012, 574, 1010, 574, 1036, 550, 1012, 572, 1012, 574, 1012, 2556, 1014, 2556, 1038, 2532, 1012, 574, 1012, 572, 1038, 550, 1010, 574, 1012, 574, 1012, 574, 1012, 2556, 1012, 574, 1012, 574, 1034, 552, 1010, 574, 1038, 548, 1012, 574, 1036, 550, 1036, 2534, 1012, 574, 1036, 550, 1012, 574, 1012, 574, 1012, 574, 1010, 2558, 1038, 2534, 1012, 2556, 1040, 548, 1038, 2532, 1014, 2558, 1014, 574, 1012, 2558, 1014, 572, 1012, 574, 1038, 550, 1012, 572, 1012, 574, 1012, 2556, 1040, 548, 1038, 548, 1014, 572, 1014, 574, 1012, 574, 1012, 574, 1012, 574, 1036, 550, 1010, 574, 1038, 2532, 1038, 2532, 1016, 2556, 1014, 2558, 1014, 2558, 1014, 572, 1014, 572, 1012}; // VOLTAS
uint8_t state[10] = {0x33, 0x28, 0x80, 0x1C, 0x08, 0x08, 0x3B, 0x41, 0x00, 0x7C};

Timestamp : 000080.964
Library : v2.7.9

Protocol : VOLTAS
Code : 0x3328001C08083B4100FC (80 Bits)
Mesg Desc.: Power: Off, Turbo: Off, WiFi: Off, Light: Off
uint16_t rawData[161] = {1012, 574, 1012, 574, 1012, 2558, 1036, 2534, 1014, 572, 1012, 574, 1010, 2556, 1038, 2534, 1014, 574, 1012, 572, 1012, 2558, 1038, 548, 1012, 2556, 1016, 572, 1012, 574, 1012, 574, 1012, 572, 1012, 574, 1012, 574, 1036, 548, 1038, 550, 1036, 550, 1034, 550, 1012, 574, 1036, 550, 1012, 574, 1012, 574, 1012, 2556, 1014, 2558, 1038, 2534, 1014, 574, 1010, 574, 1012, 572, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1014, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 574, 1012, 2556, 1014, 572, 1012, 574, 1012, 574, 1038, 550, 1012, 572, 1012, 2558, 1038, 2532, 1014, 2558, 1014, 574, 1012, 2556, 1038, 2532, 1014, 572, 1012, 2558, 1038, 550, 1012, 574, 1012, 574, 1012, 574, 1038, 548, 1038, 2530, 1014, 574, 1012, 574, 1036, 550, 1012, 574, 1012, 572, 1012, 574, 1012, 574, 1012, 574, 1012, 2558, 1014, 2558, 1012, 2558, 1014, 2556, 1014, 2558, 1014, 2558, 1014, 572, 1012, 574, 1010}; // VOLTAS
uint8_t state[10] = {0x33, 0x28, 0x00, 0x1C, 0x08, 0x08, 0x3B, 0x41, 0x00, 0xFC};

crankyoldgit · 2020-08-16T21:25:23Z

Let me know if the descriptions don't match at any time.
Thanks for confirming.
Sorry about the bug.

manj9501 · 2020-08-16T21:33:51Z

Sure, I'll keep you updated!
Also, I tested the bugfix of PR #1245, it makes things hunky-dory again!

Ref: #1238 (comment) X-Ref: #1232 Fixes #1244

crankyoldgit · 2020-08-16T23:58:22Z

Also, I tested the bugfix of PR #1245, it makes things hunky-dory again!

Thanks for confirming!

* Checksum support. * Power, toString, toCommon, set/GetRaw etc. For #1238

crankyoldgit · 2020-08-17T04:15:07Z

@manj9501 What's the difference between "Chill" and "Cool" operation modes?
Normally we have Auto, Cool, Heat, Dry, & Fan as the typical modes.

manj9501 · 2020-08-17T04:53:55Z

Turns out I was wrong! I did some research and well, the mode I've mistaken for 'Cool' all this while is actually the Heat mode. My bad!
Guess I should have looked for the manual before embarking on this journey.
Also, since my place gets plenty hot every summer season, it was kind of hard for me to see why anybody here would need a Heat mode.
I made this mistake even though Heat mode has a Sun as its icon, how so parochial of me!
I wanna reiterate that Heat mode is just the Chill mode without the Turbo, Energy Saver and Sleep functionalities.

crankyoldgit · 2020-08-17T04:58:41Z

So, are these values correct then for the modes?

const uint8_t kVoltasFan   = 0b0001;  ///< 1
const uint8_t kVoltasHeat  = 0b0010;  ///< 2
const uint8_t kVoltasDry   = 0b0100;  ///< 4
const uint8_t kVoltasCool  = 0b1000;  ///< 8

manj9501 · 2020-08-17T05:01:18Z

Yes, these are the right values.

manj9501 · 2020-08-25T12:58:59Z

Bizarre system, but hey, we've worked it out together. That's all that matters.

Yes, thanks for keeping me busy with the investigation ;-)

So, with that I think that's everything working/done. Correct?

Correct!
Just last few rounds of testing and I think it'll be good to go hopefully!

manj9501 · 2020-08-25T20:29:01Z

I don't know if it's worth mentioning or not, but I've noticed that Turbo mode disables the Fan Speed option, i.e. whatever fan speed was set when Turbo mode was activated, it'll remain so until and unless the Turbo mode is deactivated.

I've tested the setOnTime() and setOffTime() functions using various time values and the AC behaved as expected.

I've one question though. There is the Dry mode with constraints(24C, Low Fan) and the Econo option in the Cool mode with constraints(24C, Med Fan).
Can we associate their respective constraints as default values of Temperature and Fan Speed, which override the reset state Temperature and Fan Speed values and even the Temperature and Fan Speed values that may have been explicitly specified in the code using setTemp() and setFan()?
e.g. if setEcono(true) is used, the Temperature sent must always be 24C and Fan Speed sent must always be Med.

NiKiZe · 2020-08-25T21:52:53Z

I don't know if it's worth mentioning or not, but I've noticed that Turbo mode disables the Fan Speed option, i.e. whatever fan speed was set when Turbo mode was activated, it'll remain so until and unless the Turbo mode is deactivated.

I've tested the setOnTime() and setOffTime() functions using various time values and the AC behaved as expected.

I've one question though. There is the Dry mode with constraints(24C, Low Fan) and the Econo option in the Cool mode with constraints(24C, Med Fan).
Can we associate their respective constraints as default values of Temperature and Fan Speed, which override the reset state Temperature and Fan Speed values and even the Temperature and Fan Speed values that may have been explicitly specified in the code using setTemp() and setFan()?
e.g. if setEcono(true) is used, the Temperature sent must always be 24C and Fan Speed sent must always be Med.

Do we have to constrain it?
The goal should be to be able to control the unit, not to exactly emulate the remote.
As long as it works to send different values, why should we implement the same limits?

The user of the library can always add additional limits.

crankyoldgit · 2020-08-26T05:00:55Z

Do we have to constrain it?

Yes and No.

The goal should be to be able to control the unit, not to exactly emulate the remote.

Correct.

As long as it works to send different values, why should we implement the same limits?

Here is the crux of it. In my opinion, we should not let a user trivially create/construct a message that the unit won't recognise or respond to. If the A/C silently ignores an entire command because it has econo set whilst in heat mode, then I think we should not allow it. However, if the A/C just ignores the econo part, and sets everything else in the message because "heat and econo mode are incompatible" then I'm fine with the library sending it.

For example, the SwingH mode in this very protocol & a/c. The A/C didn't recognise a command with SwingH set because it doesn't support it, so allowing a user to send that sort of message is not great. However, the A/C doesn't support WiFi, but it happily accepts messages with the WiFi setting turn on. So, allowing it to be sent is fine.

Basically, I'm all for maximal functionality & possibility w.r.t. to the library. i.e. We don't have to be bound by the remote's or manufacturer's limitations thus unlocking extra functionality. However, making messages that won't even be partially recognised is something we should avoid if we can trivially do it.

manj9501 · 2020-08-26T06:43:35Z

Basically, I'm all for maximal functionality & possibility w.r.t. to the library. i.e. We don't have to be bound by the remote's or manufacturer's limitations thus unlocking extra functionality. However, making messages that won't even be partially recognised is something we should avoid if we can trivially do it.

@crankyoldgit I second you!

crankyoldgit · 2020-08-26T08:22:25Z

e.g. if setEcono(true) is used, the Temperature sent must always be 24C and Fan Speed sent must always be Med.

That may be what the remote does/sends, but will the A/C unit accept the econo & dry mode that deviate from those restrictions/limitations?
e.g. Does the A/C remote respond (mostly correctly) if you send a Dry mode with Fan High message? etc

manj9501 · 2020-08-26T08:37:14Z

Does the A/C remote respond (mostly correctly) if you send a Dry mode with Fan High message? etc

Yes, it responds correctly, with the fan speed remaining LOW, as expected.

crankyoldgit · 2020-08-26T08:41:53Z

Hmm. Then I'm tempted to not enforce it in the library if the similar restrictions behave similarly.

manj9501 · 2020-08-26T08:49:30Z

Yes, the AC automatically know what to do when the Econo option is activated.
So I suppose my question has been answered!

* Add `IRVoltas` class to handle detailed setting support. - Model - Power - Mode - Fan Speed - Temperature - Turbo (Cool Mode only) - Econo (Cool Mode only) - Sleep (Cool Mode only) - Wifi - Light/Lamp - SwingV - SwingH (Unavailable for Model 122LZF) - Off Timer - On Timer * Add support for `VOLTAS` to Common A/C API (`IRac`) * Unit tests. * Tested against real received messages, and sending messages to a real device. Fixes #1238

manj9501 · 2020-08-29T11:20:30Z

Thanks a lot @crankyoldgit for making this journey worth embarking on!
I really appreciate your prompt responses and I probably can't even imagine all the hard work that you must have put in. So here's your🥇
Cheers!

_v2.7.10 (20200831)_ **[BREAKING CHANGES]** - move SPIFFS to LittleFS for ESP8266 (#1182 #1226) - Daikin176: Change & increase operating mode values. (#1233 #1235) **[Bug Fixes]** - TOSHIBA_AC: not turning off when using `IRac` class. (#1250 #1251) - Haier: change position of Fan speed bits. (#1246 #1247) **[Features]** - Voltas: Add detailed support for Voltas A/Cs (#1238 #1248) - Add support for Metz protocol. (#1241 #1242) - Basic support for Voltas A/C protocol (#1238 #1243) - Add low level bit formatting sanity checks. (#1232) **[Misc]** - Rewrite Airwell by using bit fields (#1254) - Rewrite Haier YRW02 using bit fields (#1253) - rewrite Haier HSU07-HEA03 (#1246 #1247) - rewrite ir_Gree & ir_Midea by using bit field (#1240) - Incorrect usage of `assert()` (#1244 #1245 #1232) - rewrite Gree (#1210)

## v2.7.10 release _v2.7.10 (20200831)_ **[BREAKING CHANGES]** - move SPIFFS to LittleFS for ESP8266 (#1182 #1226) - Daikin176: Change & increase operating mode values. (#1233 #1235) **[Bug Fixes]** - TOSHIBA_AC: not turning off when using `IRac` class. (#1250 #1251) - Haier: change position of Fan speed bits. (#1246 #1247) **[Features]** - Voltas: Add detailed support for Voltas A/Cs (#1238 #1248) - Add support for Metz protocol. (#1241 #1242) - Basic support for Voltas A/C protocol (#1238 #1243) - Add low level bit formatting sanity checks. (#1232) **[Misc]** - Rewrite Airwell by using bit fields (#1254) - Rewrite Haier YRW02 using bit fields (#1253) - rewrite Haier HSU07-HEA03 (#1246 #1247) - rewrite ir_Gree & ir_Midea by using bit field (#1240) - Incorrect usage of `assert()` (#1244 #1245 #1232) - rewrite Gree (#1210)

crankyoldgit · 2020-08-31T14:17:15Z

The code changes mention have now been included in the newly released v2.7.10 of the library.

manj9501 · 2020-08-31T14:20:55Z

Thanks for the information! I'll update it right away

crankyoldgit · 2020-08-31T14:23:17Z

Note: It may take up to 24 hours for the standard Arduino library manager(s) to get the updated version of the library. but it's available now from github if you want to do it manually.

manj9501 · 2020-08-31T14:56:09Z

Yeah, I took the manual route. Thanks!

gokul12051997 · 2020-09-23T06:01:14Z

Hello, I've been trying to make a voltas remote decoding using gpio interrupts and timers. I've analysed the remote burst and noticed that there wasn't any start bit. I'm almost near to the end and all I miss now is the integrity. Since because I don't see a start bit, IR receiver easily gets pulled to other signals. It would of great help if some one can guide me to the finish line. Also please correct me if I was wrong at any point.

crankyoldgit · 2020-09-23T06:22:39Z

Hello, I've been trying to make a voltas remote decoding using gpio interrupts and timers. I've analysed the remote burst and noticed that there wasn't any start bit. I'm almost near to the end and all I miss now is the integrity. Since because I don't see a start bit, IR receiver easily gets pulled to other signals. It would of great help if some one can guide me to the finish line. Also please correct me if I was wrong at any point.

@gokul12051997 Please create a new issue and include all the data & code you've worked out thus far.
e.g. Have you followed the two wiki pages on how to add new protocols etc?
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

With out data & code etc, how can we help you?

NiKiZe · 2020-09-23T06:27:59Z

Hello, I've been trying to make a voltas remote decoding using gpio interrupts and timers. I've analysed the remote burst and noticed that there wasn't any start bit. I'm almost near to the end and all I miss now is the integrity. Since because I don't see a start bit, IR receiver easily gets pulled to other signals. It would of great help if some one can guide me to the finish line. Also please correct me if I was wrong at any point.

Are you maybe trying to write your own decoder, and not using this library and want help with understanding the raw or signal?

gokul12051997 · 2020-09-23T06:48:06Z

@crankyoldgit Sorry and I'll create a new issue with the data's.
@NiKiZe yes I'm trying to write my own decoder. When I observed the Ir burst I found only 2 pulses one with 1.6ms and another with 3.5ms which kept of repeating a unique way to form a 195ms burst. So I started writing by recoding the occurrence of those two pulses and there by formed the 10byte hex data which matched @crankyoldgit decoded results.
The issue I'm facing right now is that, if don't disturb the system for like 10mins and then send the Ir burst, the decoded data is completely wrong.
Another senenario which I faced is like if I bring a mobile phone in between the remote and the receiver, the decoded result is completely wrong again, which I thought was because of interference and not having a start bit in the voltas ir burst.

Xref: #1238 Fixes #1799

_v2.8.3 (20220915)_ **[Bug Fixes]** - Fix `#if` for DECODE_COOLIX48 (#1796) - Add missing `prev`s to `decodeToState()` (#1783) **[Features]** - Add `pause()` function to ESP32 when receiving. (#1871) - ARGO: Argo add `sendSensorTemp()` (#1858 #1859) - HAIER_AC160: Experimental detail support. (#1852 #1804) - BOSCH144: Add IRac class support (#1841) - Mitsubishi_AC: update left vane in `IRac` class (#1837) - Basic support for Daikin 312bit/39byte A/C protocol. (#1836 #1829) - Experimental basic support for Sanyo AC 152 bit protocol. (#1828 #1826) - GREE: Add model support for `YX1FSF`/Soleus Air Windown A/C (#1823 #1821) - Experimental basic support for Bosch 144bit protocol. (#1822 #1787) - Experimental basic support for TCL AC 96 bit protocol. (#1820 #1810) - Add basic support for clima-butler (52bit) RCS-SD43UWI (#1815 #1812) - TOTO: An experimental _(s)wipe_ at support for Toto Toilets. (#1811 #1806) - CARRIER_AC128: Experimental Basic support for Carrier AC 128bit protocol. (#1798 #1797) - HAIER_AC160: Add basic support for Haier 160bit protocol. (#1805 #1804) - DAIKIN: Add basic support for 200-bit Daikin protocol. (#1803 #1802) - FUJITSU: Improve handling of 10C Heat mode. (#1788 #1780) - FUJITSU: Improve handling of short (command only) messages. (#1784 #1780) **[Misc]** - Improve the `_IRREMOTEESP8266_VERSION_VAL` macro (#1875 #1870) - SONY: Update supported devices. (#1872) - SAMSUNG: Update supported devices (#1873) - NEC: Update supported devices (#1874) - Give IRmacros.h smaller scope to avoid impacting projects using IRremoteESP8266 (#1857 #1853 #1851) - Inhibit protocol names for not-included protocols (#1853 #1851) - Test out codeql static analysis (#1842) - Remove pylint disable=no-self-use (#1817) - Fujitsu General: update supported devices (#1813) - DAIKIN: Update supported devices (#1808 #1807) - Fujitsu: Update supported remote info. (#1801 #1794) - DAIKIN128: Update supported devices (#1754) - Voltas: Add link to manual for 122LZF A/C. (#1800 #1799 #1238) - Daikin128: Additional unit test. (#1795 #1754) - MIDEA: Update supported devices (#1791 #1790)

**_v2.8.3 (20220915)_** **[Bug Fixes]** - Fix `#if` for DECODE_COOLIX48 (#1796) - Add missing `prev`s to `decodeToState()` (#1783) **[Features]** - Add `pause()` function to ESP32 when receiving. (#1871) - ARGO: Argo add `sendSensorTemp()` (#1858 #1859) - HAIER_AC160: Experimental detail support. (#1852 #1804) - BOSCH144: Add IRac class support (#1841) - Mitsubishi_AC: update left vane in `IRac` class (#1837) - Basic support for Daikin 312bit/39byte A/C protocol. (#1836 #1829) - Experimental basic support for Sanyo AC 152 bit protocol. (#1828 #1826) - GREE: Add model support for `YX1FSF`/Soleus Air Windown A/C (#1823 #1821) - Experimental basic support for Bosch 144bit protocol. (#1822 #1787) - Experimental basic support for TCL AC 96 bit protocol. (#1820 #1810) - Add basic support for clima-butler (52bit) RCS-SD43UWI (#1815 #1812) - TOTO: An experimental _(s)wipe_ at support for Toto Toilets. (#1811 #1806) - CARRIER_AC128: Experimental Basic support for Carrier AC 128bit protocol. (#1798 #1797) - HAIER_AC160: Add basic support for Haier 160bit protocol. (#1805 #1804) - DAIKIN: Add basic support for 200-bit Daikin protocol. (#1803 #1802) - FUJITSU: Improve handling of 10C Heat mode. (#1788 #1780) - FUJITSU: Improve handling of short (command only) messages. (#1784 #1780) **[Misc]** - Improve the `_IRREMOTEESP8266_VERSION_VAL` macro (#1875 #1870) - SONY: Update supported devices. (#1872) - SAMSUNG: Update supported devices (#1873) - NEC: Update supported devices (#1874) - Give IRmacros.h smaller scope to avoid impacting projects using IRremoteESP8266 (#1857 #1853 #1851) - Inhibit protocol names for not-included protocols (#1853 #1851) - Test out codeql static analysis (#1842) - Remove pylint disable=no-self-use (#1817) - Fujitsu General: update supported devices (#1813) - DAIKIN: Update supported devices (#1808 #1807) - Fujitsu: Update supported remote info. (#1801 #1794) - DAIKIN128: Update supported devices (#1754) - Voltas: Add link to manual for 122LZF A/C. (#1800 #1799 #1238) - Daikin128: Additional unit test. (#1795 #1754) - MIDEA: Update supported devices (#1791 #1790)

crankyoldgit self-assigned this Aug 14, 2020

crankyoldgit added enhancement more info labels Aug 14, 2020

manj9501 mentioned this issue Aug 16, 2020

Basic support for Voltas A/C protocol #1243

Merged

crankyoldgit added a commit that referenced this issue Aug 16, 2020

Voltas: Progress check-in

6c7b52c

* Checksum support. * Power, toString, toCommon, set/GetRaw etc. For #1238

crankyoldgit mentioned this issue Aug 16, 2020

Assert failure in IRrecvDumpV2 & V3 examples #1244

Closed

crankyoldgit added a commit that referenced this issue Aug 16, 2020

[Bug] Incorrect usage of assert()

33f0500

Ref: #1238 (comment) X-Ref: #1232 Fixes #1244

crankyoldgit mentioned this issue Aug 16, 2020

[Bug] Incorrect usage of assert() #1245

Merged

crankyoldgit added a commit that referenced this issue Aug 16, 2020

[Bug] Incorrect usage of assert() (#1245)

791319e

Ref: #1238 (comment) X-Ref: #1232 Fixes #1244

crankyoldgit added a commit that referenced this issue Aug 17, 2020

Voltas: Progress check-in

1594f00

* Checksum support. * Power, toString, toCommon, set/GetRaw etc. For #1238

crankyoldgit removed the more info label Aug 26, 2020

crankyoldgit closed this as completed in #1248 Aug 28, 2020

crankyoldgit mentioned this issue Aug 31, 2020

v2.7.10 Release #1257

Merged

crankyoldgit added a commit that referenced this issue May 8, 2022

Voltas: Add link to manual for 122LZF A/C.

f649d98

Xref: #1238 Fixes #1799

crankyoldgit mentioned this issue May 8, 2022

Voltas: Add link to manual for 122LZF A/C. #1800

Merged

crankyoldgit added a commit that referenced this issue May 8, 2022

Voltas: Add link to manual for 122LZF A/C. (#1800)

b073fa9

Xref: #1238 Fixes #1799

crankyoldgit mentioned this issue Sep 15, 2022

v2.8.3 release #1878

Merged

Voltas AC Remote IR Mapping #1238

Voltas AC Remote IR Mapping #1238

Comments

manj9501 commented Aug 14, 2020 • edited Loading

crankyoldgit commented Aug 14, 2020

manj9501 commented Aug 14, 2020 • edited Loading

manj9501 commented Aug 14, 2020

crankyoldgit commented Aug 15, 2020

manj9501 commented Aug 15, 2020

crankyoldgit commented Aug 16, 2020

crankyoldgit commented Aug 16, 2020

crankyoldgit commented Aug 16, 2020

manj9501 commented Aug 16, 2020

manj9501 commented Aug 16, 2020 • edited Loading

crankyoldgit commented Aug 16, 2020

manj9501 commented Aug 16, 2020

crankyoldgit commented Aug 16, 2020

manj9501 commented Aug 16, 2020

crankyoldgit commented Aug 16, 2020

crankyoldgit commented Aug 17, 2020

manj9501 commented Aug 17, 2020

crankyoldgit commented Aug 17, 2020

manj9501 commented Aug 17, 2020

manj9501 commented Aug 25, 2020 • edited Loading

manj9501 commented Aug 25, 2020

NiKiZe commented Aug 25, 2020 • edited Loading

crankyoldgit commented Aug 26, 2020

manj9501 commented Aug 26, 2020

crankyoldgit commented Aug 26, 2020

manj9501 commented Aug 26, 2020

crankyoldgit commented Aug 26, 2020

manj9501 commented Aug 26, 2020

manj9501 commented Aug 29, 2020

crankyoldgit commented Aug 31, 2020

manj9501 commented Aug 31, 2020

crankyoldgit commented Aug 31, 2020

manj9501 commented Aug 31, 2020

gokul12051997 commented Sep 23, 2020

crankyoldgit commented Sep 23, 2020

NiKiZe commented Sep 23, 2020

gokul12051997 commented Sep 23, 2020

manj9501 commented Aug 14, 2020 •

edited

Loading

manj9501 commented Aug 14, 2020 •

edited

Loading

manj9501 commented Aug 16, 2020 •

edited

Loading

manj9501 commented Aug 25, 2020 •

edited

Loading

NiKiZe commented Aug 25, 2020 •

edited

Loading