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

[immi]

Well, in German manual they're called "Pumpendrehzahl Warmwasser" and "Pumpendrehzahl Heizen". As they do not have a P-number, I'd say your suggestions are fine.

please test following patch

at line 497 add followings

Code Auswählen Erweitern


my %sets539only =(
"p99PumpSpeedHC" => {cmd2=>"0A02CB", argMin =>   "0", argMax =>  "100", type =>"5temp",  unit =>" %"}, 
"p99PumpSpeedDHW" => {cmd2=>"0A02CC", argMin =>   "0", argMax =>  "100", type =>"5temp",  unit =>" %"} 
);


at about line 1560 update following

Code Auswählen Erweitern


elsif ($attrVal eq "5.39") {
        THZ_RemoveInternalTimer("THZ_GetRefresh");
        %sets=(%sets439, %sets539only);
        %gets=(%getsonly539, %sets);
        THZ_Refresh_all_gets($hash);
      }


p.s. you can decide the naming if PumpSpeed or PumpRate

[TheTrumpeter]

Works perfect.

Regarding name: I like "rate" more than "speed".

[immi]

Hab' den Rückgabewert trotzdem mal ausgewertet, 0x1003 bzw. 4099d. Wüsste nicht mit welcher Umrechnung ich da auf 1,7bar kommen sollte. 

You just have to be more creative: try
1003h     ->  turn   0310h    -->    784d -->  1,784 bar
immi

[immi]

v 0.155 uploaded
- new parameters for 5.39 by thetrumpeter msg561513:  "p99PumpRateHC" and "p99PumpRateDHW"      

[TheTrumpeter]

You just have to be more creative: try
1003h     ->  turn   0310h    -->    784d -->  1,784 bar
immi

How to implement that to try if the value "lives" or is constant?
As of now I only added new registers and took the values "as they are". I could do that and see if the value changes.

Maybe that's the clue also for "Abluftfeuchte"...

You think they swapped lower and upper byte to prevent people from getting the values? Or why do they do that? Does not make sense to me... nor makes it sense to store only half of the physical value. What if pressure drops below 1bar?

[immi]

You think they swapped lower and upper byte to prevent people from getting the values? Or why do they do that? Does not make sense to me...

No it is not a safety measure. Sometimes they swap the bytes, maybe in your case not, and they divide the value over 2 registers.
I just think that many developers reworked the code over several firmwares, no-one cleaned up  and they wanted to mantain some compatibility with legacy products.
If you look at my code starting from line 1443, you see many strange encodings
I understand your frustration: But think it is much better than a sudoku
immi

[TheTrumpeter]

Hm... makes it more difficult 

When I try to read 0A001F, I get "unknown request", so I cannot read it out nor swap the bytes. So it won't be the value I search for.

[toggle]

Hab' den Rückgabewert trotzdem mal ausgewertet, 0x1003 bzw. 4099d. Wüsste nicht mit welcher Umrechnung ich da auf 1,7bar kommen sollte. 

You just have to be more creative: try
1003h     ->  turn   0310h    -->    784d -->  1,784 bar

Für mich sieht 0x1003 eher nach dem Ende der Message aus (DLE + ETX).

[willybauss]

Hi immi,

I get duplicate events caused by my Mythz userReadings. After weeks of investigation I still don't have any idea where they might come from. The userReading definition looks like:

Code Auswählen Erweitern

CopHC:sHeatRecoveredDay.* {sprintf("%.2f", ReadingsNum("Mythz","sHeatHCDay",1) / ReadingsNum("Mythz","sElectrHCDay",1))},
CopDHW:sHeatRecoveredDay.* {sprintf("%.2f", ReadingsNum("Mythz","sHeatDHWDay",1) / ReadingsNum("Mythz","sElectrDHWDay",1))},
PumpeDHW:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[25]},
PumpeHC:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[27]},
PumpeSol:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[29]},
Compress:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[31]},
Boost3:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[33]},
Boost2:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[35]},
Boost1:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[37]},
SwitchingProg:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[1]},
Compressor:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[3]},
HeatingHC:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[5]},
HeatingDHW:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[7]},
BoosterHC:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[9]},
FilterBoth:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[11]},
VentStage:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[13]},
PumpHC:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[15]},
Defrost:sDisplay.* {(split ' ',ReadingsVal("Mythz","sDisplay",0))[17]},
Service:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[1]},
Rel_humidity:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[67] + 11.5},
flow_temp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[3]},
return_temp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[5]},
outside_temp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[1]},
dhw_temp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[9]},
inside_temp:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[27]}

Setting an EventMonitor, filtered by any one of these userReadings shows that all these userReadings are duplicated - identical content and identical time stamp. The ones which are logged show up twice in the log file of course.

For debugging I did e.g. for "return_temp": I removed everything from my configuration where the phrase "return_temp" shows up, beside the definition in the userReading shown above. But still: as soon as I do a "get Mythz sGlobal" I get two events. Removing "return_temp" from the userReadings definition ends up in zero events of course.

Might this behavior be caused by the module itself? I tried going back from my current version 0.155 to 0.152 without success.

Yes, event-min-interval .*:1 solves the issue. But it would be much better to solve the root cause instead of putting a plaster on the result.

Any Idea?

BR Willy

edit:
related topic in Help-section (while DOIF turned out to be not the root cause meanwhile):  https://forum.fhem.de/index.php?topic=65327

[immi]

do you see the duplicate for the userreading related to sGlobal or also for the one others (e.g. sHeatRecoveredDay)?

[willybauss]

I did a rough check for most of them now. It looks like the duplicates exist in the userReadings only, but not in single readings. This might mean that the issue is limited to "multi parameter readings" like sGlobal, sHC1, sDisplay etc., but does not exist in single parameter readings.
In detail:

userReadings which are logged show up twice in the log file and twice in the EventMonitor.

userReadings which are not logged show up  twice in EventMonitor (and of course not in the log file).

Others like get Mythz sHeatRecoveredDay, sElectrDHWDay, sElectrHCDay, sHeatDHWDay, sHeatHCDay are read directly by a get command, triggered by an "at" close to midnight. All of these are single parameter readings. Those are not affected from the issue, and show up once in EventMonitor.

[immi]

Hi willy
I update the all readings (with multiple or single parameters) with the same procedure.
I cannot reproduce your failure on my nas or on my mac.

Code Auswählen Erweitern

related topic in Help-section (while DOIF turned out to be not the root cause meanwhile):  https://forum.fhem.de/index.php?topic=65327

I read the 3d and I do not understand why are so sure DOIF is not the connected to your problem.
If I have understood correctly, your issues is activated from a special formatting of DOIF.
I agree with Damian thet the 2 formatting "should" be equivalent, but unfortunatelly are not.

What happens if you modify sGlobal with setreading

Code Auswählen Erweitern

setreading   Mythz sGlobal  outsideTemp: 1.5 flowTemp: 26.4 returnTemp: 24.2 hotGasTemp: 37.7 dhwTemp: 47.1 flowTempHC2: -60 evaporatorTemp: -1.5 condenserTemp: 25.8 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: 1 evaporatorIceMonitor: 0 signalAnode: 0 evuRelease: 1 ovenFireplace: 0 STB: 0 outputVentilatorPower: 0 inputVentilatorPower: 0 mainVentilatorPower: 0 outputVentilatorSpeed: 0 inputVentilatorSpeed: 0 mainVentilatorSpeed: 0 outside_tempFiltered: 1.9 relHumidity: 0 dewPoint: 0 P_Nd: 4.87 P_Hd: 11.66 actualPower_Qc: 0.000 actualPower_Pel: 0.000 collectorTemp: -60 insideTemp: 27.6
Edit: I mean: do you get duplicated also from setreading?
immi

[willybauss]

Is the 0.155 I'm using the latest version?

I have the same issue also for readings which are not at all related to the content of this DOIF. That's the reason why I said it's not related. But you're right. Formatting of this DOIF might work like a switch for something completely different - what does not really make the issue more understandable.

Modifying sGlobal with setreading leads to the same result: duplicates.

[immi]

Is the 0.155 I'm using the latest version?

yes

I have the same issue also for readings which are not at all related to the content of this DOIF. That's the reason why I said it's not related. But you're right. Formatting of this DOIF might work like a switch for something completely different - what does not really make the issue more understandable.

Modifying sGlobal with setreading leads to the same result: duplicates.

setreading is completely unrelated to my code (my code is not executed with it).
Theoretically if you define Mythz as a dummy, you should still see that setreading give you duplicates

[willybauss]

So I should check other modules for duplicates as well  . Looks like a nightmare meanwhile. So, now I remember that a year or so ago I added a few event-min-interval's in other modules - maybe to avoid duplicates ...

I have to check; may take a while, since I'm VERY busy in the job currently.