Erkennung 1-wire-Sensoren DS18B20

  • Hallo,

    ich habe an einem Raspi 7 solcher Sensoren über einen Busmaster angeschlossen. Obwohl das System "normalerweise" korrekt arbeitet, fallen die immer mal wieder alle aus. Dies ist erkennbar, da unter /sys/bus/w1/devices die Verzeichnisse mit den Sensoradressen fehlen. Bisher kann ich den Fehler nur beheben, indem ich alle Sensoren abeziehe und sie nach und nach wieder anstecke, wobei jeweils zwischendurch Zeit zum Erkennen gegeben werden muss.

    Gibt es irgendeine Linuxanweisung (nicht Reboot), mit der ich die Erkennung manuell anstoßen kann???

    Ich kenne die grundsätzlichen Probleme wie Leitungslängen, Kabeltopographie, Busmasteranzahl, Sensorqualitäten, zusätzliche Spannungsversorgung.

    Gruss, wonk :danke_ATDE:

  • Die Anweisung zur Neuerkennung hat das OWFS an den Sensor schon x-mal geschickt und keine gültige Antwort erhalten. Daraufhin hat das OWFS den Sensor aus dem FS rausgenommen und wird zur Laufzeit des OWFS nicht mehr verwendet/abgefragt. Das tritt meistens erst nach längerem Betrieb auf.

    Ursachen, wie immer: Von Leitungsqualität, -Länge, -Topologie, (Gesamt-)Abschlusswiderstand, Leitungsreflexionen. -Kapazitäten, ... ist alles möglich.

    Es gibt keinen Linux-Befehl zur Reanimation eines einzelnen Sensors. Du kannst höchstens das OWFS neu starten, oder versuchen, durch Unterbrechung der Sensorstromversorgung eine Neuinitialisierung der Sensoren allenfalls zu erzwingen.

    Allenfalls wäre auch das w1-gpio-pullup dtoverlay eine Option, bei dem erst über einen eigenen Pin der Pullup Widerstand zur Sensorabfrage aktiviert wird. Das ist aber in diesem Forum unbekannt und Du könntest Vorreiter für diese Schaltungsart sein.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Moinsen,

    Da diese Sensoren für ihr fast regelmäßiges Ausfallverhalten bekannt sind, besonders wenn mehrere Sensoren mit unterschiedlichen Leitungslängen angeschlossen sind, kann man auch dem Bequemen des Nullwiderstandes gehen.
    Leider machst du keine Angaben, in welchem Zeitrahmen diese Abfragen erfolgen.

    Dazu muss man folgende Dinge beachten. Zu einem benötigt der DS18B20 maximal 750 ms um auf eine Abfrage zu reagieren um intern die Daten aufzubereiten. In der Folge sollte auch die Abfragerate nicht geringer sein.

    Ausgehend davon was die einzige Lösung ist dieser Dinger wieder an den Start zu bringen, und von @RTFM schon so gesagt wurde kann man zwei grundsätzliche Lösungsansätze verfolgen:

    Die Vc Schaltet man über einen GPIO Pin. Dabei ist zu beachten, dass dieser Sensor Minimum im aktiven Betrieb 2 mA benötigt. Das mal die Anzahl der Sensoren, plus den Verluststrom über den Pullup, wäre ein einzelner GPIO in der direkten Schaltung damit überfordert. Also es wird ein Schaltverstärker zB ein Transistor benötigt.
    Darauf basierend und abhängig von der Abfragerate kann man nun:
    - Erstens: 1,5 Sekunden vor der Abfrage diese Sensoren unter Strom setzen, und dann die Abfrage starten. Das hat wiederum den Nachteil, dass bei höheren oder niedrigeren Temperaturen am / im Grenzbereich Wertabweichungen auftreten. Und dann schaltet man diese Sensoren gesammelt wieder ab. Diese Methode kann erfolgreich sein, wenn die Abfragerate eher gering / langsam ist, und nur aller 10 Sekunden oder länger eine solche Abfrage eingefordert wird. Allerdings kann man damit auch einige mA Strom sparen, wenn es sich um eine Batterie / Akku basierte Endanwendung handelt.

    - Zweitens: man lässt es drauf ankommen und lässt eine Übertragunsgfehler zu, muss diesen allerdings abfangen, um diesen Fehler mit besagter Methode "Unterbrechung der Stromversorgung" der Sensoren begegnen zu können.

    Aber ich denke mich zu erinnern, dass wohl Dennis89 schon mal ein solches Python Programm hier vorgestellt hatte, welches anhand der Adresse eine Wertzuordnung macht, und dann auch klar ermittelt werden kann welcher Sensor ausgefallen ist.

    Franky

  • Hallo,

    Vielend Dank für die vielen interessanten Erläuterungen. Mir als Elektronik.dummy sagt das: Die Sensoren sind sehr schön einfach anzusprechen - wenn es funktioniert. Wenn es mehr Sesnoren werden und die Topographie komplexer, wird es richtig aufwendig!

    Ob die Verwendung von Original-Maxim-Sensoren etwas bringt, ist auch noch nicht gesichert.

    Andere vergleichbar einfach zu verwendende günstige Sensoren gibt es wohl nicht, oder doch?

    Gruss, wonk :danke_ATDE:

  • Moinsen,

    Ab betriebssichersten sind die alten noch Dallas COP Gelabelten Sensoren. Mann bekommt sie noch, aber wirklich inzwischen sehr selten, weil dieser Produzent schon vor Jahren die Produktion eingestellt hat.

    Aus persönlichen Erfahrungen kann ich sagen, wenn die Leitungen zu den einzelnen Sensoren eine im dm ( Dezimeter ) Bereich abweichende Leitungslänge haben, dann gehen mit fast alle Sesnoren die Probleme los, besonders wenn es sich um einfache "Klingeldrähte" handelt. Am besten man verwendet alte 4 Polige Telefonstrippen, die auch geschirmt sind, und macht sich in der Nähe des Controllers einen Sammelpunkt, wo alle Leitungen noch vor dem Pullup, zusammenlaufen.

    Franky

  • Moinsen,

    es macht keinerlei Sinn, den im OneWire antworten alles Slave nacheinander. Nur wie dann die Auswertung erfolgt ist die Sache der SW oder des Scriptes.

    Dann nimm einen OPV als Booster, für die VC. Also alles Vc Anschlüsse laufen am Ausgang des OPV zusammen. Und wenn du messen willst, dann bestimme einen GPIO ( wenn noch frei ) der ein High Signal zum OPV sendert, der daraufhin seinen Ausgang auf HIGH zieht, also die Vc zur Verfügung stellt. Und dann nach 30 sek oder 1 min kannst du dann die eigentliche Sensorabfrage starten. Weiter 30 sek später trennst du wieder die Vc in dem du den GPIO wieder auf LOW schaltest.

    Franky

  • Hallo,

    Leider kann ich das so nicht beeinflussen. Ich verwende zur Abfrage vzlogger (wiki.volkszaehler.org), die die Daten in eine Datenbank schreibt und darstellt. Wie genau vzlogger abfragt, weiß ich nicht. Ich kann durch die Konfiguration nur beeinflussen, in welchen Zeiträumen abgefragt wird. Es sei denn alles selbst programmieren - bin ich zu dumm zu. Aber Vielen Dank für Deine Hinweise.

    Gruss, wonk :danke_ATDE:

  • Moinsen,

    klar kannst du das !
    Man muss dazu nicht einmal in diese Komische SW eingreifen.
    Du machst dir einen kleinen Python Script fertig. Irgendwas mit GPIOZERO und DigitalOutputDevice. Diesen schaltest du dann auf ON, und nach einer Zeit X , hier kann man time.sleep() verwenden das ganze wieder Off. Dann schreibst du dir entweder einen Stratscript für die Shell, oder versuchst direkten Aufruf. Dann schreibst du dieses Script in die CronTab, damit dieser kleine Python Script aller 15 min oder was auch immer gestartet wird. Jetzt habe ich keine Ahnung wie dieser VOLKSZÄHLER Mist startet aber diesen kannst du mit einer Verzögerung von 1 min nach dem Systemstart auch starten. Damit ist der Schaltende Python Script dem Intervall in dieser SW immer eine Minute voraus Also:

    Python
    from gpiozero import DigitalOutputDevice
    from time import sleep
    
    switsching_pin = 21 # kann nach belieben und frei gewählt werden 
    opv_switch = DigitalOutputDevice(switsching_pin) 
    opv_switch.on()
    sleep(120) # 2*60sek = 2 Min
    opv_switch.off()
    opv.switch.close() 

    Wenn du also diesen Script aller 15 min ausführen lässt ( CronTab ) und diese VOLKS-SW mit einer Verzögerung von 1 min zum Systemstarten lässt, dann ist dieser Stricpt immer 1 min voraus, und die Termo Sensoren bekommen immer ausreichend Zeit sich zu aktivieren, bevor diese SW einen Leseversuch macht. Und nach 2 min wird der Ausgang wieder abgeschaltet und freigegeben.

    Franky

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!