Ich denke, viele von euch werden über die Beiträge schon ein grobes Bild über mich und meine Familie haben. Jedoch bin ich daneben noch ehrenamtlich in der Freiwilligen Feuerwehr tätig und habe somit einen sogenannten Melder. Dieser alarmiert im Einsatzfall die Feuerwehrkräfte, damit den Menschen in Not auch geholfen werden kann.

Da ich mein Haus fast komplett heimautomatisiert habe, war die Überlegung, den Melder an dieser Stelle irgendwie in mein Smart Home zu integrieren. Hintergrund der Idee ist: Geht der Melder los, werden im Haus die Lichter bis zur Haustür bei Dämmerung und Nacht eingeschaltet und nach einer definierten Zeit wieder ausgeschaltet.

Doch um überhaupt einmal anzufangen, wird erst einmal eine Meldung via Telegram an mich gesendet. Wie dieses Projekt aktuell aussieht, was dabei zu beachten ist und was ein Maker, der ebenfalls auf so eine technische Spielerei Lust hat, bei diesem Beitrag mitnehmen kann, zeige ich dir hier. Interesse geweckt? Dann legen wir los!

⚠️ Wichtiger Hinweis: Dieser Beitrag basiert auf einem Melder der Firma Airbus Defence & Space, dem P8GR-Melder mit Dockingstation. Die Dockingstation hat ein frei zugängliches potentialfreies Schaltrelais, das als Privatperson verwendet werden darf. Die sogenannte Modemschnittstelle, also der USB-Anschluss, erkläre ich hier nicht, da diese für Privatpersonen nicht oder nur unter strengen Voraussetzungen freigeschaltet werden darf. Mit meinem Projekt kann daher weder mit dem Melder kommuniziert noch können irgendwelche Daten über diese Schnittstelle gesendet oder empfangen werden.

Verwendeter Melder

In diesem Beitrag wird, wie schon erwähnt, der Melder P8GR der Firma Airbus Defence & Space verwendet. Gerade in Hessen ist dieser der am meisten verwendete Melder. In einigen Bundesländern oder Landkreisen kann es aber zu Abweichungen kommen. Daher bitte vorab informieren, welcher Melder zum Einsatz kommt und welche Anschlussmöglichkeiten dieser bietet!

Hinweise und Voraussetzungen für diesen Blog

Wer diesen Beitrag komplett umsetzen will, der braucht einiges an Hard- und Software. Dein Maker-Büro sollte folgende Hard- bzw. Software haben, siehe Tabelle 1.

Tabelle 1: Benötigte Hard- und Software für das Projekt

Zusätzlich brauchst du noch einen MQTT-Broker. Hier gibt es verschiedene Varianten. Ich empfehle zu Anfang einen Raspberry Pi mit z. B. Docker und einem geeigneten Docker-Image. Hast du schon eine Hausautomation, so solltest du prüfen, ob im Hintergrund bereits ein MQTT-Broker läuft.

Für die Platine in diesem Beitrag werden zusätzlich die Bauteile aus Tabelle 2 benötigt.

Tabelle 2: Benötigte Bauteile für das Projekt

Damit abschließend die Platine mit dem D1 Mini und der Melder in der Dockingstation Strom bekommen, brauchst du noch ein USB-Kabel mit USB-Typ-B-Stecker und ein entsprechendes USB-Kabel für die Stromversorgung der Dockingstation.

Grundidee vom PagerAlarm

Die Grundidee von meinem Projekt ist recht simpel. Mit einem geeigneten Melder, in meinem Fall dem Airbus P8GR samt Dockingstation, greife ich das Signal bei einer Alarmierung ab. Umgangssprachlich hört man auch „Der Melder geht auf” oder „Der Melder geht los”. Diese Alarmierung wird über das Schließen des potentialfreien Relaiskontakts dem D1 Mini mitgeteilt.

Der D1 Mini verbindet sich mit dem MQTT-Broker und sendet an ein MQTT-Topic die Nachricht „on” oder eine von dir definierte Nachricht. Node-RED reagiert auf diese Nachricht, erstellt mir eine Telegram-Nachricht und sendet diese über einen Telegram-Bot an mich.

Nach etwa 30 Sekunden wird das MQTT-Topic durch meinen Node-RED-Flow wieder auf „off” zurückgesetzt. Der D1 Mini reagiert auch erst nach 40 Sekunden auf eine erneute Alarmierung, um unnötige Nachrichten zu vermeiden. Abbildung 1 zeigt den Ablauf der Idee.

Wichtig an dieser Stelle: Wir bekommen nur das Schaltsignal der Alarmierung und keinerlei Alarmierungsdetails über die Modemfunktion. Nur wenn der Pager auslöst, wird auch das Relais geschlossen. Damit „weiß” mein PagerAlarm, dass gerade eine Alarmierung erfolgt ist. Welche Art von Alarmierung vorliegt, kann das System aber nicht erkennen. Aus diesem Grund schreibt mir mein Telegram-Flow von Node-RED, dass ich für zusätzliche Informationen zur Alarmierung auf den Melder oder in die Alarmierungs-App gucken soll.

