Buderus KM271 - Bekomme Kommunikation nicht repariert

[FosCo]

Hallo,

eigentlich hatte ich mich gefreut, passend zur Heizsaison eine Auswertung der letzten Heizperiode zu starten.
Dann muss ich leider feststellen, dass mein KM271 nicht mehr mit meinem raspi reden möchte.

Das hat bis zum März laut readings wunderbar funktioniert, anschließend nicht mehr. Der Alarm griff ins Leere, aber das ist ein anderes Thema (mqtt-bridge readings sind da eben speziell für den Alarm und brauchen ne andere Taktik).

Nun habe ich sowohl Heizung, als auch FHEM und raspi neugestartet, leider ohne Erfolg.

die 02 bekommt er noch raus, dann wars das.

Das Problem fing (natürlich an, als ich versucht habe, die Zirkulationspumpe abends runter und morgens rauf zu setzen.
Vorher gab es nur CRC Meldungen, aber die readings kamen.

Das war das erste Mal an Silvester:

Code Auswählen Erweitern

2018.12.31 20:12:53 1: KM271: Wrong CRC in datapacket <02>
2018.12.31 22:30:00 3: KM271: set ww_zirkulation 0
2018.12.31 22:30:04 2: KM271: NAK received
2018.12.31 22:30:04 2: KM271: Sending attempt for <0c0e656565656500100374> failed, retrying
2018.12.31 22:30:04 2: KM271: NAK received

Anschließend gab es die Monate immer wieder mal 10-20 NAKs für verschiedene Werte, danach nur noch CRC Fehler beim lesen.

Bis Mai:

Code Auswählen Erweitern

2019.05.18 09:20:25 2: KM271: NAK received
2019.05.18 09:20:25 2: KM271: Sending attempt for <ee00001003fd> failed, retrying

Das sieht inklusive FHEM Neustart heute noch genauso aus, nun verbose=5:

Code Auswählen Erweitern

Server shutdown
2019.10.29 13:01:58 1: Shutdown executed
2019.10.29 13:02:01 1: Including fhem.cfg
2019.10.29 13:02:04 3: WEB: port 8083 opened
2019.10.29 13:02:04 2: eventTypes: loaded 172 events from ./log/eventTypes.txt
2019.10.29 13:02:04 3: Opening KM271 device /dev/ttyAMA0
2019.10.29 13:02:05 3: Setting KM271 serial parameters to 2400,8,N,1
2019.10.29 13:02:05 3: KM271 device opened
2019.10.29 13:02:20 1: Including ./log/fhem.save
2019.10.29 13:02:20 1: usb create starting
2019.10.29 13:02:22 3: Probing ZWDongle device /dev/serial1
2019.10.29 13:02:22 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 426.
2019.10.29 13:02:22 1: ZWDongle: Can't open /dev/serial1: Input/output error
2019.10.29 13:02:22 3: Probing CUL device /dev/ttyS0
2019.10.29 13:02:22 1: CUL: Can't open /dev/ttyS0: Input/output error
2019.10.29 13:02:23 1: usb create end
2019.10.29 13:02:23 3: Opening mqtt device raspi3:1883
2019.10.29 13:02:23 3: mqtt device opened
2019.10.29 13:02:23 0: Featurelevel: 5.9
2019.10.29 13:02:23 0: Server started with 15 defined entities (fhem.pl:20415/2019-10-27 perl:5.024001 os:linux user:fhem pid:20620)
2019.10.29 13:02:23 3: DbLog logdb - Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2019.10.29 13:02:23 3: DbLog logdb - Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created
2019.10.29 13:02:23 5: KM271: KM271RAW <02020202020202020202>
2019.10.29 13:02:23 5: SW: 02
2019.10.29 13:02:23 5: KM271: KM271RAW <02>
2019.10.29 13:02:23 5: SW: 02
2019.10.29 13:02:23 5: KM271: KM271RAW <10>
2019.10.29 13:02:23 5: SW: ee00001003fd
2019.10.29 13:02:23 5: KM271: KM271RAW <15>
2019.10.29 13:02:23 2: KM271: NAK received
2019.10.29 13:02:23 2: KM271: Sending attempt for <ee00001003fd> failed, retrying
2019.10.29 13:02:23 5: SW: 02


Irgendwas scheint mit

Code Auswählen Erweitern

ee00001003fd fest zu hängen.

Hat jemand eine Idee, wie ich diese scheinbare Verstopfung lösen kann?
Die fhem.save habe ich schon zwischen shutdown und restart gelöscht, damit dort keine set werte dazwischenfunken können

[rudolfkoenig]

Ich wuerde versuchen die KM271 von einem anderen Rechner anzusprechen, oder statt ttyAMA0 einen USB-Seriell Wandler testen.
Sonst tippe ich auf einem Fehler im KM217, aber ich an deiner Stelle wuerde ich sowas nicht hoeren wollen

[FosCo]

Hey rudolfkoenig, ja, das wäre die unschönste aller möglichen Diagnosen, aber es wäre zumindest eine. Das Modul ist letztes Jahr als neues Teil direkt von der Wartungsfirma eingebaut worden, mal sehen.

Heizungsneustart war bei meinen Versuchen ebenfalls dabei, hat leider nichts geändert.

Den Debug werde ich vom Laptop aus mal versuchen, der letzte verbliebene mit serieller Schnittstelle ist dort ohnehin für solche Fälle zwischengeparkt
Allerdings erscheint mir das unwahrscheinlich, da es ja vorher lief...

edit: Danke für die schnelle Antwort

[rudolfkoenig]

letztes Jahr als neues Teil

Huch, die gibts noch neu?
Das Ding hat vor 10 Jahren schon als extrem veraltet (und ueberteuert) ausgeschaut, und war kaum aufzutreiben.

[CQuadrat]

Hier gibt es noch welche:
https://www.ersatzteilfachmann.de/Buderus/Buderus-Ersatzteile/5016590-Buderus-Modul-KM271-S00-Kommunikationsmodul--227916.html

[FosCo]

Mein Heizungsfachmann hat mir das Teil für 50€ inklusive Einbau im Rahmen der Wartung überlassen.

Das Testscript bekommt Daten am pi, nächster Analyseschritt ist dann Neuanlage des Moduls in FHEM, mal sehen.

edit: Nach dem Testscript kam auf einmal wieder der uralte Fehlerspeichereintrag als frisches Reading über die Schnittstelle, kurz gewartet, anschließend identisches Bild wie vorher

[FosCo]

So, nachdem ich jetzt in der config direkt per Webbrowser einige Zeilen rauskopieren wollte, um sie nachher ebenso einfach wieder rein zu kopieren, habe ich mal kurz fhem zerschossen (typo).
Anschließender Neustart -> alle readings kommen wie gewohnt 

Wunderheilung... Bestätigt aber irgendwie meine Theorie eines "verklemmten" Teilstreams durch einen fehlgeschlagenen Write

Baue mir morgen meine Alarme sinnvoller auf und hoffe, dass Telegram sich über den Haupt-FHEM-Pi dann bei erneutem Vorfall meldet...

Edit: Auch eine Stunde später kommen die Werte wie gewünscht und wie bereits Anfang des Jahres, was auch immer da durch welche Aktionen für ein "Propfen" gelöst wurde O_o