1-wire-Bus mit DS18B20 steigt immer wieder aus

  • Hallo,


    ich bin neu hier im Forum, bringe aber schon etwas Erfahrung mit dem Raspi3 mit.

    Seit ca. 1 Jahr habe ich eine Temperaturmesung mit 3 Stück DS18B20 am Laufen, Kabellängen 3-6 Meter, am 1-wire Bus des raspi.

    Das kann wochenlang reibungslos funktionieren, und auf einmal steigt die Messung aus und bleibt dann weg. Dann wird kein Sensor mehr erkannt. Selten hilft dann ein einfacher sudo reboot; schon häufiger hilft ein reboot mit zwischenzeitlichem Stromabschalten (das geht aber nur vor Ort!); manchmal half sonst auch noch ein apt-get upgrade oder raspi-update, manchmal brauchte es x Neustarts. Verwunderlich finde ich, dass das Problem, wenn es erst mal aufgretreten ist, nicht mal durch sudo reboot zu beheben ist. Was ist da verrutscht? (edit: vergleiche dazu auch https://www.raspberrypi.org/forums/viewtopic.php?p=498758)


    Erschwerend für die Eingrenzung des Problems ist das seltene Auftreten. Die letzten 3 Male (= 3 Monate Testzeit) ist das Problem aber jeweils zeitlich eng mit dem Abschalten eines weiteren Verbrauchers (Gefriertruhe) im gliechen Stromkreis (gleiche Steckdose) aufgetreten, so dass ich auch schon an Überspannungen dachte. Andere Störungen waren am Pi nie festzustellen.

    Das Ding soll headless in 50 km Entfernung stabil laufen, so dass monatliche Messprobleme (die dann aus der Ferne praktisch nicht zu beheben sind) nicht tolerierbar sind.

    Ach so, ich habe natürlich schon gefühlte tausend verschiedene Konfigurationen durchprobiert, wie im Internet zu finden (Treiber, Bootkonfig, Pullup-Konstellationen und -werte, Sensorzahl, Kabellänge), ohne dass irgendwas davon eine Änderung erbracht hätte. Was bisher noch nicht probiert ist: Abschalten des device tree (mangels Kompetenz und mangels Hoffnung auf Erfolg), Betreiben der Sensoren an 5 Volt (aus Angst um den Raspi).


    Ich vermute nun eher, dass es irgendwie mit der Speisespannung zusammenhängt, die einen Peak oder Dip erfährt, wenn nebendran etwas ausschaltet. Ob das durch die 5-V-Versorgungsleitung reinkommt oder per Störfunk durch die Sensorleitungen, da habe ich noch keinen Hinweis.


    Für Tips wäre ich höchst dankbar. Natürlich kann ich auch diverse Config-, Log- oder Treiberinfos noch nachliefern, aber derzeit nur aus dem funktionierenden Zustand heraus.

    Edited once, last by 1wire: neue Quelle gefunden ().

  • manchmal half sonst auch noch ein apt-get upgrade oder raspi-update, manchmal brauchte es x Neustarts. Verwunderlich finde ich, dass das Problem, wenn es erst mal aufgretreten ist, nicht mal durch sudo reboot zu beheben ist. Was ist da verrutscht?

    Vor dem apt-get upgrade musst Du ein apt-get update durchführen, sonst wird die Paketindexdatei nicht mit ihren Quellen syncronisiert. (Siehe < man apt-get >)


    Schlimmer ist aber raspi-update, mit dem Du Dir einen instabilen (Entwickler-) Kernel installierst. Das ist für normale Linux-Pi Anwender inzwischen ein absolutes No Go !



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hallo RTFM,


    danke für den Hinweis!

    - update vor upgrade ist jeweils passiert, klar.

    - das mit dem raspi-update war dann natürich blöd (obwohl die Messung danach erst mal wieder lief). ich werde mal recherchieren, ob das evtl. zurückzuwälzen ist. (edit: aktuelle Kernel version: 4.14.27-v7+)

    Edited once, last by 1wire: Kernel-Version herausgefunden ().

  • Moin 1wire,


    erstmal: Herzlich Willkommen im Forum!


    Die erste Frage die mir so durch den Kopf schoss, war das schon immer so? Sporadische Ausfälle.

    Die letzten 3 Male (= 3 Monate Testzeit) ist das Problem aber jeweils zeitlich eng mit dem Abschalten eines weiteren Verbrauchers (Gefriertruhe) im gliechen Stromkreis (gleiche Steckdose) aufgetreten, so dass ich auch schon an Überspannungen dachte.

    Ist das reproduzierbar ? Oder nur ein Zufall?!


    Mein Vorschlag: Warte auf den nächsten Fehlerfall und schau dir dann die Logfiles an bzw journalctl . Falls der Zeitraum bekannt ist, ist die Suche einfacher. Sonst mühsam...


    Ok, das soll es erstmal gewesen sein. Es gibt sicher noch einige Frage, aber beantworte die bisherigen schon mal.


    Gruss Bernd


    //EDIT: Wegen auf richtigen Kernel zurück gehen. Der liebe hyle hat da immer so eine schönen Link. Vielleicht ist er ja so nett...

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"

    Vielleicht trifft man sich in der RPi-Plauderecke.

    Edited once, last by Bernd666 ().

  • Hallo Bernd,


    das würde ich auch machen, leider weiß ich gerade nicht, welcher der letzte stable Kernel vor 4.14.27 war. :conf: Aktuell sind wir zwar bei 4.14.50+, aber imho wäre besser erst ein downgrade nach einem stable und danach ein konventionelles update + upgrade.

  • Hallo Bernd666,


    Du hast da was am Auge.

    Aber zur Sache:


    war das schon immer so? Sporadische Ausfälle.

    Ja, das Problem war auch schon am nagelneuen Raspi in Erstkonfiguration, auch noch mit altem Kernel. (sonst hätte es dass Kernelupdate gar nicht erst gegeben).

    Anfangs dachte ich immer, das Problem kommt von den einzelnen Sensoren (z.B. nass gewordener Aquariensensor), so dass diverse Sensoren getauscht wurden und nun seit längerem auch kein Nassfühler mehr dabei ist. Es ist auch egal, ob drei Sensoren mit Kabeln 3-6m oder nur ein einziger Sensor mit ganz kurzem Kabel dran hängt, mit oder ohne Verteilerdose, mit 4k7 oder mit 2k2 Widerstand, mit oder ohne Software-Pullup, alles egal: Die Messung läuft perfekt, bis sie irgendwann aussteigt. Die Intervalle bis zum Ausstieg betrugen mehrere Stunden bis (meistens) mehrere Wochen. Der Log zeigt dann immer "maximum number of 64 sensorsreached" oder so ähnlich, und es wird kein Sensor mehr erkannt. Das ist dann auch unabhängig von der Software, mit der der Bus abgefragt wird (python, pcmanfm, Konsole).

    Quote

    Ist das reproduzierbar ? Oder nur ein Zufall?!

    Es kam bisher immer wieder; ich kann es bislang aber nicht gezielt auslösen. "Zufall" ist für mich ein Sammelbegriff für alle Zusammenhänge, die ich noch nicht verstanden habe, oder für die meine Präzision nicht ausreicht. Insofern ist es bisher Zufall, wann das Problem auftritt.

    ABER ich vermute inzwischen, dass das Problem etwas mit dem Abschalten benachbarter Stromverbraucher zu tun hat, und ich versuche es derzeit gezielt hierdurch auszulösen (z.B. Waschmaschine an der gleichen Steckdose laufen lassen); das läuft noch nicht lange genug um etwas sagen zu können. Zufällig :-) habe ich Logfiles, wann die Gefriertruhe an- und ausschaltet, die an der gleichen Steckdose hängt, und ich habe natürlich die Temperatur-Logfiles und meinen Errorlog der Temperaturmessung; daher sehe ich den engen zeitlichen Zusammenhang bei 3 solchen Ausstiegen.


    Quote

    Mein Vorschlag: Warte auf den nächsten Fehlerfall und schau dir dann die Logfiles an bzw journalctl . Falls der Zeitraum bekannt ist, ist die Suche einfacher. Sonst mühsam...

    Danke für den Tip mit journalctl, das kannte ich nicht! Ja, ich warte auf den nächsten Fehlerfall und versuche ja auch, diesen zu provozieren.

    Der Zeitpunkt (bzw. ein enges Zeitfenster), zu dem der Fehler dann aufgetreten ist, ist anhand Logs und Messungen nachträglich genau zu sehen.

    (Und auch nach vergeblichem Software-Reboot kommen dann Logfile-Einträge, die zeigen, dass der Bus ausgestiegen ist, "maximum number of sensors reached usw.)


    Danke für die Hinweise!!

    Parallel suche ich weiter in englischen Foren, wo ähnliches auch reihenweise berichtet wurde, ohne dass man wohl viel schlauer geworden ist....

    Deshalb versuche ich derzeit parallel die Alternative, einen USB-Bus mit DS9097E zum Laufen zu bekommen; ist aber auch nicht so einfach wie es überall steht....


    P.S.: Die Klicks zum richtigen Zitieren habe ich noch nicht gefunden....

  • Es ist auch egal, ob drei Sensoren mit Kabeln 3-6m oder nur ein einziger Sensor mit ganz kurzem Kabel dran hängt, mit oder ohne Verteilerdose, mit 4k7 oder mit 2k2 Widerstand

    versuchs mal mit 1k bis 820 Ohm pullup, die 4,7k und 2,2k am PI sind viel zu viel.


    Einzelne Fehlmessungen sind aber völlig normal, deswegen CRC & Mehrfachmessungen im Sekundenabstand, nicht weniger!

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr

  • Ich würde auch ein Netzfilter (AKA Entstörfilter) zunächst vor dem Pi Netzteil andenken.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • versuchs mal mit 1k bis 820 Ohm pullup, die 4,7k und 2,2k am PI sind viel zu viel.

    OK, das probieren wir noch. Beurteilung erfolgt dann entweder sofort nach einem weiteren Error (--> hilft nix) oder - falls kein Error - in 6 Monaten (--> hilft wahrscheinlich).

    (Meine Hinterkopftheorie dazu: Vielleicht gibt es beim Abschalten eines benachbarten Verbrauchers ja eine Spannungsspitze und Elektrosmog, der in die 1wire-Leitung einstreut, weil diese nicht genug hochgezogen wird?) - aber seit 12 Monaten bereits viel Theorie und wenig Erfolg :-(

    Einzelne Fehlmessungen sind aber völlig normal, deswegen CRC & Mehrfachmessungen im Sekundenabstand, nicht weniger!

    Einzelne Fehlmessungen habe ich bislang softwareseitig abgefangen, selten und kein Problem.

    Aber damit ich "Mehrfachmessungen im Sekundenabstand" richtig verstehe: Ich frage derzeit mit Python alle 15 Sekunden zuerst die Sensorliste ab, dann die einzelnen Sensoren dieser Liste ohne Delay. Sollte ich ZWISCHEN die einzelnen Sensoren eine Sekunde Wartezeit einfügen?

  • Ich würde auch ein Netzfilter (AKA Entstörfilter) zunächst vor dem Pi Netzteil andenken.


    Servus !

    Ja, ja! Genau in solche Richtung dachte ich auch zuletzt. Ich kann löten, habe aber keine Ahnung von Entstörfiltern und was man da nimmt. Ich hatte schon an eine einfache Induktivität in Reihe zur Netzseite des Rpi-Netzteils gedacht, aber mir fehlt wie gesagt das nötige Wissen, um Henry zu bemühen. Auch an einen großen Elko an 5V des Raspi dachte ich schon, aber der ist dann wohl wieder zu träge, ....

    Ich recherchiere nun mal nach "AKA-Entstörfilter" - edit: gibt's da vielleicht noch einen Tip dazu oder ein Beispiel, was man nehmen könnte? -, und

    danke für den Tip!

  • OK, das probieren wir noch

    das wird dann klappen


    Einzelne Fehlmessungen habe ich bislang softwareseitig abgefangen, selten und kein Problem

    gut so, auch bei mir am AVR mit 5V & 72m Kabel völlig normal

    Ich frage derzeit mit Python alle 15 Sekunden

    gut


    die einzelnen Sensoren dieser Liste ohne Delay. Sollte ich ZWISCHEN die einzelnen Sensoren eine Sekunde Wartezeit einfügen?

    unbedingt, bedenke jede Lesung am Bus zieht die Leitungen runter und da alle Sensoren am selben Bus hängen, deswegen min. 1s zwischen den Lesungen!

    Besonders wichtig bei voller Auflösung & parasitäter Speisung, aber bei miesen Kabeln und langen Leitungen gib den Chips & Kabel Zeit sich umzuladen ->T = R x C

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr

  • das wird dann klappen

    Wie kann man nach 11.347 Beiträgen noch so optimistisch sein?! ;-)

    jede Lesung am Bus zieht die Leitungen runter und da alle Sensoren am selben Bus hängen, deswegen min. 1s zwischen den Lesungen!

    Besonders wichtig bei voller Auflösung & parasitäter Speisung, aber bei miesen Kabeln und langen Leitungen gib den Chips & Kabel Zeit sich umzuladen ->T = R x C

    Das verstehe ich nicht ganz, denn die Leitung muss doch pro Lesung ganz oft hoch und runter, also ganz oft t=RC, was hilft dann eine einzelne lange Pause..... - Aber egal, ich probier das.

    Ich arbeite mit voller Auflösung, aber nicht mit parasitärer, sondern 3.3V-Speisung. Kabel sind wohl übelste elmag. Klasse, aber nicht lang (und das Problem trat auch bei 1 Sensor mit kurzem Kabel auf).

  • Hurra, es ist wieder ein Error aufgetreten!

    Ich habe bisher zunächst NICHTS verändert, um erst mal an die Logs im Fehlerfall zu kommen. Auch läuft die Maschine mit dem wieder ausgestiegenen 1-wire-Bus noch im Fehlermodus weiter, falls ich noch was nachschauen oder probieren muss.

    Ausgestiegen ist die Messung um 08:57:52, wieder kurze Zeit (ca. 1 Sekunde) nachdem die Gefriertruhe ausgeschaltet hat, die an der gleichen Steckdose hängt (auch diese wird geloggt).


    Nun die Logfiles (kern.log, messages, syslog):



    Soweit die Logfiles. Hier gehts weiter im Text.

    Die Ausgabe für "lsmod" ist im Errorzustand unverändert gegenüber vorher.
    "zellberry" ist der Rechnername. Die korrekten Adressen der Sensoren sind: ["28-80000026a373", "28-80000026e752", "28-800000270681"].

    Ich lese das so, dass lauter irrige Sensoradressen gefunden werden, was den maxCount von 64 sofort vollzählt.

    Das Verrückte ist, wie oben schon geschrieben, dass ein "sudo reboot" nur in seltenen Fällen abhilft, ein "sudo shutdown" mit neuem Strom aber meistens.

    1. Was steigt da so nachhaltig aus??

    2. Hat jemand eine Erklärung, was da beim Aussteigen jeweils passiert?

    3. Kann ich jetzt im Errorzustand noch etwas probieren, wie etwa den Bus zu resetten?

    Wenn im jetzigen Zustand alles abgegrast ist, werde ich den Rechner neu starten. Nächste Versuche werden (a) ein Netzfilter, (b) eine Verkleinerung des 4k7 auf 1k2 und (c) Wartezeit 1 Sekunde zwischen den Sensorabfragen sein.

    Hierzu gleich noch Frage 4 an die Community, ist aber nicht die Hauptsache: Kann ich mich trauen, die Sensoren mit 5V zu versorgen, und das Datapin dann mit 1k2 an 3,3V zu hängen? Das habe ich mich bisher nicht getraut, weil ich nicht weiß, ob der Sensor u.U. die 5V an das Datapin rausgibt.


    Danke fürs Lesen und Mitdenken!

    Edited 8 times, last by 1wire ().

  • Hallo,

    bitte kopiere die Log-Files nicht direkt in den Post, es gibt 2 bessere Möglichkeiten:

    • verwende das Code-Tags Symbol </> im schwarzen Balken über der Eingabe, oder
    • lade die Log-Datei als Datei-Anhang hoch.

    Sonst müssen alle ewig blättern um zu nächsten Beitrag zu gelangen.

    Schönen Gruß, kle

  • bitte kopiere die Log-Files nicht direkt in den Post,

    Sorry! - Ich habe inzwischen nachgebessert....

    Bei messages und syslog geht es übrigens mit dem dritten Eintrag los (nur um zu dokumentieren, dass keine kritischen Einträge vorausgingen).

    ... auch den nachfolgenden Beitrag noch eingearbeitet ...

    Edited once, last by 1wire ().

  • prima, noch eine Info: beim Eingeben in Code-Tags </> kannst Du auch den Dateinamen eintragen: Klicke auf Code

    Schönen Gruß, kle

  • Hallo, zwei Monate später.


    Die Sache findet sich auch im englischsprachigen Raspi-Forum (https://www.raspberrypi.org/fo…164059&p=1400261#p1400261). Eine richtige Erklärung, was genau schiefläuft, findet sich dort auch nicht, aber man sieht, dass das Problem nicht so selten ist, und vor allem findet sich dort ein sehr guter Workaround (!).


    Kurz berichtet, was ich inzwischen gemacht habe:

    - Delay von 0,25s zwischen zwei aufeinanderfolgenden Sensorabfragen

    - Verringerung des 4k7 auf 3k3

    - Einstöpseln des Raspi-Netztteils (original natürlich) in eine eigene Steckdose, nicht in eine Steckerleiste.

    (- Einen Netz-Entstörfilter mit 2x10mH habe ich vorbereitet, aber bislang gar nicht eingesetzt).


    Damit reduzierte sich vermutlich das Fehleraufkommen bereits. Auf jedem meiner 2 eingesetzten Raspberrys ist innerhalb von 6-8 Wochen jeweils 1 Fehler aufgetreten.

    (Hardware: Raspi 3B, Raspi zero w, jeweils mit bisher 3 Sensoren).


    Das wichtigste: Der Workaround, der im englischsprachigen Forum beschrieben ist, wird automatisch bei Bedarf gestartet und hat bislang 2 von 2 Mal super geholfen. Kurz: Die Plusleitung der Sensoren wird nicht an +3,3 Volt gehängt, sondern an einen freien GPIO, der als Output konfiguriert ist und im Fehlerfall die Speisung für eine Weile unterbricht.

  • - Delay von 0,25s zwischen zwei aufeinanderfolgenden Sensorabfragen

    relativ kurz, ich mache dazwischen 1s Pause weil ich parasitär speise und deswegen ist ein power abschalten leicht, einfach den Port auf low lassen.

    - Verringerung des 4k7 auf 3k3

    um längere Leitungen zu treiben und auch Störungen weniger durch zu lassen empfiehlt sich am PI bei Bedarf bis runter auf 820Ohm (wenn 1k nicht reicht)


    Selbstverständlich ist CRC check und verwerfen von Unsinn Pflicht zwischen 2 Raumtemperaturmessungen kann die Temperatur nur um >10°C springen wenns brennt!

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr