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

[immi]

Hi andre
i implemented your suggestions for  nonblocking and committed.
My strategy is that if you are calling manually a "set" or a "get" you should have priority.
I am still not very happy with sub THZ_AvoidCollisions.
I am still not very happy with the many opening and closing of the interface.
But it is a nice start 
immi


dear all
added attribute  nonblocking:0,1
the functionality is very very beta
without the attribute the module will behave as before

[andre.k]

Hi immi,

many thanks. I'm testing the new version next weekend. I just had a look in the svn.

My strategy is that if you are calling manually a "set" or a "get" you should have priority.

that's difficult to achieve

I am still not very happy with sub THZ_AvoidCollisions.

yes it is pretty raugh

Andre

BTW: I don't like all these select statements just to wait, because these are blocking the global fhem loop.

[andre.k]

Hi immi,

v168 is running and works fine. Thank you again.

I've still a problem with the function THZ_AvoidCollisions. The function is called from time to time, even in the backround. For checking, I commented out the call from THZ_Get, because this function ist called from nonblocking in the backgrout. No change, AvoidCollisions is still called (entries in log file).

Code Auswählen Erweitern

Possible collision in myWP was aborted
Second I additionaly commented out the THZ_AvoidCollisions from THZ_Set and everything is fine. It is silly because the THZ_Set is never called in backround. Do you have an idea?

Andre

[immi]

I've still a problem with the function THZ_AvoidCollisions. The function is called from time to time, even in the backround.

THZ_AvoidCollisions. is always called by THZ_Set and THZ_Get.
it checks if there is {RUNNING_PID}, otherwise returns
The non-blocking process do not have {RUNNING_PID}; therefore return.
Only parents, which have a non-blocking child, have {RUNNING_PID}.

Let us say you want a THZ_Set or a THZ_get from front-end, you check if a child is running by defined{RUNNING_PID} and kill it.
Please help me undertanding, where you see an issue.

Second I additionaly commented out the THZ_AvoidCollisions from THZ_Set and everything is fine. It is silly because the THZ_Set is never called in backround.

THZ_AvoidCollision should kill everything  in the background and priotize the front-end.
Therefore it is also important for THZ_Set, because there could be a Get in the background..

immi

[andre.k]

THZ_AvoidCollision should kill everything  in the background and priotize the front-end.
Therefore it is also important for SET, because there could be a Get in the background..

Understood, but I never did a SET in the WEBGUI and nevertheless I got entries in the Logfile. Where are the SET calls come from?

Let us say you want a THZ_Set or a THZ_get from front-end, you check if a child is running by defined{RUNNING_PID} and kill it.
Please help me undertanding, where you see an issue.

There is no issue. The approach is ok. But somehow child processes are killed although I do not set/get in front-end.

[immi]

Understood, but I never did a SET in the WEBGUI and nevertheless I got entries in the Logfile. Where are the SET calls come from?

I set interactively from webgui and from doif, on a regular basis
For both I want a syncronous answer, and if possible a 99.999% success rate.

There is no issue. The approach is ok. But somehow child processes are killed although I do not set/get in front-end.

This cannot and should not happen. I cannot look at it on the short term. Maybe  in the next holiday
immi

[andre.k]

Hi immi,

This cannot and should not happen

My Log is full of entries

Code Auswählen Erweitern

2017.08.13 23:06:08 3: Possible collision in myWP was aborted

I debuged that the SET function is called regulary with the following paramter:

Code Auswählen Erweitern

2017.08.16 09:31:00 1: DEBUG>myWP Set: ?

Maybe the Set function is called from the FHEM main loop to check the valid Set commands of the modul. To fix this we can move the THZ_AvoidCollisions function call after the first if-block.

Code Auswählen Erweitern

    return "Unknown argument $cmd, choose one of  $setList";
  }
 
  return "\"set $name $cmd\" needs at least one further argument: <value-to-be-modified>" if(!defined($arg));

  Debug("$name Set: $cmd $arg");
  THZ_AvoidCollisions($hash);
 
 
  my $cmdHex2 = $cmdhash->{cmd2};
  my $argMax = $cmdhash->{argMax};
  my $argMin = $cmdhash->{argMin};
 
  #-- check the parameter range
  if ($cmdhash->{type} =~ /7prog|8party/) {         
    ($arg, $arg1)=split('--', $arg);


Could you please extend the range of timeout values in your next release.

Code Auswählen Erweitern

            ."simpleReadTimeout:0.25,0.5,1,2,3,4,5,6,7,8,9,10 " #standard has been 0.5 since msg468515

Andre

[immi]

Maybe the Set function is called from the FHEM main loop to check the valid Set commands of the modul. To fix this we can move the THZ_AvoidCollisions function call after the first if-block.

Your hypothesis is correct.
the webinterface calls THZ_Set in order to know which possibilities/registers  THZ_Set offers.
Moving the call to THZ_AvoidCollisions after line 942, will fix the issue.
The same is for THZ_Get, for which THZ_AvoidCollisions should be after after line 1158
Would you be so nice to test it? I cannot untill weekend

Could you please extend the range of timeout values in your next release.

I wanted to double them in case blocking_call parameter is enabled.
I do not want to have 8 seconds in the background with blocking

[andre.k]

Hi immi,

Would you be so nice to test it? I cannot untill weekend

I've tested. It's working.

I wanted to double them in case blocking_call parameter is enabled.
I do not want to have 8 seconds in the background with blocking

I would implement in the other way round. If blocking attribut is NOT enabled then set the timeout value to a maximum value of 0.5 sec. So even the user selects an higher value, the timeout is set to 0.5 sec.

Andre

[immi]

I would implement in the other way round. If blocking attribut is NOT enabled then set the timeout value to a maximum value of 0.5 sec. So even the user selects an higher value, the timeout is set to 0.5 sec.

good idea

v 0.169 uploaded
ciao
immi

[andre.k]

Hallo an alle,

mich würde mal interessieren, wer noch das Nonblocking-Feature nutzen würde und dann seine Erfahrungen mitteilen könnte? Hat außer mir noch jemand eine THZ mit der alten Firmware 2.xx? Ich vermute nur die alten Modelle der THZ haben das Problem mit den sporadisch auftretenden Timeouts beim Warten auf Antwort. Vielleicht liegt es auch an der alten Hardware (serielles Inteface mit 9600 bps). Wie auch immer. Über Feedback wäre ich dankbar.

Andre


 

[willybauss]

Hallo an alle,

mich würde mal interessieren, wer noch das Nonblocking-Feature nutzen würde und dann seine Erfahrungen mitteilen könnte? Hat außer mir noch jemand eine THZ mit der alten Firmware 2.xx? Ich vermute nur die alten Modelle der THZ haben das Problem mit den sporadisch auftretenden Timeouts beim Warten auf Antwort. Vielleicht liegt es auch an der alten Hardware (serielles Inteface mit 9600 bps). Wie auch immer. Über Feedback wäre ich dankbar.

Andre

Ich verfolge das jetzt schon ne Weile, bin aber grade nicht in der Lage, mich da reinzudenken. Deshalb:
Was macht es?
Wie erkenne ich, ob ich es brauche?
Welchen Vorteil habe ich davon?
Welche Nachteile?
Wie aufwändig ist es zu implementieren?
...

[immi]

Ich verfolge das jetzt schon ne Weile, bin aber grade nicht in der Lage, mich da reinzudenken. Deshalb:
Was macht es?
Wie erkenne ich, ob ich es brauche?
Welchen Vorteil habe ich davon?
Welche Nachteile?
Wie aufwändig ist es zu implementieren?

Hi Willy
As you know FHEM is blocked when 00_THZ is talking to the heatpump (no parallel processing).
This is not a problem if your communication with the heatpump is fast; but if your comunication takes some seconds for each register, fhem is not responsive anymore.
Andre and me are trying to develop a non-blocking 00_THZ.pm
It is very important for old heatpumps with serial inteface 9600bps.
There are some drawbacks on non-blocking actual implementation
1) more memory is allocated
2) more computing power is needed
3) devio (both serial interface management and ser2net) has to be improved or newly written
4)  if you are calling manually a "set" or a "get" you should have priority; I am not sure that it is working properly: no time to test carefully
5) lots of logs entries



If you still want to test it
- attribute simpleReadTimeout 3   ## you give up to 3 seconds to the heatpump to react
- attribute nonblocking 1              ## you enable nonblocking

If not, you will not see or experience any drawback

ciao immi

[andre.k]

Ich verfolge das jetzt schon ne Weile, bin aber grade nicht in der Lage, mich da reinzudenken. Deshalb:

...

immi ist mir zwar zuvorgekommen, aber ich hole mal etwas weiter aus.

Was macht es?

1. FHEM arbeitet normalerweise nicht Multi-Tasking, d.h. alle FHEM-Module laufen in einzigen Prozess des Betriebssystems. Die einzelnen Module (bzw. die Funktionen z.B. Get oder Set) werden durch die FHEM-Hauptschleife aufgerufen. Das erfordert, dass sich jedes Modul kooperativ verhält und die Modulfunktionen so wenig wie möglich Zeit verbrauchen und so schnell wie möglich die Kontrolle wieder an die Hauptschleife zurückgeben. Eine einzelne Modulfunktion darf das Gesamtsystem nicht blockieren, z.B. indem sie auf eine Antwort von einem externen Gerät (in unserem Beispiel die THZ) wartet. Wenn nun aber, wie in meinem Fall das Gerät (THZ) doch länger benötigt, um seine Daten bereitzustellen, kann man das Warten/Lesen in einen eigenen Prozess auslagern. Dazu stellt FHEM ein Modul Blocking.pm zur Verfügung. Das haben wir jetzt im THZ-Modul integriert. Damit ist es möglich den Read-Timout auf höhere Werte (bis 10 sec) einzustellen, ohne dass FHEM blockiert wird.

Wie erkenne ich, ob ich es brauche?

Wenn man viele Timeout-Meldungen

Code Auswählen Erweitern

"THZ_ReadAnswer: InterfaceNotRespondig. Maybe too slow"

im Logfile hat (bei mir waren das machmal über 100 pro Tag) kann es sinnvoll sein, den Read-Timeout zu erhöhen und das Feature Non-Blocking zu verwenden. Ein Timeout beim Lesen bedeutet ein verlorener Wert in den Readings und damit im Logfile und das kann unter Umständen bei den Plots unschöne Effekte haben.

Welchen Vorteil habe ich davon?

Der Vorteil ist, dass beim Refresh der Readings im Hintergrund keine Werte mehr verlorengehen.

Welche Nachteile?

Es gibt aktuell keinen Nachteil aus Anwendersicht. Das Feature ist allerdings noch nicht so umfassend getestet und einige Dinge sind intern noch nicht optimal gelöst.

Wie aufwändig ist es zu implementieren?

Das Feature wird über zwei Attribute im Modul THZ gesteuert:
1. Das Atrribut "nonblocking" schaltet das Feature ein/aus (1=ein, 0=aus). Standartmäßig, d.h, wenn das Attribut nicht vorhanden ist, ist das Feature ausgeschaltet. Man hat also dann das gewohnte Verhalten.
2. Das Attritut "simpleReadTimeout" legt die Zeit fest, die Maximal auf eine Antwort von der THZ geartet wird. Hier kann man den optimalen Wert ausprobieren. Je höher der Wert, desto weniger Fehlermeldungen sollten im Logfile erscheinen. Bei mir habe ich den Wert auf 8 sec. gesetzt. Hinweis: Die Wartezeit wir intern begrenzt, falls das nonblocking nicht auf 1 gesetzt wurde. Damit wird verhindert, dass THZ blockiert.

[willybauss]

Könnte das eine Erklärung sein für das Problem, das ich vor einiger Zeit beschrieben hatte?:

Hi immi,

my logfile shows frquent (3 ... 6 times per day) messages saying

Code Auswählen Erweitern

Mythz THZ_ReadAnswer got no answer from DevIo_SimpleRead. Maybe too slow?

This is not a new effect, I know it since years, and everything works fine. But from time to time I wonder if I can do something to avoid it. Is there a user accessible value to e.g. increase wait time?

und

Hi immi,

I don't think it's increasing. I believe I have these entries since 2 years or so. Normally I don't even check the logfile contents, as long as it stays small in monthly size. But currently I try to find the root cause, why my Homematic CUL stops working frequently; needs a 'reopen' then. I observed an approx. 70 ... 80% match of times tamps between CUL stop and these THZ entries. CUL stop happens approx. 2 ... 3 times per month. So I don't believe that CUL is root cause for THZ issue, but I think its the other way round - THZ issue might be cause for the CUL to stop working.

For that reason I wonder if increasing wait times may help. Is fhem blocked during these wait times? If yes, the CUL issue wouldn't be healed by increasing wait times further. I need to try it out. How long may these wait times be - few seconds?

As I understand, the message tells me that Mythz sends a request to the THZ, and the answer doesn't come in expected time frame, right? What can I do to have the THZ's answer earlier? Nothing I guess, right? I have a serial connection with approx. 4 - 5m cable. The cable ends in a serial-USB converter. The converter is plugged into an USB hub, directly connected to RaspberryPi's USB port.

Since the CUL issue happens very rarely we shouldn't expect an answer within weeks. We need to think in months though. I'll let you know as soon as I have any answers.

Thanks so far. Have a nice weekend.
Willy

I had not yet time to change the cable against a shielded one, as immi suggested in an answer to this post. I'll do so in winter time.