[gelöst] Temperaturabfrage bricht ständig ab

[dan1180]

Hallo zusammen,

ich kämpfe nun schon seit geraumer Zeit und komm einfach nicht weiter. Ich habe an meinem RPI über einen DS2480 (USB -> 1wire), 19 Temperatursensoren hängen. Diese haben auch funktioniert. Nun habe ich seit längerem das Phänomen, dass ohne erkennbaren Grund die Temperaturmessung stehen bleibt und sich das LOG mit Fehlermeldungen füllt. Ein Löschen und neu Definieren aller Komponenten bringt dann wieder für ein paar Tage Abhilfe. Ich habe inzwischen sowohl OWX, als auch OWX_ASYNC getestet. Im Log steht die letzte erfolgreiche Temperaturmessung folgendermaßen:

Code Auswählen Erweitern

2017.09.26 02:21:55 1: OWTHERM: fbh_vl has returned invalid data of length 20
2017.09.26 02:21:55 1: OWXTHERM_BinValues called for device fbh_vl in context getsp with data 0x34 0x00 0x32 0x14 0xff 0xff 0x0e 0x10 0x71
2017.09.26 02:21:55 1: OWXTHERM_BinValues:  fbh_vl: no error,  25.875  0x34 0x00 0x32 0x14 0xff 0xff 0x0e 0x10 0x71
2017.09.26 02:21:55 4: [fbh_vl moving average] Value = 26 Time = 2017-09-26 02:16:55
2017.09.26 02:21:55 4: [fbh_vl moving average] Value = 25.9375 Time = 2017-09-26 02:17:55
2017.09.26 02:21:55 4: [fbh_vl moving average] Value = 25.9375 Time = 2017-09-26 02:18:55
2017.09.26 02:21:55 4: [fbh_vl moving average] Value = 25.9375 Time = 2017-09-26 02:19:55
2017.09.26 02:21:55 4: [fbh_vl moving average] Value = 25.875 Time = 2017-09-26 02:21:55
2017.09.26 02:21:55 4: [fbh_vl moving average] calculated over 5 values is    26
2017.09.26 02:21:55 5: Starting notify loop for fbh_vl, 3 event(s), first is temperature: 25.875
2017.09.26 02:21:55 5: End notify loop for fbh_vl


Danach kommt nur noch

Code Auswählen Erweitern

2017.09.26 02:22:02 1: OWTHERM: fsk_rl has returned invalid data of length 20
2017.09.26 02:22:02 1: OWXTHERM_BinValues called for device fsk_rl in context getsp with data 0x6a 0x01 0x4b 0x46 0x7f 0xbf 0xff 0xff 0x06
2017.09.26 02:22:02 1: OWXTHERM_BinValues:  fsk_rl: invalid CRC,  22.625  0x6a 0x01 0x4b 0x46 0x7f 0xbf 0xff 0xff 0x06

2017.09.26 02:22:10 1: OWXTHERM_BinValues called for device hkk_vl in context getsp with data 0x36 0x00 0x64 0x00 0x80 0xff 0xff 0xff 0xff
2017.09.26 02:22:10 1: OWXTHERM_BinValues:  hkk_vl: invalid CRC,  26.75  0x36 0x00 0x64 0x00 0x80 0xff 0xff 0xff 0xff
2017.09.26 02:22:11 1: OWXTHERM_BinValues called for device kol_rl in context getsp with data 0xb9 0x01 0x64 0x00 0x7f 0xff 0xff 0x07 0x83
2017.09.26 02:22:11 1: OWXTHERM_BinValues:  kol_rl: invalid CRC,  27.5625  0xb9 0x01 0x64 0x00 0x7f 0xff 0xff 0x07 0x83

2017.09.26 02:23:02 1: OWXTHERM_BinValues called for device fsk_rl in context getsp with data 0x6a 0x01 0x80 0x4b 0xa5 0x46 0xa3 0x7f 0xbf
2017.09.26 02:23:02 1: OWXTHERM_BinValues:  fsk_rl: invalid CRC,  22.625  0x6a 0x01 0x80 0x4b 0xa5 0x46 0xa3 0x7f 0xbf

