THZ Tecalor (LWZ Stiebel Eltron) Wärmepumpe -Optimierung und Erfahrungsaustausch

Begonnen von willybauss, 07 Februar 2015, 11:30:16

Vorheriges Thema - Nächstes Thema

TheTrumpeter

Ich habe mal eine ganz andere Frage, sorry wenn zu OffTopic...

Bisher habe ich die LWZ mittels einfachem RS232-HAT über die UART-Schnittstelle vom RasPi abgefragt, was problemlos lief/läuft. Auch über einen einfachen USB-Adapter lief/läuft es einwandfrei.

Ich habe mein System nun auf einen RasPi 4 umgezogen und wollte bei der Gelegenheit auch gleich einen billigen RS485-USB-Adapter, den ich für ein anderes Gerät benötige, durch etwas ordentliches ersetzen.

Dafür wollte ich den Waveshare RS485/RS232 HAT einsetzen (https://www.waveshare.com/rs485-rs232-hat.htm), der über SPI läuft. Alles andere, was ich gefunden habe, läuft immer über die UART-Schnittstelle, sodass ich nicht sowohl RS485 als auch RS232 verwenden könnte.
Aber egal was ich versuche, ich bekomme keine Kommunikation mit der LWZ. Vermutlich bin ich einfach zu blöd dafür. (RS485 bekomme ich auch nicht zum Laufen. Da blinkt zwar die "RX"-LED am HAT, sobald ich den Bus anschließe (die anderen Geräte quatschen permanent), aber auslesen klappt auch nicht.

Ich habe es über SPI1 versucht, der vom HAT direkt genutzt würde, aber auch mittels Aufbrechadapter SPI0 probiert. Ich erhalte immer
msg2 THZ_Get: Error msg2:  THZ_ReadAnswer: InterfaceNotRespondig. Maybe too slow THZ_Get_Com: error found at step0  -- 0B0005 ->
Mit SPI0 ist zumindest die CS-Warnung aus dmesg weg, aber sonst keine Änderung.

SPI1:
[   10.633323] sc16is7xx spi1.0: Native CS is not supported - please configure cs-gpio in device-tree
[   10.639406] spi1.0: ttySC0 at I/O 0x0 (irq = 185, base_baud = 921600) is a SC16IS752
[   10.644402] spi1.0: ttySC1 at I/O 0x1 (irq = 185, base_baud = 921600) is a SC16IS752

SPI0:
[    7.498702] spi0.0: ttySC0 at I/O 0x0 (irq = 185, base_baud = 921600) is a SC16IS752
[    7.499507] spi0.0: ttySC1 at I/O 0x1 (irq = 185, base_baud = 921600) is a SC16IS752

Ich hätte erwartet, dass ich in der THZ-Konfiguration einfach "/dev/ttySC1@115200" anstatt bisher "/dev/ttyAMA0@115200" setze und es läuft. Aber nein, Fehlanzeige.


Ich habe versucht zusätzlich zum dtoverlay für den Chip auch noch spi1_cs1 zu aktivieren, aber dann bekomme ich:
[    3.128818] spi spi1.0: chipselect 0 already in use
[    3.129898] spi_master spi1: spi_device register error /soc/spi@7e215080/sc16is752@0
[    3.135515] spi_master spi1: Failed to create SPI device for /soc/spi@7e215080/sc16is752@0



Hat irgendjemand Erfahrung damit?
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Eonwe

Hallo TheTrumpeter,

ich hab eventuell nen Ansatzpunkt. Ich muss aber vorneweg sagen, dass Hardwareprogrammierung nicht mein Spezialgebiet ist und viel meines Wissens auf die schnelle zusammengegoogelt wurde. Ich kann also auch fundamental daneben liegen.

Für mich sieht das ganz nach nem Timing Problem aus. Der Chip wird ja initialisiert und erkannt. Intern verfügt der Chip über einen FIFO-Stack, der empfangene Daten erst nach einer gewissen Länge oder einem Timeout weiterleitet.
Problem: Die Kommunikation mit der THZ ist mehrstufig und der Handshake hat nur 2 Bytes, wir laufen also jedes mal in den Timeout. Der ist für das THZ-Modul aber zu groß und es erscheint die Fehlermeldung.

Eigentlich müsste man die Byte-Länge des FIFO-Stacks reduzieren, ich hab aber keine Möglichkeit gefunden wie das auf die Schnelle gehen könnte.

Zum Testen könntest du das Attribut SimpleReadTimeout mal hochsetzen um zu sehen ob es was bringt. Default sind 0,8 Sekunden.


Ansonsten mal die Tests, die WaveShare zum Download anbietet, ausprobieren um zu sehen ob überhaupt ne Kommunikation mit der Anlage zustande kommt. Als Handshake schickt man 0x02 und müsste 0x10 zurückbekommen.

Phantas

Hallo Forum,
ich habe mal eine kleine Frage zum STB Schalter - klackt der IMMER, wenn man ihn drückt?
Oder nur, wenn er ausgelöst hat und man ihn wieder reindrückt?
Bei mir funktioniert der Heizstab nur sporadisch (oftmals braucht es mehrere Komplettresets der LWZ 403 Sol) und aktuell funktioniert es gar nicht mehr.
Boosterstage 2 oder 3 in Settings macht keinen Unterschied ob es funktioniert oder nicht, im Fehlerspeicher landet da komischerweise auch nichts.

Mir ist nur eben aufgefallen, dass der STB jedesmal klackt beim reindrücken (also während Strom komplett weg von der Anlage ist) und ich meine, früher hat der einmal geklackt und dann blieb er so und hat nicht mehr geklackt...

TheTrumpeter

Zitat von: Eonwe am 13 August 2025, 19:22:43Zum Testen könntest du das Attribut SimpleReadTimeout mal hochsetzen um zu sehen ob es was bringt. Default sind 0,8 Sekunden.
Hm...

Wirklich einen Einfluss scheint das nicht zu haben, bekomme nun aber in dmesg beim Versuch was zu lesen zumindest:

[  248.015397] sc16is7xx_handle_tx: 1 callbacks suppressed
[  248.015428] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64

Ansonsten kommt laufend die untere Meldung:
[  584.252071] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  584.764056] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  585.276060] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  585.788053] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  586.345983] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  594.751103] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  594.751148] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  595.352447] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  595.976072] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  596.540078] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  597.052082] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  597.564049] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  598.076067] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  598.588054] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64
[  599.100077] sc16is7xx spi0.0: chip reports 96 free bytes in TX fifo, but it only has 64

Wirklich reproduzierbar ist das aber nicht. Mal kommt diese "Callback"-Info, mal nicht. Ich habe jetzt jeden möglichen Attributwert probiert sowie auch ohne Attribut und dabei immer mehrere Male gelesen, insgesamt aber nur 7x die Meldung bekommen, mit der "FiFo"-Meldung ist das Log aber voll.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Eonwe

wie sieht denn die dtoverlay Konfiguration als solche genau aus? Die Fehlermeldung besagt, dass der Treiber mehr bytes bekommt als erwartet, da wird irgendwas falsch gelesen.

TheTrumpeter

Zitat von: Eonwe am 08 September 2025, 22:52:54wie sieht denn die dtoverlay Konfiguration als solche genau aus? Die Fehlermeldung besagt, dass der Treiber mehr bytes bekommt als erwartet, da wird irgendwas falsch gelesen.
Ich habe das Ding nicht mehr... aber letztendlich habe ich mich da an die Anleitung des Herstellers gehalten, d.h.
dtoverlay=sc16is752-spi1,int_pin=24Ich habe dann auch die Verkabelung auf SPI0 probiert & die Konfiguration entsprechend angepasst. Es ist schon eine Weile her, aber irgendwo habe ich die Details zu den dtoverlay-Konfigurationen gefunden und dann alle möglichen Parameter ausprobiert. Soweit ich mich erinnere, konnte man aber in der SPI0-Variante nur angeben wie viele CS es gibt und in der SPI1-Variante überhaupt nur den Interrupt-Pin.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

takoda

Hallo zusammen,

ich hab leider ein Problem mit der Anzeige der Lüftergeschwindigkeiten.

sFan zeigt folgende Werte an:
inputFanSpeed: 23 outputFanSpeed: 23 pFanstageXAirflowInlet: 120 pFanstageXAirflowOutlet: 120 inputFanPower: 236 outputFanPower: 236
sGlobal:
outsideTemp: 13.8 flowTemp: 25.2 returnTemp: 24.9 hotGasTemp: 25 dhwTemp: 44.7 flowTempHC2: -60 evaporatorTemp: 19.4 condenserTemp: 24.1 mixerOpen: 0 mixerClosed: 0 heatPipeValve: 0 diverterValve: 0 dhwPump: 0 heatingCircuitPump: 0 solarPump: 0 compressor: 0 boosterStage3: 0 boosterStage2: 0 boosterStage1: 0 highPressureSensor: 0 lowPressureSensor: 0 evaporatorIceMonitor: 0 signalAnode: 0 evuRelease: 1 ovenFireplace: 1 STB: 0 [b]outputVentilatorPower: 6533.6[/b] [b]inputVentilatorPower: 6533.6[/b] mainVentilatorPower: 0 outputVentilatorSpeed: 24 inputVentilatorSpeed: 23 mainVentilatorSpeed: 0 outside_tempFiltered: 13.7 relHumidity: 0 dewPoint: 0 P_Nd: 9.31 P_Hd: 10.6 actualPower_Qc: 0.000 actualPower_Pel: 0.000 collectorTemp: -60 insideTemp: -60 windowOpen: 0 quickAirVent: 0 flowRate: 0 p_HCw: 1.46 humidityAirOut: 42.21
Die Werte bei VentilatorPower (Input und Output) ergeben irgendwie keinen Sinn. Hat einer eine Idee?

Besten Dank im Voraus

willybauss

Ist sicher, dass Deine Anlage zur eingestellten Firmware Version passt? So richtig viele Infos hast Du uns ja nicht mitgegeben ...
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

takoda

Sorry, das war ein klassischer Anfängerfehler. 🙂
Bei mir läuft eine LWZ 304 Trend Wärmepumpe. Die Installation von FHEM habe ich in einem Docker-Container eingerichtet.

sFirmware version: 07.09
sFirmware-Id HW: 242 SW: 7.02 Date: AUG 10 2016 2025-09-22 17:24:32

Die beiden Lüfter wurden wg. Lagerschaden vor einiger Zeit getauscht, leider hatte der Techniker aber vergessen die Lüftereinstellungen in der Heizung anzupassen. Ich hatte die Einstellung Fachmann > Lüften > Lüfter auf 0 gestellt, laut Handbuch ist das so auch korrekt. Es wurden die Papst Lüfter verbaut, davor war die Einstellung auf 1.

willybauss

Da bin ich erst mal ratlos. Die Papst-Lüfter sind dieselben wie vorher?
Was mir auffällt: im Wiki wird für die 304 Trend die FW-Version 5.09 gelistet. Wurde bei der Reparatur auch ein Update eingespielt?
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

takoda

Schade ;D
Laut dem PDF von Stiebel Eltron ist die Version 5.09 für die 304 Trend, wenn die Anschlüsse der Platine seitlich sind, also noch ohne USB. Bei der Version mit dem USB vorne ist die 7.09 die aktuellste Version und das ist bei mir so.

Vorher waren die Xiangming Lüfter verbaut, aber wg. Teilemangel wurden dann jetzt wieder die Lüfter von Papst verbaut.

willybauss

Zitat von: takoda am 22 September 2025, 22:30:52Vorher waren die Xiangming Lüfter verbaut, aber wg. Teilemangel wurden dann jetzt wieder die Lüfter von Papst verbaut.
Ah ja, dann kann es natürlich sein, dass die Parameter anders sein müssen. Ob das übers Fachmannmenü einstellbar ist weiß ich nicht (=> Manual?). Evtl. hätte der Monteur da was umstellen müssen.

Mit etwas Glück meldet sich Jemand mit derselben Anlage zum eventuellen Abgleich der Settings.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS