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:

Filter

Oben finden Sie Filter nach:

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

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:

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:

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

Gemeinsame Detail-Ansicht

In allen drei Ansichten können Sie einen Eintrag anklicken, um die Detail-Ansicht zu öffnen. Dort sehen Sie:

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:

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:

{
  "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 <STX>24752000751011#80###<ETX> (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=<KEY> mit Payload: 
    {"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/<instance-name>

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

Alarm ist in alarm_divera_inbound, aber kein Eintrag in tcp_outbound

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?

Wann deaktivieren?

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Oben rechts befinden sich zwei Aktions-Buttons:

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:

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/<UID>/r/<RIC>). 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:

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:

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

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.