Traducido del English por IA ·
Ejecutamos un servicio en Go en una caja edge de un parque solar que lee los inversores y publica en Hermetry mediante MQTT con QoS 1. El enlace es un router 4G que se cae unas pocas veces al día, normalmente entre 30 s y unos minutos.Mi modelo mental viene de cuando usábamos nuestro propio Mosquitto hace años: el broker persiste los mensajes QoS 1 en disco, el cliente se reconecta con clean session = false y se entrega todo lo que estaba en cola. Por eso puse CleanSession en false en el cliente y di por hecho que Hermetry guarda los datos en ambos sentidos por nosotros.Al revisar el historial tras una caída, veo huecos de exactamente la duración del corte. ¿El broker de Hermetry no persiste los mensajes? ¿Tengo que activar algún ajuste o el almacenamiento en búfer es responsabilidad mía?Lo que he comprobado hasta ahora: la pestaña Log del dispositivo muestra la desconexión con keepalive_timeout y una reconexión unos minutos después, como se esperaba. Los logs de nuestro cliente indican que las publicaciones durante el corte devolvieron respuesta sin error, y eso me hizo pensar que el broker las tenía. Las lecturas de los inversores se envían cada 30 s, con un ts tomado del reloj propio del inversor (sincronizado por NTP), en el formato {«ts»: …, «values»: {…}}. Necesitamos que el historial esté completo porque el propietario del parque factura mensualmente a partir de él, así que cada pocos minutos perdidos al día cuestan dinero.
We run a Go service on an edge box at a solar site that reads inverters and publishes to Hermetry over MQTT with QoS 1. Link is a 4G router that drops a few times a day, usually for 30 s to a few minutes.
My mental model came from running our own Mosquitto years ago: the broker persists QoS 1 to disk, client reconnects with clean session = false, everything queued gets delivered. So I set CleanSession false on the client and assumed Hermetry holds things for us both ways.
Looking at the history after a drop I see gaps of exactly the outage length. Is Hermetry’s broker not persisting? Do I need to switch some setting on, or is the buffer my job?
What I checked so far: the device’s Log tab shows the disconnect with keepalive_timeout and a reconnect a few minutes later, as expected. Our client logs say the publishes during the outage returned without error, which is what made me think the broker had them. Inverter readings are every 30 s with a ts we take from the inverter’s own clock (NTP synced), sent as {«ts»: …, «values»: {…}}. We need the history to be complete because the site owner bills from it monthly, so a few minutes missing per day actually costs money.
Traducido del English por IA ·
Los huecos de exactamente la duración de la caída parecen indicar que no se publicó nada durante la caída, y no que el broker los perdiera. ¿Tu cliente encola siquiera los mensajes mientras está desconectado?
Gaps of exactly the outage length sounds like nothing was published at all during the outage, not like the broker lost them. Is your client even queuing while disconnected?
Traducido del English por IA ·
Buen punto. Paho Go usa el almacén en memoria por defecto. Yo había asumido que los encola mientras está sin conexión.
Good point. Paho Go with the default in-memory store. I’d assumed it queues while offline.
Traducido del English por IA ·
Desde el lado de la dirección: nuestro integrador nos dijo lo mismo sobre los huecos, y acabaron añadiendo almacenamiento en el equipo. No puedo darles los detalles, lo siento.
From the management side: our integrator told us the same thing about gaps, they ended up adding storage on the box. Can’t tell you the details, sorry.
Traducido del English por IA ·
Clean session false no servirá de nada en Hermetry de todos modos. Estoy bastante seguro de que la documentación dice que se sirve como clean session.
Clean session false won’t help on Hermetry anyway. I’m fairly sure the docs say it’s served as a clean session.
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.
Traducido del English por IA ·
Sí. El almacenamiento en memoria de Paho descartaba todo al desconectarse, así que la suposición de Maria también acertó. Puse un archivo bbolt delante del publicador, que se borra al recibir PUBACK, y para probarlo desconecté la antena 4G durante 5 minutos: el historial mostró los datos acumulados con las marcas de tiempo correctas unos 20 s después de reconectar. También eliminé la línea CleanSession=false, ya que no hacía nada.
Yep. The Paho memory store was throwing everything away on disconnect, so Maria’s guess was spot on too. Put a bbolt file in front of the publisher, delete on PUBACK, and pulled the 4G antenna for 5 minutes as a test: backlog showed up in history with the right timestamps about 20 s after reconnect. Removed the CleanSession=false line as well since it did nothing.
Traducido del English por IA ·
Una cosa más: limita el almacenamiento local. Una vez tuvimos un sitio desconectado durante 9 days y el disco se llenó. Las lecturas más antiguas que tu retención se rechazan de todos modos.
One thing to add: cap the local store. We had a site offline for 9 days once and the disk filled up. Readings older than your retention get refused anyway.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.