THZ / LWZ Tecalor Stiebel Eltron Heizung

[willybauss]

So langsam wirds Zeit für einen Vergleich heatpumpMonitor vs. FHEM.
Noch habe ich beim  heatpumpMonitor Features, die ich in FHEM noch vermisse:

   
• hübsche, übersichtliche Darstellung der wichtigsten Momentanwerte: sicher eine reine Fleißaufgabe
• Email im Alarmfall (Ausfall, Booster aktiv, ...); das kann man vermutlich mit etwas googeln irgendwie einrichten
• die Liste der Fehlercodes incl. Beschreibung der Fehlersuche (Kopie aus dem Manual): sicher ebenfalls eine reine Fleißaufgabe, da purer Text
• mehrere verschiedene Graphen für unterschiedliche Zeiträume: in FHEM ersetzt durch die Zoom-Möglichkeit

Das ist alles nicht so tragisch. die wirklichen Unterschiede sind:


Die Protokollverarbeitung:
In FHEM ist das Protokoll tief im Sourcecode vergraben. Bei anderer Firmwareversion wirds richtig richtig schwer, das Ding wieder ans laufen zu bekommen. Bei jedem Update der 00_THZ.pm darf man dann seine manuellen Anpassungen wiederholen. 
Der heatpumpMonitor hat die Protokolldefinition ausgelagert in Protocol.ini Dateien. Neue Firmware mit geänderter Datenstruktur => neue ini Datei erstellen, anwenden, fertig. 


Die Art der Datenverarbeitung:
Der HeatpumpMonitor liest die Daten aus und verarbeitet sie sofort:

   
• die wichtigsten Momentanwerte kommen in eine winzige json Datei.
• Die Datenhistory fällt in eine Round Robin Datenbank. Dabei ist bereits beim Erstellen der Datei definiert, wie groß sie ist und welche Daten in welchen zeitlichen Abständen sie enthält (und welche nicht  ); alte Werte fallen raus, neue kommen hinzu ==> Dateigröße ist konstant. Wenn neue Werte dazu kommen sollen oder sich an der Zeitlichkeit etwas ändern soll muss die RRD Datei neu erstellt werden => die History ist weg. 
• Aus der RRD werden unmittelbar nach dem Auslesen die Grafiken als Bitmaps erstellt (.png format). Dadurch ist der Raspi ziemlich genau 60 Sekunden beschäftigt, bis alles verarbeitet und übers Netz auf den Server geschrieben ist.
• In definierbaren Zeitabständen (ich wählte 15 Minuten) werden die Daten (json-datei und .png-Grafiken) auf einen Webserver außerhalb meiner Firewall geschoben. Dadurch habe ich immer und von überall Zugriff, ohne den Flaschenhals des DLS-Uploads. 

FHEM liest die Daten nur aus und schreibt sie ins log-File (pure ASCII).

   
• kleinere Aufbereitungen wie Offsetwerte, um falsch messende Sensoren zu kalibrieren, sind dann auch gleich in den Log-Daten drin.
• Es gibt eine wesentlich größere Zahl von Daten, für oder gegen deren Nutzung man sich zunächst gar nicht entscheiden muss. Wenn man später merkt, dass man doch etwas braucht, baut man sich eine Grafik und wendet sie auf die bereits vorliegenden Daten an. 
• Die Datenmenge kann problemlos im laufenden Betrieb erweitert werden. Neuere Einträge im log enthalten dann eben mehr Werte als alte. 
• Dadurch entsteht aber ein ständig anwachsendes Datenaufkommen. Beim auslesen der Daten im 1-Minuten-Raster kommen so ca. 1,6MB pro Tag zusammen. Zum Vergleich der heatpumpMonitor: 750kB einmalig für das RRD File, plus einmalig 1,1MB für die png-Grafiken (die immer wieder überschrieben werden). Das klingt fast gleich, ABER: nach 1 Jahr sind es beim heatpumpMonitor immernoch 1,1MB (das RRD-File braucht man zum ansehen der Daten nicht); bei FHEM aber sind es schon 600MB. 

Womit wir beim Webzugriff wären:

   
• heatpumpMonitor immer gleichbleibend 1,1MB, um alle Daten zu sehen
• FHEM anfangs auch so, nach 1 Jahr aber schon 600MB  (=> Flaschenhals DSL-Upload !!!) 

So kann man natürlich nicht arbeiten. Ich kann nicht jede Minute 600MB auf den Webserver schreiben. Evtl. könnte man auch über ftp die Daten  inkrementell schreiben. Aber beim auslesen sind es immernoch 600MB.
Zugegeben: ich bin vom heatpumpMonitor verwöhnt; man kann sich auch mit 2 oder 3 Minuten-Rastern zufrieden geben. Aber das verringert das Problem nur, wirklich gelöst wird es nicht. Und Lösungen wie "lege doch jeden Monat ein neues log-File an" sind eine Krücke.

An dieser Stelle bin ich noch nicht zu einer Lösung gekommen. Evtl. werde ich doch wieder Bitmaps erstellen und per ftp online stellen. Es sei denn mir fällt noch was besseres vor die Füße. Es müsste doch irgendwie gehen, dass man die Plots in Bitmap-Dateien schreibt und alle 15 Minuten per ftp auf einen Webserver schiebt. Wenn man sich auf das Aller nötigste beschränkt kommt man da mit 100 - 200kB gut hin.
Das Szenario ist dabei: ich bin ein paar Tage weg, die Heizung spinnt. Bevor meine Frau zuhause kalte Füße bekommt kann ich ihr schon Bescheid sagen, wie sie den Fehler beheben kann - weil ich

   
• per Email über den Ausfall benachrichtigt werde
• den Fehler anhand der Daten (hoffentlich) identifizieren kann
• in der o.g. Onlinedoku die Fehlerursache einkreisen kann

Letzter und für mich entscheidender Unterschied: Werte schreiben, d.h. die Wärmepumpe nicht nur kontrollieren, sondern auch steuern.
Der heatpumpMonitor hat da gar nichts anzubieten; das Projekt ist tot, von ehemals maßgeblichen Entwicklern bekommt man auf Anfragen gar keine Antwort.

FHEM scheint das zu können - ich habs noch nicht versucht. Aber ohne Risiko ist das nicht, weil ... sh. Protokoll-Story weiter oben ... Wenn der Servicetechniker eine neue Firmware aufspielt und man lässt die alte FHEM-Steuerung drauf los, kann man sich einiges kaputt machen, falls sich die Registeradressen geändert haben.
Dennoch werde ich das angehen. Ziel ist z.B. eine sinnvolle Steuerung der Passivkühlung im Sommer. Warum muss ich der Anlage erst per Displaytastatur sagen, dass ich ein Fenster aufgemacht habe, und dass sie jetzt Passivkühlung Mode 1 wählen soll? Das Fenster soll gefälligst selbst Vollzug an FHEM melden, und FHEM meldet dann der THZ was zu tun ist. Und wenn ich mitten in der Nacht wegen pöbelnder Disco-Heimkehrer das Fenster im Schlafzimmer zu mache, dann kann FHEM ohne mein Zutun von Passivkühlung Mode 1 auf Mode 2 umschalten, damit ich nicht im Schlaf ersticke.


Wenn man lange genug nachdenkt fallen einem sicher noch ein paar weitere Steuerungsanwendungen ein. Man sollte sich halt gut überlegen, ob man auch so riskante Sachen wie Heizkreispumpe und Booster anfasst. Wenn man sich da vertut ... 

[micomat]

wow da brauch ich ja fast n bier bis ich den text durch hab
du darfst fhem nicht mit dem heatpumpmonitor vergleichen. die ziele beider systeme sind grundegend verschieden. das eine ist nur dazu da die wärmepumpe auszulesen das andere ist ein komplexes system zu heimautomatisierung in das die waermpepumpe erst seit wenigen wochen integriert werden kann.

mal ein paar auskuenfte zu einigen deiner punkten:
eine email im alarmfall kann auch FHEM verschicken, musst du nur implementieren. du kannst die errorcodes abfragen und natuerlich auch ob die wp verbunden ist.

die grafikerstellug ist in fhem grundlegend anders als in heatpumpmonitor (hpm).
beides hat vor- und nachteile.

wenn du selbst entwickelst und aenderungen einpflegst oder das gerne haettest, dann kann immi das sicherlich fuer dich einbauen. er ist diesbezueglich sehr kommunikativ. ansonsten richtig, musst du deine eigenen aenderungen wieder einbauen.

zum logging: es gibt bereits die moeglichkeit die daten statt in textfiles in eine sql-db zu schreiben. noch effizienter als json
uebrigens ich hab eine 50MBit/s leitung, also mir is die dateigroesse "wurschd"
du kannst alernativ die logfiles auch in monatliche logs unterteilen. da wuerde die einzelgroesse reduzieren.

das mit dem schreiben habe ich ausgiebig getestet funktioniert perfekt.
am einfachsten kannst du das mit der luefterstufe testen. einfach mal die tag-stufe erhoehen oder reduzieren. da kann eigentlich (natuerlich gibts ne garantie nicht) nix schief geben da die hex-daten die dabei uebertragen werden bei einem fehler einfach verworfen werden sofern sie nicht unwahrscheinlicherweise ein anderes gueltiges register treffen.

ich hatte vorher auch hpm und habe erst nach etwas zoegern komplett auf fhem umgestellt. nicht zuletzt dank der unterstuetzung und der programmierung von immi
und da ich hier einfach viel mehr potential sehe als beim schon toten hpm habe ich mich auch hierfuer entschieden. mit allen vor- und auch den nachteilen. erstere ueberwiegen aber fuer mich
die eierlegende wollmilchsau wirds wohl nie geben, aber fhem kann einfach viel viel viel mehr als hpm und ist somit fuer mich erste wahl.
vielleicht kann dein upload-thema ja mit dblog geloest werden? dann brauchst du garnix uploaden sondern kannst (je nach fritzbox oder router) per vpn deine daten direkt im fhem sehen.
http://www.fhemwiki.de/wiki/Neues_Charting_Frontend#DbLog_installieren_und_konfigurieren

gruß
markus

[Heiner]

Hi Immi,
long time not spoken. I am very happy about this very interactive page and all the Progress in the Software.

I have as well playd a lot with this SW and it is great. When I tried to set the next Holiday period, I was confused to see that somehow the internal time of THZ is not in sync wiht the normal time and fhem time, In fact the date was completly old and as i could not set it correctly from remote, I adjusted my Holiday accordingly..... But in fact all my Error. now I remember that the "timedate" get only read at start of fhem, therafeter it always looks outdated. Could I suggest in one of the next updates to hide this usually wrong Info? OR that it gets updated once I open the Parameter page of my THZ? OR it could say "timedate of last FHEM start"

reagrds Heiner

[micomat]

Hi Heiner,

as far as i can see the timedate is read all 8h (default setting) along with the history data. But if you set only the holiday time there should be no problem with the time setting at the heatpump.
Can you check the time setting at the display? Maybe the setting of time and date is wrong there?
What do you mean with "completely old" time?

EDIT:
sorry, just tested it it's not read with the history data.
But you can set an "at" command to read the timedate all x-min if you want to.

Markus

[willybauss]

Code Auswählen Erweitern

attr Plot_Temp plotsize 840,420
löst auch die Frage mit dem zu kleinen Plot. Sieht jetzt viel übersichtlicher aus.

[willybauss]

But this value could be correct. I don't know where your humidity sensor is, but my three sensors in our house reporting me rel. humidity between 27% and 34% depending on the room.
I believe that this is a special problem of ventilation systems with a cross counterflow heat exchanger (Kreuzgegenstrom Wärmetauscher) as this system is also dehumidifying the air.

I simply put three different weather stations (different models, different manufacturers) close to the external display, where the humidity sensor is built in. All three reported exactly same value, but external display of heatpump was 11.5% off. So I believe that these three are right and just one is wrong.
Question is still, if it's an additional offset or a factor. This question can be answered in summer, when humidity will rise typically.

[micomat]

