Adding support for Galanz / Tekno point allegro HVAC devices

[cociweb]

Version/revision of the library used

2.7.18

Describe the bug

no bug: it's a request for new protocol implementation (see details below)

To Reproduce

measured and decoded the outgoing signal from the display (ir receiver) board towards to the main board.

Example code used

N/A

Expected behaviour

recognize an unknown protocol as a known.

Output of raw data from [IRrecvDumpV2.ino]

Irlib2 dump for the full buttonset is available if needed. On/off is attached for example here:
ON: Data:[3614,1610,474,1210,390,1294,454,550,394,606,474,530,474,1186,394,634,390,638,450,1210,366,1318,450,554,394,1270,470,554,450,530,390,1318,450,1214,470,530,474,1210,370,1294,474,550,450,554,470,1214,450,550,394,614,466,1218,450,550,370,634,474,530,474,550,450,550,450,554,366,634,502,554,446,554,450,550,450,554,390,614,474,526,478,526,474,550,450,534,406,614,390,1294,394,610,390,614,470,1214,366,638,470,554,450,1214,366,1318,450,550,454,550,474,530,470,530,474,550,454,550,450,1238,450,1210,470,1214,454,1210,474,550,450,554,394,582,394,634,474,526,478,550,450,526,474,1214,474,550,454,550,394,606,370,634,474,526,478,550,450,550,394,610,366,638,414,586,478,546,454,550,422,606,390,610,474,554,450,550,454,550,450,530,410,614,478,526,474,550,450,550,454,550,390,614,474,526,474,550,454,550,450,554,366,634,474,526,478,550,450,550,454,550,366,638,474,526,474,550,454,1210,414,1270,394,610,390,614,470,1214,366,638,470,1190,474,554,390] OFF: Data:[3530,1686,478,1210,474,1214,366,634,474,526,478,550,450,1194,490,530,474,550,478,1214,474,1210,470,534,470,1214,366,634,474,530,478,1210,366,1318,454,546,398,1290,454,1210,390,610,474,550,454,1210,474,526,478,550,450,1214,470,530,474,550,454,550,394,606,370,614,494,554,450,550,450,550,478,526,366,638,470,530,474,550,454,550,450,550,370,634,474,530,474,550,450,550,450,418,530,610,470,1186,502,526,370,634,474,1210,450,1238,450,530,470,554,394,610,386,614,474,550,454,550,478,1210,478,1210,390,1270,474,1214,474,550,450,550,454,550,366,638,470,530,474,550,454,526,474,1238,450,526,474,550,450,554,390,614,414,610,450,550,450,554,450,554,386,614,390,610,478,526,474,550,454,550,366,638,390,610,478,546,454,550,450,550,370,634,390,638,450,550,450,550,454,550,366,638,386,614,474,530,474,550,450,554,366,634,390,610,478,526,474,550,450,554,366,634,370,634,474,550,454,1210,390,1294,450,1214,474,1210,390,614,478,522,478,1210,390,610,502]

What brand/model IR demodulator are you using?

N/A (factory default : Gal-L05)

Circuit diagram and hardware used (if applicable)

Arduino Uno with PIn2 (IRlib2 library with extended buffer)

I have followed the steps in the [Troubleshooting Guide]

Yes

Has this library/code previously worked as expected for you?

No for this protocol

Other useful information

See below.

Hello,

I've partly decoded (but some more action is needed from my side) the Tekno point ALLEGRO (SSA) type IR protocol which uses Galanz manufactured boards/remote controller. I've not found similar protocol on the www.

I'm not an expert in programming, so I would like to ask some help to implement it and let me use it by the library.

Let me share my findings in the following table.
maybe there is some modulation or something what is used for salting, but more-or-less the timing is in the sheet. (I can send raw timing data on request.)

Here you can find my oscilloscope capture:

Thank's in advance!

[NiKiZe]

The questions in issue template should be answered, (also see the FAQ in regards to unknown protocols)
And remember to include both brand and model of device and remote so that it can be anotated correctly.

[cociweb]

