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

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.

Zur Wahrung deiner Privatsphäre wird erst eine Verbindung zu YouTube hergestelt, wenn du den Abspielbutton betätigst.

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:

18 Kommentare

  1. Wolf Bischof

    Super Dokumentation und Projektaufbau.

    Vielleicht gibt es noch die Chance, das Ganze später in einer Art Varianten zu erweitern:

    ★ Nachtbeobachtung mit IR Beleuchtung/IR Cam
    ★ Betrieb mit Akku und WLAN

    Gruß

    Antworten
    1. Helmut (Beitrag Autor)

      Danke, die Artikelserie ist noch nicht zu Ende, mindestens 7 weitere Artikel habe ich gedanklich noch in der Pipeline und wer weiß, was mir noch einfällt.Aber ob es genau das sein wird, kann ich noch nicht versprechen.

      Antworten
  2. Uwe P

    Super!!
    Sehr viel Hintergrundwissen.
    Ich komme bis zum Teil 11.( Testen )
    $ python3 record.py
    python3: can’t open file ‚record.py‘: [Errno 2] No such file or directory

    Hab es schon zweimal neu gemacht, komme nicht weiter. Auch nicht mit su

    Antworten
    1. Helmut (Beitrag Autor)

      Hallo Uwe,
      das werden wir schon hinbekommen.
      Ich nehme an, Du hast Dich per SSH an Deinem Raspberry Pi angemeldet. Dann versuch doch mal folgende Kommandos:
      1. whoami
      Damit siehst Du welcher User Du bist
      2. pwd
      zeigt Dir an in welchem Verzeichnis Du stehst und dann
      3. ls -l
      und Du siehst alle Dateien in Deinem aktuellen Verzeichnis
      Da sollte dann eine record.py dabei sein.
      Falls nicht, dann poste hier mal, was Du auf die Befehle hin erhältst.

      Antworten
  3. Uwe P

    Hallo Helmut,
    danke für die schnelle Hilfe.
    Hier das Ergebnis:
    pi@raspberrypi:~ $ whoami
    pi
    pi@raspberrypi:~ $ pwd
    /home/pi
    pi@raspberrypi:~ $ ls -l
    insgesamt 8
    drwxr-xr-x 2 root root 4096 Mai 12 13:18 trigger
    drwxr-xr-x 2 root root 4096 Mai 12 13:18 Videos
    pi@raspberrypi:~ $

    Antworten
    1. Helmut (Beitrag Autor)

      Alles gut Uwe,

      Du hast nur die beiden Pythonprogramme noch nicht in diesem Verzeichnis abgelegt. Dazu die Programmtexte aus diesen beiden Artikeln:
      https://blog.helmutkarger.de/raspberry-video-camera-teil-11-sw-python-fuer-die-kamera/
      https://blog.helmutkarger.de/raspberry-video-camera-teil-12-sw-trigger-per-bewegungssensor/
      jeweils in eine Textdatei einfügen und diese so benennen, wie es in der jeweiligen Überschrift angegeben ist, also record.py und motioninterrupt.py.
      Dann sollte alles funktionieren.

      Antworten
  4. nils

    Hallo

    für das Überwachungssystem ( Lösung von alten Video)
    würde auch mein Script gehen.

    chmod +x bzipper

    Crontab -e
    0 * * * * /pfad/wo/es/liegt/bzipper

    Script:: bzipper

    #!/bin/bash
    EXPIREAGE=10 # Zahl in Tagen nach Datum , Vorhaltezeit
    DATE=“`date +%Y-%m-%d`“

    if [[ ! -d „$1“ ]] ; then
    echo „usage: b2zipper /media/usbstick/video/“ 1>&2
    exit 1
    if

    find „$1“ -type f -mtime +$EXPIREAGEE -delete

    exit 0

    Antworten
  5. Uwe P

    Hallo Helmut,

    ich hänge immer noch beim testen fest.
    Ich muss auch die Triggerdatei als su erzeugen und löschen.

    pi@raspberrypi:~/trigger $ touch 2017-05-18-18-18-45.trg
    touch: „2017-05-18-18-18-45.trg“ kann nicht berührt werden: Keine Berechtigung
    pi@raspberrypi:~/trigger $ su
    Passwort:
    root@raspberrypi:/home/pi/trigger# touch 2017-05-18-18-20-45.trg
    root@raspberrypi:/home/pi/trigger#

    —————————————————————-

    pi@raspberrypi:~ $ python3 record.py
    Ready for trigger
    Trigger detected!
    2017-05-18-18-20-45
    10.0
    Traceback (most recent call last):
    File „record.py“, line 43, in
    stream.copy_to((video_path + ‚b-‚ + triggerfile + ‚.h264‘), seconds=beforetime)
    File „/usr/lib/python3/dist-packages/picamera/streams.py“, line 758, in copy_to
    output = io.open(output, ‚wb‘)
    PermissionError: [Errno 13] Permission denied: ‚Videos/b-2017-05-18-18-20-45.h264‘

    Antworten
    1. Helmut (Beitrag Autor)

      Aber record.py lässt sich schon mal starten. Da bist Du schon einen Schritt weiter.

      Wie es aussieht hast Du die beiden Unterverzeichnisse als Superuser angelegt. Damit hat der User Pi keine Rechte dort, Du kannst keine Triggerdatei anlegen und das Programm keine Videos schreiben. Lösch die beiden Verzeichnisse nochmal und leg sie als User Pi an, dann sollte das funktionieren.

      Antworten
  6. Uwe P

    Hallo Helmut,

    bin ein Stück weiter, aber hängt wieder:(
    Kannst du mir nochmal helfen. Ich verwende einen Rasp B.

    pi@raspberrypi:~ $ python3 record.py
    Ready for trigger
    Trigger detected!
    2017-05-23-10-57-45
    10.0

    Traceback (most recent call last):
    File „record.py“, line 47, in
    camera.wait_recording(1)
    File „/usr/lib/python3/dist-packages/picamera/camera.py“, line 1167, in wait_r ecording
    encoder.wait(timeout)
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 395, in wait
    self.stop()
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 815, in stop
    super(PiVideoEncoder, self).stop()
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 419, in stop
    self._close_output()
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 349, in _clos e_output
    mo.close_stream(output, opened)
    File „/usr/lib/python3/dist-packages/picamera/mmalobj.py“, line 368, in close_ stream
    stream.close()
    OSError: [Errno 28] No space left on device

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
    File „record.py“, line 56, in
    camera.stop_recording()
    File „/usr/lib/python3/dist-packages/picamera/camera.py“, line 1196, in stop_r ecording
    self.wait_recording(0, splitter_port)
    File „/usr/lib/python3/dist-packages/picamera/camera.py“, line 1167, in wait_r ecording
    encoder.wait(timeout)
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 398, in wait
    raise self.exception
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 267, in _call back
    stop = self._callback_write(buf)
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 921, in _call back_write
    return super(PiVideoEncoder, self)._callback_write(buf, key)
    File „/usr/lib/python3/dist-packages/picamera/encoders.py“, line 298, in _call back_write
    written = output.write(buf.data)
    OSError: [Errno 28] No space left on device
    pi@raspberrypi:~ $

    Antworten
    1. Helmut (Beitrag Autor)

      Immer gerne wenn ich kann.
      „No space left on device“ lese ich da. Deine SD-Karte scheint voll zu sein.
      Gib mal df ein, dann sollte sowas kommen:

      df
      Dateisystem    1K-Blöcke  Benutzt Verfügbar Verw% Eingehängt auf
      /dev/root       30583756 16370240  12941248   56% /
      devtmpfs          307136        0    307136    0% /dev
      tmpfs             311468        0    311468    0% /dev/shm
      tmpfs             311468    33156    278312   11% /run
      tmpfs               5120        4      5116    1% /run/lock
      tmpfs             311468        0    311468    0% /sys/fs/cgroup
      tmpfs             311468      208    311260    1% /tmp
      /dev/mmcblk0p1     64456    21256     43200   33% /boot

      Bei mir sind in / 56% in Verwendung und ca. 12GB frei. Ist Deine SD-Karte recht klein, oder hast Du irgendwo Unmengen von Daten drauf?

      Antworten
  7. Uwe P

    Oh, ich verwende eine 8 Gb Karte und die ist voll.
    Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
    /dev/root 7569720 7236224 0 100% /

    ich werde das mal ändern.
    Danke Dir

    Antworten
    1. Helmut (Beitrag Autor)

      Ja 8GB ist sehr knapp. Du könntest zwar sicherlich Sachen finden, die gelöscht werden können, aber wenn Du Videos aufzeichnest hast Du schnell wieder ein paar Gigabyte zusammen. Ich hab 32GB SD-Karten für die Kameras.

      Antworten
  8. Uwe P

    Hallo Helmut,
    es läuft perfekt, dank Deiner ausführlichen Anleitung.
    Ich hab mir noch eine einfache Samba-Freigabe eingerichtet und kann die Videos über meinen PC anschauen. Demnächst will ich das ganze auf mein E-Mail senden, muss erstmal googeln.

    Antworten
    1. Helmut (Beitrag Autor)

      Das freut mich Uwe. Wie hast Du es mit dem Hardwareaufbau gelöst? Schick gerne mal ein Foto.

      Antworten
  9. Uwe P

    Geplant ist eine Überwachung der Eingangstür. Der Raspi soll im Haus bleiben und Kamera + Sensor außen. Ich warte noch aus das lange Flachbandkabel;)Ich schicke dir dann Bilder.
    Im Moment habe ich das Phänomen das beim starten der Videos der PIR oder weis nicht, er eine Aufzeichnung macht. Also jedes mal wenn ich ein Video anschaue erzeugt er ein neues.
    Ich dachte erst der PIR ist falsch eingestellt, hab de PIR auch schon getauscht. Hast du da eine Idee oder Erklärung.

    Antworten
    1. Helmut (Beitrag Autor)

      Eine Erklärung habe ich dafür nicht direkt, aber ich kenne das Phänomen. Das Abrufen einer aufgezeichneten Videodatei, um die anzusehen, bringt den PIR dazu, erneut zu triggern. Es macht den Eindruck, als würde diese heftige Aktivität am Raspberry irgendwie in den PIR zurück einstrahlen. Ich hab das tatsächlich durch den Austausch des PIR-Sensors weg bekommen und habe heute das Problem nicht mehr, weil ich nur noch dann ein Video aufzeichne, wenn PIR und Farberkennung gleichzeitig triggern. Zumindest würde es mir jetzt nicht mehr auffallen. Ich hab natürlich auch die Empfindlichkeit am PIR-Sensor auf Minimum zurückgedreht – ich weiß nicht, ob das bei Dir geht.

      Antworten
  10. Axel

    Toller Artikel! Hat mir sehr weitergeholfen. Werde Deine Seite gerne weiterempfehlen.

    Antworten

Schreibe einen Kommentar zu Uwe P Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert