1Wire-Adapter meldet sich mit "failed"

[Prof. Dr. Peter Henning]

Natürlich - aber dann wären die ja schon im Sommer gestorben.

Ich tippe darauf, dass entweder irgendwo ein Kabelbruch vorliegt, oder dass einer der Sensoren so defekt ist, dass er den Bus blockiert.

Also Multimeter auspacken und die Leitung kontrollieren

LG

pah

[Prof. Dr. Peter Henning]

Äh - wie ist es denn nun, Fehler gefunden ?

LG

pah

[tantor]

Leider noch nicht. Wie kann ich den Bus messtechnisch prüfen? Ohmisch oder auch in Betrieb unter Spannung?  Werde morgen den Bus Stück für Stück öffnen und testen.

Gesendet von meinem SM-G900F mit Tapatalk

[Bartimaus]

Sowohl als auch. Die Leitungen prüfe ich "ohmisch", und an den Sensoren prüfe ich ob genug Spannung anliegt. Bei meinem Bus sind es ca. 4,8V

Guggst Du: http://www.fhemwiki.de/wiki/1-Wire_St%C3%B6rungsbeseitigung

[ojb]

Hallo,

ich hatte so ein ähnliches Problem. Mein 1-Wire USB Interface war über OWX angebunden. Das hat jetzt auch monatelang problemlos funktioniert (Counter, Temp, Feuchte).

Dann hatte ich Probleme mit einem bekannten Bug in einem neuen Linux Kernel von Ubuntu (siehe anderer Beitrag von mir). Der zerschiesst die Kommunikation mit dem USB-Interface.

Nachdem ich wieder auf den "guten Kernel" zurück bin lief wieder alles außer OWX. Es wurde aber weder HW noch SW verändert. Auch ich hatte dann "invalid data".

Ich hab dann mal die Weboberfläche von OWFS probiert und siehe da ich kann auf meine Sensoren zugreifen, es kommen Daten, alles passt.

Also habe ich in FHEM von OWX auf OWServer umgetsellt und seitdem läuft wieder alles.

Erklären kann ich es mir nicht ....

Liebe Grüße
Oli

[Prof. Dr. Peter Henning]

Es kann jeder die Software benutzen, die ihm am Besten gefällt - einer Begründung durch Märchen bedarf es nicht.

LG

pah

[ojb]

Hallo pah,

was willst Du mir mit der Antwort sagen? Ich hätte gerne OWX weiterverwendet ... mit den paar Stunden Docs lesen, testen und umkonfigurieren hätte ich besseres anzufangen gewusst.

Ich schalt Dich gerne mal mit Teamviewer auf meine Maschine und lasse Dich an meinem Märchen live teilhaben.

Interessanter wäre doch zu fragen warum tantor im gleichen Märchen ist ....

Schönen Abend
Oli

[Prof. Dr. Peter Henning]

Erstens: Wenn man Software A durch Software B ersetzt, gibt es natürlich keine Fehlermeldungen mehr, die zu Software A gehören.
Zweitens: Datenpakete mit ungültigem CRC werden von OWFS genauso verworfen, wie von OWX - man bemerkt es nur nicht.

Ergo: Die Behauptung, dass die Fehler nicht mehr da seien durch Wechsel von OWX auf OWFS ist keine korrekte Schlussfolgerung - sondern ein Märchen.

Die Vorstellung, dass Sensoren oder gar der Busmaster durch kurzzeitige Verwendung eines anderen Kernels beschädigt worden seien, halte ich ebenfalls für gewagt. Wahrscheinlichste Erklärung in diesem Fall: Mit dem Wechsel des Kernels wurden weitere Veränderungen am System vorgenommen, die mit dem Zurückwechseln nicht komplett zurückgedreht wurden.

Und schließlich, aus vier Jahrzehnten IT-Erfahrung: Wenn Nutzer X ein Phänomen "invalid data" meldet, und Nutzer Y ebenso, heißt das noch lange nicht, dass beide Fehler dieselbe Ursache haben.

LG

pah

[ojb]

Hallo Peter,

Ergo: Die Behauptung, dass die Fehler nicht mehr da seien durch Wechsel von OWX auf OWFS ist keine korrekte Schlussfolgerung - sondern ein Märchen.

Unter OWX werden alle Sensoren erkannt, aber ich bekomme vom Counter "invalid data", die Temperatur- und Feuchtefühler am selben Bus laufen ohne Probleme.
Ich kommentiere OWX aus und nehme OWServer und alles geht wieder inklusive Counter.
=> Kein Märchen.

Die Vorstellung, dass Sensoren oder gar der Busmaster durch kurzzeitige Verwendung eines anderen Kernels beschädigt worden seien, halte ich ebenfalls für gewagt

Die Vorstellung würde ich auch ins Märchenreich einordnen.
Bei mir handelt es sich allerdings um einen bestätigten Bug, welcher die Kommunikation mit dem FTDI zerschiesst:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1500860
=> Kein Märchen.

Und schließlich, aus vier Jahrzehnten IT-Erfahrung: Wenn Nutzer X ein Phänomen "invalid data" meldet, und Nutzer Y ebenso, heißt das noch lange nicht, dass beide Fehler dieselbe Ursache haben.

