Hi,
ich will zwei (am besten vier) DHT11 Sensoren an meinem RasPi Pico
betreiben. Leider klappt das nicht. Benutze ich nur einen Sensor, messe
ich plausible Temperaturen und Luftfeuchtigkeiten. Sobald ich den Code
aber auf 2 oder 3 Sensoren erweitere, erhalte ich nur noch 0 für Temp
und Hum für alle Sensoren. Kann mir jemand erklären, warum das so ist?
Falls es an der Wahl der Sensoren liegt: Kann man mehrere BME280er
gleichzeitig benutzen?
Das Problem wird vermutlich in "import dht" liegen. Kann die Library
überhaupt mit mehreren DHT Sensoren umgehen?
Ich habe auf einem Breadboard parallel zwei DHT21 und zwei BM280 laufen.
Die endgültige Platine kommt später. Allerdings habe ich es in C selbst
programmiert. Ich nutze eine eigene Library für die DHT21 (mit Nutzung
der PIOs). Das ganze läuft unter FreeRTOS SMP.
Ich hatte Anfangs ebenfalls Probleme. Die waren aber eher hausgemacht.
Das Timing der DHT21, die ich zum Test zur Verfügung hatte war leicht
unterschiedlich. Mit 3,3V hatte ich bei den DHT21 immer wieder mal
Bitfehler. Erst mit 5V + Pegelwandlern hatte ich ein stabiles Signal.
Nimm mal die measure Aufrufe raus, die werden in temperature() schon
implizit aufgerufen. Zu schnell nacheinander aufgerufen liefert measure
einen Fehler.
Sonst sehe ich im dht Code keinen Grund das es nicht mehrere Instanzen
erlaubt.
Mike W. schrieb:> sensor1.measure> sensor2.measure
In der Vergangenheit hat es sich immer bewährt, wenn man dem Aufruf
einer Methode ein Pärchen Klammern spendiert. ;-)
Norbert schrieb:> Mike W. schrieb:>> sensor1.measure>> sensor2.measure>> In der Vergangenheit hat es sich immer bewährt, wenn man dem Aufruf> einer Methode ein Pärchen Klammern spendiert. ;-)
Jo, das ist der Fehler. Warum sagt denn der Compiler nichts? Danke sehr.
Das ist nun die Ausgabe:
Temperature 1: 17 °C Humidity 1: 64%
Temperature 2: 20 °C Humidity 2: 52%
Die Sensoren sind 1 cm von einander entfernt. 3 Grad und 12% Unterschied
sind schon viel...
Michael H. schrieb:> Das Problem wird vermutlich in "import dht" liegen. Kann die Library> überhaupt mit mehreren DHT Sensoren umgehen?
=> Anscheinend geht das doch. Wenn man keine Klammern vergisst :-)
Rainer W. schrieb:> Mike W. schrieb:>> Falls es an der Wahl der Sensoren liegt: ...> Es kann auch an deinem Aufbau liegen (Kabellänge). Bei 3V3 ist der DHT11> etwas pingelig.
=> Wo wir gerade bei Kabellängen sind: Wie lang können die denn für
DHT11, DHT22 und BME280 maximal sein? Meine Ziel-Anwendung hätte nämlich
1 und 2 Meter Kabellänge. Bei HDMI, das meines Wissens auch I2C nutzt,
sind es max. 15 Meter.
Mike W. schrieb:> Jo, das ist der Fehler. Warum sagt denn der Compiler nichts? Danke sehr.
Weil's kein Fehler ist. Du fragst lediglich das Objekt ab und bekommst
die (ungenutzte und verworfene) Information das es sich um eine Funktion
handelt.
Mike W. schrieb:> Die Sensoren sind 1 cm von einander entfernt. 3 Grad und 12% Unterschied> sind schon viel...
Neee, das ist bei den schrottigen DHT-Sensoren normal!
Helmut -. schrieb:> Mike W. schrieb:>> Die Sensoren sind 1 cm von einander entfernt. 3 Grad und 12% Unterschied>> sind schon viel...>> Neee, das ist bei den schrottigen DHT-Sensoren normal!
Dann ist gut :-)
Gibt es denn wegen der Kabellänge für die BME280 Hinweise und
Erfahrugnen?
Mike W. schrieb:> Jo, das ist der Fehler. Warum sagt denn der Compiler nichts? Danke sehr.
das kann ich noch nicht nachvollziehen. Für den pico gibt es die dht lib
und da finde ich folgendes:
https://github.com/ikornaselur/pico-dht11/blob/f98c792d66bc5b8c3ee66059a95e67775c43e9dc/dht.py#L51-L59
Also wird da measure() beim Lesen des Properties aufgerufen, der
explizite wäre damit also nicht nötig.
In der Doku zu MicroPython steht der measure() Aufruf im Beispiel auch
drin, also gibt es da wohl verschiedene Implementierungen. Woher weiß
man jetzt welche tatsächlich verwendet wird?
Die anderen Sensoren SHT oder BME sind deutlich besser, die waren nur
lange nicht lieferbar oder wenn dann sehr teuer. Sieht es damit jetzt
besser aus?
Wenn du Schweizer Qualität bei den SHTs willst, musst du halt dafür
zahlen. Die Billigdinger, die als SHT angeboten werden, sind
China-Nachbauten, kommen aber an die Qualität der Originale nicht heran.
Und ob die BME alle von Bosch sind, ist auch eine Frage des Preises.
J. S. schrieb:> Also wird da measure() beim Lesen des Properties aufgerufen, der> explizite wäre damit also nicht nötig.
Dort (github Version) ist ›humidity()‹ explizit als Property einer
Klasse definiert.
Das kann man dann jedoch nicht - so wie Eröffnungspost beschrieben - als
Methodenaufruf abfragen, da gäbe es 'ne Kelle.
In der von dir gezeigten Klasse wäre
»wert = xxx.humidity«
richtig und »wert = xxx.humidity()«
würde eine Exception werfen.
Des weiteren:
Wenn ›measure()‹ nur implizit aufgerufen werden soll, warum heist das
olle Ding dann nicht zumindest ›_measure()‹?
Danke, ja, verstehe. Das MicroPython hat mittlerweile eine ganze Menge
Treiber (als C-Code) integriert, der dht gehört dazu und die Aufrufe
sehen anders aus als in externen py-only lib aus.
Python ist nicht meine Muttersprache, aber interessant finde ich es
schon.
Ist _measure() dann automatisch was in C++ private wäre? Gibt es sowas
wie private in python Klassen?
der Vollständigkeit halber, dann dürfte es dieser Quellcode sein:
https://github.com/micropython/micropython-lib/blob/7128d423c2e7c0309ac17a1e6ba873b909b24fcc/micropython/drivers/sensor/dht/dht.py#L24-L36
Und darin wird eine Funktion in C aufgerufen die das bitbanging macht.