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?