Die Telegram-Nachricht ist damit eine zusätzliche Alarmierung auf meinem Smartphone, aber sie ist von mehreren Komponenten abhängig. Bei einem Stromausfall sind meine Platine und damit das Projekt außer Betrieb. Der Melder selbst besitzt eine Batterie und funktioniert weiterhin. Sobald der Strom wieder vorhanden ist, startet auch der PagerAlarm automatisch neu. Ob MQTT und Node-RED ebenfalls automatisch wieder gestartet werden, hängt von der jeweiligen Konfiguration des Benutzers ab.

Fällt das WLAN aus, versucht der D1 Mini, die Verbindung wiederherzustellen. Ist das nicht erfolgreich, kann keine Benachrichtigung gesendet werden. Fällt MQTT aus, kann Node-RED nicht auf eine Meldung reagieren. Der D1 Mini schließt in diesem Fall den MQTT-Socket und versucht, die Verbindung neu aufzubauen. Ist Telegram selbst nicht erreichbar, bekomme ich ebenfalls keine Nachricht. Für die hier gezeigte Telegram-Benachrichtigung wird deshalb neben Strom und WLAN auch eine funktionierende Internetverbindung benötigt.

Die Verdrahtung

Solltest du nun nicht selbst eine Platine fräsen oder anfertigen lassen wollen, so möchte ich dir natürlich die grundlegende Verdrahtung zeigen.

Es gibt eine Spannungsversorgung von 5 V, die an den D1 Mini angeschlossen wird.

Um später das Relaissignal der Dockingstation zu bekommen, nutze ich einen Schraubanschluss, der mit D1 bzw. GPIO5 und Masse verbunden ist. Wichtig ist das, weil im Code dieser Pin als Pull-Up-Input definiert wird. Das bedeutet: Im Ruhezustand liegt der Pin auf HIGH, erst das schließende Relais zieht ihn auf Masse. D1 bzw. GPIO5 ist dabei der ALERT_PIN.

Die optionale LED wird mit einem 200-Ohm-Widerstand an Masse und D4 bzw. GPIO2 angeschlossen. In meiner aktuellen Konfiguration im GitHub-Repository steht LED_PIN auf None, die LED ist also deaktiviert. Möchtest du die LED auf der Platine nutzen, muss GPIO2 entsprechend als LED_PIN eingetragen werden.

Ursprünglich hatte ich dafür D3 vorgesehen. Dieser Pin kann den D1 Mini im ungünstigsten Fall allerdings in den Boot-Modus versetzen, weshalb die LED mittlerweile auf D4 bzw. GPIO2 liegt.

Wie schon geschrieben, die LED samt Widerstand ist im Code kein Muss!

In meinem Fall, da ich Steckplätze an meiner Mehrfachsteckdose sparen wollte, gibt es einen entsprechenden Spannungsausgang, welcher später die Dockingstation mit Strom und Spannung versorgen soll.

Wichtig hierbei ist: Prüfe, was die Dockingstation an Strom (A) benötigt, da der D1 Mini zwischen 70 mA und 400 mA Strom ziehen kann. Das verwendete 5-V-Netzteil muss ausreichend Leistung für D1 Mini und Dockingstation bereitstellen. Mit dem Airbus P8GR hat ein handelsübliches USB-Netzteil vollkommen ausgereicht.

Vom Steckbrett zum „Produkt”

Die kommenden Abschnitte erklären nun den Werdegang, wie aus der Breadboard-Spielerei der erste fertige Prototyp entstanden ist. Solltest du daran kein Interesse haben oder schon Hintergrundwissen zu KiCad, TARGET 3001!, Estlcam, 3D-Druck und Löten haben, dann ist dieser Teil wahrscheinlich eher uninteressant für dich. Du kannst an dieser Stelle gerne direkt zur Software springen.

Die Verdrahtung in KiCad und TARGET 3001! umsetzen

An dieser Stelle könnte man sich fragen, warum ich die Platine in TARGET 3001! und KiCad entwerfe. Der Grund dahinter ist ziemlich banal, es liegt an meinem Studium und Estlcam. Während meines Studiums musste ich schon Leiterplatten mit TARGET 3001! erstellen und bin damit noch immer vertraut.

Ein Nachteil an dieser Stelle: Es ist nur für Windows verfügbar und da ich mittlerweile komplett auf Linux umgestiegen bin, gibt es nur noch einen Computer, der unter anderem wegen TARGET 3001! mit Windows betrieben wird.

Der zweite Grund ist, dass die Frässoftware Estlcam ebenfalls nur für Windows verfügbar ist und das Konvertieren vom Platinenlayout in G-Code, dem Maschinencode für die CNC-Fräse, mit TARGET 3001! deutlich einfacher ist.

Aktuell arbeite ich aber verstärkt mit KiCad 10 und versuche mit FreeCAD und weiterer Software, die CNC-Fräse auch über Linux „gangbar” zu bekommen. Daher arbeite ich an dieser Stelle zweigleisig.

Das Gute bei diesem Projekt: Egal ob nun KiCad oder TARGET 3001!, beide Softwarelösungen sind kostenlos. TARGET 3001! bietet eine freie Version an, die auf Layer und Kontaktierung limitiert ist, aber auch schon in der Vergangenheit bin ich nicht einmal annähernd an dieses Limit gekommen. KiCad ist an dieser Stelle komplett kostenlos und macht in meinen Augen an einigen Stellen vieles besser als TARGET 3001!, was aber mein subjektiver Eindruck ist.

