Industrial Router Online, MQTT Not Publishing? Check the Task
Consider a pumping station where a local industrial router acquires pressure and water-level readings and runs an MQTT publishing task. It sends those readings to a remote broker; a platform obtains the data through a subscription. Reporting had been continuous, but the platform values have stopped updating. The router still shows a 4G/5G connection and can ping an external host.
In this configuration, the router is the publishing client, not the broker. An MQTT client can publish, subscribe, or do both; connecting to a broker does not make it only a receiver. See the MQTT 3.1.1 definitions in §1.2.
The first question is whether the local publishing task is still making progress, or whether it is attempting to send but failing during connection or publication. Internet access is only one network check. It does not answer that question.
This diagnostic path applies to a device that actually supports and is configured for local acquisition and MQTT publishing. Confirm the topology first. If the router only forwards a separate gateway's traffic, inspect the publishing task on that gateway. If it acts as a broker or subscriber, inspect that service in its actual role. For background on the roles and data path, see Wavetel's MQTT overview.
Trace one new sample to find the failing segment
Choose a measurement you can identify reliably. Record the time, identifier and publish topic for one new sample. Look for evidence at three checkpoints:
New sample generated → local task makes a publish attempt → the same new message appears on the remote broker's target topic.
Evidence found | Check next |
|---|---|
The local device has a new sample, but no subsequent publish attempt is recorded | The hand-off from acquisition to publishing, then the local publishing task |
The task keeps attempting to send, but connection or publish records show failures | The actual MQTT client connection, authentication and publish result between the local device and the remote broker |
The same new message appears on the broker's target topic | The subscription and platform-processing path |
If there is no new sample at all, return to the data source and acquisition task. If no publish attempt is visible, do not immediately conclude that the task has stopped: enable the diagnostics the device supports and confirm whether the step occurred.
Before changing anything, preserve logs from both sides of the incident, the client's uptime, broker address and port, client identifier and topic. If the device and broker clocks differ, record the offset so the same attempt can be correlated.
New samples, no publish attempt: inspect the local task
First establish whether the publishing service is running. If its process exited, record when it stopped, the error and any restart history. Restore the service through the supported maintenance procedure. Changing MQTT connection parameters will not restart a service that is no longer running.
If the process is present, inspect its last point of progress. Did the new sample reach the publishing task? Did encoding complete? Is the send queue or publish call advancing? A running process is not necessarily a progressing task. It may be waiting for data, a connection, a particular record or a retry. If it is waiting for the connection to recover, move to the connection checks below.
State the observation at the most specific step supported by the records. “Samples continue to update, but no new publish call is observed” is more useful than “MQTT is broken.” It is still not a root-cause finding; inspect the task state and errors next.
Publish attempts continue but fail: inspect the actual connection
Take the most recent failed publish attempt. Check the broker address and port the client actually used, the connection result, and the corresponding broker log at that time.
If the connection was not established, use the failure stage to inspect name resolution, TCP and, where enabled, TLS. For TLS, check device time, the trust chain and the server name. Disabling certificate validation is not evidence of a repair. A successful ping does not prove that the MQTT port or TLS handshake works.
If the broker refused the MQTT connection, compare the credentials actually used with the broker response. If the client connected but publication failed, inspect the topic, publish permission and client error. Match each failure to one check rather than changing several settings at once. For broader power, cellular and IP-path checks, see Wavetel's layered industrial-router troubleshooting guide.
Test under the local service's real network egress and configuration. A laptop test client that can publish proves only that test worked; it does not prove the router task used the same path, identity, topic or data source.
Finally, distinguish a client acknowledgment from a new message on the intended broker topic. MQTT 3.1.1 provides no publish acknowledgment for QoS 0. A QoS 1 PUBACK alone does not establish that publication was authorized, much less that the platform processed the data. The specification permits a broker to acknowledge an unauthorized publication according to normal QoS rules or close the connection. Check the broker's topic-message record, or observe the same new data through an authorized diagnostic subscription. See MQTT 3.1.1 §§3.3.4, 3.3.5 and 4.3.2.
Prove recovery with a fresh sample end to end
After preserving the incident records, restore the identified service or connection within the permitted maintenance scope. Do not stop at “online” or “connected.” Follow a new sample generated after recovery:
Confirm that local acquisition recorded the sample and initiated the corresponding publish attempt.
Confirm that the same message appeared on the remote broker's target topic, with matching acquisition time and data identifier.
Observe whether reporting continues at the expected interval and record any further manual intervention.
These are recommended verification steps, not a claim that a physical device has been tested. If the broker has the fresh sample but the platform still displays an older value, there is evidence for the local-to-broker leg. Continue with the subscription and platform-processing path instead of repeatedly restarting a local service that has completed its upload.
A useful hand-off identifies the observed boundary: “Local samples are fresh, but the publishing task has not made another publish call,” or “The task keeps trying, but the connection fails during TLS.” Attach the corresponding records and any verified recovery result so the next engineer knows which service to investigate.
FAQ
If the router connects to an external broker, must it be receiving data?
No. A client may publish, subscribe or do both. This example concerns a router publishing acquired readings to a remote broker. Confirm any subscription role from the actual configuration.
Why can a test client publish while the local task cannot?
The test client and local task may use different network egress, identities, topics or data sources. After a successful test, return to the local task: verify that a new sample triggered an attempt and check its actual connection and publish result.
If a restart restores uploads, is the incident resolved?
It shows that the reporting path works again, not why it stopped. Preserve the pre-restart task and connection records, confirm that new samples keep arriving at the expected interval, and record whether the symptom recurs.
