Anbindung Junkers Gastherme mit HT3-Bus an FHEM

[strauch]

Moin moin,

neue Version Stand: 2014-06-12 05:48:00Z. Die Steuerdaten-Telegramme mit 11 Bytes werden erstmal ausgefiltert. Da gibt es zwei Arten: 9000ff0000d3020000a600 und 9000ff0000d3010000aa00. Das erste wird etwa alle 10 Minuten ab 23 Uhr bis kurz vor 5 Uhr gesendet. Das andere in der übrigen Zeit.

Klingt irgendwie nach Nachtabsenkung.

Sobald ich an einen Rechner komme werde ich meinen link im ersten Beitrag anpassen. Danke.

Gesendet von meinem Nexus 4 mit Tapatalk

[kaizo]

Ich denke auch, es ist die Nachtabsenkung. Heute Nacht waren nur zwei Checksummen-Fehler, einer zu Beginn der Absenkung und einer zum Ende. Sonst läuft es gut.

Allerdings finde ich die grafische Darstellung der Werte interessant:
(http://forum.fhem.de/index.php?action=dlattach;topic=19445.0;attach=16267;image%5D)
Auszug der SVG-Grafik

(http://forum.fhem.de/index.php?action=dlattach;topic=19445.0;attach=16269;image)
Detail, vergrößert

HK-Temp-Ist / hc1_Tdesired ist hier immer ein Sprung vom Wert nach Null und dann auf den Wert.
Ein Fehler in den Daten oder in der SVG-Konfig?

Ich vermute zudem, dass die Datenbank durch die "redselige" Junkers-Heatronic mit Daten stark belastet wird, hier hilft auch ein event-on-change-reading nicht wirklich viel, besser wäre es, wenn die Daten in einem festlegbaren Intervall geloggt werden könnte.

Gruß
Kai

[Heiko R.]

Da muss ich gucken. Kann sein, dass durch die zusätzlichen Nachrichten ein paar Werte verbogen werden. An das Intervall habe ich auch schon gedacht. Bei mir sitzt läuft das Modul auf dem zweiten Rechner und ich ziehe mir nur die Daten rüber, die ich brauche. Der DB-Platzbedarf war beim ht3_logger auch nicht gerade gering.

[kaizo]

Hmm, mit dem periodischen Abfragen der Werte auf meinem zweiten RPI, das war auch mein erster Ansatz, siehe die ersten Post in diesem Thread. Da kamen dann alle 5/15min neue Werte in die Datenbank und nicht, wie jetzt, zum Teil in einem Abstand von 10-20sek.
Ist natürlich auch sehr stark von dem Datendurchsatz auf dem HT-Bus abhängig, und es gehen bei einer Intervallabfrage diverse Daten auch ggf. verloren. Ich logge zur Zeit auch den Lauf der Zirkulationspumpe mit, und da gehen dann garantiert Werte verloren.

Die Frage ist hierbei, ob man die Intervalle bei den Datenabfragen einstellt oder, noch besser, man immer abfragt, aber die Daten nur in Intervallen in die Datenbank schreibt. Am besten wäre die Auswahl beider Möglichkeiten, so z.B. bei Datenpunktänderung eine direkte Sicherung in die Datenbank (z.B. für die Zirk.Pumpe oder die Heizungspumpe, Stati-Änderungen des 3-Wege-Ventils,...), während bei anderen Daten ein festes Intervall ausreichend wäre (z.B. Solarertrag wird meist nur einmal pro Stunde aktualisiert, die Temperaturen würden auch für ein festes Intervall oder bei Abweichung/Hysterese reichen)

Einiges wäre denkbar und auch sinnvoll, um den Datenwust zu verringern. Meine Plots benötigen recht lange, um die Grafen darzustellen, da die Daten in der MySQL immer mehr werden. Muss aber auch mal eine Archivierung machen.

Gruß
Kai

[kaizo]

Nochmals zu den Grafiken, ich habe mir die Daten in der MySQL mal genauer angesehen.
Bis Donnerstag war alles ok, da liefen die Daten ohne "0" ein.
Nach dem ersten Update kam hier und da mal eine "0" in den Daten, ab 12.6. kommen sehr häufig Nullwerte in die Datenbank.

Ich hänge das Log mal als Anhang hier dran.


Gruß
Kai

[Heiko R.]

Ja, der schiebt dann wohl bei den kürzeren Steuerdaten die 0 da mit rein. Das darf natürlich nicht sein, weil gar keine Temperaturwerte in der Nachricht enthalten sind. Ich habe die Verarbeitung dieser Nachrichten vorerst gestoppt, bis die Bedeutung klar ist (auch die vermutlich längere).

Die Idee mit den Intervallen oszilliert auch noch bei mir im Hinterkopf, aber ich habe noch keinen vernünftigen Ansatz gefunden, eben weil einige wichtige Werte (z.B. Brennerstatus) verloren gehen könnten. Bei Dir ist mir aufgefallen, dass Du sehr viele gleiche Temperaturen im Log hast. Da würde ein event-on-change-reading schon Wunder bewirken. Ich bin aber noch nicht so in die Tiefen von Perl und die Interna von FHEM eingedrungen, um alle Möglichkeiten auszuschöpfen. Mühsam ernährt sich das Eichhörnchen Wenn jetzt alle Fehlermeldungen verschwunden sind, haben wir den ersten Stand vom ht3_logger erreicht. Das ist doch schonmal was.

Gruß
Heiko

[kaizo]

Anfangs hatte ich das event-on-change-reading noch nicht gesetzt.
Die neue Version habe ich aktiv, nun werden allerdings auch die hc1-Daten nicht mehr ausgewertet. Da wäre es sinnvoller, die Fehler nachts zu akzeptieren, als die Telegramme komplett zu "ignorieren"

Als Fehler kam nur eine Meldung:

Code Auswählen Erweitern

2014.06.15 06:02:34.143 3: Heatronic error: Cannot handle message 'controller data'
2014.06.15 06:02:34.146 3: 9000ff00006f03c50090003000b0002d003500(a4/35)

Ich denke, ein solcher Fehler ist zu verschmerzen.

Interessant sind aber immer noch die SVG's:
(http://forum.fhem.de/index.php?action=dlattach;topic=19445.0;attach=16323)

Das rote oben ist die Temp. des WW-Speichers, das graue die Brennerleistung
Im unterem SVG ist sind die roten Linien die Temp. des WW-Speichers oben/unten

Bei der Brennerleistung ist das erklärbar, liegt an Event-on-change-reading, da habe ich die Darstellung umgestellt, dann passt es.


Teilweise werden nun aber Daten falsch interpretiert:

Code Auswählen Erweitern

ch_time 2000-111-02 03:00:230 2014-06-15 12:16:13

Das scheint sich nun ein Fehler eingeschlichen zu haben.
Der ch_time Fehler tritt sporadisch auf.

[Heiko R.]

Ich habe die auch wieder gehabt. Sobald mein Rechner wieder läuft,  ändere ich das wieder. Die Telegramme färben meine Haare grau

[Heiko R.]

Wie peinlich ... Ich habe die Steuerdaten über die Zeitroutine ausgewertet ... Asche über mein Haupt ... Neue Version ist eingestellt.

Gruß,
Heiko

[kaizo]

Ich habe die auch wieder gehabt. Sobald mein Rechner wieder läuft,  ändere ich das wieder. Die Telegramme färben meine Haare grau

Da hast du aber noch Glück. Meine meisten sind schon transparent

[Heiko R.]

Moin,

da war immer noch ein Fehler drin ... der hat dann gleich auch mal zum Beenden von fhem geführt.

Gruß,
Heiko

Nachtrag: Heute ist aber auch echt der Wurm drin ... jetzt habe ich vergessen, das Mitschreiben der Telegramme auszuschalten. Wenn eine Datei Junkers.log in fhem/log auftaucht, kann die gelöscht werden.

[Heiko R.]

Guten Morgen,

die Länge der unbekannten Nachrichten für die Steuerdaten habe ich endlich feststellen können. Es gibt also Nachrichten mit 17, 11 und 9 Bytes. Die Nachrichten mit 9 Bytes beinhalten nur den neuen Heizungsmodus (Comfort, eco, Frost), die normale Länge ist 17 Bytes. Die Nachrichten mit 11 Bytes sind noch nicht nicht geklärt (sie sind nicht eindeutig den Heizkreisdaten zuzuordnen) und werden daher nicht ausgewertet.

Ich teste das heute mal durch. Wenn alles gut läuft, gibt es morgen eine neue Version.

Gruß,
Heiko

[Heiko R.]

Moin moin,

die neue Version ist online. Bitte in der Definition "Heatronic" in "HEATRONIC" ändern (s. a. Einführungspost). Ich habe das geändert, um eine Analogie zu den anderen Modulen herzustellen.

Gruß,
Heiko

[Heiko R.]

Moin moin,

ich habe eben das Modul 89_HEATRONIC.pm in das Repository von FHEM übertragen und es wird dort gepflegt. Beim Update von FHEM bekommt ihr also auch die neueste Version des Moduls.

Gruß,
Heiko

[Heiko R.]

Hallo,

es gibt nochmal ein Update mit einer Fehlerbeseitigung.

Gruß,
Heiko