Egal, für welche Software du dich nun am Ende entscheidest, das Prinzip ist gleich. Zunächst erstellst du, wie in Fritzing, einen Schaltplan. Damit „weiß” das Programm, welcher Pin zu welchem Bauteil muss und wie die genaue Verdrahtung auszusehen hat.

Ein Vor- bzw. Nachteil ist da der große Bauteilkasten von KiCad. Allein schon die richtige Stiftleiste zu finden, kann eine Herausforderung sein. Zunächst suchst du das passende Symbol, musst aber später über den sogenannten Footprint – dieser wird wichtig bei dem Platinenlayout – das korrekte Bauteil heraussuchen.

TARGET 3001! macht es dir an dieser Stelle einfacher, da du explizit das Bauteil suchst. Problem ist aber, dass in TARGET 3001! leider der D1 Mini im Sortiment fehlt und dieser erst umständlich importiert werden muss. Ist das Bauteil aber einmal importiert, so kann es bei jedem Projekt wiederverwendet werden. Mit etwas Eingewöhnung in die jeweilige Software zeigt sich schon der erste Erfolg.

Ein Punkt an dieser Stelle noch: Beide Programme gehen unterschiedlich mit Änderungen im Layout um. Sprich: Ändere ich den Schaltplan, muss das Platinenlayout nicht zwangsweise Fehler aufzeigen. In KiCad musste ich teilweise eine entsprechende Prüfung manuell triggern.

Die Platine wird virtuelle Realität

Ist der Schaltplan fertig, kommt es zu dem aufwändigeren Teil: die Platine. Vom Prinzip „wissen“ die Programme, wie das Routing aussehen muss. Da aber die Platine so klein wie möglich sein sollte, ist es besser, die Bauteile per Hand zu platzieren und die Leiterbahnen ebenfalls „händisch” zu verlegen.

Sowohl KiCad als auch TARGET 3001! bieten für das Routing der Leiterbahnen Optionen an, damit rechtwinklige oder sauber geführte Leiterbahnen entstehen. In beiden Programmen kannst du auch Leiterbahnpunkte kreieren, um Masse an einem sinnvollen Platz auf der Platine zusammenlaufen zu lassen.

Hier muss ich TARGET 3001! den Vorteil zugestehen: Bauteile, Bohrungen und die eigentlichen Leiterbahnen lassen sich dort intuitiver platzieren. In KiCad habe ich anfangs echte Probleme gehabt, bis ich das Problem mit dem sogenannten „Footprint” herausgefunden hatte.

Wie man hier schon erkennen kann, sind nicht alle GPIOs irgendwie verbunden, sondern die Leiterbahnen sind so gezogen, dass auch nur die GPIOs zum Einsatz kommen, die benötigt werden. Durch das jetzt schon festgelegte Layout kriegt man eine ungefähre Vorstellung der Platine.

Noch besser ist natürlich ein gerendertes 3D-Modell der Platine, was sowohl KiCad als auch TARGET 3001! beherrschen.

Dabei werden auch, sofern es diese Modelle gibt, gleich die Bauteile an der korrekten Position dargestellt. So sieht man auch direkt, wo es ggf. noch Probleme geben könnte und ob die Positionen einzelner Bauteile verschoben werden müssen. Wer sich nun fragt, warum die USB-Buchsen so weit von der Platine ragen: Das liegt daran, dass diese später vom gedruckten Gehäuse getragen und fixiert werden.

Die Platine fräsen und bestücken

An dieser Stelle kann ich nun leider nicht jeden Schritt genau erklären, da gerade das Portieren von TARGET 3001! und KiCad in G-Code für die CNC-Fräse eine kleine Wissenschaft für sich ist. Da ich aktuell noch Estlcam dafür nutze, ist der Workflow dabei wie folgt:

1. Platinenlayout öffnen
2. Export des Platinenlayouts als Produkt → Isolationsfräsen
3. Parameter fürs Fräsen einstellen
4. Definition, ob Bohren vor oder nach dem Fräsen
5. G-Code erzeugen
6. G-Code in Estlcam laden
7. Platine erstellen

Klingt auf dem Papier nun leicht, in der Realität brauche ich immer ein oder zwei Versuche, bis es gelingt.

Ist die Platine dann endlich fertig, ist noch etwas Nacharbeit nötig. Es gibt noch kleine Späne, die Kurzschlüsse verursachen können, und auch die größeren Bohrlöcher müssen mit einem Handbohrer vorsichtig gebohrt werden.

Sprich: Nach dem Fräsen muss die Platine mit einem feinen Schmirgelpapier bearbeitet werden, bis das Multimeter beim Prüfen keine Kurzschlüsse mehr signalisiert. Da die Leiterbahnen recht dünn sind, hilft an dieser Stelle auch ein gutes Bastelmesser, um die gefräste Bahn sauber von Spänen zu befreien.

Ist soweit alles fertig, kann man die Platine in ihre Endform schneiden. An dieser Stelle nutze ich sehr gerne eine Laubsäge.

Die LED ist bewusst weggelassen, da später Telegram mich über die Alarmierung informieren soll. Wichtig beim Löten: mit den kleinsten Bauteilen anfangen und bei den größten enden. Während des Lötens auch immer mit dem Multimeter prüfen, ob nicht irgendwo ein Kurzschluss produziert wurde. Gerade bei kleineren Leiterbahnpunkten passiert mir persönlich das gerne mal.

Was man nicht sieht: Die Kupferseite ist anschließend mit einem Klarlack überzogen worden, um Oxidation an den Leiterbahnen zu minimieren.

Den Teil, der mir die größten Sorgen bereitet hatte, siehst du in Abbildung 9. Die Platine wurde das erste Mal an die Dockingstation vom Melder angeschlossen. Zuvor noch mehrfach auf Kurzschlüsse oder andere Fehler geprüft, kommt irgendwann der Zeitpunkt, an dem man mit der realen Hardware testen muss.

Aufatmen konnte ich direkt beim Einstecken der Spannungsversorgung, da sowohl der D1 Mini als auch die Dockingstation ohne Probleme liefen. Hier wurde der D1 Mini noch mit einem einfachen Blink-Skript gestartet.

Das Gehäuse für das Projekt

Zuletzt in dieser Phase noch ein Thema zum Gehäuse. Dieses sollte erst einmal schlicht sein und meine Leiterplatine schützen. Wie bei dem Platinenlayout bereits erwähnt, werden die beiden USB-Buchsen zusätzlich durch das Gehäuse fixiert, damit diese beim Ein- und Ausstecken nicht von der Leiterplatine abbrechen. Ja, das kann passieren und bei meiner ersten Platine ist dies auch tatsächlich passiert.

Die Platine passt hier später passgenau rein und kann dann mit dem Deckel verschraubt werden. Dieser ist so konstruiert, dass die Stege vom Deckel die Platine mit dem Boden fixieren. Ich gebe zu, man könnte das Gehäuse noch interessanter designen, mir war aber erst einmal die Funktion wichtiger.

Der kleine Steckanschluss für die Dockingstation musste selbst gecrimpt werden. Ein schöneres Kabel mit Ummantelung soll später in der finalen Version kommen.

Die Software auf dem D1 Mini

Da (Micro-)Python immer beliebter wird, empfand ich dieses Projekt als interessant genug, aus der Visual-Studio-Code-mit-PlatformIO-Komfortzone zu kommen und den D1 Mini mit MicroPython zu programmieren.

Ja, C++ hat diverse Vorteile gegenüber MicroPython, nicht zuletzt die Reaktionszeit und der Speicherbedarf. Da dieses Projekt aber nicht auf schnelle Reaktion aus ist und Speicher an dieser Stelle irrelevant ist, können all diese Punkte vernachlässigt werden.

Es gibt auf diversen Seiten und Foren Berichte, Benchmarks und Diskussionen, warum oder warum nicht C(++) besser als MicroPython ist. Sei mir an dieser Stelle nicht böse, diese Diskussion möchte ich hier nicht führen. 😉

D1 Mini spricht MicroPython

Hast du gerade deinen D1 Mini frisch aus der Verpackung genommen, so wird mit hoher Wahrscheinlichkeit ein Arduino-Sketch-Programm, meist das Blink-Beispiel, darauf laufen.

Um MicroPython nun auf den ESP8266, also unseren D1 Mini, zu bekommen, eignet sich die Thonny IDE am besten für Anfänger. Lade dir bitte zuvor die aktuellste MicroPython-Firmware herunter, siehe Firmwareseite. Zum Zeitpunkt des Beitrags war v1.29.0 die aktuellste Version.

Schließe jetzt schon einmal den D1 Mini an deinen PC an und starte die Thonny IDE.

Wie in der Abbildung gezeigt, gehst du unten rechts in der Statusleiste auf die aktuell ausgewählte Python-Umgebung und dann auf „Den Interpreter konfigurieren …” bzw. „Configure interpreter”.

Dort kann auch schon etwas anderes stehen. Das kann passieren, wenn du zuvor schon mit der Thonny IDE gearbeitet hast. Im folgenden Dialog wählst du den passenden Interpreter aus, hier MicroPython (ESP8266), und prüfst unter Port oder WebREPL, ob schon eine passende Kommunikationsschnittstelle ausgewählt wurde.

Je nach Betriebssystem sieht die Anzeige für den Port etwas anders aus. Da ich Linux verwende, wird direkt auf ttyUSB0verwiesen. Sollte dir der Port komisch erscheinen, wähle im Drop-down-Menü den passenden Anschluss aus.

Wichtiger ist, gerade bei einem frischen D1 Mini, das Flashen mit MicroPython.

Im nachfolgenden Dialog setzt du den Port, hier hilft manchmal auch ein Reload für die automatische Erkennung, und wählst die zuvor heruntergeladene MicroPython-Firmware aus.

Über „Installieren” wird dann die Firmware auf den D1 Mini übertragen. Es empfiehlt sich, gerade wenn der D1 Mini schon vorher für Projekte genutzt wurde, den Haken bei „Erase flash before installing” zu setzen. Damit werden dann auch Überreste von vorherigen Projekten gelöscht.

Das Projekt auf den D1 Mini bringen

Jetzt muss das Projekt noch auf den D1 Mini transferiert werden. Da leider der Paketmanager in der Thonny IDE nicht zu funktionieren scheint, habe ich einen einfachen Weg für dieses Projekt genutzt.

Lade mein GitHub-Repository herunter, siehe AirbusPager_Remoteadapter, und navigiere nach dem Klonen oder Entpacken in das Verzeichnis D1_Mini_Software. Dort erstellst du einen weiteren Ordner umqtt mit einer neuen Datei simple.pydarin. Jetzt muss noch von GitHub der Code in unsere leere Datei kopiert und gespeichert werden.

Dein Verzeichnis sollte nun ungefähr so aussehen wie in der Abbildung. Wichtig: Dort, wo mein Python-Projekt liegt, braucht es den Unterordner umqtt mit der Datei simple.py, andernfalls wird die Thonny IDE dir einen Fehler beim Ausführen des Codes anzeigen.

In der Thonny IDE navigiere ich nun zu dem Verzeichnis mit meinem Code, markiere alles und wähle über das Kontextmenü der rechten Maustaste die Option „Upload nach /“.

Damit ist der Code nun übertragen und theoretisch könnte dieser auch laufen. Jedoch sind noch einige Einstellungen nötig, die ich etwas erklären muss.

Der Code einfach erklärt

Der Code für mein Projekt ist auf drei MicroPython-Dateien aufgeteilt:

1. main.py – Übernimmt die ganze Arbeit und wird beim Einschalten des D1 Mini direkt gestartet
2. netconn.py – Übernimmt die Wi-Fi- und MQTT-Verbindung, überwacht diese und versendet MQTT-Nachrichten
3. config_dock.py – Hier sind alle Einstellungen, die für den Betrieb vom D1 Mini relevant sind

Die Architektur im Überblick

Bevor wir in die Details gehen, ein Wort zur Architektur. Das Projekt ist bewusst in drei Dateien aufgeteilt, um Wiederverwendbarkeit und Wartbarkeit zu erhöhen. netconn.py ist eine universelle Netzwerkkonnektor-Klasse, die ich in anderen ESP8266-Projekten wiederverwenden kann. config_dock.py trennt die sensiblen Zugangsdaten (WLAN-Passwort, MQTT-Credentials) von der eigentlichen Programmlogik.

Das ist nicht nur sicherer beim Teilen des Codes, sondern ermöglicht auch einfache Anpassungen, ohne den Core-Code anzufassen.

Was passiert beim Start? – Die main.py

Wenn der D1 Mini mit Spannung versorgt wird, sucht MicroPython nach einer Datei namens main.py und führt diese automatisch aus. Das ist vergleichbar mit der setup()– und loop()-Funktion in Arduino, nur dass hier die Struktur freier ist.

Die main.py erledigt folgende Schritte:

1. Import der Module – netconn.py und config_dock.py werden geladen. Das sind keine externen Bibliotheken, sondern unsere eigenen Projektdaten.
2. Initialisierung der GPIOs – Der ALERT_PIN (standardmäßig D1 / GPIO5) wird als Eingang mit internem Pull-Up definiert. Das bedeutet: Solange nichts passiert, liegt der Pin auf HIGH. Schließt das Relais der Dockingstation, zieht es den Pin auf LOW – das ist unser Alarm-Signal.
3. Optional: LED initialisieren – Falls LED_PIN in der Konfiguration gesetzt ist, wird dieser Pin als Ausgang definiert. Standardmäßig steht der Wert aktuell auf None. Soll die LED auf meiner Platine genutzt werden, wird GPIO2 bzw. D4 verwendet.
4. Watchdog aktivieren – Der ESP8266 verfügt über einen Hardware-Watchdog, der das System neu startet, wenn er über einen bestimmten Zeitraum nicht zurückgesetzt wird. Das klingt zunächst bedrohlich, ist aber ein Sicherheitsnetz: Sollte die Software hängenbleiben, startet das Board selbstständig neu. Der Watchdog wird in der Hauptschleife zyklisch zurückgesetzt.
5. Netzwerkverbindung aufbauen – Eine Instanz der NetConn-Klasse wird erstellt und mit den Werten aus config_dock.py initialisiert. Die Klasse versucht nun, sich mit dem WLAN zu verbinden und anschließend mit dem MQTT-Broker.
6. Hauptschleife (while True) – Hier passiert die eigentliche Magie.

Die Hauptschleife im Detail

Die Schleife ist bewusst einfach gehalten, aber jede Zeile hat ihre Berechtigung!

Anstatt den Pin dauerhaft abzufragen, was Energie kostet und den Watchdog nervös macht, nutze ich einen Interrupt für den Alarmpin. Das bedeutet, der ESP8266 arbeitet normal seinen Loop in der Hauptschleife ab und nur wenn sich der Pin ändert, wird eine sogenannte Interrupt Service Routine (ISR) ausgelöst.

Diese ISR ist bewusst sehr kurz: Sie erfasst den aktuellen Pinzustand und den Zeitpunkt der Änderung. Die eigentliche Prüfung, Entprellung und MQTT-Publikation erfolgen anschließend in der Hauptschleife. Die ISR sendet niemals selbst eine MQTT-Nachricht, denn das würde im Interrupt-Kontext zu instabilem Verhalten führen.

Das ist ein wichtiges Konzept in der Embedded-Entwicklung: Im Interrupt nur das Nötigste tun, den Rest in der Hauptschleife erledigen.

Wenn ein Alarm erkannt wird, wird nicht sofort wieder auf einen neuen Alarm reagiert. Es gibt eine Cooldown-Phase, die in config_dock.py unter COOLDOWN_MS einstellbar ist. Default sind 40000, also 40 Sekunden.

Warum so lange? In der Regel folgt nicht direkt nach einer Erstalarmierung unmittelbar eine Zweitalarmierung. In meiner ehrenamtlichen Zeit hat eine Änderung der gemeldeten Lage oder eine weitere Alarmierung mehrere Minuten Abstand. Mit diesem Cooldown verhindere ich mehrere MQTT-Nachrichten für die gleiche Alarmierung.

Zusätzlich zum Cooldown gibt es einen optionalen Software-Debounce, in config_dock.py der Parameter DEBOUNCE_MS. Das ist eine zweite Sicherheitsebene: Wenn der Pin schwingt, werden nur Änderungen akzeptiert, die länger als die Debounce-Zeit anstehen. Für mechanische Schalter ist das sinnvoll, bei Relais wie beim P8GR in der Regel nicht nötig, sollte dennoch eingestellt werden. Daher ist der Default-Wert in meiner Konfiguration auf 300 gesetzt, um auch hier das Relaissignal zu entprellen.

In jedem Schleifendurchlauf wird nc.health_tick() aufgerufen. Diese Methode prüft:

• Ist das WLAN noch verbunden?
• Ist der MQTT-Broker noch erreichbar?
• Falls nicht: Trennen, warten, neu verbinden

Und hier kommt ein wichtiger Punkt, der mich viel Zeit und Nerven gekostet hat.

Die netconn.py und das ensure_mqtt()-Problem

Die netconn.py ist als Python-Klasse NetConn strukturiert. Sie kapselt alles, was mit WLAN und MQTT zu tun hat. Beim Initialisieren bekommt sie die Konfiguration aus config_dock.py übergeben. Die Methode connect() baut zunächst das WLAN auf und dann die MQTT-Verbindung.

Das Problem mit umqtt.simple: Es ist eine wirklich minimalistische MicroPython-Bibliothek für MQTT. Das ist im ersten Augenblick ein Vorteil für den Speicherbedarf, allerdings hat sie einen gravierenden Nachteil: Es gibt keine eingebaute Verbindungsprüfung. Die Klasse merkt nicht, wenn die Verbindung zum Broker abbricht, beispielsweise wenn der Broker neu startet oder ein Router das NAT-Timeout überschreitet. Der Socket wird an dieser Stelle einfach nicht überprüft.

Das führte bei mir zu folgendem Phänomen: Der D1 Mini lief stundenlang ohne Neustart, aber Testalarme kamen einfach nicht mehr beim Broker an. Die umqtt.simple-Instanz glaubte noch verbunden zu sein, aber im Hintergrund war die Verbindung schon längst tot.

Nach einer Analyse mit meinem KI-Agenten, siehe dazu meinen Beitrag zu OpenClaw, hat sich herausgestellt, dass umqtt.simple keine zyklische Verbindungsprüfung hat. Die Lösung war eine eigene Methode ensure_mqtt(), die ich in die netconn.py integrieren musste.

Die Methode arbeitet mit einem Timeout-basierten Ansatz:

1. Es wird ein Zeitstempel last_ping gespeichert, wann zuletzt eine MQTT-Nachricht erfolgreich gesendet wurde.
2. In regelmäßigen Abständen, gesteuert über KEEPALIVE_INTERVAL_MS, wird ein MQTT-PINGREQ an den Broker gesendet.
3. Kommt keine PINGRESP-Antwort oder schlägt das Senden einer Nachricht fehl, wird die Verbindung als defekt betrachtet.
4. Die alte Verbindung wird explizit geschlossen, eine neue Instanz von MQTTClient erstellt und die Verbindung neu aufgebaut.

Dieser Ansatz ist zwar nicht so elegant wie eine echte asynchrone Verbindungsüberwachung, aber auf einem ESP8266 mit MicroPython ist er robust genug. Die Hauptschleife in main.py ruft zyklisch nc.health_tick() auf, welches wiederum ensure_mqtt() triggert. Dadurch wird der Watchdog auch regelmäßig zurückgesetzt – ein zusätzlicher positiver Nebeneffekt.

Warum ist das alles wichtig? In einem Feuerwehr-Alarmierungssystem ist Verlässlichkeit alles. Hier wird keine Echtzeitüberwachung gefordert, eine gewisse Bearbeitungszeit ist durchaus unproblematisch, aber eine abgebrochene Verbindung darf nicht dazu führen, dass Alarme unbemerkt verloren gehen.

Die Kombination aus:

• Hardware-Watchdog (schützt vor totalen Hängern)
• Software-Debounce (schützt vor Mehrfachauslösungen)
• Cooldown (verhindert Spam)
• ensure_mqtt() (verhindert stille Verbindungsausfälle)

macht das System robust genug für den Dauerbetrieb.

Die config_dock.py – Dein persönlicher Anpassungspunkt

Diese Datei ist das Herzstück für alle, die das Projekt nachbauen wollen. Sie enthält keine Logik, sondern nur Konstanten. Das hat den Vorteil, dass bei einem Firmware-Update nur main.py und netconn.py ausgetauscht werden müssen, ohne dass die Zugangsdaten neu eingegeben werden.

Bei größeren Änderungen kann auch eine Anpassung der config_dock.py nötig sein, was aber in den Release Notes angekündigt wird.

Die wichtigsten Parameter:

