Wie können wir helfen?

TetraControl2Connect

Erstellt am
Zuletzt aktualisiert am
durchTimo Schwab
Print
Du bist hier:
< Alle Themen

Allgemeines

TetraControl 2 Connect ist ein einfaches Kommandozeilen Tool zur Verbindung von TetraControl mit mehreren Connect Standorten oder Organisationen. Das Programm verbindet sich über eine Websocket-Verbindung mit dem Webserver von TetraControl und verarbeitet Positionsdaten, Statusdaten und SDS. Funkgespräche werden ignoriert.

Normalerweise werden Status- und Positionsdaten über den EinsatzMonitor in den entsprechenden Connect Standort hochgeladen. Dieses Tool stellt eine Alternative da, für Standorte an denen kein EinsatzMonitor installiert werden soll. Das Tool wird von FeuerSoftware kostenlos zur Verfügung gestellt und stellt die Verknüpfung zwischen der kostenpflichtigen Software „TetraControl“ und der FeuerSoftware Cloud „Connect“ da. Die Daten werden über die Öffentliche Connect API verarbeitet.

Funktionsweise

Positions- und Statusupdates

Bei einem neuen Status oder Position wird das Fahrzeug in den gespeicherten Fahrzeugen gesucht. Wenn wir den Status oder Position einem Fahrzeug zuordnen können, senden wir die Information mit dem endsprechenden Key an Connect.

Rückmeldungen und Verfügbarkeit

Bei einer neuen Rückmeldung zu einem Einsatz oder setzen der Verfügbarkeit am Pager suchen wir den entsprechenden Benutzer anhand der ISSI und senden die Rückmeldung bzw. Verfügbarkeit an Connect.

Sonderfunktion „Einsatzupdate bei Wechselschleifen“

Diese Funktion setzt voraus, dass über einen anderen Weg (z.B. E-Mail, WDX,..) bereits ein Einsatz in Connect angelegt wird. Wenn in dem vorhandenen Einsatz die Informationen fehlen, welche SNA (Subnetzadresse) alarmiert wurde, kann mit dieser Funktion diese hinzugefügt werden. TetraControl2Connect empfängt die Alarm SDS des Pagers und aktualisiert den letzten bereits angelegten Einsatz in Connect um die Informationen der alarmierten SNA (Subnetzadresse) im RIC Feld. Hierbei wird die alarmierte SNA z.B. &01 aus der AlarmSDS ausgelesen und im RIC Feld als „SNA(&01)“ angehangen. Es werden keine weiteren Einsatzinformationen aktualisiert. Durch den Einsatz der Dynamischen AAO in Connect kann nun nach der alarmierten SNA alarmiert werden auch wenn die Informationen im ursprünglichen Einsatz nicht vorhanden waren.

Download TetraControl2Connect

Inbetriebnahme

Voraussetzungen

  • TetraControl muss auf durchgehend laufen (am besten auf localhost, Websocket-Verbindung ist nicht verschlüsselt!)
  • In TetraControl muss der Webserver aktiviert sein
  • In TetraControl muss ein entsprechender Benutzer mit ausreichenden Berechtigungen fü den Webserver angelegt werden.

Hinweise

  • Wenn Fahrzeuge oder Benutzer neu angelegt oder geändert wurden, werden diese erst nach 4 Stunden neu eingelesen. Alternativ kann das Programm neu gestartet werden.
  • Wir können nur Daten verarbeiten, wenn die ISSIs der Fahrzeuge und Benutzer in Connect korrekt hinterlegt sind.

Konfiguration

Die Konfiguration wird in der Datei appsettings.json vorgenommen. Diese muss im gleichen Verzeichnis wie die Anwendung selbst liegen.

Abschnitt Serilog

Dies ist die Konfiguration der Protokollierung. Unter MinimumLevel kann die Protokollierungebene gewählt werden. Gütige Werte sind: Debug, Information, Warning, Error und Critical.
Im Unterabschnitt WriteTo unter „File“ kann der Pfad für die Logdateien und die Anzahl der Logdateien, die aufbewahrt werden sollen, gewählt werden. Im Pfad müssen doppelte \ verwendet werden!

{
  "Serilog": {
    "Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File", "Serilog.Sinks.Debug" ],
    "MinimumLevel": "Debug",
    "WriteTo": [
      { "Name": "Console" },
      { "Name": "Debug" },
      {
        "Name": "File",
        "Args": {
          "path": "logs\\log.txt",
          "rollingInterval": "Day",
          "retainedFileCountLimit": 7
        }
      }
    ]
  }

Abschnitt TetraControlOptions

Dies ist die Konfiguration der Verbindung zu TETRAcontrol.

TetraControlHost -> Serveradresse des TETRAcontrol Webservers.
TetraControlPort -> Port zur Verbindung des TETRAcontrol Webservers. Standard: 80
TetraControlUsername -> Benutzername zur Authentifizierung am TETRAcontrol Webserver
TetraControlPassword -> Passwort zur Authentifizierung am TETRAcontrol Webserver

"TetraControlOptions": {
    "TetraControlHost": "localhost",
    "TetraControlPort": 80,
    "TetraControlUsername": "Connect",
    "TetraControlPassword": "Connect"
  }

Abschnitt ProgramOptions

Unter SendVehicleStatus kann eingestellt werden, ob Fahrzeugstatus übertragen werden (Standard: true)
Unter SendVehiclePositions kann eingestellt werden, ob Fahrzeugpositionen übertragen werden (Standard: true)
Unter SendUserOperationStatus kann eingestellt werden, ob Einsatzrückmeldungen von Benutzern übertragen werden (Standard: true)
Unter SendUserAvailability kann eingestellt werden, ob Benutzer-Verfügbarkeiten (Taktische Verfügbarkeit) übertragen werden (Standard: true)
Unter SendAlarms kann eingestellt werden, ob Callouts (Alarmierungen) ausgewertet und übertragen werden (Standard: true)
Unter UserAvailabilityLifetimeDays kann die Anzahl der Tage eingestellt werden, wie lange eine Verfügbarkeit für einen Benutzer gelten soll, bis sie zurückgesetzt wird.
Unter WebSocketReconnectTimeoutMinutes kann die Zeitspanne in Minuten eingestellt werden, nachdem die WebSocket-Verbindung zu TetraControl neu hergestellt werden soll, nachdem in dieser keine Nachrichten von TetraControl empfangen worden sind. (Standard: 5 Minuten)
Unter PollForActiveOperationBeforeFallbackMaxRetryCount kann die Anzahl der maximalen Versuche eingestellt werden, um nach einem aktiven Einsatz in Connect zu schauen, bevor ein Fallback-Alarm gegeben wird. (Standard: 4)
Unter PollForActiveOperationBeforeFallbackDelaySeconds kann die Zeitverzöerung in Sekunden zwischen den Versuchen nach einem aktiven Einsatz in Connect zu schauen eingestellt werden. (Standard: 10 Sekunden)
Unter HeartbeatEndpointUrl kann die Url angegeben werden, zu der im eingestellen Intervall ein HTTP-GET Request gesendet wird. (z.B. f UptimeRobot, falls leer gelassen wird kein Heartbeat gesendet)
Unter HeartbeatInterval kann das Intervall eingestellt werden, wie oft der Heartbeat-Aufruf erfolgen soll. (Format HH:mm:ss, wenn kein Wert wird kein Heartbeat gesendet)
Unter IgnoreStatus5 kann eingestellt werden, ob Status 5 (Sprechwunsch) ignoriert werden soll. (True/False, Standard: False)
Unter IgnoreStatus0 kann eingestellt werden, ob Status 0 (Priorisierter Sprechwunsch) ignoriert werden soll. (True/False, Standard: False)
Unter AddPropertyForAlarmTexts kann eingestellt werden, ob bei einer Einsatz-Aktualisierung nach Alarmeingang auch ein Zusatzfeld mit dem Alarmtext vom Pager erstellt werden soll
Unter UseFullyQualifiedSubnetAddressForConnect kann eingestellt werden, ob die Darstellung der alarmierten Subnetzadressen ausfürlich oder geküzt erfolgen soll. (Bei True: z.B. „T2C(71234567_&01 – SBI“), bei False (standard): „SNA(&01)“)
Unter IgnoreAlarmWithoutSubnetAddresses kann eingestellt werden, ob Callouts (Alarme) ohne Subnetzadressen (also an die gesamte GSSI) ignoriert werden sollen (Standard: false)
Unter AcceptCalloutsForSirens kann eingestellt werden, ob Callouts (Alarme) für Sirenen (beginnend mit Steuerzeichen z.B. $2002) verarbeitet werden sollen (Standard: false)

"ProgramOptions": {
    "UserAvailabilityLifetimeDays": 7,
    "WebSocketReconnectTimeoutMinutes": 5,
    "PollForActiveOperationBeforeFallbackMaxRetryCount": 4,
    "PollForActiveOperationBeforeFallbackDelay": "00:00:10",
    "HeartbeatEndpointUrl": "",
    "HeartbeatInterval": "00:10:00",
    "IgnoreStatus5": false,
    "IgnoreStatus0": false,
    "AddPropertyForAlarmTexts": false,
    "UseFullyQualifiedSubnetAddressForConnect": false,
    "IgnoreAlarmWithoutSubnetAddresses": false
  }

Abschnitt StatusOptions

Hier müssen die Statuswerte (Zahlenwert, nicht der Text) eingestellt werden, die vom Pager für die einzelnen Status gesendet werden. (Bitte Melderkonfiguration beachten!)

  • AvailableStatus -> Status „Verfügbar“
  • LimitedAvailableStatus -> Status „Bedingt verfügbar“
  • NotAvailableStatus -> Status „nicht verfügbar“
  • ComingStatus -> Einsatzrückmeldung „komme“
  • NotComingStatus -> Einsatzrückmeldung „komme nicht“
  • ComingLaterStatus -> Einsatzrückmeldung „komme später“

Wenn ein Status nicht verwendet wird, kann dort -1 eingetragen werden. Wichtig ist, dass dieser Status nicht an anderen Stellen in der Melderkonfiguration verwendet wird, um Missverständnisse zu vermeiden.

Ab Version 2.1.9 ist es möglich, hier mehrere Statuswerte in folgendem Format einzutragen „123;456;789“. (Nützlich, um z.B. verschiedene Pager-Hersteller gemischt auszuwerten (Motorola/Airbus).

  "StatusOptions": {
    "AvailableStatus": "15",
    "LimitedAvailableStatus": "-1",
    "NotAvailableStatus": "0",
    "ComingStatus": "32768;57345",
    "NotComingStatus": "32769;57344",
    "ComingLaterStatus": "-1"
  }

Abschnitt SeverityOptions

Hier wird der Umgang mit den Schweregraden von Alarmierungen gesteuert.

  • UseServerityTranslationAsKeyword -> Schweregradübersetzung als Stichwort für Fallback-Einsäzte verwenden (anstelle von „ALARM“)
  • SeverityTranslations -> Da die Schweregrad-Texte von der Melderprogrammierung abhängig sind und nur die Zahl von TetraControl übermittelt wird, können hier die Übersetzungen der Schweregrade eingetragen werden. (Standard: Hessen) Falls keine Übersetzung gefunden wird, wird „ALARM“ genommen
  "SeverityOptions": {
    "UseServerityTranslationAsKeyword": true,
    "SeverityTranslations": {
      "1": "Information",
      "2": "Einsatzabbruch",
      "3": "Bereitschaft",
      "4": "Krankentransport",
      "5": "Rettungsdienst R-O",
      "7": "Hilfeleistung normal",
      "8": "Feuer normal",
      "9": "Rettungsdienst R-1",
      "10": "Rettungsdienst R-2",
      "11": "Hilfeleistung dringend",
      "12": "Feuer dringend",
      "13": "Groﾟalarm",
      "15": "KatS-Alarm"
    }

Abschnitt ConnectOptions

Hier müssen die API-Keys aus Connect eingetragen werden. Unter Name kann eine frei wählbare Bezeichnung hinterlegt werden, um die Schlüssel besser zuordnen zu können.

Die Authentifizierungschlüssel können im Connect Portal für jeden Standort unter „Schnittstellen“ -> „Öffentliche Connect-Schnittstelle“ angezeigt und kopiert werden.

Eintragen mehrerer Schlüssel erfolgt nach der JSON-Syntax. (Siehe https://developer.mozilla.org/de/docs/Learn/JavaScript/Objects/JSON#arrays_als_json)

Hinweis: Die SubnetAddresses und GSSI sind aktuell nur für bestimmte Feuerwehren relevant und müssen nicht ausgefüllt werden. (Siehe Sonderfunktion „Einsatzupdate bei Wechselschleifen“)
Unter AlarmDirectly kann pro Schleife eingestellt werden, ob ein Alarm direkt nach Pagerauswärtung nach Connect hochgeladen werden soll.
Dann wird für diese Schleife nicht versucht, einen vorhandenen Einsatz zu aktualisieren.

"ConnectOptions": {
    "Sites": [
        {
            "Name": "Organisation1",
            "Key": "<<KEY1>>",
            "SubnetAddresses": [
                {
                    "Name": "Schleife1",
                    "GSSI": "12345678",
                    "SNA": "&01",
                    "AlarmDirectly": false
                },
                {
                    "Name": "Schleife2",
                    "GSSI": "12345678",
                    "SNA": "&01",
                    "AlarmDirectly": false
                }
            ]
        },
        {
            "Name": "Organisation2",
            "Key": "<<KEY2>>",
            "SubnetAddresses": [
                {
                    "Name": "Schleife1",
                    "GSSI": "12345678",
                    "SNA": "&01",
                    "AlarmDirectly": false
                },
                {
                    "Name": "Schleife2",
                    "GSSI": "12345678",
                    "SNA": "&01",
                    "AlarmDirectly": false
                }
            ]
        }
    ]
}

Fragen und Probleme

Hier finden Sie den entsprechenden Artikel aus dem Feuersoftware Forum.

Zum Beitrag im Forum
Schlagwörter:
Inhaltsverzeichnis