bwze
commented
6 years ago OK, as a follow up, I've been successful in sending the new protocol type by altering the sendCOOLIX function in ir_Coolix.cpp.
I still haven't been able to figure out the decode portion yet.
This is what I'm using...
`#if SEND_COOLIX // Send a Coolix message // // Args: // data: Contents of the message to be sent. // nbits: Nr. of bits of data to be sent. Typically COOLIX_BITS >>>in this case it's 48, not 24... // repeat: Nr. of additional times the message is to be sent >>> no repeats due to checksum?? // // Status: Works like a charm.... :) // // Ref: // https://github.com/z3t0/Arduino-IRremote/blob/master/ir_COOLIX.cpp // TODO(anyone): Verify repeat functionality against a real unit. // Verified...this works with my Midea AC unit.... (bwze) void IRsend::sendCOOLIX(uint64_t data, uint16_t nbits, uint16_t repeat) { if (nbits % 8 != 0) return; // nbits is required to be a multiple of 8.
// Set IR carrier frequency enableIROut(38);
for (uint16_t r = 0; r <= repeat; r++) { // Header mark(COOLIX_HDR_MARK); space(COOLIX_HDR_SPACE);
// Data
// Break data into byte segments, starting at the Most Significant
// Byte. Each byte then being sent normal and later being sent again
// as a second payload inverted.
for (uint16_t i = 8; i <= nbits; i += 8) {
// Grab a bytes worth of data.
uint8_t segment = (data >> (nbits - i)) & 0xFF;
// Send Normal.
sendData(COOLIX_BIT_MARK, COOLIX_ONE_SPACE,
COOLIX_BIT_MARK, COOLIX_ZERO_SPACE,
segment, 8, true);
}
// Footer
mark(COOLIX_BIT_MARK);
spaceace(COOLIX_MIN_GAP); // Pause before repeating
mark(COOLIX_HDR_MARK); //Resend Header
space(COOLIX_HDR_SPACE); //Resend Space
for (uint16_t i = 8; i <= nbits; i += 8) {
// Grab a bytes worth of data.
uint8_t segment = (data >> (nbits - i)) & 0xFF;
// Now send Inverted.
sendData(COOLIX_BIT_MARK, COOLIX_ONE_SPACE,
COOLIX_BIT_MARK, COOLIX_ZERO_SPACE,
segment ^ 0xFF, 8, true);
}
mark(COOLIX_BIT_MARK); //Need to send this to finish the overall payload} }
endif
`
crankyoldgit
(Please use this template for reporting issues. You can delete what ever is not relevant. Giving us this information will help us help you faster. Please also read the FAQ & Troubleshooting Guide. Your problem may already have an answer there.)
Version/revison of the library used
v2.1.1
Expected behavior
Not really a problem with the expected behavior as much as a request for a new AC decoder...
Actual behavior
As far as I can tell, it worked exactly as it should have...
Output of raw data from IRrecvDumpV2.ino (if applicable)
Represents, Power: ON, Mode: AUTO, Fan: AUTO, Setpoint: 65°F
Encoding : UNKNOWN Code : E656F582 (100 bits) Timing[199]:
Steps to reproduce the behavior
Not sure you can if you don't have my particular AC, but I'm willing to work with you however possible...
Example code used
No code for this yet.....
Circuit diagram and hardware used (if applicable)
I'm using the scenario as decribed in IRrecvDumpV2.ino which is working perfectly...
I have followed the steps in the [Troubleshooting Guide]
Yes
Other useful information
So, here goes.....I have two Midea mini splits ACs that I'm attempting to control with the help of your library and an open source home automation software (Home Assistant).
I have successfully used the Coolix decode/send commands included in your library with a slightly altered version of your MQTT server example to successfully emulate total control of one of my mini split ACs from the software with no issues whatsoever. This, I guess confirms that the Coolix protocol is the same as the one used by Midea.
My problem, however, is that the other AC's remote uses a different protocol and I don't have enough experience to change ir_Coolix..cpp to allow it work.
The included Coolix (A.K.A. Midea) protocol normally sends six bytes of data as such....
Header Spacer Byte 0 Byte 0 (Inverse) Byte 1 Byte 1 (Inverse) Byte 2 Byte 2 (Inverse) Long Gap Header Spacer Byte 0 Byte 0 (Inverse) Byte 1 Byte 1 (Inverse) Byte 2 Byte 2 (Inverse)
This other remote sends six bytes of data too, but slightly differently...
Header Spacer Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 (Checksum) Long Gap Header Spacer Inverse - Byte 0 Inverse - Byte 1 Inverse - Byte 2 Inverse - Byte 3 Inverse - Byte 4 Inverse - Byte 5 (Checksum)
All of the timing seems to be the same as the included Coolix protocol (i.e. the headers, spacers, ones, zeros, bit mark, gap spacing, and carrier frequency look the same).
I have successfully, with research via the Internet and using Analysis IR software, decoded the other remotes byte structure....and it's somewhat similar to the Coolix protocol.
So, all of this to ask....would someone be willing to take a look at my IR captures and see if there is a way to add the ability to decode and send this other protocol via HEX?
IR Captures