// Weather.chrisge.org – Die Software III/III: Munin & Fazit

Nachdem ich das Projekt Weather.chrisge.org bereits in Grundzügen erläutert habe und die verwendete Hardware ebenfalls vorgestellt habe, werde ich in diesem Beitrag auf die Softwarekonfiguration eingehen. Da der gesamte Entwicklungsprozess mehrere Monate in Anspruch nahm, werde ich nur auf die wichtigsten Dinge eingehen. Zu einem späteren Zeitpunkt werde ich gegebenenfalls eine Dokumentation im mein.homelinux.com Wiki erstellt. Falls Fragen auftauchen sollten: melden!

Dieser Beitrag ist Teil der Serie Weather.chrisge.org:

Diese Anleitung dürfte mit Debian-basierende Linux-Distributionen (z.B. Ubuntu) kompatibel sein. Die Munin Plugins müssten aber auf jeder Linux Plattform funktionsfähig sein. Ich habe sie bis jetzt aber nur mit Debian Squeeze getestet.

Graphen: Munin

Die Graphen erzeuge ich mit Munin. Der Vorteil ist, dass ich die Graphen auf einem anderen System rendern kann, also die Wetterstation ein sehr leistungsschwaches System (nur Munin-Node) sein kann, während das andere System (Munin) die Daten graphed und präsentiert, wofür mehr Leistung erforderlich ist. Zu Munin habe ich bereits eine Anleitung geschrieben:

Darin wird die Architektur von Munin (Munin u. Munin-Node) sowie die Installation und die Einrichtung näher erläutert. Diese Anleitung ist absolute Basis für diese Anleitung. Munin muss bereits voll einsatzfähig und konfiguriert sein.

Plugins

Da kein Plugin finden konnte, dass meinen erwünschten Zweck erfüllt, musste ich selbst drei Munin-Plugins schreiben. Wie dies geht, wird im Munin Wiki beschrieben.

Die Plugins werden in /usr/share/munin/plugins/ gespeichert und anschließend nach /etc/munin/plugins verlinkt:

$ sudo ln -s /usr/share/munin/plugins/PLUGIN /etc/munin/plugins/
$ sudo /etc/munin/munin-node restart    #Munin-Node neustarten

Meine Plugins holen jew. noch die Daten von YAHOO! Weather und legen eine Statusdatei an, die immer den zuletzt ausgelesenen Wert anzeigen. Der Code ist nicht wirklich gesäubert und muss, wenn die Plugins verwendet werden sollen noch angepasst werden! Sie sollen nur Beispiele sein!
Folgendes muss angepasst werden:

  • Der Pfad zum Sensor
  • Das Statfile
  • Die URL zum YAHOO! Weather Wetterbericht

Hinweis: Die YAHOO! Weather Methode funktioniert nicht mehr! In diesem Post findest du eine funktionierende Lösung mit der Wunderground Weather API. Diese Plugins müssen noch angepasst werden! Wenn du Fragen hast, kannst du gerne einen Kommentar hinterlassen.

Luftfeuchtigkeit

humidity
#!/bin/sh
# Simple OWFS Humidity Munin Plugin
# Copyright: (C) 2012 Christoph Winkler <cw[at]chrisge[dot]org>
# Web: http://www.chrisge.org / http://weather.chrisge.org
# License: GPL-3 <http://www.gnu.org/licenses/gpl-3.0.txt>
 
if [ "$1" = "config" ]; then
 
echo 'graph_title Humidity (Luftfeuchtigkeit)'
echo 'graph_args --rigid'
echo 'graph_vlabel Relative Humidity in %'
echo 'graph_scale no'
echo 'graph_category Weather'
 
echo 'screen0.label Local Relative Humidity'
echo 'real0.label Adapted from YAHOO! Weather'
 
echo 'real0.draw LINE1'
 
exit 0
fi
 
TWC_TMP="/tmp/weather_twc_tmp"
wget "http://de.weather.com/weather/local/77746?x=0&y=0" -O $TWC_TMP > /dev/null 2>&1
 
REAL=$(cat $TWC_TMP | grep -A2 Luftfeuchtigkeit | tail -n 1 | cut -d '>' -f 2 | cut -d'%' -f1)
STATE_R="/tmp/humidity_r"
 
echo $REAL > $STATE_R
 
BASE="/media/owfs"
 
SENSOR_0="26.E67023010000"
STATE_0="/tmp/humidity_0"
 
if test -d ${BASE}/$SENSOR_0
then
  SCREEN_0=$(cat ${BASE}/$SENSOR_0/humidity ; echo)
  echo $SCREEN_0 > $STATE_0
  echo screen0.value $SCREEN_0
fi
 
echo real0.value $REAL

Temperatur

temperature
#!/bin/sh
# Simple OWFS Temperature Munin Plugin
# Copyright: (C) 2012 Christoph Winkler <cw[at]chrisge[dot]org>
# Web: http://www.chrisge.org / http://weather.chrisge.org
# License: GPL-3 <http://www.gnu.org/licenses/gpl-3.0.txt>
 
if [ "$1" = "config" ]; then
echo 'graph_title Temperatures (Temperaturen)'
echo 'graph_args --base 1000'
echo 'graph_vlabel Temperature in Celsius'
echo 'graph_category Weather'
echo 'graph_scale no'
 
echo "screen0.label Outdoor Sensor one"
echo "screen1.label Outdoor Sensor two"
echo "case0.label Outdoor in Sun"
echo "real0.label Adapted from YAHOO! Weather"
 
echo 'real0.draw LINE1'
 
exit 0
fi
 
BASE="/media/owfs"
 
SENSOR_0="26.E67023010000"
SENSOR_1="28.75798C020000"
SENSOR_2="28.4F523C020000"
 
STATE_0="/tmp/temperature_scr_0"
STATE_1="/tmp/temperature_scr_1"
STATE_2="/tmp/temperature_cas_0"
 
TWC_TMP="/tmp/weather_twc_tmp"
wget "http://de.weather.com/weather/local/77746?x=0&y=0" -O $TWC_TMP > /dev/null 2>&1
 
REAL=$(cat $TWC_TMP | grep '<TD COLSPAN="2"' | head -n 1 | cut -d ';' -f 2 | cut -d '&' -f 1)
STATE_R="/tmp/temperature_r"
 
echo $REAL > $STATE_R
 
if test -d ${BASE}/$SENSOR_0
then
  SCREEN_0=$(cat ${BASE}/$SENSOR_0/temperature ; echo)
  echo $SCREEN_0 > $STATE_0
  echo screen0.value $SCREEN_0
fi
 
if test -d ${BASE}/$SENSOR_1
then
  SCREEN_1=$(cat ${BASE}/$SENSOR_1/temperature ; echo)
  echo $SCREEN_1 > $STATE_1
  echo screen1.value $SCREEN_1
fi
 
if test -d ${BASE}/$SENSOR_2
then
  CASE_0=$(cat ${BASE}/$SENSOR_2/temperature ; echo)
  echo $CASE_0 > $STATE_2
  echo case0.value $CASE_0
fi
 
echo real0.value $REAL

Dewpoint

Der Dewpoint → Taupunkt kann aus der relativen Luftfeuchtigkeit sowie der Temperatur errechnet werden. Mein Plugin bassiert auf diesem Skript und benötigt unbedingt das Paket bc.

dewpoint
#!/bin/sh
# Simple OWFS Humidity Munin Plugin
# Copyright: (C) 2012 Christoph Winkler <cw[at]chrisge[dot]org>
# Web: http://www.chrisge.org / http://weather.chrisge.org
# License: GPL-3 <http://www.gnu.org/licenses/gpl-3.0.txt>
# Based On: http://www.lawbiz.ch/d/spahni/programs/relhumidity.html
 
if [ "$1" = "config" ]; then
echo 'graph_title Dewpoint (Taupunkt)'
echo 'graph_args --base 1000'
echo 'graph_vlabel Dewpoint in Celsius'
echo 'graph_category Weather'
echo 'graph_scale no'
 
echo "screen0.label Local Dewpoint"
echo "real0.label Adapted from YAHOO! Weather"
 
echo 'real0.draw LINE1'
exit 0
fi
 
BASE="/media/owfs"
 
SENSOR_0="26.E67023010000"
STATE_0="/tmp/dewpoint_0"
 
TEMPERATURE="$(cat ${BASE}/$SENSOR_0/temperature ; echo)"
HUMIDITY="$(cat ${BASE}/$SENSOR_0/humidity ; echo)"
 
TWC_TMP="/tmp/weather_twc_tmp"
wget "http://de.weather.com/weather/local/77746?x=0&y=0" -O $TWC_TMP > /dev/null 2>&1
 
REAL=$(cat $TWC_TMP | grep -A2 Taupunkt | tail -n 1 | cut -d '>' -f 2 | cut -d'&' -f1)
STATE_R="/tmp/dewpoint_r"
 
echo $REAL > $STATE_R
 
if test -d ${BASE}/$SENSOR_0
then
SCREEN_0=$(echo "define pa (n) {
         if (n >= 0.0) {
            return (7.5);
         } else {
            return (7.6);
         }
      }
 
      define pb (n) {
         if (n >= 0.0) {
            return (237.3);
         } else {
            return (240.7);
         }
      }
 
      define sdd (t) {
         return (6.1078 * e( l(10) * ((pa(t) * t) / (pb(t) + t)) ) );
      }
 
      define dd (r,t) {
         return (r / 100.0 * sdd(t));
      }
 
      /* factor 2.302585093 converts ln() to log() */
      v  = l(dd($HUMIDITY,$TEMPERATURE) / 6.1078) / 2.302585093;
      tp = ((pb($TEMPERATURE) * v) / (pa($TEMPERATURE) - v));
 
      if ( tp >= 0.0 ) {
         tp = (tp + 0.05);
      } else {
         tp = (tp - 0.05);
      }
 
      scale = 4;
      (tp / 1.0); " | bc -l)
 
  if [ "$(echo $SCREEN_0 | head -c 1)" = "." ] ; then SCREEN_0=0${SCREEN_0}
    elif [ "$(echo $SCREEN_0 | head -c 2)" = "-." ] ; then SCREEN_0=-0${SCREEN_0#-}
  fi
 
  echo $SCREEN_0 > $STATE_0
  echo screen0.value $SCREEN_0
 
fi
 
echo real0.value $REAL

Fazit & Ausblick

Inspiriert wurde ich durch Dave's & Max's Weather-Station/Cam von der ich damals in Doozan's Forum erfahren habe. Das ganze Projekt war eine einzige große Bastelei. Ich hatte zu keinem einzigen Baustein eine vollständige Dokumentation. Letzten Endes habe ich nach einigem Herumprobieren dann doch immer eine Lösung gefunden. Unter anderem deshalb habe ich das Grundgerüst für andere Bastler dokumentiert. Wenn dir Angaben fehlen oder etwas unklar erscheint, stehe ich dir gerne zur Verfügung.

Es ist immer wieder erstaunlich zu sehen, was man mit kleiner Embedded ARM-Hardware so alles hin bekommt. Als nächstes werde ich den 1-Wire Bus durch weitere Sensoren erweitern und ggf. das System in ein wetterfestes Gehäuse draußen platzieren - im Moment steht es noch drinnen. In diesem Zusammenhang warte ich auf den Raspberry Pi, der für eine Wetterstation wirklich genial ist.

Probleme

Das größte Problem ist, dass der USB-Hub in unregelmäßigen Abständen resetet wird und der 1-Wire Adapter dann nicht mehr als ttyUSB0 sondern ttyUSB1 angemeldet wird. OWFS verliert dann den Bus, bis der Adapter abgesteckt und erneut angeschlossen wird (erscheint wieder las ttyUSB0).
Manchmal verliert Motion bei diesem Vorfall die Webcam, beendet sich und muss anschließend wieder gestartet werden.

// Weather.chrisge.org – Die Software II/III: OWFS

Nachdem ich das Projekt Weather.chrisge.org bereits in Grundzügen erläutert habe und die verwendete Hardware ebenfalls vorgestellt habe, werde ich in diesem Beitrag auf die Softwarekonfiguration eingehen. Da der gesamte Entwicklungsprozess mehrere Monate in Anspruch nahm, werde ich nur auf die wichtigsten Dinge eingehen. Zu einem späteren Zeitpunkt werde ich gegebenenfalls eine Dokumentation im mein.homelinux.com Wiki erstellt. Falls Fragen auftauchen sollten: melden!

Dieser Beitrag ist Teil der Serie Weather.chrisge.org:

Dieser Post ist bezüglich OWFS Verwendung (nicht Installation) nur für die in den obigen Beiträgen vorgestellte 1-Wire Hardware gültig, kann aber problemlos auf andere übertragen werden. Kompatible Betriebssysteme sollten Debian-basierende Linux-Distributionen (z.B. Ubuntu) sein. Ich habe sie bis jetzt aber nur mit Debian Squeeze getestet.

1-Wire: OWFS

Um die Werte der Sensoren auszulesen verwende ich, wie bereits erwähnt OWFS. Da OWFS nicht in den Paketquellen vorhanden ist, muss es manuell kompilieren werden. Dazu findet sich hier eine detaillierte Anleitung.

Vorbereitungen

Zuerst müssen diverse Kernelmodule deaktiviert werden:

$ sudo modprobe -r ds9490r
$ sudo modprobe -r ds2490
$ sudo modprobe -r wire

…und anschließend in die /etc/modprobe.d/blacklist eingetragen werden:

# OWFS via libusb
blacklist ds9490r
blacklist ds2490
blacklist wire

Nun werden die für das Kompilieren benötigten Pakete installiert:

$ sudo apt-get install build-essential automake autoconf autotools-dev gcc g++ libtool fuse-utils libfuse-dev swig python2.5-dev tcl8.4-dev php5-dev

Kompilieren

libusb

Hier ist es wichtig darauf zu achten, dass man libusb-0.1 (LEGACY) verwendet und in jenem Unterverzeichnis die aktuellst Version bezieht. Zur Zeit dieses Posts wäre dies diese URL:

http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/libusb-0.1.12.tar.gz/download

libusb lade ich mit wget wie folgt herunter (wer lieber seinen Browser verwendet, kann gerne jenen verwenden und die Datei nachher an den richtigen Ort verschieben):

$ wget http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/libusb-0.1.12.tar.gz/download -O libusb.tar.gz
$ tar xvzf libusb.tar.gz
$ cd libusb-0.1.12/

Nun kompilieren wir libusb:

libusb-0.1.12$ make
libusb-0.1.12$ sudo make install

Folgender Befehl (hier hat die verlinkte Anleitung einen Fehler):

$ libusb-config --version

…sollte 0.1.12 ausgeben.

OWFS

Zuerst besorgt man sich die aktuellste Version von OWFS auf sourceforge.net. In diesem Fall (Stand: Apr. 2012) lautet die URL wie folgt:

http://sourceforge.net/projects/owfs/files/latest/download?source=files

OWFS wird nun wie folgt heruntergeladen (Browser: siehe libusb:

$ wget http://sourceforge.net/projects/owfs/files/latest/download?source=files -O owfs.tar.gz

Nun entpacken wir das Paket:

$ tar xvzf owfs.tar.gz
$ cd owfs-2.8p14/

…anschließend kann der Build beginnen:

owfs-2.8p14$ ./configure --enable-debian
owfs-2.8p14$ make
owfs-2.8p14$ sudo make install

Erster Start

Wer OWFS ohne root-Rechte verwenden will, muss wie in der verlinkten Anleitung beschrieben noch etwas Hand an udev anlegen. Wer auf Nummer sicher gehen will, sollte diesen zusätzlichen Schritt durchführen. Dann könnte OWFS sowie OWSERVER ohne root-Rechte gestartet werden.

Ansonsten kann der 1-Wire Adapter (in meinem Fall der LinkUSB) mit dem fertigen 1-Wire Netz an den Rechner gehängt werden. Da jener Adapter über einen Seriellen Converter verfügt, müssten die benötigten Kernel Module normalerweise automatisch nachgeladen werden. Dies kann anhand der Ausgabe von dmesg | grep usb oder dem Syslog überprüft werden. Dort sollte folgende Meldung erscheinen:

[ 5996.029323] usb 1-1.2.4: new full speed USB device using orion-ehci and address 83
[ 5996.166193] usb 1-1.2.4: New USB device found, idVendor=0403, idProduct=6001
[ 5996.173435] usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5996.181097] usb 1-1.2.4: Product: FT232R USB UART
[ 5996.185945] usb 1-1.2.4: Manufacturer: FTDI
[ 5996.190237] usb 1-1.2.4: SerialNumber: A900fxuD
[ 5996.205792] usb 1-1.2.4: configuration #1 chosen from 1 choice
[ 5996.227183] usb 1-1.2.4: Detected FT232RL
[ 5996.231342] usb 1-1.2.4: Number of endpoints 2
[ 5996.235939] usb 1-1.2.4: Endpoint 1 MaxPacketSize 64
[ 5996.241057] usb 1-1.2.4: Endpoint 2 MaxPacketSize 64
[ 5996.246139] usb 1-1.2.4: Setting MaxPacketSize 64
[ 5996.252885] usb 1-1.2.4: FTDI USB Serial Device converter now attached to ttyUSB0

Sollte dies nicht der Fall sein, kann die Installation des Paketes libftdi1 helfen.
Aus der letzten Zeile geht hervor, dass der Adapter über /dev/ttyUSB0 angesprochen werden kann. OWFS (genauer gesagt OWSERVER) wird nun so gestartet:

$ sudo /opt/owfs/bin/owserver -p 4304 -d /dev/ttyUSB0 -t 30 --link --error_level 9

Aus einem mir bis jetzt unbekannten Grund, ist der Bus direkt nach dem Start nicht benutzbar. Ich warte normalerweise 5-10 Minuten und starte erst dann OWFS und binde damit den Bus als „Dateisystem“ ein:

$ sudo mkdir /media/owfs    #Anlegen des Mountpoints
$ sudo /opt/owfs/bin/owfs -s localhost:4304 --allow_other /media/owfs

Sollte das mit einer Fehlermeldung enden, dass kein 1-Wire Bus gefunden werden konnte, wartet man am besten einfach noch mal ein paar Minuten. Diese Unberechenbarkeit ist der Grund, dass ich kein Startskript einsetze, sondern OWFS immer per Hand starte. Das Problem liegt wahrscheinlich an der verwendeten Hardwarekonfiguration (Dockstar, USB-Hub und LinUSB) - mit einer anderen, könnte es ohne Probleme funktionieren.

Zusätzlich starte ich noch OWHTTPD:

$ /opt/owfs/bin/owhttpd -p 4305 -s localhost:4304

….und rufe nun die URL

http://host:4305

auf, die ein Listing des Buses anzeigt. Hier kann ich auch die Werte der Sensoren auslesen.

Werte auslesen

In obigem Beispiel wurde der Bus in /media/owfs gemountet. Folgendes befindet sich nun in dem Verzeichnis:

$ ls /media/owfs/
26.E67023010000  28.4F523C020000  28.75798C020000  alarm  bus.0  settings  simultaneous  statistics  structure  system  uncached

Die ZAHL.BLABLA benannten Verzeichnisse sind die IDs der Sensoren, in dem Verzeichnis befinden sich dann die Werte:

$ ls /media/owfs/26.E67023010000/
address  B1-R1-A  crc8  disconnect  endcharge  HIH3600  HTM1735   IAD  locator      offset  r_address  r_locator  temperature  udate  VDD
alias    CA       date  EE          family     HIH4000  humidity  id   MultiSensor  pages   r_id       S3-R1-A    type         VAD    vis

Der obige Sensor ist ein MS-TH, d.h. er verfügt über Temperatur und Luftfeuchtigkeit:

$ cat /media/owfs/26.E67023010000/humidity ; echo
     41.4725
$ cat /media/owfs/26.E67023010000/temperature ; echo
      7.5625

So kann man mit cat ganz einfach die Werte auslesen. Die Verwendung in Skripten ist somit wirklich einfach.

// Weather.chrisge.org – Die Software I/III: Motion

Nachdem ich das Projekt Weather.chrisge.org bereits in Grundzügen erläutert habe und die verwendete Hardware ebenfalls vorgestellt habe, werde ich in diesem Beitrag auf die Softwarekonfiguration eingehen. Da der gesamte Entwicklungsprozess mehrere Monate in Anspruch nahm, werde ich nur auf die wichtigsten Dinge eingehen. Zu einem späteren Zeitpunkt werde ich gegebenenfalls eine Dokumentation im mein.homelinux.com Wiki erstellt. Falls Fragen auftauchen sollten: melden!

Dieser Beitrag ist Teil der Serie Weather.chrisge.org:

Kompatibel zu dieser Anleitung sollten Debian-basierende Linux-Distributionen (z.B. Ubuntu) sein. Getestet wurde die Anleitung bis jetzt aber nur mit Debian Squeeze.

Webcam: Motion

Zur Überwachung der Webcam verwende ich Motion. Motion verfügt über zahlreiche Features, die die Software nicht nur für Überwachungskameras, sondern auch für Livecams interessant macht. Zum einen wäre da der Livestreamsupport, automatische Timelapses, regelmäßige Snapshots und die Möglichkeit Bewegungen aufzuzeichnen.

Motion kann in Debian ganz einfach installiert werden:

$ sudo apt-get install motion uvccapture libv4l-0

Dazu installieren wir zum Testen noch uvccapture und das benötigte Video4Linux.

Webcam testen

Mit Hilfe von Video4Linux sollte es nun möglich sein, die Webcam unter Linux zu nutzen. Die Informationen zu diesem Schritt stammen aus dieser Anleitung. Zunächst schließt man die Webcam an den Rechner und beobachtet die Ausgabe von dmesg | tail (auch im Syslog) - diese sollte etwa so aussehen:

[618864.131947] usb 1-1.2.2: new high speed USB device using orion-ehci and address 84
[618864.484692] usb 1-1.2.2: New USB device found, idVendor=046d, idProduct=0825
[618864.491961] usb 1-1.2.2: New USB device strings: Mfr=0, Product=0, SerialNumber=2
[618864.499615] usb 1-1.2.2: SerialNumber: 7FB273A0
[618864.509173] usb 1-1.2.2: configuration #1 chosen from 1 choice
[618864.516449] uvcvideo: Found UVC 1.00 device <unnamed> (046d:0825)
[618864.623982] input: UVC Camera (046d:0825) as /devices/platform/orion-ehci.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/input/input3
[618864.641837] usbcore: registered new interface driver uvcvideo
[618864.652312] USB Video Class driver (v0.1.0)

Dann testet man die Webcam mit Hilfe von uvccapture:

$ uvccapture

das sollte ein Bild mit dem Namen snap.jpg mit Hilfe der Webcam aufnehmen.

Konfiguration

Die Konfiguration von Motion erfolgt (wenn nur eine Webcam verwendet wird) über die sehr gut kommentierte Konfigurationsdatei in /etc/motion/motion.conf. Das Finden der richtigen Konfiguration ist ein Prozess, der über mehrere Tage in der Praxis erprobt werden muss. Für jeden Fall bietet sich eine andere Konfiguration an. Deshalb werde ich hier nur auf die wichtigsten Punkte eingehen. Eine umfangreiche Dokumentation aller Parameter findet sich im Motion Wiki:

Außerdem ist im LinuxUser ein guter Artikel zu Motion erschienen:

Als Daemon starten

Um Motion automatisch als Daemon starten zu lassen ist es nötig in der Datei /etc/default/motion die Option start_motion_daemon auf yes zu setzen:

start_motion_daemon=yes

Die weitere Konfiguration erfolgt in der /etc/motion/motion.conf. Auch hier muss die Option daemon auf on gesetzt werden:

daemon on

Basiseinstellungen

Anschließend können die Grundeinstellungen der Webcam vorgenommen werden. Hier bietet es sich vor allem an die Auflösung zu verändern - z.B. 960 x 720:

# Image width (pixels). Valid range: Camera dependent, default: 352
width 960

# Image height (pixels). Valid range: Camera dependent, default: 288
height 720

Diese Einstellung bedarf einiges an Erprobung. So muss die Hardware über genügend Leistung verfügen eine Auflösung wie 1280 x 960 tatsächlich zu packen. Bei der Dockstar war dies nicht der Fall. Außerdem muss die Kamera die Auflösung natürlich unterstützen.

Eine weitere Möglichkeit mit schwacher Hardware aufzukommen ist, die Option minimum_frame_time zu erhöhen. Bei 5 wird alle 5 Sekunden ein Bild der Kamera aufgenommen:

minimum_frame_time 5

Bewegungen erkennen

Um das Erkennen von Bewegungen zu konfigurieren, existiert der Bereich Motion Detection Settings. Hier kann zum Einen der threshold (die Empfindlichkeit) erhöht werden. Mehr Informationen hierzu finden sich im Artikel des LinuxUsers.

Ich habe zusätzlich die Einstellungen für pre- und post_capture modfiziert - das hat schönere „Motions“ zur Folge (Bilder von vor und nach der Erkennung der Bewegung):

# Specifies the number of pre-captured (buffered) pictures from before motion
# was detected that will be output at motion detection.
# Recommended range: 0 to 5 (default: 0)
# Do not use large values! Large values will cause Motion to skip video frames and
# cause unsmooth mpegs. To smooth mpegs use larger values of post_capture instead.
pre_capture 2

# Number of frames to capture after motion is no longer detected (default: 0)
post_capture 2

Ausgabedateien – Bilder & Co.

Wenn die Option output_normal aktiviert wird, werden von den Motions zusätzlich noch Bilder gemacht:

output_normal on

…hier kann noch die Qualität dieser Bilder (und weiterer) verändert werden:

quality 100

Wenn die Bilder später weiter verwendet werden sollen, ist eine hohe Qualität zu empfehlen. Dies fordert aber wesentlich mehr Speicherplatz!

In dem Abschnitt FFMPEG related options finden im Bezug auf die zu produzierenden Daten die wichtigsten Einstellungen statt. ffmpeg_cap_new hat zur Folge, dass Motions aufgenommen werden:

ffmpeg_cap_new on

Mit ffmpeg_timelapse kann der Intervall der einzelnen Bilder für die Timelapse definiert werden:

ffmpeg_timelapse 30

Ich empfehle die Option ffmpeg_variable_bitrate auf 2 zu setzen, ansonsten haben die Timelapses später keine gute Qualität:

ffmpeg_variable_bitrate 2

Mit Hilfe der Option snapshot_interval können regelmäßig Snapshots angefertigt werden:

snapshot_interval 120

Dateipfade

Die Option target_dir gibt an, wo die Dateien landen:

target_dir /media/webcam/motion

Die weiteren Filenames sehen bei mir so aus:

snapshot_filename ../snapshots/%Y%m%d/%H%M%S-%v-snapshot
jpeg_filename %Y%m%d/%v/%H%M%S-%v-%q
movie_filename ../films/%Y%m%d%H%M%S-%v
timelapse_filename ../timelapse/%Y%m%d-timelapse

Das hat zu Folge, dass /media/webcam bei mir so aussieht:

$ ls /media/webcam/
films  motion  snapshots  timelapse

So können die Dateien wesentlich besser verwaltet werden, als in den Standarteinstellungen.

Livecam

Anschließend kann der Live Webcam Server aktiviert werden:

webcam_port 8080

Damit andere Rechner auch die Livecam verwenden können, muss webcam_localhost deaktiviert werden:

webcam_localhost off

Benachrichtigungen

Wenn man informiert werden will, wenn die Kamera „verloren geht“ kann man zusätzlich die Option on_camera_lost nutzen:

on_camera_lost echo "Kamera %t am %d.%m.%Y um %T verloren." | mail -s "[Motion] Kamera verloren" root@localhost

Hier wird beispielsweise eine E-Mail an root@localhost gesendet.

Erster Start

Nachdem die wichtigsten Parameter gesetzt wurden, kann man nun Motion das erste Mal starten:

sudo /etc/init.d/motion start

Gleichzeitig sollte man einen Blick in das Syslog werfen:

$ tail -f /var/log/syslog

Dort sollten Meldungen in folgender Art auftauchen:

Apr  9 15:04:06 host motion: [0] Processing thread 0 - config file /etc/motion/motion.conf
Apr  9 15:04:06 host motion: [0] Motion 3.2.12 Started
Apr  9 15:04:06 host motion: [0] Created process id file /var/run/motion/motion.pid. Process ID is 8379
Apr  9 15:04:06 host motion: [0] Motion running as daemon process
Apr  9 15:04:06 host motion: [0] ffmpeg LIBAVCODEC_BUILD 3412993 LIBAVFORMAT_BUILD 3415808
Apr  9 15:04:06 host motion: [0] Thread 1 is from /etc/motion/motion.conf
Apr  9 15:04:06 host motion: [0] motion-httpd/3.2.12 running, accepting connections
Apr  9 15:04:06 host motion: [0] motion-httpd: waiting for data on port TCP 8081
Apr  9 15:04:06 host motion: [1] Thread 1 started
Apr  9 15:04:06 host motion: [1] cap.driver: "uvcvideo"
Apr  9 15:04:06 host motion: [1] cap.card: "UVC Camera (046d:0825)"
Apr  9 15:04:06 host motion: [1] cap.bus_info: "usb-orion-ehci.0-1.2.2"
Apr  9 15:04:06 host motion: [1] cap.capabilities=0x04000001
Apr  9 15:04:06 host motion: [1] - VIDEO_CAPTURE
Apr  9 15:04:06 host motion: [1] - STREAMING
Apr  9 15:04:06 host motion: [1] Config palette index 8 (YU12) doesn't work.
Apr  9 15:04:06 host motion: [1] Supported palettes:
Apr  9 15:04:06 host motion: [1] 0: YUYV (YUV 4:2:2 (YUYV))
Apr  9 15:04:06 host motion: [1] 1: MJPG (MJPEG)
Apr  9 15:04:06 host motion: [1] Selected palette YUYV
Apr  9 15:04:06 host motion: [1] Test palette YUYV (960x720)
Apr  9 15:04:06 host motion: [1] Using palette YUYV (960x720) bytesperlines 1920 sizeimage 1382400 colorspace 00000008
Apr  9 15:04:06 host motion: [1] found control 0x00980900, "Brightness", range 0,255 
Apr  9 15:04:06 host motion: [1] #011"Brightness", default 128, current 128
Apr  9 15:04:06 host motion: [1] found control 0x00980901, "Contrast", range 0,255 
Apr  9 15:04:06 host motion: [1] #011"Contrast", default 32, current 32
Apr  9 15:04:06 host motion: [1] found control 0x00980902, "Saturation", range 0,255 
Apr  9 15:04:06 host motion: [1] #011"Saturation", default 32, current 32
Apr  9 15:04:06 host motion: [1] found control 0x00980913, "Gain", range 0,255 
Apr  9 15:04:06 host motion: [1] #011"Gain", default 0, current 0
Apr  9 15:04:06 host motion: [1] mmap information:
Apr  9 15:04:06 host motion: [1] frames=4
Apr  9 15:04:06 host motion: [1] 0 length=1382400
Apr  9 15:04:06 host motion: [1] 1 length=1382400
Apr  9 15:04:06 host motion: [1] 2 length=1382400
Apr  9 15:04:06 host motion: [1] 3 length=1382400
Apr  9 15:04:09 host motion: [1] Resizing pre_capture buffer to 1 items
Apr  9 15:04:10 host motion: [1] Started stream webcam server in port 8080
Apr  9 15:04:10 host motion: [1] Resizing pre_capture buffer to 3 items

Ist das nicht der Fall hilft folgender Befehl:

$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so

…und ein anschließender start (oder restart, wenn motion noch läuft):

$ sudo /etc/init.d/motion start

Nun sollte Motion laufen und die ersten Aufnahmen produzieren.

Optimierung

Wenn die Livcam statt über Port 8080 über Port 80 ansprechbar sein soll, empfiehlt sich eine Portweiterleitung. Grund: Port 80 kann nur mit root-Rechten verwendet werden. Es gibt zwar diverse Tools, die Port 80 für bestimmte Programme verfügbar machen. Das hat in meinen Versuchen mit motion allerdings nicht funktioniert (motion kann dann nicht mehr auf die Webcam zurückgreifen). Eine Portweiterleitung von 80 auf 8080 richtet man so ein (iptables benötigt):

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080

Da dies bei jedem Neustart wieder erforderlich ist, trägt man in der /etc/rc.local vor das exit 0 folgendes ein:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080

Besonders die Verwendung eines Maskfiles, wie hier erklärt kann helfen Störquellen wie Bäume auszuschalten. Zusätzlich kann man am threshold und area_detect sowie an despeckle rumschrauben, bis die Einstellungen optimal sind. Hier empfiehlt sich ein Blick in die Dokumentation von Motion.

// Weather.chrisge.org – Die Hardware

Nachdem ich das Projekt Weather.chrisge.org bereits in Grundzügen vorgestellt habe, werde ich nun detaillierter auf die verwendete Hardware eingehen. Da der gesamte Entwicklungsprozess mehrere Monate in Anspruch nahm, werde ich nur auf die wichtigsten Dinge eingehen. Falls Fragen auftauchen sollten: melden!

Dieser Beitrag ist Teil der Serie Weather.chrisge.org:

Das Basissystem

Als Basissystem verwende ich eine Seagate Dockstar mit Debian Squeeze. Da das System nur 128 MB RAM und einen ARM Prozessor mit 1,2 GHz verfügt, muss natürlich beachtet werden, dass die verwendete Software möglichst Ressourcen schonend ist. Unter anderem deshalb kann es hilfreich sein, zum Rendern der Daten einen anderen Server zu verwenden und ein sparsames ARM-System nur zum Sammeln und Bereitstellen der Datensätze für den anderen Server zu verwenden. Eine Munin Installation kann hier somit ideal eingesetzt werden.

Eine Übersicht über derzeit verfügbare ARM-Hardware habe ich schon vor längerem auf mein.homelinux.com veröffentlicht:

Speicherplatz

Wenn Motion mit den höchsten Einstellungen bezüglich der Qualität der Bilder bzw. Aufnahmen verwendet wird, können an einem windigen Tag (….und Wolken ohne Ende) täglich schon einmal 1-3 GB an Daten zusammenkommen. Hierfür verwende ich einen 16 GB USB-Stick, der in der Nacht auf einen RAID 1 auf einem anderen Server gesichert werden. Dies ist nicht nur auf Grund des beschränkte Platzbedarfes (damit man auf dem USB nach der Sicherung die Dateien löschen kann) sondern vor allem im Hinblick auf die „Halbbarkeit“ des USB-Sticks - ich habe auf Dockstars bereits 2 Sticks ins Grab geschickt (kaputt geschrieben) - sinnvoll.
Aber, da eine externe Festplatte zu laut wäre und eine SSD zu teuer und sinnlos via USB, werde ich diese Methode wohl oder übel so beibehalten.

Webcam

Zum einen muss die Webcam von Motion unterstützt werden, zum anderen sollte die Bildqualität in einem akzeptablen Rahmen liegen. Es sollte vor allem darauf geachtet werden, dass die Webcam auch mit schlechten Lichtverhältnissen zurechtkommt. Im Endeffekt kann jede Webcam verwendet, die mit video4linux funktioniert, denn dieses setzt Motion ein.

Ich habe mich für eine Logitech HD Webcam C270 (meine hat ein anderes Design als die auf der Logitech Seite) entschieden. Nachträglich würde ich eher eine bessere nehmen, da die C270 gerade bei schlechten Lichtverhältnissen nicht unbedingt eine gute Form macht.

Positionierung

Da ich die Webcam nicht draußen anbringen wollte, musste ich die Webcam innen hinter einer Scheibe platzieren. Das größte Problem hierbei war, dass die Scheibe natürlich spiegelt und das überwiegend dann, wenn Licht von hinten, also von innen auf die Scheibe fällt. So habe ich wie in den Bildern ersichtlich versucht, die Befestigung der Webcam komplett zu verdunkeln. Das ist mir auch relativ gut gelungen. Anschießend muss die Webcam richtig ausgerichtet werden, dazu schließt man jene am besten an einen anderen Rechner an.

Ich kann nur empfehlen, die Webcam so zu platzieren, dass möglichst viel vom Himmel zu sehen ist, also eher eine Ausrichtung in die „Höhe“ als in die „Ferne“. So sind Nachts mehr Sterne erkennbar. Außerdem bietet es sich an, das komplette System draußen zu platzieren.

1-Wire Sensoren und Adapter

Was wäre eine Wetterstation ohne Sensoren? Ich wollte keine fertige Wetterstation wie z.B. die WH1080, da dies mir zu „einfach“ schien - Ich wollte alles selbst basteln und mir die Möglichkeit vorenthalten später eigene Sensoren zu entwerfen (bei 1-Wire relativ einfach) bzw. das sogenannte 1-Wire Netzwerk durch weitere Sensoren jeglicher Art zu erweitern (UV, Solar, Luftdruck, usw.).

1-Wire Sensoren und Equipment gibt es beispielsweise hier:

Ich habe mich relativ schnell für Sensoren von iButtonLink entschieden, da diese (fast! alle) problemlos von der zu verwendenden Software OWFS unterstützt werden. Diese Sensoren gibt es sowohl bei Fuchs Elektronik, als auch bei HomeChip. HomeChip ist zwar billiger, aber durch die Versandkosten gleicht sich das ziemlich schnell mit Fuchs Elektronik aus. Folglich habe ich folgendes Equipment bei Fuchs (Sensoren, Adapter) und Amazon bestellt:

  • 2 x T-Sense (Temperatursensor)
  • 1 x MS-TH (Luftfeuchtigkeit und Temperatur)
  • 1 x LinkUSB (USB-Adapter) → die i-Variante soll auch mit OWFS funktionieren
  • div. Patchkabel (1-Wire wird mit „Lankabeln“ verkabelt)

→ Um zu überprüfen, ob ein Sensor mit OWFS funktioniert, einfach nach [Sensor] OWFS googlen. Die Webseite von OWFS ist leider nicht gerade übersichtlich.

Bald werden noch diese Sensoren folgen:

Verkabeln

Eine grundlegende Einführung in das 1-Wire System findet sich auf HobbyBoards. Wie daraus hervorgeht bestehen folgende Möglichkeiten:

  • Daisy Chain Netzwerk: der Adapter am Rechner wird mit dem Eingang des 1ten Sensors verbunden; dessen Ausgang wird mit dem Eingang des 2ten Sensors verbunden; usw.
  • Star Netzwerk: alle Eingänge der Sensoren werden mit einem Hub verbunden; dieser wird an den Adapter des Rechners verbunden
  • Diese beiden Arten lassen sich natürlich kombinieren!

Als Verbindung dient jew. Patchkabel (in meinem Fall RJ45).

Hobbyboards

Die Sensoren von HobbyBoards besitzen RJ45 Anschlüsse und der zugehörige Adapter verfügt über einen RJ11/12 (Telefonkabel) Anschluss. Somit wird hier ein Adapterstück benötigt. Außerdem benötigen einige Sensoren einen „Power Injector“, da die Stromversorgung über den Bus nicht ausreicht.
Hier muss mit einigem an mehr Kosten gerechnet werden! Zudem ist es ratsam bei dem Betreiber des Shops vorher nachzufragen, ob das Setup so funktioniert.

Hier ist einiges einfach: Der Adapter (LinkUSB[i]) sowie die Sensoren verfügen über den gleichen Anschluss (RJ45), wobei darauf geachtet werden muss, das nicht doch ein anderer Adater mit RJ11/12 wie z.B. der DS9490R bestellt werden. Auch bei iButtonLink gibt es zusätzliche Stromversorgungen (Achtung: ohne Netzgerät!), die nur benötigt werden, falls die Versorgung des Adapters nicht mehr ausreicht.

Mein Setup folgte der Daisy Chain Typologie, somit benötigte ich keinen Hub (den es bei iButtonLink auch gibt) und auf Grund der passenden Anschlüsse auch keine Adapter vor dem eigentlichen Computer Adapter. Eine zusätzliche Versorgung des Buses war ebenfalls nicht von Nöten. So folgten bei mir direkt nach dem Computer Adapter die eigentlichen Sensoren, die einfach nur mit Patchkabel verbunden waren.

Andere

Bei Verwendung anderer 1-Wire Hardware unbedingt auf Anschlüsse und sonstige Voraussetzungen achten!

Radiation Shield / Screen

Wie du bereits in vorherigem Post erfahren hast, waren die ersten Versuche mit den Sensoren nicht sehr überzeugend. Die Temperatur und Luftfeuchtigkeit wich bei Sonneneinstrahlung in extremen Maße ab – kein Wunder: die Sensoren sind schwarz! Folglich musste ein sog. Radiation Shield her. Hier nur ein paar Anleitungen dazu:

Ich habe meinen Screen aus Blumentöpfen hergestellt. Dazu kauft man etwa 12 (weiße! → ich musste meine braunen nachträglich lackieren) Untersetzer mit einem Durchmesser von ungefähr 20-30 cm. Dabei sollten die oberen Beiden einen 2-5 cm größeren Durchmesser besitzen. Nun wird so vorgegangen:

  1. Löcher bohren u. bei allen bis auf dem unteren, sowie den beiden oberen die Mitte herausschneiden (am besten mit einer Blechschere)
  2. Anschließend werden die Untersetzer wie in obig aufgeführten Anleitungen beschrieben, mit Gewindestangen zusammengesetzt. Der Abstand zwischen den einzelnen Untersetzern muss experimentell ermittelt werden, sollte aber bei etwa 1-3 cm liegen. Die einzelnen Untersetzer können entweder durch Verwendung von haufenweise Muttern oder von Abstandhaltern an den Gewindestangen befestigt werden.
  3. Die Sensoren werden an dem 2t obersten Untersetzer befestigt; die Kabel am besten unten (am letzten) herausgeführt.
  4. Alles weitere den erwähnten Anleitungen oder folgenden Bildern entnehmen:

Da ich nur einen T-Sense und den MS-TH in dem Shield platziert hatte, stand mir noch ein T-Sense zur Verfügung. Diesen habe ich in extra Gehäuse gepackt, in das ich Löcher gebohrt und anschließend weiß lackiert habe. Hier das Ergebnis:

→ Der Sensor wird als Outdoor in Sun gemonitored.

Hello World!

This is the personal website of Christoph Winkler.
Here you will find a sort of blog and some information about me and my projectshave fun!

Recent Comments
Latest Tweets

Follow me on Twitter...

QR-Code: aktuelle Seiten-URL
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 3.0 Unported