Telenot Complex 400H mit HomeKit – einfach aufs iPhone, ohne Home Assistant

Kurz gesagt: Dieses Open-Source-Projekt (Rust auf einem ESP32) verbindet meine Telenot Complex 400H nativ über das HomeKit Accessory Protocol mit Apple Home und dem iPhone – ganz ohne lokalen Server oder Home Assistant. Ein Auto-Discovery-Scan findet die Melder von selbst, die Hardware kostet rund 65 €. Getestet habe ich es bisher nur an meiner eigenen Complex 400H; verwandte Modelle (Complex 200H, hiplex 8400H) sprechen dieselbe Protokoll-Sprache und sollten ebenfalls laufen – dafür suche ich Beta-Tester.

Einleitung

💡 Stell dir vor, deine Telenot-Alarmanlage taucht einfach in der Apple Home-App auf. Scharfschalten vom iPhone, “Hey Siri, aktiviere die Alarmanlage”, das Licht geht an, wenn der Bewegungsmelder in der Garage anschlägt. Kein Abo, keine Cloud, keine Daten, die das Haus verlassen.

Und das Beste: Dafür brauchst du keinen Server, kein Linux und keine einzige Zeile Code. Die ganze Lösung ist ein kleines Kästchen – das Foto oben zeigt es – das per Netzwerkkabel angeschlossen wird (der Strom kommt gleich mit durchs Kabel). Danach ein kurzes Klick-Setup im Browser, und die Bridge findet deine Melder von selbst. ✅

Keine Sorge, wenn du nicht der Technik-Typ bist: Der erste Teil hier ist eine einfache Schritt-für-Schritt-Anleitung – genau dafür gedacht, dass du das entspannt hinbekommst. Nach dem Kostenvergleich ist für die meisten Schluss, und alles läuft. Wer danach doch tiefer eintauchen will, findet den technischen Teil weiter unten. (Und ja: das ist der Nachfolger meines ersten Anlaufs mit Raspberry Pi – nur eben viel einfacher.)

Das bekommst du: deine Alarmanlage in Apple Home

Der ESP32 spricht das HomeKit Accessory Protocol direkt – die Bridge taucht in der Apple Home-App auf wie ein fertig gekauftes Gerät. Kein Server, kein Home Assistant, keine Bastelei dazwischen.

Was dabei herauskommt:

Eine Alarmanlagen-Kachel mit den echten Modi: Abwesend, Zu Hause, Nacht, Aus – plus Alarmzustand.
Ausgewählte Melder als eigenes Zubehör – bewusst nicht alle. Eine voll ausgebaute Anlage hat schnell über hundert Meldepunkte; die alle nach HomeKit zu kippen, würde die Home-App unbrauchbar zumüllen. Stattdessen aktivierst du gezielt die Melder, die wirklich zählen. Meiner Erfahrung nach ist das nur eine Handvoll: die Haustür, ein paar Fenster-Gruppen, ein, zwei Schlüssel-Bewegungsmelder. Genau die sind es, die man auf einen Blick sehen und für Automationen nutzen will (“Licht an, wenn Bewegung in der Garage”).
Ein zufällig generierter Pairing-Code pro Gerät – keine fest einkompilierte 12312312-Nummer.

Und Siri kann jetzt natürlich auch: “Hey Siri, aktiviere die Alarmanlage.”

Telenot-Alarmanlage und ausgewählte Melder direkt in der Apple Home-App

So sieht das in echt aus: die Telenot als Alarmanlagen-Kachel (hier unscharf) und daneben eine Handvoll kuratierter Melder – Tür zu, beide Fenster zu, keine Bewegung. Alles direkt vom ESP32, ganz ohne Home Assistant dazwischen.

Was du brauchst: Hardware für die Telenot-HomeKit-Bridge

