Does MQTT QoS guarantee that a gateway keeps every reading during an outage?
MQTT QoS defines message delivery between MQTT peers. Keeping measurements collected while a gateway cannot connect also requires a local recording and replay mechanism. Check storage capacity, power-loss behaviour, record timestamps and how the receiving application handles retries on the selected hardware and firmware.
Discuss the data path to your existing platform- Sensor or PLC
Read a value with its original time
- Local queue
Keep unsent records through an outage
- 4G / MQTT
Resume delivery when the link returns
- Application
Check identity, then save the record
Start with the gap the operator actually sees
A pump station sends useful readings all morning. Its cellular link then disappears, although the instruments and controller keep running. When service returns, a current value appears on the dashboard. The missing hours may still be missing. Ask whether the job needs only the latest state, a complete trend, or an event history. Those are different requirements, and a communications gateway can meet one without meeting the others.
Find out where measurements are recorded
Draw the path from the instrument to the destination: polling, local recording, upload, broker and application storage. Give each step an owner. A router that transports serial data may depend on a remote server to initiate reads; when that server is unreachable, there may be nothing recorded locally. An acquisition device with scheduled polling can keep taking readings, provided its firmware also has the required recording function. Ask for a demonstration using the intended register list and firmware version.
Separate MQTT delivery from application history
The OASIS MQTT specification defines QoS 0, 1 and 2. QoS 1 permits duplicates; QoS 2 applies between the participating MQTT peers. Neither setting alone describes how a sensor is sampled during a disconnected period or how a business database saves the data. Give each measurement a stable identity and retain its original time. The application can then recognize a retried record and keep old measurements from appearing as new events.
Size the queue against a stated outage
Suppose an example station creates one record each minute and must cover a 12-hour link interruption. That is 720 records before allowing for recovery time and additional events. Record size, flash capacity, reserved space and the storage-full policy still need checking. Ask whether the queue is in memory or persistent storage, and when a record is committed. Also decide whether replayed history or fresh measurements take priority after reconnection. These choices affect what the operator sees first.
- Record the sampling interval separately from the upload interval.
- Specify what happens when storage becomes full.
- Keep queue depth and the age of the last received reading visible.
Test the whole chain before expanding
Disconnect the network while sampling continues, restore it, and compare the collected and received record counts. Repeat with a restart while records are waiting. Include a broker connection failure and an application-side rejection; they exercise different parts of the path. Inductive Automation’s store-and-forward documentation illustrates memory buffering and disk caching for database writes in its own software. A gateway feeding that software needs its own review: one cache does not automatically protect every earlier step.
Send a brief the integration team can use
Share the controller or sensor interface, the fields you need, sampling frequency, expected outage duration and your destination. State whether alarms need to distinguish a late event from a current fault. We can then compare a simple transport device with an acquisition gateway and any additional integration work. Ask the proposal to name the queue, replay rules, platform responsibilities and agreed recovery test.
| Requirement | Check in the proposed configuration |
|---|---|
| Latest state after reconnection | Fresh polling and an explicit stale-data indication |
| Continuous measurement history | Local sampling, persistent queue and timestamped replay |
| No duplicate records in the database | Stable record identity and application handling of retries |
| History through a device restart | Commit policy and a tested restart with queued records |
Reference documents
Common questions
Is an MQTT acknowledgement the same as a saved database record?
It acknowledges the relevant MQTT delivery step. Confirm how the receiving application stores a record and how the project detects application-side failure.
Can a serial router provide offline history?
Some configurations may support recording, but serial transport alone does not establish that function. Check local polling, storage and replay on the exact firmware.
