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.
Druckbare Version
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!
Ich habe mal eine erste Testinstallation unter Ubuntu 7.04 gemacht, und den Monitord mit einer Aufzeichnung einer Monatsalarmierung (ZVEI) konfrontiert.Zitat:
Zitat von jhr-online
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
Deinem Post entnehme ich, daß der Test generell erfolgreich war :-)Zitat:
Zitat von nepomuck
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.
Na klar, ich bin ganz begeistert. Danke.Zitat:
Zitat von Buebchen
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?
Das ist klar, aber der Timeout erscheint mir etwas arg lang. Eigentlich sollten 100ms "Stille" genügen, oder?Zitat:
Zitat von Buebchen
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: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 co 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/Code:svn export svn://jhr-online.de/monitor/monitor/branches/2.1
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.
Soweit so gut. Leider bekomme ich mit dem aktuellen Rep. nach dem erfolgreichen kompilieren nur einen Segmentaition fault.Zitat:
Zitat von jhr-online
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
Ja -- ich habe keine Ahnung, was die Norm vorsieht.Zitat:
Zitat von Buebchen
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
Nur um sicher zu gehen, dass es nicht an einem Tippfehler liegt... Wir hatten Port 9333 angepeilt IIRC.Zitat:
Zitat von MacLeod
jhr
ups, ja, meine natürlich den 9333 ;-)