monitor 1.9.0 - aber richtig :)

[jhr-online]

So Leute,
im Moment sieht es ja so aus, als würde doch der ein oder andere am Projekt arbeiten. Daher hab ich mir überlegt, das mal in etwas geordnete Bahnen zu lenken und uns eine vernünftige Basis zur Verfügung zu stellen. Für diese Zwecke stelle ich mal (ganz uneigennützig ;)) ein bisschen Platz auf meinem Server zur Verfügung und hoffe, dass es dann etwas flüssiger läuft.
Folgende Möglichkeiten habe ich neu geschaffen:

• Der Monitor und das Frontend sind nun in einem svn-Repository vorhanden. Lesenden Zugriff hat jeder, schreiben kann jeder, der mir eine PN oder E-Mail schickt. Dann trage ich ihn ein. Zugriff:
  monitor:

  svn checkout svn://jhr-online.de/monitor

  Frontend:

  svn checkout svn://jhr-online.de/monitor-php

  Wer sich die Repos anschauen will und vielleicht sogar per RSS verfolgen, kann das unter http://svn.jhr-online.de/
• Für unsere Entwickler und alle Interessierten habe ich eine Mailingliste erstellt: monitor@lists.jhr-online.de. Eintragen kann man sich unter http://lists.jhr-online.de/listinfo/monitor
• Des weiteren uns soll ein vernünftiges BugTrackingSystem das Sammeln von Fehlern und Wünschen erleichtern. Ich habe mir mal ein schönes ausgesucht und eingerichtet. Da "monitor" das Standardprojekt ist, erreicht man es zügig unter http://bts.jhr-online.de

Oftmals ist es üblich, wenn bereits eine Version 1 öffentlich ist, die Entwicklung zur Version 2 einfach 1.9 zu nennen. Das hab ich jetzt auch mal getan (auch um anzudeuten, dass ich mir eine stablie Version 2 wünsche). D.h. in den Repos liegen jetzt (sowohl vom monitor, als auch vom Frontend) die Version 1.9.0 und jetzt seid ihr dran: entwickelt fleißig! :-)
Ach ja: wer sich im BTS als User registriert und mich anschreibt wegen svn-Schreibrechten, der wird auch da als Developer eingetragen.

Was meint ihr? Wird das so was?

jhr

[jhr-online]

Man, wie doof. Jetzt hab ich das wichtigste vergessen...

In dieser Version, die jetzt im Repo ist, befindet sich vom Frontend die Version, die im Komplettpaket von Manuel vorhanden ist. Am Besten wär's, wenn du, Manuel, einmal kurz rüberschauen könntest und evtl. Änderungen direkt übertragen könntest. Vom monitor selber ist eine Version drin, die es so bisher nicht gab. Die beiden Änderungen von Paneologe (in demod_zvei.c und fms.c) sind drin (das waren zwei zusätzliche Zeilen insgesamt) und eine Änderung ist drin, die ein Freund von mir neulich fertig gemacht hat: Die SQL-Zugangsdaten stehen jetzt nicht mehr in der mon_mysql.c, sondern in der .monrc und werden beim Programmstart eingelesen. Die Daten müssen in folgendem Format rein:

SQL_HOST localhost
SQL_DB dbname
SQL_USER username
SQL_PASS passwort
SQL_PORT 3306

Bei mir scheint's zu laufen :)

jhr

[Paneologe]

Hi,
klasse Idee.. nur ein Problem:
# svn checkout svn://jhr-online.de/monitor
svn: Can't connect to host 'jhr-online.de': Connection refused

Gruß Paneologe

[jhr-online]

Jap, ich weiß. Hab den Hinweis bekommen, dass das Repo unsinnig erstellt war. Das muss ich gleich eben korrigieren, dann ist es wieder online... :) Aber erst muss der Mailserver gewartet werden, also bitte ein wenig Geduld noch :)

jhr

[jhr-online]

Kaum will man was richtig machen, wird es anstengend... :)

Das svn sollte erreichbar sein, allerdings ist jetzt alles in einem.

svn://jhr-online.de/monitor

Hoffentlich klappt das alles nun. Falls schon jemand versucht haben sollte, sich in die Mailingliste einzutragen, möge er das bitte wiederholen. Mein Mailserver hat sich heute Mittag irgendwie verabschiedet... :(
Derzeit bin ich gut im IRC zu erreichen. Wer also richtig mitmischen will ;), kann das tun auf irc.freenode.net im channel #fms-monitor. Ansonsten bleiben die o.g. Optionen erhalten. Insbesondere auf das BTS weise ich noch mal hin.
@Paneologe: Für dich hab ich schon einen Bug drin; du solltest dich da mal drum kümmern :)

jhr

[SirFS]

Klasse Sache! Habs mal angepinnt.

[jhr-online]

Vielleicht könnten sich unsere Entwickler mal kurz zu Wort melden? Buebchen und ManuelW und so? Wäre gut, wenn wir deren Meinung auch hätten, die müssen mit der neuen, von mir eingerichteten und vorgeschlagen Situation ja arbeiten. Ist das okay so? Denn, wenn nicht, dann lassen wir den Spaß einfach!

