Posts by frankprcb

    Meine Lösung benutze ich seit rund 3 Jahren ohne Probleme. Der Pi läuft 24/7, monatelang.

    Als ich mir das Programm ausgedacht haben, wußte ein Großteil der User noch nicht einmal, daß sich die Displaybeleuchtung des 7" Touch überhaupt über Software steuern läßt.

    Mit dem Dateiobjekt habe ich es mit meinen bescheidenen Kenntnissen, die für meine Bedürfnisse allerdings auch ausreichen, schlicht und einfach nicht hinbekommen, mit Superuserrechten nach /sys zu schreiben, also habe ich das so gelöst, daß es funktioniert. Ob das nun die feine Art des Programmierens ist, war für mich nicht unbedingt von Belang, es sollte einfach funktionieren.


    Es gab für mich also bislang keinen Grund, nach anderen Lösungen zu schauen. Zumal auch im System keine Zombieprozesse zu finden sind, erst recht keine, die auf das echo Kommando zurückzuführen sind. Erst dann hätte ich mir Gedanken gemacht.

    Hallo dodas.


    Leider scheint es hier keine Funktion für persönliche Nachrichten mehr zu geben.

    Für ein größeres Display müßten in meinem Programm alle Positionen (Grafiken, Touchflächen) neu ermittelt und geändert werden. Das geht nur, wenn ich zum Testen auch einpassendes Display hätte. Zudem nutze ich für solche umfangreichen Projekte mittlerweile kein pygame mehr, erzeugt zum Einen sehr viel CPU Last und macht das Ganze unnötig lahm, zudem ist die Unterstützung vieler Touchscreens unter aktuellen Distributionen eh nicht mehr gegeben.

    Hallo


    Im Zuge mehrerer meiner Raspberry Projekte stand ich vor einem Problem mit der Helligkeit verschiedener Touchscreens. Im konkreten Fall ging es um den offiziellen 7" Touchscreen und um das Adafruit pitft+ 2,8" mit kapazitivem Touch.


    Ausgangslage: die Geräte laufen 24/7 und werden beide über die entsprechenden Touchscreens gesteuert, da beide aber in Sichtweite des Bettes stehen und die Anzeigen nicht dauerhaft gebraucht werden, im Gegenteil deren Beleuchtung nachts sogar stört, habe ich mir eine Lösung überlegt, wie die Beleuchtung automatisch aus- und bei Touchaktion wieder angeschaltet wird.

    Ein einfaches ScreenBlank reicht leider nicht, die Displaybeleuchtung bleibt dann trotzdem aktiv und ist im Fall des 7" doch sehr störend hell. Zudem muß man ja nicht unnötig Strom verbrennen, auch wenn es sicher nicht allzu viel ist.


    Beide Raspberrys laufen mit max2play. Wie bei den meisten Distributionen ist der allergrößte Teil der Software, Python, wiringpi, grafische Oberfläche (LXDE), bereits vorinstalliert. Lediglich das Paket xscreensaver muß in vielen Fällen mittels

    Code
    sudo apt-get install xscreensaver

    nachinstalliert werden.


    Im Fall von max2play läuft ja meistens jivelite als Oberfläche. jivelite bringt eigene Screensaver mit, die für die Darstellung eventueller Inhalte bei eingeschaltetem Display sorgen. Darauf will ich hier nicht weiter eingehen. Für den vorgestellten Zweck ist nur xscreensaver gemeinsam mit einem kleinen Python Programm zuständig.


    Als erstes richten wir xscreensaver auf dem desktop ein. Im Fall des 2,8" Displays ist das kaum möglich, da wichtige Steuerelemente nicht auf das Display passen. Da sollte die Einrichtung mittels Maus auf einem per HDMI angeschlossenen Bildschirm erfolgen, danach kann der Bildschirm und die Maus wieder entfernt werden.

    Ich habe es so gewählt, daß bei einem Pi der Blank Screen nach 30 Minuten, beim anderen der Blank Screen nach 10 Minuten aktiviert wird. DPMS habe ich zwar ebenfalls aktiviert, die Einstellung hat aber bei den beiden Displays mangels Power Management keine Wirkung.

    Der Timeout ist auch die einzige Einstellung, die der Anwender des Gerätes eventuell mal anpassen muß, auf eine möglichst einfache Bedienung habe ich Wert gelegt.

    Nach der Installation und Einrichtung muß noch geprüft werden, ob der xscreensaver Daemon auch automatisch gestartet wird. Die ist der Fall, wenn in $HOME/.config/autostart die Datei xscreensaver-daemon.desktop mit folgendem Inhalt zu finden ist:


    Code
    [Desktop Entry]
    Type=Application
    Encoding=UTF-8
    Name=Xscreensaver
    TryExec=xscreensaver
    Exec=/usr/share/xscreensaver/xscreensaver-wrapper.sh -nosplash
    NoDisplay=true
    X-KDE_StartupNotify=false
    # NotShowIn=KDE;GNOME;
    Comment=The XScreensaver daemon

    Ein paar Worte zur Hardware.


    Die Helligkeit des offiziellen 7" Displays kann bekanntermaßen gesteuert werden, in dem man einen Wert zwischen 0 (aus) und 255 (max) mit Superuserrechten in /sys/class/backlight/rpi_backlight/brightness schreibt.

    Das Adafruit Display kann über GPIO Port #18 per PWM gesteuert werden, siehe hier.

    Diese Funktionen nutze ich in meinem Python Programm.


    Das Programm initialisiert beim Start zuerst einmalig den Screensaver, das passiert, wenn er das erste mal aktiviert wird. Ohne diese Aktivierung fehlen die Rückmeldungen, ob er aktiv ist, oder nicht, diese Rückmeldung wertet das Programm aber aus. Die Aktivierung erfolgt mittels xscreensaver-command -display :0 -activate, nach 5 Sekunden Wartezeit wird der Screensaver mittels xscreensaver-command -display :0 -deactivate wieder deaktiviert.

    Dann wird die initiale Helligkeit eingestellt. Hier gibt es Unterschiede zwischen beiden Displays.

    Beim Raspberry Display nehme ich, wenn es an ist, immer den Wert 60, der ist immer noch hell genug, um selbst bei Sonnenlicht alles sehr gut ablesen zu können.

    Beim Adafruit Display wird zuerst mittels

    Code
    gpio -g mode 18 pwm
    gpio pwmc 1000

    GPIO #18 auf PWM mit einer Taktfrequenz von 1000Hz eingestellt. Die Helligkeit wird dann über die Pulsbreite eingestellt, von 0 (aus) bis 1023 (max) ist hier möglich. Bei mir hat sich bewährt, nachts 30 zu nehmen, am Tag 300. Der Befehl dafür lautet gpio -g pwm 18 Wert.

    Initial nutze ich bei dem Display 300.


    Ist die Intialisierung erledigt, startet die Dauerschleife. Sie fragt den Status des xscreensavers mittels xscreensaver-command -display :0 -time ab und extrahiert dort "blanked" (Helligkeit 0) oder "non-blanked" (entsprechende Helligkeit des jeweiligen Displays). Beim Adafruit wird zusätzlich noch die aktuelle Stunde geholt und die Helligkeit entsprechend nach Tag oder Nacht gewählt.

    Anschließend wird die Helligkeit entsprechend eingestellt, sofern sich der Zustand nach dem letzten Einstellen geändert hat, das ist so gewählt, um unnötiige Schreibvorgänge nach /sys zu vermeiden und die SD Karte zu schonen.


    Eigentlich sehr einfach gehalten, das Ganze. Vor dem Hintergrund, daß Python als Interpretersprache viel CPU Last erzeugt, ist das sicher kein Fehler.


    Das für das Display passende Programm wird einfach in $HOME abgelegt, in meinem Fall /home/pi, da unter max2play der User automatisch angemeldet wird. Für den Autostart sorgt ein Eintrag in der Datei $HOME/.config/lxsession/LXDE/autostart. Der Eintrag lautet in meinem Fall @/usr/python /home/pi/dim-run.py. Bei anderem User muß der Pfad natürlich angepaßt werden.


    Und das sind die beiden Python Programme.


    7" Display:


    Adafruit Display:



    Da hier im Forum die Darstellung der TAB Stops nicht funktioniert, ohne diese aber Syntax Errors kommen, habe ich noch ein Archiv mit beiden Programmen angehängt.


    Sollte der Beitrag den Anforderungen an ein HowTo genügen, kann ihn ein Moderator auch gern in den entsprechenden Bereich verschieben.

    Nochmal ich habe mit dem PI keine Erfahrung,
    ...
    Dann habe ich mich entschieden dieses Forum aufzusuchen.
    Es ist bestimmt und da bin ich mir ganz sicher eine minimalistische änderung in meinem bestehenden
    Programm.


    Ich beschäftige mich seit noch nicht mal einem Jahr mit dem Pi. Jetzt kannst Du gern hier nach Threads suchen, in denen ich mal etwas gefragt habe. Wirst Du keinen Erfolg haben.


    Was sagt Dir das? Eigeninitiative, Lesen, Lernen, dann wird das etwas mit dem Pi.


    Da schließe ich mich anderen Usern an, hier wird Hilfe bei konkreten Problemen geboten, Hilfe zur Selbsthilfe, um genauer zu sein. Ein Programmierservice ist das Forum sicher nicht.

    Warum immer gleich mit Kanonen auf Spatzen schießen? Aus dem Eröffnungspost geht doch recht eindeutig hervor, daß die LED einfach nur blinken soll, so lange der Song läuft, da steht nix von "im Musiktakt" oder Ähnlichem. Typische Forenkrankheit, aus jeder winzigen Mücke einen gigantischen Elefanten zu machen.


    Einfach die LED, am Besten über einen Transistor zum Schutz des Pi, an einen PWM GPIO Anschluß des Pi schalten, diesen mit 5 Hz, 50% Pulslänge programmieren und dann bei Start des Titels auch den GPIO starten, ist das Lied zu Ende, den GPIO wieder stoppen. Ist mit ganz einfachen Befehlen in Python zu erreichen.
    Einen konkreten Code werde ich hier absichtlich nicht liefern, denn wir wollen ja alle ständig dazulernen. Wird dem TE jetzt alles mundgerecht geliefert, weiß er zwar, daß es geht, aber nicht wie und warum. Deshalb einfach in die GPIO Programmierung einlesen, ist nicht soo schwer. Der Denkanstoß ist erst einmal da.

    Bei meinem Pi2 ist es nicht egal, wie herum die Stromversorgung erfolgt. Die des Displays scheint schwächer auszufallen.
    Mit der "normalen" Variante, Netzteil im Pi, Display über die Jumper versorgt, kein Problem, alles funktioniert tadellos, auch bei maximaler Displaybeleuchtung.
    Mit der auch dokumentierten Variante, Netzteil am Display, ein 2 Kabel von der USB-A Buchse am Display auf die Micro USB Buchse am Pi, gibt es Probleme. Selbst bei stark reduzierter Helligkeit leuchtet sehr häufig das bunte Kästchen rechts oben auf, das darauf hinweist, daß die Stromversorgung überlastet ist. Bei voller Helligkeit kommt es gar zu gelegentlichen Abstürzen des Pi2, wenn seine CPU ordentlich zu ackern hat und gleichzeitig auch noch viele Daten am SD Slot übertragen werden. Mit einem weiteren Pi2 konnte ich das reproduzieren.
    Der Pi Modell B ist nicht in der Lage, das Display zu versorgen, auch mit vorhandener Hardware selbst getestet.

    Die Icons kann ich hier nicht hochladen, da urheberrechtlich geschützt.


    Einfach hier ein Iconset aussuchen oder das korrespondierende Icon entsprechend dem Pedant im Iconset umbenennen, der Name vor der Dateiendung ist entscheidend.

    :thumbs1:


    Übrigens, wer sich auch mit der Auswertung von daten im JSOn Format beschäftigen will:
    je nach Anbieter kommen sie halbwegs hirarchisch geordnet oder auch alle nacheinander in einer Zeile. Da die Abfrage und Auswertung (bzw. das Extrahieren der gewünschten Daten) auch wieder der hirarchie folgen muß, ist der JSON Online Editor http://jsoneditoronline.org/ ein herorragendes Hilfsmittel.
    Einfach den JSON Output in das linke Panel einfügen, auf den Pfeil nach rechts in der Mitte klicken, voila, man hat eine wunderbare Ansicht der Datenhirarchie.

    Du mußt nur mal auf die Steuerplatine schauen, angeblich geht das Dimmen nur mit V1.1. Meine ist 1.1.


    Blöd ist bei dem Display nur, daß der Touchscreen über die pygame Routinen nicht abfragbar ist, da kommt nur Müll heraus. Der Workaround aus dem Adafruit Forum, die alte libsdl1.2 zu installieren, funktioniert bei diesem Display nicht. Ich frage den Touchscreen in pygame mittels xlib ab, hat den kleinen Nachteil, daß mein Python Programm unter X gestartet werden muß.

    Was für ein Netzteil verwendest Du denn für den Pi?
    Ich verwende ein 2,5A Steckernetzteil, das versorgt problemlos das 7" Display über die Brücken vom Pi aus mit.


    Für Dein Problem könntest Du auch die Hintergrundbeleuchtung dimmen:

    Code
    echo "Dein Wert von 0 - 255" > /sys/class/backlight/rpi_backlight/brightness"


    Dazu noch die Rechte für /sys/class/backlight/rpi_backlight/brightness im Dateisystem anpassen, damit Du auch als User "pi" dort schreiben kannst.


    Im Programm evtl. dann noch einbauen, daß das Display bei Berührung für eine definierte Zeit hell geschaltet wird, danach wieder gedimmt.
    Mit Wert 80 ist es locker noch hell genug, braucht aber nur noch wenig Strom. In meinem neuen Projekt (Weckradio mit riesiger Zeitanzeige und aktuellem Wetter/Wettervorschau) nutze ich 80 für hell und 20 für gedimmt.

    Und, läßt Du uns an der Lösung teilhaben?


    Ich kenne das Watterott nicht, vermute aber, daß es nicht wie das Adafruit als /dev/fb1, sondern als /dev/fb0 läuft.


    Ich habe auch mal wieder etwas geändert (außer Code aufräumen und noch mehr in Funktionen auslagern).


    In der Zeit von 6 - 22 Uhr wird jetzt auch 1x pro Minute für 10 Sekunden das aktuelle lokale Wetter angezeigt.
    Als Anbieter nutze ich die kostenlose API von http://www.weatherunderground.com. OpenWeatherMap aktualisiert die Wetterdaten in der freien Version generell zu selten, speziell bei der einzigen Wetterstation in meiner Nähe sind die Daten häufig bis zu 12 Stunden alt und somit unbrauchbar.



    Der Code (get_weather, das Ende von get_time(), show_weather() und update_screen() beachten):


    Ich muß 2 Stationen abfragen, da nur eine der Stationen in der Nähe korrekte Temperaturdaten liefert (alles private Stationen, die entsprechend nicht sauber aufgebaut sind, Temperatursensoren teilweise in der prallen Sonne), aber genau die wieder keine Winddaten liefert.
    Die Icons liegen in /hopme/pi/wanduhr/weathericons. Man kann die Icons von Weatherunderground nehmen (mehrere Iconsets als *.gif verfügbar, aber alle häßlich), ich habe von http://de.fordesigner.com/maps/3800-0.htm die Icons genommen und sie entsprechend den korrespondierenden umbenannt, allerdings *.png. Weatherunderground liefert den Namen des zum aktuellen Wetter passenden Icons praktischerweise ohne Endung.


    Beim Programmstart wird eine Pause von 30 Sekunden eingelegt, da wpa_supplicant beim Start des Pi unter wheezy manchmal ewig braucht, um die Verbindung zum Netz herzustellen. War die einfachste Lösung, man startet ja nicht laufend neu.


    was meinst du mit einem Thread?


    Eventuell solltest Du Dich mit dem Vokabular und den Gepflogenheiten bei der Benutzung von Internetforen vertraut machen.


    Ansonsten sind alle offiziellen Erweiterungen der Raspberry Foundation auf deren Webseite gut dokumentiert, 3rd Party Erweiterungen auf den Webseiten der Hersteller.
    Wie in allen Bereichen der Computerwelt, speziell aber bei Linux, helfen die User gern, erwarten aber auch ein gewisses Mindestmaß an Eigeninitiative.

    Auch wenn beim TE die Entscheidung gefallen ist, aber es stehen ja öfters User vor der Frage, was sie nehmen.


    Als Soundkarte setze ich bei Pi Projekten auch auf die Logilink USB Karte, die schon genannt wurde. Funktioniert problemlos out of the Box.
    Dazu den 3,7W Verstärker von Adafruit: http://www.exp-tech.de/shields…-audio-amplifier-max98306
    Begnügt sich auch mit 5V, Verstärkung kann über Jumper oder per Software vom Pi gesteuert werden, kann auch per GPIO ins Standby geschickt werden.


    Für viele typische Pi Anwendungen wie z.B. Weckradios reicht die Lösung locker.


    Wer bessere Soundqualität in einem kompakten Gerät will, kann auch statt USB Karte + Verstärker zum HiFiBerry Amp+ greifen. Bei entsprechender Lautsprecherwahl kommt das Ergebnis dann HiFi schon recht nahe.

    In diesem Thread geht es allerdings nicht um "unterstützen != verfügbar/haben", sondern es wurde gefragt, wie das Problem gelöst werden könnte. Und da habe ich durchaus eine realisierbare Lösung aufgezeigt.


    Ohne dynDNS wird es allerdings auch mit IPv6 nicht gehen, da sich, zumindest bei der Telekom, aber meines Wissens auch bei anderen Anbietern, der zugewiesene Adreßraum nach 90 Tagen ändert, obwohl es bei den IP Anschlüssen keine Zwangstrennung mehr gibt. Da ist man auf die Forderungen der Datenschützer eingegangen.


    Die Verbindung zu einem mobilen Router (sofern der Router auf der WAN Seite IPv6 unterstützt und mit Namensauflösung per dynDNS), um den es sich ja hier handelt, sollte bei diversen Geräten durchaus machbar sein, es ist schließlich ein Router und kein einfaches Endgerät wie ein Handy z.B.. Da ich das Gerät des TE nicht kenne, weiß ich natürlich nicht, ob es bei ihm auch so ist.


    Ein IPv6 Ping zu meinem iPhone ist z.B. kein Problem, ein Router sollte dann die Pakete auch ordnungsgemäß weiterleiten, bzw. bei IPv6 bekommt der Raspi bei entsprechender Routerkonfiguration eh eine öffentliche Adresse, so daß Port Forwarding & Co Schnee von Gestern sind. Bei einem Prefix von 2003:45:xxxx:xxxx::/56, den jeder Kunde bei der Telekom im Festnetz erhält, sollten genügend öffentliche Adressen vorhanden sein, selbst wenn der TE alle jemals hergestellten Pi's aufkauft und ins Netz bringen will. Im Mobilnetz gibt es zwar nicht ganz so viel, aber immer noch ausreichend.

    Wenn der Client nur IPv4 kann bringt dir das aber auch nichts ... dyndns.com bietet soweit mir bekannt ist keinen 4to6 Tunnel.


    Und wo ist da bei meinem Post die Stelle, bei der IPv4 ins Spiel kommt?


    • jedes halbwegs aktuelle IOS/Android Mobilgerät unterstützt IPv6
    • alle aktuellen Mobilfunktarife (zumindest die mit Laufzeitverträgen) der Telekom bieten IPv6
    • dynDNS unterstützt IPv6
    • die meisten halbwegs aktuellen Router und die meisten Internettarife im Festnetz unterstützen IPv6
    • Raspian unterstützt IPv6


    Ich sehe da keinerlei Stelle, an der IPv6 nicht funktioniert.


    Und habe es natürlich selbst getestet. Auf die Schnelle einen kleinen Webserver auf dem Pi eingerichtet, keine IPv4 Weiterleitung im Router, meine dynDNS Adresse im iPhone aufgerufen, voila, Verbindung über IPv6 steht.

    Ich erstelle mit als User root ein Cronjobfile mit dem Namen root.


    Warum die Fummelei und nicht als User Pi sudo crontab -e?
    Und dann in die crontab

    Code
    00 06 *   *   *   sudo /home/pi/scripts/pumpe-start.sh &
    
    
    45 08 *   *   *   sudo /home/pi/scripts/pumpe-ende.sh &


    eintragen.