Modul für Buderus Wärmepumpe WPS

[dankli]

Hallo Rolf,

erst einmal Entwarnung wegen der GT2_temp. Ich habe den RasPi nochmal neu gestartet - seitdem ist wieder alles ok und die Temperatur ist aktuell.
Die Version meiner Heizung ist: PROGRAM_VERSION=6; PROGRAM_REVISION=0.

Ich habe das aktuelle Modul nochmal gegen die Version V12 getauscht. Nach Robot des RasPis ist der Fehler E11.TT wieder aufgetreten und der Temperatursensor war wieder aktiv. D.h. es ist unabhängig von der KM273-Modulversion. Jetzt muss ich nur herausfinden, warum der Fehler früher nicht aufgetreten ist. Eigentlich ist alles fest an seinem Platz im Schaltschrank eingebaut und ich habe nichts geändert....

Das Aktualisieren des Moduls über update/shutdown restart sowie ein reines shutdown restart hat keinen Einfluss auf die Aktivierung des Raumfühlers. Eine Änderung auf "DoNotPoll=1" hat auch keinen Einfluss. Es hängt eindeutig mit dem Neustart des RasPis zusammen.
Ich werde nochmal die Terminierung überprüfen. Ggf. muss ich mir mal Gedanken über ein CAN-Trace während des Neustarts machen.

Ich werde es mir am Wochenende oder in der nächsten Woche mal in Ruhe anschauen.

Gruß, Daniel

[mike3436]

zum E11.TT.GT5 Raumtermeraturfühler:
Bei mir werden die folgenden zwei Werte in den Readings angezeigt:
GT5_ANSLUTEN 0
GT5_TEMP DEAD
Wechselt bei euch GT5_ANSLUTEN auf 1, wenn der raspi neugestartet wird?
Eventuell hilft der Parameter GT5_KVITTERAD (einzige boolche GT5 Variable, die beschreibbar ist, erkennbar am Maxwert 16777216, und kvittera bedeutet Bestätigen/Quittieren)
Zum Test mal GT5_KVITTERAD in der %KM273_gets Tabelle einfügen, und nach RasPi Neustart mal GT5_KVITTERAD=1 (oder GT5_KVITTERAD=0) setzen.

Was macht ihr denn, um den Fehler zu beheben? Wie wir der Fehler quittiert, bzw. wie wird in der Installationsebene der Sensor deaktiviert.
Bei mir tritt der Fehler nicht auf, ich habe auch mal einen Reset des RasPi2 gemacht, und alles läuft normal weiter.

Zur Programmversion:
Ich habe eine WP Baujahr 2013:
PROGRAM_GENERATION 3
PROGRAM_VERSION 1
PROGRAM_REVISION 0
Wie alt/neu ist denn deine WP mit PROGRAM_VERSION=6?

[wladi12]

WPS10-1, Baujahr 2012, Programmversion 3.1.0

[mike3436]

Hallo Wladi,
hast du den Test mit dem Raspi2 mal gemacht? Läuft die Kommunikation damit störungsfrei?
Gruß Rolf

[wladi12]

Hallo Rolf,

ja - die Kommunikation läuft störungsfrei mit Raspi2 und auch 3; mit beiden USBTin-Boards.
Es war keine GND- oder Verdrahtungssache.

Daniel hatte absolut recht: Beim Raspi Shutdown mit angeschlossenem USBTin denkt die WP, das ein Raumfühler angeschlossen ist (T5) und gibt diese CAN-Störmeldungen. Warum dies geschieht, weiß ich nicht.
"Abhilfe" ist wirklich in der Installateur-Ebene den "Raumfühler" wieder auf "nein" zu setzen. Schon läufts. ...

Frage:
Kann man hier nicht eine fhem-Routine einbauen, die bei jedem Raspi-Shutdown mit Neustart den Raumfühler zwingend auf "Nein" setzt?
Das wäre einfacher, als immer an die WP zu laufen - schon in Fragen der "Fernbedienbarkeit" ....

[mike3436]

Hallo Wladi,

Kann man hier nicht eine fhem-Routine einbauen, die bei jedem Raspi-Shutdown mit Neustart den Raumfühler zwingend auf "Nein" setzt?

