monitor 1.9.0 - aber richtig :)

Hallo zusammen,

Es freut mich zu sehen, wie das Projekt wächst und gedeiht. Ich möchte mich daher so langsam an die nächste Version der Monitor-Live-CD "Bosix" machen.

@Buebchen
Ich müsste wissen, welche Dependencies die fertig kompilierte Version des monitord hat. Dann könnte ich eine Super-Kompakte Linux-Distri bauen ( <64 MB) die vom USB-Stick ohne X bootet und direkt den Server startet. (Bosix-Server)
Dazu gäbe es dann eine "full featured" Live-CD mit monitord, Gnome oder KDE und Frontend(s).

Andreas

Zitat:

---

Zitat von Dove

Einer seits das anderer seits Auslösung = AusbEsudg
Also da ist das Aus (ok) dann lö versteh ich wenn dort das zeichen vorher sowie 1-2 dannach flöten gehen
nur dann bleibt da noch nen udg :D


PS.: ich hab mir nur deine convert.h kopiert.

---

ok. Ich schäm mich ja schon. Aber der Fehler war mal so richtig dämlich, daß ich den nicht direkt gesehen habe:

Code:

---

inline int convertNibbleToInt(const char& c)
 {
        int x ;
        if (c >='0' && c<='9')
        {
                x=c-'0' ;
        } else if (c >='A' && c<='F')
        {
                <b> x=c-'A'+10 ;</b>
        } else if (c >='a' && c<='f')
        {
                <b> x=c-'a'+10 ; </b>
        } else {
                throw BadConversion("convertNibbleToInt");
        }
        return x ;
 }

---

Der Fehler war bei den Zeichen A-F. Das +10 am Ende fehlte (ja ja ja ja ja .... war bestimmt schon spät )

Buebchen dürfte ich leise erfragen ob die alamierungs text (Bzw FMS-Texte) schon mit geschickt werden ?
Wenn ja, wie kommt das an ?
Wenn Nein, wann planst du es ein zu bauen ?

FMS Text sollte dabei sein.... wie schaut es aus mit unterdrückung doppelter Alarme?

FMS Text ist noch nicht implementiert. Wird aber als eins der nächsten Themen kommen. Ich wollte jetzt erstmal Pocsag mit 1200 Baud machen. Das geht im Moment einfach überhaupt nicht. Warum weiss ich aber noch nicht.

Ich denke, FMS Text ist in den nächsten 1-2 Wochen drin. Wird dann als weiteres Feld hinten an die FMS-Zeile drangehängt. Als Text mit HexToString konvertiert.

@Florian Feuerbaer:
Die Unterdrückung doppelter Meldungen - wie auch alle anderen Filteroptionen - sind m.E. Aufgabe des Frontends.

Zitat:

---

Zitat von nepomuck

@Buebchen
Ich müsste wissen, welche Dependencies die fertig kompilierte Version des monitord hat. Dann könnte ich eine Super-Kompakte Linux-Distri bauen ( <64 MB) die vom USB-Stick ohne X bootet und direkt den Server startet. (Bosix-Server)
Dazu gäbe es dann eine "full featured" Live-CD mit monitord, Gnome oder KDE und Frontend(s).

Andreas

---

Es wird erstmal nicht mehr als beim klassischen monitor sein. Eher weniger, da ich definitiv weder ncurses, noch X nutze.

Da ich den Fehler im POC1200 Modul noch nicht finden konnte habe ich den FMSText vorgezogen. FMS Text sollte jetzt übertragen werden.

Update ist im svn. Muss ich unter linux aber noch prüfen ...

[edit]
kompiliert auch unter linux.

Also auswerten (convert String To Hex) geht immer nochj nicht so richtig.
Aus Sosi macht er Sesi und unklare Auslösung: udabare AusbEsudg

Aber der FMS-Text geht schon 1000 pro :D

Das ist echt subba

ich habe grade mal nen bissl geforscht.

Also da rennt irgendwas mit den 10 noch falsch. Ob +10 oder -10 sind ka :D

und wo auch ka :D

Also bei meinem Test war es danach ok.

Wichtig: Du musst deine convert.h erneuern. Der monitord hatte den Fehler "nur" bei der Auswertung von Benutzername und Passwort.

