ESP8266 comme broker MQTT local pour que les capteurs continuent de fonctionner quand Internet coupe ?
Traduit de English par IA ·
Petit entrepôt plus ma maison à côté. Six nœuds ESP8266 (température, deux contacts de porte, une pince de courant pour le congélateur, un capteur de portail). Chacun se connecte actuellement tout seul à Hermetry via MQTT/TLS.Problème : la connexion Internet de l’entrepôt coupe quelques fois par semaine, parfois pendant une heure. Quand cela arrive, les nœuds perdent tout, et l’un d’eux pilote aussi un buzzer local que je voudrais garder opérationnel (portail ouvert + congélateur chaud = bip).J’ai trouvé uMQTTBroker, qui fait tourner un broker sur un ESP8266. Le plan serait : un ESP8266 en broker local, les nœuds publient dessus, et quelque chose transmet à Hermetry quand Internet est disponible. Quelqu’un a-t-il déjà fait cela ? Un ESP8266 suffit-il pour 6 clients ? Et le broker de Hermetry peut-il se connecter en bridge à lui ou recevoir les messages retained après une coupure ?
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?
Traduit de English par IA ·
Personnellement, je ne mettrais pas l’élément qui doit impérativement rester actif sur la puce la plus faible du bâtiment. Mais je suis curieux de savoir ce que les autres ont fait.
Personally I wouldn’t put the one piece that must stay up on the weakest chip in the building. But curious what others did.
Traduit de English par IA ·
uMQTTBroker fonctionne, je l’ai utilisé un certain temps. Pas de TLS, et chez moi il a planté à partir d’environ 8 clients.
uMQTTBroker works, I ran it for a while. No TLS, and it fell over at about 8 clients for me.
Traduit de English par IA ·
Que se passe-t-il pour les alarmes Hermetry quand Internet est coupé ? Elles ne se déclenchent tout simplement pas ?
what happens to the Hermetry alarms when the internet is down? do they just not fire?
Traduit de English par IA ·
@Rachel ils ne peuvent pas, Hermetry ne voit jamais les données tant que la connexion n’est pas rétablie. Pour la même raison, nous gardons les verrouillages locaux à l’atelier et utilisons le cloud pour les notifications et l’historique. Ta logique de buzzer doit rester sur site.
@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.
Traduit de English par IA ·
J’ai exactement essayé le truc uMQTTBroker chez moi l’an dernier et j’ai abandonné, puis j’ai fait ceci, qui tourne sans problème depuis 8 mois. Je ne suis pas expert, donc prenez-le comme « ce qui a marché pour moi ».Un Pi Zero 2 W faisant tourner Mosquitto sert de broker local. Les nœuds ESP8266 publient dessus sur le LAN ; le port 1883 non chiffré convient ici, car rien ne sort de la maison. La logique du buzzer est un petit script Python sur le Pi qui s’abonne localement, il fonctionne donc sans aucune connexion Internet.Pour Hermetry, le Pi est un seul appareil marqué comme passerelle (l’interrupteur « Cet appareil est une passerelle » lors de l’ajout). Un second script s’abonne à tout sur le broker local, horodate chaque mesure avec l’heure du Pi (synchronisée par NTP, à vérifier avec timedatectl), les conserve dans un fichier SQLite et les envoie vers le cloud avec paho-mqtt sur TLS :
topic: v1/gw/telemetry
{
"freezer-1": [{"ts": 1762941600000, "values": {"temp": -18.6, "amps": 1.92}}],
"gate": [{"ts": 1762941605000, "values": {"open": 0}}]
}
Chaque nœud devient un appareil enfant portant son nom. Il ne supprime une ligne de SQLite qu’après le PUBACK. Quand Internet revient, il envoie l’arriéré du plus ancien au plus récent, par lots, et les mesures se placent à leurs heures réelles dans l’historique.Deux choses que j’ai apprises à mes dépens. Hermetry ignore le flag retain et ne fait pas de pont vers votre broker, donc ne vous appuyez sur aucun des deux. Et un gros arriéré se résorbe au rythme « Replay messages per second » du profil, donc après une longue coupure il faut un certain temps pour rattraper le retard, c’est normal.La page que j’ai suivie : 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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.

