Raspberry Video Camera – Teil 13: SW Autostart und Überwachung

Helmut 19. April 2017 18 Kommentare

In den vorangegangenen Artikeln habe ich die Software für die Raspberry Video Camera vorgestellt. Das war jeweils ein Python-Programm für die Raspberry Kamera an sich und für den PIR Bewegungssensor. Nun geht es darum, die Programme automatisch beim Bootvorgang zu starten und dafür Sorge zu tragen, dass das System verlässlich läuft. Dabei muss man es mit der Überwachung nicht übertreiben. Ein nächtlicher Reboot und ein Programm, das das Volllaufen der SD-Karte verhindert, reichen bereits vollkommen aus. Letzteres kann mit ein paar Zeilen Python-Code und einem Eintrag in die Crontab leicht erledigt werden.

Zuerst aber wieder ein Oachkatzl-Video. Mehr davon gibts in meinem YouTube-Kanal.

Autostart nach Reboot

Die beiden Python-Scripts für die Raspberry Video Camera haben wir bisher von Hand in einer (oder zwei) SSH-Session gestartet. Das ist gut zum Testen, weil man Fehlermeldungen sofort auf die Konsole bekommt, für einen dauerhaften Betrieb ist das aber viel zu umständlich. Alle benötigten Programme sollen beim Boot des Raspberry Pi automatisch gestartet werden, ohne dass eine Benutzeraktion erforderlich ist.

Wie kann man generell den automatischen Start von Programmen unter Linux erreichen? Dazu gibt es mehrere Möglichkeiten, die sehr schön im Artikel Raspberry Pi – Autostart von Skripten und Programmen einrichten auf Raspberry.tips beschrieben sind. Die eleganteste Methode wäre es sicherlich, ein Init-Script zu schreiben und in /etc/init.d/ abzulegen. Diese Methode bietet einige Konfigurationsmöglichkeiten und vor allem die Möglichkeit, die Programme per Befehl jederzeit stoppen und neu starten zu können. Für unseren Anwendungsfall braucht es all das nicht unbedingt, so dass ich die einfachere Variante über die Datei /etc/rc.local wähle.

Rc.local ist auf dem Raspberry Pi bereits vorhanden und kann um eigene Programmaufrufe ergänzt werden, die nach dem Bootvorgang gestartet werden sollen. Wichtig ist dabei, dass eigene Ergänzungen immer oberhalb des abschließenden exit 0 erfolgen. Die Zeile exit 0 muss also am Ende stehen. Die Datei rc.local können wir einfach mit dem Editor bearbeiten:

sudo nano /etc/rc.local

Und eigene Kommandos kommen ans Ende, aber vor dem abschließenden exit 0:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

