Heizungs-Datenerfassung (HT3)

[Juri K. (iuser)]

Hallo,

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

Gruß
Juri

[Norbert S. (junky-zs)]

Hallo Stephan,

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

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

Gruß Norbert

[Juri K. (iuser)]

Hallo Norbert,

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

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

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


Gruß
Juri

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

[Norbert S. (junky-zs)]

Hallo Juri,

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

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

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

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

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

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

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

@Alle

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

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

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

good news and bad news:

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

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

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

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

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

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

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

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


Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

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

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

Gruß,
Stephan

[Stephan (Gast)]

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

[Norbert S. (junky-zs)]

Hallo Stephan,

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

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

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

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

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

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

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

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

danke für das Logfile. Werde es analysieren.

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

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

Gruß Norbert

[Klaus (Gast)]

Hallo,

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

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

Gruß
Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

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

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

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

[Klaus (Gast)]

Hallo Norbert,

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

Gruß Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

> Ich bekomme allerdings eine Fehlermeldung
wie lautet die Fehlermeldung?

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

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

Gruß Norbert

[Stephan (Gast)]

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

Hallo Norbert,

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

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

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

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

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

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

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

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

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

Gruß Norbert

[Klaus (Gast)]

Hallo Norbert,

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

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

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

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

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

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

Anbei noch ein Logfile und die Anlagenkonfiguration.

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

Gruß
Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

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

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

Gruß Norbert

[Klaus (Gast)]

Hallo Norbert,

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

Gruß Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

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

Danke im Voraus!
Gruß Norbert

[Stephan (Gast)]

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

Gruß, Stephan

[Klaus (Gast)]

Hallo Norbert,

deine Änderung scheint zu funktionieren.

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

Gruß
Klaus

[Klaus (Gast)]

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

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

[Norbert S. (junky-zs)]

Hallo Klaus,

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

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

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

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

Herzlichen Dank,
Stephan

[Nils R. (augur)]

Hi.

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

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo,

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

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

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

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

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

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

Im Modulkopf ist eine kurze Beschreibung enthalten.

Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:

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

Hi,

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

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

Viele Grüße,
Nils

[Stephan (Gast)]

Hallo Nils,

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

Gruß,
Stephan

[Stephan (Gast)]

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

Hallo Norbert,

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

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

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

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

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

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo,

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

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

Gruß Norbert

[Nils R. (augur)]

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

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

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

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

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

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

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

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

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

Gruß Norbert

[Juri K. (iuser)]

Hallo,

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

Gruß
Juri

[Klaus (Gast)]

Hallo,

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

Hier die Änderung:

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


Gruß
Klaus

[Norbert S. (junky-zs)]

Hallo,

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

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

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

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

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

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

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan T.,

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

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

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

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

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

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

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

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

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

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

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

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

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

Danke und Gruß,
Stephan

[Lasse (Gast)]

Moin Norbert und alle anderen,

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

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

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

Vielen Dank schonmal und schönen Gruß,
Lasse

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

[Stephan (Gast)]

Hallo Lasse,

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

Gruß,
Stephan

[Lasse (Gast)]

Stephan,

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

Gruss,
Lasse

[Stephan (Gast)]

Hallo Lasse,

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

Gruß,
Stephan

[Stephan (Gast)]

Hallo Lasse,

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

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Lasse,

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

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

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

Gruß Norbert

[Lasse B. (preamp)]

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

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


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

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


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

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


Lasse

[Norbert S. (junky-zs)]

Hallo Lasse,

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

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

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

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

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

Gruß Norbert

[Lasse B. (preamp)]

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


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

Lasse

[Lasse B. (preamp)]

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

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

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

[Norbert S. (junky-zs)]

Hallo Lasse,

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

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

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

Gruß Norbert

[Lasse B. (preamp)]

Moin auch,

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

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

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

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

B0 00 00
B0 00 09

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



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


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

Lasse

[Lasse B. (preamp)]

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

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

[Lasse B. (preamp)]

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

[Norbert S. (junky-zs)]

Hallo Lasse,

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

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

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

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

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

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

Gruß Norbert

[Lasse B. (preamp)]

Hallo Norbert,

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

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

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

[Lasse B. (preamp)]

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

[Norbert S. (junky-zs)]

Hallo Lasse,

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

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

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

Gruß Norbert

[Lasse B. (preamp)]

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

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


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

Vielen Dank! Werde ich nachher mal testen.


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

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

Gruß,
Lasse

[Lasse B. (preamp)]

Die Solarerfassung funktioniert jetzt weitestgehend, vielen Dank 
nochmal!

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

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

Ideen? :)

Gruss, Lasse

[Norbert S. (junky-zs)]

Hallo Lasse,

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

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

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

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

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

Gruß Norbert

[Lasse B. (preamp)]

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


Hier nochmal ein paar Solartelegramme die ich ausfindig machen konnte.

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

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


Gruß, Lasse

[Norbert S. (junky-zs)]

Hallo,

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

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

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

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

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

vielen Dank für die viele Arbeit!!!

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

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

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

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

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:

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

Hallo Norbert,

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

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

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

Danke und Gruß,
Stephan

[Stephan T. (stephant)]

Hallo Norbert,

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

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

[Norbert S. (junky-zs)]

Hallo Stephan,

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

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

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

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

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

Gruß Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

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

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

Gruß Norbert

[Mario R. (upd8r)]

Moin zusammen,

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

Hatte das vielleicht schon mal jemand?

BG
Mario

[Norbert S. (junky-zs)]

Hallo Mario,

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

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

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

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

Gruß Norbert

[Mario R. (upd8r)]

Hallo Norbert,

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

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

Also doch ein Bug in der SW? duckundwech

Danke + Gruß,
Mario

[Norbert S. (junky-zs)]

Hallo Mario,

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

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

Gruß Norbert

[Mario R. (upd8r)]

Hi Norbert,

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

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

Danke!

[Mario R. (upd8r)]

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

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

[Norbert S. (junky-zs)]

Hallo Mario,

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

Gruß Norbert

[Mario R. (upd8r)]

Moin Norbert,

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

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

[Mario R. (upd8r)]

Hi Norbert,

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

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

Danke und sorry für die ganzen Nachfragen.

[Norbert S. (junky-zs)]

Hallo Mario,

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

  ht_binlogclient.py <logfilename deiner wahl.log>

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

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

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

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

Gruß Norbert

[Mario R. (upd8r)]

Danke, ich habe das jetzt auskommentiert und schaue mal.

Schönes Rest-WoE!

[Stephan T. (stephant)]

Hallo Norbert,

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

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

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

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

Gruß Norbert

[Mario R. (upd8r)]

Hallo zusammen,

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

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

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

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

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

2 Screenshots anbei.

[Stephan T. (stephant)]

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

Hallo Norbert,

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

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

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

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

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo,

@Stephan
> Wenn es noch länger dauern würde, dann würd ich mir behelfen, indem mit
> PHP die ht_netclient-Befehle aufgerufen werden...
Es wird länger dauern mit einer FHEM-Modulanpassung. Dieses Jahr wird 
wohl nichts mehr draus. Für die Empfangsrichtung von Cxyz-Reglerdaten 
hast Du ja eine Testversion im Rennen jedoch für die Senderichtung ist 
da noch was zu tun.

@Mario R.
Grosses Lob an Mario, sieht klasse aus und ist auf jeden Fall mehr Wert 
als die rrdtool Drawanzeige.
Bleib dran und gib uns mehr davon. Vielleicht kann jemand Dich bei der 
Anpassung unterstützen.

Gruß Norbert

[Stephan T. (stephant)]

Hallo,

ich habe nach einigen Tagen immer wieder das Problem, dass die 
HTML-Seite nicht mehr aufrufbar ist. Der normale Apache läuft noch und 
nach einem "sudo /etc/init.d/httpd restart" ist auch die HT3-Indexseite 
wieder lesbar.
In /var/log finde ich nirgendwo eine Logdatei, die dazu irgendwas 
hilfreiches liefert.

Wo könnte ich noch gucken? Passiert ungefähr nach 6-7 Tagen und die 
Seite ist auf meinem Arbeits-PC ständig geöffnet.

Danke und Gruß,
Stephan

[Mario R. (upd8r)]

Warum nimmst Du nicht den Apache?

Also ich habe zwar keine Probleme mit dem httpd gehabt, aber da ich bei 
mir für die neuen Grafiken auch einen Web-Server installieren musste 
(hier nginx und PHP), habe ich auch den Pfad für die rrdtool-Grafiken 
angepasst.

Das geht sicherlich eleganter, aber ich habe einfach den Pfad in der 
ht3_worker.py hart auf /var/www/html umgesetzt. Müsste so ca, Zeile 285 
sein (laut vim).

285 # Draw-Path hart gesetzt
286 #        strsystemcmd = AbsPathandFilename + ' ' + Abspath2_db + ' ' + Abspath_2_draw + ' ' + str(hc_count)
287         strsystemcmd = AbsPathandFilename + ' ' + Abspath2_db + ' /var/www/html ' + str(hc_count)

Nicht vergessen, die index.html auch dorthin zu kopieren. httpd habe ich 
hier komplett gestoppt.

Nur als Anregung.

[Mario R. (upd8r)]

Mal kurz ein Update zu meiner HighCharts-Visualisierung. Das hier ist 
Stand 1.0.

Im Großen und Ganzen bin ich schon zufrieden, gibt aber noch ein paar 
ToDos.

- eindeutschen (muss nicht unbedingt Englisch sein bei mir)
- momentan kann man nur x Stunden/Tage von "jetzt" in die Vergangenheit 
schauen (siehe Menü oben), ich hätte gern einen Zeitraum zum Auswählen

Anmerkungen:
Ich habe alles umgesetzt, was für mich wichtig ist. Das ist nicht 
zwangsläufig das gleiche wie in den rrdtool-Grafiken jetzt. Der ein oder 
andere mag also was vermissen.
Es ist zwar dynamisch, aber alles über 24 Stunden kann im Browser schon 
sehr zäh werden, schließlich sind da Tausende Datenpunkte, die 
HighCharts darstellen muss und die er sich prinzipbedingt auch wirklich 
in den Speicher lädt. 7 Tage wie im Menü funktionieren technisch nach 
dem Hochsetzen von PHP-Speicherlimits und Timeouts, 10 Tage eher nicht 
mehr. Alles läuft auf einem Pi2 Model B. Getestet nur unter Chrome.

Muss mal schauen, wie ich das zum Download bereitstelle, falls Interesse 
besteht.

[Adam (Gast)]

Hallo,

sei ca. 2 Wochen durch paar Sekunden habe ich falsche Daten bei 
Heizkreis, durch paar Sekunden richtige Daten. Datenbase habe ich 
gelöscht und neu angelegt. Warmwasser und HK1 zeigt richtige Werte. Ich 
habe sogar eine Kopie von Herbst auf die SD-Karte noch mall überspielt.
Was kann da sein?

[Norbert S. (junky-zs)]

Hallo Adam,

was hat sich denn an Deinem Heizungssystem und der Datenerfassung in den 
letzten 2 Wochen geändert?
Welchen Adapter-Typ und welche Software-Version setzt Du ein und wie 
sieht Dein Heizungssystem (Heizgeräte- und Regler-Typ) aus ?

Gruß Norbert

[Adam (Gast)]

Hallo Norbi,
danke für Rückmeldung.
In letzter Zeit hat sich bei mir gar nichts geändert. Plötzlich falsche 
Daten. S. Bilder.
Miniadapter für Raspi, SW 0.2.2, Heizgerät ZSB14-3C mit neue variable 
Pumpe,
1 Heizkreis.
Grüße
Adam

[Adam (Gast)]

Hallo Norbi,
heute habe ich ganzen System und HT3 neu installiert -> gleiche Probleme 
:(
Muss was in Hardware liegen. Was meinst Du? Was soll ich prüfen?
Grüße

[Norbert S. (junky-zs)]

Hallo Adam,

eine Neuinstallation ist nicht nötig und die Hardware ist auch in 
Ordnung.
Grund ist wohl eine Fehldetektion bei der MessageID 24 und der 
Geräteadresse (10)hex -->> Regler.
Falsch ist die Sequenz:
90 00 18 00 18 ... CRC 00
Richtig ist:
88 00 18 00 27 ... CRC 00
Bei der falschen Sequenz stimmen zufällig die MsgID und die CRC und 
deshalb wird dieses Telegramm auch dekodiert.
Um das zu vermeiden mache bitte folgende Änderung im SW-Modul:
 ~/HT3/sw/lib/ht_discode.py Zeile: 2580
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 46, 47, 64, 100, 106],
Es wird damit die MessageID 24 (18)hex für Gereäteadresse:(10)hex in die 
Blacklist übernommen und dieses falsche Telegramm unterdrückt.
Probiere es aus und gib Bescheid ob es funktioniert.

Wenn Du Zeit hast kannst Du auch noch ein binäres Logfile (<1Std.) 
erzeugen und hier im Forum reinstellen oder mir an meine PM senden. Dann 
kann ich dieses Fehlverhalten bei mir analysieren.

Hinweis:
 Diese SW-Anpassung ist 'nur' für passive HT-Adapter nötig (Mini-/ 
Micro-Adapter)
 Für die ht_pitiny und ht_piduino-Adapter ist dies nicht erforderlich da 
diese das Telegramm-Ende korrekt erkennen können.

Gruß Norbert

[Adam (Gast)]

Hallo Norbi,

in Verzweiflung habe ich Heizkessel ausgeschaltet (vom Netz getrennt) 
und wieder eingeschaltet und ... HT3 wieder funktioniert richtig !!

Geht mein Regler langsam kaputt ?

Wenn das wieder passiert, probiere Dein Vorschlag. Seit gestern klappt 
alles.

Danke für Deine Hilfe und grüße
Adam

[Philippe D. (philippe_d)]

Hallo zusammen,

danke an alle für ihren Einsatz die Heatronic-Schnittstelle zu 
analysieren!

Mit den zusammengetragenen Informationen habe ich mir einen HT3-USB 
Adapter auf Basis eines Arduino M0 Pro gebaut und verarbeite die 
Empfangsdaten mit einem Python-Skript. Gespeichert werden die Messwerte 
in einer InfluxDB-Instanz.

System: Junkers CerapurACU ZWSB 22/28-3 mit CW400-Regler

Ich habe jetzt noch ein paar HT3-Telegramme, die unbekannt sind
(die mit *):

   90 00 06 00 11 01 11 05 2D 31 03 00 10 FF 00 A7 00
** 90 08 23 00 41 64 64 C5 00
   88 00 18 00 41 02 2A 32 00 01 23 20 C0 80 00 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 E3 00
   88 00 34 00 28 00 75 01 BD 81 00 00 03 00 00 07 3D 00 03 EA 00 63 00
** 90 08 1A 00 41 64 64 7E 00
** 90 00 FF 00 01 67 00 00 BD 00
** 90 00 FF 00 02 1D 00 00 09 07 5C 00
** 90 08 35 00 11 01 A9 00
** 90 08 35 03 28 6B 00

[Philippe D. (philippe_d)]

Vorab, so nenne ich die Bestandteile eines Telegramms:

HT3 Message-Frame
-----------------

  Byte 0   Byte 1   Byte 2   Byte 3   Byte 4
+--------+--------+--------+--------+------------+-------+-------+
! Source ! Target ! MsgID  ! SubID  ! (Data ...) !  CRC  ! Break !
+--------+--------+--------+--------+------------+-------+-------+

Byte 0 bis 3 bilden den Header. Und ein Telegramm hab ich 
"entschlüsselt", mit dem Header 90 00 FF 08.
Die 2 Bytes an Position 6 und 7 bilden einen 24h-Zähler (Rückwärts)

   [Fri Jan 13 21:29:29.460 2017] 90 00 FF 08 01 A5 00 5B 45 00
   [Fri Jan 13 21:29:51.487 2017] 90 00 FF 08 01 A5 05 A0 B4 00
   [Fri Jan 13 21:30:06.603 2017] 90 00 FF 08 01 A5 00 5B 45 00
   [Fri Jan 13 21:30:21.548 2017] 90 00 FF 08 01 A5 05 A0 B4 00
** [Fri Jan 13 23:05:29.130 2017] 90 00 FF 08 01 A5 05 9B 8F 00
   [Fri Jan 13 23:10:27.200 2017] 90 00 FF 08 01 A5 05 96 82 00
   [Fri Jan 13 23:15:28.608 2017] 90 00 FF 08 01 A5 05 91 85 00
   [Fri Jan 13 23:20:26.584 2017] 90 00 FF 08 01 A5 05 8C 98 00
   [Fri Jan 13 23:25:28.024 2017] 90 00 FF 08 01 A5 05 87 93 00
   [Fri Jan 13 23:30:29.494 2017] 90 00 FF 08 01 A5 05 82 96 00
   [Fri Jan 13 23:35:27.704 2017] 90 00 FF 08 01 A5 05 7D 69 00
   [Fri Jan 13 23:40:28.925 2017] 90 00 FF 08 01 A5 05 78 6C 00
   [Fri Jan 13 23:45:26.917 2017] 90 00 FF 08 01 A5 05 73 67 00
   [Fri Jan 13 23:50:28.387 2017] 90 00 FF 08 01 A5 05 6E 7A 00
   [Fri Jan 13 23:55:29.811 2017] 90 00 FF 08 01 A5 05 69 7D 00
   [Sat Jan 14 00:00:27.787 2017] 90 00 FF 08 01 A5 05 64 70 00

Der Zähler startet bei 05A0 == 1440 Minuten.
Bei ** bedeutet 059B == 1435 Minuten ...

Die Frage ist nun welchem Zweck dieser Rückwärtszähler dienen könnte?

[Norbert S. (junky-zs)]

Hallo  Philippe,

Deine Entschlüsselung des HT-Messagesframes ist nicht ganz korrekt. Es 
gibt im Prinzip zwei bzw. drei Messageklassen:
1. Byte2 kleiner als (F0)hex
  Dann sind die ersten 4 Byte als Telegramm-Header wichtig.
2. Byte2 grösser als (F0)hex
  Dann sind die ersten 6 Byte als Telegramm-Header wichtig.
3. Request-Telegramme
  Bei diesen sind die ersten 7 Byte wichtig.
  Diese werden jedoch nur für Sonderzwecke benötigt.

Dann ergibt sich folgendes Bild:
Zu1.
 Byte0  Byte1  Byte2 Byte3   Byte 4
+------+------+-----+------+----------+---+-----+
!Source!Target!MsgID!Offset!(Data ...)!CRC!Break!
+------+------+-----+------+----------+---+-----+

Zu2.
 Byte0  Byte1  Byte2  Byte3  Byte4   Byte5  Byte6
+------+------+------+------+-------+------+----------+---+-----+
!Source!Target!Marker!Offset!ID High!ID Low!(Data ...)!CRC!Break!
+------+------+------+------+-------+------+----------+---+-----+

Zu3.
Sonderfall, hier nicht gezeigt.

Die HTML-Doku habe ich mit beigefügt. Diese ist ja ohnehin Bestandteil 
des git-Projektes.

Deine Telegramme wirst Du damit besser analysieren können.

Gruß Norbert

[Philippe D. (philippe_d)]

Hallo Norbert,

die erweiterten Telegramme mit einer 'MsgID' grösser/gleich 0xF0 sind 
mir bekannt.
Mir geht es darum, dass ich die Bezeichnung 'Offset' im Header nicht 
mag, weil sie impliziert, dass die Nutzdaten erst weiter hinten im 
Telegramm zu finden sind.
Diese 'Offset' Bezeichnung habe ich in alten Dokumenten von Buderus 
gefunden (ca. von 2001). Es ging dort aber um die 3964R Prozedur, wo 
direkt der Speicher beschrieben wurde. Da wurde der Offset benutzt, um 
anzugeben wo die Daten einzusortieren sind.

Bei meiner Heizung gibt es 2 Telegramme mit der 'MsgID' 0x35 aber 
unterschiedlicher 'SubID':

[Fri Jan 13 21:28:23.674 2017] 90 08 35 00 11 01 A9 00
[Fri Jan 13 21:28:23.690 2017] 90 08 35 03 37 74 00

Die erweiterten Telegramme werte ich noch nicht aus, da sie andere 
Längen haben als in deiner Übersicht.

Anbei noch ein Screenshot meiner Lösung mit Influx/Grafana.

Gruß
Philippe

[Philippe D. (philippe_d)]

Hallo Norbert,

In deiner Doku hast du ja die Message-IDs 677...684 - Heizkreis: 
Systemwerte...
Da dreht meine Heizung etwas am Rad (oder ist es mein Hamster, der im 
Schleudergang ist ?!?)

[Fri Jan 13 21:28:29.977 2017] 90 00 FF 0F 01 A5 01 0C 60 00
[Fri Jan 13 21:29:29.210 2017] 90 00 FF 0D 01 A5 00 5B 03 A1 F3 00
[Fri Jan 13 21:29:29.460 2017] 90 00 FF 08 01 A5 00 5B 45 00
[Fri Jan 13 21:29:30.614 2017] 90 00 FF 03 01 A5 2A 7D 00
[Fri Jan 13 21:29:30.801 2017] 90 00 FF 06 01 A5 2A 1E B4 00
[Fri Jan 13 21:29:40.785 2017] 90 00 FF 00 01 A5 00 D0 23 2A 3F 00 2A 1E 00 5B 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00
[Fri Jan 13 21:29:41.066 2017] 90 00 FF 19 01 A5 06 04 00 00 00 00 FF 64 41 00 3C 01 FF 01 02 AB 00

Das längste Telegramm 'FF 00 01 A5' ist mit 33 Bytes zu kurz (soll 39 
Bytes), aber die CRC stimmt ... Die Raum-Soll- und Ist-Temperatur stimmt 
schon mal :o)


Gruß
Philippe

[Norbert S. (junky-zs)]

Hallo Philippe,

>Mir geht es darum, dass ich die Bezeichnung 'Offset' im Header nicht
>mag, weil sie impliziert, dass die Nutzdaten erst weiter hinten im
>Telegramm zu finden sind.
Genau so ist es aber.
Allerdings muss man beachten das dieser Offset vom ersten Datenbyte (:= 
0) an gezählt wird und nicht vom Telegramm-Anfang.
Und dieser Offset ist bezogen auf das erste Datenbyte im kompletten 
Telegramm (Offset:=0).
Somit kann ein Modul auch Teilmengen an Informationen an die Steuerung 
senden.

Zu sehen ist genau dies auch bei Deinen erfassten Telegrammen:
Die Detail-Telegramme mit Offset:=03 und :=08 sind z.B.:

         90 00 FF 03 01 A5 ->2A<- CRC Break
                            90 00 FF 08 01 A5 ->00 5B<- CRC Break
Das sind die makierten Detail-Werte im kompletten Telegramm:
90 00 FF 00 01 A5 00 D0 23 ->2A<- 3F 00 2A 1E ->00 5B<- 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00

Ich habe dies hoffentlich ins rechte Licht/Spalte gerückt damit der 
Durchblick besser wird :-)
>Die Frage ist nun welchem Zweck dieser Rückwärtszähler dienen könnte?
In der Message '01 A5' bedeuten diese Zähler die Zeit bis zum nächsten 
Programmwechsel und es sind noch weitere Programminformationen 
enthalten.
Diese Informationen habe ich bisher noch nicht genutzt und die gibt es 
auch so nur bei EMS2 bzw. Cxyz-Regler).

Gruß Norbert

[Philippe D. (philippe_d)]

Hallo Norbert,

Danke, Danke, Danke!

Irgendwie hatte ich das im ganzen Thread bisher nicht verstanden (schäm)
Mit deiner Erklärung kann ich die Bezeichnung 'Offset' doch noch lieb 
gewinnen!

Witzig wird es aber bei diesen 2 Telegrammen:

[Fri Jan 13 21:29:40.785 2017] 90 00 FF 00 01 A5 00 D0 23 2A 3F 00 2A 1E 00 5B 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00
[Fri Jan 13 21:29:41.066 2017] 90 00 FF 19 01 A5 06 04 00 00 00 00 FF 64 41 00 3C 01 FF 01 02 AB 00

Offset '0x19' kommt genau auf dem CRC '0x68' zu liegen ...
Hmmm, in der alten Doku stand ja, dass der Offset zum einsortieren der 
Daten diene ...

Könnte es sein, dass das 2. Telegramm eine 'Fortsetzung' darstellt?
So, frei nach:

'Offset == 0': Schreibe die Daten an den Anfang des 'Array'
'Offset > 0': Füge die Daten ab Index 'Offset' ins 'Array'

'Array' im Sinne von Pointer (o.ä.) auf reservierten Speicherbereich für 
bestimmtes Telegramm ...



Gruß
Philippe

[Norbert S. (junky-zs)]

Hallo Philippe,

>Könnte es sein, dass das 2. Telegramm eine 'Fortsetzung' darstellt?
Ja, das sehe ich auch so.
Die maximale von mir bisher gesehene Telegrammlänge bei den Fxyz-Reglern 
war 33 Byte (Header,Daten,CRC und Break zusammen).
Diese Längenbegrenzung macht ja auch Sinn, da für die Zeit der 
Telegramm-Übertragung keine anderen Telegramme gesendet werden können 
und die CRC(8Bit) auch mehrdeutig wird.

Jetzt hat man wohl bei den Cxyz-Reglern mehr Informationen übertragen 
müssen/wollen und hat eine Art: 'Fortsetzung folgt sogleich' erzeugt.
Somit ergibt sich bei weiterhin gleicher maximaler Länge von 33 Byte pro 
Telegramm ein Offset von 25 := 19(hex) im folgenden Telegramm mit der 
gleichen MessageID.

Wenn ich allerdings die Anzahl der Bytes Deiner Telegramme mit meiner 
Beschreibung der MsgID:677-684 vergleiche so passt da was noch nicht.
Ich habe mich auch bisher ein wenig gesträubt die restlichen Werte im 
Telegramm in der Doku zu beschreiben, da mir der Nähr-/Mehr-Wert noch 
ein wenig fehlt zumal ich auch 'nur' einen Fxyz-Regler habe.
Es sind Informationen wie: Zeit bis zum nächsten Temperaturwert; Zeit 
seit letztem Temperaturwert f. Eco,Comfort...; Estrichtrocknung ect. 
enthalten.
Kein Wunder das so ein Krebsgeschwür von Telegramm da rauskommt.

Kannst Du die erfassten Daten binär in ein File schreiben und mir 
zukommen lassen?
Für eine weitere Analyse und Verbesserung der SW wäre dies hilfreich.

Gruß Norbert

[Martin S. (matz666)]

Guten Abend miteinander.

Nach langer Abstinenz bin ich wieder da.

Hier ein kurzer Überblick über meinen momentanen Stand.

Der Raspberry hat nun einen Apache2.

Die Daten der Sqlite Datenbank werden über PHP aus der Datenbank 
ausgelesen. --> d.H. Somit immer aktuell.

Solarertrag gesamt wird von Openhab errechnet und auch auf der Seite 
angezeigt.

Für den mobilen Zugriff wurde eine jquery gestaltet die aufklappbare 
Spalten hat und beinhaltet auch die Grafiken.

Bei Interesse kann der Code zur Verfügung gestellt werden.

Gruß Martin

[Philippe D. (philippe_d)]

Hallo Norbert,

anbei ein 24h-Log meiner Heizung im 7Zip-Paket, einmal als Hex-Dump mit 
1 Telegramm je Zeile und einmal in Binär.
Geht von Mo, 30.01.17 21:10 bis Di, 31.01.17 21:53, also müsste auch 
eine therm. Desinfektion drinn sein.


System: Junkers CerapurACU ZWSB 22/28-3 mit CW400-Regler

Daten/Einstellungen:

Wärmeerzeuger
Typ Steuereinheit: HT3
SW-Vers. Steuereinheit: 20.13
HCM/BCI-Nummer: 1604

Bedieneinheit
Typ: CW400
SW-Version: NF33.04

Heizungsprogramm Mo-Fr
ab 00:00 Heizen
ab 07:30 Absenken
ab 17:00 Heizen

Temperatureinstellungen
Heizen: 23°C
Absenken: 19°C

Sommer/Winter-Umschalt: Temp.
Sommerbetr.ab: 17°C

Warmwasser-Temperatureinstellungen
Warmwasser: 56°C
Warmwasser reduziert: 40°C

Warmwasser-Zeitprogramm Mo-Fr
ab 00:00 Aus
ab 05:30 Warmwasser
ab 08:00 Aus
ab 15:00 Reduziert
ab 18:00 Warmwasser

Thermische Desinfektion: Automatisch
Am Dienstag 11:45 bei 72°C

[Martin S. (matz666)]

Guten Morgen allerseits.

Für all jene die ihre Daten gerne über MQTT weitergeben würden hab ich 
nun gestern am Abend quick and dirty ein paar Bash Scripte geschrieben.

Der Raspberry benötigt das Packet mousqitto-clients mit dem er per 
Kommandozeile mit dem Broker kommunizieren kann.

Hier der Inhalt

#!/bin/bash
mqttserver="AdressedesServers"
#Solar
S_solar=$(sqlite3 /pfad/zur/Datenbank/HT3/sw/var/databases/HT3_db.sqlite "SELECT T_kollektor, T_speicher_unten, V_ertrag_stunde, C_laufzeit, V_solar_pumpe FROM solar ORDER BY rowid DESC LIMIT 1");
IFS="|"; declare -a solar=($S_solar)
mosquitto_pub -h $mqttserver -t /heizung/solar/T_kollektor -m "${solar[0]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/T_speicher_unten -m "${solar[1]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/V_ertrag_stunde -m "${solar[2]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/C_laufzeit -m "${solar[3]}"
mosquitto_pub -h $mqttserver -t /heizung/solar/V_solar_pumpe -m "${solar[4]}"

Das Script dann mit chmod +x lauffähig machen und im Crontab (crontab 
-e) alle Minuten oder 2 ausführen lassen.

Das ganze läuft bei mir mit mehreren Dateien jeweils für HK und Solar 
und Heizgerät auf einem Raspberry B ohne Probleme.

lg

Martin

[Adam (Gast)]

Hallo Norbert,

Adam schrieb:
> Hallo Norbi,
>
> in Verzweiflung habe ich Heizkessel ausgeschaltet (vom Netz getrennt)
> und wieder eingeschaltet und ... HT3 wieder funktioniert richtig !!
>
> Geht mein Regler langsam kaputt ?
>
> Wenn das wieder passiert, probiere Dein Vorschlag. Seit gestern klappt
> alles.
>
> Danke für Deine Hilfe und grüße
> Adam

Hallo Norbert,

ein oder zwei mall täglich durch 1 bis 6 Stunden kriege ich keine Msg 
24_0. D.h. ich kriege keine Infos über wichtigste Infos: Tsoll, Tist, 
Pumpenleistung, VLeistung.
Wo kann das liegen?

Grüße
Adam

[Norbert S. (junky-zs)]

Hallo Adam,

hattest Du schon die empfohlene SW-Anpassung eingebracht?
Falls nicht dann den markierten Wert einbringen.

~/HT3/sw/lib/ht_discode.py Zeile: 2580
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 46, 47, 64, 100, 106],

