DIVERA 24/7 im Smart Home: Wenn der Alarm das Licht einschaltet
Fallstudie aus der Ortsfeuerwehr Ölper mit einem Alarm, einem neutralen Signal und beliebig vielen Zuhause
03:14 Uhr, das Handy vibriert auf dem Nachttisch. Bis das Licht an ist, bis die Kleidung gefunden ist, bis die Haustür zufällt, vergehen wertvolle Sekunden. Genau in dieser Zeit passiert im Haus technisch nichts. Dabei steht in vielen Fluren längst eine smarte Lampe, in der Küche ein Lautsprecher und im Keller ein kleiner Server.
Kurz gesagt: Für die Ortsfeuerwehr Ölper hat die Agentur Zentral GmbH eine Plattform entwickelt, die einen DIVERA-Alarm entgegennimmt und als neutrales Signal an die Smart-Home-Systeme der Einsatzkräfte verteilt. DIVERA braucht dafür nur einen einzigen Webhook, die Zahl der persönlichen Ziele ist nach oben offen und Einsatzdaten verlassen das System nicht. Dieser Beitrag zeigt, wie die Lösung entstanden ist, wie sie aufgebaut ist und wo bewusst Grenzen gezogen wurden.
Was DIVERA 24/7 leistet und wo es aufhört
DIVERA 24/7 ist eine Alarmierungs- und Einsatzplattform für Feuerwehren, Rettungsdienste und Hilfsorganisationen. Sie nimmt die Alarmierung der Leitstelle entgegen und verteilt sie an die Einsatzkräfte, als Push auf das Smartphone, ergänzt um Einsatzstichwort, Adresse, Karte und Rückmeldefunktion. Dazu kommen Verfügbarkeitsstatus, Fahrzeug- und Personalübersichten, Alarmmonitore im Gerätehaus sowie Schnittstellen zu Drittsystemen.
Eine dieser Schnittstellen ist die Datenübergabe per Webhook. Sie ruft bei einem Alarm automatisch eine frei wählbare Web-Adresse auf und überträgt dabei wahlweise gar keinen Inhalt oder ein vollständiges JSON-Objekt mit Einsatz- und Empfängerdaten. Eingerichtet wird sie in der Verwaltung der Einheit über die Einstellungen, den Bereich Schnittstellen und dort die Datenübergabe. Die Zahl der möglichen Webhooks ist tarifabhängig begrenzt.
Damit endet aber auch der Zuständigkeitsbereich von DIVERA. Die Plattform alarmiert Menschen, nicht Wohnungen. Sie kennt keine Lampen, keine Lautsprecher und keine Routinen. Und sie ist nicht dafür gedacht, für jede einzelne Einsatzkraft ein eigenes Zielsystem zu verwalten.
Ein Alarm für viele Zuhause
Die Idee war zunächst klein. Ein DIVERA-Alarm sollte in einem Haushalt das Licht einschalten. Technisch ist das lösbar, weil Alexa selbst zwar keinen beliebigen HTTP-Aufruf als Routinen-Auslöser akzeptiert, ein Dienst wie Voice Monkey aber genau diese Brücke baut und einen virtuellen Auslöser bereitstellt.
Sobald jedoch mehr als eine Person mitmachen möchte, kippt diese Rechnung. Jede Einsatzkraft hätte eine eigene Zieladresse und jede dieser Adressen bräuchte einen eigenen DIVERA-Webhook. Die verfügbaren Webhooks sind schnell aufgebraucht. Schon vorher wird die Verwaltung unangenehm. Wer trägt neue Kameraden ein? Wer entfernt sie beim Austritt wieder? Wer merkt, dass eine Zustellung seit Wochen fehlschlägt?
Hinzu kommt eine Frage, die schwerer wiegt als die Technik. Was genau soll ein Alarm eigentlich nach draußen tragen? Ein Webhook mit vollständigem Einsatzobjekt schickt Stichwort, Adresse und Empfängerdaten an einen externen Dienstleister. Für „Licht an“ braucht es davon nichts.
Eine eigene Plattform statt vieler Webhooks
Die Lösung liegt in einer Umkehrung der Architektur. Statt DIVERA für jedes Ziel einzeln zu konfigurieren, bekommt DIVERA genau einen Empfänger, nämlich eine eigene Webanwendung unter einer Subdomain der Feuerwehr. Dort landet der Alarm und erst dort wird entschieden, wer welches Signal erhält.
Der Ablauf sieht damit so aus. Die Leitstelle alarmiert, DIVERA erhält den Einsatz und ruft einen einzigen Webhook auf. Die Plattform verteilt daraufhin ein neutrales Signal an alle freigegebenen Ziele und im jeweiligen Smart-Home-System startet die persönliche Routine.
Das löst mehrere Probleme auf einmal. Die Zahl der Nutzenden ist nach oben offen, weil sie nichts mehr mit der Zahl der DIVERA-Webhooks zu tun hat. Neue Mitglieder werden in der Plattform angelegt, nicht in der DIVERA-Konfiguration. Und die Entscheidung, welche Daten das Haus der Feuerwehr verlassen, fällt an genau einer Stelle.
Technisch steht dahinter eine PHP-Anwendung mit MySQL-Datenbank auf gewöhnlichem Webhosting. Es braucht keinen eigenen Server im Gerätehaus, keinen Raspberry Pi im Schrank und keine Hardware, die jemand warten müsste. Fällt ein Zielsystem aus, betrifft das nur diesen einen Haushalt.
Ein Signal, viele Systeme
Von Anfang an war klar, dass die Plattform nicht auf einen Hersteller festgelegt sein durfte. Wer heute Alexa nutzt, betreibt morgen vielleicht Home Assistant. Wer basteln möchte, hat einen Raspberry Pi im Regal stehen.
Umgesetzt ist das über austauschbare Zielsysteme. Alexa wird über einen Voice-Monkey-Routinentrigger angesprochen, Home Assistant über einen Webhook, ioBroker über einen REST-Endpunkt und Node-RED über einen HTTP-In-Flow. Dazu kommen selbst gehostete Endpunkte auf einem Raspberry Pi sowie ein generischer HTTPS-Webhook für alles Weitere.
Google Home fehlt in dieser Liste bewusst. Google bietet derzeit keinen allgemeinen Webhook-Starter für persönliche Routinen an. Statt eine halbfertige Lösung zu versprechen, dokumentiert die Plattform den sauberen Brückenweg über Home Assistant, Node-RED oder ioBroker.
Was am Ende passiert, entscheidet jede Einsatzkraft selbst. Die Plattform liefert nur den Auslöser. Ob daraufhin das Flurlicht angeht, die Kaffeemaschine startet oder der Fernseher stummgeschaltet wird, ist eine private Routine im jeweiligen System.
Ein eigener Zugang für jede Einsatzkraft
Der Einstieg in die Plattform ist bewusst schlicht gehalten. Jedes Mitglied meldet sich mit einem persönlichen Portal-Konto an und sieht danach nur die eigenen Verbindungen. Wer Verwalter oder Administrator ist, bekommt zusätzlich die Bereiche für Benutzer, Freigaben und Systemstatus.
Der Zugang ist damit klar von DIVERA getrennt. Wer die Smart-Home-Funktion nicht nutzen möchte, legt schlicht kein Konto an und bekommt auch kein Signal. Wer aussteigt, wird deaktiviert und die hinterlegten Ziele werden nicht mehr angesprochen. Diese Trennung war eine bewusste Entscheidung, denn eine freiwillige Komfortfunktion darf niemanden zur Teilnahme zwingen.
Die Anmeldung selbst folgt den üblichen Anforderungen an eine Webanwendung im Feuerwehrumfeld. Passwörter werden gehasht gespeichert, die Verbindung läuft ausschließlich über HTTPS und fehlgeschlagene Anmeldeversuche werden begrenzt. Neue Mitglieder erhalten eine Einladung per E-Mail und vergeben ihr Passwort selbst, sodass niemand ein Startpasswort weitergeben muss.
Auch optisch bleibt die Oberfläche im Rahmen. Sie nimmt das Wappen der Ortsfeuerwehr auf, arbeitet mit dem vertrauten Signalrot und lässt sich zwischen hellem und dunklem Modus umschalten. Auf dem Smartphone funktioniert sie genauso wie am heimischen Rechner.
Verwaltung statt Skriptpflege
Eine Lösung, die nur der Entwickler bedienen kann, ist im Feuerwehralltag wertlos. Deshalb gibt es ein Rollenmodell mit drei Stufen. Administratoren steuern das System, Verwalter legen Benutzer an und richten deren Ziele ein, Benutzer pflegen ihre eigenen Verbindungen.
Neue Mitglieder erhalten eine Einladung per E-Mail und richten ihr Ziel anschließend selbst ein. Ein Testsignal prüft direkt aus der Oberfläche, ob die Kette bis zur eigenen Lampe funktioniert, ohne dass dafür ein echter Einsatz abgewartet werden muss. Übersichten zeigen, wie viele Ziele je Person aktiv sind und wann die letzte Anmeldung stattgefunden hat.
Damit bleibt die Verwaltung dort, wo sie hingehört. Wer neu in die Einsatzabteilung kommt, wird einmal angelegt und richtet den Rest selbst ein. Wer die Wehr verlässt, wird deaktiviert und erhält kein Signal mehr.
Wer darf überhaupt angerufen werden?
Eine Anwendung, die auf Zuruf beliebige Adressen im Internet aufruft, ist ein bekanntes Sicherheitsrisiko. Trägt jemand statt seines Smart-Home-Endpunkts eine interne Adresse ein, wird der Server zum Werkzeug gegen das eigene Netz. Dieses Muster heißt Server-Side Request Forgery und ist in Webanwendungen mit frei konfigurierbaren Zielen der klassische Fehler.
Die Plattform begegnet dem mit einer Freigabeliste. Ziele bekannter Anbieter mit festem Host sind automatisch freigegeben. Trägt jemand einen eigenen öffentlichen Host ein, wird dieser erst nach Prüfung und ausdrücklicher Freigabe durch einen Administrator angesprochen. Bis dahin steht die Verbindung auf „wartet auf Freigabe“ und stellt nichts zu.
Dazu kommen weitere Schutzmaßnahmen. Zieladressen werden verschlüsselt gespeichert. Eingehende Alarme werden dedupliziert, damit ein doppelt ausgelöster Webhook nicht zu doppelten Signalen führt. Und die Zustellung läuft über eine Warteschlange statt synchron im Request.
Betrieb sichtbar machen statt hoffen
Eine Alarmkette, die man nur im Ernstfall bemerkt, ist eine Alarmkette, die man zu spät bemerkt. Deshalb legt die Plattform ihren technischen Zustand offen. Sichtbar sind PHP- und Datenbankversion, verfügbare Erweiterungen, der Status des Cronjobs, der Zustand der Zustellwarteschlange und der Zeitpunkt des letzten Events.
Wartende, laufende, erfolgreiche und endgültig fehlgeschlagene Zustellungen sind getrennt ausgewiesen. Damit lässt sich eine einzelne fehlerhafte Verbindung von einem Problem des gesamten Systems unterscheiden. Ein öffentlicher Healthcheck erlaubt zusätzlich die Überwachung von außen, etwa durch einen Monitoring-Dienst, der bei einem Ausfall eine Meldung verschickt.
Die Zustellung läuft dabei nicht im Request des eingehenden Alarms, sondern über eine Warteschlange, die ein Cronjob abarbeitet. Das hat einen praktischen Grund. Wenn ein Zielsystem langsam antwortet oder gerade nicht erreichbar ist, blockiert das nicht die Annahme des Alarms und auch nicht die Zustellung an alle anderen Empfänger.
So lässt sich vor dem Einsatz beantworten, was sonst erst im Einsatz auffällt.
Warum das Signal absichtlich leer ist
Die vielleicht wichtigste Entscheidung im gesamten Projekt ist eine Verzichtsentscheidung. DIVERA könnte im Webhook ein vollständiges Einsatzobjekt liefern, inklusive Stichwort, Einsatzadresse und Empfängerinformationen. Die Plattform gibt davon nichts nach außen weiter.
Was ein Smart-Home-System benötigt, um eine Routine zu starten, ist ein Auslöser. Mehr nicht. Eine Lampe muss nicht wissen, ob es sich um einen Brandeinsatz oder eine Türöffnung handelt. Ein Sprachassistent eines kommerziellen Anbieters muss keine Einsatzadressen speichern.
Nach außen geht deshalb ein neutrales Signal ohne Einsatzdetails. Einsatzbezogene Informationen bleiben dort, wo sie hingehören, also in DIVERA und auf den Endgeräten der Einsatzkräfte.
Grenzen, die man kennen sollte
Diese Lösung ist eine ergänzende Komfortfunktion. Sie ersetzt keine offizielle Alarmierung über DIVERA und keine BOS-Alarmierungsmittel. Wer sich auf das Licht im Flur verlässt statt auf Melder und App, hat die Kette falsch verstanden.
Auch technisch gibt es Abhängigkeiten. Die Zustellung setzt eine funktionierende Internetverbindung im Zielhaushalt voraus. Dienste wie Voice Monkey sind Angebote Dritter mit eigenen Grenzen im kostenlosen Tarif. Und jede zusätzliche Station in der Kette bringt eigene Latenz mit, also DIVERA, die Plattform, der Brückendienst und der Sprachassistent. In der Praxis liegt das im Sekundenbereich, garantiert ist es nicht.
Diese Grenzen sind kein Nebensatz im Kleingedruckten, sondern stehen als Hinweis dauerhaft im Fuß der Anwendung.
Was das für andere Projekte bedeutet
Der eigentliche Kern dieses Projekts ist keine Feuerwehr-Besonderheit. Es geht um eine Situation, die in vielen Organisationen vorkommt. Ein System kann Daten nach außen geben, aber nicht in der Form, in der ein zweites System sie braucht. Zwischen beiden fehlt eine Stelle, die übersetzt, verteilt, absichert und protokolliert.
Genau solche Verbindungsstücke entwickelt die Agentur Zentral GmbH, von der Schnittstellenanalyse über die Architektur bis zum laufenden Betrieb. Ob als Webanwendung mit eigener Oberfläche, als Middleware zwischen zwei Fachanwendungen oder als Erweiterung einer bestehenden Website. Entscheidend ist nicht die Größe des Systems, sondern dass am Ende jemand die Verantwortung für Betrieb, Sicherheit und Datenschutz übernimmt.
Fazit: ein Signal genügt
Die Plattform für die Ortsfeuerwehr Ölper beantwortet eine kleine Frage mit einer sauberen Architektur. Nicht jede Einsatzkraft braucht einen eigenen Webhook. Nicht jedes Smart-Home-System braucht Einsatzdaten. Und nicht jede Integration muss sich auf einen Hersteller festlegen.
Ein zentraler Eingang, ein neutrales Signal und kontrollierte Ziele machen die Lösung offen für beliebig viele Nutzende, unabhängig vom Sprachassistenten und datensparsam an der Stelle, an der es zählt. Was danach im eigenen Zuhause passiert, entscheidet jeder selbst.
Häufige Fragen
Hier finden Sie kurze Antworten auf die wichtigsten Fragen zur DIVERA-Smart-Home-Plattform.
Nein. Sie ist eine ergänzende Komfortfunktion und ersetzt weder DIVERA noch BOS-Alarmierungsmittel. Die verbindliche Alarmierung bleibt unverändert.
Nein. Nach außen geht ein neutrales Signal ohne Stichwort, Adresse oder Personenbezug. Einsatzdetails bleiben in DIVERA.
Die Zahl ist nach oben offen. DIVERA benötigt nur einen einzigen Webhook; die Verteilung an beliebig viele persönliche Ziele übernimmt die Plattform.
Alexa über Voice Monkey, Home Assistant, ioBroker, Node-RED, selbst gehostete Endpunkte auf einem Raspberry Pi und Ähnlichem sowie ein generischer HTTPS-Webhook. Für Google Home ist der Weg über Home Assistant, Node-RED oder ioBroker dokumentiert.
Nicht ohne Prüfung. Ziele bekannter Anbieter sind freigegeben, eigene Hosts werden erst nach ausdrücklicher Freigabe durch einen Administrator angesprochen.