// Kurztipp: Einem NIC eine weitere IP-Adresse mit IP hinzufügen

Wenn auf einem NIC (Network Interface Controller) eine weitere IP-Adresse benötigt wird, wird dies oft via Ifconfig mit einem virtuellen Interface bewerkstelligt, welches in der /etc/network/interfaces eingetragen wird:

auto eth0:1
iface eth0:1 inet static
    address 192.168.10.10
    netmask 255.255.255.0

Hier möchte als Alternative die Methode via IP kurz vorstellen. Zunächst fügen wir die IP-Adresse 192.168.10.10 mit der Subentzmaske 255.255.255.0 bzw. /24 dem Interface eth0 hinzu:

$ sudo ip addr add 192.168.10.10/24 dev eth0

…und schon ist unser Rechner über die bereits erwähnte Adresse erreichbar:

$ ip addr        #Ausgabe gekürzt
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    inet 192.168.9.10/24 brd 192.168.9.255 scope global eth0
    inet 192.168.10.10/24 scope global eth0
       valid_lft forever preferred_lft forever
 
$ ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.
64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=0.062 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=0.055 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=0.044 ms

Ebenfalls zu erwähnen ist, wie einfach diese Einstellung wieder wiederrufen werden kann:

$ sudo ip addr del 192.168.10.10/24 dev eth0
 
$ ip addr        #Ausgabe gekürzt
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    inet 192.168.9.10/24 brd 192.168.9.255 scope global eth0
       valid_lft forever preferred_lft forever
 
$ ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.
^C
--- 192.168.10.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms

Soll diese Einstellung nun bootfest gemacht werden, kann dies beispielsweise durch einen Eintrag in der /etc/network/interfaces geschehen, der so aussehen könnte:

#Definition von eth0
auto eth0
iface eth0 inet static
    address 192.168.9.10
    netmask 255.255.255.0
    gateway 192.168.9.1
    up ip addr add 192.168.10.10/24 dev eth0       #weitere IP-Adresse beim Start von eth0 hinzufügen
    down ip addr del 192.168.10.10/24 dev eth0     #...und beim Beenden wieder entfernen 

// Virt-resize – wenn die virtuelle Platte zu klein wird

Zur Virtualisierung einiger VMs verwende ich libvirt mit KVM. Leider waren die ursprünglichen 4GB Festplattenimage pro Ubuntu VM dann doch zu wenig. Die Debian Gäste kommen seltsamerweise bis jetzt mit 3GB aus :-)
Also musste ich die „Platten“ der VMs vergrößern. Die libvirt Doku verweist hierbei auf virt-resize. Dieses Tool ist in dem Paket libguestfs-tools enthalten und spart einem eine Menge Arbeit.

Schritt für Schritt

Zuerst muss man herausfinden, welche Partition der VM vergrößert werden soll. Dazu reicht ein einfaches df oder mount innerhalb der VM. Alternativ kann man auch vom Host aus virt-filesystems verwenden.
Nachdem man zusätzlich herausgefunden hat, wo das Image der VM liegt (z.B mit virsh dumpxml oder virsh edit), schaltet man die betroffene VM aus – keine Angst, die Prozedur dauert höchstens 5 Minuten. Wer über entsprechende Dumper für VMs verfügt (z.B. dieses Skript), könnte zuvor auch noch ein Backup des betroffenen Gastes ziehen.
Anschließend geht man wie in der Doku beschrieben vor (hier eine leicht angepasste Vorgehensweise):

$ cd /var/lib/libvirt/images                                       #In das Verzeichnis des Images wechseln
/var/lib/libvirt/images$ sudo mv VM.img VM.img.bak                 #VM.img anpassen
/var/lib/libvirt/images$ sudo truncate -r VM.img.bak VM.img
/var/lib/libvirt/images$ sudo truncate -s +3G VM.img               #Vergrößerung um 3GB
/var/lib/libvirt/images$ sudo virt-resize --expand /dev/sda1 VM.img.bak VM.img    #/dev/sda1 evtl. anpassen
Examining VM.img.bak ...
**********
 
Summary of changes:
 
/dev/sda1: This partition will be resized from 3,5G to 6,5G.  The 
    filesystem ext4 on /dev/sda1 will be expanded using the 'resize2fs' 
    method.
 
/dev/sda2: This partition will be left alone.
 
**********
Setting up initial partition table on VM.img ...
Copying /dev/sda1 ...
 100% ⟦▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓⟧ 00:00
Copying /dev/sda2 ...
 100% ⟦▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓⟧ --:--
Expanding /dev/sda1 using the 'resize2fs' method ...
 
Resize operation completed with no errors.  Before deleting the old 
disk, carefully check that the resized disk boots and works correctly.

Das schöne ist, dass hierbei auch gleich das Dateisystem der Partition (hier /dev/sda1 mit ext4) vergrößert „resized“ wird. Es ist also keine weitere Arbeit nötig. Der Gast kann sofort wieder gestartet werden.
Sollte bei dem obigen Vorgang etwas schief gelaufen sein, liegt noch ein Backup der Disk (VM.img.bak) vor. Virt-resize kann übrigens auch mit LVM umgehen – siehe Doku.

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

Hello World!

This is the personal website of Christoph Winkler aka chrisge.
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