ESP8266 als lokaler MQTT-Broker, damit die Sensoren weiterlaufen, wenn das Internet ausfällt?
Von English mit KI übersetzt ·
Kleines Lager plus mein Haus nebenan. Sechs ESP8266-Knoten (Temperatur, zwei Türkontakte, ein Stromzangen-Sensor am Gefrierschrank, ein Torsensor). Jeder davon verbindet sich derzeit selbst über MQTT/TLS mit Hermetry.Problem: Das Internet im Lager fällt ein paar Mal pro Woche aus, manchmal für eine Stunde. Dann verlieren die Knoten alles, und einer von ihnen steuert außerdem einen lokalen Summer an, der weiterhin funktionieren soll (Tor offen + Gefrierschrank warm = Piepton).Ich habe uMQTTBroker gefunden, das einen Broker auf einem ESP8266 betreibt. Der Plan wäre: ein ESP8266 als lokaler Broker, die Knoten veröffentlichen dort, und etwas leitet bei bestehender Internetverbindung an Hermetry weiter. Hat das schon jemand gemacht? Reicht ein ESP8266 für 6 Clients? Und kann der Broker von Hermetry eine Bridge dorthin aufbauen oder nach einem Ausfall retained Messages empfangen?
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?
Von English mit KI übersetzt ·
Persönlich würde ich das eine Teil, das unbedingt laufen muss, nicht auf dem schwächsten Chip im Gebäude platzieren. Aber ich bin neugierig, was andere gemacht haben.
Personally I wouldn’t put the one piece that must stay up on the weakest chip in the building. But curious what others did.
Von English mit KI übersetzt ·
uMQTTBroker funktioniert, ich habe es eine Zeit lang betrieben. Kein TLS, und bei mir ist es bei etwa 8 Clients abgestürzt.
uMQTTBroker works, I ran it for a while. No TLS, and it fell over at about 8 clients for me.
Von English mit KI übersetzt ·
Was passiert mit den Hermetry-Alarmen, wenn das Internet ausgefallen ist? Lösen sie einfach nicht aus?
what happens to the Hermetry alarms when the internet is down? do they just not fire?
Von English mit KI übersetzt ·
@Rachel das können sie nicht, Hermetry sieht die Daten erst, wenn die Verbindung wieder da ist. Aus demselben Grund behalten wir die lokalen Verriegelungen in der Halle und nutzen die Cloud für Benachrichtigungen und Verlauf. Deine Buzzer-Logik gehört vor Ort.
@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.
Von English mit KI übersetzt ·
Ich habe letztes Jahr zu Hause genau das uMQTTBroker-Vorgehen ausprobiert und dann aufgegeben. Danach habe ich dies umgesetzt, und es läuft seit 8 Monaten stabil. Ich bin kein Experte, also betrachte es als „was bei mir funktioniert hat“.Ein Pi Zero 2 W mit Mosquitto ist der lokale Broker. Die ESP8266-Knoten veröffentlichen im LAN dorthin, unverschlüsselt auf Port 1883 ist das dort in Ordnung, weil die Daten das Haus nie verlassen. Die Summerlogik ist ein kleines Python-Skript auf dem Pi, das lokal abonniert, es funktioniert also ganz ohne Internet.Für Hermetry ist der Pi ein einzelnes Gerät, das als Gateway markiert ist (der Schalter „Dieses Gerät ist ein Gateway“ beim Hinzufügen). Ein zweites Skript abonniert alles auf dem lokalen Broker, versieht jeden Messwert mit der Zeit des Pi (per NTP synchronisiert, prüfbar mit timedatectl), speichert sie in einer SQLite-Datei und sendet sie per paho-mqtt über TLS nach oben:
topic: v1/gw/telemetry
{
"freezer-1": [{"ts": 1762941600000, "values": {"temp": -18.6, "amps": 1.92}}],
"gate": [{"ts": 1762941605000, "values": {"open": 0}}]
}
Jeder Knoten wird anhand seines Namens zu einem untergeordneten Gerät. Eine Zeile wird erst nach dem PUBACK aus SQLite gelöscht. Wenn das Internet zurückkehrt, sendet es den Rückstand vom ältesten zum neuesten in Stapeln, und die Messwerte landen mit ihren echten Zeitstempeln in der Historie.Zwei Dinge habe ich auf die harte Tour gelernt. Hermetry ignoriert das Retain-Flag und überbrückt nicht zu deinem Broker, also verlasse dich auf keines von beiden. Und ein großer Rückstau wird mit der Rate „Replay messages per second“ des Profils abgebaut, daher braucht es nach einem langen Ausfall eine Weile, bis der Rückstand aufgeholt ist. Das ist normal.Die Seite, der ich gefolgt bin, war 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.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.

