# Handbuch für Mandanten-Admins Bedienung der Mandanten-GUI: Pager verwalten, DIVERA integrieren, Alarme # Alarme, gesendete Alarme und Logs # Alarme, gesendete Alarme und Logs Die drei Ansichten **Alarme**, **Gesendete Alarme** und **Logs** sind Ihre wichtigsten Werkzeuge zur Nachverfolgung des Alarmflusses. Jede Ansicht zeigt einen anderen Blickwinkel auf die gleiche Kette. ## Menüpunkt „Alarme" Die Seite **Alarme** zeigt alle eingegangenen Alarm-Trigger – sowohl DIVERA-Webhooks als auch Pager-seitige Notruf-Ereignisse (MANDOWN, NOTRUF, TEAROFF). ### Tabelle Für jeden Eintrag sehen Sie: - **Empfangen um** – Zeitstempel der Einlieferung beim Broker - **Quelle** – „DIVERA" oder „Pager" - **Titel** – z.B. der Einsatzstichwort von DIVERA oder „NOTRUF" - **Text** – Alarmtext / Kurzbeschreibung - **Adresse** – Ort des Einsatzes (wenn verfügbar) - **Instance** – DIVERA-Instanz oder Pager-UID - **Gerouted an** – Anzahl der Pager, an die dieser Alarm weitergeleitet wurde ### Filter Oben finden Sie Filter nach: - **Zeitraum** (Start/Ende) - **Quelle** (DIVERA oder Pager) Die Ansicht ist auf 500 Einträge je Abfrage begrenzt. Ältere Einträge bleiben in der Datenbank, werden aber nicht automatisch geladen. ### Detail-Ansicht Klicken Sie einen Alarm an, öffnet sich die Detail-Seite mit dem vollständigen JSON-Payload (bei DIVERA) und einer Liste aller Pager, an die dieser Alarm routed wurde. Pro Pager sehen Sie: Status (sent/failed/retry_pending), Zeitpunkt, RIC, eventuelle Fehlermeldung. ## Menüpunkt „Gesendete Alarme" Während **Alarme** das „Ein"-Kommen zeigt, ist **Gesendete Alarme** das „Aus"-Gehen zu den Pagern. Jede einzelne Pager-Nachricht erzeugt genau einen Eintrag hier. ### Tabelle - **Erstellt** / **Gesendet** – Erstellungszeit in der Queue und tatsächliche Versandzeit - **Pager** – Seriennummer und Bezeichnung - **RIC** – Ziel-RIC (oder leer bei Nur-Text) - **Status** – `queued`, `sent`, `failed`, `retry_pending`, `cancelled` - **Retry-Zähler** – wie viele Versuche bereits unternommen wurden (0 bis 60) - **Fehler** – die letzte Fehlermeldung (wenn `failed` oder `retry_pending`) ### Status-Bedeutungen **`queued`** Frisch in der Queue, noch nicht versendet. Normalerweise sehr kurz (unter einer Sekunde). **`sent`** Erfolgreich an den Pager übergeben. Bei TCP: TCP-Ack vom Pager erhalten. Bei MQTT: Mosquitto hat den Publish bestätigt – der Pager war zu dem Zeitpunkt online. **`retry_pending`** Die Zustellung ist beim aktuellen Versuch fehlgeschlagen. In `next_retry_at` steht, wann der nächste Versuch gemacht wird (meist in 1 Minute). `retry_count` wird hochgezählt. **`failed`** Nach 60 erfolglosen Versuchen (also ca. 1 Stunde lang) wurde endgültig aufgegeben. `last_error` enthält den Grund des letzten Fehlschlags. **`cancelled`** Der Alarm wurde manuell abgebrochen. Kommt selten vor. ### Filter und Suche Sie können filtern nach: - Zeitraum - Pager (Seriennummer) - Status - RIC Zusätzlich gibt es ein freies Suchfeld, das über alle Textfelder läuft. ### Warum „sent" nicht automatisch „angekommen" bedeutet Eine subtile, aber wichtige Eigenheit: Bei MQTT-Pagern bestätigt der Mosquitto-Broker den Publish, sobald die Nachricht bei ihm liegt. Ob der Pager sie dann tatsächlich empfängt, hängt davon ab, ob er online war. Der Broker hat deshalb eine Zusatzprüfung eingebaut: Bevor er eine MQTT-Nachricht versendet, prüft er `pager.last_seen_mqtt`. Ist diese älter als 15 Minuten, wird der Versand zurückgestellt (`retry_pending` mit Fehler „pager_offline_mqtt"). Nur wenn der Pager tatsächlich online ist, wird der Publish ausgeführt. Bei TCP ist das einfacher: Eine tote TCP-Verbindung erkennt der Kernel schnell (TCP Keep-Alive alle 30 s), und der Broker setzt den Status entsprechend. ## Menüpunkt „Logs" Die **Logs**-Seite zeigt das Rohprotokoll aller Pager-Kommunikation in Ihrem Mandanten – eingehend und ausgehend, TCP und MQTT. ### Ansichten Im oberen Bereich können Sie zwischen vier Ansichten umschalten: **Eingehend (Inbound)** Alle vom Pager empfangenen Nachrichten (Keep-Alives, Status-Rückmeldungen, Notrufe). **Ausgehend (Outbound)** Alle an Pager gesendeten Nachrichten (Alarme). **DIVERA** Alle DIVERA-API-Aufrufe (Outbound-Status-Meldungen). **System** Anwendungs-Logs des Brokers (nur der Anteil, der Ihren Mandanten betrifft). ### Spalten Pro Eintrag sehen Sie: - **Datum / Uhrzeit** - **Pager-UID** (wenn zutreffend) - **Befehl** (cmd_num und Beschreibung) - **Payload** (Rohdaten oder JSON) - **Verbindungstyp** (TCP/MQTT) - **Remote-Adresse** (IP des Pagers bei TCP) ### Auto-Refresh Oben befindet sich ein Toggle **Auto-Refresh** mit einstellbarem Intervall (1–30 Sekunden). Aktiviert lädt die Tabelle regelmäßig neu. Das ist nützlich, wenn Sie eine laufende Kommunikation beobachten möchten. ### Zeitraum-Filter Beschränken Sie die Ansicht auf einen Zeitraum, um historische Vorgänge nachzuvollziehen. ### Suche und Filter - **Pager-UID** (14 Ziffern) - **Remote-IP** - **Befehl** (z.B. nur Keep-Alives oder nur Notrufe filtern) ## Gemeinsame Detail-Ansicht In allen drei Ansichten können Sie einen Eintrag anklicken, um die Detail-Ansicht zu öffnen. Dort sehen Sie: - Vollständigen Rohdaten-Dump (hex, base64 oder JSON) - Details zur Pager-Registrierung - Zeitstempel in verschiedenen Formaten - Verlinkung zu verwandten Einträgen (z.B. von „Gesendeter Alarm" zum auslösenden DIVERA-Alarm) ## Praktische Use-Cases **Einen konkreten Einsatz verfolgen** Notieren Sie die DIVERA-Alarm-ID. Öffnen Sie **Alarme**, filtern Sie nach dieser ID. Klicken Sie den Eintrag an – Sie sehen alle Pager, an die gerouted wurde. Klicken Sie auf einen Pager – Sie landen in **Gesendete Alarme** und sehen, wie es dort ausging. Von dort können Sie in **Logs** springen und die tatsächliche Pager-Nachricht sehen. **Problem mit einem konkreten Pager** Öffnen Sie **Logs**, filtern Sie nach der UID des Pagers. Schalten Sie auf „Eingehend" – sehen Sie, ob der Pager überhaupt Keep-Alives sendet. Schalten Sie auf „Ausgehend" – sehen Sie, welche Alarme in letzter Zeit geschickt wurden und welchen Status sie haben. **Ausfallzeit rekonstruieren** Suchen Sie in **Logs** → „System" nach Einträgen wie „PANIC", „FATAL", „Connection lost". Das hilft bei der Diagnose, warum zu einer bestimmten Zeit Alarme nicht durchkamen. ## Export Aktuell gibt es keine direkte Export-Funktion in der Mandanten-GUI. Sie können Listen per Copy&Paste aus der Browser-Ansicht entnehmen. Für umfangreichere Exporte (CSV, JSON) wenden Sie sich an den Super-Admin, der Datenbank-Abfragen direkt ausführen kann. ## Retention Einträge in den Log-Tabellen werden aktuell **nicht automatisch gelöscht**. Die Datenbank wächst also mit der Zeit. Wenn Sie eine dezidierte Aufbewahrungs-Policy benötigen (z.B. „alle Keep-Alives älter als 30 Tage löschen"), sprechen Sie Ihren Super-Admin an. Der Broker unterstützt solche Policies prinzipiell, aber sie sind nicht pro Mandant einstellbar. # DIVERA24/7-Integration Die Integration mit DIVERA24/7 ist das Herzstück jedes Mandanten. Dieses Kapitel beschreibt detailliert, wie Sie die bidirektionale Schnittstelle einrichten und betreiben. ## Was ist DIVERA24/7? **DIVERA24/7** ist eine cloudbasierte Einsatzleit- und Alarmierungssoftware der divera GmbH. Leitstellen nutzen DIVERA, um Einsatzaufträge zu erstellen und Einsatzkräfte zu alarmieren. Die Software ist in Deutschland bei vielen Feuerwehren, Rettungsdiensten und anderen BOS-Organisationen im Einsatz. ## Wie arbeiten DIVERA und der Broker zusammen? Die Kopplung funktioniert in **beide Richtungen**. ### Inbound (DIVERA → Broker) DIVERA sendet bei jedem neuen Einsatz einen **Webhook** (HTTP POST mit JSON-Payload) an eine URL, die Sie in DIVERA konfigurieren. Der Broker empfängt diesen Webhook, speichert ihn in der Datenbank (`alarm_divera_inbound`) und leitet den Alarm an die passenden Pager weiter – basierend auf den `divera_rics`-Einstellungen Ihrer Pager. ### Outbound (Broker → DIVERA) Wenn ein Pager eine Status-Rückmeldung sendet (z.B. „Ich komme"), übersetzt der Broker diese in einen HTTPS-Aufruf an die DIVERA-API. DIVERA kennt dann den Status der alarmierten Kraft und zeigt ihn in der Leitstellen-Übersicht an. ## DIVERA-Auth-Key hinterlegen Bevor Outbound funktionieren kann, müssen Sie Ihren DIVERA-Auth-Key im Broker eintragen. ### Auth-Key in DIVERA besorgen Loggen Sie sich in DIVERA ein. Gehen Sie zu **Verwaltung → Schnittstellen → API-Schlüssel** (oder ähnlich, je nach DIVERA-Version). Erstellen Sie einen neuen API-Schlüssel. Der Schlüssel ist eine lange Zeichenkette, etwa: ``` if185u4vdGQrmY3GCNF1rj7Nb4ned8c8xiMPIMNi8Pt1trKXEtxw8K9QZ98LIjUB ``` Kopieren Sie ihn in die Zwischenablage. ### Auth-Key im Broker eintragen In der Broker-GUI: **Einstellungen** → Button **Alarmdienste verwalten**. Im geöffneten Modal sehen Sie ein Feld **DIVERA24/7 Auth-Key**. Fügen Sie den Schlüssel ein. Nach Klick auf **Speichern** wird der Schlüssel verschlüsselt in der Datenbank abgelegt. Der Key wird **zweifach** gespeichert – in `tenants.divera_authkey` und in `system_config` unter dem Schlüssel `divera_auth_key` mit Ihrer `tenant_id`. Der Broker-Code bevorzugt beim Zugriff zuerst `tenants.divera_authkey`. Diese Redundanz ist historisch gewachsen und wird in einer zukünftigen Version konsolidiert. ### Weitere Alarmdienste-Einstellungen Im gleichen Modal stehen Toggles für verschiedene Funktionen: **DIVERA24/7 Inbound** Aktiviert die Verarbeitung eingehender Webhooks. Wenn deaktiviert, werden die Webhooks zwar in `alarm_divera_inbound` gespeichert, aber keine Pager werden alarmiert. Nützlich zum Testen/Pausieren. **DIVERA24/7 Outbound** Aktiviert das Senden von Status-Rückmeldungen (KOMME etc.) an DIVERA. **Mandown an DIVERA24/7 senden** Wenn ein Pager seine Mandown-Taste drückt (cmd `0A`), wird automatisch ein Alarm in DIVERA erzeugt. Achtung: Das erstellt einen echten Einsatz in DIVERA! **Notrufe an DIVERA24/7 senden** Analog: Bei Notruf-Taste (cmd `08`) wird ein Einsatz erzeugt. **Tear-Off Alarme weiterleiten** Bei Abreißen des Pagers von der Halterung (cmd `0B`) wird ein Einsatz erzeugt. Die drei letzten Funktionen sind standardmäßig **deaktiviert**. Aktivieren Sie sie nur, wenn Ihre DIVERA-Konfiguration und Ihre Organisation damit umgehen kann. ## Webhook-URL in DIVERA eintragen Jetzt muss DIVERA wissen, wohin es seine Alarme senden soll. ### Die URL konstruieren Der Broker akzeptiert Webhooks auf zwei äquivalenten URLs: **Variante A (Subdomain-basiert):** ``` https://10001.pager.dexa.gmbh/webhook/divera/ ``` Der Mandant wird aus der Subdomain `10001` abgeleitet. Der Pfad endet mit `/webhook/divera/` (mit oder ohne trailing slash). **Variante B (Pfad-basiert):** ``` https://pager.dexa.gmbh/webhook/divera/10001 ``` Der Mandant wird aus dem Pfad-Segment `10001` abgeleitet. Einfacher einzutragen, weil keine Subdomain involviert ist. Beide Varianten funktionieren identisch. Auch `broker.dexa.gmbh` statt `pager.dexa.gmbh` ist erlaubt. ### Den Webhook in DIVERA konfigurieren In DIVERA: **Verwaltung → Schnittstellen → Alarmierung → Webhook (ausgehend)** oder ähnlich. Legen Sie eine neue Schnittstelle an: - **Name:** z.B. „BOS Data Broker" - **URL:** siehe oben - **HTTP-Methode:** POST - **Content-Type:** application/json - **Trigger:** Neuer Einsatz (und ggf. Updates) Aktivieren Sie die Schnittstelle. DIVERA sollte bei der Aktivierung eine Test-Anfrage senden – Sie sehen diese dann in Ihren Log-Tabs (System oder DIVERA). ### Webhook-Payload von DIVERA DIVERA sendet pro Einsatz ein JSON-Objekt mit allen relevanten Daten. Die wichtigsten Felder: ```json { "id": 32375472, "foreign_id": "SFH-20260422-153000-001", "title": "Rauchmelder ALARM", "text": "Rauchsensor hat Rauch erkannt: HLF20-1 RM1", "address": "Haferlandweg 18, 48157 Münster", "lat": 51.991, "lng": 7.651, "pager": ["1366481A", "1369114A"], "cluster_id": 12345, "priority": true, "created_at": "2026-04-22T10:11:01+02:00" } ``` Das Feld `pager` ist für die Broker-Logik am wichtigsten – es enthält die RICs, die DIVERA für diesen Einsatz an Pager adressieren möchte. Der Broker gleicht diese RICs mit den `divera_rics` seiner Pager ab und findet so die Zieldevices. ## Der Inbound-Fluss im Detail Wenn ein DIVERA-Webhook eingeht, läuft intern folgende Kette ab: 1. **Nginx** nimmt die HTTPS-Anfrage auf Port 443 entgegen und leitet sie an `iotwebui:8082` weiter. 2. **iotwebui** ruft den Handler `handleDiveraWebhook` auf. Dieser ermittelt den Mandanten (aus Subdomain oder URL-Pfad) und fügt einen Eintrag in die Tabelle `alarm_divera_inbound` ein. 3. Ein PostgreSQL-**Trigger** löst ein `NOTIFY alarm_inbound_new` aus. 4. Der Dienst **alarm-processor** hat auf diesen Kanal gelauscht. Er liest den Eintrag, parst `divera_raw` und ermittelt für jede RIC im `pager`-Array die passenden Pager des Mandanten. 5. Für jeden Treffer-Pager erzeugt er einen Eintrag in `tcp_outbound` mit Status `queued`. 6. Der PostgreSQL-Trigger `notify_alarm_queued` löst aus. 7. Der Dienst **iotserver** hat auf `alarm_queued` gelauscht. Er greift den Eintrag auf und dispatcht ihn – entweder per TCP-Frame oder MQTT-Publish. 8. Nach erfolgreichem Versand (TCP-Ack oder MQTT-Broker-Ack) wird `tcp_outbound.status` auf `sent` gesetzt. 9. Gelingt der Versand nicht: Status wird `retry_pending`, nächster Versuch in 60 Sekunden. Nach 60 erfolglosen Versuchen endgültig `failed`. Im Mandanten-GUI können Sie diesen Fluss live verfolgen – unter **Alarme** für die eingegangenen DIVERA-Nachrichten, unter **Gesendete Alarme** für die ausgelieferten Pager-Nachrichten. ## Der Outbound-Fluss im Detail Wenn ein Pager eine Status-Rückmeldung sendet: 1. Pager sendet TCP-Frame `24752000751011#80###` (für „KOMME") oder MQTT-Publish auf `p/u/24752000751011/ka` mit `{"type":"80"}`. 2. **iotserver** empfängt die Nachricht, persistiert sie in `tcp_inbound`. 3. Der PostgreSQL-Trigger löst `NOTIFY tcp_inbound_new` aus. 4. Der Dienst **divera-outbound-processor** hat auf diesen Kanal gelauscht. 5. Er prüft: ist das eine Status-Rückmeldung (cmd `02`, `80`, `82`, `84`)? Und ist DIVERA-Outbound für den Mandanten aktiv? Und gibt es einen Auth-Key? 6. Wenn ja: Er sucht in `tcp_outbound` nach dem letzten DIVERA-Alarm (`alarm_id IS NOT NULL`) für diesen Pager. 7. Er sendet einen HTTPS-POST an `https://app.divera247.com/api/setstatus?accesskey=` mit Payload: ```json {"person":"24752000751011","Status":{"key":2,"alarm":true,"alarm_id":32375472}} ``` 8. `key` ist dabei der Status-Code: 1=EMPFANGEN, 2=KOMME, 3=KOMME SPÄTER, 4=KOMME NICHT. 9. Die Antwort von DIVERA wird in `system_logs` mit Category `DIVERA24/7 outbound` protokolliert. ## Test der Integration Nach vollständiger Konfiguration empfehlen wir folgenden Test: 1. Stellen Sie sicher, dass ein Pager online ist (Status grün). 2. Erstellen Sie in DIVERA einen Test-Einsatz mit RIC, der auch in den `divera_rics` des Test-Pagers eingetragen ist. 3. Der Pager sollte innerhalb von 2–5 Sekunden vibrieren. 4. Drücken Sie auf dem Pager „KOMME". 5. In DIVERA sollte der Status „Ich komme" für den Pager-Nutzer erscheinen. 6. Im Broker-GUI unter **Logs** finden Sie alle dazugehörigen Einträge. Funktioniert ein Schritt nicht, nutzen Sie die **Logs**-Seite zur Diagnose. Filtern Sie nach der `alarm_id` des Test-Einsatzes, um nur die relevanten Einträge zu sehen. ## DIVERA-Instance-Mapping Falls Ihr Mandant mehrere DIVERA-Instanzen nutzt (z.B. eine Haupt-DIVERA und eine Test-Instanz), können Sie unterschiedliche `instance`-Namen konfigurieren. Die URL wäre dann: ``` https://pager.dexa.gmbh/webhook/divera/ ``` Das `instance`-Feld wird in `alarm_divera_inbound.instance` gespeichert und hilft beim Unterscheiden der Quellen. ## Fehlerbilder **HTTP 403 „Nicht autorisiert" im DIVERA-Outbound-Log** Der Auth-Key ist falsch, abgelaufen oder hat nicht die erforderlichen API-Rechte in DIVERA. Prüfen Sie: Stimmt der Key in den Mandant-Einstellungen mit dem in DIVERA überein? **Webhook geht rein, aber Pager bekommt nichts** - Ist der Pager online (Dashboard prüfen)? - Hat der Pager die richtige RIC in `divera_rics`? - Sendet DIVERA die richtige RIC im `pager`-Array des Webhooks? **Alarm ist in `alarm_divera_inbound`, aber kein Eintrag in `tcp_outbound`** - Ist der Dienst `alarm-processor` gestartet? `systemctl status alarm-processor` (nur Super-Admin) - Ist DIVERA-Inbound deaktiviert (Toggle in Einstellungen)? Diese und weitere Probleme werden im Kapitel **Betrieb & Troubleshooting** vertieft. # Einstellungen und Benutzerverwaltung # Einstellungen und Benutzerverwaltung Dieses Kapitel bündelt die beiden Mandanten-Bereiche, in denen Sie die Konfiguration Ihrer Instanz verwalten: die **Einstellungen** und die **Benutzerverwaltung**. ## Einstellungen Die Seite **Einstellungen** ist Ihre zentrale Schalt-Anlage. Sie erreichen sie über die Hauptnavigation. ### Alarmdienste verwalten Die wichtigste Kachel. Öffnet ein Modal mit allen DIVERA-bezogenen Einstellungen. Diese wurden bereits im Kapitel „DIVERA24/7-Integration" behandelt. Nochmal die Kurzfassung der Toggles: | Einstellung | Zweck | |-------------|-------| | DIVERA24/7 Auth-Key | API-Schlüssel für Outbound-Calls | | DIVERA24/7 Inbound | Eingehende Webhooks verarbeiten (ja/nein) | | DIVERA24/7 Outbound | Status-Rückmeldungen an DIVERA senden (ja/nein) | | Mandown an DIVERA | Mandown-Ereignisse (cmd 0A) als Einsatz in DIVERA erzeugen | | Notrufe an DIVERA | Notruf-Ereignisse (cmd 08) als Einsatz in DIVERA erzeugen | | Tear-Off Alarme weiterleiten | Tear-Off-Ereignisse (cmd 0B) als Einsatz erzeugen | Änderungen werden sofort aktiv – kein Neustart notwendig. ### Pager automatisch registrieren Ein Toggle in den System-Einstellungen. Wenn aktiviert, dürfen sich **MQTT-Pager ohne Vorregistrierung** einfach verbinden. Der Broker legt dann automatisch einen Pager-Eintrag in der Datenbank an und ordnet ihn Ihrem Mandanten zu. Das Flag greift **nur für MQTT**. TCP-Pager müssen immer vorregistriert sein, weil bei TCP die Mandantenzuordnung nicht zuverlässig abgeleitet werden kann. **Wann aktivieren?** - Während der initialen Einrichtung, wenn Sie viele MQTT-Pager auf einmal ausrollen. - Wenn Ihre MQTT-Pager zuverlässig mit der richtigen Broker-URL konfiguriert sind. **Wann deaktivieren?** - Im Regelbetrieb. Neue Pager sollen dann bewusst über die Pager-Seite angelegt werden, nicht automatisch. - Sicherheitsbedenken: Ein Angreifer mit gültiger Tenant-URL könnte sonst unerwünschte Pager registrieren (zwar harmlos, aber nicht ideal). ### Pager-Inaktivität (Minuten) Schwellwert, ab wann ein Pager als „inaktiv" / „offline" gilt. Default: **30 Minuten**. Wenn Ihr Pager häufiger Keep-Alives sendet (z.B. alle 60 Sekunden), können Sie den Wert reduzieren. Wenn Ihre Pager seltener senden (z.B. nur alle 10 Minuten), erhöhen Sie ihn. Achtung: Das hier eingestellte Intervall gilt für Anzeigen in GUI. Das interne „Versand nur wenn online"-Verhalten nutzt immer feste 15 Minuten. ### E-Mail-Einstellungen (Mailgun) Damit Passwort-Reset-Mails und Einladungs-Mails versendet werden können, müssen Sie einen SMTP-fähigen Service hinterlegen. Der Broker nutzt Mailgun. Einzutragen: - **Mailgun API-Key** – aus Ihrem Mailgun-Account - **Mailgun Domain** – die in Mailgun verifizierte Domain (z.B. `mail.mustermann-fw.de`) - **Absender-Name** – z.B. „Feuerwehr Musterstadt" - **Absender-E-Mail** – z.B. `noreply@mustermann-fw.de` Nach dem Speichern können Sie einen **Test-Mail** versenden, um die Konfiguration zu prüfen. ### System-Status-Einstellungen Unter **System** können Sie Schwellwerte für das Dashboard-Ampel-System anpassen: - Wie viele Stunden ohne Alarm-Empfang sollen rot markiert werden? - Wann soll der „System gesund"-Indikator auf Warnung wechseln? Diese Einstellungen sind meist ohne Anpassung sinnvoll konfiguriert. ## Benutzerverwaltung Die Seite **Benutzerverwaltung** listet alle Benutzer Ihres Mandanten und ermöglicht Anlegen, Bearbeiten und Löschen. ### Benutzerrollen Der Broker kennt für Mandanten-Ebene zwei Rollen: **`admin`** Vollzugriff auf alle Funktionen des Mandanten. Kann weitere Benutzer anlegen, Pager bearbeiten, Einstellungen ändern. **`user`** Lesender Zugriff. Kann Dashboard, Logs, Alarme sehen, aber nichts ändern. Nützlich für Personal, das nur informativ zugreifen soll (z.B. Fahrzeugführer, die über das Dashboard Ihre Alarme einsehen). Eine Rolle `super_admin` **existiert**, ist aber nicht auf Mandanten-Ebene sichtbar. Super-Admins haben keinen Mandanten-Bezug. ### Neuen Benutzer anlegen Klicken Sie auf **Neuen Benutzer anlegen**. Geben Sie an: - E-Mail (muss eindeutig sein) - Initial-Passwort (der Benutzer wird aufgefordert, es beim ersten Login zu ändern) - Rolle (`admin` oder `user`) - Vorname, Nachname (optional) Nach Anlage wird – wenn Mailgun konfiguriert ist – eine Einladungs-Mail versendet. ### Benutzer bearbeiten Klick auf einen Benutzer öffnet die Detail-Ansicht. Änderbar sind: Name, Rolle, aktiv/inaktiv. **Aktiv/Inaktiv** ist nützlich, um einen Benutzer temporär zu sperren, ohne ihn zu löschen – z.B. bei Urlaub. Ein inaktiver Benutzer kann sich nicht einloggen, bleibt aber in der Datenbank und kann alle historischen Aktionen nachvollziehen. ### Passwort zurücksetzen Für jeden Benutzer gibt es einen Button **Passwort zurücksetzen**. Das System sendet dem Benutzer eine Reset-Mail (Mailgun notwendig). Alternativ können Sie ein neues Passwort manuell vergeben. ### Benutzer löschen Löschen entfernt den Benutzer dauerhaft aus der Datenbank. **Historische Einträge** (z.B. „Alarm gesendet von X") bleiben erhalten, zeigen aber keinen klickbaren Benutzer-Link mehr. Eine gängige Alternative: Benutzer auf **inaktiv** setzen statt löschen. Das bewahrt die Audit-Spur. ### Die Super-Admin-Beziehung Manchmal haben Super-Admins Ihnen temporär Zugriff auf Ihre Mandanten-Instanz gegeben, um zu helfen. Der Super-Admin kann sich dafür **als Sie einloggen** – über einen Login-Token, der in seinem Admin-Panel erzeugt wird. Sie sehen solche Einloggungen im Audit-Log. Wenn Sie sich unsicher sind, fragen Sie Ihren Super-Admin. ## Passwort-Richtlinien Die Plattform erzwingt keine harten Passwort-Regeln (Mindestlänge, Sonderzeichen), sondern empfiehlt starke Passwörter. Als Orientierung: - mindestens 12 Zeichen - Mischung aus Groß-/Kleinbuchstaben, Ziffern, Symbolen - keine Wörterbuch-Wörter - keine persönlichen Daten (Namen, Geburtstage) Administratoren sollten zusätzlich einen **2. Faktor** nutzen, sofern der Browser bzw. das Gerät 2FA unterstützt. Die Plattform selbst bietet aktuell kein eingebautes 2FA – das ist für zukünftige Versionen geplant. ## Audit und Nachvollziehbarkeit Alle Änderungen in Einstellungen und Benutzerverwaltung werden in `system_logs` mit der Kategorie `audit` protokolliert. Super-Admins können diese Protokolle im Admin-Panel einsehen. Mandanten-Admins sehen Audit-Einträge in ihrer eigenen **Logs**-Seite unter der Ansicht „System". # Erste Schritte im Mandanten-Admin Dieses Kapitel richtet sich an Sie als Mandanten-Administrator. Sie sehen, wie Sie sich an Ihrem Mandanten anmelden, die GUI navigieren und welche ersten Schritte zur Einrichtung Ihrer Organisation nötig sind. ## Voraussetzungen Bevor Sie beginnen, benötigen Sie: - Eine zugewiesene **Mandantennummer** (5-stellig, z.B. `10001`). Diese erhalten Sie vom Super-Administrator. - Ihre **Login-Daten** (E-Mail-Adresse und Passwort). Diese werden ebenfalls vom Super-Admin bereitgestellt oder Sie erhalten eine E-Mail mit einem Initial-Passwort. - Einen aktuellen Webbrowser (Firefox, Chrome, Edge, Safari – alle in aktuellen Versionen). - Die Kenntnis der Mandanten-URL, z.B. `https://10001.pager.dexa.gmbh`. ## Anmeldung ### URL aufrufen Öffnen Sie in Ihrem Browser die URL Ihres Mandanten: ``` https://10001.pager.dexa.gmbh ``` Ersetzen Sie `10001` durch Ihre tatsächliche Mandantennummer. Alternativ funktioniert auch `https://10001.broker.dexa.gmbh` – beide Subdomains sind äquivalent. ### Login-Formular Sie werden auf das Login-Formular umgeleitet. Tragen Sie Ihre E-Mail-Adresse und Ihr Passwort ein und klicken Sie auf **Anmelden**. Bei der ersten Anmeldung werden Sie nach erfolgreicher Authentifizierung möglicherweise aufgefordert, Ihr Passwort zu ändern. Befolgen Sie diesen Schritt, um ein persönliches Passwort zu setzen, das dem Super-Admin nicht mehr bekannt ist. ### Passwort vergessen Sollten Sie Ihr Passwort vergessen haben, nutzen Sie den Link **Passwort vergessen** auf dem Login-Formular. Sie erhalten eine E-Mail mit einem Link zum Zurücksetzen – vorausgesetzt, in Ihrer Mandanten-Konfiguration ist ein funktionierender E-Mail-Versand (Mailgun) hinterlegt. Falls auch das nicht funktioniert: Ein Super-Administrator kann Ihr Passwort jederzeit über das Admin-Center zurücksetzen. ## Die Hauptnavigation Nach erfolgreichem Login sehen Sie das Dashboard Ihrer Mandanten-GUI. Im oberen Bereich finden Sie die Hauptnavigation mit folgenden Einträgen: | Menüpunkt | Zweck | |-----------|-------| | **Dashboard** | Startseite mit Kennzahlen (aktive Pager, Warteschlange, Systemzustand) und je einer Live-Liste für eingehende und ausgehende Sendungen | | **Pager** | Verwaltung aller Pager Ihres Mandanten | | **Alarme** | Liste aller eingegangenen DIVERA-Alarme mit Details | | **Gesendete Alarme** | Liste aller vom Broker an Pager versendeten Nachrichten | | **Alarm senden** | Manuelles Senden eines Test-Alarms an einen Pager | | **Logs** | Rohprotokoll aller Pager-Kommunikation | | **Einstellungen** | Konfiguration des Mandanten (DIVERA-Auth-Key, Auto-Register etc.) | | **Benutzerverwaltung** | Weitere Admins und Benutzer Ihrer Organisation anlegen | Zusätzlich erreichbar über Karten auf dem Dashboard: - **System-Health** (`/system-health`) – Detailseite mit Diensten, Ressourcen und Alarmeingang - **Worker-Pipeline** (`/jobs`) – Mandanten-Variante der Admin-Worker-Pipeline (siehe Abschnitt unten) Am rechten Rand befinden sich Abmelde-Option und Zugriff auf Ihr eigenes Benutzerkonto (Passwort ändern). ## Das Dashboard verstehen Das Dashboard zeigt auf einen Blick den Gesamtzustand Ihres Mandanten. Es ist absichtlich schlank gehalten – Detail-Inhalte erreichen Sie per Klick auf die jeweilige Karte. ### Stats-Bereich (drei Karten) **Aktive Pager** Anzahl der Pager, die in den letzten 20 Minuten (konfigurierbar pro Mandant in den Einstellungen) eine Verbindung zum Broker hatten. Diese Zahl ist nicht identisch mit der Gesamtzahl konfigurierter Pager – ein offline-Pager zählt hier nicht mit. Klick öffnet `/pagers`. **Warteschlange** Anzahl der ausstehenden Sendungen in `tcp_outbound` mit Status `queued`. Klick öffnet `/jobs` (siehe „Worker-Pipeline" weiter unten). **System-Health** Status-Label **OK / INFO / WARNUNG / KRITISCH** mit kurzer Begründung. Klick öffnet die Detailseite `/system-health`. | Backend-Status | Label | Farbe | |---|---|---| | operational | OK | grün | | degraded | INFO | gelb | | warning | WARNUNG | orange | | critical | KRITISCH | rot | ### Aktive-Pager-Liste Liste der Pager mit aktueller Verbindung. Pro Pager: Seriennummer, IP:Port, **Letzte EINGEHEND** (jüngste TCP- oder MQTT-Nachricht des Pagers) und **Letzte AUSGEHEND** (jüngste vom Broker an den Pager gesendete Nachricht aus `tcp_outbound`). ### Letzte EINGEHEND / Letzte AUSGEHEND Zwei nebeneinanderliegende Listen: - **Letzte EINGEHEND** – jüngste 10 DIVERA-Webhooks, Pager-seitige Notruf-Tasten-Alarme (MANDOWN, NOTRUF, TEAROFF) und Status-Rückmeldungen. - **Letzte AUSGEHEND** – jüngste 10 vom Broker abgesetzte Sendungen (TCP/MQTT), inkl. Status-Indikator (grün=erfolgreich, rot=fehlgeschlagen, gelb=offen) und Payload-Vorschau. ## Worker-Pipeline (`/jobs`) Über die Karte „Warteschlange" auf dem Dashboard erreichen Sie eine eigene Seite, die die drei Stufen der Sendungs-Verarbeitung visualisiert. Sie spiegelt die Admin-Variante (`/admin/jobs`), zeigt aber ausschließlich Daten Ihres Mandanten. | Stufe | Schritt | Tabelle | |---|---|---| | 1. Eingang | DIVERA-Webhook → `alarm-processor` → `tcp_outbound` | `alarm_divera_inbound` | | 2. Versand an Pager | `tcp_outbound` → `iotserver` (TCP / MQTT) → Pager | `tcp_outbound` | | 3. Quittung an DIVERA | Pager-Antwort → `divera-outbound-processor` → DIVERA-API | `tcp_inbound` | Pro Stufe sehen Sie ein Mini-Schaubild mit dem aktuellen Worker-Status (läuft/gestoppt + Uptime), eine kurze Erklärung der Retry-Policy und vier Reiter: - 🔵 **Aktiv** – Jobs in Bearbeitung. Stuck-Indikator (`⚠`) markiert Jobs, die länger als 5 Minuten warten. Aktion: **Abbrechen** stoppt den Worker für diesen Eintrag. - 🟢 **Erfolgreich** – Jobs, die innerhalb der letzten 24 Stunden erfolgreich abgeschlossen wurden. - 🔴 **Fehler** – Jobs mit dauerhaftem Fehler (z.B. nach max. Retries). - ⚪ **Ausgeblendet** – Jobs, die ein Mandanten-User per **Ausblenden**-Button aus der Liste entfernt hat. Reiter erlaubt **Einblenden** zur Wiederherstellung. Die Spalte **Nächster Versuch** zeigt den nächsten Retry-Zeitpunkt – entweder explizit (`in 30s`, `in 5 min`, `jetzt fällig`) oder Status-abgeleitet (`sofort (NOTIFY)` für `queued`-Jobs, `spätestens 60 s (Sweep)` für die Sweep-Stufen). ## Erste Einrichtungs-Schritte Nach Ihrem ersten Login empfehlen wir die folgenden Schritte in dieser Reihenfolge. ### Weitere Admins anlegen Legen Sie mindestens einen zweiten Admin-Benutzer an, damit Sie sich nicht versehentlich selbst aussperren. Gehen Sie zu **Benutzerverwaltung → Neuen Benutzer anlegen**, geben Sie E-Mail und ein Initial-Passwort an. Das System sendet eine Einladungs-Mail – sofern Mailgun konfiguriert ist. ### DIVERA-Auth-Key hinterlegen Damit der Broker Status-Rückmeldungen zurück an DIVERA senden kann, benötigt er Ihren **DIVERA24/7 Access-Key**. Diesen finden Sie in Ihrem DIVERA-Account unter dem Menüpunkt für API-Keys. In der Broker-GUI: **Einstellungen → Alarmdienste verwalten → DIVERA24/7 Auth-Key**. Tragen Sie den Key ein und speichern Sie. Der Schlüssel ist damit verschlüsselt in der Datenbank hinterlegt und wird bei jeder DIVERA-Rückmeldung verwendet. ### DIVERA-Webhook-URL in DIVERA eintragen Damit DIVERA Einsatzaufträge an Ihren Broker sendet, müssen Sie dort einen Webhook konfigurieren. Die URL lautet entweder: ``` https://10001.pager.dexa.gmbh/webhook/divera/ ``` oder alternativ (in DIVERA einfacher einzutragen, weil keine Subdomain nötig): ``` https://pager.dexa.gmbh/webhook/divera/10001 ``` Ersetzen Sie `10001` durch Ihre Mandantennummer. In DIVERA: **Einstellungen → Alarm-Schnittstellen → Neuer Webhook**, HTTP-Methode POST, Content-Type `application/json`. ### Pager registrieren Legen Sie Ihre Pager im System an. **Pager → Pager registrieren**. Benötigt wird: - Seriennummer (14-stellig, auf dem Pager) - Bezeichnung (frei wählbar, z.B. "Pager Wehrführer") - Eigentümer (optional, z.B. "Max Mustermann") - Organisation (optional) Nach Registrierung erscheint der Pager in der Liste – zunächst als **offline**. Sobald der Pager eine Verbindung aufbaut, wechselt der Status. ### RIC-Zuordnung Öffnen Sie jeden registrierten Pager und tragen Sie die **Divera RICs** ein – die RICs, für die dieser Pager alarmiert werden soll. Mehrere RICs werden mit Komma getrennt. Beispiel: Pager Wehrführer bekommt RICs `1379996B,1369114A` – er wird damit bei allen DIVERA-Alarmen alarmiert, die diese RICs enthalten. ### Test-Alarm senden Gehen Sie zu **Alarm senden** und senden Sie einen Test an einen Ihrer Pager. Der Pager sollte innerhalb weniger Sekunden vibrieren und den Text anzeigen. Ist das der Fall: Die Kette funktioniert. Verfolgen können Sie den gesamten Weg in `/jobs` (Stufe 1 → 2 → 3). Falls nicht, hilft der nächste Abschnitt dieses Handbuchs – die Detail-Kapitel zu Pager-Verwaltung, DIVERA-Integration und Alarmierung. ## Abmeldung und Sicherheit Nach Arbeitsende melden Sie sich über das Menü rechts oben **Abmelden**. Damit wird Ihre Sitzung serverseitig entwertet – ein erneutes Login ist notwendig. Dies ist besonders wichtig an geteilten Arbeitsplätzen. Die Sitzungsdauer ist standardmäßig auf **24 Stunden** begrenzt. Danach werden Sie automatisch ausgeloggt. ## Unterstützung Sollten Sie Probleme haben, wenden Sie sich an Ihren Super-Administrator. Dieser hat mandantenübergreifenden Zugriff und kann Ihre Konfiguration, Logs und ggf. direkt eingreifen. Für technische Fragen zur Plattform selbst kontaktieren Sie den Hersteller (Dexa Systems GmbH) über die Ihnen bekannten Support-Kanäle. # Pager-Verwaltung Die Pager-Verwaltung ist das Kernstück Ihres Mandanten. Hier legen Sie neue Pager an, bearbeiten bestehende, weisen ihnen RIC-Codes zu und behalten den Überblick über den Online-Status Ihrer Flotte. ## Die Pager-Seite öffnen Nach dem Login klicken Sie in der Hauptnavigation auf **Pager**. Sie sehen eine Tabelle mit allen in Ihrem Mandanten registrierten Pagern. Die Tabelle zeigt pro Pager: - **Seriennummer** (14 Ziffern, eindeutig weltweit) - **Bezeichnung** (frei wählbarer Name) - **Verbindungstyp** (TCP oder MQTT) - **Zuletzt gesehen** (Zeitpunkt der letzten empfangenen Nachricht) - **Status** (Online-Indikator grün/grau) - **Batterie** und **Signalstärke** (soweit übertragen) - **GPS-Position** (soweit vorhanden, mit Link zur Karte) Oben rechts befinden sich zwei Aktions-Buttons: - **Pager registrieren** – öffnet den Dialog zum Anlegen eines neuen Pagers - **Aktualisieren** – lädt die Tabelle neu ## Einen neuen Pager registrieren Klicken Sie auf **Pager registrieren**. Ein Modal-Dialog öffnet sich mit folgenden Eingabefeldern: **Seriennummer (14 Ziffern) – Pflicht** Die 14-stellige eindeutige ID des Pagers. Sie finden diese auf einem Aufkleber auf dem Gerät, im Menü des Pagers (unter „Geräteinfo" oder „Seriennummer") oder auf dem Verpackungskarton. Die Eingabe muss exakt 14 Ziffern enthalten, keine Leerzeichen, Bindestriche oder Buchstaben. **Bezeichnung** Ein frei gewählter Name, unter dem dieser Pager in der GUI erscheint. Typische Bezeichnungen: „Pager Wehrführer", „Pager Gruppe 1 Angriff", „Pager Maschinist Mustermann". Machen Sie die Bezeichnung so, dass Sie den Pager leicht wiederfinden. **Eigentümer** Optional: Der Name der Person, die den Pager trägt. **Organisation** Optional: Übergeordnete Organisation, z.B. „FF Musterstadt". **Typ** Aktuell nur **Oelmann LX7** verfügbar. Weitere Typen werden in zukünftigen Versionen ergänzt. Nach dem Klick auf **Registrieren** wird der Pager in der Datenbank angelegt. Seine `tenant_id` wird automatisch auf Ihren Mandanten gesetzt. Der Pager erscheint sofort in der Tabelle – zunächst als **offline**, weil er noch keine Verbindung aufgebaut hat. ### Wichtig: TCP vs. MQTT Bei der Registrierung legen Sie **nicht** fest, ob der Pager später per TCP oder MQTT kommunizieren wird. Der Typ ergibt sich automatisch aus der Art, wie sich der Pager zum ersten Mal verbindet: - Verbindet sich der Pager per TCP zu Port 60123 → `connection_type` wird auf `'tcp'` gesetzt. - Verbindet sich der Pager per MQTT zu Mosquitto → `connection_type` wird auf `'mqtt'` gesetzt. Ein Pager, der vorregistriert wurde und sich nie verbindet, bleibt ohne Verbindungstyp und erscheint als offline. ## Einen Pager bearbeiten Klicken Sie in der Tabelle auf einen Pager, öffnet sich die Detail-Ansicht. Dort können Sie folgende Felder ändern: | Feld | Beschreibung | |------|--------------| | Bezeichnung | Anzeigename | | Eigentümer | Name der tragenden Person | | Organisation | Oberorganisation | | Typ | Geräte-Typ | | RICs | Pager-Hardware-RICs (kommagetrennt) | | Divera RICs | Routing-RICs für DIVERA-Alarme (kommagetrennt) | **Nicht änderbar** sind Seriennummer (Primärschlüssel) und Verbindungstyp (wird automatisch gesetzt). ## RICs und Divera RICs verstehen Die beiden RIC-Listen haben unterschiedliche Bedeutungen, die wir hier noch einmal explizit trennen. ### RICs (Hardware-RICs) Das sind die RIC-Adressen, die der Pager **physisch empfangen** kann. Diese Konfiguration stammt aus dem Pager selbst (z.B. beim Programmieren der Geräte-Firmware) und wird in der Broker-Datenbank gespiegelt, damit die Plattform weiß, was der Pager kann. Bei MQTT-Pagern wird dieses Feld teilweise automatisch gefüllt, wenn der Pager sich für RIC-Topics subscribiert (`p/u//r/`). Bei TCP-Pagern müssen Sie die RICs manuell eintragen. Beispiel: `1366481A,1366473B,1369114A` ### Divera RICs (Routing-RICs) Das sind die RIC-Adressen, für die dieser Pager **alarmiert werden soll**. Das ist ein reines Software-Konstrukt des Brokers. Wenn DIVERA einen Alarm für RIC `1379996B` meldet, prüft der Broker **alle** Pager des Mandanten und findet die, die `1379996B` in ihrer `divera_rics`-Liste haben. Diese bekommen den Alarm. Beispiel: Pager des Wehrführers hat `divera_rics = "1379996B,1379996C"`. Er wird alarmiert, wenn DIVERA einen Alarm für eine dieser beiden RICs sendet. ### Warum trennt der Broker die beiden? Aus Sicherheit und Flexibilität: Ein Pager kann theoretisch auf RIC X hören, aber Sie möchten ihn über die Plattform nicht bei RIC X alarmieren (z.B. weil ein anderer Pager diese Aufgabe übernimmt). Umgekehrt kann ein Pager per Plattform auf RIC X alarmiert werden, auch wenn seine Hardware RIC X nicht kennt – der Broker sendet dann einen „Nur-Text"-Alarm ohne RIC-Filter an den Pager, der dann auf jeden Fall auslöst. ## Online-Status Der Online-Status eines Pagers wird aus einem einzigen Kriterium abgeleitet: > Hat dieser Pager in den letzten **15 Minuten** eine Nachricht an den Broker geschickt? (TCP-Frame oder MQTT-Publish) Wenn ja → online. Wenn nein → offline. Die 15-Minuten-Schwelle ist hart kodiert und passt zu den typischen Keep-Alive-Intervallen der Oelmann-Pager (alle 60 Sekunden). Ein Pager, der länger als 15 Minuten nichts von sich gehört hat, wird behandelt als hätte er keinen Funkkontakt – was bei Pager-Einsätzen die richtige Annahme ist. **Wichtig:** Der Broker verweigert den Versand von MQTT-Alarmen an offline-Pager und setzt den Alarm stattdessen auf Retry. Das vermeidet, dass sich Alarme als „erfolgreich gesendet" melden, obwohl der Pager gar nicht online war. Bei TCP ist die Erkennung direkter, weil die Verbindung einfach abreißt. ## Pager löschen Klicken Sie in der Pager-Liste auf das **Löschen**-Icon neben einem Eintrag. Das System fordert eine Bestätigung. Beim Löschen: - Der Pager-Datensatz wird aus der `pager`-Tabelle entfernt. - **Historische Daten** (alte `tcp_inbound`- und `tcp_outbound`-Einträge) bleiben erhalten. Sie referenzieren den Pager jetzt nur noch über die Seriennummer. - Eventuell vorhandene offene Alarme in der Queue (`tcp_outbound` mit Status `queued` oder `retry_pending`) werden **nicht** gelöscht. Sie bleiben in der Queue, können aber nicht mehr zugestellt werden – bis der Pager neu angelegt wird oder `max_retries` erreicht ist. Wenn sich derselbe Pager danach wieder mit dem Broker verbinden möchte: Bei TCP wird die Verbindung abgelehnt (Pager unbekannt). Bei MQTT hängt es davon ab, ob Auto-Register im Mandanten aktiv ist. ## Batterie und Signalstärke Pager senden in ihren Keep-Alive-Nachrichten regelmäßig Batterie- und Signalstärke-Werte. Die GUI visualisiert diese: - **Batterie** in Prozent oder Volt (je nach Pager-Firmware). Unter 20% wird der Wert rot markiert. - **Signalstärke** in dBm. Werte um -80 dBm sind gut, unter -100 dBm schwach, unter -110 dBm kritisch. Klicken Sie auf den Wert, um eine Historien-Grafik der letzten 24 Stunden zu sehen. ## GPS-Position MQTT-Pager können GPS-Koordinaten senden. Ist eine GPS-Position vorhanden, erscheint in der Tabelle ein Karten-Symbol neben dem Pager. Klick darauf öffnet eine externe Karte (Google Maps oder OpenStreetMap, je nach Konfiguration) mit der zuletzt bekannten Position. GPS-Daten werden **nicht dauerhaft gespeichert** – nur der zuletzt bekannte Wert. Das hat datenschutzrechtliche Gründe und ist bewusst so gewählt. Wenn Sie Bewegungsprofile benötigen, aktivieren Sie GPS-Tracking explizit pro Pager (in den Detail-Einstellungen). ## Typische Fehler **Pager kommt nicht online** - Ist der Pager eingeschaltet und hat Netz (LTE / WLAN)? - Stimmt die Seriennummer exakt (14 Ziffern)? - Ist der Pager auf die richtige Broker-URL konfiguriert (`.pager.dexa.gmbh` oder `.broker.dexa.gmbh`)? **TCP-Pager wird abgelehnt** Schauen Sie im Log-Tab nach Einträgen wie „rejecting unknown TCP pager" – das bedeutet, der Pager ist nicht in der Datenbank. Legen Sie ihn über **Pager registrieren** an. **MQTT-Pager kommt online, aber keine Alarme** Prüfen Sie die **Divera RICs** des Pagers. Sind die RICs leer? Dann bekommt der Pager keine DIVERA-Alarme. **Alarm wird als „gesendet" markiert, aber Pager vibriert nicht** Der Pager war zum Sendezeitpunkt möglicherweise offline. Der Broker prüft das mittlerweile und setzt solche Alarme auf Retry, aber nur bei MQTT. Bei TCP erkennt man es erst am Verbindungs-Log. ## Bulk-Operationen Aktuell unterstützt die GUI keine Bulk-Operationen (z.B. mehrere Pager auf einmal bearbeiten). Für umfangreiche Änderungen wenden Sie sich an den Super-Admin, der direkt über die Datenbank oder die Admin-API arbeiten kann.