Forum: Projekte & Code Heizungs-Datenerfassung (HT3)

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

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

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

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

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

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

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

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

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

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

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

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

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

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.:

1

#!/usr/bin/perl

2

#

3

use strict;

4

use warnings;

5

use RRDTool::OO;

6

7

my $DB_heizgeraet  = "/home/ralf/HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd";

8

my $heizgeraet_rrdh = RRDTool::OO->new(file => $DB_heizgeraet);

9

#

10

$heizgeraet_rrdh->update (

11

  time   => 1418559640,

12

  values => {

13

   T_vorlauf_soll=>37,

14

   T_vorlauf_ist=>35.9,

15

   T_ruecklauf=>3276.8,

16

   T_mischer=>23.5,

17

   V_modus=>1,

18

   V_brenner_motor=>0,

19

   V_brenner_flamme=>0,

20

   V_leistung=>0,

21

   V_heizungs_pumpe=>1,

22

   V_zirkula_pumpe=>0,

23

   V_speicher_pumpe=>0,

24

   T_aussen=>6.1,

25

   C_betrieb_gesamt=>5029,

26

   C_betrieb_heizung=>4842,

27

   C_brenner_gesamt=>1871,

28

   C_brenner_heizung=>1656,

29

   V_spare_1=>0,

30

   V_spare_2=>0,

31

   }

32

);

33

# ---- error occured: -------

34

# 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.:

1

NAME=HT3_Logger.py

2

NAME_SCRIPT=ht3_logger

3

USER="ralf"

4

DAEMON=/home/$USER/HT3/sw/$NAME

5

DAEMON_ARGS=""

6

PIDFILE=/home/$USER/HT3/sw/var/run/$NAME_SCRIPT.pid

7

APPLICATION_FOLDER=/home/$USER/HT3/sw/

8

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....

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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',
  },

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

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

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?

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

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

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

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

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

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

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',
  },

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

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?

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

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.

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

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

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

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

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

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

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.

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

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

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

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"

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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?

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

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.

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

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

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

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

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

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!

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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