Firmware, GPAD_API, Frequent Client.connect(), Blocking Status LED, Rev 0.48

[ForrestErickson]

Describe the bug
A clear and concise description of what the bug is.
Short Summary of the expected behavior:
On MQTT loss of client expect smooth fast reconnect

Short Summary of the buggy behavior:
Long periods of time spent failed connection and trying to reconnect.

I observed that the status LED is frequently blocked.

Once the client reconnects there is a burst of activity on the serial monitor.

Test with "i" command

I sent the I command through MQTT from the PMD_PROCESSING_MQTT sketch.
Once the Krake reconnected there were two bursts of I information in the PMD console.

I observed that on the Serial Monitor there were also two instances of "i" command reported.

public.cloud.shiftr.io lost MQTT at: 33574387
Attempting MQTT connection at: 33574387..... failed, rc=-4Attempting MQTT connection at: 33590669..... failed, rc=-4Attempting MQTT connection at: 33607260..... success669..... failed, rc=-4Attempting MQTT connection at: 33607260..... success at33617224
connected!
Topic arrived [F4650BBB3ED8_ALM] |i|
Received MQTT Msg.
Command: i
Firmware Version: 0.48
GPAD API Version: 0.1.0
System up time (mills): 33910965
Mute Status: NOT MUTED
Current alarm Level: 3
Current alarm message: a3
IP Address: (0,0,0,0)
currentlyMuted : 0
interpret Done
a3
dfPlayer.play
3
PlayNotBusyLevel
HIGH .next called! =================
Number:4 Play Finished!
Topic arrived [F4650BBB3ED8_ALM] |i|
Received MQTT Msg.
Command: i
Firmware Version: 0.48
GPAD API Version: 0.1.0
System up time (mills): 33927299
Mute Status: NOT MUTED
Current alarm Level: 3
Current alarm message: a3
IP Address: (0,0,0,0)
currentlyMuted : 0
interpret Done
a3
dfPlayer.play
3
PlayNotBusyLevel
HIGH .next called! =================
Number:4 Play Finished!
public.cloud.shiftr.io lost MQTT at: 33957296
Attempting MQTT connection at: 33957296..... success at33966961
connected!

To Reproduce
Steps to reproduce the behavior:
Desk top shot showing the VSCode, the PMD console and the PMD control window.

Hardware description
Model: Krake
Serial Number: US0009
Other: GPAD_API set for broker "public.cloud.shiftr.io"

Test Equipment
PMD Sketch at:
https://github.com/PubInv/krake/tree/main/PMD/PMD_Processing_MQTT

Additional context
Add any other context about the problem here.

CC:
@TheBakedPotato

[ForrestErickson]

An AI suggests the following:

Advanced Status Checking
If you need more detail than a simple "true/false," use the state() method to see exactly why the client is no longer connected:
myDevices
myDevices
+2
State Constant Value Description
MQTT_CONNECTED 0 Connected successfully
MQTT_CONNECT_BAD_PROTOCOL -1 The server doesn't support the requested version of MQTT
MQTT_CONNECT_BAD_CLIENT_ID -2 The server rejected the client ID
MQTT_CONNECT_UNAVAILABLE -3 The server was unable to accept the connection
MQTT_CONNECT_BAD_CREDENTIALS -4 The username or password was rejected
MQTT_CONNECT_UNAUTHORIZED -5 The client was not authorized to connect
MQTT_CONNECTION_TIMEOUT -4 The server didn't respond within the keep-alive time
MQTT_CONNECTION_LOST -3 The network connection was broken

And also warns:

Common Causes for Disconnects
Keep-Alive Timeout: If your code has long delay() calls or blocking functions, it may fail to call client.loop() frequently enough, causing the broker to drop the connection.
Duplicate Client IDs: If two devices connect with the same Client ID, the broker will kick the first one off when the second one joins.
WiFi Drops: On boards like the ESP32 or ESP8266, the underlying WiFi connection may drop, which automatically kills the MQTT connection.
Packet Size: Sending a message larger than the MQTT_MAX_PACKET_SIZE (default 128 or 256 bytes) can cause an immediate disconnect.

