DS18B20 mit RPi instabil
-
Liebe Community,
nun wende ich mich doch noch an euch. Ich hatte gehofft, dass ich auf Grundlage der bisher im Forum gefallenen und nützlichen Hilfestellungen ich mein Problem lösen könnte. Nun weiß ich aber nicht mehr weiter. Folgendes:
Mein aktuelles Ziel ist es, 9 Temperaturen in unserem Heizungssystems mittels DS18B20 zu messen und zu loggen. Ein Sensor fällt aktuell immer wieder aus und die Messung bricht ab. Das ist mein Problem.
Ich habe mich neu in die Thematik eingearbeitet und mich vor 2 Monaten für einen RaspberryPi 4B mit Raspbian als Betriebssystem entschieden. Trotzdem ich Neuling in Python bin klappte der Start des Projekts sehr gut. Ich führte verschiedene Tests mit dem Breadboard durch, die bis auf kleine Probleme sehr gut funktionierten. Ich machte Kalibrierungsmessungen, um die Messwerte der DS18B20 mit einem geeichten Messgerät zu vergleichen und shiftete daraufhin einezlne Senosrwerte um -0,1 bis 1,3 K, um die Streuung zu verringern. Ich positionierte die Fühler an den Messstellen und installierte im Technikraum einen kleinen Schaltschrank, indem ich den RPi und die Klemmverteiler untergebracht habe.
Soweit so gut. Vor etwa einem Monat nahm ich das Mess-System in Betrieb. Erst schien alles gut. Doch das System läuft einfach nicht stabil.
- Folgende Kenndaten des Systems:
- Raspberry Pi 4B, Raspbian
- Betrieb nicht über parasite mode, sondern normal 3 poliger Anschluss (0,1,Bus)
- 3-Bussystem an GPIO 4, 17, 27
- sternförmige Verschaltung, siehe fritzing-Skizze. Skizze_Schaltplan_3_Busse.pdf
- Kabellängen der Sensoren: zwischen 1,5 m und 6 m, mit Ausnahme des Außenfühlers, ca. 30 m
- Kabelquerschnitt: 3 x 0,75 mm², alle: ungeschirmt, mit Außnahme Außenfühler: geschirmt
- 5,5 V Betriebsspannung (Empfehlung von AZ-Delivery bei Kabellängen über 1 m)
- PullUp-Widerstände: 2x 2,2 kOhm, 1x 3,7 kOhm
- Code temp_T1-T9_short.py
- Fehlerbeschreibung:
- Die Messung bricht scheinbar spontan nach 2 h bis 2 Tagen ab.
- Fehlermeldung im Shell: „list index out of range“
- Schaut man über das terminal, welche Sensoren gefunden werden, so fehlt dann immer der Außenfühler (T1)
- Ein neuer Compiliervorgang in Python ist ohne Fehlermeldung nach ca. 3 min möglich (vorher nicht. - Warum auch immer). Dann werden weiter alle Temperaturen richtig ausgeben. Nur aber nicht der Außenfühler. Für den Außenfühler (out_) erscheint in der shell: „out_: None“
- Nach Neustart des RPi werden alles Sensoren wieder gefunden und es werden für alle Sensoren Messwerte ausgegeben.
- Der Außenfühler startet aber nach Auftreten des Abbruchs und Neustart des RPi nicht fehlerfrei. Es werden Temperaturen ausgelesen, welche ca. 20 K zu warm sind. Innerhalb der ersten 3 Minuten des Messvorganges geht die Überhitzung zurück und der Wert des Außenfühlers stimmt mit einer Vergleichsmessung überein.
- Fehlerinterpretation
- Ich denke, dass es wahrscheinlich mehrere Fehlerquellen gibt.
- Bitte checkt deswegen auch meinen Code. temp_T1-T9_short.py
- Eine Quelle ist der Ein- bzw. Auschaltprozess des 3-Phasen-Ventilator des Luftkollektors (LK-Ventilator). Wenn dieser ausschaltet bricht das Mess-System (fast immer) ab und es erscheint die Fehlermeldung in der Shell. Leider ist wie gesagt dieser Fehler nicht immer 100% reproduzierbar. Manchmal schaltet man den LK-Ventilator aus, und die Messung bricht nicht ab. Sehr oft fallen aber das Ausschalten des LK-Ventilators und das Abbrechen der Messung zusammen und anschließend läuft die Messung wieder einige Stunden fehlerfrei. Eine Korrelation beider Ereignisse liegt sehr nahe, da das Kabel des LK-Ventilators neben dem Kabel des geschirmten Außenfühlerkabels verlegt ist und eine Induktion möglich ist.
- Die Messung ist aber auch schon abgebrochen, als der Ventilator bereits aus war.
- Lösungsansätze
Ich möchte euch an dieser Stell nicht gleich auflisten, was ich bereits alles versucht habe, um keinen falschen Fokus zusetzen und euch einen unvoreingenommen und kreativen Geist zu bewahren. Außerdem würde meine Beschreibung dann noch viel, viel länger werden...
Ich wäre euch sehr, sehr dankbar, wenn ihr mir weiterhlefen könntet!!
bis bald
Gari -
@gari
Hallo Gari,bin jetzt auch nicht der Experte, hatte aber selbst auch schon diverse "spaßige" Zeiten mit den DS18B20.
Zu erst bin ich über Deinen Aufbau des "Sternförmigen" Buses "gestolpert". Hier empfinde ich insbesondere die Leitung zu T1 als schwierig. Du scheinst dort zwar Dinge durch unterschiedliche Pull-Up Widerstände berücksichtigt zu haben, aber allgemein glaube ich verstanden zu haben, dass Stichleitung ab gewissen Längen immer etwas schwierig sind.
Dazu sind 30m Kabellänge 5V und 0,75mm² nicht wirklich etwas was, was ich blind vertrauen würde (Spannungsabfall und gesicherter Betrieb/Übertragung etc etc.).
Hast Du eine Möglichkeit Details über "list index out of range" zu erfahren?
Bei mir kamen durch temporäre Messfehler/fehlerhafte Sensoren immer der Defaultwert des DS18B20 zurück -127Grad.
Da es bei mir nur extrem selten vorkam, gehe ich hin und filter die 127Grad einfach per Software als ungültiger Wert raus aber bei Dir würde ich ehrlicherweise anders vorgehen und mit etwas mehr "Standard" Bastelware arbeiten. Hierzu würde ich die Stränge auftrennen und jeweils einzeln an einen Pin eines ESP8266 hängen und diesen mit einer Standardsoftware wie Tasmota oder ESPeasy betreiben, als Testaufbau um die Fehlerquelle einzugrenzen.
Läuft das stabil, dann mal den gesamten Bus an einen Pin des ESP8266 hängen und oder in Teilschritten. Je nach Ergebnis würde ich dann Umbauen und Umrüsten oder Deinen Aufbau Debuggen. Der Testaufbau mit Standard-Bastelsoftware wäre für mich der einfachste und günstigste Weg hier Ergebnisse zu bekommen.
An dem Bus selber "rummfummeln" da gehen Stunden bei drauf was am Ende wenig bringt..... so meine Erfahrung. Bei der Software gibt es diverse Fallstricke wie Bibliotheken und Auflösungen wie die DS18B20 angesprochen werden. Da ich da nicht im Detail drin stecke und auch das Rad nicht neu erfinden muß, ist der Tasmota/ESPEasy Ansatz ein recht einfacher und verlässlicher wie ich finde um zu probieren ob es an der Software oder am Bus liegt etc etc.Viele Grüße
-
@gari hier ist eine gute OneWire-Beschreibung - https://wiki.fhem.de/wiki/1-Wire_Busverlegung
Diese bestätigt, dass Sternverdrahtung ab 3,5m problematisch ist...
-
@jleg @Gari
Sorry ich glaube das hab ich jetzt reingebracht, wenn man genau schaut ist das kein Stern. Es sind 3 einzelne Buse am RPI an 3 GPIOs.Ist das so richtig mit den Pull-Ups? Hab gerade im Kopf, je länger die Leitung umso kleiner der Widerstand. Minimal habe ich was von ca 1,2kOhm im Kopf.
-
@pete0815 sagte in DS18B20 mit RPi instabil:
Sorry ich glaube das hab ich jetzt reingebracht, wenn man genau schaut ist das kein Stern. Es sind 3 einzelne Buse am RPI an 3 GPIOs.
...und 2 davon sind Sterne, oder?
-
@jleg sehe ich nicht sorry.
violet, gelb und orange sind für mich unabhängige Buse.
An Bus "gelb" und Bus "orange" hängen in Serie weitere DS18B20 also warum Bus1/T1 Probleme macht würde ich in erster Instanz nicht aus diesem Aufbau der weiteren Sensoren sehen.
Nichtsdestotrotz, den Widerstand (3,3KOhm) würde ich ggf nochmal prüfen ob der nicht besser reduziert werden sollte. Dann einfach mal den Bus1 an einen ESP8266 hängen mit ESPEasy und gucken ob das funktioniert. Bei Problemem mit dem PullUp wurden die Sensoren bei mal einmal gar nicht erkannt/angezeigt und nach richtigem PullUp lief ESPEasy sofort mit dem Sensor.
-
@pete0815 sagte in DS18B20 mit RPi instabil:
An Bus "gelb" und Bus "orange" hängen in Serie
Fritzing ist zwar denkbar ungünstig imo, aber für mich hängen die parallel...
-
@pete0815 sagte in DS18B20 mit RPi instabil:
Nichtsdestotrotz, den Widerstand (3,3KOhm) würde ich ggf nochmal prüfen ob der nicht besser reduziert werden sollte.
Hm, Datenblatt sagt 4,7k...
-
@gari sagte in DS18B20 mit RPi instabil:
Lösungsansätze
- ich würde mal T1 alleine testen
- das hier muss nichts heissen (ich habe diverse dieser Fakes im problemlosen Dauereinsatz), wäre aber vielleicht trotzdem interessant zu wissen: https://github.com/cpetrich/counterfeit_DS18B20
-
@gari said in DS18B20 mit RPi instabil:
Code temp_T1-T9_short.py
Wenn ich das Programm richtig verstehe, liest du zyklisch ohne jegliche Pause die Sensoren. Dabei wird jeder Sensor 2x hintereinander gelesen (mit 0,005 Sek. Pause dazwischen). Damit wird wohl der Sensor geweckt, abgefrat und dann beim zweiten Mal das Resultat der (vorherigen) Messung übertragen.
Das halte ich insbesondere bei der Leistungslänge des Außenfühlers für sehr sportlich. Hier kann es etwas dauern, bis die Spannung am Bus stabil steht.
Ich würde zwischen den Sensorabfragen eines Sensors etwas länger warten, um mögliche Probleme auf dem Bus möglichst gering zu halten.
https://forum.arduino.cc/t/ds-18b20-delay/580691/2 -
Ja, Pete, genau so ist es.
Die Snesoren T2-T4 sind ein Bus. Und untereinander sternförmig verschaltet.
Die Sensoren T5-T9 sind ein Bus. Und untereinander sternförmig verschaltet.
Wobei ich ehrlich zugeben muss, dass ich parallele und sternförmige Verschaltung an dieser Stelle für das gleiche halte und keinen Unterschied dazwischen erkenne.Der Sensor T1 hat einen separaten Bus. Und demnach einen separaten Pin.
Danke, dass ihr an dieser Stelle meine Verschaltung hinterfragt!Da T1 aber eigenen Bus hat, und auch dann nicht stabil läuft, halte ich es für eher unwahrscheinlich, dass die Ursache für die Spontanabbrüche die Verschaltung ist.
Bevor ich 3 separate Busse verwendete, lief das System auf 2 Bussen. Und ganz am Anfang auf einem. Immer erschien das gleiche Problem. Es scheint sogar, dass nun mit T1 auf einem separaten Bus das System am instabilsten ist. -
An alle @Pete0815 @JLeg @hans_999 ,
danke für eure Antworten!
Ich bin neu hier im Forum und begeistert, über euere schnelle Reaktion. Vielen, vielen Dank!
Wie ihr merkt, muss ich mich noch etwas darin üben, die Antwortoptionen richt zu nutzenZu den PullUp-Widerständen:
Mir ist bekannt, dass 4,7 kOhm im Datenblatt gelistet sind.
Wie hier bei einem ähnlichen Thema im Forum bin ich darauf gestoßen, die PullUps mit steigender Kabellänge zu reduzieren.
Folgende PullUp-Widerstände habe ich daher bereits für alle 3 Busse ausprobiert:- 2,2 KOhm
- 3,7 kOhm
- 4,7 kOhm
- 10 kOhm (auf Empfehlung eines anderen Bastlers)
Leider ohne nennenswerten Erfolg.
-
@jleg Danke für deinen Lösungsansatz: Ich werde nun als nächstes Testen, nur T1 ohne andere Sensoren zu messen.
-
@hans_999 said in DS18B20 mit RPi instabil:
liest du zyklisch ohne jegliche Pause die Sensoren
Danke hans_999, für den Hinweis! Werde ich auch mit mehr delay ausprobieren!
-
@gari Insbesondere der Aufbau mit 30m macht es notwendig sehr nah an den Specs zu arbeiten, da sonst etliche Effeckte auftreten. Viele der im Netz gezeigten Lösungen funktionieren, aber halt nicht für Aufbauten wo der OneWire Bus auch auf seine möglichen Längen genutzt wird.
Erster Punkt Dein Anschluß am RPI ist so nicht gesund für den RPI. Du versorgst die DS18B20 mit 5V und so bekommen die GPIOs auch im worst case 5V ab, wobei sie nur für 3,3V spezifiziert sind.
Den Aufbau mit 3,3V zu speisen halte ich für einen Versuch der nicht funktionieren wird, da bei 30m der Spannungsabfall schon gefährlich nah an die Grenze der 3V der DS18B20 abfällt und so ggf zusätzliche Probleme schafft.
Wenn dieser "einfache Aufbau" direkt am RPI gewählt wird, ist ggf dieser Aufbau zu testen:
oder
Wenn ich Deinen doch sehr schönen Aufbau mit Reihenklemmen etc sehe, würde ich auch hingehen und den OneWireBus mit einem richtigen OneWire Master aufbauen wie dem DS2482. Habe so einen so im Betrieb und bei Interesse schau Dir mal an wie das Module vom volkszähler projekt umgesetzt wurde.
Das dürfte hier natürlich too much sein, es gibt aber kleine Breakout Boards für den DS2482 für mehrere Stränge wie dieses. Das ist dann über 5V zu speisen und der per I2C anzukoppeln aber auch über einen LogicShifter auf 3,3V zu bringen um korrekt an den GPIOs zu arbeiten.
Vermutungsweise bringen aber bis auf die 3,3V am GPIO des RPI wenig Effekte die man sofort sieht. Entsprechend ist auch Dein Busaufbau dringenst zu überdenken bzw. derzeit so zu interpretieren, dass Du Stubs von bis zu 6m hast und davon wird nebem einem Sternförmigen Aufbau was das dann am Ende so ist, dringend abgeraten. Du hast dort doch genügend GPIOs zu Verfügung am RPI. Hänge die DS18B20 doch mal einzeln an den RPI; per GPIO nur einen DS18B20. Damit sollten wenn vorhanden Timing Probleme falls durch Wechselwirkung erzeugt werden, erledigt sein. Timing Probleme durch Leitungseffeckte(Länge) natürlich nicht.
Um Probleme durch den eigenen Code zu identifizieren kann ich mich wie gesagt nur wiederholen. Einen ESP8266 mit einer Standardsoftware wie ESPEASY oder Tasmota sollte das einfach für 2,3€ mal im Testaufbau prüfbar machen. Aber vorsicht für den ESP8266 gilt das gleiche wie für den RPI. Der verträgt auch nur 3,3V auf den GPIOs und mit 5V sollte man bei 30m schon versorgen. 2,3€ im Testaufbau finde ich immer noch sinniger als stundenlang einen eigenen Code im Revue zu besprechen, weil es verwertbare Fakten schafft.
-
@gari sagte in DS18B20 mit RPi instabil:
Wobei ich ehrlich zugeben muss, dass ich parallele und sternförmige Verschaltung an dieser Stelle für das gleiche halte und keinen Unterschied dazwischen erkenne.
naja, im Fall "OneWire" geht es natürlich um "mechanische" Sterne, nicht "elektrische". Denn elektrisch sind es ja (je Bus) Parallelschaltungen.
Als unproblematischer (stabiler) angesehen wird beim DS18B20 allgemein halt die Verdrahtung, die eher nach Art der "Weihnachtslichterketten" aufgebaut ist - Sensor B hängt eher dicht an Sensor A, und C dito an B usw. Aber das ist eigentlich alles hübsch im oben bereits genannten Link dargestellt, auch visuell... -
@gari Darf ich mich hier auch noch einschalten und fragen, weshalb du ein separates Skript verwendest und nicht einfach einen der bestehenden Adapter? Es gibt den iobroker.ds18b20 und den owfs Adapter.
-
@gari Habe eine ähnliche Hardware-Config wie Du. Bei mir sind es 10 Stück DS18B20, die ich auf einem Verteiler zusammen führe. Als Pullup-Widerstand habe ich 4K7 genommen. Allerdings habe ich auf der Betriebsspannung am Verteiler noch einen 100nF und einen 100µF Kondensator gesetzt. Läuft seit Jahren stabil bei mir.
-
ich hatte nach dem Wechsel auf den Raspi4 auch das Problem. Bei mir half in der
"/boot/config.txt" den GLIO Pin mit einzutragen.
dtoverlay=w1-gpio,gpiopin=4 -
@volbuss Jo, hab ich bereits .