Damit wird dann die Meldung 24 (18)hex vom Regler unterdrückt.
Vom Heizgerät (Adr: 08) wird die dann immer noch ausgewertet.

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

bist Du denn schon mit Deinem Projekt weitergekommen, den FWxxx durch 
einen CWxxx bei Dir auszutauschen?

Aktuell kann man bei den CWxxx nämlich nur die Temperatur steuern und 
sonst nix. Ich würde aber gern die Zirkulation hierüber starten, da der 
CW ja keine Rücksicht darauf nimmt, ob jemand da ist. Und da wir 
wechselnde Schichten haben, macht es nicht wirklich Sinn, morgens um 7 
die Zirkulation zu starten, wenn keiner mehr da ist.

Wenn ich zu den Zeiten, wo aktuell der CW die Zirkulation startet, die 
Daten in der DB prüfe, sollte ich dann den Befehl sehen können?

Danke und Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

>bist Du denn schon mit Deinem Projekt weitergekommen, den FWxxx durch
>einen CWxxx bei Dir auszutauschen?
Dies habe ich auf Eis gelegt. Leider reicht es nicht nur den Regler 
auszutauschen, auch das Solarmodul muss ausgetauscht werden. Und deshalb 
verzichte ich drauf weil dies keinen Vorteil bringt (nur für Junkers :-)

>Ich würde aber gern die Zirkulation hierüber starten, da der
>CW ja keine Rücksicht darauf nimmt, ob jemand da ist.
Du kannst doch sicherlich die Zirkulationspumpe per Zirkulationsprogramm 
steuern. Damit ist eine wenn auch kleine Anpassung möglich.

>Wenn ich zu den Zeiten, wo aktuell der CW die Zirkulation startet, die
>Daten in der DB prüfe, sollte ich dann den Befehl sehen können?
Die Daten werden in die sqlite-DB geschrieben wenn sie auftreten. Somit 
könntest Du diese Telegramme dort auch wiederfinden. Da diese vom Regler 
kommen werden die Daten in der Heizkreis-Tabelle zu finden sein.
Das wird irgendwas mit Source:=(90)hex oder (98)hex und Target:=(08)hex 
am Telegrammanfang sein, also:
 90 08 .. .. oder 98 08 .. ..

Gruß Norbert

[Adam (Gast)]

Norbert S. schrieb:
> Hallo Adam,
>
> hattest Du schon die empfohlene SW-Anpassung eingebracht?
> Falls nicht dann den markierten Wert einbringen.
>
> ~/HT3/sw/lib/ht_discode.py Zeile: 2580
>     deviceadr_2msgid_blacklist = {
>         0x10: [11, 12, 24, 46, 47, 64, 100, 106],
>
> Damit wird dann die Meldung 24 (18)hex vom Regler unterdrückt.
> Vom Heizgerät (Adr: 08) wird die dann immer noch ausgewertet.
>
> Gruß Norbert

Hallo Norbert,

nach die SW-Anpassung läuft wieder alles richtig.

Besten Dank und grüße
Adam

[Thomas D. (nasi_be)]

Martin S. schrieb:
> ...
> #Solar
> S_solar=$(sqlite3 /pfad/zur/Datenbank/HT3/sw/var/databases/HT3_db.sqlite
> "SELECT T_kollektor, T_speicher_unten, V_ertrag_stunde, C_laufzeit,
> V_solar_pumpe FROM solar ORDER BY rowid DESC LIMIT 1");
> IFS="|"; declare -a solar=($S_solar)
> ...
>
> Das Script dann mit chmod +x lauffähig machen und im Crontab (crontab
> -e) alle Minuten oder 2 ausführen lassen.
>
> Das ganze läuft bei mir mit mehreren Dateien jeweils für HK und Solar
> und Heizgerät auf einem Raspberry B ohne Probleme.
>
> lg
>
> Martin

Hallo Martin,

ich habe versucht dein Script zu übernehmen, da ich so die ausgelesenen 
Daten per REST-API an OpenHAB übergeben kann.
Das funktioniert auch soweit, allerdings bekomme ich beim wiederholten 
Aufruf des Scripts immer die folgende Meldung:

Error Code SQLITE_LOCKED (6): Database Is Locked

Hattest du das Problem auch schon mal und konntest es irgendwie lösen?
Muss man vielleicht die aufgebaute Verbindung irgendwie wieder sauber 
trennen?

Viele Grüße
Thomas

[Martin S. (matz666)]

Hallo Thomas

Tut mir leid, hab erst jetzt gelesen das du Hilfe brauchst.

Jahatte das Problem hatte ich auch, hab mir dann einen netclient 
gebastelt der die daten über das Netzwerk vom Raspberry zieht. Er ist 
nur für den mqtt export zuständig. Auch hab ich festgestellt das ein 
großteile der usb sticks zu langsam ist.

Ich hab das Script nochmals angepasst um zu Überprüfen ob der Arry leer 
ist denn das verursacht Fehlermeldungen in Openhab.

Also wenn noch Interesse besteht melden.

[Norbert S. (junky-zs)]

Hallo,

es gibt ein neues Release: 0.3 zum Projekt auf github.
Wie gehabt zu erhalten mit :
  git clone https://github.com/norberts1/hometop_HT3.git
oder Download des ZIP-Files.

Neu ist der Daemon: ht_collgate der den HT3_Logger komplett ersetzt.

Die zusätzliche Schnittstellen: MQTT-Client und SPS-Interface können 
jetzt durch diesen neuen Daemon gestartet werden.
Die vorhandenen Datenbanken können weiter verwendet werden da sich diese 
Schnittstellen (sqlite und rrdtool) seit der Version: 0.2.2 nicht 
geändert haben.
Allerdings ist jetzt die Datenbank: sqlite per Default ausgeschaltet und 
nur die rrdtool-Datenbank ist aktiv.
Folgende Konfigurations-Werte sind per default gegeben:

 sqlite-Datenbank : Aus
 rrdtool-Datenbank: Ein
 MQTT-Client      : Aus
 SPS-Client       : Aus

Die Dokumentation gibt u.A. Auskunft über diese Konfiguration, die 
Installation des MQTT-Broker und pyhton-paho Library sowie über die 
Eigenschaften der SPS-Schnittstelle.

Die Steuerung der Heizung über MQTT-Befehle ist für die Fxyz- und die 
Cxyz- Regler enthalten und wenn man einen ht_transceiver (ht_piduino 
oder ht_pitiny) hat auch möglich.
Der ht_collgate verbindet sich mit dem ht_proxy.server, holt sich dort 
die RAW-Daten ab und dekodiert diese.
Die dekodierten Daten werden zu den Clients gesendet (MQTT) bzw. sind 
durch einen SPS-Client abfragbar.

Es werden weiterhin alle Adapter-Typen unterstützt.

Details gehen aus der Dokumentation hervor.

Gruß Norbert

[Martin S. (matz666)]

Hallo Norbert.

Erst mal herzlichen Dank das du nun auch MQTT Transport integriert hast.

Nun zu meiner Frage.

Ich habe den Ht-pitiny auf meinem Raspi2 hängen der als Ht-Proxy läuft.

Auf meinem Webserver läuft eine Instanz die die Daten aus der Datenbank 
zieht und für die Webseite aufbereitet. Hier läuft jetzt ein Bash Script 
das die Daten an den MQTT Broker sendet. Dieser soll nun durch die neue 
Version 0.3 ersetzt werden.

Kann ich auf dem Pi die alte Version belassen oder sollte ich auf dem PI 
auch auf 0.3 updaten???

Danke
Martin

[Norbert S. (junky-zs)]

Hallo Martin,

der ht_proxy hat sich gegenüber der SW-Vorgängerversion (0.2.x) nicht 
geändert. Ebenso das ht_proxy_cfg.xml Konfigurationsfile nicht. Somit 
brauchst Du diesen Anteil auf dem RPI2 nicht zu aktualisieren.

Aber alle ht_clients die RAW-Daten vom ht_proxy.server bekommen, müssen 
die neueste SW-Version 0.3 erhalten.
Es ist z.B. der HT3_Logger.py daemon durch den ht_collgate.py daemon 
ersetzt und im Konfigurationsfile: HT3_db_cfg.xml sind set-Parameter 
dazugekommen.
Daher sind auch viele der lib-Module angepasst und laufen nur noch 
korrekt in der 0.3 SW-Version.

Aber das Beste zum Schluss.
Die vorhandenen Datenbanken (aus Versionen 0.2.x) können weiter genutzt 
werden und werden auch nicht durch die neue SW-Version 0.3 gelöscht. 
Neue Daten werden an die vorhandenen angehängt.

Einzig die sqlite-Datenbank ist jetzt per default deaktiviert.
Aber diese brauchst Du ja in Zukunft eh nicht mehr da der ht_collgate.py 
daemon mit aktiviertem MQTT-Interface die Daten an den MQTT-Broker 
sendet.

Gruß Norbert

[Martin S. (matz666)]

Kurze Info.

Da ich nur einige Zeit damit verbracht habe möchte ich den anderen die 
Suche ersparen.

In der aktuellen Version auf Git ist der ht_collgate nichtausführbar.

Bitte mit chmod +x ./ht_collgate.py nachholen.

@Norbert könntest du das beheben.

Danke

[Norbert S. (junky-zs)]

Hallo Martin,

danke für die Info.
Allerdings tritt dieser Fehler bei mir nicht auf.

Habe mir mehrmals mit 'git clone' und auch mit dem Download des 
Zip-Files das ganze Projekt von github geholt und jedesmal sind die 
nötigen executable-Flags bei den Files gesetzt.
Ebenso wird mir im Browser angezeigt das es sich um ein 'Executable 
File' handelt (siehe Bild).

Daher weiss ich jetzt nicht was bei Deiner Installation anders sein soll 
als bei mir.
Du hast Dir sicher auch das ganze Projekt mit git clone .... vom 
github-server geholt oder?

Gruß Norbert

[Martin S. (matz666)]

Morgen Norbert.

Ich hab das Projekt als ZIP gezogen.

Kann es sein das es hier einen Unterschied gibt???

[Martin S. (matz666)]

Noch eine Frage.

Steig bei den MQTT Befehlen zum steuern nicht ganz durch.

Habe topic root namen auf /ht3 geändert.

Um bei Heizkreis 1 die Betriebsart zu verstellen schicke ich.

Topic: /ht3/hc1_Tniveau
Message: Tniveau,2,1,heizen

Richtig so???

[Norbert S. (junky-zs)]

Hallo Martin,

dein Topic-rootname: '/ht3' ist ungünstig bzw. falsch.
Das Slash vorne sollte weg, also 'ht3'.
Der Topic-rootname bei MQTT hat nichts mit einer root-Pfadangabe zu tun. 
Es wird in der Regel kein führendes '/' angegeben.
Aber dies ist nicht der Fehler, sondern vor dem Kommando kommt noch die 
'set'-Angabe.
Somit wäre richtig:
  Topic: set/ht3/hc1_Tdesired
  Message: 22.5,heizen
Funktion: Es wird für den Heizkreis1 das Temperaturniveau:Heizen auf 
22.5 Grad eingestellt.
Hinweis:
Die Topic-Namen für die Kommandos an die Heizung sind die gleichen wie 
die 'Empfangs-Topic Namen' haben jedoch noch das 'set/' davor.

Im Konfigurationsfile: HT3_db_cfg.xml sind die set-Befehle bei den 
Logitems eingetragen bei denen eine Kommandierung z.Zeit möglich ist.
Für hc1_Tdesired steht da z.B.:
  <set_param>Tdesired,3,1,T,heizen|sparen|frost||.....
bedeutet:
 Tdesired mit drei Parametern.
 1. Heizkreisnummer:= hier 1 <<-- Parser intern genutzt
 2. T:= gewünschter Temperaturwert <<-- 1. Befehlsparameter
 3. ein Wert aus Liste für zugehöriges Temperaturniveau 
<<--2.Befehlsparameter

Achtung: Die Werte für die Temperaturniveaus unterscheiden sich je nach 
Reglertyp: 1. Fxyz-Regler oder 2. Cxyz-Regler.
Diese Angaben sind für den Parser wichtig, für die Befehle eines 
MQTT-Client ist die Anzahl der Parameter einen Zähler weniger siehe 
Beispiel oben.

Bitte dringend dazu auch die Dokumentation lesen: §2.3.2 MQTT-Client und 
$2.2 Konfiguration und Tabellen 7 und 8.

Gruß Norbert

[Martin S. (matz666)]

Hallo Norbert.

Leider funktionieren die MQTT Befehle noch immer nicht.

Darum meine Frage. Welcher Teil wertet die Befehle aus?

Kann es sein das ich auf dem Pi die Version 0.3 aufspielen muss damit es 
funktioniert.

[Norbert S. (junky-zs)]

Hallo Martin,

wie weiter oben beschrieben ist eine Aktualisierung des PI nicht 
zwingend erforderlich wenn da NUR der ht_proxy.server läuft und dort der 
ht_pitiny-Adapter angeschlossen ist.
Dein Web-Sever ist ja wohl mit diesem RPI verbunden und hat die aktuelle 
Software erhalten, richtig?
Aktualisierung auf 0.3 ist allerdings immer die bessere Lösung.

Jetzt habe ich aber auch an Dich noch ein paar Fragen:
1. Wie hast Du erkannt das die Befehle keine Wirkung zeigen?
 (mit HT3_Analyser.py oder mosquitto??)
2. Hast Du jemals Deine Heizung mit dem Tool: ht_netclient.py gesteuert?
3. Welchen Reglertyp hast Du (Fxyz oder Cxyz)?
4. Ist der Empfang von Heizungsdaten mit MQTT-Messages erfolgreich?
5. Läuft der MQTT-Broker? (sonst auch kein Empfang/Senden).
6. Womit sendest Du die MQTT-Befehle?
7. Welche Tests hast Du durchgeführt?
Ein paar Tipps dazu:
1. Empfang:
mosquitto_sub -d -h <server-IP> -t hometop/ht/# -q 1
oder
mosquitto_sub -d -h <server-IP> -t set/hometop/ht/# -q 1

2. Senden mit :
mosquitto_pub -d -h <server-IP> -t set/hometop/ht/hc1_Tniveau -m 
"heizen"
oder
mosquitto_pub -d -h <server-IP> -t set/hometop/ht/hc1_Tdesired -m 
"22.0,heizen"

Die Dekodierung der MQTT-Befehle macht lib/mqtt_client_if.py welches vom 
ht_collgate gestartet wird.

Gruß Norbert

[Martin S. (matz666)]

Martin S. schrieb:
> Topic: /ht3/hc1_Tniveau
> Message: Tniveau,2,1,heizen

hier liegt der Fehler Norbert.

hatte in der Message zu viel drinnen. mit "heizen" "sparen" "frost" 
"auto" ist auf einmal alles ok.
Topic: /set/ht3/hc1_Tniveau
Message: sparen

Danke für deine Geduld und deine schnelle Antwort.

lg

Martin

[Andre (Gast)]

Hallo Norbert,
Hallo zusammen,

ich bin schon seit langer Zeit begeisterter Nutzer Deiner Software und 
des piTiny Adapters - bisher habe ich die Daten allerdings aus reiner 
Neugier protokolliert. Aktuell habe ich allerdings ein Problem mit 
meiner Heizung (bzw. mit dem Warmwasser), welches in den Plots auch 
wunderbar visualisiert wird (siehe Anhang). Das Problem trat vor einem 
Jahr schon einmal auf, verschwand aber von selbst nach 2 Tagen.

Mein Warmwasser an der Zapfstelle ist derzeit nur noch lauwarm. Konkret 
kann ich maximal 40° messen. Wenn ich dusche, fällt die Temperatur 
relativ schnell ab. Wenn ich mir die Plots so anschaue, entspricht das 
mehr oder weniger der Speichertemperatur, aber nicht der Ist Temperatur. 
Generell sieht der Plot aus meiner Sicht seltsam aus: T-Ist ist im Plot 
konstant bei ~70° (!) (das ist nirgends so konfiguriert), T-Soll bei 
~52° (so soll es sein). T-Speicher ist bei ~40° (das entspricht dem 
Wasser an der Zapfstelle und passt komischerweise relativ gut zur 
Vorlauftemperatur der Heizung).

Um das ganze besser zu verstehen habe ich ein paar Fragen zu den 
angegebenen Werten. Welche Temperaturen werden mit "T-Ist", "T-Speicher" 
und "T-Speicher Unten (Solar)" genau angezeigt und wo werden sie 
gemessen. Sollte T-Ist tatsächlich so irgendwo im System vorhanden sein, 
müsste ja ein Ventil / Mischer defekt sein und das Wasser nicht in den 
Kreislauf geben. Sollte die Temperatur nicht korrekt sein, würde ich auf 
einen NTC tippen.

Letztes Jahr war ein Heizungsbauer vor Ort, der wollte so auf Verdacht 
einen NTC austauschen, er war sich aber auch nicht sicher. Da nach 2 
Tagen der Selbstheilungsprozess eingesetzt hat, haben wir es damals 
gelassen. Hat einer eine Meinung dazu?

Besten Dank für Deine / eure Ideen!

Gruß
André

[Norbert S. (junky-zs)]

Hallo André,

da ich auch ein CerapurSolar-Heizgerät (CSW) habe kann ich Dir 
hoffentlich einige Fragen beantworten.

> Welche Temperaturen werden mit "T-Ist", "T-Speicher" und "T-Speicher
> Unten (Solar)" genau angezeigt ?

"T-Speicher" ist der Temperatur-Wert des WW-Pufferspeichers und wird mit 
einem WW-Telegramm gesendet.

"T-Speicher unten" (Solar) ist der Temperatur-Wert des TS2 - 
Temperatursensors am Systempufferspeicher SP400 (Details siehe Bilder).
Dieser Wert wird mit einem Solar-Telegramm gesendet.

"T-Ist" (WW) kommt vom Temperatursensor im Mischventil (MV) des CSW.
Dieses Ventil ist speziell im CSW eingebaut, andere Junkers-Heizgeräte 
haben dies meines Wissens nicht (siehe Beschreibung im Bild).
T-Ist (WW) wird mit einem WW-Telegramm gesendet und aufgezeichnet.
Allerdings wird dieser Temperaturwert des Mischventils (MV) auch in 
einem Heizgerät-Telegramm verwendet, Anzeige im Systemstatus als Wert: 
"T-3Wege Mischer".
Hinweis:
Da diese Telegramme nicht zeitgleich gesendet werden sind die 
angezeigten Werte u.U. leicht unterschiedlich (in den 
Nachkomma-Stellen), gleichen sich aber wieder an.

Wird durch das Heizgerät kein WW erzeugt, so steht das Mischventil (MV) 
und das 3-Wege Umsteuerventil (DWU) auf Stellung "Heizen".
Der Temperaturfühler im Mischventil (MV) misst also die Temperatur im 
Vorlauf in der Nähe der Heizungspumpe (HP).
Somit passt die angezeigte Temperatur von ca. 75Grad durchaus zu Deinem 
Heizungssystem (Vorlauf), da Du ja neben der Fussbodenheizung auch 
Radiatoren hast.

Die Verwendung der Mischventil-Temperatur im WW-Telegramm als "T-Ist" 
beim CSW-Heizgerät ist also denkbar ungünstig von Junkers gelöst.
Dies ist also kein Fehler in Deinem Heizungssystem und der NTC 
funktioniert ja auch.

Allerdings fällt mir in Deinem WW-Plot auf, das die Warmwasser-Erzeugung 
(hellblau) sehr häufig ausgelöst wird und das die WW-Speichertemperatur 
(hellgrün) nicht mal in die Nähe des Soll-Wertes gelangt.
Bei meiner Anlage ist dies sichtbar anders (siehe Bild). Wenn die 
WW-Speichertemperatur unterhalb des Grenzwertes fällt wird das Heizgerät 
auf Warmwasser-Erzeugung umgeschaltet und solange geheizt bis der 
Sollwert erreicht ist. Der Wert "Speichertemperatur OK" wird dann 
angezeigt wenn die Speichertemperatur nicht unter den Grenzwert absinkt.
Hinweis:
Dieser Grenzwert hängt von der ECO-Taste aktiv/inaktiv ab.

Mein Tipp um der Sache näher zu kommen:
1. HT3_Analyser starten und die Werte (Temperatur / Flags) 
kontrollieren, insbesondere für "T-3Wege Mischer (HG)", "3-Weg -> 
WW-Speicher (HG)", "Betriebsmodus (HG)", "Warmwasser-Erzeugung" und 
"Speichertemperatur OK".
2. WW Sollwert mal zum Test auf 60 Grad erhöhen. Dann muss 
"Speichertemperatur OK" auf "Nein" stehen, der "Betriebsmodus (HG)" auf 
Warmwassererzeugung umschalten und sich die WW T-Speichertemperatur 
erhöhen. Eventuell dann noch die Taste "Warmwasser-Sofort" am Regler 
drücken.
3. Kontrollieren ob Störungsmeldungen in HT3_Analyser und Regler 
vorhanden sind.
4. Alte Plots aus rrdtool-db auswerten, bei denen das System in Ordnung 
war.

Vielleicht funktioniert das Mischventil im CSW-Heizgerät nicht mehr so 
wie es soll, aber dies ist nur meine laienhafte Vermutung.

Gruß Norbert

[Marc (Gast)]

Guten Morgen,

was läuft bei mir denn falsch? Die RRDTools Grafiken werden nicht 
generiert auf Grund folgenden Fehlers:

pi@heattronic-pi:~/HT3/sw/var/log $ /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi /home/pi 1
rrdtool graph /home/pi//HT3/sw/etc/html/HT3_Heizgeraet.png --vertical-label Temperaturen (Celsius) --width 740 --right-axis-label Temperaturen (Celsius) --title Heizgerät (07:46:28 04.10. - 07:45:28 06.10.2017) --right-axis 1:0 --start 1507095988 --end 1507268728 --height 310 DEF:modusfkt=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_modus:MAX CDEF:draw2=modusfkt,45,* AREA:draw2#e9ddaf DEF:Brennerleistung=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_leistung:MAX AREA:Brennerleistung#cccccc:Brennerleistung (%) VDEF:Brennerleistung_last=Brennerleistung,LAST COMMENT:                       last\: GPRINT:Brennerleistung_last:%2.lf\l DEF:TSoll=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_vorlauf_soll:MAX LINE1:TSoll#ff0000:T-Soll (Regelung) VDEF:TSoll_last=TSoll,LAST COMMENT:                         last\: GPRINT:TSoll_last:%2.lf\l DEF:TIst=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_vorlauf_ist:MAX LINE1:TIst#0000ff:T-Ist  (Vorlauf) VDEF:TIst_last=TIst,LAST COMMENT:                          last\: GPRINT:TIst_last:%2.1lf\l DEF:TRueck=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_ruecklauf:MAX LINE1:TRueck#00ff00:Rücklauf VDEF:TRueck_last=TRueck,LAST COMMENT:                                  last\: GPRINT:TRueck_last:%2.1lf\l DEF:zirkula_pumpe=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_zirkula_pumpe:MAX CDEF:draw12=zirkula_pumpe,10,* AREA:draw12#d45500:Zirkulations-Pumpe\l DEF:Heizungspumpenleistung=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_spare_1:MAX LINE1:Heizungspumpenleistung#008d00:Heizungspumpenleistung (%) VDEF:HP_Leistung_last=Heizungspumpenleistung,LAST COMMENT:                last\: GPRINT:HP_Leistung_last:%2.lf\l DEF:Aussentemperatur=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_aussen:MAX LINE2:Aussentemperatur#000055:Aussentemperatur min\: VDEF:Aussentemperatur_min=Aussentemperatur,MINIMUM GPRINT:Aussentemperatur_min:%3.1lf VDEF:Aussentemperatur_max=Aussentemperatur,MAXIMUM COMMENT:max\: GPRINT:Aussentemperatur_max:%3.1lf VDEF:Aussentemperatur_last=Aussentemperatur,LAST COMMENT:   last\: GPRINT:Aussentemperatur_last:%3.1lf\l DEF:BZeitg=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:C_betrieb_gesamt:LAST VDEF:BZeitg_average=BZeitg,LAST GPRINT:BZeitg_average:  Betriebszeit gesamt \: %6.1lf Stunden\l DEF:brennereinheiz=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:C_brenner_heizung:LAST VDEF:brennereinheiz_last=brennereinheiz,LAST GPRINT:brennereinheiz_last:  Brenner ein         \: %6.lf Zähler COMMENT: \s COMMENT: \s --color CANVAS#fff6d5 --color BACK#ffdd55 failed: invalid format string '%2.lf\l' (should match '^(?:[^%]+|%%)*%[-+ 0#]?[0-9]*(?:[.][0-9]+)?l[eEfFgG](?:[^%]+|%%)*(?:%s)?(?:[^%]+|%%)*$') at /usr/share/perl5/RRDTool/OO.pm line 444

Dieser Fehler kommt:
 failed: invalid format string '%2.lf\l' (should match 
'^(?:[^%]+|%%)*%[-+ 
0#]?[0-9]*(?:[.][0-9]+)?l[eEfFgG](?:[^%]+|%%)*(?:%s)?(?:[^%]+|%%)*$') at 
/usr/share/perl5/RRDTool/OO.pm line 444

Danke schon mal...

[Marc (Gast)]

Hallo,

ich habe noch eine Frage. Ich besitze eine CSW 14/75-3 A mit 3 Solar 
Kollektoren, dem 415 Liter Pufferspeicher mit Fußbodenheizung.

Müsste bei mir nicht auch der T-3Wege Mischer im Heizgerät-Telegramm 
auftauchen? Ich finde aber in der SQLite DB keinen Eintrag dazu.

Grüße
Marc

[Norbert S. (junky-zs)]

Hallo Marc,

der Anzeige-Wert: "T-3Wege Mischer" steht als logitem-name: "T_mischer" 
in den Datenbanken.
Die Datenbank-Spalten werden nur mit den logitem-Namen generiert.
Den Zusammenhang zu den Anzeigenamen sieht man im Konfigurationsfile:
 ...
        <logitem name="T_mischer">
            <datatype>REAL</datatype>
            <datause>GAUGE</datause>
            <maxvalue>100.0</maxvalue>
            <default>0.0</default>
            <unit>Grad</unit>
            <displayname>T-3Wege Mischer</displayname>
            <accessname>ch_T3waymixer</accessname>
        </logitem>

Der Wert für T_mischer wird mit Msg_ID:24 gesendet.
sqlite-Einträge siehe Bilder.

> failed: invalid format string '%2.lf\l' (should match...
Die Fehlermeldung muss ich noch auswerten. Dir hilft es ja nicht wenn 
ich sage das der bei mir nicht auftritt.
Allerdings hatte ich vor kurzem einen vergleichbaren Fehler auch schon 
von einem anderen Forumsteilnehmer erhalten.
Letztendlich hat er dann das Raspbian Linux installiert und der Fehler 
war weg. Bis dato hatte ich angenommen das dies ein Einzelfall sei.

Tritt dieser Fehler sporadisch auf oder ständig?

Gruß Norbert

[Marc (Gast)]

Hallo Norbert,

danke für deine Antworten.

Bzgl. des Fehlers, ja der tritt immer auf, also immer dann, wenn neue 
Grafiken generiert werden sollen. Ich habe erstmal den Heizgeräte Part 
auskommentiert um die restlichen Grafiken zu sehen (die funktionieren 
einwandfrei). Aber sobald ich die rrdtool_draw.pl durch die original 
Version wieder ersetze, rasselt das Script sofort in den Fehler.

Mein Raspbian läuft mit:
Linux ht-pi 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l 
GNU/Linux

rrdtool in der Version:
1.6.0-1+b1

librrdtool-oo-perl:
0.36-1

---

Mir ist noch eine kuriose Sache in der DB aufgefallen. Mein T-Soll Wert 
beim WW rutscht manchmal auf 0 für einige Telegramme um anschließend 
wieder auf den normalen Wert von 60 zu kommen. Ich habe die Grafik mal 
angehängt. Nicht wundern, die Zeitspanne habe ich auf 6 Stunden 
reduziert. Deutlich zu sehen sind die Ausbrecher gen 0. Da dieser 0 Wert 
nur für ein paar Sekunden (maximal 10-15) in den DBs existiert, erreicht 
die T-Soll Linie nicht 0.

Ich habe mal die SQLite DB für mit der WW Tabelle angehängt.

[Norbert S. (junky-zs)]

Hallo Marc,

> failed: invalid format string '%2.lf\l' (should match...
Folgendes habe ich dazu gefunden:
Das Problem ist rrdtool versionsabhängig.
rrdtool-
version script-run linux-release
1.4.7___OK_______wheezy
1.4.8___OK_______jessie
1.6.x___Fehler___stretch, buster, sid
Was genau die Ursache ist kann ich nicht sagen, da ich nur wheezy und 
jessie einsetze.
Wahrscheinlich ist im rrdtool die Integer/Float-Typprüfung 
verändert/verbessert worden.
Vorschlag:
Deaktiviere zum Test die Zeilen/Blocks im rrdtool_draw.pl script in 
denen '%2.lf\l' vorkommt. Nur im Heizgeräte-draw werden an den Stellen 
Integer-Werte eingetragen.

> Mein T-Soll Wert beim WW rutscht manchmal auf 0
Werde Deine sqlite-db noch auswerten.

Welchen Adapter setzt Du ein? Ich nehme mal an einen HT3_Mini- oder 
HT3_Micro-Adapter?

Gruß Norbert

[Marc (Gast)]

Hallo Norbert,

>> failed: invalid format string '%2.lf\l' (should match...
> Folgendes habe ich dazu gefunden:
> Das Problem ist rrdtool versionsabhängig.
> rrdtool-
> version script-run linux-release
> 1.4.7___OK_______wheezy
> 1.4.8___OK_______jessie
> 1.6.x___Fehler___stretch, buster, sid
> Was genau die Ursache ist kann ich nicht sagen, da ich nur wheezy und
> jessie einsetze.
> Wahrscheinlich ist im rrdtool die Integer/Float-Typprüfung
> verändert/verbessert worden.
> Vorschlag:
> Deaktiviere zum Test die Zeilen/Blocks im rrdtool_draw.pl script in
> denen '%2.lf\l' vorkommt. Nur im Heizgeräte-draw werden an den Stellen
> Integer-Werte eingetragen.

Alles klar, das versuche ich mal. Möglich das der Versionssprung die 
Ursache ist.

>> Mein T-Soll Wert beim WW rutscht manchmal auf 0
> Werde Deine sqlite-db noch auswerten.

Danke.

> Welchen Adapter setzt Du ein? Ich nehme mal an einen HT3_Mini- oder
> HT3_Micro-Adapter?

Ich habe den HT3 Mini zusammengelötet.

Gruß
Marc

[Constanze H. (warteschleife)]

Hi Norbert,
leider gibt es nach 2 Tagen Betrieb Probleme mit ht_tiny Adapter.
Auf dem Adapter flackern zwar beide LEDs wie sie sollen,
aber es scheint keine Kommunikation mit dem PI mehr zu geben.
Ich habe das System gerade komplett neu auf einem PI-3 mit Debian Jessie
aufgesetzt, leider ohne Erfolg.
Irgendeine Idee, wie ich weiter testen kann?

Update:
wenn ich ht_collgate und ht_proxy stoppe, blinkt nur noch
die grüne LED. D.h. kein Bussignal vorhanden.
Der CW100 läuft allerdings normal.

Danke und Gruß
Michael

[Norbert S. (junky-zs)]

Hallo Michael,

> wenn ich ht_collgate und ht_proxy stoppe, blinkt nur noch
> die grüne LED. D.h. kein Bussignal vorhanden.

Dies ist 'normal' und kein Fehler. Im start-script wird bei Eingabe von 
'stop' der spi-Port wieder aktiviert und der spi-Treiber meint: 'Jetzt 
bin ich Herr im Haus und blockiert das HTBus-Empfangssignal :-(.
Beim Start des collgate-daemon wird dieser SPI-Port deaktiviert und für 
den HT-Bus genutzt :-)

Du kannst also zum Test einmal folgendes als user 'pi' eingeben:
 sudo ~/HT3/sw/etc/sysconfig/spi_clk_off.py
Die grüne und rote LED müssen dann wieder wie gewohnt blinken wenn der 
HT-Bus angeschlossen ist.

Du hast einen PI3 und der hat netterweise ein Bluetooth an Board. Leider 
wird der serielle Port dafür verballert den wir aber nutzen wollen.

Deshalb meine Frage ob Du die nötige Deaktivierung dieser Schnittstelle 
durchgeführt hast? Siehe auch Doku Seite 51ff oder unter
URL:
  https://forum.fhem.de/index.php/topic,50340.0.html
Gruß Norbert

[Marc (Gast)]

Hallo Norbert,

die Heizgeräte Grafik funktioniert nun.
Ich habe %2.lf\l durch %2.0lf\l ersetzt, bzw. %6.lf durch %6.0lf. 
Vielleicht erwartet die neue Version da genauere Angaben zu den 
Nachkommastellen.

In der Heizgeräte Grafik habe ich das gleiche Phänomen wie bei dem 
T-Soll Wert. Ich werde das Kabel von dem HT-Mini Adapter zum Bus mal 
etwas kürzen. Aktuell ist dies, weil ich es erstmal nur testen wollte ob 
es überhaupt geht, ein altes Lautsprecherkabel welches 2 Meter oder so 
lang ist.

Ein bisschen wundere ich mich allerdings über die Zirkulationspumpe. Ist 
eine solche Pumpe nicht normalerweise dafür da um an den 
Warmwassserzapfstellen das warme Wasser zirkulieren zu lassen? Also 
damit man immer flott warmes Wasser zur Verfügung hat? Einen solchen 
Kreislauf bzw. eine solche Pumpe besitze ich nicht. Oder wird der Wert 
von einer anderen Pumpe genommen?

Gibt es vielleicht irgendwo eine Grafik in der eingezeichnet ist, 
welcher Wert wo abgegriffen wird? Das wäre für einen Noob wie mich sehr 
hilfreich ;)

Grüße
Marc

[Norbert S. (junky-zs)]

Hallo Marc,

prima das das Script rrdtool_draw.pl jetzt geht und die Ursache 
eingegrenzt ist!

> Mein T-Soll Wert beim WW rutscht manchmal auf 0 ...
Ursache ist eine Fehldetektion des Telegramms: MsgID 51_0.
In Deinem sqlite-Datenbank-File ist dies z.B. beim Eintrag#: 4808 zu 
sehen (siehe Bild).
Dort startet das Telegramm mit a0 00 33 00 30 00 b0 00 ...
Der Wert 'b0' wird der Soll-Temperatur zugeordnet (ist richtig) jedoch 
der Wert an sich ist als Temperatur zu hoch (176 Grad). Deshalb wird in 
die Datenbank der default-Wert -> 0 eingetragen.
Eine Fehldetektion kann immer mal bei den Adaptertypen HT3_Mini- und 
HT3-Micro vorkommen, weil die Break-Erkennung als Telegramm-Endekennung 
damit nicht möglich ist.

In Deinem System hast Du mindestens einen gemischten Heizkreis mit dem 
Modul IPM(x). Deshalb kann diese Sequenz: a0 00 33 00 ... durchaus 
vorkommen wenn dieses IPM-Modul auch die Warmwasser-Regelung (Heizgeräte 
externe Warmwassererzeugung) macht.
Ich nehme mal an das dies bei Dir nicht der Fall ist.
Deshalb trage den Wert '51' in das python-Modul: lib/ht_discode.py für 
Geräteadr (20)hex bis (23)hex ein:
Zeilen: 2607 ff
    # device-adr mapped with not valid message-IDs for detailed message 
- searching
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 46, 47, 64, 100, 106],
        0x1b: [17, 56, 74, 89],
        0x20: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
        0x21: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
        0x22: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
        0x23: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92, 
95, 97, 101, 104, 107],
    }
Damit wird Telegramm MsgID_51 für Module (20...23)hex unterdrückt.

Bitte erzeuge noch ein binäres Logfile von Deiner Anlage und lass es 
mir zukommen. Dann kann ich mir dies noch zusätzlich ansehen und 
auswerten.

Der Regler aktiviert die Zirkulationspumpe und teilt dies in einem 
Telegramm mit. Dem Regler ist es egal ob wirklich eine Pumpe da 
vorhanden ist oder nicht. Er hat jedenfalls das Relay dafür angesteuert 
und seine Pflicht getan. Dies kann man wohl auch ruhigstellen, must mal 
im Handbuch des Reglers nachlesen.

Die Telegramme sind dokumentiert unter:
 ~/HT3/sw/etc/html/HT3-Bus_Telegramme.html

Gruß Norbert

[Constanze H. (warteschleife)]

Hi Norbert,
viele Dank, das scheint zu funktionieren.
Allerdings erst, nachdem das Teil 2 Tage lang
ausgeschaltet in der Ecke lag.
Nach erneutem Start bekomme ich jetzt wieder Daten.

Viele Grüße
Michael

[Marc S. (mrmiller)]

Hallo Norbert,

ich habe das BINLOG-File mal hier hochgeladen.

Ich suche in den DB Werten noch den Wert der geforderten 
Vorlauftemperatur. In dem FW120 Bedienterminal unter Info -> Heizkreis 
steht etwas von 25,7 Grad. Dieser müsste auch in der Binlog Datei unter 
den neusten Werten zu finden sein (falls vorhanden). Den Wert T_soll_HK 
von 21.0 Grad in Heizkreis Tabelle kann ich nicht ganz nachvollziehen.

Gruß
Marc

[Marc S. (mrmiller)]

Moin,

Marc S. schrieb:
> Den Wert T_soll_HK
> von 21.0 Grad in Heizkreis Tabelle kann ich nicht ganz nachvollziehen.

Ich habe den Wert mitlerweile gefunden. Man setzt diesen ja als Wert für 
den jeweiligen Modus (in meinem Fall bei Heizen) ein.

Jetzt interessiert es mich aber doch ob ich solche Werte wie: Geforderte 
Vorlauftemperatur (beim HK) oder so sehen kann.

Oder sind Werte wie: Maximale Vorlauf- bzw. Warmwassertemperatur auch in 
irgendwelchen Telegrammen logbar?

Grüße
Marc

[Norbert S. (junky-zs)]

Hallo Marc,

>Jetzt interessiert es mich aber doch ob ich solche Werte wie: Geforderte
>Vorlauftemperatur (beim HK) oder so sehen kann.
Du kannst den HT3_Analyser.py dazu verwenden. Die Bilder zeigen die WW 
-Telegramme so wie diese in Deinem bin-Logfile enthalten sind.
Bei Deinem System ist ein gemischter Heizkreis mit dem Modul IPM1 
vorhanden.
Diese Telegramme beginnen mit: a0...
Die Telegramme mit: 90...sind vom Regler Fxyz.

Im Analyser werden die MessageID's für den jeweiligen Systempart in 
Kurzform erklärt.

Details sind dokumentiert unter:
 ~/HT3/sw/etc/html/HT3-Bus_Telegramme.html

Die empfohlene Änderung in 'deviceadr_2msgid_blacklist' (siehe oben) 
habe ich testet und die funktioniert auch.
Deshalb kannst Du diese Änderung ohne weiteres übernehmen. Die 
Fehldetektionen der WW-Solltemperatur werden damit dann unterdrückt.

Gruß Norbert

[adam (Gast)]

Hallo Norbert,
manchmal kommen kurzfristig falsche Werte. Schau bitte Zeile 305 - das 
macht Message:
  25_0 :HG :90 00 19 00 10 00 90 00 21 00 29 00 10 00 90 88 16 00 02 af 
00 88 10 16 00 ff 43 9d 00 90 00 31 00 39 00 10 00

Wie kann ich die Message unterdrücken?
FW120, nur Heizkörper.

Danke und grüße

[Norbert S. (junky-zs)]

Hallo adam,

>Wie kann ich die Message unterdrücken?

Trage den Wert '25' (dezimal) in das python-Modul: lib/ht_discode.py für
Geräteadr (10)hex ein:
Zeilen: 2607 ff
    # device-adr mapped with not valid message-IDs for detailed message
- searching
    deviceadr_2msgid_blacklist = {
        0x10: [11, 12, 24, 25, 46, 47, 64, 100, 106],
        0x1b: [17, 56, 74, 89],
        0x20: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
        0x21: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
        0x22: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
        0x23: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
    }
Damit wird dann das Telegramm 90 00 19... (hex) unterdrückt.
Der ht_collgate - daemon muss natürlich nach dieser Änderung neu 
gestartet werden.

Gruß Norbert

[adam (Gast)]

Hallo Norbert,

danke, geholfen.

Gruß Adam

[Andre G (Gast)]

Guten abend zusammen,
habe nun einige Zeit diesen Thread und auch noch einen anderen zum Thema 
Junkers und HT3-Bus gelesen.
Selbst bin ich sehr am Projekt interessiert (vorab danke für diese tolle 
Arbeit!). Allerdings habe ich einige Unklarheiten bzw. Unsicherheiten:

1. Ich besitze eine Junkers Cerasmart Heizung mit TA211E und DT-2. Wenn 
ich das richtig lese, wird das HT3-protokoll unterstützt (in den 
anleitungen liest man zwar immer von Heatronic, aber nie von HT3 - gibt 
es hier möglicherweise noch Unterschiede?). Aber habe ich das auch 
richtig verstanden? Kann ich die hier vorgestellte Lösung einsetzen?

2. Linux und Python ist für mich ok, aber löten... das ist immer etwas 
haarig bei mir. Würde mir jemand einen Adapter gegen einen 
entsprechenden Obulus bauen? Das Modul soll dann an meinem rasppi zero w 
arbeiten.

3. Gelesen habe ich, dass das Modul verpolungssicher gebaut ist - d.h. 
also, wenn ich die korrekten Anschlüsse verwende, kann ich nicht 
wirklich was kaputt machen?

4. Ich würde auch gerne die Heizung darüber steuern können. Im Vorfeld 
hatte ich als  Idee, den Außenfühler "abzugreifen". Den Wert kann ich 
dann weiterreichen, oder aber bei Bedarf beeinflussen. Lässt sich diese 
Idee realisieren? Idealerweise mit Funktion bei Ausfall des 
Zwischenmoduls (kann z.b. rpi besimmte gpios im ausgeschalteten zustand 
durchschleifen?)... Ein hohes Ziel, dessen bin ich mir bewusst...


gruß in die Runde und angenehme Resttage vor der Weihnachtszeit!

[Norbert S. (junky-zs)]

Hallo Andre G,

> Ich besitze eine Junkers Cerasmart Heizung mit TA211E und DT-2...
Deine Heizung und der Regler hat wohl keinen Heatronic -Bus. Dies 
entnehme ich den Unterlagen von Junkers für Deine Heizung.

Junkers hat eine Kompatibilitätsliste auf der Web-Seite und auch dort 
ist die 'Cerasmart' Heizung nicht enthalten.
URL mit PDF-File:
https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/waermepumpen_neu_/kompatibilitaetslisten/home_und_multi_home__kompatible_junkers_geraete.pdf

HT3 steht als Abkürzung für: Heatronic in Version 3.
Es gibt da noch Heatronic 4i und für die neuen Heizsysteme mit den 
Cxyz-Reglern und den EMS2 - Bus.
Es muss also ein Bus vorhanden sein, der zumindest Heatronic 3 
entspricht. Heatronic2 geht da also auch nicht.
Die hier vorgestellte Datenerfassung mit den zugehörigen Adaptern 
funktioniert also für alle Heatronic3, Heatronic4i und EMS2-Bussysteme.
Dies sind wohl alle Systeme ab Baujahr 2008.

Leider entspricht Deine Heizung und der zugehörige Regler nicht dem 
Profil.
Zumindest die Junkers-Unterlagen zu Deiner Heizung machen mir da keine 
Hoffnung.

Gruß Norbert

[Andre G. (andre_g929)]

Vielen Dank für dine Mühe.
Interessanterweise spricht zumindest die Anleitung der Steuerung der 
Anlage (TA211e) von Heatronic:
http://www.manderfeld.de/downloads/ta_211e.pdf
die Version des HT-Protokolls ist natürlich nicht angegeben.

Ich glaube, ich schraube das Teil mal auf uznd schaue nach. Denn wenn 
ich das richtig sehe, dann müsste das Modul bei 2-adriger Anbindung auf 
HT3 hinweisen, bei analoger Anbindung wäre es 3-adrig angebunden...

Hab ich denn eine Chance, über Messungen an den Polen herauszufinden, ob 
meine Heizung schon HT3 "spricht"?

gruß und danke schonmal.
andre

[Nils R. (augur)]

Hi,

gibt es eigentlich eine Möglichkeit die Betriebsart "Auto" zu erkennen 
als aktuellen Status eines Heizkreises? Ich würde gerne für die 
Integration in eine Haussteuerung den "Wunschstatus" mit dem echten 
abgleichen und diesen dann versuchen zu setzen. Jedoch gibt es die 
Betriebsart Auto ja nicht in der Statusausgabe.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,
>gibt es eigentlich eine Möglichkeit die Betriebsart "Auto" zu erkennen?
Ja, z.B. mit dem HT3_Analyser und HT3_Systemstatus wird dieser Wert als 
'Betriebsstatus' angezeigt (siehe Bild).
In den zugehörigen Telegrammen wird dieser Wert gesetzt (siehe Bild für 
Fxyz-Regler).

>Ich würde gerne für die Integration in eine Haussteuerung den "Wunschstatus" mit
>dem echten abgleichen und diesen dann versuchen zu setzen.
Ja, dies geht z.B. mit dem Tool:'~/HT3/sw/ht_netclient.py'.
Der Aufruf: ./ht_netclient.py -h zeigt Dir welche Parameter nötig sind.

Der Aufruf: ./ht_netclient.py -b heizen bringt die Heizung in den 
'Manuellen'-Mode.
Der Aufruf: ./ht_netclient.py -b auto bringt die Heizung wieder in den 
'Auto'-Mode.

Du solltest dafür die aktuelle Software Rel. 0.3 verwenden.

Gruß Norbert

@Moderator
Im Bearbeitungsmode lassen sich Bilder (z.B. doppelte) nicht mehr 
löschen.
Sicher lässt sich dies noch verbessern :-)

[Nils R. (augur)]

Hi Norbert,

danke für die Beschreibung. Die Umschaltung habe ich schon am Laufen nur 
aufgrund der Anbindung des PI mit Wlan manchmal das Problem, dass die 
Verbindung nicht klappt.

Daher würde ich gerne den gewünschten Modus mit dem aktuellen in der 
Heizung vergleichen. Derzeit lese ich die aktuellen Parameter aus der 
SQLite DB aus, aber dort konnte ich den Status für "Auto" nicht finden. 
Es wird nur der aktuelle Status in meiner eingesetzten Version 
gespeichert (wenn ich den nicht übersehen habe). Kannst du mir sagen, 
wie ich den Status inkl. "Auto" auslesen kann?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,
der Wert für den Betriebstatus (u.A. 'Auto') steht in der sqlite-DB 
unter 'V_operation_status'.
'Auto' hat für den Fxyz-Regler den Wert: 2.
Diese Namen sind im Konfigurations-File als 'logitem name' festgelegt 
und die Datenbanken werden mit diesem Namen erzeugt.
Der Zusammenhang zum angezeigten GUI-Namen ergibt sich ja aus dem 
logitem.
Somit kannst Du auch andere Daten zuordnen.
Auszug aus dem Konfig-File:
        <logitem name="V_operation_status">
            <datatype>INT</datatype>
            <datause>GAUGE</datause>
            <maxvalue>10</maxvalue>
            <default>0</default>
            <unit></unit>
            <displayname>Betriebsstatus</displayname>
            <accessname>hc1_operationstatus</accessname>
        </logitem>

Bei der Abfrage des Betriebsstatus nach einer Änderung musst Du Dir Zeit 
lassen, weil leider das zugehörige Telegramm nicht sofort nach einer 
Änderung sondern schlimmstenfalls nach 1 Minute gesendet wird.

Gruß Norbert

[Chris (Gast)]

Norbert S. schrieb:
> Junkers hat eine Kompatibilitätsliste auf der Web-Seite und auch dort
> ist die 'Cerasmart' Heizung nicht enthalten.
> URL mit PDF-File:
> 
https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/waermepumpen_neu_/kompatibilitaetslisten/home_und_multi_home__kompatible_junkers_geraete.pdf

Der Link läuft leider ins Leere. Kann jemand die Datei zur Verfügung 
stellen? Ich wüsste gerne, ob meine Heizung unterstützt wird.

[Nils R. (augur)]

Norbert S. schrieb:
> der Wert für den Betriebstatus (u.A. 'Auto') steht in der sqlite-DB
> unter 'V_operation_status'.
> 'Auto' hat für den Fxyz-Regler den Wert: 2.

Aha, das hab ich wohl übersehen. Eigentlich gebe ich mir alle Spalten 
der Datenbank als Webservice aus, um diese in eine Oberfläche 
einzulesen. Bin derzeit immer vom Betriebsart ausgegangen, dass es dort 
drinnen stehen muss. Danke dafür, das probiere ich aus.

Viele Grüße,
Nils

[Markus (Gast)]

Hallo Zusammen,

ist etwas OffTopic, zur Analyse habe ich aber HT3 eingesetzt :-)

Die Heizungspumpe UPM 15-70 die in der Heizung verbaut ist bleibt 
unregelmäßig stehen. Meistens direkt nach der Warmwasserladung.
Danach geht die Heizung auf über 100 Grad, da die Wärme nicht 
abtransportiert wird. Nach dem Abkühlen geht es wieder auf 100 Grad, 
usw.

Ausschalten und neu Einschalten der ganzen Heizung hat die Pumpe dann 
für Tage/Wochen wieder zum Leben erweckt.

Beim letzten Ausfall habe ich die Spannung an der Pumpe gemessen. 
Spannung war da. Stecker im Betrieb bei der Pumpe abgezogen und neu 
aufgesteckt. Pumpe läuft wieder an.

Der Heizungsmonteur hatte noch die Idee die Steuerung an der Pumpe 
abzuziehen. Damit läuft die Pumpe auf 100%, hat aber weiterhin die 
sporadischen Ausfälle.

Ich gehe momentan davon aus, das die Pumpe eine Blockierung feststellt, 
obwohl da keine ist. Wer hat eine bessere Idee?

1. kann ich mit dem ht_netclient.py auch einen Reset durchführen? 
Eventuell kurz in den frost-Modus gehen?

Die Pumpe gibt den aktuellen Betriebszustand an die Heizung zurück. 
http://net.grundfos.com/Appl/WebCAPS/Grundfosliterature-4927111.pdf 
(seite 10.) Kann man das irgendwo abfragen? Oder muss ich da mit einer 
eigenen Schaltung dran? Im Display der Buderus sehe ich keine 
Fehlermeldung.


Grüße

[Hans (Gast)]

Hallo zusammen,

ich habe ein Problem mit meiner HT3-Datenerfassung. In unregelmäßigen 
Abständen (gefühlsmäßig nach einem viertel Jahr) friert die 
Datenerfassung einfach ein. Es werden keine aktuellen Daten mehr 
angezeigt. Im Browser werden zwar noch die Diagramme geöffnet, leider 
ohne Historie und aktuellen Daten (siehe Anhang). Das Datum steht dann 
auch in der Vergangenheit. Per SSH kann ich noch auf den Pi zugreifen 
und einen Reboot durchführen. Aber leider funktioniert die 
Datenerfassung danach auch nicht. Bisher habe ich dann schon zwei Mal 
den Pi komplett neu aufgesetzt. Das ist auf Dauer ein klein wenig 
nervig. Habe nur ich das oben geschilderte Problem? Wie kann ich die 
HT3-Erfassung wieder zum Leben erwecken?
Wie sichert bzw. Werte Ihr die Daten auf dem PI aus  ?

Wünsche Allen frohe Ostern

Hans

[Klaus (Gast)]

@Hans

Ich habe von Anfang an ein ähnliches Problem. Nach einer gewissen 
Laufzeit von ein paar Monaten bekommt die Aufzeichnung immer mehr 
Lücken.
Ich muss dann immer die sqlite DB wegkopieren bzw. löschen.
Nach einem Neustart wird die DB wieder leer angelegt und es läuft wieder 
ein paar Monate.
Ob es sich um denselben Effekt handelt kann ich dir leider nicht sagen. 
Müssten eigentlich alle haben dieses Problem. Oder es liegt an einer 
bestimmten Version. Vielleicht meldet sich ja der Norbert noch.

Klaus

[Hans (Gast)]

Hi Klaus,

Dankeschön für die Info. Werde ich am Wochenende mal ausprobieren.

Viele Grüße

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

bin mir nicht sicher ob Du die sqlite-DB aktiviert hast (per default ist 
diese aus). Falls ja dann würde ich wie von Klaus beschrieben die 
sqlite-DB neu aufsetzen (erzeugen).
Ich gehe auch davon aus, das Du das letztgültige Software-Releae: 0.3 
installiert hast.

Nach längerer Zeit kann die DB doch recht gross werden und der Pi hat 
damit dann mächtig zu tun.
Wenn die sqlite-DB aktiviert wurde so werden Daten älter als 30 Tage 
normalerweise aus der DB gelöscht, Eintrag:
 (<autoerase_olddata>30</autoerase_olddata>)
im Konfigurationsfile.

Ich vermute jedoch das Du die sqlite-DB nicht aktiv hast.
Wenn dem so ist liegt wohl noch ein anderes Problem vor.

Bitte kontolliere im Fehlerfall mal das /tmp Verzeichnis. Wenn dort sehr 
viele perl-scripte (*.pl) liegen bleiben so werden die Daten nicht in 
die rrdtool-db eingetragen.
Diesen Fall hatte ich schon mal, der aber nach einem reboot des PI 
wieder behoben war.
Eine Neuinstallation war nicht nötig gewesen.

Beachte bitte auch das nach einem reboot die Datenerfassung erst neu 
aufgesetzt wird und erst nach ca. 5 -10 Minuten wieder Daten in den 
Anzeigen zu sehen sind.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Markus (Gast),

> kann ich mit dem ht_netclient.py auch einen Reset durchführen?
> Eventuell kurz in den frost-Modus gehen?
Einen Reset kann man nur auf den ht_pitiny-Adapter ausführen jedoch 
nicht auf die Heizung und deren Module.

> Die Pumpe gibt den aktuellen Betriebszustand an die Heizung zurück.
> Kann man das irgendwo abfragen?
In den 'normalen' Betriebstelegrammen habe ich dafür noch keinen 
Platzhalter gefunden.

> Im Display der Buderus sehe ich keine Fehlermeldung.
Wenn der Fehler weg ist findet man diesen in der Historie. Je nach 
Regler wird dieser Wert abgespeichert und sichtbar (in der 
Fachman-Ebene).

Es sollte ein Fehler angezeigt werden wenn die Steuerung der Pumpe 
abgezogen ist. Zumindest gibt es dafür einen Fehlertext.
Dies wird je nach Heizgerät in der Heizungssteuerung gemacht. Falls also 
doch kein Fehler zu finden ist erkennt die Heizung auch das Blockieren 
der Pumpe nicht.

Wie in Deinem Bild zu sehen hast Du ja schon mehrfach die Rotor 
Abdeck-Schraube gelöst.
Ist im Fehlerfall der Pumpen-Rotor leicht zu drehen oder sitzt der 
mechanisch fest?
Hat der Heizungsfachmann auch schon mal das 3-Wege Umschaltventil 
kontrolliert?
(Dies sollte allerdings funktionieren, sonst hättest Du schon lange 
kalte Füsse oder kaltes Wasser erhalten :-)

Wenn alle Stricke reissen so würde ich die Pumpe ersetzen. Diese ist 
billiger als ein neuer Wärmetauscher.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

zum Thema: Blockieren von Heizungspumpen nach längerer Stillstand-Zeit 
noch ein Hinweis:
Es ist sinnvoll das Heizgerät im Sommer nicht auszuschalten, da viele 
der Junkers-Heizgeräte einen Blockierschutz in der Steuerung haben.
Diese sorgt dafür das die Pumpen und das 3-Wege Ventil ab und zu 
betrieben werden und sich dann nicht festsetzen.

Gruß Norbert

[Nils R. (augur)]

Moin,

ich hab mal mein Raspi aktualisiert und das Problem, dass ich mit 
ht_netclient nicht mehr auf den Bus schreiben kann. Ich erhalte die 
Meldung csocketsendThread();Error on socket.send

Das Aufzeichnen von Werten klappt einwandfrei. Ich habe auch alles als 
Modem konfiguriert, anbei ein Screenshot eines neuen Logs. Hab keine 
Idee mehr woran es liegen könnte.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> Ich erhalte die Meldung csocketsendThread();Error on socket.send
Diese Meldung ist vom 'ht_proxy.server'. Der Grund der Meldung ist aber 
daraus nicht ersichtlich.
Da sich die Software des 'ht_proxy.servers' seit ca. 3 Jahren nicht 
geändert hat muss ein Zusammenhang mit den anderen 'Aktualisierungen' da 
sein.

Welche Aktualisierungen hast Du durchgeführt (neues OS, Raspi etc.)?

Gruß Norbert

[Nils R. (augur)]

Hi Norbert,

ich hatte noch eine uralte Version der Software (frühe Version mit 
Proxy) am laufen auf einem Wheezy. Am Jahresanfang hab alles mal 
aktualisiert und die Konfiguration neu gemacht und dann liegen gelassen, 
weil ich noch die DB auf einen USB Stick ziehen wollte.

Seitdem bekomme ich das Schreiben auf den Bus nicht mehr hin. Die 
Hardware ist aber gleich geblieben. Dachte eigentlich es liegt an der 
Konfiguration, aber ich denke die müsste stimmen.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

>ich hatte noch eine uralte Version der Software.
>Am Jahresanfang hab alles mal aktualisiert und ...

Dann hast Du wahrscheinlich jetzt folgende Software im Einsatz ?:
OS: 'Stretch'
HT3: Rev.: 0.3 von github

In diesem letztgültigen Release hat sich zwar der 'ht_proxy.server' 
nicht geändert aber viele andere Module in der Library sind angepasst 
worden.

Einige ältere SW-Module sind entfallen. Dazu bitte auf github das readme 
und die Projekt-Doku lesen. Dort sind die Änderungen beschrieben.
URL: https://github.com/norberts1/hometop_HT3

Gruß Norbert

[Peter (Gast)]

Hallo!
Ich habe würde meine Junkerstherme gerne mit Openhab verbinden. Hat 
jemand vielleicht schon das ganze in Openhab inplementiert? Musste dazu 
ein Modul programmiert werden?

LG Peter

[Juri K. (iuser)]

Hallo Peter,

ja, ich habe es gemacht - das geht ganz normal über die MQTT Anbindung.

Hier sind ein Paar Beispiele:

Number ht3_ch_Treturn        "T. Ist (Rücklauf) [%.1f°C]"      <dryer> 
(Junkers)        { mqtt="<[broker:hometop/ht/ch_Treturn:state:default]"}
Number ht3_ch_Tflow_measured    "T. Ist (Vorlauf) [%.1f°C]" 
<dryer>  (Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_Tflow_measured:state:default]"}
Number ht3_ch_Tflow_desired      "T. Soll (Regelung). [%.1f°C]" 
<dryer>  (Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_Tflow_desired:state:default]"}
Number ht3_ch_Toutside        "T. Aussen [%.1f°C]"          <dryer> 
(Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_Toutside:state:default]"}
Number ht3_ch_T3waymixer      "T. 3Wege Mischer [%.1f°C]"        <dryer> 
(Junkers,PersistHT3)  { 
mqtt="<[broker:hometop/ht/ch_T3waymixer:state:default]"}

Gruß
Juri

[Martin S. (matz666)]

Das ganze funktioniert bei mir über die MQTT Schnittstelle.

Items entsprechend programieren.

Schaltvorgänge über eine Rule.

Mfg

Martin

[Martin S. (matz666)]

Hier noch die Rule.

Z.B zum Modus HK verstellen.

rule "HK1 Modus"
when
  Item hk1modi changed
then
  if (hk1modi.state ==0) publish 
("mosquitto","set/ht3/hc1_Tniveau","auto")
  if (hk1modi.state ==1) publish 
("mosquitto","set/ht3/hc1_Tniveau","frost")
  if (hk1modi.state ==2) publish 
("mosquitto","set/ht3/hc1_Tniveau","sparen")
  if (hk1modi.state ==3) publish 
("mosquitto","set/ht3/hc1_Tniveau","heizen")
end

Viel Spaß!!! Bei Fragen melde.

Lg
Matz

[Nils (Gast)]

Norbert S. schrieb:
> Dann hast Du wahrscheinlich jetzt folgende Software im Einsatz ?:
> OS: 'Stretch'
> HT3: Rev.: 0.3 von github

Hi,

hab jetzt alles neu installiert und bis auf den blöden Terminal-Service 
auf dem Interface alles direkt zum Laufen bekommen. Da hat wohl was mit 
dem update nicht geklappt, jetzt hab ich eine schöne neue Umgebung. :-)

Viele Grüße,
Nils

[Thorsten W. (thorsten_w197)]

Hallo Norbert,

ich nutze jetzt seit längerem deine Software mit einem passiven 
Selbstbauadapter zum Auslesen meiner Heizung.

Klappt prima - seit 2 Tagen auch mit MQTT und FHEM.

Eine Frage habe ich dennoch - kann das Intervall in dem die Werte kommen 
irgendwie angepasst werden?

Gruß,
Thorsten

[Nils (Gast)]

Norbert S. schrieb:
> In diesem letztgültigen Release hat sich zwar der 'ht_proxy.server'
> nicht geändert aber viele andere Module in der Library sind angepasst
> worden.

Hi,

habe alles neu Aufgesetzt und leider kann ich noch immer nicht auf den 
Bus schreiben. Ich hab hier auch davon gelesen, dass andere auch mal das 
Problem hatten wenn 2 Clients angemeldet waren. Hast du noch eine Idee 
dazu, ich komme nicht mehr weiter.

Viele Grüße,
Nils



12.11.2018 22:44:08 INFO: cht_proxy_daemon init
12.11.2018 22:44:08 INFO: cht_proxy_daemon(); common serveraddress used
12.11.2018 22:44:08 INFO: cht_proxy_daemon start as 
proxy-server:'';port:'8088'
12.11.2018 22:44:08 INFO: logfile:'./var/log/ht_proxy.log'
12.11.2018 22:44:08 INFO: cportwrite();thread start; devicetype:MODEM
12.11.2018 22:44:08 INFO: cportread() ;thread start; devicetype:MODEM
12.11.2018 22:44:10 INFO: Client-ID:1; ('127.0.0.1', 56166) connected
12.11.2018 22:44:10 INFO: Server   :('0.0.0.0', 8088)
12.11.2018 22:44:10 INFO: Client-ID:1; register(); got devicetype:RX
12.11.2018 22:44:10 INFO: csocketsendThread(); socket.send thread start
12.11.2018 22:44:10 INFO: Client-ID:1; added; number of clients:1
12.11.2018 22:44:10 INFO: Client-ID:1; cht_RequestHandler(); 
socket.receive thread start
17.11.2018 09:56:00 INFO: Client-ID:2; ('127.0.0.1', 56332) connected
17.11.2018 09:56:00 INFO: Server   :('0.0.0.0', 8088)
17.11.2018 09:56:00 INFO: Client-ID:2; register(); got devicetype:MODEM
17.11.2018 09:56:01 INFO: csocketsendThread(); socket.send thread start
17.11.2018 09:56:01 CRITICAL: csocketsendThread();Error on socket.send
17.11.2018 09:56:01 INFO: Client-ID:2; added; number of clients:2
17.11.2018 09:56:01 INFO: Client-ID:2; cht_RequestHandler(); 
socket.receive thread start
17.11.2018 09:56:01 INFO: Client-ID:2; ('127.0.0.1', 56332) disconnected
17.11.2018 09:56:01 INFO: Client-ID:2; removed; number of clients:1
17.11.2018 09:56:01 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
17.11.2018 10:00:49 INFO: Client-ID:3; ('127.0.0.1', 56334) connected
17.11.2018 10:00:49 INFO: Server   :('0.0.0.0', 8088)
17.11.2018 10:00:49 INFO: Client-ID:3; register(); got devicetype:MODEM
17.11.2018 10:00:49 INFO: csocketsendThread(); socket.send thread start
17.11.2018 10:00:49 INFO: Client-ID:3; added; number of clients:2
17.11.2018 10:00:49 INFO: Client-ID:3; cht_RequestHandler(); 
socket.receive thread start
17.11.2018 10:00:49 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
17.11.2018 10:01:01 INFO: Client-ID:3; ('127.0.0.1', 56334) disconnected
17.11.2018 10:01:01 INFO: Client-ID:3; removed; number of clients:1
17.11.2018 10:01:01 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
17.11.2018 10:02:20 INFO: Client-ID:4; ('127.0.0.1', 56336) connected

[Nils (Gast)]

Hab hier das gleiche Problem gefunden: 
https://forum.fhem.de/index.php/topic,19445.255.html

[Norbert S. (junky-zs)]

Hallo Thorsten,
Thorsten W. schrieb:
> Klappt prima - seit 2 Tagen auch mit MQTT und FHEM.
>
> Eine Frage habe ich dennoch - kann das Intervall in dem die Werte kommen
> irgendwie angepasst werden?
Ein Intervall kann nur für die rrdtool-db Daten konfiguriert werden.
    <rrdtool-db>
      <enable>on</enable>
      <step_seconds>60</step_seconds>
Bei der MQTT-Schnittstelle werden nur die sich ändernden Werte gesendet.
Bei FHEM muss man das Notify konfigurieren. Wie das geht bitte im 
FHEM-Thread nachsehen.
Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Nils,
Nils schrieb:
> Ich hab hier auch davon gelesen, dass andere auch mal das
> Problem hatten wenn 2 Clients angemeldet waren.
Module mit gleicher Geräte-Adresse am gleichen Heizungs-Bus machen 
Probleme.
Dies betrifft alle Module am Bus: MBLan2 und ht_pitiny/ht_piduino haben 
per Default die gleiche Geräte-Adresse. Diese kann man jedoch beim 
ht_pitiny/ht_piduino ändern. Siehe die Doku dazu.
Wer kein MBLan2 am Bus hat braucht nichts zu ändern!
Jedoch wer zwei ht_pitiny / ht_piduinos am gleichen Bus betreibt muss 
einen davon auf eine andere Adresse einstellen.
Wer 'nur' einen passiven Adapter (HT3_Mini- / HT3_Micro-Adapter) hat 
braucht sich darum keine Gedanken machen.

Nils schrieb:
> habe alles neu Aufgesetzt und leider kann ich noch immer nicht auf den
> Bus schreiben.
Der Empfang geht ja wohl jetzt wieder !?
Es werden sicher auch Grafiken der rrdtool-db angezeigt?
Da Du ja einen 'aktiven' Adapter hast (ht_pitiny/ht_piduino) 
kontrolliere mal die LED's, insbesondere die Rote LED. Die muss 
kurzzeitig aufblitzen (auch ohne Befehle zum Bus).
Du kannst auch die Debug-Ausgaben des ht_proxy.servers aktivieren im 
ht_proxy.py File:
-->> ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile, 
loglevel=logging.DEBUG)
 # ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile)
Wichtiger Hinweis:
 Der ht_proxy.Server muss VOR allen anderen ht_applikationen gestartet 
werden wenn manuelle Eingriffe gemacht werden.
Beim reboot wird dies automatisch durch die Scripte erzielt.

Nils schrieb:
> Hab hier das gleiche Problem gefunden:
> https://forum.fhem.de/index.php/topic,19445.255.html
Die von mir dort gemachten Hinweise / Empfehlungen hast Du durchgeführt?

Gruß Norbert

[Nils (Gast)]

Hi Norbert.

Ja, das hab ich durch. Die Adresse ist es nicht, da es ja schon mal 
lange reibungslos lief, bis ich an der Software gefummelt habe. Hab aber 
alles mal geprüft und diese auch neu gesetzt.

Die rote Led blickt vereinzelt. Anbei mal ein Debuglog, vielleicht 
siehst du was. Ich versuch es auch mal weiter.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,
die im Debuglog des ht_proxy (ht_proxy.log) enthaltenen Sendebytes sind 
OK. Siehe dazu auch:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Die Sequence ist also nicht der Grund warum Du die Heizung nicht steuern 
kannst. Es sei den Du hast einen Neuen Heizungs-Regler, aber dem ist ja 
wohl nicht so.

Kontrolliere bitte mal ob der alte Prozess 'HT3_logger.py' noch durch 
den init gestartet wird. Es ist ein Logfile dazu in Deinem ZIP-File 
(ht_logger.log) enthalten.
Das wäre dann nicht gut, weil der alte überflüssige Prozess dann auch 
zusätzlich die gleichen Daten in die Datenbanken schreibt.
Es wird ja nur noch der ht_collgate.py benötigt. Falls nötig in 
/etc/init.d deaktivieren.

Gruß Norbert

[Nils (Gast)]

Norbert S. schrieb:
> Es sei den Du hast einen Neuen Heizungs-Regler, aber dem ist ja
> wohl nicht so.
>
> Kontrolliere bitte mal ob der alte Prozess 'HT3_logger.py' noch durch
> den init gestartet wird. Es ist ein Logfile dazu in Deinem ZIP-File
> (ht_logger.log) enthalten.

Hi,

der HT3_logger läuft nicht. Den hatte ich testweise nur mal gestartet. 
Der Heizungsregler ist auch schon Jahre drinnen. Vielleicht mach ich den 
einfach mal aus... :-) Das probiere ich mal stumpf.

Viele Grüße,
Nils

[Nils (Gast)]

Hi,

hab mal so viel wie möglich an Services abgeschaltet und konnte ein 
interessantes Verhalten feststellen. Wenn ich den ht_proxy neustarte 
wird das erste Kommando mit ht_netclient korrekt übertragen. Alle 
weiteren scheitern. Wenn ich also vor jeder Modusänderung den ht_proxy 
neustarte funktioniert es. Kannst du damit was anfangen? M.E. sollte es 
damit nicht direkt an der Konfiguration oder Verkabelung liegen, oder?

Viele Grüße,
Nils

[Nils R. (augur)]

Moin,

keine Idee dazu?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

Nils schrieb:
> M.E. sollte es
> damit nicht direkt an der Konfiguration oder Verkabelung liegen, oder?
An der Hardware (Verkabelung, Rapsi, ht_Adapter) hast Du ja nichts 
geändert nehme ich mal an und somit wird wohl eine andere Ursache 
vorliegen.

> Wenn ich den ht_proxy neustarte wird das erste Kommando mit ht_netclient
> korrekt übertragen. Alle weiteren scheitern.
Kontrolliere bitte die LED's auf dem ht_pitiny-Adapter. Wenn die 
rote-LED nach dem Senden ständig/konstant leuchtet liegt ein Fehler vor. 
Siehe dazu auch die Beschreibung unter:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Ich glaube Du hast noch ein MBlan2 parallel am Bus. Klemm das mal bitte 
testehalber ab und prüf dann die Sendefunktion mit dem ht-Adapter.

Welche HW/SW verwendest Du?:
1. Raspi A/B/B3 mit Linux 'stretch'?
2. Junkers Regler Fxyz und Fertigungsdatum (wird sich wohl nicht 
geändert haben)
3. MBLan2 parallel am Heizungsbus und verbunden mit Cloud?
4. ht-Adapter muss auf andere Adresse als MBLan eingestellt sein (ist 
aber ja wohl schon so, siehe oben)

Hast Du das Software-Release 0.3.1 komplett neu installiert und die 
Datenbanken neu erzeugt?

Gruß Norbert

[Nils R. (augur)]

Welche HW/SW verwendest Du?:
1. Raspi A/B/B3 mit Linux 'stretch'?  Ja, Raspi B
2. Junkers Regler Fxyz und Fertigungsdatum (wird sich wohl nicht
geändert haben)  FW200 - ist gleich
3. MBLan2 parallel am Heizungsbus und verbunden mit Cloud? Ja, geht aber 
auch nicht ohne
4. ht-Adapter muss auf andere Adresse als MBLan eingestellt sein (ist
aber ja wohl schon so, siehe oben) - Ja, ist er

Hast Du das Software-Release 0.3.1 komplett neu installiert und die
Datenbanken neu erzeugt? Ja


Kontrolliere bitte die LED's auf dem ht_pitiny-Adapter. Wenn die
rote-LED nach dem Senden ständig/konstant leuchtet liegt ein Fehler vor.

Leuchtet nicht konstant...hab aber gerade am Kabel rumgebastelt, um den 
Bus zu verkürzen, da ist sie auf rot gegangen und der FW200 hat 
gemeckert.


Aktueller Stand: Ich musste ein Backup einspielen, weil die SD Karte 
irgendwie aufgegeben hat und nun funktioniert auch die Aufzeichnung 
nicht mehr. :-(

[Tamas B. (atom327i)]

Hallo Zusammen,
ich möchte um Eure Hilfe bitten.
(Sorry, mein Deutsch ist nicht so schön :()

Ich versuche meine Bosch EMS2 system zu loggebn.
Zuerst möchte ich an Norber S. für die riesige Arbeit eine große Danke 
sagen!

Ich Möchte HT3 logger nur für meine Heizungsoptimalization verwenden. 
Ich brauche keine Sendefunktion, keine Datenbank, keine IP Netzwerk, 
usw.
Requirement: Botschaft-> Temperaturwerten (soll, ist), Pumpenstatus, 
Gasverbrauch zu konvertieren.

Um es einfacher zu machen, ich probierte die KomplettSW-Umgebung zu 
verwenden.

Mein Problem ist: ich besitze kein Raspberry Pi, und ich möchte auch 
mich nicht in Linux Einarbeiten. (mein Schuld)

Ich möchte aber das ganze Zeug irgendwie unten Windows in betrieb 
nehmen.
Positiv: HW habe ich gebaut, mit USB-COM schnittstelle ich bekomme mit 
Terminal SW die EMS Daten richtig.

Von SWher: ich habe Perl Python, SQlite installiert, und hoffentlich 
auch RRDtool richtig installiert.

Bei create_dtebase.py ich kann RRD Datebase nicht erzeugen lassen. Es 
wird kein perl script erzeugt. (str: \\tmp\\rrdtool_dbcreate.pl) sonst 
kommt Exception, db_rrdtool.createdb_rrdtool();Error;<2>
Warum kann es potentiell so sein?

Ich möchte mal fragen: kann ich irgendwie eine Übersetzungstabelle in 
dem Projekt finden, womit ich einfach Serielldaten direkt nach 
Physikalische Werten umrechnen kann? Es wäre für mich ganz genug, und 
einfach in Excel csv zu schreiben. (wie DBC für CAN oder LDF für LIN bus 
in Automotiv)

Mein Hintergrund: ich arbeite in Automotivbereich als SW Expert, mit 
mehr als 20 Jahren Embedded SW, HW Erfahrung (C, C++). Ich habe aber 
kein Erfahrung (noch :)) mit Python, und auch kein mit dem Linux.

Also Danke im Voraus!
Gruß,
Tamas

[Norbert S. (junky-zs)]

Hallo Tamas,

Tamas B. schrieb:
> Bei create_dtebase.py ich kann RRD Datebase nicht erzeugen lassen. Es
> wird kein perl script erzeugt. (str: \\tmp\\rrdtool_dbcreate.pl) sonst
> kommt Exception, db_rrdtool.createdb_rrdtool();Error;<2>
> Warum kann es potentiell so sein?
Der Fehler:Error;<2> bedeutet:
ERROR_FILE_NOT_FOUND -> The system cannot find the file specified.
Dies deutet auf falsche Pfade zum Filesystem hin, leidige Thema: '\' und 
’/'.
Das aktuelle SW-Release ist noch NICHT für Windows angepasst.

Vorhandene Software für Windows / Linux (python) unter:
Beitrag "Re: Heatronic 3 Adapter und Analysesoftware"
Dies ist allerdings eine ältere Version mit einer GUI-Ausgabe.

Software für Windows und Junkers-Heizung gibt es auch unter:
www.fhem.de
und der zugehörige Beitrag unter:
https://forum.fhem.de/index.php/topic,19445.msg883929.html?PHPSESSID=4kitu415rj51blpplt28emsfq2#msg883929

Tamas B. schrieb:
> Ich versuche meine Bosch EMS2 system zu loggebn.
Die hier vorhandene Software arbeitet mit 'Junkers Heatronic/EMS2(c)' 
Telegrammen und passt nicht zu Buderus (Bosch) EMS2.
Es ist beides mal zwar EMS2, aber die Telegramme zwischen Junkers- und 
Buderus-Heizungen sind unterschiedlich.
Damit die Verwirrung noch optimaler wird, heissen ab 2017 die ehemals 
Junkers Cxyz-Regler auch Bosch Cxyz-Regler.
Bitte kläre also welche Heizung von welchem Hersteller Du betreibst.
Die Telegramme und die Auswertung hängen davon ab.

Tamas B. schrieb:
> Positiv: HW habe ich gebaut, mit USB-COM schnittstelle ich bekomme mit
> Terminal SW die EMS Daten richtig.
Du kannst ja diese empfangenen Daten binär in ein File schreiben und 
hier posten. Das kann ich dann auswerten.

Gruß Norbert

[leinado (Gast)]

Hallo,
vielen Dank zunächst einmal an diesem tollen Projekt.
Ich habe es Dank der guten Dokumentation hingekriegt das alles mit dem 
Raspberry pi3 b+ und dem selbstgebauten Miniadapter ans Laufen zu 
kriegen, obwohl ich kaum Linux und Programmierkenntnisse habe.

Was mir jetzt noch fehlt, ist die Anzeige für meinen wassergeführten 
Kaminofen, also die Kesseltemperatur und Pumpe ein bzw aus.
Mein Heizungssystem: Junkers mit FW200, ISM2 UND IPM1.
Auf der FW200 wird die Kesseltemperatur des Kaminofens unter Solar - 2. 
Kollektorfeld angezeigt.

Meine Frage ist nun, wie ich das am besten machen könnte?
Habe gedacht, ob ich vielleicht die bei mir ungenutzte Anzeige für den 
2. Herzkreislauf nehmen könnte? Also quasi nur etwas modifizieren und es 
zeigt bei mir da den Kaminofen an.

Währe nett, wenn mir da jemand Tipps geben könnte. Ich habe da etwas 
Angst alles kaputt zu machen, so dass nichts mehr läuft.

Liebe Grüße
Daniel

[Norbert S. (junky-zs)]

Hallo Daniel,

leinado schrieb:
> Was mir jetzt noch fehlt, ist die Anzeige für meinen wassergeführten
> Kaminofen,...
> Habe gedacht, ob ich vielleicht die bei mir ungenutzte Anzeige für den
> 2. Herzkreislauf nehmen könnte?
Dies würde ich nicht empfehlen, da die Heizkreise ja Wärme-Senken sind 
und der Kessel ja eine Wärme-Quelle.
Daher wird ja an Deinem Regler dieser auch unter Solar angezeigt (was 
auch immer sich Junkers dabei gedacht hat).
Daher mein Vorschlag dies ebenfalls als zweite bzw. n'te Wärmequelle 
unter Solar anzeigen lassen, zumal es dort noch freie 'Spare' Logitems 
gibt.
Die Anzeige ist also kein Problem.

Bleibt noch die Dekodierung der richtigen Daten aus dem richtigen 
Telegramm(en).
Es wird wahrscheinlich ein Telegramm vom ISM2 Modul sein (B0 00 FF 00 
...).
Dies kannst Du dir im HT3_Analyser ansehen oder besser wäre es wenn Du 
ein Binärfile von den Telegrammen erstellst (<= 1 Std. mit Angaben der 
Kesseltemperatur/Zeitpunkt).
Binär-Logfile erstellen mit z.B.:
 cd ~/HT3/sw
 ./ht_binlogclient.py <meinlogfile.log>
Kannst Du an meine PM senden oder hier posten.

Gruß Norbert

[leinado (Gast)]

Hallo Norbert,
vielen Dank für deine Hilfe!
Ich habe gerade mal ein Logfile erstellt. Ich hoffe ich habe das richtig 
gemacht, sonst mache ich das gerne nochmal.
Logfile habe ich als Datei angehängt.
Zeitstempel:
Zeit  Temperatur  Pumpe
0:00  72,7    an
0:01  72,6    an
0:03  72,4    an
0:05  72,2    an
0:06  72,1    an
0:06  72,4    an
0:09  72,5    an
0:10  72,6    an
0:12  72,6    aus
0:13  74,6    aus
0:13  74,8    aus
0:13  75,9    an
0:14  76,8    an
0:14  77,7    an
0:14  78,8    an
0:15  79,7    an
0:15  79,3    an
0:15  78,2    an
0:16  77,0    an
0:16  75,9    an
0:16  74,9    aus

Ich hoffe 16 Minuten sind ausreichend, sonst mache ich das gerne länger.
Damit die Pumpe für den Kreislauf zwischendurch auch mal ausgeht, habe 
ich den Temperatursensor vom Pufferspeicher unten mal kurz oben am 
Speicher reingesteckt. Vielleicht kannst du so auch die Pumpe finden.

Gruß Daniel

[Norbert S. (junky-zs)]

Hallo Daniel,
leinado schrieb:
> Ich hoffe 16 Minuten sind ausreichend, sonst mache ich das gerne länger.
Das reicht völlig, danke für das Logfile und die gute Beschreibung der 
Werte :-)
Hinweis:
Die Systemzeit der Heizung ist um ca. 14Minuten anders als Deine 
Angaben.
Die Auswertung beeinflusst dies aber nicht.

Habe die Anpassungen in die Dekodierung eingebracht und auch die 
rrdtool-Grafik Anzeige erweitert.
Es wird jetzt ein weiterer Graph für '2.Waermequelle' angezeigt wenn die 
zugehörigen Telegramme und Werte von der Heizung gesendet werden.

Die Software ist noch nicht ganz rund, werde diese aber zeitnah auf 
github als neues Release veröffentlichen. Will damit weitere 
Test-Releases mit verschiedenen Zwischenständen hier im Forum vermeiden.

Wenn das Release soweit fertig ist kannst Du es ja auf Deine spezielle 
coole (heisse) Heizung hetzen :-)

Gruß Norbert

[leinado (Gast)]

Hallo Norbert,
vielen vielen Dank. :-)
Da bin ich schon sehr gespannt.
Gruß Daniel

[Norbert S. (junky-zs)]

Hallo @all,

eine neues Release (0.3.1) ist auf github vorhanden.
Dies am besten als komplettes Paket laden mit:
 git clone https://github.com/norberts1/hometop_HT3.git

Es sind im Wesentlichen weitere Dekodierungen für die Cxyz-Regler 
hinzugekommen und zusätzliche Anzeigen für die Temperatur an der 
Hydraulischen Weiche (falls vorhanden) und eine zusätzliche grafische 
Ausgabe für Werte der Solaranlage (2.Kollektor-Anlage).
Diese Anzeigen sind so weit als möglich dynamisch gehalten und wer diese 
Systemanteile nicht hat wird diese Anzeigen auch nicht erhalten bzw. 
sind diese Werte auf 0 gesetzt.

Vorhandene Datenbanken aus dem Release 0.3 können weiterhin verwendet 
und müssen nicht neu erzeugt werden.

leinado schrieb:
> Da bin ich schon sehr gespannt. Gruß Daniel
Bitte teste dieses Release an Deiner Anlage, die Werte für Deinen 
wassergeführten Kaminofen (Temperatur und Pumpe) sollten in der 
Zusatzgrafik (2.Waermequelle) angezeigt werden.

Gruß Norbert

[leinado (Gast)]

Hallo Norbert,
vielen Dank für deine Mühe. Es funktioniert leider bei mir noch nicht so 
richtig. Wahrscheinlich habe ich irgendwo einen Fehler gemacht. Deswegen 
erkläre ich mal Schritt für Schritt was ich gemacht habe.
1. Ich habe das komplette Paket geladen. Der Ordner hometop_HT3 lag dann 
in /home/pi
2. Ich habe den Order /home/pi/hometop_HT3/HT3 kopiert und in 
/home/pi/HT3 eingefügt und dabei alle Dateien überschrieben.
3. ich habe HT3_Analyser.py aus /home/pi/HT3/sw gestartet und mich 
riesig über das Ergebnins gefreut. Jetzt wurde 2. T-Kollektor und 2. 
Pumpe angezeigt.
4. die *.png in /home/pi/HT3/sw/etc/html wurden regelmäßig aktualisiert 
und Heizkreis 1 zeigte nun zusätslich die Mischertemperatur an :-)
Leider fehlte noch das png für den 2. Kollektor

bis hierhin also alles fast gut

5. Nach einem Reboot kamen bei dem HT3_Analyser.py nun leider aber keine 
Daten mehr rein. Und auch die *.png wurden nicht mehr aktualisiert.
mit sudo minicom -b 9600 -o -D /dev/ttyAMA0 konnte ich aber sehen, dass 
weiterhin Daten rein kamen.
6. Ich habe dann alle Dateien aus einer Sicherungskopie wieder in 
/home/pi/HT3 geschrieben und nach einem Reboot funktionierte wieder 
alles auf Anhieb wie vorher.
7.Habe alle oben genannten Punkte 3 mal wiederholt mit identischem 
Ergebnis.

Jetzt habe ich gerade beim Schreiben dieses Textes gemerkt, dass ich ja 
noch die Baudrate in der  ht_proxy_cfg.xml anpassen muss. Und endlich 
jetzt funktioniert der HT3_Analyser.py auch nach einem Reboot in der 
neuen Version und zeigt 2. T-Kollektor und 2. Pumpe :-)
Auch die *.png werden nun fleißig aktualisiert. Es fehlt leider noch das 
HT3_Solar_second.png
Aber da habe ich wahrscheinlich auch noch irgendwo einen Fehler gemacht.

Mir ist aufgefallen, dass es manchmal ca 5 Minuten dauert, bis 2. 
T-Kollektor und 2. Pumpe in dem HT3_Analyser.py angezeigt werden. Alle 
anderen Werte kommen viel eher.

Liebe Grüße
Daniel

[Norbert S. (junky-zs)]

Hallo Daniel,

leinado schrieb:
> Es fehlt leider noch das HT3_Solar_second.png
Um dem auf die Spur zu kommen aktiviere mal die Debugausgaben im 
Konfigfile: HT3_db_cfg.xml und starte den ht_collgate.py neu.
     <loglevel>DEBUG</loglevel>
Nach > 5 Minuten solltest Du eine Debugausgabe für den rrdtool.draw 
sehen etwa so:
DEBUG: cdb_rrdtool.create_draw();
         path2db  :/home/pi/HT3/sw/var/databases;
         path2draw:/home/pi/HT3/sw;
         hc_count:2;
         Contr.type:2;
         mixer_flags:[1, 1, 1, 0];
         hydrlic_sw:0;
         solar_flag:1;
         second_source:1
DEBUG: /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 
0 1 1

Wichtig sind ja dabei für Dich die Flags: 'solar_flag:1' und 
'second_sorce:1'. Beide müssen auf 1 sein, damit HT3_Solar_second.png 
geschrieben wird.
Du kannst dieses Perl-Sript auch direkt mit den nötigen Parametern 
manuell aufrufen. Wichtig sind die richtigen Pfade und das die Anzahl 
und die Werte der Parameter korrekt sind (siehe oben).
Also z.B.:
cd ~/HT3/sw/etc
./rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 0 1 1
Je nach vorhandenem Controller-Type musst Du da dann halt eingeben:
1 := Fxyz Controller
2 := Cxyz Controller

> Mir ist aufgefallen, dass es manchmal ca 5 Minuten dauert, bis 2.
> T-Kollektor und 2. Pumpe in dem HT3_Analyser.py angezeigt werden. Alle
> anderen Werte kommen viel eher.
Ja, einige der Telegramme kommen seltener. Ganz extrem ist z.B.: der 
Solarertrag (Tag/Summe bei Cxyz-Controllern). Der kommt wirklich nur 
einmal die Stunde.

Gruß Norbert

[leinado (Gast)]

Norbert schrieb:
>Nach > 5 Minuten solltest Du eine Debugausgabe für den rrdtool.draw sehen

Wo genau sehe ich die Debugausgabe? Unter /home/pi/HT3/sw/var/log 
vielleicht? Da habe ich aber nirgendwo etwas entsprechendes gefunden.

[leinado (Gast)]

Ich habe es heute nochmal versucht aber das mit der Debugausgabe 
funktioniert bei mir nicht.
In der HT3_db_cfg.xml habe ich das logging auf DEBUG gestellt und den 
Raspberry neu gestartet, damit der ht_collgate.py neu gestartet wird.
In der HT3_db_cfg.xml steht ja drin, dass das Logfile in 
./var/log/ht_default.log geschrieben werden soll. Da gibt es bei mir 
dieses Logfile aber nicht.

Was aber bei mir funktioniert :

cd ~/HT3/sw/etc
./rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 0 1 1
Bei mir (111110011)

Da wird dann ein HT3_Solar_second.png erstellt. ??
Müsste jetzt nur noch automatisch aktualisiert werden, so wie die 
anderen *.png

Liebe Grüße
Daniel

[leinado (Gast)]

Ich habe es jetzt bei mir erstmal so gemacht, dass ich das 
rrdtool_draw.pl umgeändert habe:

# solar ertrag draw
  solar_yield_draw($mypath, $mytargetpath, $controller_type);

  if ($second_collector == 0) {
    solar_draw_second_field($mypath, $mytargetpath, $controller_type);
  }

vorher: if ($second_collector > 0)

ist zwar nicht so ganz Sinn der Sache aber bei mir funktioniert es 
erstmal so :-)

Liebe Grüsse Daniel

[Henrik (Gast)]

Moin allerseits,

was bedeuten die einzelnen Stati in der Variable "hc1_operationstatus"?
3 steht für? Heizen? was gibt es dort noch? Gibt es eine Mappingtabelle 
oder ähnliches?

Gruß
Henrik

[Rob (Gast)]

Moin Leute,

mal ne Frage an alle, hättet Ihr auch ein Modul von AK-Nord 
(https://www.ak-nord.de/) genommen um die Heizungs-Datenerfassung über 
Ethernet zu realisieren oder seid Ihr alle der Meinung doch lieber ein 
RaspberryPI??

Laut deren Homepage bzw. den Datenblätter der Produkte ist dies deren 
Fokus, die Netzwerkkommunikation zu realisieren.

Was meint Ihr?


MfG
Rob