monitor 1.9.0 - aber richtig :)

[mdi]

Hallo Andreas,

Erst einmal vielen Dank für dein Engagement bei diesem Projekt.

gern; ich habe zur Zeit eben selber eine gehörige Portion Interesse daran und bin schon sehr angetan, auf welch breiter Grundlage man hier mitarbeiten kann :)!

Ich werde den neuen ZVEI-Code gleich unter Linux gehörig stressen.

Das ist gut; ich habe zur Zeit leider keine sinnvolle Möglichkeit, den "mal eben" unter Linux zu testen ohne große Aktionen machen zu müssen. Muss dringend mal wieder ein Multiboot-System einrichten ;). Feedback ist gerne genommen; meine C/C++-Programmierkünste sind ein wenig eingerostet in den letzten Jahren.

Die Geschichte mit dem Unterscheiden der beiden Fälle "unklare Auslösung" wäre vom Code her kein Problem - da sowieso unterschiedliche Stellen für die Ausgabe zuständig sind, bräuchte man nur wie Du schriebst entsprechend eine weitere Definition. Ich weiß allerdings nicht, auf welchen Argumenten die bisherige fußt!

Wie aufwändig ist es, andere Dualton-Dekodierungen einzubauen? Neben "Feueralarm" kommen in der Praxis vor allem "Testalarmierung" und "Katastrophenalarm" zum Einsatz. Es wäre schön, wenn der monitor diese Töne erkennt und korrekt auswertet.

Das ist ein wenig Aufwand aber wie geschrieben noch zu machen und alles andere als vom Tisch, wenngleich bei mir zur Zeit etwas geringer priorisiert (da ich nur die echten Fünftonfolgen brauche -> Betriebsfunk). Notwendig ist dafür die Überarbeitung der process_block()-Methode, da diese zur Zeit nur Einzelfrequenzen erkennen bzw. zurückmelden (return int Frequenz-Index) kann. Lösungsansätze habe ich schon im Kopf, allerdings wird der Eingriff etwas umfassender, weil dafür vermutlich auch die diversen Matrizen erweitert werden müssen und ich in dem Zuge gleich alle im ZVEI-Standard definierten Buchstaben (A, C, J, ...) mit einbauen wollte - vielleicht braucht sie einmal jemand (ich brauche nur das A, das ist prinzipiell schon da, wird aber noch nicht weiter behandelt). Für die Fälle der Sirenentöne müssten dann auch entsprechende Typ-Nummern vergeben und im Protokoll integriert werden (oder gibt es die schon?).

Noch nicht. Der unrsprüngliche Plan sah vor, SQL-Datenspeicerung über einen Client abzuwickeln -- der natürlich auf der selben Maschine laufen könnte.

Hm, dem SVN-Inhalt nach zu urteilen gibt es bereits eine MySQL-Storage-Engine, die entsprechendes für MySQL tun könnte. Wie ist da der Stand der Dinge?

Web-Funktionen liessen sich über ein reguläres PHP-Backend umsetzen.

Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).
Mir schwebte vor, dass die StoreResult()-Methode in der Lage wäre, eine noch zu schreibende HTTPStorage-Engine zu nutzen, um per HTTP GET (oder auch POST, das kann man ja beliebig ausweiten) die Telegramme/Tonfolgen/... an einen Webserver zu übergeben. Das hätte in meinen Augen den Vorteil, dass diese nicht nur über eine dauerhaft bestehende TCP-Verbindung (entsprechend FMS/Crusader/monitor-Socket) erhältlich wären sondern (in der monitor.xml konfigurierbar) per HTTP an ein PHP-Skript "gepusht" werden könnten, was sie dann wie der Anwender möchte weiterverarbeitet. Oder gibt es etwas ähnliches schon und ich habe Tomaten auf den Augen, weil ich bisher nur die ZVEI-Codes angeschaut habe?

Ich finde allerdings, dass der monitord-Dienst an sich so klein wie eben möglich gehalten werden sollte, so dass er auf lausigen alten PCs läuft, die ein völlig abgespecktes Linux von CD oder USB booten.

Ja, das wäre gut, keine Frage. Ist halt die Frage, ob die Einbindung von libcurl da schon ein Problem wäre oder ob nicht. Meine Tests eben (Windows only) verliefen sehr vielversprechend und würden genau meinen Wunsch von oben realisieren: Übergabe der Daten an einen Webserver zur Weiterverarbeitung mittels PHP wie auch immer gewünscht.

Viele Grüße
Martin