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

[hellijo]

Hi Immi,

thanks. First i have to learn, how to change the .pm file.
If i know howto, you will get a report, which version works.

BR Jörg

[willybauss]

nach /opt/fhem/FHEM navigieren, dort die Datei 00_THZ.pm suchen und gegen eine andere austauschen, dann Restart, zumindest des THZ-Moduls.

Der Dateiname muss immer gleich bleiben, der Inhalt muss die Version widerspiegeln.

[hellijo]

Danke funzt.

Die 0.198 wirft auch Fehler. Schau mir morgen die 0.196 an.

[willybauss]

...
And sometimes:

2022.05.21 21:22:54 3: THZ_Get: Error msg2:  THZ_ReadAnswer: InterfaceNotRespondig. Maybe too slow THZ_Get_Com: error found at step1  -- 08 ->

Klingt nach schlechter (oder zu langer) Kabelverbindung zur THZ. Da kann die Firmware-Version nichts dafür.

[LeJoke]

And in the log i get this messages:

2022.05.21 21:19:38 3: Mythz/RAW: 0202020202020202020202020202020202020202020202020202 -  -

And sometimes:

2022.05.21 21:22:54 3: THZ_Get: Error msg2:  THZ_ReadAnswer: InterfaceNotRespondig. Maybe too slow THZ_Get_Com: error found at step1  -- 08 ->

VG Jörg

PS: How can I change to release 0.196?

Hatte mal ähnliche Probleme mit unsiningen / zu vielen / übrig gebliebenen Zeichen im buffer -insbesondre bei readings die viele Daten zurück liefern- als ich von Fritz 7170 auf raspi 4 gewechselt bin.
immi hat im code darauf hin einen Zähler hochgesetzt ("#increased to 120 for LeJoke his raspi4  ...") seitdem funktioniert es wieder.
Da du wohl von raspi auf Nuc gewechselt hast ggf. was ähnliches ? Sieht fast so aus, als ob Du Dein buffer mit "02" STX ohne weitere Nachricht vollläuft ?

[hellijo]

Hatte mal ähnliche Probleme mit unsiningen / zu vielen / übrig gebliebenen Zeichen im buffer -insbesondre bei readings die viele Daten zurück liefern- als ich von Fritz 7170 auf raspi 4 gewechselt bin.
immi hat im code darauf hin einen Zähler hochgesetzt ("#increased to 120 for LeJoke his raspi4  ...") seitdem funktioniert es wieder.
Da du wohl von raspi auf Nuc gewechselt hast ggf. was ähnliches ? Sieht fast so aus, als ob Du Dein buffer mit "02" STX ohne weitere Nachricht vollläuft ?

Puuh gute Frage. Kann sein.
Mit dem Raspi hatte ich die Meldung nich.
Habe aber auch ein paar Readings mit unplausiblen Werten.
z.B.
pExpert        760201001D3124
sControl       2CF2050500000000000010001D010100000000
sHC1           outsideTemp: 20.3 x08: FDBF returnTemp: 25 integralHeat: 0 flowTemp: 25.5 heatSetTemp: 19.5 heatTemp: 25.1 seasonMode: summer integralSwitch: 200 hcOpMode: normal roomSetTemp: 21 x60: 0 x64: D200 insideTempRC: 0 x72: 0000 x76: F800 onHysteresisNo: 0 offHysteresisNo: 1 hcBoosterStage: 0

[LeJoke]

Puuh gute Frage. Kann sein.
Mit dem Raspi hatte ich die Meldung nich.
Habe aber auch ein paar Readings mit unplausiblen Werten.
z.B.
pExpert        760201001D3124
sControl       2CF2050500000000000010001D010100000000
sHC1           outsideTemp: 20.3 x08: FDBF returnTemp: 25 integralHeat: 0 flowTemp: 25.5 heatSetTemp: 19.5 heatTemp: 25.1 seasonMode: summer integralSwitch: 200 hcOpMode: normal roomSetTemp: 21 x60: 0 x64: D200 insideTempRC: 0 x72: 0000 x76: F800 onHysteresisNo: 0 offHysteresisNo: 1 hcBoosterStage: 0

die readings oben sollten aus folgenden code Bereich stammen (Version auf 2.14 eingestellt):