Ich kann die wahrscheinlich notwendigen Parameter mal in die Liste aufnehmen, und dann kannst du das erst mal manuell probieren.
Wenn das dann funktioniert, werde ich dann als parametrierbare Startup Funktion implementieren.

Ich habe aktuell eine Shutdown Funktion implementiert, die beim herunterfahren den CAN-Bus am USBTin schiesst, und vielleicht hat sich dann damit das Problem erledigt.
Wie schon geschrieben, kann ich das Problem mit meinem Raspi nicht nachvollziehen (mein Wheezy-Image ist relativ alt, und wurde immer nur über apd-get update/upgrade  für Raspi2 und Raspi3 upgedatet).

Aufgrund mehrerer anderer Erweiterungen, die ich noch testen muss, kann ich das Modul erst am Wochenende veröffentlichen.

[mike3436]

Hallo Wladi,
hier mal eine Testversion des Moduls mit mehreren Erweiterungen:

• CAN-Schnittstelle wird bei Shutdown geschlossen
• Über Attribut AddToReadings können jetzt weitere Readings hinzugefügt werden, ohne in der Tabelle im Modul ein read=1 setzen zu müssen
• Über Attribut AddToGetSet können jetzt weitere Get/Set Parameter hinzugefügt werden (diese werden auch automatisch zu Readings hinzugefügt)

Aktuell werden diese Attributänderungen noch nicht online verarbeitet, d.h. ein config save und shutdown restart ist notwendig.

Beispiel zur Parametererweiterung:
attr myKM273 AddToReadings GT3_STATUS GT3_KVITTERAD GT5_STATUS GT5_ANSLUTEN
attr myKM273 AddToGetSet ACCESS_LEVEL GT3_KORRIGERING GT5_KVITTERAD

GT3 und GT5 werden wohl äquivalent behandelt, bei mir steht:
GT3_STATUS=1
GT3_ANSLUTEN=1
GT3_KVITTERAD=1
GT5_STATUS=0
GT5_ANSLUTEN=0
GT5_KVITTERAD=0
Ich erwarte, dass bei deinem und Daniels Problem GT5_KVITTERAD=1 steht.
Ich konnte dann aber z.B. den ACCESS_LEVEL nicht auf 1 setzen um GT5_KVITTERAD=0 zu setzen.
Wenn ich aber den Installateurmode in der WP aktiviere, dann wechselt ACCESS_LEVEL von 0 auf 1.

Gruß Rolf

[mike3436]

Hallo, ich habe nochmal etwas ausprobiert:
Wenn ich set myKM273 GT5_KVITTERAD 1 ausführe, dann fängt die WP an zu piepsen und meldet Fehler E11.TT.
Wenn ich dann set myKM273 GT5_KVITTERAD 0 ausführe, dann verschwindet der Fehler E11.TT wieder.
Ein vorheriges set myKM273 ACCESS_LEVEL 1 habe ich gemacht, aber die Rückmeldung bleibt ACCESS_LEVEL=0.
Der Installateurmodus ist über CAN-Bus wohl nicht erforderlich, um die Parameter zu verändern, also ist hier generell beim Spielen vorsicht angesagt 

Nebenbei: wenn ich GT3_KVITTERAD=0 setze, dann setzt die Warmwasserbereitung ohne Fehlermeldung aus, bis wieder  GT3_KVITTERAD=1 gesetzt wird.

Basis ist natürlich die Version Version 0015 mit Attribut AddToGetSet ... ACCESS_LEVEL GT5_KVITTERAD ...
oder ein selbst abgewandeltes Modul mit GT5_KVITTERAD in KM273_gets Tabelle.
Gruß Rolf

[mike3436]

Modul V0015 getestet eingechecked

Edit:
noch einen Fehler gefunden:
Eingabe per Slider geht nicht (per set Befehl aber schon)
Behebe ich morgen ...

Der Fehler mit der (neuen) Slider-Eingabe trat bei mir am Montag auf, konnte ihn aber heute nicht mehr nachvollziehen.
Ich habe aber sowohl am Montag als auch heute ein Update durchgeführt.
Gruß Rolf

[mike3436]

Hallo,
hat schon jemand das aktuelle Modul ausprobiert?
Gibt es hier neue Erkenntnisse bei euch bezüglich der Probleme beim Raspi Reset?

[wladi12]

Hallo Rolf,

habe das neue Modul per update installiert, läuft bei mir bis dato ohne Fehler - hatte aber bis jetzt auch noch keinen CAN-Busabsturz bzw. diesen
Raumtemperaturfühler-Fehler mehr. ....
Das Modul läuft und macht, was es soll. ... Danke!

Wladi

[dankli]

Hallo Rolf,

erst einmal sorry, dass ich in den letzten Wochen nicht geantwortet habe - aber im Garten ist im Moment mehr Aktion angesagt als im Haus.... Jetzt im Urlaub hatte bzw. habe ich mal wieder Zeit ein wenig zu gucken.

Meine Wärmepumpe ist von 2016. Programmversion 3.6.0 (PROGRAM_REVISION 0, PROGRAM_VERSION 6 lt. Modul KM273).

Der Fehler mit GT5 ist immer noch (V0015) nach Neustart aktiv. Es dauert immer einige Zeit nach Neustart (max. 5 min), bis die Wärmepumpe piepst und einen Fehler meldet. Eine Änderung des Wertes GT5_KVITTERAD auf 0 schaltet nicht das Piepsen aus. Dieses bestätige ich zur Zeit manuell an der Wärmepumpe. Es gibt aber auch noch andere Fehler, die mittlerweile (nur bei Neustart und gelegentlich) auftreten:

- Anschluß an Raumfühler E11.TT kontrollieren (der bekannte Fehler - tritt immer auf - auch mit Modul V0015)
- Anschluß an I/O-Karte AHB kontrollieren (ist vorher gelegentlich schon mal aufgetreten)
- Anschluß an I/O-Karte XB2 sekundärer Kühlkreislauf kontrollieren (dieser ist ganz neu)

Nach Neustart des Raspberries dauert es einige Zeit, bis die Verbindung über CAN sauber aufgebaut wurde und es gibt einige KM273 Heizung DISCONNECTED/CONNECTED im schnellen Abstand. Lt. Log sieht es aus, als wenn teilweise Werte ausgelesen werden, dann aber die Verbindung zusammenbricht. Nach einigen Versuchen (Schätzung 5-10) baut sich die Verbindung dann sauber auf und die Werte lassen sich lesen. Der bzw. die Fehler treten übrigens erst Nach dem Start von FHEM auf und nicht beim Shutdown....

In den Messwerten, welche von der Wärmepumpe ausgelesen werden, habe ich 103 Messwerte, welche keine Variablenname haben sondern hexadezimal aussehen (z.B.: 0001C180, 0003C270,...) - Hast Du das auch?

Des Weiteren habe ich nochmal die CAN-Verkabelung sowie Terminierung überprüft. Alles liegt im Soll-Bereich.

Solange der Raspi nicht neugestartet wird, funktioniert alles.

Vielleicht schaffen wir es ja hier eine Lösung zu erarbeiten. Ggf. hat Buderus ja auch das CAN-Protokoll etwas geändert....

Gruß und Dank für Deine Hilfe und vor allem nochmals für das Modul.

Daniel

[mike3436]

Hallo Daniel,

zur Analyse benötige ich ein FHEM-Logfile.
Dazu im myKM273 Attribut verbose 5 setzen.
FHEM herunterfahren, aktuelles fhem-2017-08.log sichern und löschen, und am besten neue FHEM.cfg nur mit KM273 Modul anlegen.
Raspi neu starten und hoffen dass der Fehler auftritt 

In den Messwerten, welche von der Wärmepumpe ausgelesen werden, habe ich 103 Messwerte, welche keine Variablenname haben sondern hexadezimal aussehen (z.B.: 0001C180, 0003C270,...) - Hast Du das auch?

Das sind die CAN-Kommunikationen zwischen den Modulen der Heizung. Manche sind Zustandswerte, die interessant sind, manche sind Analogwerte von Fühlern, die aber noch linearisiert werden müssen. Die CAN-Id's sind aber von je nach Heizung unterschiedlich.

[mike3436]

Hallo Daniel,

vielen dank für die beiden Logfiles

ich glaube "verbose  5" belastet den Rechner zu sehr, und deswegen bekommt er nicht alles mit.
Der Emfang der Parameter-Tabelle bricht nach 2504 von 76279 Bytes ab.

Code Auswählen Erweitern

KM273_ReadElementList readCounter 76279 changed to 2504
Da das bei älteren Systemen aber ein Softwarebug war, gebe ich mich irgendwann mit den emfangenen Daten zufrieden (System meldet z.B. 60010 Bytes verfügbar, liefert aber z.B. immer nur 60000).

Bei V12 wird die Tabelle noch wohl noch mit "verbose 3" gelesen - wann das Attribut in FHEM wirksam gesetzt wird, weis ich nicht genau.

Code Auswählen Erweitern

KM273_ReadElementList done, readCounter=76279 readIndex=76279

Kannst du V15 nochmal mit verbose 3 loggen.

Die Usache könnte aber auch schon lokalisiert sein - ist aber nur eine Vermutung:

Code Auswählen Erweitern

2017.08.11 22:02:36 1: usb create starting
2017.08.11 22:02:37 3: Probing CUL device /dev/ttyACM0
2017.08.11 22:02:38 3: Probing TCM_ESP3 device /dev/ttyACM0
2017.08.11 22:02:38 3: Probing ZWDongle device /dev/ttyACM0
2017.08.11 22:02:38 3: Probing FRM device /dev/ttyACM0
2017.08.11 22:11:10 3: Probing CUL device /dev/ttyAMA0
2017.08.11 22:11:10 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2017.08.11 22:11:10 1: usb create end

Hier wird das ttyACM0, auf dem auch der CAN-Bus Dongle läuft, für verschiedene Dongles durchprobiert.
Was da an Daten rausgeht, weis ich nicht.
Vielleicht bekommt man bzw. du  das raus, wenn in der fhe.cfg das globale verbose 5 mal testweise gesetzt wird.
Auf jeden Fall aber das verbose von myKM273 auf 3 setzen!

Was aber auch neu ist, und mir diese Woche erstmalig aufgefallen ist, sind die regelmässigen Aufrufe der KM273_Ready während des Lesens der Tabelle.
Das nachfolgende CAN_Init wird aufgerufen, wenn STATE = 'disconnected'.

Code Auswählen Erweitern

2017.08.11 23:25:10 3: myKM273: KM273_ReadElementList send T01FD3FE080000100000002000
2017.08.11 23:25:10 3: myKM273: KM273_ReadElementList send R01FDBFE00
2017.08.11 23:25:10 3: myKM273: KM273_ReadElementList entry readCounter=76279 readIndex=8192
2017.08.11 23:25:11 1: /dev/ttyACM0 disconnected, waiting to reappear (myKM273)
2017.08.11 23:25:11 3: myKM273: KM273_Ready
2017.08.11 23:25:11 3: myKM273: KM273_Ready
2017.08.11 23:25:11 3: Setting myKM273 serial parameters to 115200,8,N,1
2017.08.11 23:25:11 3: myKM273: CAN_DoInit
2017.08.11 23:25:11 1: /dev/ttyACM0 reappeared (myKM273)
2017.08.11 23:25:11 3: myKM273: KM273_ReadElementList entry readCounter=76279 readIndex=12288
2017.08.11 23:25:11 3: myKM273: KM273_ReadElementList send T01FD3FE080000100000003000
2017.08.11 23:25:11 3: myKM273: KM273_ReadElementList send R01FDBFE00
2017.08.11 23:25:11 3: myKM273: KM273_ReadElementList entry readCounter=76279 readIndex=12288
2017.08.11 23:25:12 1: /dev/ttyACM0 disconnected, waiting to reappear (myKM273)
2017.08.11 23:25:12 3: myKM273: KM273_Ready
2017.08.11 23:25:12 3: myKM273: KM273_Ready
2017.08.11 23:25:12 3: Setting myKM273 serial parameters to 115200,8,N,1
2017.08.11 23:25:12 3: myKM273: CAN_DoInit
2017.08.11 23:25:12 1: /dev/ttyACM0 reappeared (myKM273)
2017.08.11 23:25:12 3: myKM273: KM273_ReadElementList entry readCounter=76279 readIndex=16384

Hier ist ggf. an dem FHEM Basismodul DevIo etwas verändert worden?

Edit:
Oder mein USBtin hat auch einen Fehler ... wohl eher nicht ...
Ich habe die letzte Version (13833, 28.03.2017) von DevIo.pm restauriert, und die Disconnects sind weg!

Ich habe auch mal die bei mir auskommentierte Zeile aktiviert

Code Auswählen Erweitern

define initialUsbCheck notify global:INITIALIZED usb create
Aber keine Probleme bzw. andere Meldungen:

Code Auswählen Erweitern

2017.08.12 23:32:37 1: usb create starting
2017.08.12 23:32:37 3: Probing CUL device /dev/ttyAMA0
2017.08.12 23:32:37 3: Can't open /dev/ttyAMA0: Permission denied
2017.08.12 23:32:37 1: usb create end

Aber die Zeile

Code Auswählen Erweitern

define myKM273 KM273 /dev/ttyACM0@115200
kommt direkt danach, und führt aber im Ablauf dazu, dass trotzden die KM273 Initilisierung von der USB detektierung erfolgt!

Code Auswählen Erweitern

2017.08.12 23:32:36 3: myKM273: KM273_ClearElementLists
2017.08.12 23:32:36 3: Opening myKM273 device /dev/ttyACM0
2017.08.12 23:32:36 3: Setting myKM273 serial parameters to 115200,8,N,1
2017.08.12 23:32:36 3: myKM273: CAN_DoInit
2017.08.12 23:32:36 3: myKM273 device opened
2017.08.12 23:32:36 3: myKM273: KM273_Attr AddToGetSet GT3_KVITTERAD GT5_KVITTERAD DHW_GT3_STOP_TEMP
2017.08.12 23:32:36 3: myKM273: KM273_Attr ReadElementListElements not ready for verify attribute
2017.08.12 23:32:36 3: myKM273: KM273_Attr AddToReadings GT5_STATUS GT3_STATUS GT._ANSLUTEN DATE_.* .*ANODE.*
2017.08.12 23:32:36 3: myKM273: KM273_Attr ReadElementListElements not ready for verify attribute
2017.08.12 23:32:37 1: Including /mnt/fhem/log2/fhem.save
2017.08.12 23:32:37 1: usb create starting
2017.08.12 23:32:37 3: Probing CUL device /dev/ttyAMA0
2017.08.12 23:32:37 3: Can't open /dev/ttyAMA0: Permission denied
2017.08.12 23:32:37 1: usb create end
2017.08.12 23:32:37 3: myKM273: KM273_Notify INITIALIZED


[sido]

Hallo Mike,
ich habe gerade mal dein Modul probiert. Ich habe eine ganz neue Junkers WP, die STM 120-2. Hat auch CAN-BUS. Ich bekomme im Log nach "define myKM273 KM273 /dev/ttyACM0@115200" aber folgende Meldungen:

2017.12.31 15:40:29 3: myKM273: KM273_ClearElementLists
2017.12.31 15:40:29 3: Opening myKM273 device /dev/ttyACM0
2017.12.31 15:40:29 3: Setting myKM273 serial parameters to 115200,8,N,1
2017.12.31 15:40:29 3: myKM273: CAN_DoInit
2017.12.31 15:40:29 3: myKM273 device opened
2017.12.31 15:40:29 3: myKM273: KM273_Notify DEFINED myKM273
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList entry readCounter=0 readIndex=0
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList send R01FD7FE00
2017.12.31 15:40:29 3: myKM273: CAN_Read unknown data ''
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList entry readCounter=0 readIndex=0
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList KM200active=0 KM200wait=19 readIndex=0
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList entry readCounter=0 readIndex=0
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList KM200active=0 KM200wait=18 readIndex=0
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList entry readCounter=0 readIndex=0
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList KM200active=0 KM200wait=17 readIndex=0
2017.12.31 15:40:29 3: myKM273: KM273_ReadElementList entry readCounter=0 readIndex=0

Was kann das bedeuten? Ich habe das USB-Tin selbst gelötet, aber das sollte doch kein Problem sein. Kann ich es vielleicht noch weiter auf Low-Level testen?

Wäre für jede Hilfe dankbar!

Gruß,
Sido