Eine Telenot-Alarmanlage: Bei mir eine Complex 400H. Andere Modelle derselben Protokoll-Familie – die Complex 200H und die hiplex 8400H – sollten nach allem, was ich bisher weiß, ebenfalls funktionieren; selbst getestet habe ich aber nur meine eigene Complex 400H. Beta-Tester gesucht!
Das Bridge-Kästchen: Ein ESP32-Board mit aufgestecktem RS232-Modul in einer passenden Box. Die einfachste Variante kommt komplett ohne Löten aus – die Module werden nur zusammengesteckt. Die konkreten Teile mit Preisen (rund 65 € komplett) findest du weiter unten in der Stückliste.
Ein Netzwerkkabel mit PoE: Also Strom über das Netzwerkkabel, aus dem Switch oder einem günstigen PoE-Injektor. Kein Netzteil, kein WLAN-Gefrickel im Keller.
15 Minuten Zeit und einen Browser. Kein Programmierwissen. Wirklich keins.

Was dein Errichter einmalig vorbereiten muss

Zwei Handgriffe an der Zentrale sind Sache deines zertifizierten Errichters – ohne die geht es nicht, mit ihnen ist danach alles selbsterklärend. Sag deinem Errichter einfach diese zwei Dinge:

Die GMS-Schnittstelle auf dem seriellen Port aktivieren. Über genau diese Schnittstelle meldet die Zentrale ihren Zustand nach außen – das ist das Tor, durch das die Bridge später mit der Anlage spricht. Bei mir war das in wenigen Minuten erledigt.
Das serielle Kabel aus der Anlage herausführen. Das Innere der Telenot ist sabotageüberwacht und soll verschlossen bleiben. Damit du (oder ein Beta-Tester) nicht bei jedem Handgriff die Zentrale öffnen musst, legt der Errichter das serielle Kabel einmalig von innen nach außerhalb des Gehäuses – auf ein kleines Anschlussfeld im Schaltschrank.

Danach ist Schluss mit Errichter: Ab jetzt klemmst du selbst die Bridge an das herausgeführte Kabel (RS232, 9600 8N1 – Details im Hardware-Kapitel). Öffnen, Verkabeln im Inneren, Sabotagekreis – all das bleibt beim Profi, das Anklemmen der Bridge ist dann ein reiner Steck-Vorgang von außen.

Und wohin kommt das Kästchen? Nicht in die Zentrale, sondern in eine eigene kleine Box direkt daneben. Für mich kam der ESP32 im Gehäuse der Zentrale nicht in Frage – man muss anfangs öfter ran (Setup, Updates), und jedes Öffnen der Anlage löst sonst Sabotagealarm aus. Ob dein Errichter das Herausführen und die externe Box mitträgt, klärst du am besten vorab mit ihm. Überhaupt gilt: Im Zweifel zählt immer, was dein Errichter sagt. Ist er so kooperativ wie meiner, lässt sich über alles reden und man bekommt eine ehrliche, professionelle Einschätzung.

Kurz für den Errichter: GMS-Ausgabe auf dem seriellen Port aktivieren und die serielle Leitung nach außen herausführen – mehr braucht es an der Zentrale nicht.

Telenot in Apple Home einrichten – Schritt für Schritt

Das gesamte Setup läuft über einen Assistenten im Browser – kein YAML, keine Config-Dateien, kein SSH:

Erstanmeldung mit dem Passwort vom Geräteaufkleber, dann sofort eigenes Passwort setzen.
Verbindung prüfen: Die Bridge testet die serielle Verbindung zur Zentrale.
Discovery-Scan starten und zusehen, wie die Melder eintrudeln.
Sensoren bestätigen: Namen, Typen und Räume prüfen – einzeln oder als Bulk-Aktion.
Integration wählen: Apple Home (Direkt-HomeKit) oder MQTT/Home Assistant – dazu gleich mehr.
Sicherheit: PIN setzen und bewusst entscheiden, ob Fernentschärfen erlaubt sein soll.
Übernehmen: Konfiguration speichern, Neustart – ab jetzt läuft die Bridge autark.

Das Webinterface siehst du übrigens genau einmal – zum Einrichten. Danach spielt sich alles in Apple Home ab. So sieht der Weg dahin aus:

Discovery-Scan im Setup-Assistenten — Der Scan läuft – die Melder trudeln von selbst ein.

Gefundene Melder mit Klartext-Namen – Typ meist schon richtig erkannt.

HomeKit koppeln per QR-Code — HomeKit koppeln: QR-Code mit der iPhone-Kamera scannen.

PIN und Sicherheit einstellen — PIN setzen – Fernentschärfen bleibt bewusst aus.

Zusammenfassung vor dem Speichern — Zusammenfassung: Integration Apple HomeKit, Fernentschärfen aus – speichern, fertig.

Status- und Steuerungs-Ansicht der Bridge — Bonus: Die Bridge hat ein eigenes Status- & Steuerpanel – scharf/unscharf und Melderstatus direkt im Browser.

Apple Home oder Home Assistant? Die eine Entscheidung, die zählt

Im Integrations-Schritt entscheidest du dich für einen von zwei Wegen – die schließen sich gegenseitig aus:

Direkt-HomeKit (empfohlen, am einfachsten): Der ESP32 spricht HomeKit selbst – ganz ohne Broker, ohne Home Assistant. Deine Alarmanlage und die kuratierten Melder landen direkt in Apple Home; scharf/unscharf per iPhone und Siri. Simpel, wartungsarm, fertig.
MQTT / Home Assistant: Die Bridge publiziert an deinen MQTT-Broker, und Home Assistant bekommt alle Melder als Entitäten – die feine, granulare Steuerung. In diesem Modus ist das native HomeKit aus. Apple Home bekommst du dann, wenn du willst, klassisch über Home Assistant (dessen eigene HomeKit-Bridge) – also den indirekten Weg wie damals bei v1.

Meine klare Empfehlung: Wenn du kein Home Assistant betreibst und eigentlich nur scharf/unscharf plus ein paar Melder in Apple Home willst – nimm beim Einrichten die reine Apple-Home-Variante und überspring MQTT. Das ist der einfachste, sorgloseste Weg: ein paar Minuten, und du bist durch. Home Assistant lohnt sich erst, wenn du wirklich jeden Melder und komplexe Automationen willst.

Was kostet der Spaß? Die ESP32-Bridge für rund 65 €

Die Hardware kostet rund 65 € – drei Teile vom Hersteller Olimex, ohne Löten zusammengesteckt. Die genaue Stückliste mit Links steht im technischen Teil weiter unten; dazu kommen nur noch zwei simple Kabel, die man oft schon in der Schublade hat.

Zum Vergleich: Telenots offizieller Weg in die Gebäudetechnik ist das KNX-400-IP-Modul. Das kostet, soweit mir andere Telenot-Nutzer berichtet haben, in Richtung 2.000 € – zuzüglich Einrichtung durch den Errichter. Und selbst dann bekommst du damit kein HomeKit. Der Nachbau hier kostet rund 65 € an Hardware – und spricht HomeKit nativ. 😉

Ab hier wird’s technisch 🔧

Für den reinen Betrieb brauchst du ab hier nichts mehr – alles läuft. Wer mag, liest weiter: Ab jetzt geht es um das Warum und Wie unter der Oberfläche.

Raspberry Pi (v1) vs. ESP32-Rust-Firmware (v2): Was ist neu?

Der direkte Vergleich mit meiner ersten Lösung zeigt am besten, was sich getan hat:

	v1: telenot-bridge (2025)	v2: telenot-firmware (2026)
Laufzeitumgebung	Raspberry Pi + Docker + Node.js	Ein ESP32, fertig
Sprache	JavaScript	Rust
HomeKit	Umweg über Home Assistant + HomeBridge	Nativ auf dem Chip (HAP)
Sensor-Konfiguration	~100 Zeilen JavaScript von Hand	Auto-Discovery + Klick zum Bestätigen
MQTT / Home Assistant	Pflicht	Optional
Stromversorgung	Netzteil für Pi + Adapter	PoE, galvanisch isoliert
Webinterface	dauerhaft erreichbar	existiert nur im Setup-Fenster

Die Idee dahinter ist für mich eine grundsätzliche: Eine Alarmanlagen-Bridge ist Infrastruktur. Meiner Meinung nach soll so etwas wie ein Stück Hardware sein – anschließen, einrichten, vergessen. Keine OS-Updates, keine Container, keine SD-Karte, die nach drei Jahren stirbt.

Größe & Ressourcen: 1,7 MB Firmware auf 520 KB RAM

Mir war klar, dass v2 schlanker wird. Aber wie viel schlanker, hat mich dann doch von den Socken gehauen:

v1 brauchte einen Raspberry Pi mit Linux, Docker und Node.js. Allein der node_modules-Ordner: zehntausende Dateien, mehrere hundert Megabyte – bevor auch nur eine Zeile eigener Code läuft.
v2 ist eine einzige Datei: 1,7 MB. Darin steckt alles – der komplette Telenot-Protokoll-Decoder, der HomeKit-Stack, TLS, MQTT und sogar das eingebaute Setup-Webinterface (das komprimiert nur rund 75 KB in den Flash wandert).
Und das Ganze läuft auf einem Chip mit 520 Kilobyte RAM. Zum Vergleich: Allein dieser Blogartikel belegt in deinem Browser gerade ein Vielfaches davon. 😄

Weniger Code, weniger Dateien, weniger laufende Teile – das ist nicht nur Ästhetik. Jede Abhängigkeit, die nicht existiert, kann keine Sicherheitslücke haben und kein Update brauchen.

Auto-Discovery: Telenot-Melder automatisch erkennen 🔍

Im alten Setup sah die Sensor-Konfiguration so aus: Errichter-Doku aufschlagen, Hex-Adressen heraussuchen, für jeden Melder einen Konfigurations-Block schreiben. Bei einem voll ausgebauten Haus sind das schnell hundert Zeilen – und eine Fehlerquelle pro Zeile.

Jetzt macht das die Zentrale selbst. Der Discovery-Scan läuft in drei Schritten:

Belegt-Scan: Die Bridge fragt die Zentrale, welche Ein- und Ausgänge überhaupt belegt sind.
Namens-Scan: Für jede belegte Adresse holt sich die Bridge den Klartext-Namen, den der Errichter hinterlegt hat (“IM Essen EG”, “MK Garagentor”, …).
Klassifizierung: Aus den Namen erkennt die Bridge automatisch den Sensortyp – “IM ” wird ein Bewegungsmelder, “MK ” ein Magnetkontakt, Rauch- und Wassermelder werden ebenso erkannt.

Wichtig: Die automatische Erkennung ist ein Vorschlag, keine Entscheidung. Jeder gefundene Sensor startet als “unbestätigt” und wird im Setup-Assistenten einmal gegengecheckt – Name anpassen, Typ korrigieren, fertig. Aus hundert Zeilen Handarbeit wird ein Scan und ein paar Klicks. ✅

Unter der Haube: Hardware, Stückliste & Rust-Architektur 🤓

Der spannende Teil für alle, die es genau wissen wollen: wie das Ganze aufgebaut ist.

Hardware

Die Basis ist ein Olimex ESP32-POE-ISO-16MB: ein ESP32 mit echtem Ethernet und galvanisch isolierter PoE-Versorgung. Die 16 MB Flash sind kein Zufall – sie schaffen Platz für die zwei OTA-Partitionen (A/B) und das eingebaute Setup-Web. Dazu ein RS232-Pegelwandler (Olimex MOD-RS232), der die GMS-Schnittstelle der Zentrale (9600 Baud, 8N1) auf die richtigen Pegel bringt und einfach per Flachbandkabel auf den UEXT-Anschluss des Boards gesteckt wird – kein Löten.

Stückliste

Der ganze Nachbau besteht aus drei Kaufteilen, alle beim Hersteller Olimex erhältlich:

Teil	ca.	Zweck
ESP32-POE-ISO-16MB	25 €	ESP32-Board mit PoE + isoliertem Ethernet, 16 MB Flash
MOD-RS232	6 €	RS232-Pegelwandler, steckt per Flachband auf den UEXT
BOX-ESP32-POE-ISO-F	9 €	passende Box für Board + Modul

Macht rund 65 € komplett – inklusive Versand und Mehrwertsteuer (Warenwert ~40 €, der Rest ist Versand aus Bulgarien plus MwSt.).

