WIfi can interfere with sending the IR commands (?)

[stardad60]

Excellent library!
I’m using the 288 bit protocols from the ir_Mitsubishi.h library on a Mitsubishi mini-split using a ESP82266 nodeMCU. External circuit is the recommended transistor driver to IR diode and recommended GPIO pin.

Apparently Wifi can interfere with the transmission of the commands. I’m assuming the WiFi activity is doing something with the timing because I can see that the IR command is still transmitting, it’s just not being recognized as a command on the AC unit. I isolated my trouble to the WIfi and now turn off the WiFi before sending the command. With Wifi off, the commands are working as expected. It’s a bit annoying to turn off and on the Wifi since I have a web based interface. Searching the discussions for interference I saw Bluetooth mentioned and CPU loading on an ESP32 too but nothing else. I think I’m implementing a pretty common application with a web interface to a controller; something I would have thought many other people would have tried and this would be commonly run into. Perhaps I’m missing something else that I can be enlightened with. Or is this common knowledge that just hasn’t been highlighted?

[crankyoldgit]

That's interesting. I haven't come across Wifi as being an issue before. There are plenty of projects (and our examples) that use Wifi and IR commands with no real reported issues. Doesn't mean there isn't a time for a first case or a report.

As I understand it (and that not an expert-level opinion), on the 8266 (a single CPU device), all the WiFi processing is done effectively in the background. e.g. during delay() or yield() calls. So, in theory, sending/transmitting an IR message shouldn't be interrupted. Do you have capture of a "corrupted" IR message it is producing at all? e.g. via a second ESP running IRrecvDumpV2, or an oscilloscope. It would be of use to find out when/where the message is being corrupted.

Do you have a simplified case/example code that reproduces it at all?

Have you tried wrapping your send call (i.e. sendMitsubishi()) with nointerrupts() & interrupts() at all? If so, did it still not work?

[stardad60]

Thanks for the reply.

Attached is simplified code that I used that isolated my problem. I just commented in and out the code with Wifi turn off before the ac.send().

The first thing I tried was bracketing with nointerrupts()/interrupts() and it did not help.
Sorry, no captures, I don’t have a scope or a spare NodeMCU for a capture at the moment.

HOWEVER…there is a twist. I have to amend this to qualify the term “WiFi” with “Struggling WiFi”.

As I was preparing the code for publication I noticed the network I hardcoded to was a WiFi extender that is a few rooms away from where this was all being tested. (Where I develop and where the AC is are in two different spots and I don’t always code to scan for the strongest signal). So I replaced the network ID with a closer WIfi signal and bingo, the commands worked consistently. When I change back to the wifi extender, the commands again did not work. I will also add ‘not work consistently’. I noticed if I kept at it, one or two commands would make it through…maybe 10%.

Now I can see why many folks would not see a problem. I too, am not familiar with the nodeMCU underlying wifi architecture and its use of resources to understand what might be happening. The weaken WiFi signal I’m sure is causing lots of retransmissions, perhaps the CPU gets involved and messes up the IRed transmission timing.

/* Simple Menu code for testing IR AC commands */
/* Don't forget to change SSID and PASSWORD to your own */

/* At bottom of sketch comment out (or in)  WiFi turning off before the ac.send() */


#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Mitsubishi.h>
#include <Time.h>

#include <ESP8266WiFi.h>
#include <ESPAsyncTCP.h>
#include <ESPAsyncWebServer.h>


const uint16_t kIrLed = 4;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRMitsubishiAC ac(kIrLed);  // Set the GPIO used for sending messages.
int singleshot = 0;
int temperature;
int acclock;
int timeron;
int timeroff;
int fanspeed;



// Wifi Setup
const char* ssid = "YOUR NETWORK";
const char* password = "YOUR PASSWORD";


void printState() {
  // Display the settings.
  Serial.println("Mitsubishi A/C remote is in the following state:");
  Serial.printf("  %s\n", ac.toString().c_str());
  // Display the encoded IR sequence.
  unsigned char* ir_code = ac.getRaw();
  Serial.print("IR Code: 0x");
  for (uint8_t i = 0; i < kMitsubishiACStateLength; i++)
    Serial.printf("%02X", ir_code[i]);
  Serial.println();
}

void setup() {
  ac.begin();
  Serial.begin(9600);
  delay(200);


  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  if (WiFi.waitForConnectResult() != WL_CONNECTED) {
    Serial.println("WiFi Failed!");
    return;
  }
  Serial.println();
  Serial.print("This device IP Address is: ");
  Serial.println(WiFi.localIP());

  configTime("CST+6CDT+5,M3.2.0/2,M11.1.0/2", "pool.ntp.org" );   //set local time to central time
  Serial.println("Local Time Configured.\n");


  // Set up what we want to send. See ir_Mitsubishi.cpp for all the options.
  Serial.println("Default state of the remote.");
  printState();
  Serial.println("Setting desired state for A/C.");
  ac.on();
  ac.setFan(1);
  ac.setMode(kMitsubishiAcCool);
  ac.setTemp(26);
  ac.setVane(kMitsubishiAcVaneAuto);
}

void loop() {

  Serial.println("Tests to send commands to A/C ...");
  Serial.println("Make sure the Serial Monitor is set to 'no line ending' to avoid double entries");
  Serial.println("");
  Serial.println("Menu..............");
  Serial.println("      1   Turn ON");
  Serial.println("      2   Turn OFF");
  Serial.println("      3   Enter temperature");
  Serial.println("      4   Set Clock");
  Serial.println("      5   Timer ... Set ON Time");
  Serial.println("      6   Timer ....Set OFF Time");
  Serial.println("      7   Set Fan Speed");

  Serial.println("Enter COMMAND:");
  while (Serial.available() == 0) { // Wait for User to Input Data
  }

  int AC_command = Serial.parseInt();
  delay(1000);
  singleshot = 1;

  Serial.print("You entered "); Serial.print(AC_command); Serial.print("\n");
  switch (AC_command) {

    case 1:
      Serial.println("You chose on!");
      ac.setTimer(kMitsubishiAcNoTimer);
      ac.on();
      Serial.println("Sending IR command to A/C ...");
      break;

    case 2:
      Serial.println("You chose off!");
      ac.off();
      Serial.println("Sending IR command to A/C ...");
      break;

    case 3:
      Serial.println("Enter temperature in Celsius: ...");
      while (Serial.available() == 0) { // Wait for User to Input Data
      }
      temperature = Serial.parseInt();
      Serial.print("You entered "); Serial.print(temperature); Serial.print("\n");
      ac.setTemp(temperature);
      break;

    case 4:
      Serial.println("Enter Clock: ...(10min increments past midnight ...):");
      while (Serial.available() == 0) { // Wait for User to Input Data
      }
      acclock = Serial.parseInt();
      Serial.print("You entered "); Serial.print(acclock); Serial.print("\n");
      ac.setClock(acclock);
      break;

    case 5:
      Serial.println("Enter Timer ON value ...(10min increments past midnight ...):");
      while (Serial.available() == 0) { // Wait for User to Input Data
      }
      timeron = Serial.parseInt();
      Serial.print("You entered "); Serial.print(timeron); Serial.print("\n");
      ac.setStartClock(timeron);
      ac.setTimer(kMitsubishiAcStartStopTimer);
      break;

    case 6:
      Serial.println("Enter Timer OFF value (10min increments past midnight ...):");
      while (Serial.available() == 0) { // Wait for User to Input Data
      }
      timeroff = Serial.parseInt();
      Serial.print("You entered "); Serial.print(timeroff); Serial.print("\n");
      ac.setStopClock(timeroff);
      ac.setTimer(kMitsubishiAcStartStopTimer);

      break;

    case 7:
      Serial.println("Enter FAN speed 1-6 value (6 is silent)...");
      while (Serial.available() == 0) { // Wait for User to Input Data
      }
      fanspeed = Serial.parseInt();
      Serial.print("You entered "); Serial.print(fanspeed); Serial.print("\n");
      ac.setFan(fanspeed);
      break;

    default:
      Serial.println("ERROR!!! Case statement fallthru?");
      Serial.print("Program sees a:"); Serial.print(AC_command); Serial.print("...end\n");
      break;

  }

  //WiFi.mode(WIFI_OFF);              //un-commenting this and below  makes the AC recognize the command
  delay(100);
  if (singleshot == 1) {
    ac.send();
    printState();
    singleshot = 0;
  }

  //WiFi.begin(ssid, password);       //un commenting this makes the AC recognize the command
  //if (WiFi.waitForConnectResult() != WL_CONNECTED) {
  //  Serial.println("WiFi Failed!");
  //  return;
  //}


  Serial.print("\n");


}

[crankyoldgit]

Hmm. Our examples don't use the Async libraries for http/web/TCP traffic etc. As you've seemed to have narrowed it down to an environmental issue, can you try using the normal/non-Async network functions etc? Try also with no ntp usage. i.e. Ditch the Time.h & configTime() perhaps.

I'm just guessing what could be causing the issue, as it should work with or without a good wifi connection.

Doing some reading, the default sync period for configTIme() is every 5 mins.

Also check out this setting:

IRremoteESP8266/src/IRremoteESP8266.h

Lines 888 to 894 in 1e2c1d8

	// Use millisecond 'delay()' calls where we can to avoid tripping the WDT.
	// Note: If you plan to send IR messages in the callbacks of the AsyncWebserver
	// library, you need to set ALLOW_DELAY_CALLS to false.
	// Ref: https://github.com/crankyoldgit/IRremoteESP8266/issues/430
	#ifndef ALLOW_DELAY_CALLS
	#define ALLOW_DELAY_CALLS true
	#endif // ALLOW_DELAY_CALLS

[stardad60]

I might have the answer….but first let me answer your questions for background.
Using my simple menu driven test sketch, I tried out the items you mentioned.
Eliminated the ntp hooks, played with the ALLOW_DELAY_CALLS option and eliminated the Async libraries and as far as I can tell, those changes didn’t make a big difference. (The sketch I’m using for testing is so simple though I don’t think a lot of the Async features other than the library inclusion is really in play). I then noticed another detail that probably is close to the answer.
On restarting the sketch (reset button) over and over, I find that IF the attempt at connecting to the Wifi is successful, I can happily send recognized commands to the AC consistently. That counters the struggling Wifi speculations, at least if it struggles after an initial connection. BUT if the attempt at the WiFi connection fails….then no IRed commands work, even though the commands still get transmitted (by observing an on board companion receiver) trying them over and over through the menu.

I do see something strange with that failure….. the code for checking the Wifi connection is below
if (WiFi.waitForConnectResult() != WL_CONNECTED) {
Serial.println("WiFi Failed!");
return;
}
I have no idea where I copied this from but I noticed there is a ‘return’ in the failure leg. I have no idea what that is doing there and worse, what executing a ‘return’ there really does. Oddly nothing crashes and the sketch seems to work (keep in mind this simple sketch does not really need wifi for it to function and send commands).
That return statement maybe pops the stack and just slightly screws something up (maybe in the IR code it self is a step out of sync) but not enough to crash. I eliminated the return statement and the now it looks like things always work. I haven’t had time to go back to the original program and clean things up though. Interestingly strange. Thanks for your ideas.

[crankyoldgit]

To understand what the return does, the Arduino framework is basically doing:

{
  setup();
  for (;;) {  // loop forever
    loop();
  }
}

When it hits the return; statement in the WiFi if clause, it will skip the rest of the the setup() procedure.
So, any setup done there will not be done.