crankyoldgit / IRremoteESP8266

Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/
GNU Lesser General Public License v2.1
3k stars 833 forks source link

Mitsubishi Heavy 152: inconsistent messages #2140

Closed ptoffy closed 2 months ago

ptoffy commented 2 months ago

Version/revision of the library used

2.8.6

Describe the bug

IRMitsubishiHeavy152Ac sends inconsistent signals

To Reproduce

It probably doesn't matter but, for context, I have an AsyncWebServer (from the ESPAsyncWebServer lib) running which listens for requests to send commands to the AC. For sending signals to the (Mitsubishi SRK25ZS) AC I:

  1. set up a IRMitsubishiHeavy152Ac instance connected to my IR led;
  2. set up the base config for the AC, which I use to test:
    ac.setPower(false);
    ac.setMode(kMitsubishiHeavyCool);
    ac.setTemp(27);
    ...
    ac.begin();
  3. set up some routes which should send signals like
    server.on("/on", HTTP_GET, [](AsyncWebServerRequest *request) {
      ac.on();
      ac.send();
      request->redirect("/");
    });
  4. decode the results with an IR receiver using
    void loop() {
      decode_results results;
      if (!irrecv.decode(&results))
        return;
      String description = IRAcUtils::resultAcToString(&results);
      if (description.length())
        Serial.println(D_STR_COMMAND ": " + description);
      Serial.println(resultToSourceCode(&results));
      Serial.println();
    }
  5. the received commands get decoded but are, at times, UKNOWN instead of MITSUBISHI_HEAVY_152. I tried sending commands from the AC's remote and they're fine every time so my guess is the decoding is fine, the sending isn't. I've also tried with a couple different IR LEDs but nothing changes

Example code used

Most of the important stuff is above. I also used

#define _IR_ENABLE_DEFAULT_ false
#define DECODE_MITSUBISHIHEAVY true

to narrow down the messages

Expected behaviour

The messages are correct (and therefore get decoded correctly) each time, instead of just sporadically. I'd also love for the AC to actually do something when the messages are correct but that's another beast to tame

Output of raw data from [IRrecvDumpV2.ino]

Example of a correctly decoded/sent message:

Command: Power: On, Mode: 1 (Cool), Temp: 27C, Fan: 6 (Econo), Swing(V): 1 (Highest), 
  Swing(H): 7 (Left Right), Silent: On, Turbo: Off, Econo: On, Night: Off, Filter: Off, 
  3D: Off, Clean: Off

uint16_t rawData[307] = {
    3090, 1664, 332, 466,  418, 1180, 404, 414,  372, 398,  392, 1196,
    408,  414,  342, 1220, 358, 432,  406, 418,  374, 1194, 382, 1208,
    404,  1188, 404, 392,  388, 1202, 406, 414,  372, 1190, 332, 1262,
    404,  1190, 404, 392,  330, 454,  360, 438,  402, 400,  340, 1246,
    402,  1192, 404, 392,  400, 1188, 332, 458,  396, 1208, 366, 1220,
    356,  430,  416, 376,  404, 404,  340, 1244, 328, 456,  420, 1190,
    404,  402,  318, 404,  432, 1216, 330, 1264, 402, 1192, 404, 392,
    402,  1190, 398, 1194, 404, 390,  402, 1190, 402, 1192, 400, 1194,
    400,  1196, 400, 1192, 398, 396,  400, 390,  350, 1246, 396, 398,
    400,  394,  398, 392,  328, 460,  384, 1216, 396, 400,  368, 1226,
    370,  414,  402, 1200, 370, 1226, 338, 1252, 366, 1228, 370, 416,
    422,  1178, 368, 424,  350, 1242, 384, 402,  370, 432,  368, 426,
    368,  422,  352, 1244, 376, 416,  354, 440,  368, 1228, 398, 1194,
    392,  1206, 388, 1200, 396, 1206, 362, 416,  382, 1218, 398, 1196,
    396,  390,  360, 434,  402, 400,  398, 394,  372, 416,  328, 1268,
    374,  1220, 372, 1220, 356, 1236, 396, 1196, 354, 432,  380, 1220,
    370,  1226, 394, 392,  362, 432,  372, 430,  396, 400,  374, 414,
    352,  1244, 394, 396,  394, 400,  392, 396,  326, 464,  372, 434,
    368,  1236, 364, 1232, 374, 1222, 366, 1248, 280, 1316, 368, 1224,
    342,  1250, 322, 1272, 322, 482,  302, 488,  352, 436,  348, 456,
    340,  456,  334, 1260, 342, 1248, 318, 1276, 318, 1270, 334, 1258,
    332,  1260, 342, 1252, 330, 462,  330, 460,  342, 446,  342, 452,
    330,  470,  332, 462,  332, 460,  320, 468,  316, 1286, 332, 1298,
    280,  1278, 328, 1264, 332, 1262, 278, 1316, 332, 1296, 302, 1254,
    330,  466,  332, 462,  330, 460,  318, 468,  334, 470,  330, 472,
    328,  466,  330, 458,  342, 1256, 334}; // MITSUBISHI_HEAVY_152
uint8_t state[19] = {0xAD, 0x51, 0x3C, 0xE5, 0x1A, 0x09, 0xF6, 0x0A, 0xF5, 0x06,
                     0xF9, 0x20, 0xDF, 0x07, 0xF8, 0x80, 0x7F, 0x80, 0x7F};

and right after:

uint16_t rawData[307] = {
    3122, 1616, 332, 458,  410, 1186, 406, 400,  386, 400,  382, 1206,
    406,  394,  340, 1246, 362, 430,  406, 396,  406, 1194, 404, 1186,
    404,  1202, 404, 400,  342, 1242, 404, 394,  370, 1220, 404, 1192,
    400,  1192, 402, 388,  350, 438,  360, 432,  404, 398,  404, 1190,
    384,  1208, 402, 392,  404, 1190, 394, 392,  362, 1238, 396, 1196,
    350,  436,  418, 376,  400, 402,  398, 1194, 370, 416,  418, 1182,
    398,  398,  372, 416,  400, 1198, 394, 1202, 398, 1196, 422, 360,
    372,  1230, 396, 1196, 446, 1152, 396, 1196, 328, 1266, 404, 1190,
    368,  1226, 400, 1204, 372, 418,  398, 392,  356, 432,  398, 404,
    396,  398,  372, 428,  402, 384,  360, 1240, 394, 400,  372, 1222,
    388,  398,  400, 1202, 370, 1224, 374, 1222, 370, 1222, 370, 412,
    404,  1198, 368, 426,  396, 1200, 384, 400,  368, 436,  368, 422,
    396,  396,  350, 1246, 368, 426,  372, 420,  396, 1200, 372, 1220,
    396,  1196, 392, 1202, 368, 1224, 368, 422,  328, 1268, 366, 1228,
    366,  422,  328, 462,  402, 426,  354, 448,  340, 454,  320, 1274,
    386,  1220, 322, 1272, 344, 1248, 302, 1292, 340, 448,  340, 1258,
    342,  1258, 344, 444,  344, 442,  344, 456,  336, 460,  336, 456,
    320,  1276, 328, 466,  328, 468,  328, 462,  318, 470,  344, 450,
    330,  1272, 328, 1266, 338, 1256, 330, 1264, 330, 1266, 328, 1264,
    330,  1264, 324, 1270, 328, 466,  330, 458,  320, 470,  258, 538,
    332,  468,  332, 1300, 276, 1278, 332, 1260, 330, 1264, 284, 1310,
    332,  1298, 278, 1278, 330, 464,  330, 464,  330, 460,  318, 472,
    328,  474,  332, 462,  330, 472,  332, 458,  318, 1278, 332, 1268,
    330,  1256, 332, 1260, 330, 1264, 324, 1272, 332, 1260, 330, 1262,
    332,  460,  330, 462,  332, 460,  320, 470,  348, 446,  330, 470,
    330,  468,  330, 494,  276, 1280, 334}; // UNKNOWN 2D068800

    uint16_t rawData[307] = {
    3102, 1656, 404, 396,  324, 1262, 410, 390,  390, 402,  396, 1190,
    400,  398,  406, 1186, 406, 386,  390, 406,  372, 1218, 406, 1184,
    390,  1202, 406, 396,  320, 1266, 406, 392,  400, 1190, 408, 1182,
    408,  1188, 404, 398,  396, 390,  404, 382,  330, 464,  400, 1194,
    410,  1180, 408, 384,  392, 1202, 406, 388,  404, 1186, 392, 1200,
    408,  386,  404, 380,  332, 462,  402, 1208, 406, 386,  406, 1188,
    400,  404,  404, 390,  374, 1218, 358, 1236, 400, 1192, 404, 386,
    380,  1214, 404, 1190, 402, 390,  356, 1238, 412, 1184, 402, 1194,
    400,  1192, 400, 1190, 330, 458,  400, 396,  406, 1188, 400, 386,
    380,  412,  400, 396,  406, 390,  402, 1190, 400, 386,  400, 1198,
    402,  390,  410, 1192, 402, 1190, 402, 1196, 400, 1190, 400, 392,
    400,  1194, 390, 398,  398, 1200, 374, 414,  330, 462,  372, 434,
    394,  404,  376, 1214, 400, 392,  370, 428,  374, 1218, 374, 1220,
    396,  1196, 398, 1194, 360, 1234, 398, 394,  400, 1192, 390, 1202,
    396,  400,  368, 418,  358, 436,  398, 396,  366, 432,  346, 1248,
    346,  1250, 346, 1242, 350, 1248, 342, 1264, 324, 468,  324, 1252,
    366,  1242, 344, 448,  326, 466,  330, 460,  326, 468,  346, 452,
    344,  1250, 342, 448,  336, 472,  352, 444,  342, 452,  320, 468,
    346,  1252, 334, 1260, 334, 1260, 334, 1258, 334, 1262, 336, 1256,
    338,  1262, 336, 1258, 334, 458,  336, 458,  336, 494,  282, 470,
    346,  446,  336, 1262, 334, 1262, 340, 1254, 338, 1254, 334, 1260,
    336,  1258, 336, 1258, 340, 450,  330, 464,  334, 462,  334, 498,
    282,  466,  324, 468,  334, 464,  336, 458,  334, 1260, 256, 1336,
    336,  1256, 334, 1258, 336, 1262, 332, 1262, 284, 1316, 334, 1260,
    336,  450,  306, 502,  342, 456,  336, 460,  334, 454,  322, 472,
    330,  484,  334, 464,  334, 1258, 322}; // UNKNOWN 582513D0

