// Jahresrückblick: Jahresraffer & Wettergraphen 2013

Auch für dieses Jahr habe ich wieder eine Timelapse aus täglichen Snapshots zusammengestellt. Diese wurden immer um 17 Uhr in der Zeitspanne vom 29.12.2012 bis zum 29.12.2013 aufgenommen und anschließend mit ffmpeg zusammengesschnitten. Leider hatte ich – wie unschwer ersichtlich – auch dieses Jahr wieder Probleme mit der Absenkung der Webcam.


→ Timelapse No.9 – One Year in Schutterwald II auf Vimeo, weitere Timelapses auf meinem Vimeo Channel

Weather.chrisge.org hat mittlerweile Wetteraufzeichnungen, die zwei Jahre zurückreichen. Hier die zur Timelapse passenden und zum Vergleich auch noch die von letztem Jahr.

// Jahresrückblick mal anders: Jahresraffer 2012

So zum Jahresende habe ich mir gedacht, ich erstelle eine Timelapse für das ganze Jahr 2012. Snapshots habe ich dabei aber vom Zeitraum 28.12.2011 bis 28.12.2012 (und nicht vom 1.12.2012 - 31.12.2012) jew. von 17 Uhr ausgewählt und mit ffmpeg zusammengeschnitten. Ich hoffe man sieht nicht nur, wie sich die Webcam abgesenkt hat, sondern auch den Verlauf der Sonne.


→ Timelapse No.8 – One Year in Schutterwald auf Vimeo, sowie weitere Timelapses auf meinem Vimeo Channel

Hierzu die passenden Wetteraufzeichnungen von Weather.chrisge.org, die mittlerweile ebenfalls über ein Jahr zurückreichen:

// 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
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