CC::Blog

Schlagwort: rpi

  • Raspberry A Bewegungsmelder reloaded

    Wie hier im Blog schon beschrieben, habe ich mir mit einem Pi A einen kleinen Statusscreen gebastelt, der sich immer dann anschaltet, wenn jemand in die nähe des Pi’s kommt. Realisiert wurde das mit der PiCam – basierend auf Helligkeitsänderungen beim Snapshot. Soweit so gut. Seit 2 Monaten hängt sich der olle Pi jedoch regelmässig auf. So schlimm, dass ich Ihm einen crontab-Eintrag verpasst habe, mit dem er jede Nacht neu bootet.

    Zeit der Sache mal auf den Grund zu gehen. Das Problem war: Zu wenig RAM. Der Pi A hat gerade 256MB davon (eigentlich mehr als genug, für soetwas). Dummerweise hängt in PiCam direkt an der GPU des kleinen Rechners. Was bedeutet, dass man dem Ding in der /boot/config.txt den Parameter gpu_mem=128 mitgeben muss. Heisst: 128MB für die GPU (drunter funktioniert die cam nicht) und 128MB für das OS. Sofern man nun nicht eine extraschlanke Distribution mit busybox und dem ganzen Small-Mem-Footprint-gedönse nutzt, ist das verdammt mau. Erst recht mit der extrem aufgeblasenen Raspianedition.

    Also mussten Lösungsansätze her. Die Cam mit weniger als 128MB GPU-RAM zu betreiben funktioniert also schon mal nicht. Dann halt komplett anders.  Für gerade mal 1,10 Euro/Stück gibt es bei Amazon PIR-Sensoren. PIR steht für Pyroelektrische Passive Infrarot Sensoren. Die Dinger, die man aus den Bewegungsmeldern an Aussenlampen kennt. Das besondere an diesen PIRs ist, dass sie out-of-the-box mit dem Pi über GPIO spielen können.

    Obwohl das Chinaware ist, ist es relativ gut dokumentiert. In dieser Grafik findet sich alles, was man wissen muss:

    Wir sehen zwei Potentiometer, mit denen man die Empfindlichkeit und eine Art „Nachlaufwert“ einstellen kann. Den Timer stellt man am besten auf „0“ (Anschlag ganz links), das „Distanz“-Poti nach Gusto. Nun zum elektrischen:

    • VCC bei dem Ding ist 5V – der kommt also an PIN2 des GPIO’s (+5V OUT)
    • GND auf GND – PIN 6
    • OUT ist der PIN, der „HIGH“ wird, wenn sich was vor dem Sensor bewegt. Und coolerweise spuckt das Ding ca. 3,3V aus – also genau richtig für den GPIO. Den hängen wir an GPIO18 (PIN 12)

    Hier eine Übersicht der GPIO-PINs des raspis:

    Nach dem das nun alles Erledigt ist, geht es zum simpleren Teil. Der Software. Ich habe das ganze, wie bereits beim Cam-Script in Python realisiert:

    [codebox 1]

    In der Variable „delay“ kann man einstellen, wie lange der Screen nach einer Bewegungserkennung angeschaltet bleiben soll. Es sind natürlich auch andere Pins als GPIO18 möglich (bspw. GPIO4 / Pin7)

    Das Shellscript, „screen.sh“ ist dasselbe, wie im Cam-Post:

    [codebox 2]

    Nun noch in der /boot/config.txt den Wert gpu_mem auf 32 oder gar 16 stellen, rebooten, und wir haben wieder mehr als genug RAM. Dass die CAM nun nicht mehr funktioniert, sollte jedem klar sein – aber das war ja auch Sinn und Zweck der Sache.

  • 1wire mit dem Pi

    Ich betreibe hier seit über einem Jahrzehnt ein paar von diesen netten günstigen Dallas-1-Wire Dingern (DS1820) an einer Linuxkiste mit samt USB-Host-Adapter im sog. „Parasite-Mode“ (Ausser GND und Data benötigt man da nichts, und kann ein paar von den Sensoren – an bspw. im Haus liegenden Telefonkabeln – abfragen).

    Der USB-Host-Adapter ist eigentlich überflüssig, da der Pi das mit seinen GPIO’s von Haus aus kann. Und das ganze ist derartig trivial, dass ich es hier kurz erklären will. Man nehme:

    • den o.g. DS1820 (da gibts div. Variationen von, die sich in der Präzision unterscheiden – kosten ca. 2 Euro)
    • Einen Pi – mit Linux drauf.

     

    Den 1820 wie folgt mit dem Pi verbinden:

    GND auf GND // Vdd auf 3,3V // VDQ (Data) auf GPIO 4

    (Hier eine Ansicht des 1820, und hier eine des GPIO-Ports vom Pi)

    Dann ab auf die Shell und kurz 2 Kernel-Module nachladen:

    [codebox 1]

    Wenn alles richtig gelaufen ist, gibt es unter /sys/bus/w1/devices nun ein neues Verzeichnis mit der Unique-ID des 1820 (Die haben alle eine Art Mac-Adresse, die die einmalig macht) in dem wiederum eine Datei mit dem Namen „w1_slave“ liegt. Angenommen der 1820 hat die ID „28-0000041234567“ so heisst unsere Datei : „/sys/bus/w1/devices/28-000004593386/w1_slave“. Wenn man sich diese anzeigen lässt (zB via cat), kommt (etwas unsexy) der platte Temperaturwert als ASCII zum Vorschein.

    Den hübschen wir nun noch auf, und schon haben wir einen Wert, den man weiterverarbeiten kann (snmp, website, wo auch immer):

    [codebox 2]

    Günstiger kann man keine Temperaturen messen – und erweiterbar und flexibel ist es auch noch. (Es sei denn man will unbedingt 100 Euro für das neueste, hippe, bunte Temperaturmessdevice, dass nur mit App läuft, ausgeben und die Werte alle Nasen lang in die Cloud pumpen…)

  • Statusscreen mit dem Pi und Bewegungserkennung

    Es ist mal wieder Zeit für ein kleines Urlaubsprojekt.
    Hier lag seit 3 Jahren, neben einem RaspberryPi und nem alten 17″ Eizo-Screen, so ein Wandhalter für TFT-Screens herum. Da kann man doch was raus machen.

    Also fix den Wandhalter an die Wand gedübelt und den Pi mit NFS-Root (siehe Eintrag hier) aufgesetzt.
    Der Pi selbst ist mit dem Cam-Modul ausgestattet, und hängt per HDMI 2 DVI an dem o.g. Eizo.

    Folgende Ziele habe ich verfolgt (und umgesetzt):
    – Autologin nach reboot, sowie automatisches einloggen auf nem Server und attachen an tmux
    – Sobald sich was vor der Cam bewegt, soll der Monitor „aufwachen“, nach 60s. wieder ausgehen.

    Ist an sich recht einfach. Fangen wir mal mit dem Autologin an:
    via /etc/inittab sagen wir dem Pi, dass er sich – anstelle des logins – auf dem tty1 als „pi“ einloggen soll:

    #1:2345:respawn:/sbin/getty --noclear 38400 tty1
    1:2345:respawn:/bin/login -f pi tty1 /dev/tty1 2>&1

    Dazu die obere Zeile auskommentieren, und die untere einfügen.
    Nach einem reboot sollte der pi nun direkt auf der Shell als User „pi“ landen.
    Alles weitere (ssh-login) und Co. machen wir in der ~pi/.bashrc (letzte Zeile einfach anfügen)

    ssh -t [user]@[machine wo tmux rennt] "tmux att"

    Nun sollte nach dem Reboot (ssh-keys und laufender tmux auf „machine“ vorrausgesetzt) direkt der tmux erscheinen. Den kann man dann vom „normalen“ Rechner aus mit content bestücken (top, iftop, tail aufs log, etc.)

    Wer noch Hintergrundbild und höhere Auflösung auf dem pi haben möchte, dem seit fbterm ans Herz gelegt.

    Weiter gehts mit der „Motiondetection“. Dazu habe ich mir erstmal ein kleines Shellscript gebaut, welches den Monitor an/ausschalten kann, und dieses unter /usr/bin/screen.sh abgelegt:

    #!/bin/bash
    tvstat=$(tvservice -s |grep off)
    if [[ $tvstat == *off* ]]; then
    TV=OFF
    else
    TV=ON
    fi

    if [ "$1" == 'on' ] && [ "$TV" == "OFF" ]; then
    /usr/bin/tvservice -p;
    #fbset -depth 8;
    #fbset -depth 16;
    chvt 2;
    sleep 1
    chvt 1;
    chvt 2;
    chvt 1;
    #echo 'Switched Screen ON!'
    fi
    if [ "$1" == 'off' ] && [ "$TV" == "ON" ]; then
    /usr/bin/tvservice -o
    echo 'Switched Screen OFF!'
    fi

    Nicht von den chvt verwirren lassen. mit tvservice wird der Monitor an/ausgeschaltet, mit chvt auf das entsprechende (Virtuelle) Terminal umgeschaltet. Quasi das Shell-pendant zu „ALT-F1 bis ALT-F10“ zum Console wechseln. Ohne das hin- und herschalten via chvt geht der Moni zwar an, aber es wird nichts angezeigt.

    Die eigentlich Motiondetection ist in Python gebastelt (wie üblich: Kurz und schmutzig):

    [codebox 1]

    Wenn man das Ding nun laufen lässt, macht es im dauerloop ein Bild in niedriger Auflösung von der Cam, und vergleicht die Helligkeitswerte mit denen des vorherigen Pics. Ist der Unterschied grösser als „threshold“, dann macht das Script den Monitor an. Nach 60s ohne Bewegung wird er wieder ausgeschaltet.
    Jetzt nur noch das Script mit „start-daemon“ in ein init.d Script packen und beim booten automatisch starten, und fertig.

    Wie immer gibt es zig Wege dahin, dies ist nur einer von vielen. Das ganze kann man sicher noch immens optimieren. Für hier ist es mehr als in Ordnung.