SDS2DB schreibt SDS-Nachrichten in eine MySQL-Datenbank

[ahk]

Wenn ein Endgerät gerade aktiv in einer Gruppe Empfängt (z.b. ein Gespräch), dann kommen SDS an eine andere Scan Gruppe nicht an.

Aber wenn Du 50 FuGs hast in 6 Gruppen, dann sind doch ca. 8 Geräte in einer Gruppe, die Du dann gemeinsam schalten kannst. Wofür dann Scangroups?
Oder habe ich da was falsch verstanden?

Gruß
Arne

[oliversc]

Mit SDS Empfang aus Scan-Gruppen habe ich gar keine Erfahrung. Meine FRT haben ihre Datengruppe gewählt. Alle HRT/MRT senden Status, LIP-Meldungen und Text-SDS an die Datengruppe. Von der Leitstelle zu den HRT/MRT gehen SDS an die ISSI. Für deine M2M Anwendung (jetzt wird mir dein Headless-Read-Only-FS-Ansatz klar ;-) würde ich aber mit jeder Lampe einzeln kommunizieren und deine Gruppenbildung auf Anwendungsebene realisieren. Da bist du viel flexibler und musst nicht mit komischen Scangruppen-SDS hantieren. ;-) Oder ist es wichtig, dass die Lampen gruppenweise syncron schalten?

Die Frage ist halt wie schnell 50 SDS hintereinander rausgehen.. wenn wir von einem Zeitraum von 15-20 Sekunden reden ist das sicherlich zu verschmerzen, bei allem was darüber hinaus geht wird es schon schwierig. Zumal ja auch jeder einzelne Empfänger seine Aktion (die untersschiedlich sein kann) quittiert.
Ist hal nicht so einfach eine heisorisch gewachsene Struktur mal up-zo-date zu bringen.. und Lösungen von der Stange gibts für diesen Einsatzzweck absolut gar keine..

[oliversc]

Wenn ein Endgerät gerade aktiv in einer Gruppe Empfängt (z.b. ein Gespräch), dann kommen SDS an eine andere Scan Gruppe nicht an.

Aber wenn Du 50 FuGs hast in 6 Gruppen, dann sind doch ca. 8 Geräte in einer Gruppe, die Du dann gemeinsam schalten kannst. Wofür dann Scangroups?
Oder habe ich da was falsch verstanden?

Die Geräte werden ausschliesslich zur M2M (machine to machine) Kommunikation verwendet. Ausser SDS passiert auf den Geräten nix.
Verschiedene Gruppen damit diese Geräte en Bloc angesprochen werden können. Scan Gruppen weil verschiedene Szenarien halt vorsehen dass verschiedene Geräte je nach Szenario "zusammengehören"

[flachrelais_48]

Die Geräte werden ausschliesslich zur M2M (machine to machine) Kommunikation verwendet. Ausser SDS passiert auf den Geräten nix.
Verschiedene Gruppen damit diese Geräte en Bloc angesprochen werden können. Scan Gruppen weil verschiedene Szenarien halt vorsehen dass verschiedene Geräte je nach Szenario "zusammengehören"

Ich bleibe dabei... ;-) Alle in eine Datengruppe und die Adressierung der zu steuernden Systeme auf Anwendungsebene machen. Also eine SDS mit dem Kommando "Lampen an / Steuergruppe 27" an die eine Tetra-Daten-Gruppe schicken. Der empfangende Steuerrechner schaut ob er zur Steuergruppe 27 gehört und das Kommando ausführt, oder nicht. Wenn du flexibel bleiben willst, machst du die Steuergruppenzugehörigkeit dynamisch und steuerst sie auch per Kommando-SDS. Vlt. gibt es da ja ein Protokoll aus der Automationstechnik, an dem du dich orientieren kannst? Mit MQTT lässt sich auf den Steuerrechnern ja auch ein Control-Stack umsetzen (Stichwort "Retained Message").

