NEWS
DS18B20 mit RPi instabil
-
@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? ;)
-
@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.
-
@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...
-
@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:
Nichtsdestotrotz, den Widerstand (3,3KOhm) würde ich ggf nochmal prüfen ob der nicht besser reduziert werden sollte.
Hm, Datenblatt sagt 4,7k...
-
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 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
-
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 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 -
@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
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 nutzen ;)Zu 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.
-
@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 -
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 nutzen ;)Zu 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.
@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.
-
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.@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... -
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 -
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 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 -
Hey, danke euch alle für die Anregungen!
@Pete0815 Danke besonders dir, für die ausführlichen Erklärungen.
Nach dem ich die Messung allein mit T1 (Außenfühler) laufen ließ und danach mit den Fühlern T2-T9, musste ich feststellen, dass beide Varianten spontan abbrechen. :( Es liegt also nicht nur am Außenfühler (wie ihr ja schon befürchtet habt).
Beim Überprüfen der PulluP-Widerstände habe ich dann festgestellt, dass durch die 5,5 V die GPIOs der Busse 1 und 2 eine wegbekommen haben. Es stellte sich nämlich zwischen GPIO und dem Spannungspin, ein Widerstand von 27 kOhm ein. Bei den anderen GPIOs hingegen nur 40 MOhm.
Also habe ich nun erstmal die Busse auf neue GPIOs gelegt und teste T2-T9 über 3,3 V (Ohne Außenfühler). Alle anderen Ratschläge habe ich natürlich gelesen. Ich teste mich Stück für Stück durch. -
@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.
-
@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.
@unclesam Danke für den Tip Uncle Sam, ich kannte die Adapter noch nicht ;) Ich muss aber auf Jeden Fall auch die Temperaturen abspeichern können. Zur Zeit mach ich das in eine txt. Die kann ich ja dann in Excel gut weiter verarbeiten.
Des Weiteren habe ich die Überlegung (Wenn dann man die Temperaturmessung richtig klappt) ggf. auch aktive Elemente (Pumpen, Stellventile) zu schalten. Das wäre dann natürlich ein eues Vorhaben. Mein Ziel ist aber, dass mit besthendem Skript man dann daran anküpfen könnte.
Würde der Adapter sich dazu als Zwischenglied auch eignen?Nun aber erst mal eins nach dem anderen ;)
-
Hey, danke euch alle für die Anregungen!
@Pete0815 Danke besonders dir, für die ausführlichen Erklärungen.
Nach dem ich die Messung allein mit T1 (Außenfühler) laufen ließ und danach mit den Fühlern T2-T9, musste ich feststellen, dass beide Varianten spontan abbrechen. :( Es liegt also nicht nur am Außenfühler (wie ihr ja schon befürchtet habt).
Beim Überprüfen der PulluP-Widerstände habe ich dann festgestellt, dass durch die 5,5 V die GPIOs der Busse 1 und 2 eine wegbekommen haben. Es stellte sich nämlich zwischen GPIO und dem Spannungspin, ein Widerstand von 27 kOhm ein. Bei den anderen GPIOs hingegen nur 40 MOhm.
Also habe ich nun erstmal die Busse auf neue GPIOs gelegt und teste T2-T9 über 3,3 V (Ohne Außenfühler). Alle anderen Ratschläge habe ich natürlich gelesen. Ich teste mich Stück für Stück durch.@gari
klingt als kommst Du einen Schritt weiter auch wenn das Ergebnis gerade noch nicht so erfreulich klingt. Ob man die GPIOs so "durchmessen" kann k.A. Mir ist die Fummellei dort meistens mit Widerständen (Spannungsteilern) zu aufwendig und da ich eh örtlich in Abzweigkästen viel mit Dupontkabeln unterwegs bin führe ich die Sensorseite gerne voll in 5V aus und geht auf GPIOs, kommt ein Logic Shifter davor (Stückpreis 50Cent 4 Kanäle ;)).
https://de.aliexpress.com/item/32771873030.htmlViel Erfolg!
776
Online32.4k
Users81.5k
Topics1.3m
Posts