monitord auf Raspberry Pi

Hallo allerseits,

ich habe ein Archlinux auf meinem Pi laufen und bin beim Kompilieren in folgenden Fehler gelaufen:

Code:

---

/bin/sh ./libtool --tag=CXX  --mode=compile g++ -DHAVE_CONFIG_H -I.  -Ijthread-1.2.1/src -D_DEBUG -Wall  -frtti -DPLUGINS -fPIC -rdynamic  -shared -frtti  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -MT monitord/plugins/monitord_plugins_libmplugin_audiorecorder_la-mpluginAudio.lo -MD -MP -MF monitord/plugins/.deps/monitord_plugins_libmplugin_audiorecorder_la-mpluginAudio.Tpo -c -o monitord/plugins/monitord_plugins_libmplugin_audiorecorder_la-mpluginAudio.lo `test -f 'monitord/plugins/mpluginAudio.cpp' || echo './'`monitord/plugins/mpluginAudio.cpp
 g++ -DHAVE_CONFIG_H -I. -Ijthread-1.2.1/src -D_DEBUG -Wall -frtti -DPLUGINS -fPIC -rdynamic -shared -frtti -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -MT monitord/plugins/monitord_plugins_libmplugin_audiorecorder_la-mpluginAudio.lo -MD -MP -MF monitord/plugins/.deps/monitord_plugins_libmplugin_audiorecorder_la-mpluginAudio.Tpo -c monitord/plugins/mpluginAudio.cpp  -fPIC -DPIC -o monitord/plugins/.libs/monitord_plugins_libmplugin_audiorecorder_la-mpluginAudio.o
monitord/plugins/mpluginAudio.cpp: In Elementfunktion »void MonitorAudioPlugIn::addThreadMessage(SocketThread*, std::string)«:
monitord/plugins/mpluginAudio.cpp:20:45: Fehler: »sleep« wurde in diesem Gültigkeitsbereich nicht definiert
monitord/plugins/mpluginAudio.cpp: In Elementfunktion »bool MonitorAudioPlugIn::getThreadMessage(SocketMessage&)«:
monitord/plugins/mpluginAudio.cpp:41:39: Fehler: »sleep« wurde in diesem Gültigkeitsbereich nicht definiert
make[1]: *** [monitord/plugins/monitord_plugins_libmplugin_audiorecorder_la-mpluginAudio.lo] Fehler 1
make[1]: Leaving directory `/tmp/yaourt-tmp/aur-monitord-svn/src/build'
make: *** [all] Fehler 2

---

Das Paket wurde aus dem AUR kompiliert, aber auch nach einem manuellen svn co, ./configure und make trat der Fehler auf.

Hat jemand eine Idee, wie das Problem zu lösen ist?

Viele Dank für die Hilfe!

Zitat:

---

Zitat von Dtrieb7482

Hallo allerseits,

ich habe ein Archlinux auf meinem Pi laufen und bin beim Kompilieren in folgenden Fehler gelaufen:...

---

Hi, ich habe noch nie mit einem Archlinux gearbeitet. Aber kann man dort nicht die gleichen Befehle wie bei einem Debian verwenden?

@matt:

Du hast doch auch den UBC69 XLT

Wie hoch hast du den Line-In Pegeal im alsamixer?

Soweit ich das verstehe gibt es da keinen Pegel.
Ich kann bei meiner Soundblaster Mp3+ nur den Line in an oder aus machen.
Wenn du dir den Pegel anzeigen lässt ist er im unteren drittel.

So ist zumindest meine Erfahrung damit.
Ich muss:
Den Aufnahme Regler auf 100 bzw 1 stellen weiß nicht genau und muss die Aufnahme des Kanals mit Leertaste aktivieren. Dann steht da Aufnahme drunter.

Den Eingangspegel kann ich mit dem Befehl

Code:

---

sudo arecord -vv -D plughw:1,0 /dev/null

---

darstellen lassen.

Die Kombination Uniden UBC 60 XLT2 (über Diskriminatorausgang angeschlossen) und Behringer UCA 202 ergibt bei mir einen Eingangspegel zwischen den Grenzen 20% und 30%. Im Mittel liegt er aber tatsächlich bei 24% oder 25%.

Im Alsamixer bietet die UCA202 keine Einstellungsmöglichkeiten was den Pegel betrifft. Sollte der Pegel nicht passen, muss er also über entsprechende Hardware angepasst werden.

Hi zusammen,

die Abbrüche nach 2-3 h lagen bei mir daran, dass ich die Stormversorgung über meinen PC lief, sobald dieser in den Powersave gegangen ist, war der Raspberry zwar noch erreichbar, allerdings hat sich monitord dabei aufgehangen.

Hat von euch schon jemand ein Skript geschrieben, das in /etc/init.d liegt um monitord zu starten und zu stoppen?

Meins sieht bisher so aus:

Code:

---

case "$1" in
    start)
                /home/pi/monitord/monitord/monitord -c /home/pi/monitord/monitord/monitord.xml  &
                ;;
    stop)
                pid=$(pidof monitord)
                kill $pid
                ;;
        restart)
                pid=$(pidof monitord)
                kill $pid
                /home/pi/monitord/monitord/monitord -c /home/pi/monitord/monitord/monitord.xml  &
                ;;
          *)
                echo "usage $0 start|stop" ;;
esac

exit 0

---

Wenn ich

Code:

---

sudo /etc/init.d/monitord start

---

ausführe wird in der Konsole "monitord 2.0svn running..." angezeigt. Damit ich eine normale Eingabezeile mit "pi@raspberrypi ~ $" erhalten muss ich einmal Enter drücken. (siehe Bild)

Gibt es eine Möglichkeit, damit ich sofort nach dem Starten von Monitord wieder eine normale Eingabezeile erhalte?

Versuchs mal mit:

/home/pi/monitord/monitord/monitord -c /home/pi/monitord/monitord/monitord.xml >> /dev/null &

Ich habe mich auch mit diesem Startscript versucht, allerdings habe ich leider nicht genug Ahnung von Linux um mit den Runlevel die Abhängigkeiten richtig hin zu bekommen.

Von daher habe ich einfach einen Cronjob erstellt, der jede Minute überprüft ob Monitord läuft und es entsprechend startet, wenn dem nicht so ist.

Mit dem LUA-Script bin ich auch nicht klar gekommen, von daher habe ich hier die gleiche Lösung über ein Cronjob erledigt: Eine PHP-Datei fragt alle 15 Sekunden ab ob ein neuer Eintrag in der mySQL-DB ist und löscht diesen entweder oder verarbeitet diesen weiter z.B.: AlarmTafel oder SMS-Alarmierung

@dataflash:
Mit dem ">> /dev/null" hat es geklappt.

Ich filtere die dekodierten Meldungen mit einem LUA Skript. Funktioniert einwandfrei. Falls zu hilfe benötigst kann ich versuchen dir zu helfen.

Zum Ausführen von Aktionen will ich mit dem LUA Skript ein in C geschriebenes Programm ausführen. Damit Monitord nicht wartet bis das Programm fertig ausgeführt ist, erstellt es einen Daemon von sich selbst, der beendet wird, sobald alle Aktionen abgeschlossen sind.

Darin kann ich alles denkbare anstellen.

Zitat:

---

Zitat von matt

Hi, ich habe noch nie mit einem Archlinux gearbeitet. Aber kann man dort nicht die gleichen Befehle wie bei einem Debian verwenden?

---

Nein es sind nicht die gleichen Befehle.

Wäre schön wenn mir jemand weiterhelfen könnte, dann könnte ich mich auch mit dem Programm beschäftigen.

Zitat:

---

Zitat von Dtrieb7482

Nein es sind nicht die gleichen Befehle.

Wäre schön wenn mir jemand weiterhelfen könnte, dann könnte ich mich auch mit dem Programm beschäftigen.

---

Gibt es einen Grund warum du nicht mit einem Debian arbeiten kannst?
Ich glaube bis jetzt haben hier im Thread alle Leute mit dem Raspbian gearbeitet.

@ Matt, die POCSAG Messages möchte ich eigentlich nicht über LUA filtern, da die RIC Liste über eine Datenbank aktualisiert wird und über das PHP-Script direkt ein Abgleich erstellt wird.

Das Startscript im init.d allerdings würde mich schon sehr interessieren, wie schon beschrieben, ist nicht das SH-Script das Problem, sondern der aufruf beim start.
Mein Script, dass im init.d liegt wird nicht beim start ausgeführt.

Zitat:

---

Zitat von dataflash

@ Matt, die POCSAG Messages möchte ich eigentlich nicht über LUA filtern, da die RIC Liste über eine Datenbank aktualisiert wird und über das PHP-Script direkt ein Abgleich erstellt wird.

Das Startscript im init.d allerdings würde mich schon sehr interessieren, wie schon beschrieben, ist nicht das SH-Script das Problem, sondern der aufruf beim start.
Mein Script, dass im init.d liegt wird nicht beim start ausgeführt.

---

In /etc/init.d/ habe ich die Datei monitord liegen. Mit ihr starte und beende ich Monitord als Daemon. Ist noch nicht perfekt, aber funktioniert.

Code:

---

case "$1" in
    start)
                /home/pi/monitord/monitord/monitord -c /home/pi/monitord/monitord/monitord.xml >> /dev/null &
                echo "Monitord wurde gestartet"
                ;;
    stop)
                pid=$(pidof monitord)
                kill $pid
                echo "Monitord wurde beendet"
                ;;
        restart)
                pid=$(pidof monitord)
                kill $pid
                echo "Monitord wurde beendet"
                /home/pi/monitord/monitord/monitord -c /home/pi/monitord/monitord/monitord.xml  >> /dev/null &
                echo "Monitord wurde gestartet"
                ;;
          *)
                echo "usage $0 start|stop|restart" ;;
esac

exit 0

---

Um das Skript beim Booten des Raspberrys auszuführen habe ich in der Datei /etc/rc.local vor der Zeile

Code:

---

exit 0

---

die Zeile

Code:

---

/etc/init.d/monitord start

---

eingefügt. Damit wird Monitord automatisch beim Booten gestartet.

Ich hab mir einen cronjob bzw. ein Skript geschrieben:

es setzt die Einstellungen im alsamixer und startet monitord

zudem wird jede minute geprüft ob monitord läuft und bei bedarf neugestartet. das ganze wird natürlich dann auch protokolliert.

zudem will ich noch einbauen das geprüft wird wie alt die letzten änderungen in der monitord.log sind. solten diese älter als 2 minuten sein, so soll ebenfalls eine meldung an mich per mail kommen.

monitord.log wird einmal im monat gelöscht.

damit sollte soweit mal alles abgedeckt sein das dafür sorgt das monitord immer ordnungsgemäß läuft

Was hast du alles gemacht damit der cronjob lief?
Weil ich hab das versucht und irgendwie wollte der das Script nicht ausführen.
Oder muss das Script an einer bestimmten stelle liegen?

@Matt, danke für das scirpt läuft wunderbar.

@DeLocke, ist das ein sh script? Kannst du es mir eventuell mal schicken, wenn es fertig ist?

@MueThoS: sudo crontab -e
Dann kommt es drauf an welches script du ausführen willst, wenn du ein sh script ausführen willst, sieht das ganze so aus (script wird alle 5Minutes ausgeführt):

*5 * * * * sh /home/pi/monitod/monitord/scriptname.sh

STRG + X anschließend J oder Y drücken, je nach Keyboard Layout und schon sollte es gehen.

Wichtig hierbei eine Zeitangabe unter 1 Minute ist im Cronjob nur über mehrere mit Timer möglich.

Sollte es immer noch nicht gehen, post mal dein Script.

Wie habt ihr das denn gelöst das der alsamixer seine Einstellungen nach einem booten behält?

mit alsactl store ist es nach dem booten immer wieder weg und erst mit alsactl restore wieder da?

Ich hab mir das jetzt halt in das cron-Skript geschrieben.

Script hab ich mit deinen Tips hin bekommen.
Macht aber im mom erst mal nicht viel.
Ausser meiner Webseite zu sagen das der Pi läuft und der Monitord noch läuft.

Also bei mir behält der Alsamixer die Einstellungen, da gabs diese Befehl zum setzen der Werte des Alsamixers, weiter vorne im Thread.

Wie schon bemerkt, gibt es noch einige Bugs beim Einlesen der monitord.xml.
Dazu gehören wohl auch einige Werte für POCSAG1200.

In der Datei MonitorModulPocsag1200.cpp habe ich den Konstruktor

Code:

---

MonitorModulePocsag1200::MonitorModulePocsag1200(int sampleRate, bool crccheck, bool errorcorrection, int minpreambel, int maxerrors, int algorithmus)

---

durch die folgenden Zeilen ergänzt:

Code:

---

FILE_LOG(logDEBUG) << "POCSAG Parameter" ;
FILE_LOG(logDEBUG) << "sample : " << sampleRate  ;
FILE_LOG(logDEBUG) << "crc    : " << crccheck  ;
FILE_LOG(logDEBUG) << "ecc    : " << errorcorrection  ;
FILE_LOG(logDEBUG) << "min_Pre: " << minpreambel  ;
FILE_LOG(logDEBUG) << "max_err: " << maxerrors  ;
FILE_LOG(logDEBUG) << "Algo  : " << algorithmus  ;

---

Damit konnte ich in der monitord.log sehen, dass nicht alle Angaben aus der xml-Datei übernommen wurden.

Deswegen habe ich den Variabeln "crccheck", "errorcorrection", "maxerrors" und "algorithmus" direkt in der Funktion deren Werte zugewiesen.
Mal schauen ob sich damit was an der Auswertequalität verbessert.

Leider ändert sich durch die Änderung im Quellcode bei mir nichts an der Auswertequalität.

Hier ein Beispiel:
Die Alarmierungen werden mehrfach hintereinander gesendet. Bei manchen fehlen dann einfach mal ein paar Zeichen.

Meldung 1: 123456789ABCDEFGHIJKLMOPQRSTUVWXYZ
Meldung 2: 123456789ABC
Meldung 3: 123456789ABCDEFGHIJKLMOPQRSTUVWXYZ

Die zweite Meldung wurde folglich nicht korrekt ausgewertet.

Ein allgemeines Zeichen, welches die Meldungen abschließt (wie z.B. NULL) ist vorhanden. Sonst könnte man das ganz einfach prüfen.

Hallo Zusammen!
Ich lese hier jetzt nun schon seit einiger Zeit mit und interessiere mich für die Auswertung. Mittels Raspberry. Habe das Thema aber selbst aber aufgrund mangelnder Linuxkenntnisse und manges Zeit noch nicht angegangen.
Bei uns werden alle Meldungen mit <EOT> abgeschlossen, so das man doch darüber eine Prüfung machen könnte.
Die in Matts Beitrag angesprochene Mehrfachauswerung mit teils abgehackten Texten werden meiner Meinung nach am Empfang von von merheren DAUs liegen. Den einen empfängt der Scanner sehr gut und einer der weiter weg steht liefert den abgehackten Text.
Gruß
Reissdorf

Zitat:

---

Zitat von matt

Leider ändert sich durch die Änderung im Quellcode bei mir nichts an der Auswertequalität.

Hier ein Beispiel:
Die Alarmierungen werden mehrfach hintereinander gesendet. Bei manchen fehlen dann einfach mal ein paar Zeichen.

Meldung 1: 123456789ABCDEFGHIJKLMOPQRSTUVWXYZ
Meldung 2: 123456789ABC
Meldung 3: 123456789ABCDEFGHIJKLMOPQRSTUVWXYZ

Die zweite Meldung wurde folglich nicht korrekt ausgewertet.

Ein allgemeines Zeichen, welches die Meldungen abschließt (wie z.B. NULL) ist vorhanden. Sonst könnte man das ganz einfach prüfen.

---

Wäre da nicht der max-errors Parameter der richtige für dich?

Ich habe eine kurze Frage am Rande:

Ich meine, dass in diesem Thread mal jemand den Namen eines Programms erwähnt hat, mit dem man POCSAG- und FMS-Meldungen erzeugen kann (so wie mit dem BOS-Tool).

Allerdings kann ich nichts finden. Kann mir vielleicht jemand helfen?

Zitat:

---

Zitat von Reissdorf

Bei uns werden alle Meldungen mit <EOT> abgeschlossen, so das man doch darüber eine Prüfung machen könnte.

---

Erstmal eine gute Idee! Nur was ist wenn alle Auswertungen leicht schief gehen.
Dann hast du eventuell dieses EOT nicht mit drinnen. Ich möchte dann aber trotzdem die Alarmierung sehen.

Zitat:

---

Zitat von Reissdorf

Die in Matts Beitrag angesprochene Mehrfachauswerung mit teils abgehackten Texten werden meiner Meinung nach am Empfang von von merheren DAUs liegen. Den einen empfängt der Scanner sehr gut und einer der weiter weg steht liefert den abgehackten Text.
Gruß
Reissdorf

---

Bei mir ist das definitiv der Fall.
Die erste Auswertung geht immer schief. Das hört man auch am Signal.
Die zweite ist die beste und danach wird es wieder etwas schlechter.

Zitat:

---

Zitat von MueThoS

Erstmal eine gute Idee! Nur was ist wenn alle Auswertungen leicht schief gehen.
Dann hast du eventuell dieses EOT nicht mit drinnen. Ich möchte dann aber trotzdem die Alarmierung sehen.

Bei mir ist das definitiv der Fall.
Die erste Auswertung geht immer schief. Das hört man auch am Signal.
Die zweite ist die beste und danach wird es wieder etwas schlechter.

---

Genau so sieht es bei mir auch aus.

Folgendes habe ich mir mal überlegt:
Annahme:
- Wir haben eine RIC. Diese wird (sagen wir einfach mal) bei einem Alarm 3 mal nacheinander alarmiert.
- Die erste Nachricht wurde zu 40% ausgewertet, die zweite zu 100% und die dritte zu 60%

Das Ergebnis sind drei Meldungen in der POCSAG-Tabelle in MySQL, bei denen lediglich eine "nutzbar" ist.

Abilfe:
- Ein Programm überwacht den Inhalt der POCSAG-Tabelle
- Es korreliert die Meldungen dieser einen RIC gegeneinander (Kreuzkorrelation)
- Korrelieren zwei Meldungen miteinander prüft das Programm welche der beiden Meldungen weniger Zeichen im Text hat und löscht diese.

Es macht natürlich nur Sinn Meldungen zu korrelieren, welche zeitlich nahe aneinander liegen. Z.B. 5 Minuten.

Was haltet ihr davon?

Ist genau das was ich im mom mache!
Nur das ich über eine temporäre Tabelle gehe.
Der monitord schiebt ALLE Einträge in die temp. Tabelle.
Wenn die Seite offen ist läuft ein Script mit welches folgendes macht.

temp. Tabelle auslesen und jeden Datensatz abarbeiten mit:
schauen ob es im Zeitraum von 2 Minuten + und - einen solchen Datensatz gibt.
Also RIC,SUB und Zeit müssen Stimmen.
Wenn NEIN Datensatz rüber kopieren und aus der temp. Löschen.
Wenn JA wird geschaut wie lang die Texte sind.
Wenn er LÄNGER ist überschreiben (UPDATE) und aus der temp. löschen.
Wenn er KÜRZER ist nur löschen.

Weil so auch schlechte Meldungen angezeigt werden. Aber eben immer nur die beste.
Das ganze geht auch recht schnell. Als ich das Script eingebaut hatte waren ca 7000 Datensätze in der temp. Tabelle. Das hat dann doch ca 40 Sekunden gedauert.
Aber bei maximal 100 Datensätze wenn mal längere Zeit keiner auf der Seite war geht das fix. Und ab dann geht es ja sozusagen on the fly.

Großer Vorteil:
Wenn man Redundanz haben will. Ich kann hin gehen und wo anders auch einen RasPi hin stellen der schreibt in die selbe temp. Tabelle und es wird trotzdem immer nur der beste Datensatz übernommen.
Fällt einer aus läuft alles weiter über den anderen.

Was ich beim kopieren der Daten noch mit machen sind bestimmte Texte per HTML zu verändern. z.b. aus INT_NA wird <b>INT_NA</b>
Nachteil: ich ändere die Stammdaten. Das will ich eventuell noch ändern da nur beim Anzeigen die Veränderungen statt finden und in der DB alles original bleibt.

Habt ihr auch das Problem das monitord unregelmäßig abstürzt im Schnitt ca. alle 3 Tage einmal?

Kurz mal zu meinem Setup:
PC A: monitord <-> PC B: AllFMS via Port 9300

Gibt es die Möglichkeit einen detaillierten debug trace zu erstellen. Ich logge bereits im debug Level in ein Log jedoch steht dort nichts von einem Abbruch drin...

Bei mir schmiert der monitord eigentlich nur ab wenn die Soundkarte Probleme macht.
Bis jetzt was es immer so das ich den USB Port der Soundkarte resetten konnte und dann die Alsa-Settings restoren und dann monitord wieder starten.
Seit gestern habe ich nur noch Probleme!
Meiner Meinung nach das einzige was ich geändert habe ist einen neuen Pi (512MB) zu nehmen.
Ich habe jetzt den alten wieder drann der lief vorher ca 5 Wochen sauber durch.
Mal schauen obs wieder besser ist.

Problem ist eigentlich wie erkenne ich ob die Soundkarte noch geht.
Bei dem aktuellen Fehler war es so das der monitord das gar nicht gemerkt hat.
Soundkarte war dunkel und monitord lief fröhlich weiter.

Tja, keine Ahnung wie ich das noch abfragen kann

Ich könnte mich aufregen!
Es lief 4 Wochen am stück ohne Unterbrechungen und jetzt hält es nicht mal mehr eine halbe Stunde!

Mit:
cat /proc/asound/cards | grep -c "Creative Labs"
finde ich raus ob die Karte noch da ist. Leider stellt dies aber nicht sicher ob sie auch geht.

Mit:
amixer -c 1 2> sound.log
grep -c "error" sound.log
Versuche ich auf die Karte zu zu greifen um zu schauen ob sie funktioniert. Das scheint zu klappen.

Mit:
lsusb | grep "Creative" | awk '{print substr($4,1,3)}'
finde ich heraus auf welchen Port sie sich befindet.
um mit:
sudo ./usbreset /dev/bus/usb/001/$usbport
die Karte zu resetten
das C-Programm zum resetten der Karte findet man hier:
http://toothbrushsymphony.blogspot.d...pberry-pi.html

Gut jetzt merke ich zwar das es Probleme gibt und kann was da gegen tun nur währe mir der Zustand von vorher wo es noch lange lief lieber.
Ich weiß nicht woran es liegen könnte.

USB-Hub als Stromversorgung zwischen schalten habe ich probiert dann läuft aber definitiv die Auswertung schlecht!

Zitat:

---

Zitat von MueThoS

Ich könnte mich aufregen!
Es lief 4 Wochen am stück ohne Unterbrechungen und jetzt hält es nicht mal mehr eine halbe Stunde!

Mit:
cat /proc/asound/cards | grep -c "Creative Labs"
finde ich raus ob die Karte noch da ist. Leider stellt dies aber nicht sicher ob sie auch geht.

Mit:
amixer -c 1 2> sound.log
grep -c "error" sound.log
Versuche ich auf die Karte zu zu greifen um zu schauen ob sie funktioniert. Das scheint zu klappen.

Mit:
lsusb | grep "Creative" | awk '{print substr($4,1,3)}'
finde ich heraus auf welchen Port sie sich befindet.
um mit:
sudo ./usbreset /dev/bus/usb/001/$usbport
die Karte zu resetten
das C-Programm zum resetten der Karte findet man hier:
http://toothbrushsymphony.blogspot.d...pberry-pi.html

Gut jetzt merke ich zwar das es Probleme gibt und kann was da gegen tun nur währe mir der Zustand von vorher wo es noch lange lief lieber.
Ich weiß nicht woran es liegen könnte.

USB-Hub als Stromversorgung zwischen schalten habe ich probiert dann läuft aber definitiv die Auswertung schlecht!

---

Hi,

ich hatte bei mir mal die USB Geschwindigkeit reduziert von USB2 auf USB1.1 - aber ich weiß jetzt nicht mehr wie ich das gemacht habe. Den Vorschlag hatte ich aus einem Forum...

Läuft auf 1.1

ich mache gerade mal ein update / upgrade auf dem pi
Glaube zwar nicht das dies die Sache besser macht aber naja.

Ansonsten bleibt nur neu auf setzten

Alle ca 15 Minuten hängt sie sich auf.
Wenigstens merkt das Script das jetzt.

Hallo,

ich setze seit einigen Jahren erfolgreich die alte monitor Version 1.8.1 ein.
Habe jetzt nach Eurer Anleitung auch die monitord, auf dem Raspberry, für ZVEI zum Laufen bekommen.

Frage: Hat jemand von Euch die alte Monitor Version 1.8.1 auf dem Raspberry Pi zum Laufen gebracht?

Nachdem ich im Makefile

CFLAGS +=-Wall -g -O -DARCH_i386
else
CFLAGS +=-O3 -march=i486 -DARCH_i386


durch


CFLAGS +=-Wall -g -O -DARCH_armv6
else
CFLAGS +=-O3 -march=armv6 -DARCH_armv6


ersetzt habe, lief das make durch.

Wenn ich monitor starte, passiert aber nichts.


Gruß

Marcel

Ich würde wetten, das hängt am Sounddevice. Du musst mal schauen, welches Sounddevice Deine USB-Soundkarte (oder was verwendest Du sonst?) abbildet. Das muss dann entsprechend im Quelltext angepasst werden vor dem Compilieren.
Bekommst Du denn irgendwelche Fehlermeldungen, wenn Du monitor startest?

Gruß,
Funkwart

PS: Vielleicht solltest Du einen neuen Thread "monitor auf Raspberry Pi" aufmachen, damit hier nichts durcheinander kommt.

Hi,

ich habe an meinem Raspberry Pi per USB-HUB eine Sound Blaster Play!
angeschlossen.

Unter /dev/ gibt es audio und audio1.

In der Datei "unixinout.c", in Zeile 1395,
habe ich das Audio-Device "/dev/audio" geändert.
Habe aber auch /dev/audio1 und hw:1,0 getestet.


if ((fd = open(ifname ? ifname : "/dev/audio", O_RDONLY)) < 0) {


Es kommt einfach keine Ausgabe beim Aufruf von monitor.
Siehe Anhänge.

@all

hat jemand von Euch noch Kontakt zum Autor
von monitor 1.8.1 (Markus Grohmann)?
Oder ist er hier eventuell im Forum noch unterwegs?

Ich würde gerne die alte Monitor-Version weiter verwenden,
allerdings auf dem Raspberry Pi.

Über die Jahre habe ich mir einiges dazu gebastelt,
so das es eine brauchbare Lösung für 5-Ton Alarmierung ist.

Ich habe das ganze jetzt noch einmal unter Pidora probiert.
Make läuft durch. Bekomme aber auch hier keine Konsolenausgabe.

Ich vermute, das hängt mit dem ARM zusammen.

Hat eventuell noch jemand Tips für mich, oder könnte das mal probieren?


Gruß

Marcel

Also ich habe zwar keinen Pi, aber den alten monitor unter Ubuntu laufen. Ich hatte auch das Problem dass nichts ausgewertet wurde, das Problem war bei mir das der monitor noch OSS als Soundsystem erwartet, Ubuntu aber mittlerweile Alsa einsetzt. Es gibt aber eine Möglichkeit da eine Zwischenebene zu schalten, das Programm heißt AOSS. Der Aufruf erfolgt dann mittels

aoss monitor

Vielleicht hilft es dir ja weiter...


Grüße, Christoph

OSS hatte ich auch installiert.

Also hier noch einmal meine Frage:

Hat jemand von Euch noch Kontakt zum Autor
von monitor 1.8.1 (Markus Grohmann)?
Oder ist er hier eventuell im Forum noch unterwegs?

Hier ist ja etwas ruhiger geworden ...

Dennoch habe ich eine Frage. Hat jemand die Sache mit den Filtern (LUA-Skript) versucht? Ich habe gerade erst wieder ein System aufgesetzt, bei dem ich die Filter nicht hin bekomme.

Gruss
matt

Hallo matt,

ich hab beide Filter (plugin und socket) erfolgreich im Einsatz, wo hängt es denn?

Gruß

carrier92

Hallo carrier92,

wenn ich das nur wüsste. Ich habe alle notwendigen Plugins installiert und mit kompiliert. Monitord gibt im Debug-Modus auch nichts auffällig aus.

Zur Kontrolle habe ich in den Funktionen, welche von monitord aus den LUA-Dateien aufgerufen werden einfach mal ein print("test") eingefügt um zu sehen, ob sie überhaupt aufgerufen werden.
Auf dem Bildschirm bekomme ich diesbezüglich gar nichts...

Gruss
matt

kannst du mir den "configure" Befehl zeigen den du verwendet hast und hast du die Protokolldatei geprüft (config.log)

da sollte sowas stehen "checking lua.h usability" mit dem "Result: yes"

Mit diesem configure hab ich gearbeitet:
./configure --enable-plugins --with-alsa --with-mysql --with-lua-includes=/usr/include/lua5.1 --with-lua-suffix=5.1

Gruß

carrier92

Ich verwende den gleichen configure Befehl. Den habe ich ja vor einiger Zeit selbst hier gepostet:

./configure --enable-plugins --with-alsa --with-mysql --with-lua-includes=/usr/include/lua5.1 --with-lua-suffix=5.1

In der config.log sind alle Zeilen, die mit lua zu tun haben mit einem "result: yes" abgeschlossen.

Gerade eben habe ich nochmal ein komplett neues OS aufgesetzt und monitord installiert. Allerdings ohne Änderung. Trotz dem Befehl "print ('test')" in den Filterfunktionen wird nichts ausser die normalen DEBUG-Meldungen auf dem Bildschirm ausgegeben...

Führe ich die LUA-Skripte direkt (also ohne Monitord) aus, kommen die Bildschirmausgaben.

Sorry wusste nicht mehr das der configure Befehl von dir war.

Die Filter werden, soweit ich weis, nur ausgewertet wenn ein Client verbunden ist.

Im Anhang mal meine beiden lua scripte.

Der socketfilter wird ein Fehler beim aufrufen werfen da er keine Verbindung herstellen kann, aber man sieht somit daß das script überhaupt aufgerufen wird.

Im Pluginfilter wird gefilter was an die Datenbank gesendet wird.

Gruß
carrier92

Ich möchte das bei einem bestimmten ZVEI Alarmierung eine Email versendet wird.
Die Daten sind alle in einer Datenbank.

Wer kann mir helfen?

Hmm, keine guten Nachrichten.
Das Skript von carrier92 habe ich ausprobiert. Hab dafür nochmal ein komplett neues System aufgesetzt. Mit dem Skript hat es nicht funktioniert. Zudem ist mir aufgefallen, dass mir die Behringer UCA202 kurz nachdem ich Monitord gestartet habe abschmiert (LED aus)...

den UCA 202 hat bei mir nicht funktioniert, da ich den Eingangspegel nicht regel konnte.
Hast du eine alternative Soundkarte?

Ich kann auch mal versuchen dir mein PI image zu schicken, mit dem funktioniert es bei mir.

image senden wird doch nix (1,8GB) gepackt