Wie steht's um alles?

[jhr-online]

Ja ja ja, ihr habt ja längst gewonnen. Die Domain ist verlängert :)

[felix000]

Danke. 

[funkwart]

Hallo monitor-Nutzer,

hier nochmal eine Bitte an alle: lasst uns neu Ausprobiertes und vermeintlich Althergebrachtes hier auführlicher als bisher kommunizieren. Wenn jemand etwas Neues zum Laufen gebracht hat, dann bitte hier auch eine Beschreibung einstellen, wie dies geschehen ist. Sonst kommen immer wieder viele Nachfragen und Antwortschnipsel, die dann weitere Nachfragen von anderen produzieren.
Als Anregung nochmal: Das Wiki vielleicht wieder beleben, wo dann jeder in einem entsprechenden Abschnitt seine Vorgehensweise erläutern kann.

Gruß,
Funkwart

[cwh]

Wiki klingt gut.

Wo?

[mdi]

Moinmoin,

ich habe mich hier auch ziemlich rar gemacht; erschrocken stellte ich eben fest, dass mein letzter Besuch Ende September war. Für mich ziehe ich daraus (ich stehe in engem Kontakt mit mehreren monitord-Usern in meinem Bekanntenkreis), dass der monitord prinzipiell "rund" läuft. Das zeigte sich ja auch durch die "Übernahme" in andere Programme.

Tatsächlich freue ich mich erstmal über die quasi schon beschlossene Verlängerung der Domain; ohne die wäre das Projekt vermutlich "noch mehr Nische" als es ohnehin von Natur aus ist.

Zusammengefasst fehlt tatsächlich wohl:
- ein Frontend, das mehr kann als das, was im SVN steckt (vielleicht fehlen auch nur Zusatzmodule, eine einfachere Einrichtung oder ähnliches). Ich hatte mit meinem PHP-Webfrontend eine "offene" Struktur zu schaffen versucht, die ziemlich low-level Ansätze für mehr bietet, leider habe ich bis heute keine darauf basierenden Ansätze gefeedbackt bekommen.
- ein Standalone-Frontend; dieses ist scheinbar obsolet geworden, seitdem der Radio-Operator die monitord-Schnittstelle nutzbar macht.
- Doku, wobei da auf monitord.de schon einiges zusammen getragen ist.
- Anleitungen aus User-Sicht. Ich selber bezeichne mich durchaus als Betriebsblind, denn von mir geschriebene Anleitungen sind häufig zu detailliert oder zu grob.
- die hier erbetene Diskussion über aufgesetzte und lauffähige Lösungen; ich denke, hier scheitert es häufig genug daran, dass man dafür den eigenen Quellcode veröffentlichen müsste.

Ich persönlich freue mich, dass es weiter geht und bin auch keinesfalls weg, wenn auch nicht mehr so oft hier wie noch vor einigen Monaten :)!

Viele Grüße aus dem Frost
Martin

[funkwart]

Hallo,

ich würde mich bei der Erstellung von Anleitungen aus User-Sicht beteiligen. Hier würde ich gerne meinen Fokus auf den wirklichen Vorteil von monitord legen, nämlich den Betrieb unter Linux. Es ist ja schön, dass der monitord in andere Software Einzug gefunden hat - das auch zu Recht, aber diese läuft nunmal nicht unter Linux. Das aber ist doch fast eine Bedingung für stabilen Betrieb. Ich habe einen alten Laptop (Thinkpad 560Z) mit 96MB RAM mit einem Uralt-SuSE Linux laufen (8.2), das mir treu den monitor in der 1.9er Version laufen lässt. Seit fast Menschengedenken habe ich dort keinen Neustart durchführen müssen.

Nun würde ich gerne den monitord "scharf" einsetzen, komme aber nicht so recht an eine saubere Installation und eine knappe Auswertung mit Log-File, einfachem FE (gerne in Konsolenform, um auf X zu verzichten) und ereignisgesteuerter script-Ausführung heran. Das ging im alten monitor einfacher.

Also, Unterstützung (soweit die Zeit es zulässt) würde ich gerne leisten, bräuchte dazu aber ein wenig Support auf technischer Seite.

Gruß,
Funkwart

[sunnyman]

Hallo Zusammen,

mir geht es ähnlich wie schmodda.
In meiner Serverlandschaft läuft einsam und verlassen noch eine Windows-Kiste, die außer FMSPro32 nichts zu tun hat. Das würde ich gerne auf den Vollblut-Server mit Ubuntu Server migrieren, der daneben steht. Da meine Virtualisierungsversuche mit VirtualBox nicht so erfolgreich waren, würde ich es gerne mal mit monitor ausprobieren.

Aus der Homepage kann man ja jetzt nicht so direkt ableiten, wie es um das Projekt steht, sprich ich habe wenig Lust, das Ding zu bauen und zur Funktion zu überreden, um dann möglicherweise irgendwann festzustellen dass es buggy ist :)

Was Doku angeht: Installationsdoku kann ich gern beibringen.

[mdi]

Moinmoin,

Aus der Homepage kann man ja jetzt nicht so direkt ableiten, wie es um das Projekt steht, sprich ich habe wenig Lust, das Ding zu bauen und zur Funktion zu überreden, um dann möglicherweise irgendwann festzustellen dass es buggy ist :)

Was Doku angeht: Installationsdoku kann ich gern beibringen.

wenn aus den Angeboten in diesem Thread vielleicht duch Eröffnung eines neuen Threads eine Installationsanleitung für Linux wird, wäre das super und würde sicher den Weg auf die monitord-Webseiten finden.

Zum Thema buggy: Definiere buggy ;)! Nein, im Ernst - meiner Erfahrung nach funktionieren die Auswerter gut und stabil. In meinem Dunstkreis läuft eine Windows-Kiste mit dem monitord im Betriebsfunk und macht Fünftonauswertung 24/7 (Windows-Neustarts nach Updates und ähnliche seltene Wartungszwecke ausgenommen). Dabei kam es eine gefühlte Ewigkeit nicht mehr zu Absurditäten. Auf Windows kann ich für meinen Teil ganz klar sagen: Der monitord läuft wartungsfrei und zuverlässig.

Viele Grüße
Martin

[cwh]

So langsam muß ich auch mal meinen monitord-client namens moncl etwas promoten, mit dem ich seit 2 Jahren unsere Feuerwehr per SMS alarmiere und die Alarmierungsmeldungen per Audiorecorder mitlogge.

svn co http://www.webeve.de/svn/cwh/trunk/moncl

Geschrieben in Perl. Primär lauffähig unter Linux, für Windows bräuchte er wohl Anpassungen

Die Mühlen mahlen langsam, aber gründlich:

Ich habe nun endlich mal mein Alarmierungsscript in ein öffentliches SVN repo verschoben:

svn co http://www.webeve.de/svn/webeve/trunk/moncl/

Oder zum gucken:
http://www.webeve.de/viewvc/webeve/trunk/moncl/

Die Features sind:
- läuft als Daemon (automatischer Start beim Booten)
- SMS-Versand über Internet (bevorzugt Clickatell)
- Verschiedene Schleifen-Empfänger Zuordnungen (für mehrere Wehren geeignet)
- auch Weiterleitung nach Email
- Audioaufzeichnung nach Alarmierung mit Weiterleitung per Email (Audioformat nach wählbar)
Und bestimmt noch einiges anderes, was ich jetzt vergessen hab ;)
Allerdings ist es schon ein bissl bastelei das aufzusetzten, also es ist nicht ganz mit Entpacken und Starten getan.

Dazu muß ich sagen, dass ich das vermutlich nur noch auf Wunsch anderer weiterentwickeln werde, denn seit Einführung der Integrierten Leitstellen in Bayern ist es nun auch möglich direkt von der Leitstelle eine SMS mit Informationen zum Einsatz zu bekommen. D.h. ich baue grade ein SMS-Weiterleitungsscript, das sich unter

svn co http://www.webeve.de/svn/webeve/trunk/smscatter/

findet.

Grüße,
Christopher

[cwh]

ich baue grade ein SMS-Weiterleitungsscript, das sich unter

svn co http://www.webeve.de/svn/webeve/trunk/smscatter/

findet.

Das übrigens seit zwei Wochen im Produktiveinsatz ist.

Alles was man braucht ist:
- einen Rechner (ohne nennenswert Rechenleistung)
- ein GSM oder UMTS-Modem (aka. Web-Stick)
- eine (Discounter-)SIM-Karte
- einen Internetzugang
- einen Clickatell-Account (zum SMS-Versand)
- am besten Linux mit
- Ruby
- gammu-smsd (überwacht das Modem auf eingehende SMS-Nachrichten)
- mein Script namens smscatter

Damit kann man eine beliebig lange Liste an Auslösenummern definieren (Leitstelle, Kommandant, etc.). Weiterhin eine beliebig lange Liste an Empfängern. Emailweiterleitung ist auch möglich. Das ganze ersetzt T-Mobile Alarmruf, ist möglicherweise nicht so ausfallsicher dafür aber Welten billliger.

Ich gedenke die Email dahingehend zu erweitern, dass dort eine Karte enthalten ist, in der der Einsazuort, der in der Leitstellen-SMS enthalten ist, markiert ist. Ich denke da an http://openfiremap.org

(Offtopic-)Grüße,
Christopher