What it solves
Direct MQTT publishing loses queued telemetry when connectivity or power disappears.
How it works
1Telemetry→2persistent append→3MQTT attempt→4ack or backoff
Use it when
Queue telemetry while a broker is offline
Retry failed publish attempts with backoff
Acknowledge delivered QoS 0 or QoS 1 messages
Quick Start
#include "iotspool.h"
iotspool_cfg_t cfg=iotspool_cfg_default(); iotspool_t *spool=NULL;
iotspool_init(&spool,&cfg,&store); iotspool_recover(spool);
/* Enqueue, peek a ready message, then ack only after publish succeeds. */Real scenarios
Queue telemetry while a broker is offline
A persistent store-and-forward queue appends messages before delivery and recovers pending records after restart.
Retry failed publish attempts with backoff
A persistent store-and-forward queue appends messages before delivery and recovers pending records after restart.
Acknowledge delivered QoS 0 or QoS 1 messages
A persistent store-and-forward queue appends messages before delivery and recovers pending records after restart.
Engineering evidence
- README documents Linux, ESP32 and STM32 targets plus tests and an adoption-test brief
Known limits
- Uses an external MQTT client rather than implementing one
- Durability depends on the selected storage backend contract
- Application supplies time and publish-loop integration