¿ESP8266 como broker MQTT local para que los sensores sigan funcionando cuando se cae internet?
Traducido del English por IA ·
Un pequeño almacén más mi casa de al lado. Seis nodos ESP8266 (temperatura, dos contactos de puerta, una pinza amperimétrica para el congelador, un sensor de portón). Cada uno se conecta actualmente por sí mismo a Hermetry mediante MQTT/TLS.Problema: la internet del almacén se cae unas cuantas veces por semana, a veces durante una hora. Cuando eso pasa, los nodos pierden todo, y uno de ellos también controla un zumbador local que me gustaría que siguiera funcionando (portón abierto + congelador caliente = pitido).Encontré uMQTTBroker, que ejecuta un broker en un ESP8266. El plan sería: un ESP8266 como broker local, los nodos publican en él y algo reenvía a Hermetry cuando hay internet. ¿Alguien lo ha hecho? ¿Basta un ESP8266 para 6 clientes? ¿Y el broker de Hermetry puede conectarse como bridge a él o recibir mensajes retenidos después de una caída?
Small warehouse plus my house next door. Six ESP8266 nodes (temperature, two door contacts, a freezer current clamp, a gate sensor). Each one currently connects to Hermetry by itself over MQTT/TLS.
Problem: the warehouse internet drops a few times a week, sometimes for an hour. When it does, the nodes lose everything, and one of them also drives a local buzzer that I’d like to keep working (gate open + freezer warm = beep).
I found uMQTTBroker, which runs a broker on an ESP8266. Plan would be: one ESP8266 as local broker, nodes publish to it, something forwards to Hermetry when the internet is up. Has anyone done this? Is an ESP8266 enough for 6 clients? And can Hermetry’s broker bridge to it or receive retained messages after an outage?
Traducido del English por IA ·
Personalmente, no pondría la pieza que debe seguir activa en el chip más débil del edificio. Pero tengo curiosidad por saber qué hicieron los demás.
Personally I wouldn’t put the one piece that must stay up on the weakest chip in the building. But curious what others did.
Traducido del English por IA ·
uMQTTBroker funciona, lo estuve usando un rato. Sin TLS, y en mi caso se cayó con unos 8 clientes.
uMQTTBroker works, I ran it for a while. No TLS, and it fell over at about 8 clients for me.
Traducido del English por IA ·
¿Qué pasa con las alarmas de Hermetry cuando internet está caído? ¿Simplemente no se activan?
what happens to the Hermetry alarms when the internet is down? do they just not fire?
Traducido del English por IA ·
@Rachel no pueden, Hermetry no ve los datos hasta que vuelve la conexión. Por el mismo motivo mantenemos los enclavamientos locales en la planta y usamos la nube para avisos e historial. Tu lógica del zumbador debe estar en planta.
@Rachel they can’t, Hermetry never sees the data until it comes back. Same reason we keep local interlocks on the shop floor and use the cloud for notices and history. Your buzzer logic belongs on site.
Traducido del English por IA ·
Probé exactamente lo de uMQTTBroker en casa el año pasado y lo dejé, luego hice esto, que lleva 8 meses funcionando bien. No soy experto, así que tómalo como «lo que me funcionó a mí».Una Pi Zero 2 W con Mosquitto es el broker local. Los nodos ESP8266 publican en él por la LAN; el puerto 1883 sin cifrar está bien ahí porque nunca sale de casa. La lógica del zumbador es un pequeño script de Python en la Pi que se suscribe localmente, así que funciona sin nada de internet.Para Hermetry, la Pi es un dispositivo marcado como gateway (el interruptor «Este dispositivo es un gateway» al añadirlo). Un segundo script se suscribe a todo en el broker local, marca cada lectura con la hora de la Pi (sincronizada por NTP, compruébalo con timedatectl), las guarda en un archivo SQLite y las envía con paho-mqtt sobre TLS:
topic: v1/gw/telemetry
{
"freezer-1": [{"ts": 1762941600000, "values": {"temp": -18.6, "amps": 1.92}}],
"gate": [{"ts": 1762941605000, "values": {"open": 0}}]
}
Cada nodo se convierte en un dispositivo hijo con su nombre. Solo borra una fila de SQLite después del PUBACK. Cuando vuelve internet, envía el acumulado del más antiguo al más reciente, por lotes, y las lecturas se registran en su hora real en el historial.Dos cosas que aprendí a las malas. Hermetry ignora el flag de retain y no hace bridge a tu broker, así que no te apoyes en ninguno de los dos. Y un acumulado grande se vacía a la velocidad de «Replay messages per second» del perfil, así que tras un corte largo tarda un rato en ponerse al día; es normal.La página que seguí fue Devices behind a gateway.
I tried exactly the uMQTTBroker thing at home last year and gave up on it, then did this, which has been solid for 8 months. Not an expert, so take it as «what worked for me».
A Pi Zero 2 W running Mosquitto is the local broker. The ESP8266 nodes publish to it on the LAN, plain 1883 is fine there because it never leaves the house. The buzzer logic is a tiny Python script on the Pi that subscribes locally, so it works with no internet at all.
For Hermetry, the Pi is one device marked as a gateway (the «This device is a gateway» switch when you add it). A second script subscribes to everything on the local broker, stamps each reading with the Pi’s time (NTP-synced, check timedatectl), keeps them in a SQLite file, and sends them up with paho-mqtt over TLS:
topic: v1/gw/telemetry
{
"freezer-1": [{"ts": 1762941600000, "values": {"temp": -18.6, "amps": 1.92}}],
"gate": [{"ts": 1762941605000, "values": {"open": 0}}]
}
Each node becomes a child device by its name. It only deletes a row from SQLite after the PUBACK. When the internet comes back it sends the backlog oldest first, in batches, and the readings land at their real times in history.
Two things I learned the hard way. Hermetry ignores the retain flag and doesn’t bridge to your broker, so don’t build on either. And a big backlog drains at the profile’s Replay messages per second rate, so after a long outage it takes a while to catch up, that’s normal.
The page I followed was Devices behind a gateway.
- 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.

