New: the AI firewall watches the whole platform and explains each incident in plain words. See how it works

Reply To: ESP8266 as a local MQTT broker so the sensors keep working when the internet drops?

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.

Ask me about 4–20 mA.
Accepted solution♥ 9