Posts by gupi

    Bin weiter gekommen.

    • Nachdem ich das Display und den Touch an einer bestehenden älteren RPI2 Anwendung angeschlossen habe, funktionierte dort der Touchscreen. Der Pi reagierte auf meinen Stylus und auch auf den Finger.
    • Deshalb habe ich von einer älteren NOOBS Version (NOOBS_v2_1_0) meinen Pi3 neu aufgesetzt und getestet - war aber ohne Erfolg. Der Pi wollte die Signale vom Touchscreen nicht verstehen. Ein Blick auf "uname -a" zeigte zu meiner Verblüffung einen Kernel 4.9.28.
    • Damit hatte ich nicht gerechnet, denn meine bisherige NOOBS_v2_4_0 hatte vor "apt-get upgrade" die Kernel Version 4.4.50 gezeigt und erst danach 4.9.28.
    • Also alles nochmal von vorne (NOOBS_v2_1_0) aber diesmal ohne Netzwerkkabel. Mit einer Netzwerkverbindung wird der aktuelle Kernel aus dem Netz und nicht von der SD-Karte installiert.
    • Jetzt wird ein Kernel 4.4.34 angezeigt und die Signale vom Touchscreen steuern zumindest schon mal den Mauszeiger.


    :D Das ist der aktuelle Stand, jetzt kann ich mich (endlich) um die Kalibrierung kümmern.
    Danach muss ich "nur" noch herausfinden wie man die normale graphische Oberfläche mit dem Touchscreen steuert - Mouseclick links und rechts usw.


    LG
    Gunter

    Hallo,
    ich stehe vor einem ähnlichen Problem:


    Konfiguration:
    RPi 3
    Pollin 7" Display mit Touchscreen (120964)


    pi@rpi002:~/Downloads/eGTouch_v2.5.5814.L-ma $ lsusb
    Bus 001 Device 005: ID 24ae:2010
    Bus 001 Device 004: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen
    Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
    Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    pi@rpi002:~/Downloads/eGTouch_v2.5.5814.L-ma $ uname -a
    Linux rpi002 4.9.28-v7+ #998 SMP Mon May 15 16:55:39 BST 2017 armv7l GNU/Linux


    Treiber wurde von "http://www.eeti.com/drivers_Linux.html" heruntergeladen, entpackt und mit:

    pi@rpi002:~/Downloads/eGTouch_v2.5.5814.L-ma $ sudo sh setup.sh


    installiert.
    Allerdings ohne spürbaren Erfolg, auch nach einem reboot - die Stylus und/oder Fingerberührungen werden vom Pi ignoriert.


    pi@rpi002:~/Downloads/eGTouch_v2.5.5814.L-ma $ evtest
    zeigt allerdings die Events an!


    Bin ratlos und brauche Hinweise :wallbash:
    Gunter

    Hallo Allerseits,


    der FTP Server vsftpd treibt mich in den Wahnsinn. :wallbash:


    Sobald ich eine Datei auf den Server hochlade, wird diese mit einem Offset von zwei zusätzlichen Stunden in fileZilla angezeigt. Eine Datei die um 16:28 hochgeladen wird, zeigt er mir mit 18:28 Uhr. Sehe ich im Terminal auf das Verzeichnis ls -al /var/www/html/index.php so wird dieses mit der richtigen Zeit - also 16:28 - angezeigt.


    In meiner vsftpd.conf steht "use_localtime=YES" - In der Defaulteinstellung (NO) hätte mir ja auch GMT angezeigt werden müssen, also 14:28 UHR.


    Meine timezone steht auf Europa/Berlin (raspi-config)


    Weshalb will mich vsftpd unbedingt nach Moskau verlagern?
    Oder spielt mir fileZilla einen Streich und ich verdächtige vsftpd zu Unrecht?


    Hat jemand eine Idee?


    LG
    Gunter

    Ich bin bei der Ursachenforschung etwas weiter gekommen, allerdings noch ohne Lösung.


    Wenn ich mir die log-datei von mpd ansehe (/var/log/mpd/mpd.log) bemerke ich folgendes:


    Code
    Nov 30 11:31 : client: [3] opened from [::1]:57099
    Nov 30 11:34 : client: [3] closed


    wenn ich nach dem Start des scripts innerhalb der ersten Minute den Button mehrfach drücke, startet und stoppt die Audioausgebe wie gewünscht und der closed Eintrag im Log verzögert sich. Erst wenn dieser Eintrag im Log auftaucht, zeigt sich der Fehler.


    Es dauert übrigens genau eine Minute nach der letzten Button - Betätigung bis der client stoppt. Deshalb auch der Zeitabstand von vier Minuten im Log, denn ich habe den Button mehrfach alle 30 Sekunden gedrückt.


    Das heißt, erst wenn der client, warum auch immer, gestoppt ist, kann das script nicht mehr mit dem daemon kommunizieren und verabschiedet sich.


    Die Frage ist also, weshalb stoppt der client? Ist das ein automatischer timeout? Hier bringt mich momentan die googelei nicht weiter, oder ich stelle die falsche Frage. Die Doku von mpd ist auch nicht viel sprechender.


    :wallbash:
    Gunter
    Automatisch zusammengefügt:[hr]
    Gotscha - zumindest der "workaround" funktioniert.


    ich habe einfach die Schleife um einen client Aufruf alle 20 Sekunden eingefügt. Damit unterbleibt das automatische Beenden des clients durch timeout und das script läuft und läuft und läuft.


    Weshalb allerdings der client vorher beendet wurde würde mich schon interressieren.


    :D
    Gunter

    Nachdem ich mir das Verhalten nochmal genauer angesehen habe, komme ich immer mehr zu der Auffassung, dass hier wohl eher die Ursache beim mpd bzw. mpc liegt. Der Fehler tritt ja beim client Aufruf auf.
    Deshalb ist meine Anfrage eventuell besser im Multimedia Forum aufgehoben.


    Moderator, würdest Du bitte den Beitrag entsprechend verschieben?


    :danke_ATDE: Gunter

    Hallo,


    ich habe das One Button Audiobook (siehe hier) nachgebaut.


    Die hierin vorgeschlagenen Tests (Handbetrieb) funktionieren auch. Ich kann auch das python script starten und über den button die mp3 Datei starten und anhalten. Auch die Datenübernahme vom usb Stick funktioniert noch, aber nach dem erneuten start von mpd durch das script geht's in die Hose. Das Script stürzt mit Fehlermeldungen ab:




    Die neue mp3 datei wurde vom stick geladen und der stick un-mounted.


    Bis dahin hat es also noch funktioniert.


    Da ich allerdings von Python keinen blassen Schimmer habe, komme ich hier nicht wirklich weiter. :wallbash:


    Kann mir jemand von den Python Gurus hier weiterhelfen?


    Ich habe das script (mit meinen GPIO-Pin Anpassungen) angefügt:


    Danke schon mal.


    Configuration:
    Debian Jessie (aktuellste RASBIAN Version) auf RPi B


    Nachtrag:
    der Fehler liegt möglicherweise an einer ganz anderen Stelle, denn nachdem ich mal ein komplettes Hörbuch auf den USB Stick gepackt hatte, funktioniert zumindest der restart via script. Vorher hatte ich lediglich einen Testsong auf dem Stick.


    Jetzt zeigt sich aber eine veränderte Symptomatik. Sobald das script mehrere Minuten ohne Tastendruck läuft, stürzt es beim nächsten Tastendruck ab. Dabei ist es gleichgültig ob die Wiedergabe gerade läuft oder ob der Tastendruck die Wiedergabe gerade starten sollte.


    So sieht jetzt die Fehlermeldung aus:






    :danke_ATDE:
    Gunter

    @ torbotoni,
    Danke, genau das werde ich machen. Die Software zu ändern und dann zu testen ist wohl das risikoärmste. An der Hardware möchte ich nur im Notfall etwas ändern, wäre hierbei sehr aufwändig.
    Deshalb hatte ich nach Ideen gefragt, manchmal ist man selber ziemlich betriebsblind.

    :danke_ATDE:


    Gunter

    Erstmal Danke für die schnelle Reaktion auf meine Frage.


    dreamshader - verifiziert mittels Scope leider nicht, da mir mein (geliebtes) Labor nicht mehr zur Verfügung steht und ich jetzt eher hobbymäßig ausgestattet bin. Ich habe allerdings via Consol-Kommandos getestet - Sobald ich den Mode auf out setze zieht das Relais an.


    Jörg - natürlich setze ich den Mode nicht ständig (mutwillig). Das Setzen gehört allerdings zu meiner Initialisierungsroutine in der Anwendung - passiert also bei Programmstart. Ich verifiziere bei Programmstart nicht, ob ein Init überhaupt nötig ist - wäre ja eigentlich nur nach einem vorangegangenen Power-down nötig da der MCP seine Registerinhalte beibehält.


    Wie gesagt, das Ganze ist ein Effekt, mit dem ich gar nicht gerechnet hatte. Ich war bislang in dem Glauben, dass der Schritt 2 der Initialsierung schneller als die Trägheit der Relais hätte sein müssen. Vielleicht sollte ich mal nach der Ursache für die Verzögerung zwischen Schritt 1 und 2 forschen.


    Mal sehen wie ich hier weiterkomme, den Inverter wollte ich mir möglichst sparen.


    Gruß
    Gunter

    Hallo,
    ich betreibe eine Relaikarte an einem MCP23s17. Klappt auch soweit, aber leider erwartet die Relaiskarte aktiv-low Eingänge. Auch damit kann ich ja umgehen sobald die Ausgänge fertig initialisiert sind.
    Ich initialisiere die benutzten ports (Ausgänge) auf 1.
    Doch während der Initialisierung:

    • Schritt ...mode 207 out
    • Schritt ...write 207 1

    kommt es zwischen den beiden Schritten vor, dass ein Relais kurz anzieht. Die Ursache ist mir auch klar, da ja mit dem 1. Schritt dar Ausgang auf Null gesetzt wird. Mitunter dauert es aber zwischen den beiden Schritten lange genug um das Relais kurz flackern zu lassen. Damit hatte ich bei meiner Planung nicht gerechnet. Es kommt auch nicht oft vor aber leider hin und wieder doch.


    Ich hatte mir folgende Lösungsalternativen überlegt:

    • externe Pull-up Widerstände an die 23s17 Ausgänge anschließen
    • externe Pull-down Widerstände in Kombination mit Invertern anschließen
    • die internen Pull-ups des IC nutzen


    Nach nochmaligen Studium des MCP23s17 Datenblattes scheint die Alternative 3 gar nicht zu funktionieren. Die internen Pull-ups sind nur im Input mode wirksam. Alternative 1 dürfte auch nicht funktionieren, da mit Setzen des out mode (Schritt 1) der pin sofort auf Null geht.


    Scheint nur Alternative 2 zu bleiben (ein open collector Transistor mit pull-down Widerstand an der Basis) als Inverter.


    Oder hat jemand einen besseren Vorschlag?


    Zur Zeit nutze ich einen "Workaround" . Ich aktiviere die 5Volt für die Relais erst nach meiner Expander Initialisierung.


    Gruß
    Gunter

    tomrossi


    das geänderte (ungetestete) skript mit array habe ich Dir doch schon in meine Antwort eingefügt. Du brauchst hier nur noch die Sensor-Ids in die "echten" Werte zu ändern.


    [code=php]// Replace your DS18B20 serial here!
    $SENSORIDS = array (
    "28-000005c68110",
    "28-000005c64711",
    "29-000005c64712",
    "30-000005c64713",
    "31-000005c64714"
    );[/php]

    Sicher nicht die eleganteste Lösung, aber zum Testen sollte das ausreichen:
    mach einfach eine Kopie deiner temperatur.php (oder wie immer Du dein Skript genannt hast), ändere den Namen der Kopie in temperatur2.php. Jetzt nur noch dort die SensorId anpassen und nicht nur temperatur.php, sondern auch temperatur2.php durch den cron-job aufrufen lassen. Jetzt solltest Du beide Temperaturen sehen können.
    Wenn das so geklappt hat, kannst Du nach dem gleichen Muster auch Deine anderen Sensoren einbinden.


    Natürlich ist es sehr viel eleganter, alle Sensoren in einem PHP Skrit abzuarbeiten. Dazu müsstest Du die Sensor -Ids in ein Array schreiben. Dieses Array durchläufst Du dann in einer Schleife (foreach($sensorIds as $sensorId))...
    In der Schleife erzeugst Du dann die Dateien, die das CMS anschließend ausliest und anzeigt. Ich fürchte nur, das überfordert Deine PHP Fähigkeiten, deshalb als schneller Workaround: mein erster Vorschlag oben.


    Hoffe das bringt Dich erst mal weiter.
    [hr]
    Kurzer Nachtrag:
    Funktioniert der Skript bei Dir wirklich? Aus meiner Sicht kann das gar nicht sein, denn Zeile 8 hat eine Syntax mit der PHP sicher nicht klar kommt:

    PHP
    $EmonCMSHost = "localhost";<a href="http://cdn.raspberry.tips/2014/12/temperatur.php_.txt">temperatur.php</a>[/php]
    Was soll ein HTML-link an der Stelle mitten im PHP Code ohne diesen vorher zu beenden?
    Also weg mit:[code]<a href="http://cdn.raspberry.tips/2014/12/temperatur.php_.txt">temperatur.php</a>


    [hr]
    Ungetested!!!!
    [code=php]<?php
    // ================ Config ===========================
    // Replace your DS18B20 serial here!
    $SENSORIDS = array (
    "28-000005c68110",
    "28-000005c64711",
    "29-000005c64712",
    "30-000005c64713",
    "31-000005c64714"
    );


    // Set the emoncms API Key, the Hostname or IP and the internal Sensor ID (Numeric only)
    $EmonCMSApiKey = "d5fc60b7e270c380ef0a2b418f632a84";
    $EmonCMSHost = "localhost";
    foreach ( $SENSORIDS as $key => $SENSORID ) {
    $ecmsSENSORID = $key + 1;
    // ==================================================

    // BuildSensor Path
    $SensorPath = '/sys/bus/w1/devices/' . $SENSORID . '/w1_slave';

    // Open resource file for thermometer
    $thermometer = fopen ( $SensorPath, "r" );

    // Get the contents of the resource
    $thermometerReadings = fread ( $thermometer, filesize ( $SensorPath ) );
    // Close resource file for thermometer
    fclose ( $thermometer );
    // We're only interested in the 2nd line, and the value after the t= on the 2nd line
    preg_match ( "/t=(.+)/", preg_split ( "/\n/", $thermometerReadings )[1], $matches );
    $temperature = $matches [1];

    // Write to emoncms - Example http://192.168.178.24/emoncms/…on?node=1&csv=100,200,300
    // You may want to add other parsed values
    $url = 'http://' . $EmonCMSHost . '/emoncms/api/post.json?node=' . $ecmsSENSORID . '&csv=' . $temperature . '&apikey=' . $EmonCMSApiKey . '';

    $ch = curl_init ();
    curl_setopt ( $ch, CURLOPT_URL, $url );
    curl_setopt ( $ch, CURLOPT_RETURNTRANSFER, 1 );
    $contents = curl_exec ( $ch );
    curl_close ( $ch );
    }
    ?>[/php]

    Hallo Allerseits,


    Ich habe zur aktuellen wiringPi Version (2) eine PHP Extension gebildet und in PHP eingefügt. Mit einer PHP Klasse kann ich nun auf alle Funktionen von WiringPi zugreifen bzw. diese ausführen, wenn da nicht die Hürde mit den Rechten wäre:

    PHP
    <?php
    ...
    wp2::wiringPiSetup();
    ...


    wird leider mit einer Fehlermeldung im error.log quittiert:

    Quote


    wiringPiSetup: Must be root. (Did you forget sudo?)


    was mus ich tun, damit die Extension (wiringpi2.so) mit den nötigen Rechten ausgeführt wird?:helpnew:


    Gruß
    Gunter