Heizungs-Datenerfassung (HT3)

[Norbert S. (junky-zs)]

Hallo Henrik,
Henrik schrieb:
> was bedeuten die einzelnen Stati in der Variable "hc1_operationstatus"?
> 3 steht für? Heizen? was gibt es dort noch? Gibt es eine Mappingtabelle
> oder ähnliches?
Diese Mapping-Funktion (GetStrOperationStatus) ist enthalten im 
SW-Modul: lib/gui_worker.py.
(Anzeige im HT3_Analyser -> ' Betriebsstatus')
Fuer 'Fxyz' - Regler:
ivalue rtnstr
 0     "---"
 1     "Manuell"
 2     "Auto"
 3     "Urlaub"
 4/5   "E-Trocknung"
Fuer 'Cxyz' - Regler:
ivalue rtnstr
 0     "Off"
 1     "Summer"
 2     "Manual"
 3     "Comfort"
 4     "Eco"
----------------
GetStrOperationNiveau()
(Anzeige im HT3_Analyser -> ' Temperatur-Niveau')
Fuer 'Fxyz' - Regler:
ivalue rtnstr
 0     "---"
 1     "Frost"
 2     "Sparen"
 3     "Heizen"
Fuer 'Cxyz' - Regler:
ivalue rtnstr
 1     "Eco"
 2     "Comfort1"
 3     "Comfort2"
 4     "Comfort3"
===============================
Hallo Rob,
Rob schrieb:
> mal ne Frage an alle, hättet Ihr auch ein Modul von AK-Nord
> (https://www.ak-nord.de/) genommen um die Heizungs-Datenerfassung über
> Ethernet zu realisieren oder seid Ihr alle der Meinung doch lieber ein
> RaspberryPI??
Es muss nicht unbedingt ein RaspPi sein, die vorgestellten ht-Adapter 
funktionieren auch mit einem UART-USB Adapter.
Die ht-Adapter haben jedoch noch zusätzlich eine galvanische Trennung 
zwischen dem Heizung-Bus und der Aussenwelt und die aktiven Adapter 
(ht_pitiny/ht_piduino) können kontrolliert Daten zur Heizung senden.
Somit funktionieren diese als Gateway, welches die Module von ak-nord 
nicht können.
Ausserdem sind die Module von ak-nord zu teuer.

Gruß Norbert

[Andreas W. (urbansunited)]

Hi!

Hat schon einer Erfahrungen mit der Installation unter Raspbian Buster 
gesammelt?

Wie löse ich zB

sudo insserv httpd?

insserv fehlt, muss installiert werden. Bekomme beim Installieren:

Setting up insserv (1.18.0-2) ...
insserv: FATAL: service mountkernfs has to exists for service udev
insserv: FATAL: service urandom has to exists for service networking
insserv: FATAL: service mountdevsubfs has to exists for service hwclock
insserv: FATAL: service udev is missed in the runlevels 2 3 4 5 to use 
service raspi-config
insserv: exiting now!

Hat einer eine Lösung?

Danke

Andi

[Andreas Wülbern (Gast)]

Hi!

Ich beantwortet meine Frage selber:

Insserv scripts mit Buster? Es geht, sogar ganz einfach:

Copy script in /etc/init.d
sudo chmod +x /etc/init.d/your_script
sudo systemctl enable your_script

Nach dem Neustart werden unsere Scripts dann automatisch ausgeführt.

Gestern selbst auf Buster erfolgreich installiert.

Problem gelöst :)

Cheers

Andi

[Norbert S. (junky-zs)]

Hallo Andreas,

Andreas Wülbern schrieb:
> Insserv scripts mit Buster? Es geht, sogar ganz einfach:...

Danke für Deine Bemühungen. Kommt bei Gelegenheit mit in die Doku.
PS:
Eins ist uns gewiss:
Linux-Software altert auch, aber es vergilbt fast nichts schneller als 
Doku, eventuell sogar noch gedruckt auf Papier.
Deshalb wird uns die Arbeit nicht ausgehen und bei uns kommt somit keine 
Langeweile auf:-).

Gruß Norbert

[Mario R. (upd8r)]

Ich muss mal wieder Norbert einen Dank aussprechen, die Software läuft 
bei mir seit Jahren ohne Probleme.

In einem Anfall von Spieltrieb habe ich jetzt auf die nächste Version 
mit collgate aktualisiert und lasse jetzt alle Daten über den MQTT-Kanal 
in meine kürzlich installierte influxDB wandern. Ich bin noch am Basteln 
des Grafana-Dashboards, anbei der aktuelle Stand. Sobald ich zufrieden 
bin, werde ich das Dashboard auch bei Grafana verfügbar machen.

[Andreas W. (urbansunited)]

Hallo Mario,

sehr schön!
Ich habe auch Grafana bei mir laufen, habe aber bisher meine Heizung 
dort noch nicht eingebunden. Das sollte später passieren.
Von daher nehme ich dein Dashboard natürlich sehr gerne. Spart mir jede 
Menge an Arbeit :D
Ich würde aber auch schon mal einen Zwischenstand bei mir installieren 
;)

Danke und Gruß

Andi

[Mario R. (upd8r)]

Hi Andi,

anbei mal der aktuelle Stand, wie gesagt, ich importiere über 
MQTT/Telegraf und habe an den topic-Namen nix geändert.
Hier ist nur ein HK plus Solar in Betrieb, mehr habe ich also auch nicht 
eingebunden.

Kann aber auch die Telegraf-Konfig dann nochmal posten ...

Die Solarertragswerte sind nicht 100% identisch und bei den Pumpenläufen 
bin ich mir auch nicht sicher, ob er das zuverlässig erkennt.

[Bernd B. (bernd_b736)]

Hallo
Die Heizperiode ist angebrochen und leider hat meines Raspi SD das 
Zeitliche gesegnet. Ich habe das System neu aufgesetzt und leider kann 
ich nicht so genau sagen wo das eigentliche Problem liegt.

Ich denke ich habe alle Packete eingespielt. und über raspi-config die 
login shell über serial deaktiviert.

Ich starte den proxy und den ht_collgate. Keine Fehler, aber es werden 
offebar auch keine Daten gelesen/geschrieben.
Das Debug log ist ziemlich leer.

Den einzigen Fehler den ich provozieren kann ist, wenn ich den MQTT 
client aktiviere: Dann bekomme ich beim start von 
ht_collateccollgate().run();Error;could not start 'mqtt-interface' with 
file:'./etc/config/HT3_db_cfg.xml'

[Bernd B. (bernd_b736)]

im ht_client_rx.log steht etwas das mich wundert:

12.10.2019 09:41:07 INFO: ----------------------
12.10.2019 09:41:07 INFO: cht_socket_client init
12.10.2019 09:41:07 INFO: connected to server:'localhost';port:'8088'
12.10.2019 09:41:07 INFO: logfile:'./var/log/ht_client_rx.log'
12.10.2019 09:41:07 INFO: Client-ID:1; registered with devicetype:'RX'

Ich nutze den pitiny und ich denke ich sollte im MODEM modus arbeiten. 
Offenbar habe ich da wohl noch was nicht richtig konfiguriert

[Mario R. (upd8r)]

Vermutlich ist es bei dir was anderes, aber ich habe neulich ein Update 
von Stretch auf Buster gemacht und danach die gleiche Fehlermeldung.

Irgendein Python mqtt Modul wurde beim Upgrade Event und ich musste es 
mittels pip wieder nachinstallieren.

Im Übrigen kann ich jedem nur Raspibackup empfehlen: 
https://www.linux-tips-and-tricks.de/de/raspibackup/

Habe das hier schon so oft benötigt ....

[Bernd B. (bernd_b736)]

> Irgendein Python mqtt Modul wurde beim Upgrade Event und ich musste es
> mittels pip wieder nachinstallieren.

Das kann ja eeigentlich nur Paho sein... das hatte ich installiert mit 
pip3 install paho-mqtt.
ABER nach ein wenig debugging hat sich genau das als falsch 
herausgestellt. Ich habe es nochmal installiert und jetzt gibt es den 
Fehler nicht mehr.
Leider bekomme ich immer noch keine Daten von HZ Bus.

[Norbert S. (junky-zs)]

Hallo Bernd,
da Du einen ht_pitiny-Adapter hast, kannst Du dessen LED-Anzeigen 
kontrollieren.
Grüne LED muss flackern -> Signal vom Heizungsbus vorhanden.
Rote LED muss aufblitzen -> Adapter antwortet dem Heizungsbus auf 
Anfragen.
-->> Wenn soweit OK, dann bitte die Konfiguration kontrollieren!
Die Baud-Rate für den ht_pitiny-Adapter muss auf 19200 stehen! 
Konfig-File: ht-proxy_cfg.xml

Bernd B. schrieb:
> 12.10.2019 09:41:07 INFO: Client-ID:1; registered with devicetype:'RX'
> Ich nutze den pitiny und ich denke ich sollte im MODEM modus arbeiten.
Ist OK auch für den ht_pitiny-Adapter. Ist nicht der Grund für die 
fehlenden Daten vom Bus.
Dies zeigt aber, das der ht_proxy.server korrekt arbeitet. Ob dieser 
allerdings Daten vom ht_pitiny-Adapter erhält kannst Du prüfen mit 
Browseraufruf:
 http://<IP-Adresse des RPi>:8088
Soll-Ausgabe von Sequenzen wie: #HR�....

Zum Test kannst Du auch die python-Module (ht_proxy.py, ht_collgate.py) 
ohne die Start-scripte von Hand aufrufen, dann bekommst Du im Fehlerfall 
mehr Informationen.

Ich nehme mal an Du benutzt den aktuellen SW-Stand (Rev. 0.3.1) von 
github und Linux 'stretch' oder 'buster'?

Gruss Norbert

[Bernd B. (bernd_b736)]

Hallo Norbert
Ich habe des Rätsels Lösung gefunden. spi_clk_off.py hat geholfen.

Ist vielleicht auch für andere interessant. Ich habe einen Raspberry Pi 
Model B Rev 2 und das aktuelle (oct. 19) Image von Raspbian (minimal) in 
Verwendung.

[Norbert S. (junky-zs)]

Hallo Bernd,
prima das es wieder läuft!

Bernd B. schrieb:
> Ich habe des Rätsels Lösung gefunden. spi_clk_off.py hat geholfen.
Dieses Script wird normalerweise von den Start-Scripten: 'ht_proxy' und 
'ht_collgate' beim Systemboot aufgerufen:
...
$APPLICATION_FOLDER/etc/sysconfig/spi_clk_off.py
...

Nur wenn man einen Daemon von Hand startet, ist dieser manuelle Aufruf 
von 'spi_clk_off.py' erforderlich.

Gruß Norbert

[Bernd B. (bernd_b736)]

:D ja das habe ich dann später bemerkt. Aber Du weist ja wie es läuft... 
erst mal versucht man es "zu Fuss" bevor man das ganze automatisch 
laufen lässt.

Ich habe noch eine Frage: Ich steuere die Heizung via MQTT->

Für den Heizmodus gibt es ja das Topic: hc1_Tniveau.
Das kann man mit den Werten "auto, frost, sparen, heizen" in den 
entsprechenden Modus setzen.
Aber wie kann man erkennen, ob man aktuell im "Auto" Modus ist oder 
"manuell" auf einem der Modi sitzt?
hc1_Tniveau gibt einem soweit ich das sehe ja nur (1, 2, 3) an.

Tolles Projekt Norbert, noch mal vielen Dank für die harte Areit.

[Norbert S. (junky-zs)]

Hallo Bernd,

Bernd B. schrieb:
> Aber wie kann man erkennen, ob man aktuell im "Auto" Modus ist oder
> "manuell" auf einem der Modi sitzt?
Bei aktiviertem MQTT erhält man ja alle Informationen beim Start des 
MQTT-Clients (sofern der Broker entsprechend eingestellt ist) und danach 
jeweils wenn eine Änderung für ein Item aufgetreten ist.
Allerdings gibt es z.Zeit noch keine Abfrage-Möglichkeit eines Wertes 
über die MQTT-Schnittstelle.
Ich denke dies wäre eine nützliche Erweiterung dieser Schnittstelle. In 
Analogie zum 'Set'-Befehl dann eben einen 'Get'-Befehl für die Items.

Diese Abfrage-Möglichkeit gibt es allerdings schon mit dem 
SPS-Interface. Diese Schnittstelle muss aber erst aktiviert werden, da 
default deaktiv.

Konfigurations-File 'collgate_cfg.xml' anpassen und dort SPS auf 'on' 
stellen. Danach den ht_collgate-daemon neu starten.
Über dies Schnittstelle können dann Werte abgefragt werden. Details 
siehe auch Doku im Kapitel 2.3.3 SPS ht_Server.
Das Testprogramm ~/HT3/sw/test/sps_testclient.py kann als Grundlage für 
solche Abfragen dienen (siehe Ausgaben in den Bildern).

Allerdings werden die Werte nicht als Strings sondern wie in den 
Telegrammen gesendet zurückgegeben. Die Interpretation ist dann separat 
noch nötig z.B.:
send     -> :hc1_operationstatus
response <- :hc1_operationstatus:=1
Die '1' steht dann für aktuellen Betriebsstatus:= 'Manuell' bzw '2' := 
'Auto'.
(Diese Werte gelten allerdings nur für die Fxyz-Regler-Serie)

Gruß Norbert

[_rooky_ (Gast)]

Hallo,

beeindruckende Software. Und ich habe mich beim Aufbauen des Adapters 
schon auf die reichhaltige Datenanzeige gefreut. Bisher nutze ich eigene 
Sensoren, die per MySensors an Domoticz gesendet werden. Da habe ich 
aber bisher nur wenige Sensoren/Parameter verfügbar.

Leider werden im HT3_Analyzer nur wenige Daten angezeigt. Dafür aber 
einige unbekannte Nachrichten. Zwei Screenshots sind angehängt.

Exemplarisch habe ich noch ein putty.log der seriellen Schnittstelle und 
die Datei Heizung.log angehängt.

In Heizung.log sind aufgezeichnete Daten im Klartext enthalten. Die 
erste Spalte sind Mikrosekunden Wartezeit zwischen den empfangenen 
Bytes. Die zweite Spalte die Anzahl Bytes pro read() (immer 1;)
Die ...-Zeilen sind Wartezeiten in 2000 Mikrosekunden pro '.', wenn 
gerade keine Bytes ankommen.
Damit hatte ich gehofft, die Genzen von Messages erkennen zu können. 
Z.B: bei Zeile 407-437 funktioniert das ganz gut. An anderen Stellen ist 
es eher verwirrend.

Meine Anlage:
Kessel ZSBE 28-3
FW200 (JF12.10)
IPM2  (JF20.06)
ISM2  (JF23.02)
Heizkreis1 mit externem Mischer
Kombinierter Solar- und Warmwasserspeicher
Hydraulische Weiche


Nun meine Fragen: hat es ggf eine einfache Ursache, warum die Messages 
im HT3_Analyser nicht angezeigt werden, eine Konfiguration o.ä.? Oder 
verwendet meine Anlage Messages, die der HT3_Analyzer nicht unterstützt?

Schon mal vielen Dank für die Hilfe.

Gruß,
rooky

[Norbert S. (junky-zs)]

_rooky_ schrieb:
> Und ich habe mich beim Aufbauen des Adapters schon auf
> die reichhaltige Datenanzeige gefreut.
Welchen der Adapter-Typen hast Du gebaut?
Wichtig sind die richtigen Optokoppler, da nicht alle die erforderlichen 
Daten haben(Flankensteilheit, Ansprechstrom etc.)

> In Heizung.log sind aufgezeichnete Daten im Klartext enthalten.
Dieses Logfile zeigt einige seltsame Sequenzen, die in dieser Form nicht 
gesendet werden, z.B.:
  211147   1 22
    1053   1 00
.
    2509   1 A2
    1250   1 A2 <=== Fehler, ist doppelt
    1200   1 00
    1146   1 00
...........
   23963   1 0E
    1064   1 00
...............
   30076   1 30
    1061   1 00
...
    7084   1 B0
    1236   1 B0 <=== Fehler, ist doppelt
    1213   1 00
    1134   1 00
Wie bzw. womit wurde dieses Logfile erstellt?
Sicher nicht mit dem vorhandenen Tool: ht_binlogclient.py.
Es sieht nach Auslesefehlern der UART-RX Werte aus oder dein Adapter hat 
Probleme mit den Signalen auf dem Bus.

> Nun meine Fragen: hat es ggf eine einfache Ursache, warum die Messages
> im HT3_Analyser nicht angezeigt werden,
Wenn die serielle Schnittstelle (Baudrate etc.) richtig eingestellt ist 
würde ich noch als Ursache deinen Adapter vermuten.

> Oder verwendet meine Anlage Messages, die der HT3_Analyzer nicht unterstützt?
Die Messages Deiner Anlagen-Module werden dekodiert und erkannt wenn die 
Sequenzen richtig sind (CRC muss korrekt sein).
Aus den aufgezeichneten Telegrammen kann ich folgendes entnehmen:
Modul IPM2 steuert 1. den Heizkreis1 (Device-ID 20hex.) und ist 2. für 
die Steuerung der Warmwassererzeugung zuständig (Device-ID 22hex.)
Dein Heizgerät ist eingestellt auf 'Interne Warmwassererzeugung 
deaktiv'.
Modul ISM2 kontrolliert 1. Solar-Kollektor (Device-ID 30hex.) und 2. 
wohl auch die Warmwasser-Erzeugung.

Mein Tipp, deinen Adapter noch einmal checken und eventuell ein Logfile 
erzeugen nur mit dem Aufruf:
 cd ~/HT3/sw
 ./ht_binlogclient.py <irgendeinenlogfilenamen.log>
Das Logfile kann ich dann checken wenn Du es hier veröffentlichst.
Gruß Norbert

[_rooky_ (Gast)]

Hallo Norbert,

vielen Dank für die schnelle Antwort und Analyse.

Ich habe einen HT3-Miniadapter mit H11L1M aufgebaut.

Ja, die A2 A2, B0 B0 und 90 90 sind mir auch aufgefallen. Das Textlog 
habe ich mit einem eigenen C++ Programm erstellt.
'binlogclient.log' habe ich angehängt. Dort sehe ich auch die 
Doppelbytes.

Ich habe in der Zwischenzeit hp_discode.py mit einigen Traces bestückt, 
um die Dekodierung besser verstehen zu können. Das Logfile dazu habe ich 
auch angehängt ('ht_analyser.log'). Dort sieht es zumindest so aus, als 
wenn die Doppelbytes nicht ankommen.
Einen Screenshot des HT3_Analyzer derselben Session habe ich auch 
angehängt.

Die HT3_db_cfg.xml ist auch angehängt.

Gruß
rooky

[_rooky_ (Gast)]

Hallo Norbert,

ich habe jetzt einen ATmega328 zwischen den HT3 Miniadapter und den 
Raspberry Pi geschaltet. Dieser erkennt BREAK (Frameerror mit 
Empfangsbyte=0x00, Register UCSRnA, Bit FEn). Damit ermittle ich das 
Message-Ende.

Tatsächlich kommen die Nachrichten mit Source A0, A2, B0, 90 mit 
duplizierten Bytes an. Source 88 dagegen kommt normal.

Ich habe probeweise ht_discode.py so angepasst, dass die duplizierten 
Bytes entfernt werden (if ...: del self._rawdata[:message_size:2]) --> 
diese Nachrichten werden dann tatsächlich erkannt und dekodiert!

Im Anhang ein Screenshot. Es gibt noch einen Fehler in meiner 
Nachrichtenaufbereitung, der gelegentlich eine fehlerhafte Nahricht 
durchlässt. Daran muss ich noch arbeiten.


Die Doppelbytes scheinen so auf dem Bus anzuliegen, da ja am gleichen 
Draht für 88 keine Doppelbytes ankommen, aber für A0, A2, B0, 90 schon.

Ich habe den HT3 Miniadapter am freien Busausgang des ISM2 angeklemmt. 
Ich könnte mal probieren an anderer Stelle (HG, FW200) anzuklemmen, ob 
da was anderes passiert.

Ggf. werde ich noch mal den Bus mit einem Speicheroszi aufzeichnen und 
so bestätigen - oder auch nicht -, dass es die Doppelbytes tatsächlich 
gibt.

Wie auch immer sich das alles erklären lässt, Im HT3_Analyzer sind jetzt 
deutlich mehr Daten zu sehen ;)

Gruß,
rooky

[Norbert S. (junky-zs)]

Hallo rooky,
prima das Du eine Lösung für das Problem gefunden hast.

> Ich habe den HT3 Miniadapter am freien Busausgang des ISM2 angeklemmt.
Schliesse den ht_Adapter direkt am Bus an, also parallel zu den Modulen 
an die Klemmen (BB bzw. ESM2).
Dabei ist es egal welches Modul Du nimmst, die hängen alle parallel am 
gleichen Bus. Du kannst also auch das ISM2 nehmen.
Offensichtlich wird am zweiten Anschluss des ISM2 das Bus-Signal 
modifiziert ausgegeben und ist somit ungeeignet für die korrekte 
Dekodierung.

Gruß Norbert

[Fred (Gast)]

Hallo Nobert,

ich habe auch seit kurzem nach deiner Anleitung auch deinen super 
Datenlogger am Laufen. Primär um die Einstellungen der Anblage nach 
einer Analysephase ggf. zu optimieren. Leider stimmt irgendetwas mit den 
WW-Daten nicht, es kommt nur sehr selten ein Wert und wenn, dann sind 
die Temparaturwerte im Speicher viel zu gering. Vor allem die 
Warmwasserspeichertemperatur interessiert.

Anlagedaten:
------------------
- ZSB 24-4 C 23
- FW200 Regler
- IPM1: Hydraulische Weiche (HW), Speicherladepumpe, 
Speichertemperaturfühler (SP)
- IPM2: Heizkreis 1 Radiatoren, Heizkreis 2 Fußbodenheizung
- ISM2: Warmwasser Schichtspeicher, Solarkreispumpe, Ventil 
Rücklaufanhebung (DWU1), NTCxxx

- Raspi3 mit HT3-Miniadapter, hometop 0.3.3


Vielen Dank im Voraus

Gruß, Fred

[Norbert S. (junky-zs)]

Fred schrieb:
> Leider stimmt irgendetwas mit den WW-Daten nicht...
Dank des Logfiles und Deiner Beschreibung konnte ich das Problem 
nachvollziehen und auch eine Lösung finden.
Grund ist eine in Deinem System verwendete DeviceID:0x41, die von einem 
der IPM2 Module (für Warmwasser) verwendet wird. Damit die Dekodierung 
auch dafür funktioniert ist eine kleine Anpassung in der Software nötig.
Diese kannst Du zum Test bei Deiner Software selber durchführen wie 
folgt:
Modul : ~/HT3/sw/lib/ht_discode.py
Zeile : 3224 ff
Aktion: 0x41 im array:'deviceaddress_white_list[]' hinzufügen.

# 2021-02-12: 0x41 added in deviceaddress_white_list[]
deviceaddress_white_list = [
     0x08, 0x0a, 0x0b, 0x0c, 0x0d, 0x10, 0x18, 0x19, 0x1a,
     0x20, 0x21, 0x22, 0x23, 0x28, 0x29,
     0x30, 0x31, 0x41, 0x48]

Damit ist dann die Dekodierung auch für WW möglich (siehe Bilder)
Diese Änderung und die Auswirkungen muss ich im Detail noch einmal 
kontrollieren und werde dann ein neues Release auf github 
veröffentlichen.

Für mich sind diese IPM2 Module und deren Einstellungen sehr wichtig, da 
ich in meiner Anlage die Module nicht habe. Deshalb ist Dein Logfile für 
mich Gold wert!
Welche Schalter-Stellungen haben diese IPM1/IPM2 Module bei Dir im 
System?

Gruß Norbert

[Fred (Gast)]

Hallo Norbert,

vielen Dank für deinen Tip!

Ich habe die Änderungen wie beschrieben durchgeführt und es sieht jetzt 
viel besser aus (siehe HT4_WW_Graph.png).

> Für mich sind diese IPM2 Module und deren Einstellungen sehr wichtig, da
> ich in meiner Anlage die Module nicht habe. Deshalb ist Dein Logfile für
> mich Gold wert!
> Welche Schalter-Stellungen haben diese IPM1/IPM2 Module bei Dir im
> System?

Freut mich :-) Falls du noch mehr brauchst gib bescheid.

---------------------------------
IPM 1 - WW Speicherladekreis
---------------------------------
Speicherladekreis nach der hydraulischen Weiche muss Kodierung 3 oder 
höher erhalten. In meinem Fall ist die Kodierung vom 
Heizungsinstallateur auf **10** (Device ID 0x41) gesetzt worden.

**Anschlüsse:**
   - VF = Gemeinsamer Vorlauffühler der Hydraulische Weiche (HW)
   - SF1 = Speichertemperaturfühler SF (NTC) des Warmwasserspeichers
   - P1 = Speicherladepumpe LP

---------------------------------
IPM 2 - Modul für zwei Heizkreise
---------------------------------
- Heizkreis 1 (HK1) = Kodierschalter I auf **1** (Device ID 0x20)
- Heizkreis 2 (HK2) = Kodierschalter II auf **2** (Device ID 0x21)

**Anschlüsse:**
   - MF2 = Vorlauftemperaturfühler gemischter Heizkreis (Fußbodenheizung 
HK2)
   - P1 = Heizkreispumpe (Heizkreis HK1, Radiatoren)
   - M2 = Mischerstellmotor Heizkreis HK2 (Fußbodenheizung)
   - P2 = Heizkreispumpe (Heizkreis HK2, Fußbodenheizung)
   - TB2 = Temperaturwächter HK2 (Fußbodenheizung)

Meine Anlage scheint doch etwas spezieller zu sein. Im HT_Analyzer sehe 
ich noch einige Telegramme mit Fragezeichen dargestellt (siehe 
HT4_Unknown_Telegrams.png), es scheint noch nicht alles zu passen, ich 
versuch gerade noch deinen Code besser zu verstehen um auch selbst 
analysieren zu können.

Gruß Fred

[Norbert S. (junky-zs)]

Fred schrieb:
> Meine Anlage scheint doch etwas spezieller zu sein. Im HT_Analyzer sehe
> ich noch einige Telegramme mit Fragezeichen dargestellt...
Deine Anlage ist zwar speziell, das Problem liegt jedoch mehr in der Art 
wie Bosch (Junkers/Buderus) die Telegramme auf dem seriellen Bus senden.
Besonders das Ende-Kennzeichen eines Telegramms wird durch das 
BREAK-Signal angezeigt (mehr als 10Bit Bus auf low). Dieses Signal wird 
leider vom seriellen Treiber in eine Null übersetzt und somit kann man 
das Ende eines Telegrams nicht mehr eindeutig erkennen.
Bei langen Telegrammen ist eine CRC am Ende enthalten. Diese kann man 
prüfen und somit das Telegramm dekodieren. Leider gibt es viel häufiger 
kurze Telegramme die keine CRC enthalten.
Insbesondere das Polling der Steuerelektronik im Heizgerät (Master) und 
die kurzen Antworten der Module (Clients) führt oft zu 
Fehldecodierungen.
z.B. aus Deinem Bild:

C1 00 14 00 09 00 89 00 15 00 09 00 89 00 09 00 89 00 ...
PA Br DP Br DP Br PA Br DP Br DP Br PA Br DP Br PA Br ...
PA:= Polling-Antwort des angesprochenen Moduls (hier immer keine Daten)
DP:= DevicePolling von Steuerelektronik
Br:= Breaksignal vom seriellen Treiber zu Null uebergeben

Die Dekodierung der Telegramme mit den passiven Adaptern: 
HT3_Mini/Micro_Adapter ist daher ohne korrekte Break-Signalerkennung 
erschwert.
Die aktiven ht_transiver-Adapter (ht_pitiny/ht_piduino) erkennen das 
Break-Signal korrekt und übergeben die Telegramme mit Längenangabe zur 
weiteren Dekodierung.
Werde trotzdem versuchen die Dekodierung für die passiven Adapter zu 
verbessern.
Gruß Norbert

[micha (Gast)]

Hallo zusammen,

vorab vielen Dank für die super Arbeit! habe einen Raspberry Zero mit 
einem ht-tranceiver am laufen und die Daten per MQTT in unser IP Symcon 
System eingebunden. Funktioniert bislang perfekt.

Ich hätte eine Frage zum dem Errorcode. Gibt es hier eine Übersetzung? 
Den bzw. die Causecodes habe ich in der Anleitung gefunden, zum Errocode 
(z.B. 17461) aber rein gar nichts. Kann dieser entschlüsselt werden? 
Würde gern die Codes in Symcon hinterlegen und die Fehler im Klartext 
auf dem Tablet anzeigen.

Haben eine einfache Therme ZSB 14-4C... mit Warmwasserspeicher, 
Solarthermieanlage und ein C 400 Bedienelement.

Gruß Micha

[Norbert S. (junky-zs)]

micha schrieb:
> Den bzw. die Causecodes habe ich in der Anleitung gefunden, zum Errocode
> (z.B. 17461) aber rein gar nichts.
Diesen Errorcode habe ich ebenfalls nicht in meinen Unterlagen gefunden. 
Was ich für die Cx400/800 Reglerserie finden konnte sind alles Codes 
wie:
 Störungs-Code   : Axy | z.B.: A41
 und Zusatz-Codes: 811, 4051, usw.

Die dezimale Zahl:17461 in Hex: 4435 ergäben die ASCII-Zeichen: D5
Allerdings ist auch dieser Error-/Cause-Code nicht in meinen Unterlagen.

Mit dem HT3_Analyser kannst Du die Telegramme auswerten, insbesondere 
das Telegramm: MsgID 24_0.
Im Telegramm sind die Bytes: 22/23 für den Display-Code und die Bytes: 
24/25 für den CauseCode reserviert (siehe markierten Bereich im Bild, 
Wert dort 00cc hex := 204dez.)

Falls in Deiner Anlage Fehler vorhanden sind, so sollten diese auch im 
Regler Cx400 angezeigt werden. Vergleiche bitte mal beide Angaben.
Eventuell kannst Du auch noch ein binäres Logfile (ca. 1/2 Std.) deiner 
Anlagentelegramme erzeugen und mir zusenden oder hier veröffentlichen.

Gruß Norbert

[Micha (Gast)]

Hallo Norbert,

danke für die Antwort. Das passt dann aber zusammen. Die Anlage zeigt 
ein D5 331 an, was nach Anleitung auf einen defekt des externen 
Vorlauftemperaturfühlers hindeutet.

Der Angezeigte Fehler setzt sich dann immer aus Errorcode und Causecode 
zusammen?!

Gruß micha, allen schöne Ostern!

[Norbert S. (junky-zs)]

Micha schrieb:
> Der Angezeigte Fehler setzt sich dann immer aus Errorcode und Causecode
> zusammen?!
Ja.
Es gibt mehrere Telegramme für Fehlermeldungen, aber Error- und 
Cause-Code werden zusammen gesendet. Eventuell kann einer der beiden 
Werte Null sein (nicht gesetzt). Ist kein Fehler vorhanden sind beide 
Werte Null.

Telegramme mit Error-/Cause-Code sind:
MesId's (dezimal): 24, 162, 190, 191;
teilweise allerdings mit unterschiedlicher Byte-Anzahl und von 
verschiedenen Quellen. Dies macht die Auswertung schwieriger.
Am Heizungs-Regler angezeigte Fehlermeldungen stammen wohl vom Telegramm 
MesID:24.

Micha schrieb:
> Die Anlage zeigt ein D5 331 an, was nach Anleitung auf einen defekt des externen
> Vorlauftemperaturfühlers hindeutet
Da Du nur eine Zahl (17461) mitgeteilt bekommst, ist wohl noch eine 
Dekodierung des Wertes von 17461 nach D5 erforderlich oder?
Wird denn die Zahl: 331 korrekt übermittelt?
Welche Werte werden im HT3_Analyser.py für Error-/Cause-Code angezeigt?

Gruß Norbert

[Stephan (Gast)]

Hallo,

ich musste letzte Woche meine SD-Karte begraben und versuche nun die 
Datenerfassung neu zu installieren. Dies habe ich eigentlich schon öfter 
gemacht, angefangen damals mit einem PI 1 und einem Miniadapter. Bis 
ungefähr Weihnachten lief es nun auf einem PI3B+ mit einem pitiny.

Aber nun will es einfach nicht gelingen. LED's auf dem pitiny blinken 
und ich habe mich an die aktuelle Anleitung gehalten und bin nur den 
kürzensten Standardweg gegangen. Aber es kommt einfach kein Paket an. Es 
werden keine Datenbankeinträge geschrieben, Logeinträge kommen nach dem 
Start keine dazu und auch Grafiken werden keine erstellt.

Hat jemand eine Idee?

Danke und Gruß
Stephan

[Norbert S. (junky-zs)]

Stephan schrieb:
> Aber nun will es einfach nicht gelingen. LED's auf dem pitiny blinken
> und ich habe mich an die aktuelle Anleitung gehalten und bin nur den
> kürzensten Standardweg gegangen. Aber es kommt einfach kein Paket an. Es
> werden keine Datenbankeinträge geschrieben, Logeinträge kommen nach dem
> Start keine dazu und auch Grafiken werden keine erstellt.
>
> Hat jemand eine Idee?
Hallo Stephan,
da Dein(e) Adapter schon einmal an der Heizung Daten erfasst hatten ist 
wohl die Hardware und die Verbindung zum Heizungsbus in Ordnung.
Da Du auch die Standardkonfiguration (Default-Einstellung von github) 
verwendet hast betreibst Du das Projekt lokal als user 'pi' auf Deinem 
RPi.

Wenn trotz allem keine Daten kommen bleibt als Grund wohl nur noch die 
serielle Schnittstelle vom/zum Adapter (ht_pitiny) über. Bitte die 
Einstellungen in den Konfigurationsfiles kontrollieren.
Erforderlich sind ja für den aktiven ht_pitiny-Adapter:
 19200 Baud und 8N1.

Dies muss im Konfigfile ~/HT3/sw/etc/config/ht_proxy_cfg.xml eingestellt 
werden. Beispiel von meinem RPi4:

    <ht_transceiver_if devicename="RX">
      <parameter>
        <serialdevice>/dev/serial0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>RX</devicetype>
    </ht_transceiver_if>
    <ht_transceiver_if devicename="MODEM">
      <parameter>
        <serialdevice>/dev/serial0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>MODEM</devicetype>
      <deviceaddress_hex>0D</deviceaddress_hex> 
    </ht_transceiver_if>

Bitte den Namen der Seriellen Schnittstelle beachten!
Die ist hier geändert auf: /dev/serial0
Es kann sein, dass die serielle Schnittstelle Deines RPi eben nicht mehr 
als /dev/ttyAMA0 bezeichnet wird sondern eben als /dev/serial0 etc.
Die bitte auf Deinem RPi kontrollieren (siehe Bilder für RPi3 und RPi4).

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:

> Es kann sein, dass die serielle Schnittstelle Deines RPi eben nicht mehr
> als /dev/ttyAMA0 bezeichnet wird sondern eben als /dev/serial0 etc.

Hallo Norbert,
wie immer gilt: kaum macht man es richtig, schon geht es...

Ja, genau das war es! Ich wähnte mich auf der sicheren Seite weil die 
Anleitung bei der Unterscheidung zwischen ttyAMA0 und Serial0 ja klar 
von einen PI 4 spricht und ich ja "nur" einen PI 3 B+ habe.
Und ich hätte schwören können, dass es beim "ersten" Mal mit diesem Pi 
noch ttyAMA0 war (aber das war auch noch nicht mit Buster).

Also vielen Dank für die Hilfe und die langjährige Arbeit am Projekt.

Gruß
Stephan

[Norbert S. (junky-zs)]

Stephan T. schrieb:
> Und ich hätte schwören können, dass es beim "ersten" Mal mit diesem Pi
> noch ttyAMA0 war (aber das war auch noch nicht mit Buster).
Ja, wahr auch so. Deswegen hatte ich dies in der Doku auch so für den 
RPi3 beschrieben und beim RPi4 war dann eben /dev/serial0 nötig.
Aber dies hat man wohl jetzt für RPi3/4 und Buster geändert und hängt 
mehr oder weniger mit der Bluetooth-Schnittstelle zusammen.
Siehe dazu:
https://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3-pizerow-pi4-or-later-models/45571#45571

Werde deshalb die Default-Konfiguration im Projekt auf github.com 
anpassen müssen.
PS:
Allerdings warum man ausgerechnet den Namen: '/dev/serial*' verwendet 
hat ist mir schleierhaft. Die Schnittstellen: SPI, I²C, USB usw. 
arbeiten auch seriell, werden aber sicher nicht mit diesem Namen 
anzusprechen sein (oder doch in Zukunft!!???)

Noch ein Hinweis zur fehlerhaften SD-Karte.
Hatte selber Probleme mit SD-Karten. Zu häufiges Schreiben bekommt denen 
wohl nicht so gut (bei Dauerbetrieb und über Jahre).
Habe deshalb die Datenbanken auf einem USBStick generiert und schreibe 
die Heizungsdaten auch nur noch auf diesen Stick. Dazu ist die 
Konfigurationdatei anzupassen auf den absoluten Pfad des USBSticks.
Dies läuft nun schon seit Jahren.

Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,

ich betreibe seit ca. 3 Jahren Deine Software auf einem Raspberry Pi 3B
mit dem HT3-Miniadapter ohne große Probleme. Dafür erst einmal vielen
Dank.
Nun habe ich vor das Raspbian auf Bullseye zu aktualisieren und auch
Deine neueste Softwareversion einzusetzen. Dabei habe ich folgende
Vorgehensweise gewählt:
- Erstellung des Raspian Bullseye auf einem anderen Raspberry Pi 3B+
- Installation Deiner aktuellen Software nach Anleitung
- Erster Test auf dem Raspberry Pi 3B+ ohne HT3-Miniadapter, keine
  Fehlermeldungen, aber auch ohne Daten.
- Alten Raspberry Pi 3B herunterfahren und die SD-Karte mit dem neuen
  Bullsey einlegen. Raspberry wieder hoch fahren.
- Ich bekomme keine Fehlermeldungen in den Log-Dateien,
  aber auch keine Daten.
- Darauf hin habe ich die SD-Karten wieder getauscht
  und das alte System läuft wieder ohen Probleme.

Hast Du eine Idee, was und wie ich weiter prüfen kann?

Gruß Michael

[Stephan (Gast)]

Hallo Michael,
Guck Mal die letzten 4 Posts. Sieht so aus als hättest du dasselbe 
Problem wie ich...
Gruß
Stephan

[Michael W. (wemi2019)]

Hallo Stephan,
vielen Dank für den Hinweis. Genau das war es. In der vorhergehenden 
Version habe ich noch /dev/ttyAMA0 benutzt. Und ich bin mir fast sicher, 
dass ich da bereits Buster am laufen hatte. Aber jetzt, mit 
/dev/serial0, läuft wieder alles.
Gruß
Michael

[Bernd B. (bernd_b736)]

Hallo Norbert
Ich nutze deine Software schon seit nun über 4 Jahren und musste schon 
seit längerem nichts mehr ändern. Vielen Dank für die ganze Mühe die Du 
dir gemacht hast - das ist echt bewundernswert!

Die aktuellen Gaspreise haben mich aber motiviert noch mal nach 
Optimierungspotentials zu suchen.

Ich habe eine Solarthermie und unterstütze die Heizung durch Rücklauf 
anhebung.
Leider führt das dazu, dass meine Heizung ziemlich ins Takten kommt und 
ich würde eigentlich viel lieber die Heizkreispumpe ohne Brenner nutzen.

Leider habe ich keine Möglichkeit gefunden nur die Pumpe ein/aus zu 
schalten. Kann die Heizung bzw. das Interface das einfach nicht?

[Bernd B. (bernd_b736)]

Ich glaube die Antwort kann ich mir selbst geben.
Tatsächlich reicht es aus, die Solltemperatur zu senken. Dann schafft es 
die Gastherme - ohne zu zünden - in regelmäßigen Abständen die 
Heizkreispumpe zu starten.

[Martin G. (g_martin)]

Hallo Zusammen,

ich durch die HT3-Soft- und Hardware jetzt erstmals eine Idee über die 
Aktivitäten meiner Heizung bekommen, ZWSB 22/28-3 mit FW120 aus 2014 in 
einem EFH von 1997. Aus meiner Sicht ist da ziemlich was los (siehe 
Bilder)

Ich versuche aktuell, dass etwas zu entwirren. Wenn mir jemand spontan 
Hinweise geben kann, was komisch ist, oder verbessert werden kann, freue 
ich mich über Hinweise. Die Heizungsfragen will ich im auch im 
Heizungsforum stellen 
https://www.heizungsforum.de/forums/junkers-bosch.14/, (falls nicht 
jemand bessere Adressen hat).

Das Gerät steht praktisch noch auf den Einstellungen von Inbetriebnahme 
und läuft aus meiner Sicht viel zu oft an.

Ich habe allerdings noch eine ganz spezielle Frage: Ich beobachte, dass 
der Wert `hc1_Tflow_desired`, also T-Soll (Regelung) vom Heizgerät bei 
mir ständig, aber ohne für mich erkennbare Frequenz, auf 85 °C hochgeht.

Kann mir jemand erklären, was da passiert und warum das passiert? Wie 
kann ich das verhindern, oder will ich das vielleicht gar nicht 
verhindern?

Viele Grüße
Martin

PS: Grandioses Gesamtpaket, Respekt an Norbert!

[Norbert S. (junky-zs)]

Martin G. schrieb:
> Ich habe allerdings noch eine ganz spezielle Frage: Ich beobachte, dass
> der Wert `hc1_Tflow_desired`, also T-Soll (Regelung) vom Heizgerät bei
> mir ständig, aber ohne für mich erkennbare Frequenz, auf 85 °C hochgeht.
Wird immer bei Warmwasser-Erwärmung auf diesen Wert gesetzt. Soll ja 
schnell erwärmt werden.

> Kann mir jemand erklären, was da passiert und warum das passiert? Wie
> kann ich das verhindern, oder will ich das vielleicht gar nicht
> verhindern?
Warmwasser wird zu häufig erzeugt. Liegt wohl hauptsächlich an der 
aktiven Zirkulations-Pumpe. Wasser ist dann zwar immer sofort heiß am 
Hahn, aber dafür zahlt man dann auch.
Versuchsweise mal die Zirkulations-Pumpe deaktivieren (wenn der Chef des 
Hauses dann flucht hat Man(n) schlechte Karten :-).

Die WW-Speicher Temperatur ist fast immer (ca. 3 Grad) unterhalb des 
Soll-Wertes. Kann ich mir z.Zeit nicht erklären.

Vielleicht hat noch jemand ein paar Tipps.

Gruß Norbert

[Martin G. (g_martin)]

Das hat mir schon sehr geholfen. Meine Anlage hat auch eine externe Wilo 
Pumpe (die nicht in Betrieb ist). Dass die Heizung selbst umwälzt, war 
mir nicht (mehr?) klar. Damit verstehe ich dann auch die 
Pumpenaktivität, die im Diagramm auftaucht ist. Da hat meine Heizung 
etwas gemacht, das ich eigentlich so nicht wollte.

Die Umwälzung ist jetzt abgestellt bzw. sehr punktgenau eingestellt. Das 
zeigt sich auch schon in der aktualisierten Darstellung.Danke schon 
einmal dafür.

Als nächstes würde ich ja gerne die Anzahl der Zündungen reduzieren. 
Könnte ich da mit der Taktsperre Erfolg haben? Oder ist das herumdoktern 
an Symptomen?

Grüße Martin

[Norbert S. (junky-zs)]

Martin G. schrieb:
> Als nächstes würde ich ja gerne die Anzahl der Zündungen reduzieren.
> Könnte ich da mit der Taktsperre Erfolg haben? Oder ist das herumdoktern
> an Symptomen?
Bin kein Heizungsfachmann, jedoch probieren geht über studieren.
Du kannst die Automatische Taktsperre oder auch die Schaltdifferenz 
einstellen.
Den richtigen Wert kannst Du nur durch Probieren herausfinden und der 
ist ein Kompromiss zwischen Komfort und zugelassener Regelabweichung.
Einstell-Möglichkeiten siehe Bild.

Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
habe heute morgen einen Ausfall meiner HT3-Software. Nach einem Neustart 
läuft zunächst ein paar Minuten alles. Danach stürzt der Prozess 
ht_collgate mit folgenden Fehlermeldungen ab:

30.08.2022 10:10:33 INFO: Starting 'Ccollgate.run()
30.08.2022 10:10:33 INFO: cht_if_worker(); Start ----------------------
30.08.2022 10:10:33 INFO: cht_if_worker();  Loglevel      :INFO
30.08.2022 10:10:33 INFO: cht_if_worker();  Datainput-Mode:SOCKET
30.08.2022 10:10:33 INFO: cht_discode.discoder() --> common 
CRC-detection procedure <--
30.08.2022 10:12:44 CRITICAL: cstore2db.run();Error; on 
ht_if.decoded_data_4_DBs().get()
30.08.2022 10:12:45 CRITICAL: 
ccollgate().run();Error;cstore2db_if-thread terminated.
30.08.2022 10:12:45 CRITICAL: ccollgate().run();Error; terminated

Ich kann mit dem Fehler nichts anfangen. Das System lief bisher 2-3 
Jahre reibungslos.

Gruß Michael

[Norbert S. (junky-zs)]

Michael W. schrieb:
> Ich kann mit dem Fehler nichts anfangen. Das System lief bisher 2-3
> Jahre reibungslos.
Der Prozess wird beendet, weil offensichtlich keine Daten decodiert 
werden konnten.
Details dazu in sw/lib/Ccollgate.py
    # read values from queue, wait if empty or stop if (None, None)
    (nickname, value) = self._ht_if.decoded_data_4_DBs().get()
    # terminate thread if both values are None, else process them
    if (nickname, value) == (None, None):
       self.stop()
       break
Einen Grund kann ich allerdings auch nicht erkennen.

> Das System lief bisher 2-3 Jahre reibungslos.
Ich nehme deshalb an Du nutzt ein älteres Release der Software.
Ich kann Dir da nur empfehlen auf das letztgültige Release: 0.5 des 
github.com repositories zu aktualisieren.
Grund: Falls man linux aktualisiert (update/upgrade) kommen einige 
Änderungen (Namensänderungen serielle Schnittstelle etc.) mit in das 
Betriebssystem die vorher nicht enthalten waren.
Dann werden halt keine Daten mehr von der Schnittstelle empfangen und 
decodiert.
Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
ich nutze zur Zeit die Version 0.4.2
Mittlerweile habe ich herausgefunden, dass der Fehler beim Schreiben in 
die SQLite-DB auftritt. Hatte vor ein paar Monaten die SQLite-DB in 
Betrieb genommen, weil ich einige Datensätze analysieren wollte und 
danach nicht wieder außer Betrieb genommen.
Ich habe jetzt das Speichern in der SQLite-DB unterbunden und dann läuft 
wieder alles wie gewohnt.
Ich werde jetzt nicht mehr weiter suchen und auch nicht mehr updaten, da 
ich das System vermutlich nur noch ein halbes Jahr betreibe.
Vielen Dank für Deine Unterstützung.
Gruß Michael

[Nils (Gast)]

Hi,

ich hab gerade HT3 neu installiert mit der Datenbank auf einem USB 
Stick. Leider generiert er die HTML Bilder nicht, obwohl er Daten 
abspeichert und die RRD Datenbanken modifiziert werden. Jemand eine Idee 
dazu wo ich schauen sollte?

Viele Grüße,
Nils

nils@ht3:~ $ /home/nils/HT3/sw/etc/rrdtool_draw.pl /media/usbstick 
/home/nils 2 1 0 1 1 0 0 1 0
rrdtool info /media/usbstick//HT3/sw/var/databases/HT3_db_rrd_solar.rrd 
failed: could not lock RRD at /usr/share/perl5/RRDTool/OO.pm line 444


24.09.2022 15:13:54 DEBUG:   35_0 ;TSoll:24;Leistung:100;Drehzahl:0
24.09.2022 15:13:54 DEBUG:   35_0 ;TSoll:24;Leistung:100;Drehzahl:0
24.09.2022 15:13:54 DEBUG:   35_0 ;TSoll:21;Leistung:100;Drehzahl:0
24.09.2022 15:13:58 DEBUG:   24_0 
;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 
7:0;Byte28:0
24.09.2022 15:14:02 DEBUG:  259_0 
;Optim.Faktor_WW:16;Optim.Faktor_HG:0;Ertrag letzte 
Std.:0;Tkollektor:31.8;Tspeicher:36.6;pump status:0;Kollektor aus:0; 
Speicher voll:0;>
24.09.2022 15:14:03 DEBUG:   30_0 :HG;T_HydraulicDevice:21.7
24.09.2022 15:14:06 DEBUG:  268_0 ;status_mixer:1
24.09.2022 15:14:07 DEBUG:  268_0 ;status_mixer:2
24.09.2022 15:14:07 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:08(h)
24.09.2022 15:14:07 DEBUG:    2_0 ;Bus-Response Source:08(h) to 
Target:10(h)
 ;1.Busteilnehmer:95;Typ:Heatronic3;Softwarefamilie:18;Softwareversion:8
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:0
 ;Markenzeichen:None