Zustimmung, aber wenn ich mir den Fall so anschaue dann sagt mein Instinkt, den ich in einem Ingenieursstudium und zwei Jahrzehnten als Entwicklungsingenieur in der Elektronikabsicherung eines großen Münchner Automobilbauers schärfen konnte, da könnte ein Zusamenhang und ein reales Problem bestehen ....

Schönes Wochenende
Oli

[Prof. Dr. Peter Henning]

Unter OWX werden alle Sensoren erkannt, aber ich bekomme vom Counter "invalid data", die Temperatur- und Feuchtefühler am selben Bus laufen ohne Probleme.
Ich kommentiere OWX aus und nehme OWServer und alles geht wieder inklusive Counter.
=> Kein Märchen.

Leider doch ein Märchen. "Invalid data" = fehlerhafte CRC-Werte  wird von OWFS einfach nicht gemeldet.

LG

pah

[tantor]

Habe den Fehler gefunden!  Der Fehler wurde durch einen defekten  Temperatursensor verursacht.  Konnte den Fehler leider erst nach Umbau meiner Verdrahtung nach dem Ausschlussprinzip lokalisieren. Danke für eure Unterstützung.

Gesendet von meinem SM-G900F mit Tapatalk

[ojb]

Hallo Peter,

Leider doch ein Märchen. "Invalid data" = fehlerhafte CRC-Werte  wird von OWFS einfach nicht gemeldet.

Bei OWFS steht:

OWFS Fehlersuche

Das One-Wire Filesystem OWFS und die entsprechende Webseite des Servers bietet einige Möglichkeiten, um Fehler auf dem 1-Wire Bus festzustellen. Die Fehler können innerhalb der Statistik des OWFS gesehen werden.
CRC Fehler
Anzeige der CRC Fehler für den Bus

Die CRC Fehler werden auf der Seite ,,http://<IP-OWSERVER>:2121/bus.0/statistics/errors" dargestellt. Hier sieht man die Anzahl der übertragenen Pakete und deren Fehleranzahl. Bei einem guten Bus sollte die Anzahl der CRC8 / CRC16 = 0 sein. Generell kann man sagen, je größer diese Zahl im Verhältnis zu den gesendeten Protokollen ist, umso schlechter ist der Bus.
Search Fehler
Anzeige des Fehlerstatus für den Bus

Sollten während der Suche von Busteilnehmer auf dem 1-Wire Bus Fehler auftreten, werden diese auf diese Webseite des OWFS dargestellt. Hier sollte auch immer eine 0 stehen. Generell kann man sagen, je größer diese Zahl im Verhältnis zu den Suchanfragen ist, umso schlechter ist der Bus. http://<IP-OWSERVER>:2121/bus.0/bus.2/interface/statistics/search_errors

und bei mir sind die CRC Errors (siehe Screenshot) = 0.

Ich habe jetzt schnell folgendes gemacht:

OWServer mit

Code Auswählen Erweitern

sudo service owserver stop beendet um die serielle Schnittstelle freizugeben.

In FHEM wieder auf OWX "umkommentiert":

Code Auswählen Erweitern


#       $1-Wire

define ow_cuno OWX cuno
attr ow_cuno room !FHEM

#define ow_usb OWX_ASYNC /dev/serial/by-id/usb-E-Service_Online_1-Wire_Bus_Coupler_Iso_A6XOTIX4-if00-port0
define ow_usb OWX /dev/serial/by-id/usb-E-Service_Online_1-Wire_Bus_Coupler_Iso_A6XOTIX4-if00-port0
attr ow_usb room !FHEM

#define ow_usb OWServer localhost:4304
#attr ow_usb nonblocking 1
#attr ow_usb room !FHEM


Ergebnis:
Temp- und Feuchtefühler gehen einwandfrei. OWCOUNT bleibt auf 'initialized' und es kommen keine Werte.

Danach wieder "umkommentiert" auf OWSERVER.

Ergebnis:
Alle Sensoren liefern Werte.

Ergo => Kein Märchen   

[Prof. Dr. Peter Henning]

Erstens: Bitte die Antwort von tantor lesen, soviel zum Thema "gleiches Märchen".
Zweitens: Viel Spaß weiterhin, für eine solche Nulldiskussion habe ich keine Zeit.

pah

[ojb]

Erstens:
Du hast Recht, er hatte tatsächlich ein Hardwareproblem, also etwas ganz anderes. Ich lag also falsch.

Zweitens:
Schade daß Du so viel diskutiert hast und nicht versucht hast Dich konstruktiv mit meinem Problem von OWCOUNT zu befassen.
Das finde ich intellektuell ingenieurswissenschaftlich auf jeden Fall sehr spannend.
Ich kann mir keinen Reim drauf machen, zumal es ja über Monate stabil lief ...

ojb

[Prof. Dr. Peter Henning]

Ich habe das OWCOUNT-Modul entworfen, programmiert und leiste - wie man oben sieht - auch durchaus Support. Wie ebenfalls bereits gesagt: In den Rohdaten vom Bus treten hier CRC-Fehler auf. Aber das ist weder ein Fehler des Moduls, noch ein Problem der Konfiguration. Und wenn jemand nur darauf besteht, dass das mit einem anderen Backend nicht auftritt - voila, viel Spaß.

pah