[TIPP] Leitfaden zur strukturierten Fehlersuche in 1-W (und anderen) Bussystemen

Ihr habt ein tolles 1-Wire Projekt gebaut, dann stellt es vor, es hilft anderen auf Ideen für die eigenen Aufgabenstellungen zu kommen.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten
Benutzeravatar

Ersteller
773H
Reactions:
Beiträge: 425
Registriert: Mo Okt 15, 2018 9:24 pm
Hat sich bedankt: 95 Mal
Danksagung erhalten: 191 Mal

Leitfaden zur strukturierten Fehlersuche in 1-W (und anderen) Bussystemen

#1

Beitrag von 773H »

Aus aktuellem Anlass der schon seit längerem fälligen Fehlersuche bei mir. Hilft vielleicht dem einen oder anderem auch weiter, der das so noch nie machen musste ... :idea:
Ein Leitfaden zur strukturierten Fehlersuche in 1-W (und anderen) Bussystemen findet sich sicherlich auch in der einen oder anderen Dokumentation von ElabNET in einer ähnlichen Form. Im Forum konnte ich diesbezüglich nichts ausführliches finden. Darf gerne in der KB hierhin -> app.php/kb/viewarticle?a=54 <- verschoben werden, da hätte ICH es gefunden)

Ausgangssituation
Seit 2 Jahren machte einer meiner Außensensoren (Hülsenfühler mit Silikonleitung) im Gullisumpf Probleme, wenn die Temperaturen in den zweistelligen Minusbereich gingen. Er lieferte dann keine Werte mehr. Erstmal egal.
Seit ca. einem halben Jahr zeigte der Kanal des PBM mit dem angeschlossenen Außenbereich eine verminderte Busqualität (5%) mit dem Mouse-over-Hinweis: „viele Fehler, Verkabelung, Klemmstellen, Buslänge überprüfen“ (oder so ähnlich). Erstmal egal, denn die 5 Balken daneben waren alle grün, die Messwerte aller Sensoren wurden weiterhin zuverlässig geliefert, die Zeitserien zeigen keine Aussetzer (bis auf manchmal den Gullifühler).
Seit dem Update des TWS von V3.0IP3 auf V3.0IP4 dann das Desaster: Nach dem Neustart des Systems war der Kanal des PBM dauerhaft rot hinterlegt. PBM-Kanal tot. Nicht egal, denn alle an diesen Kanal angeschlossenen Sensoren waren auf einen Schlag weg.
ext/dmzx/imageupload/files/0b7e98dac483 ... 04cf34.jpg

Deswegen ist es auch WICHTIG, einen Neustart des Servers ca. 1 Tag VOR der Updaterei durchzuführen, denn dieser schon länger bestehende Fehler trat ja erst NACH dem Neustart störend in Erscheinung und würde dann fälschlicherweise dem Update angelastet!!!

Vorüberlegung
Es spielt eine Rolle, ob man Fehler in einer Bestands- oder Neuinstallation sucht. In meinem Beispiel einer lange Jahre fehlerfrei funktionierenden Bestandsinstallation kann man natürlich alle Verdrahtungsfehler, ungünstige Buslänge, ungeeigneten Abzweige, etc. ausschließen. Es kann letztendlich nur einer (oder mehrere!) der Sensoren defekt sein oder sich eine Klemmstelle gelöst haben (wenn kurz zuvor keine Bauarbeiten (Bohrer!) im Haus durchgeführt wurden und auch keine neuen Sensoren hinzugefügt wurden!). Diese Art von Fehler in einer Neuinstallation / Änderungsinstallation / Post-Baustellen-Installation lassen sich allerdings durch die im Folgenden beschriebene Fehlersuche ebenfalls ausfindig machen.

