Der BeaconGuard Button ist ein Notrufmelder für Gebäude, in denen im Ernstfall niemand nach dem Telefon sucht. Ein Druck löst den hinterlegten Ablauf aus — Alarmierung, Eskalation, Benachrichtigung der zuständigen Stelle — und das E-Ink-Display bestätigt der Person, die gedrückt hat, dass der Ruf angekommen ist. Genau diese Rückmeldung fehlt bei einfachen Funktastern, und sie entscheidet darüber, ob jemand ein zweites und drittes Mal drückt oder Ruhe bewahrt. Weil Auf- und Abwärtsstrecke bestätigt übertragen werden und das Gerät den Ausfall der Funkstrecke selbst auf dem Display anzeigt, weiss man auch im Normalbetrieb, ob der Melder noch erreichbar ist. Firmware, Bildkatalog und Cloud-Konsole sind unsere eigene Entwicklung.

• 4 TastenHaupttaste und drei seitliche, einzeln freischaltbar
• 200 × 200 pxbistabiles E-Ink, hält das Bild ohne Strom
• 14 BilderAlarmbilder im Gerät, je Ereignis zuweisbar
• CR24771000 mAh, ohne Werkzeug wechselbar
• bestätigtLoRaWAN Klasse A, Uplink und Downlink quittiert

Was den BeaconGuard Button auszeichnet

• Rückmeldung am Gerät, nicht nur im Leitstand: Nach dem Druck wechselt das E-Ink-Display auf ein Ereignisbild, wahlweise mit freiem Text an frei wählbarer Position und in vier Schriftgrössen. Wer im Stress drückt, sieht, dass der Ruf raus ist. Ohne diese Rückmeldung bleibt jeder Funktaster eine Blackbox, und Blackboxen werden im Ernstfall mehrfach gedrückt.
• Das Gerät zeigt selbst an, wenn es nicht mehr erreichbar ist: Bleiben die erwarteten Quittungen während eines Ereignisses aus, oder kommt das periodische Lebenszeichen nicht mehr durch, wechselt die Anzeige auf ein eigenes Kein-Signal-Bild. Sobald das Lebenszeichen wieder ankommt, kehrt das Standardbild zurück. Das ist der Unterschied zwischen einem Melder, dem man vertraut, und einem, von dem man erst im Ernstfall erfährt, dass er seit Wochen tot war.
• Bestätigte Übertragung in beide Richtungen: Uplinks und Downlinks laufen quittiert über die LoRaWAN-Schicht. Ein verlorener Alarm bleibt nicht unbemerkt.
• Vier Tasten, einzeln freigeschaltet: Haupttaste plus drei seitliche. Welche aktiv sind, legt die Konfiguration per Bitmaske fest; die untere seitliche Taste bleibt für Test und Bluetooth reserviert. Kurzer und langer Druck werden getrennt gemeldet, ihre Schwellen sind einstellbar — der kurze Druck in Schritten von 10 ms, der lange in Schritten von 100 ms. So lässt sich ein Melder bauen, der auf kurzes Antippen gar nicht reagiert und erst nach drei Sekunden Halten auslöst.
• Vierzehn Alarmbilder im Gerät: Sanitätsalarm, Bedrohungsalarm, Evakuation, Amokalarm, Bombendrohung, Gasalarm, SOS, Drehlicht und Ausser-Betrieb, dazu allgemeine Symbole für Feuer, Serviceanfrage, medizinischen Notfall und technische Warnung. Alle 200 × 200 Pixel schwarzweiss. Standardbild und Ereignisbild werden je Gerät zugewiesen.
• Akustische Rückmeldung, getrennt schaltbar: Ein Signalton lässt sich für kurzen und langen Druck unabhängig ein- oder ausschalten, und der Ablauf kann verschiedene Töne auslösen. In Ruhezonen bleibt er aus, in lauten Hallen an.
• Der Ablauf hat einen definierten Anfang und ein definiertes Ende: Nach dem Druck horcht das Gerät in einem einstellbaren Fenster auf Downlinks, so oft wie konfiguriert. Der Leitstand kann in dieser Zeit Bild, Text und Ton nachführen — etwa von „Ruf abgesetzt» auf „Hilfe unterwegs». Ist die Zahl der Horchvorgänge auf null gesetzt, ist die Meldung die letzte, und das Gerät fällt danach auf das Standardbild zurück.
• Firmware aus eigener Hand: Ablauflogik, Bildkatalog und Meldeformat sind unsere Entwicklung. Sonderwünsche an Anzeigetexten, Tastenverhalten oder Payload sind deshalb eine Frage des Aufwands, nicht der Machbarkeit.
• Fertiger Payload-Formatter für The Things Stack: Decoder und Downlink-Encoder liegen als JavaScript-Datei bereit, zum Einsetzen in beide Formatterfelder des Geräts. Downlinks gehen auf FPort 2. Dazu ein Werkzeug, das eine Konfiguration Feld für Feld zusammensetzt und den entstehenden Payload byteweise erklärt.
• Anbindung über Webhooks und REST: Ereignisse werden als Webhook zugestellt, Gerätebestand und Downlinks laufen über eine REST-Schnittstelle. Gebäudeleittechnik und Sicherheitsplattformen lassen sich ohne Zwischenschicht anbinden.
• Farbcodierung als Bedienkonzept: Das Gehäuse gibt es in Violett für Panikalarm, Blau für den medizinischen Notfall und Bernstein für Evakuation. Personal erkennt den richtigen Knopf an der Farbe, nicht an einer Beschriftung, die man lesen müsste. Weitere Farben und Symbolsätze sind für gebäudespezifische Szenarien möglich.

Wo der BeaconGuard Button eingesetzt wird

• Spitäler und Pflegeeinrichtungen: Medizinischer Notfall im Patientenzimmer, im Gang, im Untersuchungsraum. Die Farbe ist im Haus eindeutig belegt, der Ablauf ruft das zuständige Team statt einer allgemeinen Nummer, und die Anzeige führt den Auslösenden durch die Wartezeit.
• Schulen und Hochschulen: Panikalarm in Schulzimmern und Hörsälen, Evakuationsauslösung an definierten Punkten. Für Amoklage und Bombendrohung liegen eigene Bilder im Gerät. Der Ausbau erfolgt raumweise ohne Bauarbeiten.
• Bürohochhäuser: Vertikale Abdeckung ist der klassische Schwachpunkt von WLAN-Lösungen. Sub-GHz-Funk durchdringt Geschossdecken, weshalb wenige Gateways ein ganzes Haus tragen.
• Veranstaltungsorte und öffentlich zugängliche Gebäude: Melder an Punkten, an denen Personal allein arbeitet — Garderobe, Kasse, Nebenräume. Der lange Tastendruck als Auslöseschwelle verhindert, dass Publikum versehentlich auslöst.
• Industrie und Werkhallen: Alleinarbeitsplätze und Bereiche ohne Sichtkontakt. Signalton eingeschaltet, Gasalarmbild hinterlegt, Auslösung erst nach mehreren Sekunden Halten.
• Bestehende LoRaWAN-Installationen: Wo bereits Gateways für Sensorik stehen, kommt der Melder ohne zusätzliche Infrastruktur dazu. Mit dem fertigen Payload-Formatter ist er auf The Things Stack in Minuten eingebunden.

Was zum Gerät gehört

Der Button allein ergibt noch kein Alarmsystem. Wir liefern drei Ausbaustufen, und die Wahl gehört an den Anfang des Projekts, nicht ans Ende:

• Nur Hardware: Melder und Gateways zur Einbindung in bestehende Systeme, mit technischer Dokumentation, Payload-Formatter und Zugang zur Schnittstelle. Richtig, wenn ein Netzwerkserver und eine Alarmierungsplattform bereits vorhanden sind.
• Hardware und Cloud-Konsole: Dazu die zentrale Verwaltung — Ablaufbaukasten, Weiterleitungsregeln, Batterieüberwachung, Webhooks. Der übliche Weg für Häuser ohne eigene IoT-Plattform.
• Hardware mit Einführung: Zusätzlich Standortbegehung und Abdeckungsplanung, Begleitung der Installation, Prüfung im Betrieb und Schulung. Für Häuser, in denen die Inbetriebnahme selbst ein Projekt ist.

Technische Daten

Masse, Gewicht, Schutzart, Betriebstemperaturbereich und die zu erwartende Batterielaufzeit tragen wir nach, sobald sie geprüft sind. Wir stellen lieber keine Zahl hin als eine, die im Projekt nicht hält — frag uns, wenn du sie für die Planung brauchst, dann messen wir nach.

Unterstützung

Der BeaconGuard ist unsere eigene Entwicklung. Das heisst für dich: Wir beantworten Fragen zur Ablauflogik, zum Meldeformat und zur Anbindung nicht über einen Distributor, sondern direkt — und Anpassungen an Anzeigetexten, Tastenverhalten oder Schnittstelle sind besprechbar. Die vollständige Beschreibung aller Nachrichtenfelder, den Payload-Formatter und ein Werkzeug zum Zusammensetzen von Konfigurationen stellen wir zur Verfügung. Für die Abdeckungsplanung im konkreten Gebäude nehmen wir uns gerne Zeit, bevor bestellt wird.