Sending data for a Carrier HVAC - how compose the stream ?

[gnkarn]

im trying to control my ac from a sonoff TH with Tasmotta firmware on it , i have decoded the Carrier HVAC IR code , and it is similar to a NEC1 protocol , but composed of### three consecutive data streams separated by a 20ms space.

the first part it has HEADER( 16xm + 8xs) then the 32 bit data a final mark and the 20 ms space

the second part is the same thing but with the logical complement of the 32 bit data.

the final part is the same as the first part .

in total we then have a message that is 203 mark&spaces long. how to send these three parts separated by its 20ms space gap , all at once, so it could later be associated with one mqtt send command ?

thank you

[gnkarn]

additional information : example of an ON command

aw: (203) 8532, -4216, 628, -1312, 628, -528, 628, -1312, 628, -1312, 628, -528, 628, -524, 628, -1316, 624, -1316, 628, -524, 628, -528, 628, -1312, 628, -1316, 624, -528, 628, -1312, 628, -528, 628, -1312, 628, -1312, 628, -528, 628, -1316, 624, -528, 628, -1312, 628, -528, 628, -1312, 628, -1316, 624, -1316, 628, -1312, 628, -1316, 628, -524, 628, -528, 628, -528, 624, -1316, 628, -528, 628, -20064, 8504, -4228, 628, -528, 628, -1312, 628, -528, 628, -528, 628, -1312, 628, -1316, 624, -532, 624, -528, 628, -1316, 628, -1312, 628, -528, 628, -528, 628, -1312, 628, -528, 628, -1316, 628, -528, 624, -528, 628, -1316, 628, -528, 628, -1316, 624, -528, 628, -1316, 628, -528, 624, -532, 624, -528, 628, -528, 628, -528, 628, -1316, 624, -1316, 628, -1316, 628, -528, 624, -1316, 628, -20076, 8528, -4212, 624, -1316, 628, -528, 628, -1316, 628, -1316, 624, -528, 628, -528, 628, -1316, 628, -1316, 628, -528, 624, -532, 624, -1316, 628, -1316, 628, -528, 628, -1316, 624, -528, 628, -1316, 628, -1316, 628, -528, 628, -1316, 624, -532, 624, -1316, 628, -532, 624, -1316, 628, -1316, 624, -1320, 624, -1316, 628, -1316, 628, -528, 628, -528, 628, -528, 628, -1316, 624, -532, 624,

in this case a : B335ABE2 , B335 is device address A : is Turn on B means temperature 30 deg C E = Cold with fan at 2 . 2 = swing OFF

[crankyoldgit]

From what I can gather after reading https://github.com/arendst/Sonoff-Tasmota/blob/development/sonoff/xdrv_irremote.ino, Tasmota does not support sending all the protocols that this library supports. So, as it stands, there is nothing you can do to use this protocol without modifying the Tasmota code-base. i.e. You can do it, but there is not much we/I can really do for you directly.

Without any alterations to our library, you've got basically three sending options for this type of data. 1) Send in Raw format. aka sendRaw(). That's the least preprocessing option, but the largest "memory" usage option. As it is open-ended (in that the array of data can be quite large), it's unlikely to be added to Tasmota. But hey, it'd be great if they did. 2) Send in Global Cache format. aka sendGC(). I provide a tool to convert sendRaw() to Global Cache format, so preparing the data to send is trivial. Adding that support for that protocol to Sonoff-Tasmota would fabulous as it would allow almost any IR protocol to be sent. Plus there is a large DB of IR commands available to the public etc. However, it too suffers from it being a large arbitrary sized chunk of data to be decoded/parsed in Tasmota. Thus it probably isn't going to be added. (NOTE: If you or arendst were going to adopt only one of these methods, sendGC() is the best one to chose as it's well defined and the most flexible. 3) Pronto codes. aka. sendPronto(). Similar to Global Cache, except no tool to convert Raw to Pronto and slightly less flexible than the GC format.

All three of those methods would be able to send the data you want with the timings you want, without any changes to this library, but they require significant changes to Tasmota, but would provide HUGE IR sending capabilities to their project.