What brand/model IR demodulator are you using?

CHQ1838 (I guess it's quite similar to the VS1838B so it might cause problems too?)

Circuit diagram and hardware used (if applicable)

Screenshot 2024-09-06 at 01 00 44

You can't see it here because Wokwi doesn't have IR transmitters, but GPIO13 is connected to the data pin of the IR led

Thanks for the great work on the library!

NiKiZe commented 2 months ago

Does the AC not respond to these commands? It is quite common that the library don't decode every message, it is quite restrictive in what it accepts because it tries to decode many protocols, but actual units does decoding differently.

Note that you do need a transistor to drive the LED, I assume this is included in your driver board, but if it isn't I wouldn't expect that you get any working signal.

ptoffy commented 2 months ago

Does the AC not respond to these commands?

No it does not, although I am somewhat far away from the AC, so the next thing I would have tried after getting the decoding to work would have been to get closer (the AC remote works though)

It is quite common that the library don't decode every message

Not even the ones sent by it?

Actually I don't have a transistor, but since the data gets sent and sometimes decoded correctly I assumed I was fine. I've also been using it for a while now and nothing's happened (not even overheating) so I should be fine? I might add one just in case

ptoffy commented 2 months ago

Actually, I've just tried and by moving closer it does work! I'm not sure why it would turn it off when using ac.on(), and on when using ac.off() but that's probably an error in my code so I'll figure it out. Thanks for looking into this

crankyoldgit commented 2 months ago

Yes, you will need the transistor!

See also: https://github.com/crankyoldgit/IRremoteESP8266/blob/5406737abf9ff0c8fbc379d99ecdd5d890df9abe/src/IRremoteESP8266.h#L990

NiKiZe commented 2 months ago

Does the AC not respond to these commands?

No it does not, although I am somewhat far away from the AC, so the next thing I would have tried after getting the decoding to work would have been to get closer (the AC remote works though)

It is quite common that the library don't decode every message

Not even the ones sent by it?

Actually I don't have a transistor, but since the data gets sent and sometimes decoded correctly I assumed I was fine. I've also been using it for a while now and nothing's happened (not even overheating) so I should be fine? I might add one just in case

This isn't an issue of overheating. First of the IR LED won't get enough power to being registered in most cases. And then there is the issue of burning up the gate related to that pin, something that happens over time. But is the LED connected directly, or is it on a board, you mention data pin, if there is no transistor on that board, the vcc pin is probably not connected to anything at all.

Don't expect the same device to get correct readings while sending, timings will just be quite of.

ptoffy commented 2 months ago

@NiKiZe Sorry I misread you for a resistor (if you couldn't tell, I'm quite new at this!). But no I don't have a transistor. I'm using a KY-005 module if that helps, of which the VCC is pinned to the 5V of the board and the data pin to a GPIO(14) port (all through a breadboard). Although it seems to be working fine now, do you think I still might need a transistor?

NiKiZe commented 2 months ago

So, yes, as I have seen it, vcc on that board isn't connected to anything. I'm surprised you get any reaction at all, but shure, short distance and perfect conditions might work, at least for a while until it suddenly doesn't.

crankyoldgit commented 2 months ago

The KY-005 probably has a transistor on it, but I can't tell for sure. As it has three inputs (VCC, GND, & [S]ignal) When driving the IR LED via just the GPIO pin, there is not enough current to power the IR LED properly. Hence why a transistor needs to be "switched" on/off a much higher current supply than the GPIO can deliver. i.e. Connecting it directly to VCC & GND. If you're getting a signal to work at more than 1 metre, then it will be using a transistor.

In short, see https://github.com/crankyoldgit/IRremoteESP8266/wiki#ir-sending

NiKiZe commented 2 months ago

Vcc is not connected to anything, unless you can verify there is a transistor on the board. (I can not find a picture showing that anywhere) image

https://www.electrothinks.com/2023/02/ky-005-infrared-transmitter-module.html?m=1#google_vignette

ptoffy commented 2 months ago

You're actually right, removing the VCC connection doesn't change anything. So is getting a transistor on the signal pin enough?

NiKiZe commented 2 months ago

As already mentioned , see https://github.com/crankyoldgit/IRremoteESP8266/wiki#ir-sending We can't really say more than we already have, as we focus on the software side, and not the electronics, there is better places for that (and more qualified), hope you understand.

ptoffy commented 2 months ago

Yes thank you!