Modul für Buderus Wärmepumpe WPS

mike3436 · 11 Mai 2017, 19:14:17

Das Image solle auf allen Raspi's laufen, aber ich würde auf jeden Fall ein Backup machen und auf eine andere SD duplizieren.
PollingIndex 178 bedeutet, dass 178 Werte im letzten Datenzyklus (normalerweise alle 60s) gepollt wurden, und der Wert stimmt mit meiner Variablenanzahl überein.
Micht interessiert der Wert beim CAN-Fehler, bzw. ob dann vielleicht sogar STATE<>opened.

wladi12 · 11 Mai 2017, 20:10:03

Beim CAN-Fehler ist der Wert 178 (d.h. Modul ist "eingefrohren"), auch der State ist weiter "opened".

mike3436 · 11 Mai 2017, 23:37:42

Ja, ist korrekt, ich habe das gerade bei mir mal ausprobiert: Modul CAN-seitig abgezogen, und pollingIndex bleibt 178, auch beim manuellen Seitenrefresh (notwendig zur Aktualisierung!).
Der Indexzähler wird auch ohne CAN-Antwort auf den Maxwert hochgezählt - war anders als ich dachte.
Läuft denn der CAN-Bus wieder störungfrei nach "shutdown restart" in FHEM oder muss der USBTin vorher vom USB abgezogen werden?

wladi12 · 12 Mai 2017, 05:22:46

.... USBTin muss abgezogen werden.

mike3436 · 13 Mai 2017, 22:13:25

... ich warte mal deine Tests mit dem Raspi 2B ab

wladi12 · 15 Mai 2017, 20:23:18

Hallo Rolf,

ich bin beim testen - dauert aber noch...

Mal eine Frage zu den USB-Ports:
Ich habe (nach neuem Netzteil) zusätzlich die Strombegrenzung der USB-Ports von 600mA mit "Usb_Current_Max=1" hochgesetzt, müsste für jeelink und USBTin reichen, aber:
1.Frage:
Laut"# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
attr initialUsbCheck disable 1" müsste die Automatische Erkennung ausgeschalten sein. Oder?

2.Frage: der Jeelink hat laut
"define myJeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NTJ4-if00-port0@57600" Port 0" - wie auch der
USB Tin laut "define myKM273 KM273 /dev/ttyACM0@115200" BEIDE Port 0 (zwar mit unterschiedlichen Baudraten, aber immerhin).

Kann das der Fehler sein ? ...

der_da · 15 Mai 2017, 20:31:09

Bin zwar nicht Rolf, aber ...

Zitat von: wladi12 am 15 Mai 2017, 20:23:18
1.Frage:
Laut"# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
attr initialUsbCheck disable 1" müsste die Automatische Erkennung ausgeschalten sein. Oder?

Ich sage mal JA, die Automatische Erkennung ist bei dir AUS.

Zitat von: wladi12 am 15 Mai 2017, 20:23:18
2.Frage: der Jeelink hat laut
"define myJeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NTJ4-if00-port0@57600" Port 0" - wie auch der
USB Tin laut "define myKM273 KM273 /dev/ttyACM0@115200" BEIDE Port 0 (zwar mit unterschiedlichen Baudraten, aber immerhin).

Bei mir ist der JeeLink auf /dev/ttyUSB0@57600 eingebunden, und mein myKM273 auf /dev/ttyACM0@115200.
Ob das bei dir der Fehler ist, vermag ich allerdings nicht zu beurteilen.

wladi12 · 15 Mai 2017, 20:59:58

OK, Danke - dann schalte ich mal die automat.Erkennung wieder ein.

Zwischenstand bis dato:
1.Netzteil getauscht (alt: 2A, neu 3A) - Fehler unverändert
2.USB Ports auf max - (wg. Jeelink UND USBTin) Fehler unverändert, danach
3.GPIO und Jeelink abgezogen - Fehler kam nach 2 Stunden (also später, bei mir sind alle Baugruppen in einer PVC-Dose an der Wand), war aber derselbe
4. USBTin getauscht (habe Ersatz von Th.Fischl erhalten - Danke nochmal!) , hat aber auch nicht funktioniert, wieder Fehler ...
5 KM200 ist völlig egal (ob mit oder ohne - keine Beeinflussung).

Bleibt nur noch Raspi tauschen, danach gebe ich auf. $:-\$

mike3436 · 15 Mai 2017, 23:37:20

Hallo Wladi,
die Fragen mit dem Strom und initialUsbCheck kann ich dir auch nicht beantworten - ich habe es in beiden fhem.cfg's auskommentiert.
# define initialUsbCheck notify global:INITIALIZED usb create

Die Parametrierung vonn JeeLink (Raspi1) und USBTin Raspi2) habe ich genauso wie der_da
define myJeeLink JeeLink /dev/ttyUSB0@57600
define myKM273 KM273 /dev/ttyACM0@115200

Wenn du den Fehler beim JeeLink vermutest, und den abziehst, dann aber auch in FHEM deaktivieren!
Ich würde das Image duplizieren, auf dem 2.Raspi laufen lassen, in der fhem.cfg nur den KM273 drin lassen, und damit testen.

Generell gehe ich auch nicht mehr von einem wirklichen CAN-Bus-Fehler aus, sondern eher, dass der USBTin durch irgendwas auf die falsche Baudrate programmiert wird, und dann den Bus regelmässig alle 60s stört, wenn die Parameter ausgelesen werden. Wenn du DoNotPoll=1 setzt, dann sollte das Modul nach der Initialisierung nichts mehr abfragen, sondern nur noch empfangene Werte updaten - ein einfacher Test um meine Theorie zu untermauern. Und wenn der Fehler auftritt, und du dann FHEM runterfährst (nicht neu startest), ist der Fehler dann weg?