The Carrier protocol you have described is simple enough to write an encoder/decoder for to send/capture the 32bit value. If you have access to an ESP8266 with an IR LED etc etc and some willingness to help debug etc, we can probably do that. Then it would be a matter of updating Tasmota to using a version of the library that supports the Carrier protocol (via 32bit command) and a few tweaks to the Tasmota code. i.e. Fairly trivial from Tasmota's point of view.

If you are willing to help per above, let me know, and I'll start adding Carrier support. Getting anything added to/supported by Tasmota is entirely up to you.

[crankyoldgit]

I should add, if you are willing to use a separate ESP8266 device, you can use the IRMQTTServer example code to do what you want. i.e. send a single HTTP or MQTT command to produce the IR message you want.

[gnkarn]

thank you for your answer ! , i will read in detail what you suggested as options , im not in a hurry to make tasiota to "include it on the master" , as we can allways add it as separate files and compile the custom version, if it works well , they may consider merging the solution later .

so , let me study your suggestions and will came back with more questions ,

[gnkarn]

as i see , tasmotta uses the 2.2.1 version of your library , so it shouldn't be a major problem , i have all codes for my AC already in excel , so that part is not a problem , the issue I'm trying to resolve right now is just to be able to turn on, off, and change modes , cool and fan only . so just 4 commands total . This way i would be able to "bypass" the inner temp control of my AC, and control it directly from the ESp.

so , i need to be able to code those 4 messages, and trigger them by changing the mqtt payload in tasmotta.

So, as you explained , it should be easy , to include that in tasmotta ( will study that part , still have no clue on how to do that ...), and just send those 4 commands without the need to modify the library itself . Let me know if you think I'm in the right track , tks

[crankyoldgit]

Yes, you can certainly change the code for Tasmota yourself and maintain your own fork. Just be aware that Tasmota really uses almost all the memory of a Sonoff device etc. You may have difficulty trying to fit in the codes you want send while still fitting in the memory limit. i.e. You may have to disable/remove some other parts of Tasmota you are not using. e.g. each code you want to add via sendRaw/sendGC hardcoded into Tasmota will take about 400+ bytes of space.

Last time I checked (I run Tasmota too) it only had 10's of kbytes to spare.

[gnkarn]

i understand , i will try that first then . thank you

[crankyoldgit]

FYI, I've added experimental support for your Carrier A/C protocol in the carrier_ac branch. Let me know if it works or not. If it does, then adding it to tasmota should be much easier.

[gnkarn]

Thank you for taking the time to help me , I will test this afternoon I will be testing by using this function

IRsend::sendCarrierAC(uint64_t data, uint16_t nbits, uint16_t repeat) .

[crankyoldgit]

Correct. A call of sendCarrierAC(0xB335ABE2); should reproduce the example you provided.

BTW, what model of remote and hvac unit is this for? (So I can add it to the notes)

[gnkarn]

the remote control has this identification: 42QG5A55970 the indoor unit can be 619EGX0090E0 or 619EGX0120E0 or 619EGX0180E0 or 619EGX0220E0

in case it would be useful here is additional information

mode	temp	fan	swing	code
RECIRC		MAX	ON	B335992F
RECIRC		4	ON	B33599CF
RECIRC		2	ON	B335994F
RECIRC	19	A	OFF	B3359982
RECIRC		MAX	OFF	B3359922
RECIRC		4	OFF	B33599C2
RECIRC		2	OFF	B3359942
FRIO	19	A	ON	B335946F
FRIO		MAX	ON	B335949F
FRIO		4	ON	B335941F
FRIO		2	ON	B33594EF
FRIO		A	OFF	B3359462
FRIO		MAX	OFF	B3359492
FRIO		4	OFF	B3359412
FRIO		2	OFF	B33594E2
HUMEDAD		2	ON	B33594AF
HUMEDAD			OFF	B33594A2
VENT		MAX	ON	B3359932
VENT		4	ON	B33599DF
VENT		2	ON	B335995F
VENT		MAX	OFF	B3359932
VENT		4	OFF	B33599D2
VENT		2	OFF	B3359952
CALOR		A	ON	B33594BF
CALOR		MAX	ON	B335940F
CALOR		4	ON	B33594FF
CALOR		2	ON	B335947F
CALOR		A	OFF	B33594B2
CALOR		MAX	OFF	B3359402
CALOR		4	OFF	B33594F2
CALOR		2	OFF	B3359472

Fast cool B335929F Fast heat B335950F timer on 1 B335E93F timer off 1 B335E49F

Temperature digit : 9X9F X = TEMP 4 19 C 20 2 21 A 22 6 23 E 24 1 25 9 26 5 27 D 28 3 29 8 30

[gnkarn]

all the information is contained on the las 2 bytes , command type, temperature, mode, and swing

note on model numbers , here in argentina , the carrier units were branded as "Surrey , and Bryant" and , the equipment model i tested on , is 53NGK009/012

[crankyoldgit]

I'm 90% convinced that the codes are not MSB (Most Significant Bit) first, but are LSB (Least Significant Bit) first. At least the temperature is IMHO.

So convinced am I that I think you've typo'ed the last temperature value. Instead of:

8 30

You should have the value of "B" for 30. (in your notation)

If you look at them in LSB order vs MSB order:

19C is 0x2 / 0b0010 (LSB)  or  0x4 / 0b0100 (MSB)
20C is 0x3 / 0b0011 (LSB)  or  0xC / 0b1100 (MSB)
21C is 0x4 / 0b0100 (LSB)  or  0x2 / 0b0010 (MSB)
22C is 0x5 / 0b0101 (LSB)  or  0xA / 0b1010 (MSB)
23C is 0x6 / 0b0110 (LSB)  or  0x6 / 0b0110 (MSB)
24C is 0x7 / 0b0111 (LSB)  or  0xE / 0b1110 (MSB)
25C is 0x8 / 0b1000 (LSB)  or  0x1 / 0b0001 (MSB)
26C is 0x9 / 0b1001 (LSB)  or  0x9 / 0b1001 (MSB)
27C is 0xA / 0b1010 (LSB)  or  0x5 / 0b0101 (MSB)
28C is 0xB / 0b1011 (LSB)  or  0xD / 0b1101 (MSB)
29C is 0xC / 0b1100 (LSB)  or  0x3 / 0b0011 (MSB)
and
30C should be 0xD / 0b1101 (LSB)  or  0xB / 0b1011 (MSB)

[gnkarn]

yes , that is totally correct . thanks

[gnkarn]

tested the power on command and it works !!

#include <IRremoteESP8266.h>
#include <IRsend.h>

IRsend irsend(4);  // An IR LED is controlled by GPIO pin 4 (D2)

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);     // Initialize the LED_BUILTIN pin as an output
 irsend.begin();
  Serial.begin(115200, SERIAL_8N1, SERIAL_TX_ONLY);
}

void loop() {
 irsend.sendCarrierAC(0xB335ABE2);
/*sendCarrierAC(uint64_t data, uint16_t nbits, uint16_t repeat)*/
 Serial.println("carrier on code");

 digitalWrite(LED_BUILTIN, LOW);   // Turn the LED on (Note that LOW is the voltage level
                                    // but actually the LED is on; this is because 
                                    // it is acive low on the ESP-01)
  delay(1000);                      // Wait for a second
  digitalWrite(LED_BUILTIN, HIGH);  // Turn the LED off by making the voltage HIGH
  delay(2000);                      // Wait for two seconds (to demonstrate the active low LED)
}```

[gnkarn]

now , to modify the tasmota code , to be able to send the new commands, ...

[gnkarn]

ok, i finish ( i think) modifying Tasmota to work with CARRIER_AC , will test it tomorrow ..

[crankyoldgit]

Good luck. Thanks for confirming that sendCarrierAC() worked for you.

[gnkarn]

question: is it needed to add

#if SEND_CARRIER_AC
    case CARRIER_AC: sendCarrierAC(data); break;
#endif 

into IRsend.cpp ?

[gnkarn]

never mind , i found the issue , tks

[crankyoldgit]

@gnkarn How did it all go? Are we okay to close this issue now?

[gnkarn]

Hi, it worked perfect , I modified trasmita code in order to be able use it on a sonoff TH, modified for IR. I wonted to upload this version to github but don’t know how to do it from platformio

[gnkarn]

Thankyou

[crankyoldgit]

Okay. Marking this issue closed.