Hello, the standard questions are answered, details remained at the end.
The HVAC device is Tekno Point Allegro (SSA series: SSA-09H ). The remote controller model is GZ-055B-E1 - on the link maybe there is some more Beko alternative models, but I've found it rebranded as arcelik and sanken as well. The product use 3rd party (Galanz) manufactured boards: GAL-L05 for ir receiver+display and GAL0411GK for main board

[NiKiZe]

Does not look like output from IRrecvDumpV2.ino but does seem somewhat compatible. Is on and off the only 2 buttons? Still missing full brand and model of the actuall devices you are using?

[cociweb]

Here you can find the full capture, but the decoded excel table above is more convenient, I think. (please ignore the last 1000 on every record.

[crankyoldgit]

I've just added experimental support for the Teknopoint protocol as described thus far.
Please download/clone/pull the Teknopoint_Basic branch and let me know how it goes with capture & sending of your IR messages. Don't rely on the data collected by it yet, as the bit ordering needs to be determined/confirm first per https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#determining-the-bit-order-of-the-protocol

[crankyoldgit]

FYI, one of the many reasons we ask for the data from our tools or in our format is so it is easier to use our existing tools, code, and suite of tests on it. I makes our life coding up stuff for you guys MUCH easier. Hence we ask people to meet us half way so we don't have to futz around and convert data/formats/etc trying to help you. i.e. Less effort for us means we can help you faster, better, and with a smile, rather than being a Cranky Old Git. ;-)

[cociweb]

Hello,
Thank you!
I've checked the branch. I've tried it with VS1636B decoder it seems it found the protocol, but it's a little unreliable (as earlier flaged it in the issues/wiki).
Is there any trick for the library to use inverse input as well? (The factory default decoder use inverse /active-low/ logic) - as I saw the Send method is already prepared for this. If I have a reliable decoder with inverse logic I can recapture everything again according to the guides.

Bit ordering (as you can see it in the attached table it mostly uses MSB.)
For temp: 16C->1111, 17C->0111 - when the temp is increased the value is decreased by 1MSB
For timers: 1h->110000, 2h->011000 - increased by 3MSB

The below example represents:off/on for factory mode, fan auto, swing - as in the table:

Timestamp : 000014.163
Library   : v2.7.18

Protocol  : TEKNOPOINT
Code      : 0xC4D36480000410E01C000000003E (112 Bits)
uint16_t rawData[227] = {3594, 1614,  464, 1194,  518, 1190,  470, 504,  440, 584,  468, 560,  468, 1186,  498, 526,  470, 530,  488, 1194,  470, 1170,  514, 528,  470, 1212,  470, 528,  472, 528,  464, 1218,  492, 1190,  470, 528,  416, 1268,  470, 1212,  470, 530,  470, 528,  438, 1246,  496, 502,  464, 538,  494, 1186,  470, 554,  470, 530,  470, 530,  414, 584,  496, 528,  470, 504,  522, 502,  512, 488,  496, 528,  470, 530,  438, 562,  496, 528,  470, 528,  490, 484,  464, 586,  470, 528,  446, 552,  416, 584,  468, 556,  468, 530,  470, 1214,  470, 528,  494, 506,  512, 488,  496, 528,  470, 528,  416, 1268,  468, 530,  414, 584,  496, 528,  470, 530,  464, 1244,  470, 1186,  496, 1186,  498, 528,  470, 506,  440, 584,  514, 510,  470, 530,  468, 530,  416, 584,  496, 530,  470, 1186,  496, 1188,  466, 1216,  438, 540,  520, 526,  496, 528,  416, 584,  468, 556,  470, 528,  498, 500,  510, 488,  496, 530,  470, 528,  416, 584,  510, 488,  496, 530,  470, 528,  438, 562,  498, 528,  468, 530,  470, 528,  508, 490,  496, 530,  470, 528,  416, 584,  466, 556,  470, 528,  470, 528,  512, 488,  522, 530,  470, 528,  508, 490,  498, 526,  446, 554,  416, 584,  512, 486,  496, 530,  470, 528,  416, 584,  514, 1168,  510, 1146,  442, 1266,  470, 1188,  496, 1186,  514, 510,  496};  // TEKNOPOINT
uint8_t state[14] = {0xC4, 0xD3, 0x64, 0x80, 0x00, 0x04, 0x10, 0xE0, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x3E};


Timestamp : 000105.025
Library   : v2.7.18

Protocol  : TEKNOPOINT
Code      : 0xC4D36480002410E01C0000000001 (112 Bits)
uint16_t rawData[227] = {3622, 1612,  464, 1216,  442, 1242,  566, 412,  460, 560,  466, 534,  464, 1218,  464, 560,  438, 560,  440, 1220,  462, 1218,  464, 562,  436, 1220,  462, 562,  436, 562,  462, 1242,  414, 1246,  436, 562,  436, 1242,  442, 1220,  464, 562,  436, 556,  466, 1222,  436, 562,  464, 584,  414, 1218,  464, 536,  464, 562,  436, 562,  438, 560,  464, 536,  464, 562,  436, 562,  464, 536,  464, 556,  442, 562,  436, 560,  466, 536,  462, 562,  438, 560,  464, 538,  462, 560,  438, 560,  438, 1246,  438, 562,  436, 560,  466, 1218,  462, 536,  466, 556,  444, 560,  440, 560,  466, 534,  464, 1216,  466, 534,  464, 560,  440, 558,  464, 536,  464, 1216,  468, 1216,  440, 1242,  440, 558,  440, 560,  466, 534,  466, 558,  440, 558,  466, 534,  466, 556,  442, 558,  440, 1244,  440, 1216,  468, 1216,  466, 556,  444, 556,  444, 556,  440, 562,  546, 476,  526, 472,  440, 560,  466, 532,  544, 478,  522, 478,  440, 562,  470, 528,  472, 552,  550, 448,  442, 542,  490, 550,  448, 550,  418, 584,  554, 496,  502, 496,  418, 584,  464, 534,  526, 496,  502, 496,  440, 562,  526, 496,  502, 496,  446, 556,  436, 562,  524, 498,  502, 496,  418, 584,  522, 500,  502, 498,  502, 496,  418, 564,  544, 498,  502, 496,  418, 584,  438, 560,  526, 496,  502, 1180,  528};  // TEKNOPOINT
uint8_t state[14] = {0xC4, 0xD3, 0x64, 0x80, 0x00, 0x24, 0x10, 0xE0, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x01};

[NiKiZe]

Since the protocol now matches, could you collect the state for the full temp range, with information about temperature, and also most othe functions.

This helps us validate the data easily. Again, don't use these state values yet, they might change.

[crankyoldgit]

I've checked the branch. I've tried it with VS1636B decoder it seems it found the protocol, but it's a little unreliable (as earlier flaged it in the issues/wiki).

If you get some failed matches, even with the VS1636B, please report them. I can try to tune the matching of the protocol based on those failures. Assuming that are "good". i.e. the VS1636B isn't playing up.

Is there any trick for the library to use inverse input as well?

Yes. We swap the timings for the Spaces. e.g.

IRremoteESP8266/src/ir_Teknopoint.cpp

Lines 18 to 19 in 25f1ac1

	const uint16_t kTeknopointOneSpace = 1238;
	const uint16_t kTeknopointZeroSpace = 567;

That will invert the binary output.

But in order to determine what is the correct bit determination we need the data as described in the wiki and as @NiKiZe requested as per:

Since the protocol now matches, could you collect the state for the full temp range, with information about temperature, and also most other functions.

Once we have the data from: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#determining-the-bit-order-of-the-protocol

We can look at/find the temperature range (and the checksum) to try to determine the best way to represent the bit stream.
i.e. bit order, and if 1s should be 0s etc.

[cociweb]

Hello,
I've done some repetative test for my ir demodulator (VS1636B) to get the correct timing. The dataset contains 19 samples.
Can you please review the the timing values? After a more reliable identification, I can start to recapture the temps, functions, etc.

[crankyoldgit]

Looking at the timings, occasionally there is a "space" that is short by about 200 useconds. i.e. 1/3rd+ less than the expected value. That's what causing those messages to not match. I'm fairly sure it's the VS1636B that's behind it, but I see what I can tweak so you get a more reliable capture for now.

[crankyoldgit]

I've tried to improve the matching for you. It matches all the extra "UNKNOWN" messages I tested it against. So, fingers crossed. Download the branch again etc etc. let me know.

[cociweb]

Hello,
Today, I've recaptured everything again. You can find my raw data here. The matching is much more reliable, but there are some unknown messages yet (please chek it from the beginning until Timestamp: 000785.6339 - after that some junk can occured.) I've put "helper string" with State: prefix where the protocol is recognized into the raw log.
Additionally, I've added a third worksheet to the table, and you can check interactivelly, forth and back (first sheet) the decoded parts and checksum as well.

[crankyoldgit]

Apologies for letting this sit idle for so long. I've had a lot of other stuff happening that took priority.

I've pushed some changes to the branch, mostly changing the bit ordering. All previous capture values will be unusable. Sorry.
I've also added a checksum integrity check for the capture based on your analysis.

For your spreadsheet, please don't use Excel. I don't have that software and other people might not either. Please convert it & update it on some shared easily visible platform that gets updated live. e.g. Google Sheets or similar. Please make it publicly readable when you do.

So, download the branch and recapture etc. It should be fairly simple.

[cociweb]

Hello,
The same busy summertime is here as well. Let me re-capture them on the next weekend again. (BTW, you can use msoffice online, if you begin the link with "https://view.officeapps.live.com/op/view.aspx?src=" , So any xls/xlsx is viewable for free in your browser and you can export it as well) Let's try it online - If it's unsuccessfull, I will upload it on another way.

[crankyoldgit]

The same busy summertime is here as well.

It's Winter where I am. :-)

Let's try it online

Excellent, I didn't know that. Works for me. Knock yourself out with MS Excel then, as long as you update the file etc.

[crankyoldgit]

and add the "Night" speed. etc.

By which I mean I'll treat it like "sleep" via IRac/Tasmota/etc

[crankyoldgit]

I've improved the TCL112AC protocol and hacked up some temporary support for TEKNOPOINT too.
Hopefully it should detect the different models (one is TCL, the other is TEKNOPOINT)

It should now report different Swing(V)" values:
e.g.
Swing(V): 1 (UNKNOWN)

What I need from you (and couldn't easily find in the spreadsheet(s)) are what are the "5 fixed positions + auto swing." values are and the "Night" fan speed you mentioned.

Basically, I need you to document what & how the new bits in #1486 (comment) are & what they do.
Make it very simple & plain.
e.g. SwingV of 1 means "Highest" etc. TimerType of 0b01 means the off timer is set/enabled, 0b11 means the on and off timers are set/enabled, etc. A Fan value of 4 means "Blah". A TimerIndicator of 1 means something something and something. OnTimer is a number of minutes from now the A/C will turn on if and only if TimerType is 0b11. OffTimer is the wall clock time to turn off the A/C expressed in the number of minutes passed midnight. e.g. 185 means 3:05am etc. etc etc.

Got it?

Please download branch https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1486 and test out IRrecvDumpV2+ and let me know how it goes (and the above data etc)

[crankyoldgit]

Experimental Timer & Min/Night fan speed has been added to the branch. Please test.

[cociweb]

Hello,
Wow! Great Job! Here You can see the output of the IRrecvDumpV2.

Here are my experiences:

1. Night mode recognized as 'Fan: 1 (UNKNOWN)' (see the definitions below.)
2. SwingV fixed positions recognized as 'Swing(V): X (UNKNOWN)' (see definitions below)
   3a) There are a few 'useless' fileds for Technopoint: Econo: Off, Health: Off, Turbo: Off, and Light: On which are always constants (there is no any lights which tend to be 'on')
   3b) if the previous is expected, than maybe the 'Quiet mode' is missed (Addressed by #1528)
3. the ONTimer and the OFFTimer is always recognised as 'X Timer: 00:00' when it is not turned to off. (see definitions below)
   Furthermore, as of now they are swapped!

New DEFs:

• SwingV:
  SwingV of 5 (0b101) means a fixed position in 'lowermost'
  SwingV of 4 (0b100) means a fixed position in 'lower''
  SwingV of 3 (0b011) means a fixed position in 'middle'
  SwingV of 2 (0b010) means a fixed position in 'upper'
  SwingV of 1 (0b001) means a fixed position in 'uppermost'
  [SwingV of 7 (0b111) means a continous vertical airflow rotation 'Swing']

• Night mode:
  Fan value of 1 (0b001) means 'Night mode'

Feature description for Night mode:

• Night mode in cooling running
  A. The indoor fan runs at low speed.
  B. One hour later, the setting temperature will automatically increase by and one hour later again, the
  setting temperature will automatically increase by 1 once more, then the air conditioner will keep
  running.
• Night mode in heating running
  A. The indoor fan runs at low speed.
  B. One hour later, the setting temperature will automatically decrease by and one hour later again, the
  setting temperature will automatically decrease by 1 once more, then the air conditioner will keep
  running.

• Timers:

OnTimer is a number of hours (1-12) from now the A/C will turn ON if and only if TimerIndicator is 1 and OnTimerEnabled is 1.
where the following bits are represent the hours:
0b000011 - 01H
0b000110 - 02H
0b001001 - 03H
0b001100 - 04H
0b001111 - 05H
0b010010 - 06H
0b010101 - 07H
0b011000 - 08H
0b011011 - 09H
0b011110 - 10H
0b100001 - 11H
0b100100 - 12H
0b000000 - OnTimer is cleared
If there is no OnTimer definied (cleared), the OnTimerEnabled should be 0. (TimerIndicator should be 0 as well if no OffTimer definied either)

OffTimer is a number of hours (1-12) from now the A/C will turn OFF if and only if TimerIndicator is 1 and OffTimerEnabled is 1.
where the following bits are represent the hours:
0b000011 - 01H
0b000110 - 02H
0b001001 - 03H
0b001100 - 04H
0b001111 - 05H
0b010010 - 06H
0b010101 - 07H
0b011000 - 08H
0b011011 - 09H
0b011110 - 10H
0b100001 - 11H
0b100100 - 12H
0b000000 - OffTimer is cleared
If there is no OffTimer definied (cleared), the Power bit and the OffTimerEnabled bit should be 0. (TimerIndicator should be 0 as well if no OnTimer definied either)

OnTimerEnabled of 1 means the ON timer is set
OnTimerEnabled of 0 means the ON timer is unset
OffTimerEnabled of 1 means the OFF timer is set.
OffTimerEnabled of 0 means the OFF timer is unset
TimerIndicator of 1 means that one of the timers (ON/OFF timer) is set.
TimerIndicator of 0 means that both of the timers (ON/OFF timer) are unset.

[crankyoldgit]

Hey, thanks for the data/captures from IRrecvDumpV2+ etc.

If you get an output that is "wrong", you need to tell me what it is supposed to be.
e.g.

Timestamp : 000809.561
Library   : v2.7.20

Protocol  : TEKNOPOINT
Code      : 0x23CB2601003403007800060000CA (112 Bits)
Mesg Desc.: Model: 2 (GZ055BE1), Type: 1, Power: On, Mode: 3 (Cool), Temp: 31C, Fan: 0 (Auto), Econo: Off, Health: Off, Turbo: Off, Swing(H): Off, Swing(V): 7 (Swing), Light: On, On Timer: Off, Off Timer: 00:00
uint16_t rawData[227] = {3732, 1536,  546, 1142,  544, 1114,  518, 508,  544, 458,  546, 454,  546, 1140,  546, 456,  544, 456,  546, 1142,  546, 1114,  544, 482,  546, 1116,  544, 456,  544, 482,  546, 1114,  542, 1144,  544, 456,  546, 1140,  546, 1114,  546, 482,  546, 456,  544, 1118,  568, 458,  546, 454,  546, 1118,  568, 456,  546, 456,  544, 456,  546, 456,  570, 432,  568, 456,  544, 456,  544, 456,  546, 456,  544, 458,  568, 458,  546, 454,  544, 456,  544, 456,  544, 484,  544, 456,  546, 456,  546, 1116,  570, 456,  518, 1142,  542, 1142,  544, 456,  544, 460,  568, 1116,  546, 1140,  546, 456,  546, 456,  544, 456,  544, 460,  568, 456,  546, 456,  570, 456,  546, 482,  546, 456,  546, 454,  546, 456,  546, 456,  542, 460,  568, 456,  546, 454,  546, 456,  546, 454,  544, 1142,  544, 1142,  546, 1114,  516, 1168,  546, 456,  570, 458,  542, 484,  544, 456,  546, 454,  546, 456,  544, 458,  542, 484,  546, 456,  546, 456,  544, 1142,  546, 1114,  544, 482,  544, 456,  546, 456,  544, 456,  544, 482,  572, 456,  544, 456,  546, 454,  544, 458,  544, 460,  568, 456,  544, 456,  544, 456,  544, 456,  544, 482,  520, 484,  544, 456,  544, 456,  546, 456,  544, 482,  546, 456,  546, 456,  544, 1142,  544, 456,  544, 1116,  544, 482,  546, 456,  544, 1140,  520, 1140,  546};  // TEKNOPOINT
uint8_t state[14] = {0x23, 0xCB, 0x26, 0x01, 0x00, 0x34, 0x03, 0x00, 0x78, 0x00, 0x06, 0x00, 0x00, 0xCA};

The above is good in a away, as I can see something is likely to be wrong with the poor timer time, but If you capture stuff and don't tell me what is wrong, how am I supposed to know what is wrong with it? e.g. What should the timer time be? What did it say on the remote? etc etc.

[crankyoldgit]

Per your earlier comment (& same in your spreadsheet):

	//9 byte		
uint8_t		        :1;	//0
uint8_t OffTimer	:6;	
uint8_t		        :1;	//0
	//10 byte	
uint8_t		        :1;	//0
uint8_t OnTimer  	:6;	
uint8_t		        :1;	//0

The reason you were getting 00:00 it seems as you got the order of these values wrong.
After checking the data it looks like OffTimer is in Byte[10].
Please double check your analysis to confirm this is the case. (I'm going to assume you were wrong)

[crankyoldgit]

I've made updates to the branch to hopefully address the issues you've reported.

Please download and test etc, and let me know what doesn't work as expected.

Also. Is there more to "Night" mode that the protocol setting the fan speed to 1 or is that it?
btw. It should be reported as "quiet" / min speed now.

[cociweb]

Hello,

• The Night/quiet mode is solved under the FAN mode - It's ok for me. (Won't be misleading the 'Quite mode bit in the 5th byte in case of TCL from documentation pov?)
• The Vertical air flow positions are perfect.

BUT, I've found 2 glitches:

• I've found 1 more useless parameter the Swing(H): Off - I've left it out from the previous list. Sorry about the missing reqs.
• I've double checked my experiments about the timers, but I see the same: (the middle 6 bit in the 9th byte illustrate the OFFtimer and the middle 6 bit in the 10th byte illustrate the ONtimer.
  As of now, the values are well decoded, but still swapped.
  Here you can see the current capture for OFF/ON timer and the expected result:
  OFF Timer (expected)
  ON Timer (expected)

[crankyoldgit]

• (Won't be misleading the 'Quite mode bit in the 5th byte in case of TCL from documentation pov?)

Sadly, that will probably be something we have to live with for now in order to save some space on the chip.

• I've found 1 more useless parameter the Swing(H): Off - I've left it out from the previous list. Sorry about the missing reqs.

Done.

• As of now, the values are well decoded, but still swapped.

Should now be working.

The branch has been updated. Please download and test again, etc etc.

[cociweb]

Great!
Everything is working like a charm from decode pov, so my ticket can be closed.
Thank you for your time and effort in the support!

The sending part will be tested later. I need to figure out the technical howto.

Thank you once more!

[crankyoldgit]

Thanks for confirming.

[crankyoldgit]

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