Forum: Projekte & Code Heizungs-Datenerfassung (HT3)


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Norbert S. (junky-zs)


Lesenswert?

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

von Andreas W. (urbansunited)


Lesenswert?

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

von Andreas Wülbern (Gast)


Lesenswert?

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

von Norbert S. (junky-zs)


Lesenswert?

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

von Mario R. (upd8r)


Angehängte Dateien:

Lesenswert?

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.

von Andreas W. (urbansunited)


Lesenswert?

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

von Mario R. (upd8r)


Angehängte Dateien:

Lesenswert?

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.

von Bernd B. (bernd_b736)


Lesenswert?

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'

von Bernd B. (bernd_b736)


Lesenswert?

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

von Mario R. (upd8r)


Lesenswert?

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

von Bernd B. (bernd_b736)


Lesenswert?

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

von Norbert S. (junky-zs)


Lesenswert?

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

von Bernd B. (bernd_b736)


Lesenswert?

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.

von Norbert S. (junky-zs)


Lesenswert?

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

: Bearbeitet durch User
von Bernd B. (bernd_b736)


Lesenswert?

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

von Norbert S. (junky-zs)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von _rooky_ (Gast)



Lesenswert?

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

von Norbert S. (junky-zs)


Lesenswert?

_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

von _rooky_ (Gast)


Angehängte Dateien:

Lesenswert?

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

von _rooky_ (Gast)


Angehängte Dateien:

Lesenswert?

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

von Norbert S. (junky-zs)


Lesenswert?

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

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

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

von Norbert S. (junky-zs)


Angehängte Dateien:

Lesenswert?

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.
1
# 2021-02-12: 0x41 added in deviceaddress_white_list[]
2
deviceaddress_white_list = [
3
     0x08, 0x0a, 0x0b, 0x0c, 0x0d, 0x10, 0x18, 0x19, 0x1a,
4
     0x20, 0x21, 0x22, 0x23, 0x28, 0x29,
5
     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

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

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

von Norbert S. (junky-zs)


Lesenswert?

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:
1
C1 00 14 00 09 00 89 00 15 00 09 00 89 00 09 00 89 00 ...
2
PA Br DP Br DP Br PA Br DP Br DP Br PA Br DP Br PA Br ...
3
PA:= Polling-Antwort des angesprochenen Moduls (hier immer keine Daten)
4
DP:= DevicePolling von Steuerelektronik
5
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

: Bearbeitet durch User
von micha (Gast)


Lesenswert?

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

von Norbert S. (junky-zs)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Micha (Gast)


Lesenswert?

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!

von Norbert S. (junky-zs)


Lesenswert?

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

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.