# Autostart RaspiCam
cd /home/pi
rm -f trigger/*
su pi -c 'python3 -u record.py &> record.log &'
su pi -c 'python3 -u motioninterrupt.py &> motion.log &'

exit 0

Die Modifikationen für die Raspberry Cam habe ich im Listing hervorgehoben. Wir müssen uns vor Augen halten, dass wir die eigenen Scripts bisher als User Pi ausgeführt haben und das sollte auch weiterhin so bleiben. Die /etc/rc.local wird allerdings von Root abgearbeitet. Das bedingt ein paar Besonderheiten. So stehen wir nicht automatisch im Homeverzeichnis von Pi, sondern müssen mit cd explizit und mit absoluter Pfadangabe dorthin wechseln. Das ist die erste Zeile cd /home/pi. In der zweiten Zeile werden evtl. noch vorhandene Dateien aus dem Triggerverzeichnis gelöscht. Und in den beiden darauffolgenden Zeilen werden unsere beiden Python-Scripts gestartet. Allerdings nicht als Root, sondern als User Pi. Den Userwechsel erledigt das Kommando su, dem wir den User pi mitgeben und mit -c ein Kommando (in Hochkomma), dass ausgeführt werden soll. Das ist der Python3-Aufruf, den wir bereits kennen, aber mit drei Modifikationen:

• &> record.log bewirkt, dass die Programmausgaben (print-Befehle) in die Datei record.log geschrieben werden,
• -u sorgt dafür, dass sofort ungepuffert in die Logdatei geschrieben wird,
• und das & am Ende startet den Prozess im Hintergrund, so dass das Skript sofort mit der nächsten Zeile fortfahren kann.

Wenn wir uns danach per SSH am Raspberry Pi anmelden, werden wir feststellen, dass die beiden Logdateien record.log und motion.log in /home/pi liegen und die Print-Ausgaben der beiden Programme enthalten, die wir vorher im interaktiven Betrieb auf die Konsole bekommen haben. Die Logdateien werden bei jedem Neustart überschrieben. Den Dateiinhalt können wir jederzeit mit cat anzeigen:

cat record.log

Die beiden Hintergrundprozesse an sich sehen wir, wenn wir die Prozessliste aufrufen:

$ ps ax
  PID TTY      STAT   TIME COMMAND
  ...
  697 ?        Sl    23:57 python3 -u record.py
  707 ?        Sl    64:57 python3 -u motioninterrupt.py
  ...

Die Ausgabe aller Prozesse ergibt natürlich eine viel längere Liste, aus der ich nur die beiden relevanten Zeilen herausgenommen habe. In der Spalte PID steht zu jedem Prozess die Prozess-ID, mit der wir den Prozess auch beenden können, in diesem Beispiel mit

$ kill 697

für record.py.

Automatischer nächtlicher Reboot

Generell wären natürlich zahlreiche Überwachungen möglich, um sicherzustellen, dass die Kamera ständig einsatzbereit ist. Die Python-Programme könnten Heartbeats abgeben, also periodisch einen Zeitstempel in eine Datei schreiben. Das könne wiederum ein anderes Programm auslesen und bei Herzstillstand die Wiederbelebung einleiten. Die könnte durch einen Restart des Programms erfolgen, oder wenn das keinen Erfolg bringt durch den Reboot des Raspberry Pi. Es wäre sogar denkbar, eine kleine Hardwarevorrichtung zu bauen, die ein Relais in der Stromzuführung des RasPi hat, das periodisch angetriggert werden muss um nicht abzufallen. Damit könnte ein Raspberry Pi kurz stromlos geschaltet werden, sogar, wenn sich das Betriebssystem komplett aufgehängt hat.

Für unseren Anwendungsfall wäre das aber alles viel zu übertrieben. Den Aufwand können wir uns sparen, weil Raspbian so stabil läuft, dass es in der Regel auch über Wochen und Monate zu keinem Aufhängen kommt. Was wir aber mit geringem Aufwand realisieren können, ist ein nächtlicher Reboot, der das System zumindest alle 24 Stunden in einen definierten Anfangszustand versetzt.

Regelmäßig wiederkehrende Aktionen sind unter Linux eine Aufgabe für Cron.  Cron ist ein Daemon, also ein Serverdienst, der zu vorgegebenen Zeiten Programme oder Scripte anstarten kann. Die gewünschten Vorgaben trägt man dazu in die Crontab ein und das funktioniert wie folgt:

sudo crontab -e

Sudo ist hier wichtig, denn wir wollen die Crontab für den User Root editieren. Würden wir sudo weglassen, dann würden wir die Crontab des Users Pi aufrufen. Bei der anfänglichen Frage nach dem gewünschten Editor, belassen wir es beim Vorschlag Nano und drücken nur Enter. Dann gehen wir mit den Cursortasten ans Ende der Datei und ergänzen folgende Zeile:

0 0 * * * /sbin/reboot

Mit Strg-X beenden wir den Editor und bestätigen das Speichern der Crontab. Täglich um Mitternacht wird der Raspberry Pi nun durchgebootet.

Überwachung auf Speicherüberlauf (freedisk.py)

Ins Verzeichnis Videos laufen alle Videoaufzeichnungen. Das ist kein Problem, so lange die SD-Karte groß genug ist und wir die Videos regelmäßig (täglich) abholen. Sollte das versäumt werden, wird schnell der Speicherplatz ausgehen, was natürlich vermieden werden muss. Man könnte nun hergehen und das Videoprogramm so erweitern, dass es nur dann Videos speichert, wenn ausreichend Platz auf der SD-Karte zur Verfügung steht. Damit würden bei sich füllendem Speicher irgendwann keine weiteren Videos aufgezeichnet. Ein anderer Ansatz wäre es, nicht zu verhindern, dass neue Videos erzeugt werden, sondern die älteren zu löschen um Platz für neue zu schaffen. Damit müssten wir uns als Anwender keine Gedanken mehr um das Löschen der Dateien machen – das tut das System von alleine. Wir müssen nur rechtzeitig die Videos sichten, um keine gute Aufnahme zu verpassen.

Ich realisiere hier den zweiten Ansatz mit einem eigenständigen Python-Programm. Das erscheint mir universeller und auch für andere Anwendungsfälle einsetzbar. Gestartet wird das Programm dann regelmäßig per Cronjob. So brauchen wir die vorhandenen Programme nicht zu ändern.

import os
import shutil

# Directory in which files should be deleted
folder = '/home/pi/Videos'
files = []

# Minimum free disk space in bytes
minfree = 3000000000
currfree = shutil.disk_usage(folder).free

# If enough free disk space: nothing to do -> exit program
if currfree > minfree: exit()

# Calc amount of bytes to free on disk
tofree = minfree - currfree

# Get list of files in folder
for f in os.listdir(folder):
  stat = os.stat(os.path.join(folder, f))
  files.append([os.path.join(folder, f), stat.st_mtime, stat.st_size])
# and store information in list like [filename, modification time, size]

# Sort file list by modification time
files.sort(key=lambda i: i[1], reverse=True)

# Delete files - oldest first - until minimum disk space is reached
while files and tofree > 0:
  delfile = files.pop()
  os.remove(delfile[0])
  tofree -= delfile[2]

Zu Beginn werden die benötigten Python-Module geladen. Das sind hier os für die Interaktion mit dem Filesystem und shutil, ein Modul für „high-level file operations“. Mit shutil können wir leicht den verbleibenden Speicherplatz ermitteln.

In der Variablen folder hinterlegen wir das Verzeichnis, in dem die ältesten Dateien bei Bedarf gelöscht werden sollen. In unserem Fall ist das das Verzeichnis Videos im Homeverzeichnis des Users Pi. Und mit files wird eine Liste für die Dateiinformationen vorbereitet. Bei minfree müssen wir dann noch angeben, ab welcher Speichergrenze, das Programm tätig werden soll um Dateien zu löschen. Dazu folgende Überlegung: Gehen wir davon aus, dass das Löschprogram durch Cron alle 5 Minuten aufgerufen wird. In 5 Minuten würde bei fortlaufender Videoaufzeichnung keinesfalls mehr als 1GB Datenvolumen geschrieben, eher ein gutes Stück weniger. Wenn dann aber die Nachbearbeitung mit MP4Box beginnt, so kann temporär während der Umwandlung die dreifache Datenmenge entstehen. Mit 3GB sollten wir also auf der sicheren Seite sein, wenn wir davon ausgehen, dass dieses Programm alle 5 Minuten so viele alte Dateien löscht, dass wieder 3GB frei sind. Der Eintrag für minfree ist in Bytes vorzunehmen, es sind also 9 Nullen nach der 3.

shutil.disk_usage(folder).free ermittelt nun den freien Speicherplatz und wenn der überhalb der Minimalanforderung liegt, wird das Programm ohne weitere Aktion mit exit() beendet.

Andernfalls wird der benötigte Speicherplatz errechnet um dien Mindestwert wieder zu erreichen und eine Liste der Dateien in folder erstellt. In einer For-Schleife werden alle Dateinamen abgefragt und zu jeder Datei der Status ermittelt. Die Liste speichert dann pro Datei den Dateinamen, die Zeit der letzten Änderung und die Größe. Damit kann sie im nächsten Schritt in umgekehrter Reihenfolge anhand des jeweiligen Datei-Änderungs-Zeitstempels sortiert werden.

Abschließend werden in einer While-Schleife so lange die jeweils ältesten Dateien aus dem Verzeichnis gelöscht, bis die Schwelle wieder in den positiven Bereich überschritten wird. Dazu wird in der letzten Programmzeile bei jeder Löschung die freigegebene Dateigröße vom Löschbedarf subtrahiert.

Wir geben diesem Programm den Namen freedisk.py und legen es zu unseren anderen Python-Programmen ins Homeverzeichnis des Users Pi. Um das Programm regelmäßig automatisch zu starten, brauchen wir einen weiteren Eintrag in der Crontab. Dabei gehen wir genauso wie oben vor und fügen folgende Zeile in die Crontab ein:

*/5 * * * * /usr/bin/python3 /home/pi/freedisk.py

