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

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

Vorheriges Thema - Nächstes Thema

maximalz

@belu
Um an die Werte zu kommen, an die Zeile attr Mythz userReadings ... einfach Folgendes anhängen
, CopHC {sprintf("%.2f", ReadingsNum("Mythz","sHeatHCDay",1) / ReadingsNum("Mythz","sElectrHCDay",1))}, CopDHW {sprintf("%.2f", ReadingsNum("Mythz","sHeatDHWDay",1) / ReadingsNum("Mythz","sElectrDHWDay",1))}

Dann habe ich die Werte einfach per Plot-Editor ausgegeben (der Ursprung ist ein eiskalt von willibauss übernommenes Plot)

# Created by FHEM/98_SVG.pm, 2015-03-25 21:36:32
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set grid
set ylabel ""
set y2label ""
set yrange [0:1]
set y2range [0:4]

#FileLog_Mythz 35:Mythz.sGlobal\x3a:0:
#FileLog_Mythz 37:Mythz.sGlobal\x3a:0:
#FileLog_Mythz 39:Mythz.sGlobal\x3a:0:$fld[38]/1.5
#FileLog_Mythz 41:Mythz.sGlobal\x3a:0:$fld[40]/3
#FileLog_Mythz 31:Mythz.sGlobal\x3a:0:$fld[30]*1.2
#FileLog_Mythz 19:Mythz.sHC1\x3a::$fld[18]=~"summer"?0:1
#FileLog_Mythz 51:Mythz.sGlobal\x3a:0:(1-$fld[50])*0.5
#FileLog_Mythz 4:Mythz.CopDHW\x3a:0:
#FileLog_Mythz 4:Mythz.CopHC\x3a:0:

plot "<IN>" using 1:2 axes x1y1 title 'Compressor' ls l1fill lw 1 with lines,\
     "<IN>" using 1:2 axes x1y1 title 'BoosterStage3' ls l0fill lw 1 with lines,\
     "<IN>" using 1:2 axes x1y1 title 'BoosterStage2' ls l4fill lw 1 with lines,\
     "<IN>" using 1:2 axes x1y1 title 'BoosterStage1' ls l3fill lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'HeatingCircuit_Pump' ls l5 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'WinterMode' ls l2fill lw 0.5 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'EVU Lock' ls l6fill lw 0.5 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'CoP DHW' ls l0 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'CoP HC' ls l1 lw 1 with lines


Ich weiß noch nicht, wie oft sich die Werte für sHeat...Day und sElectr...Day ändern, also auch noch nicht, ob sich das Plotten so lohnt.
THZ (403 SOL), OBIS (2x EDL21), SolarEdge (SE10k)

willybauss

Zitat von: maximalz am 25 März 2015, 21:25:58
Ja, die Heizung läuft definitiv länger am Stück....
Klingt prima! 3 - 6 Starts pro Tag (Heizung und WW zusammen) habe ich zur Zeit auch. Der Start nachts um 4 Uhr passiert bei mir auch. Da wird es halt draußen immer kälter. Alternativ könnte man abends über ein Zeitprogramm die Solltemperatur für 1 - 2 Stunden etwas anheben, um ohne Heizphase über die Nacht zu kommen. Aber ob sich das lohnt ... ???
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

Zitat von: maximalz am 25 März 2015, 21:44:31
Ich weiß noch nicht, wie oft sich die Werte für sHeat...Day und sElectr...Day ändern, also auch noch nicht, ob sich das Plotten so lohnt.
Kommt darauf an, ob Du explizit ein Intervall definiert hast, sonst gar nie. Schau mal in den Details von Mythz unter "Attributes". Dort befinden sich z.B. interval_sGlobal, interval_sHC1 usw. Da müsstest Du dann auch Intervalle für "Deine" ...Day Werte definieren.

Oder Du hast sie wie ich als "at" definiert

define GetsHeatHCDay at *23:55:00 get Mythz sHeatHCDay

