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

Begonnen von immi, 02 Februar 2015, 11:42:16

Vorheriges Thema - Nächstes Thema

The Spirit

Zitat von: immi am 23 Juni 2016, 18:05:36
es kommt darauf an wie lange ist die kabel.
kurze kabel --> USB direktt könnte einfacher sein
sehr lange kabel --> RS232 ist besser un  billiger
immi
danke.
Kabel bis zum Pi wird um die 6-7m sein.
Dann also RS232.
Wo genau ist der Stecker eigentlich?
Sehe leider immer nur kleine Ausschnitte. Gibt es wo ein Bild wo man mal die ganze Anlage sieht mit dem Stecker drauf?
Danke
THZ 304 Eco Baujahr 2015

micomat

wenn du die tuer auf der rechten seite aufmachst, ist oben der 3-polige diagnosestecker.
eine Anleitung wie Du den auf eine "normale" RS232 umbaust findest du hier: http://robert.penz.name/heat-pump-lwz/
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

willybauss

Die Teile zum Bau des Steckers bekommst Du alle bei Reichelt. USB-Seriell-Umsetzer ebenfalls.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

immi

Further 2 ideas, which I have not tried
1) you can think to "RS232/TTL Wandler mit MAX3232"
http://www.pollin.de/shop/dt/MTQ2OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Sonstige_Boards/RS232_TTL_Wandler_mit_MAX3232.html
You connect the ttl directly to the raspi internal serial (MAX3232 should be 3.3v compliant)
On the rs232 side, you desolder the rs232-plug and solder a cheap shielded isdn cable.

2) you save all the long cables and go wireless with a esp8266 as ser2net repeater
here you have to look if you find ttl logic directly in your tecalor board; otherwise a max3232 is also needed.

If you have never used a soldering iron, forget it and follow Willy and Marcus advise.
immi

Karle

Hi !

I often can find in the log file the following line:

2016.07.02 09:28:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 09:28:49 2: Mythz/RAW: 10
2016.07.02 09:48:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 09:48:49 2: Mythz/RAW: 10
2016.07.02 10:08:04 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 10:08:04 2: Mythz/RAW: 10
2016.07.02 10:08:29 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 10:08:29 2: Mythz/RAW: 10
2016.07.02 10:08:39 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 10:08:39 2: Mythz/RAW: 10
2016.07.02 10:08:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 10:08:49 2: Mythz/RAW: 10
2016.07.02 10:28:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 10:28:49 2: Mythz/RAW: 10
2016.07.02 10:48:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 10:48:49 2: Mythz/RAW: 10
2016.07.02 11:08:04 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 11:08:04 2: Mythz/RAW: 10
2016.07.02 11:08:29 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 11:08:29 2: Mythz/RAW: 10
2016.07.02 11:08:39 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 11:08:39 2: Mythz/RAW: 10
2016.07.02 11:08:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 11:08:49 2: Mythz/RAW: 10
2016.07.02 11:09:31 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 11:09:31 2: Mythz/RAW: 10
2016.07.02 11:28:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?
2016.07.02 11:28:49 2: Mythz/RAW: 10
2016.07.02 11:48:49 3: Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?

Can someone tell me what is the reason for that respectively what can I do against it ? The functionality (logging) is working.

I updated my system some days ago from a RPI 1 to the odroid C2, i had this issue with both machines (I think with the Odroid i have more of this lines in the logfile).

Greets Karl

immi

Hi Karl
It looks like you tecalor is busy and ansers very late.
I jut uploaded version 0.152 introducing a delay for you.

update fhem tomorrow; restart and tell me if you seen an improvement.

immi

Karle

Hi Immi,

thank you, I will update the next days and check if it is gone.

It is an LWZ 303 i (Stiebel), but with no special things. It also was restartet 3-4 days ago.

Greets Karl

willybauss

Actually I have the problem, that my THZ does not switch off ventilation if I set p7 or p8 to 0. The code part of my DOIF looks like

DOELSEIF
    ( ([extraVent_Wohnzimmer_value] == 0)
  and ([extraVent_Schlafzimmer_value] == 0)
  and ([Mythz:sGlobal:[inputVentilatorPower. (\d+)]] > 10)
  and ([Mythz:sGlobal:[dhwPump. (\d+)]] == 0)
  and ([Mythz:Rel_humidity] < 60)
  and ([RandomTimer_BinAbwesend] eq "ja") )
        ((set Mythz p07FanStageDay 0),
(set Mythz p08FanStageNight 0),
(attr extraVent_ALL cmdpause 1:1:1:7200),
{Log 1,"Ventilation set to level 0"})


In the log I see every two hours (=> cmdpause 7200) an entry "Ventilation set to level 0", but the inputVentilatorPower value stays on 17 all the time.

Unfortunately I cannot reboot the THZ currently, since I'm on vacation in Italy; so I just have remote access.

Any idea?
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

immi

HI willy
the problem is not related to THZ module nor to your tecalor:
from command ref

DOIF (Bedingung1)
(set ...) ## erster Befehl der ersten Sequenz soll um eine Sekunde verzögert werden
(set ...) ## zweiter Befehl der ersten Sequenz soll um 2 Sekunden nach dem ersten Befehl verzögert werden
DOELSEIF (Bedingung2)
(set ...) ## erster Befehl der zweiten Sequenz soll um 3 Sekunden verzögert werden
(set ...) ## zweiter Befehl der zweiten Sequenz soll um 0,5 Sekunden nach dem ersten Befehl verzögert werden

