Modifications
What I changed on the gateway — and why every change has an incident behind it, not a wish list.
Out of the box a gateway is mute: it does radio, and you hear nothing about it. Is it still running? Are packets arriving? How warm is it inside the enclosure? Everything that was added here answers one of those questions — and every change has an incident behind it, not a wish list.
The gateway speaks MQTT
The biggest addition: a monitoring program of my own runs alongside the packet forwarder and continuously publishes what it sees — to my own broker, not into somebody else's cloud.
What arrives there, in four groups:
- State — online, internet reachable, forwarder running, heartbeat, enclosure temperature, humidity and pressure
- System — CPU temperature, load, memory, swap and the fill level of the SD card, the last one as an early warning
- Traffic — message counters, time of the last message, uptime and restarts of the forwarder
- Statistics — unique devices per hour and per day, broken down by network and by spreading factor
The Home Assistant registration came about on the side. The gateway announces itself there by itself instead of you entering every value by hand — it works, but I do not use it at all: my visualisation runs through EisBär, which reads the topics directly. That part fell out anyway, because the values had to be cleanly named and described regardless. Anyone using Home Assistant gets it for free.
A "last will" for the outage
The most important addition is the least conspicuous one. A device that crashes can no longer report that it crashed — which is exactly when you would want the report.
MQTT has the Last Will and Testament for this: on connecting you leave a message behind that the broker sends when the connection drops. The gateway does not announce its own death; the broker announces it on its behalf. Without that, the last value stays on "online" forever, and the display looks splendid while the device is cold.
Counters that make a standstill visible
A gateway receiving nothing looks like a gateway with nothing to do right now. So counters run alongside: seconds since the last message, uptime of the forwarder, number of its restarts. Only those numbers tell "quiet" from "dead".
Restart with a brake
If the forwarder crashes it restarts — but not immediately and not endlessly fast. The wait grows from five seconds to five minutes. A service restarting itself every second mostly produces log lines and hides the cause.
Plus a watchdog that restarts the forwarder when the public address has really changed — not on every twitch of name resolution.
Display and lights
The OLED shows address, state and counters. The four LEDs show the same in passing. That sounds like a gimmick but is the fastest route to an answer to "is it still running?" — faster than any login.
And what went wrong along the way
The more honest half of the report. A selection:
- An error topic without a device id — the messages landed somewhere nobody was looking.
- A brief dropout of the temperature sensor flooded the log with identical messages. Now only a change of state is reported, not every attempt to read.
- The reconnect to the broker called a method with the wrong spelling — Python only notices at runtime, and precisely when the connection has dropped. So at the worst possible moment.
- SIGTERM was not handled. A cleanly stopped program left exactly the same impression as a crashed one.
- And finally the Raspberry Pi itself died — not the SD card, not the software. The cause was a firmware interface that stopped answering requests, triggered by the CPU changing clock speed. Since then the clock is fixed, and the query that hung back then sits in a thread of its own — it can now block at most itself, no longer the whole monitoring.