So startet Cron das Programm alle 5 Minuten. Wie generell in der Crontab sollten alle Pfade vollständig und absolut eingegeben werden. Um zu überprüfen, ob Cron das Programm tatsächlich periodisch startet, können wir ein paar Minuten lang das Syslog mitlesen:

$ tail -f /var/log/syslog | grep CRON
Apr  6 17:55:01 raspi166 CRON[25070]: (root) CMD (/usr/bin/python3 /home/pi/freedisk.py)
Apr  6 18:00:01 raspi166 CRON[28110]: (root) CMD (/usr/bin/python3 /home/pi/freedisk.py)
Apr  6 18:05:01 raspi166 CRON[31164]: (root) CMD (/usr/bin/python3 /home/pi/freedisk.py)

Dann mit Strg-C einfach abbrechen.

Fazit

Mit diesen Automatisierungs und Überwachungsmaßnahmen haben wir die Raspberry Video Camera zu einem produktiven System ausgebaut, das von alleine arbeitet. Menschlichen Eingriff braucht es eigentlich nur, um die aufgezeichneten Videos zu sichten und ggf. abzuholen. Wer in seinem Home-Netzwerk einen großen Speicherpool (NAS) besitzt, der kann die Übertragung der Videodateien auch noch automatisieren – per FTP zum Beispiel.

