Posts by frodo

    Wenn ich schon deine Geduld mit meinen Fehlern strapaziere, will ich auch zu einem Ergebnis kommen.


    Bin ich auf dem richtigen Weg mit der Klasse


    Code
    DigitalInputDevice(EventsMixin, InputDevice)


    und dem Parameter

    Code
    float bounce_time

    und, wenn ja, was muss ich denn in 'meiner' def_init für meine Zwecke angeben und wo im Script gehört das überhaupt hin?

    Ich seh schon ich muss mich erst mal in gpiozero richtig einlesen und auch einen Python-Grundkurs machen, sonst stochere ich ewig in meinem eigenen Nebel herum.

    Der Wink mit dem Zaunpfahl ist (endlich) angekommen :danke_ATDE:


    ...

    PingServer('192.168.1.7'): status.alice,

    }

    ...


    Wobei da ein Komma 'zu viel' ist, oder? Ändert aber nix dran, dass die Prozedur (?) PingServer mein kleines Projekt erheblich voranbringt!

    verstehe ich das richtig:

    die for-Schleife pingt alle 5 Min. die IP(s), wenn vorhanden/gefunden schaltet (in meinem Fall) Pin 23 für 1 Sek. durch/an? Welchen Pin muss ich denn für red/AUS angeben? Gar keinen?


    und, wie kriege ich es jetzt hin, dass das Script zwar wie oben (richtig?) alle 5 Min. pingt, bei TRUE die Tür öffnet, dann aber nicht alle 5 Min. erneut Pin 23 schaltet (da zu Hause), sondern erst wieder, wenn alle IPs für ne gewisse Zeit NICHT mehr gefunden werden? Da komme ich mit den angedachten und vorhandenen Schleifen überhaupt nicht klar.

    Danke für die Tipps. Mit

    Code
    if call("ping -c 1 " + ip, shell=True) != 0:

    sollte ich jetzt weiter kommen!


    gpiozero ist sicher 'neuer' und 'stabiler, für meine Pille-Palle-Anwendung tut's aber auch noch das alte RPI.GPIO


    Die Einrückungen waren/sind 'drin' werden beim kopieren hier in den Code nicht übernommen bzw. ich hätte sie hier nach bearbeiten müssen (mea culpa).


    Mein Script 'läuft' aber trotzdem nicht. Mit welchen Befehlen (Linux-Anfänger; hatte mich gerade mühsam in Wheezy und Jessie rein gefummelt ... und kann jetzt mit Stretch wieder von vorne anfangen) krieg ich raus, warum nicht? Und 'stimmt' überhaupt die Logik meines Scripts?

    Habe eine (Anfänger!)-Frage:

    bei im WLAN erkannter IP (des Smartphones) soll mein Script für eine Sek. einen Türöffner betätigen. Danach soll das Script in regelmässigen Abständen überprüfen, ob die IP immer noch im WLAN ist und das Script erst dann wieder 'scharf' schalten, wenn die IP für längere Zeit (hier 1 Std.) dann NICHT mehr im WLAN ist.

    Mit Bluetooth habe ich es probiert und es hat auch bestens funktioniert; aus baulichen Gegebenheiten (Reichweite) muss ich aber auf die Bluetooth-Lösung verzichten.

    Mein Code funktioniert aber nicht; steckt sicher voller [Denk-]Fehler!?


    Bitte Denkanstösse zum Überprüfen warum da was nicht funktioniert.


    Nachtrag:


    Ich versuche es jetzt mit http:// ... das ftp-Protokoll unterstützen die Raspi-Browser leider nicht. Die Dateien sind jetzt lokal auf dem Raspi (in /home/shares/pics/) und nicht mehr auf der externen NAS ... und trotzdem klappt die Bild-Anzeige nicht





    Dieses (existente) Bild wird im Browser nicht angezeigt, nur ein Platzhalter mit dem (Bild-)Dateinamen.


    Kopiere ich jetzt aber die (Bild-)Adresse

    Code
    /home/shares/pics/BILD.jpg


    in die Browser-Eingabezeile wird das Bild sehr wohl angezeigt und der Browser ändert dessen Adresse in

    Code
    file:///home/shares/pics/BILD.jpg


    In einem PHP-Forum sagte man mir, diese Dateien/Bilder könnten auch gar nicht angezeigt werden, da sie "außerhalb des Web-Root" lägen/liegen. Ein Zugriff/Anzeige auf die Datei ist aber wohl doch möglich!?? Nur anscheinend nicht von 'innerhalb' einer aufrufenden (PHP-)Seite.


    Wie kann das sein? Was verstehe ich da anscheinend völlig falsch?


    Unterstützt deine Fritzbox Webdav ?
    Wenn ja, richte sie so ein, dass du auf den NAS per Webdav zugreifen kannst. Webdav arbeitet über das http Protokoll.


    Wäre/ist ne gute Idee (Webdav läuft auf meiner Fritzbox) ... wenn ich nicht gut 50 GB Daten hätte und die (kostenlosen) Cloud-Speicher auf 25 GB deckeln würden.
    Ich könnte ja meine Daten auf 2-3 Webdav-Clouds verteilen ... habe aber in der Fritzbox nur die Möglichkeit EINEN Dienst auszuwählen. Schade!

    Danke!
    Direkteingabe URL (f t p ://...) liefert die gleiche Fehlermeldung. URL mit FritzBox-IP (ohne Login; ich weiß: unsicher) leider dito.
    Das hiesse dann, dass weder Epiphany noch Midori FTP 'Können'? Dachte eigentlich auch, das sei mittlerweile Standard!?
    Könnte es was helfen einen FTP-Deamon auf dem Raspi aufzusetzen, oder denke ich da in die falsche Richtung? Einfach planlos rumprobieren möchte ich lieber nicht: das Raspi-OS lässt sich ziemlich schnell zerhauen.


    Nachtrag:
    Du hast Recht kaiuwe: Midori scheint kein FTP zu 'können': https://bugs.launchpad.net/midori/+bug/1196211
    Ist Euch ein Raspi-Browser bekannt, der 'es' kann?
    Irgendeine andere Idee, wie ich per Browser (!) -also nicht über die FritzNAS-Weboberfläche- auf die NAS-Inhalte zugreifen kann?

    Wie kann ich vom Raspi über einen Browser (Epiphany, Midori) per FTP (und WLAN) auf eine FritzBox-USB-FP (NAS) zugreifen?


    Konfiguration: Raspi B, Jessie (upgedated und upgegradet), Apache2, PHP5


    Problem:
    Ich möchte einzelne, auf dem NAS abgelegte Dateien (Bilder), auf dem Raspi anzeigen lassen und habe dazu eine PHP-Datei mit einer FTP-SCR zu diesem/n Bild erstellt (f t p : / / fritz.box/USB_DEVICE_NAME/BILD.jpg). (musste das mit Blanks schreiben: der Editor hier macht aus "ftp://" beim speichern sonst autom. ein "http://")
    Die Verbindung erfolgt per WLAN (unerheblich!?).
    Die PHP-Datei wird 'ordentlich' ausgeführt, das Bild jedoch nicht angezeigt (nur der Bild-Dateiname und ein Bild-Platzhalter). Bei Direktaufruf der Bild-URL über ddie Browser erscheint die Fehlermeldung "es war nicht möglich diese Webseite zu laden".


    Auf einem Win-PC dagegen funktioniert der Bild-Aufruf (und die Bild-Anzeige) dagegen fehlerfrei.


    'Können' die Raspi-Browser kein FTP oder muss ich zusätzlich etwas installieren um die Bilder angezeigt zu bekommen?


    Weil eine .desktop-Datei eine Verknuepfung darstellt, die durch die graphische Benutzeroberflaeche interpretiert wird. Das ist aber aus Sicht des OS keine ausfuehrbare Datei. So wie ich die LXDE-Doku verstehe, ist das aber notwendig.


    Und wieder was gelernt! Danke.


    Problem ist übrigens gelöst: in Jessie ist NICHT die LXDE-pi/autostart, auch nicht die LXDE/autostart für eben jenen (Autostart) "zuständig", sondern die ~/.config/lxsessions/LXDE-pi/autostart !
    Aber das habe ich jetzt eher zufällig erfahren; ALLE Tipps und Beispielscripte und Tuts, die ich gefunden, durchgeackert und ausprobiert habe (Frust! Frust! Frust! Gerade für einen Linux-Neuling, der sich eigentlich aufmachen wollte, Windoof für immer zu beerdigen) beziehen sich aber auf die erstgenannten Autostart-Dateien ...


    Was geht nicht?


    Teilweise funktioniert der Eintrag in der rc.local bei Jessie nicht, weil das zu früh gestartet werden soll.
    Stelle mal in der raspi-config ein, dass das System auf das hochkommend es Netzwerkes warten soll (Punkt 3 oder vier im ersten Menü)


    Danke. Hab ich gemacht. Leider ohne Erfolg.


    Nochmal eine Verständnisfrage:


    Wenn mein Browser aus dem Desktop-Menü mit dem Befehl (Target File)

    Code
    /usr/share/applications/midori.desktop


    gestartet wird, wieso hat dann ein Autostart-Eintrag

    Code
    @/usr/share/applications/midori.desktop


    in der /etc/xdg/lxsession/LXDE-pi/autostart nicht den gleichen Effekt?
    Ist DIESE Autostart-Datei gar nicht "zuständig"?
    Ist mein Befehl falsch?
    Ich verstehe die Welt (und Jessie) nicht mehr!

    Hast du eine Lösung gefunden?


    Habe ein ähnliches/gleiches Problem mit

    Code
    pi@raspberrypi ~ $ midori


    --> "Cannot open Display"


    Was geholfen hat, aber nur per SSH-Shell, ist, vor dem Programmaufruf (midori) ein

    Code
    pi@raspberrypi ~ $ DISPLAY=:0


    auszuführen. DANN klappts auch mit dem Programmaufruf ...


    Was ich noch nicht hin gekriegt habe, ist, das Display-Command z.B. in der LXDE-pi/autostart ausführen zu lassen, denn von dort will ich auch mein midori starten, was aber, wahrscheinlich eben wg. der Display-Problematik nicht funktioniert: midori (oder irgendein anderes Programm) startet (ohne Fehlermeldung) einfach nicht ...


    Noch eine Anmerkung zum Verstaendnis: das export display hat nichts damit zu tun. Das ist notwendig fuer deine SSH-Session, weil es ja sein koennte, dass du die Bildschirmausgabe von Software die du via einer SSH-Shell startest auf *DEINEM* Rechner haben moechtest, statt auf dem entfernten Rechner. Und darum muss man das entscheiden - das DISPLAY=:0.0 sagt im Grund aus "localhost (aus sicht der Shell, also der remote-host), Bildschirm 0 (also der erste), und das .0 ... ka, wahrscheinlich sowas wie Desktop oder aehnliches.


    Hat aber alles mit rc.local nix zu tun, das laeuft ja auf dem PI und geht auch nicht davon aus, dass da was an Bildschirmausgabe weitergeleitet werden muss. Sie Post obendrueber.


    Danke! Kapiert.


    Meine Frage bleibt aber:
    Gebe ich an der SSH-Shell zuerst

    Code
    pi@raspberrypi ~$ DISPLAY=:0

    ein, kann ich anschließend -ebenfalls von der shell- Midori über

    Code
    pi@raspberrypi ~$ midori

    problemlos starten ... ohne das vorhergehende

    Code
    DISPLAY=:0

    erhalte ich "Cannot open Display"


    Konsequenterweise wird über LXDE-pi/autostart beim Start (in die GUI mit autom. Anmeldung als pi) mein @midori-Befehl (auch) nicht ausgeführt (ohne Fehlermeldung).


    Wie bringe ich meinem Raspi bzw. Jessie bei, dass VOR dem Midori-Autostart-Eintrag ein DISPLAY=:0 ausgeführt werden soll oder, wenn das eine Lösung ist, ein weiteres Display (1, ...) angesprochen wird, weil, dann 'klappt' es ja offensichtlich?


    Und, das würde mich wirklich interessieren: was ist an Jessie bzg. Displays so grundlegend "anders", als an Wheezy (außer dass u.a. bei Wheezy die LXDE-pi/autostart für eben die Autostarts zuständig ist); in Wheezy läuft der @midori-Befehl ohne Weiteres!?

    Einfache Aufgabe (Pi2)?


    Midori im Vollbild starten!


    Autostarteintrag in /etc/xdg/lxsession/LXDE-pi/autostart ( Midori ...) funktioniert leider nicht:



    Beim Start von der (SSH-) Konsole (als Pi) "$midori" erhalte ich die Fehlermeldung "Cannot open Display"
    Wenn ich an der Konsole das Display mit "$DISPLAY=:0" zuerst neu zuordne und dann $midori starte, klappt alles wunderbar ... wie kriege ich jetzt aber die DISPLAY=:0-Anweisung in die Autostart (oder darf die dort gar nicht rein? Sorry: Dummie!)
    Habe es auch mit einem "export DISPLAY=:0.0" in der /etc/rc.local versucht (da deren Einträge zuerst ausgeführt werden!?) und mit (gefühlt) weiteren tausend Scripten: ohne Ergebnis.


    Klar scheint mir: das Display (0) ist durch den Pi-Start in den Desktop anscheinend "belegt" und Midori kann in diesem Display nicht starten ... oder bringe ich jetzt alles durcheinander??


    Was mich wurmt: in Wheezy funktionierte der LXDE/autostart-Eintrag " Midori -e Fullscreen -a URL" tadellos ohne weitere Installationen ... leider habe ich in Wheezy meinen UMTS-Stick nicht zum laufen gekriegt, was wiederrum unter Jessie kein Problem war/ist.


    Und ja, bevor diese Nachfrage kommt: beide Systeme habe ich jeweils "nackt" nur mit apt-get update und apt-get upgrade genutzt.