monitor 1.9.0 - aber richtig :)

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

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

[DocSteel]

Hallo

Es wäre schön wenn mal einer der Entwickler im ersten Beitrag dieses Themas einen aktuellen Link zu einem funktionierenden svn posten könnte (bzw. den vorhandenen anpassen)

Bei jhr-online.de/monitor und bei monitord.de kommen beim Versuch dort svn's auszuchecken Fehlermeldungen bzw. es gibt die Domain im ersten Fall gar nicht mehr.

Das macht es Interssierten schwer an die Quellen zu kommen. Trotzdem ein tolles Projekt.

Gruß

Doc - Der sich über einen Link zu den aktuellen Dev-Quellen freuen würde (gerne auch Vers. 1.9, muss ja nicht 2.0 Beta sein, hauptsache es läuft)

[Buebchen]

Aktuelles SVN:

http://svn.monitord.de

-> wichtig ist das http Protokoll (für WebDAV)

[pocfreak]

bekommt jemand dieses

http://www.kb9ukd.com/digital/pocsag12.wav

signal dekodiert?

wenn ja, mit welchem eingangspegel??

das signal lässt sich bei mir unter windows und linux (wine) mit PDW dekodieren.

aber nicht mit monitor.

ich wäre für hilfe echt dankbar!!

[funkwart]

Hallo Forum,
hallo Entwickler,

gibt es eigentlich irgendwelche Entwicklungen bezüglich der Dekodierung von POCSAG 1200 Baud? Das letzte Posting, das ich dazu gefunden habe, hatte im Prinzip zum Inhalt: Dekodierroutine geändert, monitord dekodiert 1k2 deutlich schlechter als vorher.
Es ist doch schade, dass ein so universell und fortschrittlich aufgebautes Programm nicht genutzt werden kann, weil eine Komponente nicht tut, was sie soll.
Ich habe leider weder von C++ noch von POCSAG-Dekodierung genug Ahnung, um mich selbst an den Code zu setzen.
Könnte nicht einer der Programmierer die Dekodierroutine vom alten 1.8.1 einbauen und wie bei fms per Tag in der XML-Datei zur Auswahl stellen? Bitte, habt doch ein Herz für die User, die so fürchterlich auf dem Schlauch stehen aktuell!

Vielen Dank und bested Grüße,
Funkwart

[jhr-online]

Bin ich ebenfalls dabei.

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.

Für dich gilt, wie für alle anderen, die mitmachen wollen:

• Schick mir eine PN mit einem Wunschpasswort, damit ich Schreibzugriff auf das Repo einrichten kann.
• Registrier dich im BugTrackingSystem und nenn mir in der PN deinen Namen, damit ich dich da zum Developer machen kann (das erlaubt auch da Änderungen und so)
• Registrier dich in der Mailingliste
• Komm ab und zu mal im Channel #fms-monitor auf irc.freenode.net vorbei

Wenn alle einverstanden sind, machen wir mal einen Termin ab, an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

jhr

PS: Danke! :)

[ManuelW]

Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...

Ob Montag um die Zeit klappt weiss ich noch nicht, da wollt ich an nem
Bau-Seminar in SecondLife teil nehmen :P

[jhr-online]

Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...

Es ist nur ein Angebot. Wenn wir die nicht brauchen, mache ich sie wieder aus. Ist ja kein Problem. Ich hab mich nur sehr an den Luxus gewöhnt :)

Was den Termin betrifft: Das war auch nur ein Vorschlag. Scheint wohl nix zu werden, wenn sich zwei melden, weil sie nicht da sind. Andere Vorschläge?

jhr

[Buebchen]

Also, ich war im Osterstreß (der jetzt erstmal fließend in dn Kommunions-Streß übergeht). Würde aber versuchen, dabei zu sein. Am liebsten frühestens um 20:00 Uhr. Besser sogar 21:00 Uhr :-)

Mailingliste würde ich mal abwarten. Ggf. für die Entwickler unter sich. Ansonsten finde ich ist das Forum einfacher und erreicht mehr Leser.

[Max K.]

Es ist nur ein Angebot. Wenn wir die nicht brauchen, mache ich sie wieder aus. Ist ja kein Problem. Ich hab mich nur sehr an den Luxus gewöhnt :)

Hi,

finds ersma toll wie du dich engagierst!

Allerdings fände ich auch toll, wenn dieses Forum hier weiter als hauptsächliche Kommunikationsplattform genutzt werden würde, weil dabei evtl. auch weniger aktive User, die nicht in der mailingliste angemeldet sind, von den Infos u. Diskussionen profitieren können..

Mfg.
Max

[nepomuck]

an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

Da bin ich in der "Offline-Pampa"
Wäre schön, wenn einer das Chat-Protokoll redigiert und den Report hier postet.

Ich werde einfach mal meine Ideen zu einer Wunschliste zusammenschreiben und hier oder in das Code-System einstellen. Ich habe da ein paar Ideen zu Front- und Backends sowie Kommunikationsmodulen, damit der Monitor netzwerkfähig wird. Frond- und Backend könnten dann auf getrennten PCs arbeiten, wie bei FMS Pro.

Andreas