[TetraControl2Connect] Ein TC mit unendlich vielen Standorten / Organisationen verbinden

1. offizieller Beitrag
    • Offizieller Beitrag

    Ich weiß nicht warum, aber ich wurde jetzt die letzten 2 Wochen aus ganz Deutschland von sehr vielen Leuten angesprochen, die von TC aus in mehrere Organisationen ihre Status und Positionsdaten übermitteln wollen. Ich habe euch ein Tool versprochen, versprechen gehalten :)

    #) Tetracontrol muss lokal laufen

    #) WebServer auf Port 80 Starten

    #) Benutzer: Connect Passwort: Connect anlegen

    1) Alle öffentliche Schnittstellen ConnectKeys werden aus ConnectKeys .txt ausgelesen. (Datei wird beim ersten starten erstellt)

    ===> Es können beliebig viele Keys dort hinterlegt werden, durch Zeilenumbruch trennen.

    2) Wir fragen Connect pro Key nach den vorhandenen Fahrzeugen und merken uns diese.

    ===> Bei neuen Fahrzeugen muss dieses Tool hier neu gestartet werden.

    !!WICHTIG!! Nur Fahrzeuge deren Issi wir matchen können verarbeiten wir! In Connect bei Funkgerätekennung eintragen.

    3) Bei einem neuen Status oder Position wird das Fahrzeug in den gespeicherten Fahrzeugen gesucht.

    4) Wenn wir den Status oder Position einem Fahrzeug zuordnen können, senden wir die Information mit dem endsprechenden Key hoch an Connect.

    Download: https://feuersoftware.com/Download/TetraControl2Connect.zip

    Sollte auch für unsere experten unter Linux laufen, dann müsst ihr einen Proxy bauen der den lokalen 80er Port auf TC umleitet. Soweit ich weiß geht TC ja eh nur unter Windows?

    Timo kannst du das bitte mit in die Doku aufnehmen? Danke :*

    PS: Das ganze ist mit unserer öffentlichen API umgesetzt, also alle die Basteln wollen könnten dies auch alles selbst bauen.

    • Offizieller Beitrag

    Update - Probleme beim GPS Update behoben

    • Offizieller Beitrag

    Update, ein Fahrzeug, dass mehrfach in Organisationen angelegt wurde, dessen Status wird jetzt auch in alle Orgas übermittelt.

    Hallo!

    In der Konfigurationsdatei "appsettings.json", Abschnitt "ConnectOptions" kann bei den einzelnen Schleifen (unter "SubnetAddresses") das Flag "AlarmDirectly" gesetzt werden.

    So ganz klar ist mir die Funktion an dieser Stelle noch nicht.

    Ich habe es für mich jetzt mal so interpretiert:

    Geht über einen via TETRAcontrol verbundenen P8GR ein Alarm ein, wird dieser für "AlarmDirectly=true" direkt nach Connect hochgeladen mit der Folge, dass eine Alarmierung der Einsatzkräfte erfolgt (gemäß der dyn. AAO und der Alarmgruppen).

    Für "AlarmDirectly=false" werden lediglich die Daten, eines bereits in Connect vorliegenden Alarms, um die ggf. fehlenden Subs ergänzt.

    Ist das so korrekt?

    • Offizieller Beitrag

    Hey,
    Ja ganz genau so ist es. Die Funktion haben wir eingebaut, da z.B. bei einem Probealarm teilweise keine Einsatz von der Leitstelle eröffnet wird und somit keine Einsatzdaten vorliegen. Daher wäre es hier unsinnig mehrfach zu versuchen einen Einsatz zu updaten. Hier wird also direkt ein Einsatz in Connect erstellt.

    Prima!

    Noch zwei Fragen:

    1. Bei der dynamischen AAO haben wir als Bedingung z.B. "RIC enthält "0815471_03" für die direkte Alarmierung durch die Leitstelle eingetragen (bei uns leider über die Alamos-Schnittstelle). Wenn TetraControl2Connect einen Einsatz hochlädt, funktioniert die Abfrage noch oder müssen dann GSSI und Sub in dieser Form angegeben werden: "0815471&03" (also einem "&" anstelle eines "_")?

    2. Leider funktioniert die Alarmierung unserer Leitstelle über die Alamos-Schnittstelle nicht zuverlässig (scheint aber ein Problem der Leitstelle zu sein). Werden mehrere Subs alarmiert, fallen immer mal wieder einige unter den Tisch, kommen also nicht bei Connect an.
    Hier bietet es sich ja dann an, mit Hilfe des angeschlossenen P8GRs eine Redundanzalarmierung zu implementieren.
    Setzt man bei allen Subs "AlarmDirectly=true", würden alle Alarme hochgeladen werden. Somit ist sichergestellt, dass der Alarm immer ankommt (Redundanz).
    Im Regelfall existieren die Alarme aber schon, zumindest teilweise (via Alamos-Schnittstelle). Wird dann bei Connect ein erneuter Einsatz angelegt (und Alarm ausgelöst), trotz identischer Einsatznummer?
    Was passiert bei einem noch nicht existierendem Einsatz für "AlarmDirectly=false"? Wir der einfach ignoriert oder trotzdem hochgeladen und führt zu einer Alarmierung?

    • Offizieller Beitrag
    Zitat von Stefan247

    Prima!

    Noch zwei Fragen:

    1. Bei der dynamischen AAO haben wir als Bedingung z.B. "RIC enthält "0815471_03" für die direkte Alarmierung durch die Leitstelle eingetragen (bei uns leider über die Alamos-Schnittstelle). Wenn TetraControl2Connect einen Einsatz hochlädt, funktioniert die Abfrage noch oder müssen dann GSSI und Sub in dieser Form angegeben werden: "0815471&03" (also einem "&" anstelle eines "_")?

    2. Leider funktioniert die Alarmierung unserer Leitstelle über die Alamos-Schnittstelle nicht zuverlässig (scheint aber ein Problem der Leitstelle zu sein). Werden mehrere Subs alarmiert, fallen immer mal wieder einige unter den Tisch, kommen also nicht bei Connect an.
    Hier bietet es sich ja dann an, mit Hilfe des angeschlossenen P8GRs eine Redundanzalarmierung zu implementieren.
    Setzt man bei allen Subs "AlarmDirectly=true", würden alle Alarme hochgeladen werden. Somit ist sichergestellt, dass der Alarm immer ankommt (Redundanz).
    Im Regelfall existieren die Alarme aber schon, zumindest teilweise (via Alamos-Schnittstelle). Wird dann bei Connect ein erneuter Einsatz angelegt (und Alarm ausgelöst), trotz identischer Einsatznummer?
    Was passiert bei einem noch nicht existierendem Einsatz für "AlarmDirectly=false"? Wir der einfach ignoriert oder trotzdem hochgeladen und führt zu einer Alarmierung?

    Das ganze ist nicht ganz so einfach zu erklären, da es hier einige Abhängigkeiten gibt. Habe gerade mit Moritz gesprochen. Er wird sich telefonisch bei dir melden.

    Das Telefonat mit Moritz konnte viele Fragen klären. Danke!

    Mit Hilfe eines P8GRs und entsprechender Konfiguration von TetraControl2Connect habe ich ein Redundanzsystem aufgebaut, was auch soweit funktioniert!

    Ein Punkt noch: Bei der monatlichen Funktionsprüfung sendet unsere Leitstelle nur die GSSI aus, jedoch keine Sub (bei entsprechender P8GR-Parametrierung lösen diese auch aus).
    Um das zu verarbeitet, müsste dann in der Konfigurationsdatei "appsettings.json", im Abschnitt "SubnetAddresses", für die fehlenden Sub dieser Eintrag gesetzt werden:
    "SNA": ""
    Also ein Leerstring. Würde das funktionieren?
    Und wie wäre dass dann in Connect, bei der dynamischen AAO auszuwerten? Eine Abfrage der RIC nur auf die GSSI würde ja immer auslösen!

    Ja, schön, dass hier jede Leitstelle ihr eigenes Süppchen kocht...

    Hier das Log:

    2022-11-15 18:00:40.094 +01:00 [INF] SDS received from '4674730'.

    2022-11-15 18:00:40.097 +01:00 [DBG] SDS {"Type":"sds","Status":"","StatusCode":"","StatusText":"","DestinationSSI":"2680602","DestinationName":"Biebertal","SourceSSI":"4674730","SourceName":"4674730","RadioId":2,"RadioName":"P8GR","Remark":"-1;0;223;","Alt":0,"FixQual":0,"Latitude":0,"Longitude":0,"Text":"Vollalarm Biebertal\\\nFunktionsüberprüfu…","TimestampUTC":"2022-11-15T17:00:39.8000000","$type":"TetraControlDto"}

    2022-11-15 18:00:40.150 +01:00 [INF] Processing SDS with Text 'Vollalarm Biebertal\

    Funktionsüberprüfung Tetra-Pager\

    jeden 15. eines Monats\' from ISSI '4674730'.

    2022-11-15 18:00:40.229 +01:00 [DBG] Could not find user with ISSI '4674730' in our user list. Ignoring...

    Bei uns nutzt die Sub 64 nur der Service-Point, zu Testzwecken. Die Sub 64 ist auch nur in der Benutzerrolle 4 ("Test") programmiert. Bei allen anderen Benutzerrollen fehlt diese. Daher ist eine Funktionsprüfung, wie bei Euch über die 64, gar nicht möglich! Es sei denn, die Kräfte wechseln vor der Prüfung explizit zur Benutzerrolle 4, was natürlich quatsch ist!
    Vor ein paar Jahren hatten wir eine Flächenlage, wo ein Vollalarm (GSSI ohne Sub) ausgelöst wurde. Also auch im Ernstfall ein durchaus realistisches Szenario, mit dem, wenn auch selten, zu rechnen ist.