Hallo,
hm... dass der Dekoder eine "Signalqualität" erkennt, ist zur Zeit so gar nicht vorhanden. Wenn eine Fünftonfolge erkannt werden kann (bei jedem Wechsel des Tons gibt es ein neues Zeichen, Pausen dürfen zwischen den fünf Tönen nicht auftreten), wird diese ausgegeben. Das ist ja auch verhältnismäßig einfach zu realisieren. Wenn man eine etwas fehlertolerantere Lösung schreiben wollte, könnte man die Toleranz von Pausen in der Tonfolge einbauen (so dass z.B. von den 70ms Tonlänge grob 30ms unerkannt bleiben dürfen - generell keine schlechte Idee, so etwas sollte ich machen). Andersherum könnte man das dann vielleicht für die "Signalqualität" nutzen: Wenn weniger als 60% der eigentlichen Tonlänge eines der Töne erkannt wurden, ist das Signal "unklar"). Da stellt sich aber die Frage: Wird so etwas echt benötigt? Ja, ok, es wäre dann nur noch ein BOOL ;D.Zitat von nepomuck
Hm, schade. ;).
Nein; Spaß bei Seite: Grundsätzlich kann ich die Einstellung gut nachvollziehen. Für mich (aus Anwendersicht) wirkt die MySQL-Geschichte "fetter" als die HTTP-Idee. Im Monitor integriert (als Storage-Engine) hätte es den Vorteil, dass man keinen direkten Zugriff auf eine MySQL-Datenbank braucht um Daten wegzuschreiben, sondern die Daten per HTTP POST an einen Webserver liefern kann (nicht jeder Hoster bietet MySQL-Zugriff von außen an). Auch bräuchte man keinen Client, der über Netz/Sockets dauerhaft connecten muss, sondern hätte entsprechend keinerlei Ports zu öffnen und würde mit dem Monitor keinen "Server" sondern einen "HTTP-Client" aufsetzen. Das wäre auch für Paketfilter/Firewalls einfacher zu händeln. Aber das als Client-Modul (das heißt, es läuft als eigenes Programm im eigenen Prozess und verbindet sich zum Monitor über die Sockets?) zu bauen, sollte ja grundsätzlich nicht problematisch sein und hätte wiederum den Vorteil, dass keine weitere Library für den eigentlichen monitord benötigt wird.
Hier würde ich die Weiterführung des obigen Gedankens vorschlagen: Das MySQL-Modul als Client-Modul bauen und für die History SQLite nutzen (wobei das Datenbank-Design und die SQL-Queries sicher ähnlich wenn nicht gleich sind). Damit könnte der Monitor "von Hause aus" immerhin eine SQL-fähige Datenbank auf Dateibasis mit den aufgefangenen Alarmierungen füttern, die sehr einfach handhab- und auch anderweitig nutzbar ist. Auch ist kein MySQL-Server dafür notwendig, den Monitor einschließlich der History-Funktion zu nutzen. Wer dann MySQL-Unterstützung braucht, kann das MySQL-Modul einbinden und die Daten in einer eigenen Datenbank sonstwo sammeln.
Ja, ich bin begeistert von SQLite, entschuldigung ;).
Das finde ich sehr gut. Die HTTP-Push-Sache ist bereits in der Mache (basierend auf curl, ich brauche das Feature! ;)).
Da wir gerade bei der Zukunft sind: Ich habe mir gestern Abend das SVN einmal genauer angeschaut und gesehen, dass in /trunk gar nicht entwickelt wird. Stattdessen gibt es mehrere 2.x-Branches, in denen sich Dinge tun, wobei es den Eindruck macht, als würden die Branches immer wieder voneinander abstammen und "abbrechen", sobald ein neuer Branch gebaut wurde.
Da es ja auch bei der Nutzung von SVN gewisse Standards gibt, möchte ich hiermit vorschlagen, dass /trunk nach /branches/1.9.0 gemoved wird (als Archiv, damit es nicht wegkommt, quasi). Entsprechend ist /trunk dann leer und kann mit den Daten des aktuellen Branches (/branches/2.1.1-mergeWinLin) gefüllt werden, wobei dann hoffentlich keine wichtigen Änderungen aus den anderen 2er-Branches verloren gehen (gut, man könnte nochmal diff-en und nötigenfalls mergen). Damit wäre im /trunk die aktuelle Version 2.0 (ohne die 1en und das mergeWinLin am Ende - brechen wir es auf das eigentliche Ziel herunter), die dann als Feature-Set hat: Plattformunabhängigkeit, Funktionalität (Erkennung, Ausgabe über die drei Sockets in drei Formaten Crusader, FMS32, monitord).
Einen Branch/Branches für die 2.1 oder 2.2 (HTTP-Engine, MySQL-Engine, was auch immer) anzulegen, wäre dann sicher sinnvoll, sobald ein neues Feature implementiert werden soll. Ich möchte auch die Nutzung von Tags anregen, mit denen man ja ganz famos Revisionen im SVN Versionsnummern von Software aufklatschen kann, so dass nach einer Umstrukturierung wie vorgeschlagen direkt der Inhalt von /trunk in /tags/2.0-291107 als lauffähige Version markiert werden könnte und sollte, um lauffähigen Code schnell und einfach auscheckbar zu haben.
Auch möchte ich anregen, dass die tolle Entwicklung des 2er monitor ein bisschen mehr an die Öffentlichkeit kommt. Ich würde gern hier im Forum diesen Thread schließen (er wird doch arg unübersichtlich) und drei neue anfangen:
a) Der Monitor 1.9 (falls existent)
b) Der Monitor 2.0: Aktueller Stand der Entwicklung
c) Der Monitor 2.x: Ausblick
Dabei sollte b) enthalten: Verweise auf die Sourcen/das SVN, die genutzten Entwicklungsumgebungen unter Windows (MSYS/MinGW) und Linux, Protokolle, kompilierte Binaries zum Anschauen als naja, nicht nightly aber "aktueller Stand der Dinge"-Build, Informationen zu den Frontends (die ich mir ehrlich gesagt leider noch gar nicht weiter angeschaut habe).
c) sollte die Vorschläge/Planung für die nächste Version (MySQL-Storage, History-Funktion, HTTP-Push-Mechanismus) enthalten.
Eventuell sollte man auch einen Extra-Thread für die Monitor-Frontends anlegen, in denen diese kurz vorgestellt und ihre Benutzung erklärt werden. Sicherlich könnte man diese aber auch in b) mit integrieren.
Puuh... wieder viel geschrieben und "neue Ideen" eingebracht. Ich hoffe, ich verprelle damit niemanden, aber ich bin echt begeistert vom "neuen Monitor" und finde es ehrlich schade, dass der aktuelle Stand hier doch irgendwie ein Schattendasein fristet :7.
@Buebchen: Die Sache mit dem Überarbeiten der Storage-/Display-Module und dem "Übersehen" unbekannter Parameter finde ich sehr sinnvoll.
Allerdings fiel mir dazu ein: Warum sollte man nicht die Nachrichten, die von den Auswertern kommen, in eigene Objekte kapseln? Damit könnten die Nachrichtenpakete vom Typ "ZVEImsg", "POCmsg" und "FMSmsg" sein, auch wenn sie dann vielleicht nur Attribute enthalten (Datencontainer eben). Damit würde es die Ausgabe-Methoden geben "Output(ZVEImsg out)", "Output(POCmsg out)" und "Output(FMSmsg out)". Das würde auch ein ähnliches Verhalten abbilden wie Du schriebst: Zusätzliche Attribute der Datenobjekte würden zwar bestehen aber nicht ausgegeben (weil die Methode das Feld nicht kennt und eben nicht darauf zugreift - aus die Maus), ohne dass große Eingriffe in den Code (speziell die Definition der Ausgabemethoden) notwendig wären.
Viele Grüße
Martin
Zitieren