[oliversc]

Ich bleibe dabei... ;-) Alle in eine Datengruppe und die Adressierung der zu steuernden Systeme auf Anwendungsebene machen. Also eine SDS mit dem Kommando "Lampen an / Steuergruppe 27" an die eine Tetra-Daten-Gruppe schicken. Der empfangende Steuerrechner schaut ob er zur Steuergruppe 27 gehört und das Kommando ausführt, oder nicht. Wenn du flexibel bleiben willst, machst du die Steuergruppenzugehörigkeit dynamisch und steuerst sie auch per Kommando-SDS. Vlt. gibt es da ja ein Protokoll aus der Automationstechnik, an dem du dich orientieren kannst? Mit MQTT lässt sich auf den Steuerrechnern ja auch ein Control-Stack umsetzen (Stichwort "Retained Message").

Was auf Empfängerseite hinter dem Radio passiert kann ich leider nur sehr eingeschränkt beeinflussen.
Die Idee auch dort etwas habwegs intelligentes an Technik zu installieren gestaltet sich aus den verschiedensten Gründen schwierig bis quasi unmöglich.
Gruppenzugehörigkeit dynamisch höst sich nach nem guten Plan an..

[flachrelais_48]

Was auf Empfängerseite hinter dem Radio passiert kann ich leider nur sehr eingeschränkt beeinflussen.
Die Idee auch dort etwas habwegs intelligentes an Technik zu installieren gestaltet sich aus den verschiedensten Gründen schwierig bis quasi unmöglich.

Das macht so ein M2M Projekt natürlich nicht einfacher. Ohne Logik auf Empfängerseite wird's schwierig. Wie stellst du dir das vor?

[oliversc]

Das macht so ein M2M Projekt natürlich nicht einfacher. Ohne Logik auf Empfängerseite wird's schwierig. Wie stellst du dir das vor?

Eine gewisse Logik ist vorhanden, nur leider sehr rudimantär. Hinter den FuG sind irgendwelche MikroController die zumindest ein paar Rückmeldungen an das FuG weitergeben. Leider sind die natürlich nicht alle gleich - wo kämen wir denn dahin. ;-)
Das Leben steckt heir voller Überaschungen, und je mehr ich technisch hinterfrage, umso mehr Baustellen tun sich auf.. Von daher bin ich lieber erstmal vorsichtig...

[oliversc]

Das macht so ein M2M Projekt natürlich nicht einfacher. Ohne Logik auf Empfängerseite wird's schwierig. Wie stellst du dir das vor?

mal wieder ein kurzes Update..
nach diversen Gesprächen und gaaaanz viel Kaffee mit dem technischen Ansprechpartner der Empfängerseite werden jetzt Arduino Boards als Empfangs-Steuerkomponente eingesetzt.
Damit ist dann auch mehr als genug Logig auf der Empfänergseite vorhanden um vernünftig zu kommunizieren.

Serverseitig ist mittlerweile die Konfig so geändert dass das Alix Board nur noch der reinen Kommunikation dient. hat den Vorteil dass ich außer für die Logfiles mit einem reinen readonly filesystem arbeiten kann.
sds2db kommuniziert in einem seperaten Subnetz über ssh mit dem Datanbankserver der auch die Gui zur Verfügung stellt.

Was mir momentan noch ein wenig Kopfzerbrechen bereitet ist das pollen von LIP Daten.. irgendwie bekomme ich das nicht wirklich hin. Jedenfalls antwortet kein Gerät mit seinen GPS Daten.
Gibts da irgenwas spezielles was ich im HRT MTH800 bzw 850 aktivieren oder deaktivieren muss damit das angesprochene Gerät auch antwortet?

[flachrelais_48]

Hast du denn das GPS Feature auf deinen Geräten verfügbar? Das muss natürlich im Codeplug aktiviert und konfiguriert sein. Meine Geräte antworten auf einen Immediate Location Report Request.

[oliversc]

Hast du denn das GPS Feature auf deinen Geräten verfügbar? Das muss natürlich im Codeplug aktiviert und konfiguriert sein. Meine Geräte antworten auf einen Immediate Location Report Request.

Kann mir auf den Geräten zum Beispiel die GPS Koordinaten anzeigen lassen. .

[flachrelais_48]

Ja, aber das sagt nichts darüber, ob auch LIP als Transport-Protokoll konfiguriert ist.
Wie sieht es denn auf deinem Leitstellen-Daten-Gerät aus? Dort muss das GPS Feature Flag deaktiviert sein.
Interessant wäre auch das Schnittstellenlog der PEI-Initialisierung von sds2db. Ist die Antwort auf "AT+CTSP=1,3,10" "OK"?

[oliversc]

Ja, aber das sagt nichts darüber, ob auch LIP als Transport-Protokoll konfiguriert ist.
Wie sieht es denn auf deinem Leitstellen-Daten-Gerät aus? Dort muss das GPS Feature Flag deaktiviert sein.
Interessant wäre auch das Schnittstellenlog der PEI-Initialisierung von sds2db. Ist die Antwort auf "AT+CTSP=1,3,10" "OK"?

Mittlerweile hab ich den Fehler gefunden.
Mein Leistellen-Gerät muss in die Liste der LIP berechtigten Geräte eingtragen sein.. sonst klappt das nicht.. ;)

[flachrelais_48]

Ach ja, jezt wo ich es lese.... Musste ich bei mir auch anpassen. Sorry. Bei meiner Version ist es aber keine Liste sondern eine Range die durch "GPS Authorized ISSI Base" und "GPS Authorized ISSI Range" definiert wird.

[TLF1625]

Hallo flachrelais_48,

wollte mal nachfragen, ob du deine Version von SDS2DB die auf Mosquitto umgestellt ist, für uns hier bereitstellen kannst ??? Oder hast du optional eine Anleitung, wie ich SDS2DB auf Mosquitto umstellen kann ?
Wir nutzen SDS2DB mittlerweile im ELW, allerdings nicht in einer reinen Datengruppe. Bei vielen Gesprächen wächst der spool Ordner jedoch recht flott auf einige Dateien an. Beispielsweise bei den Unwettern vor zwei Wochen hinkte meine Dokumentation dann immer gut 5 (teilweise 10) Minuten dem eigentlichen Gespräch hinterher.
Wenn ich das oben im Thread richtig verstanden habe, dann verarbeitet die Mosquitto Lösung die Kommunikation schneller?!

Danke schonmal im Voraus.
TLF1625

[flachrelais_48]

Oh ja, Mosquitto ist ein Quantensprung gegenüber dem alten Spool-File-System.
Bei meinem Projekt hat sich viel getan. Nachdem es immer mehr Funktionen abdecken musste, habe ich es umbenannt und neu strukturiert. Es heißt jetzt "SMI" (Short Message Intermediary). Die Funktionen habe ich modularisiert. Es gibt nun Transceiver-Plugins und Subscriber-Plugins. Die Transceiver-Plugins (SDS, SMS und POCSAG) publishen empfangene Nachrichten auf ihrem MQTT-Topic. Die Subscriber-Plugins (mysql,sdsfrpoc,sdsfrsms) abonnieren die MQTT-Topics und verarbeiten die Nachrichten. Das System ist so flexibel für Erweiterungen. Denkbar wären z.B. künftige Transceiver-Plugins für Messenger-Anbindungen wie Signal oder Telegram. Ich habe auch die Sys-v-Initscripte auf Systemd-Units umgestellt.

Ich werde demnächst modularisierte tgz-Archive bereitstellen. Dann kann sich jeder sein SMI nur mit den benötigten Modulen installieren.
Die alte SDS2DB-Version umzustricken ist eher keine Option. Was macht ihr denn im ELW damit? Habt ihr ein Status-Frontend?