Eine KNX-Alarmanlage in Home Assistant vom JUNG-Panel entkoppeln

Das Haus kam mit einem JUNG EAM4000 KNX-Alarmpanel, und jahrelang besaß es die gesamte Sicherheitslogik. Es schaltete die Bewegungsmelder frei, entschied über den Scharf-Zustand und steuerte die Sirenen. Als ich anfing, das Haus in Home Assistant zu ziehen, war der naheliegende Schritt, den Alarm einfach aus diesem Panel auszulesen. Habe ich nicht gemacht — und darum geht es hier.

Der naive Weg koppelt dich ans Panel

Verlockend ist es, die eigenen Ausgänge des Panels anzuzapfen: seine Zonen- und Sabotage-Objekte in HA verdrahten und als Sensoren lesen. Am ersten Tag funktioniert das. Aber dann weiß HA nur das, was das Panel ihm mitzuteilen beschließt. Ist das Panel unscharf, werden diese Zonenausgänge still, also sieht HA ebenfalls nichts. Deine Automatisierungslogik hängt jetzt unterhalb der Scharf-Logik eines anderen Systems, und du hast dir eine Abhängigkeit eingehandelt, die du kaum noch überschauen oder ändern kannst.

Ich wollte nicht, dass Home Assistant Sklave des JUNG-Panels ist. HA sollte die Instanz sein, die entscheidet, und das Panel bestenfalls ein gleichberechtigter Teilnehmer am Bus. Also habe ich umgedreht, wer die Wahrheit besitzt.

HA besitzt den Zustand und schreibt ihn zurück auf den Bus

Der Kerntrick ist fast peinlich einfach, sobald man ihn sieht. Statt den Alarmstatus aus dem Panel heraus zu lesen, habe ich Home Assistant zum Eigentümer des Alarmzustands gemacht und ihn zurück auf den KNX-Bus geschrieben. Zwei HA-input_booleans — ein 'scharf/aktiv'-Objekt und ein 'bereit'-Objekt — werden über einen expose:-Block in knx.yaml als Typ binary auf KNX-Gruppenadressen veröffentlicht. Der Bus spiegelt jetzt HAs Wahrheit, nicht die des Panels.

# knx.yaml — HA BESITZT den Alarmzustand und schreibt ihn zurück auf den Bus
# (status + 'bereit' sind HA-input_booleans, die zu KNX exposed werden, nicht gelesen)
expose:
  - type: "binary"
    entity_id: "input_boolean.knx_ha_alarm_status"
    address: "x/1/10"   # HA-eigenes 'scharf'-Objekt am Bus (echte GA maskiert)
  - type: "binary"
    entity_id: "input_boolean.knx_ha_alarm_bereit"
    address: "x/1/11"   # in HA berechnetes 'bereit'

Diese exposeten Objekte lassen sync_state bewusst weg — HA ist hier der Schreiber und darf pushen. Die Adressen nutzen die normale 3-stellige KNX-Form; die führende Gruppe habe ich maskiert, weil das ein Sicherheitsthema ist und die echte Adress-Map privat bleibt.

Präsenz über die Lichtadresse lesen, nicht über die Alarmzone

Hier kommt das Detail, über das ich mich wirklich freue. Die Bewegungsmelder feuern ohnehin ein Licht-Telegramm, um Flur- und Treppenlicht zu schalten, und sie senden es unabhängig davon, ob der Alarm scharf ist. Also lese ich jeden Melder über seine Licht-Gruppenadresse in HA ein, nicht über die Alarmzone des Panels — ein schlichter binary_sensor mit device_class: motion auf das Licht-Status-Objekt gezeigt. Der Gewinn: HA sieht Präsenz, selbst wenn der Alarm völlig unscharf ist — genau die Information, die das Panel mir verborgen hätte. Es gibt sieben JUNG 3361-1 Melder im ganzen Haus, aufgeteilt in einen Fünfer-Keller-Satz für einen 'Nacht'-Modus und den vollen Siebener-Satz für 'abwesend'.

Jeder dieser Nur-Lese-Sensoren setzt sync_state: false — Fensterkontakte, Bewegungsmelder, Sabotage. Das verhindert, dass HA GroupValueRead-Anfragen stellt oder zurückschreibt, sodass HA auf diesen Objekten ein passiver Zuhörer ist und den Bus-Verkehr der Alarmanlage nicht stört. Die oben exposeten Alarmobjekte lassen es bewusst weg, denn dort ist HA der Schreiber.

