Hallo liebes Forum, ich habe bisher mit Python ein Script geschrieben, welches die Luftfeuchte und Temperatur durch den DHT11 Sensor ermittelt. Mein nächstes Ziel ist es den DHT11 Sensor Plug & Play fähig zu machen. Ich hab im Internet gelesen das der DHT11 Sensor eine 1-Wire Komponente ist. Falls ich mich nicht irre sollte der Sensor doch eine eindeutige ID besitzen. Ich weiß aber nicht wie man diese ermitteln kann. Bitte um Unterstützung. Denn wenn ich die ID habe denke ich, dass ich den Raspberry PI sagen kann, dass sobald dieser Sensor angeschlossen ist mein Skript automatisch starten soll. Beste Grüße Stefan
Stefan309 schrieb: > Ich > hab im Internet gelesen das der DHT11 Sensor eine 1-Wire Komponente ist. ...halte ich für ein Gerücht! Es ist keine 1wire-Schnittstelle (und auch kein I2C), lasse mich aber auch gern belehren, wenn du die entsprechende Textstelle im Manual präsentierst...
50c schrieb: > (und auch kein I2C) Rainer U. schrieb: > Lies mal hier: > > https://www.mikrocontroller.net/articles/AVR_TWI warum?
Hallo 50c, link: https://www.laub-home.de/wiki/Sensorino_-_Auslesen_verschiedener_Sensoren_mit_Arduino ist der DHT11 aufgelistet. Dort steht unter Vorteile : 1-Wire Bus (Sensor ID, Reihenschaltung möglich). Hab ich etwas falsch verstanden? Um welche Schnittstelle handelt es sich denn dann? Ich lasse mich ebenfalls gerne von euch belehren! Ich bin noch ein Anfänger in dem Gebiet. Beste Grüße Stefan
Stefan309 schrieb: > Dort steht unter Vorteile : 1-Wire Bus > (Sensor ID, Reihenschaltung möglich). Hab ich etwas falsch verstanden? ...jupp, die Tabelle, die du hier zitierst gilt für den DS1820! Für den DHT11 steht da genau das Gegenteil. Oder sehe ich es falsch...?
Hi >Dort steht unter Vorteile : 1-Wire Bus >(Sensor ID, Reihenschaltung möglich). Hab ich etwas falsch verstanden? Ja. Das was du gelesen hast, steht beim DS1820. Abgesehen davon würde ich nur den Original Datenblättern trauen. MfG Spess
Mein Fehler ihr habt Recht.. Handelt es sich denn jetzt um ein TWO Wire Interface Rainer Unsinn? Wisst ihr worum es sich handelt bei dem DHT11?
Stefan309 schrieb: > Handelt es sich denn jetzt um ein TWO Wire > Interface 50c schrieb: > (und auch kein I2C) Was ist daran jetzt nicht zu verstehen? spess53 schrieb: > Abgesehen davon würde ich nur den Original Datenblättern trauen. korrekt, da steht es genau drin!
immer freundlich bleiben ok :-) Ja ist ja gut da steht Communication Process: Serial Interface (Single-Wire Two-Way). So und was machen wir nu in Richtung automatisieren?
Stefan309 schrieb: > immer freundlich bleiben ok :-) Ja ist ja gut da steht Communication > Process: Serial Interface (Single-Wire Two-Way). So und was machen wir > nu in Richtung automatisieren? gar nichts, denn, wie weiter im Datenblatt nicht (zu finden ist), würde man dazu eine eineindeutige ID benötigen... Bin doch freundlich und versuche dich in die richtige Vorgehensweise zu "schubsen" --> RTFM
Alles klar Meister. Hmm also ein anderer Gedanke.. Ist es möglich den Raspberry Pi beizubringen, dass sobald gewisse GPIO Pins belegt sind eine Aktion ausgeführt wird? Dazu müsste man ja nur die Belegung einmal abscannen und tadaaa Problem gelöst :-) ... Meinungen und Kritik??
Mit direkter Programmierung der GPIO Register z.B. in BASIC kein Problem: Risc OS pico BASIC https://www.riscosopen.org/content/downloads/raspberry-pi https://cdn-shop.adafruit.com/product-files/2885/BCM2835Datasheet.pdf
Stefan309 schrieb: > Ist es möglich den > Raspberry Pi beizubringen, dass sobald gewisse GPIO Pins belegt sind > eine Aktion ausgeführt wird? Dazu müsste man ja nur die Belegung einmal > abscannen und tadaaa Problem gelöst :-) ... Meinungen und Kritik?? ...und warum nicht einen Temperatur-/Luftfeuchtigkeits-Sensor verwenden, der busfähig ist?
Weil ich hier den SunfounderKit mit Anzahl > 30 Sensoren hab und so wie es aussieht diese alle nicht Bus Fähig sind :-) Also eine Alternative wäre da sehr gut. Ja ich weiß ich hätte mich besser informieren sollen aber damals wollte ich das ja noch gar nicht um Plug & Play erweitern.... @Lothar ich glaub das bringt mich jetzt aus dem Konzept gibt es da Beispiele für?? Niemals geb ich auf!!
> Ist es möglich den > Raspberry Pi beizubringen, dass sobald gewisse GPIO Pins belegt sind > eine Aktion ausgeführt wird? Dazu müsste man ja nur die Belegung einmal > abscannen und tadaaa Problem gelöst :-) ... Meinungen und Kritik?? Dein Sensor unterstützt eine Checksum. Du könntest also periodisch eine Liste von Pins abfragen (d.h. den im Datasheet spezifizierten 40-bit Dialog ausführen) und die Checksum prüfen.
Also die Checksum abfragen in Ordnung ich schau mir das mal an Danke!
Also hat jemand vlt. ein Beispiel dafür wie man das mit der Checksum ermittelt? Danke
Wenn du auf DHT11 klickst geht ein Fenster auf mit Link zum Datenblatt... http://www.aosong.com/asp_bin/Products/en/DHT11.pdf ...in dem du auch Beispiele für die Checksum findest.
Mikro 7. schrieb: > ...in dem du auch Beispiele für die Checksum findest. :-), sage ich doch --> RTFM
bei den sunfounder sensoren sind cds mit beispielen dabei, dort ist auch die checksumme dabei...
Stefan309 schrieb: > Also hat jemand vlt. ein Beispiel dafür wie man das mit der Checksum Ist in C musst Du also in Python oder BASIC umschreiben. Wobei es sein kann dass es in Python nicht geht wegen der Latenz. https://www.robot-r-us.com/vmchk/sensor-temp/humid/dht11-temperature-and-humidity-sensor.html
Lothar schrieb: > Ist in C musst Du also in Python oder BASIC umschreiben. Wobei es sein > kann dass es in Python nicht geht wegen der Latenz. ...wusste gar nicht, dass man keine C-Programme für einen Raspberry schreiben kann, wieder etwas dazugelernt ;-)
51c schrieb: > ...wusste gar nicht, dass man keine C-Programme für einen Raspberry > schreiben kann, wieder etwas dazugelernt ;-) Der Frager hat es aber doch in Python angefangen, vermutlich auf Linux :-) Wobei wohl das Linux für Latenz sorgen wird, egal ob in Python oder in C
Bit-Banging für das langsame und kurze DHT11-Protokoll sollte mit C (Userland) völlig unkritisch sein. Bit-Banging auf dem Pi wird ab ca. 1us Signalen (pro Level) und mit zunehmender Länge der Signalfolge kritisch. Timerabfrage und Leveländerunge benötigen im Mittel ca. 100ns. Man benötigt aber mehrere (mindestens 2) Timerabfragen pro Edge und ein bisschen C-Code (der auch mal auf einen 160ns Cache Fault laufen kann). Sollte es einmal zu Verzögerungen kommen, kann man bei vielen Protokollen den Dialog einfach wiederholen. Das gleich gilt, wenn das OS dazwischenfunkt. Die Grenze ist bspw. bei der WS2812b Ansteuerung erreicht (ein paar LEDs geht gerade noch so, wobei da schon viele Retrys notwendig sind).
Mikro 7. schrieb: > Bit-Banging auf dem Pi wird ab ca. 1us Signalen Unter Linux. Daher wurde ja schon auf ein RTOS BASIC verwiesen (pico: ziemlich verbreitet, ähnlich BASCOM, sehr einfach). Es gibt auch noch ein Bare Metal Pascal (Ultibo). Bare Metal in C ist hingegen schon ein ziemlicher Aufwand. Damit treten aber z.B. auch keine PWM Glitches auf.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.