Unwanted RGB LED colour cycling

Official Hardware Nano Family Nano ESP32
1

I have a Nano ESP32 with two I2C sensors attached which delivers their measurements to an MQTT Broker. Recently, following a power cut the MQTT Broker became unavailable (it started up with a different IP address from that hard-coded in my sketch). Consequently the code jumps to a function to handle connection errors and either disconnects and reconnects the wifi, or disconnects and reconnects the MQTT Broker, and if neither work it tries to restart the ESP (though I don't think that works or is called because it doesn't seem to get restarted).

The tangible result is that RGB LED starts colour cycling, about once every 2 seconds or so.

This is annoying. The Nano is installed in the enclosure of an All-Sky Camera, a device which takes long exposure (30 seconds) photos of the whole sky with a 180 degree fish-eye lens. These are then put together into a movie at the end of the night. This RGB LED causes coloured patches to be reflected from the inside of the protective acrylic dome.

I solved the permanent power LED by removing it from the board and in principle I could do the same with this one, but i would prefer to find a more elegant solution. How can I disable this activity in software.

Thanks,
Richard

2

It is working! The part of your code that says "if (this) then red, if (that) then green, if (other) then blue" is seeing "this, that" and "other" and performing perfectly.

29-500_xl_2-785479987
29-500_xl_2-7854799872250×2251 203 KB

3

That may be the bootloader in idle mode, in which case there is nothing you can do about it except to avoid the restart.

Fix your program so that when the connection is lost, it displays a message and goes into a wait loop.

4

How are you doing that ?

5

This is the method which, it seems, is the source of the problem:

////////////////////////////////////////////////////////////////////////////////////////////////
void handleConnectionIssues() {
  bool mustRestart = false;

  if (WiFi.status() != WL_CONNECTED) {
    if (millis() - wifiConnectCheck > WIFI_CONNECT_INTERVAL) {  //try reconnecting
      Serial.println("Error connecting to MQTT Broker - WiFi not connected");
      Serial.println("Reconnecting WiFi");
      WiFi.disconnect();
      WiFi.reconnect();
      wifiRestartCount++;
      wifiConnectCheck = millis();
      MQTTpublishFail = false;
      MQTTloopFail = false;
      mustRestart = false;
    }
  } else {
    Serial.println("Error connecting to MQTT Broker - but WiFi is still connected");
    // try restarting mqtt
    Serial.print("Last MQTT error: ");
    Serial.println(lastMQTTerror());
    Serial.println("Trying to restart MQTT Client");
    if (!mqtt.disconnect()) {
      Serial.println("Can't disconnect MQTT Client - must restart Arduino");
      mustRestart = true;
    } else {
      if (!connectToMQTT()) {
        Serial.println("Can't restart MQTT Client - must restart Arduino");
        mustRestart = true;
      } else {
        Serial.println("Restarted MQTT Client");
        mqttRestartCount++;
        mustRestart = false;
      }
    }
  }

  if (mustRestart) {
    // it's still connected, MQTT restart didn't help, so try restarting
    Serial.println("Error connecting to MQTT Broker - must restart");
    Serial.println("Disconnecting WiFi");
    WiFi.disconnect();
    Serial.println("trying to disconnect MQTT");
    mqtt.disconnect();
    Serial.println("Restarting ESP");
    ESP.restart();
  }
}
6

Have a look here (under RGB)
and here where it tells you how to fix the code for a RGB led which has the colors in a different order.

Navigate to packages/arduino/hardware/esp32/<version>.

Open io_pin_remap.cpp in a text editor.

Find the following lines:

[LED_RED]   = 46,
[LED_GREEN] = 0,
[LED_BLUE]  = 45, // RTS
Edit them so they look like this:

[LED_RED]   = 46,
[LED_GREEN] = 45, // RTS
[LED_BLUE]  = 0,
Save the changes to io_pin_remap.cpp.

This shows the actual ESP32 pins where the LED is connected. I am not familiar with the ESP32-S3 that much but there is a chance that these are also strapping pins or may have pullups connected, or that it just cycles through it as part of the startup cycle (i was going to say bootloader, but it isn't a bootloader). In case of the latter you may be able to circumvent this by using different pin nrs or have a really long look through the rest of the core,