attr <DOIF-module> wait 1,2:3,0.5


I see 3 potential failures in your definition
1) the additinal comas between the commands
2) the redundant brackets
3) "attr extraVent_ALL cmdpause" which should be outside of the DOIF-definition, if addresing the same istance.

not sure of any: test it, otherwise post in the DOIF part of the forum, where the manteiner of DOIF can support you

enjoy your holyday, and avoid the football topic
immi

willybauss

Hi immi,

even if I try to set the level on the command line it doesn't work:

set Mythz p07FanStageDay 0
or
set Mythz p07FanStageDay 2

does not take any effect. I assume the DOIF's cmdpause to be inactive in this case, right?

The whole DOIF code looks like


DOIF
   (( ([extraVent_Wohnzimmer_value] == 3)
   or ([extraVent_Schlafzimmer_value] == 3) )
  and ([Mythz:sGlobal:[inputVentilatorPower. (\d+)]] < 55) )
        ((set Mythz p07FanStageDay 3),
(set Mythz p08FanStageNight 3),
(attr extraVent_ALL cmdpause 7200:7200:7200:7200),
{Log 1,"Ventilation set to level 3"})
DOELSEIF
   (( ([extraVent_Wohnzimmer_value] == 2)
   or ([extraVent_Schlafzimmer_value] == 2)
   or ([Mythz:Rel_humidity] > 70) )
and ( ([Mythz:sGlobal:[inputVentilatorPower. (\d+)]] > 55)
   or  ([Mythz:sGlobal:[inputVentilatorPower. (\d+)]] < 30) ))
        ((set Mythz p07FanStageDay 2),
(set Mythz p08FanStageNight 2),
(attr extraVent_ALL cmdpause 1:7200:7200:7200),
{Log 1,"Ventilation set to level 2"})
DOELSEIF
   (( ([extraVent_Wohnzimmer_value] == 1)
   or ([extraVent_Schlafzimmer_value] == 1)
   or ([Mythz:sGlobal:[dhwPump. (\d+)]] > 0) )
and ( ([Mythz:sGlobal:[inputVentilatorPower. (\d+)]] > 30)
   or  ([Mythz:sGlobal:[inputVentilatorPower. (\d+)]] < 10) ))
        ((set Mythz p07FanStageDay 1),
(set Mythz p08FanStageNight 1),
(attr extraVent_ALL cmdpause 1:1:7200:7200),
{Log 1,"Ventilation set to level 1"})
DOELSEIF
    ( ([extraVent_Wohnzimmer_value] == 0)
  and ([extraVent_Schlafzimmer_value] == 0)
  and ([Mythz:sGlobal:[inputVentilatorPower. (\d+)]] > 10)
  and ([Mythz:sGlobal:[dhwPump. (\d+)]] == 0)
  and ([Mythz:Rel_humidity] < 60)
  and ([RandomTimer_BinAbwesend] eq "ja") )
        ((set Mythz p07FanStageDay 2),
(set Mythz p08FanStageNight 0),
(attr extraVent_ALL cmdpause 1:1:1:7200),
{Log 1,"Ventilation set to level 0"})


As you see the cmdpause's are set intentionally, to allow switching to higher levels immediately, but reject switching to lower levels for 2 hours. This is the most important part of the code to avoid switching up and down too often.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

#415
Another idea: may p09FanStageStandby be active as long as vacation time is set via the pHoliday* settings? I have to check the THZ manual.

btw:
Yesterday we had a nice evening in Pisa downtown, open air public viewing incl. fish and Chianti. But most of the visitors clapped their hands in wrong situations  ::) ... Both teams had been equal, just good luck on our side. Don't worry.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

#416
Zitat von: willybauss am 03 Juli 2016, 12:47:33
Another idea: may p09FanStageStandby be active as long as vacation time is set via the pHoliday* settings? I have to check the THZ manual.

Manual is not really clear on these details, but

set Mythz p09FanStageStandby 0

sets the level to 0. So I have to enhance my DOIF for vacation times. As an immediate solution I'll switch off vacation mode and accept heating up DHW once per day.

immi:
Is there a flag indicating current state of vacation mode, or do I need to calculate it dealing with all these pHoliday* variables? A flag would be a nice feature  ;)

edit:
pOpmode might be the right one, but missing in commandref. I try to find in source code of module.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

I'm a bit confused:

get pOpMode

reports "DHWmode", no matter if vacation mode is set or unset. But as I mentioned above: ventilation in vacation mode behaves as it was in standby mode. So pOpMode doesn't seem to report the right value in case of vacation, at least for ventilation.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

immi

Sometimes I complain on the missing documentation of the tecalor.
But I assume that the main issue is the missing logic in the registers of the firmware.
The more we reverse eng. the more we see very strange things.

pOpMode should be the one to look at... but :(

try to look in sHC1, there is another opMode

immi

willybauss

Zitat von: immi am 03 Juli 2016, 14:45:13
try to look in sHC1, there is another opMode

Thanks for the hint. sHC1.opMode is the right one:
==> standby in case of vacation
==> setback in normal case

So I need to enhance the DOIF by this value.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS