THZ / LWZ Tecalor Stiebel Eltron Heizung

[micomat]

on mine, 1000 enters the "god mode"

[willybauss]

if you are able to delete the failure history using passcode 1000 someone changed the passcode from the original one to 1000.

[micomat]

i don't care for me 1000 is no problem as nobody as myself is changing something on the THZ.

[willybauss]

@ immi
while searching for the solution to get emails in case of failure I stumbled over the argument event-on-change-reading. Am I right assuming that the THZ module doesn't support it?

Willy

[micomat]

@willy, try to create an "if" enquiry like "IF fault0DATE=today then send email".
so you could create and email when the last error date is up to date.

[willybauss]

meanwhile I managed to get informed by email in case of faults.


1st Solution:

Code Auswählen Erweitern

define Mythz.alarm1 at +*01:00:00 { if (ReadingsVal("last10errors","number_of_faults",0) > 0 ) { DebianMail('MYNAME@t-online.de','Tecalor Mythz Alarm', 'ErrorLog hat ausgeloest: '. $EVENT) ;; } }
attr Mythz.alarm1 room Heizung

2nd Solution:

Code Auswählen Erweitern

define Mythz.alarm notify .*fault.* { if (ReadingsVal("last10errors","number_of_faults",0) > 0 ) { DebianMail('MYNAME@t-online.de','Tecalor Mythz Alarm','ErrorLog hat ausgeloest: '. $EVENT);; } }
attr Mythz.alarm room Heizung


2nd solution is preferred, since email is being sent immediately. And there's no need to adjust time intervals if reading intervals are changed.


Unfortunately $EVENT doesn't work, don't know why  . The email just shows the phrase '$EVENT'
issue fixed meanwhile; code updated in examples.

Additionally I do not yet understand why I have to use wildcards   '.*fault.*'  instead of  'number_of_faults'  .

[willybauss]

@willy, try to create an "if" enquiry like "IF fault0DATE=today then send email".
so you could create and email when the last error date is up to date.

This would reduce no. of emails to max. 24, since I check for errors once per hour. I'd really like to wait for immi's answer for the event-on-change-reading feature before searching for a limitation of email count in different way.

[willybauss]

issue with $EVENT fixed. solutions updated in code above.

@micomat:
please feel free to copy the code into your wiki. It could be helpful ...

[micomat]

sure will add it next time i update the wiki
thanks!

[immi]

sorry guys,
I am currently not at home, bad internet connection, less time for private stuff.
Nevertheless i read that you made great progress without me.
good job willy

immi

[immi]

Hi Willy
There are several answers to your problems.
1) if you have a big issue in last10errors, I do not see a problem to get 20 emails. You should (let) repair it very fast, before something goes reaaly wrong.
2) if you really want only one email, you can set a variable like $emailsent after sending email and test it before sending.
3) event-on-change-reading is not fully implemented (and tested) so far in thz; actually I do not fully understand the command.ref: Double negations are quite tricky to interpret... The german version is not much better.

event-on-update-reading
If not set, every update of any reading creates an event, which e.g. is handled by notify or FileLog. The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only updates of the listed readings create events.
event-on-change-reading
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created.
The precedence of event-on-update-reading and event-on-change-reading is as follows:
    If both attributes are not set, any update of any reading of the device creates an event.
    If any of the attributes is set, no events occur for updates or changes of readings not listed in any of the attributes.
    If a reading is listed in event-on-update-reading, an update of the reading creates an event no matter whether the reading is also listed in event-on-change-reading.

Moreover: event-on-change-reading and event-on-update-reading and event-min-interval are very interesting because are standard attributes solving one open issue on my opl "blacklist some parameters from being logged and/or from generating notify". I have a week holiday for Easter  ...

immi

[willybauss]

Hi immi,

your 2nd option (set a variable like $emailsent after sending email and test it) sounds very easy; I'll try to do it in this way - thou version 1) is also absolutely right.

I played around with event-on-change-reading but observed that logging stops as soon as I try to use it. Might be caused by not being implemented fully. Then I thought about using the "differnce" option of userReadings. But  $emailsent seems indeed to be the easiest way.

I want to use email information not just in case of failures but also in case of e.g. booster usage. And in this case it's really not necessary to get tons of emails instead of one per day.

event-on-change-reading would  - as I understand the commandref -  not allow more than one different email triggers. But my current solution combined with  $emailsent does.

Willy

[immi]

summer is definitely coming. Therefore v0.080

changelog:
-bit responsible for summer/winder mode identified
-Status_HC1_F4 and Status_HC2_F5 present now "mode: Summer" (or Winter)
-p49SummerModeTemp and p50SummerModeHysteresis implemented read/write

from the heatpump datasheet following rule:
if outsidetemp > p49SummerModeTemp + p50SummerModeHysteresis ---> Summermode
if outsidetemp < p49SummerModeTemp - p50SummerModeHysteresis ---> Wintermode

e.g.

Code Auswählen Erweitern

p49SummerModeTemp =15 °C
p50SummerModeHysteresis =3 K
if outsidetemp > 18 °C ---> Summermode
if outsidetemp < 12 °C ---> Wintermode

@Markus please check the version and update the wiki

thanks
immi

[micomat]

Great invention will Check and update tomorrow

edit: i can already See the icons representing Winter/Summer State in my mind

thanks
markus

[micomat]

hi immi,

i updated to 0.80 and i can see the values P49 and P50 now. in HC2 the display of the mode is visible:

Code Auswählen Erweitern

outside_temp: 21.3 return_temp: 29.2 vorlauftemp: -60 heat_temp: 20.4 heat-set_temp: 29.2 stellgroesse: -100 mode: winter x32: 0 x36: 256 x40: 2 x44: 0 x48: 0 x52: 0
in HC1 i miss the mode description?

Code Auswählen Erweitern

outside_temp: 21.2 x08: 51.5 return_temp: 29.1 integral_heat: 0 flow_temp: 29.4 heat-set_temp: 24.9 heat_temp: 29.1 x32: 0.2 x36: 0.2 x40: 0 integral_switch: 100 mode: x52: 0 room-set-temp: 21 x60: 0 x64: 5632 x68: 210 x72: 512 x76: 22 x80: 0

i also noticed that i saw the value of P49 coming up in the thz-log while restarting fhem but i first saw it in fhem after manually klicking on "get p49". P50 was showing up from the beginning.
and ideas? i only use HC1.

thanks
markus