THZ / LWZ Tecalor Stiebel Eltron Heizung

[belu]

Sorry to disappoint you. Even if there may be some coincidences this it not the case.

Two more FE responses from THZ 404 SOL (5.39):
03 b1 83 f5 00 01 00 ** ** ** 00 06 67 71 03 0b 4e 6f 76 20 20 39 20 32 30 31 31 20
03 b1 83 f5 01 00 00 ** ** ** 00 06 67 71 03 0f 4d 61 72 20 31 34 20 32 30 31 34 20

** - es handelt sich um die Seriennummer der Hauptplatine (sollte man vielleicht nicht posten)
Blau ist vermutlich die Hardware-Variante:
49 - THZ 303 SOL (willybauss)
4A - THZ 403 SOL (immi, PhyTHZ)
71 - THZ 404 SOL (toggle, godmorgon, *****)

Und in rot eine weitere Variante der SW-Versionsnummer:
02 05 => 2.05 (PhyTHZ)
02 08 => 2.08 (immi)
03 0b => 3.11 (*****)
03 0f => 3.15 (toggle, godmorgon)
03 10 => 3.16 (belu ?)
Und das ist der Grund, warum bei PhyTHZ manche Daten fehlen, obwohl er 4.39 wie immi hat.

Es wäre schon interessant zu wissen, wie der Softwarestand (2.06, 2.36, 3.19, 4.19, 4.39, 5.19, 5.39), die Software-ID und die SW-Versionsnummer mit Datum aus der FE-Message zusammenhängen. Jedenfalls kann der Softwarestand zumindest bei neueren Modellen verstellt werden, wie belu es hier  demonstrierte. Daher ist es kein Hardware-Attribut, sondern eher eine Protokoll-Version, die z.B. am CAN-Bus unterstützt wird.

Gruß
toggle

@ Toggle,

habe es nun verstanden und du hattest recht.

03B183F5000100 XX XX XX 000667710310104465632031302032303134201003

Antwort ist Date: DEC 10 2014

@Willy,

keine Ahnung, hab ne Raspberry aber per Mythz komm ich ja drauf, mit Verbose 5 komme ich ja auch so an die Daten. Ich war am überlegen mir ne BananaPI zu zu legen, hat mehr Power, bei gleichem Verbrauch. Denke dann ist das mit den Plots auch einfacher, was hälst davon?

LG

[belu]

sDisplay  switchingProg: 0 compressor: 1 heatingHC: 1 heatingDHW: 1 boosterHC: 1 filterBoth: 1 ventStage: 0 pumpHC: 0 defrost: 0 filterUp: 0 filterDown: 0

But just two icons are shown in display: compressor and DHW


insideTempRC: 23.1  worksperfectly, thanks a lot!

Also mein Feedback von sDisplay.

switchingProg: 0 compressor: 1 heatingHC: 1 heatingDHW: 1 boosterHC: 1 filterBoth: 1 ventStage: 0 pumpHC: 0 defrost: 0 filterUp: 0 filterDown: 0

Heizung ist aus, das einzige was aktuell aktiv ist sollte diese Schaltprogramm aktiv diese Sanduhr oder 2 Dreiecke, also das klappt so nicht so ganz richtig.

LG

[toggle]

Meine Vermutung bzgl. der Modell-ID ist wohl nicht ganz richtig. Belu hat auch 0x71, aber eine 304 SOL. Vielleicht ist es der Hardwarestand der Hauptplatine.

[belu]

@Toggle,

also das einzige was wichtig ist das ist das Datum der Software, das hat mir auch der Stiebel Eltron Monteur gesagt, diese Firmware ID 5.19 5.39 hat nur grob etwas zu sagen, diese beiden Firmware versionen sind gleich nur je nach Modell ist das eine oder das andere aktiv. Die Anlagen unterscheiden sich ja nicht wirklich außer in der größe der Wärmepumpe, hatte meine Anlage mal umgestellt und ihr gesagt du bist eine THZ 404 SOL hatte dann direkt Softwarestand 5.39 als ich zurück gestellt hatte auf die THZ 304 SOL hatte ich die 5.19.

Ich denke wir werden genau die selbe Platine drin haben, die ist denke ich bei allen neueren Geräten gleich. Meine Anlage ist vom März 2012. Hatte letztens halt einen Monteur da der mir die letzte Firmwareversion drauf gemacht hat. Er meinte es wäre 5.19 316 Dez 10 2014, habe ich auch so in der Update Software gesehen.

[willybauss]

keine Ahnung, hab ne Raspberry aber per Mythz komm ich ja drauf, mit Verbose 5 komme ich ja auch so an die Daten. Ich war am überlegen mir ne BananaPI zu zu legen, hat mehr Power, bei gleichem Verbrauch. Denke dann ist das mit den Plots auch einfacher, was hälst davon?

Gibt es dann aktuell überhaupt noch ein Problem?