24.09.2022 15:14:08 DEBUG:   24_0 
;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 
7:0;Byte28:0
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:20(h)
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Response Source:20(h) to 
Target:10(h)
 ;1.Busteilnehmer:102;Typ:IPM2;Softwarefamilie:20;Softwareversion:7
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:100
 ;Markenzeichen:Junkers
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:21(h)
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Response Source:21(h) to 
Target:10(h)
 ;1.Busteilnehmer:102;Typ:IPM2;Softwarefamilie:20;Softwareversion:7
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:100
 ;Markenzeichen:Junkers
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Request  Source:10(h) to 
Target:30(h)
24.09.2022 15:14:09 DEBUG:    2_0 ;Bus-Response Source:30(h) to 
Target:10(h)
 ;1.Busteilnehmer:101;Typ:ISM1;Softwarefamilie:23;Softwareversion:3
 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0
 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:101
 ;Markenzeichen:Junkers
24.09.2022 15:14:18 DEBUG:   24_0 
;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 
7:0;Byte28:0
24.09.2022 15:14:18 DEBUG:   22_0 
:HG;heat_enable:On;TargetDevice(dez.):16;MaxT_Vorlauf:61
24.09.2022 15:14:18 DEBUG:   30_0 :HG;T_HydraulicDevice:21.7

[Nils (Gast)]

Bitte meine Frage ignorieren. Nach 1 Stunde sieht man nun aktuelle 
Messwerte und auch die erste Historie. Anscheinend war ich einfach nur 
zu ungeduldig...

Super Software übrigens.

[Nils R. (augur)]

Hi.

Ich würde gerne eine Frage von mir aus 2015 wieder aufgreifen. 
Unterstützung von Fehlermeldungen aus der Therme, dass diese z.B. ein 
Programm aufrufen welches einen Alert verschickt.

Ich habe hier eine wahrscheinlich bekannte Doku gefunden welche für den 
EMS Bus (ähnlich zum EMS2?) die Fehlerprotokolle auslistet, wenn auch 
nicht den Fehlercode. Für eine erste Benachrichtigung einfach den 
Fehlercode rauszusenden wäre direkt auf dem Niveau vom MB-LAN2, mehr 
kann dies auch nicht.

https://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> Unterstützung von Fehlermeldungen aus der Therme, dass diese z.B. ein
> Programm aufrufen welches einen Alert verschickt.
Hallo Nils, ich hoffe Dein System läuft noch und erzeugt keine Fehler 
:-)

Es macht auf jeden Fall Sinn so etwas zu haben.
Den nicht jeder hat oder will ein teuer MBLan2, wenn man Fehlermeldungen 
auch billiger senden kann.
Es ist z.Zeit nur eine Anzeige in den GUI's (HT3_Analyser und 
HT3_Systemstatus) enthalten, gesendet wird an die Schnittstellen noch 
nichts.

Daher habe ich auf github.com ein neues 'issue:21' aufgemacht, in dem 
man Fakten, Wünsche und Bemerkungen reinschmeissen kann.
 https://github.com/norberts1/hometop_HT3/issues/21

Zum Anfang werde ich dort auch eine Mapping-Liste (Errorcode <--> Text) 
reinstellen, damit jeder diese Errorcodes mit seinem Anlagenhandbuch 
vergleichen und eventuell auf github.com 'issue:21' oder hier ergänzen 
kann.

Wie die Software im einzelnen ergänzt/erweitert werden soll muss noch 
festgelegt werden.

Gruß Norbert

[Nils R. (augur)]

Das klingt ja sehr gut. Dann trag ich mal was zusammen. Bei mir tritt 
immer mal wieder das Problem auf, dass zu wenig Druck anliegt. Den 
Messwert dazu hab ich übrigens auf Seite 39 nicht gefunden, ist aber in 
MB-LAN2 vorhanden. Ggf. kann man diesen noch ergänzen. Ticket in Github?

Übrigens hat man mir nun mitgeteilt, dass die EasyControl App nicht mehr 
supportet wird. Leider funktioniert diese nicht im WLAN und stürzt 
direkt ab. Macht das ganze noch sinnloser...muss immer WLAN abschalten, 
um diese benutzen zu können.

[Nils R. (augur)]

Hi,

ich hab mal eine Frage zu meiner Heizung, die ich aufgrund der HT3 Daten 
bekommen habe (echt super nochmal das zu haben... :-)  ).

Hardware:
ZSBE 28-3 A23
FW200
IPM2
ISM1
Speicher SK400-1
3x FKT-1S Solarkollektoren

Anscheinend speichert meine Heizung schön Solarenergie, nutzt diese aber 
nicht oder die Abflachung der Warmwasserkurve ist die Solarnutzung, aber 
irgendwie hätte ich da mehr erwartet...
Zudem steht T-Ist (Raum) immer auf über 30Grad, das ist aber auch im 
MB-LAN2 so, liegt somit eher an der Heizung. Die FW200 ist 
witterungsgeführt, aber der Wert ist schon komisch.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> ...Zudem steht T-Ist (Raum) immer auf über 30Grad
Der Regler FW200 ist bei Dir sicher im Heizgerät eingebaut. Somit misst 
dieser die interne Temperatur des Heizgerätes. Sieht man auch an der 
T-Ist Kurve im Heizkreis, immer dann wenn der Brenner läuft geht diese 
Temperatur schlagartig hoch. Leider wird in den Telegrammen nicht 
mitgeteilt ob der Regler im Heizgerät eingebaut ist.

PS: Jeder Junkers/Bosch Regler Fxyz und auch Cxzy hat einen internen 
Temperatursensor. Somit könnte man diesen auch direkt in einen zu 
kontrollierenden Raum installieren wenn man die Heizungs-Busleitung 
dahin verlegen kann. Dazu gibt es Wandbefestigungen von Junkers/Bosch.
Genau dieses habe ich bei meinem Heizungssystem gemacht und den CW400 in 
meinem Wohnzimmer installiert. Kann dadurch auf eine Fernbedienung 
verzichten und erhalte die korrekte T-Ist Temperatur des Raumes.

> Anscheinend speichert meine Heizung schön Solarenergie, nutzt diese aber
> nicht oder die Abflachung der Warmwasserkurve ist die Solarnutzung, aber
> irgendwie hätte ich da mehr erwartet...
Für die Warmwasserunterstützung reicht die Solar-Temperatur nicht mehr 
aus, da der Warmwasser Soll-Wert ja auf 50Grad steht, die 
Solarspeichertemperatur diesen Wert aber nicht mehr erreicht.
Daher wird diese Solarenergie für die Heizkreise genutzt werden.
Allerdings sieht man dies nicht im Heizgeräte-Bild.
Da ist auch fast immer die Rücklauftemperatur höher als die 
Vorlauftemperatur, nur wenn geheizt oder das Heizgerät in Standby steht 
ist dies nicht so.
Leider sieht man in Deinem rrdtool-plot nicht wann die Heizungs- bzw. 
Heizkreis-Pumpen laufen, weil Du eine ältere Software-Revision nutzt.
Bitte die Software aktualisieren, damit diese Infos zur Verfügung 
stehen.

Angefügte Bilder zeigen mein System und wann die Solarenergie aus dem 
Solarspeicher für den Heizkreis genutzt wird (10:00 bis 12:15 und 16:00 
bis 18:30). Auch sieht man wann die Heizungspumpe läuft 
(Heizungspumpenleistung %).
Die Solartemperatur reicht aber auch hier nicht mehr für die 
WW-Erwärmung.

Gruß Norbert

[Nils R. (augur)]

Moin,

solange die Regelung den Raumwert nicht nutzt. :-) Dann blende ich mal 
die Werte aus. Ich hab die aktuelle Software, aber das rrd angepasst 
damit es für mich etwas übersichtlicher ist. Hab es nun wieder 
eingeblendet.

Anscheinend wird die Solarenergie nicht für die Heizung genutzt, auch 
sinkt die Temperatur des Speichers nicht so schnell wie bei dir. Ich hab 
auch nur einen Warmwasserspeicher und keinen Kombispeicher laut meinen 
Recherchen, den mal wohl bräuchte für beides. Das ist ein Punkte wo ich 
ansetzen möchte zur Optimierung, dass die Solarenergie dann für die 
Heizung genutzt werden kann und nicht einfach im Speicher verpufft. So 
hab ich es jedenfalls verstanden.

Viele Grüße,
Nils

[Nils R. (augur)]

Was hast du für ein Heizungssetup und ist es möglich wann der 
Solarspeicher angezapft wird für Warmwasser oder Heizung in dem 
Solardiagramm zu ergänzen? Der Ertrag ist bei mir etwas zwiespältig, 
wenn dieser eigentlich nicht genutzt wird…

[Nils R. (augur)]

Falls jemand Interesse hat, hab meine Zirkulationspumpe automatisiert 
(war nur eine mechanische Uhr dran) und anstatt einem weiteren IPM es 
mit Relais, ESP32 und einer MQTT Anbindung zusammen mit der HT3-MQTT 
Anbindung gelöst. Mit so einem Standard wie MQTT ist schon cool, was da 
alles geht. https://github.com/NilsRo/HotWaterRecirculatingPump

[Norbert S. (junky-zs)]

Nils R. schrieb:
> solange die Regelung den Raumwert nicht nutzt. :-)
Wird nicht, da am Regler FW200 ja reine Außentemperatur-Führung 
eingestellt ist.
> Was hast du für ein Heizungssetup
Mehr oder weniger die Default-Einstellungen.
- Automatische Taktsperre: Aus
- Taktsperre auf 3 Minuten
- Schaltdifferenz 10 K
- Gebläsenachlaufzeit 30 Sekunden
- Minimale Nennwärmeleistung 36 %

Die Einstellungen Deiner Heizung solltest Du noch mal prüfen bzw. 
optimieren.
Was mir an dem letzten Heizgeräte-Plot 
(https://www.mikrocontroller.net/attachment/572109/Bild_2022-10-01_175742006.png) 
negativ aufgefallen ist:
die Heizungspumpe läuft sehr häufig und dann nur kurz. Diese kurze 
Taktung ist nicht besonders effektiv wenn man einen Brennwert-Kessel 
hat.
Bessere wäre eine längere Laufzeit auf niedrigem Niveau.
Vielleicht kannst Du da noch etwas verbessern.

> ist es möglich wann der Solarspeicher angezapft wird für
> Warmwasser oder Heizung in dem Solardiagramm zu ergänzen?
Die Telegramme auf dem Heizungsbus sind da nicht sehr detailfreudig.
Habe zu Versuchszwecken das Solardiagramm ergänzt um die beiden 
Faktoren:
- Optimierungsfaktor Heizung
- Optimierungsfaktor Warmwasser

Diese Daten werden vom ISM/MS - Modul bereitgestellt.
Diese sind jedoch nur reine Faktoren und keine Temperatur-Werte.
Was,wie und wann die Regler (FW200 etc.) diese Werte nutzen, kann ich 
aus den anderen Telegrammen und Grafen nicht erkennen.
Siehe Beispiel: Solargraf mit der Optimierungsfaktor-Ergänzung.
Wenn dir dies weiterhilft kommt es mit ins nächste SW-Release.

Gruß Norbert

[Mik L. (mik_l)]

Hallo,

meine Junkers-Therme ist leider nicht HT3-fähig (24V Stetigregelung über 
1-2-4 Anschluss), aber der nachträglich installierte 
Raumtemperaturregler FR50 kann beides.

Ist zufällig bekannt, inwiefern und ob der FR 50 z.B. Raumtemperatur und 
Schaltverhalten parallel über den HT3 Anschluss publiziert oder ob da 
der Bus mangels "geschwätziger" Therme automatisch abgeschaltet ist?

Gruß Mike

[Nils R. (augur)]

Moin,

ich möchte zusätzlich zur RRD Datenbank auch die HTML Erzeugung auf 
einen USB-Stick umziehen was soweit auch geklappt hat. Leider bekomme 
ich aber die automatische PNG Erzeugung nicht abgeschaltet, dies macht 
er immer noch im Standardverzeichnis.

Die Erzeugung mit off oder 0 abzuschalten bringt leider nichts...kann 
ich irgendwo schauen welchen Wert er ermittelt hat?

Die neue Erzeugung mache ich mit einem Crontab-Eintrag selber. (*/5   
  /home/nils/HT3/sw/etc/rrdtool_draw.pl /media/usbstick/ 
/media/usbstick/)

    <rrdtool-db>
      <enable>on</enable>
      <step_seconds>60</step_seconds>
      <starttime_utc>1344000000</starttime_utc>
      <!-- autocreate_draw:
        parameter used for auto-creating the png-draws from 
rrdtool-database content.
        (value is defined in 'minutes' (> 0) or disabled (== 0))
         if set to:0 or off autocreating is disabled.
         if set to:> 0      autocreating is enabled
            (enabled only if database is also set 
to:<enable>on</enable>)
      -->
      <autocreate_draw>0</autocreate_draw>
    </rrdtool-db>

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> Die Erzeugung mit off oder 0 abzuschalten bringt leider nichts...
Nach einer Konfigurations-Änderung ist ein Restart des ht_collgate.py 
erforderlich.

Nils R. schrieb:
> Die neue Erzeugung mache ich mit einem Crontab-Eintrag selber.
Kann man machen, jedoch muss man die nötigen Parameter ebenfalls 
übergeben.
Diese werden dynamisch aus den dekodierten Heizungsdaten ermittelt und 
als Darstellungs-Eigenschaften dem perl-script übergeben.
Im Crontab-Eintrag ist dies dann statisch mit einzutragen, sonst kommt 
u.U. eine falsche grafische Darstellung der Heizungsanlagen-Werte.
Parameter sind:
rrdtooldb.create_draw(
 db_path, html_path, --> Pfade auf db und html
 heatercircuits_amount(), --> Anzahl Heizkreise
 controller_type_nr(), --> Controller-Typ (Fxyz, Cxyz)
 GetAllMixerFlags(), --> gemischte /ungemischte Heizkreise (array)
 IsTempSensor_Hydrlic_Switch()), --> hydraulische Anpassung 0/1
 IsSolarAvailable()), --> Solar vorhanden oder nicht 1/0
 IsSecondCollectorValue_SO())) --> zweiter SO-Kollektor da oder nicht 
1/0

Zusätzlich muss der httpd.py-daemon als html-server im gleichen 
Verzeichnis wie unter 'html_path' angegeben vorhanden sein und laufen.

Gruß Norbert

[Nils R. (augur)]

Hab zur Sicherheit den Raspi durchgestartet, aber er ignoriert den 
Parameter weiterhin.

Aufgrund deiner Beschreibung hab ich nun einen Symlink auf den USBStick 
angelegt und lasse die Automatik die Dateien erzeugen, funktioniert 
reibungslos und sicher auch etwas einfacher fürs aktualisieren...danke 
dir.

[Nils R. (augur)]

Moin.

Ich beschäftige mich gerade damit meinen Raspi auf ein 
Readonly-Filesystem umzustellen, da mir immer die SD und der USB Stick 
abrauchen.

Läuft soweit auch und nutze nur MQTT für die zentrale Speicherung. Dabei 
kam mir nun die Frage ob der rsyslog Deamon nicht zum loggen genutzt 
werden könnte. Damit sind die Logs im zentralen Verzeichnis und landen 
bei mir auch auf dem zentralen Syslogserver.

https://gist.github.com/danielkraic/a1657f19bad9c158cbf9532e1ed1503b

Ähnliches gilt übrigens auch für das run Verzeichnis der pids, obwohl 
die Logs persistent zu haben wichtiger wäre. Hattest du dich schonmal 
damit beschäftigt Norbert?

Viele Grüße
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> Dabei kam mir nun die Frage ob der rsyslog Deamon nicht zum loggen genutzt
> werden könnte. Damit sind die Logs im zentralen Verzeichnis und landen
> bei mir auch auf dem zentralen Syslogserver.
Habe mich bisher noch nicht mit 'rsyslog' beschäftigt aber danke für den 
Link zu github.
Da das Logging ohnehin im Projekt vorhanden ist sieht der Aufwand dazu 
erst einmal gering aus. Schaue ich mir an.
Allerdings wenn alles zentral auf dem syslog Server gespeichert wird und 
das Format (Payload) nicht standardisiert ist, sehe ich viel Kraut und 
Rüben in den syslogfiles, den man wieder mit grep oder anderen Tools 
(SigNoz etc.) wieder für das jeweilige 
Server/Projekt/Prozess/Applikation sortieren muss.
Das Logging-Format in meinem Projekt (im Debug-Modus) ist mit 
';'-Trennern aufgebaut und kann damit DIREKT als csv-file in Excel bzw. 
LibreOffice ausgewertet werden.

> Ähnliches gilt übrigens auch für das run Verzeichnis der pids.
Nach Anpassung der systemd startscripte ist dieses Verzeichnis ohnehin 
nicht mehr nötig.

Gruß Norbert

[Jürgen (jl2)]

Hallo Norbert,

erst einmal vielen Dank für Deine bisherige Arbeit + Mühe die Du in 
dieses Projekt investiert hast. Danke dessen konnte ich seit 2017 ohne 
Probleme die Daten meiner Heizung anzeigen und über MQTT auch steuern. 
Mit Erweiterung der Anlage um Solar wurde nun die FW100 Regelung gegen 
eine CW400 + MS200 ausgetauscht. Da ich einen 2. Pufferspeicher mit 3 
Wege Ventil im Ladekreis habe, wollte ich Fragen ob die Daten des 2. 
Pufferspeicher ebenfalls angezeigt werden könnten ?
In der CW400 werden die Daten des 2. Pufferspeicher + Ventilstellung 
anzeigt.
Werden diese Daten aktuell nicht dekodiert oder muß die Konfiguration 
angepasst werden ?

Gruß,
Jürgen

[Norbert S. (junky-zs)]

Jürgen schrieb:
> Da ich einen 2. Pufferspeicher mit 3
> Wege Ventil im Ladekreis habe, wollte ich Fragen ob die Daten des 2.
> Pufferspeicher ebenfalls angezeigt werden könnten ?
Die Daten werden mit dem rrdtool als zweite Solar Grafik angezeigt. Dies 
wird automatisch erzeugt sobald die zugehörigen Telegramme erkannt 
werden.
Diese Daten werden auch mit MQTT ausgegeben.
Allerdings habe ich selber keinen 2. Solarspeicher und 'nur' das MS100 
Modul mit dem CW400. Deshalb habe ich nicht alle Informationen über die 
Telegramme und Inhalte.

Du kannst mir aber Deine Anlagendaten in ein Binarfile mitprotokollieren 
und hier veröffentlichen. Ich kann dann die Auswertung verbessern.
Dazu folgenden Aktion auf dem RPi starten:

 
cd ~/HT3/sw
./ht_binlogclient.py irgendeinName1.log

Das/die Logfiles sollten nicht zu groß werden (ca. 1Std.) damit die 
Auswertung besser/schneller geht.
Wichtig ist dabei auch die Anlage zu beobachten und Aktionen (z.B. 
Ladepumpe an/aus, 3Wege-Ventil Veränderung etc.) zeitlich zu erfassen 
und den Logfiles zuzuordnen.
Ich weiß allerdings nicht wie man solche Aktionen für den 2. 
Solarspeicher erzwingen kann. Da kennst Du dich besser aus.

