THZ Tecalor (LWZ Stiebel Eltron) module support and code improvement.

[börni]

sollte ich das bei mir nun schon mal händisch abändern oder auf nen Update warten?

Vielen Dank & viele Grüße
Fabian

[andre.k]

Du kannst ruhig warten bis immi das korrigiert und ins SVN hochlädt. Es handelt sich ja nur um Warnings, die sind eigentlich unschädlich.

[immi]

Hi Andre
i implemented and committed the following
- all %soll have a type
- validation of time inputs in set

please xcheck

Hi Fabian
please wait for Andre confirmation before upgrading
immi

[willybauss]

the missing answer for andre's new registers:

get sControl:
1st try: 

Code Auswählen Erweitern

0101F4F21003 msg2 decode: timing issue

2nd try:

Code Auswählen Erweitern

heatRequest: 5 heatRequest2: 5 hcStage: 0 dhwStage: 0 heatStageControlModul: 0 compBlockTime: 0 pasteurisationMode: 0 defrostEvaporator: 00 boosterStage2: 0 solarPump: 0 boosterStage1: 0 compressor: 0 heatPipeValve: 0 diverterValve: 0 dhwPump: 0 heatingCircuitPump: 0 mixerOpen: 0 mixerClosed: 0 sensorBits1: 00 sensorBits2: 01 boostBlockTimeAfterPumpStart: 0 boostBlockTimeAfterHD: 0

get sFan:

Code Auswählen Erweitern

statusAFC: 512 supplyFanSpeedCAL: 9.18333333333333 exhaustFanSpeedCAL: 524.8 supplyFanAirflowCAL: 5.79 exhaustFanAirflowCAL: 89.6 supplyFanSpeed: 544 exhaustFanSpeed: 56320 supplyFanAirflowSet: 572 exhaustFanAirflowSet: 34304 supplyFanSpeedTarget: 0 exhaustFanSpeedTarget: 0 supplyFanSpeed0: 0 exhaustFanSpeed0: 1.4 supplyFanSpeed200: 412.1 exhaustFanSpeed200: 640 airflowTolerance: 50 airflowCalibrationInterval: 0 timeToCalibration: 63

I didn't try to understand what the answers may tell me, don't have enough time currently, sorry.


btw:
to try out "nonblockng" - is it enough to set the attribute to 1?

[immi]

I didn't try to understand what the answers may tell me, don't have enough time currently, sorry.

No problem Willy.. you are investing so much time in supporting newcomers in the forum, which is more important.

p.s. do not strart looking at nonblockng unless you have tons of time. Parallelizing is a complex beast.
immi

[willybauss]

Since a few days I'm using the new "freezemon" https://forum.fhem.de/index.php/topic,83909.0.html  module and saw lots of entries like

Code Auswählen Erweitern

s:23:37:27 e:23:37:28 f:1.23 d:CUL_HM_procQs(CUL_HM_procQs) THZ_GetRefresh(N/A) SYSMON_Update(sysmon)


After having changed Mythz to nonblocking the result looks like

Code Auswählen Erweitern

1 - s:08:05:59 e:08:06:01 f:2.579 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:08:17:07 e:08:17:08 f:1.005 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:08:18:07 e:08:18:08 f:1.114 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:08:28:10 e:08:28:11 f:1.219 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:08:42:14 e:08:42:15 f:1.022 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:08:48:16 e:08:48:17 f:1.021 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:08:52:17 e:08:52:18 f:1.136 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:09:11:23 e:09:11:24 f:1.017 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:09:15:24 e:09:15:25 f:1.182 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:09:32:29 e:09:32:30 f:1.061 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:09:36:30 e:09:36:31 f:1.033 d:CUL_HM_procQs(CUL_HM_procQs)
1 - s:09:40:50 e:09:40:51 f:1.376 d:CUL_HM_procQs(CUL_HM_procQs)

but the same time the log file is filled with tons of

Code Auswählen Erweitern

2018.02.08 09:32:27 3 : [Mythz] THZ_GetRefresh(sDisplay) BlockingCall started
2018.02.08 09:32:29 3 : Setting Mythz serial parameters to 115200,8,N,1
2018.02.08 09:32:29 1 : /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 reappeared (Mythz)
2018.02.08 09:32:30 1 : FreezeMon: myFreezemon possible freeze starting at 09:32:29, delay is 1.061 possibly caused by CUL_HM_procQs(CUL_HM_procQs)
2018.02.08 09:33:27 3 : opened||||||
2018.02.08 09:33:27 3 : [Mythz] THZ_GetRefresh(sDisplay) BlockingCall started
2018.02.08 09:33:30 3 : Setting Mythz serial parameters to 115200,8,N,1
2018.02.08 09:33:30 1 : /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 reappeared (Mythz)
2018.02.08 09:33:45 3 : opened||||||
2018.02.08 09:33:45 3 : [Mythz] THZ_GetRefresh(sHC1) BlockingCall started
2018.02.08 09:33:46 3 : Setting Mythz serial parameters to 115200,8,N,1
2018.02.08 09:33:46 1 : /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 reappeared (Mythz)
2018.02.08 09:34:27 3 : opened||||||
2018.02.08 09:34:28 3 : [Mythz] THZ_GetRefresh(sDisplay) BlockingCall started
2018.02.08 09:34:30 3 : Setting Mythz serial parameters to 115200,8,N,1
2018.02.08 09:34:30 1 : /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 reappeared (Mythz)
2018.02.08 09:35:28 3 : opened||||||
2018.02.08 09:35:28 3 : [Mythz] THZ_GetRefresh(sDisplay) BlockingCall started
2018.02.08 09:35:30 3 : Setting Mythz serial parameters to 115200,8,N,1
2018.02.08 09:35:30 1 : /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 reappeared (Mythz)
2018.02.08 09:36:28 3 : opened||||||

Therefore I switched of nonblocking now. Is there a better solution, e.g. suppress these log entries? Would it be dangerous to suppress them?

[ioT4db]

...
Ich weiss nicht inwiefern die Register auch in den neueren Anlagen bzw. Firmware<>2.14 vorhanden sind. Vieleicht könnte das mal jemand testen. Die zugehörigen Get-Kommandos sind wie folgt
...

Also die Werte der Lüfterstufen (bei get sFan) stehen bei mir (sFirmware version: 05.19 / sFirmware-Id HW: 113 SW: 3.16 Date: DEC 10 2014) schonmal weiter hinten!

Die Position in der Parse message habe ich fett markiert...

Beispiel:

2018.01.29 22:55:36 5: Parse message: F6E80200013AA30001714F00013C69000174A800000000000000000E101518 008C 008C 23 23 00
(hier Lüfter Stufe 1: 140 m3/h in und out und outputVentilatorPower: 35 inputVentilatorPower: 35)

2018.01.30 08:39:47 5: Parse message: 29E80200013AA30001714F00013C69000174A800000000000000000E101A14 00A0 00A0 28 28 00
(hier Lüfter Stufe 2: 160 m3/h in und out und outputVentilatorPower: 40 inputVentilatorPower: 40)

VG

[immi]

Hi Willy
I do not know what freezemon does in detail.
But it is not a big surprise that thz blocks fhem during the serial comunication for some milliseconds.
For newer tecalor with higher serial-baud it is negligible.
For older thz 2.x it is not negible; therefore andre and me implemented the 2 approaches (non-blocking and Global select loop) in July2017 (https://forum.fhem.de/index.php/topic,33211.msg675835.html#msg675835)
I am still not 100% happy with the solutions (both have sideeffects)

To Your question:  >>suppress these log entries
The log entries are not the problem; The problem is that we are opening and closing the serial adapter each time you make a non-blocking call.
immi

Hi friesenjung
good job
I will xcheck this evening
immi

[willybauss]

For newer tecalor with higher serial-baud it is negligible.

My THZ works with 115.2kbit/s. But frequently opening/closing the adapter might have different drawbacks, I guess. So I let it as it is currently.

[andre.k]

Hi Andre
i implemented and committed the following
- all %soll have a type
- validation of time inputs in set

please xcheck

Hi Fabian
please wait for Andre confirmation before upgrading
immi

Hi immi,

I checked the new version. It's ok, no warnings from THZ_Set anymore.

André

[immi]

Hi Andre
thanks
one other question: what is "calibration speed" in your  E8fan?


Hi friesenjung
i committed the followings

Code Auswählen Erweitern


[" x48: ",                  48, 4, "hex", 1],
[" x52: ",                  52, 4, "hex", 1],
[" x56: ",                  56, 4, "hex", 1],
[" inputFanSpeed: ",        58, 2, "hex", 1],         #like in sGlobal?  actual measured speed
[" outputFanSpeed: ",       60, 2, "hex", 1],         #like in sGlobal? actual measured speed
[" pFanstageXAirflowInlet: ",  62, 4, "hex", 1],    #m3/h  like p37Fanstage1AirflowInlet or p38Fanstage2AirflowInlet
[" pFanstageXAirflowOutlet: ", 66, 4, "hex", 1],  #m3/h like p40Fanstage1AirflowOutlet or p41Fanstage2AirflowOutlet
[" inputFanPower: ",           70, 2, "hex", 1],      # like in sGlobal
[" outputFanPower: ",          72, 2, "hex", 1],      # like in sGlobal

everything before charachter 58 has still to be deciphered

[ioT4db]

Hi friesenjung
i committed the followings

Code Auswählen Erweitern


[" x48: ",                  48, 4, "hex", 1],
[" x52: ",                  52, 4, "hex", 1],
[" x56: ",                  56, 4, "hex", 1],
[" inputFanSpeed: ",        58, 2, "hex", 1],         #like in sGlobal?  actual measured speed
[" outputFanSpeed: ",       60, 2, "hex", 1],         #like in sGlobal? actual measured speed
[" pFanstageXAirflowInlet: ",  62, 4, "hex", 1],    #m3/h  like p37Fanstage1AirflowInlet or p38Fanstage2AirflowInlet
[" pFanstageXAirflowOutlet: ", 66, 4, "hex", 1],  #m3/h like p40Fanstage1AirflowOutlet or p41Fanstage2AirflowOutlet
[" inputFanPower: ",           70, 2, "hex", 1],      # like in sGlobal
[" outputFanPower: ",          72, 2, "hex", 1],      # like in sGlobal

everything before charachter 58 has still to be deciphered

hi immi,

its not so easy but I will give my best

Another question: Is there a reason that p58 ist not schown with firmware 5.39?

[immi]

Another question: Is there a reason that p58 ist not schown with firmware 5.39?

not sure I understand you question: I explain you again

[" xxyyzz: ",                  56, 4, "hex", 10],

xxyyzz: --> text describing the value
56         --> start position of the value
4           --> lenght of the value
"hex"     ---> type of he value
10           --> correction factor (e.g. multiplicate by 10 the value)
immi

[ioT4db]

hi immi,

no, not the new registers. I ment in the normal THZ-Readings (see attachement) running with the attribute firmware=5.39

[immi]

you ca

hi immi,
no, not the new registers. I ment in the normal THZ-Readings (see attachement) running with the attribute firmware=5.39

all register which have been found and interpreted, have been implemented
You can ask tecalor in which register is stored  p58..... 
immi