This page will list the product’s features in a structured matrix.
Replace the feature entries above with your actual product features and statuses.
Feature
iOS
Android
Android 5G Custom
Wenn die Zustellung über MQTT bzw. Push scheitert oder die App nicht zuverlässig signalisieren kann, startet der Alarmserver einen ausgehenden Anruf auf das Zielgerät. Dadurch wird die Signalisierung mit dem auf dem Gerät eingestellten Klingelton sichergestellt – selbst bei gesperrtem Bildschirm oder eingeschränkten Benachrichtigungen.
Auslöser:
fehlende oder verzögerte Bestätigung der Push/MQTT-Zustellung (konfigurierbarer Timeout)
Edge Cases und Hinweise:
Rufnummern: ausgehende Nummer muss bekannt und freigeschaltet sein (Whitelist, PBX/Carrier‑Policies)
Compliance: Anrufprotokolle und Bestätigungen werden auditierbar gespeichert; Datenschutz und Einwilligungen beachten
Damit bleibt die Alarmierung auch dann wirksam, wenn Push‑Benachrichtigungen nicht zugestellt werden oder vom System unterdrückt sind.
Wenn die Zustellung über MQTT bzw. Push scheitert oder die App nicht zuverlässig signalisieren kann, startet der Alarmserver eine ausgehenden SMS auf das Zielgerät. Dadurch wird die Signalisierung mit dem auf dem Gerät eingestellten Klingelton sichergestellt – selbst bei gesperrtem Bildschirm oder eingeschränkten Benachrichtigungen.
Auslöser:
fehlende oder verzögerte Bestätigung der Push/MQTT-Zustellung (konfigurierbarer Timeout)
Damit bleibt die Alarmierung auch dann wirksam, wenn Push‑Benachrichtigungen nicht zugestellt werden oder vom System unterdrückt sind.
Zweck
Zuverlässige Alarmzustellung ohne externe Push-Dienste – besonders in abgeschotteten Netzen oder bei eingeschränkter Internetverbindung.
Funktionsweise
Alarme werden im lokalen Netzwerk über MQTT verteilt. Die App abonniert definierte Topics (z. B. alarms/<gruppe>/<prioritaet>) und löst sofort eine lokale Benachrichtigung aus.
Keine Abhängigkeit von externen Push-Gateways; Latenz ist typischerweise sehr gering.
Fallback‑Pfad: Auslösen bei ausbleibender Bestätigung innerhalb definierter Zeit
Zweck
Sprachlich aufbereitete Alarmmeldungen (Ansagen) sowie Alarmtöne werden zuverlässig über den System‑Mediaplayer wiedergegeben – klar hörbar, wiederholbar und mit Priorisierung.
Funktionsweise
Die App nutzt den System‑Mediaplayer, um Audioinhalte (Alarmton, Sprachansage, Hinweis) auf dem passenden Audiokanal abzuspielen.
„Audio Ducking“ reduziert andere Medienlautstärken vorübergehend, damit die Alarmmeldung verständlich bleibt.
Wiedergabe kann konfiguriert wiederholt werden, bis eine Bestätigung erfolgt oder ein Richtlinien‑Timeout erreicht ist.
Konfiguration
Audioquelle: TTS‑Ansage oder vorproduziertes Audio (z. B. MP3/WAV)
Priorität: Hohe Priorität erzwingt Vollbild‑Anzeige (wo erlaubt) und bevorzugte Audiopfade
Rückmeldung
Bestätigung erfolgt per Button in der App (nicht per DTMF). Die Bestätigung stoppt die Wiedergabe und aktualisiert den Alarmstatus.
Sicherheit & Datenschutz
Minimierung personenbezogener Inhalte in Audioansagen; klare Trennung von Meta‑ und Kontaktdaten
Protokollierung von Wiedergabestart/Stop und Bestätigungen (Audit)
Wiederholung/Timeout: Wiederholungslogik stoppt bei Bestätigung zuverlässig
Kompatibilität: Wiedergabe mit verschiedenen Ausgabegeräten (Lautsprecher, BT) prüfen
Zweck
Für jede Art der Auslösung (Quelle, Schweregrad, Gruppe) können spezifische Alarmtöne, Lautstärken und Farbschemata hinterlegt werden. So erkennen Nutzer:innen bereits am Klang/Farbe die Bedeutung und Dringlichkeit.
Zuordnungslogik
Quellenbasiert: z. B. „Sensor A“ → tiefer Ton, Blau; „Push-Kanal Leitstelle“ → hoher Ton, Rot
Schweregrad: „kritisch“ → lauter, penetranter Ton und Vollbild (wo erlaubt); „Warnung“ → moderat
Gruppen/Empfänger: Team‑spezifische Profile (z. B. Technik vs. Medizin) mit unterschiedlichen Mustern
Konfiguration
Profile: Ton (Vorgabe), Lautstärke, Wiederholung, Vibration(y/n), Farbschema
Regeln: Mapping pro Quelle/Schweregrad/Gruppe; Zeitabhängige Profile (Time‑of‑Day)
Priorität: Hohe Prioritäten können Vollbild‑Anzeige und bevorzugte Audiopfade erzwingen (OS‑konform)
Verhalten
Vordergrund: Sofortige Anzeige mit passendem Farbthema und Ton; Aktionen sichtbar (Bestätigen/Rückruf)
Hintergrund: Lokale Benachrichtigung mit konfiguriertem Ton/Vibration/Farbe; bei hoher Priorität Vollbild (wo zulässig)
Wiederholung: Konfigurierbare Intervalle bis zur Bestätigung oder bis ein Richtlinien‑Timeout erreicht ist
Edge Cases
„Nicht stören“/Stummmodus: OS‑Grenzen beachten; Profile erhöhen die Wahrnehmbarkeit im erlaubten Rahmen
Konflikte: Mehrere gleichzeitige Alarme → Prioritätsauflösung; nur höchstrangiges Profil spielt Ton/Farbe
Geräteausgabe: Kopfhörer/Bluetooth aktiv → Hinweis im UI; Anpassung der Lautstärke gemäß Ausgabegerät
Sicherheit & Datenschutz
Minimierung personenbezogener Inhalte in Ton/Zuordnung; klare Trennung von Meta‑ und Kontaktdaten
Auditierbare Protokollierung von Profilzuordnung, Tonwiedergabe und Bestätigungen
Tests & Qualität
Mapping‑Test: Jede Quelle/Schwere wird korrekt dem Profil zugeordnet
Konflikt‑Handling: Gleichzeitige Alarme lösen korrekt auf; keine Doppelton‑Wiedergabe
Zeitprofile: Regeln greifen abhängig von Tageszeit wie erwartet
Zweck
Klare Zuordnung von Rufnummern zu Kontaktnamen im Alarm‑ und Kommunikationsfluss; reduziert Fehlkommunikation und beschleunigt Entscheidungen.
Funktionsweise
Die App greift (mit Einwilligung/Berechtigung) lesend auf das lokale Adressbuch zu und bildet eine schnelle Lookup‑Tabelle (Nummer → Kontaktname/Firma).
Bei eingehenden oder ausgehenden Ereignissen (Alarm, Anruf, Rückruf) wird die Nummer lokal aufgelöst und im UI angezeigt.
Kein Upload personenbezogener Kontaktdaten; die Verarbeitung bleibt vollständig auf dem Gerät.
Konfiguration
Berechtigungen: Zugriff auf Kontakte aktivieren (iOS/Android OS‑Dialoge)
Matching‑Regeln: Normalisierung von Nummern (Ländervorwahl, Leerzeichen, Sonderzeichen)
Performance: Lookup und UI‑Anzeige ohne spürbare Verzögerung
Berechtigungen: Verhalten bei verweigertem Zugriff (sauberer Fallback)
Zweck
Kritische Alarm‑ und Telemetriedaten bleiben verfügbar, auch wenn vorübergehend keine Netzwerkverbindung besteht. Die App arbeitet weiter und synchronisiert zuverlässig nach Wiederherstellung der Verbindung.
Funktionsweise
Alarm- und Telemetriedaten werden per HTTPS vom Alarmserver abgerufen und lokal in einem sicheren Store zwischengespeichert (verschlüsselt, integritätsgesichert).
Bei fehlender Konnektivität nutzt die App den lokalen Cache für Anzeige, Bestätigung und Protokollierung. Änderungen werden als ausstehende „Sync‑Events“ gesammelt.
Sobald die Verbindung zurückkehrt, werden ausstehende Events und Caches differenziell synchronisiert (Konfliktauflösung gemäß Richtlinie).
Konfiguration
Cache‑Größe & Retention: maximale Einträge/Größe und Aufbewahrungsdauer
Verschlüsselung: Aktivierung und Schlüsselverwaltung (z. B. OS‑Keychain)
Sync‑Politik: Intervalle, Backoff bei Fehlern, Priorisierung kritischer Ereignisse
Verhalten
Vordergrund: UI zeigt Daten aus Cache und kennzeichnet Offline‑Status deutlich; Bestätigungen werden lokal protokolliert
Hintergrund: Periodischer Sync versucht ausstehende Events zu senden; energiesparend mit Backoff
Reconnect: Beim Netzwechsel/Flugmodus‑Ende startet ein sofortiger Sync mit Konfliktprüfung
Edge Cases
Teilweise Daten: Unvollständige Datensätze werden markiert und bei nächster Gelegenheit vervollständigt
Versionskonflikte: Serverseitige Änderungen vs. lokale Bestätigung → Richtlinienbasierte Auflösung und Audit
Transport: ausschließlich HTTPS; keine sensiblen Daten über unsichere Kanäle
Ruhe: Verschlüsselung ruhender Daten im lokalen Store; Zugriff nur mit App‑Berechtigungen
Protokollierung: Audit‑fähige Logs für Cache‑Zugriffe, Bestätigungen und Sync‑Ergebnisse
Tests & Qualität
Offline‑Simulation: WLAN aus/Flugmodus → Anzeige/Bestätigung aus Cache funktioniert
Sync‑Robustheit: Wiederverbindung mit Last/Fehlern → Backoff, Wiederholungslogik, Konfliktauflösung
Performance: Cache‑Zugriffe und UI‑Antwortzeiten ohne spürbare Verzögerung
Datensicherheit: Verschlüsselung aktiv, Schlüsselzugriff und Rechte korrekt
Zweck
Aus der Alarmansicht heraus kann direkt ein Telefongespräch gestartet werden, um schnell mit der zuständigen Stelle zu sprechen. Der bestehende telefonbasierte Workflow bleibt nutzbar und wird um App‑Komfortfunktionen ergänzt.
Funktionsweise
Die App bietet einen „Rückruf“‑Button. Ein Tap öffnet die native Call‑UI, inklusive Übergabe der Zielnummer und optionaler Fallnummer/Referenz.
Optional kann eine Bestätigung per DTMF im Gespräch genutzt werden (z. B. „Taste 1 für bestätigt“), sofern die Telephony‑Integration dies vorsieht.
Konfiguration
Zielnummern: pro Alarmtyp/Gruppe konfigurierbar (Zentrale, Leitstelle, Einsatzleitung)
Berechtigungen: App‑Zugriff auf Telefonie‑Funktionen (OS‑Policies beachten)
Ablauf
Alarm trifft ein (Push/MQTT) und öffnet die Alarmansicht.
Nutzer:in tippt auf „Rückruf“ → Call‑UI öffnet sich mit der hinterlegten Nummer.
Optional: DTMF‑Bestätigung im Gespräch (bei entsprechender Infrastruktur).
Edge Cases
Kein Netz / Flugmodus: Rückruf nicht möglich → UI zeigt Hinweis und bietet erneuten Versuch an
Dual‑SIM / VoIP vs. GSM: Ausgehender Anruf folgt der Standardleitung; Nutzer:innen können Leitung wählen
Besetzt / Nicht erreichbar: UI bietet alternative Nummern oder erneuten Versuch; Protokollierung der Versuche
Sicherheit & Datenschutz
Telefonnummern werden gemäß Datenschutzrichtlinien verarbeitet; Einwilligung/Transparenz beachten
DTMF‑Bestätigungen werden als Ereignisse protokolliert, ohne Inhalte offenzulegen
Tests & Qualität
DTMF‑Pfad: Bestätigung im Gespräch (falls aktiviert) wird zuverlässig erkannt und protokolliert
Edge‑Handling: Kein Netz/Besetzt/Nicht erreichbar → verständliche Hinweise und korrekte Protokollierung
Zweck
Bei hochpriorisierten Alarmen soll unmittelbares Handeln möglich sein. Die App kann ein aktives Telefongespräch beenden oder die Nutzer:innen zum sofortigen Abbruch auffordern, damit die Alarmmaßnahmen nicht verzögert werden.
Funktionsweise
Bei einem eingehenden Alarm wird geprüft, ob ein aktiver Anruf läuft.
Automatisches Beenden des Gesprächs
Nach dem Abbruch öffnet sich die Alarmansicht mit Handlungsoptionen (Bestätigen, Rückruf, Details).
Hinweis: App‑seitiges hartes Beenden ist ausschließlich in der speziellen android5g‑Umgebung verfügbar; auf Standard‑Android/iOS sind OS‑Policies zu respektieren.
Konfiguration
Richtlinien: Wann beendet/pausiert werden darf (Alarm‑Priorität, Rollen/Gruppen, Ausnahmen)
Verhalten
Vordergrund: Vollbild‑Overlay unterbricht das Gespräch oder fordert zum Abbruch auf; nach Abbruch sofortige Alarm‑Interaktion
Hintergrund/Sperrbildschirm: Alarmanzeige und ggf. System‑Signal für Unterbrechung; Rücksprung in App nach Abbruch
Logging: Ereignisse (Erkennung aktiver Anruf, Abbruch/Entscheidung, Zeitpunkte) werden auditierbar protokolliert
Sicherheit & Datenschutz
Compliance: Richtlinien sind dokumentiert; Audit‑Logs unterstützen Nachvollziehbarkeit
Tests & Qualität
Policy‑Tests: Auslösung bei verschiedenen Prioritäten/Rollen
OS‑Grenzen: Verhalten auf Standard‑Android/iOS (nur Hinweis/Overlay) vs. android5g (erzwungener Abbruch) prüfen
UX‑Flows: Countdown, Bestätigung, Rücksprung in Alarm‑Ansicht
Zweck
Kritische Alarme werden sicher wahrgenommen, indem die App die Systemlautstärke innerhalb der zulässigen OS‑Grenzen temporär anhebt und anschließend wieder zurücknimmt.
Funktionsweise
Beim Eintreffen eines hochpriorisierten Alarms setzt die App ein definiertes Lautstärke‑Profil auf dem passenden Audiokanal (z. B. Medien‑, Klingelton‑ oder Alarmkanal).
Die Anhebung gilt nur für die Alarmdauer. Nach Bestätigung oder Timeout wird die ursprüngliche Lautstärke automatisch wiederhergestellt.
In Kombination mit dem Media‑Player kann „Audio Ducking“ andere Audioquellen kurzzeitig absenken, damit der Alarm klar hörbar bleibt.
Konfiguration
Profile: Ziel‑Lautstärke pro Kanal, Schrittweite, maximale Dauer
Priorität: Nur ab einer definierten Alarmpriorität aktiv (z. B. „kritisch“)
Rücknahme: Regeln zur automatischen Rücknahme nach Bestätigung/Timeout
Verhalten
Vordergrund: Sofortige Lautstärkeanhebung mit sichtbarer Alarmansicht (Vollbild, wo erlaubt) und klaren Handlungsoptionen
Hintergrund/Sperrbildschirm: Lautstärkeanpassung gemäß OS‑Policies; bei hoher Priorität kann zusätzlich eine Vollbild‑Alarmansicht geöffnet werden (wo zulässig)
Wiederholungen: Erneute Anhebung bei wiederholten Alarmen, jedoch mit Schutz gegen Übersteuerung jenseits der Profilgrenzen
Edge Cases
„Nicht stören“/Stummmodus: OS‑Policies haben Vorrang; die App respektiert DND‑Regeln. Wo zulässig, werden erlaubte Kanäle genutzt, um die Wahrnehmbarkeit zu erhöhen.
Ausgabegeräte: Kopfhörer/Bluetooth aktiv → Lautstärkeanhebung folgt dem aktiven Ausgabepfad; UI weist auf mögliche Lautstärkepeaks hin
Parallel‑Audio: Ducking verhindert starke Überlagerungen; Konfliktlogik ist konfigurierbar
Sicherheit & Datenschutz
Keine personenbezogenen Daten betroffen; es werden nur System‑Audioeinstellungen temporär angepasst
Transparenz: UI zeigt Anhebung und Rücknahme klar an; Richtlinien einsehbar
Audit: Protokollierung der Anhebung/Rücknahme mit Zeitpunkten und Kanälen
Tests & Qualität
Kanal‑Test: Richtiger Audiokanal wird angepasst (Medien vs. Klingelton)
DND‑Verhalten: App respektiert „Nicht stören“/Stummmodus wie vorgesehen
Rücknahme: Lautstärke kehrt nach Bestätigung/Timeout verlässlich zum Ausgangswert zurück
Ausgabegeräte: Verhalten mit Lautsprecher, Kopfhörer, Bluetooth prüfen
Zweck
Kritische Alarme sollen sofort ins Auge fallen. Ein Vollbild‑Overlay stellt die Alarminformationen und Handlungsoptionen fokussiert dar und minimiert Ablenkungen.
Konfiguration
Ob Emergency Alarm oder nicht
Verhalten
Vordergrund: Sofortige Überblendung der aktuellen Ansicht; andere Elemente werden ausgeblendet
Hintergrund/Sperrbildschirm: Öffnet eine Vollbild‑Alarmansicht gemäß OS‑Policies; bei Android/5G‑Varianten mit erweiterten Rechten
Interaktion: Bestätigung schließt das Overlay, aktualisiert den Alarmstatus und löst nachgelagerte Flows (z. B. Rückruf)
Edge Cases
„Nicht stören“/Sperrbildschirm: OS‑Regeln haben Vorrang; Vollbild kann eingeschränkt sein
Multitasking: Bei aktiven Vollbild‑Overlays sind andere App‑Interaktionen temporär blockiert
Barrierefreiheit: Kontrast/Farben und Schriftgrößen berücksichtigen; Screenreader‑Hinweise
Sicherheit & Datenschutz
Anzeige beschränkt sich auf erforderliche Alarmdaten; keine überflüssigen personenbezogenen Inhalte
Aktionen werden auditierbar protokolliert (Zeitpunkt, Entscheidung)
Tests & Qualität
Prioritäts‑Trigger: Vollbild öffnet ab der konfigurierten Stufe zuverlässig
UI‑Lesbarkeit: Helligkeit, Kontrast, Buttons klar und erreichbar
Sperrbildschirm/DND: Verhalten unter verschiedenen OS‑Einstellungen prüfen
