Prolonged MQTT connection failures (30-60+ min) to mqtt3.thingspeak.com despite correct config and confirmed-healthy network

Title: Prolonged MQTT connection failures (30-60+ min) to mqtt3.thingspeak.com despite correct config and confirmed-healthy network

Hi all,

I'm running an industrial IoT gateway (WECON V-BOX, Lua scripting) publishing energy metering data (PM710 meter via Modbus RTU) to a private ThingSpeak channel over MQTT (mqtt3.thingspeak.com:1883), on a 4G cellular connection, one publish per 60s cycle.

Setup:

- QoS 0, CleanSession=1, no Will flag, correct topic format (channels/<id>/publish)

- Update rate well within the free/student license limit (60s vs 15s minimum)

- Persistent MQTT connection with a preventive renewal every 15 publications (close + recreate the client object)

- Tested keepalive=60 and keepalive=90 (both with the same underlying issue)

Symptom: intermittently, the client gets stuck failing to (re)connect for extended periods -- I've logged individual episodes lasting 8, 27, and even 58 minutes, with repeated connect() attempts returning "Operation failure" every cycle, before eventually recovering on its own without any configuration change.

What I've already ruled out:

- Site/cellular connectivity: I have an independent, parallel monitoring path (WECON's own V-NET platform, reading the same gateway but NOT going through MQTT/ThingSpeak at all) that shows ~99-100% data continuity during these exact windows where ThingSpeak shows 0% -- so the 4G link itself is healthy during these episodes.

- Publish-side rejection: publish() succeeds 100% of the time when connected (no rejected messages, no rate-limit errors).

- Basic MQTT config errors (checked against the official troubleshoot-MQTT-publish checklist: correct broker address/port, QoS 0, CleanSession=1, no Will flag).

Questions:

1. Does ThingSpeak's MQTT broker enforce any rate limit or temporary lockout on CONNECT attempts (as opposed to the documented publish rate limit)? I.e., could repeated failed connection attempts from the same client ID cause the broker to temporarily refuse further attempts?

2. Is there a known minimum time the broker needs to fully release a previous session (same Client ID, CleanSession=1) before accepting a new CONNECT, beyond what a normal disconnect()/close() sequence would provide?

3. Are there known issues or best practices specific to WECON V-BOX / embedded Lua MQTT clients connecting to ThingSpeak?

4. Is there any server-side logging or status page I could check for a specific device/client ID to see the broker's-eye view of why a CONNACK was refused during one of these episodes?

Any pointers, even partial, would be much appreciated -- this is for a doctoral research project measuring IoT gateway availability, so I have detailed logs (timestamps, consecutive failure counts, episode durations) if that's useful context.

Thanks in advance.

[Vinod]

If you can please share the detailed logs by email to vcherian<at>mathworks <dot>com, that will be helpful for me to compare with server logs.

Answer 1

[Vinod]

Hi @jorge,

Thank you for doing the basic debugging and clarifying that once the connection is made, publishes work reliably.

Since I do not have acces to the same network or WECON V-NET platform,we will need to work together to collect information that will help get to the bottom of why your connection is being rejected. There is nothing server side that explains to me the behavior you are seeing. My recommendation is to start cutting out the as many layers in the middle to see what is going on. Could you share an Arduino/ESP8266/ESP32 sketch, perhaps derived from this one that demonstrates the problem? Is it possible to potentially modify the ESP32 Lua example with the script you have and share that so we can look to use that as a starting point, cutting out the WECON V-NET platform?

Thanks, Vinod.