• WLAN_SSID und WLAN_PASS – WLAN-Zugang zu deinem Heimnetzwerk
• MQTT_BROKER – Die IP-Adresse oder der Hostname deines MQTT-Brokers (meist eine IP wie 192.168.1.100)
• MQTT_PORT – Standard ist 1883 für unverschlüsselte Verbindungen
• MQTT_USER und MQTT_PASS – Falls dein Broker Authentifizierung verlangt, z. B. Mosquitto mit allow_anonymous false
• MQTT_TOPIC – Das Topic, unter dem die Alarmierung veröffentlicht wird. Ich nutze b"pageralarm/docking/alert". Das bdavor ist wichtig: MicroPython erwartet bei MQTT-Topics Byte-Strings, keine normalen Strings.
• CLIENT_ID – Ein eindeutiger Name für diesen D1 Mini im MQTT-Netzwerk
• ALERT_PIN – Der GPIO-Pin für das Relaissignal. Standardmäßig wird GPIO5 bzw. D1 verwendet.
• LED_PIN – None = LED deaktiviert. Soll die LED auf meiner Platine genutzt werden, wird GPIO2 bzw. D4 eingetragen.
• COOLDOWN_MS – Sperrzeit in Millisekunden nach einem Alarm
• DEBOUNCE_MS – Entprellzeit für mechanische Kontakte (0 = aus)
• LED_BLINK_MS – Blinkintervall der LED während des Cooldowns
• KEEPALIVE_INTERVAL_MS – Wie oft die MQTT-Verbindung geprüft wird
• WIFI_RETRY_S und MQTT_RETRY_S – Wartezeit zwischen Wiederverbindungsversuchen

Zusätzlich prüft die Software, ob gültige Pins verwendet werden und dass ALERT_PIN und LED_PIN nicht auf denselben GPIO gelegt werden.

Der Wert COOLDOWN_MS = 40000 (40 Sekunden) mag auf den ersten Blick hoch erscheinen. Bedenke aber: Eine typische Nachalarmierung bei der Feuerwehr dauert deutlich länger als 40 Sekunden. In dieser Zeit soll der Melder ohnehin nicht noch einmal auslösen. Die Sperrzeit verhindert also nicht nur Prellen, sondern auch versehentliche Mehrfachmeldungen.

Die LED als Statusanzeige

Standardmäßig ist die LED über LED_PIN = None deaktiviert. Soll die LED auf meiner Platine genutzt werden, wird GPIO2 bzw. D4 als LED_PIN eingetragen. In diesem Fall zeigt sie folgende Zustände an:

Zustand	LED-Verhalten
Ruhezustand, Alarmpin HIGH	LED aus
Alarm erkannt / Cooldown aktiv	LED blinkt alle 300 ms
Alarmpin nach dem Cooldown weiterhin LOW	LED blinkt erneut alle 300 ms
Relais wieder geöffnet, Alarmpin HIGH	LED aus

⚠️ Wichtig: Wir erkennen nicht, ob der Pager physisch in der Dockingstation steckt oder nicht. Die LED reagiert ausschließlich auf das Relaissignal der Alarmierung. Im Ruhezustand ist das Relais geöffnet, der Alarmpin liegt auf HIGH und die LED ist aus. Wird bei einer Alarmierung das Relais geschlossen, wird der Alarmpin auf LOW gezogen. Während des aktiven Cooldowns blinkt die LED im eingestellten 300-ms-Takt. Ist der Alarmpin nach Ablauf des Cooldowns weiterhin LOW, beginnt bei der erneuten Alarmerkennung auch die LED wieder zu blinken. Sobald das Relais wieder geöffnet wird und der Alarmpin auf HIGH wechselt, bleibt die LED aus.

Node-RED als Stellglied der Automation

In meinem Projekt findest du auch für Node-RED einen Flow.

Dies ist mein anonymisierter Flow für die Freiwillige Feuerwehr, wenn eine Alarmierung des Melders gekommen ist. Der Flow verbindet sich mit dem MQTT-Broker und lauscht auf eine Änderung des Alarmierungstopics. Ist dieses auf „on” geschaltet, wird zunächst ein Timer gestartet, der nach 30 Sekunden das Topic auf „off” zurücksetzt. Gleichzeitig wird eine Telegram-Nachricht vorbereitet und gesendet.

Über einen mit dem BotFather eingerichteten Telegram-Bot wird diese Nachricht dann an mich weitergeleitet. Unter node_red in meinem Repo kannst du diesen Flow bequem herunterladen. Einzig das Paket node-red-contrib-telegrambot musst du für Node-RED herunterladen sowie die Einwahldaten zum MQTT-Broker eintragen und den Telegram-Bot konfigurieren.

Interessant ist in diesem Flow der Knoten Message_for_Telegram, wo die eigentliche Nachricht zusammengebaut wird. Da ich immer wiederkehrende, statische Nachrichten nicht leiden kann, habe ich drei Arrays, die mir eine zufällige Nachricht zusammenbauen.

Einzig die Alarmzeit und der Hinweis „– Weitere Infos via Pager, APager oder DE-Alarm!” werden der Nachricht angehängt. Damit habe ich genügend Variation, wobei ich bei einer Alarmierung meist nicht auf den Text achte, sondern nur darauf, ob eine Alarmierung gekommen ist.

Alles in meinem GitHub-Repo noch einmal erklärt

