monitor 1.9.0 - aber richtig :)

[nepomuck]

Die Sache mit dem Fehlercode ist gut. Das kann man als Datenfeld noch eintragen.

Mir fallen dazu spontan folgende Fehler ein:
Vom Server: Problem mit Soundkarte; Fehler in Konfig-Datei; Softwarefehler (kann Module nicht laden etc..); User ungültig; Passwort falsch; No anonymous Login(siehe unten); Netzwerkfehler; Server voll (evtl. Login-Limit)

Ping/Pong:
Ich würde einen Ping von beiden Seiten einrichten, so dass sowohl der Server als auch der Client die Verbindung überprüfen können. Dem Pong-Befehl sollte zudem als Datenfeld Datum und Uhrzeit der jeweiligen Maschine anhängen, dann können sich Client und Server synchronisieren.

Der Sirenendoppelton wird beim ZVEI mit ausgegeben.

Bei einer Sirenenalarmierung gäbe es also eine doppelte Ausgabe?
300:26250:1
330:1
Macht as Sinn?

Ein Login sähe nach meiner Meinung z.B. so aus :
120
220:Harry:Hirsch
122

Jagen wir da den Benutzernamen als ASCII durch? Oder bleiben wir dabei, dass wir Konsequent alle Textübertragungen Hex-Codieren?

Da die Passwörter auf beiden Seiten ja bekannt sind, kann man hier ne Einweg-Verschlüsselung nehmen

Das sollte genügen. Es müßte ja passende crypt-Funktionen geben, die als Output ein Hex-kodierten Code liefern.
Ich würde zudem vorschlagen, dass der Monitor-Daemon je nach Konfiguration auch anonyme Logins ohne PW zulassen kann.

Oder wir lassen über einen zweiten Befehl auch das Anmelden im Klartext zu.

Würde ich nicht. Entweder gleich anonym (für Server die ohnehin nur im Intranet laufen) oder mir sauber verschlüsseltem Hash. Da könnte man über die Konfigurationsdatei regeln, wer sich wie anmelden darf. Es könnte eine "Trusted-Hosts"-Liste geben mit IP-Adressen die anonym reinkommen während maschinen von außen sich anmelden müssen.

Andreas

[MiThoTyN]

Ping/Pong:
Ich würde einen Ping von beiden Seiten einrichten, so dass sowohl der Server als auch der Client die Verbindung überprüfen können. Dem Pong-Befehl sollte zudem als Datenfeld Datum und Uhrzeit der jeweiligen Maschine anhängen, dann können sich Client und Server synchronisieren.

Brauch man eigentlich nicht. Der Client prüft in regelmäßigen Zeitabständen die Verbindung. Das Ergebnis ist ja auch Aussagekräftig für den Server. Da muss der nicht auch noch den Client anpingen.

Die Uhrzeit zum synchronisieren würde ich damit nicht übertragen. Die Zeiten der Auswertungen werden bei der Datenübertragung selbst mitgesendet. Und Client und Server müssen ihre Zeit nicht über den monitor synchronisieren. Dazu gibt es bessere Wege und sollte auch standard sein mittlerweile.

Bei einer Sirenenalarmierung gäbe es also eine doppelte Ausgabe?
300:26250:1
330:1
Macht as Sinn?

Ja wie willst du das sonst machen? Der Sirenenton ist ein gültiger DTMF-Ton. Wenn also jemand das DTMF-Modul aktiviert hat, wird er so eine doppelte Anzeige bekommen. Was er damit im Endeffekt macht bleibt ja ihm überlassen. Richtig wäre es so auf jeden Fall.

Jagen wir da den Benutzernamen als ASCII durch? Oder bleiben wir dabei, dass wir Konsequent alle Textübertragungen Hex-Codieren?

Alles HEX-Codieren. Da sollte man in der Tat konsequent sein. Sonderzeichen kann es ja auch im Usernamen geben.

Würde ich nicht. Entweder gleich anonym (für Server die ohnehin nur im Intranet laufen) oder mir sauber verschlüsseltem Hash. Da könnte man über die Konfigurationsdatei regeln, wer sich wie anmelden darf. Es könnte eine "Trusted-Hosts"-Liste geben mit IP-Adressen die anonym reinkommen während maschinen von außen sich anmelden müssen.

Wäre ne Möglichkeit. Da der reine monitor-Server eh nur EIN Login hat und eine Benutzerverwaltung erst in der Datenbank geschieht. Es macht also Sinn zusätzlich zu dem einen Login auch eine Trusted-Host Liste anzulegen.

Gruß Joachim

[Buebchen]

Ich hätte da jetzt nochmal ne Frage zum TCP Protokoll. Ist es jetzt entschieden, wie z.B. eine FMS Zeile (CMD=310) aussieht? - Ich meine, welche Parameter in welcher Reihenfolge auftauchen sollen ?

Die Frage zielt dahin ab, daß ich den Socket-Server in einem ersten Stadium fertig habe. Jetzt würde ich gerne die interne Verbindung Auswerter -> Client-Socket testen. Da kann ich zwar auch jeden beliebigen Text ausgeben, aber da könnte ich dann auch direkt einen syntaktisch korrekten String generieren. Wäre sicherlich für alle Entwicker interessant, damit die auch starten können.

Nächste Frage, ob es schon Ideen / Vorschläge für den default TCP-Port gibt. Wie bei vielen anderen auch einen Port um die 9000 ? Ich nutze zum Testen 9400.

[nepomuck]

Ja wie willst du das sonst machen? Der Sirenenton ist ein gültiger DTMF-Ton. Wenn also jemand das DTMF-Modul aktiviert hat, wird er so eine doppelte Anzeige bekommen.

Soweit ich weiß, kommt DTFM sowieso NUR in Verbindung mit einer ZVEI-Alarmierung zum Einsatz. Also braucht es meines Erachtens kein eigenes DTFM-Modul, es genügt die DTFM-Erkennung als Teil des ZVEI-Moduls laufen zu lassen.

Nächste Frage, ob es schon Ideen / Vorschläge für den default TCP-Port gibt. Wie bei vielen anderen auch einen Port um die 9000 ? Ich nutze zum Testen 9400.

Es gibt da eine Liste im Internet unter
http://meineipadresse.de/html/ip-ports.php
oder auf anderen Seiten.

Da steht, dass 9400 von Samsung für Netzwerkscanner verwendet wird. Das sollte kaum zu Problemen führen.
Um allen Eventualitäten aus dem Weg zu gehen, kannst du einen der aufgelisteten Ports verwenden, der laut Liste nicht benutzt wird.
9322-9342 Unassigned
9347-9373 Unassigned
9375-9395 Unassigned
9398-9399 Unassigned
9402-9417 Unassigned

wie wär's mit 9333? Kann man sich leicht merken.

Andreas

[MiThoTyN]

Soweit ich weiß, kommt DTFM sowieso NUR in Verbindung mit einer ZVEI-Alarmierung zum Einsatz. Also braucht es meines Erachtens kein eigenes DTFM-Modul, es genügt die DTFM-Erkennung als Teil des ZVEI-Moduls laufen zu lassen.

Ja aber auch nur DANN, wenn der monitor ein reiner BOS-Auswerter werden soll. DANN kannste dir DTMF und andere Rufverfahren sparen. Soll der monitor weiterhin universell sein, müssen auch weitere Verfahren im Protokoll berücksichtigt werden. Das ist die entscheidende Frage.

wie wär's mit 9333? Kann man sich leicht merken.

Klingt gut.

Ich werd am Wochenende mal die Schnittstellenbeschreibung verfeinern. Dass wir da die genaue Syntax pro Zeile definiert haben.

Gruß Joachim

[nepomuck]

Hallo Monitor-Freunde,

In diesem Thread herrscht gerade gespenstische Stille. Ich hoffe nicht, dass die Bemühungen um die modularisierte Version 2.x zwischenzeitlich eingeschlafen sind.

@MiThoTyN
Wie ist der aktuelle Status des Backend-Protokolls? Davon hängt im Moment eigentlich alles ab.

@Buebchen
Wie sieht's mit dem Code-Redesign und dem Backend aus?

Andreas

[Buebchen]

Wie Du schon sagst: Ohne Protokolldefinition komme ich erstmal nicht so recht weiter. Zumindest will ich nicht in einem Luftgebilde testen. Lieber mit nem "echten" Client.

Aber ich denke, Joachim hat im Moment genug zu tun. Sonst hätte er das Protokoll bestimmt schon fertig.

[Edit]
Die Einteilung in einzelne Komponenten ist als Basis vorhanden. Im Moment habe ich FMS als Test sowohl unter Windows, als auch unter Linux laufen. Auch der Socketserver für die TCP Sockets ist als erste Version lauffähig. Wenn das Komm-Protokoll steht kann ich den Socketserver fertig machen. Danach wollte ich die anderen Module angehen. Das KommProtokoll hat Einfluss auf die Struktur der Daten, die die Module an die TCP Sockets weitergeben. Deswegen wollte ich das erst nach dem Protokoll weiterschreiben.

[Schewal]

Ich griegs unter Ubuntu einfach nicht zum laufen, ich verzweifel hier noch...

[nepomuck]

Ich griegs unter Ubuntu einfach nicht zum laufen, ich verzweifel hier noch...

Mit dem Problem bist du hier im falschen Thread. Die Lösung zum Ubuntu-Problem gibt's hier:

http://www.funkmeldesystem.de/foren/...4&postcount=12

Weitere Nachfragen bitte in diesem Thread.

Andreas

[Buebchen]

@MiThoTyN:

wie siehst mit dem Protokoll aus. Ich könnte neben der HEX Kodierung auch base64 anbieten. Würde bei FMS Text ein paar Bytes sparen.

@alle:
Welche Information gehören denn sinnvollerweise nun in ein FMS Datenpaket rein ?

310 : [Uhrzeit in Sekunden seit 01.01.1970] : [Servername] : [Kanalbezeichnung] : [FMSKennung] : [Status] : [Baustufe] : [Richtung] : [TKI] : [ggf: FMSText]

was habe ich denn jetzt eigentlich vergessen ?

[kfire]

Der Protokoll-Vorschlag sieht doch gut aus. Mehr Informatonen hat das Backend nicht, die weitere Verarbeitung geschieht im Frontend.

Ich finde mich nicht wirklich zurecht: Gibt es schon ein Backend zum testen ?

Ich hätte eher Interesse an der Pocsag-Auswertung..

Weiter so,
kfire

[Buebchen]

Generell findet man die tagesaktuelle Version im CVS / SVN. Natürlich nur was für die mutigen :-)

Wobei die Pocsag und ZVEI Anbindung noch nicht im TCP SocketServer drin ist. Ausserdem fehlt halt noch die Formatierung der Ausgabe. Ggf. werde ich da einfach nach persönlichem Empfinden eine Vorgabe machen. Muss man später vielleicht nochmal anpassen.

Die Module für ZVEI / POC512 und FMS sind in Bearbeitung (Entwickelt unter Ubuntu 6.06 LTS).

[jhr-online]

Ich schreib's mal hier, da es ja für alle interessant ist, die mitwirken möchten, aber im Moment hätte wohl eine PN an buebchen auch gereicht ;)
Mir wär's ganz lieb, wenn ihr beim Übertragen ins svn-Repo einen Kommentar fürs Log mitschicken könntet. Im Moment ist das ziemlich schnuppe, dass da nix steht, aber wenn du, buebchen, langsam das Gefühl bekommst, dass sich mal jemand anders einmischen kann, dann sollten wir (oder besser: solltest du) anfangen, Logeinträge mitzuschicken. Das macht es nachher erheblich einfacher, zu überblicken, was passiert...

So, vielen Dank für Ihre Aufmerksamkeit und viel Spaß noch bei der Arbeit ^^

jhr

[Buebchen]

Finden denn eigentlich schon checkout statt ? Ich fange dann vorsichtshalber mal an, ins Log zu schreiben.

Strukturbeschreibung starte ich aber wohl erst, wenn alle Module dem Grunde nach laufen. Doxygen-File ist schon erstellt - Fehlen halt noch die Kommentare dafür :-)

[Medic]

Hallo NG,

Ich beteilige mich jetzt auch mal. Bin gerade dabei nen Java-basierten Converter für FMS32-Pro und den Crusader zu schreiben und wollte fragen ob ich das hier gepostete KommProtokoll so nutzen kann oder gibts hier schon eine neue Fassung wo man besser sieht wie der Datenstrom aussieht?

Gruß

Medic