THZ / LWZ Tecalor Stiebel Eltron Heizung

[immi]

Markus
You are right. I just checked. 81 is plausible.
----------
It is some weeks that I am thinking how to improve allFB.
At the time, I only see two solutions and I am not happy with both:
1) separating all 40 parameters hidden behind allFB in 40 readings. It would be easy to implement, but the logfille-size will explode if you update too frequently allFB, because each parameter would also get a timestamp and some overhead.
2) giving full flexibility to the user, shifting the whole parsing to the config file; drawback is that the config file will become huge and really complicated. Newbies will get completely confused, and will give up.

I would like to have your feedback
thanks

@ Willi I will try bdlog on the weekend

immi

[willybauss]

keep it simple, start without DBLOG and FILElog.

don't understand what you mean. How should I show graphs without logging values to anywhere, neither DB nor FILE? Or did you mean I should stay with FileLog and not use DbLog? That's not really an option, at least long term. I'd really like to have the tooling all right before going into broadly using it.

Are you sure you have 81 separated words in allFB?

Please have a look on attached screen dump. I didn't check if it's really 81 items wide, but from what I see I don't doubt about it. Same issue with 'history' and 'last10errors'.

[micomat]

Hi immi,

could we modify the first option?
Keep the readings in allFB (getting them separated with userReadings is documented in the wiki and quite easy) but making the reading names shorter? maybe in three/fur letter-codes like clt for collector_temp or mvp for mainventilatorpower. this would decrease the log-size without changing the whole parsing. to prevent all old data becomes obsolete automatically while doing this you could set up a paramter like "attr Mythe shortnames" to use them? just a suggestion

do you separate the logfiles into months or do you store all in one file?

Markus

[willybauss]

looks like new frontend's charting function, reading from FileLog, doesn't manage the way how allFB data is stored in FileLog, see attached screen dump.
blue chart: Rel_humidity read from DbLog ==> o.k.
green chart: inside_temp read from FileLog ==> every second value is correct, showing the value stored in FileLog (e.g. 22.5), but the ones inbetween show zero, obviously read from the allFB row wrongly.


related part of FileLog looks like (line breaks added for better reading):

Code Auswählen Erweitern

2014-03-05_19:35:33 Mythz allFB: outside_temp: 4.6 flow_temp: 23.5 return_temp: 24.5 hot_gas_temp: 40.5 dhw_temp: 47.5
    flow_temp_HC2: -60 evaporator_temp: 13.8 condenser_temp: 24.8 Mixer_open: 0 Mixer_closed: 0 HeatPipeValve: 0 DiverterValve: 0
    DHW_Pump: 0 HeatingCircuit_Pump: 0 Solar_Pump: 0 Compressor: 0 BoosterStage3: 0 BoosterStage2: 0 BoosterStage1: 0
    HighPressureSensor: 0 LowPressureSensor: 1 EvaporatorIceMonitor: 0 SignalAnode: 0 EVU_release: 1 OvenFireplace: 0 STB: 0
    OutputVentilatorPower: 34 InputVentilatorPower: 27 MainVentilatorPower: 0 OutputVentilatorSpeed: 23 InputVentilatorSpeed: 28
    MainVentilatorSpeed: 0 Outside_tempFiltered: 6.1 Rel_humidity: 24.8 DEW_point: 719 P_Nd: 7.19 P_Hd: 11.36 Actual_power_Qc: 0
    Actual_power_Pel: 0 collector_temp: -60 inside_temp: 23.1
2014-03-05_19:35:33 Mythz inside_temp: 22.5
2014-03-05_19:35:33 Mythz Rel_humidity: 36.3



Don't know what would happen if DbLog would manage allFB in a better way. Maybe the values would oscillate between corrected and uncorrected ones - what's not really better than now.  Since the issue is with DbLog it's useless to give the old graph method with DbLog a try.


Bottom lime there's currently no other way than using FileLog and old graph method.

[immi]

Hi willi
please forget my previus post 17:39:47.
Please post your plotting configuration for both; it is getting interesting.

Hi Markus,
I think that your third option is very diskspace friendly and new user friendly, but I am afraid the readability would be terrible.
I want something diskspace friendly, user friendly and readable. I would also like to add units....

There is also a possibility of improving option 1 with a blacklist as attribute. The user could decide which parameters should be ignored. (e.g. I do not have a solarcollector --> Attr Mythz ignore_parameter solarcollector).

p.s. I am now dividing the the logfiles into months, polling every 5 minutes.
The logfilesize is acceptable.

immi

[micomat]

I think that your third option is very diskspace friendly and new user friendly, but I am afraid the readability would be terrible.

right, but when i think about other systems, a lot of themhave abbreviations for the readings.
e.g. the HMS has T, H and Bat. for Temperature, Humidity and Battery.
we need to find the happy medium way

There is also a possibility of improving option 1 with a blacklist as attribute. The user could decide which parameters should be ignored. (e.g. I do not have a solarcollector --> Attr Mythz ignore_parameter solarcollector).

thats also a great idea

best,
markus

[immi]

dear all
version 0.072 uploaded
changelog:
1) all programHC1*, programHC2*, programFan* and programDHW* have been implemented with get and set
2) inside_temp  has been added to the end of allFB
3) connect/disconnet bug related to ser2net has been extremely improved: max one retry per second

immi

[willybauss]

Please post your plotting configuration for both; it is getting interesting.

Hi immi,
don't know if there's a ascii file output of new graphing system's config anywhere. So I send you the setup as screen dump. Hope that helps.


Willy


btw: I would prefer having a blacklist too, since I need just a small part of all possible values currently - might increase over time of course.

[micomat]

dear all
version 0.072 uploaded

added to wiki pages
sadly my internet provider has a problem today so i cannot connecto to the internet to install it =(

markus

[willybauss]

as I described earlier I added corrections to fhem.cfg  due to the sensor offsets. So it looks like

Code Auswählen Erweitern

define Mythz THZ /dev/ttyUSB0@115200
attr Mythz interval_allFB 120
attr Mythz interval_history 28800
attr Mythz userReadings inside_temp {((split ' ',ReadingsVal("Mythz","allFB",0))[81]) - 0.6 }, Rel_humidity {((split ' ',ReadingsVal("Mythz","allFB",0))[67]) + 11.5}
define FileLog_Mythz FileLog /mnt/fhem/log/Mythz-%Y-%m.log Mythz

meanwhile I observed that the userReadings are also done after every  interval_history reading row, resulting in e.g.

Code Auswählen Erweitern

2014-03-05_21:42:47 Mythz programHC1_Sa_0: n.a.--n.a.
2014-03-05_21:42:47 Mythz inside_temp: 22.5
2014-03-05_21:42:47 Mythz Rel_humidity: 36.3
2014-03-05_21:42:47 Mythz programHC1_Mo_0: n.a.--n.a.
2014-03-05_21:42:47 Mythz inside_temp: 22.5
2014-03-05_21:42:47 Mythz Rel_humidity: 36.3
2014-03-05_21:42:48 Mythz programHC1_We_0: n.a.--n.a.
2014-03-05_21:42:48 Mythz inside_temp: 22.5
2014-03-05_21:42:48 Mythz Rel_humidity: 36.3
2014-03-05_21:42:48 Mythz programHC1_Tu_2: n.a.--n.a.
2014-03-05_21:42:48 Mythz inside_temp: 22.5
2014-03-05_21:42:48 Mythz Rel_humidity: 36.3

So there's a lot of unnecessary stuff written to the log. Does anyone know how I can limit execution of userReadings to allFB rows only?

[willybauss]

my thoughts about new log file format

Hi immi,

I have a few ideas to changed file format in regards to

   
• compatibility
• saving disk space (synonymical to increase speed of graph creation)

compatibility:
Improvement in efficiency might be limited, as long as log file format has to be compatible. Therefore a new approach: leave the output format as it is and don't touch this code area in future, to limit your effort. Implement code for new file format in addition to existing code, and limit your future work to this code. User can select data format by using either

Code Auswählen Erweitern


attr Mythz interval_allFB 120
attr Mythz interval_history 28800


or

Code Auswählen Erweitern


attr Mythz interval_allFB_new 120
attr Mythz interval_history_new 28800




Saving disk space by

   
• Shortening descriptions as mentioned by micomat already
• switch format of history reading to same as allFB: just 1 date/time entry, followed by all values in 1 row; limited effect, since read every 8 hours only; but medium effect in my case, since userReadings are done after each history row, as I described in my post today 10:49:36
• blacklist

completely different approach - don't know if possible without inventing fhem newly ...:

   
• write all data (even history) in allFB style sequence, but omit variable names in these rows completely
• write variable names as separate (header) row to file just once (or once per day, per hour, per 100 readings etc.)
• basically this would lead to a syntax almost identical to .csv file format
• just 1 identifier per row is needed additionally, in order to differenciate btw. allFB rows and history rows
• using userReadings might break the approach unfortunately - any idea?
• blacklist might or might not be possible with this approach; it might be possible to write header rows after every change of blacklist, but evaluation of values might get complex in this case

Already existing question are still valid, e.g.

   
• how does this fit into DbLog'ging (in order to reduce time needed to show graphs, which could need > half a minute for e.g. whole month view)
• how can new interface's graphing system be used, either from FileLog or from DbLog, even in case of userReadings

Advantage of new graphing system is ease of use, e.g. change time frame for a graph on the fly, select variables t.b. used from pull down menu instead of counting entry numbers ...

[micomat]

0.072 installed working like a charm!
thanks!

[immi]

Hallo Willy
thanks for brainstorming.
I am slowing getting the big picture.
The first priority of 00_THZ is to be mainstream for fhem and control the interface to the heatpump.
I did not and I am not going to save data with THZ (exept for debugging) in any format.
I will keep on using FHEM-system-calls given by FHEM to DBLOG or FILELOG or other modules.
The module DBLOG or FILELOG will provide inputs for plotting. I am not the manteiner of plotting interfaces, of filelog nor dblog.

for history interval polling,  I did not implement a full refresh  (with stuff like programHC1_Tu_2 ....). It is  probably a bug.
I will check tonight.

Hi Markus
for the documentation following information could be interesting
A full refresh (of all parameters) is done only at systemstart, very very slowly (not to decrease performance of FHEM), and takes ca 3 or 4 minutes.
After(*note)  that the intervall polling of allFB and History register should start.

(*note) If the FB-intervall or History-Intervall attributes are lower than 3 minutes, there clould be a concurrency. But I do not expect any problems.

immi

[micomat]

will add this to the wiki

[immi]

Hy Willy
no bug in 00_THZ
commandref is always your friend:

userReadings
A comma-separated list of definitions of user-defined readings. Each definition has the form:
    <reading>[:<trigger>] [<modifier>] { <perl code> }
After a single or bulk readings update, the user-defined readings are set by evaluating the perl code { <perl code> } for all definitions and setting the value of the respective user-defined reading <reading> to the result. If <trigger> is given, then all processing for this specific user reading is only done if one of the just updated "reading: value" combinations matches <trigger>, which is treated as a regexp.

if you do not use the :<trigger>, each time MyTHZ is updated also the userreading will be updated
here the corrected version

Code Auswählen Erweitern


attr Mythz userReadings inside_temp:allFB {((split ' ',ReadingsVal("Mythz","allFB",0))[81]) - 0.6 }, Rel_humidity:allFB {((split ' ',ReadingsVal("Mythz","allFB",0))[67]) + 11.5}

immi