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.