Hallo zusammen,
habe seit Tagen das Problem, dass meine 1Wire Temperaturen nur noch mit "defined" angezeigt werden und mein 1Wire-Adapter sich mit "failed" im Status (s. Anhang) meldet. Im Log steht folgendes:
2015.09.26 11:58:22 3: OWX: Complex called with undefined interface
2015.09.26 11:58:22 3: OWX: Reset called with undefined interface
in einer Schleife.
Kennt jemand dieses Problem oder Hat einer einen Tipp für mich? Habe mittlerweile drei verschiedene Adapter ohne erfolg getestet. Hat sich vielleicht etwas an der Konfi geändert? Muß der Adapter anders angemeldet werden? Ich definiere ihn bisher so "define 1wire OWX /dev/ttyUSB0"
Ist der Adapter auch auf USB0 gemountet ?
Ja, der Adapter ist mir usb0 angemeldet.
Gesendet von meinem SM-G900F mit Tapatalk
Nein, da hat sich gar nichts geändert.
Was sagt das Log denn nach einem "shutdown restart" ? Da sollte etwas zu lesen sein wie:
2015.09.22 04:13:14 3: Opening OWX_OG device /dev/owxog
2015.09.22 04:13:14 3: Setting OWX_OG serial parameters to 9600,8,N,1
2015.09.22 04:13:14 3: OWX_OG device opened
2015.09.22 04:13:14 1: OWX_SER: Serial device /dev/owxog defined
2015.09.22 04:13:16 1: OWX_SER::Detect 1-Wire bus OWX_OG: interface master DS2480 detected for the first time
LG
pah
Der Adapter meldet sich bei mir im Log-File folgendermaßen:
2015.09.27 10:16:46 3: Opening 1wire device /dev/ttyUSB0
2015.09.27 10:16:46 3: Setting 1wire serial parameters to 9600,8,N,1
2015.09.27 10:16:46 3: 1wire device opened
2015.09.27 10:16:46 1: OWX: Serial device /dev/ttyUSB0 defined
und die einzelnen Temperaturfühler so:
2015.09.27 10:17:40 3: OWTHERM: Device AL_Raumtemperatur defined.
Warum steht bei Dir in Zeile 4 und 5 OWX_SER?
Das bedeutet, dass OWX unter ttyUSB0 kein Interface findet. Vermute mal, dass ein anderes USB-Device den Port für sich reklamiert.
Vorgehensweise: per udev-Rule dem Adapter mit der und der Seriennummer ein festes Device-File zuweisen. Wurde hier im Forum schon ungefähr 400 x diskutiert.
Warum das bei mir anders aussieht ? Leicht andere Version ...
Ich hänge diese inoffiziellen Versionen gerne hier an - aber bitte vorerst ohne Garantie, noch Beta. Alte Versionen unbedingt vorher sichern - ich kann im Moment keine Zeit erübrigen, bei Wiederherstellungen zu helfen.
LG
pah
Werde ich mal versuchen. Verstehe aber nicht, warum das System mit meiner Konfi über ein Jahr problemlos funktioniert hat.
Ich habe immer schon Probleme zu verstehen, warum bei anderen etwas nicht funktioniert. Überfordert bin ich mit der Frage, warum bei Anderen etwas funktioniert oder funktioniert hat....
Aber ernsthaft: An der Software hat sich nichts geändert. Also erster Verdacht: Es hat sich etwas an der Hardware geändert, de USB-Port ttyUSB0 wird von einem anderen Gerät belegt.
LG
pah
Nun stehen alle 1Wire Teilnehmer auf " initialized"
Log zeigt folgenden Eintrag:
2015.09.27 14:50:12 3: Opening 1wire device /dev/ttyUSB0
2015.09.27 14:50:12 3: Setting 1wire serial parameters to 9600,8,N,1
2015.09.27 14:50:12 3: 1wire device opened
2015.09.27 14:50:22 3: OWX_SER::Detect 1-Wire bus 1wire: interface master DS2480 detected for the first time
Screenshots im Anhang
Äh - ja ? Er findet das Interface, was sagen denn die Devices, wenn sie abgefragt werden ? Was sagt die Bus-Suche ?
LG
pah
Wo sehe ich das? Im event log?
Gesendet von meinem SM-G900F mit Tapatalk
Nein. Direkt auf dem OWX Device get devices ausführen - nur anklicken.
LG
pah
Es wird folgende Meldung ausgegeben:
OWTHERM: Could not get values from device DB_Raumtemperatur, return was invalid data
kann es sein, das alle meine 12 Temperatur-Sensoren defekt sind? Habe leider aktuell keinen unbenutzten, um diesen alleine am Adapter zu testen.
Das sieht dann nach einem Verkabelungsfehler auf dem Bus aus.
LG
pah
Aber wie schon gesagt, die Verkabelung ist seit einem Jahr unberührt in Betrieb. Hat im Sommer einen Blitzeinschlag, der damals für mich aber erstmal nichts zerstört hat. Ist es möglich, dass die Sensoren einen ab bekommen haben?
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
Äh - wie ist es denn nun, Fehler gefunden ?
LG
pah
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
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
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
Es kann jeder die Software benutzen, die ihm am Besten gefällt - einer Begründung durch Märchen bedarf es nicht.
LG
pah
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
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
Hallo Peter,
ZitatErgo: 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.
Zitat
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 (https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1500860)
=> Kein Märchen.
ZitatUnd 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
ZitatUnter 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
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
Hallo Peter,
ZitatLeider doch ein Märchen. "Invalid data" = fehlerhafte CRC-Werte wird von OWFS einfach nicht gemeldet.
Bei OWFS steht:
ZitatOWFS 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
sudo service owserver stop beendet um die serielle Schnittstelle freizugeben.
In FHEM wieder auf OWX "umkommentiert":
# $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 ;)
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
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
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