Watchdog-Problem für den Raspberry

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,
    hoffe ich bin hier richtig. Ich versuche die letzten Tagen einen watchdog für den PI zu konfigurieren. Für diesen Zweck bin ich der folgenden Anleitung gefolgt: http://www.gieseke-buch.de/raspberrypi/ei…rwachung-nutzen
    Da ich ein bestimmtes Programm überwachen möchte, habe ich die nachfolgenden zwei Zeilen in meine watchdog.conf-Datei eingefügt:

    Code
    file           = /home/name/file_for_watchdog
    change         = 300

    So soll der eingebaute Watchdog alle 5 Minuten die Datei "file_for_watchdog" auf ein mögliches Schreiben überpüfen. Dies funktioniert auch ganz gut. Nur, sobald mein Programm abstürzt, gerät der PI in einer Reboot-Endlosschleife. Mein Programm starte ich mit Hilfe von rc.local. Ich habe die Vermutung, dass der Watchdog vor meinem Programm startet und zudem beim Neustart keine 5 Minuten wartet. Somit wird gleich ein Neustart erzwungen.
    Was mache ich falsch..?

    Es folgt meine komplette watchdog.conf-Datei:

    Code
    file           = /home/name/file_for_watchdog
    change         = 300
    max-load-1      = 24
    
    
    watchdog-device = /dev/watchdog
    realtime        = yes
    priority        = 1

  • ... die Datei "file_for_watchdog" auf ein mögliches Schreiben überpüfen.

    Alternativ könntest Du diese Datei auch mit iwatch oder mit inotify überwachen. Ist m. E. einfacher zu konfigurieren, als mit dem watchdog und die Überprüfung erfolgt laufend/ständig (d. h. es kann sofort reagiert werden).

    Code
    ~ $ apt-cache show iwatch | grep -iE 'descript|homepage'
    Description: realtime filesystem monitoring program using inotify
    Homepage: http://iwatch.sourceforge.net/
    Description-md5: a0413a7310bf0706deb3b62cdb932928

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo BFK,

    herzlich Willkommen in unserem Forum!

    Mal abgesehen davon, das ich kein Freund von [font="Courier New"]watchdog[/font] bin (der unbedarfte Anwender kann sich dadurch sein System bis zur Unbenutzbarkeit zurecht stutzen), der von Dir verwendete Parameter [font="Courier New"]max-load-1[/font] bedeutet, dass ein Reset / Reboot ausgelöst wird, sobald die Prozessor-Auslastung der letzten Minute einen bestimmten Wert überschritten hat.

    Ich weiß nicht, wie Du Du Deinen Raspberry Pi einsetzt. Meiner jedenfalls compiliert z.B. selbstgeschriebene Programme (kurzfristig 100% Prozessorauslastung). Die selbstgeschriebenen Anwendungen nutzen während der Testphase auch mal ganz gern 100% der Prozessorauslastung.

    Somit würde bei mir der Raspberry Pi laufend rebooten - und damit ein Einsatz ad absurdum geführt werden.

    Ersetze [font="Courier New"]max-load-1[/font] durch [font="Courier New"]max-load-5[/font] oder [font="Courier New"]max-load-15[/font]. Und berichte dann, ob eine Besserung eingetreten ist.

    Übrigens:


    Nur, sobald mein Programm abstürzt, gerät der PI in einer Reboot-Endlosschleife.

    Ein Watchdog macht nur Sinn, wenn Dein Programm nicht abstürzt. Ein Absturz ist meistens mit 100% Prozessorauslastung verbunden. Hier wäre es sinnvoller, wenn Dein Programm über das Linux-Kommando [font="Courier New"]kill[/font] entfernt wird.

    Also bräuchtest Du einen Watchdog zum Watchdog... Verstehst Du jetzt meine Abneigung gegenüber watchdog? Was passiert, wenn Dein watchdog zum watchdog nicht funktioniert / abstürzt etc.

    Investiere lieber Zeit und Grips in Dein Programm, um es absturzsicher zu machen. Ein Programm darf ruhig mal abstürzen (während der Entwicklung passiert das schon mal). Aber ein abgestürztes Programm sollte kein Grund sein, ein laufendes System mit in den Abgrund zu ziehen.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    2 Mal editiert, zuletzt von Andreas (14. Oktober 2017 um 14:28)

  • Zitat

    Ein Programm darf ruhig mal abstürzen (während der Entwicklung passiert das schon mal). Aber ein abgestürztes Porgramm sollte kein Grund sein, ein laufendes System mit in den Abgrund zu ziehen.


    Es kommt hda wohl auf den Einsatz an. Wenn ein RPi nur eine Aufgabe hat - ein Prg. zu laufen zu lassen, kann es durchaus Sinn machen den "Rechner" neu zu starten....

    Ich bin aktuell dabei einen Wecker zu Programmieren. Ich "füttere" die Watchdog Datei direkt vom Programm aus ohne wachtdog daemon. Hier mein Code - ggf kannst Du ihn anpassen:

    Einmal editiert, zuletzt von WernerPI (11. September 2015 um 08:50)

  • Hallo Leute und danke euch erstmals für eure Antworten.

    Alternativ könntest Du diese Datei auch mit iwatch oder mit inotify überwachen. Ist m. E. einfacher zu konfigurieren, als mit dem watchdog und die Überprüfung erfolgt laufend/ständig (d. h. es kann sofort reagiert werden).

    Das würde aber bedeuten, dass ich nicht den eingebauten Hardware-Watchdog verwende, sondern dass sich ein anderes Programm darum kümmert. Oder verstehe ich hier was falsch..?

    Ersetze [font="Courier New"]max-load-1[/font] durch [font="Courier New"]max-load-5[/font] oder [font="Courier New"]max-load-15[/font]. Und berichte dann, ob eine Besserung eingetreten ist.

    Habe ich versucht...habe "max-load-1" gleich auskommentiert...der PI hängt trotzdem in der Reboot-Endlosschleife. Dies ist auch logisch, wenn man bedenkt, dass nicht die Prozessorauslastung, sondern das nicht schreiben der Datei die Ursache für das Neustarten ist.

    Ein Watchdog macht nur Sinn, wenn Dein Programm nicht abstürzt.

    Verstehe ich nicht. Der Watchdog soll ja genau dann reagieren, wenn das zu überwachende Programm abstürzt. Wenn mein Programm niemals abstürzt, dann brauche ich ja auch keinen Watchdog..!


    Investiere lieber Zeit und Grips in Dein Programm, um es absturzsicher zu machen. Ein Programm darf ruhig mal abstürzen (während der Entwicklung passiert das schon mal). Aber ein abgestürztes Porgramm sollte kein Grund sein, ein laufendes System mit in den Abgrund zu ziehen.

    Ja da hast du Recht, aber der Watchdog soll ja nur für den Fall der Fälle eingreifen können. Und, wie schon WernerPI schrieb, bin ich auch der Meinung, dass ein Watchdog in gewissen Situationen schon Sinn macht. In meinem Fall ist mein Programm das einzige, was funktionieren soll.


    Ich bin aktuell dabei einen Wecker zu Programmieren. Ich "füttere" die Watchdog Datei direkt vom Programm aus ohne wachtdog daemon. Hier mein Code - ggf kannst Du ihn anpassen:

    Werde ich mir angucken, habe aber gehofft, dass ich den Watchdog-daemon verwenden könnte..!

    Ich glaube, wenn ich es hinbekomme den watchdog-damon, nach meinem Programm beim Rebooten zu starten, wird dies schon klappen. Ich frage mich nur, wie ich dies anstellen soll..?

  • Hallo zusammen,

    wesentlich ist, daß man den watchdog entsprechend konfiguriert. Es gibt in '/etc/watchdog.conf' den Parameter

    Code
    repair-binary =   <your_scriptname>

    Man erstellt sich ein passendes Script und bearbeitet entsprechend den "Fehler" - abschliessend ist der RETURN-Code innerhalb des Scripts massgebend! "return 0" in einem Bashscript wird keinen Neustart des gesamten Systems auslösen, alles läuft normal weiter, als wenn nichts geschehen wäre.
    Man entscheidet also durchaus selbst, wie weiter verfahren werden soll!

    Steht auch im Manual - deshalb wundern mich immer wieder die eigentlich falschen Kommentare zum Thema "watchdog". :s

    Gruß, mmi

  • RETURN-Code innerhalb des Scripts massgebend! "return 0" in einem Bashscript

    Nicht 'return 0' sondern 'exit 0' :fies:


    Ganz besonders wichtig für den TE (und alle anderen) ist, das der bcm-watchdog nicht dafür geeignet ist andere Programme zu überwachen oder sonst was, da der bcm-watchdog den PI neu startet! Der bcm-watchdog soll eigentlich nur die Software als solches überwachen, also das Betriebssystem.

    Linux ist kein Windows! Linux muss man nicht für jeden Mist neu starten! Vor allem aber nicht wegen eines einzelnen Programms was gecrasht ist! Kopf meets Tisch!

    Es macht absolut gar kein Sinn das der PI neu gestartet wird wenn...

    • Die CPU Auslastung steigt.

      vor allem nicht innerhalb der letzten paar Minuten (max-load-1 , max-load-5)
      Wieso darf der PI nichts zu tun haben? Ist es schlecht wenn der PI, der ja eigentlich eh nicht mit CPU-Power protzen kann, mal etwas zu tun hat? :s
      Es ist überhaupt nicht schlimm wenn der CPU mit 100% ausgelastet wird, auch nicht über einen längeren Zeitraum! Das ist kein Anzeichen dafür dass etwas gecrasht ist!


    Ein einzelnes Programm abstürzt/crasht. Nicht innerhalb gewisser Zeit in eine Datei geschrieben wird.

    dies belastet zudem die SD unnötig


    ...oder irgend etwas anderes was vom eigentlich Grund des bcm-watchdogs abweicht

    Überlegt euch mal für was der bcm-watchdog eigentlich entwickelt wurde und ursprünglich vorgesehen ist bzw was seine Hauptaufgabe ist. Dann kommt ihr eigentlich auch dahinter was an diesem bcm-watchdog anders ist als an anderen üblichen Watchdogs ... ich schreibe hier die ganze Zeit bewusst 'bcm-watchdog'

    Der 'bcm-watchdog' funktioniert so dass auf der Softwareseite (Betriebssystem) regelmäßig in eine sog. FIFO Datei geschrieben wird -> /dev/watchdog
    Der BroadCoM SoC wiederum erwartet alle 60 Sekunden das in diese FIFO Datei geschrieben wird - falls nicht nimmt der SoC an das sich das Betriebssystem aufgehängt hat, und startet daraufhin den PI neu (Hard Reset, als würde RUN bzw P6 betätigt werden).

    Siehe dazu auch:
    Watchdog
    Raspberry Pi rebootet ohne ersichtlichen Grund

    Wenn Du/Ihr aber eigentlich nur ein Programm überwachen wollt um dieses eine Programm neu zu starten falls es mal crasht - dann braucht ihr zwar auch einen sog. Watchdog aber nicht diesen speziellen bcm-watchdog!

    Wenn man ein Script nutzt, welches ebenfalls permanent im Hintergrund läuft, um ein anderes Programm zu überwachen - gibt es kaum eine Garantie das dieses Script nicht auch mal crasht..
    Das einzig Sinnvolle als Watchdog ist ein Script / Programm zu haben welches regelmäßig über Crontab ausgeführt wird. CRON stürzt eigentlich nie ab, zumindest ist mir das in den letzten 20 Jahren noch nie passiert :D

    Es reicht ein ganz simples bash Script, was auch überhaupt nicht schwer zu konfigurieren ist. Klar gibt es auch hier Versionen die komplexer sind, ist ja schließlich bash und da gibts keine Grenzen was man sonst noch so für Features in das Script einbauen kann...

    Die einfachste Ausführung sieht wie folgt aus:


    Mehr zur crontab kannst du hier nachlesen: https://www.forum-raspberrypi.de/Thread-tutorial-crontab-cron-jobs

    Was das Script macht ist, die Prozess-Liste (ps) nach dem Namen des Prozesses zu durchsuchen und nur wenn der dort nicht gefunden werden kann wird der Prozess bzw Programm/Script/whatever gestartet...

    Wichtig ist das der Crontabeintrag bei dem Benutzer erfolgt der auch berechtigt ist das Script/Programm auszuführen bzw der es ausführen soll... Wenn es also zB ein Programm ist was root Rechte benötigt dann muss der Crontabeintrag auch beim root Benutzer erfolgen und du musst "sudo crontab -e" verwenden - das steht aber auch in dem crontab Tutorial..

    Was auch zu beachten wäre ist das LOGFILE. Wenn das Programm/Script sehr oft crasht dann wird die Logdatei sehr schnell anwachsen, was letztlich früher oder später dazu führen kann das die SD voll ist. Dafür gäbe es auch noch eine Lösung, die ich jetzt aber nicht in die Simple-Version mit einbauen wollte :fies:

    Ebenfalls sollte bedacht werden ist dass es kein Sinn macht ein ständig crashendes Script/Programm mithilfe Dieses Watchdogs ständig neu zu starten - daann scheint ein allgemeines Problem vorzuliegen welches man besser lösen sollte anstatt es mithilfe des Watchdogs zu ignorieren.

  • Hallo meigrafd und danke dir mehrmals für deine ausführliche Erklärung.

    Die Idee mit dem cronjob hatte ich vorerst auch, wollte diese aber nicht umsetzen, denn ich war mir nicht sicher wie stabil crontab laufen würde. Werde dies aber erstmals so versuchen.
    Mein Programm läuft bis jetzt stabil, hatte zumindestens seit dem Betrieb keine Ausfälle, wollte tzrotzdem etwas für den Fall der Fälle einbauen.

    Die Frage, die ich mit jetzt noch stelle: Was passiert wenn sich das System und nicht das Programm abstürzt...? Sollte in diesem Fall der eingebaute bcm-watchdog aktiviert sein..? ... und wenn ja welche Einstellung würdest du denn empfehlen, da du von max-load abrätst..? (Klar hängt es vom jeweiligen Anwendungsfall ab, aber ich rede hierbei von Programmen, die sehr leightweight sind, wie z.B. Automatisierungs- oder Timer-Anwendungen).

    Zu meiner letzten Frage:
    Wie sieht es mit Server-Anwendungen aus..? Wie kontrolle ich z.B. ob eine apache-Server wirklich läuft..? Würdest du in diesem Fall die gleiche Methode empfehlen oder gibt es in diesem Fall etwas standardmässiges..?

  • Für den Fall das sich das komplette Betriebssystem aufhängt - also wirklich - macht der bcm-watchdog natürlich Sinn. Ist mir aber noch nie passiert ;)

    Die 'max-load' Einstellungen machen gänzlich überhaupt gar kein Sinn, egal was dein PI zu tun hat oder sonst was.
    Führt euch vor Augen das der PI nicht mals 1 GHZ hat und es daher durch aus mal vorkommen kann das er mal mehr als 90% Last hat - insbesondere bei Personen die ihn als MediaCenter verwenden. Es ist wirklich absolut nicht schlimm wenn der CPU über einen längeren Zeitraum 100% Last hast, dann wird er halt ein kleines bisschen wärmer aber na und? Selbst das verkraftet der SoC absolut problemlos, auch hier kein Grund Panik zu kriegen wenn der SoC 80°C warm wird - er taktet sich zudem beim erreichen von 85°C automatisch runter und kritisch wird es erst ab 90°C also kurz bevor Wasser Kocht.

    Für eigen erstellte Programme / Scripts macht es ggf Sinn ein Watchdog-Script zu verwenden, aber für apache eher weniger. Über apt-get installierte Programme gelten als stabil und crashen nicht einfach so. Man muss also nicht für sowas wie apache2 extra einen Watchdog einrichten. Das wär etwas zu viel des Guten ;)

    Ob ein Dienst "läuft" kannst du am besten über den Befehl service abrufen, wie zum Beispiel:

    Code
    sudo service apache2 status

    Alternativ direkt das Script aufrufen:

    Code
    sudo /etc/init.d/apache2 status
    &quot;/etc/watchdog.conf&quot;


    Alles bis auf folgendes auskommentieren:

  • Jetzt habe ich an die Extperten diesbezüglich auch mal eine Frage:

    Die meisten scheinen den Watchdog ja abzulehnen weil man es auch anders lösen kann. Bei mir läuft Pi als recht komplexe Heizungsteuerung mit 16 Temperaturfühlern schon über ein Jahr sehr stabil und ich bin gegeistert :thumbs1: , jedoch kam es schon zwei Male vor dass sich die komplette Temperaturerfassung aufgehängt hat wobei dann alle einfach 0 Grad anzeigen (bzw. der Messwert als invalid eingestuft wurde, bei wassergeführten Kaminöfen die überhitzen können und dann notgekühlt werden müssen ist das sehr unangenehm). Gibt es da auch eine andere Möglichkeit als den Neustart des ganzen Systems wofür sich der Watchdog natürlich anböte?!

  • Hallo ElSol666,

    normalerweise solltest Du der Ursache auf den Grund gehen, weshalb sich die Temperaturerfassung aufgehängt hat.

    Zum Beispiel kann es sein, dass die Temperatur in zu kurzen Intervallen abgefragt wird - kannst nur Du beurteilen

    Zum Beispiel kann die Elektronik eine Ausnahmesituation erlebt haben (zu feucht, zu kalt, zu warm).

    Vielleicht kamen sich zwei Anwendungen in die Quere...

    Normalerweise bietet sich das Studium der Log-Dateien an. Diese sollten Hinweise auf das System geben, bevor es zu den Fehlmessungen kam.

    Dann bietet es es sich an, ein redundantes System sich selbst prüfender Sensoren einzurichten. Diese geben Dir Hinweise, wenn vereinzelte Sensoren einfach so aussteigen.

    Und erst, wenn nichts anderes funktioniert, dann mag ein Reboot sinnvoll sein...


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • IMHO ist selbst dann kein Reboot sinnvoll.. Ein Reboot ist insbesondere unter Linux eigentlich nie Sinnvoll - nur um einen neuen Kernel einzubinden, aber das ist dann eigentlich auch schon die einzige Ausnahme.

    Es sollte notgedrungen reichen das Kernel-Module zu entladen und neu zu laden. Oder eine Schaltvorrichtung einzurichten sofern es mit den Sensoren zu tun hat (was für welche kommen überhaupt zum Einsetz und wie sieht der Code aus?)

  • Hallo.


    Die meisten scheinen den Watchdog ja abzulehnen weil man es auch anders lösen kann. Bei mir läuft Pi als recht komplexe Heizungsteuerung mit 16 Temperaturfühlern schon über ein Jahr sehr stabil und ich bin gegeistert :thumbs1: , jedoch kam es schon zwei Male vor dass sich die komplette Temperaturerfassung aufgehängt hat wobei dann alle einfach 0 Grad anzeigen (bzw. der Messwert als invalid eingestuft wurde, bei wassergeführten Kaminöfen die überhitzen können und dann notgekühlt werden müssen ist das sehr unangenehm). Gibt es da auch eine andere Möglichkeit als den Neustart des ganzen Systems wofür sich der Watchdog natürlich anböte?!


    Hatte mit meiner Solar/Hezungssteuerung ein ähnliches Problem.
    Im Sommer, wenn der Pufferspeicher genügend voll ist, schalte ich per PDI Regelung Zellen um, und lasse sie Strom produzieren.
    Das Problem war, was ist, wenn Sensoren ausfallen, hängen oder der RPI gegen die Wand fährt.
    Meine Lösung war ein externes Zeitrelais, das vom raspi zyklisch angestoßen werden muss, ansonsten fällt die gesamte Steuerspannung weg, und die Heizung fällt in einen gefahrlosen Grundzustand.
    Das gleiche mit den Temp-sensoren.Wenn die länger mucken, Log-Einträge schreiben, entsprechend reagieren oder notfalls Relaistriggerung abschalten.
    Problem war am Anfang auch die ungeschirmte Sensorleitung und der Rv.
    Die Anlage läuft seit ~1,5 Jahren im 24/ Modus und bin voll zufrieden.
    Evtl als Denkanstoss.
    Hier die Schaltung.

    gruß root

    Einmal editiert, zuletzt von root (25. November 2015 um 19:09)

  • Zitat

    ...jedoch kam es schon zwei Male vor dass sich die komplette Temperaturerfassung aufgehängt hat wobei dann alle einfach 0 Grad anzeigen...


    Das könnte man durch ein Programm, das mehrere Messwerte, die eigentlich (von der Logik her) nie gleich sein könnten, überwachen.
    Und wenn das vorkommt, z.B. das Programm der Temperaturerfassung neu starten.

    Das wäre auch eine Art Watchdog, der aber eben nur dieses Programm überwacht und es neu startet.

    -----------------
    Ich hatte mal eine Wetterstation im Einsatz, die per Serieller Schnittstelle angebunden war. Da ich diese aber nicht frei hatte (und das Gerät zu weit weg war), wurde die per Netz mit dem c't-Projekt "com2LAN" und 'socat' realisiert.
    Wenn nun die Verbindung weg war, habe ich über ein Job erst die Erfassungssoftware gestoppt, die Schnittstelle neu gestartet und die Überwachungssoftware neu gestartet.
    Das konnte man leicht testen, da dann einfach der Prozess für die serielle Schnittstellenemulation weg war.

    Computer ..... grrrrrr

    Einmal editiert, zuletzt von Rasp-Berlin (25. November 2015 um 19:24)

  • Das sind ja einige gute Ansätze, dachte gar nicht dass dies doch soviel Resonanz erfährt!

    Es handelt sich um 1-wire Temperaturfühler (DS1820 von TI) die mit simpler Schaltung direkt am IO von Pi hängen. Das Konzept ist genial denn zum Einen sind sie sehr preisgünstig im Vergleich zu PT100 oder PT1000 Fühlern, zum Anderen braucht man keine aufwändige Schaltung und spart so sehr viel Strom ... und man spart auch viele Leitungen durch das Bus-System. Allerdings ist es bei so vielen Fühlern, die noch dazu zig-Meter auseinander liegen (Solarthermie auf dem Dach, Pi im Heizungskeller, zwei Kaminöfen in den Wohnungen), nicht so einfach die richtigen PullUp-Widerstände zu finden, und trotz abgeschirmter Kabel ist bei solch einem weit verzweigtem Bus-System auch immer mal eine Störung von außen möglich ... hier alles eliminieren zu wollen stünde in keinem Verhältnis zum Aufwand, vor allem da ja wie gesagt in einem ganzen Jahr das Problem erst zweimal auftrat. Auch der Aufwand für Redundanz, sprich einen zweiten Pi (denn es gibt ja nur eine 1-wire Schnittstelle) + Kabel + Fühler, ist deutlich zu groß!

    Die Abfrage der Sensoren erfolgt übrigens nicht sehr häufig, im Moment mache ich es alle 15 Sekunden und das sollte das System ja nicht wirklich umhauen!!! ;)

    Aber vielleicht könnte man ja tatsächlich auch einfach den Prozess der für die 1-wire Schnittstelle verantwortlich ist, neu starten. Problem hierbei ist natürlich auch dass man den Zustand zum Testen nicht so einfach herbeiführen kann, so selten wie er auftritt ... da ist man mit einem Neustart des ganzen Systems natürlich auf der sichereren Seite.

  • Hallo ElSol666,


    ein paar Hinweise:

    Du brauchst nur einen einzigen Widerstand nicht mehrere, um mehrere DS18B20 anzusteuern.

    Wenn Du alle Kabel zu den Sensoren gleich lang hast, dann ist auch der Leitungswiderstand ungefähr gleich groß und Du hast kein Wechselspiel zwischen kurzen und langen Leitungen.

    Wenn Du statt eines Festwiderstandes ein Poti (10k) einbaust, dann kannst Du ganz leicht den optimalen Widerstand einstellen, bei dem alle Sensoren ansprechen.

    Für die Redundanz brauchst Du keinen zweiten RPi, sondern lediglich z.B. 2 DS18B20 an jeder Messstelle. Zeigen beide Sensoren ungefähr die gleiche Temperatur an, dann ist der Mittelwert ein verlässlicher Messwert. Weichen die Temperaturen voneinander ab, dann ist dies als Hinweis einer Störung zu deuten.

    Die Abfrage im Abstand von 15 Sekunden halte ich für viel zu kurz. Ich würde die Messung im Minuten- bis 5-Minutenabstand durchführen. So schnell ändern sich Temperaturen nicht und so schnell muss auch keine Steuerung reagieren und Änderungen hervorrufen.

    Der 1Wire-Bus bzw. die angeschlossenen Sensoren bereiten eigentlich nur dann Probleme, wenn mit der Spannungsversorgung (des RPi oder der Sensoren) etwas nicht stimmt. Und da ist eine Lösung mit dem o.a. Poti recht angenehm.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (26. November 2015 um 23:43)

  • Hallo Andreas,

    ich habe ganz bewusst mehrere Widerstände denn das Ganze ist modular aufgebaut: Je mehr Fühler umso geringer muss ja auch der Widerstand sein, und durch die parallelen Widerstände kann man auch einfach mal ein Segment abziehen (z.B. einen Ofen) ohne dass die ganze Messung zusammenbricht.

    Kabel zu den Sensoren gleich lang ist unmöglich da z.B. bis zur Solarthermie auf dem Dach locker mal 15m drauf gehen, zu einem der Kaminöfen sind es gar 20m. Der Pufferspeicher, Brenner und Warmwasserspeicher stehen im Keller natürlich nah an der Steuerung ... wenn ich jetzt aber alle Kabel 20m lang machen würde, käme ich locker über eine Länge hinaus die überhaupt noch funktioniert mit dieser Art Bus, hierzu sind im Internet meist maximale Kabellängen von 50 bis 100m angegeben.

    Doppelte Sensoren an einen Messpunkt geht auch nicht denn die maximale Anzahl dieser 1-wire Fühler liegt bei 20 ... ich bin jetzt schon bei 15. Außerdem steigt, wenn es mal passiert, sowieso die ganze Fühlerkette aus.

    Minutentakt Abfrage ist auch unmöglich ... Du hast noch keinen Kaminofen richtig brennen sehen, oder? ;) Da steigt die Temperatur seeeeehr schnell in Richtung 100 Grad (um die 70-80° liegt sie bei warmen Pufferspeicher eh schon), sprich in Richtung explodierenden Dampf ... wenn es da kurz davor nicht die Zwangskühlung durch kaltes Leitungswasser gäbe, welche ich natürlich unbedingt verhindern möchte!

    Übrigens bin ich beim Pull-Up Widerstand dank der langen Leitungen und vielen Fühler inzwischen schon bei 600 Ohm angelangt. Die Standard Schaltungen gehen von ca. 5 kOhm aus ... ich weiß nicht wieviel weniger ich meinem armen Kleinen noch zumuten kann bevor die Schnittstelle abraucht.

    Hast denn Du auch etwas Ähnliches am Laufen, Andreas?
    Ich versuche mal ein Bildchen anzuhängen vom FrontEnd der Steuerung das auf dem PC läuft.

  • Hallo Elsol666,

    jetzt wo die Anwendung bekannt ist, sieht das natürlich anders aus.


    Doppelte Sensoren an einen Messpunkt geht auch nicht denn die maximale Anzahl dieser 1-wire Fühler liegt bei 20 ... ich bin jetzt schon bei 15. Außerdem steigt, wenn es mal passiert, sowieso die ganze Fühlerkette aus.

    Die Anzahl der Sensoren am 1Wire-Bus kannst Du auf folgende Weise erhöhen: [Quelle: PN an einen bekannten User]

    Eigentlich brauchst Du nur einen einzigen Widerstand (s. Poti) für N Sensoren - hast Du echt bei jedem DS1820 zwischen VDD und DQ einen eigenen Widerstand gesetzt?

    Das mit den gleich langen Leitungen war eine Idee, um die Leitungswiderstände annähernd konstant zu halten - aber ich denke mal, dass es bei diesen Längen gleichgültig ist, ob eine Leitung jetzt 20 % länger als eine andere Leitung ist.



    Hast denn Du auch etwas Ähnliches am Laufen, Andreas?

    Nee, aber Interesse am Programmieren diverser Anwendungen.

    Jetzt erscheint aber auch die Frage mit dem zweiten Raspberry in einem anderen Licht. Die Abfrage eines DS1820 dauert knapp eine Sekunde. Wenn Du 15 Sensoren hast, dann brauchst Du allein zum Erfassen der Messwerte 11,25 Sekunden. Ich hatte auch mal Sensoren, bei denen eine Abfrage 950 ms benötigt hatte. Da wären die 15 Sekunden weitgehend aufgebraucht. Das restliche Programm müsste sich dann für die anderen Aufgaben (Steuern und Regeln) sehr beeilen.
    Wenn Du den Weg mit redundanten Sensoren gehen / testen möchtest, dann wäre in der Tat ein zweiter Raspberry erforderlich, wenn 2x15 Sensoren innerhalb 15 Sekunden abgefragt werden sollen.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (27. November 2015 um 22:30)

  • Wau, mehr als 20 Sensoren, das habe ich auch noch nicht gewusst ... super, vielen Dank!!!! :thumbs1:


    Genaue Zeitmessung habe ich zwar noch nicht gemacht, aber er scheint die 15 Sensoren in ca. 5 Sekunden durch zu haben denn ich lasse ihn sogar noch 10 sek schlafen und komme insgesamt bei 16-17 sek für einen Durchlauf raus.

    Ich habe nicht an jedem einen Widerstand, aber an drei Zweigen an denen jeweils mehrere Sensoren hängen. Dadurch kann ich sie rausziehen oder reinstöpseln wie ich lustig bin, geht ganz gut!
    Ich denke das wirkliche Problem ist die Länge der Leitungen obwohl sie abegeschirmt sind, zumal sie auch oft neben 220V Kabeln laufen (müssen) an denen induktive Verbraucher hängen, da kann schon mal etwas reinstreuen!

    Insgesamt bin ich auf jedem Fall vom Raspy begeistert, geniales Teil!!!! :D

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!