Fehlersuche
Wichtig ist hierbei vor allem, dass man SYSTEMATISCH vorgeht, um unnötige Mehrfacharbeiten zu vermeiden. Weiterhin ist es essentiell, dass der Fehlersuchende weiß, wo ALLE Klemmstellen und Sensoren zu finden sind und diese natürlich auch zugänglich sind!
ext/dmzx/imageupload/files/f38adc69c0a5 ... 219588.jpg
Wir gehen mal davon aus, dass der Eigentümer der Anlage dieses Wissen hat, denn sonst wird es sehr zeitaufwendig.
Zunächst zieht man den entsprechenden Stecker des Kanals des PBM ab und überprüft, ob der Kanal wieder die vorherige Busqualität liefert. Dies dient dazu, Hardwaredefekte durch den Fehler am PBM auszuschließen. Man kann natürlich auch im entsprechenden Stockwerk das ankommende Buskabel vom Rest trennen und muss nicht an den PBM (Abdeckungen im Sicherungskasten, etc).
ext/dmzx/imageupload/files/d9505cb000a6 ... c3dc87.jpg
Danach sucht man sich eine Klemmstelle an der zu untersuchenden Buslinie, die idealerweise mittig zwischen allen angeschlossenen Sensoren liegt - also 50% der Sensoren sind vor und 50% der Sensoren sind hinter dieser Klemmstelle an den Bus angeschlossen. Hier wird der Bus nun aufgetrennt, indem man vorsichtig an dem zu lösenden Draht zieht und dabei die Wago-KNX-Klemme durch leichte Drehbewegungen hin und her bewegt.
[Anmerkung: wenn man das zu oft macht, nutzt sich der Kupferdraht immer weiter ab, bis er nicht mehr zuverlässig in der Klemme hält. Man kann das an den zunehmenden Riefen im Kupfer erkennen, die irgendwann in eine Mattierung übergehen. Spätestens jetzt sollte man den Draht an der Isolierung abzwicken und neu abisolieren. Wer auf Nummer sicher gehen will, macht das vor jedem neuen Einstecken des Drahtes in die KNX-Busklemmen. Wenn sich der Draht ohne Drehbewegungen aus der Klemme ziehen lässt, hat man eine neue zukünftige Fehlersuche erfolgreich vorbereitet ...]
ext/dmzx/imageupload/files/bdaf42d2cc34 ... ae21da.jpg
Dies kann unter entsprechenden Vorsichtsmaßnahmen auch unter Spannung (SELV) durchgeführt werden, ist aber aus Gründen von möglichen Hardwaredefekten NICHT empfehlenswert!
[Anmerkung: aus historischen Gründen ist bei mir im Projekt das 1-W-Buskabel GRÜN und der KNX-Bus ORANGE. In Abweichung zu den vorherrschenden Meinungen in anderen Foren ist auch diese Kombination funktionstüchtig]. :mrgreen:
Einzelne UP-Sensoren lassen sich durch Abziehen der Wagoklemmen vom Bus trennen – das ist identisch zu KNX-Geräten.
Nach dem Öffnen der Buslinie an dieser Stelle kann man unter den Reitern „1-Wire“ -> „Schnittstellen“ auf -> „erneute Inventur“ drücken oder warten, bis sich das System selbst aktualisiert hat. Ist der Kanal jetzt wieder grün (nicht notwendigerweise allerdings auf 100%) bzw. die rote Kanalmarkierung weg, wissen wir, dass der Fehler auf der abgeklemmten Seite des Busses liegt.
Ist der Kanal weiterhin gestört, wissen wir, dass zumindest „EIN“ Fehler auf der noch angeschlossenen Seite liegt. Für die weitere Beschreibung gehen wir einfach davon aus, dass es genau „EINEN“ Defekt in dieser Buslinie gibt, denn sonst wird die Beschreibung unnötig lang und kompliziert. Mehrfachfehler lassen sich durch dieses Vorgehen genauso ausfindig machen.
Wir gehen davon aus, dass durch die eben durchgeführte Maßnahme der Bus wieder auf „grün“ ist.
ext/dmzx/imageupload/files/46a6feb170e4 ... 963fe8.jpg
Man schließt in diesem Fall die abgeklemmten Drähte wieder farbrichtig an und bewegt sich weiter am Bus entlang Richtung einer Klemmstelle, an der die Sensoraufteilung 25% hin zum Ende des Buskabels und 75% zum PBM ist. Hier wird wieder aufgetrennt und wieder getestet, ob der Bus in Ordnung ist. Man führt diese Schritte nun so oft Richtung Ende des Buskabels (und im weiteren Verlauf natürlich auch eventueller Abzweige) durch, bis man letztendlich am Verursacher der Störung angelangt ist. Dieser wird dann abgeklemmt / getauscht.
Eine Übersicht über noch verbleibende Sensoren liefert im Übrigen der „Slave-Manager“ An dieser Stelle kann man nachsehen, wenn man sich nicht mehr ganz sicher ist, was noch alles im weiteren Verlauf an Sensoren angeschlossen wurde.
ext/dmzx/imageupload/files/3e667d62d7ad ... 745a49.jpg
Wenn man sicher gehen will, dass jetzt alles wieder in Ordnung ist, kann man den TWS neu starten, denn dann werden auch alle 1-W Dienste neu gestartet und damit die Bushistorie mit der Busqualität gelöscht. Alternativ kann man auch nur den 1-W Dienst unter „Systemeinstellungen“ -> System“ -> „Monitor“ neu starten, indem man hinter „1-W-Subsystem“ auf „Neustart“ klickt – das habe ich allerdings nicht getestet und weiss nicht, ob das so wie gedacht funktioniert.
ext/dmzx/imageupload/files/dfcf652e94e4 ... 14cec0.jpg

Viel Erfolg bei der Fehlersuche
Stephan
Zuletzt geändert von 773H am Mi Dez 29, 2021 3:26 pm, insgesamt 2-mal geändert.
TWS 2500 ID:677, PBM ID:495 & ID:632, TWS 2500 ID:220 TWS 2500 ID:574 , PBM ID:1022, beide VPN offen, Neustart kein Problem
In Gebrauch -> HS4, TWS, KNX, 1-W, DALI, MQTT, Home Connect. In Test -> e-key. In Planung -> DMX

MartinMV
Elaborated Networks
Reactions:
Beiträge: 5
Registriert: Sa Aug 11, 2018 10:47 pm
Danksagung erhalten: 8 Mal

#2

Beitrag von MartinMV »

Auch wenn ich jetzt nicht alle Bilder angesehen habe, ist das im Allgemeinen genau die Vorgehensweise, die wir im Support so auch empfehlen.
Gerade durch die stetige Halbierung des vermutlich fehlerhaften Busstücks kommt man oft recht effizient ans Ziel.

Beim Lösen der Busleitung von der WAGO-Klemme bitte bedenken, dass die Leiter hier evtl. geknickt werden, wenn man nicht aufpasst.
Wir hatten schon mehrmals den Fall, dass sich, nach langem Suchen, ein verdeckter Leiterbruch als Ursache für den vermeintlich defekten Sensor herausgestellt hat.
Antworten

Zurück zu „Vorstellung Eurer Projekte“