@TheBakedPotato
The "Keep-Alive Timeout: If your code has long delay() calls or blocking functions, it may fail to call client.loop() frequently enough, causing the broker to drop the connection." sounds like something to check into.
The Krake was not having this problem until about version 0.46 or so.
Could there have been a change which caused longer delays between calls to client.loop()?

[ForrestErickson]

An AI suggests the following code for reconnect which reports status and which is non blocking during the reconnect.

#include <WiFi.h>
#include <PubSubClient.h>

WiFiClient espClient;
PubSubClient client(espClient);
unsigned long lastReconnectAttempt = 0;

void setup() {
  Serial.begin(115200);
  client.setServer("your.mqtt.broker", 1883);
}

void loop() {
  // 1. Check if we are still connected
  if (!client.connected()) {
    unsigned long now = millis();
    
    // 2. Only attempt reconnect every 5 seconds (non-blocking)
    if (now - lastReconnectAttempt > 5000) {
      lastReconnectAttempt = now;
      
      Serial.print("Attempting MQTT connection... ");
      if (reconnect()) {
        lastReconnectAttempt = 0;
      } else {
        // 3. Get detailed status code if connection failed
        int errorCode = client.state();
        printMQTTError(errorCode);
      }
    }
  } else {
    // Client is connected, process incoming messages
    client.loop();
  }
}

boolean reconnect() {
  if (client.connect("UniqueClientID")) {
    Serial.println("Connected!");
    client.subscribe("inTopic");
    return true;
  }
  return false;
}

void printMQTTError(int state) {
  switch (state) {
    case -4: Serial.println("Fail: Connection Timeout"); break;
    case -3: Serial.println("Fail: Connection Lost"); break;
    case -2: Serial.println("Fail: Connect Failed"); break;
    case -1: Serial.println("Fail: Disconnected"); break;
    case 1:  Serial.println("Fail: Bad Protocol"); break;
    case 2:  Serial.println("Fail: Bad Client ID"); break;
    case 3:  Serial.println("Fail: Unavailable"); break;
    case 4:  Serial.println("Fail: Bad Credentials"); break;
    case 5:  Serial.println("Fail: Unauthorized"); break;
    default: Serial.print("Fail: Unknown State "); Serial.println(state); break;
  }
}

[ForrestErickson]

With the help of an AI I have written a sketch which connects to the shifterio serve and reconnects. It subscribes to a topic to which the PMD publishes and has been tested to work reliable.

Serial Monitor shows connection and MQTT traffic

The Sketch:

ConnectionStatusMonitoringMQTT.zip

[ForrestErickson]

@TheBakedPotato
Juhandre,
Could you review the program flow of this example ConnectionStatusMonitoringMQTT.zip ?
Could you review the program flow of the GPAD_API and find a fix for the frequent loss of the MQTT broker?

I guess we should work in this branch.
I have pushed all of my changes and probably will not make more. If I have some insight and make more changes, I will leave some notes here in this issue.

Lee

CC: @nk25719

[ForrestErickson]

The AI summary of our work:

This is working.

I hope you can learn from this to help others.
That is great news! I’m glad we got your ESP32 stable, connected, and talking to the Shiftr.io broker.
To recap the "lessons learned" from your troubleshooting session—which are the most common pitfalls with the PubSubClient library:
WiFi First: Never call client.connect() before WiFi.status() == WL_CONNECTED. It triggers a low-level TCP stack crash (the Invalid mbox error).
Credentials in Connect: Authentication (user/pass) must be passed inside the .connect() method, not the .setServer() method.
The Callback Hook: client.setCallback() must be called in setup() for the library to know where to send incoming data.
Non-Blocking Loops: Using millis() instead of delay() for reconnection attempts keeps the ESP32 responsive and prevents it from being kicked by the broker for a timeout.