Gruß Rolf

wladi12 · 16 Mai 2017, 18:57:04

USB und Jeelink laut Euren Einstellungen:
define myJeeLink JeeLink /dev/ttyUSB0@57600
define myKM273 KM273 /dev/ttyACM0@115200

Jeelink deaktiviert u. abgezogen, ebenso GPIO.
Es läuft nur KM273 mit USBTin.

Fehler trat wieder auf, auch bei DoNotPoll=1.
Beenden von fhem ändert nichts - Fehler bleibt.
Auch ein reeboot ändert nichts.
Also Ist Dein Modul KM273 i.O.
USBTin getauscht, das gleiche. ...

Ich werde am Wochenende den Raspi tauschen, dann hab ich keine Idee mehr

dankli · 17 Mai 2017, 21:14:42

Hallo Zusammen,

erst einmal vielen Dank an mike3436 für das Modul KM273. Ich bin sehr begeistert wie gut es (eigentlich) läuft.

Bei mir läuft ein RasPi mit USBtin. Die Anbindung des USBtins an die Heizung (Buderus WPS) ist über ein ca. 8m langes gedrilltes und geschirmtes Kabel angeschlossen. Der Abschlusswiderstand in der Heizung ist deaktiviert und der korrekte Widerstand am USBtin angelötet. Das System läuft seit 6. November 2016 stabil.
Anfang März ist zum ersten Mal aufgefallen, dass die Heizung einen Fehler (E11.TT) gemeldet hat. Dieser Fehler war aber vorher nicht existent bzw. der Temperatursensor ist nicht verbaut. Über das Installationsmenü lässt er sich deaktivieren - danach meldet die Heizung keinen Fehler mehr.
Jetzt ist klar, dass ein Reboot des RasPis dazu führt, dass der Sensor wieder aktiv geschaltet wird. Es ist dann wieder ein Eingriff in die Installationsebene notwendig, den Temperaturfühler zu deaktivieren.
Zusätzlich ist mir heute aufgefallen, dass die GT2_Temp falsch ausgelesen wird. Die Heizung zeigt 23°C an, FHEM aber nur ca. 17°C.

Jetzt meine Frage: Wurde Ende Februar/Anfang März etwas geändert? Ich kann gerne beim Debuggen unterstützen!

Auf jeden Fall schon nochmal ein großes Lob für das Modul!

Daniel

mike3436 · 17 Mai 2017, 23:03:06

Hallo Daniel,

Bei mir wird GT2_TEMP mit 23.3°C korrekt angezeigt (entspricht dem im KM200 angezeigten Wert für Aussentemperatur).
Ändert sich denn die Zeit des Readings?

Im Programm hat sich nicht viel verändert - eine Änderungshistorie steht im Kopf:
# 0013 07.01.2017 mike3436 KM273_gets HOLIDAY params added for get/set, cyclic read for some alarms and requests activated in KM273_elements_default
# 0014 22.03.2017 mike3436 KM273_getsAdd add variables for 2nd heating circuit if Attribut HeatCircuit2Active is set to 1

Die wesentliche Erweiterung in V0013 war das zusätzliche Lesen von anstehenden Alarmen und Request.
Ich habe dir die Version V0012 vom 21.08.2016 zum Test in den 1. Beitrag eingefügt.

Ansonsten vielleit noch interessant zum Vergleich: Programmversion (Readings PROGRAM_xxx) deiner WP

Gruß Rolf

wladi12 · 18 Mai 2017, 05:52:14

Ergänzung:
Mir ist aufgefallen, das je nachdem wo der CAN-Bus an der PEL angeschlossen ist
bei den Klemmen 32-34 (Fehler: E11.TT) und 36-38 (Fehler: E12.TT), also verschiedene Heizkreise angezeigt werden.

Noch eine Frage:
Lässt sich vielleicht im Modul eine Routine einbauen, die die (nicht vorhandenen) Raumfühler E11.TT bzw. T12.TT in beiden Kreisen dauerhaft rücksetzt,
damit dies nicht über die Installateurebene an der WP notwendig ist?

Das "DoNOtPoll=1" scheint ja nach dem Rsetart des Pi wieder aufgehoben, oder?

Ich bin im Programmieren zu laienhaft, um sowas zu entwickeln - aber vielleicht wäre damit dieser Fehler (der scheinbar auch Andere betrifft) gefixt.

mike3436 · 18 Mai 2017, 12:22:05

ZitatDas "DoNOtPoll=1" scheint ja nach dem Rsetart des Pi wieder aufgehoben, oder?

Nein, wird nicht aufgehoben (ist ja ein ATTRIBUT, dass mit in der fhem.cfg gespeichert wird)

Wenn DoNotPoll=1 gesetzt ist, und der Fehler E11.TT tritt trotzdem auf, dann habe ich erstmal keinen Ansatz zur Lösung der Problematik.
Dann wird beim Start nur die Parameterliste abgefragt. Befehle auf den CAN-Bus passieren danach nur über Get und Set.
Alles andere, was dann noch in den Readings auftaucht, kommt von der WP direkt bzw. indirekt über ein parallel angeschlossenes KM200.

Aber so kann man ggf. die Ursache erst mal einkreisen ...

wladi12 · 18 Mai 2017, 20:42:28

Hallo,

Daniel hat recht - ist bei mir identisch: "... ein Reboot des RasPis dazu führt, dass der Sensor wieder aktiv geschaltet wird. Es ist dann wieder ein Eingriff in die Installationsebene notwendig, den Temperaturfühler zu deaktivieren." Ein Werksreset ist nicht notwendig.
Ist auch kein Unterschied zw. Raspi 2 und 3.

Kann man das abfangen, indem z.B. vor einem Reboot das Modul von der Kommunikation getrennt wird?