Zuletzt noch die Dokumentation. Das Projekt ist schnell gewachsen und da ich im Weiteren neue Features plane und ggf. den einen oder anderen Bug finden werde, wird es auch in unregelmäßigen Abständen neue Versionen der Hard- und Software geben.

In dem entsprechenden GitHub-Wiki werden wichtige Änderungen mit aufgenommen. Darin wird der Aufbau noch einmal erklärt, kleine Löttechniken und auch ein FAQ samt Troubleshooting sind mit dabei. Sowohl auf Deutsch als auch auf Englisch, sodass jeder dieses Projekt umsetzen kann.

Die lange Reise

Anders als in meinen Blogs vorher habe ich dich mit auf die Reise vom Prototyp zum Produkt genommen. Was sich hier einfach liest, hat über zwei Monate gedauert, mit der gesamten Automation im Hintergrund.

Es sieht alles einfach aus, aber sich in die Programme einzuarbeiten, Fehler zu finden und immer wieder zu optimieren, kostet Zeit. Da ich das als Hobby immer abends oder am Wochenende entwickelt habe, musste ich an manchen Stellen wieder von vorne beginnen. Anders als bei meinem regulären Beruf waren größere Pausen vorprogrammiert.

Ein zweiter Punkt war tatsächlich die Software. Ich programmiere normalerweise in C++ bzw. mit Visual Studio Code und PlatformIO. Python kann ich sehr rudimentär und ich empfand dieses Projekt als den richtigen Einstieg, um mich mal in (Micro-)Python einzuarbeiten.

Auch hier ist etwas Zeit ins Land gegangen. Mein KI-Agent NoJoAgent, siehe dazu den Beitrag zu OpenClaw, hat mir an einigen Stellen die nötige Hilfestellung gegeben. Dadurch habe ich die KI-Unterstützung durchaus noch mehr schätzen gelernt.

Zusammenfassung

Man kann an dieser Stelle wahrscheinlich nun streiten, ob Telegram der richtige Ort für eine Alarmierungsmeldung ist. Da ich bis auf den Alarmzeitpunkt keine weiteren relevanten Informationen preisgebe, ist es in meinen Augen unkritisch.

Die Telegram-Nachricht entsteht tatsächlich nur dann, wenn der Pager auslöst und dadurch das Relais der Dockingstation geschlossen wird. Mein PagerAlarm weiß damit, dass eine Alarmierung vorliegt, aber nicht, weshalb alarmiert wurde. Auf die eigentliche Alarmmeldung kann ich über dieses Projekt nicht zugreifen. Deshalb verweise ich in der Telegram-Nachricht darauf, die weiteren Informationen über Pager, APager oder DE-Alarm abzurufen.

Die Nachricht ist der Einstieg in meine Automation, um mein „Beleuchtungskonzept” im Haus bei Dämmerung oder in der Nacht umzusetzen. Gleichzeitig bleibt das System technisch von Strom, WLAN, MQTT, Node-RED, Internet und Telegram abhängig. Fällt eine dieser Komponenten aus, kann die zusätzliche Telegram-Alarmierung ausbleiben. Der batteriebetriebene Melder selbst ist davon unabhängig.

Ich gebe an dieser Stelle zu: Ich benötigte Werkzeuge, Maschinen und Materialien, die nicht jeder im Haus hat. Ein 3D-Drucker kommt immer mehr in Mode, aber eine CNC-Fräse wie meine kleine CNC 3018 braucht dann eben doch nicht jeder täglich.

Gerade mit Blick auf die Erstellung des Platinenlayouts, auch wenn es hier noch recht primitiv ist, muss man sich in Software einarbeiten und auch ein gewisses elektrisches Grundwissen mitbringen. Nicht zuletzt der Melder samt Dockingstation könnte für viele, die nicht ehrenamtlich im Bevölkerungsschutz tätig sind, schwierig werden. Das zugrunde liegende Konzept dahinter kann aber für andere Alltagsprobleme adaptiert werden.

Ausblick

Interessant wäre zudem die Heimautomationserweiterung in einer entsprechenden Wehr, die dann Licht, Rollläden und vielleicht sogar auch Tore ansteuert. Gerade in kleinen Gemeinden oder Ortsteilen wäre eine solche Lichtersteuerung durchaus interessant.

Tatsächlich macht mir dieses Projekt so viel Spaß, dass mögliche Erweiterungen an und auf der Platine schon auf meinem Ideenboard existieren. Angefangen von einem kleinen Buzzer auf der Platine, da im Heimmodus mein Melder lautlos ist, bis hin zu kleineren externen Devices mit Licht und Sound, die mich neben Telegram an strategischen Punkten im Haus über eine Alarmierung informieren.

Gerade durch Shelly und Co. ist es zudem einfach geworden, solche Automationen zusammen mit openHAB, Home Assistant oder anderen Heimautomationssteuerungen umzusetzen. Damit kann Node-RED oder deine Heimautomationssteuerung so auf die Alarmierung reagieren, wie man es möchte. Die Grenze liegt an dieser Stelle bei der Umsetzung der Programmierung.

Sofern dich dieses Projekt interessiert, guck einfach mal auf GitHub vorbei, siehe https://github.com/M3taKn1ght/AirbusPager_Remoteadapter. Ich freue mich über jeden gemeldeten Fehler oder Verbesserungsvorschlag!