Gruß Norbert

[Jürgen (jl2)]

Hallo Norbert,

entsprechend den anderen Beiträgen hier hatte ich mit der Frage nach den 
bin-logfites schon gerechnet und mal 1 Stunde zum Test mitlaufen lassen.
Ich mache das heute Abend nochmals und notiere mit dabei die Zeitpunkte 
der Ventil Umschaltung ( lässt sich mit der Diagnose Funktion am CW400 
steuern )

Gruß,
Jürgen

[Norbert S. (junky-zs)]

Jürgen schrieb:
> entsprechend den anderen Beiträgen hier hatte ich mit der Frage nach den
> bin-logfites schon gerechnet und mal 1 Stunde zum Test mitlaufen lassen.
Danke für das Logfile.
Bei der ersten Auswertung habe ich in meinem Analyser Fehlercodes Deiner 
Anlage angezeigt bekommen.
Displaycode: A11
Causecode: 3061
Laut meinen Unterlagen bedeutet dies:
"Keine Kommunikation mit Mischermodul für Heizkreis1"
Vorgeschlagene Aktionen:
- Konfiguration prüfen (Adresseinstellung am Modul).
- Mit der gewählten Einstellung ist ein Mischermodul erforderlich.

Offensichtlich ist irgend eine Einstellung Deines Systems noch zu 
korrigieren.

Gruß Norbert

[Jürgen (jl2)]

Norbert S. schrieb:
> Offensichtlich ist irgend eine Einstellung Deines Systems noch zu
> korrigieren
Die Fehlermeldungen hatte ich provoziert da das MM200 zu diesem 
Zeitpunkt stromlos war. Ich hatte den Außenfühler abgebaut, das hat die 
Regelung in eine Art "Notlauf" versetzt und beide Heizungspumpen laufen 
lassen .... Ist aber jetzt beseitigt da die Fassade an dieser Stelle 
fertig ist und der Fühler wieder dran ..
Ich habe die Temperatur des 2.Speicher mal beobachtet und jeweils ein 
kurzes log generiert. Wenn ich nicht falsch liege wird die Temperatur 
mit Telegramm 938_0 übertragen. In den 3 Logs habe ich versucht 
folgendes einzufangen:
 - 21:12:05 Wechsel von 63,1 nach 63,0 ºC
 - 21:18:10 Wechsel von 63,0 nach 62,9 ºC
 - 21:23:16 Wechsel von 62,9 nach 62,9 ºC
des Temperatur Fühler im Solar Speicher 2 unten.

In den beiden anderen Logs habe ich versucht
 - 21:27:19 Umschaltung des Ventil nach SP2
 - 21:29:20 Umschaltung des Ventil nach SP1
einzufangen.
Vermute mal das wird mit Telegramm 986_5 übertragen.
Hoffe das hilft erst einmal ...

Gruß,
Jürgen

[Norbert S. (junky-zs)]

Jürgen schrieb:
> Ich habe die Temperatur des 2.Speicher mal beobachtet und jeweils ein
> kurzes log generiert. Wenn ich nicht falsch liege wird die Temperatur
> mit Telegramm 938_0 übertragen.
Wird mit Telegramm 866_0_0 übertragen (siehe LibOfficeCal-Datei im 
tar-file).
Habe die Werte/Bytes kommentiert und die Solar Temperatur-Sensornamen 
(TSxy) hinzugefügt.

> Umschaltung des Ventil nach SP1
> Vermute mal das wird mit Telegramm 986_5 übertragen.
Ja, sieht so aus. Wert ist:0 bei SP1 und (64)hex->100 bei SP2.

Bitte kontrollierte mal die Anschlüsse im MS200 oder poste ein Foto. 
Daraus könnte ich die SolarOption Deines System extrahieren, mit den 
Infos der Telegramme vergleichen und die Temperatur-Sensoren zuordnen.

Entnehmen kann ich aus den Telegrammen z.Zeit:
 Solaroption: BDI
 ist:
 B := Umschaltung 2.Speicher mit Umschaltventil
 D := Heizungsunterstützung Speicher2
 I := Umladesystem bei Speicher-Reihenschaltung
Ob dies so stimmt wäre zu klären.

Die Projekt-Software ist noch nicht für die vielen Solar-Konfigurationen 
eines MS200 ausgelegt.
Es wird zwar z.Zeit eine 2. Solargrafik mit dem rrdtool angezeigt, aber 
nur wenn ein zweiter Solar-Kollektor mit Sensor TS7 vorhanden ist.
Dies ist aber in Deinem System nicht vorhanden.

Die Dekodierung der Solar-Telegramme für die Cxyz-Regler muss ich 
erweitern.
Deine Log-Files sind da Gold wert :-)
Über die Darstellung als rrdtool-Grafik muss ich mir noch Gedanken 
machen.
Auf jeden Fall kommen die zusätzlichen Infos auf der MQTT-Schnittstelle 
raus.

Bitte poste auch die Systemkonfiguration, es sind ein MM200 und MS200 
vorhanden mit einem ungemischten und einem gemischten Heizkreis laut 
Analyser.
Ob dies richtig ist kannst nur Du beurteilen.
Das Bild:
 Solar_Option_D_Sp2.png
zeigt die vermutlich bei Dir vorhandene Solar-Konfiguration.

Ich habe zusätzlich im github Projekt-Verzeichnis ein neues Issue:28 
angelegt.
Siehe URL:https://github.com/norberts1/hometop_HT3/issues/28
Kommentare, Logfiles etc. können auch da abgelegt werden.

Gruß Norbert

[Jürgen (jl2)]

Hallo Norbert,

ich nutze aktuell die Option 1ABJ und genau so angeschlossen wie im 
angefügten Bild ersichtlich. Zur Verwirrung trägt offensichtlich bei das 
mit dieser Option der Fühler TS11 (unten SP3) am Anschluss TS8 des MS200 
sowie TS10 (oben SP1) am TS7 des MS200 angeschlossen wird. Die Option K 
und P nutze ich nicht.
Somit werden:
 - TS1, TS2, TS5 mit VS2 für die Solar Ladung,
 - TS3, TS4 mit VS1 für die Heizungsunterstützung,
 - TS10, TS11 und PS7 für die Umladung
genutzt. Das sollte auch so in den logs so zu sehen sein.

Das der Wert des TS5 im Telegram 866_0_0 Byte22+23 steht kann ich so 
bestätigen. Hatte den Ananlyzer laufen als die Anzeige im CW400 für Sp2 
von 80,0 auf 79,9 Grad gefallen ist.
Siehe Bild 866_0_0: Byte 22/23 = hex 031f, ist dez 799 und geteilt durch 
10 = 79,9 Grad.

Gruß,
Jürgen

[Markus J. (mjotter)]

Hallo,

kann man die Uhrzeit synchronisieren?
Also die Uhr/Datum der Heizung mit dem RPI einstellen?

[Norbert S. (junky-zs)]

Markus J. schrieb:
> kann man die Uhrzeit synchronisieren?
> Also die Uhr/Datum der Heizung mit dem RPI einstellen?
Dies funktioniert natürlich nur mit den aktiven Adaptern 
(ht_pitiny/ht_piduino), ist aber z.Zeit nicht in der Software enthalten.

Das Einstellen der Uhrzeit mit EMS Bus-Telegrammen teste ich alsbald.

Eine Synchronisierung der Uhrzeit könnte mit der lokal auf dem RPi 
vorhandenen Zeit erfolgen, die dann mit ntp synchronisiert ist.
Eine manuell eingegebene Zeit halte ich für die Synchronisation 
ungeeignet.
Die kann man dann ja auch am Systemregler (Fxzy / Cxyz) eingeben.

Gruß Norbert

[Markus J. (mjotter)]

Hi Norbert,

ich habe die aktuelle Version neu augesetzt. Incl Debian 12 (bookworm)
Mit MQTT eingeschaltet war die Fehlermeldung, das die Config-Datei nicht 
passt. Damit konnte ich nichts anfangen.

Habe den Fehler gefunden: (für die falsche Fehlermeldung)

Zeile 987 ( 
https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/sw/lib/Ccollgate.py#L987
) läuft auf Fehler.
Daher wird Zeile 988 nicht ausgeführt.
Und die Fehlermeldung in Zeile 995 ist falsch
https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/sw/lib/Ccollgate.py#L995

Grund war, das ich kein paho-mqtt verfügbar hatte.
mit
 apt install python3-paho-mqtt
lief es dann.

Keine Ahnung wieso  ( sudo pip3 install paho-mqtt;)
https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/.mqtt_setup.sh#L69
nicht ausgereicht hat.

[Norbert S. (junky-zs)]

Markus J. schrieb:
> ich habe die aktuelle Version neu aufgesetzt. Incl Debian 12 (bookworm)
> Mit MQTT eingeschaltet war die Fehlermeldung, das die Config-Datei nicht
> passt...

Danke für die Fehlersuche und die Lösung.

Ursache ist sicher nicht Debian 12 sondern wahrscheinlich die Verwendung 
von pip3 im Installation-Script.
Habe dazu im Projekt einen neuen issue:29 aufgemacht und Details 
hinzugefügt.
Siehe:
 https://github.com/norberts1/hometop_HT3/issues/29
Bearbeitung und Korrektur erfolgt alsbald.

Gruß Norbert

[Norbert S. (junky-zs)]

Norbert S. schrieb:
> Bearbeitung und Korrektur erfolgt alsbald.
Habe ein neues Release: 0.7.2 erzeugt.
Das Tool: pip3 wird nicht mehr für die Installation verwendet und das 
Modul: Ccollgate.py enthält verbesserte Fehlermelde-Ausgaben.

Projektfiles siehe:
 https://github.com/norberts1/hometop_HT3/

Gruß Norbert