ESP32 MQTT client keeps disconnecting and reconnecting every few seconds: what causes it?

The clue is that a second board makes it worse: both are almost certainly connecting with the same client ID. A broker allows one connection per client ID; when a new connection arrives with an ID that is already in use, it closes the old one. Each board's reconnect then kicks the other off, in an endless loop. The Mosquitto log reports the client as already connected and says it is closing the old connection.

Make the ID unique per device, for example by building it from WiFi.macAddress() or the chip ID rather than a fixed string in the sketch.

The second common cause is the keep-alive. The client must exchange a packet with the broker within every keep-alive interval, and with PubSubClient that only happens inside client.loop(). The library's default keep-alive is 15 seconds. If your main loop blocks, for instance with delay(30000) between readings or a slow sensor read, no ping is sent, and the broker drops the connection after one and a half intervals, about 22 seconds.

Call client.loop() on every pass of the main loop and time the 30 second publishing with millis() instead of delay(). If long blocking is unavoidable, raise the interval with setKeepAlive().

The missing large messages are a buffer limit, not a network fault. PubSubClient builds each packet in a fixed buffer, 256 bytes by default in current versions, and that must hold the topic, the payload and the header. A publish that does not fit returns false and sends nothing.

Check the return value of publish(), and enlarge the buffer with client.setBufferSize(1024) or whatever your largest message needs. Also note that this library publishes at QoS 0 only, so a message sent during a brief disconnection is lost without any error.

Make the reconnect logic non-blocking and tolerant. A while (!client.connected()) loop that retries immediately can hammer the broker and starves the rest of the program. Try once, and if it fails wait a few seconds before the next attempt, increasing the wait up to a limit. Check Wi-Fi first: if WiFi.status() is not connected, an MQTT connect attempt cannot succeed, and the underlying cause may be weak signal or a power supply that sags during transmit bursts.

After every reconnect, subscribe again. With a clean session the broker forgets the subscriptions when the connection drops, so a node that publishes happily may have stopped receiving commands.

Use the diagnostics on both sides to confirm which case you have. On the device, print client.state() after a failed connect; the library documents the codes, which distinguish a network timeout from a refused connection such as bad credentials.

On the broker, watch the Mosquitto log: a keep-alive problem appears as a client that has exceeded its timeout, while the duplicate-ID case shows the old connection being closed. Those two lines tell you what to fix before changing any code.