Bevor Du auf BananaPi umsteigst logge Dich erst mal auf den Raspi ein und starte im Terminal ein "top". Dann wirst du wahrscheinlich sehen, das der Prozessor nur minimal belastet ist. Bei mir dümpelt er bei weniger als 5% Last herum, davon 0,7% perl. Der Raspi ist zumindest bei mir kein Flaschenhals.

Wenn Du mehr Last siehst (läuft da sonst noch was größeres außer fhem?) finde heraus, wer dafür zuständig ist und versuche dort, das Problem zu beheben.

> ...  dann ist das mit den Plots auch einfacher ...
Was ist Dein Problem bei den Plots?

[toggle]

switchingProg: 0 compressor: 1 heatingHC: 1 heatingDHW: 1 boosterHC: 1 filterBoth: 1 ventStage: 0 pumpHC: 0 defrost: 0 filterUp: 0 filterDown: 0

Ein Auszug aus dem Logfile für "get sDisplay" mit verbose=5 wäre hilfreich.

[belu]

Gibt es dann aktuell überhaupt noch ein Problem?

Bevor Du auf BananaPi umsteigst logge Dich erst mal auf den Raspi ein und starte im Terminal ein "top". Dann wirst du wahrscheinlich sehen, das der Prozessor nur minimal belastet ist. Bei mir dümpelt er bei weniger als 5% Last herum, davon 0,7% perl. Der Raspi ist zumindest bei mir kein Flaschenhals.

Wenn Du mehr Last siehst (läuft da sonst noch was größeres außer fhem?) finde heraus, wer dafür zuständig ist und versuche dort, das Problem zu beheben.

> ...  dann ist das mit den Plots auch einfacher ...
Was ist Dein Problem bei den Plots?

@Willy

das war damals eine von den ersten 1000 RaspberryPI hab damals preorder gemacht und das ist halt die ganz alte kleine, die Schreddert immer am Limit, hab da eigentlich nur Mini Debian drauf ProFtpd FHEM Apache.

Wenn ich gegen abend die Logfiles aktualisiere dauert der aufruf der Plots sicherlich so 2 Minuten. In der Zeit habe ich aber auch ne Load von 2,5

Allein wenn ich nun das Loglevel auf Verbose 5 gemacht habe und mit Nano in diese Datei gehen um sie auszuwerten, weil die Output von tail leider zu gering ist bekomme ich graue Haare.

[belu]

@toggle

jaja spart euch manpages tail, habe schon
Hab es auf 30 Lines erweitert nun kann man mit arbeiten.


2015.01.31 10:59:27 4: HTTP FHEMWEB:192.168.1.136:51763 GET /fhem&room=Heizung_Plot&cmd=Get+Mythz+sDisplay
2015.01.31 10:59:27 5: Cmd: >Get Mythz sDisplay<
2015.01.31 10:59:27 5: THZ_Get: Try to get 'sDisplay'
2015.01.31 10:59:27 5: THZ_Get_Comunication: Check if port is open. State = '(opened)'
2015.01.31 10:59:27 5: Mythz sending 02
2015.01.31 10:59:27 5: SW: 02
2015.01.31 10:59:27 5: Mythz start Funktion THZ_ReadAnswer
2015.01.31 10:59:27 5: THZ_ReadAnswer: uc unpack: '10'
2015.01.31 10:59:27 5: Mythz sending 0100820A01761003
2015.01.31 10:59:27 5: SW: 0100820A01761003
2015.01.31 10:59:27 5: Mythz start Funktion THZ_ReadAnswer
2015.01.31 10:59:27 5: THZ_ReadAnswer: uc unpack: '10'
2015.01.31 10:59:27 5: Mythz start Funktion THZ_ReadAnswer
2015.01.31 10:59:27 5: THZ_ReadAnswer: uc unpack: '02'
2015.01.31 10:59:27 5: Mythz sending 10
2015.01.31 10:59:27 5: SW: 10
2015.01.31 10:59:27 5: Mythz start Funktion THZ_ReadAnswer
2015.01.31 10:59:27 5: THZ_ReadAnswer: uc unpack: '0100830A017600011003'
2015.01.31 10:59:27 5: Mythz sending 10
2015.01.31 10:59:27 5: SW: 10
2015.01.31 10:59:27 5: Parse message: 830A01760001
2015.01.31 10:59:27 5: Message length: 12
2015.01.31 10:59:27 5: Triggering Mythz (0 changes)
2015.01.31 10:59:27 4: 14176:FHEMWEB:192.168.1.136:51763: /fhem&room=Heizung_Plot&cmd=Get+Mythz+sDisplay / RL:873 / text/html; charset=UTF-8 / Content-Encoding: gzip

es ist nur Schaltprogramm aktiv

Output switchingProg: 0 compressor: 1 heatingHC: 1 heatingDHW: 1 boosterHC: 1 filterBoth: 1 ventStage: 0 pumpHC: 0 defrost: 0 filterUp: 0 filterDown: 0

[willybauss]

@belu:
dann würde ich erst mal nen Versuch mit dem Raspi B+ machen. Wie gesagt: keinerlei Lastprobleme bei mir (B-Version). Wohin schreibst Du denn die Daten? Die sollten auf jeden Fall außerhalb der SD-Karte liegen. Sonst hast du langfristig ein Problem, da die Karte nur eine begrenzte anzahl Schreibzyklem mitmacht.

[toggle]

@immi
The offset for sDisplay is not correct - it should be 8-11 instead of 4-7 (830A01760001).

"0A0176Dis" => [[" switchingProg: ",   11, 1, "bit0", 1],     [" compressor: ",   11, 1, "bit1", 1],
         [" heatingHC: ",      11, 1, "bit2", 1],     [" heatingDHW: ",   10, 1, "bit0", 1],
         [" boosterHC: ",      10, 1, "bit1", 1],     [" filterBoth: ",   9, 1, "bit0", 1],
         [" ventStage: ",      9, 1, "bit1", 1],     [" pumpHC: ",      9, 1, "bit2", 1],
         [" defrost: ",      9, 1, "bit3", 1],     [" filterUp: ",      8, 1, "bit0", 1],
         [" filterDown: ",   8, 1, "bit1", 1]
         ],

[belu]

@Willy

also die Daten schreib ich nach /mnt/fhem/log/ das ist natürlich auf der SD Karte. Hatte zu anfang mal überlegt ob ich ne Ramdisk mache, aber das ding hat nur 256 mb und nunja die sind halt immer voll belegt. Ganz nebenbei sind sie halt weg wenn man sie Rebootet und es auf der Ramdisk war.
Die Lösung ist nicht ganz optimal, aktuell vom Januar hab ich 8,7mb Daten. Wenn ich einen Plott aufruf geht er die ja durch.
Also 256 mb der alte 700 mhz Singlecore.... Sprechen dafür sie einfach mal zu ersetzen.
Hab ihn jetzt einfach mal übertaktet, vielleicht bringt das was...
Der Ram ist ja geteilt für CPU und GPU hab mal GPU nur noch auf 16 mb gesetzt, ist ja eh kein Display und X drauf...

[willybauss]

Zur Abwechslung mal eine praktische Anwendung der ganzen Mythz-Datenloggerei: ich habe aus den geloggten Daten ein neues Diagramm erstellt, um die Ursachen für Beginn/Ende der Heiztakte zu ergründen. Man sieht im angehängten ScreenDump, dass geheizt wird, wenn die Hysterese (-4K, grüne Kurve) unterschritten wird. Das Ende des Heiztaktes wird durch den Integralwert veruracht (eingestellter Integralwert ist 200, rote Kurve). Das hilft mir beim einstellen der Hysteresen und Integralwerte.

Ein kleines Darstellungsproblem gibt es aber noch:

@immi:
Do you know how I can achieve sGlobal and sHC1 to be in sync, means they should always be read the same time (+/- a few seconds). Currently the upper plot shows end of heating cycle at ~8:50 while the lower plot shows a max. integral value at ~8:45. I assume that's caused by a time offset between reading sGlobal and sHC1. Of course this effect could be limited by reading the data more often, but I'm already at >10MB per month, using 5 minute reading intervals. This shouldn't increase to 50MB by reading every minute. Otherwise creating plots takes too much time.

[willybauss]

also die Daten schreib ich nach /mnt/fhem/log/ das ist natürlich auf der SD Karte.

Bei mir liegen die Daten auf /mnt/fhem/log. Das ist ein gemounteter Share meines NAS. Glücklicherweise habe ich bei meinen WD MybookLive /  WD MybookLiveDuo Zugriff auf die Linuxebene. Dadurch wird ein solcher Mount recht einfach. Aber man braucht halt einen Raspi mit LAN-Port dafür.
Der Zugriff auf die Logfiles von Windows aus geschieht dann einfach per Netzlaufwerk V:\fhem\log. Man sollte beim angucken der Logs halt nicht versehentlich speichern, weil inzwischen ja schon wieder neue Daten dazu geschrieben wurden.

[immi]

@immi:
Do you know how I can achieve sGlobal and sHC1 to be in sync, means they should always be read the same time (+/- a few seconds). Currently the upper plot shows end of heating cycle at ~8:50 while the lower plot shows a max. integral value at ~8:45. I assume that's caused by a time offset between reading sGlobal and sHC1. Of course this effect could be limited by reading the data more often, but I'm already at >10MB per month, using 5 minute reading intervals. This shouldn't increase to 50MB by reading every minute. Otherwise creating plots takes too much time.

Hi
Interesting plot,
The first thing is to have the same read interval. Then it should not drift more than 0.2s  for each read.
For data size, please consider that new methods have been (or are just going to be) released from Boris.
You can now filter very well the data before it is logged.
I am short on time this week. This is why v0129 has not been tested or uploaded to the repository.
Actually I am working on 0.130 with a new supported parameter (maybe monday)
sorry
immi


Hi Toggle
I will fix your suggestion.

Hi Belu
thanks for sharing your FE
immi

[willybauss]

Actually I am working on 0.130 with a new supported parameter (maybe monday)

Hi immi,
would it be possible to also have a fix for this issue in 0.130?
Willy