Dazu kommen noch zwei simple Kabel, die man oft schon in der Schublade hat:

Ein Patchkabel zu einem PoE-Switch oder einem günstigen PoE-Injektor – der Strom kommt gleich mit durchs Netzwerkkabel. Wer keinen PoE-Switch hat, nimmt einen einfachen 802.3af-Injektor (z. B. TP-Link TL-POE150S, ~15 €).
Ein serielles DB9-Kabel (1:1 / straight-through, kein Nullmodem), das die Bridge mit der vom Errichter herausgeführten GMS-Leitung verbindet (z. B. Digitus D-Sub9 Stecker/Buchse, 2 m). Länge nach Bedarf, aber kurz halten. Achte auf die Steckergeschlechter, damit beide Enden passen.

Ein ehrliches Wort zur Isolation: Der MOD-RS232 teilt sich im PoE-Betrieb die Masse mit dem ESP. Das ist hier unkritisch, weil PoE und Ethernet auf dem Board bereits galvanisch getrennt sind – diese Masse bleibt damit die einzige Verbindung zur Anlage, es entsteht keine Erdschleife. Wer es zum Endausbau vollständig galvanisch getrennt haben will, ersetzt den MOD-RS232 durch ein isoliertes RS232-Modul; am restlichen Aufbau ändert sich nichts.

Das Titelbild zeigt eine 3D-gedruckte Gehäuse-Variante – wer keinen 3D-Drucker hat, nimmt einfach die fertige Olimex-Box aus der Stückliste.

Architektur

Die Firmware ist als Rust-Workspace aus mehreren Crates aufgebaut, und die Trennung ist bewusst streng:

telenot-protocol – Der Protokoll-Decoder: FT1.2-Rahmen (IEC 60870-5-1) und VdS-2465-Records. Komplett no_std und ohne Heap-Allokationen, getestet gegen echte Mitschnitte meiner Anlage.
telenot-core – Das Herzstück: eine deterministische Zustandsmaschine nach dem Sans-IO-Prinzip. Sie macht selbst kein I/O, sondern bekommt Events (SerialFrame, Timeout, UserCommand) und liefert Actions zurück. Dadurch läuft die gesamte kritische Logik auf dem Entwicklungsrechner testbar – ganz ohne Hardware.
telenot-app – Die Service-Schicht: REST-API fürs Setup, MQTT, Security (PIN, Lockout).
telenot-firmware – Die dünne ESP-IDF-Schale: UART, Ethernet, HTTPS, HomeKit.

Ein Grundprinzip zieht sich durch alles: Snapshot = Wahrheit. Die Telenot sendet alle ~3 Sekunden ein zyklisches Status-Telegramm mit dem kompletten Scharf- und Melderzustand. Nur dieses Telegramm bestimmt, was die Bridge nach außen meldet – niemals der optimistische Zustand nach einem gesendeten Befehl. Wenn die Anlage einen Scharfschaltbefehl ablehnt, zeigt HomeKit das auch so an.

Auto-Discovery im Detail

Der Belegt-Scan aus dem Discovery-Kapitel ist im Kern erfreulich kompakt: Die Zentrale antwortet mit Bitmaps, in denen jedes 0-Bit ein konfigurierter Meldepunkt ist.

/// Belegt-Telegramm auswerten: jedes 0-Bit ist ein belegter Meldepunkt.
pub fn ingest_belegt(&mut self, bs: &BlockStatus) {
    match bs.adresserweiterung {
        0x71 => self.got_inputs = true,   // Eingänge
        0x72 => self.got_outputs = true,  // Ausgänge
        _ => return,
    }
    let base = bs.base_address();
    for (i, byte) in bs.status.iter().enumerate() {
        for bit in 0..8u16 {
            if (byte >> bit) & 1 == 0 {
                self.occupied.insert(base + i as u16 * 8 + bit);
            }
        }
    }
}

Danach werden für alle belegten Adressen die Klartext-Namen abgefragt und daraus eine fertige Konfiguration mit sauberen, deduplizierten Topics erzeugt.

Security by Design 🔒