Sounds like a high Quality sensor 
EDIT:
according to the Installation Manuals of the THZ, there is no Offset for humidity Sensors.
maybe its defect? still covered by guarantee?

[immi]

Hi Heiner
happy that you are back; you were the first tester of 00_THZ.
concerning timedate you can always look at the right colum, which you should compare with the middle one: middle is timedate of the tecalor, right is the timestamp of your linux computer when the reading has been taken.
I have an offset of 22seconds.

The information is read only by fhem start automatically. I do not see any need for periodic update. I find the information relevant if current goes away and I am abroad. I do not know how long the tecalor internal timer keeps the time without current.

immi

[willybauss]

vielleicht kann dein upload-thema ja mit dblog geloest werden? dann brauchst du garnix uploaden sondern kannst (je nach fritzbox oder router) per vpn deine daten direkt im fhem sehen.
http://www.fhemwiki.de/wiki/Neues_Charting_Frontend#DbLog_installieren_und_konfigurieren

Auch dann habe ich den Upload als Flaschenhals. Aber mit ner sqLite DB wäre ich aus dem Thema raus, dass das ganze Textfile gelesen werden muss. Das könnte den Traffic deutlich verringern.
Mir ist allerdings noch nicht klar, wie ich die Daten da rein bekomme. Das 00_THZ Modul schreibt ja definitiv ins Textfile. Ich muss mir mal an einem verregneten Wochenende das Thema DbLog rein ziehen.

[willybauss]

according to the Installation Manuals of the THZ, there is no Offset for humidity Sensors.
maybe its defect? still covered by guarantee?

I'm pretty sure there's no warranty at all for a THZ display which I got from Ebay for 21,50€ ... The sensor works basically. As long as I can manage the issue by offset correction it's ok for me.

[immi]

Hi Willi

Das 00_THZ Modul schreibt ja definitiv ins Textfile. Ich muss mir mal an einem verregneten Wochenende das Thema DbLog rein ziehen.

not correct; 00_THZ does not write in text file. I write back to fhem global variables, called readings. The module FileLog is writing  the readings to a file, as DBlog could write to  a database.

immi

[micomat]

I'm pretty sure there's no warranty at all for a THZ display which I got from Ebay for 21,50€ ... The sensor works basically. As long as I can manage the issue by offset correction it's ok for me.

lol thats the reason...

[willybauss]

Ich folge grade dem Rat von micomat und versuche auf das neue Charting Frontend zu wechseln. Dabei kommt es noch zu (für mich) ungeklärtem Fehlverhalten.
Die fhem.cfg sieht grade so aus:

Code Auswählen Erweitern

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
define myDbLog       DbLog   /mnt/fhem/db.conf             Mythz

Die letzte Zeile ist fürs schreiben in die Datenbank hinzugekommen, die erste existiert nur wegen der früher beschriebenen Problematik mit den Offsets der Sensoren.
Wenn ich nun im neuen Frontend ein Chart bauen will, dann sehe ich zwar inside_temp und Rel_humidity in der Liste der möglichen Daten für die Y-Achse (das kommt dann aus der 1. Zeile), aber alle Werte von allFB sind in einem einzigen Datenbankeintrag als String enthalten. Den kann das Frontend nicht auflösen, um die Werte darzustellen. Ich habe dann mal die Syntax von FileLog und DbLog lt. CommandReference verglichen; dabei fällt mir nichts ungewöhnliches auf. Es heißt bei DbLog sogar ausdrücklich "<regexp> ist identisch wie FileLog." Demnach sollte "Mythz" als <regexp> ja funktionieren - tut es aber nicht.  


Vermutlich gibt es auch an dieser Stelle wieder eine ganz einfache Lösung, die ich aber nicht kenne. Mir fällt spontan nur ein, alle Werte von allFB nochmal separat zu definieren änlich wie in der 1. Zeile (attr Mythz userReadings ...). Das klingt aber ziemlich aufwändig - auch für den Server.


Gibt es was einfacheres?

[immi]

Hi Willi
keep it simple, start without DBLOG and FILElog.
Are you sure you have 81 separated words in allFB?

immi

[micomat]

Hi immi,

thats possible, the collector temp is on my position 83