my %getsonly214 = (
...,
  "pExpert"             => {cmd2=>"02", type =>"02pxx206", unit =>""},
  "sControl"           => {cmd2=>"F2", type =>"F2type", unit =>""},
  "sHC1"             => {cmd2=>"F4", type =>"F4hc1214",    unit =>""}, ...

Für "02pxx206" & "F2type"hab ich so auf Anhieb keine parsinghashs im code gefunden, was erklärt warum Du da die raw Werte hast. "F4hc1214" hat an den Stellen, die Du rot markiert hast noch "raw" stehen.
Der code sieht aber bereits in der 0.193 so aus, so dass Du das schon vorher hättest haben sollen / hattest ...

Hab noch mal etwas weiter zurück gelesen. Prinzipiell funktioniert fhem auf dem NUC, nur ein paar Einzelwerte fehlen / sind falsch?

Hast Du konkrete vorher / nachher Beispiele der readings die jetzt anders sind?

[hellijo]

Klingt nach schlechter (oder zu langer) Kabelverbindung zur THZ. Da kann die Firmware-Version nichts dafür.

Hi Willy,

du hattest Recht. Der Stecker auf der Leiste X18 mit dem Buchsenstecker für RS232 war nicht richtig gesteckt und hat gewackelt. Festgestellt, da ich heute früh gar kein Verbindung mehr hatte.
Jetzt mal weiter schauen und hoffen, dass im Normbetrieb keine häufigen Verbindungsfehler kommen.

die readings oben sollten aus folgenden code Bereich stammen (Version auf 2.14 eingestellt):

my %getsonly214 = (
...,
  "pExpert"             => {cmd2=>"02", type =>"02pxx206", unit =>""},
  "sControl"           => {cmd2=>"F2", type =>"F2type", unit =>""},
  "sHC1"             => {cmd2=>"F4", type =>"F4hc1214",    unit =>""}, ...

Für "02pxx206" & "F2type"hab ich so auf Anhieb keine parsinghashs im code gefunden, was erklärt warum Du da die raw Werte hast. "F4hc1214" hat an den Stellen, die Du rot markiert hast noch "raw" stehen.
Der code sieht aber bereits in der 0.193 so aus, so dass Du das schon vorher hättest haben sollen / hattest ...

Hab noch mal etwas weiter zurück gelesen. Prinzipiell funktioniert fhem auf dem NUC, nur ein paar Einzelwerte fehlen / sind falsch?

Hast Du konkrete vorher / nachher Beispiele der readings die jetzt anders sind?

Danke für den Tipp, die Werte die ich sehe passen auch zum Quellcode. Hätte ich früher drauf kommen können.

der 0 vor der Koma zeigt es ist und es bleibt beta ..... 

every hint from you is welcome.

Vielen Dank für die Hilfe immi.
Ich habe noch eine Frage zum Code:
Welcher Wert verbirgt sich hinter insideTempRC? bei mir toggelt der Wert zwischen 1843.2 und 0
Ich habe die wirkliche insideTemp unten eingefügt, ist im orig Code nicht enthalten.

Code Auswählen Erweitern


  "F4hc1214" => [["outsideTemp: ", 4, 4, "hex2int", 10], [" x08: ", 8, 4, "raw", 1],
      [" returnTemp: ", 12, 4, "hex2int", 10], [" integralHeat: ", 16, 4, "hex2int", 1],
      [" flowTemp: ", 20, 4, "hex2int", 10], [" heatSetTemp: ", 24, 4, "hex2int", 10],
      [" heatTemp: ", 28, 4, "hex2int", 10], 
      [" seasonMode: ", 38, 2, "somwinmode", 1],
      [" integralSwitch: ", 44, 4, "hex2int", 1], [" hcOpMode: ", 48, 2, "opmodehc", 1],      
          [" roomSetTemp: ", 62, 4, "hex2int", 10], [" x60: ", 60, 4, "hex2int", 10],
      [" x64: ", 64, 4, "raw", 1], [size=12pt][b][" insideTempRC: ", 68, 4, "hex2int", 10][/b][/size],
      [" x72: ", 72, 4, "raw", 1], [" x76: ", 76, 4, "raw", 1],
      [" onHysteresisNo: ", 32, 2, "hex", 1], [" offHysteresisNo: ", 34, 2, "hex", 1],
      [" hcBoosterStage: ", 36, 2, "hex", 1], [size=12pt][b][" insideTemp: ", 74, 4, "hex2int", 10][/b][/size]
         ],


Dann habe ich noch eine zweite Frage, aus dem Code wurde ich nicht schlau.
Wenn die THZ aktuell ausgelesen oder beschrieben wird, werden dann parallel Anfragen versendet, oder wird bis zum Abschluss des lesen oder schreiben gewartet?

Einen schönen Start ins Wochenende.

Gruß Jörg

[willybauss]

Es gibt insideTemp (in sGlobal) und insideTempRC (in sHC1). Hoffentlich bringe ich das aus der Erinnerung noch richtig zusammen:

insideTempRC müsste der Wert sein, der aus einem externen Display gelesen wird. Falls Du keines hast, kannst Du diesen Wert ignorieren. Eigentlich hätte ich erwartet, dass er dann konstant (=0?) ist. Ist evtl. in der Anlage ein offenes Kabelende angeschlossen, und am anderen Kabelende hängt kein Display?

Zumindest bei den alten Anlagen (z.B. meine 303 SOL) gab es die Möglichkeit, auch ohne 2. Display einen Temperatursensor (Zweidrahtsentor KTYirgendwas) anzuschließen. Das müsste dann insideTemp sein. Keine Ahnung, ob es das bei neueren Anlagen noch so gibt. Aber da der Wert aus Kompatibilitätsgründen in sGlobal drin steht, wird er sicher gelesen und Dir angeboten.

Aber wenn ich mir deinen Code so ansehe, dann scheinen bei Dir beide insideTemp und insideTempRC in sGlobal zu stehen

[immi]

Ich habe noch eine Frage zum Code: Welcher Wert verbirgt sich hinter insideTempRC? bei mir toggelt der Wert zwischen 1843.2 und 0

In my Frimware
HC1 -> insideTempRC: is my temperature sensor upstairs (adjusted with p76RoomThermCorrection)
sGlobal -> insideTemp: is my temperature sensor upstairs (no adjustment)
I try to explain how does it work, using the logfile you sent me

Code Auswählen Erweitern


2022.05.27 20:15:22 5: THZ_ReadAnswer: uc unpack: '010062F40090FEA900E3002A00E100EF00E100010001001D00C80100000000000000D20000000000E90000000000D51003'
you remove 0100 (header) & footer (1003)

Code Auswählen Erweitern


62F40090FEA900E3002A00E100EF00E100010001001D00C80100000000000000D20000000000E90000000000D5
you remove 64 (crc)  and F4 (command for register HC1)

Code Auswählen Erweitern


0090FEA900E3002A00E100EF00E100010001001D00C80100000000000000D20000000000E90000000000D5
and now you start guessing
0090 HEX --> 144 decimal --> 14,4 divide by 10
and this is your first part of your decoding rule ["outsideTemp: ",   4, 4, "hex2int", 10]

I have never found any documentation from tecalor
immi

[hellijo]

In my Frimware
HC1 -> insideTempRC: is my temperature sensor upstairs (adjusted with p76RoomThermCorrection)
sGlobal -> insideTemp: is my temperature sensor upstairs (no adjustment)

Ok fine. I Think RC is maybe the corrected value in the newer SW.
I havn´t any parameter to adjust the inside or the outside temperature sensor.
If I manipulate your code, that insideTemp=insideTempRC everything looks finde.

Maybe, the messages get for FW2.14 a other format than FW2.06

I try to explain how does it work, using the logfile you sent me

Code Auswählen Erweitern


2022.05.27 20:15:22 5: THZ_ReadAnswer: uc unpack: '[s]0100[/s]62F40090FEA900E3002A00E100EF00E100010001001D00C80100000000000000D20000000000E90000000000D5[s]1003[/s]'
you remove 0100 (header) & footer (1003) this step is clear for me

Code Auswählen Erweitern


62F40090FEA900E3002A00E100EF00E100010001001D00C80100000000000000D20000000000E90000000000D5
you remove 64 (crc) Do you mean 64?  and F4 (command for register HC1) F4= HC1 wright?

Code Auswählen Erweitern


0090FEA900E3002A00E100EF00E100010001001D00C80100000000000000D20000000000E90000000000D5
and now you start guessing
0090 HEX --> 144 decimal --> 14,4 divide by 10
and this is your first part of your decoding rule ["outsideTemp: ",   4, 4, "hex2int", 10]

I have never found any documentation from tecalor
immi

If I had understand it right, I can interprete the message and correct the code for HC1 for FW 2.14.

[immi]

If I had understand it right, I can interprete the message and correct the code for HC1 for FW 2.14.

ja, und wir nennen es 2.14j

[immi]

I asked also before
please codeimprovement  here http://forum.fhem.de/index.php/topic,33211.0.html

[timtom2000]

Hallo,

per Zufall habe ich gestern ein merkwürdiges Verhalten bei der WW-Zubereitung entdeckt, dass ich mir nicht erklären kann und dass ich noch nie so gesehen habe:
Der Verdichter wird während laufender WW-Bereitung für die Dauer von ca. 20min. unterbrochen, s. Screenshot ca. 12:55-13:15 (Signal "Verdichter"; generiert aus sDisplay). Zu erkennen auch an der kurzen Delle im Anstieg der WW-Temp.
Währenddessen ist die WW-Bereitung aber weiterhin aktiv und wird auch im Display angezeigt (Signal "Warmwasser"; generiert aus sDisplay).
Die WW-Soll-Temp. liegt zudem konstant bei 52°C (rot gepunktet, nicht leicht zu erkennen).

Ich kann mir nicht erklären, warum der Verdichter überhaupt abschaltet und dann (erst) nach ca. 20min. wieder anschaltet, obwohl sich weder am OpMode, noch an der WW-Soll-Temp. etwas geändert hat.

Hat jemand eine Idee oder so etwas schon mal beobachtet?

Hinweis: Die WW-Bereitung ist bei mir PV-gesteuert. Bei hohem Energieertrag wird der OpMode autom. auf Manual gestellt. Die WW-Temp. im Manual-Betrieb habe ich auf 52°C (+3K Hysterese) eingestellt, im Normalbetrieb auf 41°C (+3K). Ist die WW-Soll erreicht, wird der Manual-Mode wieder autom. verlassen und auf Normal gestellt. Deswegen sackt dann die WW-Soll-Temp. ab, das ist so gewollt.

[willybauss]

EVU-Sperre?