Der Punkt, der mir bei der Neuentwicklung am wichtigsten war. Für dich als Anwender heißt das vor allem: Niemand kann deine Anlage aus der Ferne entschärfen – außer du erlaubst es ausdrücklich. Die Bridge ist konsequent fail-closed gebaut:

Fernentschärfen ist ab Werk deaktiviert. Wer es will, muss es im Setup bewusst aktivieren und eine PIN setzen. Das gilt für MQTT und HomeKit gleichermaßen – beide laufen durch denselben PIN-geschützten Pfad. Scharfschalten geht immer, Entschärfen nur mit Opt-in.
Die PIN wird als PBKDF2-Hash mit Salt gespeichert, der Vergleich läuft in konstanter Zeit, und Fehlversuche führen zu einem Lockout, der auch einen Neustart übersteht – ein simples Steckerziehen setzt die Brute-Force-Bremse nicht zurück.
Das Webinterface existiert im Normalbetrieb schlicht nicht. Der HTTP-Listener läuft nur in einem befristeten Zeitfenster – beim allerersten Setup 24 Stunden, danach je Neustart 30 Minuten – oder nach einem langen Druck auf die physische Taste am Gerät. Danach: kein offener Port, Angriffsfläche null. Es gibt keinen Netzwerk-Weg, das Setup zu öffnen – nur den Taster.
Secrets bleiben im verschlüsselbaren NVS-Speicher und tauchen weder in Config-Exporten noch in der Diagnose auf.
Rust, ohne Ausnahmen: Alle portablen Crates erzwingen unsafe_code = "forbid" – Speicherfehler-Klassen wie Buffer Overflows im Protokoll-Parser sind damit per Compiler ausgeschlossen. Dazu über 150 Unit-Tests, viele davon gegen echte Telegramm-Mitschnitte.

Mein praktischer Rat für den Anfang: Lass das Fernentschärfen im Setup einfach aus. Dann arbeitet die Bridge faktisch rein lesend – sie zeigt dir jederzeit den Zustand und kann höchstens scharfschalten, aber nie entschärfen. Das ist die sorgloseste Einstellung und deckt die allermeisten Alltagswünsche ab; einschalten kannst du es später immer noch.

Updates ohne Werkstattbesuch sind bereits eingebaut: Die Firmware liegt auf zwei Partitionen (A/B), jedes Update wird vor dem Schreiben per SHA-256 geprüft, und startet die neue Version nicht sauber, rollt der Bootloader automatisch auf die alte zurück. Ein täglicher Update-Check meldet neue Releases – installiert wird aber bewusst nur auf Knopfdruck, nie von allein.

Zwei prominente Härtungs-Features – Secure Boot v2 und Flash-Verschlüsselung – habe ich bewusst nicht aktiviert. Sie schützen vor einem Angreifer, der den Chip physisch in der Hand hält – und genau der liegt außerhalb des Bedrohungsmodells: Wer im verschlossenen, sabotageüberwachten Schaltschrank steht, hat ganz andere Wege. Die primäre Verteidigung ist der Sabotagekreis der Anlage, nicht ein verschlüsselter Flash. Das Restrisiko ist dokumentiert und bewusst akzeptiert – ich halte nichts davon, Sicherheit zu behaupten, die im echten Angriffsfall nichts bringt.

In dieselbe Kategorie „ehrlich bleiben” gehört das Entschärfen selbst: Das GMS-Telegramm ist auf dem Draht nicht authentifiziert. Wer physischen Zugriff auf die RS232-Leitung bekommt und eine eigene Bridge anklemmt, kann die Anlage unscharf schalten – völlig unabhängig davon, was in meiner Firmware eingestellt ist. Für mich persönlich ist dieses Restrisiko vertretbar: Ein solcher Angreifer stünde ohnehin schon direkt an der Anlage. Und weil die serielle Leitung bewusst außerhalb der Zentrale kurz herausgeführt wird, lässt sich das Kästchen mitsamt Anschluss über den Deckelkontakt der externen Box in den Sabotagekreis einbinden – dann löst genau dieser Griff Alarm aus, statt unbemerkt zu bleiben.