In meinen nächsten Artikeln wird es aber darum gehen, das Triggern der Kamera zu verbessern. So ein PIR-Bewegungssensor liefert mir noch zu viele Fehlsignale. Das lässt sich anders und besser machen. Zum Beispiel durch die Auswertung des Kamerabildes.

---

Weitere Artikel in dieser Kategorie:

• Raspberry Video Camera – Teil 1: Oachkatzl-Cam
• Raspberry Video Camera – Teil 2: Komponenten & Konzepte
• Raspberry Video Camera – Teil 3: Raspberry Pi Kamera Modul V2.1
• Raspberry Video Camera – Teil 4: Aufnahmeauslöser
• Raspberry Video Camera – Teil 5: Passiver Infrarot Bewegungssensor
• Raspberry Video Camera – Teil 6: Stromversorgung
• Raspberry Video Camera – Teil 7: Spannungsregler 5V
• Raspberry Video Camera – Teil 8: Montage Modell 850
• Raspberry Video Camera – Teil 9: Montage Kamera Modul
• Raspberry Video Camera – Teil 10: SW Installation Betriebssystem und Module
• Raspberry Video Camera – Teil 11: SW Python für die Kamera
• Raspberry Video Camera – Teil 12: SW Trigger per Bewegungssensor
• Raspberry Video Camera – Teil 14: SW Installation Computer Vision (OpenCV 3.2)
• Raspberry Video Camera – Teil 15: SW Einzelbilder exportieren für die Farberkennung
• Raspberry Video Camera – Teil 16: SW Trigger per Farberkennung
• Raspberry Video Camera – Teil 17: Exkurs – Wie Computer Farben sehen
• Raspberry Video Camera – Teil 18: SW Farbkalibrierung
• Raspberry Video Camera – Teil 19: SW Kombinationstrigger
• Raspberry Video Camera – Teil 20: Exkurs – Farbdarstellung per 2D-Histogramm
• Raspberry Video Camera – Teil 21: Konzept einer selbstlernenden Farberkennung
• Raspberry Video Camera – Teil 22: SW selbstlernende Farberkennung in Python
• Raspberry Video Camera – Teil 23: Verbesserung durch ROI und Aufnahmezeitbegrenzung
• Raspberry Video Camera – Teil 24: Anpassung von Programmparametern
• Raspberry Video Camera – Teil 25: Zweite Kamera
• Raspberry Video Camera – Teil 26: Optimierungen gegen Frame Drops
• Raspberry Video Camera – Teil 27: Was kostet der Spaß?
• Raspberry Video Camera – Teil 28: Kamera Modell 200 mit Raspberry Pi Zero
• Raspberry Video Camera – Teil 29: Stromversorgung für Kamera Modell 200
• Raspberry Video Camera – Teil 30: Software für Kamera Modell 200