Der Fehler trat konstant bei allen Zeichen mit "A" bis "F" auf. Das "a" wurde zu Null berechnet. Das "F" zu fünf. Deswegen trifft es eben nicht nur die Sonderzeichen und Umlaute sondern alle ASCII Zahlen mit nen Buchstaben im Hexcode.

Ich habe einige Zeichenketten umkonvertiert und wieder zurück. Versuch' einmal ein "make clean" und bau dein Projekt nochmal neu.

hab ich heute nach dem checkout getan. kommen irgendwie nur komische konstruke bei raus.

hmm, ok.

Nur zur Sicherheit ein kleiner Test:

Code:

---

        std::string ergebnis ;
        std::string hex="6f6e" ;

        convertHexToString(hex,ergebnis) ;

---

... das ergebnis sollte "on" sein. Das wäre richtig. Wenn du "ed" erhälst ist es noch die alte convert.h.

lol ich bin nen depp.

Hab SVN updated und neu kompiliert.
So den client habsch sicherlich nit neu gemacht ...

Gebt mir nen Orden ^^

Zitat:

---

Zitat von Dove

lol ich bin nen depp.

Gebt mir nen Orden ^^

---

Nix da.. geb gas und mach fertisch, dann schauen wir mal ;)

ohhhh :(

bei rennt es :D und bei dir ?! ^^

@Buebchen.

die badConverion Exception die beim decoden geworfen wird tritt doch dann auf, wenn er auf, wenn er zeichen findet die (<0&&>9)||(<A&&>F)||(<a&&>f)
Nur das das doch rein Theoretisch gar nicht passieren, wenn ich daten von dir bekomme (monitord)

Ich versteh nicht warum er dort ständig rein brät.

Wird vielleicht wird der Doppelpunkt als Trennzeichen noch mitübergeben ? Sonst lass dir die Zeichenkette vorher mal ausgeben. Aber wie du schon schreibst. Die Exeception wird nur bei Zeichen geworfen die nicht [0..9], [a..f] oder [A..F] sind.

also die Exception kommt bei sowas hier:
Error: &TRN03195967E00847EB5 -EOL- æ2ÔTôÂÒ

Error musste dir davor wegdenken, das ist noch ausgabe vorher.
Error: 67 73 f0 7d -EOL- RRô´ÄRõ¤'&öæ2ââââÔTôÂÒ

sowas kommt da auch bei raus bzw rein.

Entweder bekomm ich das so vom daemon (was ich nicht glaube) oder ich hab irgendwo noch schrott in den vars stehen.

Aha. Der Fehler liegt im monitord. Der Text ist ja nicht verschlüsselt, sondern klartext. Seltsam. Habe ich bestimmt wieder mal beim Testen vergessen 'was zurückzustellen.

Die zweite Aussendung ist vom Fahrzeug aus. Die sollten eigentlich überhaupt nicht auftauchen.

Werde das heute abend mal prüfen ...

Die "Schrott am Ende" liegt vermutlich daran, daß die Zeichenkettenvariable nicht bei jedem Aufruf "genullt" wird.

ja hab ich mir eigendlich auch gedacht, aber da ich die laufzeit var (mein vector mit dem jeweiligen param) erst in der While erstelle kanns daran nicht liegen.

Und der Buffer wird am ende der while auf buffer[0] = '\0'; gesetzt.

Nimm lieber ein

Code:

---

memset(buffer,0,_BUFFERGROESSE_) ;

---

-EDIT1-
Ich habe den -EOF- jetzt entfernt und die Datentelegramme Fahrzeug->Leitstelle sollten nun auch angezeigt werden (Ohne Leerzeichen zwischen den Zahlen).

Frage dazu:
kann mal jemand prüfen, ob die Reihenfolge der Zeichen stimmt bei Telegrammen Fzg->Leitstelle.

Damit ich die Daten aus dem BOSTool korrekt empfangen kann mußte ich die Nibbles (4Bit Werde=Einzelne Ziffern) paarweise tauschen.

So wird 12345678 tatsächlich als 21436587 bei mir empfangen.
-EDIT2-

@Dove:
Wenn Du std::string nutzt kannst du auch die .Empty Methode nutzen.

Falls ihr es noch nicht in der aktuellen Revision gesehen habt; der monitord kann jetzt auch fms32pro und crusader sprechen.
Ich habe die funktionen unter der "Aufsicht" und tatkräftiger Mithilfe von buebchen heute implementiert.
Damit die Ports aktiv werden bitte in der monitord.xml die entsprechenden Auskommentierungszeichen entfernen.
Ein Passwort wird zur zeit nicht benötigt.
Also wer lust und zeit hat, bitte testen.

Gruß

Medic

wow!
das ist ja klasse!

wie kann ich das denn nun ausprobieren mit dem crusader?
wenn ich indem verzeichniss monitord ein "make" mache kommt dies:

macleod@MacLeod:~/monitor/monitor/monitor/branches/2.1/monitord$ make
gcc -c -c -D _DEBUG -O2 -I../jthread-1.2.1/src/ -I../xmlParser -I../simpleopt -Wno-deprecated MonitorModules.cpp -o MonitorModules.o
gcc -c -c -D _DEBUG -O2 -I../jthread-1.2.1/src/ -I../xmlParser -I../simpleopt -Wno-deprecated MonitorModuleFMS.cpp -o MonitorModuleFMS.o
MonitorModuleFMS.cpp: In member function ‘void MonitorModuleFMS::DisplayResult()’:
MonitorModuleFMS.cpp:778: error: ‘_strdate’ was not declared in this scope
MonitorModuleFMS.cpp:779: error: ‘_strtime’ was not declared in this scope
MonitorModuleFMS.cpp: In member function ‘void MonitorModuleFMS::DisplayResult(std::string)’:
MonitorModuleFMS.cpp:1002: error: ‘_strdate’ was not declared in this scope
MonitorModuleFMS.cpp:1003: error: ‘_strtime’ was not declared in this scope
make: *** [MonitorModuleFMS.o] Fehler 1
macleod@MacLeod:~/monitor/monitor/monitor/branches/2.1/monitord$

oder hab ich da nun etwas total falsch verstanden...

wäre nett wenn einer die schritte kurz erläutern würde.

vorab schonmal
besten dank!

MacLeod

Zitat:

---

Zitat von MacLeod

wow!
das ist ja klasse!

wie kann ich das denn nun ausprobieren mit dem crusader?

---

Hab das gleiche Problem:
suse10.2, gcc-Version: 4.1.2 aktuelle Libs

Zusatz:
meinen jetzigen recherchen nach ist in der aktuellen Version der time.h diese Funktion nicht mehr enthalten (lt. manpage auf meinem System zur time.h)
Die unter Suse 10.2 aktuellen Funktionen dazu lauten:
asctime(localtime(t)) wobei t für eine Strucktur steht

Code:

---

struct tm {
                  int tm_sec;        /* seconds */
                  int tm_min;        /* minutes */
                  int tm_hour;        /* hours */
                  int tm_mday;        /* day of the month */
                  int tm_mon;        /* month */
                  int tm_year;        /* year */
                  int tm_wday;        /* day of the week */
                  int tm_yday;        /* day in the year */
                  int tm_isdst;      /* daylight saving time */
              };

---

Da ich aber an der Stelle auf die schnelle nichts rumfingern möchte, und ich auch noch keinen schreibzugang zum Repository habe, werde ich bei gelegenheit es mal ausprobieren und dann posten.
Evtl. gibt ja auch noch andere Lösungen.

gruß
Simon

war ja klar, dass es wieder mal unterschiede in den Implementierungen gibt. Werde die Funktion für linux noch eben anpassen.

Heute auf der Arbeit kam ich einfach nicht dazu, es auch unter linux zu kompilieren.

Zitat:

---

Zitat von sschaebe

und ich auch noch keinen schreibzugang zum Repository habe

---

PM an mich mit Wunschpasswort und fertig :)