Dann wird es einmal täglich kurz vor Mitternacht gelesen und ins Logfile geschrieben.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

maximalz

Ich schreibe es auch einmal kurz vor Mitternacht, interessant wäre dann ein Plot, was generell über eine größere Zeitspanne geht, ohne explizit zoomen zu müssen.
THZ (403 SOL), OBIS (2x EDL21), SolarEdge (SE10k)

willybauss

Zitat von: maximalz am 26 März 2015, 18:29:58
Ich schreibe es auch einmal kurz vor Mitternacht, interessant wäre dann ein Plot, was generell über eine größere Zeitspanne geht, ohne explizit zoomen zu müssen.
Du musst im Plot das Attribut fixedrange auf z.B. 7days setzen.

Das mit den userReadings ist aber etwas unglücklich:

       
  • Du ermittelst einmal pro Tag kurz vor Mitternacht die Verbrauchs-Tageswerte

       
  • dann werden in den nächsten 24 Stunden diese Werte verwendet, um alle 5 Minuten dieselben COP-Werte zu berechnen und ins Logfile zu schreiben
Dieselben COP-Werte stehen dann pro Tag 288 mal im Logfile.

Evtl. wäre das mit einem notify, das auf das lesen der Tageswerte triggert, besser. Ich kann's aber auf die Schnelle nicht sagen, wie es genau aussehen muss.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

immi

not necessary wiilly:
let sElectrHCDay run 5 seconds after sHeatHCDay and you trigger the userreading with sElectrHCDay


define GetsHeatHCDay at *23:59:00 get Mythz sHeatHCDay
attr GetsElectrHCDay room Heizung
define GetsElectrHCDay at *23:59:05 get Mythz sElectrHCDay
attr GetsElectrHCDay room Heizung
attr Mythz userReadings CopHC:sElectrHCDay {sprintf("%.2f", ReadingsNum("Mythz","sHeatHCDay",1) / ReadingsNum("Mythz","sElectrHCDay",1))}, CopDHW {sprintf("%.2f", ReadingsNum("Mythz","sHeatDHWDay",1) / ReadingsNum("Mythz","sElectrDHWDay",1))}


p.s. not tested

willybauss

Zitat von: immi am 27 März 2015, 21:39:08
not necessary wiilly:
let sElectrHCDay run 5 seconds after sHeatHCDay and you trigger the userreading with sElectrHCDay
...
This would cause all other userReadings to be execued just once per day too, instead of after every reading.
edit: that's wrong => see next post

I tried it with
at 23:59:30 setreading Mythz CopHC {(ReadingsVal("Mythz","sHeatHCDay",1)) / (ReadingsVal("Mythz","sElectrHCDay",1))}

what didn't work for any reason. It ends up in a code string, instead of its result
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

Now I understand better what you mean. It should work like this:


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])}, CopHC:sElectrHCDay {sprintf("%.2f", ReadingsNum("Mythz","sHeatHCDay",1) / ReadingsNum("Mythz","sElectrHCDay",1))}, CopDHW:sElectrHCDay {sprintf("%.2f", ReadingsNum("Mythz","sHeatDHWDay",1) / ReadingsNum("Mythz","sElectrDHWDay",1))}


edit: tested - works  :)
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

immi

Hi Willy
pay attention that you read sElectrHCDay some seconds after sElectrHCDay otherwise you will use the  sElectrHCDay of the previous day.

Dear all
I played today with some old features of FHEMWEB
I start to like very much "plotfork".

define WEB FHEMWEB 8083 global
attr WEB SVGcache 1
attr WEB editConfig 1
attr WEB longpoll 1
attr WEB plotfork 1
attr WEB refresh 180
...


"plotfork" forks the generation of the plots in several processes: it makes very sense if you have more cores  or more cpus.
I think it could make sense also with 1 core.
immi

willybauss

Zitat von: immi am 29 März 2015, 16:33:27
Hi Willy
pay attention that you read sElectrHCDay some seconds after sElectrHCDay otherwise you will use the  sElectrHCDay of the previous day.
You're right. But in fact I do it a bit different (the code above is just an example):
at
GetsElectrDHWDay     Next: 23:55:00
GetsElectrHCDay        Next: 23:55:10
GetsHeatDHWDay        Next: 23:55:20
GetsHeatHCDay        Next: 23:55:30
GetsHeatRecoveredDay   Next: 23:55:40

Thigger is caused by sHeatRecoveredDay, which is the last one.
Reason for doing it at 23:55:xx instead of 23:59:xx is that I got zero values in some cases, since obviously the midnight reset happens not exactly at 0:00.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

Zitat von: immi am 29 März 2015, 16:33:27
...


define WEB FHEMWEB 8083 global
attr WEB SVGcache 1
attr WEB editConfig 1
attr WEB longpoll 1
attr WEB plotfork 1
attr WEB refresh 180
...


plotfork doesn't improve anything on my Raspi, but I let it in the code, since I'm going to replace it by a quad core Raspi2 soon.
SVGcache improves a lot, thanks for the hint. But I didn't find a way to define the target directory for the cached plots. I'd like to have them stored on my NAS, which is NFS mounted to the Raspi's file system.
longpoll is active by default anyway, so I don't add it.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

immi

Willy
consider that you have benefits from SVGcache only for old plots/data

back to your question.
$FW_dir/SVGcache is hardcoded to the web server dir:
in the standard case www/SVGcache

2 workarounds
1) put the whole fhem or just www/SVGcache in the NFS mounted NAS
2) link the directory www/SVGcache  to a directory mounted as NFS


immi

maximalz

Ich habe gerade ein merkwürdiges Verhalten meiner Lüftung festgestellt:

Ich habe die Zeiten 00:00-02:00, 06:00-08:00 und 16:00-18:00 am Display der WP eingestellt. Schaue ich ins Log/Plot, so sehe ich dass
a) die Zeit 16:00-18:00 in FHEM nicht angezeigt wird (das ist die zuletzt programmierte, seit dem hatte ich keinen FHEM-Restart mehr)
b) die Lüftung bereits um 4 Uhr angeht und bis 8 Uhr läuft, alle anderen Intervalle sind ok

Kennt jemand den Grund bzw. hat etwas Ähnliches beobachtet?

Frank
THZ (403 SOL), OBIS (2x EDL21), SolarEdge (SE10k)

immi

Hi Frank
Something went wrong in your display; you used it not properly or it wrote not properly the data back to the tecalor.

Set again the times in the display.
In order to crosscheck you can restart FHEM, wait 3 minutes and look at the readings programFan_xx_x


another possibility is that you use FHEM to change the parameters. I find it more confortable
immi

willybauss

Beim ändern der Parameter (sowohl am Display als auch über FHEM) ist es mir schon oft passiert, dass die Werte nicht von der Anlage übernommen wurden. Besonders häufig tritt das bei den außerplanmäßigen Lüftungseinstellungen (z.B. Stufe 3 für 60 Minuten) auf. Da das auch bei Bedienung am Display auftritt gehe ich davon aus, dass die Anlage da eine "Designschwäche" hat.
Gelegentlich dauert es auch ein paar Minuten, bis die Anlage sich dazu durchringt, vorgenommene Änderungen auch am Display anzuzeigen, z.B. wenn ich über fhem von Automatik auf WW-Betrieb umschalte.
Ein weiterer Fall sind die Hysteresen, die bei Änderung zwar sofort am Display angezeigt, aber manchmal nicht von der Anlage übernommen werden.
Wenn du wirklich wissen willst, ob Deine Einstellungen von der Anlage akzeptiert wurden, dann mach einfach mal einen Reset der Anlage (kleinen weißen Knopf hinter der rechten Tür für 20 Sekunden drücken). Dann den vollständigen Reboot der Anlage abwarten und anschließend im Display sowie in fhem  alles nochmal kontrollieren.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS