Heizungs-Datenerfassung (HT3)

[Norbert S. (junky-zs)]

Hallo, die Software zu Heizungs-Datenerfassung mit RaspberryPi und 
Laptop/PC stelle ich hier vor. Es wird das Heatronic3 Protokoll 
(Junkers) erfasst, in eine SQL-Datenbank und eine rrdtool-Datenbank 
geschrieben.
Die grafische Darstellung der Historie wird mit den Hilfsmitteln des 
rrdtool's gemacht. Zur Echtzeit-Darstellung der Daten sind 1. 
HT3_Analysator GUI und 2. HT3_Systemstatus GUI vorhanden.
Die Software ist in Python3 geschrieben, das Interface zu rrdtool ist 
Perl (object-orientiert).

Im Tar-File ist ebenfalls eine ausführliche Beschreibung und 
Installationsanweisung enthalten.
Die Hardware ist hier im Forum schon beschrieben unter:
Beitrag "Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Wie das Resultat aussehen kann habe ich als Plott beigefügt. Die SW ist 
wie gehabt OpenSource, frei nach dem Motto:
 Hey man,
 don't make it bad
 take this bad source
 and make it better
 remember, to make it open source
 everythink else
 in only worse.

So nun Feuer frei und Flamme an.

Norbert

[Stefan B. (sbiermann)]

Hallo Norbert,
hast du mal daran gedacht deine Software auf github.com zu 
veröffentlichen? Ist meiner Meinung nach die ideale Plattform um solche 
Opensource Software zu veröffentlichen. Da dann auch andere in der Lage 
sind ihre Ideen zum Projekt beizutragen und die Software sogar weiter 
entwickeln können.

Viele Grüße
Stefan

[Norbert S. (junky-zs)]

Hallo Stefan,
ja Du hast recht dort ist es besser aufgehoben, jedoch wollte ich nicht 
den zweiten Schritt vor dem ersten machen.
Mit github muss ich noch Erfahrung sammeln.
Hinweis: Im obigen Tar-File sind die subversion-checkins enthalten, 
somit sind Änderungen nachvollziebar.

Gruss Norbert

[Kai Zöllner (Gast)]

Hallo Norbert,

nachdem ich endlich mal die Hardware zusammengesteckt habe 
(Breadboard)kann ich nun auch die Daten der Heizung auslesen. Die 
Hardware ist bei mir etwas abgewandelt, da ich nicht den vorgeschlagenen 
Optokoppler verwende und zum Signalinvertieren ein CMOS nehme.

Ich habe folgende Konfiguration meiner Heizung
ZSB22, FW100, ISM1 (für Solar)
Eine Fernbedienung habe ich (leider) nicht

Bei mir gibt es einige Datenpunkte nicht:
Heizgerät Rücklauf
Heizkreis Ist-Mischer  (Mischerloser Betrieb)
Heizkreis Raumtemperatur (klar, kein Fühler!)

Dafür habe ich zusätzlich noch die Zirkulationspumpe und die 
Heizkreispumpe mit in die Grafiken genommen, da die ZP auch für Komfort 
und Verluste sorgt(siehe Grafik).
Zudem werden bei mir zwei weitere Grafiken erzeugt, einmal ein Tageswert 
und einmal eine Wochendarstellung.

Die Beschriftung beim Heizgerät ist nicht ganz optimal, es ist 
eigentlich nicht der Vorlauf Soll/Ist, sondern die Kesseltemperatur. In 
den Grafiken kann man sehr schön die erhöhte Temperatur beim 
Warmwasserbetrieb (Speicherladung) erkennen.

Werde mir mal die nächsten Tage die mitgeschriebenen Hexcodes in der 
Datenbank ansehen und schauen, ob man noch was daraus erkennen kann.

Hast Du schon eine Idee, welcher Wert beim Solar der "Ertrag 2" sein 
kann?
Und gibt es schon eine neuere Version deiner Software?

Tolle Arbeit, die Du da geleistet hast! Vielen Dank dafür nochmals. Auch 
dass Du eine ausführliche Anleitung geschrieben hast, das hat mir beim 
Verständnis und dem Installieren der Software viel geholfen!!!

Gruß
Kai

[Norbert S. (junky-zs)]

Hallo Kai,
Glückwunsch, sieht super aus. Auch Deine FHEM-Anbindung ist gelungen -> 
Beitrag "Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Ich kann Dich bei FHEM nicht so toll unterstützen, da diese bei mir 
nicht fliegt, hoffe aber das andere dort weiter sind.

>Bei mir gibt es einige Datenpunkte nicht:
>Heizgerät Rücklauf
>Heizkreis Ist-Mischer  (Mischerloser Betrieb)
Bei mir sind diese Fühler im Gerät (CSW24) eingebaut und messen dort die 
Temperaturen des Primärkreises, dahinter ist ein externer Wärmetauscher 
und der Sekundärkreis mit separater Heizkreispumpe der jedoch keine 
Temperaturfühler hat.
Schau mal in Deine Anlagenunterlagen auf die Explositionszeichnungen, 
dort sind beim mir die Details (Mischerfühler etc.) eingezeichnet.

>Hast Du schon eine Idee, welcher Wert beim Solar der "Ertrag 2" sein kann?
Nein, nicht wirklich. Hatte gehofft, daß dies ein Wert für die 
Wärmeentnahme aus dem Solarspeicher sei aber die Werte sind zu hoch und 
zeitlich passt das auch nicht so recht.

>Und gibt es schon eine neuere Version deiner Software?
Nein z.Zeit nicht. Habe gerade bei meiner Anlage Unregelmäßigkeiten bei 
dem Solarkollektor Temperaturfühler festgestellt.
90 Grad am Solarkollektor Nachts um 1-3 Uhr hat man nicht so häufig in 
unseren Breitengraden. Der Temperatur-Sensor zeigt manchmal falsche 
Werte an.
Da zeigt sich wieder der Vorteil wenn man eine kontinuierliche 
Aufzeichnung der Daten macht, denn gerade die sporadischen Fehler sind 
nicht einfach festzustellen. Werden zwar in der Zentrale gespeichert 
aber wenn der Fehler wieder weg ist, ist auch im Hauptmenü nichts mehr 
davon zu sehen.
Mit neuer Software warte ich noch etwas, da ich diese gerne um 
Telegramme von FW2xy usw. (zweikreisige Anlagen) erweitern möchte. Diese 
Infos sind im Zulauf, ich selber habe nur eine einkreisige Anlage.

Gruß Norbert

[Kai Zöllner (Gast)]

Hallo Norbert,

schön das es noch weitergeht.
Ich habe gerade noch einen kleinen Fehler entdeckt, es scheint so als 
wenn die Daten zu Heizgerät-Betriebsmodus (das Bitfeld) nicht ganz 
sauber decodiert wird. Ich habe in dem Hex-Code auch einen Wechsel zu 
0x0A=10dez="Warmwasser"+"Flamme an", dieses wird aber nicht in der 
SQL-Datenbank im Feld V_modus korrekt gespeichert. Auch die Anzeige des 
Analysers gibt bei mir immer "0" = Warmwasser an.

Wenn ich mal die Tage etwas mehr Zeit bekommen sollte werde ich auch den 
Weg zur Einbindung in FHEM umschreiben, sofern hier bedarf besteht. Mit 
dem FHEM-Modul HTTOMOD geht die Einbindung doch recht zufriedenstellend. 
Zumindest nach den ersten Tagen sieht das Ergebnis recht gut aus.


Gruß
Kai

[strauch (Gast)]

@Kai ich hab mal im FHEM Forum meinen Beitrag zum MB-LAN umgebaut und 
hier auf deine Lösung verwiesen, vielleicht kommt durch die Verknüpfung 
ja noch mehr fähige Leute hier hin. Vielen Dank für eure Arbeit bisher.

http://forum.fhem.de/index.php/topic,19445.0.html

[Norbert S. (junky-zs)]

Hallo,
Kai schrieb:
>Ich habe gerade noch einen kleinen Fehler entdeckt, es scheint so als
>wenn die Daten zu Heizgerät-Betriebsmodus (das Bitfeld) nicht ganz
>sauber decodiert wird. Ich habe in dem Hex-Code auch einen Wechsel zu
>0x0A=10dez="Warmwasser"+"Flamme an", dieses wird aber nicht in der
>SQL-Datenbank im Feld V_modus korrekt gespeichert.
V_modus, V_brenner_motor und V_brenner_flamme in der SQL-Datenbank sind 
schon Interpretationen (0 oder 1) der Bits in den Telegramm-Bytes 7 und 
9 des Telegramms: 88001800 und nicht die direkte Speicherung der Bytes. 
Hintergrund ist, das ich diese Bit-Knispelei nicht nach Aussen verlagern 
sondern gekapselt intern im Dekoder haben wollte. Dies macht Anpassungen 
einfacher, die Datenbanken müssen dann nicht angepasst werden.
Allerdings werde ich nicht mehr Byte 7 := für Heizung/Warmwasser 
Erkennung verwenden sondern Byte9 Bit1 und Bit2 (Bit1 -> LSB). Somit 
wird dann:
Byte9/Bit1 Byte9/Bit2 Mode       V_mode
0          0          ---        0
1          0          Heizungs   1
0          1          Warmwasser 2
1          1          ---        0

Ich hoffe Du kannst dies so gebrauchen und in Deinen Anzeigen nutzen.
Wenn ok, geht dies so ins nächste Release.

Gruß Norbert

[Kai Zöllner (Gast)]

Hallo Norbert,

wenn der V_mode 0,1 oder 2 wird, so wäre das kein Problem. Dass Du die 
"Bit_Knispelei" im Programm vornimmst finde ich gut und ist auch OK so.
Ich kann allerdings zur Zeit den Unterschied "Warmwasser" und 
"Heizbetrieb" bei mir so nicht erkennen. Wenn das mit dem V_mode 
umgesetzt ist wäre das möglich. Wollte das auch schon selber einbauen, 
aber da will ich noch mit warten.

Wann veröffentlichst Du die nächste Version der Soft?
Ist da schon was geplant?

Gruß
Kai

[Norbert S. (junky-zs)]

Hallo Kai,
die Änderung des V_mode habe ich wie oben beschrieben eingebracht. Dabei 
habe ich jedoch übersehen, dass es auch den Zustand: 'Standby' geben 
muss, bei dem weder Heizungs- noch Warmwasser-Betrieb aktiv sind. 
Heizung- und Warmwasser gleichzeitig halte ich für weniger 
wahrscheinlich, da in der Regel ja ein 3Wege-Ventil für eine Umschaltung 
sorgt. Daher habe ich die Zuordnung der Bit's wie folgt verbessert:

Byte9/Bit1 Byte9/Bit2 Mode       V_mode
0          0          Standby    0
1          0          Heizungs   1
0          1          Warmwasser 2
1          1          ---        3
Somit kommen die unteren beiden Bits des Telegramms jetzt direkt in den 
V_mode der Datenbank und der Rest ist dann 'Ansichtssache'.

>Wann veröffentlichst Du die nächste Version der Soft?
Habe die letzte Version stark angepasst um Daten von Heizungsanlagen mit 
zwei oder mehr Heizungs-Kreisen (mit oder ohne Mischer) erfassen zu 
können. Diese Test-Version ist bei Frank installiert und läuft dort seit 
einer Woche. Wenn die Ergebnisse da sind bringe ich eine neue Version 
raus.

Durch Anpassungen im Konfigurationsfile lassen sich die Anlagentypen 
einstellen, bis zu 4 Heizkreise sind darstellbar und die Daten werden 
erfasst.
Keine Angst, die Software lässt sich sogar auf meine Schmalspuranlage 
mit einem Heizkreis konfigurieren.

Die Darstellung an der Analyser-GUI hat sich nicht grundlegend 
verändert, Details sind jedoch:
1. die Aussentemperatur und die Betriebszeiten sind jetzt zum Heizgerät 
gewandert, so wie es auch in den Reglern FWxy angezeigt wird.
2. Es werden jetzt 4 Heizkreise in der Datenbank angelegt, die je nach 
Konfiguration dann befüllt werden.
Daraus folgt allerdings auch, dass die Datenbanken (sqlite und rrdtool) 
neue Tabellen-Einträge haben. Ich habe deshalb bei mir die Datenbanken 
neu angelegt.
Die alten Daten habe ich noch nicht übernommen, obwohl der Wunsch schon 
da ist. Mit Sql-Aufrufen und den rrdtool-Hilfsmitteln sollte dies 
machbar sein.
Für Tipps wäre ich dankbar.

Gruß Norbert

[Kai <Zöllner (Gast)]

Hallo Norbert,

danke für die Info.
Zur Übernahme der Daten gibt es ja mehrere Wege. Bei sql könnten die 
zusätzlichen Datenfelder ja einfach ergänzt werden. Und für die 
rrd-Datenbank wäre es sicherlich über rrddump/rrdexport und einem 
rrdimport möglich, aber es wäre bestimmt einfacher, die rrd-Daten neu 
über die sql-Datenbank neu zu füllen.

Also mein Vorschlag wäre, die bestehende Sqllite-Datenbank um die 
benötigten Felder zu ergänzen (Stichwort z.B. ALTER TABLE) und dann über 
sql-Export die rrd-Datenbank neu füllen.


Gruß
Kai

[Norbert S. (junky-zs)]

Hallo,

so, die Software, Hardware-Beschreibung und Dokumentation habe ich jetzt 
auf github.com abgelegt.
URL:
 https://github.com/norberts1/hometop_HT3.git

Es läuft so wie ich mir das vorgestellt habe, aber sicher nicht so wie 
andere sich das wünschen.
Daher fleissiges mitmachen ist erwünscht.
Das Wiki existiert noch nicht, aber das ist ja nur eine Baustelle von 
vielen.
Für Details in die vorhandene Dokumentation sehen.

Die aktuelle Software ist in Zukunft auf github.com zu finden, hier an 
dieser Stelle in diesem Forum wird es auch weitergehen (I'll hope so) 
nur nicht so mit aktueller Software.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

vielen Dank ersteinmal für die Arbeit, die Du da hineingesteckt hast!

Nachdem wir vor kurzem eine neue Junkers ZWB30 bekommen haben, bin ich 
zwecks auslesen der Daten auf diesen Thread gestossen. Den Adapter habe 
ich vorgestern gelötet und an einem Netzgerät getestet.
Gestern habe ich dann die Software auf dem Raspi installiert, als Linux 
Unerfahrener nicht sooo einfach, aber die Anleitung hilft gut weiter.

Folgendes ist mir dabei aufgefallen, bei der Installation des 
Betriebssystems steht unter deaktivieren der TTY-Systemausgaben:
von
  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 
console=tty1
in
   dwc_otg.lpm_enable=0 console=tty1
ändern. Das habe ich ziemlich wörtlich genommen, danach bootete 
allerdings der Raspi nicht mehr. Nachdem ich zweimal alles komplett neu 
installiert habe, bin ich bei Ardafruit fündig geworden. Alles was 
hinter:
console=TTY1
steht, muss erhalten bleiben. Also der in der Anleitung farblich 
markiere Text darf nur gelöscht werden.
Mit der dritten Installation klappte dann ersteinmal soweit alles. 
allerdings kommen keine Daten an. Die Grafiken werden regelmäßig 
erstellt, zeigen aber immer einen geraden Strich bei 0 an. Da der Raspi 
aber schon bei der Heizung steht, habe ich keinen Monitor angeschlossen. 
Gibt es eine andere Möglichkeit über SSH zu testen, ob überhaupt gültige 
Daten ankommen? Wo wird eigentlich der UART auf 9600,8N1 eingestellt?

Mittels USB-Wandler und HTerm auf dem Laptop konnte ich Daten empfangen, 
allerdings nicht beurteilen ob es gültige sind. Würde da ein Log helfen?

Vielen Dank und Grüße

Ralf

[Ralf K. (elral)]

So, ich habe nun mal mit geloggt, 9600 8N1
Ich glaube das sieht nicht so gut aus. Statt des H11L1M habe ich einen 
Sharp PCP00 verwendet, kann es daran liegen?
Ausserdem werden gar keine Werte mehr aufgenommen, da wird wohl ein 
Script nicht mehr gestartet.

Über Hinweise würde ich mich sehr freuen.

Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,
Glückwunsch zur neuen Heizung! Diese hat zwar schon das 
HT4i-Telegrammhandling, aber daran liegt dein Problem nicht. Andere 
HT4i-Heizungen laufen ja auch schon mit dem Adapter.
Bitte daher folgendes Kontrollieren:
1. Kontrolle der Datenbanken. Vorhanden und Lese/Schreibrechte des 
Users?
Dies passt bei dir, da du ja die Grafiken (rrdtool) angezeigt bekommst.
2. User ist in Group 'dialout' enthalten? -> siehe Anleitung
3. Mit 'ssh' auf den RaspberryPi und folgende Checks durchführen:
 $ /etc/init.d/ht3_logger status
 $ --> [ok] HT3_Logger is running.
Falls diese Antwort nicht kommt, läuft der Daemon nicht. Bitte dann noch 
mal in der Anleitung nachsehen bei der Aktivierung des Scriptes mit 
insserv (Seite 27) und ein 'reboot' durchführen.

 $ ps -aux | grep HT
 $ --> <path>/HT3/sw/etc/httpd.py
   --> <path>/HT3/sw/HT3_Logger.py
Der httpd.py Daemon läuft bei dir, da du ja Grafik-Ausgaben bekommst. 
Der Logger muss ebenfalls laufen, damit die Daten von der Schnittstelle 
ausgewertet und in die Datenbank (sqllite und rrdtool) geschrieben 
werden.

Terminal oeffnen (minicom -s), Einstellungen für die Schnittstelle 
machen und Daten erfassen (9600 8N1).
Zuvor jedoch Kontrolle, ob die Schnittstelle auch auf 9600 Baud 
eingestellt war mit:
 stty -F /dev/ttyAMA0
und den HT3_logger stoppen mit:
  /etc/init.d/ht3_logger stop

Wenn alles richtig ist, müssen Daten im minicom-terminal kommen. Falls 
nicht, bitte den Anschluss des Adapters an die Heizung kontrollieren. 
Die GRÜNE LED muss im Rythmus der HT-Busdaten flackern. Tut sie dies 
nicht, ist die Polarität der beiden BUS-Anschlussdrähte zu tauschen.
Wenn soweit alles OK ist, dann bitte den HT3_Logger wieder starten mit:
   /etc/init.d/ht3_logger start
und die Datenbanken überwachen mit:
 $ cd <path zur datenbank> (z.B.: cd .../HT3/sw/var/databases) und dort 
eingeben:'
 $ watch -d 'ls -al'

Die Datenbanken (*.sqlite und *.rrd) müssen spätestens jede Minute 
grösser werden (ca. 6 Minuten nach dem Start des Loggers) und es wird 
kurzfristig ein sqlite-journal file geschrieben).
Ebenso dürfen im '/tmp'-Verzeichnis keine temporären perl-files liegen 
bleiben. Falls doch, geben die darin enthaltenen Fehlermeldungen einen 
groben Hinweis auf die Ursache.

Übrigens, die Baudrate ist z.Z. sehr versteckt unter 
.../HT3/sw/lib/ht3_worker.py in Zeile 63 zu finden:
    self.__port = serial.Serial(self.__serialdevice, 9600 )

Ich hoffe, das diese Hinweise dir und auch anderen weiterhelfen!

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

vielen Dank schon mal.

Ich habe eben noch Monitor, Maus und Tastatur angeschlossen.
Nach etwas Verzögerung werden mir Werte im Analyser angezeigt, 
allerdings scheint "nichts"/etwas falsches in die Datenbanken 
geschrieben zu werden. Die Grafiken zeigen konstant nahezu 0 an.
Am schwersten habe ich mich dabei getan, die Pfadangaben aus der 
Anleitung, die auf den USB Stick verweisen, in mein Verzeichnis 
umzuändern (/home/ralf/ ). Das sind dann auch die beiden Parameter, die 
ich dem rrdtool.pl in der /etc/crontab übergebe. Vielleicht liegt ja da 
das Problem.

Zu Deinen Hinweisen werde ich leider erst morgen/übermorgen kommen, die 
teste ich durch.

Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,

zuerst die guten Nachrichten!
1. Optokoppler PC900 (Sharp) ist OK.
2. Baudrate ist OK
3. Dein Logfile enthält bekannte Telegramme 88 00 18 00 ...
4. -> Dein Adapter ist OK und funkt auch

jetzt die weniger guten Nachrichten:
4. Es sind neue, mir bisher noch nicht bekannte Telegramme dabei, z.B.:
89 00 88 00 2A 00 00 00 00 00 03 00 00 00 DE 00 00 80 00 00 80 00 80 00 
80 00 00 C2 00

Da diese z.Zeit nicht dekodiert werden ist die Auswertung und Anzeige 
davon betroffen. Ich vermute hier als Grund zusätzliche HT4i-Telegramme.

Weil ich leider kein HT4i-System habe, gib mir mehr von diesen Logfiles 
für eine Auswertung. Bitte über einen längeren Zeitraum erfassen. Das 
Format kann durchaus Binär sein, da ich das dann direkt in den Analyser 
einlesen kann. Aber ASCII ist auch kein Problem.
Direkt hier ins Forum stellen (falls jemand das gleiche Problem hat und 
ganz heiss aufs dekodieren ist) oder an meine PM.

Noch ein Hinweis zu den Pfad-Angaben.
Nach der Installation stehen die Datenbank-Pfadangaben in der 
Konfiguration auf den Installations-Folder (relativ):
z.B.: <installations-Folder>/var/databases.
Will/muss man dies anpassen, so ist ebenfalls das Konfigurations-file 
unter ./etc/config und die Aufrufparameter des scripts 'rrdtool_draw.pl' 
anzupassen -> Siehe Doku.
Beispiel für den Cronjob bei einem USBstick und einem Heizkreis:
  ..../usr/bin/perl -S rrdtool_draw.pl /media/usbstick /home/<user>/ 1
Es ist hier der absolute Pfad in der Konfiguration anzugeben und enthält 
dann: /media/usbstick/HT3/sw/var/databases/

Die Konfiguration muss auf jedenfall vor dem Erzeugen der Datenbanken 
(mit ./create_databases.py) angepasst werden. Nur dann werden die 
Datenbanken im NEUEN Folder erzeugt.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

ich habe heute morgen noch schnell nachgeschaut, es werden wohl keine 
Daten in die Datenbank geschrieben. Fehlermeldungen unter /tmp konnte 
ich mir noch nicht anschauen, das mache ich dann heute abend. 
Installiert habe ich unter /home/ralf/ da ich keinen USB-Stick 
angeschlossen habe, die 16GB Karte sollte ersteinmal genug Platz haben 
(lt. Anleitung ~1,5GB/Jahr). Lese-/Schreibrechte muss ich auch noch 
kontrollieren, <User> ist in Gruppe dialout enthalten, ansonsten würde 
ich wohl auch keinen Systemstatus erhalten.

minicom ist zur Zeit nicht installiert, werde ich dann heute abend 
nachholen.
Ich habe dann noch ein log mittels:
cat /dev/ttyAMA0 >> /tmp/<filename>
angestossen. Vorher noch den HT3_logger gestoppt, der lief nämlich. Das 
wird dann wohl bis heute Spätnachmittag mit loggen. Ist das so O.K.? 
Wenn nicht, werde ich das mit minicom nochmals loggen.

Nochmals vielen Dank und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,

ja das loggen ist so OK.
Wenn darin dann Daten sind und du bekannte Telegramme wiederfindest 
z.B.: 88 00 18 00 ... brauchst du minicom nicht zu installieren (einfach 
mit hexdump den Inhalt anschauen).

Ich nehme an, das du die Software von github hast, somit sollten unter 
dem Verzeichnis: /home/ralf/ auch die Software und Datenbanken: 
/home/ralf/HT3/sw/var/databases wiederzufinden sein.
Somit brauchst du nur den <user> in den Start- und Log-Scripten 
anzupassen und den relativen Pfad in der Konfiguration so wie er ist 
belassen.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

anbei die Logdatei von heute.
Ja, die SW habe ich von Github, werde jetzt mal anfangen zu prüfen.

Danke und Grüße

Ralf

/edit:
Ich habe Fehlerdateien in /tmp/xyz.pl, z.Bsp.:

#!/usr/bin/perl
#
use strict;
use warnings;
use RRDTool::OO;

my $DB_heizgeraet  = "/home/ralf/HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd";
my $heizgeraet_rrdh = RRDTool::OO->new(file => $DB_heizgeraet);
#
$heizgeraet_rrdh->update (
  time   => 1418559640,
  values => {
   T_vorlauf_soll=>37,
   T_vorlauf_ist=>35.9,
   T_ruecklauf=>3276.8,
   T_mischer=>23.5,
   V_modus=>1,
   V_brenner_motor=>0,
   V_brenner_flamme=>0,
   V_leistung=>0,
   V_heizungs_pumpe=>1,
   V_zirkula_pumpe=>0,
   V_speicher_pumpe=>0,
   T_aussen=>6.1,
   C_betrieb_gesamt=>5029,
   C_betrieb_heizung=>4842,
   C_brenner_gesamt=>1871,
   C_brenner_heizung=>1656,
   V_spare_1=>0,
   V_spare_2=>0,
   }
);
# ---- error occured: -------
# 65280, syspart:heizgeraet, timestamp:1418559640

Fehler 65280 bedeutet "command could not be found" ?

Berechtigungen der Datenbanken sind: rw-r--r--, Besitzer: ralf

Im /etc/init.d/ht3_logger steht u.a.:

NAME=HT3_Logger.py
NAME_SCRIPT=ht3_logger
USER="ralf"
DAEMON=/home/$USER/HT3/sw/$NAME
DAEMON_ARGS=""
PIDFILE=/home/$USER/HT3/sw/var/run/$NAME_SCRIPT.pid
APPLICATION_FOLDER=/home/$USER/HT3/sw/
SCRIPTNAME=/etc/init.d/$NAME_SCRIPT

Unter /home/ralf/HT3/sw/var/run/ gibt es aber kein ht3_logger.pid, ist 
das richtig?
ht3_logger status meldet aber [OK] HT3_Logger.py is running

Leichte Verwirrung macht sich breit....

[Ralf K. (elral)]

Der Fehler liegt wohl eher beim überspielen der Daten aus der Datenbank 
in die .rrd Dateien.
In der HT3_db.sqlite werden die Daten eingetragen, das habe ich mir 
gerade mal angeschaut. Grenzt es jetzt hoffentlich wieder etwas mehr ein 
...

Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,
ja deine Vermutung ist richtig, es werden keine Daten in die rrdtool-db 
geschrieben.
Da diese aber unter dem Folder:/home/ralf/HT3/sw/var/databases/ 
vorhanden sind (sonst würdest du die Grafiken mit dem Browser nicht 
angezeigt bekommen) liegt ein anderer Gund vor.
Bitte prüfe die Installation des objektorientierten RRDtool-Perlanteils 
in deinem System. In der Doku ist dies auf Seite 25 beschrieben:
  Perl objekt-orientiertes RRDTool Interface installieren:
  # apt-get install librrdtool-oo-perl

Dieses steht auch in den Perl-Files unter: use RRDTool::OO; und ist 
erforderlich um die Daten in die rrdtool-db einzutragen.

Der Inhalt des Fehlerfiles zeigt zwar: T_ruecklauf=>3276.8, ist zwar AKW 
Reaktor like, aber das liegt wohl mehr daran, das in deinem Kessel eben 
kein Rücklauf-Fühler drin ist. Dies kann man durch Konfiguration 
deaktivieren und ist NICHT das Problem was du z.Zeit noch hast.

Das start-script 'ht_logger' und deine Einstellungen sind OK.
Eventuell muss noch das Konfigurations-File angepasst werden für:
1. Anzahl Heizkreise (default:1)
2. Heigerät mit externem Mischer und Modul IPM vorhanden oder nicht 
(default: <unmixed>True</unmixed> -> kein externer Mischer).

Bitte um Info, wie dein System aufgebaut ist, es gibt ja nichts von der 
Stange sondern Junkes hat das sehr schön konfigurierbar gemacht!

Ja das PID-file habe ich auch schon mehrfach gesucht und 
sollte/müsste/könnte dasei, aber auch bei mir ist dies nicht zu finden.
Trotzdem wird ja der HT3_Logger gestartet und lässt sich auch stoppen 
und dies ist auch nicht der Fehler.

Fehler ist sicher fehlende: librrdtool-oo-perl Library.

Poste mir das es so ist :) damit ich ruhig schlafen kann!
Vorher noch System aktualisieren: apt-get update und apt-get upgrade.
Es tut sich da gerade sehr viel.
Das Logfile werde ich mir morgen ansehen, danke dafür.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

>librrdtool-oo-perl ist bereits die neueste Version :(

Beim apt-get upgrade gab es aber einen Fehler, "irgendetwas" stimmt 
nicht mit libyaml-0-2:armhf ....
Das sollte ich mit dpkg --configure -a beheben, hat auch wohl geklappt.

Mir ist noch eine Fehlermeldung aufgefallen, die muss ich aber erst 
nochmal nachvollziehen, bevor ich die wiedergeben kann (mathlib oder 
irgendsowas??)

Mein System besteht eigentlich nur aus der ZWB30-4C, einem Heizkreislauf 
für die Fußbodenheizungen, Warmwasser Aufbereitung im Gerät 
(Durchlauferhitzer) und der Witterungsführung FW120.

Grüße und schlafe trotzdem gut.

Ralf

/edit:
Interessant finde ich noch, dass in den Grafiken Linien gezeichnet 
werden, nur dann nicht wenn der Logger inaktiv ist.

[Ralf K. (elral)]

Hallo Norbert,

die im vorigen Beitrag genannte Fehlermeldung kam bei insserv und 
lautet:
insserv: warning: script 'mathkernel' missing LSB tags and overrides
Also nichts mit 'mathlib'

Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,

durch die Grafik wird einiges klarer!
Die Werte sind in der Datenbank, die Anzeige wird jedoch durch den 
riesigen Wert bei 'T-Raum=6226' so skaliert, daß die wesentlich 
kleineren anderen Werte nur als Strich bei ca. 0 erscheinen.
Da du keine Fernbedienung hast, der Wert jedoch als Hausnummer im 
Telegramm enthalten ist bitte folgendes anpassen:
Im Modul ./lib/ht3_decode.py Zeile 346 anpassen von:
  self.__gdata.update(nickname,"Tsteuer_FB",f_Steuer_FB)
auf
  self.__gdata.update(nickname,"Tsteuer_FB",0)
Gleiches gilt auch für die Rücklauf-Temperatur. Die ist bei deinem 
System eine Hausnummer im Telegramm, also folgendes anpassen:
Im Modul ./lib/ht3_decode.py Zeile 227 anpassen von:
  self.__gdata.update(nickname,"Truecklauf",f_truecklauf)
auf
  self.__gdata.update(nickname,"Truecklauf",0)

Eventuell gibt es noch weitere Werte, die ausserhalb von Gut und Böse 
sind und keiner realen Temperatur entsprechen können. Bitte schau dir 
alle Grafiken diesbezüglich an.

Bitte kontrolliere auch noch einmal das /tmp -Verzeichnis, ob weiterhin 
Fehlerfiles geschrieben werden.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

oh Schei...., da hätte ich auch mal selbst 'drauf kommen können. Das 'K' 
hinter der 6.0 habe ich immer schön gedanklich ausgeblendet.

Ich habe jetzt ersteinmal die Kurven im rrdtool_draw.pl heraus genommen, 
und siehe da, wunderschöne Kurven :)
Jetzt muss ich noch herausfinden, was die Temperatur Tist beim Heizkreis 
1 genau bedeutet. Die wird auch im Display des eingebauten FW120 
angezeigt.

Nach Weihnachten, wenn wieder etwas mehr Zeit ist, melde ich mich 
sicherlich noch einmal. Ich würde gerne auch die Raumtemperatur noch mit 
aufnehmen. Mir schwebt da so etwas wie hier vor: 
http://www.kompf.de/weather/technik.html.
Schön wäre es, wenn die Daten dann auch in die SQL-DB kämen. Wenn ich 
dann so den ein oder anderen Tip bekäme würde ich mich freuen.

Also nochmals vielen Dank und Grüße

Ralf

/edit:
Fehlerfiles sind gestern noch einmal geschrieben worden, ggf. als ich 
etwas geteset habe. Ich beobachte das jetzt mal

[Norbert S. (junky-zs)]

Hallo Ralf,
prima das es jetzt klappt. Wie so häufig, kleine Ursache grosse Wirkung.

Nur zur Info, die Warmwasserdaten wirst du noch nicht angezeigt 
bekommen, da das Telegramm dazu (88 00 34 00) bei HT4i 25 Byte und bei 
HT3 nur 23 Byte lang ist. Dies ist im Decoder im Moment noch nicht 
enthalten. Beim nächsten Release ist es dann aber drin.
Dies Problem ist aber schon im Nachbar-Thread beschrieben und auch eine 
Lösung angedacht worden siehe:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

ja, den Nachbarthread habe ich schon gelesen.

Fragen zur Software dann weiterhin hier, im Nachbarthread oder ein neuer 
Thread?

Aktuell hätte ich die Frage, wo die Speichertiefe der rrdtool-db fest 
gelegt wird. Im XML-File und in create_databases.py finde ich "nur" das 
Erfassungsintervall.
Und in welchem Format muss Anfangs-/Endzeit dem rrdtool_draw.pl 
übergeben werden?

Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,
>Fragen zur Software dann weiterhin hier, im Nachbarthread oder ein neuer
>Thread?
Software-Fragen sind hier genau richtig, es ist ja der Projekte & 
Code-Bereich (Es ist nicht alles Mist was nach Code aussieht :).

>Aktuell hätte ich die Frage, wo die Speichertiefe der rrdtool-db fest
>gelegt wird.
Beim Anlegen der rrdtool-db wird ein Perl-Script dynamisch im 
/tmp-Verzeichnis erzeugt und ausgeführt 'rrdtool_dbcreate.pl'. Es wird 
mit den Informationen des ./etc/config/<konfigfile>.xml gefüttert u.A. 
mit den Werten:
 my $start_time     = 1344000000;
 my $step           = 60;
Diese Werte stammen ja aus dem Konfigurationsfile unter:
    <rrdtool-db>
      <enable>on</enable>
      <step_seconds>60</step_seconds>
      <starttime_utc>1344000000</starttime_utc>
    </rrdtool-db>
Alle Angaben sind in Sekunden UTC, die 60 gibt somit das kleinste 
Intervall für die rrdtool-db an. Im rrdtool_dbcreate.pl-script stehen 
dann auch noch folgende Einträge fest eingetragen:
        ...
        archive     => {
            rows     => 1051200,
            cpoints  => 5,
            cfunc    => 'LAST',
        },
        archive     => {
            rows     => 525600,
            cpoints  => 1,
            cfunc    => 'AVERAGE',
        },
        archive     => {
            rows     => 105120,
            cpoints  => 5,
            cfunc    => 'MAX',
        },
        archive     => {
            rows     => 105120,
            cpoints  => 5,
            cfunc    => 'MIN',
        }
Alles zusammen ergibt dann:
# Define the archiv
# 'LAST    saved every 5 min, kept for 10years back
# 'AVERAGE saved every 1 min, kept for  1year  back
# 'MAX  saved every 5 min, kept for 1year back
# 'MIN  saved every 5 min, kept for 1year back
Details dazu findest du auf den Man-Pages zum rrdtool.
Klar hätte ich jetzt auch gesagt wirst du sagen und zugegebenermassen 
ist das keine leichte Hausmannskost sondern, naja schwere Lektüre.
Siehe auch URL: http://oss.oetiker.ch/rrdtool/
Dewegen habe ich ja auch das ganze möglichst gekapselt im Python-Code 
versteckt und das ist mir so gut gelungen das ich auch erstmal wieder 
suchen muste.
Zu finden unter ./lib/db_rrdtool.py in Zeile 341 und der Methode:
 def __define_rrd_details(...)

>Und in welchem Format muss Anfangs-/Endzeit dem rrdtool_draw.pl
>übergeben werden?
10 stellig in Sekunden, so wie dies mit dem Aufruf angezeigt wird:
 $ date +%s

Gruß Norbert

[Martin S. (matz666)]

Guten Morgen Norbert.

DANKE erst einmal für die tolle Arbeit.

Ich bin schwer erstaunt wie gut das Projekt läuft. Je tiefer ich in die 
Dateien reinschaue, desto klarer wird wie viele Stunden du an dem 
Projekt schon verbracht hast für UNSEREN KOMFORT.

DANKE dafür.

Ich habe die ganze Sache seit Anfang Dezember auf laufen, habe aber noch 
ein paar kleine Probleme bzw. Wünsche für die ich deine technische 
Unterstützung benötigen würde.

Ich habe wie Ralf im HK1 die 6k Linie die ich aber leider nicht 
rausbringe, auch nach deiner Anleitung nicht.

Ich würde einen Crashkurs benötigen um die rrdtool_draw.pl abzuändern 
und jene linien die ich nicht benötige einfach mal rauszuschmeissen. In 
diesem Zuge würde ich die Zirkulationspumpe gerne in die WW Grafik 
verschieben wenn das nicht zu viel Mehraufwand bedeutet.

So und nun die WUNSCHLISTE.

Meine Anlage besteht aus:
1 FW200 für HK1
2 IMP1 für HK1 und HK2
1 ISM2 für Solaranlage und Schichtladung
1 FB100 für HK2
1 ZBR 40 ??? hab ich nicht ganz genau im Kopf.

da ich mit dem ISM 2 Schichtladung realisiere fehlen mir die Werte TB 
(3. Fühler Umladesystem) und der Relaisausgang DWUC für das 
Schichtladeventil.

Ist es die vielleicht zeitlich möglich diese mit mir "auszugraben" und 
zu implemenetieren.

Danke und schöne Grüße

Martin

[Norbert S. (junky-zs)]

Hallo Martin,
hier ein paar Tipps:
>Ich habe wie Ralf im HK1 die 6k Linie die ich aber leider nicht
>rausbringe, auch nach deiner Anleitung nicht.
Zu File:'rrdtool_draw.pl':
Finde raus, welcher Wert durch die Decke geht (6k) und deaktiviere genau 
diesen im Perl-Script.
Beispiel: Wert für 'T_steuer_FB' ist zu hoch -> im script deaktivieren:
#  draw    => {
#    dsname  => 'T_steuer_FB',
#    name  => 'Raumtemperatur',
#    legend  => 'T-Raum (FB10/FB100) min\:',
#    thickness => 2,
#    color  => '8080ff'
#  },
!Achtung! bei namen: 'name' => 'xyz' die im Script mehrfach auftauchen, 
dort auch die folgenden Anteile deaktivieren, hier bei 'Raumtemperatur' 
also auch:
#  draw    => {
#    type  => "hidden",
#    name  => "Raumtemperatur_min",
#  vdef  => "Raumtemperatur,MINIMUM",
#  },
#  gprint    => {
#    format  => '%3.2lf',
#    draw  => 'Raumtemperatur_min',
#  },
#  draw    => {
#    type  => "hidden",
#    name  => "Raumtemperatur_max",
#    vdef  => "Raumtemperatur,MAXIMUM",
#  },
#  comment    => 'max\:',
#  gprint    => {
#    format  => '%3.2lf\l',
#    draw  => 'Raumtemperatur_max',
#  },
-----
Es gibt halt viele unterschiedliche Anlagenkonfigurationen und da kommt 
es schon mal vor, das der eine oder andere Wert aus den Telegrammen 
nicht verwendet wird und auf einer Hausnummer steht.
Dieses Problem habe ich als 'ToDo' auf meinem Zettel und werde die im 
Konfigurationsfile vorhandenen MAX-Werte dazu nutzen den Telegrammwert 
dann auf Default zu zwingen.

>In diesem Zuge würde ich die Zirkulationspumpe gerne in die WW Grafik 
>verschieben wenn das nicht zu viel Mehraufwand bedeutet.
Ja, der Mehraufwand ist nicht gering. Grund, das Konzept der 
Datenerfassung, Speicherung und Grafik-Anzeige ist z.Zeit 
Telegramm-Sender gesteuert, dies meint: die Informationen werden in dem 
'Subsystem' -Anteil gespeichert welches diese Information gemeldet hat.
->Zirkulationspumpen-Status wird vom 'Heizgeraet' gemeldet und erscheint 
dann auch dort.
Zugegeben sehr unflexibel, aber so ist das rrdtool nun mal in diesem 
Punkt. Besser man nimmt diese Werte aus der sql-Datenbank, aber dann 
würde ich gleich auch die 'FHEM'-Realisierung verwenden. Dort sind ja 
meine Dekodier-Informationen mit eingeflossen.

>So und nun die WUNSCHLISTE.
Du hast eine recht üppige Anlage, die ich als Referenzanlage bei mir 
hier zu Hause leider nicht rumliegen habe. Auch der Weihnachtsmann wird 
mir die nicht gönnen :=).
Daher ein paar Fragen und meine Wunschliste:
1. Das XML-Konfigurations-File muss für deine Anlage angepasst sein, 
allein die Anzahl der Heizkreise im File zu verändern reicht dann nicht, 
siehe Mischer IPM etc.
Ich hoffe du hast die Anpassung dort gemacht!?

2. Hast du ein Übersichtsbild deiner Anlage. Insbesondere für ISM2 
Speicher und Schichtladung kann ich mir dann so ein besseres Bild 
machen.
So ein Bild wäre ganz gut wie unter:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

3. Da ich ja nicht diese Module habe, wünsche ich mir von dir ein paar 
logfiles, eventuell mit sprechenden Namen was da im logfile gerade 
abgelaufen ist. Aufruf mit:
 cat /dev/ttyAMA0 >> /tmp/<filename>
Ich habe dann die Möglichkeit dies zu Analysieren und einen Mehrwert 
rauszuknispeln.

Für die weitere Kommunikation schlage ich vor, dies über die PMails zu 
machen, hier im Forum wird das sonst zu unübersichtlich.

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Beim nächsten Release ist es dann aber drin.

Hallo Norbert,

ich bin neu in das Thema eingestiegen und der Analyzer/Systemstatus 
zeigt mir schon viel (also ist die HW in Ordnung).

Allerdings zeigen mir alle Tools keine WW-Daten. Ich habe den Code aus 
dem Github, also gibt es die oben erwähnte Version noch nicht???

Desweiteren hab ich im Systemstatus alles verfügbar, aber auf den 
rrd-Grafiken sind die Werte nicht drauf. Wie gehe ich am besten vor?

[Norbert S. (junky-zs)]

Hallo Stefan,

>Allerdings zeigen mir alle Tools keine WW-Daten.
Ein Grund ist das erweiterte Telegramm: 88 00 34 00 ... Dies wurde ja 
schon von Heiko R. so festgestellt (siehe anderen Thread).
Bin gerade dabei dies in ein neues Release mit einzupflegen und dann 
auch wieder auf github zu veröffentlichen.

>Desweiteren hab ich im Systemstatus alles verfügbar, aber auf den rrd-Grafiken 
>sind die Werte nicht drauf.
Ja, die rrd-Grafiken zeigen eine Untermenge aller erfassten Daten an. 
Bei der Auswahl der Daten habe ich versucht nur die zu verwenden, die 
wahrscheinlich bei allen Anlagen/Systemen vorhanden sind.
Es gibt ja eine Unmenge von System-Konfigurationen. Die doch recht 
statische Anzeige der rrdtool-Grafik wird dem nicht gerecht und eine 
Auswahl/Konfiguration ist schlecht bzw. mit Aufwand realisierbar.
Dies lässt sich natürlich erreichen (XML-Konfigurationsfile etc.) und 
mit Datenentnahme aus der SQL-Datenbank. Damit ist dann die starke 
Kopplung zwischen Datenerfassung und Datenpräsentation vermieden.
Es ist also durchaus möglich die Daten von der sqlite/mysql-db 
abzufragen und diese dann ohne rrdtool grafisch aufzupimpen. Siehe dazu 
auch das FHEM-Projekt.
Ohne Konfiguration und Anpassung der Datenpräsentation kommt man jedoch 
auf keinen Fall aus, dazu gibt es zu viele unterschiedliche Systeme.
Eine denkbare Möglichkeit ist: Dynamische Generierung des rrdtool 
Abfrage-Scripts: 'rrdtool_draw.pl' mit den Informationen aus dem 
Konfigurations-File.
Zur Zeit habe ich dies jedoch nicht auf dem Schirm.
Kannst du so etwas realisieren?
Ich kenne auch deine Anlagenkonfiguration nicht.

>Wie gehe ich am besten vor?
Die fehlenden 'WW'-Telegramme kommen mit ins nächste Release und sind 
z.Zeit noch nicht auf github vorhanden.

Für deine gewünschten Zusätze bei den rrdtool-Grafiken nimmst du am 
besten das vorhandene Script 'rrdtool_draw.pl' und erweiterst es für 
deine Bedürfnisse.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

erstmal vielen Dank für die schnelle Antwort. Ist schon interessant, was 
alles noch an Daten in den Anlagen steckt, was einem die FWxxx 
verschweigen.

Was meinst Du denn wann mit dem neuen Release zu rechnen ist? Oder lohnt 
es sich für mich, an der Decoder-Datei zu experimentieren, so dass die 
jetzt keine HT3 sondern nur noch HT4-WW-Telegramme verstanden werden?

Und noch eine kleine Bitte für das nächste Release: Auch bei mir musste 
ich die T-Raum und T-Ruecklauf mit so irsinnigen Werten und musste es 
anpassen.
Sollte man dann nicht im Decoder alles über 100 ignorieren und auf 0 
setzen?

Du fragtest nach meiner Anlage: Ist eine denkbar simple bestehend aus 
einer Cerapur ZSB14-4c, einem externen ST120-Speicher und einer FW120. 
Der Systemstatus zeigt mir zumindestens heizungsseitig alle Daten an und 
auch in der Sqlite-DB steht es drin (muß nur noch abgleichen, ob alle 
Daten da sind). Allerdings ist die Grafik komplett falsch skaliert 
(wegen der 6000er Werte, so dass ich nicht sehen kann, ob Vorlauftemp 
und Leistung gezeigt werden. Unter der Grafik jedenfalls steht fast 
nichts bei den Werten. Ich denke mal, die sollten die aktuellen Werte 
zeigen, oder?

Da HT3-Systemstatus alles gewünschte zeigt, müsste die Konfig doch gar 
nicht mehr angepasst werden? So was wie andere Heizkreise und Solar hab 
ich ja nicht.

Noch eine letzte Frage: Wenn ich den Systemstus oder Analyzer laufen 
habe, dann tragen die die ankommenden Werte in die DB ein? Also MUSS ich 
den Logger vorher stoppen?

[Norbert S. (junky-zs)]

Hallo Stefan,

Stephan schrieb:
> Was meinst Du denn wann mit dem neuen Release zu rechnen ist?
Nächste Woche, sagte der SW-Entwickler zu seinem Chef :=) und ich hoffe 
auf 3kW (2015).

> Sollte man dann nicht im Decoder alles über 100 ignorieren und auf 0
> setzen?
Ja, wird mit eingebracht sein. Hatte ich ja weiter oben schon erwähnt.

> Da HT3-Systemstatus alles gewünschte zeigt, müsste die Konfig doch gar
> nicht mehr angepasst werden?
Nein, dann nicht

> Wenn ich den Systemstus oder Analyzer laufen
> habe, dann tragen die die ankommenden Werte in die DB ein? Also MUSS ich
> den Logger vorher stoppen?
Ja, du must den Logger zuvor stoppen und ja, die SW-Anteile:Systemstatus 
und SW-Analyser tragen die Daten auch in die DB's ein. Ist ja der 
gleiche SW-Unterbau nur mit GUI dabei.
Du must den Logger stoppen weil sonst mehr als eine Applikation auf dem 
tty-Port rumnudeln.
Frei nach Hitchcock: 'Bei Aufruf Portmord!'.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

also es muss tatsächlich nichts angepasst werden. Ich glaube mir wurde 
die Anzeige durch die 6000er Werte verzerrt, so dass ich dachte, die 
anderen Werte wäre eine Nullinie. Jetzt hab ich die (wie oben 
beschrieben) nicht vorhandenen Werte rausgenommen und die Datenbanken 
neu aufgebaut.
Und nun kommen auch richtige Anzeigen.

Leider noch nicht für WW, aber da kann ich warten. Oder falls Du den 
neuen Decoder schon fertig hast, würde ich den natürlich gern Betatesten 
:-)))

[Norbert S. (junky-zs)]

Hallo,
es hat sich mal wieder etwas auf der Softwareseite (hometop_HT3) getan.

Folgende Neuerungen/Verbesserungen sind im Release: 0.1.6 enthalten:
1. Fehlende Dekodierung für WW-Telegramme (88 00 34 00) mit 25 Byte 
Länge hinzugefügt.
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

2. Fehlende Dekodierung für 90 00 FF 00 mit 9Byte und 11Byte Länge 
hinzugefügt.
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

3. Überprüfung auf MAX-Werte und bei Überschreitung setzten auf 
Default-Wert bei den Temperaturwerten. Diese Werte (Max/Default) stammen 
aus dem Konfigurationsfile und werden beim Start der Applikation 
einmalig gelesen.
Beitrag "Re: Heizungs-Datenerfassung (HT3)"

4. Neue Konfigurations-Möglichkeit für das DatenInterface.
Es ist jetzt möglich im Konfigurationsfile: 
'./HT3/sw/etc/config/HT3_db_cfg.xml'
die Interface-Parameter einzustellen.

Per Default steht dort unter <data_interface>:
  <baudrate>9600</baudrate>
  <serialdevice>/dev/ttyAMA0</serialdevice>
Die Konfiguration der Schnittstelle kann jetzt nur noch zentral im 
Konfigurationsfile gemacht werden (ist ja kein Nachteil) hat aber zur 
Folge, daß die alten Konfigurationsfiles entweder:
4.1 Angepasst werden müssen oder
4.2 besser das neue Konfig-File nehmen und dessen Inhalt an die Anlage 
anpassen.
Fakt ist jedenfalls, altes Konfigfile und neue Software--> läuft 
schlecht bis garnich.

5. Dokumentation ist angepasst für neue Konfig-Parameter und den 
Hardware-Anteil 'ht_transceiver'.

Hinweis: Die Software des 'ht_transceiver' muss erfreulicherweise nicht 
aktualisiert werden.

Wo gibt es das ganze?
 https://github.com/norberts1/hometop_HT3

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

super, vielen Dank.

Gibt es eine Empfehlung von Dir, wie ich am besten update ohne meine 
vorhandenen Daten zu überschreiben?

Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,
>Gibt es eine Empfehlung von Dir, wie ich am besten update ohne meine
>vorhandenen Daten zu überschreiben?
Das Konfigfile im aktuellen Release 0.1.6 hat identische 'logitems' mit 
bleichen Namen wie beim Release 0.1.5.
Nur das 'data_interface' ist ja hinzugekommen und einige 'UNKNOWN'-Werte 
bei <maxvalue>-Temperaturwerten sind jetzt gesetzt. Daher müssen die 
Datenbanken NICHT neu angelegt werden. Der alte Inhalt kann weiter 
benutzt werden.
Außnahmen gibt es aber auch hier:
--> Falls jemand das alte Konfig-File mit zusätzlichen 'logitem' 
versehen oder umgekehrt gelöscht hat, so muss er dies auch in gleicher 
Weise im NEUEN Konfig-File machen, und das bevor die Applikation 
gestartet wird!

In beiden Fällen, wenn Anzahl und Namen der logitems identisch bleibt, 
braucht die Datenbank nicht aktualisiert zu werden.
Die NEUE Software 0.1.6 kann dann nach Installation direkt verwendet 
werden.
Es wird ja eine schon vorhandene Datenbank NICHT überschrieben!

Gruß Norbert

[Stephan T. (stephant)]

Hallo,

nach dem Update läuft alles (wieder).

Jetzt hätte ich aber gern die Y-Skalierung (auch) auf der rechten Seite 
der Grafiken.

Wer kann helfen?

Danke,
Stephan

[Stephan T. (stephant)]

Hallo,

noch eine andere Frage: Die aktuelle Pumpenleistung ist wohl noch nicht 
berücksichtigt, oder? Es ist in der Telegrammbeschreibung beim 880019er 
Telegramm zwar Byte 13 aufgeführt, aber wird wohl nicht in die DB 
geschrieben.
Dabei sollte es von den Werten her schon passen, denn bei mir schwankte 
die i16-Anzeige (HT4i) immer zwischen 96% und 100% und das würde gut zu 
den gesendeten Hex-Werten 60 und 64 passen.
Ich habe jetzt mal die Pumpenkennlinie von Konstantdruck auf 
Proportionaldruck umgestellt (minimal 30%) und jetzt kommt der Hex-Wert 
29, was genau den angezeigten 41% entspricht.
Also kann man die Vermutung doch wohl bestätigen, dass Byte 13 die 
Pumpenleistung ist?

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stefan,
gut zu hören, das auch die Version 0.1.6 läuft!

>Jetzt hätte ich aber gern die Y-Skalierung (auch) auf der rechten Seite
>der Grafiken.
Schau mal in die Doku rein: 
http://oss.oetiker.ch/rrdtool/doc/rrdtool.en.html
Im script: ./HT3/sw/etc/rrdtool_draw.pl läßt sich dies anpassen.

>Die aktuelle Pumpenleistung ist wohl noch nicht berücksichtigt, oder?
Stimmt, die Pumpenleistung ist noch nicht in der Datenbank. Deshalb hier 
eine kleine Anleitung wie man fehlende Werte noch in:
1. GUI und 2. Datenbank bekommt.
Im Konfigfile sind V_spare(x) Werte abgelegt. Diese kann man für neu 
erkannte Werte nutzen ohne die Datenbanken neu anlegen zu müssen.

Nötige Anpassungen (hier für die Pumpenleistung angepasst):
1. ./HT3/etc/config/HT3_db_cfg.xml
Bei <systempart name="heizgeraet"> und item 'V_spare_1' ändern:
....
        <logitem name="V_spare_1">
            <datatype>INT</datatype>
            <datause>GAUGE</datause>
            <maxvalue>100</maxvalue>
            <default>0</default>
            <unit>%</unit>
            <displayname>Heizpumpenleistung</displayname>
.....
2. Decode-modul anpassen: ./HT3/sw/lib/ht3_dedode.py
2.1 In Methode: 'HeizgeraetMsg' Zeile: 198 deaktivieren
   ## only deactivation ->self.__gdata.update(nickname,"V_spare1",0)
2.2  In Methode: 'HeizgeraetMsg2' Zeilen: ab ca. 228 ändern in
            i_pumpenleistung   =int(buffer[13])
            self.__gdata.update(nickname,"V_spare1",i_pumpenleistung)

3. GUI - Anzeige anpassen (falls gewünscht)
In Methode '__Heizgeraet' ab ca. Zeile: 353 ergänzen mit
        tempvalue=format(int(self.__gdata.values(nickname,"Vspare1")))
        temptext =self.__DisplayColumn(nickname,"Vspare1",tempvalue)
        if len(temptext)>0: self.__text.insert("end",temptext)

4. Anpassen rrdtool Grafik-Ausgabescript (rrdtool_draw.pl):
Ab Zeile 108 in $rc = $heizgeraet_rrdh->graph(...  Anpassungen machen 
für die Heizungspumpe
(Ich habe die Anzeige 'Heizungspumpe' entfernt und statt dessen deren 
Punmpenleistung als anzuzeigenden Wert genommen. Die Werte sind: 
Wert/10, da sonst die Anzeige besch.. aussieht):
 #zs ######### deaktivieren
 #  draw           => {
 #    dsname => 'V_heizungs_pumpe',
 #    type  => "hidden",
 #    name  => 'Heizungspumpe',
 #  },
 #############
 #zs neu, statt V_heizungs_pumpe jetzt der Leistungswert in %
   draw           => {
    dsname => 'V_spare_1',
    type  => "hidden",
    name  => 'Heizungspumpenleistung',
  },
 #zs ######### deaktivieren
 #  draw    => {
 #    color  => '008d00',
 #    type  => "area",
 #    legend => 'Heizungspumpe\l',
 #    cdef  => "Heizungspumpe,5,*"
 #  },
 #############
 #zs neu, statt V_heizungs_pumpe jetzt der Leistungswert in %
  draw    => {
    color  => '008d00',
    type  => "area",
    legend => 'Heizungspumpenleistung\l',
    cdef  => "Heizungspumpenleistung,10,/"
  },

Danach Erfassung neu starten und das wars!
Kann diese Änderungen im nächsten Release mit Einbringen wenn gewünscht!

Gruß Norbert

[Ralf K. (elral)]

Hallo zusammen,

@Stefan,
wenn Du die Y-Saklierung auf der rechten Seite hin bekommst, dann gebe 
doch bitte Bescheid wie Du das gemacht hast. Das ist genau der Punkt in 
den Grafiken, den ich noch nicht hin bekomme habe.

@Norbert,
ich habe heute morgen ein Update gemacht, nun wird leider nichts mehr in 
die SQL-DB und rrdDB eingetragen.
Meine Vorgehensweise war, alle Dateien (ausser den Datenbanken) im 
bestehenden HT3 Ordner zu ersetzen. Dann habe ich das Config File 
angepasst, wobei ich wohl einen neuen Namen für <hardwaretype> angegeben 
habe. Alles andere im Config File habe ich so belassen (1 Heizkreis, 
Anschluss am UART).
Im ht3_logger File habe ich den User angepasst, sonst weiter nichts.

ht3_logger status meldet mir, das der Daemon läuft. in /tmp erscheinen 
keine Fehlermeldungen. minicom zeigt an, dass Daten kommen.

Nun bin ich mal wieder ratlos. Hättest Du nochmal einen Tipp für mich 
was ich wie weiter kondolieren kann.

Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo,

@Ralf
>Dann habe ich das Config File angepasst, wobei ich wohl einen neuen Namen für 
><hardwaretype> angegeben habe.
Der 'hardwaretype' wird nur in der GUI ANGEZEIGT und wird sonst nicht 
benutzt.

>Dann habe ich das Config File angepasst,...
Welche Version hast du genommen, dein altes vom Release 0.1.5 oder das 
neue vom Release 0.1.6 ??

Das alte Konfigurationsfile muss auf jedenfall um die Einträge 
'<data_interface>' erweitert werden, siehe dazu:
Beitrag "Re: Heizungs-Datenerfassung (HT3)".

Ich glaube aber du hast das so gemacht und daher bitte die wichtigen 
Schnittstellen-Einstellungen kontrollieren:
      <parameter name="ASYNC">
----------------------
1. DEVICE:
        <serialdevice>/dev/ttyAMA0</serialdevice>
oder
        <serialdevice>/dev/ttyUSB0</serialdevice>
----------------------
2. LEER lassen
        <inputtestfilepath></inputtestfilepath>
----------------------
3. BAUDRATE:
        <baudrate>9600</baudrate>
ODER für 'ht_transceiver' !!!!!!!!!!!!!!!!!!!!!!
        <baudrate>19200</baudrate>
----------------------
4. Bleibt so:
        <config>"8N1"</config>  <!-- only 8N1 available -->

Warscheinlich hast du noch die Baudrate auf 9600 stehen!

!!!!!!!!!!! Für den 'ht_transceiver' muss die BAUDRATE auf 19200 Baud 
eingestellt werden !!!!!!!!!!!

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
> Kann diese Änderungen im nächsten Release mit Einbringen wenn gewünscht!

Hallo Norbert.

ich denke schon, dass die Pumpenleistung interessant ist, denn laut 
diverser Berichte ist die Heizungspumpe der Stromfresser Nummer 1 in 
einem Haushalt. Insofern macht es schon einen Unterschied, ob die Pumpe 
die ganze Zeit mit 50% oder 100% läuft. Ich habe vor 2 Tagen von 
Konstantdruck auf Proportionaldruck umgestellt und die Heizung läuft wie 
vorher, nur eben mit viel weniger Pumpenleistung. Problematisch ist 
aber, dass kaum ein Heizungsbauer das wirklich gut einstellen kann. Das 
ist immer Trial-and-Error und viele Heizungsbauer kennen im Zweifelsfall 
nur Vollgas.
Frage mal 10 Firmen nach dem hydraulischen Abgleich (besondere kleinere 
Firmen). Da wird immer überdimensioniert.

Ich habe die Pumpenleistung jetzt gemäß Deiner sehr guten Beschreibung 
dazugefügt. Bei Punkt 3 fehlt die Angabe der Datei: gui_worker.py.
Etwas graue Haare hat mir das Python schon wachsen lassen, denn ich habe 
Deinen Text copy/paste eingefügt und hatte dann immer einen TabError und 
kein Script ist gestartet. Hab dann irgendwann gefunden, dass Python 
keine Tabs haben darf sondern stattdessen 4 Leerzeichen. Optisch sieht 
das gleich aus...

Ebenfalls hab ich die Teilung durch 10 wieder rausgenommen und type=area 
rausgemacht, denn das war mir dann doch zu fitzelig da unten in den 
ersten 10%. Jetzt sieht es wie angehängt aus und macht so auch Sinn 
(glaub ich).

Nur mit dem Label rechts komm ich nicht weiter. Ich habe die 
rrdtool-Anleitung durchgelesen und eigentlich müsste es "right-axis 1:1" 
sein, aber wenn ich die folgenden Parameter verwende bekommen ich Error 
"Illegal parameter 'right_axis' in graph() at 
/usr/local/bin/rrdtool_draw.pl line 89". Dabei ist right-axis auch ein 
Parameter von rrdgraph!?!?

$rc = $heizgeraet_rrdh->graph(
  image      => $ImageHG,
  vertical_label  => 'Temperaturen (Celsius)',
  right_axis    => '1:1',
  right_axis_label  => 'Temperaturen (Celsius)',
  start      => $start_time,
  end        => $end_time,
  width      => $mywidth,
  height      => $myheight,
  title      => 'Heizgerät'.$timestring,
  color      => { back => '#ffdd55',
            canvas => '#fff6d5',
  },

[Stephan T. (stephant)]

Grrr, 3 mal wollte ich gar nicht hochladen, aber nach der Vorschau ist 
der Anhang "keine Datei ausgewählt".

[Norbert S. (junky-zs)]

Hallo Stephan,
>Grrr, 3 mal wollte ich gar nicht hochladen,...
Du weist doch, aller Guten Dinge sind drei!

Sieht wirklich gut aus und hat auf jedenfall einen Mehrwert!
Dies kommt mit ins nächste Release. Daher kann sicherlich: Heizungspumpe 
'läuft/läuft nicht' raus aus der rrdtool-Grafik.
In der Datenbank bleibt es natürlich weiterhin drin!

>Nur mit dem Label rechts komm ich nicht weiter.
Schwierigkeit ist hierbei das PerlModul:
  RRDTool::OO - Object-oriented interface to RRDTool
Dies übernimmt nicht 1:1 die möglichen Befehle/Parameter vom rrdtool 
sondern hat eigene Methoden.
Bitte ruf mal deshalb die Man-Pages vom Tool auf: man RRDTool::OO.

Habe dies kurz überflogen, jedoch keine Beschreibung über die 
Platzierung von Beschriftungen (links/rechts) gefunden.
Ich schau mir dies noch mal im Detail an wenn Zeit dazu ist.

Im Übrigen hast du wohl einen recht heissen Ofen, der geht mit seiner 
Leistung zeitweise über 100% !!???.
Ist dies ein Erfassungs- oder Anzeigefehler?

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
> Im Übrigen hast du wohl einen recht heissen Ofen, der geht mit seiner
> Leistung zeitweise über 100% !!???.
> Ist dies ein Erfassungs- oder Anzeigefehler?

Hmmmmm, das hängt wohl davon ab, wie man 100% definiert. Die ZSB hat ja 
13,3kW max Heizungsleistung, aber 15,1 für WW. Und zu der erwähnten Zeit 
gab es eine Speicherladung und somit sollte er über 100% kommen können, 
sofern die 100% die max. Heizleistung ist.

Aber das bringt mich zu einem anderen Punkt: Ich habe phpLiteAdmin 
installiert, um die SQLite-DB einsehen zu können, aber jetzt kann er 
nichts mehr abrufen, wenn ich nach Datum desc sortieren lasse, denn die 
Abfragen laufen in den 30-Sekunden-Timeout. Also an die aktuellen Werte 
komme ich nicht mehr ran.
Also müsste man entweder einen Primary Key Index draufpacken (geht nur 
mit Tabelle neu erstellen) oder Daten älter als x Tage löschen.
Was wäre denn aus Deiner Sicht das passendere?

[Ralf K. (elral)]

Hallo Norbert,

ich habe noch mein selbstgebautes Interface, Deine Platine habe ich 
leider noch nicht bestückt (ich bin noch an einem anderen Projekt dran).

Klar habe ich das neue Config File genommen, die Schnittstellen 
Einstellungen sind ja auch bereits so vorbelegt (9600N1). Das habe ich 
gerade auch noch einmal kontrolliert.

Können noch an anderer Stelle Fehlermeldungen gespeichert werden?

Wenn alles nichts hilft, mache ich die Tage eine Neu-Installation :(

Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Stephan,
>Ich habe phpLiteAdmin installiert, um die SQLite-DB einsehen zu können, aber 
>jetzt kann er nichts mehr abrufen,...
Ich nutze ein Sql-Plugin für Firefox und damit habe ich das gleiche 
Problem. Es liegt also weniger an dem SQLite externen Tool, sondern an 
den Eigenheiten/Einschränkung von SQLite eben nur wirklich einem 
User/Thread den Zugriff zu erlauben.
Deshalb läuft der SQLite-DB Zugriff in der Applikation auch nur in EINEM 
Thread. Ich hatte die SQLite-DB auch nur als Zwischenwirt für die 
rrdtool-db vorgesehen. Jedoch für eine Analyse ist sie unerlässlich.
Mysql hätte für den Zugriff und Verwaltung natürlich Vorteile.

Bliebe also für dich nur übrig die Applikation kurz zu stoppen und dann 
die DB auszulesen.

>Was wäre denn aus Deiner Sicht das passendere: Primary Key Index draufpacken 
>(geht nur mit Tabelle neu erstellen) oder Daten älter als x Tage löschen.
Ich ziehe Daten älter als x Tage löschen vor aus zwei Gründen:
1. Vorhandene und gut gefüllte Datenbanken brauchen nicht mehr neu 
erstellt zu werden.
2. SQLite hat (zumindest bei mir) Probleme wenn die Datenbank-Grösse 
über 80 bis 90 MByte anwächst.
Deshalb hatte ich schon über einen Wert im Konfigurationsfile 
nachgedacht (so ne art Watermark: Zeit / Grösse) nach der die 
SQLite-Datenbank wieder geschrumpft wird.
Wie gesagt ich hatte bisher nur darüber nachgedacht und noch nicht 
realisiert, aber der Bedarf ist ja wohl da.

Gruß Norbert

[Stefan B. (sbiermann)]

Hallo,
es gibt bei SQLite noch die Möglichkeit Backups zu fahren während die DB 
läuft. Genau das wäre die Lösung für das Problem.
Was allerdings sehr nice wäre, ist wenn man eine beliebige DB nutzen 
kann. Dann kann man für Analysezwecke auf SQLite gehen und während des 
normalen Betriebes auf z.B. Mysql.
Wenn ich die Platine von Norbert bekommen habe, schaue ich mir den Code 
mal genauer an. Mal schauen vielleicht krieg ich da ziemlich einfach 
einen DBLayer eingezogen mit dem man dann beliebige SQL DB ansprechen 
kann. Soweit ich das gesehen habe wird nur Standard SQL Syntax benutzt, 
von daher sollte es eigentlich machbar sein. Ich wollte eh schon mal 
seit längerem meine Python Kenntnisse erweitern.

Viele Grüße
Stefan

[Norbert S. (junky-zs)]

Hallo Ralf,
>Können noch an anderer Stelle Fehlermeldungen gespeichert werden?
Das Logging ist z.Zeit wenig vorhanden. Insbesondere beim Tool 
'HT3_Logger.py' fällt dies negativ auf.
Daher mein Vorschlag:
1. Beenden des HT3_Logger.py daemon und diesen ohne erneutes booten so 
in einem Terminalfenster aufrufen. Die Ausgaben werden dir dann 
weiterhelfen.
oder
2. Beenden des HT3_Logger.py und Start von HT3_Analyser.py (im 
Terminalfenster unter der Grafischen Oberfläche beim Pi). Mit der GUI 
siehst du schneller ob Daten kommen. Auch dort werden Meldungen im 
Fenster ausgegeben.
3. Neuinstallation (git clone ... in neues Verzeichnis) würde ich nur 
machen, wenn Pkt1./2. nicht weiterhelfen. Die vorhandenen Datenbanken 
kannst du ja in das neue Verzeichnis ./HT3/sw/var/databases verschieben.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

wenn ich HT3_Logger.py starte, kommt "nur" die Meldung, dass die 
Datenbank existiert und das die rrdtool Datenbank existiert. Nichts 
weiteres.
Breche ich mit CTRL-C ab, kommt eine Meldung mit line 33

Beim starten auf der grafischen Oberfläche von HT3_Analyser.py oder 
HT3_Systemstatus.py passiert rein gar nichts.

Grüße

Ralf

[Stephan T. (stephant)]

Norbert S. schrieb:
> Es liegt also weniger an dem SQLite externen Tool, sondern an
> den Eigenheiten/Einschränkung von SQLite eben nur wirklich einem
> User/Thread den Zugriff zu erlauben.

Hallo Norbert,

auch ich bevorzuge die Methode, alte Daten zu löschen. Denn Daten, die 
nicht da sind, muss man nicht aufwändig sortieren.

Nach meinen Versuchen ist es kein Problem eines gemeinsamen Zugriffs, 
sondern ein reines Performance-Problem. Ich hatte den Logger gestoppt 
und erhalte trotzdem keine Daten. Dann habe ich aus der Tabelle 
Heizgerät alle Daten älter als 3 Tage gelöscht (ca. 20k verbleiben) und 
schon kann ich nach Datum sortieren. Dauert aber immer noch 13s, so dass 
klar ist, dass es mit den 80k Zeilen vorher einfach nicht gehen kann.

Wie viele Tage müssen denn überhaupt vorgehalten werden? Sobald die 
Daten einmal in die rrdtool-DB übertragen wurden, braucht man sie doch 
eigentlich nicht mehr, oder?

Gruß,
Stephan

[Stephan T. (stephant)]

Norbert S. schrieb:
>>Nur mit dem Label rechts komm ich nicht weiter.
> Schwierigkeit ist hierbei das PerlModul:
>   RRDTool::OO - Object-oriented interface to RRDTool
> Dies übernimmt nicht 1:1 die möglichen Befehle/Parameter vom rrdtool
> sondern hat eigene Methoden.
> Bitte ruf mal deshalb die Man-Pages vom Tool auf: man RRDTool::OO.
>
> Habe dies kurz überflogen, jedoch keine Beschreibung über die
> Platzierung von Beschriftungen (links/rechts) gefunden.

Hallo,

habe das Problem mit dem Label rechts gelöst. Mann muss dem OO interface 
diese Parameter erst erlauben, denn standardmäßig sind nur 2 Dutzed 
erlaubt.

Wenn man es wie folgt schreibt vor dem Aufruf der graph-Funktion, dann 
funktioniert es:

$rc = $heizgeraet_rrdh->option_add("graph", "right_axis");
$rc = $heizgeraet_rrdh->option_add("graph", "right_axis_label");
$rc = $heizgeraet_rrdh->graph(
  image      => $ImageHG,
  vertical_label  => 'Temperaturen (Celsius)',
  right_axis    => '1:0',
  right_axis_label  => 'Temperaturen (Celsius)',
  start      => $start_time,
  end        => $end_time,
  width      => $mywidth,
  height      => $myheight,
  title      => 'Heizgerät'.$timestring,
  color      => { back => '#ffdd55',
            canvas => '#fff6d5',
  },

[Norbert S. (junky-zs)]

Hallo,

@Stephan
>habe das Problem mit dem Label rechts gelöst.
Prima, danke dir. Da muss man erst einmal drauf kommen!

>Wie viele Tage müssen denn überhaupt vorgehalten werden?
Geschmackssache, macht man es kurz sind die Daten weg die man gerade 
noch haben wollte. Macht man es lang, wird alles ein wenig zäher.
Deshalb wird es konfigurierbar und jeder kann es so einstellen wie 
gewünscht.

@Ralf
Etwas merkwürden das ganze! Habe selber es einmal so gemacht wie 
du:Kopieren der neuen Files in das alte Verzeichnis (0.1.6 kopiert nach 
alt 0.1.5) und es läuft!
Bitte Versuch noch folgendes:
1. Deaktivieren der Datenbank-Zugriffe im Konfig-file: 
'./HT3/sw/etc/config/HT3_db_cfg.xml'
    <!-- sql-database -->
    <dbname_sqlite>./var/databases/HT3_db.sqlite</dbname_sqlite>
    <sql-db>
      <enable>off</enable>
    </sql-db>
und
    <rrdtool-db>
      <enable>off</enable>
      <step_seconds>60</step_seconds>
      ...
2. Applikation neu starten (am besten HT3_Analyser.py) und auf Daten 
warten
3. Kontrolle ob die Schnittstelle korrekt eingestellt wurde mit:
    stty -F /dev/ttyAMA0
   Dort muss bei dir dann 9600 Baud zu finden sein 
(HT3-mini/micro-Adapter).

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
> Geschmackssache, macht man es kurz sind die Daten weg die man gerade
> noch haben wollte.

Hallo Norbert,

nun, wenn es nur darum geht, die Daten der letzten 2 Tage mit rrdtool 
grafisch anzuzeigen, wieviel Daten braucht das unbedingt? Ich habe mal 
im HK1 alle Daten in der HT3_db vor heute gelöscht, das draw-Script 
aufgerufen und er zeigt trotzdem noch alles. Klar, kommt ja auch aus der 
rrd-DB und nicht aus der HT3-DB.
Also wenn ich die Daten nicht noch für irgendetwas anderes benötige, 
dann können die doch gelöscht werden, oder?
Wie wird eigentlich verwaltet, welche Daten aus der HT3-DB bereits 
verarbeitet sind? Alle bearbeiteten Daten werden dann mit Timestamp in 
die rrdtools_info geschrieben und es werden somit nur welche als "neu" 
betrachtet, die hier noch nicht drinstehen, richtig?
Oder wie arbeitet das zusammen?

[Norbert S. (junky-zs)]

Hallo,

Stephan schrieb:
>Also wenn ich die Daten nicht noch für irgendetwas anderes benötige,
>dann können die doch gelöscht werden, oder?

Ja, das kann man dann so tun.
Es werden alle 60 Sekunden die Daten (sofern vorhanden) aus der 
SQLite-DB in die rrdtool-db übertragen.
Durch den UTC-Timestamp wird auch bei Sommer-/Winterzeit-Umstellung 
immer dafür gesorgt das eine inkrementelle Zeit als Referenz genommen 
wird.
Das rrdtool mag es nicht, wenn mehrmals ein logitem mit gleichem 
Zeitstempel beschrieben werden soll.
Diese Verwaltung wird in der 'rrdtool_infos'-Tabelle gemacht.
Die schon übertragenen Daten können danach natürlich aus der SQLite-DB 
gelöscht werden.

Man kann wohl auch ganz auf die SQLite-DB verzichten und gleich die 
Daten in die rrdtool-DB schreiben. Einige Informationen hat man dann 
allerdings nicht zur Verfügung (hexdump, Zwischenwerte innerhalb einer 
Minute etc.).
Aber ich glaube so wie es jetzt ist hat man eine gute Alternative die 
SQLite raus und Mysql reinzubringen und auf rrdtool zu verzichten.

Ich will hier aber an dieser Stelle kein Wunschkonzert vom Zaun brechen 
und egal wie man etwas gerade realisiert wird es an anderer Stelle 
anders gebraucht.


Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
> Ich will hier aber an dieser Stelle kein Wunschkonzert vom Zaun brechen
> und egal wie man etwas gerade realisiert wird es an anderer Stelle
> anders gebraucht.

Hallo Norbert,

ich denke man kann es so lassen, denn so kann jeder selbst entscheiden, 
welche Daten er vorhalten will oder nicht. Ich habe jetzt in den crontab 
folgendes gesetzt:
"0  18      *   pi    sqlite3 
/home/pi/hometop_HT3/HT3/sw/var/databases/HT3_db.sqlite "DELETE FROM 
heizgeraet WHERE Local_date_time < strftime('%Y.%m.%d','now','-0 
days');""

Damit sollte er jeden Abend um 6 die Daten von gestern oder älter 
löschen. Bis dahin hat man noch Zeit, was zu retten, wenn man es doch 
mal noch braucht. Man muss natürlich noch sqlite3 installieren und die 
anderen Tabellen je nach Bedarf hier auch reinpacken.
Dann hat man schlanke Datenbanken.

Insbesondere der Abgleich, welche Daten schon bearbeitet wurden, wird 
wohl sonst im Laufe der Zeit immer länger dauern.

[Marcus S. (marcus72)]

Hallo,

sehe ich es richtig, dass der die Soll-Vorlauftemperatur über den Bus 
nur ohne Nachkommastelle geliefert wird?

Das wundert mich ein wenig, da meine Steuerung FW100 diese Temperatur im 
Display mit einer Nachkommastelle anzeigt.

Die Genauigkeit müsste also eigentlich da sein ...

VG
Marcus

[Norbert S. (junky-zs)]

Hallo,

Marcus Schlappa schrieb:
>... dass der die Soll-Vorlauftemperatur über den Bus nur ohne Nachkommastelle 
>geliefert wird?

Ja, das Telegramm 88 00 18 00 <Vorlauf-Wert> ... überträgt diesen 
Wert(Byte4) 'T-Soll (Regelung)' nur als Byte-Wert ohne Nachkommastellen.
Dieses Steuergeräte-Telegramm ist eine Meldung an ALLE (Byte1 := 00),
der Regler (FWxyz) wird jedoch den Soll-Wert mit einem separatem 
Telegramm an die Steuerung übertragen (z.B.: 90 08 18 00 ...).
Dieser Telegramme-Type (von Quellen an einzelne Ziele/Geräte) wird 
z.Zeit nicht ausgewertet auch weil viele der Informationen sich in den 
Telegrammen an ALLE wiederfinden.

>Das wundert mich ein wenig, da meine Steuerung FW100 diese Temperatur im
>Display mit einer Nachkommastelle anzeigt.

Welche Anzeige des Reglers (FW100) meinst du?
1. Ohne Bedienung des Reglers und Wandanbau zeigt dieser die 
Raumtemparatur an.
2. Mit Bedienung des Knopfs zeigt der die gewünschte Solltemperatur an.
3. Im Menu 'INFO' gibt es noch  beim Heizkreis die 'Geforderte 
Vorlauftemperatur'.
Alle drei Werte haben Nachkommastellen, werden aber mit 
unterschiedlichen Telegrammen zur Steuerung gemeldet. Die Steuerung 
sendet dann die Werte wieder mit ihren eigenen Telegrammen auf dem Bus 
(z.B. 88 00 18 ..) bei denen einzelne Werte wohl gerundet sind.

Gruß Norbert

[Marcus S. (marcus72)]

Norbert S. schrieb:

Hallo Norbert,

> Welche Anzeige des Reglers (FW100) meinst du?
> 3. Im Menu 'INFO' gibt es noch  beim Heizkreis die 'Geforderte
> Vorlauftemperatur'.

Ich hatte die "geforderte Vorlauftemperatur" gemeint.

Dann besteht ja noch Hoffnung, den Werte mit Nachkommastelle irgendwie 
auf dem Bus wiederzufinden.

Danke für die Hintergrundinformationen.

VG
Marcus

[Norbert S. (junky-zs)]

Hallo,

@Alle
!! WICHTIGER Hinweis, weil offensichtlich nicht allen bekannt !!

Die AKTUELLE Software zum Projekt ist NICHT mehr hier im Forum zu finden 
sondern:

1. Alles was den RaspberryPi / PC (USB) angeht zu finden unter:
   https://github.com/norberts1/hometop_HT3

2. Alles was den 'ht_transceiver' (ht_piduino/ht_pitiny) angeht zu 
finden unter:
   https://github.com/norberts1/hometop_ht_transceiver

Beide Anteile gehören zusammen, der ht_transceiver sendet keine 
Netcom100 Befehle ohne externe Software.

Die Sendesoftware wird im Repository: 'hometop_HT3' zu finden sein 
sobald die fertig ist.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

@Alle,
Es hat sich wieder etwas bei der Software getan.
Die aktuelle Version ist: 0.1.7.1 und enthält:
1. ht_proxy neu und Socket-Handling aktiviert.
2. Logging in allen lib-Modulen und Applikationen.
3. Heizungssteuerung mit 'ht_netclient' jetzt möglich
  (NetCom like, allerdings nur für Adaptertype: 'ht_transceiver').

Details stehen in der aktualisierten Dokumentation unter: ./HT3/docu
Es ist erfreulicherweise nur die 'hometop_HT3'-software zu 
aktualisieren. Der Software auf dem 'ht_transceiver' hat sich nicht 
geändert.
Bitte das eigene lokale Abbild aktualisieren.
  git clone https://github.com/norberts1/hometop_HT3.git

Die Bilder geben eine Übersicht über das System und die möglichen 
Hardware-/Software-Konfigurationen.
Auch die Adaptertypen: HT3-miniAdapter und HT3-microAdapter können mit 
dem 'ht_proxy' betrieben werden.
Die Applikationen 'HT3_Analyser.py', 'HT3_SystemStatus.py' und 
'HT3_Logger.py' können als 'ht_clients' betrieben werden, es ist dazu 
nur die Konfiguration auf: <comm_type>SOCKET einzustellen (Default).

Auch die vorhandenen Datenbanken werden vom neuen Software-Release nicht 
überschrieben und die Struktur hat sich nicht geändert.
Nach erfolgreicher Installation auf dem Raspberry PI müssen folgende 
HT-Prozesse aktiv sein:
... /usr/bin/python3 /home/pi/HT3/sw/etc/html/httpd.py
... /usr/bin/python3 /home/pi/HT3/sw/ht_proxy.py
... /usr/bin/python3 /home/pi/HT3/sw/HT3_Logger.py <<-- läuft als client

Bis zu 3 weitere ht_proxy-Clients auf RaspberryPi-externen Rechnern 
laufen stabil und der 'ht_proxy'-Server hat noch Luft nach oben 
(getestet auf RaspberryPi B).

Im Kapitel: '2.5.3.1 ht_netclient Steuerbefehle' der Dokumentation sind 
die möglichen Befehle zur Heizungssteuerung beschrieben.
Hinweis:
Falls jemand ein MB-Lan oder NetCom100 an seiner Heizung betreibt, so 
muss VOR dem Anschluss des 'ht_transceivers' an den HT-Bus die 
Geräteadresse des Adapters geändert werden wie folgt:
  ./ht_netclient.py -ht_adr 10     (Neue Geräteadresse)
  ./ht_netclient.py -ht_rst 1      (Reset des ht_transceivers)
Nach dieser Änderung können der 'ht_transceiver' und MB-Lan ODER 
NetCom100 parallel betrieben werden.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

es hat sich mal wieder etwas auf der darstellenden Software-Seite getan.

Habe zum Test das FHEM-Modul 89_HEATRONIC.pm für die Anbindung an den 
'ht_proxy'-Server erweitert. Somit läuft FHEM als 'ht_proxy'-client und 
stellt u.A. die Daten grafisch dar.
Wie so etwas aussehen kann sieht man im Bild.
Das alles ist noch in Arbeit und noch nicht abgeschlossen, wird aber 
a.s.a.p. in FHEM wiederzufinden sein. Zur Zeit ist dies noch nicht der 
Fall.
 http://fhem.de/commandref.html#HEATRONIC
Danke an die vielen Helfer die dies so überhaupt möglich machen!

Die Steuerung der HT-Heizung über das FHEM mit HEATRONIC ist noch nicht 
enthalten, jedoch ein erklärtes Ziel was zu erreichen sich lohnt!

Aber Vorsicht!
Lotto und FHEM können süchtig machen :-)

Gruß Norbert

[Stephan (Gast)]

Hallo,
nach nunmehr 5 Monaten Betrieb habe ich festgestellt, dass auf der 
HTML-Seite keine Werte mehr angezeigt werden.
HT3_Logger läuft immer noch und auch in der sqLite-DB stehen aktuelle 
Werte drin. rrdtool_draw läuft laut syslog ebenfalls noch und die 
erstellten Grafiken zeigen auch korrekten Tag und Zeit.
Sobald ich den Pi neu starte, geht auch alles wieder, aber es ist jetzt 
schon das zweite Mal, dass einfach Werte nicht mehr gezeigt werden.
Ich vermute, dass rrdtool die Werte aus irgendeinem Grund nicht in seine 
Datenbank übernommen hat. Wo kann ich möglicherweise Logdateien finden, 
die mir einen Grund nennen können?
Was könnte sonst die Ursache sein?

[Martin S. (matz666)]

Hallo Stephan.

Wie groß ist deine SQL Datenbank???

Habe selber leidvoll feststellen müssen das die Datenbank ab 80MB Größe 
nicht mehr korrekt funktioniert.

Ist bei mir immer daran zu erkennen das die Grafiken Lücken aufweisen.

Hab nun ein Script zusammengebaut das die Datenbank automatisch leert am 
1. des Monats auf die letzten 30 Tage.

[Stephan (Gast)]

Hallo Martin,

daran dürfte es nicht liegen. Meine DB ist grad mal 7,2MB groß, da ich 
abends um 6 alle Daten von gestern und älter lösche (steht ja eh alles 
in rrd-DB drin). Sind aktuell 43k Datensätze insgesamt. Und durch einen 
simplen Neustart (der ja das Problem behebt), wird die DB ja nicht 
kleiner.

Und wie gesagt, die Werte stehen ja auch drin, sind aber nicht auf der 
Grafik drauf. Also vermute ich ein Problem damit, dass rrd die Daten 
nicht in seine eigene DB rübernimmt.

Gruß,
Stephan

[Stephan (Gast)]

Noch ein Hinweis: In der Tabelle rrdtool_infos steht für "vor dem 
Neustart" immer "Error:True" und nach dem Neustart "None".
Also gab es rrdtool-Probleme, die durch einen Neustart weg sind.

[Ralf K. (elral)]

Hallo zusammen,

und ich dachte es läge mal wieder an mir, dass die Daten mittlerweile 
gar nicht mehr dargestellt werden. Zuerst gab es Lücken die immer größer 
wurden, seit einiger Zeit wird nun gar nichts mehr dargestellt. Da 
scheine ich ja dann doch nicht der einzige zu sein.
Meine SQLite DB ist 302MB. Würde das reduzieren ja gerne mal testen, nur 
wie?

Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Stefan,
um dem Problem beizukommen hast Du folgende Möglichkeiten (Rev.: >= 
0.1.7.1):
1. Logfile-Inhalt kontrollieren -->> ./HT3/sw/var/log/ht_logger.log
Fehler werden dort als 'CRITICAL' eingetragen.

2. Im /tmp-Verzeichnis werden die Perl-scripte für den Eintrag in die 
rrdtool-db erzeugt und ausgeführt. Im Fehlerfall bleiben diese Scripte 
dort liegen und enthalten einen Fehlerwert / Fehlertext.
Diese Scripte lassen sich auch von Hand ausführen und geben dann im 
Terminal-Fenster noch weitere Hinweise vom rrdtool, was danebengeht.
Um dies machen zu können darf natürlich der RaspberryPi nicht gebootet 
werden sonst ist /tmp leer!

>...daran dürfte es nicht liegen. Meine DB ist grad mal 7,2MB groß, da ich
>abends um 6 alle Daten von gestern und älter lösche.
Wie löscht Du die Datenbank: mit sql-Befehlen oder durch Neuanlegen der 
DB ?
Falls Du mit sql-Befehlen löscht ist eventuell der VACUUM-Befehl 
erforderlich. Diese Methode (vacuum) ist in der ./lib/db_sqlity.py 
enthalten, jedoch wird die noch nicht automatisch aufgerufen.

Da Du jedoch ein Problem bei der rrdtool-db vermutest solltest Du zuerst 
Pkt.2. ausführen. Hinweis: Die Perl-scripte im /tmp-Verzeichnis darf man 
nur einmal ausführen da das rrdtool doppelte Einträge (mit gleichem 
Zeitstempel) mit Fehler quittiert.

Noch ein wichtiger Hiweis:
Falls Du zwei und mehr Applikationen (HT3_Logger.py und HT3_Analyser.py 
etc.) gleichzeitig betreibst kommt es zu doppelten Einträgen in die 
rrdtool-Datenbank mit zugehörigen Fehlermeldungen. Für diesen Sonderfall 
muss die zweite und jede weitere Applikation in eine andere Datenbank 
schreiben.

Gruß Norbert

[Stephan (Gast)]

Ralf K. schrieb:
> Meine SQLite DB ist 302MB. Würde das reduzieren ja gerne mal testen, nur
> wie?

Hallo Ralf,

ich habe dafür eine Batchdatei geschrieben, welche abends automatisch 
ausgeführt wird und alle Daten vom Vortag und älter löscht. Somit sind 
in der DB nur noch die Daten des aktuellen Tages. Sofern man nur die 
Ausgabe im rrdtool anstrebt, reicht das locker, denn die Daten werden ja 
alle paar Minuten in die rrdtool-DB übertragen und sind dann eigentlich 
"überflüssig".

/usr/bin/sqlite3 /home/pi/hometop_HT3/HT3/sw/var/databases/HT3_db.sqlite 
"DELETE FROM heizgeraet WHERE Local_date_time < 
strftime('%Y.%m.%d','now','-0 days');"
/usr/bin/sqlite3 /home/pi/hometop_HT3/HT3/sw/var/databases/HT3_db.sqlite 
"DELETE FROM heizkreis1 WHERE Local_date_time < 
strftime('%Y.%m.%d','now','-0 days');"
/usr/bin/sqlite3 /home/pi/hometop_HT3/HT3/sw/var/databases/HT3_db.sqlite 
"DELETE FROM rrdtool_infos WHERE Local_date_time < 
strftime('%Y.%m.%d','now','-0 days');"
/usr/bin/sqlite3 /home/pi/hometop_HT3/HT3/sw/var/databases/HT3_db.sqlite 
"DELETE FROM sysdatetime WHERE Local_date_time < 
strftime('%Y.%m.%d','now','-0 days');"
/usr/bin/sqlite3 /home/pi/hometop_HT3/HT3/sw/var/databases/HT3_db.sqlite 
"DELETE FROM warmwasser WHERE Local_date_time < 
strftime('%Y.%m.%d','now','-0 days');"

[Stephan (Gast)]

Hallo Norbert,

zu 1. eine ht_logger.log habe ich nirgendwo finden können. Auch das 
beschriebene log-Verzeichnis unter /HT3/sw/var/log gibt es bei mir 
nicht. In der Github-Version vom Januar war das noch nicht drin. Habe 
das Verzeichnis mal manuell angelegt. Ist das Logging hierfür 
möglicherweise erst später dazugekommen? Möchte eigentlich nicht meinen 
aktuellen Stand mit dem aktuellen Github-Stand überschreiben, denn es 
sind ja schon einige Sachen auf die Heatronic 4i angepasst.

zu 2. muss ich auf das nächste Mal warten, denn jetzt ist /tmp 
tatsächlich leer

Die DB leere ich täglich mit den DELETE-Befehlen aus dem Post davor. 
Scheint auch gut zu gehen, denn vor dem VACUUM sind es gerade 5,5MB 
gewesen und danach auch wieder 5,5MB. Bringt also nichts extra.

Nein, ich stoppe immer den Logger, wenn ich den Analyser ausführen will. 
Aber das habe ich so oder so schon 2-3 Monate nicht gemacht. Nur ganz am 
Anfang.

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,
die SW-Version vom Januar ist:Ver:0.1.6  und enthält noch kein 
Error-Logging.
Das Logging ist schon hilfreich gerade für den HT3_Logger.py, da man bei 
dem ja sonst einen Blindflug macht.
Erst ab der Version 0.1.7.1 ist dieses Error-Logging in allen 
Library-Modulen enthalten.
Es sind noch weitere Zutaten dabei (ht_proxy und senden von 
Bus-Kommandos) aber an den Datenbank-Klassen hat sich nichts geändert.
Somit hilft Dir die aktuelle Version nicht direkt für Dein Problem 
(ausser das Logging).

Stephan schrieb:
>Möchte eigentlich nicht meinen aktuellen Stand mit dem aktuellen Github-Stand 
>überschreiben, denn es sind ja schon einige Sachen auf die Heatronic 4i 
>angepasst.
Meinst Du mit diesen Anpassungen an Heatronic 4i diejenigen die in der 
SW-Version 0.1.6 schon drin sind ?
Falls ja, so kann ich dich beruhigen. Ich halte die SW-Version möglichst 
abwärtskompatibel und das was einmal drin ist bleibt auch drin. Es wird 
höchsten verbessert aber nicht gelöscht (ausser da sind Fehler drin).

Oder hattest Du zusätzlich noch Verbesserungen eingearbeitet ?
Falls ja schicke die mir zu, dann kann ich das in ein nächstes Release 
einpflegen.

Nach welcher Zeit tritt der Fehler auf Stunden, Tage oder Wochen ?

Gruß Norbert

[Ralf K. (elral)]

Hallo Stephan,

vielen Dank, bleibt aber noch eine Frage.
Den Befehl sqlite3 findet er nicht, welches Paket muss ich noch 
installieren?

Danke und Grüße

Ralf

/edit: warum finde ich die Sachen immer erst, wenn ich die Frage 
gepostet habe?
Also sqlite3 ist installiert, jetzt probiere ich das erst einmal 
"händisch"

[Stephan (Gast)]

Norbert S. schrieb:
> Meinst Du mit diesen Anpassungen an Heatronic 4i diejenigen die in der
> SW-Version 0.1.6 schon drin sind ?

Hallo Norbert,

also aus meiner Erinnerung hatte ich damals gemacht:
1. Anpassung an das längere WW-Telegramm. Das sollte jetzt ja auch in 
der normalen Version funktionieren.
2. Anpassungen für die Heizungspumpenleistung (hatten wir damals 
besprochen, 18.1.), aber aus der Beschreibung der 1.7.x-Version ist 
nicht zu erkennen, ob die Pumpenleistung hier berücksichtigt wird.
3. Anpassungen für die rrdtool-Grafiken (Label rechts usw.)

Da es bei mir seit Ende Januar lief, habe ich es so gelassen, werde aber 
mal bei etwas freier Zeit und schlechtem Wetter den alten Stand sichern 
und den neuen probieren.

Norbert S. schrieb:
> Nach welcher Zeit tritt der Fehler auf Stunden, Tage oder Wochen ?

Es waren bei den beiden letzten Malen rund 1-2 Monate. Genau weiss ich 
das ja nicht, denn rrd zeigt ja nur 2 Tage. Ich werde beim nächsten Mal 
die Daten im Temp ansehen und dann sehen wir weiter.

[Ralf K. (elral)]

Hallo Stephan,

die Befehle zum verkleinern habe ich erst einmal einzelnd in einem 
Terminal ausgeführt. Hat alles geklappt, die Daten werden nun auch 
wieder grafisch dargestellt.

Danke und Grüße

Ralf

[Nils R. (augur)]

Hi.

Ich würde gerne die Infos in eine "echte" Datenbank übertragen (z.B. auf 
einem leistungsstarkem Server). Hat sich schon jemand Gedanken gemacht, 
wie man dies am Besten bewerkstelligen könnte z.B. per Textfile? Muss 
man ja nicht neu erfinden das Rad.

Viele Grüße,
Nils

[Stefan B. (sbiermann)]

Holas,
durch die Proxy Lösung von Norbert kannst du dich von jedem beliebigen 
Rechner aus verbinden. Allerdings schafft der "alte" Pi nicht mehr als 2 
Verbindungen ohne komplett ausgelastet zu sein.
Für das Ganze würde sich eine time series Database wie influxxDB oder so 
eignen als "richtige DB". influxxDB hat den Vorteil du kannst die 
Datenbank einfach per REST-Calls füllen und bekommst noch eine Horde an 
weiteren Tools für eine grafische Auswertung zur Verfügung. Anbinden 
könnte man die in dem man ein kleines Python script schreibt welches 
sich mit dem Proxy verbindet und dann an die influxxDB per http post 
schickt.
Um wirklich jede DB oder sonstige Anwendung zu unterstützen, wäre es 
meiner Meinung nach das Beste wenn anstelle des Proxy oder als 
Proxyclient ein MQTT-Client eingesetzt wird. Der kann dann die Daten als 
MQTT Messages verschicken. Dann können beliebig viele verschiedene 
Geräte/Server/Prozesse/Datenbanken an der MQTT-Queue lauschen und die 
Daten empfangen. Dürfte meiner Meinung nach die beste Lösung sein. Hier 
ein recht ausführlicher Text zu MQTT: 
http://www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html

Viele Grüße
Stefan

[Nils R. (augur)]

Stefan Biermann schrieb:
> Holas,
> durch die Proxy Lösung von Norbert kannst du dich von jedem beliebigen
> Rechner aus verbinden. Allerdings schafft der "alte" Pi nicht mehr als 2
> Verbindungen ohne komplett ausgelastet zu sein.

Hi.

Ist es mit dem Proxy möglich quasi "Plugins" zu bauen? Habe noch eine 
ältere Version ohne den Proxy und mich damit noch nicht beschäftigt. Mir 
würde es schon reichen, wenn man irgendeine Schnittstelle hat, wo man 
gegen entwickeln kann, ohne dass die Arbeit beim nächsten Update nicht 
mehr funktioniert. :-)

Viele Grüße,
Nils

[Stefan B. (sbiermann)]

Hi,
ja es ist möglich "Plugins" zu bauen. Afaik gibt der Proxy die Daten eh 
nur 1 zu 1 weiter ohne das dort irgend eine Magic passiert. Sprich du 
bekommst die Rohdaten und musst dann entsprechend selber dekodieren was 
drin steht. Solange der Proxy die Daten so weiter gibt, bist du nur von 
der Hardware der Therme abhängig, wenn die sich ändert kann es sein das 
es nicht mehr geht bzw. angepasst werden muss von dir.

Viele Grüße
Stefan

[Stephan (Gast)]

Hallo,

laut Bedienungsanleitung zu den neuen CW400/800 etc. ist es möglich,
den Strom- und Gasverbrauch der letzten 24h bzw. 30 Tage anzeigen zu 
lassen. Also muss auch diese Funktion in den Telegrammen enthalten sein.
Hat jemand eine Idee, welche Werte (Bytes) dafür in Frage kommen?

Gruß,
Stephan

[Peter (Gast)]

Hallo,

hat schonmal jemand HT3-Daten an eine Heatronic gesendet?
Ich würde gerne den Brenner aktivieren.

viele Grüsse Peter

[Norbert S. (junky-zs)]

Hallo Peter,

>hat schonmal jemand HT3-Daten an eine Heatronic gesendet?
Ja natürlich. Damit dies funktioniert müssen folgende Bedienungen 
erfüllt sein:
1. Aktuelle Software 0.1.7.1 von github und den ht_proxy-server 
aktiviert.
2. Hardware am RaspberryPi muss ein 'ht_transceiver' (ht_pitiny oder 
ht_piduino) sein.
Details dazu siehe:
 Beitrag "Re: Heizungs-Datenerfassung (HT3), SW-Rev:0.1.7.1"

>Ich würde gerne den Brenner aktivieren.
Dies geht nur indirekt über die Raum-Solltemperatur. Der Regler 
kommandiert dann der Steuerung die erforderliche Vorlauftemperatur.
Ich weiss allerdings nicht ob Du dies bei diesem Wetter wirklich willst 
:-)

Eine Einstellung der Raum-Solltemperatur ist möglich mit dem Tool: 
'ht_netclient.py'
Beispiel:
~/HT3/sw/ht_netclient.py -t 21.5
 Dies kommandiert eine Raum-Solltemperatur von 21.5 Grad.

Helpausgabe des Tools:
optional arguments:
  -h, --help            show this help message and exit
  -t TEMP, --temp TEMP  Gewuenschte Temperatur
  -b BART, --bart BART  Betriebsart der Heizung
                        Parameter:auto/heizen/sparen/frost
  -ht_cfg CFG, --cfg CFG
                        Write ht_transceiver config Parameter:0/1/2/3
  -ht_adr ADR, --adr ADR
                        Write ht_transceiver device-address, be carefull 
using this
  -ht_rst RST, --rst RST
                        HW-reset of ht_transceiver

Gruß Norbert

[Peter (Gast)]

Oh, das hört sich gut an.
Bisher ist an meine Therme noch eine FW200 und IPM angeschlossen.
Diese will ich durch eine Raspi-Steuerung ersetzen.

Sehe ich das richtig, dass man die Heatronic mit Temperaturwerten 
versorgen muss und diese dann selbst entscheidet, ob der Brenner laufen 
muss??

Gruss

[Norbert S. (junky-zs)]

Hallo Peter,

>Bisher ist an meine Therme noch eine FW200 und IPM angeschlossen.
>Diese will ich durch eine Raspi-Steuerung ersetzen.
Nicht das Du jetzt was falsch verstehst! Du kannst die Systemmodule 
FW200 und IPM NICHT durch den ht_transceiver auf dem RaspberryPi 
ersetzen!
Ich denke so hast Du dies auch wohl nicht gemeint.

Der ht_transceiver-Adapter (ht_pitiny oder ht_piduino) bildet 'nur' das 
Verhalten des NetCom-Modem nach. Die zugehörige Software erlaubt das 
STEUERN des/der Heizkreis-Anforderungen (Temperatur / Betriebsart).
Diese Anforderung wird an den Fxyz gesendet der diese dann anhand der 
Heizkurve zu einem TSoll Regel-Wert an das Heizgerät meldet.
Die REGELUNG im System machen also weiterhin die Heatronic - 
Systemmodule.


>Sehe ich das richtig, dass man die Heatronic mit Temperaturwerten
>versorgen muss und diese dann selbst entscheidet, ob der Brenner laufen
>muss??
Korrekt, Temperatur- und Betriebsart kann man kommandieren.
Zur Zeit nur für den Heizkreis 1, für die Heizkreise2 und 3 ist dies in 
Arbeit.
Da Du zwei Heizkreise (FW200) hast ist diese Erweiterung für Dich ja 
interessant.

Gruß Norbert

[Nils R. (augur)]

Hi.

Ist es mit dem Proxy eigentlich möglich auf Fehlermeldung der Heizung zu 
reagieren wie "zu wenig Wasser" oder so? Beim MB Lan hab ich die immer 
als Popup auf's Iphone bekommen, was ganz praktisch war im Winter. :-)

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

>Ist es mit dem Proxy eigentlich möglich auf Fehlermeldung der Heizung zu
>reagieren?
Der Proxy-server hat mit der AUSWERTUNG nichts zu tun, der überträgt 
auch weiterhin die erfassten Heizungsdaten im RAW-Format an die 
angeschlossenen Clients.
Der Proxy-Server wird auch in Zukunft KEINE Auswertelogik für die 
erfassten Daten erhalten. Das sollen gefälligst die verbundenen 
proxy-clients machen!

Somit müssen alle RAW-Daten von den Clients DEKODIERT werden (unabhängig 
ob proxy oder nicht) und diese Dekodierung für Fehlermeldungen ist noch 
nicht enthalten.

Die Fehlertelegramme bzw der zugehörige Inhalt werden ja wohl nur bei 
Auftreten eines Fehlers gesetzt bzw. gesendet. Einen Fehler muss man 
dann wohl manuell erzeugen damit der Telegramminhalt zum Fehlertext 
zugeordnet werden kann.
Bisher habe ich keine Fehler in meiner Heizung erzeugt, war immer ganz 
froh das die läuft.
Aber den Bedarf der Dekodierung sehe ich auch!

>..., was ganz praktisch war im Winter. :-)
Ja, wann wird's mal wieder richtig Winter...

So lange sollten wir wohl nicht warten und zumindest diese Telegramme 
erfassen.
Das Erfassen (Binär-Logfile anlegen) geht zusammen mit dem proxy-server 
und dem Tool: 'ht_binlogclient.py' sehr einfach.
Aufruf:
 ~/HT3/sw/ht_binlogclient.py <logfilename.log>

Es wird dann ein Logfile (RAW-Daten) im Verzeichnis: ~/HT3/sw/var/log/
angelegt. Dies kann man dann manuell (offline) auswerten.
Will jetzt nicht zum Heizungs-Fehlermachen aufrufen (obwohl die Heizung 
jetzt nicht gebraucht wird) aber vielleicht hat der eine oder andere die 
Möglichkeit und Zeit dies mal zu machen.
Werde mich auf jeden Fall auch daran machen.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

müssen die Fehlermeldungen über den Proxy aufgezeichnet werden oder 
reicht es, wenn ich die aus der HT3-DB nehme? Die müssten doch auch da 
hinein kommen, oder?

Andere Frage: Hast Du meinen Post vom 30.6. gesehen? Ich habe mal die 
Telegramm-Beschreibung überflogen und finde nicht so unbedingt, wo 8 
solche doch evtl. größeren Werte noch Platz hätten...

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

>müssen die Fehlermeldungen über den Proxy aufgezeichnet werden?
Nein, nur wenn man das Tool: 'ht_binlogclient.py' nutzen will.

Will man dies nicht, muss man die gerade laufende Applikation (z.B. 
HT3_logger.py) beenden und das logging auf dem /dev/ttyAMA0 dann zu Fuss 
starten. Dies alles natürlich wegen des nur einmal zu belegenden Ports.

Deshalb: proxy-server hat entscheidende Vorteile! Logging oder sonstwas 
für Anwendungen und Bedürfnisse sind von jedem PC im Haus mit 
Python3-Unterstützung und Linux (Windows) möglich.

Ich verzichte nicht mehr darauf!!

>Hast Du meinen Post vom 30.6. gesehen?
Ja natürlich, wenigstens die kommt wenn man sie braucht :-))

Du meinst sicher:
>...mit neuen CW400/800 etc. ist es möglich, den Strom- und Gasverbrauch der 
>letzten 24h bzw. 30 Tage anzeigen zu lassen.
Diese Regelgeräte bzw. Heizgerät habe ich leider nicht will aber nicht 
ausschliessen das die Telegramme schon vorhanden sind.
Wenn Du also da Möglichkeiten hast Telegramme mitzuschneiden, dann bitte 
hier posten.
Werde dann versuchen den Inhalt zu ergründen wenn irgendwie zu erkennen 
ist (Ablesen an der Anzeige) was im Logfile drin sein soll.

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Wenn Du also da Möglichkeiten hast Telegramme mitzuschneiden, dann bitte
> hier posten.

Hallo Norbert,

also ich habe "nur" eine Anlage mit HT4i und einem FW120 (der kann die 
Werte nicht anzeigen). Insofern könnte ich Dir die Hexdumps der HT4i 
geben, aber leider nicht die Werte die ein CW400 ausgeben würde.

Bringt das was? Besser wäre jemand, der auch eine HT4i hat und einen 
CW400/800, richtig?

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

>Bringt das was? Besser wäre jemand, der auch eine HT4i hat und einen
>CW400/800, richtig?
Ja, das wäre ideal da nur so ein Zusammenhang zwischen Anzeige und 
Telegrammen hergestellt werden kann.

>Insofern könnte ich Dir die Hexdumps der HT4i geben, aber leider nicht die Werte 
>die ein CW400 ausgeben würde.
Der CW400 zeigt die Werte 'nur' an, er erzeugt bzw. sendet diese NICHT. 
Diese stammen vom Heizungsgerät und den zugehörigen Telegrammen.
Man muss also beides haben:
1. Neuen Regler vom Type CR/CWx00 für die Anzeige der Werte.
2. Aktuelles Heizgerät mit HT4i und der Eigenschaft diese Telegramme 
(Verbrauchswerte) zu senden.

Deine Loggfiles von HT4i sind trotzdem einer Analyse wert. Wenn Du also 
Zeit und Gelegenheit findest dann hier posten oder an meine PM senden.

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Deine Loggfiles von HT4i sind trotzdem einer Analyse wert.

Hallo Norbert,

müssen es wirklich Logfiles sein? Ich arbeite ja nicht täglich mit der 
Software und insofern habe ich aktuell keine Logfiles (da ich ja immer 
noch die Version vom Januar habe). Ich könnte aber Daten aus dem Hexdump 
der DB liefern. Hilft das?

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

>Ich könnte aber Daten aus dem Hexdump der DB liefern. Hilft das?
Ein klares Jein.
In der DB stehen nur Daten drin die schon dekodiert wurden bzw. 
Telegramme die bekannt und deren Bytes grösstenteils bekannt sind.

Daher ist da das Binär-File im Vorteil, zumal ich dies besser durch den 
Anaylser jagen kann.

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Hallo Stephan,
>
>>Ich könnte aber Daten aus dem Hexdump der DB liefern. Hilft das?
> Ein klares Jein.
> In der DB stehen nur Daten drin die schon dekodiert wurden bzw.
> Telegramme die bekannt und deren Bytes grösstenteils bekannt sind.
>
> Daher ist da das Binär-File im Vorteil, zumal ich dies besser durch den
> Anaylser jagen kann.
>
> Gruß Norbert

Hallo Norbert,

kannst Du mir dann bitte sagen, wie ich die Binärfiles mit der 
Januar-Version erzeugen kann?

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

>...wie ich die Binärfiles mit der Januar-Version erzeugen kann?
Die Januar-Version 0.1.6 enthält noch keinen Proxy, deshalb wie folgt 
vorgehen:

1. Laufende Applikation stoppen (HT3_Logger.py etc.)
2. cat /dev/ttyAMA0 >> /tmp/<filename>

Zuvor eventuell nur: cat /dev/ttyAMA0 aufrufen zum Test ob überhaupt 
Daten kommen. Die Baudrate sollte ja noch stimmen, da diese noch von der 
Applikation richtig eingestellt war.

Nicht vergessen:
Nach dem Loggen Applikation wieder starten:-)

Gruß Norbert

[Peter (Gast)]

Hallo Norbert,

nochmal das Thema FW200, IPM ersetzen:

ich überlege tatsächlich, ob es möglich wäre, mit Raspi die
Heizung komplett zu steuern. Eine Hardware zum Einlesen der Sensoren und 
zum Schalten der Aktuatorik und entspr. HW sowie SW Knowhow ist 
vorhanden.

Ich weiß nur nicht, ob man mit dem HT3 Interface und dem Protokoll an 
alle relevanten Funktionen der Therme kommt, die da wären:
- Brenner auf 0..100% steuern
- wählen, welcher Heizkreis (1 oder 2) erhitzt werden soll.

Ich erwarte nicht, dass deine Software meine Heizung bedienen kann. Die
Regelung würde ich selbst schreiben.

Motivation:
- Optimieren der Anlage durch Nutzung von Wetterdaten
- Datenerfassung, Logging
- automatische Abwesenheitsschaltung
- keinen Heizungsmonteuer rufen müssen, wenn mal was nicht geht

Gruss Peter

[Stefan B. (sbiermann)]

Hallo Peter,
ich habe genau das gleiche vor. Allerdings mit dem Unterschied das ich 
den FW100 bei mir lasse, denn dieser übernimmt die Grundfunktionalität 
wie unter anderem Wochenprogramme und Brennersteuerung usw. Darüber 
hinaus habe ich in verschiedenen Räumen mit FS20 Geräten (FHT-80b) die 
Heizungkörper reguliert. Mit dem Adapter von Norbert bin ich nun in der 
Lage zusätzliche die Heizung auf Sparen bzw. Frost oder Heizen zu 
schalten wenn die Temperatur in den Räumen unter das eingestellte Limit 
sinkt bzw. umgekehrt die Heizung zu deaktivieren wenn die Räume warm 
sind aber die Aussentemperatur kalt ist so das die Heizung 
unnötigerweise anspringt. Gesteuert wird das Ganze dann sehr 
wahrscheinlich von FHEM oder einen Programm von mir. Da bin ich derzeit 
noch in der Überlegungsphase wie ich das am geschicktesten mache.

Ein anderer Grund warum ich nicht auf den FW100 verzichten will, ist er 
funktioniert auch ohne Norberts Adapter usw. sprich ich hab 
Ausfallsicherheit falls der Raspberry Pi den Geist aufgibt oder 
Software-/Netzwerkprobleme den Betrieb ohne FW100 nicht sicher stellen 
können.

Viele Grüße
Stefan

[Peter (Gast)]

Hallo,

also ich habe einen Kombispeicher, aus dem die Heizung und Warmwasser 
gespeist wird. Die Heizung ist eine Fußbodenheizung mit externer Pumpe 
und Mischventil.
Ich will im Prinzip anhand des Speicherfühlers den Speicher heizen und 
anhand Außenfühler eine Heizkurve bestimmen, mit der ich dann die 
passende
Vorlauftemperatur für die Heizung mische. In den Räumen habe ich jew. 
Thermostate. Da der Speicher auch von einer Solaranlage geheizt wird,
ist eine wetter-abhängige Regelung ggf. sinnvoll.

Ich würde die FW200 gerne komplett entfallen lassen, und alles selbst 
steuern. Mit der Solaranlage mache ich das bereits. Ich habe mir einen
zweiten Raspi hingelegt, der als Ersatz dient. SO ist ein Ausfall 
hoffentlich nicht so schlimm.

Vielleicht weiß ja jemand, welche Telegramme man schicken muss, damit
der Brenner startet und weiß auch wie man entweder Heizkreis 1 oder 
Heizkreis 2 bedient. Wenn ich wüßte ob das geht oder nicht, wäre ich 
schon einen großen Schritt weiter.

Ich würde mich auch gerne mal in die Protokolldefinition bzw. die 
Befehle einlesen - gibts da eine Doku?

Gruss Peter

[Norbert S. (junky-zs)]

Hallo Peter,

die Dokumentation findest Du unter:
<https://github.com/norberts1/hometop_HT3/blob/master/HT3/sw/etc/html/HT3-Bus_Telegramme.html>;


>Ich würde die FW200 gerne komplett entfallen lassen...
Wird nicht ganz einfach werden, nicht weil der Raspi nicht genügend 
Power hätte sondern eher weil er zusammen mit dem Linux nicht wirklich 
"Echtzeitfähig" ist und das immer 24/7 Betrieb.
Mit Echtzeitfähig meine ich Reaktionen auf Telegramme vom Heizgerät in 
spätestens 100 bis 200 msec.
Und das immer (auch wenn gerade ein Update oder sonst was läuft).
Da liegt meiner Ansicht die Krux.

Da ist es dann sinnvoll den Atmel auf dem ht_transceiver mit 
entsprechender Reglerlogik zu erweitern. Allerdings hat dieser für diese 
Aufgabe nicht genügend Programmspeicher.

Gruß Norbert

[Peter (Gast)]

Hallo Norbert,

danke für den link - sehe ich mir an.
ich habe mit Raspi schon mal eine Wellenpaketsteuerung auf Basis
eines Solidstate Relais gemacht. Der Raspi musste dabei
alle Nulldurchgänge zählen und zum richtigen Zeitpunkt schalten.
Das hat ohne weiteres funktioniert. Ich gehe also (erstmal) davon
aus, dass 100ms kein Problem sind, wenn man nicht gerade eine
Interpretersprache nimmt sondern den Software-Teil, der das
Protokoll behandelt direkt in C als schreibt, und wenn das nicht
reicht, dann eben als Treiber. Das Timing ist - denke ich - machbar.

Noch eine Frage:
Wenn ich die FW200 entferne und den Speicherfühler direkt an die Therme 
anschließe (das lässt sich an der Therme ja auch so konfigurieren): Ist 
die
Heatronic dann in der Lage, den Speicher auf Temperatur zu halten - also 
ohne FW200, IPM usw?

Gruss Peter

[Norbert S. (junky-zs)]

Hallo Peter,
>Wenn ich die FW200 entferne...Ist die Heatronic dann in der Lage, den Speicher 
>auf Temperatur zu halten?
Wenn Du den FW200 entfernt ist dann Dein Raspi der Regler. Der muss dann 
zu 100% (24/7 Betrieb) dafür sorgen, daß Du keine kalten Füsse und 
warmes Wasser bekommst!
Du solltest einen Oszi haben um Dir im Vorfeld die Halb-Duplex 
Kommunikation auf dem Heatronic-Bus (Master:= Heizgerätesteuerung, Slave 
alles andere) mal anzusehen.
Erst dann hast Du die Möglichkeit das Verhalten kennenzulernen und 
passend zu realisieren.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Peter,

hier im Bild ein Beispiel für die Kommunikation auf dem Heatronic-Bus.
Gemessen in meinem System mit FW100, FB10 und CSW24.

Das Zeitraster im Bild ist 3msec gross.
Die Blaue Linie sind die Bytes des Masters (Heizungssteuerung) als 
Antwort (Echo) auf Bytes des Slaves.
Die Rote Linie ist das Telegramm des Slave (hier das Modul FB10).
Dieses Timing ist mehr oder weniger mit allen Modulen am Heatronic-Bus 
gleich.
Die von mir oben angegebene maximale Zeit von ca. 100 - 200 msec bezieht 
sich auf ein komplettes Telegramm (maximal ca. 32 Byte). Ich weiss nicht 
wirklich wieviel Zeit man sich zwischen den einzelnen Bytes lassen darf 
bevor der Master rummeckert.

Die Zeit zwischen den Bytes ist natürlich wesentlich kürzer.
Somit bleibt nicht viel Luft für eine zeitgerechte Antwort wenn der 
Raspi der Regler ist.
Hinweis: Beim Halb-Duplex Betrieb muss der Slave nach jedem gesendeten 
Byte auf das Echo des Masters warten und das Break als Message-Ende 
detektieren.

Es bleibt Dir also wohl nichts anderes übrig als einen Treiber im 
Userspace-Mode oder schlimmstenfalls im Kernel-Mode für den UART des 
Raspi zu schreiben.
Wenn Du dies so realisieren kannst brauchst Du auch den 
ht_transceiver-Adapter nicht und kannst direkt mit dem UART des raspi 
die Datenkommunikation realisieren.

Sehr gute Beschreibung zum Buderus EMS-Bus findest Du auch unter:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-telegramme
die sehr ähnlich mit den Junkers-Telegrammen ist.

Gruß Norbert

[Andre (Gast)]

Hallo Norbert,

vielen Dank erstmal für die super Arbeit, ich habe den mini-Adapter am 
WE nachgebaut und er funktionierte auf Anhieb einwandfrei! Ich habe 
jetzt ein paar Fragen zu den Telegrammen, eventuell kannst Du mir da 
weiterhelfen. Meine Konfiguration ist eine CSW mit FW100 und ISM1 
(Fußbodenheizung im EG Radiatoren im OG).

Meine Solartelegramme enthalten keine Informationen zu dem Solarertrag, 
obwohl die Solarpumpe fleißig arbeitet, beispielsweise:

   b0 00 ff 00 00 03 00 00 00 00 02 6a 02 00 01 00 00 fd 68 18 00

Hast Du evtl. eine Idee dazu? Muss noch etwas eingestellt werden?

Weiterhin habe ich noch eine Verständnisfrage zum Heizkreis. Die 
Temperatur T-Ist (Regler/Wand) im HK1 ist bei mir derzeit ca. 36°, wo 
wird diese Temperatur gemessen?

Und noch eine Frage zur Software, ich nutze FHEM auf einem anderen raspi 
und würde gerne über den Proxy an die Daten kommen. Wenn ich es richtig 
gesehen habe hast Du in Deinem Repo eine Version mit dieser 
Funktionalität, ist es geplant die Version im FHEM Repo zu 
aktualisieren?

Danke vorab!

Gruß André

[Norbert S. (junky-zs)]

Hallo Andre,

>Meine Konfiguration ist eine CSW mit FW100 und ISM1
Die gleiche Konfiguration habe ich auch. Daher sollte auch bei Dir 
Solar-Ertrag (stündlicher Wert) angezeigt werden.
Den Ertrag des Tages gibt es nicht in den bisher dekodierten 
Telegrammen.

>Meine Solartelegramme enthalten keine Informationen zu dem Solarertrag,
>obwohl die Solarpumpe fleißig arbeitet, beispielsweise:
>   b0 00 ff 00 00 03 00 00 00 00 02 6a 02 00 01 00 00 fd 68 18 00
Byte8/9 := 0 Wh -->> kein Ertrag in der LETZTEN Stunde.
Byte14  := 1 -->> Solarpumpe läuft.
(Bytezählweise startet bei 0, siehe auch Telerammbeschreibung).

Dieser Solarertrag ist nur ein stündlicher Wert und wird erst nach 
Ablauf einer Stunde aktualisiert. Ebenso die Laufzeit (Minuten) der 
Solarpumpe.

Kann es sein das Du zu früh oder zu spät Dir die Anzeige angesehen hast 
oder kommt konstant kein Wert?

>Die Temperatur T-Ist (Regler/Wand) im HK1 ist bei mir derzeit ca. 36°, wo
>wird diese Temperatur gemessen?
Dies ist der Temperatursensor im Regler selber (FW100). Hängt jetzt 
davon ab wo der bei Dir plaziert ist.
Der kann ja direkt im Heizgerät eingebaut sein, oder separat an der Wand 
im Heizungsraum oder im Wohnzimmer oder oder. Das weisst Du besser wo 
der bei Dir sitzt:-)

>ich nutze FHEM auf einem anderen raspi und würde gerne über den Proxy an die 
>Daten kommen.
Genau so habe ich dies schon seit gefühlten 4 Monaten im Betrieb:
  2 RaspberryPi's (B).
Der eine stellt den Proxy bereit, macht die Datenerfassung und loggt die 
Daten in die Datenbank.
Der andere macht 'nur' FHEM und nutzt die Daten des proxy-servers vom 
ersten Raspi.

>Wenn ich es richtig gesehen habe hast Du in Deinem Repo eine Version mit dieser 
>Funktionalität, ist es geplant die Version im FHEM Repo zu aktualisieren?
Ja, nicht nur geplant sondern eingetütet bei Heiko R. Er ist noch dabei 
es einzupflegen. Im FHEM-Repository ist es jedoch noch nicht enthalten.
Siehe dazu auch:
 http://forum.fhem.de/index.php/topic,19445.msg292358.html#msg292358
Du kannst aber im Vorfeld schon meine Pre-Version nutzen und die 
Anbindung an den proxy-server damit realisieren.
Die Steuerung der Heizung und dem ht_transceiver Adapter geht dann damit 
auch.

Gruß Norbert

[Andre (Gast)]

Hallo Norbert,

> Kann es sein das Du zu früh oder zu spät Dir die Anzeige angesehen hast
> oder kommt konstant kein Wert?
Es kommt konstant kein Wert an, aber ich habe herausgefunden woran es 
liegt. Die Kollektorfläche auf meinem Dach war unten in der 
Heizungssteuerung gar nicht einprogrammiert, d.h. es war eine 
Kollektorfläche von 0.0m² eingestellt. Da waren ja Profis am Werk. Ich 
hoffe mal, dass hatte nur eine Auswirkung auf die Darstellung des 
Ertrages. Die Solaroptimierung Warmwasser war ebenfalls auf 0K gestellt, 
da habe ich jetzt mal mit einem kleinen Wert angefangen. Jetzt werden 
auch Werte übermittelt.

> Dies ist der Temperatursensor im Regler selber (FW100). Hängt jetzt
> davon ab wo der bei Dir plaziert ist.
> Der kann ja direkt im Heizgerät eingebaut sein, oder separat an der Wand
> im Heizungsraum oder im Wohnzimmer oder oder. Das weisst Du besser wo
> der bei Dir sitzt:-)
Bei mir direkt in der Heizung. Mich würde allerdings interessieren, wie 
sinnvoll die Steuerung funktioniert wenn der Regler mehr oder weniger 
immer ~33°C warm ist und die Solltemperatur im Modus Heizen auf 21° 
steht. Die Fußbodenheizung hat natürlich Regler in den Zimmern, die 
kommunizieren aber nur mit den Stellantrieben.

> Siehe dazu auch:
>  http://forum.fhem.de/index.php/topic,19445.msg2923...
> Du kannst aber im Vorfeld schon meine Pre-Version nutzen und die
> Anbindung an den proxy-server damit realisieren.
Funktioniert einwandfrei, danke dafür!

Gruß André

[Norbert S. (junky-zs)]

Hallo André,

>Mich würde allerdings interessieren, wie sinnvoll die Steuerung funktioniert 
>wenn der Regler mehr oder weniger immer ~33°C warm ist
Dein Regler FW100 wird dann wohl nur mit der Führungsgrösse 
'Aussentemepratur' und mit der eingestellten Heizkurve die 
Heizgeräte-Solltemperatur berechnen.
Da bei Dir der FW100 direkt im Heizgerät eingebaut ist und dort 3 
Stifte/Buchsen für den Kontakt vorhanden sind erkennt der Regler wohl 
selber welche Führungsgrossen er verknispeln darf.
Hinweis:
2 der Stifte sind für den HT-Bus, der dritte wohl für die 
Einbau-Erkennung.

Es lässt sich auch im Regler einstellen wo die Führungsgrösse herkommen 
soll.
Bei mir ist dies die Fernbedienung FB10 im Führungsraum mit einem 
gewissen Prozentsatz Regeleingriff.

>Funktioniert einwandfrei, danke dafür!
Danke für die Info!

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Nach welcher Zeit tritt der Fehler auf Stunden, Tage oder Wochen ?
>
> Gruß Norbert

Hallo Norbert,

jetzt ist es wieder soweit. Laut uptime läuft der Raspi jetzt seit 42 
Tagen und jetzt liegen in dem angesprochenen /tmp-Verzeichnis über 20000 
Dateien mit Endung .pl.

Da steht aber nichts für mich auswertbares drin, sondern nur:

#!/usr/bin/perl
#
use strict;
use warnings;
use RRDTool::OO;

my $DB_warmwasser  = 
"/home/pi/hometop_HT3/HT3/sw/var/databases/HT3_db_rrd_warmwasser.rrd";
my $warmwasser_rrdh = RRDTool::OO->new(file => $DB_warmwasser);
#
$warmwasser_rrdh->update (
  time   => 1436003635,
  values => {
   T_soll=>55,
   T_ist=>55.3,
   T_speicher=>55.3,
   C_betriebs_zeit=>7271,
   C_brenner_ww=>756,
   V_WW_einmalladung=>0,
   V_WW_desinfekt=>0,
   V_WW_erzeugung=>0,
   V_WW_nachladung=>0,
   V_WW_temp_OK=>1,
   V_lade_pumpe=>0,
   V_zirkula_pumpe=>0,
   V_spare_1=>0,
   V_spare_2=>0,
   }
);
# ---- error occured: -------
# -1, syspart:warmwasser, timestamp:1436003635

[Norbert S. (junky-zs)]

Hallo Stephan,

># ---- error occured: -------
># -1, syspart:warmwasser, timestamp:1436003635

aus diesem Fehlercode (-1) kann man die Ursache leider nicht ableiten.
Daher bleiben Dir folgenden Aktionen noch zu tun:

1. Grep auf den timestamp. Finde raus ob für diesen syspart (z.B. 
warmwasser) der gleiche timestamp noch in einem anderen *.pl zu finden 
ist.
Dies darf nicht sein. Die rrdtool-db meckert dann über doppelte Einträge 
zum gleichen timestamp.

2. Manueller Aufruf eines der /tmp/*.pl Fehler-Kandidaten in einem 
Terminalfenster.
Das rrdtool gibt dann noch Ausgaben zu den Aktionen und zum Fehler.

Habe die Vermutung, dass Einträge für den gleichen timestamp schon 
vorhanden sind (warum auch immer).

Dein Test 1./2. bringt hoffentlich mehr Informationen.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

danke für die schnelle Antwort.
Ich bin mir sehr sicher, dass es nichts mit doppelten Timestamps zu tun 
hat, denn seit 3.7. gibt es keinen einzigen Wert in den Grafiken zu 
sehen und auch die rrd-Datenbanken zeigen seit 3.7. keine Änderung.
Wenn es doppelte wären, dann müssten doch wenigstens die ersten Werte 
auftauchen.

Aber jetzt kommt das unverständliche: Ich habe eine der tmp-Dateien mit 
"perl tmpjdhaew_heizgeraet.pl" ausgeführt. Es gibt KEINE Fehlermeldung, 
die rrd-Datenbankdatei zeigt jetzt als Datum der letzten Änderung nicht 
mehr den 3.7., sondern 8.7.. Dasselbe gilt für jede andere pl-Datei aus 
tmp auch. Sobald ich das ganze manuell aufrufe, funktioniert es. Aber 
von den automatischen Aufrufe aus dem Hintergrund geht seit 5 Tagen kein 
einziger.

[Norbert S. (junky-zs)]

Hallo Stephan,

>Sobald ich das ganze manuell aufrufe, funktioniert es. Aber
>von den automatischen Aufrufe aus dem Hintergrund geht seit 5 Tagen kein
>einziger.

Das Verhalten ist schon ein wenig merkwürdig und nicht ganz zu erklären.
Da die /tmp/*.pl Scripte ja ausführbar und erfolgreich sind sollte auch 
der automatische Aufruf funktionieren.
Dies wird im Modul ~/.../sw/lib/db_rrdtool.py gemacht, hier die Stelle 
an der der Aufruf steht:
            #setup executemode for file to: 'rwxr-xr-x'
            os.chmod(filename, 0o755)
            #execute perl-script for updating 'rrdtool' database
            error=os.system(filename)
            if error:
                self.__rrdfileh=open("{0}".format(filename), "a")
                self.__rrdfileh.write('# ---- error occured: -------\n')
                self.__rrdfileh.write('# {0}, syspart:{1}, timestamp: 
...

Offensichtlich kommt der Aufruf: os.system(filename) schon mit einem 
Fehler: -1 zurück. Ich gehe davon aus, dass Du auf dem System keine 
Platzprobleme hast und der Fehler weiterhin da ist (Anzahl der /tmp/*.pl 
wächst an).
Ist den der Fehler nach einem Reboot des Raspberry beseitigt?
Achtung: /tmp wird dann aber geleert. Vorher am besten alle *.pl-Files 
ausführen.

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Ich gehe davon aus, dass Du auf dem System keine
> Platzprobleme hast und der Fehler weiterhin da ist (Anzahl der /tmp/*.pl
> wächst an).
> Ist den der Fehler nach einem Reboot des Raspberry beseitigt?

Hallo Norbert,

laut RPI-Monitor ist der Speicher meines Raspis mit 67% gefüllt und die 
SD-Karte mit knapp 35%. Also kann ich keine Platzprobleme erkennen.
In /tmp liegen jetzt 25000 .pl-Files und ich kann noch immer diese 
direkt und ohne Fehler ausführen im Terminal.
Habe jetzt einen Neustart gemacht und schon werden wieder neue Werte in 
die rrd-Datenbanken eingetragen.

Was kann man für das nächste Mal so machen, um dem Fehler auf den Grund 
zu gehen? Wie lange läuft bei Dir der Pi ohne Neustart?

[Norbert S. (junky-zs)]

Hallo Stephan,

gut zu hören das es wieder läuft, schlecht ist das der Fehler wieder 
auftreten kann.
Ich suche gerade nach Gründen dafür. Da der os.system()- call mit -1 
Wert zurückkommt macht die Fehlererkennung leicht aber die 
Ursachenfindung nicht unbedingt einfacher.

>Was kann man für das nächste Mal so machen, um dem Fehler auf den Grund
>zu gehen?
Ich teste da zwei Dinge: 1. anderen Systemaufruf (os.popen()) und 2. das 
temporäre Perlfile in einem Unterordner (DoY:= DayOfYear) von /tmp 
erzeugen und ausführen (wegen inode# ect. ).

>Wie lange läuft bei Dir der Pi ohne Neustart?
Da ich bisher die sqlite-db nicht grösser als ca. 100MByte habe wachsen 
lassen ist der Fehler nicht aufgetreten.
Lasse jetzt aber meine beiden Raspi's(B) Daten erfassen und in die 
jeweils eigene rrdtool-db schreiben. Einer dieser Raspi's hat noch FHEM 
parallel laufen und ist somit auch stärker belastet, aber es funzt!
Werde beide erst einmal so laufen lassen bis ein (hoffentlich nicht und 
sonst alsbald) Fehler auftritt.


Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
> Da ich bisher die sqlite-db nicht grösser als ca. 100MByte habe wachsen
> lassen ist der Fehler nicht aufgetreten.

Hallo Norbert,

die sqlite-DB wird bei mir niemals größer als 10 MB und die in Frage 
kommenden Werte stehen in dieser Datenbank ja auch alle drin. Ich habe 
also alle Werte, für welche er die Fehlermeldungen in /tmp geschrieben 
hat, die Werte in der Sqlite-DB. Der Teil hat weiterhin funktioniert.

Es ist also recht eindeutig ein Problem beim Übertragen der Daten in die 
rrdtool-Datenbank und kein generelles Dekodierungsproblem.

Bitte lasse mal einen Pi über mindestens 2 Monate ohne Neustart einfach 
laufen.

Gruß,
Stephan

[Stephan T. (stephant)]

Hallo Norbert,

es ist wieder soweit. Nach 38 Tagen gehen jetzt wieder alle Perlscripte 
in das tmp-Verzeichnis und es werden keine Daten an rrdtool übermittelt.
Wie immer nach einem Neustart wieder ok.
Wie lange läuft Dein Raspi jetzt bereits?

Gruß,
Stephan

[Ralf K. (elral)]

Hallo zusammen,

ich muss ja auch immer mal aus dem gleichen Grund resetten, am 
Wochenende war es dann soweit.
Ich schaue mal, ob es bei mir auch 38 Tage sind. Vom Gefühl her könnte 
das hin kommen.

Grüße

Ralf

[Stephan T. (stephant)]

Hallo Ralf,

das ist ja interessant. Ich habe gedacht, ich wäre der einzige mit 
diesem Problem. Also auch bei Dir regelmäßgig?

Es wäre schön, wenn Du mal drauf achten könntest, wie lange es ungefähr 
ist.

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo zusammen,

@Stephan T.
>Wie lange läuft Dein Raspi jetzt bereits?
Bei mir läuft die Applikation seit dem 9.7.2015 und die HT3_db.sqlite 
ist jetzt ca. 200 MByte groß. Der Fehler ist bei mir bisher nicht 
aufgetreten.
Allerdings habe ich zeitweise Netzwerkverlust ?? (bisher zwei mal) sodaß 
keine Daten mehr in die DB geschrieben wurden. Sobald ich dies bemerke 
starte ich jedoch den Daemon neu.

Dies hat aber wenig mit Eurem Problem zu tun, wobei ich den Grund dafür 
bisher nicht finden konnte denn die Perl-scripte in /tmp werden ja 
manuell korrekt ausgeführt (Beschreibung von Stephan weiter oben).

Um trotzdem an dieser Baustelle weiterzukommen ist folgendes Möglich:
1. Anpassung des rrdtool-Pythonmoduls als Zwischenlösung.
Art: Falls der Fehler auftritt wird der Systemcall ein zweitesmal 
ausgeführt.
Modul : .../sw/lib/db_rrdtool.py
Inhalt: ab Zeile 192 ergänzen ...
  # repeat the call if any error occured, perhaps it works the second 
time
  # workaround for test 19.08.2015
  if error:
      error=os.system(filename)

Hinweis: Bitte auf korrektes Einfügen (Tabs) achten sonst meckert 
python!

2. Ersatz der perl-scripte durch rrdtool-Aufrufe
Auf lange Sicht werde ich wohl den perl-script Aufruf für die rrdtool-DB 
Einträge ersetzen. Damit fällt dieses leidige Problem weg.
Dies wird dann wohl auf die Verwendung der 'rrdpython' - Schnittstelle 
hinauslaufen. Das muss allerdings noch realisiert werden.

Auch dachte ich an die Entkopplung zwischen der sqlite- und rrdtool-db. 
Zur Zeit muss die sqlite-db aktiv sein, damit die Daten in die 
rrdtool-db gelangen. Dies ist aus heutiger Sicht nicht mehr sinnvoll.
In Zukunft soll es möglich sein jede Datenbank (sqlite-db und/oder 
rrdtool-db) bei Bedarf durch Konfigurations-Änderung zu aktivieren / 
deaktivieren.

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
> Um trotzdem an dieser Baustelle weiterzukommen ist folgendes Möglich:
> 1. Anpassung des rrdtool-Pythonmoduls als Zwischenlösung.
> Art: Falls der Fehler auftritt wird der Systemcall ein zweitesmal
> ausgeführt.

Hallo Norbert,

habe die Zeilen eingefügt. Mal gucken, ob jetzt noch frische Werte 
kommen. Wenn ja, heißt es trotzdem erstmal 6-8 Wochen warten. Denn erst 
dann zeigt sich ja, ob der Workaround was bringt.

Gruß,
Stephan

[Ralf K. (elral)]

Hallo Stephan

Stephan T. schrieb:

> das ist ja interessant. Ich habe gedacht, ich wäre der einzige mit
> diesem Problem. Also auch bei Dir regelmäßgig?
>
> Es wäre schön, wenn Du mal drauf achten könntest, wie lange es ungefähr
> ist.

das waren jetzt 14 Tage bis keine Daten mehr angezeigt wurden.

Die von Norbert vorgeschlagenen Änderungen habe ich noch nicht 
eingefügt, werde ich vor dem Urlaub wahrscheinlich auch nicht mehr 
schaffen.

Grüße

Ralf

[Stephan (Gast)]

Norbert S. schrieb:
> Um trotzdem an dieser Baustelle weiterzukommen ist folgendes Möglich:
> 1. Anpassung des rrdtool-Pythonmoduls als Zwischenlösung.
> Art: Falls der Fehler auftritt wird der Systemcall ein zweitesmal
> ausgeführt.
> Modul : .../sw/lib/db_rrdtool.py
> Inhalt: ab Zeile 192 ergänzen ...
>   # repeat the call if any error occured, perhaps it works the second
> time
>   # workaround for test 19.08.2015
>   if error:
>       error=os.system(filename)
>
> Hinweis: Bitte auf korrektes Einfügen (Tabs) achten sonst meckert
> python!

Hallo Norbert,

das war leider nicht von Erfolg gekrönt. Nach 39 Tagen ist es wieder 
aufgetreten und ich habe jetzt wieder 15.000 Dateien im tmp-Ordner, 
welche manuell weiterhin ohne Fehler ausgeführt werden.
Auch in der SQlite-DB sind alle Werte drin, aber Tabelle rrdtool_infos 
zeigt bei jedem Eintrag "Error:true".
Wie üblich nach Neustart alles wieder gut.

Gruß,
Stephan

[Nils R. (augur)]

Stephan schrieb:
> laut Bedienungsanleitung zu den neuen CW400/800 etc. ist es möglich,
> den Strom- und Gasverbrauch der letzten 24h bzw. 30 Tage anzeigen zu
> lassen.

Moin.

Ich hab eine FW200 und kann man aus dem Brennerstatus oder irgendwie den 
Verbrauch ableiten? Wollte das in meinen Homserver integrieren als 
Energieampel. Eigentlich müsste Verbrauch und Brennerstatus ja irgendwie 
korrelieren.

Übrigens, ich hatte letztens einen Fehlercode...werden diese 
standardmäßig auch irgendwo aufgezeichnet. Norbert, wir hatten 
irgendwann mal über die Einbindung von Fehlercodes gesprochen und nun 
hätte ich einen. :-)

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,
> habe einen FW200 und kann man aus dem Brennerstatus oder irgendwie den Verbrauch 
> ableiten?
Sehe erst einmal keine direkte Möglichkeit bei HT3 und Fxyz-Regler an 
die Verbrauchswerte zu gelangen. Da sind HT4i und CW400/800 wohl im 
Vorteil.
Denkbar ist jedoch diesen Verbrauch indirekt mit den Werten der 
aktuellen Brennerleistung, MaximalLeistung des Heizgerätes und der 
Betriebszeit zu bestimmen.

> Fehlercode...werden diese standardmäßig auch irgendwo aufgezeichnet?
Zur Zeit werden die Fehlercodes nicht aufgezeichnet.
Die Erkennung, Speicherung und Anzeige ist jedoch in Bearbeitung und 
wird in den nächsten SW-Versionen enthalten sein.

Gruß Norbert

[Stephan (Gast)]

Hallo,

normalerweise muss auch die HT3 in der Lage sein, Verbrauchsdaten zu 
übertragen. Denn in der Beschreibung zur Junkers Control (die die 
Verbrauschdaten ja auch in der App anzeigen kann) sind auch HT3-Anlagen 
als kompatibel gelistet. Und ich konnte keine Einschränkung finden, dass 
bei der HT3 die Verbrauchsdaten nicht verfügbar sind.
Ich kann mir eigentlich nicht vorstellen, dass die Junkers-Programmierer 
das über Leistung/Zeit irgendwie umrechnen müssen, auch wenn das möglich 
sein sollte. Ist dann aber für uns sehr schwer, falls die 
Gasverbrauch/Leistungs-Kennlinie nicht linear ist...

@Nils: Die Fehlercodes werden doch in der FW200 gespeichert. Kann man 
rückwirkend alle auslesen. Oder geht es hier eher um Alarmierung im 
Falle eines Fehlers?

Gruß,
Stephan

[Nils R. (augur)]

Norbert S. schrieb:
> Zur Zeit werden die Fehlercodes nicht aufgezeichnet.
> Die Erkennung, Speicherung und Anzeige ist jedoch in Bearbeitung und
> wird in den nächsten SW-Versionen enthalten sein.

Das ist ja sehr schön. :-) Ich möchte diese nämlich wie Stephan gefragt 
hat zur Alamierung nutzen.

Wie weit ist eigentlich eine MySQL Anbindung? Ich habe mir eine 
Schnittstelle zu meinem Homeserver entwickelt mit PHP, aber leider ist 
SQLite nicht Multithreading-fähig. Daher bekomme ich oft Probleme und 
wollte als nächstes einen Transfer der Daten in der SQLite DB in MySql 
entwickeln.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> Wie weit ist eigentlich eine MySQL Anbindung?
Geplant ist diese, aber noch nicht realisiert.
Meine Vorstellung dabei ist die Schnittstelle zur Applikation möglichst 
so wie die sqlite-db Schnittstelle zu halten und als library-Modul zur 
Verfügung zu stellen.
Dann hat man die Möglichkeit die Daten entweder in die sqlite-db oder in 
die mysyl-db schreiben zu lassen. Per Konfiguration lässt sich dies dann 
auswählen was man haben will.
Wie gesagt, geplant aber noch nicht realisiert.
Eventuell hat jemand dieses so oder ähnlich realisiert, dann her damit!

Ich nehme jedoch an Nils das Du die Daten aus der sqlite-db nehmen und 
dann in die mysql-db übertragen willst.
Dieses lässt sich ja z.B. mit shell-scripten realisieren, jedoch wollte 
ich in der Richtung nicht aktiv werden.

Gruß Norbert

[Nils R. (augur)]

Hi Norbert.

Das Übertragen wäre nur die Notlösung. Ich hätte auch mit SQLite kein 
Problem, nur steigt diese bei einem Abruf alle 30 Sekunden aus. Ist 
häufig gelocked. Wollte nur mal nachhorchen, bevor ich unnötig dort 
aktiv werde.

Viele Grüße,
Nils

[drego (Gast)]

Hallo Freunde von Junkers und Co. Ich möchte mich nach langer schwerer 
Krankheit zurückmelden. Vor ca. 2 Jahren war ich aktiv dabei, Norbert 
bei den Auswertungen zu unterstützen. Wie einige von Euch wissen, habe 
ich eine sehr komplexe Heizungsanlage. Norbert, Glückwunsch, Du hast es 
geschafft, an die Anlage Befehle zu senden. Ich werde zeitnah auf Dich 
zukommen, das war ja schon immer mein Ziel.

Ich habe auch gesehen, dass Junkers komplett neue Regelungen hat. Kann 
mir jmd. sagen, ob die kompatibel mit den alten F Reglern sind. Das 
heisst, kann ich einfach in meiner bestehenden Anlage ein FW200 
(angebunden an bsp. IPM2 und ISM2) durch ein CW400 ersetzen?

Viele Grüße aus Dresden

[Adam K. (adamkorski)]

Norbert S. schrieb:
> Dann hat man die Möglichkeit die Daten entweder in die sqlite-db oder in
> die mysyl-db schreiben zu lassen. Per Konfiguration lässt sich dies dann
> auswählen was man haben will.

Kannst Du nicht die Daten parallel in die sqlite-db (Raspberry) und in 
mysyl-db an externen Server z.B. NAS für weitere Bearbeitung schicken?

[Hansbausn (Gast)]

Hallo,

sehr interessantes Projekt, was ihr da voran gertrieben habt. Da ich 
auch eine Junkers Heizung habe möchte ich mir auch gerne diese tolle 
Auswerteeinheit bauen. Die Bauteile sind schon bestellt.
Was mir noch nicht ganz klar ist, wie ihr letztendlich auf die gewonnen 
Daten zugreift. Die weingsten werden einen Monitor am Raspberry 
angeschlossen haben.
Ich stelle mir das so vor, dass der Raspberry per WLan oder Kabel im 
Netzwerk hängt und man von irgend einem Computer per Browser und 
IP-Adresse die Daten auslen kann. Ist das richtig oder wie macht ihr das 
?


Danke schon mal,

hans

[Stefan B. (sbiermann)]

Hallo,
ja so kann man es machen. Ich habe es in FHEM eingebunden und steuer 
darüber jetzt meine Heizung. Funktioniert soweit echt Klasse. 
Theoretisch geht auch jede andere Haus Automatisierung Software wie 
openHAB usw., allerdings gibt es dort meines Wissens nach noch kein 
Modul. Das müsste man sich erst selber programmieren.
Viele Grüße
Stefan

[Adam K. (adamkorski)]

Hansbausn schrieb:
> Ich stelle mir das so vor, dass der Raspberry per WLan oder Kabel im
> Netzwerk hängt und man von irgend einem Computer per Browser und
> IP-Adresse die Daten auslen kann. Ist das richtig oder wie macht ihr das
> ?

Ich beobachte online die Parameter auf Ipad mit installiertem Tight VNC 
Viewer. Auf Raspberry läuft HT3_Systemstatus.py
Die Grafiken lese per Browser auch auf dem Ipad.

[Hansbausn (Gast)]

Hey super, und danke schön für die Rückmeldungen. Freue mich schon aufs 
Basteln. Echt super das Projekt und die Mühe und Fleiß der da drin 
steckt!!!


Vg

hans

[Nils R. (augur)]

Moin.

Hab nun mein kleines PHP Skript fertig, welches mir erlaubt die Daten 
mit dem Homeserver zu konsumieren und anzuzeigen. Falls jemand interesse 
hat, kann er sich melden. Sollte eigentlich mit allen Produktion 
funktionieren, welche einfach Webseiten auswerten können. Ich lese 
einfach den letzten Datensatz aus der SQLite aus und stelle diesen per 
HTTP und einfachem HTML dar. Klappt perfekt. :-)

Viele Grüße,
Nils

[Hansbausn (Gast)]

Hallo Norbert,

und erst mal ganz lieben Dank für deine Hilfe.
Hardware und Anschluss habe ich soweit hinbekommen (es sollen nur die 
Betriebsdaten der Heizungsnalge visuell dargestellt werden, keine 
Steuerung der Anlage angedacht).

Die Heizungsanlage besteht aus einem Brennwertgerät ZSB14-3A mit FW100, 
einem Warmwasserspeicher SK300-1 Solar und einer Solaranlage mit ISM 1 
Regler.

Zum Auswerten der Heizungskommunikation habe ich deinen HT3 Adapter 
nachgebaut.
Zur Zeit hadere ich mit der Einrichtung des Raspberry Pi und fehlenden 
Kenntnissen im allgemeinen und auch Linux :-) Aber man möchte ja gerne 
dazu lernen.

Gehe ich richtig in der Annahme, dass gemäß deiner Beschreibung in 
Tabelle 5 die Module ht_proxy.py und ht_netclient.py für mich nicht von 
Interesse sind und daher ignoriert werden können. Dementsprechend kann 
ich unter Kapitel 2.5  auch alles ignorieren ?

Bei Kapitel 3 habe ich alle Befehle als ganz normaler User pi ausgeführt 
und nicht vorher sudo su gemacht. Hat das irgend welche Auswirkungen? 
Gemeckert wurde jedenfalls nicht.

Beim Schritt zum Deaktivieren der default TTY-Systemausgabe ist mir 
nicht ganz klar was ich anpassen soll. Interpretiere ich das richtig, 
dass die gelb markierte Passage eigentlich nur gelöscht wird ?


Bei deinen Beschreibungen eines Verzeichnis (z.B. cd ./HT3/sw) wir immer 
ein Punkt vorangestellt. Dort muss also der Pfad vom Benutzer eingesetzt 
werden ? Bei mir entspräche das dann /home/pi/HT3/sw

Beim aktivieren des Cronjobs habe ich ebenfalls ein Frage :
sind des mehrere Leerzeichen  zwischen der 5 und den ersten zwei  * und 
wieviele bei der 1 zum Schluss ? Wie und wo gebe trage ich die Parameter 
ein ? Kannst du da vielleicht aus einem realen Beispiel eine Zeile 
posten.

Die Installationsschritte zur „Anpassung und Aktivierung des 
Startscriptes ...“ (als root für user:pi): muss ich also auch wieder mit 
sudo su durchführen ?

Ab Seite 40 „Aktivierung ht-proxcy“ würde ich dan wieder ignorieren, ist 
für meine Zwecke nicht notwendig.

Gillt das auch für „Anpassen der Applikationen an die Schnittstelle 
(Beispiel: ASYNC):“


Danke nochmals für deine Hilfe bei so einem hilflosen Fall wie mir :-)

Gruß

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

> die Module ht_proxy.py und ht_netclient.py für mich nicht von
> Interesse sind und daher ignoriert werden können ?
ht_netclient.py ignorieren, da Du mit dem HT3 Mini-Adapter Deine Heizung 
nicht steuern kannst.
ht_proxy.py kannst Du verwenden, würde ich Dir sogar empfehlen. Du musst 
dazu aber die Baudrate von Default 19200 auf 9600 einstellen. Details 
siehe dazu in der Doku mit Übersichtsbild auf Seite 43. Dies erleichtert 
sicher die Einstellung im Konfigurationsfile. Wenn Du alles so 
installierst wie im Kapitel 3 beschrieben und das Konfigurationsfile 
anpasst läuft das Ganze.

> Kapitel 3 habe ich alle Befehle als ganz normaler User pi ausgeführt und nicht
> vorher sudo su gemacht.
Das ist OK, auf dem Raspi ist das 'sudo' ja extra für 'pi' aktiviert.

> dass die gelb markierte Passage eigentlich nur gelöscht wird ?
Ja genau das, alles weitere bleibt unverändert.

> Bei mir entspräche das dann /home/pi/HT3/sw
Genau, ein einfaches 'CR' reicht ja um auf das home-Verzeichnis des 
aktiven Users zu gelangen. Mit dem Punkt zeige ich an das dieses 
Verzeichnis als 'Wurzel'-Verzeichnis gemeint ist.

> sind des mehrere Leerzeichen zwischen der 5 und den ersten zwei  * ?
Nein, vorn bei der 5 müssen Tab's sein, die Parameter hinter dem 
Scriptaufruf werden mit Leerzeichen getrennt. Am besten Du kopierst eine 
vorhandene Zeile und passt diese an.
Beispiel:
*/5     * *   pi  /usr/bin/perl -S rrdtool_draw.pl /home/pi /home/pi 1

Ich empfehle Dir NICHTS zu ignorieren und alles durchzuführen und 
natürlich das Konfigurations-File anzupassen für Baudrate und 
/dev/ttyAMA0.
Resultat dann: Es wird laufen und Du hast den ht_proxy-server gleich mit 
im Rennen.

Gruß Norbert

[Hansbausn (Gast)]

Hi Norbert,
bin begeistert von deinem Projekt und deiner Hilfsbereitschaft. Werde 
mir morgen bzw. Am Montag deine Antworten in Ruhe zu Bemühte führen. 
Allerdings ist mir beim Überfliegen aufgefallen, dass du vom Ht3 Mini 
Adapter spricht. Ich habe den ganz normalen Ht3-Adapter nachgebaut, ohne 
Mini. Hat das einen anderen Einfluss auf deine Antwort?


VG aus dem Münsterland

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

einer von diesen Adapter-Typen wird's wohl sein:
  Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

> Hat das einen anderen Einfluss auf deine Antwort?
Nein

Gruß Norbert

[Hansbausn (Gast)]

Ok, jetzt wird mir einiges klarer. Ich bin beim Nachbau gemäß deiner 
PDF-Anleitung "HT3_Adaption" vorgegangen. Vielleich kannst du den 
Abbildungen 2 und 3 noch die Bezeichnung Mini mit implementieren, dann 
ist der Bezug zur Tabelle auf Seite 33 für Anfänger wie mich besser 
nachzuvollziehen.

Danke

Hans

[hansbausn (Gast)]

Hi Norbert,

eine Frage habe ich noch. Und zwar geht es um den Cronjob. Die erste 
Spalte meiner crontab Datei beginnt mit einer Raute als Überschrift. In 
den vier schon bereits gefüllten Zeilen sind dort auch Werte 
eingetragen. Kann ich die Raute Spalte einfach frei lassen und dann mit 
den Minuteneintragungen gemäß deiner Vorgaben beginnen oder wird der Job 
dann nicht ausgeführt.
Konnte leider keine Beschreibung/Bedeutung zur ersten Spalte googlen.


Danke dir

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

gute Beschreibungen bekommst Du mit:

1. man crontab
2. crontab -l

oder noch besser unter:
 http://linuxwiki.de/crontab

Damit sollte Dir dies gelingen.

Gruß Norbert

[hansbausn (Gast)]

Hi Norbert,

und nochmals liebn Dank für deine Hilfe. Echt tolles Projekt was du da 
hingezaubert hast.
Den letzten Stolperstein habe ich auch gemeistert. Das größte Problem 
sitzt immer zwischen Rückenlehne und Schreibtisch.
Bekomme die Daten jetzt ausgelesen und alle fünf Minuten werden die 
PNG´s erstellt.
Bin echt begeistert !!!

Zur Zeit hole ich mir noch die Daten per WinSCP per Hand aus dem 
Verzeichnis und schaue mir die Diagramme auf meinem Computer an. Mit 
tightvcnserver habe ich auch ausprobiert. Es scheint mir aber noch nicht 
die optimalste Lösung zu sein.
Wie Werte ihr die Daten aus ?
Würde mich sehr interessieren.

Gruß

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

prima das es jetzt klappt!

Die Anzeige der PNG - Files geht sehr einfach ohne WinSCP mit einem 
Browser Deiner Wahl, Eingabe:
 http://<IP>:8086
Für <IP> gibst Du halt die IP-Adresse Deines RaspberryPi ein, also z.B.:
 http://192.168.128.43:8086

Voraussetzung für die Anzeige der PNG-Grafiken ist, das der httpd.py - 
server auf dem RapsberryPi läuft. Siehe Doku dazu.


Gruß Norbert

[hansbausn (Gast)]

Perfekt !!!

Auch wenn ich mich wiederhole,

besten Dank

Hans

[Mario R. (upd8r)]

Hallo zusammen,

nachdem mir Norbert meine Platine vor ein paar Wochen zugeschickt hat, 
bin ich jetzt auch mal dazu gekommen, alles in Betrieb zu nehmen. Trotz 
Debian Jessie habe ich alles irgendwie hinbekommen, Kleinigkeiten sind 
anders resp. schon installiert.

Grafiken werden erzeugt, allerdings hadere ich ein bissel mit dem 
generellen Setup.


Ich habe eine CerapurModulSolar ZBS 14210 mit eingebautem Speicher, 
einem ISM1 und einer FW200, die direkt im Gerät verbaut ist. Es gibt 
keine FBirgendwas, also genau genommen gar keine Temperaturerfassung in 
einem der Räume.
Anfangs dachte ich, dass kann ja gar nicht funktionieren, aber 
augenscheinlich wird's trotzdem warm im Haus.

Nur passen jetzt so einige Anzeigewerte nicht. Also folgende Fragen: Wo 
kommt in meinem Setup die grüne Temperatur in der Grafik her?
Bekomme ich T-Raum und V_spare1 irgendwie aus der Grafik raus (Legende)?

Danke, speziell an Norbert für seine tolle Unterstützung!

[Stephan T. (stephant)]

Hallo Mario,

die T-Ist kommt in diesem Falle von der FW200. Es funktioniert durchaus, 
die im Gerät zu lassen, denn die Außentemperatur kann man auch von da 
aus regeln.
Die Raumtemperatur ist somit egal, denn es ist ja ein 
außentemperaturgesteuerter Regler.
Allerdings bekommt man damit keinerlei Raumeinfluß hin, wenn man z.B. 
auch einen Kamin an hat.
T-Raum gibt es wirklich nur bei den FB's, denn die sind von der 
Raumtemperatur gesteuert.
Ach so, und Du solltest in der FW200 eine Nacht- (und falls niemand zu 
Hause ist) auch eine Tagabsenkung programmieren. Aber nicht mehr als 3 
Grad Differenz wird angeraten.

Gruß,
Stephan

[Stefan B. (sbiermann)]

Hallo,
in Zusammenspiel mit einer Hausautomatisierungslösung wie FHEM oder 
openHab mit entsprechenden Raumreglern z.B. von Homematic oder FS20 
Baureihe lässt sich sowas nur mit FW200 ohne FBs lösen. Ich steuere so 
die Heizung für die komplette Wohnung über FHEM und Norberts-Platine. 
Die Programmierung in meinen FW100 (ebenfalls im Gerät verbaut) ist nur 
für den Notbetrieb, falls der Raspberry Pi mit dem Adapter oder der 
Rechner für FHEM kaputt ist.

Viele Grüße
Stefan

[Mario R. (upd8r)]

Dank euch für die Antworten,

also selbst steuern wollte ich gar nicht, die ganze Spielerei mit dem Pi 
und der Platine ist mehr so um die eigene Neugier zu befriedigen.
Die Regelung über die Außentemperatur funktioniert ja eigentlich ganz 
gut, ein gewisser Raumeinfluss ist ja trotzdem vorhanden, da ja die 
Raumregler der FBH bei Zieltemperatur schließen und somit die 
Rücklauftemperatur nicht mehr so stark abfällt. Das müsste ja auch eine 
Kenngröße in der Regelung sein.

Apropos Rücklauf: Wie kann denn in dem angehängten Bild die Rücklauf-T 
größer als die Vorlauftemperatur sein. Ergibt das Sinn?


Und welcher Wert ist der sich nicht verändernde hellbeige im Hintergrund 
(die einfarbige, halbhohe Fläche)?

Wie gesagt, ich würde gern die Sachen aus den Graphen entfern, die bei 
mir nicht relevant sind. Aber da muss vielleicht Norbert nochmal einen 
Tipp geben, wo ich da ran muss.

[Norbert S. (junky-zs)]

Hallo Mario,

> Wie gesagt, ich würde gern die Sachen aus den Graphen entfern, die bei mir
> nicht relevant sind.
Dies geht durch deaktivieren (auskommentieren) der zugehörigen Zeilen im 
script: rrdtool_draw.pl
In Deinem Fall also bei Zeilen 297 ff:
#zs### zu testzwecken hinzu
#  draw    => {
#    dsname  => 'V_spare_1',
#    name  => 'weisnich',
#    legend  => 'V_spare1 unbekannt',
#    thickness => 2,
#    color  => '803300',
#  },
#  draw    => {
#    color  => '803300',
#    type  => 'area',
#    cdef  => "weisnich,2,*"
#  },
und Zeile 270 ff
#  draw    => {
#    dsname  => 'T_steuer_FB',
#    name  => 'Raumtemperatur',
#    legend  => 'T-Raum (FB10/FB100) min\:',
#    thickness => 2,
#    color  => '8080ff'
#  },

> Und welcher Wert ist der sich nicht verändernde hellbeige im Hintergrund
> (die einfarbige, halbhohe Fläche)?
Dies ist in der Heizgeräte-Ansicht der Anzeige-Wert für den 
Betriebsmode:
Standby:=0; Heizen:=1; Warmwasser:=2.
Dieser Mess-Wert wird noch mal 45 genommen damit daraus ein vernünftiger 
Hintergrund wird. Somit ergibt sich dann für die Betriebsmode-Anzeige:
Standby:=0; Heizen:=45; Warmwasser:=90

Da Du zwei Heizkreise besitzt (FW200) kannst Du dies im 
Konfigurations-File aktivieren und bekommst die Graphen dafür. 
Allerdings werden auch nicht mehr Werte als im ersten Heizkreis 
angezeigt.
Wenn Du allerdings GEMISCHTE Heizkreise hast (Schaltmodul IPM1/2) dann 
bitte auch dies im Konfigurationsfile aktivieren. Es werden dann 
wesentlich mehr Informationen in den Heizkreisen angezeigt.

Gruß Norbert

[Mario R. (upd8r)]

Danke, ich schaue mir das an.
Wie kommst Du drauf, dass ich 2 Heizkreise habe? In der Tat ist es nur 
einer ?

[Norbert S. (junky-zs)]

Hallo Mario,

Du hast geschrieben:
> Ich habe eine CerapurModulSolar ZBS 14210 mit eingebautem Speicher,
> einem ISM1 und einer FW200, die direkt im Gerät verbaut ist.

Die FW200 kann zwei Heizkreise oder einen Heizkreis mit separater 
Warmwassererzeugung steuern.
Ansonsten reicht für einen Heizkreis auch eine FW120. Deshalb meine 
Vermutung das Du zwei Heizkreise haben würdest.

Mit einem Heizkreis brauchst Du ja auch nichts am Konfigurationsfile 
ändern, zumal dies noch ein ungemischter Heizkreis ist.

Zu Deiner Frage:
> Apropos Rücklauf: Wie kann denn in dem angehängten Bild die Rücklauf-T
> größer als die Vorlauftemperatur sein. Ergibt das Sinn?
Dies könnte dann z.B. auftreten wenn die Heizungspumpe nicht läuft und 
das Wasser im Heizkreis durch Schwerkraft getrieben wird.
Allerdings läuft Deine Heizungspumpe doch recht häufig und das mit stark 
wechselnder Leistung. Dafür habe ich auch keine Erklärung.

Gruß Norbert

[Mario R. (upd8r)]

Hi Norbert,

danke für Deine Antwort. Also FW200 war schon von Anfang an drin, 
vielleicht hatten die damals das kleinere Modell nicht da.

Das mit der Rücklauftemperatur macht mich aber weiterhin stutzig, 
Schwerkraft erscheint hier unlogisch, da bei uns alles auf einer Etage 
ist (kannst Du natürlich nicht wissen).

BG
Mario

[Ralf B. (Firma: privat) (pawlvandik)]

Hallo Norbert,


Nochmals Danke für den pitiny Adapter, den Du mir zur Verfügung gestellt 
hattest. Ich bin nun soweit, dass ich diesen an meine Junkers 
angeschlossen habe. Mit Deiner Doku war es leicht, die ersten Daten zu 
erfassen und bunte Graphen zu generieren.

Nun bin ich gerade dabei mir die Ausgaben anzupassen. Ich mag immer gern 
Zahlen unter den RRD Graphen haben. Dazu habe ich den Code vom 
rrdtool_graph.pl angepasst (siehe Bild).

Was ich jetzt noch gern anders hätte, wäre die Ausgabe von der Anzahl 
der Brennerstarts pro 24h als Zahl anstatt der Gesamtanzahl.

Ich hab mich schon durch diverse Dokumentationen von rrdtool::OO und RPN 
und CDEF und VDEF gekämpft, jedoch bin ich noch nicht auf den richtigen 
Weg gekommen.

Wenn Du eine schnelle Idee hast ?

Danke!
Ralf

[Hans (Gast)]

Hallo Norbert,

hast du vielleicht eine Anhnung, warum bei mir nicht die 
Rücklauftemperatur angezeigt wird? Muss ich noch in irgend einer Datei 
die Parameter anpassen? Ist ja eigentlich ein wichtiger Indikator.

Danke dir

Hans

[Klaus (Gast)]

Hallo Hans,

bei mir die Rücklauftemperatur auch nicht angezeigt. Allerdings kann ich 
die am FW 200 auch nicht finden und einen Temperaturfühler am RL habe 
ich auch nicht gefunden.

PS: meine Heizung ist von 2013

Klaus

[Norbert S. (junky-zs)]

Hallo,

@Hans
@Klaus
> hast du vielleicht eine Anhnung, warum bei mir nicht die Rücklauftemperatur
> angezeigt wird?
Nicht alle Heizgeräte haben einen Temperatur-Fühler für den Rücklauf 
eingebaut. Auch andere Temperatur-Fühler können u.U. fehlen (Mischer 
bzw. 3 Wege-Ventil).
Dies ist Bauart bedingt und variiert je nach Heizgerät.
Junkers sendet in den zugehörigen Telegrammen dann den Wert: 0x8000 => 
"Sensor offen oder nicht vorhanden".
Dies ergibt eine Hausnummer für die Temperatur und dies wird erkannt und 
dann dafür der Default-Wert aus der Konfiguration eingetragen.
Deshalb siehst Du in Deiner Grafik die Rücklauftemperatur, aber diese 
liegt konstant bei 0 Grad.

Gruß Norbert

[Juri K. (iuser)]

Hi,


habe die ht_pitiny jetzt am Laufen und die Daten fließen auch (sehe 
Bild).
Allerdings kommen irgendwie keine Daten für den Heizkreis, auch im 
Analyser keine. Und die Steuerung klappt auch nicht, die Befehle werden 
abgesetzt, aber keine Reaktion von der Therme. Was kann es sein? Die 
Aufbau ist bei mir denkbar einfach – ZWR 18-7/27 Kombitherme und FR50 
Regler parallel zu ht_pitiny. Kann es an dem FR50 liegen? Wundere mich, 
dass die Einstellungen am FR50 weder T-Soll noch T-Ist beeinflussen.

Gruß
Juri

[Norbert S. (junky-zs)]

Hallo Juri,

> Und die Steuerung klappt auch nicht, Kann es an dem FR50 liegen?
Ja, leider. Der FR50 kann die Steuerbefehle nicht auswerten und 
weitergeben. Siehe dazu Bild 'Junkers_FD_MBLan_Regler.png':
  Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

> Allerdings kommen irgendwie keine Daten für den Heizkreis
Je nach Anlage kann es sein das die zugehörigen Telegramme nicht 
gesendet werden.
Um dies festzustellen kannst Du ja mal ein Logfile der Daten Deiner 
Anlage posten.

Gruß Norbert

[Juri K. (iuser)]

Hallo Norbert,

danke für die Antwort. Kannst Du mir aus Erfahrung einen Regler 
Empfehlen? Den Regler selbst werde ich kaum nutzen, weil Alles über 
OpenHab gesteuert werden soll, der soll möglichst viel dem Openhab 
erlauben/ermöglichen. Anbei ist ein etwas Log, mit den ich selber 
verwende um die Openhab Anbindung zu Testen. Wenn ich für dich ein 
Bestimmtes Szenario aufnehmen soll – gib mir Bescheid.

Gruß
Juri

[Juri K. (iuser)]

Hallo!

Habe mich etwas eingelesen – das einfachste ist einen FR 100 zu nehmen, 
soll auch in dem Nachbarthread bei jemanden funktioniert haben. 
Allerdings stellt sich die Frage, ob man evtl. eine FR 120 oder gar 
einen Witterungsgeführten FW 100 oder CW 100 nehmen  soll um besser (von 
ht_pitiny) regeln zu können. Kann man in diesem Fall dem FW 100 die 
Außentemperatur über den ht_pitiny „vorgaukeln“? Oder braucht er 
unbedingt eigenen Fühler? Würde nur ungerne in einem Jahr einen neuen 
Regler kaufen müssen, um zusätzliche Features für den ht_pitiny 
„freizuschalten“. Dann lieber gleich einen besseren nehmen.

Gruß
Juri

[Norbert S. (junky-zs)]

Hallo Juri,

> Kann man in diesem Fall dem FW 100 die Außentemperatur über den ht_pitiny
> „vorgaukeln“?
Nein, dies geht nicht. Die Außenfühler haben keinen Bus-Anschluss und 
sind einfache NTC's. Somit werden die in der Regel direkt an die 
Heizungssteuerung angeschlossen.

> Allerdings stellt sich die Frage, ob man evtl. eine FR 120 oder gar einen
> Witterungsgeführten FW 100 oder CW 100 nehmen  soll um besser (von
> ht_pitiny) regeln zu können.
Ein Leidensgenosse aus dem Forum hat seinen alten Regler durch einen 
FW100 aus der E-Bucht ersetzt und das funktioniert. Auch der FR120 
funktioniert.
Beim CW100 sollte man aber auf die Kompatibilität zum Heizgerät achten. 
Junkers hat dort ein Liste veröffentlicht in der die passenden 
Heizgeräte aufgeführt sind.
Bei Bedarf kann ich Dir diese zukommen lassen.

Gruß Norbert

[Juri K. (iuser)]

Hallo Norbert,

auf die Schnelle konnte ich nur diese Liste finden 
https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/konnektivitaet/apps_3/junkers_control_/NEU_CT_100-_Kompatibilitaetsliste.pdf
Wenn Du eine Andere gemeint hast, lasse die mir bitte zukommen.

Aber so wie es aussieht, besorge ich mir den CW 100.

Gruß
Juri

[Norbert S. (junky-zs)]

Hallo Ralf,

Deine Anpassung mit den 'Last' - Ausgabewerten hat mir gut gefallen.
Daher habe ich dies ebenfalls in das perl-script eingebracht. Wird im 
nächsten Release enthalten sein.
Zusätzlich habe ich die Beschriftung der Y-Achse am rechten Rand mit 
eingebracht.
Hier schon mal als tar-file zum Testen.
Hinweis: altes cron-job script: rrdtool_draw.pl durch obiges ersetzen.

> Was ich jetzt noch gern anders hätte, wäre die Ausgabe von der Anzahl
> der Brennerstarts pro 24h als Zahl anstatt der Gesamtanzahl.
Habe dies auch versucht, ist mir jedoch auch nicht gelungen.
Werde wohl die Werte in Zukunft in Stunden in die Datenbank schreiben 
damit diese Werte besser lesbar werden.

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Deine Anpassung mit den 'Last' - Ausgabewerten hat mir gut gefallen.

Hallo Norbert,

ja, das hat mir auch gefallen und deshalb wollte ich es auch nutzen. Da 
ich aber schon einiges an meiner rrdtool_graph.pl geändert habe (mehrere 
Zeiträume z.B.), wollte ich es Schritt für Schritt in meine Datei 
einbinden und kann nicht 1:1 Deine Datei nehmen.
Aber wenn ich an der passenden Stelle z.B.

draw  => {
  type  => "hidden",
  name  => "Brennerleistung_last",
  vdef  => "Brennerleistung,LAST"
  },

einbinde, läuft das Script nicht mehr...
Fehlt mir da was in der DB oder irgendwo sonst?

[Norbert S. (junky-zs)]

Hallo Stephan,

> ... das einbinde, läuft das Script nicht mehr.Fehlt mir da was in der DB
> oder irgendwo sonst?
Du brauchst dazu folgende Struktur:
...
 draw            => {
   dsname  => 'V_leistung',          # realer Name fuer Datenbank-Wert
   name    => "Brennerleistung",     # virtueller Name dieses draw
   legend  => 'Brennerleistung (%)', # text in der legende
   color   => 'cccccc',              # Farbe des draw
   type    => 'area'                 # Zeichnungs-Art
 },
 draw      => {
   type    => "hidden",              # nicht gezeichneter draw
   name    => "Brennerleistung_last",# virtueller Name dieses draw
   vdef    => "Brennerleistung,LAST" # !!Letzter Wert des draw-name 
oben!!
 },
...
Beim hidden-draw wird also der 'virtuelle'-Name des realen draw genommen 
und davon der letzte erfasste Wert.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

danke, hatte das übersehen. Läuft jetzt...

[Nils R. (augur)]

Hallo zusammen,

auf dem Screenshot vom Norbert hab ich gesehen, dass die Darstellung 
viel fließender ist. Bei mir schaltet diese sehr viel häufiger aus. Ist 
das normal oder kann ich das in der Darstellung ausbessern?

Viele Grüße,
Nils

[Stephan (Gast)]

Nils R. schrieb:
> Bei mir schaltet diese sehr viel häufiger aus.

Hallo Nils,
das kann bedeuten, dass du nicht immer Werte bekommst.
Viel wahrscheinlicher ist es aber, dass deine Anlage stark taktet.
Ändere mal bitte die Start_time (in rrdtool_draw.pl ungefähr Zeile 60) 
von 2880 auf sagen wir mal 300. das gibt dann viel bessere Auflösung, da 
nur 5 Stunden und nicht 2 Tage. Dann nochmal Posten.

Gruss Stephan

[Nils R. (augur)]

Hi.

Hab ich geändert, aber die Grafik verändert sich nicht.

# Set Starttime
my $start_time     = time()-300*60;

Viele Grüße,
Nils

PS. Hab die falsche genommen, hat sich erledigt. :-)

[Stephan (Gast)]

Hast du neue Grafik?

[Nils R. (augur)]

Hier etwas höher aufgelöst. Die Datensätze fehlen anscheinend nicht. Die 
letzten Stunden sahen aber auch in der 2 Tages Betrachtung sauberer aus.

Aber es ist auch zu erkennen, dass T-Soll anscheinend den Rücklauf 
regelt?

[Stephan (Gast)]

Ja, so soll es aussehen. Versuche mal bitte mit Start_time und stop_time 
den gestrigen Nachmittag anzuzeigen.

[Nils R. (augur)]

So, hier von gestern. Sieht nach pulsen aus. Warum regelt die Heizung 
unterschiedlich??? Bzw. warum fällt die Temperatur so stark ab immer vom 
Rücklauf...

[Stephan (Gast)]

Ja, die Tage sind grob unterschiedlich. Welche Therme? Solar? Heute und 
gestern gleiches Programm und gleiche Einstellung der Heizkreise?
Was könnten die 2 Tage noch unterscheiden?

[Norbert S. (junky-zs)]

Hallo Nils,

ja die beiden Grafiken sehen schon sehr unterschiedlich aus und doch 
haben die Gemeinsamkeiten:
1. Die Aussentemperatur ist in etwa gleich und somit die geforderte 
Soll-Temperatur auch (die Warmwasser-Erzeugungszeiten mal ausgenommen).
2. Die Zirkulationspumpe zirkelt sehr gleichmässig und vergleichbar in 
beiden Grafiken.
3. Der Sollwert liegt bei ca 45 - 50 Grad.

Somit sollte die geforderte Brennerleistung in beiden Grafiken gleich 
sein. Die liegt bei ca 40-50%.
In dem einen Bild ist diese Leistung gleichmäßig verteilt über der Zeit, 
in dem folgenden Bild taktet diese sehr stark zwischen ca 80% - 0%. Im 
Mittel wird aber daraus wieder ca. 40%.

Jetzt stellt sich mir die Frage was in Deiner Heizung so taktvoll ist. 
Dies können nur die angeschlossenen Verbraucher sein: 1. Heizungsventile 
und/oder 2. Heizungspumpe.
Ich tippe sehr stark auf die Heizungspumpe. Die wird Strom sparen sollen 
und taktet ca. alle 10 Minuten. In der Zeit ist das bis dahin nicht 
umgerührte Heizungswasser abgekühlt, die Rücklauf-Temperatur natürlich 
auch und der Brenner ist stark gefordert.
Im Mittel ist also die geforderte Brennerleistung mit ca. 40-50% in 
beiden Grafiken gleich.
Ich sehe hier erst einmal keinen Systemfehler, jedoch kann man sich 
fragen ob durch diese Betriebsart Energie gespart wird. Jede Heizung ist 
eben anders eingestellt und ob diese Einstellung dann das Optimum ist 
kann man wohl nur ausprobieren.

Gruß Norbert

[Stephan (Gast)]

Hallo Nils,

ich glaube da eher an einen geänderten Bedarf am Samstag, denn wenn die 
Heizungspumpe (es müsste aber eine externe sein, denn die interne läuft 
ja immer mit 64%) so takten würde, dann müsste sie es auch am Sonntag 
getan haben.
Wenn aber am Samstag einige Heizkreise geschlossen waren, dann kann die 
Heizung die erzeugte Wärme nicht abtransportieren, schaltet ab, die 
RL-Temp geht unter Soll und die Heizung springt wieder an.

Aber ohne Daten deiner Heizung sind das nur Vermutungen. Auf jeden Fall 
läuft die Erfassung. Falls es jetzt darum geht, die Heizung zu 
optimieren, würde ich eher das Junkers-Forum auf heizungsforum.de 
empfehlen, denn da treiben sich auch einige Fachleute für Heizungsbau 
herum...

Gruß,
Stephan

[Nils R. (augur)]

Ja, die läuft wirklich super jetzt. Heute ist die Heizung mit dem 
Übergang in den Abend von Taktung in den durchgängige Steuerung 
gegangen. Scheint also irgendwie damit zu tun zu haben. Ich werde mal in 
das Forum von dir schauen...mal sehen, was da kommt.

Wie ist das eigentlich mit T-Soll und dem Rücklauf. Von der Temperatur 
wird das gesteuert und nicht T-Ist.

Viele Grüße,
Nils

[Stephan (Gast)]

Hallo Nils,

also grundsätzlich kann eine Steuerung auch anhand der RL-Temp erfolgen. 
Das hängt vom Modell ab. Ob es tatsächlich so ist, kannst Du im 
Heizungsforum erfragen.

Mir persönlich taktet die Anlage zu häufig. Wenn Du eine 
Brennwertheizung hast, dann sollte die Anlage min. 15-20 min am Stück 
laufen, denn erst dann stellt sich der Brennwerteffekt ein. So wurde es 
mir erklärt.
Aber es ist auch fast immer so, dass die Anlage überdimensioniert ist 
und auch erst in den letzten Jahren sind Anlagen auf dem Markt, welche 
so modulieren können, dass auch ein ganz kleiner Bedarf möglich ist.
Ich hatte vorher auch eine Anlage, welche nicht unter 8kW gekommen ist 
und das ist oft zu viel, wenn einige Heizkreise "abgedreht" sind (el. 
Thermostate für nicht benutzte Räume am Tag/Nacht). Meine jetzige kann 
runter auf 2,3kW und aktuell komme ich mit 10 Brennerstarts/Tag aus 
(inkl. WW). Und die Anlage läuft fast durchgehend mit 25-30% Leistung. 
Das dürfte kaum mehr als ein Teelicht sein :-)

Gruß,
Stephan

[Klaus (Gast)]

Hi @all,

ich stelle mal die Grafik meines Heizungsgeräts ein, weil ich die 
Diskussion der Ergebnisse von Norberts genialer Arbeit als nächste 
Evolutionsstufe sehe.

Sprich den Vergleich des Regelungsverhaltens unserer Heizungen.

Klaus

[Ralf (Gast)]

Hallo,


Ich stelle auch nochmal meine Daten zur Verfügung, damit man mal sieht, 
dass es auch etwas anders aussehen kann.

Jedoch glaube ich, dass im Mikrocontroller Forum nicht der Platz sein 
sollte, um über Heizungsanlagen und deren Steuerungsverhalten zu 
diskutieren.

Ich habe mir die Ausgabe, wie weiter oben schonmal angedeutet, etwas 
modifiziert, Zahlenausgaben unten hinzu und das Zirkulationspumpen-Label 
weg genommen (ich weiß ja, dass Orange die Zirkulationspumpe ist).

Leider bin ich noch immer nicht weiter gekommen, was die Ausgabe der 
Brennerstarts pro Stunde angeht. Ich habe es schon so weit getrieben, 
dass ich den Typ der data source in COUNTER geändert habe. Theoretisch 
müsste es ja dann so zu behandeln sein, wie die Ausgabe von Byte/s auf 
einer Netzwerkschnittstelle. An dieser Stelle bin ich gerade und "warte" 
nur auf wieder etwas Zeit, die ich hier hinein stecken kann.

VG
Ralf

[Stephan (Gast)]

Ralf schrieb:
> Jedoch glaube ich, dass im Mikrocontroller Forum nicht der Platz sein
> sollte, um über Heizungsanlagen und deren Steuerungsverhalten zu
> diskutieren.

Richtig. Deshalb wäre u.U. das Junkers-Forum im heizungsforum.de der 
bessere Ort dafür. Und da gibt es auch einige Fachleute, so dass man 
evtl. herausbekommt, warum bei Dir die Heizungspumpe derart unruhig 
läuft.

@Klaus: Schau dir mal 
http://www.heizungsforum.de/forum/index.php/Thread/10437-Heizungspumpe-bei-Frostschutz-immer-100 
an. Damit könntest Du einstellen, dass die Heizungspumpe bei unter 5Grad 
nicht mit 100% durchläuft.
Ansonsten sieht die Regelung schon mal nicht schlecht aus. Sehr wenige 
Brennerstarts...

@Alle: Wäre es nicht besser, man würde in die hier geposteten Grafiken 
gleich einbauen, um welche Anlage es sich handelt?

[Klaus (Gast)]

@Ralf
@Stefan

Ich gebe euch Recht, hier ist nicht der richtige Platz dafür.
Ich tendiere allerdings weniger in Richtung eines threadorientierten 
Forums sondern eher in Richtung eines Portals, wie es sie bereits 
zahlreich für PV-Anlagen gibt. Dort kann man aufgrund der zur Verfügung 
gestellten Daten, die Leistungsfähigkeit der eigenen Anlage vergleichen.

Zur Lösung eines konkreten Problems ist das Heizungsforum natürlich 
passend.

[Juri K. (iuser)]

Hallo,

habe gerade den FR50 durch CW100 ersetzt, leider ohne sichtbaren Erfolg.
Die Steuerungsversuche bewirken nichts und HK1 bleibt ohne Daten.
Auffällig ist auch, dass system-info nicht kommt und (dadurch) 
System-Zeit nicht mehr gefühlt ist.
CW100 agiert als Regler, Außenfühler ist noch nicht angeschlossen.

Was kann bei mir noch falsch sein? Soll der SW100 irgendwie anders als 
FR50 angeschlossen werden?
Habe erst mal keine Ideen mehr.
Das neue Log hänge ich auch an.

Gruß
Juri

[Norbert S. (junky-zs)]

Hallo Juri,

> Die Steuerungsversuche bewirken nichts und HK1 bleibt ohne Daten.
Habe mir Dein Log-File angesehen und folgendes festgestellt:
1. Es werden beim CW100 wieder neue Telegramm-Typen gesendet bzw. die 
Telegramm-Längen sind jetzt anders.
2. Teilweise sind die Inhalte (Nutzbytes) an anderen Stellen als bei den 
Telegrammen der Fxyz - Serie.
Somit-> Alles Neu macht der Mai (nicht nur der!).

Daher wird u.A. jetzt auch die Systemzeit nicht mehr angezeigt da dieses 
neue Telegramm jetzt 17 Byte statt bisher 14 Byte lang ist.

Was die Heizkreis-Anzeige 'HK1' angeht so ist die aktuelle Betriebsart 
in einigen Telegrammen enthalten die jedoch noch nicht alle ausgewertet 
werden.
Die Soll- und Ist-Temperatur wird nur in einigen systemabhängigen 
Telegrammen gesendet und ob dies beim CW100 der Fall ist muss noch 
geklärt werden.

Was die Steuerung des CW100 angeht so hat dieses Modul jetzt bei Dir die 
Geräteadresse: 18h. Die Steuerbefehle gehen jedoch z. Zeit noch an die 
Adresse: 10h. Ob nur eine Austausch dieser Zieladresse ausreicht ist zu 
klären. Kann Dir da eine Testsoftware bereitstellen, dies wird aber erst 
nächste Woche etwas.

Insgesamt müssen die neuen Telegramme noch dekodiert und die Software 
aktualisiert werden.

Gruß Norbert

[Juri K. (iuser)]

Hallo Norbert,

das klingt ja spanend. Und ich dachte mit der neuen Regelung wäre ich 
auf der sicheren Seite... Ich versuche mich zwischenzeitlich auch an der 
Dekodierung, komme aber noch nicht so richtig voran.  Muss aber erst 
noch etwas fummeln um die richtigen Fragen stellen zu können. Nächste 
Woche ist schon fast zu gut, weil ich selber keine Möglichkeit zum 
Testen haben werde.  Geht dann erst am 6-7 Feb. weiter.

Gib mir Bescheid, wenn ich davor noch weitere logs aufnehmen soll.

Danke und Gruß
Juri

[Stephan (Gast)]

Hallo Norbert, heute wurde mein fw120 gegen einen cw400 getauscht und 
jetzt kommen natürlich keine heizkreis Daten mehr. Kann ich helfen beim 
Testen?

[Norbert S. (junky-zs)]

Hallo Stephan,

offensichtlich hat Junkers mal wieder die Telegramme erweitert.
Um dem beizukommen lege bitte ein logfile an mit:
1. falls Du den ht_proxy.py laufen hast
  ~/HT3/sw/ht_binlogclient.py cw400.log
oder
2. falls Du direkt am Comport erfasst
  cat /dev/ttyUSB0 > cw400.log

Binärfiles mit dem ht_pitiny/ht_piduino-Adapter und ht_proxy.py sind mir 
allerdings lieber, da dort die korrekte Break-Erkennung und 
Telegramm-Längenangabe enthalten ist.

Bitte die Daten etwas länger erfassen, > 1 Stunde sollte es schon sein. 
Eventuell bestimmte Zeitpunkte (Betriebsmodeumschaltungen, 
Temperaturänderungen) mit berücksichtigen.

Habe zwar die Telegramm-Dokumentation überarbeitet und ergänzt, die 
CWxyz und CTxyz Telegramme sind aber in der Doku und SW noch nicht 
enthalten,
siehe URL:
  https://github.com/norberts1/hometop_HT3/tree/master/HT3/sw/etc/html
Doku:
  HT3-Bus_Telegramme.html.
Aber was nicht ist kann ja noch werden.

Juri hat ja das gleiche Problem mit dem CW100 aber dies lässt sich durch 
Softwareanpassung lösen.
Kannst das Logfile hier post oder an meine PM senden.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

gemäß Deiner Nachricht aus dem Juli ist der Logger in meiner Version 
noch nicht drin. Ich habe daher per cat /dev/ttyAMA0 geloggt.
Lesen kann ich da aber nichts sinnvolles. Kannst Du mal in die 
angehängte Datei gucken, ob die Daten lesbar sind und sich weiteres 
Loggen lohnt?

Danke und Gruß
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

Deine Datei enthält sinnvolle Daten und die Baud-Rate passt.
Somit lohnt es sich auf jeden Fall.
Wird zwar nicht ganz einfach zu dekodieren aber wir haben ja ein 
Wochenende vor uns :-)

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

danke für die Info. Habe jetzt mal rund 6 Stunden aufgezeichnet und 
hochgeladen.

Im übrigen scheinen bei mir dieselben Daten zu "fehlen" wie bei Juri. 
Also sind CW100 und CW400 wohl ähnlich oder gleich und es betrifft weder 
HG noch WW, sondern "nur" den HK.

Danke und Gruß,
Stephan

[Nils R. (augur)]

Hi.

Anbei mal mein Dump-Script zum leeren der SQLite DB und wegschreiben der 
Daten in CSV Files. Damit läuft die Datenbank nicht mehr über und die 
Daten liegen für weitere Analysen in z.B. Excel vor. Man sollte es nur 
einmal am Tag ausführen aufgrund der SQL Bedingung und der 
Dateibenennung. Ich hab es einmal die Woche per Cron eingeplant.

Das Script fährt den HT3_Logger vorher runter, damit kein DB Lock 
entsteht. Da ich noch eine Schnittstelle über den Apache habe, wird auch 
dieser beendet. Das wird für die meisten wahrscheinlich nicht notwendig 
sein.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo,

@Alle
Habe die Software auf github.com aktualisiert auf die Version: 0.1.8
Grund ist hauptsächlich die neue Junkers-Hardware der CWxyz Generation.
Wer es komplett mag bekommt alles mit:
  git clone https://github.com/norberts1/hometop_HT3.git

Wer schon eine Datenbank gut gefüllt hat und diese weiter nutzen will 
kann auch die aktualisierten Files updaten:
  ~/HT3/sw/lib/gui_worker.py            Version-Nummer auf 0.1.8
  ~/HT3/sw/lib/ht3_decode.py            Dekodierung ergänzt
  ~/HT3/sw/lib/ht3_dispatch.py          Dispatcher erweitert
  ~/HT3/sw/etc/rrdtool_draw.pl          Last-Value und right-axis hinzu
  ~/HT3/sw/etc/html/HT3-Bus_Telegramme.html  Beschreibung korrigiert


@Juri, @Stephan
Danke für die Logfiles (habe nun mal keinen CWxzy) und bitte die neue 
Software an Eurer Anlage testen.
Das beigefügte Bild zeigt den dekodierten Systemstatus von Stephan's 
CW400.
@Juri
Bitte erstelle mir noch einmal ein längeres (ca. 2-3 Stunden) 
binär-Logfile vom CW100 damit ich noch mehr Dekodier-Futter habe.
Das Senden zum CWxyz ist noch in Arbeit. Sobald fertig sende ich Dir 
dies zu.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Juri,

falls Du Zeit hast erstelle mir bitte noch binär-logfiles in denen 
Änderungen von Soll-Temperatur und Betriebsart-Wechsel enthalten sind.
Eventuell die logfiles entsprechend benamsen damit die Dekodierung 
einfacher ist.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,
danke für die viele Arbeit. Da ich meine DB nicht verlieren will (ich 
meine die von rrdtool), wollte ich das Update machen.

Nur die 3 .py - Dateien kopiert:
pi@raspberrypi ~/hometop_HT3/HT3/sw $ ./HT3_Logger.py
Traceback (most recent call last):
  File "./HT3_Logger.py", line 26, in <module>
    import ht3_worker
  File "lib/ht3_worker.py", line 28, in <module>
    import data, ht3_dispatch, gui_worker, db_sqlite
  File "lib/ht3_dispatch.py", line 33, in <module>
    import ht_proxy_if
ImportError: No module named ht_proxy_if


Ok, also hab ich mich daran gemacht, erstmal alles zu machen, was den 
ht_proxy angeht. Und jetzt sehe ich DT, HG und WW.

Ein HK-Telegramm kam erst nach 5 Minuten und dürfte auch nicht stimmen.
Die Ist-Temperatur kommt hin, aber Soll müsste 19 sein und Betriebart 
nicht Frost, sondern sparen. Allerdings bin ich nicht zu Hause und kann 
den Regler nicht ablesen.

Gruß,
Stephan

[Stephan (Gast)]

Hallo Norbert,
wenn ich so genau darüber nachdenke, dann könnte das doch korrekt sein. 
Der Regler ist ja neu für mich und so ganz hab ich den noch nicht 
verstanden.
Insbesondere da der Absenkbetrieb jetzt konfiguriert werden kann nach 
Raum oder Außen oder reduzierter Betrieb und hier auch noch eine vom 
Zeitprogramm unabhängige Temperatur angegeben werden kann.

Also lass mich heute Nacht nachschauen, was die Sollwerte tatsächlich 
sind.

Aber etwas anderes: Laut DB kommen die HK-Daten an, aber im 
rrdtool-Graphen wird gar nichts gezeigt (WW und HG laufen aber). Könnte 
es daran liegen, dass dieselben Werte mehrfach vorkommen? Siehe 
Screenshot...

Die rrdtool_draw sowie die DB's selbst habe ich gar nicht geändert.

Gruß,
Stephan

[Juri K. (iuser)]

Hallo Norbert,

jetzt bin ich wieder zuhause und kann endlich testen. Anbei ist die 
erste Aufzeichnung über ca.- 1 Stunde. Ich habe auch ein Ablaufscenario 
beigelegt und starte jetzt auch die längere Aufzeichnung, evtl. auch 
über die Nacht.

Gruß
Juri

[Juri K. (iuser)]

Und hier ist die andere Datei.

[Stephan (Gast)]

@Juri: Hast Du die neue Dekodierung schon getestet? Kommen Daten?

@Norbert: Leider weiterhin Probleme mit der Anzeige der HK-Daten, obwohl 
in der SQLite-DB durchaus welche vorhanden sind. Gibt aber nur einige 
winzige Punkte vereinzelt bei der Betriebsart. Kann ich irgendwo dem 
Programm zum Übertragen der Daten in die rrdtool-DB auf die Finger 
schauen?

[Norbert S. (junky-zs)]

Hallo,

@Alle mit CWxyz Regler
Im Release: 0.1.8 ist die Dekodierung noch fehlerhaft.
Wer es eilig hat kann manuell folgende Änderungen machen:
Modul: ht3_decode.py
Zeile: 505 ff
Ist:
                i_betriebsart   =int(buffer[17])
                f_Ist_HK    =float(buffer[6]*256+ buffer[7])/10
                Soll_temp = buffer[10]
                if buffer[10] > 30:
                    Soll_temp = buffer[10] / 2
                f_Soll_HK   =float(Soll_temp)
Soll:
                i_betriebsart   =int(buffer[27])
                f_Ist_HK    =float(buffer[6]*256+ buffer[7])/10
                f_Soll_HK   =float(buffer[12] / 2)

Bitte auf korrektes Einrücken achten sonst meckert python.
Damit werden die Betriebsart und die Soll_HK des Heizkreises korrekt 
aufgezeichnet (in der GUI kommen Auto und Manuell noch hinzu).
Betroffen sind davon nur Systeme bei denen dieser Telegrammtyp gesendet 
wird (z.Z. wohl nur Systeme mit CWxyz Regler).

Es sind noch weitere Details in Arbeit die ich aber noch teste und erst 
morgen auf github.com veröffentlichen werde.

@Juri
Danke für die Logdateien. Die haben die Dekodierung ermöglicht.

@Stephan
Versuch es bitte mal mit den obigen Änderungen. Sollte damit besser 
laufen.
Die selben DB-Telegrammeinträge beim Heizkreis im Release 0.1.8 sind 
falsch. Auch dies ist im nächsten Release korrigiert.


Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

danke für Deine Mühe, der Soll_HK ist jetzt auf 21, wo er auch zu 
erwarten ist.

Aber der rrdtool-Graph zeigt nach wie vor nichts obwohl rrdtool die 
Daten durchaus hat:

pi@raspberrypi ~/hometop_HT3/HT3/sw/var/databases $ rrdtool lastupdate 
HT3_db_rrd_heizkreis1.rrd
 T_soll_HK T_ist_HK T_steuer_FB V_betriebs_art V_mischerstellung 
T_vorlauf_misch_HK V_spare_1 V_spare_2

1455029935: 21 20.3 0 3 0 0 0 0
pi@raspberrypi ~/hometop_HT3/HT3/sw/var/databases $ rrdtool lastupdate 
HT3_db_rrd_heizkreis1.rrd
 T_soll_HK T_ist_HK T_steuer_FB V_betriebs_art V_mischerstellung 
T_vorlauf_misch_HK V_spare_1 V_spare_2

1455031495: 21 20.4 0 3 0 0 0 0

In der rrdtool-DB steht aber in dem Zeitraum gar nichts drin:

<!-- 2016-02-09 16:15:00 CET / 1455030900 --> 
<row><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN< 
/v><v>NaN</v></row>
      <!-- 2016-02-09 16:20:00 CET / 1455031200 --> 
<row><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN< 
/v><v>NaN</v></row>
      <!-- 2016-02-09 16:25:00 CET / 1455031500 --> 
<row><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN< 
/v><v>NaN</v></row>
      <!-- 2016-02-09 16:30:00 CET / 1455031800 --> 
<row><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN< 
/v><v>NaN</v></row>
      <!-- 2016-02-09 16:35:00 CET / 1455032100 --> 
<row><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN</v><v>NaN< 
/v><v>NaN</v></row>

Ist die DB zerschossen und ich muss sie neu aufbauen?

Herzlichen Dank,
Stephan

[Juri K. (iuser)]

Hallo,

mit den letzten Änderungen Sieht es schon besser aus. Ich habe es 
allerdings nur im Analyser angeschaut – d.h. noch keine grafischen 
Auswertungen gemacht.
2 Norbert: Danke für die schnellen Anpassungen. Sage mir Bescheid, falls 
ich weitere Logs aufnehmen soll. Werde versuchen am Wochenende den 
Außenfühler anzuschließen, danach gibt es evtl. noch etwas Interessantes 
auszulesen.

Gruß
Juri

[Norbert S. (junky-zs)]

Hallo Stephan,

> Ist die DB zerschossen und ich muss sie neu aufbauen?
Nein, ich glaube nicht.
Es kann an den mehrfachen HK-Einträgen innerhalb 1 Sekunde liegen. Dies 
mag das rrdtool für die gleichen Werte nicht.
Dieses Verhalten hattest Du ja weiter oben beschrieben und ist im 
nächsten Release (0.1.8.1) beseitigt.

Kontrolliere mal den /tmp-Ordner. Eventuell sind dort einige xyz*.pl 
Perl-scripte enthalten die genau auf diesen Fehler hindeuten.

Gruß Norbert

[Juri K. (iuser)]

Hallo Norbert,

ich versuche mich mit dem Format auseinander zu setzen, um eine openhab 
Binding zu programmieren. Dazu habe ich erst mal ein Paar grundlegende 
Fragen:

*die 4 Bytes  "0x23 0x48 0x52 0x11" (#HRDC1STX) scheint eine 
Trennsequenz zu sein - Stimmt es?
*danach kommt ein Byte - weiß Du, was das ist?
*danach kommt ein 4 bis X Bytes langes header, danach payload
*die CRC, was danach kommt - wird es über das ganze Telegramm berechnet, 
inklusive Header oder nur über Inhalt?
*Was ist ein Trennzeichen? Wieso ist es unterschiedlich?

Wenn Du mir die Fragen beantworten kannst, komme ich ein gutes Stückchen 
weiter (Wahrscheinlich zu den komplizierteren Fragen)


Gruß
Juri

P.S. Oder soll ich bei solchen Fragen lieber zu PM greifen?

[Norbert S. (junky-zs)]

Hallo Juri,

die Telegramm-Struktur ist beschrieben in der ht_transceiver - 
Dokumentation. Doku und Sw erhälts Du mit:

git clone https://github.com/norberts1/hometop_ht_transceiver.git

Die Doku ist dann unter:
 ~/hometop_ht_transceiver/docu/ht_transceiver_messages.html

Siehe dort Pkt.: 5.x für Heatronic.

Der Header des ht_transceivers ist 5 Byte lang, danach die Payload und 
ein abschliessendes CRC-Byte über alles.
Beispiel:
#HR(11)h<laengenbyte><Payload><CRC>
wobei:
 # := Tag als Header-Anfang (mehr oder weniger eindeutig)
 H := Heatronic Telegramm
 R := Received
 (11)hex ist Option-Byte und z.Zeit fest gesetzt.
  Wird jedoch noch geändert. Somit dies nicht auswerten.
 <laengenbyte> := Länge der im Telegramm enthaltenen Payload-Bytes.
  Dies ist die wohl wichtigste Angabe für Deine Auswertung.
 <Payload> := sind die Roh-Daten der Heizung.
 <CRC> := CRC über das gesamte Telegramm (Header+Payload)

Dieser Header ist natürlich nur vorhanden wenn man einen 
ht_transceiver-Adapter hat (ht_pitiny oder ht_piduino).
Ansonsten kommen natürlich nur die Roh-Daten der Heizung.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

@Alle

Habe die Software auf github.com aktualisiert auf Version: 0.1.8.1
Fehlerhafte Dekodierungen für CWxyz Telegramme und doppelte Commits sind 
behoben.
Entweder alles von github holen oder die betroffenen Module:
 ~/HT3/sw/lib/gui_worker.py    Version-Nummer auf 0.1.8.1; Auto/Manuell
 ~/HT3/sw/lib/ht3_decode.py    Dekodierung korrigiert
 ~/HT3/sw/lib/ht3_dispatch.py  Doppelte Commits beseitigt

Die Datenbanken müssen nicht neu angelegt werden falls schon vorhanden.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

good news and bad news:

Die HK1-Daten kommen jetzt eindeutig, also keine mehr doppelt. Es kommen 
vergleichsweise wenig und unregelmäßig, aber es kommen schon einige pro 
Stunde. HG und WW nach wie vor einwandfrei, auch in den Grafiken

Aber: In der Grafik absolut keine Anzeige. Ich habe sogar mal die 
heizkreis1.rrd neu erstellen lassen aber der (angehängte) Dump zeigt 
zwar immer aktuelle Werte als lastupdate, aber die Statistikdaten nur 
"NaN".

- Lohnt es sich hier noch weiter zu gucken oder soll ich Image neu 
machen und HT3 neu installieren?

- Falls ich noch gucken soll: Welches Programm überträgt die Daten von 
sqlite in rrdtool und kann ich das auch manuell ausführen um evtl. 
Fehlerausgaben sehen zu können?

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

aus Deinem sqlite-db Dump sehe ich nur 0 in den Spalten 'T_Soll_HK' und 
'V_betriebs_art' und im Hexdump sind dort die Werte ebenfalls Null.
Allein dies ist schon ein wenig seltsam.
Relevante Werte sind:
  Byte: 6/7 --> T_Ist Ist ja soweit OK.
  Byte:12   --> T_Soll Ist nur NULL !!!!???????????
  Byte:27   --> V_betriebs_art Nur NULL !!!!!!????????

Im test2.xml File sind dann diese Werte natürlich auch Null.
Es liegt also gar kein Fehler der Datenbanken vor, sondern im Telegramm 
sind die Werte einfach Null.
Warum ?. Hast Du eine Einstellung verändert am CW400 für diesen 
Heizkreis?

In Deinem Binär-logfile sind diese Werte noch gesetzt und enthalten.
Werde dies aber zum x-mal noch laufen lassen.
Bitte kontrolliere also die Einstellungen für die Heizkreise am CW400.


Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

anscheinend sind die Werte in der Tagabsenkung tatsächlich 0. Laut 
Zeitprogramm müsste tagsüber der Zielwert der Raumtemperatur bei 19 
liegen.
Also insofern keine Ahnung warum das 0 ist. Ich habe nur etwas geändert 
an der Absenkart und dem Frpstschutz, aber das Zeitprogramm und seine 
Temperaturen hab ich nicht angefasst. Blöderweise bin ich tagsüber nicht 
da, um die Ausgaben zu kontrollieren. Aber egal ob die 0 korrekt ist 
oder nicht, er zeigt ja nicht mal die 0 an.

Aktuell ist T_Soll 21 und Betriebsart 3, also sind die Bytes anscheinend 
korrekt. Ich habe Dir mal auch den aktuellen rrd-Dump angehängt. Da 
zeigt er bei "last_ds" tatsächlich den aktuellen Wert, aber "value" ist 
immer NaN.

Gruß,
Stephan

[Stephan (Gast)]

Noch etwas: Vielleicht ist die Betriebsart gar nicht Byte 27, sondern 
17. Denn da passt es mit 1 für Sparen (oder Frost) und ab 15 Uhr dann 3 
für Heizen.

[Norbert S. (junky-zs)]

Hallo Stephan,

das zugehörige Telegramm (33Byte Länge) kommt bei Deinem System sehr 
selten (15 bis ca. 30 Minuten).
Somit wird auch nur sehr selten ein Wert in die rrdtool-db eingetragen. 
Da diese mit 60 Sekunden Timing eingestellt ist und in der Zeit kein 
Wert gekommen ist wird dort dann automatisch der Default Wert Null 
eingetragen.
Die paar gültigen Werte innerhalb von 30 Minuten kann man dann in der 
Grafik nicht mal mehr als Pixel wiederfinden.
Somit hast Du eine schöne bunte Null-Linie in der HK-Grafikanzeige.
Es hilft Dir nicht viel einen Dump der rrdtool-db zu irgend einem 
Zeitpunkt zu machen, Du wirst zu 96.66% dort dann den Nix-Wert finden.

Bei Juri kommen diese Telegramme etwas häufiger. Mal sehen was sein Test 
bringt.
Allerdings gibt es von diesem Telegramm-Typ kürzere Exemplare mit einer 
Untermenge der Informationen die häufiger gesendet werden.

Bitte mach deshalb noch einmal ein binär-logfile über ca. 2 Stunden in 
der dieser Heizkreis nicht gerade im Schlaf-/Urlaub- etc. Modus ist.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

anbei das Log. Ich hoffe, es ist ok. Ich habe extra etwas länger 
gemacht, damit der Wechsel von Tag auf Nacht um 23 Uhr mit dabei ist. Im 
übrigen zeigt der Regler nach 23 Uhr sowohl als Soll-Raumtemperatur als 
auch als Betriebsstatus "Aus" an. Insofern würde hier eine 0 tatsächlich 
passen.
Vor 23 Uhr war es 21 Grad und Heizen.

Aber so wie Du schreibst sind die Werte egal, denn mit so seltenen 
Werten kann rrdtool nicht arbeiten. Wer sendet eigentlich die 
Telegramme? Die Heizung oder der Regler? Denn vor dem Reglerwechsel 
hatte ich ja einwandfreie Daten vom Heizkreis...

Gibt es ein Tool, mit dem man das Log in "lesbare" Form bringen kann? 
Also z.B. 1 Zeile Pro Telegramm und alle Werte in Hex?

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

danke für das Logfile. Werde es analysieren.

> Wer sendet eigentlich die Telegramme? Die Heizung oder der Regler?
Beide, wobei die Heizung bzw. Steuerung der Taktschläger ist und die 
angeschlossene Perpherie taktvoll darauf antworten darf.
Wobei Telegramme mit Struktur: GA 00 xy zw ... die Echo-Telegramme der 
Heizung von Telegrammen der Periperie sind, wobei hier: 
GA:='Geräteadresse mit MSB aktiv' und anschliessende 00 := 'An Alle' 
bedeuten.

> Gibt es ein Tool, mit dem man das Log in "lesbare" Form bringen kann?
Ja, heisst: HT3_Analyser.py :-)
Um dies zu aktivieren musst Du im Konfigurationsfile 
./sw/etc/config/HT3_db_cfg_.xml den Eintrag: <inputtestfilepath> 
anpassen auf absoluten Pfad mit Logfilename.
Beispiel:
      <parameter name="ASYNC">
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <inputtestfilepath>/meinPfad/meinlogfile.log</inputtestfilepath>
        <baudrate>9600</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
Weitere Änderungen sind nicht erforderlich. Die Datenbanken werden damit 
natürlich nicht in Echtzeit sondern so schnell als möglich gefüllt. 
Somit sind die grafischen Ausgaben des rrdtool nicht wirklich nutzbar 
und es wird alles komprimiert dargestellt.
Rückgängig machst Du dies wieder indem Du den Pfad/logfile-Eintrag 
wieder löscht, also:
  <inputtestfilepath></inputtestfilepath>

Gruß Norbert

[Klaus (Gast)]

Hallo,

ich habe in meiner Konfiguration mit FW200 ein Problem mit dem Telegramm 
0xA1 0x00 0x34...

Die Daten werden fälschlicherweise dem Warmwasser zugeordnet was zu den 
Peaks in der Grafik führt. (siehe Anhang).
Im Augeblick ist mir noch nicht klar um welche Daten es sich handelt.

Gruß
Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

> 0xA1 0x00 0x34... Die Daten werden fälschlicherweise dem Warmwasser
> zugeordnet
Die Zuordnung ist schon richtig, die Werte im Telegramm sind falsch 
warum auch immer.
Die korrekten Werte kommen bei Deinem System vom Telegramm: 0x88 x00 
0x34 0x00...
Aber auch das Telegramm 0xA1 0x00 0x34 ist für Warmwasser-Meldungen 
vorgesehen. In diesem Fall kommt die Meldung vom Schaltmodul IPM2 für 
den Warmwasser-Betrieb.
Wie ist Dein System aufgebaut?
Ich nehme mal an das Du neben dem FW200-Regler noch ein Schaltmodul IPM2 
eingebaut hast welches den einen Kanal für den Heizkreis und den anderen 
Kanal für Warmwasser-Erzeugung verwendet.

Auf jeden Fall sind die Werte im Telegramm falsch.
Ein Binär-logfile wird da weiterhelfen.

Wie Du Logfiles erstellen kannst findest Du unter:
  Beitrag "Re: Heizungs-Datenerfassung (HT3)" ff
Gruß Norbert

[Klaus (Gast)]

Hallo Norbert,

ich hatte das mit dem Logfile schon versucht.
Ich bekomme allerdings eine Fehlermeldung wenn ich einen zweiten Client 
(binlogclient) starte.
Bin noch am Testen woran das Problem liegt.

Gruß Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

> Ich bekomme allerdings eine Fehlermeldung
wie lautet die Fehlermeldung?

Ich nehme mal an das Du den ht_proxy.server auf dem Raspberry laufen 
hast.
Dann kannst Du das Tool: ht_binlogclient.py direkt auf dem Raspberry 
aufrufen. Dies läuft dann mit der Host-adresse: 'localhost'.
Oder Du rufst dieses Tool von einem anderen Rechner auf, dann bitte die 
Server-Adresse im Config-File auf dem anderen Rechners anpassen:
 ./sw/etc/config/ht_proxy_cfg.xml.
     <serveraddress>192.168.xxx.yyy</serveraddress>

Hast Du überhaupt ein IPM Schaltmodul in Deinem Heizungssystem?
Falls nicht ist das Telegramm ohnehin eine Fehldetektion.

Gruß Norbert

[Stephan (Gast)]

Norbert S. schrieb:
> Ja, heisst: HT3_Analyser.py :-)

Hallo Norbert,

was ich eigentlich meinte: Die HK-Telegramme kommen ja von der Heizung 
und nicht vom Regler und vor dem Reglerwechsel hatte ich immer 
einwandfreie Daten vom HK mit der Version vom Jan 15.

Also gibt es für mich nur 3 Möglichkeiten:

- Durch den neuen Regler ist die Steuerung der Heizung umgestellt, so 
dass sie jetzt andere Telegramme unbekannter Art sendet
- Für die neuen Scripte musste ich ja auch auf die aktuelle Software mit 
ht_proxy aktualisieren. Entweder hab ich dabei etwas falsch gemacht oder 
vergessen und deswegen kann die Software nicht alle Telegramme erkennen
- Die Telegramme kommen tatsächlich so selten, aber mit dem alten Regler 
und der alten Software lief es

Da der HT_Analyser ja doch nur wieder die Daten darstellen kann, die er 
kennt, dürfte es doch egal sein, ob ich ihn anstelle des Loggers laufen 
lasse oder ein Logfile einlese, oder? Unbekannte Daten könnte er nicht 
anzeigen, denn beim normalen Mitlaufen lassen sehe ich nur die Daten, 
die auch in der DB ankommen.

Was ich deshalb wollte: Das Binärlog so formatieren, dass es jeweils die 
Hexdumps eines Telegramms auf einer Zeile darstellt, ohne dass ich auf 
irgendeine Dekodierung angewiesen bin. Dann könnte ich sortieren und 
gucken, welche Telegrammart denn wie oft kommt und die bekannten 
rausfiltern.

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

> Die HK-Telegramme kommen ja von der Heizung und nicht vom Regler.
Ja und Nein.
Die meisten der dekodierten Telegramme sind Echo's VON der HEIZUNG aus 
Telegrammen der PERIPHERIE (zumindest die Telegramme 'An Alle').
Wenn Du also einen neuen Regler mit NEUEN Telegramm-Eigenschaften hast 
erhälst Du auch neue Telegramme.
Die Heizung erkennt ohnehin den Reglertyp aus separaten anderen 
Telegrammen und stellt sich drauf ein.

> Da der HT_Analyser ja doch nur wieder die Daten darstellen kann, die er
> kennt ...
Stimmt, liegt an der Dekodierung die aber erweiterbar ist. Und genau 
darum geht es ja.

> Was ich deshalb wollte: Das Binärlog so formatieren dass es jeweils die
> Hexdumps eines Telegramms auf einer Zeile darstellt
Ich habe eine Tool (Pre-Version) in Arbeit die aus dem Binälog-File ein 
CSV-File generiert. Dann kann man die Telegramme mit LibreOffice oder 
Excel bearbeiten (filtern etc.)
Dies läuft noch nicht ganz rund, kann es hier aber alsbald 
bereitstellen.

Gruß Norbert

[Klaus (Gast)]

Hallo Norbert,

jetzt hat sich der binlog starten lassen.
Allerdings ist der logger daraufhin abgebrochen und lies sich nicht mehr 
nachstarten.

12.02.2016 16:11:38 CRITICAL: ht3_cworker();Error;couldn't open 
requested socket; cfg-file:/home/pi/HT3/sw/etc/config/ht_proxy_cfg.xml

Ich musste dann 2x !!! neu booten, bevor proxy und logger wieder liefen. 
Ich habe nicht weiter analysiert, ob der Port nicht geöffnet war. Die 
Meldung deutet ja darauf hin.

Früher hatte ich schon mal folgende Meldung, wenn ich einen zweiten 
Client am Proxy anmelden wollte:

"Client-ID:{0};cportwrite();couldn't read from queue"

Ich muss mal bei Gelegenheit prüfen, ob mein Softwarestand richtig ist. 
Wenn man nur den proxy mit logger laufen lässt dann funktioniert das 
seit 2 Monaten ohne Probleme.

Anbei noch ein Logfile und die Anlagenkonfiguration.

BTW: das 0xA1 0x00 0x34 scheint auch länger zu sein als es im dispatcher 
erwartet wird.

Gruß
Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

das Telegramm: 0xA1 0x00 0x34 ist eine Fehldetektion da Dein IPM2 Modul 
nichts mit der Warmwasser-Erzeugung zu tun hat.
Zufällig stimmt bei diesem 'Telegramm' in Deinem System die CRC am Ende 
und deshalb werden die Werte auch verwendet.
Der Inhalt ist aber falsch und hat rein gar nichts mit WW zu tun.
Deshalb ist folgende Anpassung an der Software erforderlich:
Modul: ht3_decode.py
Fkt  : IPM_LastschaltmodulWWModeMsg()
Zeile: 547
Ist:
 if self.crc_testen(buffer,length) == True:
Soll:
 if((self.crc_testen(buffer,length)==True) and (buffer[length-1]==0)):

Probier es aus, ich hoffe dies beseitigt diesen Fehler in Deinem System.
Ein Test bei mir mit Deinem Logfile hat jedenfalls Wirkung gezeigt.

Gruß Norbert

[Klaus (Gast)]

Hallo Norbert,

danke für deine Antwort. Ich hatte die Auswertung für das Telegramm 
einfach auskommentiert.
Inzwischen tendiere ich dazu, dass es sich bei den Werten um die 
Rücklauf Temperaturen handeln könnte, da diese in der jetzigen 
Konfiguration immer 0 ist.
Allerdings kommt das Telegramm relativ selten.

Gruß Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

> Inzwischen tendiere ich dazu, dass es sich bei den Werten um die Rücklauf
> Temperaturen handeln könnte,...
Sicher nicht, es ist eine Fehldetektion die ich mit dieser Anpassung 
hoffentlich behoben habe. Es sind im Telegramm Polling-Bytes des Masters 
mit Antworten eines Slaves (Peripherie) enthalten: 09 89 ... die dort in 
ein gültiges Telegramm nicht hingehören.
Bitte probiere es aus, weil ich im Gutfall dies mit in das nächste 
Release übernehme.
Du bist in diesem Fall der Problemmelder und der Softwaretester weil Du 
ein System mit IPM-Schaltmodul hast. Ein IPM-Modul habe ich selber 
nicht, deshalb kann ich dies auch nicht wirklich überprüfen.
Andere die auch ein IPM-Modul haben wären Dir also recht dankbar wenn Du 
noch den letzten Schritt (ein kleiner für Klaus) machen würdest.

Danke im Voraus!
Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,
Ich habe mir für die Zeit bis zum nächsten Release ein kleines php 
Script geschrieben, was jede Minute aufgerufen wird und den jeweils 
letzten wert mit aktuellem timestamp in die DB schreibt. Und schon hab 
ich grafische Ausgaben. Damit wäre bewiesen, dass es tatsächlich nur zu 
wenige werte sind und sonst alles okay ist.
Zusätzlich habe ich den betriebszustand 0 in -1 geändert, damit nicht 2 
Werte auf der nulllinie rumlungern.
Ist zwar so jetzt möglicherweise nicht zeitlich exakt,  aber man kann 
damit arbeiten und ich kann mit den verschiedenen Absenkmodi 
experimentieren. Was die machen,  machen die ja immer dann,  wenn man 
außer Haus ist oder im bett.

Gruß, Stephan

[Klaus (Gast)]

Hallo Norbert,

deine Änderung scheint zu funktionieren.

Wenn es nicht die Rücklauftemperaturen sind, dann muss es noch ein 
weiteres Telegramm geben, da diese Werte im FW200 angezeigt werden.

Gruß
Klaus

[Klaus (Gast)]

Klaus schrieb:
> Hallo Norbert,
>
> deine Änderung scheint zu funktionieren.
>
> Wenn es nicht die Rücklauftemperaturen sind, dann muss es noch ein
> weiteres Telegramm geben, da diese Werte im FW200 angezeigt werden.
>
> Gruß
> Klaus

Einige Telegramme scheinen doch noch durchzukommen. Sieht aber aus, als 
ob es weniger sind.

[Norbert S. (junky-zs)]

Hallo Klaus,

danke für die Info und den Test. Werde es somit in das nächste Release 
mit aufnehmen.
Trotzdem werde ich noch weiter den Dekoder verbessern und möglichst 
robust machen.
Dafür sind die Logfiles Gold wert!

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

hast Du schon eine Idee, wann Du eine neue Version herausbringen 
möchtest, so dass die HK-Daten auch bei den CW's wieder zeitnah erfasst 
werden können? Das "Füllen" der Lücken ist ja doch keine wirkliche 
Lösung.

Gerne würde ich auch das Tool nutzen, um Logfiles in csv umzusetzen. 
Dann kann ich ja mal besser sehen, welche Arten von Daten wie oft 
kommen.

Herzlichen Dank,
Stephan

[Nils R. (augur)]

Hi.

Hat von euch schon jemand es hinbekommen Kommandos mit ht_netclient.py 
über PHP anzusteuern. Bei mir will es einfach nicht klappen und ich 
würde gerne über einen Webservice im Apache die Modus umschalten.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo,

@Stephan
> hast Du schon eine Idee, wann Du eine neue Version herausbringen möchtest?
Nicht vor Ostern.

> Gerne würde ich auch das Tool nutzen, um Logfiles in csv umzusetzen.
Ist in Arbeit.

@Nils
> Hat von euch schon jemand es hinbekommen Kommandos mit ht_netclient.py
> über PHP anzusteuern ?
Wenn Du ht_netclient.py von php aufrufst ist das Environment (Pfade) 
wichtig.
'ht_netclient.py' findet sonst u.U. die verwendeten Libraries nicht.
Diese liegen ja im Verzeichnis ~/HT3/sw/lib.
Siehe Aufrufe im script 'ht_netclient.py':
  ...
  sys.path.append('lib')
  import ht_proxy_if, ht_transceiver, ht_yanetcom
  ...

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

@Stephan
> Gerne würde ich auch das Tool nutzen, um Logfiles in csv umzusetzen.
Dies Tool: 'ht_bin2csv.py' habe ich als Tar-file angehängt.

Es extrahiert die binären Heatronic-Telegramme so gut es geht und 
schreibt es formatiert in ein separates CSV-File.
Dies funktioniert mit Logfiles vom ht_transceiver-Adatper (mit eigenem 
Header) aber ebenso mit reinem binären HT-Telegrammen.
Eine 100% korrekte Detektion und Formatierung wird jedoch mit reinem 
binären HT-Telegrammen nicht erreicht. Da ist noch Nacharbeit 
erforderlich.

Im Modulkopf ist eine kurze Beschreibung enthalten.

Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:

> Wenn Du ht_netclient.py von php aufrufst ist das Environment (Pfade)
> wichtig.
> 'ht_netclient.py' findet sonst u.U. die verwendeten Libraries nicht.
> Diese liegen ja im Verzeichnis ~/HT3/sw/lib.
> Siehe Aufrufe im script 'ht_netclient.py':
>   ...
>   sys.path.append('lib')
>   import ht_proxy_if, ht_transceiver, ht_yanetcom
>   ...
>
> Gruß Norbert

Hi,

ich hab die Pfade nun angepasst und auch noch im Skript einen Verweis 
auf die Konfiguration (...  ./etc/..) angepasst.

Leider stehen an mehreren anderen stellen noch relative Pfade, sodass 
ich noch den angehängten Fehler bekomme. Kann ich die Pfade ggf. an 
einer Stelle anpassen?

Viele Grüße,
Nils

[Stephan (Gast)]

Hallo Nils,

beim Überfliegen der Ausgabe ist mir aufgefallen, dass er wohl Probleme 
beim Logging hat. Du startest das Script in /home/pi/HT3/sw, das Log 
soll aber angelegt werden in /home/pi/var/log (ohne HT3). Gibt es das 
Verzeichnis so überhaupt?

Gruß,
Stephan

[Stephan (Gast)]

Norbert S. schrieb:
> Es extrahiert die binären Heatronic-Telegramme so gut es geht und
> schreibt es formatiert in ein separates CSV-File.

Hallo Norbert,

ich habe das Tool mal genommen und mein am 11.2. hochgeladenes cw400.log 
durchlaufen lassen. Für die Daten, die laut HT_Analyzer Daten für den 
Heizkreis 1 sind, nämlich 90 00 FF 00 01 A5, zeigt er im csv aber statt 
einem 33-Byte-Telegramm eines mit der Länge 10:

10.02.2016;19:49:43;10;90;00;ff;00;01;a5;00;d4;4a;00;

Alle Telegramme mit diesen ersten 6 Bytes haben nur 10 Bytes Länge.

Die 88 00 18 Telegramme hingegen haben die Solllänge von 31 Bytes.

Mach ich was falsch oder liegt es einfach daran, dass das Tool nicht 
100% dekodieren kann?

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo,

@Nils
> Leider stehen an mehreren anderen stellen noch relative Pfade, sodass
> ich noch den angehängten Fehler bekomme. Kann ich die Pfade ggf. an
> einer Stelle anpassen?
Die Pfade in den Python-scripten sind relativ und werden auch so bleiben 
damit man die gesamte Applikation in einen Pfad seiner Wahl legen kann.
Damit der Aufruf der Scripts von PHP klappt musst Du VOR dem Aufruf des 
scripts:'ht_netclient.py' in den ABSOLUTEN Pfad wechseln in dem dieses 
Script steht.
Eine Anpassung der scripte auf absolute Pfade würde ich tunlichst 
vermeiden zumal dies nach jedem SW-Update wieder erforderlich ist.

@Stephan
> ... oder liegt es einfach daran, dass das Tool nicht 100% dekodieren kann?
Ja, hatte ich erwähnt.

Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:
> Du VOR dem Aufruf des
> scripts:'ht_netclient.py' in den ABSOLUTEN Pfad wechseln in dem dieses
> Script steht.

Das hatte ich schon mal drinnen, aber dort hatte er die Bibliotheken 
trotzdem nicht gefunden. Ich hab die Pfadänderung wieder ergänzt und es 
funktioniert. :-)

Also folgende Sachen waren zu tun für andere:
- sys.path.append('/home/pi/HT3/sw/lib') <- absoluter Pfad eintragen
- Folgenden Code im PHP aufrufen:

function setzeModus2($modus) {
            chdir("/home/pi/HT3/sw/");
//            Modi: auto, heizen, sparen frost
            $command = "sudo /home/pi/HT3/sw/ht_netclient.py -b " . 
$modus;
            $read = exec($command);
            echo $command;
            echo $read;
        }

Kann ich den aktuellen Modus eigentlich auch live auslesen, um im Web 
den Status anzuzeigen oder müsste ich dafür auf die SQLite Datenbank 
abfragen?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

prima das es jetzt läuft.
Es ist zwar ein absoluter Pfad drin aber wohl nur in diesem Modul.
Ich werde jedoch diese Pfadangabe weiterhin relativ belassen und somit 
muss jeder selber manuell den Pfad in dem Modul auf seine 
Installations-Pfade anpassen.

> Kann ich den aktuellen Modus eigentlich auch live auslesen, um im Web
> den Status anzuzeigen oder müsste ich dafür auf die SQLite Datenbank
> abfragen?
Zur Zeit geht eine Abfrage einzelner Werte nicht und man muss die 
RAW-Daten selber dekodieren und den benötigten Wert rausfischen.
Es ist jedoch ein Zusatzmodul in Arbeit welches genau dies realisiert. 
Die Dekodierung ist dann nur einmal zentral nötig.
Dies und noch mehr muss jedoch noch in ein neues SW-Release hinein.

Kurzfristig ist daher eine Abfrage der Datenbank die schnellere Lösung 
um an den Wert zu kommen.

Gruß Norbert

[Juri K. (iuser)]

Hallo,

habe jetzt noch den Außentemperatur Sensor installiert und damit ein 
wenig geloggt - evtl. kann es verwendet werden. Dabei sind auch meine 
Versuche, die Parameter über ht_netclient zu setzen - Temperatur auf 25 
Grad und Betriebsart auf Frost. Leider erfolgslos, aber evtl. ist etwas 
in dem Log zu sehen?

Gruß
Juri

[Klaus (Gast)]

Hallo,

ich habe die HTML Datei (index.html) so erweitert, dass sich die Anzeige 
jede Minute aktualisiert. D.h. man muß nicht mehr explizit nachladen.
Das ist z.B. dann praktisch, wenn man den raspi zur Anzeige an einen TV 
anschliesst, ohne dass eine Tastatur angeschlossen ist.

Hier die Änderung:

<HTML>
<HEAD>
<TITLE>Heizungs-Historie</TITLE>
<script type="text/javascript">
window.onload = function()
{
  // reload images
  function updateImage() {
    var images = document.getElementsByTagName('img');
    for(var i=0; i < images.length ;i++){
      var source =  images[i].attributes.src.nodeValue.split("?")[0];
      images[i].src = source+"?"+Date.now();
    }
  }
  // reload every minute
  setInterval(updateImage, 60*1000);
}
</script>
</HEAD>
....


Gruß
Klaus

[Norbert S. (junky-zs)]

Hallo,

@Alle
Habe die Software auf github.com aktualisiert auf die Version: 0.1.9
Grund sind ein paar Korrekturen für die Telegramm-Auswertung der 
Cxzy-Regler.
Wer es komplett mag bekommt alles mit:
  git clone https://github.com/norberts1/hometop_HT3.git

Wer keinen CW100/400 bzw. CR100... Regler hat braucht dieses Update 
nicht.

@Stephan (Gast)
Bitte probiere dieses Release aus, die Auswertung ist verbessert. Habe 
mit Deinem Binaerfile getestet und die Telegramme (auch mit 10 Byte 
Länge) Deines CW400 werden besser ausgewertet.

@Klaus (Gast)
> habe die HTML Datei (index.html) so erweitert, dass sich die Anzeige
> jede Minute aktualisiert.
Danke für die Erweiterung. Die klappt gut und ich habe diese mit in das 
Release 0.1.9 übernommen.

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

schön wieder von Dir zu hören. Ich werde das in den nächsten Tagen mal 
probieren. Etwas knapp an Zeit. Oder reicht es, ein paar Dateien 
auszutauschen? Wenn ja, welche?

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan T.,

lass Dir mit dem Testen Zeit.
Ich habe ja Deine Logfiles und brauche auch keine Neuen.
Es kommt auch so schon keine Langeweile bei mir auf :-)

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

habe nur die 3 ht3_*.py in lib ausgetauscht, denn alles andere sieht ja 
laut GIT unverändert aus.
Meine HK-Meldungen kommen jetzt alle 1-2 Minuten, manchmal aber auch 3 
Minuten Pause, was dann im Graphen kleine Lücken produziert. Insofern 
bleibe ich erstmal bei meinem Workaround, alle Minute den jeweils 
letzten Wert nochmal in die DB zu schreiben. Aber zumindestens sehe ich 
Statusänderungen jetzt sofort.

Weiterhin ist mir aufgefallen, dass jetzt wieder fast alle Werte doppelt 
kommen. Das war doch schon mal gefixt, oder? Mich stört es jetzt nicht 
so, denn RRD kommt damit anscheinend klar und die Werte werden sowieso 
nach 3 Tagen gelöscht. Aber bei anderen könnte die DB unnötig wachsen.

Eine kleine Sache noch: Bei Betriebsart Sparen kommt beim CW als 
Betriebsart eine 0 und auch als Solltemperatur eine 0. Wo kann man es so 
anpassen, dass er Betriebsart 0 als 2 schreibt, damit einerseits nicht 2 
Werte denselben Graphen schreiben und dann auch noch die Legende stimmt?

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

> Wo kann man es so anpassen, dass er Betriebsart 0 als 2 schreibt, damit
> einerseits nicht 2 Werte denselben Graphen schreiben und dann auch noch
> die Legende stimmt?
Die Anpassung kannst Du im perl-script:rrdtool_draw.pl machen wie folgt:
 In Heizkreis1: Zeilen 403 ff folgendes anpassen

########test fuer Forum ##################
  draw    => {
    dsname  => 'V_betriebs_art',
##    name  => 'Betriebsart',
    name  => 'betriebs_art_fkt',
    type  => 'hidden',
##    legend  => 'Betriebsart (3=Heizen 2=Sparen 1=Frost)\l',
##    thickness => 2,
##    color  => '808080'
  },
  draw    => {
    legend  => 'Betriebsart (9=Eco 8=Comfort 7=Manual 6=Summer 
5=Off)\l',
    thickness => 2,
    color  => '808080',
    cdef  => "betriebs_art_fkt,5,+"
  },
Kurze Erklärung:
1. Der draw fuer dsname => 'V_betriebs_art' wird hidden und erhält
   einen neuen Namen name=>'betriebs_art_fkt'
2. Es wird ein Neuer draw angelegt der jetzt die Arbeit macht:
2.1 legende schreiben (hier ist der Offset mit 5 schon eingerechnet)
2.2 zum Datenbankwert 'V_betriebs_art' wird der Wert 5 addiert.

Nach meien Unterlagen sind die Betriebsart-Werte bei den CR/CW/CTxyz 
Reglern wie folgt:
 0 := Off
 1 := Summer
 2 := Manual
 3 := Comfort
 4 := Eco

Somit ist Dein angezeigter Wert nicht 'Sparen' sondern 'Off' gewesen.
Bei 'Off' spart man ja auch besonders viel :-)

> Weiterhin ist mir aufgefallen, dass jetzt wieder fast alle Werte doppelt
> kommen.
Dies schau ich mir noch an. Die Software ist sowieso in Arbeit und die 
Baustellen werden nur langsam weniger.

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

habe das eingebaut und es ist besser als vorher. Aber kann ich es so 
machen, dass er tatsächlich nur den Betriebsart-Wert 0 auf -1 setzt, 
aber keinen anderen ändert? Denn momentan zeigt die Grafik den Wert 0 
der Temperatur nicht an, denn er liegt auf der unteren Linie. Das war in 
meinem temporären Workaround besser sichtbar, als ich einen Wert bei -1 
hatte.

Danke und Gruß,
Stephan

[Lasse (Gast)]

Moin Norbert und alle anderen,

bin gestern auch mal dazu gekommen deine Software endlich in Betrieb zu 
nehmen. Bis auf zwei Dinge klappt auch alles soweit super, vielen Dank 
dafür!

Zum einen bekomme ich keinerlei Daten zur Solarthermie. Ich habe eine 
einfache ZSB 14-4 mit einem Heizkreis und integriertem Mischer, dazu den 
MS100 für einen einfachen Solarkreis und den CW400 als Regler. Wird 
davon etwas nicht richtig decodiert? Kann ich evtl. mit Logfiles 
aushelfen?

Zum anderen ist die kleinste Auflösung in den Graphen ein Schritt von 5 
Minuten, obwohl zumindest in der SQL-Datenbank deutlich mehr Daten 
vorliegen. Der Graph im Anhang zeigt zum Beispiel in der Zeit von 0710 
bis 0725 nur drei Schritte, obwohl in der Datenbank ganze 9 Schritte in 
über 60 erfassten Werten vorliegen (siehe unten). Ist das eine 
Einstellungssache oder läuft da bei mir was nicht ganz rund?

Vielen Dank schonmal und schönen Gruß,
Lasse

14.06.2016 07:09:55  26.2
14.06.2016 07:10:04  26.2
14.06.2016 07:10:24  26.2
14.06.2016 07:10:34  26.1
14.06.2016 07:10:45  26.1
14.06.2016 07:11:04  26.1
14.06.2016 07:11:34  25.9
14.06.2016 07:12:04  25.9
14.06.2016 07:12:14  25.9
14.06.2016 07:12:34  25.8
14.06.2016 07:12:54  25.8
14.06.2016 07:13:04  25.6
14.06.2016 07:13:14  25.6
14.06.2016 07:13:23  25.6
14.06.2016 07:13:44  25.6
14.06.2016 07:13:55  25.5
14.06.2016 07:14:04  25.5
14.06.2016 07:14:14  25.5
14.06.2016 07:14:33  25.5
14.06.2016 07:15:03  25.4
14.06.2016 07:15:13  25.4
14.06.2016 07:15:33  25.4
14.06.2016 07:15:43  25.4
14.06.2016 07:15:55  25.4
14.06.2016 07:16:03  25.4
14.06.2016 07:16:13  25.4
14.06.2016 07:16:43  25.4
14.06.2016 07:17:33  25.2
14.06.2016 07:17:43  25.2
14.06.2016 07:18:13  25.2
14.06.2016 07:18:22  25.2
14.06.2016 07:18:43  25.2
14.06.2016 07:19:02  25.2
14.06.2016 07:19:13  25.2
14.06.2016 07:19:55  25.2
14.06.2016 07:20:02  25.2
14.06.2016 07:20:13  25.2
14.06.2016 07:20:22  25.2
14.06.2016 07:20:32  25.2
14.06.2016 07:20:53  25.2
14.06.2016 07:21:02  25.2
14.06.2016 07:21:12  25.2
14.06.2016 07:21:21  25.2
14.06.2016 07:21:32  25.2
14.06.2016 07:21:55  25.2
14.06.2016 07:21:55  25.2
14.06.2016 07:22:02  25.2
14.06.2016 07:22:31  25.2
14.06.2016 07:22:53  25.2
14.06.2016 07:22:53  25.2
14.06.2016 07:23:01  25.2
14.06.2016 07:23:12  25.2
14.06.2016 07:23:31  25.2
14.06.2016 07:23:41  25.2
14.06.2016 07:23:55  25.2
14.06.2016 07:24:11  25.2
14.06.2016 07:24:21  25.1
14.06.2016 07:24:31  25.1
14.06.2016 07:24:41  25.1
14.06.2016 07:24:53  25.1
14.06.2016 07:25:11  25.1
14.06.2016 07:25:31  25.1
14.06.2016 07:25:41  25.1

[Stephan (Gast)]

Hallo Lasse,

das mit den 5 Minuten ist ok, denn RRD arbeitet fest mit diesem 
Intervall.
Es gibt einige Anleitungen, wie man das öfter laufen lassen kann, aber 
ich glaube nicht, dass das hier nötig ist. Schließlich geht es ja eher 
um eine Übersicht/Tendenz als um eine minutengenaue Anzeige.

Gruß,
Stephan

[Lasse (Gast)]

Stephan,

danke für den Hinweis. Dann muss ich mir bei Bedarf was einfallen lassen 
und die SQL-Daten mit Excel darstellen oder so. Meine Heizung ist 
nämlich vom "Fachmann" so eingestellt worden, dass sie durchaus mal 
Brennerlaufzeiten von unter einer Minute produziert, was ich persönlich 
für nicht akzeptabel halte und mit den aufgezeichneten Daten darstellen 
wollte.

Gruss,
Lasse

[Stephan (Gast)]

Hallo Lasse,

das mit den Brennerlaufzeiten von 1 min ist wirklich nicht akzeptabel. 
Im Moment könnte es zwar vorkommen, da manchmal die 
Soll-Vorlauf-Temperatur nur wenig höher liegt als die Ist-Temperatur, 
aber wenn es wieder kälter wird dann darf das nicht mehr sein. Meine 
Anlage (auch eine 14-4) schafft es bei kälteren Temperaturen locker 1 
Stunde die Temperatur zu halten und eben nur soviel Leistung zu erzeugen 
wie benötigt wird. Brennwerteffekt stellt sich laut meinem Monteur erst 
nach 10-15 Minuten ein.

Gruß,
Stephan

[Stephan (Gast)]

Hallo Lasse,

noch etwas: die Datenerfassung solltest Du NICHT verwenden, um deinem 
"Fachmann" oder Junkers etwas beweisen zu wollen. Es ist unklar, wie die 
reagieren, wenn Nicht-Junkers-Geräte am Bus hängen. Es könnte die 
Garantie gefährden...

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Lasse,

> Zum anderen ist die kleinste Auflösung in den Graphen ein Schritt von 5
> Minuten, obwohl ...
Für das Timing der Grafen ist der cron-job zuständig, dort kannst Du die 
Zeit reduzieren auf z.B. 2 Minuten.
Hinweis: Es werden alle 60 Sekunden neue Daten in die rrd-db 
geschrieben, schneller macht keinen Sinn, da einige Telegramme nur 1mal 
pro Minute kommen und der Raspberry (je nach Version) dann gut zu tun 
hat.
Beispiel:
Den Aufruf im cron-job ändern auf 2 Minuten
*/2   * * pi /usr/bin/perl -S rrdtool_draw.pl /home/pi /home/pi 1

> Zum einen bekomme ich keinerlei Daten zur Solarthermie. Ich habe eine
> einfache ZSB 14-4 mit einem Heizkreis und integriertem Mischer, dazu den
> MS100 für einen einfachen Solarkreis und den CW400 als Regler.
Ja, Junkers war fleissig und hat Dir und anderen neue Regler mit neuen 
Telegrammen gegönnt.
Aber ich war auch nicht faul und habe die Software für die neuen 
C-Regler und den Basisfunktionen angepasst. Allerdings ist diese 
Anpassung noch nicht auf github.com vorhanden und ich arbeite noch am 
nächsten Release.

Sende mir eine PM und ich kann Dir im Voraus diese Software als 
Testversion zusenden.
Und ja, logfiles kann ich immer gebrauchen zumal Du den HT4i-Heizungsbus 
eingebaut hast.

Gruß Norbert

[Lasse B. (preamp)]

> Für das Timing der Grafen ist der cron-job zuständig, dort kannst Du die
> Zeit reduzieren auf z.B. 2 Minuten.

Das habe ich auch schon probiert, aber ohne Erfolg. Zumal die Daten in 
der rrd-Datenbank ja unabhängig vom cron sein müssten, d.h. wenn ich das 
Script manuell aufrufe, sollten die Schritte im Minutentakt auftreten?


> Hinweis: Es werden alle 60 Sekunden neue Daten in die rrd-db
> geschrieben, schneller macht keinen Sinn, da einige Telegramme nur 1mal
> pro Minute kommen und der Raspberry (je nach Version) dann gut zu tun
> hat.

Minutentakt gefällt mir besser, aber das muss doch auch gehen wenn ich 
nicht jede Minute das Script per cron starte...


> Und ja, logfiles kann ich immer gebrauchen zumal Du den HT4i-Heizungsbus
> eingebaut hast.

Okay, dann werde ich demnächst mal welche aufzeichnen wenn die Sonne 
scheint und der Solarregler was zu tun hat. Heute morgen wollte das 
nicht so ganz klappen; hab' den ht3_logger gestoppt und "cat 
/dev/ttyAMA0" ausprobiert, ist aber nix passiert. Auch mit einem ">> 
/tmp/log.hex" dahinter entstand nur eine 0kB-Datei...


Lasse

[Norbert S. (junky-zs)]

Hallo Lasse,

> Zumal die Daten in der rrd-Datenbank ja unabhängig vom cron sein müssten,
> d.h. wenn ich das Script manuell aufrufe, sollten die Schritte im
> Minutentakt auftreten?
Das script holt sich die Daten aus der rrdtool-db. Wenn also keine Daten 
innerhalb eines Intervalls vorhanden sind (warum auch immer) wirst Du 
dort auch nur den Default-Wert (meistens 0) aus der rrdtool-db erhalten.
Da hilft auch der X-malige script-Aufruf nichts.
Das Script ist auch manuell ausführbar und Du kannst es ausprobieren.

Logfiles aufzeichnen ist recht einfach wenn der ht_proxy.server läuft:

  ~/HT3/sw/ht_binlogclient.py <meinlogfilename.log>

Das Logfile ist dann im Verzeichnis: ~/HT3/sw/var/log zu finden.

Dieser Logclient nutzt die IP-Adresse aus dem ht_proxy_cfg.xml 
Konfigurationsfile 'localhost'.
Falls der ht_proxy.server auf einer anderen Hardware läuft ist dies 
entsprechend anzupassen.

Gruß Norbert

[Lasse B. (preamp)]

Alles klar, danke. Ich werde dann mal mitloggen wenn ich den proxy am 
laufen habe :o).


Eine Idee ist mir gestern noch durch den Kopf gegangen: Wo müsste ich 
ansetzen, wenn ich sämtliche Daten in nur einer einzigen rrd-Datenbank 
haben will? Dann könnte ich die darzustellenden Werte frei kombinieren 
und mit mehreren draw-Scripts entsprechende PNGs erzeugen...

Lasse

[Lasse B. (preamp)]

Anbei schonmal ein kurzes Logfile aus der Mittagspause. Solarpumpe ist 
aktiv, Kollektortemperatur ca. 55-60°C, Speicher unten ca. 50°C. 
Solarregler MS 100, Wahlschalter am Regler auf "1", Pumpe PWM-gesteuert; 
ansonsten ein Heizkreis am Kessel ohne externen Mischer.

Die Testsoftware läuft soweit, auch mit Proxy, zeigt aber leider immer 
noch keinerlei Solardaten an (im Graph steht 'nan', also keine Werte in 
der DB).

Ich logge heute den Nachmittag mit; in 2 Stunden sollte die Solarpumpe 
ausgehen, dann hast du nochmal einen Wert mehr :).

[Norbert S. (junky-zs)]

Hallo Lasse,

habe Dein logfile mal durch den Analyser gejagt. Resultat siehe Bild.
Es werden u.A. Solarwerte im Analyser angezeigt.
Was mir nicht gefällt ist der angezeigte CauseCode:203.
Kontrolliere mal am Regler CW400 ob dort Fehler angezeigt werden oder in 
der Historie vorhanden sind. Das Handbuch sollte Details dazu hergeben.

Denke bitte daran das Deine Testsoftware ein erweitertes 
Konfigurationsfile hat und Du die Datenbank damit NEU anlegen musst.
Auch muss der cronjob jetzt die rrdtool-db Daten aus dem 
Test-Verzeichnis nehmen und daraus die Grafen erzeugen!

> Wo müsste ich ansetzen, wenn ich sämtliche Daten in nur einer einzigen
> rrd-Datenbank haben will?
Das wäre eine grundlegende Anpassung der Software, da die interne 
Struktur darauf ausgelegt ist mehrere rrdtool-dbs zu nutzen(jeder 
Systempart eine).
Grund ist hauptsächlich die Grösse der rrdtool-db. Die habe ich für eine 
Datenhaltung von 10 Jahren ausgelegt bevor alte Daten überschrieben 
werden.
Wenn alles in einer Datenbank ist wird die einfach zu riesig und nicht 
mehr effektiv für den Raspberry.

Gruß Norbert

[Lasse B. (preamp)]

Moin auch,

das sieht ja schonmal gut aus. Den Analyser hab ich gar nicht 
ausprobiert, weil der mit der aktuellen Software auch keinerlei 
Solardaten angezeigt hat.

Ich habe die alten Datenbanken komplett eingestampft und deine 
Testversion als einzige Software komplett neu nach Anleitung 
installiert. Beim durchgehen der Logfiles ist mir allerdings 
aufgefallen, dass da teilweise einzelne Bytes zu fehlen scheinen... Wenn 
dein Analyser aber gute Werte anzeigen kann, muss der Fehler ja in 
meiner Softwarekonfiguration liegen?

Welche Telegramme hat die Solargeschichte vom MS100? Irgendwas in dieser 
Richtung?

B0 00 FF 00 02 62
         02    63
         09    64
         18    66
               68

B0 00 00
B0 00 09

Wobei B0 00 FF 02 02 64, B0 00 FF 09 02 64 und B0 00 FF 00 02 62 am 
ehesten nach was interessantem aussehen, bei mir allerdings ab und an 
mal etwas in der Länge variieren.



Ja, in der Historie sind noch die ersten Fehler von der Installation 
vorhanden. Die wollte ich noch drin lassen bis der Junkers Service da 
war, weil der Heizungsbauer die nur mit einem Achselzucken quittiert 
hat.


Das mit der Datenbankgröße klingt einleuchtend. Alternativ könnte man ja 
'die eine' Datenbank auf 1 Jahr begrenzen und für jedes Jahr ein Backup 
anlegen? Egal, erstmal muss die Software bei mir überhaupt richtig 
laufen :).

Lasse

[Lasse B. (preamp)]

So, hab' noch mal eben schnell den Analyser ausprobiert. Der zeigt 
tatsächlich die Solarwerte an, wobei mir der Ertrag der letzten Stunde 
mit über 11kW etwas zu viel erscheint ;).

Jedenfalls sind die Grafiken für den Solarbereich immer noch leer und 
alle anderen Werte sind immer noch nur im 5-Minuten-Raster. Wie kann ich 
am einfachsten überprüfen ob die SQL-Daten regelmäßig und korrekt in der 
RRD-Datenbank ankommen?

[Lasse B. (preamp)]

Okay, jetzt bin ich verwirrt.
Habe mit ls -l die Datenbanken beobachtet: Die für Heizung und 
Warmwasser werden jede Minute aktualisiert, sysdate-irgendwas ist seit 
der Installation gestern unberührt und die Solar-DB wird nur jede Stunde 
aktualisiert, immer um 2 Minuten nach Voll. Und dann der Knaller: Um 
nochmal nach dem 5er-Intervall zu gucken habe ich das Script unter 
/usr/local/bin auf 60 Minuten (statt 2 Stunden) eingestellt. Jetzt war 
es so, dass beim Aufruf vom cron die Auflösung tatsächlich bei einer 
Minute lag, aber wenn ich das Script manuell starte (im Ordner 
/usr/local/bin mit ./rrdtool_draw.pl [...]), sind wieder nur 5m-Schritte 
zu sehen! Wie kann das denn angehen?

[Norbert S. (junky-zs)]

Hallo Lasse,

kontrolliere noch einmal den cronjob, da ist sicher der Fehler zu 
suchen.
Hier noch einmal ein Beispiel mit einem absoluten Pfad auf das Script 
(Achtung: Anzahl der '*' wichtig, siehe Beispiele im cronjob und doku !)
*/2 **** pi /usr/bin/perl /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi/ 
/home/pi/ 1

Die drei script-Parameter geben an:
1. Pfad aus dem die Daten kommen (rrdtool-datenbank).
2. Pfad wohin die PNG-Files geschrieben werden.
3. Anzahl der Heizkreise

Bei der Pfad-Angabe (2.) ist zu beachten das diese PNG-Files vom 
'httpd'-daemon auch in seinem Verzeichnis gefunden werden.
In dem Beispiel wird die Pfadangabe im Script ergänzt zu:
  /home/pi/ + ./HT3/sw/etc/html

Der 'httpd'-daemon läuft im Verzeichnis: /home/pi/HT3/sw/etc/html und 
dort müssen auch die PNG-Files stehen und aktualisiert werden.
Dies wird durch die Default-Configuration in den Scripten erreicht.
Bei Änderungen in den Pfaden müssen die Scripte angepasst werden.

Offensichtlich siehst Du Dir mit dem Browser immer alte, nicht 
aktualisierte PNG-Files an.

> sysdate-irgendwas ist seit der Installation gestern unberührt
Richtig, die System-Zeitinformation wird nicht in die DB geschrieben, 
alle Einträge erhalten ja ohnehin Timestamps.

Gruß Norbert

[Lasse B. (preamp)]

Hallo Norbert,

vielen Dank für deine Geduld :). Ich habe den cron-Eintrag jetzt auch 
nochmal mit absoluten Pfadangaben gemacht, die Anzahl der Sterne stimmte 
auch vorher schon. Habe auch mithilfe von find sichergestellt dass ich 
nur ein draw-Script habe und auch nur im richtigen Verzeichnis die PNGs 
geschrieben werden. Das stimmt alles soweit, da läuft nix doppelt oder 
im falschen Ordner.
Habe dann das draw-Script testweise so angepasst, dass nur die erste 
Grafik für 60 Minuten erstellt wird und alle anderen normal für 2 Tage. 
Dann noch den cron-Eintrag auf 1 Minute geändert und mir die Grafiken 
auf einem anderen Rechner per httpd im Firefox angesehen. Da habe ich 
dann für eine halbe Stunde jede Minute die erste Grafik per Speichern 
unter... gesichert.
Dabei sind 9 Grafiken mit 1min Auflösung, allerdings in recht 
unregelmäßigen Abständen. 5 Grafiken zeigen stattdessen sogar nur eine 
gerade Linie - entweder werden die Daten da anders gerundet (?) oder 
tatsächlich 30 Werte zu einem zusammengequetscht. Die übrigen Grafiken 
liegen bei 5min, allerdings sehen auch diese nicht so aus wie ich 
erwartet hätte.

Die Solargrafik war bis auf wenige Ausnahmen immer leer. Vier mal waren 
jedoch zwei kleine Spikes zu sehen, die möglicherweise zu dem geringen 
aktualisierungsintervall der entsprechenden rrd-Datenbank passen.
Den Test habe ich ab 19:33 gemacht, letzter Zugriff auf die 
Solardatenbank war 19:01, bis ca. halb 9 kam auch kein Weiterer dazu.

Irgendwas ist da doch faul... Ich habe mit einem brandneuen Jessie-Image 
auf einer neuen SD-Karte angefangen, der Raspi wird ansonsten für nix 
anderes gebraucht. Vielleicht versuche ich es nochmal mit einem 
Wheezy-Image. Problem ist nur dass ich zuhause noch auf meinen 
Internetanschluss warte :(.

[Lasse B. (preamp)]

Habe jetzt nochmal mit einem Wheezy-Image von vorne angefangen. Die 
Grafiken bisher zeigten alle eine einminütige Auflösung, was schonmal 
besser aussieht als vorher. Allerdings werden immer noch keine 
Solardaten aufgezeichnet und die Solar-Datenbank wird höchstens 1x pro 
Stunde aktualisiert.
Beim Durchstöbern des Quellcodes ist mir aufgefallen, dass in der Datei 
'ht3_decode.py' gar kein Abschnitt á là "if buffer[4] == 2 and buffer[5] 
== 0x62:" vorkommt, was die fehlenden Grafiken begründen könnte. Die im 
Analyser angezeigten Telegramme fangen nämlich mit B0 00 FF 00 02 62 an. 
Dort werden sie ja auch mit den korrekten Temperaturen angezeigt. In der 
Datei 'ht_discode.py' kommt dieser Abschnitt vor und bedient scheinbar 
den Analyser, nicht jedoch den Logger...

[Norbert S. (junky-zs)]

Hallo Lasse,

die Module HT3_decoder.py und HT3_dispatcher.py sind in Deiner 
Testsoftware zwar noch enthalten, werden aber komplett ersetzt durch das 
Modul: ht_discoder.py
Hinweis:
 Beim nächsten Release werden diese alten Module auch entfallen.

> Allerdings werden immer noch keine Solardaten aufgezeichnet und die
> Solar-Datenbank wird höchstens 1x pro Stunde aktualisiert.
Habe die Testsoftware angepasst und Dir per E-Mail zugesendet.
Mit Deinem Logfile als binärer Input wird jetzt auch der Solaranteil in 
der Grafik angezeigt.

> Welche Telegramme hat die Solargeschichte vom MS100? Irgendwas in dieser
> Richtung?
> B0 00 FF 00 02 62
>          02    63
>          09    64
>          18    66
>                68
Ja korrekt, ist aber noch nicht alles dekodiert.
Wie war das noch mit dem Eichhörnchen? (mühsam!)

Gruß Norbert

[Lasse B. (preamp)]

> die Module HT3_decoder.py und HT3_dispatcher.py sind in Deiner
> Testsoftware zwar noch enthalten, werden aber komplett ersetzt durch das
> Modul: ht_discoder.py

Das habe ich gestern abend rausgefunden ;). Bin letztlich mit dem Logger 
angefangen und habe den Weg zurückverfolgt, soweit dass die 
Kollektortemperatur jetzt korrekt ins Logfile geschrieben wird. Wenn man 
am Tag nur ca. eine Stunde Zeit dafür hat ist es in der Tat mühsam...


> Habe die Testsoftware angepasst und Dir per E-Mail zugesendet.

Vielen Dank! Werde ich nachher mal testen.


> Ja korrekt, ist aber noch nicht alles dekodiert.
> Wie war das noch mit dem Eichhörnchen? (mühsam!)

Spätestens im Herbst, wenn ich nicht mehr so viel im Garten machen muss, 
helfe ich dir gerne dabei. Wenn ich am Wochenende mal ein paar Stunden 
habe natürlich auch, aber der WAF ist beim Reverse Engineering nicht 
besonders groß... Ich habe ansonsten auch ein Gästezimmer, falls du 
selber mal ein paar Daten loggen möchtest ;D!

Gruß,
Lasse

[Lasse B. (preamp)]

Die Solarerfassung funktioniert jetzt weitestgehend, vielen Dank 
nochmal!

Bei den Ertragsdaten musste ich ein bisschen nachhelfen, weil die Werte 
um eine Zehnerpotenz zu hoch waren.

Ein Problem habe ich allerdings weiterhin. Das Telegramm für die 
Solarpumpenlaufzeit fängt an mit B0 10 FF 00 02 91. Das Problem ist die 
10. Die wird nämlich vom discoder nicht erkannt. Der Proxy kann alles 
problemlos vom UART lesen, sonst hätte ich das Telegramm ja nicht 
vollständig im Logfile. Im discoder jedoch taucht die 10 nicht auf. Ich 
habe direkt nach der firstbyte-Erkennung "buffer[0]==0xb0" den buffer[1] 
ins logfile schreiben lassen (mit der Bedingung :=0) und dort 
überwiegend die 8 wiedergefunden, aber keine einzige 16 alias 0x10.
Das Telegramm mit B0 08 35 kommt regelmäßig alle 2 Minuten und alle 
14-16 Minuten (also immer nach 7 bzw. 8 Telegrammen) kommen dann drei B0 
10 FF Telegramme. Im Logfile ist das sehr gut zu sehen, aber nicht im 
discoder.
Als letzten Versuch habe ich bei __read() die Ausgabe von 
self.port.read() in eine Variable gepackt und zusätzlich mit ord() ins 
Logfile schreiben lassen. Dabei sind definitiv mehrere 16er pro Sekunde 
zu Stande gekommen. Allerdings habe ich das nicht über einen Zeitraum 
von 16 Minuten gemacht um zu sehen ob auch ein vollständiges Telegramm 
dabei rauskommt.

Ideen? :)

Gruss, Lasse

[Norbert S. (junky-zs)]

Hallo Lasse,

> Bei den Ertragsdaten musste ich ein bisschen nachhelfen, weil die Werte
> um eine Zehnerpotenz zu hoch waren.
Ok, bring ich mit in das nächste Release ein. Danke für die Info!

> Das Telegramm für die Solarpumpenlaufzeit fängt an mit B0 10 FF 00 02 91.
> Das Problem ist die 10. Die wird nämlich vom discoder nicht erkannt.
Das stimmt, es werden in der Software z.Zeit nur Telegramme:
   <An Alle>:=0 ausgewertet.
Das Byte1 (von Null an gezählt) ist dabei dann 00.
z.B.: B0 00 FF 00 02 91 würde erkannt werden können wenn es denn im 
Dispatcher/Dedocder enthalten wäre.
Da Dispatcher und Dekoder nicht mehr zu den neuen Telegrammen passen und 
eine Erweiterung in der alten Form grottig wird habe ich mich 
entschlossen den kompletten Dispatcher und Dekoder (discoder) neu zu 
schreiben.
Dies ist jedoch noch gar nicht in Deiner Testsoftware enthalten.
Hinweis:
Junkers behandelt die Telegramme anders. Jedes Telegramm hat eine 
eindeutige Kennung die im neuen 'discoder.py' ausgewertet werden wird.
Dazu ist es allerdings nötig die ersten 6 bis 7 Byte eines Telegramms 
auszuwerten.
Dein Beispiel liest sich also so:
B0 10 FF 00 02 91
B0                  -> Source:(30 + 80)hex Solar
   10               -> Target:(10)hex Hier Dein Regler angesprochen
      FF            -> EMS - typed Message (MSG-Erweiterung)
         00         -> Message-Offset
            02 91   -> MessageID := (2+1)*256 + 145d := 913 dezimal

Mit diesem Telegramm sendet das Solarmodul ein Telegramm 913 an den 
Regler des Heizungssystems.

In Zukunft wird der Dispatcher die MessageID verwenden und ist dann 
unabhängig von Target- und Source-Bytes.
Allerdings ist dies noch in Arbeit und sobald eine brauchbare Version 
vorhanden ist bist Du der Erste der diese zum Testen erhält!

Schau auch mal auf die EMS-Infos der Buderus-Liga (auch hier im Forum).
URL:
 http://emswiki.thefischer.net/doku.php
Viele Details sind ähnlich oder auch gleich. Klar beides Bosch.
Trotz allem gibt es Unterschiede die eben die Dekodierung anders machen.

Gruß Norbert

[Lasse B. (preamp)]

Höchst interessant! Dann warte ich mal dein nächstes Release ab und 
schaue mir gelegentlich das Wiki an :).


Hier nochmal ein paar Solartelegramme die ich ausfindig machen konnte.

B0 00 FF 00 02 8E *20: [6]-[9] Ertrag letzte Stunde *10 (also durch 10 
teilen für Wattstunden), [10]-[13] Ertrag Tag in Wattstunden, [14]-[17] 
Ertrag gesamt *10 (/10 = kWh, *100 = Wh)
B0 00 FF 02 02 64 *19: [13] Solarpumpenleistung in %, [14]*255 
entspricht grob dem Ertrag der letzten Stunde ([15] variiert, ist auch 
schon >0 wenn noch kein Ertrag vorhanden ist), [7] Nachts 0, Tagsüber 4 
=> Kollektortemperatur OK?
B0 00 FF 02 02 6A *17: [14] 03=Solarpumpe aus, 04=Solarpumpe an
B0 00 FF 03 02 64 *9: [6] Nachts 0, Tagsüber 4 => Kollektortemperatur 
OK?
B0 00 FF 09 02 64 *9: [6] Solarpumpenleistung in %
B0 00 FF 0A 02 6A *9: [6] 03=Solarpumpe aus, 04=Solarpumpe an

B0 10 FF 00 02 8A *32: Ertrag der aktuellen Woche. [6]-[9] Gestern oder 
Samstag, [10]-[13] Vorgestern oder Freitag, usw. Hab die Daten an einem 
Sonntag gesammelt...
B0 10 FF 18 02 8A *32: Ertrag der letzten Woche. [6]-[9] Sonntag, 
[10]-[13] Samstag, usw.
B0 10 FF 00 02 91 *32: [6]-[9] Solarpumpenlaufzeit in Minuten


Gruß, Lasse

[Norbert S. (junky-zs)]

Hallo,

@Alle
die Software zum Projekt ist auf github.com aktualisiert zu Rev.: 0.2.1
Da die Decodierung sich mit diesem Release grundlegend geändert hat 
kann ich nur empfehlen das ganze Projekt zu aktualisieren.
Komplett wie gehabt mit:
 git clone https://github.com/norberts1/hometop_HT3.git

Auf der Web-Seite wird im README.md im Detail angegeben was sich 
geändert hat, deshalb will ich dies hier nicht wiederholen.
Grundlegend ist die Dekodierung jetzt umgestellt auf MessageIDs und 
das Handling der Cxyz - Regler ist hinzugekommen.
Danke an alle die in irgend einer Weise dazu beigetragen haben!

Noch eine wichtige Bemerkung zu den Datenbanken:
1. Die sqlite-datenbank unbedingt neu anlegen da neue Logitems 
dazugekommen sind.
2. Falls die Daten der rrdtool-datenbank weiter genutzt werden sollen so 
ist ein upgrade erforderlich.
Dies ist ebenfalls im Release enthalten unter:
 ~HT3/sw/etc/upgrade_rrdtool_db

Dort unbedingt das darin enthaltene 'readme'-file lesen, es sind perl 
CPAN-Module zu installieren die von Haus aus nicht vorhanden sind.
Allerdings muss man sehr viel Speicherplatz frei haben (>1GB in /tmp) 
damit dieses upgrade der rrdtool-datenbank auch fehlerfrei durchläuft.
Auf meiner virtuellen Maschine ist dieses upgrade durchgelaufen, 
allerdings auf meinem RaspberryPi B aus Platzmangel nicht.
Falls ähnliche Probleme auftreten bleibt leider eine Neugenerierung der 
rrdtool-datenbank nicht erspart (./create_databases.py).

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

vielen Dank für die viele Arbeit!!!

Habe es bei mir gleich ausprobiert, da ich ja nur die Dateien 
austauschen musste (DB war ja schon neu erstellt).

Eine kleine Frage: Was für eine Load sollte ein Raspi 1 B haben, wenn 
nur diese Software läuft? Aktuell habe ich rund 1,5 dauerhaft.

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

> Was für eine Load sollte ein Raspi 1 B haben, wenn nur diese Software
> läuft? Aktuell habe ich rund 1,5 dauerhaft.
Der Durchschnitt sollte unter 10% für ht_proxy und HT3_logger sein. 
Diese Zahlen sind aber stark abhängig von äusseren Faktoren wie: Anzahl 
der Heizkreise, Art des Adapters, Anzahl der ht_clients am 
ht_proxy.server und Heizungs-Regler im System.
Insbesondere die neuen Regler der Cxyz-Serie machen einen grösseren 
Traffic auf dem Heizungsbus.
Deshalb kann ich Dir da auch nur Hausnummern und keine feste Werte 
angeben.
Siehe Bild, wie es bei mir als Schnappschuss aussieht.
Deine 1,5% sind da ja recht wenig und Dein RaspberryPi langweilt sich 
:-)

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:

> Deine 1,5% sind da ja recht wenig und Dein RaspberryPi langweilt sich

Hallo Norbert,

leider reden wir nicht über % CPU sondern über die Linux Load. Und die 
sollte bei einem Single-Core wie dem Raspi 1 B eigentlich nicht 
dauerhaft über 1 (=100 % CPU) sein.
Bei mir ist es aber im meist zwischen 1,5 und 2. Schau mal auf die 
Bilder erste Zeile oben.

Der Proxy und der Logger selbst sind unauffällig, aber manchmal sehe ich 
"perl" oder "rrdtool_draw.pl" für bis zu 20s oben in der Top-Liste 
stehen mit jeweils 60-70% CPU. Von hier kommt meine im Schnitt zu hohe 
Load, besonders weil diese temporäre Last so lange dauert.
Siehe die 3 Bilder.

Mal zu den Eckdaten. Ich habe nur 1 Heizkreis, kein Solar. Regler ist 
der CW400. Aus der rrdtool_draw.pl habe ich Solar und HK2-4 gelöscht. 
Auf dem Raspi 1 B läuft nur HT3 mit einem Tiny-Adapter, RPI-Monitor und 
phpliteAdmin.
Die SQlite-DB habe ich aktuell auf 13MB, da ich alle Werte älter als 2 
Tage schon immer lösche. Es greift ausser mit http niemand zu, auch kein 
FHEM oder externer Logger.

Danke und Gruß,
Stephan

[Stephan T. (stephant)]

Hallo Norbert,

noch etwas: Das neue Autocreate! Ich habe ja meine rrdtool_draw etwas 
angepasst, da ich manche Sachen weglasse, die Grafiken etwas breiter 
mache und auch noch andere Zeiträume sehen will.
Und heute such ich mir nen Wolf, warum meine Bilder mal halbe 
Seitenbreite und mal ganze Seitenbreite haben und warum rrdtool_draw 
eigentlich so oft ausgeführt wird, obwohl laut cron nur alle 5 Minuten.

Anscheinend rufst Du das jetzt aus dem Worker auf? Damit müsste dann 
doch auch der Cron-Eintrag wegfallen, denn der zeigt ja auf eine ganz 
andere Datei...

[Norbert S. (junky-zs)]

Hallo Stephan,

> Anscheinend rufst Du das jetzt aus dem Worker auf? Damit müsste dann
> doch auch der Cron-Eintrag wegfallen, denn der zeigt ja auf eine ganz
> andere Datei...
Ja und Ja! Die durchgeführten Änderungen habe ich ja im Readme.md auf 
github.com beschrieben!
Also: Aufruf des scripts: 'rrdtool_draw.pl' im cronjob deaktivieren oder 
das Autocreate-Draw im Konfigurations-File abschalten mit:
 ...
      <autocreate_draw>off</autocreate_draw>

Dies würde auch ein wenig die hohe Last bei Deinem RaspberryPi erklären 
da ja von zwei Stellen das Perl-script aufgerufen wird.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

in der Readme steht nur was drin mit dem autocreate. Dass man nun 
allerdings den cronjob löschen muss ist nicht klar ersichtlich, zumal er 
in der PDF Doku immer noch drin ist.

Wie lange dauert bei dir das Ausführen von rrdtool_draw? Bei mir 6-7 
Sekunden.

Gruß Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

>Wie lange dauert bei dir das Ausführen von rrdtool_draw?
Ja, auch so 7-8 Sekunden.

> ..., zumal er in der PDF Doku immer noch drin ist.
Ja ich weiss, ich bin in Lieferverzug :-(
Aber es kommt ja ein Wochenende, und da mach ich blau! und vielleicht 
auch noch die Doku.

Gruß Norbert

[Mario R. (upd8r)]

Moin zusammen,

mein ISM1 zeigt mir heute an, dass die Solarpumpe bisher nur 9.5h 
gelaufen ist. In mehr als 5 Jahren. Nicht schlecht. da hat wohl jemand 
heimlich eine neue eingebaut :-)

Hatte das vielleicht schon mal jemand?

BG
Mario

[Norbert S. (junky-zs)]

Hallo Mario,

> mein ISM1 zeigt mir heute an, dass die Solarpumpe bisher nur 9.5h
> gelaufen ist. In mehr als 5 Jahren.
Dieses Verhalten hatte ich mit meinem Regler FW100/ISM1 ebenfalls 
beobachten können. Den zu geringen Wert hatte ich am 'HT3_Analyser' 
abgelesen und im  FW100 bestätigt gefunden.

Für dieses merkwürdige Verhalten kenne ich zwei Gründe:
1. Die Heizung war mehr als 6 Stunden ausgeschaltet (stromlos). Der 
Regler FWxyz vergisst die dann bis dato erfassten Daten, da dieser keine 
Batterie sondern 'nur' einen 'Super-Cap' enthält.
Dies gilt dann auch für das Solar-Regelverhalten, Zählerstände usw.

2. Das Telegramm: MsgID-259 enthält zwar 3Byte für die Pumpenlaufzeit 
(Byte 16,17,18), es werden jedoch offensichtlich nur 2Byte (Byte17,18) 
im Regler ausgewertet (siehe Bild).
Somit kommt es beim Wert 65535 := ca. 1093 Stunden zu einem Überlauf 
ohne einen Übertrag in Byte 16 durchzuführen.
Der Zähler fängt somit wieder bei 0 an.

Bei Dir kommt sicher Fall2 in Frage, da Du die Heizung bzw. Solar sicher 
nicht abgeschaltet hast.
Vergleiche mal das Telegramm:MsgID259 im HT3_Analyser mit dem im Bild 
dargestellten. Der erneute Zähler-Überlauf wird bei Deiner Heizung aber 
sicher erst im nächsten Jahr erfolgen.
Hinweis: Diesen Überlauf habe ich schon mindestens zweimal beobachten 
können.

Gruß Norbert

[Mario R. (upd8r)]

Hallo Norbert,

sorry für die späte Antwort aber ich habe jetzt bei mir doch nochmal 
geschaut und augenscheinlich werden bei mir alle 3 Bytes ausgewertet.

Der Wert ist bei mir momentan 02 09 7c, was umgerechnet 2.225h 
entspricht. Dieser Wert steht auch in meinem FW200 aber eben nicht in 
den vom rrdtool erzeugten Bildchen oder im Rest der SW (Analyser, 
Systemstatus).

Also doch ein Bug in der SW? duckundwech

Danke + Gruß,
Mario

[Norbert S. (junky-zs)]

Hallo Mario,

> Also doch ein Bug in der SW?
Ja, es werden z.Z. nur 2Byte ausgewertet.
Die Anpassung ist jedoch einfach und die kannst Du auch selber 
durchführen.
Modul: ht_discode.py  (aktuelles Release 0.2.1)
 Funktion: msgID_259_Solar()
 Zeilen: 2047 ff
 Änderungen:
if raw_index == 16 and msg_bytecount >= 3:
  i_laufzeit_minuten = int(buffer[buffer_index] * 65536 +
     buffer[buffer_index + 1] * 256 + buffer[buffer_index + 2])
(Auf korrektes Einrücken achten)

Wenn dies bei Dir funkt kommt es in das nächste Release.

Gruß Norbert

[Mario R. (upd8r)]

Hi Norbert,

erstmal danke für die Rückmeldung und den Code, ich habe die Änderung 
eingebracht (Zeilennummer in meinem vi war allerdings anders).
Also jetzt werden 3 Bytes ausgewertet aber es wird merkwürdig, der 
Hex-Wert ist momentan 020940, also umgerechnet 2224 Stunden. Das zeigt 
auch der/die FW200 an: 1h weniger als gestern um die Uhrzeit?

Aber auf jeden Fall realistischer als als vorher und zumindest mit der 
Anzeige an der Heizung konsistent :)

Danke!

[Mario R. (upd8r)]

Irgendwas passt im rrdtool noch nicht, also der Analyser hat 2224h 
angezeigt.

Die Angabe der Laufzeit im Bild "Solar Ertrag" schwankt, momentan zeigt 
er 731.2 Stunden an.

[Norbert S. (junky-zs)]

Hallo Mario,

bitte erzeuge ein binäres Logfile Deiner Anlage.
Laufzeit ca. 1 bis 2 Stunden. Wird wohl nicht mehr so viel Sonne 
dabeisein aber ein paar Daten werden schon kommen.
Mit dem Logfile kann ich nachvollziehen was dort passiert.

Gruß Norbert

[Mario R. (upd8r)]

Moin Norbert,

ich will Dir ja nun nicht mehr Arbeit machen als unbedingt notwendig ;-)
Um sicher zu gehen, dass sich jetzt nichts verbogen hat, habe ich 
gestern vor dem Schlafengehen mal alle DBs neu angelegt und heute morgen 
sieht's gut aus: 2224h auch per rrdtool.

Ich lasse es jetzt erstmal s und beobachte weiter. Danke für Deinen 
Support!

[Mario R. (upd8r)]

Hi Norbert,

kannst Du mir mal bitte verraten, wie ich am besten HEX bzw binär 
mitloggen kann?
Meine rrdtool-Grafiken haben Spikes bei der WW-Soll-Temperatur, jetzt 
habe ich mal in die DB geschaut und ja, da tauchen so alle 2 Minuten 
komische Werte auf, mal 56, mal 60 Grad o.ä.
Soll ist momentan auf 50 Grad eingestellt.

Im Analyser sehe ich rechts auch immer mal eine andere Soll-Temperatur, 
nur werde ich aus den Telegrammen nicht so schlau. In 88 00 34 00 steht 
in Byte 4 eine 32h, das passt.
Der Temperatur-Wert scheint sich immer dann zu ändern, wenn im Anschluss 
an das obige Telegramm noch das Telegramm 90 08 35 01 kommt, das im 
Analyser auch mit WW gekennzeichnet ist. Aber darüber kann ich in der 
Info nichts finden. Aber ich kann mich auch täuschen.

Danke und sorry für die ganzen Nachfragen.

[Norbert S. (junky-zs)]

Hallo Mario,

> kannst Du mir mal bitte verraten, wie ich am besten HEX bzw binär
> mitloggen kann?
Wenn Du den ht_proxy.server im/am Rennen hast ist dies ganz einfach:

  ht_binlogclient.py <logfilename deiner wahl.log>

Dies zeichnet die ht_busdaten in ein Binär-File auf (unter: 
~/sw/var/log) und nutzt die URL: 'localhost'.
Falls Dein ht_proxy.server auf einem anderen Rechner läuft ist die 
'serveraddress' des 'proxy_client' im Konfigurationsfile: 
ht_proxy_cfg.xml entsprechend anzupassen.

> Der Temperatur-Wert scheint sich immer dann zu ändern, wenn im Anschluss
> an das obige Telegramm noch das Telegramm 90 08 35 01 kommt
Im aktuellen Release wird Byte7 als 'Sollwert für Warmwassertemperatur' 
genommen. Dies ist aber auch schon im Telegramm: 88 00 34 00 enthalten.
Warum diese Werte sich unterscheiden obwohl diese zumindest namentlich 
gleich sind weiss ich nicht.
Deshalb die Dekodierung für Telegramm: 90 08 35 01 deaktivieren wie 
folgt:
Modul: ~/sw/lib/ht_discode.py
Fkt: msgID_53_DomesticHotWater()
Zeile 1547 deaktivieren:
#    self.__gdata.update(nickname, "Tsoll", self.__Check.....

> Aber darüber kann ich in der Info nichts finden. Aber ich kann mich
> auch täuschen.
Nein, Du täuscht Dich nicht. Die Doku hinkt der SW weit hinterher und 
ist immer noch eine offene Baustelle.

> Danke und sorry für die ganzen Nachfragen.
Ist genau richtig, nur so kommt man weiter. Gut für alle.

Gruß Norbert

[Mario R. (upd8r)]

Danke, ich habe das jetzt auskommentiert und schaue mal.

Schönes Rest-WoE!

[Stephan T. (stephant)]

Hallo Norbert,

da in Kürze die Heizungssaison wieder beginnen wird: Hast Du schon 
geplant, die aktuellen Möglichkeiten zur Steuerung der CW-Reihe auch in 
das FHEM-Modul zu integrieren?

Ich habe bereits eine recht brauchbare Anwesenheitssimulation 
(WLAN-MAC's der Handy's von der Fritzbox abfragen) am Laufen und würde 
somit gern die Temp runterfahren, wenn keiner mehr da ist. Und bislang 
ist die Temp ja das einzigste, was man bei den CW wirklich steuern kann.

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

> Hast Du schon geplant, die aktuellen Möglichkeiten zur Steuerung der
> CW-Reihe auch in das FHEM-Modul zu integrieren?
Ja geplant schon, jedoch bin ich noch dabei die anderen Baustellen 
(Doku...) zu bearbeiten.
Auch muss das FHEM-Modul insgesamt überarbeitet werden damit die neuen 
Telegramme (Cxyz - Regler) dekodiert werden. Ebenso werden die 
Telegramme der Lastschaltmodule (IPM) noch nicht behandelt.
Somit kommt auch weiterhin keine Langeweile auf :-)

Gruß Norbert

[Mario R. (upd8r)]

Hallo zusammen,

ich möchte Norbert hier mal einen sehr großen Dank aussprechen, der 
ständige Support und vor allen Dingen das ganze Projekt an sich sind 
einfach großartig.

Um der Community mal etwas zurückzugeben und um mich selbst ein bissel 
unter Druck zu setzen: Ich habe begonnen, an einer HighCharts-Umsetzung 
der Visualisierung von HT3 zu arbeiten, eigentlich nur deswegen, weil 
ich kein Freund der statischen rrdtool-Grafiken bin.
Jetzt muss ich allerdings sagen, dass ich weder Javascript noch PHP 
spreche (ich bin kein Programmierer) und bei mir alles per C&P und 
Trial&Error funktioniert.

Soll heißen, es dauert. Grundlage war ein Projekt aus einem anderen 
Forum, das ich momentan an meine Bedürfnisse anpasse, u.a. von mySQL auf 
SQlite3 umstellen etc.

Also, falls Interesse besteht, kann ich das Ganze am Ende gern 
zugänglich machen - aber Achtung: Interessierter Laie am Werk. Und wenn 
ich im jetzigen Tempo weitermache, gibt es die erste Version vermutlich 
erst zu Weihnachten ;-)

Ein Warmwasser-Diagramm funktioniert aber schon (inkl. Zoom), so dass 
die Grundlagen eigentlich da sind und ich jetzt ans nächste Diagramm 
gehe.

2 Screenshots anbei.

[Stephan T. (stephant)]

Norbert S. schrieb:
> Auch muss das FHEM-Modul insgesamt überarbeitet werden damit die neuen
> Telegramme (Cxyz - Regler) dekodiert werden.

Hallo Norbert,

danke, dass Du an dem Thema weiter dran bist und uns teilhaben lässt.

Ich habe mittlerweile herausgefunden, dass man am CW400 mit TC2 die 
Voreinstellung für "Heizen" setzen kann und mit TECO die für "Sparen". 
Wenn man einfach die Temperatur setzt, dann bleibt diese bis zum 
nächsten Programmwechsel. Insofern wäre eine Angabe der "Netcom-Bytes" 
nur zum Setzen der Temperatur erstmal hilfreich, damit wenigstens die 
Heizung beim Verlassen herunterfährt.

Wenn es noch länger dauern würde, dann würd ich mir behelfen, indem mit 
PHP die ht_netclient-Befehle aufgerufen werden, denn FHEM und HT3 laufen 
nicht auf denselben Raspis.

Gesucht wird allerdings weiterhin auch noch eine Möglichkeit zur 
direkten Umschaltung zwischen "Heizen" und "Sparen" ohne mit der 
Temperatur jonglieren zu müssen. Denn dann hätte ich Hoffnung, damit 
auch Zirkulation und WW beeinflussen zu können

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo,

@Stephan
> Wenn es noch länger dauern würde, dann würd ich mir behelfen, indem mit
> PHP die ht_netclient-Befehle aufgerufen werden...
Es wird länger dauern mit einer FHEM-Modulanpassung. Dieses Jahr wird 
wohl nichts mehr draus. Für die Empfangsrichtung von Cxyz-Reglerdaten 
hast Du ja eine Testversion im Rennen jedoch für die Senderichtung ist 
da noch was zu tun.

@Mario R.
Grosses Lob an Mario, sieht klasse aus und ist auf jeden Fall mehr Wert 
als die rrdtool Drawanzeige.
Bleib dran und gib uns mehr davon. Vielleicht kann jemand Dich bei der 
Anpassung unterstützen.

Gruß Norbert

[Stephan T. (stephant)]

Hallo,

ich habe nach einigen Tagen immer wieder das Problem, dass die 
HTML-Seite nicht mehr aufrufbar ist. Der normale Apache läuft noch und 
nach einem "sudo /etc/init.d/httpd restart" ist auch die HT3-Indexseite 
wieder lesbar.
In /var/log finde ich nirgendwo eine Logdatei, die dazu irgendwas 
hilfreiches liefert.

Wo könnte ich noch gucken? Passiert ungefähr nach 6-7 Tagen und die 
Seite ist auf meinem Arbeits-PC ständig geöffnet.

Danke und Gruß,
Stephan

[Mario R. (upd8r)]

Warum nimmst Du nicht den Apache?

Also ich habe zwar keine Probleme mit dem httpd gehabt, aber da ich bei 
mir für die neuen Grafiken auch einen Web-Server installieren musste 
(hier nginx und PHP), habe ich auch den Pfad für die rrdtool-Grafiken 
angepasst.

Das geht sicherlich eleganter, aber ich habe einfach den Pfad in der 
ht3_worker.py hart auf /var/www/html umgesetzt. Müsste so ca, Zeile 285 
sein (laut vim).

285 # Draw-Path hart gesetzt
286 #        strsystemcmd = AbsPathandFilename + ' ' + Abspath2_db + ' ' + Abspath_2_draw + ' ' + str(hc_count)
287         strsystemcmd = AbsPathandFilename + ' ' + Abspath2_db + ' /var/www/html ' + str(hc_count)

Nicht vergessen, die index.html auch dorthin zu kopieren. httpd habe ich 
hier komplett gestoppt.

Nur als Anregung.

[Mario R. (upd8r)]

Mal kurz ein Update zu meiner HighCharts-Visualisierung. Das hier ist 
Stand 1.0.

Im Großen und Ganzen bin ich schon zufrieden, gibt aber noch ein paar 
ToDos.

- eindeutschen (muss nicht unbedingt Englisch sein bei mir)
- momentan kann man nur x Stunden/Tage von "jetzt" in die Vergangenheit 
schauen (siehe Menü oben), ich hätte gern einen Zeitraum zum Auswählen

Anmerkungen:
Ich habe alles umgesetzt, was für mich wichtig ist. Das ist nicht 
zwangsläufig das gleiche wie in den rrdtool-Grafiken jetzt. Der ein oder 
andere mag also was vermissen.
Es ist zwar dynamisch, aber alles über 24 Stunden kann im Browser schon 
sehr zäh werden, schließlich sind da Tausende Datenpunkte, die 
HighCharts darstellen muss und die er sich prinzipbedingt auch wirklich 
in den Speicher lädt. 7 Tage wie im Menü funktionieren technisch nach 
dem Hochsetzen von PHP-Speicherlimits und Timeouts, 10 Tage eher nicht 
mehr. Alles läuft auf einem Pi2 Model B. Getestet nur unter Chrome.

Muss mal schauen, wie ich das zum Download bereitstelle, falls Interesse 
besteht.

[Adam (Gast)]

Hallo,

sei ca. 2 Wochen durch paar Sekunden habe ich falsche Daten bei 
Heizkreis, durch paar Sekunden richtige Daten. Datenbase habe ich 
gelöscht und neu angelegt. Warmwasser und HK1 zeigt richtige Werte. Ich 
habe sogar eine Kopie von Herbst auf die SD-Karte noch mall überspielt.
Was kann da sein?

[Norbert S. (junky-zs)]

Hallo Adam,

was hat sich denn an Deinem Heizungssystem und der Datenerfassung in den 
letzten 2 Wochen geändert?
Welchen Adapter-Typ und welche Software-Version setzt Du ein und wie 
sieht Dein Heizungssystem (Heizgeräte- und Regler-Typ) aus ?

Gruß Norbert

[Adam (Gast)]

Hallo Norbi,
danke für Rückmeldung.
In letzter Zeit hat sich bei mir gar nichts geändert. Plötzlich falsche 
Daten. S. Bilder.
Miniadapter für Raspi, SW 0.2.2, Heizgerät ZSB14-3C mit neue variable 
Pumpe,
1 Heizkreis.
Grüße
Adam

[Adam (Gast)]

Hallo Norbi,
heute habe ich ganzen System und HT3 neu installiert -> gleiche Probleme 
:(
Muss was in Hardware liegen. Was meinst Du? Was soll ich prüfen?
Grüße

[Norbert S. (junky-zs)]

Hallo Adam,

eine Neuinstallation ist nicht nötig und die Hardware ist auch in 
Ordnung.
Grund ist wohl eine Fehldetektion bei der MessageID 24 und der 
Geräteadresse (10)hex -->> Regler.
Falsch ist die Sequenz:
90 00 18 00 18 ... CRC 00
Richtig ist:
88 00 18 00 27 ... CRC 00
Bei der falschen Sequenz stimmen zufällig die MsgID und die CRC und 
deshalb wird dieses Telegramm auch dekodiert.
Um das zu vermeiden mache bitte folgende Änderung im SW-Modul:
 ~/HT3/sw/lib/ht_discode.py Zeile: 2580
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 46, 47, 64, 100, 106],
Es wird damit die MessageID 24 (18)hex für Gereäteadresse:(10)hex in die 
Blacklist übernommen und dieses falsche Telegramm unterdrückt.
Probiere es aus und gib Bescheid ob es funktioniert.

Wenn Du Zeit hast kannst Du auch noch ein binäres Logfile (<1Std.) 
erzeugen und hier im Forum reinstellen oder mir an meine PM senden. Dann 
kann ich dieses Fehlverhalten bei mir analysieren.

Hinweis:
 Diese SW-Anpassung ist 'nur' für passive HT-Adapter nötig (Mini-/ 
Micro-Adapter)
 Für die ht_pitiny und ht_piduino-Adapter ist dies nicht erforderlich da 
diese das Telegramm-Ende korrekt erkennen können.

Gruß Norbert

[Adam (Gast)]

Hallo Norbi,

in Verzweiflung habe ich Heizkessel ausgeschaltet (vom Netz getrennt) 
und wieder eingeschaltet und ... HT3 wieder funktioniert richtig !!

Geht mein Regler langsam kaputt ?

Wenn das wieder passiert, probiere Dein Vorschlag. Seit gestern klappt 
alles.

Danke für Deine Hilfe und grüße
Adam

[Philippe D. (philippe_d)]

Hallo zusammen,

danke an alle für ihren Einsatz die Heatronic-Schnittstelle zu 
analysieren!

Mit den zusammengetragenen Informationen habe ich mir einen HT3-USB 
Adapter auf Basis eines Arduino M0 Pro gebaut und verarbeite die 
Empfangsdaten mit einem Python-Skript. Gespeichert werden die Messwerte 
in einer InfluxDB-Instanz.

System: Junkers CerapurACU ZWSB 22/28-3 mit CW400-Regler

Ich habe jetzt noch ein paar HT3-Telegramme, die unbekannt sind
(die mit *):

   90 00 06 00 11 01 11 05 2D 31 03 00 10 FF 00 A7 00
** 90 08 23 00 41 64 64 C5 00
   88 00 18 00 41 02 2A 32 00 01 23 20 C0 80 00 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 E3 00
   88 00 34 00 28 00 75 01 BD 81 00 00 03 00 00 07 3D 00 03 EA 00 63 00
** 90 08 1A 00 41 64 64 7E 00
** 90 00 FF 00 01 67 00 00 BD 00
** 90 00 FF 00 02 1D 00 00 09 07 5C 00
** 90 08 35 00 11 01 A9 00
** 90 08 35 03 28 6B 00

[Philippe D. (philippe_d)]

Vorab, so nenne ich die Bestandteile eines Telegramms:

HT3 Message-Frame
-----------------

  Byte 0   Byte 1   Byte 2   Byte 3   Byte 4
+--------+--------+--------+--------+------------+-------+-------+
! Source ! Target ! MsgID  ! SubID  ! (Data ...) !  CRC  ! Break !
+--------+--------+--------+--------+------------+-------+-------+

Byte 0 bis 3 bilden den Header. Und ein Telegramm hab ich 
"entschlüsselt", mit dem Header 90 00 FF 08.
Die 2 Bytes an Position 6 und 7 bilden einen 24h-Zähler (Rückwärts)

   [Fri Jan 13 21:29:29.460 2017] 90 00 FF 08 01 A5 00 5B 45 00
   [Fri Jan 13 21:29:51.487 2017] 90 00 FF 08 01 A5 05 A0 B4 00
   [Fri Jan 13 21:30:06.603 2017] 90 00 FF 08 01 A5 00 5B 45 00
   [Fri Jan 13 21:30:21.548 2017] 90 00 FF 08 01 A5 05 A0 B4 00
** [Fri Jan 13 23:05:29.130 2017] 90 00 FF 08 01 A5 05 9B 8F 00
   [Fri Jan 13 23:10:27.200 2017] 90 00 FF 08 01 A5 05 96 82 00
   [Fri Jan 13 23:15:28.608 2017] 90 00 FF 08 01 A5 05 91 85 00
   [Fri Jan 13 23:20:26.584 2017] 90 00 FF 08 01 A5 05 8C 98 00
   [Fri Jan 13 23:25:28.024 2017] 90 00 FF 08 01 A5 05 87 93 00
   [Fri Jan 13 23:30:29.494 2017] 90 00 FF 08 01 A5 05 82 96 00
   [Fri Jan 13 23:35:27.704 2017] 90 00 FF 08 01 A5 05 7D 69 00
   [Fri Jan 13 23:40:28.925 2017] 90 00 FF 08 01 A5 05 78 6C 00
   [Fri Jan 13 23:45:26.917 2017] 90 00 FF 08 01 A5 05 73 67 00
   [Fri Jan 13 23:50:28.387 2017] 90 00 FF 08 01 A5 05 6E 7A 00
   [Fri Jan 13 23:55:29.811 2017] 90 00 FF 08 01 A5 05 69 7D 00
   [Sat Jan 14 00:00:27.787 2017] 90 00 FF 08 01 A5 05 64 70 00

Der Zähler startet bei 05A0 == 1440 Minuten.
Bei ** bedeutet 059B == 1435 Minuten ...

Die Frage ist nun welchem Zweck dieser Rückwärtszähler dienen könnte?

[Norbert S. (junky-zs)]

Hallo  Philippe,

Deine Entschlüsselung des HT-Messagesframes ist nicht ganz korrekt. Es 
gibt im Prinzip zwei bzw. drei Messageklassen:
1. Byte2 kleiner als (F0)hex
  Dann sind die ersten 4 Byte als Telegramm-Header wichtig.
2. Byte2 grösser als (F0)hex
  Dann sind die ersten 6 Byte als Telegramm-Header wichtig.
3. Request-Telegramme
  Bei diesen sind die ersten 7 Byte wichtig.
  Diese werden jedoch nur für Sonderzwecke benötigt.

Dann ergibt sich folgendes Bild:
Zu1.
 Byte0  Byte1  Byte2 Byte3   Byte 4
+------+------+-----+------+----------+---+-----+
!Source!Target!MsgID!Offset!(Data ...)!CRC!Break!
+------+------+-----+------+----------+---+-----+

Zu2.
 Byte0  Byte1  Byte2  Byte3  Byte4   Byte5  Byte6
+------+------+------+------+-------+------+----------+---+-----+
!Source!Target!Marker!Offset!ID High!ID Low!(Data ...)!CRC!Break!
+------+------+------+------+-------+------+----------+---+-----+

Zu3.
Sonderfall, hier nicht gezeigt.

Die HTML-Doku habe ich mit beigefügt. Diese ist ja ohnehin Bestandteil 
des git-Projektes.

Deine Telegramme wirst Du damit besser analysieren können.

Gruß Norbert

[Philippe D. (philippe_d)]

Hallo Norbert,

die erweiterten Telegramme mit einer 'MsgID' grösser/gleich 0xF0 sind 
mir bekannt.
Mir geht es darum, dass ich die Bezeichnung 'Offset' im Header nicht 
mag, weil sie impliziert, dass die Nutzdaten erst weiter hinten im 
Telegramm zu finden sind.
Diese 'Offset' Bezeichnung habe ich in alten Dokumenten von Buderus 
gefunden (ca. von 2001). Es ging dort aber um die 3964R Prozedur, wo 
direkt der Speicher beschrieben wurde. Da wurde der Offset benutzt, um 
anzugeben wo die Daten einzusortieren sind.

Bei meiner Heizung gibt es 2 Telegramme mit der 'MsgID' 0x35 aber 
unterschiedlicher 'SubID':

[Fri Jan 13 21:28:23.674 2017] 90 08 35 00 11 01 A9 00
[Fri Jan 13 21:28:23.690 2017] 90 08 35 03 37 74 00

Die erweiterten Telegramme werte ich noch nicht aus, da sie andere 
Längen haben als in deiner Übersicht.

Anbei noch ein Screenshot meiner Lösung mit Influx/Grafana.

Gruß
Philippe

[Philippe D. (philippe_d)]

Hallo Norbert,

In deiner Doku hast du ja die Message-IDs 677...684 - Heizkreis: 
Systemwerte...
Da dreht meine Heizung etwas am Rad (oder ist es mein Hamster, der im 
Schleudergang ist ?!?)

[Fri Jan 13 21:28:29.977 2017] 90 00 FF 0F 01 A5 01 0C 60 00
[Fri Jan 13 21:29:29.210 2017] 90 00 FF 0D 01 A5 00 5B 03 A1 F3 00
[Fri Jan 13 21:29:29.460 2017] 90 00 FF 08 01 A5 00 5B 45 00
[Fri Jan 13 21:29:30.614 2017] 90 00 FF 03 01 A5 2A 7D 00
[Fri Jan 13 21:29:30.801 2017] 90 00 FF 06 01 A5 2A 1E B4 00
[Fri Jan 13 21:29:40.785 2017] 90 00 FF 00 01 A5 00 D0 23 2A 3F 00 2A 1E 00 5B 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00
[Fri Jan 13 21:29:41.066 2017] 90 00 FF 19 01 A5 06 04 00 00 00 00 FF 64 41 00 3C 01 FF 01 02 AB 00

Das längste Telegramm 'FF 00 01 A5' ist mit 33 Bytes zu kurz (soll 39 
Bytes), aber die CRC stimmt ... Die Raum-Soll- und Ist-Temperatur stimmt 
schon mal :o)


Gruß
Philippe

[Norbert S. (junky-zs)]

Hallo Philippe,

>Mir geht es darum, dass ich die Bezeichnung 'Offset' im Header nicht
>mag, weil sie impliziert, dass die Nutzdaten erst weiter hinten im
>Telegramm zu finden sind.
Genau so ist es aber.
Allerdings muss man beachten das dieser Offset vom ersten Datenbyte (:= 
0) an gezählt wird und nicht vom Telegramm-Anfang.
Und dieser Offset ist bezogen auf das erste Datenbyte im kompletten 
Telegramm (Offset:=0).
Somit kann ein Modul auch Teilmengen an Informationen an die Steuerung 
senden.

Zu sehen ist genau dies auch bei Deinen erfassten Telegrammen:
Die Detail-Telegramme mit Offset:=03 und :=08 sind z.B.:

         90 00 FF 03 01 A5 ->2A<- CRC Break
                            90 00 FF 08 01 A5 ->00 5B<- CRC Break
Das sind die makierten Detail-Werte im kompletten Telegramm:
90 00 FF 00 01 A5 00 D0 23 ->2A<- 3F 00 2A 1E ->00 5B<- 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00

Ich habe dies hoffentlich ins rechte Licht/Spalte gerückt damit der 
Durchblick besser wird :-)
>Die Frage ist nun welchem Zweck dieser Rückwärtszähler dienen könnte?
In der Message '01 A5' bedeuten diese Zähler die Zeit bis zum nächsten 
Programmwechsel und es sind noch weitere Programminformationen 
enthalten.
Diese Informationen habe ich bisher noch nicht genutzt und die gibt es 
auch so nur bei EMS2 bzw. Cxyz-Regler).

Gruß Norbert

[Philippe D. (philippe_d)]

Hallo Norbert,

Danke, Danke, Danke!

Irgendwie hatte ich das im ganzen Thread bisher nicht verstanden (schäm)
Mit deiner Erklärung kann ich die Bezeichnung 'Offset' doch noch lieb 
gewinnen!

Witzig wird es aber bei diesen 2 Telegrammen:

[Fri Jan 13 21:29:40.785 2017] 90 00 FF 00 01 A5 00 D0 23 2A 3F 00 2A 1E 00 5B 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00
[Fri Jan 13 21:29:41.066 2017] 90 00 FF 19 01 A5 06 04 00 00 00 00 FF 64 41 00 3C 01 FF 01 02 AB 00

Offset '0x19' kommt genau auf dem CRC '0x68' zu liegen ...
Hmmm, in der alten Doku stand ja, dass der Offset zum einsortieren der 
Daten diene ...

Könnte es sein, dass das 2. Telegramm eine 'Fortsetzung' darstellt?
So, frei nach:

'Offset == 0': Schreibe die Daten an den Anfang des 'Array'
'Offset > 0': Füge die Daten ab Index 'Offset' ins 'Array'

'Array' im Sinne von Pointer (o.ä.) auf reservierten Speicherbereich für 
bestimmtes Telegramm ...



Gruß
Philippe

[Norbert S. (junky-zs)]

Hallo Philippe,

>Könnte es sein, dass das 2. Telegramm eine 'Fortsetzung' darstellt?
Ja, das sehe ich auch so.
Die maximale von mir bisher gesehene Telegrammlänge bei den Fxyz-Reglern 
war 33 Byte (Header,Daten,CRC und Break zusammen).
Diese Längenbegrenzung macht ja auch Sinn, da für die Zeit der 
Telegramm-Übertragung keine anderen Telegramme gesendet werden können 
und die CRC(8Bit) auch mehrdeutig wird.

Jetzt hat man wohl bei den Cxyz-Reglern mehr Informationen übertragen 
müssen/wollen und hat eine Art: 'Fortsetzung folgt sogleich' erzeugt.
Somit ergibt sich bei weiterhin gleicher maximaler Länge von 33 Byte pro 
Telegramm ein Offset von 25 := 19(hex) im folgenden Telegramm mit der 
gleichen MessageID.

Wenn ich allerdings die Anzahl der Bytes Deiner Telegramme mit meiner 
Beschreibung der MsgID:677-684 vergleiche so passt da was noch nicht.
Ich habe mich auch bisher ein wenig gesträubt die restlichen Werte im 
Telegramm in der Doku zu beschreiben, da mir der Nähr-/Mehr-Wert noch 
ein wenig fehlt zumal ich auch 'nur' einen Fxyz-Regler habe.
Es sind Informationen wie: Zeit bis zum nächsten Temperaturwert; Zeit 
seit letztem Temperaturwert f. Eco,Comfort...; Estrichtrocknung ect. 
enthalten.
Kein Wunder das so ein Krebsgeschwür von Telegramm da rauskommt.

Kannst Du die erfassten Daten binär in ein File schreiben und mir 
zukommen lassen?
Für eine weitere Analyse und Verbesserung der SW wäre dies hilfreich.

Gruß Norbert

[Martin S. (matz666)]

Guten Abend miteinander.

Nach langer Abstinenz bin ich wieder da.

Hier ein kurzer Überblick über meinen momentanen Stand.

Der Raspberry hat nun einen Apache2.

Die Daten der Sqlite Datenbank werden über PHP aus der Datenbank 
ausgelesen. --> d.H. Somit immer aktuell.

Solarertrag gesamt wird von Openhab errechnet und auch auf der Seite 
angezeigt.

Für den mobilen Zugriff wurde eine jquery gestaltet die aufklappbare 
Spalten hat und beinhaltet auch die Grafiken.

Bei Interesse kann der Code zur Verfügung gestellt werden.

Gruß Martin

[Philippe D. (philippe_d)]

Hallo Norbert,

anbei ein 24h-Log meiner Heizung im 7Zip-Paket, einmal als Hex-Dump mit 
1 Telegramm je Zeile und einmal in Binär.
Geht von Mo, 30.01.17 21:10 bis Di, 31.01.17 21:53, also müsste auch 
eine therm. Desinfektion drinn sein.


System: Junkers CerapurACU ZWSB 22/28-3 mit CW400-Regler

Daten/Einstellungen:

Wärmeerzeuger
Typ Steuereinheit: HT3
SW-Vers. Steuereinheit: 20.13
HCM/BCI-Nummer: 1604

Bedieneinheit
Typ: CW400
SW-Version: NF33.04

Heizungsprogramm Mo-Fr
ab 00:00 Heizen
ab 07:30 Absenken
ab 17:00 Heizen

Temperatureinstellungen
Heizen: 23°C
Absenken: 19°C

Sommer/Winter-Umschalt: Temp.
Sommerbetr.ab: 17°C

Warmwasser-Temperatureinstellungen
Warmwasser: 56°C
Warmwasser reduziert: 40°C

Warmwasser-Zeitprogramm Mo-Fr
ab 00:00 Aus
ab 05:30 Warmwasser
ab 08:00 Aus
ab 15:00 Reduziert
ab 18:00 Warmwasser

Thermische Desinfektion: Automatisch
Am Dienstag 11:45 bei 72°C

[Martin S. (matz666)]

Guten Morgen allerseits.

Für all jene die ihre Daten gerne über MQTT weitergeben würden hab ich 
nun gestern am Abend quick and dirty ein paar Bash Scripte geschrieben.

Der Raspberry benötigt das Packet mousqitto-clients mit dem er per 
Kommandozeile mit dem Broker kommunizieren kann.

Hier der Inhalt

#!/bin/bash
mqttserver="AdressedesServers"
#Solar
S_solar=$(sqlite3 /pfad/zur/Datenbank/HT3/sw/var/databases/HT3_db.sqlite "SELECT T_kollektor, T_speicher_unten, V_ertrag_stunde, C_laufzeit, V_solar_pumpe FROM solar ORDER BY rowid DESC LIMIT 1");
IFS="|"; declare -a solar=($S_solar)
mosquitto_pub -h $mqttserver -t /heizung/solar/T_kollektor -m "${solar[0]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/T_speicher_unten -m "${solar[1]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/V_ertrag_stunde -m "${solar[2]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/C_laufzeit -m "${solar[3]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/V_solar_pumpe -m "${solar[4]}"

Das Script dann mit chmod +x lauffähig machen und im Crontab (crontab 
-e) alle Minuten oder 2 ausführen lassen.

Das ganze läuft bei mir mit mehreren Dateien jeweils für HK und Solar 
und Heizgerät auf einem Raspberry B ohne Probleme.

lg

Martin

[Adam (Gast)]

Hallo Norbert,

Adam schrieb:
> Hallo Norbi,
>
> in Verzweiflung habe ich Heizkessel ausgeschaltet (vom Netz getrennt)
> und wieder eingeschaltet und ... HT3 wieder funktioniert richtig !!
>
> Geht mein Regler langsam kaputt ?
>
> Wenn das wieder passiert, probiere Dein Vorschlag. Seit gestern klappt
> alles.
>
> Danke für Deine Hilfe und grüße
> Adam

Hallo Norbert,

ein oder zwei mall täglich durch 1 bis 6 Stunden kriege ich keine Msg 
24_0. D.h. ich kriege keine Infos über wichtigste Infos: Tsoll, Tist, 
Pumpenleistung, VLeistung.
Wo kann das liegen?

Grüße
Adam

[Norbert S. (junky-zs)]

Hallo Adam,

hattest Du schon die empfohlene SW-Anpassung eingebracht?
Falls nicht dann den markierten Wert einbringen.

~/HT3/sw/lib/ht_discode.py Zeile: 2580
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 46, 47, 64, 100, 106],

Damit wird dann die Meldung 24 (18)hex vom Regler unterdrückt.
Vom Heizgerät (Adr: 08) wird die dann immer noch ausgewertet.

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

bist Du denn schon mit Deinem Projekt weitergekommen, den FWxxx durch 
einen CWxxx bei Dir auszutauschen?

Aktuell kann man bei den CWxxx nämlich nur die Temperatur steuern und 
sonst nix. Ich würde aber gern die Zirkulation hierüber starten, da der 
CW ja keine Rücksicht darauf nimmt, ob jemand da ist. Und da wir 
wechselnde Schichten haben, macht es nicht wirklich Sinn, morgens um 7 
die Zirkulation zu starten, wenn keiner mehr da ist.

Wenn ich zu den Zeiten, wo aktuell der CW die Zirkulation startet, die 
Daten in der DB prüfe, sollte ich dann den Befehl sehen können?

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

>bist Du denn schon mit Deinem Projekt weitergekommen, den FWxxx durch
>einen CWxxx bei Dir auszutauschen?
Dies habe ich auf Eis gelegt. Leider reicht es nicht nur den Regler 
auszutauschen, auch das Solarmodul muss ausgetauscht werden. Und deshalb 
verzichte ich drauf weil dies keinen Vorteil bringt (nur für Junkers :-)

>Ich würde aber gern die Zirkulation hierüber starten, da der
>CW ja keine Rücksicht darauf nimmt, ob jemand da ist.
Du kannst doch sicherlich die Zirkulationspumpe per Zirkulationsprogramm 
steuern. Damit ist eine wenn auch kleine Anpassung möglich.

>Wenn ich zu den Zeiten, wo aktuell der CW die Zirkulation startet, die
>Daten in der DB prüfe, sollte ich dann den Befehl sehen können?
Die Daten werden in die sqlite-DB geschrieben wenn sie auftreten. Somit 
könntest Du diese Telegramme dort auch wiederfinden. Da diese vom Regler 
kommen werden die Daten in der Heizkreis-Tabelle zu finden sein.
Das wird irgendwas mit Source:=(90)hex oder (98)hex und Target:=(08)hex 
am Telegrammanfang sein, also:
 90 08 .. .. oder 98 08 .. ..

Gruß Norbert

[Adam (Gast)]

Norbert S. schrieb:
> Hallo Adam,
>
> hattest Du schon die empfohlene SW-Anpassung eingebracht?
> Falls nicht dann den markierten Wert einbringen.
>
> ~/HT3/sw/lib/ht_discode.py Zeile: 2580
>     deviceadr_2msgid_blacklist = {
>         0x10: [11, 12, 24, 46, 47, 64, 100, 106],
>
> Damit wird dann die Meldung 24 (18)hex vom Regler unterdrückt.
> Vom Heizgerät (Adr: 08) wird die dann immer noch ausgewertet.
>
> Gruß Norbert

Hallo Norbert,

nach die SW-Anpassung läuft wieder alles richtig.

Besten Dank und grüße
Adam

[Thomas D. (nasi_be)]

Martin S. schrieb:
> ...
> #Solar
> S_solar=$(sqlite3 /pfad/zur/Datenbank/HT3/sw/var/databases/HT3_db.sqlite
> "SELECT T_kollektor, T_speicher_unten, V_ertrag_stunde, C_laufzeit,
> V_solar_pumpe FROM solar ORDER BY rowid DESC LIMIT 1");
> IFS="|"; declare -a solar=($S_solar)
> ...
>
> Das Script dann mit chmod +x lauffähig machen und im Crontab (crontab
> -e) alle Minuten oder 2 ausführen lassen.
>
> Das ganze läuft bei mir mit mehreren Dateien jeweils für HK und Solar
> und Heizgerät auf einem Raspberry B ohne Probleme.
>
> lg
>
> Martin

Hallo Martin,

ich habe versucht dein Script zu übernehmen, da ich so die ausgelesenen 
Daten per REST-API an OpenHAB übergeben kann.
Das funktioniert auch soweit, allerdings bekomme ich beim wiederholten 
Aufruf des Scripts immer die folgende Meldung:

Error Code SQLITE_LOCKED (6): Database Is Locked

Hattest du das Problem auch schon mal und konntest es irgendwie lösen?
Muss man vielleicht die aufgebaute Verbindung irgendwie wieder sauber 
trennen?

Viele Grüße
Thomas

[Martin S. (matz666)]

Hallo Thomas

Tut mir leid, hab erst jetzt gelesen das du Hilfe brauchst.

Jahatte das Problem hatte ich auch, hab mir dann einen netclient 
gebastelt der die daten über das Netzwerk vom Raspberry zieht. Er ist 
nur für den mqtt export zuständig. Auch hab ich festgestellt das ein 
großteile der usb sticks zu langsam ist.

Ich hab das Script nochmals angepasst um zu Überprüfen ob der Arry leer 
ist denn das verursacht Fehlermeldungen in Openhab.

Also wenn noch Interesse besteht melden.

[Norbert S. (junky-zs)]

Hallo,

es gibt ein neues Release: 0.3 zum Projekt auf github.
Wie gehabt zu erhalten mit :
  git clone https://github.com/norberts1/hometop_HT3.git
oder Download des ZIP-Files.

Neu ist der Daemon: ht_collgate der den HT3_Logger komplett ersetzt.

Die zusätzliche Schnittstellen: MQTT-Client und SPS-Interface können 
jetzt durch diesen neuen Daemon gestartet werden.
Die vorhandenen Datenbanken können weiter verwendet werden da sich diese 
Schnittstellen (sqlite und rrdtool) seit der Version: 0.2.2 nicht 
geändert haben.
Allerdings ist jetzt die Datenbank: sqlite per Default ausgeschaltet und 
nur die rrdtool-Datenbank ist aktiv.
Folgende Konfigurations-Werte sind per default gegeben:

 sqlite-Datenbank : Aus
 rrdtool-Datenbank: Ein
 MQTT-Client      : Aus
 SPS-Client       : Aus

Die Dokumentation gibt u.A. Auskunft über diese Konfiguration, die 
Installation des MQTT-Broker und pyhton-paho Library sowie über die 
Eigenschaften der SPS-Schnittstelle.

Die Steuerung der Heizung über MQTT-Befehle ist für die Fxyz- und die 
Cxyz- Regler enthalten und wenn man einen ht_transceiver (ht_piduino 
oder ht_pitiny) hat auch möglich.
Der ht_collgate verbindet sich mit dem ht_proxy.server, holt sich dort 
die RAW-Daten ab und dekodiert diese.
Die dekodierten Daten werden zu den Clients gesendet (MQTT) bzw. sind 
durch einen SPS-Client abfragbar.

Es werden weiterhin alle Adapter-Typen unterstützt.

Details gehen aus der Dokumentation hervor.

Gruß Norbert

[Martin S. (matz666)]

Hallo Norbert.

Erst mal herzlichen Dank das du nun auch MQTT Transport integriert hast.

Nun zu meiner Frage.

Ich habe den Ht-pitiny auf meinem Raspi2 hängen der als Ht-Proxy läuft.

Auf meinem Webserver läuft eine Instanz die die Daten aus der Datenbank 
zieht und für die Webseite aufbereitet. Hier läuft jetzt ein Bash Script 
das die Daten an den MQTT Broker sendet. Dieser soll nun durch die neue 
Version 0.3 ersetzt werden.

Kann ich auf dem Pi die alte Version belassen oder sollte ich auf dem PI 
auch auf 0.3 updaten???

Danke
Martin

[Norbert S. (junky-zs)]

Hallo Martin,

der ht_proxy hat sich gegenüber der SW-Vorgängerversion (0.2.x) nicht 
geändert. Ebenso das ht_proxy_cfg.xml Konfigurationsfile nicht. Somit 
brauchst Du diesen Anteil auf dem RPI2 nicht zu aktualisieren.

Aber alle ht_clients die RAW-Daten vom ht_proxy.server bekommen, müssen 
die neueste SW-Version 0.3 erhalten.
Es ist z.B. der HT3_Logger.py daemon durch den ht_collgate.py daemon 
ersetzt und im Konfigurationsfile: HT3_db_cfg.xml sind set-Parameter 
dazugekommen.
Daher sind auch viele der lib-Module angepasst und laufen nur noch 
korrekt in der 0.3 SW-Version.

Aber das Beste zum Schluss.
Die vorhandenen Datenbanken (aus Versionen 0.2.x) können weiter genutzt 
werden und werden auch nicht durch die neue SW-Version 0.3 gelöscht. 
Neue Daten werden an die vorhandenen angehängt.

Einzig die sqlite-Datenbank ist jetzt per default deaktiviert.
Aber diese brauchst Du ja in Zukunft eh nicht mehr da der ht_collgate.py 
daemon mit aktiviertem MQTT-Interface die Daten an den MQTT-Broker 
sendet.

Gruß Norbert

[Martin S. (matz666)]

Kurze Info.

Da ich nur einige Zeit damit verbracht habe möchte ich den anderen die 
Suche ersparen.

In der aktuellen Version auf Git ist der ht_collgate nichtausführbar.

Bitte mit chmod +x ./ht_collgate.py nachholen.

@Norbert könntest du das beheben.

Danke

[Norbert S. (junky-zs)]

Hallo Martin,

danke für die Info.
Allerdings tritt dieser Fehler bei mir nicht auf.

Habe mir mehrmals mit 'git clone' und auch mit dem Download des 
Zip-Files das ganze Projekt von github geholt und jedesmal sind die 
nötigen executable-Flags bei den Files gesetzt.
Ebenso wird mir im Browser angezeigt das es sich um ein 'Executable 
File' handelt (siehe Bild).

Daher weiss ich jetzt nicht was bei Deiner Installation anders sein soll 
als bei mir.
Du hast Dir sicher auch das ganze Projekt mit git clone .... vom 
github-server geholt oder?

Gruß Norbert

[Martin S. (matz666)]

Morgen Norbert.

Ich hab das Projekt als ZIP gezogen.

Kann es sein das es hier einen Unterschied gibt???

[Martin S. (matz666)]

Noch eine Frage.

Steig bei den MQTT Befehlen zum steuern nicht ganz durch.

Habe topic root namen auf /ht3 geändert.

Um bei Heizkreis 1 die Betriebsart zu verstellen schicke ich.

Topic: /ht3/hc1_Tniveau
Message: Tniveau,2,1,heizen

Richtig so???

[Norbert S. (junky-zs)]

Hallo Martin,

dein Topic-rootname: '/ht3' ist ungünstig bzw. falsch.
Das Slash vorne sollte weg, also 'ht3'.
Der Topic-rootname bei MQTT hat nichts mit einer root-Pfadangabe zu tun. 
Es wird in der Regel kein führendes '/' angegeben.
Aber dies ist nicht der Fehler, sondern vor dem Kommando kommt noch die 
'set'-Angabe.
Somit wäre richtig:
  Topic: set/ht3/hc1_Tdesired
  Message: 22.5,heizen
Funktion: Es wird für den Heizkreis1 das Temperaturniveau:Heizen auf 
22.5 Grad eingestellt.
Hinweis:
Die Topic-Namen für die Kommandos an die Heizung sind die gleichen wie 
die 'Empfangs-Topic Namen' haben jedoch noch das 'set/' davor.

Im Konfigurationsfile: HT3_db_cfg.xml sind die set-Befehle bei den 
Logitems eingetragen bei denen eine Kommandierung z.Zeit möglich ist.
Für hc1_Tdesired steht da z.B.:
  <set_param>Tdesired,3,1,T,heizen|sparen|frost||.....
bedeutet:
 Tdesired mit drei Parametern.
 1. Heizkreisnummer:= hier 1 <<-- Parser intern genutzt
 2. T:= gewünschter Temperaturwert <<-- 1. Befehlsparameter
 3. ein Wert aus Liste für zugehöriges Temperaturniveau 
<<--2.Befehlsparameter

Achtung: Die Werte für die Temperaturniveaus unterscheiden sich je nach 
Reglertyp: 1. Fxyz-Regler oder 2. Cxyz-Regler.
Diese Angaben sind für den Parser wichtig, für die Befehle eines 
MQTT-Client ist die Anzahl der Parameter einen Zähler weniger siehe 
Beispiel oben.

Bitte dringend dazu auch die Dokumentation lesen: §2.3.2 MQTT-Client und 
$2.2 Konfiguration und Tabellen 7 und 8.

Gruß Norbert

[Martin S. (matz666)]

Hallo Norbert.

Leider funktionieren die MQTT Befehle noch immer nicht.

Darum meine Frage. Welcher Teil wertet die Befehle aus?

Kann es sein das ich auf dem Pi die Version 0.3 aufspielen muss damit es 
funktioniert.

[Norbert S. (junky-zs)]

Hallo Martin,

wie weiter oben beschrieben ist eine Aktualisierung des PI nicht 
zwingend erforderlich wenn da NUR der ht_proxy.server läuft und dort der 
ht_pitiny-Adapter angeschlossen ist.
Dein Web-Sever ist ja wohl mit diesem RPI verbunden und hat die aktuelle 
Software erhalten, richtig?
Aktualisierung auf 0.3 ist allerdings immer die bessere Lösung.

Jetzt habe ich aber auch an Dich noch ein paar Fragen:
1. Wie hast Du erkannt das die Befehle keine Wirkung zeigen?
 (mit HT3_Analyser.py oder mosquitto??)
2. Hast Du jemals Deine Heizung mit dem Tool: ht_netclient.py gesteuert?
3. Welchen Reglertyp hast Du (Fxyz oder Cxyz)?
4. Ist der Empfang von Heizungsdaten mit MQTT-Messages erfolgreich?
5. Läuft der MQTT-Broker? (sonst auch kein Empfang/Senden).
6. Womit sendest Du die MQTT-Befehle?
7. Welche Tests hast Du durchgeführt?
Ein paar Tipps dazu:
1. Empfang:
mosquitto_sub -d -h <server-IP> -t hometop/ht/# -q 1
oder
mosquitto_sub -d -h <server-IP> -t set/hometop/ht/# -q 1

2. Senden mit :
mosquitto_pub -d -h <server-IP> -t set/hometop/ht/hc1_Tniveau -m 
"heizen"
oder
mosquitto_pub -d -h <server-IP> -t set/hometop/ht/hc1_Tdesired -m 
"22.0,heizen"

Die Dekodierung der MQTT-Befehle macht lib/mqtt_client_if.py welches vom 
ht_collgate gestartet wird.

Gruß Norbert

[Martin S. (matz666)]

Martin S. schrieb:
> Topic: /ht3/hc1_Tniveau
> Message: Tniveau,2,1,heizen

hier liegt der Fehler Norbert.

hatte in der Message zu viel drinnen. mit "heizen" "sparen" "frost" 
"auto" ist auf einmal alles ok.
Topic: /set/ht3/hc1_Tniveau
Message: sparen

Danke für deine Geduld und deine schnelle Antwort.

lg

Martin

[Andre (Gast)]

Hallo Norbert,
Hallo zusammen,

ich bin schon seit langer Zeit begeisterter Nutzer Deiner Software und 
des piTiny Adapters - bisher habe ich die Daten allerdings aus reiner 
Neugier protokolliert. Aktuell habe ich allerdings ein Problem mit 
meiner Heizung (bzw. mit dem Warmwasser), welches in den Plots auch 
wunderbar visualisiert wird (siehe Anhang). Das Problem trat vor einem 
Jahr schon einmal auf, verschwand aber von selbst nach 2 Tagen.

Mein Warmwasser an der Zapfstelle ist derzeit nur noch lauwarm. Konkret 
kann ich maximal 40° messen. Wenn ich dusche, fällt die Temperatur 
relativ schnell ab. Wenn ich mir die Plots so anschaue, entspricht das 
mehr oder weniger der Speichertemperatur, aber nicht der Ist Temperatur. 
Generell sieht der Plot aus meiner Sicht seltsam aus: T-Ist ist im Plot 
konstant bei ~70° (!) (das ist nirgends so konfiguriert), T-Soll bei 
~52° (so soll es sein). T-Speicher ist bei ~40° (das entspricht dem 
Wasser an der Zapfstelle und passt komischerweise relativ gut zur 
Vorlauftemperatur der Heizung).

Um das ganze besser zu verstehen habe ich ein paar Fragen zu den 
angegebenen Werten. Welche Temperaturen werden mit "T-Ist", "T-Speicher" 
und "T-Speicher Unten (Solar)" genau angezeigt und wo werden sie 
gemessen. Sollte T-Ist tatsächlich so irgendwo im System vorhanden sein, 
müsste ja ein Ventil / Mischer defekt sein und das Wasser nicht in den 
Kreislauf geben. Sollte die Temperatur nicht korrekt sein, würde ich auf 
einen NTC tippen.

Letztes Jahr war ein Heizungsbauer vor Ort, der wollte so auf Verdacht 
einen NTC austauschen, er war sich aber auch nicht sicher. Da nach 2 
Tagen der Selbstheilungsprozess eingesetzt hat, haben wir es damals 
gelassen. Hat einer eine Meinung dazu?

Besten Dank für Deine / eure Ideen!

Gruß
André

[Norbert S. (junky-zs)]

Hallo André,

da ich auch ein CerapurSolar-Heizgerät (CSW) habe kann ich Dir 
hoffentlich einige Fragen beantworten.

> Welche Temperaturen werden mit "T-Ist", "T-Speicher" und "T-Speicher
> Unten (Solar)" genau angezeigt ?

"T-Speicher" ist der Temperatur-Wert des WW-Pufferspeichers und wird mit 
einem WW-Telegramm gesendet.

"T-Speicher unten" (Solar) ist der Temperatur-Wert des TS2 - 
Temperatursensors am Systempufferspeicher SP400 (Details siehe Bilder).
Dieser Wert wird mit einem Solar-Telegramm gesendet.

"T-Ist" (WW) kommt vom Temperatursensor im Mischventil (MV) des CSW.
Dieses Ventil ist speziell im CSW eingebaut, andere Junkers-Heizgeräte 
haben dies meines Wissens nicht (siehe Beschreibung im Bild).
T-Ist (WW) wird mit einem WW-Telegramm gesendet und aufgezeichnet.
Allerdings wird dieser Temperaturwert des Mischventils (MV) auch in 
einem Heizgerät-Telegramm verwendet, Anzeige im Systemstatus als Wert: 
"T-3Wege Mischer".
Hinweis:
Da diese Telegramme nicht zeitgleich gesendet werden sind die 
angezeigten Werte u.U. leicht unterschiedlich (in den 
Nachkomma-Stellen), gleichen sich aber wieder an.

Wird durch das Heizgerät kein WW erzeugt, so steht das Mischventil (MV) 
und das 3-Wege Umsteuerventil (DWU) auf Stellung "Heizen".
Der Temperaturfühler im Mischventil (MV) misst also die Temperatur im 
Vorlauf in der Nähe der Heizungspumpe (HP).
Somit passt die angezeigte Temperatur von ca. 75Grad durchaus zu Deinem 
Heizungssystem (Vorlauf), da Du ja neben der Fussbodenheizung auch 
Radiatoren hast.

Die Verwendung der Mischventil-Temperatur im WW-Telegramm als "T-Ist" 
beim CSW-Heizgerät ist also denkbar ungünstig von Junkers gelöst.
Dies ist also kein Fehler in Deinem Heizungssystem und der NTC 
funktioniert ja auch.

Allerdings fällt mir in Deinem WW-Plot auf, das die Warmwasser-Erzeugung 
(hellblau) sehr häufig ausgelöst wird und das die WW-Speichertemperatur 
(hellgrün) nicht mal in die Nähe des Soll-Wertes gelangt.
Bei meiner Anlage ist dies sichtbar anders (siehe Bild). Wenn die 
WW-Speichertemperatur unterhalb des Grenzwertes fällt wird das Heizgerät 
auf Warmwasser-Erzeugung umgeschaltet und solange geheizt bis der 
Sollwert erreicht ist. Der Wert "Speichertemperatur OK" wird dann 
angezeigt wenn die Speichertemperatur nicht unter den Grenzwert absinkt.
Hinweis:
Dieser Grenzwert hängt von der ECO-Taste aktiv/inaktiv ab.

Mein Tipp um der Sache näher zu kommen:
1. HT3_Analyser starten und die Werte (Temperatur / Flags) 
kontrollieren, insbesondere für "T-3Wege Mischer (HG)", "3-Weg -> 
WW-Speicher (HG)", "Betriebsmodus (HG)", "Warmwasser-Erzeugung" und 
"Speichertemperatur OK".
2. WW Sollwert mal zum Test auf 60 Grad erhöhen. Dann muss 
"Speichertemperatur OK" auf "Nein" stehen, der "Betriebsmodus (HG)" auf 
Warmwassererzeugung umschalten und sich die WW T-Speichertemperatur 
erhöhen. Eventuell dann noch die Taste "Warmwasser-Sofort" am Regler 
drücken.
3. Kontrollieren ob Störungsmeldungen in HT3_Analyser und Regler 
vorhanden sind.
4. Alte Plots aus rrdtool-db auswerten, bei denen das System in Ordnung 
war.

Vielleicht funktioniert das Mischventil im CSW-Heizgerät nicht mehr so 
wie es soll, aber dies ist nur meine laienhafte Vermutung.

Gruß Norbert

[Marc (Gast)]

Guten Morgen,

was läuft bei mir denn falsch? Die RRDTools Grafiken werden nicht 
generiert auf Grund folgenden Fehlers:

pi@heattronic-pi:~/HT3/sw/var/log $ /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi /home/pi 1
rrdtool graph /home/pi//HT3/sw/etc/html/HT3_Heizgeraet.png --vertical-label Temperaturen (Celsius) --width 740 --right-axis-label Temperaturen (Celsius) --title Heizgerät (07:46:28 04.10. - 07:45:28 06.10.2017) --right-axis 1:0 --start 1507095988 --end 1507268728 --height 310 DEF:modusfkt=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_modus:MAX CDEF:draw2=modusfkt,45,* AREA:draw2#e9ddaf DEF:Brennerleistung=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_leistung:MAX AREA:Brennerleistung#cccccc:Brennerleistung (%) VDEF:Brennerleistung_last=Brennerleistung,LAST COMMENT:                       last\: GPRINT:Brennerleistung_last:%2.lf\l DEF:TSoll=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_vorlauf_soll:MAX LINE1:TSoll#ff0000:T-Soll (Regelung) VDEF:TSoll_last=TSoll,LAST COMMENT:                         last\: GPRINT:TSoll_last:%2.lf\l DEF:TIst=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_vorlauf_ist:MAX LINE1:TIst#0000ff:T-Ist  (Vorlauf) VDEF:TIst_last=TIst,LAST COMMENT:                          last\: GPRINT:TIst_last:%2.1lf\l DEF:TRueck=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_ruecklauf:MAX LINE1:TRueck#00ff00:Rücklauf VDEF:TRueck_last=TRueck,LAST COMMENT:                                  last\: GPRINT:TRueck_last:%2.1lf\l DEF:zirkula_pumpe=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_zirkula_pumpe:MAX CDEF:draw12=zirkula_pumpe,10,* AREA:draw12#d45500:Zirkulations-Pumpe\l DEF:Heizungspumpenleistung=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_spare_1:MAX LINE1:Heizungspumpenleistung#008d00:Heizungspumpenleistung (%) VDEF:HP_Leistung_last=Heizungspumpenleistung,LAST COMMENT:                last\: GPRINT:HP_Leistung_last:%2.lf\l DEF:Aussentemperatur=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_aussen:MAX LINE2:Aussentemperatur#000055:Aussentemperatur min\: VDEF:Aussentemperatur_min=Aussentemperatur,MINIMUM GPRINT:Aussentemperatur_min:%3.1lf VDEF:Aussentemperatur_max=Aussentemperatur,MAXIMUM COMMENT:max\: GPRINT:Aussentemperatur_max:%3.1lf VDEF:Aussentemperatur_last=Aussentemperatur,LAST COMMENT:   last\: GPRINT:Aussentemperatur_last:%3.1lf\l DEF:BZeitg=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:C_betrieb_gesamt:LAST VDEF:BZeitg_average=BZeitg,LAST GPRINT:BZeitg_average:  Betriebszeit gesamt \: %6.1lf Stunden\l DEF:brennereinheiz=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:C_brenner_heizung:LAST VDEF:brennereinheiz_last=brennereinheiz,LAST GPRINT:brennereinheiz_last:  Brenner ein         \: %6.lf Zähler COMMENT: \s COMMENT: \s --color CANVAS#fff6d5 --color BACK#ffdd55 failed: invalid format string '%2.lf\l' (should match '^(?:[^%]+|%%)*%[-+ 0#]?[0-9]*(?:[.][0-9]+)?l[eEfFgG](?:[^%]+|%%)*(?:%s)?(?:[^%]+|%%)*$') at /usr/share/perl5/RRDTool/OO.pm line 444

Dieser Fehler kommt:
 failed: invalid format string '%2.lf\l' (should match 
'^(?:[^%]+|%%)*%[-+ 
0#]?[0-9]*(?:[.][0-9]+)?l[eEfFgG](?:[^%]+|%%)*(?:%s)?(?:[^%]+|%%)*$') at 
/usr/share/perl5/RRDTool/OO.pm line 444

Danke schon mal...

[Marc (Gast)]

Hallo,

ich habe noch eine Frage. Ich besitze eine CSW 14/75-3 A mit 3 Solar 
Kollektoren, dem 415 Liter Pufferspeicher mit Fußbodenheizung.

Müsste bei mir nicht auch der T-3Wege Mischer im Heizgerät-Telegramm 
auftauchen? Ich finde aber in der SQLite DB keinen Eintrag dazu.

Grüße
Marc

[Norbert S. (junky-zs)]

Hallo Marc,

der Anzeige-Wert: "T-3Wege Mischer" steht als logitem-name: "T_mischer" 
in den Datenbanken.
Die Datenbank-Spalten werden nur mit den logitem-Namen generiert.
Den Zusammenhang zu den Anzeigenamen sieht man im Konfigurationsfile:
 ...
        <logitem name="T_mischer">
            <datatype>REAL</datatype>
            <datause>GAUGE</datause>
            <maxvalue>100.0</maxvalue>
            <default>0.0</default>
            <unit>Grad</unit>
            <displayname>T-3Wege Mischer</displayname>
            <accessname>ch_T3waymixer</accessname>
        </logitem>

Der Wert für T_mischer wird mit Msg_ID:24 gesendet.
sqlite-Einträge siehe Bilder.

> failed: invalid format string '%2.lf\l' (should match...
Die Fehlermeldung muss ich noch auswerten. Dir hilft es ja nicht wenn 
ich sage das der bei mir nicht auftritt.
Allerdings hatte ich vor kurzem einen vergleichbaren Fehler auch schon 
von einem anderen Forumsteilnehmer erhalten.
Letztendlich hat er dann das Raspbian Linux installiert und der Fehler 
war weg. Bis dato hatte ich angenommen das dies ein Einzelfall sei.

Tritt dieser Fehler sporadisch auf oder ständig?

Gruß Norbert

[Marc (Gast)]

Hallo Norbert,

danke für deine Antworten.

Bzgl. des Fehlers, ja der tritt immer auf, also immer dann, wenn neue 
Grafiken generiert werden sollen. Ich habe erstmal den Heizgeräte Part 
auskommentiert um die restlichen Grafiken zu sehen (die funktionieren 
einwandfrei). Aber sobald ich die rrdtool_draw.pl durch die original 
Version wieder ersetze, rasselt das Script sofort in den Fehler.

Mein Raspbian läuft mit:
Linux ht-pi 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l 
GNU/Linux

rrdtool in der Version:
1.6.0-1+b1

librrdtool-oo-perl:
0.36-1

---

Mir ist noch eine kuriose Sache in der DB aufgefallen. Mein T-Soll Wert 
beim WW rutscht manchmal auf 0 für einige Telegramme um anschließend 
wieder auf den normalen Wert von 60 zu kommen. Ich habe die Grafik mal 
angehängt. Nicht wundern, die Zeitspanne habe ich auf 6 Stunden 
reduziert. Deutlich zu sehen sind die Ausbrecher gen 0. Da dieser 0 Wert 
nur für ein paar Sekunden (maximal 10-15) in den DBs existiert, erreicht 
die T-Soll Linie nicht 0.

Ich habe mal die SQLite DB für mit der WW Tabelle angehängt.

[Norbert S. (junky-zs)]

Hallo Marc,

> failed: invalid format string '%2.lf\l' (should match...
Folgendes habe ich dazu gefunden:
Das Problem ist rrdtool versionsabhängig.
rrdtool-
version script-run linux-release
1.4.7___OK_______wheezy
1.4.8___OK_______jessie
1.6.x___Fehler___stretch, buster, sid
Was genau die Ursache ist kann ich nicht sagen, da ich nur wheezy und 
jessie einsetze.
Wahrscheinlich ist im rrdtool die Integer/Float-Typprüfung 
verändert/verbessert worden.
Vorschlag:
Deaktiviere zum Test die Zeilen/Blocks im rrdtool_draw.pl script in 
denen '%2.lf\l' vorkommt. Nur im Heizgeräte-draw werden an den Stellen 
Integer-Werte eingetragen.

> Mein T-Soll Wert beim WW rutscht manchmal auf 0
Werde Deine sqlite-db noch auswerten.

Welchen Adapter setzt Du ein? Ich nehme mal an einen HT3_Mini- oder 
HT3_Micro-Adapter?

Gruß Norbert

[Marc (Gast)]

Hallo Norbert,

>> failed: invalid format string '%2.lf\l' (should match...
> Folgendes habe ich dazu gefunden:
> Das Problem ist rrdtool versionsabhängig.
> rrdtool-
> version script-run linux-release
> 1.4.7___OK_______wheezy
> 1.4.8___OK_______jessie
> 1.6.x___Fehler___stretch, buster, sid
> Was genau die Ursache ist kann ich nicht sagen, da ich nur wheezy und
> jessie einsetze.
> Wahrscheinlich ist im rrdtool die Integer/Float-Typprüfung
> verändert/verbessert worden.
> Vorschlag:
> Deaktiviere zum Test die Zeilen/Blocks im rrdtool_draw.pl script in
> denen '%2.lf\l' vorkommt. Nur im Heizgeräte-draw werden an den Stellen
> Integer-Werte eingetragen.

Alles klar, das versuche ich mal. Möglich das der Versionssprung die 
Ursache ist.

>> Mein T-Soll Wert beim WW rutscht manchmal auf 0
> Werde Deine sqlite-db noch auswerten.

Danke.

> Welchen Adapter setzt Du ein? Ich nehme mal an einen HT3_Mini- oder
> HT3_Micro-Adapter?

Ich habe den HT3 Mini zusammengelötet.

Gruß
Marc

[Constanze H. (warteschleife)]

Hi Norbert,
leider gibt es nach 2 Tagen Betrieb Probleme mit ht_tiny Adapter.
Auf dem Adapter flackern zwar beide LEDs wie sie sollen,
aber es scheint keine Kommunikation mit dem PI mehr zu geben.
Ich habe das System gerade komplett neu auf einem PI-3 mit Debian Jessie
aufgesetzt, leider ohne Erfolg.
Irgendeine Idee, wie ich weiter testen kann?

Update:
wenn ich ht_collgate und ht_proxy stoppe, blinkt nur noch
die grüne LED. D.h. kein Bussignal vorhanden.
Der CW100 läuft allerdings normal.

Danke und Gruß
Michael

[Norbert S. (junky-zs)]

Hallo Michael,

> wenn ich ht_collgate und ht_proxy stoppe, blinkt nur noch
> die grüne LED. D.h. kein Bussignal vorhanden.

Dies ist 'normal' und kein Fehler. Im start-script wird bei Eingabe von 
'stop' der spi-Port wieder aktiviert und der spi-Treiber meint: 'Jetzt 
bin ich Herr im Haus und blockiert das HTBus-Empfangssignal :-(.
Beim Start des collgate-daemon wird dieser SPI-Port deaktiviert und für 
den HT-Bus genutzt :-)

Du kannst also zum Test einmal folgendes als user 'pi' eingeben:
 sudo ~/HT3/sw/etc/sysconfig/spi_clk_off.py
Die grüne und rote LED müssen dann wieder wie gewohnt blinken wenn der 
HT-Bus angeschlossen ist.

Du hast einen PI3 und der hat netterweise ein Bluetooth an Board. Leider 
wird der serielle Port dafür verballert den wir aber nutzen wollen.

Deshalb meine Frage ob Du die nötige Deaktivierung dieser Schnittstelle 
durchgeführt hast? Siehe auch Doku Seite 51ff oder unter
URL:
  https://forum.fhem.de/index.php/topic,50340.0.html
Gruß Norbert

[Marc (Gast)]

Hallo Norbert,

die Heizgeräte Grafik funktioniert nun.
Ich habe %2.lf\l durch %2.0lf\l ersetzt, bzw. %6.lf durch %6.0lf. 
Vielleicht erwartet die neue Version da genauere Angaben zu den 
Nachkommastellen.

In der Heizgeräte Grafik habe ich das gleiche Phänomen wie bei dem 
T-Soll Wert. Ich werde das Kabel von dem HT-Mini Adapter zum Bus mal 
etwas kürzen. Aktuell ist dies, weil ich es erstmal nur testen wollte ob 
es überhaupt geht, ein altes Lautsprecherkabel welches 2 Meter oder so 
lang ist.

Ein bisschen wundere ich mich allerdings über die Zirkulationspumpe. Ist 
eine solche Pumpe nicht normalerweise dafür da um an den 
Warmwassserzapfstellen das warme Wasser zirkulieren zu lassen? Also 
damit man immer flott warmes Wasser zur Verfügung hat? Einen solchen 
Kreislauf bzw. eine solche Pumpe besitze ich nicht. Oder wird der Wert 
von einer anderen Pumpe genommen?

Gibt es vielleicht irgendwo eine Grafik in der eingezeichnet ist, 
welcher Wert wo abgegriffen wird? Das wäre für einen Noob wie mich sehr 
hilfreich ;)

Grüße
Marc

[Norbert S. (junky-zs)]

Hallo Marc,

prima das das Script rrdtool_draw.pl jetzt geht und die Ursache 
eingegrenzt ist!

> Mein T-Soll Wert beim WW rutscht manchmal auf 0 ...
Ursache ist eine Fehldetektion des Telegramms: MsgID 51_0.
In Deinem sqlite-Datenbank-File ist dies z.B. beim Eintrag#: 4808 zu 
sehen (siehe Bild).
Dort startet das Telegramm mit a0 00 33 00 30 00 b0 00 ...
Der Wert 'b0' wird der Soll-Temperatur zugeordnet (ist richtig) jedoch 
der Wert an sich ist als Temperatur zu hoch (176 Grad). Deshalb wird in 
die Datenbank der default-Wert -> 0 eingetragen.
Eine Fehldetektion kann immer mal bei den Adaptertypen HT3_Mini- und 
HT3-Micro vorkommen, weil die Break-Erkennung als Telegramm-Endekennung 
damit nicht möglich ist.

In Deinem System hast Du mindestens einen gemischten Heizkreis mit dem 
Modul IPM(x). Deshalb kann diese Sequenz: a0 00 33 00 ... durchaus 
vorkommen wenn dieses IPM-Modul auch die Warmwasser-Regelung (Heizgeräte 
externe Warmwassererzeugung) macht.
Ich nehme mal an das dies bei Dir nicht der Fall ist.
Deshalb trage den Wert '51' in das python-Modul: lib/ht_discode.py für 
Geräteadr (20)hex bis (23)hex ein:
Zeilen: 2607 ff
    # device-adr mapped with not valid message-IDs for detailed message 
- searching
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 46, 47, 64, 100, 106],
        0x1b: [17, 56, 74, 89],
        0x20: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
        0x21: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
        0x22: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
        0x23: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
    }
Damit wird Telegramm MsgID_51 für Module (20...23)hex unterdrückt.

Bitte erzeuge noch ein binäres Logfile von Deiner Anlage und lass es 
mir zukommen. Dann kann ich mir dies noch zusätzlich ansehen und 
auswerten.

Der Regler aktiviert die Zirkulationspumpe und teilt dies in einem 
Telegramm mit. Dem Regler ist es egal ob wirklich eine Pumpe da 
vorhanden ist oder nicht. Er hat jedenfalls das Relay dafür angesteuert 
und seine Pflicht getan. Dies kann man wohl auch ruhigstellen, must mal 
im Handbuch des Reglers nachlesen.

Die Telegramme sind dokumentiert unter:
 ~/HT3/sw/etc/html/HT3-Bus_Telegramme.html

Gruß Norbert

[Constanze H. (warteschleife)]

Hi Norbert,
viele Dank, das scheint zu funktionieren.
Allerdings erst, nachdem das Teil 2 Tage lang
ausgeschaltet in der Ecke lag.
Nach erneutem Start bekomme ich jetzt wieder Daten.

Viele Grüße
Michael

[Marc S. (mrmiller)]

Hallo Norbert,

ich habe das BINLOG-File mal hier hochgeladen.

Ich suche in den DB Werten noch den Wert der geforderten 
Vorlauftemperatur. In dem FW120 Bedienterminal unter Info -> Heizkreis 
steht etwas von 25,7 Grad. Dieser müsste auch in der Binlog Datei unter 
den neusten Werten zu finden sein (falls vorhanden). Den Wert T_soll_HK 
von 21.0 Grad in Heizkreis Tabelle kann ich nicht ganz nachvollziehen.

Gruß
Marc

[Marc S. (mrmiller)]

Moin,

Marc S. schrieb:
> Den Wert T_soll_HK
> von 21.0 Grad in Heizkreis Tabelle kann ich nicht ganz nachvollziehen.

Ich habe den Wert mitlerweile gefunden. Man setzt diesen ja als Wert für 
den jeweiligen Modus (in meinem Fall bei Heizen) ein.

Jetzt interessiert es mich aber doch ob ich solche Werte wie: Geforderte 
Vorlauftemperatur (beim HK) oder so sehen kann.

Oder sind Werte wie: Maximale Vorlauf- bzw. Warmwassertemperatur auch in 
irgendwelchen Telegrammen logbar?

Grüße
Marc

[Norbert S. (junky-zs)]

Hallo Marc,

>Jetzt interessiert es mich aber doch ob ich solche Werte wie: Geforderte
>Vorlauftemperatur (beim HK) oder so sehen kann.
Du kannst den HT3_Analyser.py dazu verwenden. Die Bilder zeigen die WW 
-Telegramme so wie diese in Deinem bin-Logfile enthalten sind.
Bei Deinem System ist ein gemischter Heizkreis mit dem Modul IPM1 
vorhanden.
Diese Telegramme beginnen mit: a0...
Die Telegramme mit: 90...sind vom Regler Fxyz.

Im Analyser werden die MessageID's für den jeweiligen Systempart in 
Kurzform erklärt.

Details sind dokumentiert unter:
 ~/HT3/sw/etc/html/HT3-Bus_Telegramme.html

Die empfohlene Änderung in 'deviceadr_2msgid_blacklist' (siehe oben) 
habe ich testet und die funktioniert auch.
Deshalb kannst Du diese Änderung ohne weiteres übernehmen. Die 
Fehldetektionen der WW-Solltemperatur werden damit dann unterdrückt.

Gruß Norbert

[adam (Gast)]

Hallo Norbert,
manchmal kommen kurzfristig falsche Werte. Schau bitte Zeile 305 - das 
macht Message:
  25_0 :HG :90 00 19 00 10 00 90 00 21 00 29 00 10 00 90 88 16 00 02 af 
00 88 10 16 00 ff 43 9d 00 90 00 31 00 39 00 10 00

Wie kann ich die Message unterdrücken?
FW120, nur Heizkörper.

Danke und grüße

[Norbert S. (junky-zs)]

Hallo adam,

>Wie kann ich die Message unterdrücken?

Trage den Wert '25' (dezimal) in das python-Modul: lib/ht_discode.py für
Geräteadr (10)hex ein:
Zeilen: 2607 ff
    # device-adr mapped with not valid message-IDs for detailed message
- searching
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 25, 46, 47, 64, 100, 106],
        0x1b: [17, 56, 74, 89],
        0x20: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
        0x21: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
        0x22: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
        0x23: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
    }
Damit wird dann das Telegramm 90 00 19... (hex) unterdrückt.
Der ht_collgate - daemon muss natürlich nach dieser Änderung neu 
gestartet werden.

Gruß Norbert

[adam (Gast)]

Hallo Norbert,

danke, geholfen.

Gruß Adam

[Andre G (Gast)]

Guten abend zusammen,
habe nun einige Zeit diesen Thread und auch noch einen anderen zum Thema 
Junkers und HT3-Bus gelesen.
Selbst bin ich sehr am Projekt interessiert (vorab danke für diese tolle 
Arbeit!). Allerdings habe ich einige Unklarheiten bzw. Unsicherheiten:

1. Ich besitze eine Junkers Cerasmart Heizung mit TA211E und DT-2. Wenn 
ich das richtig lese, wird das HT3-protokoll unterstützt (in den 
anleitungen liest man zwar immer von Heatronic, aber nie von HT3 - gibt 
es hier möglicherweise noch Unterschiede?). Aber habe ich das auch 
richtig verstanden? Kann ich die hier vorgestellte Lösung einsetzen?

2. Linux und Python ist für mich ok, aber löten... das ist immer etwas 
haarig bei mir. Würde mir jemand einen Adapter gegen einen 
entsprechenden Obulus bauen? Das Modul soll dann an meinem rasppi zero w 
arbeiten.

3. Gelesen habe ich, dass das Modul verpolungssicher gebaut ist - d.h. 
also, wenn ich die korrekten Anschlüsse verwende, kann ich nicht 
wirklich was kaputt machen?

4. Ich würde auch gerne die Heizung darüber steuern können. Im Vorfeld 
hatte ich als  Idee, den Außenfühler "abzugreifen". Den Wert kann ich 
dann weiterreichen, oder aber bei Bedarf beeinflussen. Lässt sich diese 
Idee realisieren? Idealerweise mit Funktion bei Ausfall des 
Zwischenmoduls (kann z.b. rpi besimmte gpios im ausgeschalteten zustand 
durchschleifen?)... Ein hohes Ziel, dessen bin ich mir bewusst...


gruß in die Runde und angenehme Resttage vor der Weihnachtszeit!

[Norbert S. (junky-zs)]

Hallo Andre G,

> Ich besitze eine Junkers Cerasmart Heizung mit TA211E und DT-2...
Deine Heizung und der Regler hat wohl keinen Heatronic -Bus. Dies 
entnehme ich den Unterlagen von Junkers für Deine Heizung.

Junkers hat eine Kompatibilitätsliste auf der Web-Seite und auch dort 
ist die 'Cerasmart' Heizung nicht enthalten.
URL mit PDF-File:
https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/waermepumpen_neu_/kompatibilitaetslisten/home_und_multi_home__kompatible_junkers_geraete.pdf

HT3 steht als Abkürzung für: Heatronic in Version 3.
Es gibt da noch Heatronic 4i und für die neuen Heizsysteme mit den 
Cxyz-Reglern und den EMS2 - Bus.
Es muss also ein Bus vorhanden sein, der zumindest Heatronic 3 
entspricht. Heatronic2 geht da also auch nicht.
Die hier vorgestellte Datenerfassung mit den zugehörigen Adaptern 
funktioniert also für alle Heatronic3, Heatronic4i und EMS2-Bussysteme.
Dies sind wohl alle Systeme ab Baujahr 2008.

Leider entspricht Deine Heizung und der zugehörige Regler nicht dem 
Profil.
Zumindest die Junkers-Unterlagen zu Deiner Heizung machen mir da keine 
Hoffnung.

Gruß Norbert

[Andre G. (andre_g929)]

Vielen Dank für dine Mühe.
Interessanterweise spricht zumindest die Anleitung der Steuerung der 
Anlage (TA211e) von Heatronic:
http://www.manderfeld.de/downloads/ta_211e.pdf
die Version des HT-Protokolls ist natürlich nicht angegeben.

Ich glaube, ich schraube das Teil mal auf uznd schaue nach. Denn wenn 
ich das richtig sehe, dann müsste das Modul bei 2-adriger Anbindung auf 
HT3 hinweisen, bei analoger Anbindung wäre es 3-adrig angebunden...

Hab ich denn eine Chance, über Messungen an den Polen herauszufinden, ob 
meine Heizung schon HT3 "spricht"?

gruß und danke schonmal.
andre

[Nils R. (augur)]

Hi,

gibt es eigentlich eine Möglichkeit die Betriebsart "Auto" zu erkennen 
als aktuellen Status eines Heizkreises? Ich würde gerne für die 
Integration in eine Haussteuerung den "Wunschstatus" mit dem echten 
abgleichen und diesen dann versuchen zu setzen. Jedoch gibt es die 
Betriebsart Auto ja nicht in der Statusausgabe.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,
>gibt es eigentlich eine Möglichkeit die Betriebsart "Auto" zu erkennen?
Ja, z.B. mit dem HT3_Analyser und HT3_Systemstatus wird dieser Wert als 
'Betriebsstatus' angezeigt (siehe Bild).
In den zugehörigen Telegrammen wird dieser Wert gesetzt (siehe Bild für 
Fxyz-Regler).

>Ich würde gerne für die Integration in eine Haussteuerung den "Wunschstatus" mit
>dem echten abgleichen und diesen dann versuchen zu setzen.
Ja, dies geht z.B. mit dem Tool:'~/HT3/sw/ht_netclient.py'.
Der Aufruf: ./ht_netclient.py -h zeigt Dir welche Parameter nötig sind.

Der Aufruf: ./ht_netclient.py -b heizen bringt die Heizung in den 
'Manuellen'-Mode.
Der Aufruf: ./ht_netclient.py -b auto bringt die Heizung wieder in den 
'Auto'-Mode.

Du solltest dafür die aktuelle Software Rel. 0.3 verwenden.

Gruß Norbert

@Moderator
Im Bearbeitungsmode lassen sich Bilder (z.B. doppelte) nicht mehr 
löschen.
Sicher lässt sich dies noch verbessern :-)

[Nils R. (augur)]

Hi Norbert,

danke für die Beschreibung. Die Umschaltung habe ich schon am Laufen nur 
aufgrund der Anbindung des PI mit Wlan manchmal das Problem, dass die 
Verbindung nicht klappt.

Daher würde ich gerne den gewünschten Modus mit dem aktuellen in der 
Heizung vergleichen. Derzeit lese ich die aktuellen Parameter aus der 
SQLite DB aus, aber dort konnte ich den Status für "Auto" nicht finden. 
Es wird nur der aktuelle Status in meiner eingesetzten Version 
gespeichert (wenn ich den nicht übersehen habe). Kannst du mir sagen, 
wie ich den Status inkl. "Auto" auslesen kann?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,
der Wert für den Betriebstatus (u.A. 'Auto') steht in der sqlite-DB 
unter 'V_operation_status'.
'Auto' hat für den Fxyz-Regler den Wert: 2.
Diese Namen sind im Konfigurations-File als 'logitem name' festgelegt 
und die Datenbanken werden mit diesem Namen erzeugt.
Der Zusammenhang zum angezeigten GUI-Namen ergibt sich ja aus dem 
logitem.
Somit kannst Du auch andere Daten zuordnen.
Auszug aus dem Konfig-File:
        <logitem name="V_operation_status">
            <datatype>INT</datatype>
            <datause>GAUGE</datause>
            <maxvalue>10</maxvalue>
            <default>0</default>
            <unit></unit>
            <displayname>Betriebsstatus</displayname>
            <accessname>hc1_operationstatus</accessname>
        </logitem>

Bei der Abfrage des Betriebsstatus nach einer Änderung musst Du Dir Zeit 
lassen, weil leider das zugehörige Telegramm nicht sofort nach einer 
Änderung sondern schlimmstenfalls nach 1 Minute gesendet wird.

Gruß Norbert

[Chris (Gast)]

Norbert S. schrieb:
> Junkers hat eine Kompatibilitätsliste auf der Web-Seite und auch dort
> ist die 'Cerasmart' Heizung nicht enthalten.
> URL mit PDF-File:
> 
https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/waermepumpen_neu_/kompatibilitaetslisten/home_und_multi_home__kompatible_junkers_geraete.pdf

Der Link läuft leider ins Leere. Kann jemand die Datei zur Verfügung 
stellen? Ich wüsste gerne, ob meine Heizung unterstützt wird.

[Nils R. (augur)]

Norbert S. schrieb:
> der Wert für den Betriebstatus (u.A. 'Auto') steht in der sqlite-DB
> unter 'V_operation_status'.
> 'Auto' hat für den Fxyz-Regler den Wert: 2.

Aha, das hab ich wohl übersehen. Eigentlich gebe ich mir alle Spalten 
der Datenbank als Webservice aus, um diese in eine Oberfläche 
einzulesen. Bin derzeit immer vom Betriebsart ausgegangen, dass es dort 
drinnen stehen muss. Danke dafür, das probiere ich aus.

Viele Grüße,
Nils

[Markus (Gast)]

Hallo Zusammen,

ist etwas OffTopic, zur Analyse habe ich aber HT3 eingesetzt :-)

Die Heizungspumpe UPM 15-70 die in der Heizung verbaut ist bleibt 
unregelmäßig stehen. Meistens direkt nach der Warmwasserladung.
Danach geht die Heizung auf über 100 Grad, da die Wärme nicht 
abtransportiert wird. Nach dem Abkühlen geht es wieder auf 100 Grad, 
usw.

Ausschalten und neu Einschalten der ganzen Heizung hat die Pumpe dann 
für Tage/Wochen wieder zum Leben erweckt.

Beim letzten Ausfall habe ich die Spannung an der Pumpe gemessen. 
Spannung war da. Stecker im Betrieb bei der Pumpe abgezogen und neu 
aufgesteckt. Pumpe läuft wieder an.

Der Heizungsmonteur hatte noch die Idee die Steuerung an der Pumpe 
abzuziehen. Damit läuft die Pumpe auf 100%, hat aber weiterhin die 
sporadischen Ausfälle.

Ich gehe momentan davon aus, das die Pumpe eine Blockierung feststellt, 
obwohl da keine ist. Wer hat eine bessere Idee?

1. kann ich mit dem ht_netclient.py auch einen Reset durchführen? 
Eventuell kurz in den frost-Modus gehen?

Die Pumpe gibt den aktuellen Betriebszustand an die Heizung zurück. 
http://net.grundfos.com/Appl/WebCAPS/Grundfosliterature-4927111.pdf 
(seite 10.) Kann man das irgendwo abfragen? Oder muss ich da mit einer 
eigenen Schaltung dran? Im Display der Buderus sehe ich keine 
Fehlermeldung.


Grüße

[Hans (Gast)]

Hallo zusammen,

ich habe ein Problem mit meiner HT3-Datenerfassung. In unregelmäßigen 
Abständen (gefühlsmäßig nach einem viertel Jahr) friert die 
Datenerfassung einfach ein. Es werden keine aktuellen Daten mehr 
angezeigt. Im Browser werden zwar noch die Diagramme geöffnet, leider 
ohne Historie und aktuellen Daten (siehe Anhang). Das Datum steht dann 
auch in der Vergangenheit. Per SSH kann ich noch auf den Pi zugreifen 
und einen Reboot durchführen. Aber leider funktioniert die 
Datenerfassung danach auch nicht. Bisher habe ich dann schon zwei Mal 
den Pi komplett neu aufgesetzt. Das ist auf Dauer ein klein wenig 
nervig. Habe nur ich das oben geschilderte Problem? Wie kann ich die 
HT3-Erfassung wieder zum Leben erwecken?
Wie sichert bzw. Werte Ihr die Daten auf dem PI aus  ?

Wünsche Allen frohe Ostern

Hans

[Klaus (Gast)]

@Hans

Ich habe von Anfang an ein ähnliches Problem. Nach einer gewissen 
Laufzeit von ein paar Monaten bekommt die Aufzeichnung immer mehr 
Lücken.
Ich muss dann immer die sqlite DB wegkopieren bzw. löschen.
Nach einem Neustart wird die DB wieder leer angelegt und es läuft wieder 
ein paar Monate.
Ob es sich um denselben Effekt handelt kann ich dir leider nicht sagen. 
Müssten eigentlich alle haben dieses Problem. Oder es liegt an einer 
bestimmten Version. Vielleicht meldet sich ja der Norbert noch.

Klaus

[Hans (Gast)]

Hi Klaus,

Dankeschön für die Info. Werde ich am Wochenende mal ausprobieren.

Viele Grüße

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

bin mir nicht sicher ob Du die sqlite-DB aktiviert hast (per default ist 
diese aus). Falls ja dann würde ich wie von Klaus beschrieben die 
sqlite-DB neu aufsetzen (erzeugen).
Ich gehe auch davon aus, das Du das letztgültige Software-Releae: 0.3 
installiert hast.

Nach längerer Zeit kann die DB doch recht gross werden und der Pi hat 
damit dann mächtig zu tun.
Wenn die sqlite-DB aktiviert wurde so werden Daten älter als 30 Tage 
normalerweise aus der DB gelöscht, Eintrag:
 (<autoerase_olddata>30</autoerase_olddata>)
im Konfigurationsfile.

Ich vermute jedoch das Du die sqlite-DB nicht aktiv hast.
Wenn dem so ist liegt wohl noch ein anderes Problem vor.

Bitte kontolliere im Fehlerfall mal das /tmp Verzeichnis. Wenn dort sehr 
viele perl-scripte (*.pl) liegen bleiben so werden die Daten nicht in 
die rrdtool-db eingetragen.
Diesen Fall hatte ich schon mal, der aber nach einem reboot des PI 
wieder behoben war.
Eine Neuinstallation war nicht nötig gewesen.

Beachte bitte auch das nach einem reboot die Datenerfassung erst neu 
aufgesetzt wird und erst nach ca. 5 -10 Minuten wieder Daten in den 
Anzeigen zu sehen sind.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Markus (Gast),

> kann ich mit dem ht_netclient.py auch einen Reset durchführen?
> Eventuell kurz in den frost-Modus gehen?
Einen Reset kann man nur auf den ht_pitiny-Adapter ausführen jedoch 
nicht auf die Heizung und deren Module.

> Die Pumpe gibt den aktuellen Betriebszustand an die Heizung zurück.
> Kann man das irgendwo abfragen?
In den 'normalen' Betriebstelegrammen habe ich dafür noch keinen 
Platzhalter gefunden.

> Im Display der Buderus sehe ich keine Fehlermeldung.
Wenn der Fehler weg ist findet man diesen in der Historie. Je nach 
Regler wird dieser Wert abgespeichert und sichtbar (in der 
Fachman-Ebene).

Es sollte ein Fehler angezeigt werden wenn die Steuerung der Pumpe 
abgezogen ist. Zumindest gibt es dafür einen Fehlertext.
Dies wird je nach Heizgerät in der Heizungssteuerung gemacht. Falls also 
doch kein Fehler zu finden ist erkennt die Heizung auch das Blockieren 
der Pumpe nicht.

Wie in Deinem Bild zu sehen hast Du ja schon mehrfach die Rotor 
Abdeck-Schraube gelöst.
Ist im Fehlerfall der Pumpen-Rotor leicht zu drehen oder sitzt der 
mechanisch fest?
Hat der Heizungsfachmann auch schon mal das 3-Wege Umschaltventil 
kontrolliert?
(Dies sollte allerdings funktionieren, sonst hättest Du schon lange 
kalte Füsse oder kaltes Wasser erhalten :-)

Wenn alle Stricke reissen so würde ich die Pumpe ersetzen. Diese ist 
billiger als ein neuer Wärmetauscher.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

zum Thema: Blockieren von Heizungspumpen nach längerer Stillstand-Zeit 
noch ein Hinweis:
Es ist sinnvoll das Heizgerät im Sommer nicht auszuschalten, da viele 
der Junkers-Heizgeräte einen Blockierschutz in der Steuerung haben.
Diese sorgt dafür das die Pumpen und das 3-Wege Ventil ab und zu 
betrieben werden und sich dann nicht festsetzen.

Gruß Norbert

[Nils R. (augur)]

Moin,

ich hab mal mein Raspi aktualisiert und das Problem, dass ich mit 
ht_netclient nicht mehr auf den Bus schreiben kann. Ich erhalte die 
Meldung csocketsendThread();Error on socket.send

Das Aufzeichnen von Werten klappt einwandfrei. Ich habe auch alles als 
Modem konfiguriert, anbei ein Screenshot eines neuen Logs. Hab keine 
Idee mehr woran es liegen könnte.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> Ich erhalte die Meldung csocketsendThread();Error on socket.send
Diese Meldung ist vom 'ht_proxy.server'. Der Grund der Meldung ist aber 
daraus nicht ersichtlich.
Da sich die Software des 'ht_proxy.servers' seit ca. 3 Jahren nicht 
geändert hat muss ein Zusammenhang mit den anderen 'Aktualisierungen' da 
sein.

Welche Aktualisierungen hast Du durchgeführt (neues OS, Raspi etc.)?

Gruß Norbert

[Nils R. (augur)]

Hi Norbert,

ich hatte noch eine uralte Version der Software (frühe Version mit 
Proxy) am laufen auf einem Wheezy. Am Jahresanfang hab alles mal 
aktualisiert und die Konfiguration neu gemacht und dann liegen gelassen, 
weil ich noch die DB auf einen USB Stick ziehen wollte.

Seitdem bekomme ich das Schreiben auf den Bus nicht mehr hin. Die 
Hardware ist aber gleich geblieben. Dachte eigentlich es liegt an der 
Konfiguration, aber ich denke die müsste stimmen.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

>ich hatte noch eine uralte Version der Software.
>Am Jahresanfang hab alles mal aktualisiert und ...

Dann hast Du wahrscheinlich jetzt folgende Software im Einsatz ?:
OS: 'Stretch'
HT3: Rev.: 0.3 von github

In diesem letztgültigen Release hat sich zwar der 'ht_proxy.server' 
nicht geändert aber viele andere Module in der Library sind angepasst 
worden.

Einige ältere SW-Module sind entfallen. Dazu bitte auf github das readme 
und die Projekt-Doku lesen. Dort sind die Änderungen beschrieben.
URL: https://github.com/norberts1/hometop_HT3

Gruß Norbert

[Peter (Gast)]

Hallo!
Ich habe würde meine Junkerstherme gerne mit Openhab verbinden. Hat 
jemand vielleicht schon das ganze in Openhab inplementiert? Musste dazu 
ein Modul programmiert werden?

LG Peter

[Juri K. (iuser)]

Hallo Peter,

ja, ich habe es gemacht - das geht ganz normal über die MQTT Anbindung.

Hier sind ein Paar Beispiele:

Number ht3_ch_Treturn        "T. Ist (Rücklauf) [%.1f°C]"      <dryer> 
(Junkers)        { mqtt="<[broker:hometop/ht/ch_Treturn:state:default]"}
Number ht3_ch_Tflow_measured    "T. Ist (Vorlauf) [%.1f°C]" 
<dryer>  (Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_Tflow_measured:state:default]"}
Number ht3_ch_Tflow_desired      "T. Soll (Regelung). [%.1f°C]" 
<dryer>  (Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_Tflow_desired:state:default]"}
Number ht3_ch_Toutside        "T. Aussen [%.1f°C]"          <dryer> 
(Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_Toutside:state:default]"}
Number ht3_ch_T3waymixer      "T. 3Wege Mischer [%.1f°C]"        <dryer> 
(Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_T3waymixer:state:default]"}

Gruß
Juri

[Martin S. (matz666)]

Das ganze funktioniert bei mir über die MQTT Schnittstelle.

Items entsprechend programieren.

Schaltvorgänge über eine Rule.

Mfg

Martin

[Martin S. (matz666)]

Hier noch die Rule.

Z.B zum Modus HK verstellen.

rule "HK1 Modus"
when
  Item hk1modi changed
then
  if (hk1modi.state ==0) publish 
("mosquitto","set/ht3/hc1_Tniveau","auto")
  if (hk1modi.state ==1) publish 
("mosquitto","set/ht3/hc1_Tniveau","frost")
  if (hk1modi.state ==2) publish 
("mosquitto","set/ht3/hc1_Tniveau","sparen")
  if (hk1modi.state ==3) publish 
("mosquitto","set/ht3/hc1_Tniveau","heizen")
end

Viel Spaß!!! Bei Fragen melde.

Lg
Matz

[Nils (Gast)]

Norbert S. schrieb:
> Dann hast Du wahrscheinlich jetzt folgende Software im Einsatz ?:
> OS: 'Stretch'
> HT3: Rev.: 0.3 von github

Hi,

hab jetzt alles neu installiert und bis auf den blöden Terminal-Service 
auf dem Interface alles direkt zum Laufen bekommen. Da hat wohl was mit 
dem update nicht geklappt, jetzt hab ich eine schöne neue Umgebung. :-)

Viele Grüße,
Nils

[Thorsten W. (thorsten_w197)]

Hallo Norbert,

ich nutze jetzt seit längerem deine Software mit einem passiven 
Selbstbauadapter zum Auslesen meiner Heizung.

Klappt prima - seit 2 Tagen auch mit MQTT und FHEM.

Eine Frage habe ich dennoch - kann das Intervall in dem die Werte kommen 
irgendwie angepasst werden?

Gruß,
Thorsten

[Nils (Gast)]

Norbert S. schrieb:
> In diesem letztgültigen Release hat sich zwar der 'ht_proxy.server'
> nicht geändert aber viele andere Module in der Library sind angepasst
> worden.

Hi,

habe alles neu Aufgesetzt und leider kann ich noch immer nicht auf den 
Bus schreiben. Ich hab hier auch davon gelesen, dass andere auch mal das 
Problem hatten wenn 2 Clients angemeldet waren. Hast du noch eine Idee 
dazu, ich komme nicht mehr weiter.

Viele Grüße,
Nils



12.11.2018 22:44:08 INFO: cht_proxy_daemon init
12.11.2018 22:44:08 INFO: cht_proxy_daemon(); common serveraddress used
12.11.2018 22:44:08 INFO: cht_proxy_daemon start as 
proxy-server:'';port:'8088'
12.11.2018 22:44:08 INFO: logfile:'./var/log/ht_proxy.log'
12.11.2018 22:44:08 INFO: cportwrite();thread start; devicetype:MODEM
12.11.2018 22:44:08 INFO: cportread() ;thread start; devicetype:MODEM
12.11.2018 22:44:10 INFO: Client-ID:1; ('127.0.0.1', 56166) connected
12.11.2018 22:44:10 INFO: Server   :('0.0.0.0', 8088)
12.11.2018 22:44:10 INFO: Client-ID:1; register(); got devicetype:RX
12.11.2018 22:44:10 INFO: csocketsendThread(); socket.send thread start
12.11.2018 22:44:10 INFO: Client-ID:1; added; number of clients:1
12.11.2018 22:44:10 INFO: Client-ID:1; cht_RequestHandler(); 
socket.receive thread start
17.11.2018 09:56:00 INFO: Client-ID:2; ('127.0.0.1', 56332) connected
17.11.2018 09:56:00 INFO: Server   :('0.0.0.0', 8088)
17.11.2018 09:56:00 INFO: Client-ID:2; register(); got devicetype:MODEM
17.11.2018 09:56:01 INFO: csocketsendThread(); socket.send thread start
17.11.2018 09:56:01 CRITICAL: csocketsendThread();Error on socket.send
17.11.2018 09:56:01 INFO: Client-ID:2; added; number of clients:2
17.11.2018 09:56:01 INFO: Client-ID:2; cht_RequestHandler(); 
socket.receive thread start
17.11.2018 09:56:01 INFO: Client-ID:2; ('127.0.0.1', 56332) disconnected
17.11.2018 09:56:01 INFO: Client-ID:2; removed; number of clients:1
17.11.2018 09:56:01 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
17.11.2018 10:00:49 INFO: Client-ID:3; ('127.0.0.1', 56334) connected
17.11.2018 10:00:49 INFO: Server   :('0.0.0.0', 8088)
17.11.2018 10:00:49 INFO: Client-ID:3; register(); got devicetype:MODEM
17.11.2018 10:00:49 INFO: csocketsendThread(); socket.send thread start
17.11.2018 10:00:49 INFO: Client-ID:3; added; number of clients:2
17.11.2018 10:00:49 INFO: Client-ID:3; cht_RequestHandler(); 
socket.receive thread start
17.11.2018 10:00:49 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
17.11.2018 10:01:01 INFO: Client-ID:3; ('127.0.0.1', 56334) disconnected
17.11.2018 10:01:01 INFO: Client-ID:3; removed; number of clients:1
17.11.2018 10:01:01 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
17.11.2018 10:02:20 INFO: Client-ID:4; ('127.0.0.1', 56336) connected

[Nils (Gast)]

Hab hier das gleiche Problem gefunden: 
https://forum.fhem.de/index.php/topic,19445.255.html

[Norbert S. (junky-zs)]

Hallo Thorsten,
Thorsten W. schrieb:
> Klappt prima - seit 2 Tagen auch mit MQTT und FHEM.
>
> Eine Frage habe ich dennoch - kann das Intervall in dem die Werte kommen
> irgendwie angepasst werden?
Ein Intervall kann nur für die rrdtool-db Daten konfiguriert werden.
    <rrdtool-db>
      <enable>on</enable>
      <step_seconds>60</step_seconds>
Bei der MQTT-Schnittstelle werden nur die sich ändernden Werte gesendet.
Bei FHEM muss man das Notify konfigurieren. Wie das geht bitte im 
FHEM-Thread nachsehen.
Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Nils,
Nils schrieb:
> Ich hab hier auch davon gelesen, dass andere auch mal das
> Problem hatten wenn 2 Clients angemeldet waren.
Module mit gleicher Geräte-Adresse am gleichen Heizungs-Bus machen 
Probleme.
Dies betrifft alle Module am Bus: MBLan2 und ht_pitiny/ht_piduino haben 
per Default die gleiche Geräte-Adresse. Diese kann man jedoch beim 
ht_pitiny/ht_piduino ändern. Siehe die Doku dazu.
Wer kein MBLan2 am Bus hat braucht nichts zu ändern!
Jedoch wer zwei ht_pitiny / ht_piduinos am gleichen Bus betreibt muss 
einen davon auf eine andere Adresse einstellen.
Wer 'nur' einen passiven Adapter (HT3_Mini- / HT3_Micro-Adapter) hat 
braucht sich darum keine Gedanken machen.

Nils schrieb:
> habe alles neu Aufgesetzt und leider kann ich noch immer nicht auf den
> Bus schreiben.
Der Empfang geht ja wohl jetzt wieder !?
Es werden sicher auch Grafiken der rrdtool-db angezeigt?
Da Du ja einen 'aktiven' Adapter hast (ht_pitiny/ht_piduino) 
kontrolliere mal die LED's, insbesondere die Rote LED. Die muss 
kurzzeitig aufblitzen (auch ohne Befehle zum Bus).
Du kannst auch die Debug-Ausgaben des ht_proxy.servers aktivieren im 
ht_proxy.py File:
-->> ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile, 
loglevel=logging.DEBUG)
 # ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile)
Wichtiger Hinweis:
 Der ht_proxy.Server muss VOR allen anderen ht_applikationen gestartet 
werden wenn manuelle Eingriffe gemacht werden.
Beim reboot wird dies automatisch durch die Scripte erzielt.

Nils schrieb:
> Hab hier das gleiche Problem gefunden:
> https://forum.fhem.de/index.php/topic,19445.255.html
Die von mir dort gemachten Hinweise / Empfehlungen hast Du durchgeführt?

Gruß Norbert

[Nils (Gast)]

Hi Norbert.

Ja, das hab ich durch. Die Adresse ist es nicht, da es ja schon mal 
lange reibungslos lief, bis ich an der Software gefummelt habe. Hab aber 
alles mal geprüft und diese auch neu gesetzt.

Die rote Led blickt vereinzelt. Anbei mal ein Debuglog, vielleicht 
siehst du was. Ich versuch es auch mal weiter.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,
die im Debuglog des ht_proxy (ht_proxy.log) enthaltenen Sendebytes sind 
OK. Siehe dazu auch:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Die Sequence ist also nicht der Grund warum Du die Heizung nicht steuern 
kannst. Es sei den Du hast einen Neuen Heizungs-Regler, aber dem ist ja 
wohl nicht so.

Kontrolliere bitte mal ob der alte Prozess 'HT3_logger.py' noch durch 
den init gestartet wird. Es ist ein Logfile dazu in Deinem ZIP-File 
(ht_logger.log) enthalten.
Das wäre dann nicht gut, weil der alte überflüssige Prozess dann auch 
zusätzlich die gleichen Daten in die Datenbanken schreibt.
Es wird ja nur noch der ht_collgate.py benötigt. Falls nötig in 
/etc/init.d deaktivieren.

Gruß Norbert

[Nils (Gast)]

Norbert S. schrieb:
> Es sei den Du hast einen Neuen Heizungs-Regler, aber dem ist ja
> wohl nicht so.
>
> Kontrolliere bitte mal ob der alte Prozess 'HT3_logger.py' noch durch
> den init gestartet wird. Es ist ein Logfile dazu in Deinem ZIP-File
> (ht_logger.log) enthalten.

Hi,

der HT3_logger läuft nicht. Den hatte ich testweise nur mal gestartet. 
Der Heizungsregler ist auch schon Jahre drinnen. Vielleicht mach ich den 
einfach mal aus... :-) Das probiere ich mal stumpf.

Viele Grüße,
Nils

[Nils (Gast)]

Hi,

hab mal so viel wie möglich an Services abgeschaltet und konnte ein 
interessantes Verhalten feststellen. Wenn ich den ht_proxy neustarte 
wird das erste Kommando mit ht_netclient korrekt übertragen. Alle 
weiteren scheitern. Wenn ich also vor jeder Modusänderung den ht_proxy 
neustarte funktioniert es. Kannst du damit was anfangen? M.E. sollte es 
damit nicht direkt an der Konfiguration oder Verkabelung liegen, oder?

Viele Grüße,
Nils

[Nils R. (augur)]

Moin,

keine Idee dazu?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

Nils schrieb:
> M.E. sollte es
> damit nicht direkt an der Konfiguration oder Verkabelung liegen, oder?
An der Hardware (Verkabelung, Rapsi, ht_Adapter) hast Du ja nichts 
geändert nehme ich mal an und somit wird wohl eine andere Ursache 
vorliegen.

> Wenn ich den ht_proxy neustarte wird das erste Kommando mit ht_netclient
> korrekt übertragen. Alle weiteren scheitern.
Kontrolliere bitte die LED's auf dem ht_pitiny-Adapter. Wenn die 
rote-LED nach dem Senden ständig/konstant leuchtet liegt ein Fehler vor. 
Siehe dazu auch die Beschreibung unter:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Ich glaube Du hast noch ein MBlan2 parallel am Bus. Klemm das mal bitte 
testehalber ab und prüf dann die Sendefunktion mit dem ht-Adapter.

Welche HW/SW verwendest Du?:
1. Raspi A/B/B3 mit Linux 'stretch'?
2. Junkers Regler Fxyz und Fertigungsdatum (wird sich wohl nicht 
geändert haben)
3. MBLan2 parallel am Heizungsbus und verbunden mit Cloud?
4. ht-Adapter muss auf andere Adresse als MBLan eingestellt sein (ist 
aber ja wohl schon so, siehe oben)

Hast Du das Software-Release 0.3.1 komplett neu installiert und die 
Datenbanken neu erzeugt?

Gruß Norbert

[Nils R. (augur)]

Welche HW/SW verwendest Du?:
1. Raspi A/B/B3 mit Linux 'stretch'?  Ja, Raspi B
2. Junkers Regler Fxyz und Fertigungsdatum (wird sich wohl nicht
geändert haben)  FW200 - ist gleich
3. MBLan2 parallel am Heizungsbus und verbunden mit Cloud? Ja, geht aber 
auch nicht ohne
4. ht-Adapter muss auf andere Adresse als MBLan eingestellt sein (ist
aber ja wohl schon so, siehe oben) - Ja, ist er

Hast Du das Software-Release 0.3.1 komplett neu installiert und die
Datenbanken neu erzeugt? Ja


Kontrolliere bitte die LED's auf dem ht_pitiny-Adapter. Wenn die
rote-LED nach dem Senden ständig/konstant leuchtet liegt ein Fehler vor.

Leuchtet nicht konstant...hab aber gerade am Kabel rumgebastelt, um den 
Bus zu verkürzen, da ist sie auf rot gegangen und der FW200 hat 
gemeckert.


Aktueller Stand: Ich musste ein Backup einspielen, weil die SD Karte 
irgendwie aufgegeben hat und nun funktioniert auch die Aufzeichnung 
nicht mehr. :-(

[Tamas B. (atom327i)]

Hallo Zusammen,
ich möchte um Eure Hilfe bitten.
(Sorry, mein Deutsch ist nicht so schön :()

Ich versuche meine Bosch EMS2 system zu loggebn.
Zuerst möchte ich an Norber S. für die riesige Arbeit eine große Danke 
sagen!

Ich Möchte HT3 logger nur für meine Heizungsoptimalization verwenden. 
Ich brauche keine Sendefunktion, keine Datenbank, keine IP Netzwerk, 
usw.
Requirement: Botschaft-> Temperaturwerten (soll, ist), Pumpenstatus, 
Gasverbrauch zu konvertieren.

Um es einfacher zu machen, ich probierte die KomplettSW-Umgebung zu 
verwenden.

Mein Problem ist: ich besitze kein Raspberry Pi, und ich möchte auch 
mich nicht in Linux Einarbeiten. (mein Schuld)

Ich möchte aber das ganze Zeug irgendwie unten Windows in betrieb 
nehmen.
Positiv: HW habe ich gebaut, mit USB-COM schnittstelle ich bekomme mit 
Terminal SW die EMS Daten richtig.

Von SWher: ich habe Perl Python, SQlite installiert, und hoffentlich 
auch RRDtool richtig installiert.

Bei create_dtebase.py ich kann RRD Datebase nicht erzeugen lassen. Es 
wird kein perl script erzeugt. (str: \\tmp\\rrdtool_dbcreate.pl) sonst 
kommt Exception, db_rrdtool.createdb_rrdtool();Error;<2>
Warum kann es potentiell so sein?

Ich möchte mal fragen: kann ich irgendwie eine Übersetzungstabelle in 
dem Projekt finden, womit ich einfach Serielldaten direkt nach 
Physikalische Werten umrechnen kann? Es wäre für mich ganz genug, und 
einfach in Excel csv zu schreiben. (wie DBC für CAN oder LDF für LIN bus 
in Automotiv)

Mein Hintergrund: ich arbeite in Automotivbereich als SW Expert, mit 
mehr als 20 Jahren Embedded SW, HW Erfahrung (C, C++). Ich habe aber 
kein Erfahrung (noch :)) mit Python, und auch kein mit dem Linux.

Also Danke im Voraus!
Gruß,
Tamas

[Norbert S. (junky-zs)]

Hallo Tamas,

Tamas B. schrieb:
> Bei create_dtebase.py ich kann RRD Datebase nicht erzeugen lassen. Es
> wird kein perl script erzeugt. (str: \\tmp\\rrdtool_dbcreate.pl) sonst
> kommt Exception, db_rrdtool.createdb_rrdtool();Error;<2>
> Warum kann es potentiell so sein?
Der Fehler:Error;<2> bedeutet:
ERROR_FILE_NOT_FOUND -> The system cannot find the file specified.
Dies deutet auf falsche Pfade zum Filesystem hin, leidige Thema: '\' und 
’/'.
Das aktuelle SW-Release ist noch NICHT für Windows angepasst.

Vorhandene Software für Windows / Linux (python) unter:
Beitrag "Re: Heatronic 3 Adapter und Analysesoftware"
Dies ist allerdings eine ältere Version mit einer GUI-Ausgabe.

Software für Windows und Junkers-Heizung gibt es auch unter:
www.fhem.de
und der zugehörige Beitrag unter:
https://forum.fhem.de/index.php/topic,19445.msg883929.html?PHPSESSID=4kitu415rj51blpplt28emsfq2#msg883929

Tamas B. schrieb:
> Ich versuche meine Bosch EMS2 system zu loggebn.
Die hier vorhandene Software arbeitet mit 'Junkers Heatronic/EMS2(c)' 
Telegrammen und passt nicht zu Buderus (Bosch) EMS2.
Es ist beides mal zwar EMS2, aber die Telegramme zwischen Junkers- und 
Buderus-Heizungen sind unterschiedlich.
Damit die Verwirrung noch optimaler wird, heissen ab 2017 die ehemals 
Junkers Cxyz-Regler auch Bosch Cxyz-Regler.
Bitte kläre also welche Heizung von welchem Hersteller Du betreibst.
Die Telegramme und die Auswertung hängen davon ab.

Tamas B. schrieb:
> Positiv: HW habe ich gebaut, mit USB-COM schnittstelle ich bekomme mit
> Terminal SW die EMS Daten richtig.
Du kannst ja diese empfangenen Daten binär in ein File schreiben und 
hier posten. Das kann ich dann auswerten.

Gruß Norbert

[leinado (Gast)]

Hallo,
vielen Dank zunächst einmal an diesem tollen Projekt.
Ich habe es Dank der guten Dokumentation hingekriegt das alles mit dem 
Raspberry pi3 b+ und dem selbstgebauten Miniadapter ans Laufen zu 
kriegen, obwohl ich kaum Linux und Programmierkenntnisse habe.

Was mir jetzt noch fehlt, ist die Anzeige für meinen wassergeführten 
Kaminofen, also die Kesseltemperatur und Pumpe ein bzw aus.
Mein Heizungssystem: Junkers mit FW200, ISM2 UND IPM1.
Auf der FW200 wird die Kesseltemperatur des Kaminofens unter Solar - 2. 
Kollektorfeld angezeigt.

Meine Frage ist nun, wie ich das am besten machen könnte?
Habe gedacht, ob ich vielleicht die bei mir ungenutzte Anzeige für den 
2. Herzkreislauf nehmen könnte? Also quasi nur etwas modifizieren und es 
zeigt bei mir da den Kaminofen an.

Währe nett, wenn mir da jemand Tipps geben könnte. Ich habe da etwas 
Angst alles kaputt zu machen, so dass nichts mehr läuft.

Liebe Grüße
Daniel

[Norbert S. (junky-zs)]

Hallo Daniel,

leinado schrieb:
> Was mir jetzt noch fehlt, ist die Anzeige für meinen wassergeführten
> Kaminofen,...
> Habe gedacht, ob ich vielleicht die bei mir ungenutzte Anzeige für den
> 2. Herzkreislauf nehmen könnte?
Dies würde ich nicht empfehlen, da die Heizkreise ja Wärme-Senken sind 
und der Kessel ja eine Wärme-Quelle.
Daher wird ja an Deinem Regler dieser auch unter Solar angezeigt (was 
auch immer sich Junkers dabei gedacht hat).
Daher mein Vorschlag dies ebenfalls als zweite bzw. n'te Wärmequelle 
unter Solar anzeigen lassen, zumal es dort noch freie 'Spare' Logitems 
gibt.
Die Anzeige ist also kein Problem.

Bleibt noch die Dekodierung der richtigen Daten aus dem richtigen 
Telegramm(en).
Es wird wahrscheinlich ein Telegramm vom ISM2 Modul sein (B0 00 FF 00 
...).
Dies kannst Du dir im HT3_Analyser ansehen oder besser wäre es wenn Du 
ein Binärfile von den Telegrammen erstellst (<= 1 Std. mit Angaben der 
Kesseltemperatur/Zeitpunkt).
Binär-Logfile erstellen mit z.B.:
 cd ~/HT3/sw
 ./ht_binlogclient.py <meinlogfile.log>
Kannst Du an meine PM senden oder hier posten.

Gruß Norbert

[leinado (Gast)]

Hallo Norbert,
vielen Dank für deine Hilfe!
Ich habe gerade mal ein Logfile erstellt. Ich hoffe ich habe das richtig 
gemacht, sonst mache ich das gerne nochmal.
Logfile habe ich als Datei angehängt.
Zeitstempel:
Zeit  Temperatur  Pumpe
0:00  72,7    an
0:01  72,6    an
0:03  72,4    an
0:05  72,2    an
0:06  72,1    an
0:06  72,4    an
0:09  72,5    an
0:10  72,6    an
0:12  72,6    aus
0:13  74,6    aus
0:13  74,8    aus
0:13  75,9    an
0:14  76,8    an
0:14  77,7    an
0:14  78,8    an
0:15  79,7    an
0:15  79,3    an
0:15  78,2    an
0:16  77,0    an
0:16  75,9    an
0:16  74,9    aus

Ich hoffe 16 Minuten sind ausreichend, sonst mache ich das gerne länger.
Damit die Pumpe für den Kreislauf zwischendurch auch mal ausgeht, habe 
ich den Temperatursensor vom Pufferspeicher unten mal kurz oben am 
Speicher reingesteckt. Vielleicht kannst du so auch die Pumpe finden.

Gruß Daniel

[Norbert S. (junky-zs)]

Hallo Daniel,
leinado schrieb:
> Ich hoffe 16 Minuten sind ausreichend, sonst mache ich das gerne länger.
Das reicht völlig, danke für das Logfile und die gute Beschreibung der 
Werte :-)
Hinweis:
Die Systemzeit der Heizung ist um ca. 14Minuten anders als Deine 
Angaben.
Die Auswertung beeinflusst dies aber nicht.

Habe die Anpassungen in die Dekodierung eingebracht und auch die 
rrdtool-Grafik Anzeige erweitert.
Es wird jetzt ein weiterer Graph für '2.Waermequelle' angezeigt wenn die 
zugehörigen Telegramme und Werte von der Heizung gesendet werden.

Die Software ist noch nicht ganz rund, werde diese aber zeitnah auf 
github als neues Release veröffentlichen. Will damit weitere 
Test-Releases mit verschiedenen Zwischenständen hier im Forum vermeiden.

Wenn das Release soweit fertig ist kannst Du es ja auf Deine spezielle 
coole (heisse) Heizung hetzen :-)

Gruß Norbert

[leinado (Gast)]

Hallo Norbert,
vielen vielen Dank. :-)
Da bin ich schon sehr gespannt.
Gruß Daniel

[Norbert S. (junky-zs)]

Hallo @all,

eine neues Release (0.3.1) ist auf github vorhanden.
Dies am besten als komplettes Paket laden mit:
 git clone https://github.com/norberts1/hometop_HT3.git

Es sind im Wesentlichen weitere Dekodierungen für die Cxyz-Regler 
hinzugekommen und zusätzliche Anzeigen für die Temperatur an der 
Hydraulischen Weiche (falls vorhanden) und eine zusätzliche grafische 
Ausgabe für Werte der Solaranlage (2.Kollektor-Anlage).
Diese Anzeigen sind so weit als möglich dynamisch gehalten und wer diese 
Systemanteile nicht hat wird diese Anzeigen auch nicht erhalten bzw. 
sind diese Werte auf 0 gesetzt.

Vorhandene Datenbanken aus dem Release 0.3 können weiterhin verwendet 
und müssen nicht neu erzeugt werden.

leinado schrieb:
> Da bin ich schon sehr gespannt. Gruß Daniel
Bitte teste dieses Release an Deiner Anlage, die Werte für Deinen 
wassergeführten Kaminofen (Temperatur und Pumpe) sollten in der 
Zusatzgrafik (2.Waermequelle) angezeigt werden.

Gruß Norbert

[leinado (Gast)]

Hallo Norbert,
vielen Dank für deine Mühe. Es funktioniert leider bei mir noch nicht so 
richtig. Wahrscheinlich habe ich irgendwo einen Fehler gemacht. Deswegen 
erkläre ich mal Schritt für Schritt was ich gemacht habe.
1. Ich habe das komplette Paket geladen. Der Ordner hometop_HT3 lag dann 
in /home/pi
2. Ich habe den Order /home/pi/hometop_HT3/HT3 kopiert und in 
/home/pi/HT3 eingefügt und dabei alle Dateien überschrieben.
3. ich habe HT3_Analyser.py aus /home/pi/HT3/sw gestartet und mich 
riesig über das Ergebnins gefreut. Jetzt wurde 2. T-Kollektor und 2. 
Pumpe angezeigt.
4. die *.png in /home/pi/HT3/sw/etc/html wurden regelmäßig aktualisiert 
und Heizkreis 1 zeigte nun zusätslich die Mischertemperatur an :-)
Leider fehlte noch das png für den 2. Kollektor

bis hierhin also alles fast gut

5. Nach einem Reboot kamen bei dem HT3_Analyser.py nun leider aber keine 
Daten mehr rein. Und auch die *.png wurden nicht mehr aktualisiert.
mit sudo minicom -b 9600 -o -D /dev/ttyAMA0 konnte ich aber sehen, dass 
weiterhin Daten rein kamen.
6. Ich habe dann alle Dateien aus einer Sicherungskopie wieder in 
/home/pi/HT3 geschrieben und nach einem Reboot funktionierte wieder 
alles auf Anhieb wie vorher.
7.Habe alle oben genannten Punkte 3 mal wiederholt mit identischem 
Ergebnis.

Jetzt habe ich gerade beim Schreiben dieses Textes gemerkt, dass ich ja 
noch die Baudrate in der  ht_proxy_cfg.xml anpassen muss. Und endlich 
jetzt funktioniert der HT3_Analyser.py auch nach einem Reboot in der 
neuen Version und zeigt 2. T-Kollektor und 2. Pumpe :-)
Auch die *.png werden nun fleißig aktualisiert. Es fehlt leider noch das 
HT3_Solar_second.png
Aber da habe ich wahrscheinlich auch noch irgendwo einen Fehler gemacht.

Mir ist aufgefallen, dass es manchmal ca 5 Minuten dauert, bis 2. 
T-Kollektor und 2. Pumpe in dem HT3_Analyser.py angezeigt werden. Alle 
anderen Werte kommen viel eher.

Liebe Grüße
Daniel

[Norbert S. (junky-zs)]

Hallo Daniel,

leinado schrieb:
> Es fehlt leider noch das HT3_Solar_second.png
Um dem auf die Spur zu kommen aktiviere mal die Debugausgaben im 
Konfigfile: HT3_db_cfg.xml und starte den ht_collgate.py neu.
     <loglevel>DEBUG</loglevel>
Nach > 5 Minuten solltest Du eine Debugausgabe für den rrdtool.draw 
sehen etwa so:
DEBUG: cdb_rrdtool.create_draw();
         path2db  :/home/pi/HT3/sw/var/databases;
         path2draw:/home/pi/HT3/sw;
         hc_count:2;
         Contr.type:2;
         mixer_flags:[1, 1, 1, 0];
         hydrlic_sw:0;
         solar_flag:1;
         second_source:1
DEBUG: /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 
0 1 1

Wichtig sind ja dabei für Dich die Flags: 'solar_flag:1' und 
'second_sorce:1'. Beide müssen auf 1 sein, damit HT3_Solar_second.png 
geschrieben wird.
Du kannst dieses Perl-Sript auch direkt mit den nötigen Parametern 
manuell aufrufen. Wichtig sind die richtigen Pfade und das die Anzahl 
und die Werte der Parameter korrekt sind (siehe oben).
Also z.B.:
cd ~/HT3/sw/etc
./rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 0 1 1
Je nach vorhandenem Controller-Type musst Du da dann halt eingeben:
1 := Fxyz Controller
2 := Cxyz Controller

> Mir ist aufgefallen, dass es manchmal ca 5 Minuten dauert, bis 2.
> T-Kollektor und 2. Pumpe in dem HT3_Analyser.py angezeigt werden. Alle
> anderen Werte kommen viel eher.
Ja, einige der Telegramme kommen seltener. Ganz extrem ist z.B.: der 
Solarertrag (Tag/Summe bei Cxyz-Controllern). Der kommt wirklich nur 
einmal die Stunde.

Gruß Norbert

[leinado (Gast)]

Norbert schrieb:
>Nach > 5 Minuten solltest Du eine Debugausgabe für den rrdtool.draw sehen

Wo genau sehe ich die Debugausgabe? Unter /home/pi/HT3/sw/var/log 
vielleicht? Da habe ich aber nirgendwo etwas entsprechendes gefunden.

[leinado (Gast)]

Ich habe es heute nochmal versucht aber das mit der Debugausgabe 
funktioniert bei mir nicht.
In der HT3_db_cfg.xml habe ich das logging auf DEBUG gestellt und den 
Raspberry neu gestartet, damit der ht_collgate.py neu gestartet wird.
In der HT3_db_cfg.xml steht ja drin, dass das Logfile in 
./var/log/ht_default.log geschrieben werden soll. Da gibt es bei mir 
dieses Logfile aber nicht.

Was aber bei mir funktioniert :

cd ~/HT3/sw/etc
./rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 0 1 1
Bei mir (111110011)

Da wird dann ein HT3_Solar_second.png erstellt. ??
Müsste jetzt nur noch automatisch aktualisiert werden, so wie die 
anderen *.png

Liebe Grüße
Daniel

[leinado (Gast)]

Ich habe es jetzt bei mir erstmal so gemacht, dass ich das 
rrdtool_draw.pl umgeändert habe:

# solar ertrag draw
  solar_yield_draw($mypath, $mytargetpath, $controller_type);

  if ($second_collector == 0) {
    solar_draw_second_field($mypath, $mytargetpath, $controller_type);
  }

vorher: if ($second_collector > 0)

ist zwar nicht so ganz Sinn der Sache aber bei mir funktioniert es 
erstmal so :-)

Liebe Grüsse Daniel

[Henrik (Gast)]

Moin allerseits,

was bedeuten die einzelnen Stati in der Variable "hc1_operationstatus"?
3 steht für? Heizen? was gibt es dort noch? Gibt es eine Mappingtabelle 
oder ähnliches?

Gruß
Henrik

[Rob (Gast)]

Moin Leute,

mal ne Frage an alle, hättet Ihr auch ein Modul von AK-Nord 
(https://www.ak-nord.de/) genommen um die Heizungs-Datenerfassung über 
Ethernet zu realisieren oder seid Ihr alle der Meinung doch lieber ein 
RaspberryPI??

Laut deren Homepage bzw. den Datenblätter der Produkte ist dies deren 
Fokus, die Netzwerkkommunikation zu realisieren.

Was meint Ihr?


MfG
Rob

[Norbert S. (junky-zs)]

Hallo Henrik,
Henrik schrieb:
> was bedeuten die einzelnen Stati in der Variable "hc1_operationstatus"?
> 3 steht für? Heizen? was gibt es dort noch? Gibt es eine Mappingtabelle
> oder ähnliches?
Diese Mapping-Funktion (GetStrOperationStatus) ist enthalten im 
SW-Modul: lib/gui_worker.py.
(Anzeige im HT3_Analyser -> ' Betriebsstatus')
Fuer 'Fxyz' - Regler:
ivalue rtnstr
 0     "---"
 1     "Manuell"
 2     "Auto"
 3     "Urlaub"
 4/5   "E-Trocknung"
Fuer 'Cxyz' - Regler:
ivalue rtnstr
 0     "Off"
 1     "Summer"
 2     "Manual"
 3     "Comfort"
 4     "Eco"
----------------
GetStrOperationNiveau()
(Anzeige im HT3_Analyser -> ' Temperatur-Niveau')
Fuer 'Fxyz' - Regler:
ivalue rtnstr
 0     "---"
 1     "Frost"
 2     "Sparen"
 3     "Heizen"
Fuer 'Cxyz' - Regler:
ivalue rtnstr
 1     "Eco"
 2     "Comfort1"
 3     "Comfort2"
 4     "Comfort3"
===============================
Hallo Rob,
Rob schrieb:
> mal ne Frage an alle, hättet Ihr auch ein Modul von AK-Nord
> (https://www.ak-nord.de/) genommen um die Heizungs-Datenerfassung über
> Ethernet zu realisieren oder seid Ihr alle der Meinung doch lieber ein
> RaspberryPI??
Es muss nicht unbedingt ein RaspPi sein, die vorgestellten ht-Adapter 
funktionieren auch mit einem UART-USB Adapter.
Die ht-Adapter haben jedoch noch zusätzlich eine galvanische Trennung 
zwischen dem Heizung-Bus und der Aussenwelt und die aktiven Adapter 
(ht_pitiny/ht_piduino) können kontrolliert Daten zur Heizung senden.
Somit funktionieren diese als Gateway, welches die Module von ak-nord 
nicht können.
Ausserdem sind die Module von ak-nord zu teuer.

Gruß Norbert

[Andreas W. (urbansunited)]

Hi!

Hat schon einer Erfahrungen mit der Installation unter Raspbian Buster 
gesammelt?

Wie löse ich zB

sudo insserv httpd?

insserv fehlt, muss installiert werden. Bekomme beim Installieren:

Setting up insserv (1.18.0-2) ...
insserv: FATAL: service mountkernfs has to exists for service udev
insserv: FATAL: service urandom has to exists for service networking
insserv: FATAL: service mountdevsubfs has to exists for service hwclock
insserv: FATAL: service udev is missed in the runlevels 2 3 4 5 to use 
service raspi-config
insserv: exiting now!

Hat einer eine Lösung?

Danke

Andi

[Andreas Wülbern (Gast)]

Hi!

Ich beantwortet meine Frage selber:

Insserv scripts mit Buster? Es geht, sogar ganz einfach:

Copy script in /etc/init.d
sudo chmod +x /etc/init.d/your_script
sudo systemctl enable your_script

Nach dem Neustart werden unsere Scripts dann automatisch ausgeführt.

Gestern selbst auf Buster erfolgreich installiert.

Problem gelöst :)

Cheers

Andi

[Norbert S. (junky-zs)]

Hallo Andreas,

Andreas Wülbern schrieb:
> Insserv scripts mit Buster? Es geht, sogar ganz einfach:...

Danke für Deine Bemühungen. Kommt bei Gelegenheit mit in die Doku.
PS:
Eins ist uns gewiss:
Linux-Software altert auch, aber es vergilbt fast nichts schneller als 
Doku, eventuell sogar noch gedruckt auf Papier.
Deshalb wird uns die Arbeit nicht ausgehen und bei uns kommt somit keine 
Langeweile auf:-).

Gruß Norbert

[Mario R. (upd8r)]

Ich muss mal wieder Norbert einen Dank aussprechen, die Software läuft 
bei mir seit Jahren ohne Probleme.

In einem Anfall von Spieltrieb habe ich jetzt auf die nächste Version 
mit collgate aktualisiert und lasse jetzt alle Daten über den MQTT-Kanal 
in meine kürzlich installierte influxDB wandern. Ich bin noch am Basteln 
des Grafana-Dashboards, anbei der aktuelle Stand. Sobald ich zufrieden 
bin, werde ich das Dashboard auch bei Grafana verfügbar machen.

[Andreas W. (urbansunited)]

Hallo Mario,

sehr schön!
Ich habe auch Grafana bei mir laufen, habe aber bisher meine Heizung 
dort noch nicht eingebunden. Das sollte später passieren.
Von daher nehme ich dein Dashboard natürlich sehr gerne. Spart mir jede 
Menge an Arbeit :D
Ich würde aber auch schon mal einen Zwischenstand bei mir installieren 
;)

Danke und Gruß

Andi

[Mario R. (upd8r)]

Hi Andi,

anbei mal der aktuelle Stand, wie gesagt, ich importiere über 
MQTT/Telegraf und habe an den topic-Namen nix geändert.
Hier ist nur ein HK plus Solar in Betrieb, mehr habe ich also auch nicht 
eingebunden.

Kann aber auch die Telegraf-Konfig dann nochmal posten ...

Die Solarertragswerte sind nicht 100% identisch und bei den Pumpenläufen 
bin ich mir auch nicht sicher, ob er das zuverlässig erkennt.

[Bernd B. (bernd_b736)]

Hallo
Die Heizperiode ist angebrochen und leider hat meines Raspi SD das 
Zeitliche gesegnet. Ich habe das System neu aufgesetzt und leider kann 
ich nicht so genau sagen wo das eigentliche Problem liegt.

Ich denke ich habe alle Packete eingespielt. und über raspi-config die 
login shell über serial deaktiviert.

Ich starte den proxy und den ht_collgate. Keine Fehler, aber es werden 
offebar auch keine Daten gelesen/geschrieben.
Das Debug log ist ziemlich leer.

Den einzigen Fehler den ich provozieren kann ist, wenn ich den MQTT 
client aktiviere: Dann bekomme ich beim start von 
ht_collateccollgate().run();Error;could not start 'mqtt-interface' with 
file:'./etc/config/HT3_db_cfg.xml'

[Bernd B. (bernd_b736)]

im ht_client_rx.log steht etwas das mich wundert:

12.10.2019 09:41:07 INFO: ----------------------
12.10.2019 09:41:07 INFO: cht_socket_client init
12.10.2019 09:41:07 INFO: connected to server:'localhost';port:'8088'
12.10.2019 09:41:07 INFO: logfile:'./var/log/ht_client_rx.log'
12.10.2019 09:41:07 INFO: Client-ID:1; registered with devicetype:'RX'

Ich nutze den pitiny und ich denke ich sollte im MODEM modus arbeiten. 
Offenbar habe ich da wohl noch was nicht richtig konfiguriert

[Mario R. (upd8r)]

Vermutlich ist es bei dir was anderes, aber ich habe neulich ein Update 
von Stretch auf Buster gemacht und danach die gleiche Fehlermeldung.

Irgendein Python mqtt Modul wurde beim Upgrade Event und ich musste es 
mittels pip wieder nachinstallieren.

Im Übrigen kann ich jedem nur Raspibackup empfehlen: 
https://www.linux-tips-and-tricks.de/de/raspibackup/

Habe das hier schon so oft benötigt ....

[Bernd B. (bernd_b736)]

> Irgendein Python mqtt Modul wurde beim Upgrade Event und ich musste es
> mittels pip wieder nachinstallieren.

Das kann ja eeigentlich nur Paho sein... das hatte ich installiert mit 
pip3 install paho-mqtt.
ABER nach ein wenig debugging hat sich genau das als falsch 
herausgestellt. Ich habe es nochmal installiert und jetzt gibt es den 
Fehler nicht mehr.
Leider bekomme ich immer noch keine Daten von HZ Bus.

[Norbert S. (junky-zs)]

Hallo Bernd,
da Du einen ht_pitiny-Adapter hast, kannst Du dessen LED-Anzeigen 
kontrollieren.
Grüne LED muss flackern -> Signal vom Heizungsbus vorhanden.
Rote LED muss aufblitzen -> Adapter antwortet dem Heizungsbus auf 
Anfragen.
-->> Wenn soweit OK, dann bitte die Konfiguration kontrollieren!
Die Baud-Rate für den ht_pitiny-Adapter muss auf 19200 stehen! 
Konfig-File: ht-proxy_cfg.xml

Bernd B. schrieb:
> 12.10.2019 09:41:07 INFO: Client-ID:1; registered with devicetype:'RX'
> Ich nutze den pitiny und ich denke ich sollte im MODEM modus arbeiten.
Ist OK auch für den ht_pitiny-Adapter. Ist nicht der Grund für die 
fehlenden Daten vom Bus.
Dies zeigt aber, das der ht_proxy.server korrekt arbeitet. Ob dieser 
allerdings Daten vom ht_pitiny-Adapter erhält kannst Du prüfen mit 
Browseraufruf:
 http://<IP-Adresse des RPi>:8088
Soll-Ausgabe von Sequenzen wie: #HR�....

Zum Test kannst Du auch die python-Module (ht_proxy.py, ht_collgate.py) 
ohne die Start-scripte von Hand aufrufen, dann bekommst Du im Fehlerfall 
mehr Informationen.

Ich nehme mal an Du benutzt den aktuellen SW-Stand (Rev. 0.3.1) von 
github und Linux 'stretch' oder 'buster'?

Gruss Norbert

[Bernd B. (bernd_b736)]

Hallo Norbert
Ich habe des Rätsels Lösung gefunden. spi_clk_off.py hat geholfen.

Ist vielleicht auch für andere interessant. Ich habe einen Raspberry Pi 
Model B Rev 2 und das aktuelle (oct. 19) Image von Raspbian (minimal) in 
Verwendung.

[Norbert S. (junky-zs)]

Hallo Bernd,
prima das es wieder läuft!

Bernd B. schrieb:
> Ich habe des Rätsels Lösung gefunden. spi_clk_off.py hat geholfen.
Dieses Script wird normalerweise von den Start-Scripten: 'ht_proxy' und 
'ht_collgate' beim Systemboot aufgerufen:
...
$APPLICATION_FOLDER/etc/sysconfig/spi_clk_off.py
...

Nur wenn man einen Daemon von Hand startet, ist dieser manuelle Aufruf 
von 'spi_clk_off.py' erforderlich.

Gruß Norbert

[Bernd B. (bernd_b736)]

:D ja das habe ich dann später bemerkt. Aber Du weist ja wie es läuft... 
erst mal versucht man es "zu Fuss" bevor man das ganze automatisch 
laufen lässt.

Ich habe noch eine Frage: Ich steuere die Heizung via MQTT->

Für den Heizmodus gibt es ja das Topic: hc1_Tniveau.
Das kann man mit den Werten "auto, frost, sparen, heizen" in den 
entsprechenden Modus setzen.
Aber wie kann man erkennen, ob man aktuell im "Auto" Modus ist oder 
"manuell" auf einem der Modi sitzt?
hc1_Tniveau gibt einem soweit ich das sehe ja nur (1, 2, 3) an.

Tolles Projekt Norbert, noch mal vielen Dank für die harte Areit.

[Norbert S. (junky-zs)]

Hallo Bernd,

Bernd B. schrieb:
> Aber wie kann man erkennen, ob man aktuell im "Auto" Modus ist oder
> "manuell" auf einem der Modi sitzt?
Bei aktiviertem MQTT erhält man ja alle Informationen beim Start des 
MQTT-Clients (sofern der Broker entsprechend eingestellt ist) und danach 
jeweils wenn eine Änderung für ein Item aufgetreten ist.
Allerdings gibt es z.Zeit noch keine Abfrage-Möglichkeit eines Wertes 
über die MQTT-Schnittstelle.
Ich denke dies wäre eine nützliche Erweiterung dieser Schnittstelle. In 
Analogie zum 'Set'-Befehl dann eben einen 'Get'-Befehl für die Items.

Diese Abfrage-Möglichkeit gibt es allerdings schon mit dem 
SPS-Interface. Diese Schnittstelle muss aber erst aktiviert werden, da 
default deaktiv.

Konfigurations-File 'collgate_cfg.xml' anpassen und dort SPS auf 'on' 
stellen. Danach den ht_collgate-daemon neu starten.
Über dies Schnittstelle können dann Werte abgefragt werden. Details 
siehe auch Doku im Kapitel 2.3.3 SPS ht_Server.
Das Testprogramm ~/HT3/sw/test/sps_testclient.py kann als Grundlage für 
solche Abfragen dienen (siehe Ausgaben in den Bildern).

Allerdings werden die Werte nicht als Strings sondern wie in den 
Telegrammen gesendet zurückgegeben. Die Interpretation ist dann separat 
noch nötig z.B.:
send     -> :hc1_operationstatus
response <- :hc1_operationstatus:=1
Die '1' steht dann für aktuellen Betriebsstatus:= 'Manuell' bzw '2' := 
'Auto'.
(Diese Werte gelten allerdings nur für die Fxyz-Regler-Serie)

Gruß Norbert

[_rooky_ (Gast)]

Hallo,

beeindruckende Software. Und ich habe mich beim Aufbauen des Adapters 
schon auf die reichhaltige Datenanzeige gefreut. Bisher nutze ich eigene 
Sensoren, die per MySensors an Domoticz gesendet werden. Da habe ich 
aber bisher nur wenige Sensoren/Parameter verfügbar.

Leider werden im HT3_Analyzer nur wenige Daten angezeigt. Dafür aber 
einige unbekannte Nachrichten. Zwei Screenshots sind angehängt.

Exemplarisch habe ich noch ein putty.log der seriellen Schnittstelle und 
die Datei Heizung.log angehängt.

In Heizung.log sind aufgezeichnete Daten im Klartext enthalten. Die 
erste Spalte sind Mikrosekunden Wartezeit zwischen den empfangenen 
Bytes. Die zweite Spalte die Anzahl Bytes pro read() (immer 1;)
Die ...-Zeilen sind Wartezeiten in 2000 Mikrosekunden pro '.', wenn 
gerade keine Bytes ankommen.
Damit hatte ich gehofft, die Genzen von Messages erkennen zu können. 
Z.B: bei Zeile 407-437 funktioniert das ganz gut. An anderen Stellen ist 
es eher verwirrend.

Meine Anlage:
Kessel ZSBE 28-3
FW200 (JF12.10)
IPM2  (JF20.06)
ISM2  (JF23.02)
Heizkreis1 mit externem Mischer
Kombinierter Solar- und Warmwasserspeicher
Hydraulische Weiche


Nun meine Fragen: hat es ggf eine einfache Ursache, warum die Messages 
im HT3_Analyser nicht angezeigt werden, eine Konfiguration o.ä.? Oder 
verwendet meine Anlage Messages, die der HT3_Analyzer nicht unterstützt?

Schon mal vielen Dank für die Hilfe.

Gruß,
rooky

[Norbert S. (junky-zs)]

_rooky_ schrieb:
> Und ich habe mich beim Aufbauen des Adapters schon auf
> die reichhaltige Datenanzeige gefreut.
Welchen der Adapter-Typen hast Du gebaut?
Wichtig sind die richtigen Optokoppler, da nicht alle die erforderlichen 
Daten haben(Flankensteilheit, Ansprechstrom etc.)

> In Heizung.log sind aufgezeichnete Daten im Klartext enthalten.
Dieses Logfile zeigt einige seltsame Sequenzen, die in dieser Form nicht 
gesendet werden, z.B.:
  211147   1 22
    1053   1 00
.
    2509   1 A2
    1250   1 A2 <=== Fehler, ist doppelt
    1200   1 00
    1146   1 00
...........
   23963   1 0E
    1064   1 00
...............
   30076   1 30
    1061   1 00
...
    7084   1 B0
    1236   1 B0 <=== Fehler, ist doppelt
    1213   1 00
    1134   1 00
Wie bzw. womit wurde dieses Logfile erstellt?
Sicher nicht mit dem vorhandenen Tool: ht_binlogclient.py.
Es sieht nach Auslesefehlern der UART-RX Werte aus oder dein Adapter hat 
Probleme mit den Signalen auf dem Bus.

> Nun meine Fragen: hat es ggf eine einfache Ursache, warum die Messages
> im HT3_Analyser nicht angezeigt werden,
Wenn die serielle Schnittstelle (Baudrate etc.) richtig eingestellt ist 
würde ich noch als Ursache deinen Adapter vermuten.

> Oder verwendet meine Anlage Messages, die der HT3_Analyzer nicht unterstützt?
Die Messages Deiner Anlagen-Module werden dekodiert und erkannt wenn die 
Sequenzen richtig sind (CRC muss korrekt sein).
Aus den aufgezeichneten Telegrammen kann ich folgendes entnehmen:
Modul IPM2 steuert 1. den Heizkreis1 (Device-ID 20hex.) und ist 2. für 
die Steuerung der Warmwassererzeugung zuständig (Device-ID 22hex.)
Dein Heizgerät ist eingestellt auf 'Interne Warmwassererzeugung 
deaktiv'.
Modul ISM2 kontrolliert 1. Solar-Kollektor (Device-ID 30hex.) und 2. 
wohl auch die Warmwasser-Erzeugung.

Mein Tipp, deinen Adapter noch einmal checken und eventuell ein Logfile 
erzeugen nur mit dem Aufruf:
 cd ~/HT3/sw
 ./ht_binlogclient.py <irgendeinenlogfilenamen.log>
Das Logfile kann ich dann checken wenn Du es hier veröffentlichst.
Gruß Norbert

[_rooky_ (Gast)]

Hallo Norbert,

vielen Dank für die schnelle Antwort und Analyse.

Ich habe einen HT3-Miniadapter mit H11L1M aufgebaut.

Ja, die A2 A2, B0 B0 und 90 90 sind mir auch aufgefallen. Das Textlog 
habe ich mit einem eigenen C++ Programm erstellt.
'binlogclient.log' habe ich angehängt. Dort sehe ich auch die 
Doppelbytes.

Ich habe in der Zwischenzeit hp_discode.py mit einigen Traces bestückt, 
um die Dekodierung besser verstehen zu können. Das Logfile dazu habe ich 
auch angehängt ('ht_analyser.log'). Dort sieht es zumindest so aus, als 
wenn die Doppelbytes nicht ankommen.
Einen Screenshot des HT3_Analyzer derselben Session habe ich auch 
angehängt.

Die HT3_db_cfg.xml ist auch angehängt.

Gruß
rooky

[_rooky_ (Gast)]

Hallo Norbert,

ich habe jetzt einen ATmega328 zwischen den HT3 Miniadapter und den 
Raspberry Pi geschaltet. Dieser erkennt BREAK (Frameerror mit 
Empfangsbyte=0x00, Register UCSRnA, Bit FEn). Damit ermittle ich das 
Message-Ende.

Tatsächlich kommen die Nachrichten mit Source A0, A2, B0, 90 mit 
duplizierten Bytes an. Source 88 dagegen kommt normal.

Ich habe probeweise ht_discode.py so angepasst, dass die duplizierten 
Bytes entfernt werden (if ...: del self._rawdata[:message_size:2]) --> 
diese Nachrichten werden dann tatsächlich erkannt und dekodiert!

Im Anhang ein Screenshot. Es gibt noch einen Fehler in meiner 
Nachrichtenaufbereitung, der gelegentlich eine fehlerhafte Nahricht 
durchlässt. Daran muss ich noch arbeiten.


Die Doppelbytes scheinen so auf dem Bus anzuliegen, da ja am gleichen 
Draht für 88 keine Doppelbytes ankommen, aber für A0, A2, B0, 90 schon.

Ich habe den HT3 Miniadapter am freien Busausgang des ISM2 angeklemmt. 
Ich könnte mal probieren an anderer Stelle (HG, FW200) anzuklemmen, ob 
da was anderes passiert.

Ggf. werde ich noch mal den Bus mit einem Speicheroszi aufzeichnen und 
so bestätigen - oder auch nicht -, dass es die Doppelbytes tatsächlich 
gibt.

Wie auch immer sich das alles erklären lässt, Im HT3_Analyzer sind jetzt 
deutlich mehr Daten zu sehen ;)

Gruß,
rooky

[Norbert S. (junky-zs)]

Hallo rooky,
prima das Du eine Lösung für das Problem gefunden hast.

> Ich habe den HT3 Miniadapter am freien Busausgang des ISM2 angeklemmt.
Schliesse den ht_Adapter direkt am Bus an, also parallel zu den Modulen 
an die Klemmen (BB bzw. ESM2).
Dabei ist es egal welches Modul Du nimmst, die hängen alle parallel am 
gleichen Bus. Du kannst also auch das ISM2 nehmen.
Offensichtlich wird am zweiten Anschluss des ISM2 das Bus-Signal 
modifiziert ausgegeben und ist somit ungeeignet für die korrekte 
Dekodierung.

Gruß Norbert

[Fred (Gast)]

Hallo Nobert,

ich habe auch seit kurzem nach deiner Anleitung auch deinen super 
Datenlogger am Laufen. Primär um die Einstellungen der Anblage nach 
einer Analysephase ggf. zu optimieren. Leider stimmt irgendetwas mit den 
WW-Daten nicht, es kommt nur sehr selten ein Wert und wenn, dann sind 
die Temparaturwerte im Speicher viel zu gering. Vor allem die 
Warmwasserspeichertemperatur interessiert.

Anlagedaten:
------------------
- ZSB 24-4 C 23
- FW200 Regler
- IPM1: Hydraulische Weiche (HW), Speicherladepumpe, 
Speichertemperaturfühler (SP)
- IPM2: Heizkreis 1 Radiatoren, Heizkreis 2 Fußbodenheizung
- ISM2: Warmwasser Schichtspeicher, Solarkreispumpe, Ventil 
Rücklaufanhebung (DWU1), NTCxxx

- Raspi3 mit HT3-Miniadapter, hometop 0.3.3


Vielen Dank im Voraus

Gruß, Fred

[Norbert S. (junky-zs)]

Fred schrieb:
> Leider stimmt irgendetwas mit den WW-Daten nicht...
Dank des Logfiles und Deiner Beschreibung konnte ich das Problem 
nachvollziehen und auch eine Lösung finden.
Grund ist eine in Deinem System verwendete DeviceID:0x41, die von einem 
der IPM2 Module (für Warmwasser) verwendet wird. Damit die Dekodierung 
auch dafür funktioniert ist eine kleine Anpassung in der Software nötig.
Diese kannst Du zum Test bei Deiner Software selber durchführen wie 
folgt:
Modul : ~/HT3/sw/lib/ht_discode.py
Zeile : 3224 ff
Aktion: 0x41 im array:'deviceaddress_white_list[]' hinzufügen.

# 2021-02-12: 0x41 added in deviceaddress_white_list[]
deviceaddress_white_list = [
     0x08, 0x0a, 0x0b, 0x0c, 0x0d, 0x10, 0x18, 0x19, 0x1a,
     0x20, 0x21, 0x22, 0x23, 0x28, 0x29,
     0x30, 0x31, 0x41, 0x48]

Damit ist dann die Dekodierung auch für WW möglich (siehe Bilder)
Diese Änderung und die Auswirkungen muss ich im Detail noch einmal 
kontrollieren und werde dann ein neues Release auf github 
veröffentlichen.

Für mich sind diese IPM2 Module und deren Einstellungen sehr wichtig, da 
ich in meiner Anlage die Module nicht habe. Deshalb ist Dein Logfile für 
mich Gold wert!
Welche Schalter-Stellungen haben diese IPM1/IPM2 Module bei Dir im 
System?

Gruß Norbert

[Fred (Gast)]

Hallo Norbert,

vielen Dank für deinen Tip!

Ich habe die Änderungen wie beschrieben durchgeführt und es sieht jetzt 
viel besser aus (siehe HT4_WW_Graph.png).

> Für mich sind diese IPM2 Module und deren Einstellungen sehr wichtig, da
> ich in meiner Anlage die Module nicht habe. Deshalb ist Dein Logfile für
> mich Gold wert!
> Welche Schalter-Stellungen haben diese IPM1/IPM2 Module bei Dir im
> System?

Freut mich :-) Falls du noch mehr brauchst gib bescheid.

---------------------------------
IPM 1 - WW Speicherladekreis
---------------------------------
Speicherladekreis nach der hydraulischen Weiche muss Kodierung 3 oder 
höher erhalten. In meinem Fall ist die Kodierung vom 
Heizungsinstallateur auf **10** (Device ID 0x41) gesetzt worden.

**Anschlüsse:**
   - VF = Gemeinsamer Vorlauffühler der Hydraulische Weiche (HW)
   - SF1 = Speichertemperaturfühler SF (NTC) des Warmwasserspeichers
   - P1 = Speicherladepumpe LP

---------------------------------
IPM 2 - Modul für zwei Heizkreise
---------------------------------
- Heizkreis 1 (HK1) = Kodierschalter I auf **1** (Device ID 0x20)
- Heizkreis 2 (HK2) = Kodierschalter II auf **2** (Device ID 0x21)

**Anschlüsse:**
   - MF2 = Vorlauftemperaturfühler gemischter Heizkreis (Fußbodenheizung 
HK2)
   - P1 = Heizkreispumpe (Heizkreis HK1, Radiatoren)
   - M2 = Mischerstellmotor Heizkreis HK2 (Fußbodenheizung)
   - P2 = Heizkreispumpe (Heizkreis HK2, Fußbodenheizung)
   - TB2 = Temperaturwächter HK2 (Fußbodenheizung)

Meine Anlage scheint doch etwas spezieller zu sein. Im HT_Analyzer sehe 
ich noch einige Telegramme mit Fragezeichen dargestellt (siehe 
HT4_Unknown_Telegrams.png), es scheint noch nicht alles zu passen, ich 
versuch gerade noch deinen Code besser zu verstehen um auch selbst 
analysieren zu können.

Gruß Fred

[Norbert S. (junky-zs)]

Fred schrieb:
> Meine Anlage scheint doch etwas spezieller zu sein. Im HT_Analyzer sehe
> ich noch einige Telegramme mit Fragezeichen dargestellt...
Deine Anlage ist zwar speziell, das Problem liegt jedoch mehr in der Art 
wie Bosch (Junkers/Buderus) die Telegramme auf dem seriellen Bus senden.
Besonders das Ende-Kennzeichen eines Telegramms wird durch das 
BREAK-Signal angezeigt (mehr als 10Bit Bus auf low). Dieses Signal wird 
leider vom seriellen Treiber in eine Null übersetzt und somit kann man 
das Ende eines Telegrams nicht mehr eindeutig erkennen.
Bei langen Telegrammen ist eine CRC am Ende enthalten. Diese kann man 
prüfen und somit das Telegramm dekodieren. Leider gibt es viel häufiger 
kurze Telegramme die keine CRC enthalten.
Insbesondere das Polling der Steuerelektronik im Heizgerät (Master) und 
die kurzen Antworten der Module (Clients) führt oft zu 
Fehldecodierungen.
z.B. aus Deinem Bild:

C1 00 14 00 09 00 89 00 15 00 09 00 89 00 09 00 89 00 ...
PA Br DP Br DP Br PA Br DP Br DP Br PA Br DP Br PA Br ...
PA:= Polling-Antwort des angesprochenen Moduls (hier immer keine Daten)
DP:= DevicePolling von Steuerelektronik
Br:= Breaksignal vom seriellen Treiber zu Null uebergeben

Die Dekodierung der Telegramme mit den passiven Adaptern: 
HT3_Mini/Micro_Adapter ist daher ohne korrekte Break-Signalerkennung 
erschwert.
Die aktiven ht_transiver-Adapter (ht_pitiny/ht_piduino) erkennen das 
Break-Signal korrekt und übergeben die Telegramme mit Längenangabe zur 
weiteren Dekodierung.
Werde trotzdem versuchen die Dekodierung für die passiven Adapter zu 
verbessern.
Gruß Norbert

[micha (Gast)]

Hallo zusammen,

vorab vielen Dank für die super Arbeit! habe einen Raspberry Zero mit 
einem ht-tranceiver am laufen und die Daten per MQTT in unser IP Symcon 
System eingebunden. Funktioniert bislang perfekt.

Ich hätte eine Frage zum dem Errorcode. Gibt es hier eine Übersetzung? 
Den bzw. die Causecodes habe ich in der Anleitung gefunden, zum Errocode 
(z.B. 17461) aber rein gar nichts. Kann dieser entschlüsselt werden? 
Würde gern die Codes in Symcon hinterlegen und die Fehler im Klartext 
auf dem Tablet anzeigen.

Haben eine einfache Therme ZSB 14-4C... mit Warmwasserspeicher, 
Solarthermieanlage und ein C 400 Bedienelement.

Gruß Micha

[Norbert S. (junky-zs)]

micha schrieb:
> Den bzw. die Causecodes habe ich in der Anleitung gefunden, zum Errocode
> (z.B. 17461) aber rein gar nichts.
Diesen Errorcode habe ich ebenfalls nicht in meinen Unterlagen gefunden. 
Was ich für die Cx400/800 Reglerserie finden konnte sind alles Codes 
wie:
 Störungs-Code   : Axy | z.B.: A41
 und Zusatz-Codes: 811, 4051, usw.

Die dezimale Zahl:17461 in Hex: 4435 ergäben die ASCII-Zeichen: D5
Allerdings ist auch dieser Error-/Cause-Code nicht in meinen Unterlagen.

Mit dem HT3_Analyser kannst Du die Telegramme auswerten, insbesondere 
das Telegramm: MsgID 24_0.
Im Telegramm sind die Bytes: 22/23 für den Display-Code und die Bytes: 
24/25 für den CauseCode reserviert (siehe markierten Bereich im Bild, 
Wert dort 00cc hex := 204dez.)

Falls in Deiner Anlage Fehler vorhanden sind, so sollten diese auch im 
Regler Cx400 angezeigt werden. Vergleiche bitte mal beide Angaben.
Eventuell kannst Du auch noch ein binäres Logfile (ca. 1/2 Std.) deiner 
Anlagentelegramme erzeugen und mir zusenden oder hier veröffentlichen.

Gruß Norbert

[Micha (Gast)]

Hallo Norbert,

danke für die Antwort. Das passt dann aber zusammen. Die Anlage zeigt 
ein D5 331 an, was nach Anleitung auf einen defekt des externen 
Vorlauftemperaturfühlers hindeutet.

Der Angezeigte Fehler setzt sich dann immer aus Errorcode und Causecode 
zusammen?!

Gruß micha, allen schöne Ostern!

[Norbert S. (junky-zs)]

Micha schrieb:
> Der Angezeigte Fehler setzt sich dann immer aus Errorcode und Causecode
> zusammen?!
Ja.
Es gibt mehrere Telegramme für Fehlermeldungen, aber Error- und 
Cause-Code werden zusammen gesendet. Eventuell kann einer der beiden 
Werte Null sein (nicht gesetzt). Ist kein Fehler vorhanden sind beide 
Werte Null.

Telegramme mit Error-/Cause-Code sind:
MesId's (dezimal): 24, 162, 190, 191;
teilweise allerdings mit unterschiedlicher Byte-Anzahl und von 
verschiedenen Quellen. Dies macht die Auswertung schwieriger.
Am Heizungs-Regler angezeigte Fehlermeldungen stammen wohl vom Telegramm 
MesID:24.

Micha schrieb:
> Die Anlage zeigt ein D5 331 an, was nach Anleitung auf einen defekt des externen
> Vorlauftemperaturfühlers hindeutet
Da Du nur eine Zahl (17461) mitgeteilt bekommst, ist wohl noch eine 
Dekodierung des Wertes von 17461 nach D5 erforderlich oder?
Wird denn die Zahl: 331 korrekt übermittelt?
Welche Werte werden im HT3_Analyser.py für Error-/Cause-Code angezeigt?

Gruß Norbert

[Stephan (Gast)]

Hallo,

ich musste letzte Woche meine SD-Karte begraben und versuche nun die 
Datenerfassung neu zu installieren. Dies habe ich eigentlich schon öfter 
gemacht, angefangen damals mit einem PI 1 und einem Miniadapter. Bis 
ungefähr Weihnachten lief es nun auf einem PI3B+ mit einem pitiny.

Aber nun will es einfach nicht gelingen. LED's auf dem pitiny blinken 
und ich habe mich an die aktuelle Anleitung gehalten und bin nur den 
kürzensten Standardweg gegangen. Aber es kommt einfach kein Paket an. Es 
werden keine Datenbankeinträge geschrieben, Logeinträge kommen nach dem 
Start keine dazu und auch Grafiken werden keine erstellt.

Hat jemand eine Idee?

Danke und Gruß
Stephan

[Norbert S. (junky-zs)]

Stephan schrieb:
> Aber nun will es einfach nicht gelingen. LED's auf dem pitiny blinken
> und ich habe mich an die aktuelle Anleitung gehalten und bin nur den
> kürzensten Standardweg gegangen. Aber es kommt einfach kein Paket an. Es
> werden keine Datenbankeinträge geschrieben, Logeinträge kommen nach dem
> Start keine dazu und auch Grafiken werden keine erstellt.
>
> Hat jemand eine Idee?
Hallo Stephan,
da Dein(e) Adapter schon einmal an der Heizung Daten erfasst hatten ist 
wohl die Hardware und die Verbindung zum Heizungsbus in Ordnung.
Da Du auch die Standardkonfiguration (Default-Einstellung von github) 
verwendet hast betreibst Du das Projekt lokal als user 'pi' auf Deinem 
RPi.

Wenn trotz allem keine Daten kommen bleibt als Grund wohl nur noch die 
serielle Schnittstelle vom/zum Adapter (ht_pitiny) über. Bitte die 
Einstellungen in den Konfigurationsfiles kontrollieren.
Erforderlich sind ja für den aktiven ht_pitiny-Adapter:
 19200 Baud und 8N1.

Dies muss im Konfigfile ~/HT3/sw/etc/config/ht_proxy_cfg.xml eingestellt 
werden. Beispiel von meinem RPi4:

    <ht_transceiver_if devicename="RX">
      <parameter>
        <serialdevice>/dev/serial0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>RX</devicetype>
    </ht_transceiver_if>
    <ht_transceiver_if devicename="MODEM">
      <parameter>
        <serialdevice>/dev/serial0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>MODEM</devicetype>
      <deviceaddress_hex>0D</deviceaddress_hex> 
    </ht_transceiver_if>

Bitte den Namen der Seriellen Schnittstelle beachten!
Die ist hier geändert auf: /dev/serial0
Es kann sein, dass die serielle Schnittstelle Deines RPi eben nicht mehr 
als /dev/ttyAMA0 bezeichnet wird sondern eben als /dev/serial0 etc.
Die bitte auf Deinem RPi kontrollieren (siehe Bilder für RPi3 und RPi4).

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:

> Es kann sein, dass die serielle Schnittstelle Deines RPi eben nicht mehr
> als /dev/ttyAMA0 bezeichnet wird sondern eben als /dev/serial0 etc.

Hallo Norbert,
wie immer gilt: kaum macht man es richtig, schon geht es...

Ja, genau das war es! Ich wähnte mich auf der sicheren Seite weil die 
Anleitung bei der Unterscheidung zwischen ttyAMA0 und Serial0 ja klar 
von einen PI 4 spricht und ich ja "nur" einen PI 3 B+ habe.
Und ich hätte schwören können, dass es beim "ersten" Mal mit diesem Pi 
noch ttyAMA0 war (aber das war auch noch nicht mit Buster).

Also vielen Dank für die Hilfe und die langjährige Arbeit am Projekt.

Gruß
Stephan

[Norbert S. (junky-zs)]

Stephan T. schrieb:
> Und ich hätte schwören können, dass es beim "ersten" Mal mit diesem Pi
> noch ttyAMA0 war (aber das war auch noch nicht mit Buster).
Ja, wahr auch so. Deswegen hatte ich dies in der Doku auch so für den 
RPi3 beschrieben und beim RPi4 war dann eben /dev/serial0 nötig.
Aber dies hat man wohl jetzt für RPi3/4 und Buster geändert und hängt 
mehr oder weniger mit der Bluetooth-Schnittstelle zusammen.
Siehe dazu:
https://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3-pizerow-pi4-or-later-models/45571#45571

Werde deshalb die Default-Konfiguration im Projekt auf github.com 
anpassen müssen.
PS:
Allerdings warum man ausgerechnet den Namen: '/dev/serial*' verwendet 
hat ist mir schleierhaft. Die Schnittstellen: SPI, I²C, USB usw. 
arbeiten auch seriell, werden aber sicher nicht mit diesem Namen 
anzusprechen sein (oder doch in Zukunft!!???)

Noch ein Hinweis zur fehlerhaften SD-Karte.
Hatte selber Probleme mit SD-Karten. Zu häufiges Schreiben bekommt denen 
wohl nicht so gut (bei Dauerbetrieb und über Jahre).
Habe deshalb die Datenbanken auf einem USBStick generiert und schreibe 
die Heizungsdaten auch nur noch auf diesen Stick. Dazu ist die 
Konfigurationdatei anzupassen auf den absoluten Pfad des USBSticks.
Dies läuft nun schon seit Jahren.

Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,

ich betreibe seit ca. 3 Jahren Deine Software auf einem Raspberry Pi 3B
mit dem HT3-Miniadapter ohne große Probleme. Dafür erst einmal vielen
Dank.
Nun habe ich vor das Raspbian auf Bullseye zu aktualisieren und auch
Deine neueste Softwareversion einzusetzen. Dabei habe ich folgende
Vorgehensweise gewählt:
- Erstellung des Raspian Bullseye auf einem anderen Raspberry Pi 3B+
- Installation Deiner aktuellen Software nach Anleitung
- Erster Test auf dem Raspberry Pi 3B+ ohne HT3-Miniadapter, keine
  Fehlermeldungen, aber auch ohne Daten.
- Alten Raspberry Pi 3B herunterfahren und die SD-Karte mit dem neuen
  Bullsey einlegen. Raspberry wieder hoch fahren.
- Ich bekomme keine Fehlermeldungen in den Log-Dateien,
  aber auch keine Daten.
- Darauf hin habe ich die SD-Karten wieder getauscht
  und das alte System läuft wieder ohen Probleme.

Hast Du eine Idee, was und wie ich weiter prüfen kann?

Gruß Michael

[Stephan (Gast)]

Hallo Michael,
Guck Mal die letzten 4 Posts. Sieht so aus als hättest du dasselbe 
Problem wie ich...
Gruß
Stephan

[Michael W. (wemi2019)]

Hallo Stephan,
vielen Dank für den Hinweis. Genau das war es. In der vorhergehenden 
Version habe ich noch /dev/ttyAMA0 benutzt. Und ich bin mir fast sicher, 
dass ich da bereits Buster am laufen hatte. Aber jetzt, mit 
/dev/serial0, läuft wieder alles.
Gruß
Michael

[Bernd B. (bernd_b736)]

Hallo Norbert
Ich nutze deine Software schon seit nun über 4 Jahren und musste schon 
seit längerem nichts mehr ändern. Vielen Dank für die ganze Mühe die Du 
dir gemacht hast - das ist echt bewundernswert!

Die aktuellen Gaspreise haben mich aber motiviert noch mal nach 
Optimierungspotentials zu suchen.

Ich habe eine Solarthermie und unterstütze die Heizung durch Rücklauf 
anhebung.
Leider führt das dazu, dass meine Heizung ziemlich ins Takten kommt und 
ich würde eigentlich viel lieber die Heizkreispumpe ohne Brenner nutzen.

Leider habe ich keine Möglichkeit gefunden nur die Pumpe ein/aus zu 
schalten. Kann die Heizung bzw. das Interface das einfach nicht?

[Bernd B. (bernd_b736)]

Ich glaube die Antwort kann ich mir selbst geben.
Tatsächlich reicht es aus, die Solltemperatur zu senken. Dann schafft es 
die Gastherme - ohne zu zünden - in regelmäßigen Abständen die 
Heizkreispumpe zu starten.

[Martin G. (g_martin)]

Hallo Zusammen,

ich durch die HT3-Soft- und Hardware jetzt erstmals eine Idee über die 
Aktivitäten meiner Heizung bekommen, ZWSB 22/28-3 mit FW120 aus 2014 in 
einem EFH von 1997. Aus meiner Sicht ist da ziemlich was los (siehe 
Bilder)

Ich versuche aktuell, dass etwas zu entwirren. Wenn mir jemand spontan 
Hinweise geben kann, was komisch ist, oder verbessert werden kann, freue 
ich mich über Hinweise. Die Heizungsfragen will ich im auch im 
Heizungsforum stellen 
https://www.heizungsforum.de/forums/junkers-bosch.14/, (falls nicht 
jemand bessere Adressen hat).

Das Gerät steht praktisch noch auf den Einstellungen von Inbetriebnahme 
und läuft aus meiner Sicht viel zu oft an.

Ich habe allerdings noch eine ganz spezielle Frage: Ich beobachte, dass 
der Wert `hc1_Tflow_desired`, also T-Soll (Regelung) vom Heizgerät bei 
mir ständig, aber ohne für mich erkennbare Frequenz, auf 85 °C hochgeht.

Kann mir jemand erklären, was da passiert und warum das passiert? Wie 
kann ich das verhindern, oder will ich das vielleicht gar nicht 
verhindern?

Viele Grüße
Martin

PS: Grandioses Gesamtpaket, Respekt an Norbert!

[Norbert S. (junky-zs)]

Martin G. schrieb:
> Ich habe allerdings noch eine ganz spezielle Frage: Ich beobachte, dass
> der Wert `hc1_Tflow_desired`, also T-Soll (Regelung) vom Heizgerät bei
> mir ständig, aber ohne für mich erkennbare Frequenz, auf 85 °C hochgeht.
Wird immer bei Warmwasser-Erwärmung auf diesen Wert gesetzt. Soll ja 
schnell erwärmt werden.

> Kann mir jemand erklären, was da passiert und warum das passiert? Wie
> kann ich das verhindern, oder will ich das vielleicht gar nicht
> verhindern?
Warmwasser wird zu häufig erzeugt. Liegt wohl hauptsächlich an der 
aktiven Zirkulations-Pumpe. Wasser ist dann zwar immer sofort heiß am 
Hahn, aber dafür zahlt man dann auch.
Versuchsweise mal die Zirkulations-Pumpe deaktivieren (wenn der Chef des 
Hauses dann flucht hat Man(n) schlechte Karten :-).

Die WW-Speicher Temperatur ist fast immer (ca. 3 Grad) unterhalb des 
Soll-Wertes. Kann ich mir z.Zeit nicht erklären.

Vielleicht hat noch jemand ein paar Tipps.

Gruß Norbert

[Martin G. (g_martin)]

Das hat mir schon sehr geholfen. Meine Anlage hat auch eine externe Wilo 
Pumpe (die nicht in Betrieb ist). Dass die Heizung selbst umwälzt, war 
mir nicht (mehr?) klar. Damit verstehe ich dann auch die 
Pumpenaktivität, die im Diagramm auftaucht ist. Da hat meine Heizung 
etwas gemacht, das ich eigentlich so nicht wollte.

Die Umwälzung ist jetzt abgestellt bzw. sehr punktgenau eingestellt. Das 
zeigt sich auch schon in der aktualisierten Darstellung.Danke schon 
einmal dafür.

Als nächstes würde ich ja gerne die Anzahl der Zündungen reduzieren. 
Könnte ich da mit der Taktsperre Erfolg haben? Oder ist das herumdoktern 
an Symptomen?

Grüße Martin

[Norbert S. (junky-zs)]

Martin G. schrieb:
> Als nächstes würde ich ja gerne die Anzahl der Zündungen reduzieren.
> Könnte ich da mit der Taktsperre Erfolg haben? Oder ist das herumdoktern
> an Symptomen?
Bin kein Heizungsfachmann, jedoch probieren geht über studieren.
Du kannst die Automatische Taktsperre oder auch die Schaltdifferenz 
einstellen.
Den richtigen Wert kannst Du nur durch Probieren herausfinden und der 
ist ein Kompromiss zwischen Komfort und zugelassener Regelabweichung.
Einstell-Möglichkeiten siehe Bild.

Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
habe heute morgen einen Ausfall meiner HT3-Software. Nach einem Neustart 
läuft zunächst ein paar Minuten alles. Danach stürzt der Prozess 
ht_collgate mit folgenden Fehlermeldungen ab:

30.08.2022 10:10:33 INFO: Starting 'Ccollgate.run()
30.08.2022 10:10:33 INFO: cht_if_worker(); Start ----------------------
30.08.2022 10:10:33 INFO: cht_if_worker();  Loglevel      :INFO
30.08.2022 10:10:33 INFO: cht_if_worker();  Datainput-Mode:SOCKET
30.08.2022 10:10:33 INFO: cht_discode.discoder() --> common 
CRC-detection procedure <--
30.08.2022 10:12:44 CRITICAL: cstore2db.run();Error; on 
ht_if.decoded_data_4_DBs().get()
30.08.2022 10:12:45 CRITICAL: 
ccollgate().run();Error;cstore2db_if-thread terminated.
30.08.2022 10:12:45 CRITICAL: ccollgate().run();Error; terminated

Ich kann mit dem Fehler nichts anfangen. Das System lief bisher 2-3 
Jahre reibungslos.

Gruß Michael

[Norbert S. (junky-zs)]

Michael W. schrieb:
> Ich kann mit dem Fehler nichts anfangen. Das System lief bisher 2-3
> Jahre reibungslos.
Der Prozess wird beendet, weil offensichtlich keine Daten decodiert 
werden konnten.
Details dazu in sw/lib/Ccollgate.py
    # read values from queue, wait if empty or stop if (None, None)
    (nickname, value) = self._ht_if.decoded_data_4_DBs().get()
    # terminate thread if both values are None, else process them
    if (nickname, value) == (None, None):
       self.stop()
       break
Einen Grund kann ich allerdings auch nicht erkennen.

> Das System lief bisher 2-3 Jahre reibungslos.
Ich nehme deshalb an Du nutzt ein älteres Release der Software.
Ich kann Dir da nur empfehlen auf das letztgültige Release: 0.5 des 
github.com repositories zu aktualisieren.
Grund: Falls man linux aktualisiert (update/upgrade) kommen einige 
Änderungen (Namensänderungen serielle Schnittstelle etc.) mit in das 
Betriebssystem die vorher nicht enthalten waren.
Dann werden halt keine Daten mehr von der Schnittstelle empfangen und 
decodiert.
Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
ich nutze zur Zeit die Version 0.4.2
Mittlerweile habe ich herausgefunden, dass der Fehler beim Schreiben in 
die SQLite-DB auftritt. Hatte vor ein paar Monaten die SQLite-DB in 
Betrieb genommen, weil ich einige Datensätze analysieren wollte und 
danach nicht wieder außer Betrieb genommen.
Ich habe jetzt das Speichern in der SQLite-DB unterbunden und dann läuft 
wieder alles wie gewohnt.
Ich werde jetzt nicht mehr weiter suchen und auch nicht mehr updaten, da 
ich das System vermutlich nur noch ein halbes Jahr betreibe.
Vielen Dank für Deine Unterstützung.
Gruß Michael

[Nils (Gast)]

Hi,

ich hab gerade HT3 neu installiert mit der Datenbank auf einem USB 
Stick. Leider generiert er die HTML Bilder nicht, obwohl er Daten 
abspeichert und die RRD Datenbanken modifiziert werden. Jemand eine Idee 
dazu wo ich schauen sollte?

Viele Grüße,
Nils

nils@ht3:~ $ /home/nils/HT3/sw/etc/rrdtool_draw.pl /media/usbstick 
/home/nils 2 1 0 1 1 0 0 1 0
rrdtool info /media/usbstick//HT3/sw/var/databases/HT3_db_rrd_solar.rrd 
failed: could not lock RRD at /usr/share/perl5/RRDTool/OO.pm line 444


24.09.2022 15:13:54 DEBUG:   35_0 ;TSoll:24;Leistung:100;Drehzahl:0
24.09.2022 15:13:54 DEBUG:   35_0 ;TSoll:24;Leistung:100;Drehzahl:0
24.09.2022 15:13:54 DEBUG:   35_0 ;TSoll:21;Leistung:100;Drehzahl:0
24.09.2022 15:13:58 DEBUG:   24_0 
;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 
7:0;Byte28:0
24.09.2022 15:14:02 DEBUG:  259_0 
;Optim.Faktor_WW:16;Optim.Faktor_HG:0;Ertrag letzte 
Std.:0;Tkollektor:31.8;Tspeicher:36.6;pump status:0;Kollektor aus:0; 
Speicher voll:0;>
24.09.2022 15:14:03 DEBUG:   30_0 :HG;T_HydraulicDevice:21.7
24.09.2022 15:14:06 DEBUG:  268_0 ;status_mixer:1
24.09.2022 15:14:07 DEBUG:  268_0 ;status_mixer:2
24.09.2022 15:14:07 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:08(h)
24.09.2022 15:14:07 DEBUG:    2_0 ;Bus-Response Source:08(h) to 
Target:10(h)
 ;1.Busteilnehmer:95;Typ:Heatronic3;Softwarefamilie:18;Softwareversion:8
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:0
 ;Markenzeichen:None
24.09.2022 15:14:08 DEBUG:   24_0 
;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 
7:0;Byte28:0
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:20(h)
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Response Source:20(h) to 
Target:10(h)
 ;1.Busteilnehmer:102;Typ:IPM2;Softwarefamilie:20;Softwareversion:7
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:100
 ;Markenzeichen:Junkers
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:21(h)
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Response Source:21(h) to 
Target:10(h)
 ;1.Busteilnehmer:102;Typ:IPM2;Softwarefamilie:20;Softwareversion:7
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:100
 ;Markenzeichen:Junkers
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:30(h)
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Response Source:30(h) to 
Target:10(h)
 ;1.Busteilnehmer:101;Typ:ISM1;Softwarefamilie:23;Softwareversion:3
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:101
 ;Markenzeichen:Junkers
24.09.2022 15:14:18 DEBUG:   24_0 
;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 
7:0;Byte28:0
24.09.2022 15:14:18 DEBUG:   22_0 
:HG;heat_enable:On;TargetDevice(dez.):16;MaxT_Vorlauf:61
24.09.2022 15:14:18 DEBUG:   30_0 :HG;T_HydraulicDevice:21.7

[Nils (Gast)]

Bitte meine Frage ignorieren. Nach 1 Stunde sieht man nun aktuelle 
Messwerte und auch die erste Historie. Anscheinend war ich einfach nur 
zu ungeduldig...

Super Software übrigens.

[Nils R. (augur)]

Hi.

Ich würde gerne eine Frage von mir aus 2015 wieder aufgreifen. 
Unterstützung von Fehlermeldungen aus der Therme, dass diese z.B. ein 
Programm aufrufen welches einen Alert verschickt.

Ich habe hier eine wahrscheinlich bekannte Doku gefunden welche für den 
EMS Bus (ähnlich zum EMS2?) die Fehlerprotokolle auslistet, wenn auch 
nicht den Fehlercode. Für eine erste Benachrichtigung einfach den 
Fehlercode rauszusenden wäre direkt auf dem Niveau vom MB-LAN2, mehr 
kann dies auch nicht.

https://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> Unterstützung von Fehlermeldungen aus der Therme, dass diese z.B. ein
> Programm aufrufen welches einen Alert verschickt.
Hallo Nils, ich hoffe Dein System läuft noch und erzeugt keine Fehler 
:-)

Es macht auf jeden Fall Sinn so etwas zu haben.
Den nicht jeder hat oder will ein teuer MBLan2, wenn man Fehlermeldungen 
auch billiger senden kann.
Es ist z.Zeit nur eine Anzeige in den GUI's (HT3_Analyser und 
HT3_Systemstatus) enthalten, gesendet wird an die Schnittstellen noch 
nichts.

Daher habe ich auf github.com ein neues 'issue:21' aufgemacht, in dem 
man Fakten, Wünsche und Bemerkungen reinschmeissen kann.
 https://github.com/norberts1/hometop_HT3/issues/21

Zum Anfang werde ich dort auch eine Mapping-Liste (Errorcode <--> Text) 
reinstellen, damit jeder diese Errorcodes mit seinem Anlagenhandbuch 
vergleichen und eventuell auf github.com 'issue:21' oder hier ergänzen 
kann.

Wie die Software im einzelnen ergänzt/erweitert werden soll muss noch 
festgelegt werden.

Gruß Norbert

[Nils R. (augur)]

Das klingt ja sehr gut. Dann trag ich mal was zusammen. Bei mir tritt 
immer mal wieder das Problem auf, dass zu wenig Druck anliegt. Den 
Messwert dazu hab ich übrigens auf Seite 39 nicht gefunden, ist aber in 
MB-LAN2 vorhanden. Ggf. kann man diesen noch ergänzen. Ticket in Github?

Übrigens hat man mir nun mitgeteilt, dass die EasyControl App nicht mehr 
supportet wird. Leider funktioniert diese nicht im WLAN und stürzt 
direkt ab. Macht das ganze noch sinnloser...muss immer WLAN abschalten, 
um diese benutzen zu können.

[Nils R. (augur)]

Hi,

ich hab mal eine Frage zu meiner Heizung, die ich aufgrund der HT3 Daten 
bekommen habe (echt super nochmal das zu haben... :-)  ).

Hardware:
ZSBE 28-3 A23
FW200
IPM2
ISM1
Speicher SK400-1
3x FKT-1S Solarkollektoren

Anscheinend speichert meine Heizung schön Solarenergie, nutzt diese aber 
nicht oder die Abflachung der Warmwasserkurve ist die Solarnutzung, aber 
irgendwie hätte ich da mehr erwartet...
Zudem steht T-Ist (Raum) immer auf über 30Grad, das ist aber auch im 
MB-LAN2 so, liegt somit eher an der Heizung. Die FW200 ist 
witterungsgeführt, aber der Wert ist schon komisch.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> ...Zudem steht T-Ist (Raum) immer auf über 30Grad
Der Regler FW200 ist bei Dir sicher im Heizgerät eingebaut. Somit misst 
dieser die interne Temperatur des Heizgerätes. Sieht man auch an der 
T-Ist Kurve im Heizkreis, immer dann wenn der Brenner läuft geht diese 
Temperatur schlagartig hoch. Leider wird in den Telegrammen nicht 
mitgeteilt ob der Regler im Heizgerät eingebaut ist.

PS: Jeder Junkers/Bosch Regler Fxyz und auch Cxzy hat einen internen 
Temperatursensor. Somit könnte man diesen auch direkt in einen zu 
kontrollierenden Raum installieren wenn man die Heizungs-Busleitung 
dahin verlegen kann. Dazu gibt es Wandbefestigungen von Junkers/Bosch.
Genau dieses habe ich bei meinem Heizungssystem gemacht und den CW400 in 
meinem Wohnzimmer installiert. Kann dadurch auf eine Fernbedienung 
verzichten und erhalte die korrekte T-Ist Temperatur des Raumes.

> Anscheinend speichert meine Heizung schön Solarenergie, nutzt diese aber
> nicht oder die Abflachung der Warmwasserkurve ist die Solarnutzung, aber
> irgendwie hätte ich da mehr erwartet...
Für die Warmwasserunterstützung reicht die Solar-Temperatur nicht mehr 
aus, da der Warmwasser Soll-Wert ja auf 50Grad steht, die 
Solarspeichertemperatur diesen Wert aber nicht mehr erreicht.
Daher wird diese Solarenergie für die Heizkreise genutzt werden.
Allerdings sieht man dies nicht im Heizgeräte-Bild.
Da ist auch fast immer die Rücklauftemperatur höher als die 
Vorlauftemperatur, nur wenn geheizt oder das Heizgerät in Standby steht 
ist dies nicht so.
Leider sieht man in Deinem rrdtool-plot nicht wann die Heizungs- bzw. 
Heizkreis-Pumpen laufen, weil Du eine ältere Software-Revision nutzt.
Bitte die Software aktualisieren, damit diese Infos zur Verfügung 
stehen.

Angefügte Bilder zeigen mein System und wann die Solarenergie aus dem 
Solarspeicher für den Heizkreis genutzt wird (10:00 bis 12:15 und 16:00 
bis 18:30). Auch sieht man wann die Heizungspumpe läuft 
(Heizungspumpenleistung %).
Die Solartemperatur reicht aber auch hier nicht mehr für die 
WW-Erwärmung.

Gruß Norbert

[Nils R. (augur)]

Moin,

solange die Regelung den Raumwert nicht nutzt. :-) Dann blende ich mal 
die Werte aus. Ich hab die aktuelle Software, aber das rrd angepasst 
damit es für mich etwas übersichtlicher ist. Hab es nun wieder 
eingeblendet.

Anscheinend wird die Solarenergie nicht für die Heizung genutzt, auch 
sinkt die Temperatur des Speichers nicht so schnell wie bei dir. Ich hab 
auch nur einen Warmwasserspeicher und keinen Kombispeicher laut meinen 
Recherchen, den mal wohl bräuchte für beides. Das ist ein Punkte wo ich 
ansetzen möchte zur Optimierung, dass die Solarenergie dann für die 
Heizung genutzt werden kann und nicht einfach im Speicher verpufft. So 
hab ich es jedenfalls verstanden.

Viele Grüße,
Nils

[Nils R. (augur)]

Was hast du für ein Heizungssetup und ist es möglich wann der 
Solarspeicher angezapft wird für Warmwasser oder Heizung in dem 
Solardiagramm zu ergänzen? Der Ertrag ist bei mir etwas zwiespältig, 
wenn dieser eigentlich nicht genutzt wird…

[Nils R. (augur)]

Falls jemand Interesse hat, hab meine Zirkulationspumpe automatisiert 
(war nur eine mechanische Uhr dran) und anstatt einem weiteren IPM es 
mit Relais, ESP32 und einer MQTT Anbindung zusammen mit der HT3-MQTT 
Anbindung gelöst. Mit so einem Standard wie MQTT ist schon cool, was da 
alles geht. https://github.com/NilsRo/HotWaterRecirculatingPump

[Norbert S. (junky-zs)]

Nils R. schrieb:
> solange die Regelung den Raumwert nicht nutzt. :-)
Wird nicht, da am Regler FW200 ja reine Außentemperatur-Führung 
eingestellt ist.
> Was hast du für ein Heizungssetup
Mehr oder weniger die Default-Einstellungen.
- Automatische Taktsperre: Aus
- Taktsperre auf 3 Minuten
- Schaltdifferenz 10 K
- Gebläsenachlaufzeit 30 Sekunden
- Minimale Nennwärmeleistung 36 %

Die Einstellungen Deiner Heizung solltest Du noch mal prüfen bzw. 
optimieren.
Was mir an dem letzten Heizgeräte-Plot 
(https://www.mikrocontroller.net/attachment/572109/Bild_2022-10-01_175742006.png) 
negativ aufgefallen ist:
die Heizungspumpe läuft sehr häufig und dann nur kurz. Diese kurze 
Taktung ist nicht besonders effektiv wenn man einen Brennwert-Kessel 
hat.
Bessere wäre eine längere Laufzeit auf niedrigem Niveau.
Vielleicht kannst Du da noch etwas verbessern.

> ist es möglich wann der Solarspeicher angezapft wird für
> Warmwasser oder Heizung in dem Solardiagramm zu ergänzen?
Die Telegramme auf dem Heizungsbus sind da nicht sehr detailfreudig.
Habe zu Versuchszwecken das Solardiagramm ergänzt um die beiden 
Faktoren:
- Optimierungsfaktor Heizung
- Optimierungsfaktor Warmwasser

Diese Daten werden vom ISM/MS - Modul bereitgestellt.
Diese sind jedoch nur reine Faktoren und keine Temperatur-Werte.
Was,wie und wann die Regler (FW200 etc.) diese Werte nutzen, kann ich 
aus den anderen Telegrammen und Grafen nicht erkennen.
Siehe Beispiel: Solargraf mit der Optimierungsfaktor-Ergänzung.
Wenn dir dies weiterhilft kommt es mit ins nächste SW-Release.

Gruß Norbert

[Mik L. (mik_l)]

Hallo,

meine Junkers-Therme ist leider nicht HT3-fähig (24V Stetigregelung über 
1-2-4 Anschluss), aber der nachträglich installierte 
Raumtemperaturregler FR50 kann beides.

Ist zufällig bekannt, inwiefern und ob der FR 50 z.B. Raumtemperatur und 
Schaltverhalten parallel über den HT3 Anschluss publiziert oder ob da 
der Bus mangels "geschwätziger" Therme automatisch abgeschaltet ist?

Gruß Mike

[Nils R. (augur)]

Moin,

ich möchte zusätzlich zur RRD Datenbank auch die HTML Erzeugung auf 
einen USB-Stick umziehen was soweit auch geklappt hat. Leider bekomme 
ich aber die automatische PNG Erzeugung nicht abgeschaltet, dies macht 
er immer noch im Standardverzeichnis.

Die Erzeugung mit off oder 0 abzuschalten bringt leider nichts...kann 
ich irgendwo schauen welchen Wert er ermittelt hat?

Die neue Erzeugung mache ich mit einem Crontab-Eintrag selber. (*/5   
  /home/nils/HT3/sw/etc/rrdtool_draw.pl /media/usbstick/ 
/media/usbstick/)

    <rrdtool-db>
      <enable>on</enable>
      <step_seconds>60</step_seconds>
      <starttime_utc>1344000000</starttime_utc>
      <!-- autocreate_draw:
        parameter used for auto-creating the png-draws from 
rrdtool-database content.
        (value is defined in 'minutes' (> 0) or disabled (== 0))
         if set to:0 or off autocreating is disabled.
         if set to:> 0      autocreating is enabled
            (enabled only if database is also set 
to:<enable>on</enable>)
      -->
      <autocreate_draw>0</autocreate_draw>
    </rrdtool-db>

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> Die Erzeugung mit off oder 0 abzuschalten bringt leider nichts...
Nach einer Konfigurations-Änderung ist ein Restart des ht_collgate.py 
erforderlich.

Nils R. schrieb:
> Die neue Erzeugung mache ich mit einem Crontab-Eintrag selber.
Kann man machen, jedoch muss man die nötigen Parameter ebenfalls 
übergeben.
Diese werden dynamisch aus den dekodierten Heizungsdaten ermittelt und 
als Darstellungs-Eigenschaften dem perl-script übergeben.
Im Crontab-Eintrag ist dies dann statisch mit einzutragen, sonst kommt 
u.U. eine falsche grafische Darstellung der Heizungsanlagen-Werte.
Parameter sind:
rrdtooldb.create_draw(
 db_path, html_path, --> Pfade auf db und html
 heatercircuits_amount(), --> Anzahl Heizkreise
 controller_type_nr(), --> Controller-Typ (Fxyz, Cxyz)
 GetAllMixerFlags(), --> gemischte /ungemischte Heizkreise (array)
 IsTempSensor_Hydrlic_Switch()), --> hydraulische Anpassung 0/1
 IsSolarAvailable()), --> Solar vorhanden oder nicht 1/0
 IsSecondCollectorValue_SO())) --> zweiter SO-Kollektor da oder nicht 
1/0

Zusätzlich muss der httpd.py-daemon als html-server im gleichen 
Verzeichnis wie unter 'html_path' angegeben vorhanden sein und laufen.

Gruß Norbert

[Nils R. (augur)]

Hab zur Sicherheit den Raspi durchgestartet, aber er ignoriert den 
Parameter weiterhin.

Aufgrund deiner Beschreibung hab ich nun einen Symlink auf den USBStick 
angelegt und lasse die Automatik die Dateien erzeugen, funktioniert 
reibungslos und sicher auch etwas einfacher fürs aktualisieren...danke 
dir.

[Nils R. (augur)]

Moin.

Ich beschäftige mich gerade damit meinen Raspi auf ein 
Readonly-Filesystem umzustellen, da mir immer die SD und der USB Stick 
abrauchen.

Läuft soweit auch und nutze nur MQTT für die zentrale Speicherung. Dabei 
kam mir nun die Frage ob der rsyslog Deamon nicht zum loggen genutzt 
werden könnte. Damit sind die Logs im zentralen Verzeichnis und landen 
bei mir auch auf dem zentralen Syslogserver.

https://gist.github.com/danielkraic/a1657f19bad9c158cbf9532e1ed1503b

Ähnliches gilt übrigens auch für das run Verzeichnis der pids, obwohl 
die Logs persistent zu haben wichtiger wäre. Hattest du dich schonmal 
damit beschäftigt Norbert?

Viele Grüße
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> Dabei kam mir nun die Frage ob der rsyslog Deamon nicht zum loggen genutzt
> werden könnte. Damit sind die Logs im zentralen Verzeichnis und landen
> bei mir auch auf dem zentralen Syslogserver.
Habe mich bisher noch nicht mit 'rsyslog' beschäftigt aber danke für den 
Link zu github.
Da das Logging ohnehin im Projekt vorhanden ist sieht der Aufwand dazu 
erst einmal gering aus. Schaue ich mir an.
Allerdings wenn alles zentral auf dem syslog Server gespeichert wird und 
das Format (Payload) nicht standardisiert ist, sehe ich viel Kraut und 
Rüben in den syslogfiles, den man wieder mit grep oder anderen Tools 
(SigNoz etc.) wieder für das jeweilige 
Server/Projekt/Prozess/Applikation sortieren muss.
Das Logging-Format in meinem Projekt (im Debug-Modus) ist mit 
';'-Trennern aufgebaut und kann damit DIREKT als csv-file in Excel bzw. 
LibreOffice ausgewertet werden.

> Ähnliches gilt übrigens auch für das run Verzeichnis der pids.
Nach Anpassung der systemd startscripte ist dieses Verzeichnis ohnehin 
nicht mehr nötig.

Gruß Norbert

[Jürgen (jl2)]

Hallo Norbert,

erst einmal vielen Dank für Deine bisherige Arbeit + Mühe die Du in 
dieses Projekt investiert hast. Danke dessen konnte ich seit 2017 ohne 
Probleme die Daten meiner Heizung anzeigen und über MQTT auch steuern. 
Mit Erweiterung der Anlage um Solar wurde nun die FW100 Regelung gegen 
eine CW400 + MS200 ausgetauscht. Da ich einen 2. Pufferspeicher mit 3 
Wege Ventil im Ladekreis habe, wollte ich Fragen ob die Daten des 2. 
Pufferspeicher ebenfalls angezeigt werden könnten ?
In der CW400 werden die Daten des 2. Pufferspeicher + Ventilstellung 
anzeigt.
Werden diese Daten aktuell nicht dekodiert oder muß die Konfiguration 
angepasst werden ?

Gruß,
Jürgen

[Norbert S. (junky-zs)]

Jürgen schrieb:
> Da ich einen 2. Pufferspeicher mit 3
> Wege Ventil im Ladekreis habe, wollte ich Fragen ob die Daten des 2.
> Pufferspeicher ebenfalls angezeigt werden könnten ?
Die Daten werden mit dem rrdtool als zweite Solar Grafik angezeigt. Dies 
wird automatisch erzeugt sobald die zugehörigen Telegramme erkannt 
werden.
Diese Daten werden auch mit MQTT ausgegeben.
Allerdings habe ich selber keinen 2. Solarspeicher und 'nur' das MS100 
Modul mit dem CW400. Deshalb habe ich nicht alle Informationen über die 
Telegramme und Inhalte.

Du kannst mir aber Deine Anlagendaten in ein Binarfile mitprotokollieren 
und hier veröffentlichen. Ich kann dann die Auswertung verbessern.
Dazu folgenden Aktion auf dem RPi starten:

 
cd ~/HT3/sw
./ht_binlogclient.py irgendeinName1.log

Das/die Logfiles sollten nicht zu groß werden (ca. 1Std.) damit die 
Auswertung besser/schneller geht.
Wichtig ist dabei auch die Anlage zu beobachten und Aktionen (z.B. 
Ladepumpe an/aus, 3Wege-Ventil Veränderung etc.) zeitlich zu erfassen 
und den Logfiles zuzuordnen.
Ich weiß allerdings nicht wie man solche Aktionen für den 2. 
Solarspeicher erzwingen kann. Da kennst Du dich besser aus.

Gruß Norbert

[Jürgen (jl2)]

Hallo Norbert,

entsprechend den anderen Beiträgen hier hatte ich mit der Frage nach den 
bin-logfites schon gerechnet und mal 1 Stunde zum Test mitlaufen lassen.
Ich mache das heute Abend nochmals und notiere mit dabei die Zeitpunkte 
der Ventil Umschaltung ( lässt sich mit der Diagnose Funktion am CW400 
steuern )

Gruß,
Jürgen

[Norbert S. (junky-zs)]

Jürgen schrieb:
> entsprechend den anderen Beiträgen hier hatte ich mit der Frage nach den
> bin-logfites schon gerechnet und mal 1 Stunde zum Test mitlaufen lassen.
Danke für das Logfile.
Bei der ersten Auswertung habe ich in meinem Analyser Fehlercodes Deiner 
Anlage angezeigt bekommen.
Displaycode: A11
Causecode: 3061
Laut meinen Unterlagen bedeutet dies:
"Keine Kommunikation mit Mischermodul für Heizkreis1"
Vorgeschlagene Aktionen:
- Konfiguration prüfen (Adresseinstellung am Modul).
- Mit der gewählten Einstellung ist ein Mischermodul erforderlich.

Offensichtlich ist irgend eine Einstellung Deines Systems noch zu 
korrigieren.

Gruß Norbert

[Jürgen (jl2)]

Norbert S. schrieb:
> Offensichtlich ist irgend eine Einstellung Deines Systems noch zu
> korrigieren
Die Fehlermeldungen hatte ich provoziert da das MM200 zu diesem 
Zeitpunkt stromlos war. Ich hatte den Außenfühler abgebaut, das hat die 
Regelung in eine Art "Notlauf" versetzt und beide Heizungspumpen laufen 
lassen .... Ist aber jetzt beseitigt da die Fassade an dieser Stelle 
fertig ist und der Fühler wieder dran ..
Ich habe die Temperatur des 2.Speicher mal beobachtet und jeweils ein 
kurzes log generiert. Wenn ich nicht falsch liege wird die Temperatur 
mit Telegramm 938_0 übertragen. In den 3 Logs habe ich versucht 
folgendes einzufangen:
 - 21:12:05 Wechsel von 63,1 nach 63,0 ºC
 - 21:18:10 Wechsel von 63,0 nach 62,9 ºC
 - 21:23:16 Wechsel von 62,9 nach 62,9 ºC
des Temperatur Fühler im Solar Speicher 2 unten.

In den beiden anderen Logs habe ich versucht
 - 21:27:19 Umschaltung des Ventil nach SP2
 - 21:29:20 Umschaltung des Ventil nach SP1
einzufangen.
Vermute mal das wird mit Telegramm 986_5 übertragen.
Hoffe das hilft erst einmal ...

Gruß,
Jürgen

[Norbert S. (junky-zs)]

Jürgen schrieb:
> Ich habe die Temperatur des 2.Speicher mal beobachtet und jeweils ein
> kurzes log generiert. Wenn ich nicht falsch liege wird die Temperatur
> mit Telegramm 938_0 übertragen.
Wird mit Telegramm 866_0_0 übertragen (siehe LibOfficeCal-Datei im 
tar-file).
Habe die Werte/Bytes kommentiert und die Solar Temperatur-Sensornamen 
(TSxy) hinzugefügt.

> Umschaltung des Ventil nach SP1
> Vermute mal das wird mit Telegramm 986_5 übertragen.
Ja, sieht so aus. Wert ist:0 bei SP1 und (64)hex->100 bei SP2.

Bitte kontrollierte mal die Anschlüsse im MS200 oder poste ein Foto. 
Daraus könnte ich die SolarOption Deines System extrahieren, mit den 
Infos der Telegramme vergleichen und die Temperatur-Sensoren zuordnen.

Entnehmen kann ich aus den Telegrammen z.Zeit:
 Solaroption: BDI
 ist:
 B := Umschaltung 2.Speicher mit Umschaltventil
 D := Heizungsunterstützung Speicher2
 I := Umladesystem bei Speicher-Reihenschaltung
Ob dies so stimmt wäre zu klären.

Die Projekt-Software ist noch nicht für die vielen Solar-Konfigurationen 
eines MS200 ausgelegt.
Es wird zwar z.Zeit eine 2. Solargrafik mit dem rrdtool angezeigt, aber 
nur wenn ein zweiter Solar-Kollektor mit Sensor TS7 vorhanden ist.
Dies ist aber in Deinem System nicht vorhanden.

Die Dekodierung der Solar-Telegramme für die Cxyz-Regler muss ich 
erweitern.
Deine Log-Files sind da Gold wert :-)
Über die Darstellung als rrdtool-Grafik muss ich mir noch Gedanken 
machen.
Auf jeden Fall kommen die zusätzlichen Infos auf der MQTT-Schnittstelle 
raus.

Bitte poste auch die Systemkonfiguration, es sind ein MM200 und MS200 
vorhanden mit einem ungemischten und einem gemischten Heizkreis laut 
Analyser.
Ob dies richtig ist kannst nur Du beurteilen.
Das Bild:
 Solar_Option_D_Sp2.png
zeigt die vermutlich bei Dir vorhandene Solar-Konfiguration.

Ich habe zusätzlich im github Projekt-Verzeichnis ein neues Issue:28 
angelegt.
Siehe URL:https://github.com/norberts1/hometop_HT3/issues/28
Kommentare, Logfiles etc. können auch da abgelegt werden.

Gruß Norbert

[Jürgen (jl2)]

Hallo Norbert,

ich nutze aktuell die Option 1ABJ und genau so angeschlossen wie im 
angefügten Bild ersichtlich. Zur Verwirrung trägt offensichtlich bei das 
mit dieser Option der Fühler TS11 (unten SP3) am Anschluss TS8 des MS200 
sowie TS10 (oben SP1) am TS7 des MS200 angeschlossen wird. Die Option K 
und P nutze ich nicht.
Somit werden:
 - TS1, TS2, TS5 mit VS2 für die Solar Ladung,
 - TS3, TS4 mit VS1 für die Heizungsunterstützung,
 - TS10, TS11 und PS7 für die Umladung
genutzt. Das sollte auch so in den logs so zu sehen sein.

Das der Wert des TS5 im Telegram 866_0_0 Byte22+23 steht kann ich so 
bestätigen. Hatte den Ananlyzer laufen als die Anzeige im CW400 für Sp2 
von 80,0 auf 79,9 Grad gefallen ist.
Siehe Bild 866_0_0: Byte 22/23 = hex 031f, ist dez 799 und geteilt durch 
10 = 79,9 Grad.

Gruß,
Jürgen

[Markus J. (mjotter)]

Hallo,

kann man die Uhrzeit synchronisieren?
Also die Uhr/Datum der Heizung mit dem RPI einstellen?

[Norbert S. (junky-zs)]

Markus J. schrieb:
> kann man die Uhrzeit synchronisieren?
> Also die Uhr/Datum der Heizung mit dem RPI einstellen?
Dies funktioniert natürlich nur mit den aktiven Adaptern 
(ht_pitiny/ht_piduino), ist aber z.Zeit nicht in der Software enthalten.

Das Einstellen der Uhrzeit mit EMS Bus-Telegrammen teste ich alsbald.

Eine Synchronisierung der Uhrzeit könnte mit der lokal auf dem RPi 
vorhandenen Zeit erfolgen, die dann mit ntp synchronisiert ist.
Eine manuell eingegebene Zeit halte ich für die Synchronisation 
ungeeignet.
Die kann man dann ja auch am Systemregler (Fxzy / Cxyz) eingeben.

Gruß Norbert

[Markus J. (mjotter)]

Hi Norbert,

ich habe die aktuelle Version neu augesetzt. Incl Debian 12 (bookworm)
Mit MQTT eingeschaltet war die Fehlermeldung, das die Config-Datei nicht 
passt. Damit konnte ich nichts anfangen.

Habe den Fehler gefunden: (für die falsche Fehlermeldung)

Zeile 987 ( 
https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/sw/lib/Ccollgate.py#L987
) läuft auf Fehler.
Daher wird Zeile 988 nicht ausgeführt.
Und die Fehlermeldung in Zeile 995 ist falsch
https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/sw/lib/Ccollgate.py#L995

Grund war, das ich kein paho-mqtt verfügbar hatte.
mit
 apt install python3-paho-mqtt
lief es dann.

Keine Ahnung wieso  ( sudo pip3 install paho-mqtt;)
https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/.mqtt_setup.sh#L69
nicht ausgereicht hat.

[Norbert S. (junky-zs)]

Markus J. schrieb:
> ich habe die aktuelle Version neu aufgesetzt. Incl Debian 12 (bookworm)
> Mit MQTT eingeschaltet war die Fehlermeldung, das die Config-Datei nicht
> passt...

Danke für die Fehlersuche und die Lösung.

Ursache ist sicher nicht Debian 12 sondern wahrscheinlich die Verwendung 
von pip3 im Installation-Script.
Habe dazu im Projekt einen neuen issue:29 aufgemacht und Details 
hinzugefügt.
Siehe:
 https://github.com/norberts1/hometop_HT3/issues/29
Bearbeitung und Korrektur erfolgt alsbald.

Gruß Norbert

[Norbert S. (junky-zs)]

Norbert S. schrieb:
> Bearbeitung und Korrektur erfolgt alsbald.
Habe ein neues Release: 0.7.2 erzeugt.
Das Tool: pip3 wird nicht mehr für die Installation verwendet und das 
Modul: Ccollgate.py enthält verbesserte Fehlermelde-Ausgaben.

Projektfiles siehe:
 https://github.com/norberts1/hometop_HT3/

Gruß Norbert

[Martin S. (matz666)]

Hallo Norbert.

Ich benötige wieder einmal deine Hilfe.

Ich habe meinen Raspberry an der Heizung ausgetauscht da die 
Netzwerkschnittstelle defekt war.

Nur bekomme ich aber mit der neuen Hardware (Rpi3) keine Daten.

Ich habe die alte SD Karte versucht, sowie eine Neuinstallation.

Beide male bekomme ich keine Daten.

Hier kurz der Aufbau:
RPI3 als Socket Server mit deinem ht_piduino unter 192.168.x.6
VM als Socket Client der die Datenbank, RRD und MQTT erledigt unter 
192.168.x.137.

Leider bekomme ich schon keine Ausgabe wenn ich im Browser 
192.168.x.6:48008 aufrufe.

Ebenso finde ich es komisch das die Ausgabe von ls /dev/tty* kein 
/dev/serial0 enthält.

Ich bitte um einen Denkanstoß.

lg Martin

[Peter G. (metalfranke)]

Martin S. schrieb:
> Ebenso finde ich es komisch das die Ausgabe von ls /dev/tty* kein
> /dev/serial0 enthält.

wie kommst du darauf mit ls /dev/tty* irgendwas mit serial0 zu finden?
Ich würde etwas in der Richtung /dev/ttyAMA0 erwarten.

Gruß Peter

[Martin S. (matz666)]

>
> wie kommst du darauf mit ls /dev/tty* irgendwas mit serial0 zu finden?
> Ich würde etwas in der Richtung /dev/ttyAMA0 erwarten.
>
Ja das ist ein Schreibfehler.

Du hast vollkommen recht, ich wollte mich auf ttyAMA0 beziehen.

Martin

[Martin S. (matz666)]

Neuer Versuch mit neuem OS auf der SD Karte:

.) nach der Installation --> kein ttyAMA0 kein serial0
.) Script ht_project_setup.sh ausgeführt --> kein ttyAMA0 kein serial0

Fehlersuche:
Nach dem deaktivieren des BT Modules in der /boot/firmware/config.txt
--> ttyAMA0 und serial 0 vorhanden

nun folgender Fehler im ht_proxy:
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: 
self.RequestHandlerClass(request, client_address, self)
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]:   File 
"/usr/lib/python3.11/socketserver.py", line 757, in _init_
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]:     self.finish()
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]:   File 
"/home/pi/HT3/sw/lib/ht_proxy_if.py", line 843, in finish
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: 
_ClientHandler.remove_client(self._myownID)
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]:   File 
"/home/pi/HT3/sw/lib/ht_proxy_if.py", line 733, in remove_client
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: 
txThread=self._thread.pop(clientID)
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: 
^^^^^^^^^^^^^^^^^^^^^^^^^^
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: KeyError: 5
Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: 
----------------------------------------

es ist zum Verzweifeln.

weiter Fehlersuche:
User Pi in die gruppe tty hinzugefügt --> sudo adduser pi tty
Reboot.

aktuell kommen Daten !!!!

noch ein Frage an Norbert, da ich das weder im Forum noch im Git 
gefunden habe.
Sollte der Adapter für den Bus bei der Ausführung des Scripts schon 
aufgebaut und angeschlossen sein, oder macht es keinen Unterschied wenn 
nicht.

Gruß Martin

[Norbert S. (junky-zs)]

Hallo Martin,
es liegen offensichtlich zwei Fehler vor:
1. serial port nicht richtig konfiguriert.
2. Starten des proxy-servers 'ht_proxy.py' und Bind auf 'localhost' 
nicht erfolgreich.
Folgendes hast Du sicher durchgeführt:
- Neuinstallation des OS auf einem RPi3.
- Neuestes HT3-Projekt Release installiert als user: 'pi'.
- Aufruf des Installations-Scripts aus dem Release.

Zu 1:
Martin S. schrieb:
> weiter Fehlersuche:
> User Pi in die gruppe tty hinzugefügt --> sudo adduser pi tty
> Reboot.
Richtig ist:
sudo adduser pi dialout
Dies wird automatisch im Installations-Script gemacht. User pi sollte 
daher in der Gruppe 'dialout' sein. Die zugehörige(n) Schnittstelle(n) 
sind dann ebenfalls in dieser Gruppe.
Dazu bitte auch 'sudo raspi-config' aufrufen und die serielle 
Schnittstelle prüfen bzw. richtig konfigurieren (siehe Bilder).
Siehe auch URL:
https://www.raspberrypi.com/documentation/computers/configuration.html#uarts-and-device-tree

Zu 2:
Das Starten des ht_proxy - Servers sollte auf die lokale Adresse 
'localhost' immer möglich sein, wenn die serielle Schnittstelle richtig 
konfiguriert ist.
Das bei Deinem System beim 'Bind' auf 'localhost' eine Exception 
geworfen wird kann ich mir nicht erklären, es sei denn das Du die 
default-Konfiguration verändert hast.

> Sollte der Adapter für den Bus bei der Ausführung des Scripts schon
> aufgebaut und angeschlossen sein, oder macht es keinen Unterschied wenn
> nicht.
Für eine Erstinstallation nicht erforderlich, für jede weitere ist dies 
jedoch besser weil eventuell noch die Prozesse laufen und noch die 
Datenerfassung läuft.

Gruß Norbert