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