Posts by meigrafd

    D.h. also, ich installiere zuerst Raspbian lite (nicht das normale?) dann motion und dann MotionEye?

    Das hab ich doch in Beitrag#8 geschrieben :conf:

    (nicht das normale?)

    Raspbian-Lite ist das normale Raspbian nur ohne Desktopumgebung. Da du den Pi nicht an einen Monitor anschließen möchtest, sondern zur Überwachung eines Nistkasten, brauchst du kein Desktop.

    Was ist der Unterschied zwischen beiden?

    Ich zitiere mal das Wiki von MotionEyeOS:


    Quote

    [...] motion as a backend and motionEye for the frontend.

    MotionEyeOS ist ein individuell angepasstes System, mit Abwandlungen die Dir jetzt wie man sieht Probleme bereitet da es vom Mainstream abweicht.


    "motion" und "motionEye" sind quasi Programme die sich jeder installieren kann.

    Ich wundere mich nur darüber dass der Hersteller des Raspberry Pi es nicht nur anbietet sondern sogar vorschlägt, es zu installieren: "We recommend most users download NOOBS, which is designed to be very easy to use."

    Jein. Das offizielle System von der Foundation ist Raspbian. Auf deren Download Seite steht: "Download it here, or use NOOBS, our easy installer for Raspbian and more." wobei das letzte nicht unterschlagen werden sollte: "and more".


    Es wird nur deshalb Anfängern empfohlen weil darüber vereinfacht unterschiedliche Systeme bereitgestellt und installiert werden können - was zur Findung des richtigen Systems helfen soll. Im produktiven Einsatz sollte man aber immer das jeweilige Images direkt flashen und auf NOOBS o.ä. verzichten.


    Nimm dir lieber Raspbian-Lite und installiere dir dort motion sowie motionEye selbst. Dann kollidierst du auch nicht mit allgemeinen Anleitungen die sich primär auf Raspbian beziehen.

    Nur weil man sich von Github Dateien laden möchte muss man nicht das vollständige Git installieren, es reicht das Paket git-core um Befehle wie git clone verwenden zu können.


    Bei Punkt-2 wundert's mich auch ein wenig wieso man explizit ins /home/pi/ Verzeichnis wechseln soll... Eigentlich packt man allg. Sourcecodes ins Verzeichnis /usr/src/ aber nicht in irgendein Homedir.


    Punkt-3 ist auch etwas verwirrend weil zB erst von " SSID = " gesprochen wird, aber die Einstellung tatsächlich " ssid= " lauten muss, case sensitiv und ohne Leerzeichen zwischen Setting und =.


    Punkt-4 ist doppeltgemoppelt... Solche Punkte sollten eigentlich auf die vorherigen aufbauen, deshalb sind es ja Punkte bzw Schritte. Von dem ständigen Verzeichniswechseln wird einem schwindelig... Um eine Datei zu kopieren muss man nicht vorher in das Quellverzeichnis wechseln.



    Festhalten sollte man auch dass /boot/hotspot.txt nicht vom System selbst unterstützt wird, sondern eine individuell erstellte Datei ist die vom rpi3-hotspot/usr/bin/rpi-access-point Script verarbeitet wird. Funktioniert/existiert das Script nicht wird /boot/hotspot.txt nicht beachtet.



    Mit Verlaub ist der Text leider auch etwas komisch - falsche oder fehlende Satzzeichen, falsche Artikel, verwirrende Beschreibung.

    Über https://github.com/damiencaselli/rpi3-hotspot wird ein Hotspot eingerichtet. Du wiederum beschreibst die Möglichkeit zusätzlich auch ein Gateway ins Internet (bzw ein weiteres WLAN) einzurichten. Auf die Möglichkeit Internet über eth0 bereitzustellen gehst du leider nicht ein.

    Da ich bisher die Automount Funktion genutzt habe und dies anscheinend nicht korrekt funktioniert, möchte ich nun aus meinem Python Programm herraus erkennen ob neue USB Sticks eingesteckt wurden und diese dann mounten.

    => https://github.com/meigrafd/Sa…e/blob/master/usbWatch.py



    Wenn das nicht passiert, kann ich den Mount Point dann wiederverwenden ?

    Da es sich beim "Mount Point" nur um ein Verzeichnis handelt: Ja.

    meigrafd Das arbeiten mit dem mpd2 Modul ist ziemlich tricky, von einem bug will ich nicht gleich reden. Ständig verliert man die Verbindung zum Server und muss den Fehler mit aufwendigem Workaround abfangen

    Das wäre mir jetzt neu. Projekte wie NewTron-Radio scheinen damit keine Probleme zu haben?


    Linus: mpd kann auch /var/run/mpd/socket ansprechen und verzichtet somit gänzlich auf subprocess-wrapper. "weil intern auch mit subprocess, dbus und co. gearbeitet wird." ist also falsch :fies:

    Ein paar Anmerkungen zu dem Code:


    1. Die Scripts haben einen python2 Shebang nutzt aber print Aufrufe von python3. Auf den ersten Blick mag es zwar trotzdem funktionieren, ist aber falsch.

    2. Die detector() Klasse basiert auf sog, Polling und ist zum einen CPU-Lastiger, zum anderen ungenauer. Grund: Durch die while Schleife wird (nur) alle 100ms der GPIO Zustand selber abgefragt. Findet eine Bewegung in genau diesen 100ms statt wird diese nicht erfasst da das Script ja für 100ms blockiert wird. Besser wäre eine Interrupt-basierte Lösung.

    3. Eigentlich sollte man pro Einrückung 4 Leerzeichen verwenden, im pirDetect.py sinds aber 8.. Entweder sind das wirklich 8 Leerzeichen oder ein TAB. Vermischen sollte man das tunlichst nicht.

    4. Im 2.Script wird sowohl subprocess als auch os.system verwendet, was ziemlicher Quatsch ist. Wenn zum ausführen von fbi auch subprocess genutzt werden würde könnte auf das sehr unschöne killall verzichtet werden...

    5. Es gibt einen omxplayer-Python-Wrapper wodurch man auf subprocess&Co in Python verzichten kann.

    6. Das ganze in 2 Scripts aufzuteilen erscheint mir in diesem Fall nicht als nötig.

    7. Sein später gezeigtes "record" Script nutzt ebenfalls subprocess um die PiCamera anzusprechen, was auch unnötig ist da es das Python Module picamera gibt.

    Ich würde von all dem generell Abstand nehmen und lieber mit dem Python Module mpd2 arbeiten - und direkt die gesamte "Internetradio-Steuerung" darüber abwickeln. Wenn seine Steuerung über ein Webinterface stattfindet, einfach den Webserver durch bottle ersetzen.

    Was zum Teufel ist ein LED Draht? Typisch Chinesische Übersetzung? Ich kenne nur ne LED Schnur oder korrekter LED Schlauch.




    Sorry hab nur die Überschrift gelesen.

    Ich hab hier auch son 0.96" SSD1306 OLED Display und habe das auch mal ausprobiert...


    Das erste was mich irritiert hat: Adafruit_SSD1306 ist eigentlich nur für Mikrocontroller vorgesehen. Für Python gibt es ein separates Adafruit_Python_SSD1306 Module, was auch hier beschrieben wird: https://learn.adafruit.com/ssd…nd-beaglebone-black/usage

    Daraus geht hervor dass import Adafruit_GPIO as GPIO im Module verwendet wird und das wiederum importiert RPi.GPIO https://github.com/adafruit/Ad…dafruit_GPIO/GPIO.py#L416


    Laut einer der Example Scripts sollte das aber kein Problem sein: https://github.com/adafruit/Ad…aster/examples/buttons.py


    Module installiert wie dort beschrieben wird. Dann Display via SPI angeschlossen (mein Display kann beides, SPI ist aber schneller) und dtparam=spi=on in /boot/config.txt eingetragen.

    Dann ein Test.py Script erstellt:

    Dann ein 2. Terminal geöffnet, die interaktive Python Konsole gestartet und:

    Code
    pi@raspberrypi:~$ python
    Python 2.7.13 (default, Nov 24 2017, 17:33:09) 
    [GCC 6.3.0 20170516] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import RPi.GPIO as GPIO
    >>> GPIO.setmode(GPIO.BOARD)
    >>>

    ...Funktioniert!

    Ich schicke über einen AVR per Serielle Schnittstelle an den PI Daten.. auf 19200 baud....

    Ein arduino empfängt die daten sauber...

    Ist aber der PI dran, empfängt der nur schrott..

    Keine Ahnung wie du auf die Überschrift kommst - offensichtlich funktioniert die RS232 Schnittstelle durch aus - nur gibts ein Problem beim Empfang seitens des Pis.


    Ohne den Code zu sehen kann man dazu nichts weiter sagen.

    Sauberer wäre der Weg über das jeweilige "block device".


    Stell dir vor du schließt 2 Tastaturen an deinen Computer an. Jede Tastatur kann auf einem Bildschirm schreiben. Nun möchtest du aber das nur eine Tastatur direkt auf den Bildschirm schreiben kann und nur die andere soll ein bestimmtes Programm bedienen... Das ist jetzt quasi der gleiche Fall wie bei dir mit dem Barcode-Scanner.


    Man kann das so einrichten dass du ganz normal mit Tastatur weiter arbeiten kannst und der Bardcode-Scanner im Hintergrund abgefragt wird. Und zwar über sein jeweiliges Input-Block-Device => /dev/input/eventX wobei X mit der jeweils passenden Zahl ersetzt werden müsste. Welches Input-Block-Device verfügbar ist steht in /proc/bus/input/devices.

    Damit das Device exklusiv nur für ein bestimmtes Python-Script genutzt wird benötigt man evdev => https://python-evdev.readthedo…v.device.InputDevice.grab Beispiel: https://github.com/gvalkov/pyt…ob/master/evdev/evtest.py



    Quellen:

    https://unix.stackexchange.com/a/72554

    http://nessy.info/?p=67

    https://khanhicetea.com/post/r…om_usb_keyboard_in_linux/