Diskussionen/Anregungen/Meinungen gerne hier oder auf der o.g. Mailingliste oder, wenn's eine Plauderrunde werden soll, auch gerne in #fms-monitor auf irc.freenode.net!

jhr

[nepomuck]

Hallo zusammen,

Leider bin ich ein hundsmiserabler Programmierer und werde daher die Finger vom Code lassen. Ich hätte aber ein paar Vorschläge für neue Features der Version 1.9 und würde mich sehr freuen, wenn sich diese umsetzen ließen.

Ich benutze Monitor eigentlich nur für ZVEI-Alarmierungen, da in unserem Landkreis kein FMS verwendet wird. Im ZVEI-Modul fehlen mir ein paar Optionen.

1. Flexibles REC-Kommando
Bisher legt REC_TIME starr fest, wie lange Monitor den Funk nach einer Alarmierung mitschneidet. Könnte man hier das [@REC]-Kommando so erweitern, dass es einen Parameter zur Aufnahmedauer übergibt?
Beispiel:
.monrc
ZVNAME 00001 [@REC] ...
ZVNAME 00002 [@REC500] ...
Löst die Schleife 00001 aus, nimmt Monitor für die unter REC_TIME festgelegte Zeit auf. Löst hingegen 00002 aus, nimmt Monitor für 500 Sekunden auf. Lösen während einer Alarmierung mehrere Schleifen mit @REC aus, zählt die längste Zeitangabe.

2. Mehrere ZVEI-Aktionen
Bislang führt Monitor nur die erste passende Aktion aus, also:
ZVNAME 1* [exec "~/1.sh"]
ZVNAME 11111 [exec "~/2.sh"]
führt immer nur 1.sh aus, auch wenn 11111 alarmiert wird.

ich hätte gerne, dass folgendes funktioniert:
ZVNAME 26* [exec "~/1.sh"]
ZVNAME 26250M [exec "~/melder.sh"]
ZVNAME 26250S [exec "~/sirene.sh"]
Bei einer Alarmierung von 26250 mit Sirene werden 1.sh UND sirene.sh gestartet, bei einer Alarmierung von 26250 ohne Sirene 1.sh und melder.sh und bei 26123 nur 1.sh

3. Make ohne X
Die 1.8.1-Sourcen haben haufenweise dependencies. Selbst wenn ich monitor alleine ohne X betreiben will, bricht make ab, wenn die X-dev-libs fehlen.
Schön wären hier auch Binary-Pakete (RPM, DEB) des "nackten" Monitor-Programms für gängige Distributionen wie Ubuntu oder Fedora Core.

Trennung Backend-Frontend
Nur so eine Idee: Eigentlich könnte man den Monitor (oder eine Sub-Version davon) so weit abspecken, dass es gar keine GUI im Backend-Modul mehr gibt und das Programm im Hintergrund als Daemon lauft. Alle Meldungen, die es dekodiert, schreibt die Software einfach in ein Interrupt-Device, wie /dev/input/monitor0R. Darauf setzen dann ein oder mehrere wie auch immer geartete Fontends auf (X, GTK, MySQL) oder die Anwender schreiben eigene Perl-Skripte, die nur von /dev/input/monitor0R lesen und die Strings direkt weiterverwerten.

Bei dem o.g. Beispiel würde Monitor auf /dev/input/monitor0L bei einer Alarmierung einfach nur "ZVEI:26250S" ausgeben und das getrennte Frontend-Programm kümmert sich dann um die Darstellung oder ein eigenes Skript interpretiert diese Information.

viele Grüße,
Andreas

[jhr-online]

Schade, dass du nicht selber Hand anlegen willst, aber ich akzeptiere das natürlich (widerwillig)... ;)

Du könntest uns einen Gefallen tun und deine Anregungen ins BugTrackingSystem [1] einfügen*. Wenn ich das richtig sehe, ist Punkt 1 eine Wunschfunktion und die Punkte 2 und 3 sind Bugs. Trag das ruhig so ein - ist nicht schwer zu bedienen und man muss sich zum Eintragen nicht mal registrieren.

Deine gewünschte Trennung von Backend und Frontend wäre ein sehr großer Eingriff. Derzeit ist die Überlegung, dass Version 1.9.x aus dem jetzigen Code besteht und Bugfixes, sowie kleine neue Features enthalten soll. Für große Änderungen ist ein ordentliches Umstrukturieren des Codes angemessen, was auf eine Version 2 hinauslaufen würde. In der Theorie ist die auch geplant, aber es liegt natürlich ganz am Engagement der Entwickler, ob es soweit kommt. Das wäre nämlich richtig viel Arbeit.

jhr

[1] http://bts.jhr-online.de/?do=newtask&project=2

* Das ist deswegen von Vorteil, weil da Kontaktmöglichkeiten zu den Entwicklern gespeichert sind/sein sollen und wir die einzelnen Aufgaben (Bugs/Wunschfunktionen) da zuweisen können. Das gibt dem ganzen etwas Struktur und man kann sich absprechen, wer was übernimmt.

[Buebchen]

Vielleicht könnten sich unsere Entwickler mal kurz zu Wort melden? Buebchen und ManuelW und so? Wäre gut, wenn wir deren Meinung auch hätten, die müssen mit der neuen, von mir eingerichteten und vorgeschlagen Situation ja arbeiten. Ist das okay so? Denn, wenn nicht, dann lassen wir den Spaß einfach!

Diskussionen/Anregungen/Meinungen gerne hier oder auf der o.g. Mailingliste oder, wenn's eine Plauderrunde werden soll, auch gerne in #monitor auf irc.freenode.net!

jhr

Hab' mal nen checkout gemacht. Könntest Du mal einen branch "windows" anlegen ? Irgendwie muss ich mir nochmal tags und trunks im svn anschauen. Der trunk war die aktuelle version und ein tag war ein Milestone - Richtig ?

Soll im branch 2.0 die Renovierung erfolgen - so versteht ich den BugTrack Eintrag. Dann könnte ggf. später der Windows Ordner entfallen. Der ist stückweise schon modularisiert (wobei ich nicht am Reissbrett angefangen hatte) und sehr auf MFC / MS Visual C ausgerichtet (Bsp: CString).

[jhr-online]

Hab' mal nen checkout gemacht. Könntest Du mal einen branch "windows" anlegen ?

Versteh ich nicht, was soll da drin sein?

Irgendwie muss ich mir nochmal tags und trunks im svn anschauen. Der trunk war die aktuelle version und ein tag war ein Milestone - Richtig ?

In trunk ist das, was derzeit entwickelt wird, also das, was ich derzeit 1.9.0 nenne und auf dem Weg zu 1.9.1 ist. Unter den Branches finden sich zusätzliche Entwicklungszweige, die größere Änderungen beinhalten sollen. In diesem Fall (2.0) soll der Code ordentlich um strukturiert werden; in welcher Art auch immer (C++ wohl vermutlich nicht, aber zumindest ordentlich modularisiertes C). In den Tags liegen dann einfach die erreichten Milestones, also als nächstes 1.9.1.

Es ist spät, hoffentlich hab ich mich jetzt nicht verhaspelt... :)

jhr

[jhr-online]

Channeländerung: auf irc.freenode.net (wie gehabt) Channel #fms-monitor

jhr

[nepomuck]

Deine gewünschte Trennung von Backend und Frontend wäre ein sehr großer Eingriff. Derzeit ist die Überlegung, dass Version 1.9.x aus dem jetzigen Code besteht und Bugfixes, sowie kleine neue Features enthalten soll.

Ich halte es für den falschen Ansatz, noch mehr Features in da monolithische Programm einzubauen. Die aktuelle Version lässt sich doch jetzt schon kaum auf zeitgemäßen Plattformen compilieren, ohne nicht mindestens ein dutzen "dev" Libraries zu installieren.

Von der Zuverlässigkeit her ist das existierende Backend klasse. Die Dekodierung läuft fehlerfrei, besser als bei kommerziellen Produkten. Was hier im Forum immer wieder bemängelt wird, ist die Auswertung.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Der Output läuft in ein gewöhnliches Char-Device und jeder X-beliebige User-Mode-Prozess kann lesend darauf zugreifen. Die Entwickler der Forntends müssen sich dann gar nicht mehr mit dem alten Code herumschlagen.

Im Backend muss man sich lediglich auf ein Protokoll einigen, welches die Dekodierung auf das Char-Device schreibt wie: "Channel 0:ZVEI:12345:M" oder "Channel 1:FMS:kennung:Status 0". Die eigentliche Auswertung kann dann sogar ein simples Shell- oder Perl-Skript übernehmen.

Andreas

[SirFS]

Ich halte es für den falschen Ansatz, noch mehr Features in da monolithische Programm einzubauen. Die aktuelle Version lässt sich doch jetzt schon kaum auf zeitgemäßen Plattformen compilieren, ohne nicht mindestens ein dutzen "dev" Libraries zu installieren.

Von der Zuverlässigkeit her ist das existierende Backend klasse. Die Dekodierung läuft fehlerfrei, besser als bei kommerziellen Produkten. Was hier im Forum immer wieder bemängelt wird, ist die Auswertung.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Der Output läuft in ein gewöhnliches Char-Device und jeder X-beliebige User-Mode-Prozess kann lesend darauf zugreifen. Die Entwickler der Forntends müssen sich dann gar nicht mehr mit dem alten Code herumschlagen.

Im Backend muss man sich lediglich auf ein Protokoll einigen, welches die Dekodierung auf das Char-Device schreibt wie: "Channel 0:ZVEI:12345:M" oder "Channel 1:FMS:kennung:Status 0". Die eigentliche Auswertung kann dann sogar ein simples Shell- oder Perl-Skript übernehmen.

Andreas

Also ich muss sagen, dem stimme ich zu 100% zu.
Wenn ich mehr Zeit hätte, würde ich mich da ja mal mit beschäftigen...

[ManuelW]

Ich finde auch das klingt sehr vernünftig.
Vor allem die Konfiguration sollte einfacher werden, ich habe damals ewig
gebraucht und gebastelt bis es dann endlich mal so lief wie es sollte...