jhr

Fehler ist jetzt korrigiert. Auf beiden Plattformen wird jetzt die Standardfunktion strftime genutzt. asctime/ctime ist weniger geeignet, da es einen sehr lange Zeichenkette einschließlich Wochentag generiert. Ich vermute, daß würde der Crusader nicht verstehen.

SVN aktualisiert.

[EDIT]
Noch kleine Fehler im Crusader-Modus. Sind aber auch weitestgehend gelöst. Update folgt noch
[Update]
SVN wieder aktuell. Crusader Client zeigt mir die Daten jetzt an. FMS32Pro als Client ebenso.

so, neu ausgechecked
make ist durcgelaufen.
nur wie starte ich monitord dann?

macleod@MacLeod:~/monitor/monitor/branches$ cd 2.1
macleod@MacLeod:~/monitor/monitor/branches/2.1$ cd monitord
macleod@MacLeod:~/monitor/monitor/branches/2.1/monitord$ monitord
bash: monitord: command not found
macleod@MacLeod:~/monitor/monitor/branches/2.1/monitord$

so siehts dann aus...

kann mir das mal einer beleuchten?
wäre nett

MacLeod

Der aktuelle Ordner ist nicht im Suchpfad,wie es scheint. Starte den monitor mit "./monitord".

Zum testen ein telnet auf dem Port 9333 machen. Sollte sich der monitord melden. Alternativ auf 9300 wg. FMS32Pro.

Auch auf die Gefahr hin, dass man mich für sehr dämlich halten wird...

Code:

---

for i in monitord ; do \
                ( cd $i ; make all ; ) done
make[1]: Entering directory `/home/jhr/Projekte/FMS-Monitor/foobar/monitord'
gcc -c -c -D _DEBUG -O2 -I../jthread-1.2.1/src/ -I../xmlParser -I../simpleopt  -Wno-deprecated MonitorModules.cpp -o MonitorModules.o
gcc: error trying to exec 'cc1plus': execvp: Datei oder Verzeichnis nicht gefunden
make[1]: *** [MonitorModules.o] Fehler 1
make[1]: Leaving directory `/home/jhr/Projekte/FMS-Monitor/foobar/monitord'
make: *** [all] Fehler 2

---

Hä?

Wenn da mal kein Stück vom gcc fehlt. Bin gerade nicht so sicher, in welchem Paket der cc1plus steckt. Aber such mal nach g++ in den Beschreibungen.

Kaum auf "Antworten" geklickt, kam's mir in den Sinn: man sollte schon einen Compiler installieren ^^

Kein Wunder, dass ich den Fehler nicht kannte. Ich hab noch nie an einem System ohne Compiler gesessen ;)

jhr

Auch auf die Gefahr hin, dass Ihr mich jetzt für blöd haltet: Wo finde ich die aktuelle(n) Version(en)? Ich habe schonmal http://monitor.08k.de/index.php/Devel probiert, komme da aber nicht zum gewünschten Inhalt.

Danke für Eure Hilfe...

Funkwart

//edit: Was hier dazu stand, wo es die aktuelle Version gibt, bitte vergessen... :)
Ich antworte gleich in diesem Thread noch mal was sinnvolles. Siehe unten!

Zitat:

---

Zitat von jhr-online

monitor-2_1-rev81.tar.bz

---

Ich habe mal eine erste Testinstallation unter Ubuntu 7.04 gemacht, und den Monitord mit einer Aufzeichnung einer Monatsalarmierung (ZVEI) konfrontiert.

Dabei sind mir zwei Sachen aufgefallen:
Nur der Monitor-Port 9333 wertet Melder/Sirenenalarmierungen aus. Der FMS- und Crusader-Port geben auch bei Sirenenalarm nur eine Melderauslösung aus.

Kommt im direkten Anschluss an eine ZVEI-Folge kein Sirenen oder Melderton, dauert es mehrere Sekunden, bis die Ausgabe der Widerholung erfolgt.

Sprich: Bei einer Alarmierung von 12345 ohne Folgeton gibt Monitor zunächst ZVEI 12345 aus, dann dauert es mehrere Sekunden, dann kommt ZVEI 12345 nochmal.

Dieses Problem habe ich übrigens auch bei der monitor-Version 1.8.1 unter Ubuntu. Da kann es bis zu zehn Sekunden nach der Alarmierung dauern, bis die Schleife im Frontend erscheint. Komischerweise tritt das Phänomen bei der Bosix-Variante auf Basis Knoppix 3.0 nicht auf.

Andreas

Zitat:

---

Zitat von nepomuck

Nur der Monitor-Port 9333 wertet Melder/Sirenenalarmierungen aus. Der FMS- und Crusader-Port geben auch bei Sirenenalarm nur eine Melderauslösung aus.

Kommt im direkten Anschluss an eine ZVEI-Folge kein Sirenen oder Melderton, dauert es mehrere Sekunden, bis die Ausgabe der Widerholung erfolgt.

---

Deinem Post entnehme ich, daß der Test generell erfolgreich war :-)

Der Text "Melderauslösung" ist (noch) fix hinterlegt. Das ist aber recht leicht zu ändern. Kommt in Kürze.

Die Zeitverzögerung ist gewollt und erforderlich, da auf den Weckton/Sirenenton gewartet wird. Erst damit kann ja eine Ausgabe mit "Sirenenalarm" erfolgen. Kommt eine zweite ZVEI-Folge war es offensichtlich keine Sirenenalarmierung und dann wird es direkt ausgegeben (Melderauslösung). Ich meine, es waren keine 10 Sekunden. Aber da sind vielleicht noch andere Timer an deinem Ergebnis beteiligt.

Zitat:

---

Zitat von Buebchen

Deinem Post entnehme ich, daß der Test generell erfolgreich war :-)

---

Na klar, ich bin ganz begeistert. Danke.
Ich werde mal einen längeren Live-Test auf einem Server-PC mit Scanner starten und ein paar VMs als Clients davor hängen. Dank selbstgebastelter Außenentenne habe ich nun auch im Serverzimmer einen störungsfreien Empfang, der für FMS und ZVEI genügt.
Gibt's denn schon ein Frontend für das Monitor-Protokoll?

Zitat:

---

Zitat von Buebchen

Die Zeitverzögerung ist gewollt und erforderlich, da auf den Weckton/Sirenenton gewartet wird.

---

Das ist klar, aber der Timeout erscheint mir etwas arg lang. Eigentlich sollten 100ms "Stille" genügen, oder?

Andreas

Also wenn ich ehrlich bin müßte ich das mal nachlesen...

Sind 100ms eine Schätzung, oder ist das in der ZVEI Norm so vorgesehen ?

[EDIT]
100ms ist zu knapp. Die Pause nach der 5-Tonfolge kann schon 600ms sein.

Dann noch mindestens 2Sekunden Doppelton damit es ein Sirenenalarm ist. Diese Zeit wartet er auf jeden Fall ab, um sicher zu sein, daß es kein Sirenenalarm ist.

Gut. Da könnte man versuchen eine Abbruchbedingung reinzubauen. Werd' das mal notieren.

ich bin grade an einer am entwickeln, nen screenshot solltest du 1 oder 2 vllt auch 3 seiten vorher sehen :D

Jetzt noch mal richtig:
Wer mitmachen will, muss sich jeweils den aktuellen Stand aus dem subversion-Repository holen:

Code:

---

svn co svn://jhr-online.de/monitor/monitor/branches/2.1

---

Wer sich zum Testen einfach eine aktuelle Version daraus ziehen will, kann auf den subversion-Kram verzichten und dafür den Zweig im Repository einfach exportieren:

Code:

---

svn export svn://jhr-online.de/monitor/monitor/branches/2.1

---

Da vielleicht nicht jeder damit umgehen kann oder will, habe ich mal eine aktuelle Version exportiert und bereit gestellt unter: http://downloads.jhr-online.de/monitor/
In dem Verzeichnis kann man sich die Dateien online angucken; wer's lokal haben will, also zum Kompilieren und Testen, kann sich den bzip-komprimierten Tarball runterladen:
http://downloads.jhr-online.de/monit...tor-2_1.tar.bz

Und jetzt das Beste: Zwei mal am Tag (um 8.30 und um 20.30 Uhr) wird das Verzeichnis und der Tarball automatisch neu exportiert. Wenn sich also was geändert hat, ist man um die Zeit gut bedient ;)
Wenn jemand eine aktuellere Version braucht, kann er sich die ja exportieren oder mir auf gut Glück ne Mail schicken.

Ist das Service? ;)

jhr

//edit: Für einige, die es noch nicht bemerkt haben... Der Tarball wird mittlerweile im 3-Stunden-Takt gebildet.

Zitat:

---

Zitat von jhr-online

Ist das Service? ;)

jhr

---

Soweit so gut. Leider bekomme ich mit dem aktuellen Rep. nach dem erfolgreichen kompilieren nur einen Segmentaition fault.
EDIT: Das Problem mit dem Segmentation Fault habe ich gefunden: monitord.xml war defekt.
Gibt es ein Logfile oder kann ich irgendwelche trace-Ausgaben aktivieren?

Gruß
Simon

Zitat:

---

Zitat von Buebchen

Sind 100ms eine Schätzung?

---

Ja -- ich habe keine Ahnung, was die Norm vorsieht.

Noch ein paar "Bugs":

1.
Meine Testaufzeichnung besteht NUR aus ZVEI-Alarmen. Dennoch gibt der monitord ab und zu FMS-Telegramme aus.

2.
Die Verbindung zu FMS-PRO32 funktioniert nicht richtig. Ich spiele dem Monitor serienweise ZVEI-Alarme vor und nach einer gewissen Zeit kommen nicht mehr alle Schleifen beim FMS-PRO32-Client an. Interessanterweise zeigt eine andere Maschine mit "telnet <monitor-server> 9300" alle Schleifen korrekt an.

Konfig: SRV: Ubuntu 7.04, CLT1: Ubuntu 7.04 mit Telnet, CLT2: VM unter VMWare 6 mit XP und FMS-PRO32 3.2.2

Andreas

huhu!
also, bei mir klappt das irgendwie nicht :-((((
ich habe ne verbindung sowohl mit nem crusader- als auch mit FMS32-client. aber er wertet nix aus. ich habe ihm mal ne 5tonfolge auf den line in gegeben, wertet er aber nicht aus.

mache ich noch was falsch?
habe ich was übersehen?

edit:
wenn ich telnet >server-ip< 9300 ausführe, wird dort auch nichts angezeigt.
konfig mit der soudkarte des servers nicht i.O? sollte aber... mit nem crusader server hats dort so mal gefunzt...

MacLeod

Zitat:

---

Zitat von MacLeod

wenn ich telnet >server-ip< 9300 ausführe, wird dort auch nichts angezeigt.
konfig mit der soudkarte des servers nicht i.O? sollte aber... mit nem crusader server hats dort so mal gefunzt...

---

Nur um sicher zu gehen, dass es nicht an einem Tippfehler liegt... Wir hatten Port 9333 angepeilt IIRC.

jhr

ups, ja, meine natürlich den 9333 ;-)

Ich hab das gleich Problem wie MacLeod,

Ich kann verbindung aufbauen aber er wertet nichts aus. Auch auf der console erscheint vieleicht mal 1 Eintrag und das war es dann.

ist das sound device belegt ?

bei mir läuft das alles einwandfrei.

Gucktmal auf welchem Kanal die Daten ankommen und auf welchem Ihr auswertet.

Zitat:

---

Zitat von sschaebe

Gibt es ein Logfile oder kann ich irgendwelche trace-Ausgaben aktivieren?

Gruß
Simon

---

Logfile ist bisher Fehlanzeige. Das Execption-Handling ist bis auf wenige Ausnahmen auch noch nicht implementiert.

Was es gibt, ist ein "#define DEBUG " zu machen. Wenn es eine solche Definition gibt macht er ein paar Ausgaben mehr. Aber ob die bei einem segfault helfen werden ... Muss man dann mal probieren.

Am besten direkt im Makefile des monitord mit -D hinterlegen. Dann wird es auch überall gesetzt.

Ist halt noch alles vorm Beta-Stadium. Da ist der Forscher gefragt :-)

Also die Sounddevice ist ok bei mir kommt nur das:

Display :6 762 3744: 2
310:1183577422:4d6f6e69746f7264:4b616e616c2031:676 23744:2:1:0:3
1183577422

und das war es dann.
Es werden keine Daten über einen Port ausgegeben

Entweder bist du nicht angemeldet oder die IP des Client ist gesperrt.

[Edit]
Anmeldung als User "test" mit dem Passwort "test":

120:74657374:74657374