Das Zitat aus dem alten Post gilt eben immer noch: “Dance Like Nobody’s Watching. Encrypt Like Everyone Is.” – Werner Vogels, AWS CTO.

Weitere Funktionen der Firmware 🧰

Der Post ist schon lang, deshalb hier nur im Schnelldurchlauf – aber es steckt noch einiges mehr drin, das im Alltag praktisch ist:

Zweisprachiges Setup (DE/EN). Das komplette Einrichtungs-Web und selbst die Fehlermeldungen sind auf Deutsch und Englisch – praktisch, sobald die Firmware auch außerhalb Deutschlands getestet wird.
Melder gezielt sperren (Zonen-Bypass). Einzelne Meldebereiche lassen sich vorübergehend überbrücken – z. B. das gekippte Badfenster – ohne die ganze Anlage unscharf zu lassen.
Schaltausgänge nutzen. Freigegebene Relais und Signalgeber der Zentrale lassen sich schalten – über eine bewusste Freigabeliste, nicht wild alles.
Konfiguration sichern & zurückspielen. Ein Klick exportiert die komplette Einrichtung als Datei (bewusst ohne Geheimnisse wie PINs) – für den Umzug auf neue Hardware oder als Backup.
Failover-Anbindung. Statt der internen seriellen Leitung kann die Bridge die Zentrale auch übers Netzwerk (RS232-über-TCP) erreichen – live umschaltbar, ohne Neustart.
Diagnose an Bord. Heap, Laufzeit, Neustart-Grund, Zustand der seriellen Verbindung und des MQTT-Brokers sind jederzeit abrufbar – praktisch, falls doch mal etwas hakt.

Und der Blick nach vorn: Die hiplex 8400H und ihre Geschwister nutzen dieselbe VdS-2465-Protokollfamilie. Multi-Bereich-Betrieb und die neueren GMS-Varianten stehen auf der Liste – und genau dafür kommst du jetzt ins Spiel. 👇

Telenot mit Home Assistant & MQTT verbinden

Du willst lieber Home Assistant? Dann wählst du im Integrations-Schritt statt Direkt-HomeKit den MQTT-Weg (beides zugleich geht nicht – siehe oben). Die Bridge publiziert dann an deinen Broker, und mit HA-Discovery legt Home Assistant alle Entitäten automatisch an: das alarm_control_panel, jeden Melder als binary_sensor mit passender device_class, dazu Diagnose-Sensoren für Akku, Netz und Störungen. Apple Home ginge in diesem Modus nur noch klassisch über die HomeKit-Bridge von Home Assistant.

Die wichtigsten Topics des MQTT-Vertrags:

Topic	Richtung	Inhalt
`telenot/v1/<id>/state`	→	`DISARMED`, `ARMED_HOME`, `ARMED_NIGHT`, `ARMED_AWAY`, `TRIGGERED`
`telenot/v1/<id>/<sensor>`	→	`ON` / `OFF` je Melder
`telenot/v1/<id>/ready/intern`	→	Scharfschaltbereitschaft (offene Fenster?)
`telenot/v1/<id>/command`	←	Befehle als JSON, PIN-geschützt
`telenot/v1/<id>/command_result`	→	Echte Rückmeldung der Zentrale

Ein Detail, das ich in v1 schmerzlich vermisst habe: das Pre-Arm-Gate. Die Bridge schaltet nur scharf, wenn die Zentrale ihre Scharfschaltbereitschaft meldet. Steht noch ein Fenster offen, kommt eine saubere Ablehnung statt eines ins Leere laufenden Befehls.

Beta-Tester gesucht! 📣

Und jetzt kommst du ins Spiel: Das GMS-Protokoll spricht nicht nur die Complex 400H. Auch die Nachfolge-Generationen von Telenot – etwa die hiplex 8400H – nutzen dieselbe Protokollfamilie. Die Firmware sollte dort ebenfalls funktionieren, getestet habe ich das aber bisher nur an meiner eigenen Complex 400H.

Und damit das nicht bei “schreib mir mal” bleibt, ist das passende Werkzeug schon eingebaut:

Der eingebaute Diagnose-Modus 🔬

Für genau diesen Fall gibt es einen GMS-Mitschnitt-Modus im Setup-Web. Damit nimmst du auf, was deine Anlage über die Schnittstelle sendet – und schickst mir die Datei. Ich kann daraus deine Anlage dekodieren und Support bauen, ohne die Hardware je zu sehen. Drei Modi, sicherheitlich abgestuft:

Nur lauschen (empfohlen): Die Bridge sendet nichts an deine Anlage, sie hört nur zu. Maximal sicher – ideal für eine fremde oder unbekannte Zentrale.
Lauschen + Quittung: zusätzlich nur die technischen Empfangsbestätigungen, damit die Zentrale die Verbindung als gesund sieht und fleißig weiterfunkt.
Discover-Lauf: zusätzlich reine Lese-Abfragen (welche Melder belegt, wie heißen sie) – schaltet nie etwas.

Wichtig: Solange ein Mitschnitt läuft, sind alle Steuerbefehle (per Web, MQTT und HomeKit) hart gesperrt – der Diagnose-Modus kann deine Anlage also nicht versehentlich scharf- oder unscharfschalten. Und deine Geheimnisse (PINs, Passwörter) verlassen das Gerät nie; im “Nur lauschen”-Modus sind nicht einmal Melder-Klartextnamen dabei.

So einfach ist der Ablauf:

Bridge an das (vom Errichter herausgeführte) serielle Kabel anklemmen.
Setup-Web öffnen → Diagnose → GMS-Mitschnitt → Modus Nur lauschen.
2–3 Minuten laufen lassen – am besten währenddessen einmal an der Anlage scharf-/unscharfschalten.
Die Datei capture.bin herunterladen.
Mir schicken – zusammen mit Anlagentyp und, wenn du sie kennst, der Firmware-Version deiner Zentrale.

Du hast eine Telenot (Complex-Serie oder hiplex) und Lust mitzumachen? Melde dich einfach bei mir: carsten@hensiek.com. Ich freue mich über jeden Mitschnitt einer anderen Anlage und versuche, so gut und so zeitnah ich kann zu helfen – jeder bringt die Unterstützung für weitere Modelle ein Stück näher.

Ganz ehrlich dabei: Das hier ist ein Hobbyprojekt, von Bastler zu Bastler. Keine Garantie, kein Support-Vertrag, und ich bin kein Errichter – mit VdS-Zertifizierung oder einer geprüften Fernschaltung hat das alles nichts zu tun. Wer nicht schreiben und auch nicht auf v2 warten will, findet gleich unten die offene v1-Übergangslösung.

Das Repository der neuen v2-Firmware ist aktuell noch privat, ein Open-Source-Release ist geplant – der Link wird hier nachgereicht, sobald es so weit ist.

Code & Übergangslösung: Die neue Rust-Firmware (v2) steckt noch in der finalen Beta. Wer nicht auf den Public-Release warten (oder mir schreiben) möchte, kann ab sofort die bewährte, Docker-basierte Vorgängerversion v1 nutzen – Code offen auf GitHub: github.com/carhensi/telenot-bridge. Sie läuft auf einem Raspberry Pi und bindet die Telenot über Home Assistant + HomeKit ein. Sobald v2 öffentlich ist, wird sie hier verlinkt; v1 bleibt als Legacy-/Übergangszweig bestehen.

Fazit

v1 hat mir gezeigt, dass es geht. v2 zeigt, wie es richtig geht: ein einziger Chip statt einer Servicekette, Auto-Discovery statt Handarbeit, natives HomeKit statt drei Brücken – und eine Sicherheitsarchitektur, die dem Gerät angemessen ist, an dem sie hängt.

Für mich ist das Projekt auch ein schönes Beispiel dafür, was Rust im Embedded-Bereich inzwischen leistet: dieselbe Codebasis läuft im Simulator auf dem Mac und auf dem ESP32 an der Anlage, und der Compiler passt auf, wo es weh tun würde.

Disclaimer

Das Projekt ist nicht VdS-zertifiziert und sollte nur auf eigene Gefahr in einer experimentellen Umgebung eingesetzt werden.