SDS2DB schreibt SDS-Nachrichten in eine MySQL-Datenbank

[oliversc]

Das klingt ja interessant, was für eine Distro hast du genommen und wie hast du die Mountpoints umgebogen?

Debian GNU/Linux 6.0 - readonly filesyste in Anlehnung an https://help.ubuntu.com/community/au...stemOnUsbFlash

Ich habe sehr gute Erfahrungen mit FTDI USB/RS232 Adaptern gemacht. Da sie eindeutige Seriennummern in der USB-Firmware mitbringen, kann man schöne UDEV-Regeln anlegen und sprechende Links erzeugen.

Sowas dachte ich mir schon "ser_device=TETRA1" ;-)

Inotifywait ist für mich Geschichte. Habe in meiner ständigen Entwicklungsversion das Spool-System auf MQTT (mosquitto) umgestellt. Das beschleunigt die Kommunikation von SDS2DB mit den MT's deutlich. (obwohl es kein Problem war)

hört sich interessant an.. kann ein host gleichzeitig Borker, Subscriber und Publisher sein? also alles auf einer physikalischen Maschine?

By the way
was schicke ich denn an für eine LIP Abfrage an ein Geräte dass es mir mit seinen GPS Koordinaten antwortet?

LG
Oli

[flachrelais_48]

Debian GNU/Linux 6.0 - readonly filesyste in Anlehnung an https://help.ubuntu.com/community/au...stemOnUsbFlash

Danke, schaue ich mir mal an...

hört sich interessant an.. kann ein host gleichzeitig Borker, Subscriber und Publisher sein? also alles auf einer physikalischen Maschine?

Mit der Installation von mosquitto wird der Brokerdaemon eingerichtet. mosquitto_sub ist Subscriber, mosquitto_pub ist Publisher. Bei mir alles auf einer Maschine. Ist aber kein Muss. Man kann die Rollen auch auf verschiedene Maschinen aufteilen. Auf Wunsch mit Authentifizierung und TLS-Verschlüselung.

By the way
was schicke ich denn an für eine LIP Abfrage an ein Geräte dass es mir mit seinen GPS Koordinaten antwortet?

Ein "Immediate location report request". Habe meine SDS-Encode PHP-Funktion schon erweitert. ;-)

[oliversc]

Mit der Installation von mosquitto wird der Brokerdaemon eingerichtet. mosquitto_sub ist Subscriber, mosquitto_pub ist Publisher. Bei mir alles auf einer Maschine. Ist aber kein Muss. Man kann die Rollen auch auf verschiedene Maschinen aufteilen. Auf Wunsch mit Authentifizierung und TLS-Verschlüselung.

Ein "Immediate location report request". Habe meine SDS-Encode PHP-Funktion schon erweitert. ;-)

[/QUOTE]


Magst du mir da Einblick in deine Konfig (mosqitto) und die SDS Encode Funktion gewähren? ;-)

Eins meiner Projekte hier ist die Fernsteuerung (Ein- Ausschalten) von Lampen über Tetra.
Es stellt sich dabei die Frage ob ein FuG auch SDS aus Scan Gruppen zuverlässig empfangen kann. (SDS2Group).
Das heisst wenn ich im Maximalausbau 50 FuG habe, die auf bis zu 6 verschiedenen (Daten)Gruppen hören so dass ich die "Gruppenweise" ansprechen kann.. geht das ?

[flachrelais_48]

Eins meiner Projekte hier ist die Fernsteuerung (Ein- Ausschalten) von Lampen über Tetra.
Es stellt sich dabei die Frage ob ein FuG auch SDS aus Scan Gruppen zuverlässig empfangen kann. (SDS2Group).
Das heisst wenn ich im Maximalausbau 50 FuG habe, die auf bis zu 6 verschiedenen (Daten)Gruppen hören so dass ich die "Gruppenweise" ansprechen kann.. geht das ?

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?

[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]

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]

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..