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

[willybauss]

I see a difference of 24 seconds - so the code using 23:59:00 should have worked  .

[immi]

I see a difference of 24 seconds - so the code using 23:59:00 should have worked  .

Willy
if you are using a RasPi, for sure you update the time at boot from internet (no real-time clock)
How often you update time afterwards?
If you google, you should see that a RasPi could drift half-a-second every hour.

As opposite, the heatpump has a real-time clock.
immi

[willybauss]

I sync all of my computers, including Raspi but excluding THZ, once per day using my Fritz box as time server. Fritz box is being synced once per day with an internet time server.

[micomat]

All,

I've just updated the release history in both (DE/EN) Wiki pages and added some corrections.
Thanks to Rene for preparing all the data.

Markus

[immi]

Thanks Markus and Rene.!!

[mlb]

@immi

I'm just testing the new raspberry pi 2 with Fhem. In general it is a bit faster, but also I have noticed that perl uses just a single thread when generating graphs - so there is no real benefit from 4 cores new raspi is equipped with. I was just wondering if this is something you could consider for the future, or the chart generation is outside of THZ module?

[immi]

I'm just testing the new raspberry pi 2 with Fhem. In general it is a bit faster, but also I have noticed that perl uses just a single thread when generating graphs - so there is no real benefit from 4 cores new raspi is equipped with. I was just wondering if this is something you could consider for the future, or the chart generation is outside of THZ module?

Hi
fhem is single thread,
some effort is made in 4 directions:
1) taking the computation out of server and into client
2) generating plots in advance; this could be triggered with "notify" or "at" http://www.fhemwiki.de/wiki/Creating_Plots_-_caching_SVG%27s
3) http://www.fhemwiki.de/wiki/Blocking_Call
4) SubProcess.pm  http://forum.fhem.de/index.php/topic,34320.0.html . I am testing it and there is lots todo.

nevertheless for speeding up multiple plots, file access speed should be increased.
To my opinion, the bottleneck is reading 4 or 5 times the huge logsfiles.
My feeling is that in some cases, for generating graphs, a good RAM-caching strategy is very effective; have you tried using a ramdisk for logs?

If you are an expert with perl-multithreading (a nice oxymoron), or you have lots of time please get involved.
immi

[mlb]

I'm far from being a good developer, although yes, a while ago I did some small development myself for home automation, including multi-threading in C - just never in Perl...

nevertheless for speeding up multiple plots, file access speed should be increased.

I actually tested that at first instance Since the new raspi has 1GB of RAM, I created ramdisk and copied log files there - easy thing to do, you just need

Code Auswählen Erweitern

sudo mkdir -p /ram
sudo mount -t tmpfs -o size=50m tmpfs /ram
sudo chmod 777 /ram
and ramdisk is at  /ram, where 50m is the size, 50 Megabytes in my case.  Then of course not to lose log files in case of power failure - they can be periodically synchronized with non-volatile storage, preferably via rsync.

Then I had a look at htop to see how the new hardware is handling Fhem and saw just a single core at 100% - that's where my question was coming from.

No problem - this is not a must-have feature, although a good home automation system in my opinion should use multi-threading - separate threads to handle separate external devices, as they usually communicate in asynchronous mode. In my home automation system devices communicate over IP, commands are sent via http and statuses broadcasted via UDP. It works very well, just since Fhem seems to be single-threaded - I have some doubts I could successfully integrate it, also because of language barrier I have when trying to understand other comments written in German.

[immi]

In my home automation system devices communicate over IP, commands are sent via http and statuses broadcasted via UDP. It works very well, just since Fhem seems to be single-threaded - I have some doubts I could successfully integrate it, also because of language barrier I have when trying to understand other comments written in German.

I have 160 defined entities (17 lights, 15 windowshutters, 10 termostate, gas-sensor, heatpump...) in fhem, which are working quite well together on a cheap NAS, where mail-server a web-server is also running.
FHEm code is improving every day, because many people are contributing. Multithreading will come, I am sure.

Concerning german... It is not my mother language, therefore, when I comunicate here I write in I-english.
Someone answer in D-english. Do not be scared of it.

Concerning perl. I am learning it by writing 00_THZ.pm.


p.s. I haven´t understood. Did you see an improovement with the ramdisk?
I must say, that I do not like the 100% CPU time; strange.

[mlb]

Nice I have similar, a bit larger size - around 250 outputs, 100+ inputs, 30+ DACs,  and a couple other things. The control logic is already there, written in C. I know is not very portable, but when I run it on old raspi - it only takes 4 to 5% of CPU.  I'm just lacking a good visualisation and reporting. I know I could use Fhem to send commands via http, just the problem is to collect statuses that are sent asynchronously over UDP.

p.s. I haven´t understood. Did you see an improovement with the ramdisk?
I must say, that I do not like the 100% CPU time; strange.

Yes, there was a noticeable improvement when using ramdisk. Still, when you have 4 graphs on the same page - there is some time to wait before Fhem refreshes all of them. And a single core of raspi 2 is about 50% faster than CPU on "classic" raspi (I have two of those).

By the way - it is easy to add RTC to raspi - I have something like this, based on DS1302 - working already for 2 years without problem, I actually combined it with NTP and created internal time server for my network.

[immi]

v 0139 uploaded
changelog: added pClockDay, pClockMonth, pClockYear, pClockHour, pClockMinutes

immi

[willybauss]

works perfectly, thanks.

Updating the THZ time monthly could look like

Code Auswählen Erweitern

define SetClockMinutes at *00:27:00 {if($mday == 1) { "set Mythz pClockMinutes 27" }}
attr SetClockMinutes room Heizung

(assuming that the drift is less than 27 minutes per month  )

[peter456]

I just uploaded v 0.137
changelog
heatcurve has been improved:
- 2 curves are now displayed: one with insideTemp influence (green), the other without(blue).
- heatcurve should support also old firmware (please Andre test it)

@Peter: I am happy if you are happy with the THZ module. Let Andre make the tests for your older firmware.

Hallo Andre.k,

hast du schon bei deiner LWZ die Heizkurve getestet?
Wenn das funktioniert, wie kann ich das bei mir einrichten?
Gruß
Peter

[immi]

Hallo Andre.k,
hast du schon bei deiner LWZ die Heizkurve getestet?
Wenn das funktioniert, wie kann ich das bei mir einrichten?

Hi Peter
It should work for everyone the same.

Code Auswählen Erweitern


define wl_hr2 weblink htmlCode <div class="SVGplot"><embed src="/fhem/THZ_PrintcurveSVG/" type="image/svg+xml" /></div> <a href="/fhem?detail=wl_hr2">wl_hr2</a><br>
attr wl_hr2 room heatpump

immi

[peter456]

Vielen Dank Immi.