'Bereit' wird in HA berechnet, und das Scharfschalten hängt an HAs Flag

Die Bereit-Lampe ('Bereit') ist nicht mehr die Berechnung des Panels — sie ist meine. Fenster- und Öffnungskontakte sind als binary_sensor mit device_class: window direkt von ihren KNX-Status-Objekten modelliert, und das Garagentor bekommt seinen eigenen device_class: garage_door Sensor. Zwei Automatisierungen beobachten die geschossweisen Fenstergruppen für Erd- und Obergeschoss, und nur wenn jedes Fenster auf beiden Etagen als geschlossen meldet, kippen sie das exposete 'bereit'-Boolean auf an. Diese berechnete Bereitschaft wird dann zurück auf KNX geschrieben, sodass die Lampe am Bus HAs Antwort zeigt.

Das Scharfschalten läuft auf eine einzige Wahrheitsquelle zusammen. Zwei 'Sync'-Automatisierungen halten einen physischen KNX-Wandschalter und input_boolean.knx_ha_alarm_status in beide Richtungen im Gleichschritt, sodass Scharfschalten von der Wand und aus der App auf demselben Flag landen. Und jede Eskalation hängt an diesem Flag: ein offenes Fenster oder eine offene Tür triggert die Automatisierung, aber nichts eskaliert, solange HAs eigenes Scharf-Flag nicht gesetzt ist. Das JUNG-Panel steckt in dieser Entscheidung nicht mehr drin.

# Jede Eskalation hängt an HAs eigenem Scharf-Flag, nicht am JUNG-Panel:
conditions:
  - condition: state
    entity_id: input_boolean.knx_ha_alarm_status
    state: 'on'
triggers:
  - trigger: state
    from: 'off'
    to: 'on'
    for:
      seconds: 5   # einen prellenden Reed-Kontakt entprellen

Dieses for: seconds: 5 ist absichtliches Entprellen — ein flackernder Reed-Kontakt muss fünf Sekunden offen halten, bevor es zählt. Bei einem echten Trigger schreibt HA die betroffene Öffnung samt Zeitstempel in einen input_text-Helfer, loggt ins Logbuch, löst eine persistente Benachrichtigung aus, schickt einen Critical-Priority-Push an die Haushalts-Handys (Sound critical, Lautstärke 1.0, damit er durch den iOS-Fokus durchbricht) und schaltet einen lokalen Summer plus Licht in einigen Bereichen ein. Der Summer deaktiviert sich automatisch fünf Sekunden nachdem das Scharf-Boolean wieder ausgeht. Das Ganze wird in HA orchestriert, unabhängig vom Panel.

Das Sicherheitsnetz und der ehrliche Kompromiss

Vor der ganzen HA-Arbeit habe ich in ETS eine Sache gemacht: Ich habe die Sirenen-, Blitz- und Übertragungs-Gruppenadressen aus der JUNG-Zentrale herausgelöst. Der Sinn war, dass selbst bei einer Fehlauslösung des Panels während des Umbaus nichts physisch losgeht. HA wird die einzige Instanz, die einen Alarm auslösen kann. (Die Zentrale zu bearbeiten braucht JUNGs Hersteller-ETS-Plug-in unter Windows mit einem KNX/IP-Gateway — mit generischem ETS allein geht das nicht.)

Ein echter Stolperstein unterwegs: Einige Melder waren in ETS noch helligkeitsabhängig, sendeten ihr Bewegungstelegramm also nur im Dunkeln. Präsenz über die Lichtadresse zu lesen heißt, diese auf helligkeitsunabhängig umzuprogrammieren, sonst tauchen sie in HA tot auf. Ein paar von meinen taten genau das, bis ich es bemerkte.

Der ehrliche Kompromiss: Ich habe den zertifizierten, sabotageüberwachten Signalweg des Panels gegen Flexibilität eingetauscht. Die Sabotagekontakte existieren weiter — sie sind als device_class: tamper Sensoren abgebildet — aber ich route Sicherheit nicht mehr durch die Kopplung ans Panel. Wer einen überwachten, versicherungstauglichen Alarmweg braucht, für den hat dieses zertifizierte Panel weiterhin einen echten Job. Für ein Haus, in dem HA die Logik tatsächlich besitzen soll, war die Umkehr der Eigentümerschaft und das passive Mithören am Bus der sauberere Bau. Wer der Serie folgt: das baut auf demselben KNX-Fundament auf wie die früheren HACS- und Docker-Beiträge.