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:
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
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
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
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.
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
Ich tippe bei diesem Verhalten darauf, dass irgendetwas mit dem Bus nicht stimmt - Verkabelung wackelig, oder ein Sensor defekt.
LG
pah
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
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.
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
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
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
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
vielleicht hilft insbesondere Punkt 2 in diesem Posting: https://forum.fhem.de/index.php/topic,77853.msg698967.html#msg698967 (https://forum.fhem.de/index.php/topic,77853.msg698967.html#msg698967) (Nachrricht 6)
Gruß
Christian
@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
Nein. Verdrahtungsfehler oder defekter Sensor.
LG
pah
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
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
Hallo zusammen,
mangels Zeit bin ich bishe noch nicht dazu gekommen meinen vermeintlich defekten Sensor zu suchen. Dadurch habe ich aber eine Beobachtung machen können, die mir vielleicht jemand erklären kann??? Im besten Fall ist dan vielleicht doch kein Sensor defekt :-D
Folgendes:
Wenn meine Sensoren aussteigen füllen sie mein Log mit
2017.11.14 13:01:16 1: OWXTHERM_BinValues: fbh_vl: invalid CRC, -1.25 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.14 13:05:09 1: OWXTHERM_BinValues: fbh_rl: invalid CRC, -1.25 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.14 13:05:11 1: OWXTHERM_BinValues: fsk_vl: invalid CRC, -0.0625 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.14 13:05:12 1: OWXTHERM_BinValues: hkk_rl: invalid CRC, -1.25 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.14 13:05:13 1: OWXTHERM_BinValues: kol_vl: invalid CRC, -0.0625 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.14 13:05:15 1: OWXTHERM_BinValues: obk_vl: invalid CRC, -1.25 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.14 13:05:16 1: OWXTHERM_BinValues: fbh_vl: invalid CRC, -1.25 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
oder
2017.11.14 12:40:25 1: OWXTHERM_BinValues: kol_rl: invalid data, 0.4375 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2017.11.14 12:40:26 1: OWXTHERM_BinValues: obk_rl: invalid data, 0 0x00 0x00 0x00 0x00 0x00 0x01 0x04 0x00 0xc3
2017.11.14 12:41:16 1: OWXTHERM_BinValues: fbh_vl: invalid data, 17 0x23 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2017.11.14 12:41:22 1: OWXTHERM_BinValues: fsk_rl: invalid data, 0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2017.11.14 12:41:23 1: OWXTHERM_BinValues: hkk_vl: invalid data, 0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2017.11.14 12:41:25 1: OWXTHERM_BinValues: kol_rl: invalid data, 0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2017.11.14 12:41:26 1: OWXTHERM_BinValues: obk_rl: invalid data, 16 0x00 0x01 0x00 0x00 0x59 0xff 0x0e 0x00 0xc3
oder
2017.11.14 12:39:23 1: OWTHERM: hkk_vl has returned invalid data of length 20
2017.11.14 12:39:22 1: OWTHERM: fsk_rl has returned invalid data of length 20
2017.11.14 12:38:25 1: OWTHERM: kol_rl has returned invalid data of length 20
...
An meinen Plots sehe ich dann, dass keine Temperaturen mehr geschrieben werden. Ein "get <device> temperature" gibt mir nur die zuletzt gemessene Temperatur zurück (auch wenn diese nicht mehr stimmen kann).
Nun das seltsame:
Wenn ich meine Fußbodenheizungspumpe manuell anschalte und somit eine Temperaturänderung an meinem Sensor für den entsprechenden Vorlauf provoziere, erwacht das GESAMTE System wieder zum Leben und gib zuverlässig alle Temperaturen zurück?!?!?!?!?!? So lange, bis dieser Sensor wieder über längere Zeit die gleiche Temperatur misst. Dann legt sich alles wieder zur Ruhe. Das funktoniert absolut reproduzierbar.
Kann das jemand erklären? Kann man das System manuell regelmäßig "anstoßen"? Oder habe ich hier evtl. meinen defekten Sensor gefunden?
Vielen Dank
Dan
So...ich scheine meinen defekten Sensor gefunden zu haben und getauscht. Seit einer Woche läuft alles wieder stabil. Toi Toi Toi...
Danke an alle für ihre Hilfe!
Gruß und schöne Feiertage
Dan
Was mich jetzt interessieren würde:
Wie hast Du Ihn jetzt gefunden?
Ich habe in meinem letzten Post von einem Temperatursensor gesprochen, der immer hängen blieb und bei einem "Systemanstoß" durch manuelles Starten der Fußbodenheizung wieder funktioniert hat. Warum der sich so verhalten hat...keine Ahnung.
Diesen Sensor habe ich als erstes getauscht und siehe da, das ganze System läuft wieder ohne Probleme.
Also kurz gersagt: Lange beobachtet (notgedrungen aus Zeitmangel) und mit dem für mich wahrscheinlichsten mit Austauschen angefangen. Und dann natürlich gaaanz viel Glück gehabt, dass es der auch war ;-)
Gruß
Dan