DHT22 läßt sich nach Update auf Raspi2ModB nicht mehr auslesen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusammen,

    manchmal möchte man doch echt verzweifeln. Also erstmal durchatmen.

    Mein DHT22, direkt an einem Raspberry Pi 2 Model B angeschlossen, läßt sich einfach nicht mehr auslesen, nachdem ich dem Raspi ein Update verpaßt hatte.

    Zuvor hatte alles wunderbar funktioniert. Es handelt sich dabei um eine kleine Wetterdatenstation mit einer Basisstation auf dem Schreibtisch (Raspi + DHT22 + DS18B20 + Funkmodul) und einer batteriebetriebenen Außenstation auf dem Balkon, basierend auf einem Atmega und diversen Sensoren (u.a. ein zweiter DHT22). Hatte sogar angefangen, das mal in einem kleinen Blog zu beschreiben (skunklog.de), da sind auch ein paar wenige Bilder drin. Nicht mehr ganz aktuell.

    Und ich bin mir fast sicher, dass es nur am Raspi-Update selber liegen kann.

    Weil:

    1.) der Tausch beider DHT22 zwischen Basisstation und Außenstation zeigt, dass beide DHT22 an der Außenstation einwandfrei Daten liefern, nicht aber der, der jeweils am Raspi angeschlossen ist.

    2.) Die Wetterdatenstation lief in der ersten Jahreshälfte mehrere Monate völlig stabil. Also kann ich mich beim Anschließen und Auswahl des Widerstands etc nicht wirklich vertan haben.

    3.) Nach einem Stromausfall lief das Teil mehrere Monate nicht mehr und erst die letzten Tage fand ich wieder Zeit, mich darum zu kümmern. Nach einem ersten Anschalten bzw Restart lief alles sofort wieder problemlos.

    4.) Dann "gönnte" ich mir eine Tasse Kaffee dem Raspi ein Update (sudo apt-get update, sudo apt-get upgrade). Tja... und erst seitdem krieg ich keine Daten mehr aus dem DHT22 am Raspi ausgelesen.

    Natürlich hab ich das Internet und auch dieses Forum hier entsprechend halbwegs durchsucht und scheinbar bin ich nicht ganz allein mit diesem Problem.

    Aber eine echte Lösung hab ich nicht gefunden. Das muss irgendwas mit der verwendeten Library (?) von Adafruit zu tun haben. Wo genau da der Hase im Pfeffer liegt, weiß ich aber eben nicht und im Moment gehen meine Gedanken eher in Richtung Verwendung eines alternativen Sensors (SHT31-D, auch von Adafruit). Der DHT22 war schon immer irgendwie speziell und fast wie eine Diva. Aber wie gesagt, wahrscheinlich liegts nicht am Sensor selber, sondern am Treiber oder was auch immer da von Adafruit verschlimmbessert wurde. Schon seltsam das.

    Hat jemand irgendeinen Tip für mich?

    :conf:

    Viele Grüße

  • DHT22 läßt sich nach Update auf Raspi2ModB nicht mehr auslesen? Schau mal ob du hier fündig wirst!

  • Moin Raspbuino,

    die Frage ist, von wo bist du gekommen? Wie lange hast du kein Upgrade gemacht?

    Kontrolliert ob das Overlay für den DHT22 noch so heißt oder andere Parameter hat?

    Schon mal den Mitschreiber (logdatei) gefragt?

    Ansonsten würde dein Script/Code helfen.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Hallo Bernd,

    erstmal herzlichen Dank, daß Du Dich der Sache angenommen hast!

    Hab mal den wesentlichen Code zusammengeschrieben und einen kleinen Hinweis habe ich vielleicht, in welcher Richtung etwas vielleicht nicht (mehr) ganz stimmt. Der Reihe nach.

    Das vorletzte Update/Upgrade vor dem letzten lief bestimmt schon vor etwa einem Jahr. Dazwischen hatte ich mich um sowas nicht mehr gekümmert. Im Grunde lief die Sache ja auch perfekt bis ich den Raspi nach einem Stromausfall eben ausgeschaltet hatte und mich zeitmäßig nicht weiter kümmern konnte (und einen Autostart hatte ich nicht programmiert). Auf jeden Fall aber war das schon Python 3. In Python 2 hab ich nie programmiert.

    Hier der Code, der so im "großen" Programm bisher funktioniert hat:

    Damit probiere ich im Moment jetzt halt etwas rum.

    Hab auf nem Breadboard jetzt auch nur den DHT22 angehängt und zwar mit dem Datenpin auf dem Raspi-Pin 3 (= BCM-Code 2). Widerstand zwischen Datenpin und VCC (3.3V) sind 8.2kOhm.

    Und "interessante" Hinweise kommen ans Licht.

    Der Codeschnipsel wird mit "sudo python3 DHT22test.py" gestartet.

    Ohne das "sudo" krieg ich folgende Fehlermeldung:

    Traceback (most recent call last):

    File "DHT22test.py", line 9, in <module>

    Feuchte, Temperatur = Adafruit_DHT.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHThttp://-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/common.py", line 77, in read

    return platform.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHThttp://-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/Beaglebone_Black.py", line 213, in read

    raise RuntimeError('Error accessing GPIO. Make sure program is run as root with sudo!')

    RuntimeError: Error accessing GPIO. Make sure program is run as root with sudo!

    Mit dem "sudo" läufts aber es sieht dann halt so aus:

    pi@raspberrypi:~/Mirko $ sudo python3 DHT22test.py

    Feuchte : None

    Temperatur: None

    Keine Daten also. Je nachdem, zu welchem Zeitpunkt ich das Programm beim Abbruch mit Strg+C "erwische", bekomme ich manchmal (nicht immer!) dann folgende Fehlermeldung bzw Hinweis:

    pi@raspberrypi:~/Mirko $ sudo python3 DHT22test.py

    Feuchte : None

    Temperatur: None

    ^CTraceback (most recent call last):

    File "DHT22test.py", line 9, in <module>

    Feuchte, Temperatur = Adafruit_DHT.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHThttp://-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/common.py", line 77, in read

    return platform.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHThttp://-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/Beaglebone_Black.py", line 208, in read

    result, humidity, temp = driver.read(sensor, gpio[0], gpio[1])

    KeyboardInterrupt

    Das hat mich jetzt echt stutzig gemacht und etwas ratlos.

    Scheinbar wird da auf nen Treiber zurückgegriffen, der eher was mit einem "Beaglebone_Black" anstellen will.

    Sehr verwirrend das alles (zumindest für mich :-/).

    Die Frage mit den Overlays kann ich nicht so ganz beantworten, weil ich da ehrlich gesagt nicht 100%ig firm bin, wonach ich da jetzt genau schauen müßte und wo da eine LOG-Datei versteckt ist, weiß ich leider auch nicht.

    Hier aber mal zumindest die Eintragungen aus config.txt:

    # For more options and information see

    # http://rpf.io/configtxtreadme

    # Some settings may impact device functionality. See link above for details

    # uncomment if you get no picture on HDMI for a default "safe" mode

    #hdmi_safe=1

    # uncomment this if your display has a black border of unused pixels visible

    # and your display can output without overscan

    #disable_overscan=1

    # uncomment the following to adjust overscan. Use positive numbers if console

    # goes off screen, and negative if there is too much border

    #overscan_left=16

    #overscan_right=16

    #overscan_top=16

    #overscan_bottom=16

    # uncomment to force a console size. By default it will be display's size minus

    # overscan.

    #framebuffer_width=1280

    #framebuffer_height=720

    # uncomment if hdmi display is not detected and composite is being output

    #hdmi_force_hotplug=1

    # uncomment to force a specific HDMI mode (this will force VGA)

    #hdmi_group=1

    #hdmi_mode=1

    # uncomment to force a HDMI mode rather than DVI. This can make audio work in

    # DMT (computer monitor) modes

    #hdmi_drive=2

    # uncomment to increase signal to HDMI, if you have interference, blanking, or

    # no display

    #config_hdmi_boost=4

    # uncomment for composite PAL

    #sdtv_mode=2

    #uncomment to overclock the arm. 700 MHz is the default.

    #arm_freq=800

    # Uncomment some or all of these to enable the optional hardware interfaces

    dtparam=i2c_arm=off

    #dtparam=i2s=on

    dtparam=spi=on

    # Uncomment this to enable the lirc-rpi module

    #dtoverlay=lirc-rpi

    # Additional overlays and parameters are documented /boot/overlays/README

    # Enable audio (loads snd_bcm2835)

    dtparam=audio=on

    # DS18B20

    dtoverlay=w1-gpio

    gpiopin=4

    ---------------------

    Wär toll, wenn Du oder jemand anderes noch einen weiteren Hinweis hätte.

    Viele Grüße,

    Mirko

  • Moin Mirko,

    es gibt ein Overlay für die DHT-Familie. Hier mal ein Auszug aus /boot/overlays/README

    Code
    Name:   dht11
    Info:   Overlay for the DHT11/DHT21/DHT22 humidity/temperature sensors
            Also sometimes found with the part number(s) AM230x.
    Load:   dtoverlay=dht11,<param>=<val>
    Params: gpiopin                 GPIO connected to the sensor's DATA output.
                                    (default 4)

    Du solltest in der /boot/config.txt das overlay einfügen. Denke an die richtige Pinzuweisung. Du kannst es ja erstmal mit dem Testprogramm probieren.

    Bedenke das der DS18B20 schon an pin4 hängt.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Danke für den Hinweis, allerdings hat das nichts gebracht.

    Die config.txt sieht am unteren Ende jetzt so aus (nach Änderung Neustart):

    # DS18B20

    dtoverlay=w1-gpio

    gpiopin=4

    # DHT11

    dtoverlay=dht11

    gpiopin=2

    Ich hoffe, ich habs so wenigstens richtig eingetragen.

    Grüsse,

    Mirko

  • Das mit 1-Wire auf Pin4 hatte allerdings vorher auch durchaus funktioniert (da hängt der DS18B20 dran).

    Höchstwahrscheinlich auch nur, weil das der Default ist ;)

    Soviel zum Thema: "kann nicht an meiner Konfiguration/Software liegen, der update ist schuld ..."

    cu,

    -ds-

  • Moin Mirko,

    also, dieser Code

    mit diesem Ergebnis

    Gruss Bernd

    /edit mein erstes pythonprogramm!!!

    /edit Eintrag in der config.txt

    Code
    # Test
    dtoverlay=dht11,gpiopin=2

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

    Einmal editiert, zuletzt von Bernd666 (27. Dezember 2018 um 14:55)

  • Hallo Bernd,

    tja - herzlichen Glückwunsch!

    Also bei mir klappt das so leider nicht und wie gesagt, VOR dem Update hats ja bei mir funktioniert (auch ohne den Eintrag in config.txt).

    Kontakte und Widerstand hab ich grad nochmal geprüft. Passt soweit.

    Werd auf nen anderen Sensor (SHT31-D über I2C) setzen. Hat mich die Tage echt genug Nerven gekostet.

    Interessant fänd ichs aber schon, ob ich der einzige bin, der nach dem Update die Probleme hat.

    Vielen Dank für Deine Mühe!

    Grüße,

    Mirko

  • Moin Mirko,

    wir reden aber von Raspbian Stretch??

    Weil da passt einiges nicht!

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHThttp://-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/common.py", line 77, in read

    return platform.read(sensor, pin)

    Das sagt das du python 3.4 hast und die Library für DHT die Version 1.3.1 ist.

    Bei mir sieht es so aus

    Zitat


    @bernd-test:~ $ ls -l /usr/local/lib/python3.5/dist-packages/Adafruit_DHT-1.4.0-py3.5-linux-armv7l.egg/

    Also python3.5 und DHT 1.4.0

    Gruss Bernd

    /edit: Bei mir geht es auch ohne den Eintrag in der config.txt.

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Oh....

    danke fürs genaue Hinsehen!

    Also da sieht man wieder mal, wie schnell die Zeit vergeht. Hab zwar schon von Stretch gehört aber hab mir gedacht, naja, ich hab ja ein -normales- Update gemacht. Also alles gut.

    Nee, nix ist gut - einmal mehr muss man sich kümmern. Nichts bleibt wie es ist und das hat nicht immer nur Vorteile. Selber schuld also.

    Werd also zunächst Sicherungskopien machen und dann gehts an eine saubere Neuinstallation...

    Ich weiß ja nicht, ob ich der einzige bin, der das nicht grade jeden Tag macht. So sehr mit Linux gefällt - ich glaub ich werds nie wirklich verinnerlichen. Aber ich arbeite dran.

    Mmmist.

    ;)

  • So....

    ein gepflegtes Glas Rotwein, einen Döner, etwas Schokolade, eine ausgedehnte Runde mit unserer Hündin und so manchen Kaffee später melde ich mich nun von meinem nagelneu aufgespielten Raspbian Stretch mit folgendem Text, frisch aus dem Terminal kopiert:

    :bravo2:

    Das war es! Es hat was nicht zusammengepaßt! Was genau da im Hintergrund nicht zusammengearbeitet hat, werd ich wohl nie erfahren. Egal.

    Lieber Bernd,

    Du hast mir den entscheidenden Hinweis gegeben und dafür ein herzliches Dankeschön!!

    :danke_ATDE:

    Mir bleibt die Erkenntnis, dass ich das jetzt auch Stück für Stück bei den restlichen Raspis, die bei mir rumliegen, auch noch tun müßte. Alles zu seiner Zeit.

    Und natürlich, dass man nicht zu schnell aufgeben darf.

    Danke auch an das Forum an sich!

    Viele Grüße,

    Mirko

  • Moin Mirko,

    gerne, dafür machen wir das hier!

    Danke für die Rückmeldung!

    Dann, bitte, noch dein Thema als erledigt markieren. Das geht oben bei "Thema bearbeiten".

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!