Nach einem Alarm war der Einsatz in der App manchmal nicht sofort
sichtbar. Mit einer Umstellung am 09.07.2026 wurde das optimiert.

Warum passierte das?

Die App empfängt die Alarme auf zwei Wegen: über das Funksignal (wie der Pager) und über eine digitale Schnittstelle der Landesnotrufzentrale. Die Schnittstellendaten kamen dabei manchmal mit Verzögerung an — die App musste darauf warten, bevor der Einsatz angezeigt werden konnte. Die Ursache liegt
nicht in der App, sondern in der vorgelagerten Verarbeitung der Schnittstelle, auf die wir keinen Einfluss haben.

Was macht das Update?

Ab sofort erkennt das System, wenn Funkalarm und digitaler Alarm zum selben Einsatz gehören, und ordnet sie automatisch zusammen. Der Einsatz ist damit sofort sichtbar, sobald einer der beiden Kanäle eintrifft — ohne Wartezeit.

Beispiel 1 — Schnittstelle kommt zuerst

Die Feuerwehr Y fordert die Feuerwehr X mit der Drehleiter an. Die App zeigt den Text aus der digitalen Schnittstelle an — dieser kann kürzer oder anders aufgebaut sein als der Pagertext:

 Pager LNZ FW FF X A2 LANDWIRTSCHAFT HAUPTSTRASSE 29 FF Y FORDERT FF X MIT DL AN
 App FF X A2 LANDWIRTSCHAFT HAUPTSTRASSE 29

Es handelt sich um denselben Einsatz. Die Zusatzinfo (FF Y fordert FF X mit DL an) ist bei der Einsatzinfo in der App ersichtlich.

Beispiel 2 — Funk kommt zuerst

Die App empfängt zuerst denselben Alarm wie der Pager:

LNZ FW FF X A2 LANDWIRTSCHAFT HAUPTSTRASSE 29 FF Y FORDERT FF X MIT DL AN

Wenn später die digitalen Daten aus der Schnittstelle eintreffen, werden diese dem bereits vorhandenen Einsatz zugeordnet.

Beispiel 3 — Funksignal wird mehrfach ausgestrahlt

Funksignale werden technisch bedingt mehrfach gesendet, oft mit einem Abstand von ungefähr 30 Sekunden. Damit dadurch nicht mehrere Benachrichtigungen für denselben Einsatz entstehen, erkennt das System Wiederholungen und unterdrückt doppelte Benachrichtigungen.

Die Funkmeldungen werden dabei nicht gelöscht oder ignoriert. Auch unterdrückte Funkmeldungen werden weiterhin gespeichert und dem richtigen Einsatz zugeordnet. Die Unterdrückung betrifft nur doppelte Benachrichtigungen wie Push, SMS, E-Mail oder Webhooks.

Hinweis zum AlarmtextJe nachdem, welche Meldung zuerst eintrifft — Funkalarm oder digitaler Alarm — kann der Alarmtext in der App vom Text auf dem Pager abweichen.
Beides beschreibt denselben Einsatz. Alle Einsatzdaten und Rückmeldungen bleiben vollständig.

Hintergrund und technische Umsetzung

Ausgangslage

Pocsag Südtirol empfängt Alarme parallel über zwei Kanäle: das Funksignal (sog. Funkmeldung) und die Schnittstelle der LNZ (strukturierte Alarmdaten).
In der alten Datenbankstruktur erhielt jede Funkmeldung automatisch einen temporären Einsatz, der später mit den Schnittstellendaten der LNZ zusammengeführt und gelöscht wurde. Mit dem App Update und der damit verbundenen Datenbankumstellung Mitte Juni 2026 entfiel dieser Mechanismus:
Funkmeldungen werden seither direkt mit dem Einsatz aus der Schnittstelle verknüpft, was die Abhängigkeit von der Liefergeschwindigkeit der Schnittstellendaten erstmals richtig sichtbar machte.

Problem 1 — Verzögerung der bestehenden Schnittstelle

Die bisherige Schnittstelle übermittelt den korrekten Alarmtext (im Format des Pagertexts) über einen Kommentarmechanismus — das sogenannte „Alarmziel”. Dieser Kommentar wird vom LNZ-System nachgelagert an den Schnittstellenaufruf angehängt.

Da Pocsag Südtirol in der Alarmzielliste nach dem LFV eingetragen ist, erhält der LFV das Alarmziel systembedingt zuerst. Durch interne Messungen wurde belegt, dass der Schnittstellenaufruf mit dem
vollständigen Alarmtext mit Verzögerung bei Pocsag Südtirol einlangt.
Die genaue Ursache — ob LNZ-seitig oder durch die Verarbeitungskette des LFV — konnte nicht isoliert werden.

Technisch hängt die Verzögerung mit der sequenziellen Abarbeitung der Alarmziel-Endpunkte zusammen: Benötigt ein Endpoint länger für die Verarbeitung, müssen alle nachfolgenden Empfänger entsprechend warten.

Dieser Zusammenhang wurde in einem gezielten Test bestätigt und dem LFV kommuniziert. Auf Anfrage teilte der LFV mit, dass eine Korrektur der bestehenden Schnittstelle nicht geplant ist, da eine neue Schnittstelle
diese Problematik künftig lösen soll.
(welche aber nicht 1:1 verwendet werden kann – siehe Problem 2)

Problem 2 — Neue Schnittstelle ohne direkten Pager-Alarmtext

Die neue Schnittstelle liefert strukturierte Alarmdaten (event_subtype,alarm_level,event_location, etc.), enthält aber den Alarmtext im Pager-Format nicht direkt.
Dieser erscheint erst nachgelagert in den Kommentaren als Alarmziel-Eintrag.

Ein direkter Volltext-Abgleich zwischen dem Alarm der Schnittstelle und der Funkmeldung ist daher nicht möglich; die Texte sind unterschiedlich formatiert (z. B. FF X A2 LANDWIRTSCHAFT HAUPTSTRASSE 29 vs.LNZ FW FF X A2 LANDWIRTSCHAFT HAUPTSTRASSE 29).

Technische Lösung: Zweistufiger In-Memory-Cache

Stufe 1 — Schnittstellen-Funk-Abgleich

Beim Einlangen eines Alarms der Schnittstelle wird pro RIC ein Cache-Eintrag gesetzt (ric → (normalisierterText, einsatzId, Zeitstempel), TTL 2 Minuten). Beim Einlangen einer Funkmeldung für denselben RIC wird der Cache abgefragt. Liegt ein Eintrag vor und stimmen die Texte zu mindestens 60% überein, wird die Funkmeldung als Duplikat behandelt:
Die Benachrichtigung wird unterdrückt, die einsatzId aus dem Cache direkt übernommen.

Stufe 2 — POCSAG-Repeat-Unterdrückung

POCSAG-Signale werden technisch bedingt mehrfach ausgestrahlt (typischer Abstand ca. 30 Sekunden). Beim ersten Verarbeiten einer Funkmeldung wird ein zweiter Cache-Eintrag gesetzt ("{ric}_{normText}" → Zeitstempel, TTL 2 Minuten). Trifft dieselbe Funkmeldung erneut ein, wird sie über diesen Cache als Wiederholung erkannt und unterdrückt — unabhängig davon, ob ein Schnittstellen-Eintrag vorliegt.

Textabgleich-Verfahren

Da Schnittstellen- und Funk-Texte unterschiedliche Präfixe und Suffixe tragen, wird kein Volltext-Vergleich durchgeführt.
Stattdessen:

  • Text der Schnittstelle: Abschneiden von Zusatzinformationen ab
    ADR:
    bzw.
    BEH:
  • Beide Texte: Normalisierung (Großbuchstaben, nur alphanumerische Zeichen),
    Tokenisierung
  • Abgleich über Schnittmenge der signifikanten Wörter (Länge ≥ 4 Zeichen):
    Übereinstimmungsrate ≥ 60% relativ zur kürzeren Wortliste

Da der RIC bereits als primärer Schlüssel verwendet wird und Einsatzart, Stichwort sowie Ortsangabe in beiden Texten enthalten sind, liegt die Übereinstimmungsrate in der Praxis typischerweise bei nahezu 100% — auch wenn die Stationsnamen abweichen.

Verhalten bei Reihenfolgeumkehr

  • Schnittstelle zuerst: Cache-Eintrag vorhanden →
    Funkmeldung wird unterdrückt, einsatzIddirekt zugewiesen.
  • Funk zuerst: Kein Schnittstellen-Cache-Eintrag →
    Funkmeldung wird normal verarbeitet und in den Funk-Cache eingetragen;
    spätere Wiederholungen werden unterdrückt.
Datenintegrität
Unterdrückte Funkmeldungen werden weiterhin in die Datenbank geschrieben und
korrekt mit der einsatzId des Einsatzes verknüpft. Die Unterdrückung betrifft ausschließlich
ausgehende Benachrichtigungen (Push, SMS, E-Mail, Webhook) — nicht den Datenbankbestand.

Ist der Artikel hilfreich?

Comments are closed.