2017.09.26 02:23:10 1: OWTHERM: hkk_vl has returned invalid data of length 20
2017.09.26 02:23:10 1: OWXTHERM_BinValues called for device hkk_vl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:23:10 1: OWXTHERM_BinValues:  hkk_vl: invalid CRC,  -1.25  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:23:11 1: OWXTHERM_BinValues called for device kol_rl in context getsp with data 0xb9 0xdc 0x01 0x64 0x00 0x7f 0xbf 0xff 0xff
2017.09.26 02:23:11 1: OWXTHERM_BinValues:  kol_rl: invalid CRC,  -52.4375  0xb9 0xdc 0x01 0x64 0x00 0x7f 0xbf 0xff 0xff
2017.09.26 02:23:18 1: OWTHERM: obk_rl has returned invalid data of length 20
2017.09.26 02:23:18 1: OWXTHERM_BinValues called for device obk_rl in context getsp with data 0xdf 0x95 0xca 0x01 0x80 0x64 0xb2 0x00 0x7f
2017.09.26 02:23:18 1: OWXTHERM_BinValues:  obk_rl: invalid data,  -34.0625  0xdf 0x95 0xca 0x01 0x80 0x64 0xb2 0x00 0x7f

2017.09.26 02:24:02 1: OWTHERM: fsk_rl has returned invalid data of length 20
2017.09.26 02:24:02 1: OWXTHERM_BinValues called for device fsk_rl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:24:02 1: OWXTHERM_BinValues:  fsk_rl: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff

2017.09.26 02:24:10 1: OWXTHERM_BinValues called for device hkk_vl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:24:10 1: OWXTHERM_BinValues:  hkk_vl: invalid CRC,  -1.25  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff

2017.09.26 02:24:11 1: OWXTHERM_BinValues called for device kol_rl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:24:11 1: OWXTHERM_BinValues:  kol_rl: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:24:18 1: OWXTHERM_BinValues called for device obk_rl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:24:18 1: OWXTHERM_BinValues:  obk_rl: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff

2017.09.26 02:25:02 1: OWXTHERM_BinValues called for device fsk_rl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:25:02 1: OWXTHERM_BinValues:  fsk_rl: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff

2017.09.26 02:25:10 1: OWXTHERM_BinValues called for device hkk_vl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:25:10 1: OWXTHERM_BinValues:  hkk_vl: invalid CRC,  -1.25  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:25:11 1: OWXTHERM_BinValues called for device kol_rl in context getsp with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.09.26 02:25:11 1: OWXTHERM_BinValues:  kol_rl: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff


Ich habe einen zweiten DS2480, an dem ein 1-wire-Relais zur Heizpumpensteuerung hängt, angeschlossen. Dieser/dieses funktioniert ununterbrochen. Ein Tausch der beiden DS2480 bringt aber auch nichts.

Ich hoffe es kann mir jemand helfen bevor es richtig kalt wird

Falls zur Analyse Angaben fehlen, bitte nachfragen. Stelle gerne alles bereit.

Gruß
Dan

[Prof. Dr. Peter Henning]

Interessant. Welche Abfrageintervalle sind das denn ?

Bitte mal die Dateien 00_OWX.pm und 11_OWX_SER.pm ausprobieren, die am ENDE im Thread OWX Next Generation stehen. (vorher das alte 00_OWX.pm bitte sichern).

LG

pah

[dan1180]

Ich habe verscheidene Abfrageintervalle an meinen Sensoren. Die, die ich zur Steuerung der Heitung benötige werden alle 60 Sekunden abgefragt, andere, wie zum Beispiel die Außentemperatur vorm Haus, nur alle 15 Minuten (ändert sich ja auch in der Regel nicht so schnell).

Ich habe nun die Dateien aus deiner Antwort #414 heruntergeladen und aufgespielt. Nach einem "shutdown restart" war erstmal alles unverändert. Nach einem Reboot des RPI war dann mein OWX disconnected. Mittels "set ow_temp reopen" ist er nun "opened" holt sich aber immernoch keine neuen Temperaturen ab. Nach dem eingestellten Intervall holt er sich die zuletzt aufgezeichneten Temperaturen.

Code Auswählen Erweitern

Internals:
   ALARM      0
   ASYNC      0
   DEF        DS1820 F39FAA020800
   ERRCOUNT   1
   INTERVAL   300
   IODev      ow_temp
   NAME       fbh_rl
   NOTIFYDEV  global
   NR         377
   NTFY_ORDER 50-fbh_rl
   OW_FAMILY  10
   OW_ID      F39FAA020800
   PRESENT    0
   ROM_ID     10.F39FAA020800.83
   STATE      29°C
   TYPE       OWTHERM
   owg_temp   -1.25
   owg_th     -127
   owg_tl     -127
   READINGS:
     2017-10-01 10:44:17   state           initialized
     2017-09-30 10:55:03   temperature     28.9375
   tempf:
     factor     1
     offset     0
Attributes:
   IODev      ow_temp
   interval   300
   model      DS1820
   room       Heizung
   stateFormat {sprintf("%.f",ReadingsVal("fbh_rl","temperature",0))."°C"}
   tempHigh   40
   tempLow    20

Wie du sehen kannst wurde der Sensor neu initialisiert. Die Temperatur ist aber (auch nach einem get...temperature) von Gesternvormittag...

Was auch komisch ist: es verstellt mir regelmäßig meine tempHigh und tempLow Attribute?

Ich habe OWX (noch) nicht auf "asynchronous" gestellt?!

Gruß
Dan

[Prof. Dr. Peter Henning]

Ich tippe bei diesem Verhalten darauf, dass irgendetwas mit dem Bus nicht stimmt - Verkabelung wackelig, oder ein Sensor defekt.

LG

pah

[dan1180]

Ich werde den Bus nochmal tauschen.

Kann ein Temperatursensor ,,sporadisch" defekt sein? Wenn ich mein altes Backup wieder einspiele dann tut alles für 1-X Tage. Teilweise Wochen. Daher tue ich mich so schwer das ganze einzugrenzen.

Kann ich einen defekten Sensor irgendwie finden ohne sie einzeln zu entfernen und zu warten ob dann alles tut?

Gruß
Dan

[Bartimaus]

Moin,

bei mir sind auch über die Jahre (3) Sensoren sporadisch wegen Defekt ausgefallen. Dieses Verhalten wie in Deinem System konnte ich dabei nicht beobachten. (Ich nutze OWX-ASYNC mit ca 40 Sensoren).

Zu Beginn hatte ich allerdings massive Probleme auf dem "Bus" wenn da irgendwo ein Wackler drin war.

[dan1180]

So...Bus getauscht (sind baugleich). Erste Beobachtungen:

- Die meisten Sensoren messen im Moment.
- Drei Sensoren zeigen 0°, einer 85°. Errorcount geht dort fleisig hoch. Haben alle gestern noch realistische Werte gemessen.
- Alle dummies haben ihren Status verloren

Ob es einen Zusammenhang gibt weiß ich nicht. Werde das jetzt mal so laufen lassen. Ich hab ja zur Not noch mein Backup...

Edit 13:15 Uhr
Ich habe nun bereits nach ca. 30 Minuten mein Problem zurück  Das Positive daran ist, dass ich nicht Tage warten muss um zu sehen, dass ich es noch nicht gelöst habe.

BUS und Verkabelung schließe ich somit aus. Bleiben noch defekte Sensoren und weitere, bisher nicht in Betracht gezogene, Ursachen. Damit komm ich zurück zu meiner Frage nach der Suche defekter Sensoren. Kann man das irgendwie messen/prüfen/abfragen/...? Alle Sensoren sind parallel auf einer Leitung gelötet und nach erfolgreichem Testlauf vor gut 3 Jahren eingeschrumpft worden...wird ein Spaß da mittels ablöten und abwarten auf die Suche zu gehen 

Gruß
Dan

[dan1180]

Kurzes Update

Nachdem ich, wie im letzten Post beschrieben, nach kurzer Zeit wieder einen Zusammenbruch der Temperatursensoren hatte, bin ich beim erneuten Forum-Durchstöbern auf Beiträge gestoßen, die ein unterschiedliches Verhalten zwischen Neustart des PI (sudo reboot) oder FHEM (shutdown restart) und einer Stromunterbrechung beschrieben. Also habe ich den Pi für zehn Sekunden vom Netz getrennt und wieder unter Strom gesetzt.

Seit gestern Abend läuft alles normal und ALLE Temperatursensoren liefern mir realistische Werte. Kann ich somit einen Sensor-Defekt erst einmal ausschließen?

ABER!
Ich hatte dieses Verhalten bereits vor wochen schon einmal, nur nicht bewusst aufgenommen. Daher ist das wohl weniger eine Lösung, als eine weitere Verhaltensauffälligkeit bei der Fehlersuche?!?!?!?!

@pah
Kann/darf/soll ich OWX auf asynchronous umstellen? Ich habe am 29.09. ein FHEM-update gemacht und, wie von dir empfolen, 00_OWX.pm und 11_OWX_SER.pm ausgetauscht.

Danke und Gruß
Dan

[Fhemeinsteiger]

Ja, auch ich hatte auf einmal einen def. Sensor.(zeigte 4°C an und blockierte den Bus)
Er lief manchmal Wochenlang ohne Probleme.
Aber auch an einen Tag, hat er manchmal den Bus mehrere male zum Absturz gebracht.
Da half nur Neustart des Raspi.
Die Fehlersuche hat fast ein viertel Jahr gedauert, bei nur 8 Sensoren.
Ich habe einen nach dem anderen abgeklemmt und gewartet...
habe dann so den def. Sensor gefunden.

fhemeinsteiger

[dan1180]

Na du machst mir ja Hoffnung  3 Monate für 8 Sensoren...das heißt ich habs dann im kommenden Sommer gefunden...

Spaß beiseite. Ich habe in den vergangenen Tagen verschiedene Versuche unternommen:

• Nur um sicher zu sein habe ich eunen aktiven USB zwischen geklemmt: Ohne Erfolg.
• Abklemmen der drei am weitesten entfernten Sensoren (einen davon hatte ich als Übeltäter vermutet: System lief mehrere Tage durch, danach leider wieder das alte Verhalten.
• Script geschrieben um die USB-Anschlüsse für 10 Sek. stromlos zu schalten, da ein Hardreset häufig geholfen hat. Dies sollte eine zeitweilige Notlösung sein, da ich das Script auch von unterwegs hätte ausführen können, wenn die Sensoren mal wieder hängen: Leider war Besserung bei tatsächlicher Stromunterbrechung des Pi häufiger als beim "USB-Reset".

Ich bin weiter für jeglichen Vorschlag zu haben, werde nun aber, da die Heizsaison beginnt und ich drei der Sensoren für die Steuerung benötige, eine Bypass-Leitung legen. Diese ist dann überschaubar (wie gesagt 3 Sensoren). Parallel setze ich einen zweiten Pi auf (von denen liegen ja immer ein paar rum ) und geh auf die Suche des defekten Sensors. So bin ich am schnellsten für den Winter gewappnet und kann in Ruhe die Fehlersuche fortsetzen...

Eine brennende Frage konnte mir bisher noch niemand beantworten:
Gibt es irgend eine Möglichkeit festzustellen, ob ein Temperatursensor noch geht? Messung mittels Multimeter? Prüfscript auf Pi, mit dem man n Abfragen pro Minute startet, loggt und dann schaut ob er ab und an aussteigt?

Danke und Gruß
Dan

[cwagner]

vielleicht hilft insbesondere Punkt 2 in diesem Posting: https://forum.fhem.de/index.php/topic,77853.msg698967.html#msg698967 (Nachrricht 6)

Gruß

Christian

[dan1180]

@christian:
Meinst du deine Antwort 7? Die Anschlüsse habe ich bereits mehrmals kontrolliert. Der Punkt mit zu viel Klemmung ist mir absolut neu aber ich werde das nochmal prüfen.

Ein weiteres Phänomen, das ich vergessen habe zu erwähnen, das heute aber wieder aufgetreten ist, ist folgendes:

Ein "get devices" am entsprechenden BUS meiner Temperatursensoren liefert mir die Anwort aus dem Screenshot. Es wird das Device im Raum "OWX" angelegt. Meine Temoeratursensoren stehen alle auf "initialized" aber present=0. Verhalten wie gehabt, also keine Temperaturaktualisierung.
Ein "get devices" an meinem anderen BUS gibt mit brav mein Relais aus. Ein Tauschen der BUSSE ändert das Verhalten nicht.

Noch eine Idee:
Kann es sein, dass die ID meiner BUSSE zu ähnlich ist? Die unterscheidet sich nur in einem Buchstaben?

Danke und Gruß
Dan

[Prof. Dr. Peter Henning]

Nein. Verdrahtungsfehler oder defekter Sensor.

LG

pah

[cwagner]

Hi Dan1180,

ja, sorry, hatte die Nummerierung falsch notiert.
Ich bin wie pah der Meinung, dass es ein Verdrahtungsfehler sein muss - ähnlich war es halt auch bei mir. Das mit den gequetschten einadrigen Kabeln ist so: Bei Lüsterklemmen ohne Adernschutz (so eine kleine Metallzunge vor dem Schraubenende) führt ein zu starkes Anziehen dazu, dass der Kupfer platt gequetscht wird und bricht dann gerne an der Quetschstelle unbemerkt.

Christian

[dan1180]

Ok, dass die Adern an der Stelle Brechen können gibt für mich wieder ein Bild. Alleine die gequetschte Ader als Ursache war für mich nicht nachvollziehbar.

Dann gehe ich endgültig von einem defekten Sensor aus. Meine Kabel sind alle mit den Sensoren verlötet und haben nun über Jahre funktioniert. Kann mir nicht vorstellen, dass da die Ursache liegt. Möge die Suche beginnen...

Danke an euch, ich werde berichten.

Gruß
Dan