Traducido del English por IA ·
Kevin tiene razón, y eso es solo la mitad. Nos encontramos con lo mismo en un parque eólico.El MQTT de Hermetry es 3.1.1, y un CONNECT con clean session en false se atiende como clean. No se encola nada para un dispositivo mientras está desconectado, salvo los comandos enviados como persistentes. Por tanto, no hay estado de sesión que reanudar, en ninguna dirección para la telemetría.Lo que Hermetry sí garantiza es en el sentido de entrada: el PUBACK solo se envía después de que el mensaje esté encolado de forma segura en su lado. Si no puede encolarse, no recibes PUBACK, la sesión se cierra y se espera que el cliente vuelva a enviarlo tras reconectar. Los duplicados con el mismo dispositivo, clave y marca de tiempo se almacenan una sola vez, así que reenviar es seguro.Así pues, el búfer es tuyo, y el patrón es:
- Escribe cada lectura en un almacenamiento local (nosotros usamos un archivo SQLite) con su propio ts en ms.
- Publica desde el almacenamiento y elimina una fila solo cuando llegue su PUBACK.
- Tras reconectar: suscríbete, solicita los atributos compartidos y luego envía el backlog antes de los datos en vivo.
Envía el backlog como arrays de {ts, values} para que llegue en los momentos correctos. El perfil tiene un límite separado de Mensajes de repetición por segundo para mensajes cuyos registros son todos anteriores a un minuto, así que un backlog largo se vacía en un tiempo. No te preocupes si no aparece todo a la vez.La página de MQTT tiene la sección de confirmaciones, vale la pena leerla una vez.
Kevin’s right, and that’s half of it. We hit the same thing on a wind site.
Hermetry’s MQTT is 3.1.1 and a CONNECT with clean session false is served as clean. Nothing is queued for a device while it’s offline, apart from commands that were sent as persistent. So no session state to resume, in either direction for telemetry.
What Hermetry does promise is on the way in: the PUBACK goes out only after the message is safely queued on their side. If it can’t be queued you get no PUBACK and the session closes, and the client is expected to resend after reconnecting. Duplicates of the same device, key and timestamp are stored once, so resending is safe.
So the buffer is yours, and the pattern is:
- Write every reading to a local store (we use a SQLite file) with its own ts in ms.
- Publish from the store, delete a row only when its PUBACK arrives.
- After reconnect: subscribe, ask for shared attributes, then send the backlog before live data.
Send the backlog as arrays of {ts, values} so it lands at the right times. The profile has a separate Replay messages per second limit for messages whose records are all older than a minute, so a long backlog drains over a while. Don’t panic when it doesn’t all appear at once.
The MQTT page has the acknowledgement section, worth reading once.

