[Erweiterung] Raspberry: 58_GPIO4 neben 1Wire jetzt auch für DHT11/DHT22

Begonnen von KölnSolar, 02 Juli 2021, 14:18:56

Vorheriges Thema - Nächstes Thema

Adimarantis

Zitat von: KölnSolar am 21 Oktober 2021, 11:18:20
Nein. Sowohl mit meinem GPIO4, als auch Deinem OneWire(es werden zwar 3 angezeigt, die sind aber immer 0) habe ich eine Nachkommastelle. Das liegt daher eher(glaub ich) an dem Unterschied DHT11/DHT22. Der 11er hat ja eine geringere Genauigkeit.
Gerade hab ich tatsächlich einen Wert 0 bei humidity mit OneWire beobachtet.
Wir nutzen ja beide die Kernel Schnittstelle - und die liefert zwar 3 Nachkommastellen, aber scheint diese gar nicht zu befüllen.
Mein DHT11 an sich, hat aber eine Nachkommastelle - wird nur ignoriert. Wie gesagt, mit meinem "Hack" von RPi::DHT11 bekomme ich die jetzt. Ich denke das Kernel Modul kann man vergessen. Zu instabil, ungenau und umständlich zu verwenden. Vielleicht schicke ich dir heute abend mal was zum probieren.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Ja gerne. Solange es absturzfrei und nicht dauerblockierend(sich auflösende freezes kann ich ertragen) ist, da ich nur produktiv testen kann.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Wie versprochen was zum Testen.
Einfach irgendwo auf deinem Raspi auspacken und dann im Verzeichnis dht
perl -I - test.pl
Im Idealfall kriegst du dann sowas wie:
Humidity = 70.0 % Temperature = 20.7 *C
T: 207  H: 700
Humidity = 70.0 % Temperature = 20.6 *C
Humidity = 70.0 % Temperature = 20.6 *C
T: 206  H: 700


Ich habe festgestellt, dass ein grosser Nachteil des ursprünglichen Moduls und auch des Kernel Treibers ist, dass man Temperatur und Humidity getrennt abfragen muss.
Auf Sensorebene geht das aber gar nicht - man holt immer beides. Dadurch erhört sich auch die Wahrscheinlichkeit, dass eins von beiden fehl schlägt.

Deswegen hab ich jetzt damit rumexperientiert, stattdessen ein Array zurückgeben ($dev->query)
Anschliessend führt ers nochmal einzeln aus ($dev->temp , $dev->humidity)

Aktuell macht er im Sekundentakt bis zu 3 retries - dann gibt er auf und man bekommt "undef"

Sollte somit als absolut verträglich sein.
Falls jemanden der Source Code interessiert, ich hab auf github einen fork from Original gemacht und meine Änderungen eingecheckt: https://github.com/bublath/rpi-dht11

Edit: Achja - wiringpi muss installiert sein (mit apt)

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

ZitatIm Idealfall kriegst du dann sowas wie
Glaub ich nicht. Wo mach ich denn die Definition des GPIO ?  ;)
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

ZitatEinfach irgendwo auf deinem Raspi
reichte nicht. Das hab ich noch kurzfristig lösen können.
ZitatAchja - wiringpi muss installiert sein (mit apt)
Hab ich natürlich nicht.  ::) Dauert also noch etwas....

Edit: läuft, aber ohne jeglichen Output. Any ideas ? GPIO# nach BCM, oder ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 22 Oktober 2021, 09:48:25
Edit: läuft, aber ohne jeglichen Output. Any ideas ? GPIO# nach BCM, oder ?
BCM, genau - wie beim Kernel Treiber auch.
Mehrmals probiert?
Irgendjemand hatte gemeint beim ih lief es erst wenn noch an einem Timingparameter gedreht wurde. Müsste ich erst konfiguriertbar machen....
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Mehrfach probiert. Nix. Beendet sich ohne Output.
Fehlerquellen, die ich sehe: DHT22(vs. DHT11), noch per dtoverlay eingebunden  :-\
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

#53
dtoverlay macht nichts - das hat bei mir nicht gestört.
Ich hab aber jetzt tatsächlich was gefunden, dass beim DHT22 anders ist (timing bei initialisieren am Anfang).

Man kann jetzt DHT22 einstellen (der dritte Parameter ist "debug"):
RPi::DHT11->new($pin,22,1);

bin gespannt ob das bei dir hilft.

Edit: Hab nochmal weiter am Algorithmus gefeilt (bzw. von einer anderen Quelle "inspirieren" lassen) so dass alles jetzt noch näher an der HW Spec läuft. Mit meinem DHT11 jetzt sehr stabil (schon mit FHEM Modul) - bisher keine fails (ok, er macht intern bis zu 3 retries).
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

schon besser  :D
Humidity = 2.175 % Temperature = 0.163 *C
T: 16.3  H: 19.5
Checksum error or insufficient data
Checksum error or insufficient data
Humidity = 2.175 % Temperature = 0.163 *C
Checksum error or insufficient data
Humidity = 2.175 % Temperature = 0.163 *C
T: 16.3  H: 19.5
T ist ok. H nicht. Ist 63,8%.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 23 Oktober 2021, 01:45:36
T ist ok. H nicht. Ist 63,8%.
Dann scheint zumindest das Timing der Abfrage jetzt zu passen - diese Checksum Error kriege ich auch - die Sensoren mögen es wohl nicht zu häufig abgefragt zu werden, aber mit den eingebauten retries klappt es eigentlich immer.
Bei meinen zwei DHT11 hatte ich bei Abfrage alle 60 Sekunden über Nacht nicht einen einzigen "failure" in FHEM.

Der Algorithmus für die Umrechung ist nur beim DHT22 auch anders. Tausch mal die angehängte Datei aus, dann klappt es hoffentlich. (nur die T: und H: beachten - die Humidity/Temperature= Ausgabe macht highbyte.lowbyte was beim DHT22 zu Quatsch führt).
Spannend it noch der Sonderfall negative Temperatur - aber das wirst du wahrscheinlich schlecht testen können :)
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Jetzt passt es.  8)

ZitatSpannend it noch der Sonderfall negative Temperatur
Klar. Ich guck mal, ob ich ihn mit Kühlpacks unter 0 kriege.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 23 Oktober 2021, 11:32:30
Ist Ok: auf -11,7 runtergekühlt.
Perfekt. Dann werd ich das noch entsprechend einbinden, Debian Paket dazu etc.
Werde es dann wohl RPi::DHT nennen, da es Gegensatz zum Vorbild beide DHTs unterstützt.
Frage mich noch wie das der Kerneltreiber macht, der ja auch DHT11 heisst aber bei dir trotzdem geht. Evtl. probiert der einfach durch.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Ok, jetzt hab mir aus Neugierde mal den Sourcecode vom Kerneltreiber angesehen. Der arbeitet mit Interrupts und kriegt da irgendwie hin beide DHT zu initialisieren (wie genau will ich mich jetzt nicht reindenken) - aber ich weiss jetzt wenigstens warum ich mit den Kerneltreiber fast nie Werte bekommen habe:
Der versucht anhand der Wertezusammensetzung zu erkennen ob die Daten zum DHT11 oder DHT22 passen. Dabei prüft er unter anderem ab ob die Dezimalstellen für Temperatur leer sind - mein Sensor (vielleicht ein neueres Modell) sendet aber 1/10 Grad - und somit streikt der Kerneltreiber ("kenn ich nicht") - mit dem Kernel kriege als nur die Komma Null Messungen.

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)