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...
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
Stefan309 schrieb:> Handelt es sich denn jetzt um ein TWO Wire> Interface50c 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??
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.
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.
