Aufgabenstellung

Meine Luft-Wasser-Wärmepumpe CHA-07 von der Firma Wolf kann mit der Smartset-App der Firma Wolf überwacht werden. Die App nutzt dazu das lokale Netz und verbindet sich mit dem Schnittstellenmodul WOLF Link home (interner Name ism7). Dieses Modul befindet sich in der Inneneinheit der Wärmepumpe. Man erreicht es entweder via WLAN oder via LAN.

Die App bietet einen Überblick über diverse aktuelle Werte sowohl des Heizkreises als auch meines Warmwasserspeichers. Schaltzeiten (Nachtabsenkung, Warmwasserbereitung) können komfortabel eingerichtet werden. Ferner werden einige (wenige) Werte wie genutzte elektrische Energie, erzeugte Wärmeenergie und daraus abgeleitete Arbeitszahlen dargestellt.

Die App bietet keinen Zugriff auf die sog. “Fachmannebene”. Daher kann z.B. die Heizkurve nur direkt am Bedienmodul der Inneneinheit verändert werden.

Gleich im ersten Winter hat unsere CHA bei Außentemperaturen arbeiten müssen, die nur noch 3° über unserer Grenztemperatur lagen. Da war es sehr interessant, die Daten der einzelnen Kenngrößen im Wochenverlauf darzustellen.

Genau das kann die Smartset-App jedoch leider nicht.

{note} Ich sollte darauf hinweisen, daß ich dem Schnittstellenmodul keine Verbindung in das Internet gestattet habe und damit auf mögliche zusätzliche Features des Wolf Portalservers bewußt verzichte. Sollte es Sinn machen, meinem Installateur Zugriff zu ermöglichen, würde ich dies ad hoc konfigurieren.

Für z.B. den gewünschten Wochenverlauf nutze ich die Softwarekomponenten ism7mqtt, mosquitto sowie telegraf und influxdb, die bei mir auf einem älteren Raspberry Pi 400 (headless) laufen. Die eigentliche Darstellung erfolgt auf einem Webbrowser, der via LAN Zugriff auf das Influx-Webinterface hat.

Einschränkungen

Das Wolf Schnittstellenmodul WOLF Link home (ism7) kann nur mit einer Netzwerkverbindung umgehen. D.h. der Versuch, bei laufendem Monitoring via Raspberry Pi die App zu starten, wird scheitern. Umgekehrt gilt das genauso.

Falls das ism7 hängt, muß man sicherstellen, daß alle laufenden Zugriffe beendet werden (App beenden, vmtl. geht das nur durch Beenden des Prozesses sowie ism7mqtt beenden). Danach kann man mittels Browser einen Reboot des Schnittstellenmoduls anstoßen. Die URL ist:

http://wolflink/protect/network.htm

Dabei muß wolflink vmtl. angepasst werden (hostname oder IP). Der User ist admin, das Passwort ist das, welches auch für die App benötigt wird. Dann “Save and reboot” klicken.

Als weitere Einschränkung muß man wohl werten, daß das Schnittstellenmodul schnell überfordert ist. Eigentlich wurde das schon beim allerersten Zugriff via App direkt nach der Inbetriebnahme der Anlage deutlich, da es doch etliche Sekunden dauert, bis die App alle Daten erhalten hat und dann darstellen kann.

Bei der Nutzung von ism7mqtt führt das ggf. zu Instabilitäten. Mehr dazu gleich.

Ich habe das Schnittstellenmodul via LAN angebunden, nutze also kein WLAN. Ferner möchte ich nur Werte abfragen und keine Werte schreiben.

Installation der Softwarekomponenten

Das Schnittstellenmodul wird über den ism7mqtt abgefragt. Dieser sendet die Daten an einen MQTT-Broker, in meinem Fall mosquitto. Ich nutze dann telegraf mit dem input-Plugin mqtt_consumer und dem Output-Plugin influxdb_v2. Alles weitere wird über die Datenbank influxdb erledigt.

Die Installation eines Raspberry Pi’s mit den genannten Komponenten ist im Netz sehr oft beschrieben worden. Daher beschränke ich mich auf einige wenige Hinweise.

mosquitto

Das Paket ist im Standard-Repository und kann daher sofort installiert werden. Zum späteren Testen ist ein MQTT-Client sinnvoll. Ich nutze mosquitto_sub. Dazu muß das Paket mosquitto-clients installiert werden.

Der Broker wird bei Systemanlauf automatisch gestartet.

Influxdb

Ich nutze Influxdb V2. Die Pakete sind nicht in den Standard-Repositories, daher muß das Repository der Firma InfluxData hinzugefügt werden.

Die Datenbank wird gestartet, sobald das Netzwerk online ist.

telegraf

Diese Software wird auch von InfluxData angeboten. Nach erfolgreicher Installation der Datenbank kann telegraf ohne weiteres installiert werden. telegraf bringt Hunderte von Plugins mit - ich brauche aber nur zwei davon. Daher habe ich zwar die initiale Konfiguration mittels der Weboberfläche durchgeführt aber danach die generierte /etc/telegraf/telegraf.conf umkopiert und dann nur noch [global_tags] und [agent] behalten:

root@gogo:/etc/telegraf# ls -l
total 576
-rw-r--r-- 1 root root   5446 Jan  9 15:45 telegraf.conf
-rw-r--r-- 1 root root 577235 Dec  8 20:19 telegraf.conf.sample
drwxr-xr-x 2 root root   4096 Jan  9 15:35 telegraf.d
root@gogo:/etc/telegraf# 

Die Plugins liegen hier:

root@gogo:/etc/telegraf# ls -l telegraf.d
total 8
-rw-r--r-- 1 root root 2814 Jan  9 15:34 inputs.mqtt_consumer.conf
-rw-r--r-- 1 root root 1701 Jan  9 15:32 outputs.influxdb_v2.conf
root@gogo:/etc/telegraf# 

Für das Input-Plugin sind bei mir nur folgende Direktiven relevant:

  servers = ["tcp://127.0.0.1:1883"]
  topics = [
    "Wolf/wolflink/#",
      ]
  data_format = "json"

Für das Output-Plugin:

  urls = ["http://gogo:8086"]
  token = "$INFLUX_TOKEN"
  organization = "Stube"
  bucket = "Stube"

Telegraf wird gestartet, sobald das Netzwerk online ist. Vielleicht wäre es besser, wenn ich den Start nach erfolgtem Start der Influxdb erzwingen würde.

In jedem Fall muß die Datei telegraf.service angepasst werden:

Environment=INFLUX_TOKEN='eJT0Ciewtq8_BVSuhkhhgkjhiMDvLw898V9ALbpRO-F-u24kKugWZLNLqGgrhE4WmS1sW6T6Z-9v5P77yhbQ=='

ism7mqtt

Diese Software ist im GitHub Repository des Entwicklers verfügbar ¹ . Ich habe sie gemäß Anleitung installiert (als root in /opt/ism7mqtt).

Auch sie wird bei Systemanlauf automatisch gestartet. Falls der ism7mqtt crashen sollte, wird er mit den Direktiven

[Service]
Restart=always
RestartSec=5s

schlicht neu gestartet.

Die entscheidende Konfigurationsdatei ist die parameter.json (die wurde vorab gemäß Anleitung mittels ism7config erzeugt). Bei den Tests zeigte sich, daß das Schnittstellenmodul mit der Abfrage durch ism7mqtt auf Basis der generierten parameter.json überlastet war. Das führte u.U. dazu, daß der ism7mqtt abbrach. Leider gab es auch den Fall, daß der ism7mqtt zwar noch lief aber keinerlei Daten mehr vom ism7 erhielt.

Ich habe dann die Datei minimiert. Nun werden nun deutlich weniger Werte abgefragt. Dabei habe ich nicht nur statische Werte wie z.B. Seriennummer oder Bauzustände weggelassen sondern auch dynamische Werte, die in meiner Anlage nicht relevant sind (meine WP kann nicht kühlen).

root@gogo:~# cat /opt/ism7mqtt/parameter.json 
{
  "TcpPort": 9092,
  "Devices": [
    {
      "ReadBusAddress": "0x35",
      "WriteBusAddress": "0x30",
      "DeviceTemplateId": 340000,
      "Parameter": [
        340011
      ]
    },
    {
      "ReadBusAddress": "0x8",
      "WriteBusAddress": "0x3",
      "DeviceTemplateId": 270000,
      "Parameter": [
        270004,
        270005,
        270006,
        270007,
        270008,
        270009,
        270010,
        270025,
        270026,
        270027,
        270028,
        270029,
        270030,
        270036,
        270038,
        270040,
        270041,
        270042,
        270043,
        270046,
        270047,
        270048,
        270049,
        270058,
        270059,
        270060,
        270160,
        270161,
        270162,
        270163,
        270164,
        270165,
        270166,
        270167,
        270168,
        270169,
        270172,
        270173,
        270175,
        270176,
        270177        
      ]
    }
  ]
}
root@gogo:~# 

Um die Last des Wolf Schnittstellenmoduls weiter zu reduzieren, habe ich das Abfrageintervall des ism7mqtt auf 180 sec erhöht (Default 60):

ExecStart=/opt/ism7mqtt/ism7mqtt -i wolflink  -p password --interval=180 -t /opt/ism7mqtt/parameter.json -m localhost

Den Status des Services frage ich so ab:

root@gogo:~# systemctl status ism7mqtt

Hinweis zum Debugging

Sobald der ism7mqtt läuft, kann man einen MQTT-Client starten und beobachten, welche Nachrichten vom Schnittstellenmodul gelesen werden. Hier im eingeschwungenen Zustand:

bav@gogo:~ $ mosquitto_sub -d -t 'Wolf/wolflink/#'
Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending SUBSCRIBE (Mid: 1, Topic: Wolf/wolflink/#, QoS: 0, Options: 0x00)
Client (null) received SUBACK
Subscribed (mid: 1): 0
Client (null) received PUBLISH (d0, q0, r0, m0, 'Wolf/wolflink/CHA_0x8', ... (183 bytes))
{"Kesseltemperatur":41,"Heizkreisdurchfluss":12.8,"Hei\u00DFgastemperatur":55.8,"Sauggastemperatur":8.6,"Ablufttemperatur":6.5,"Heizleistung":3.1,"Aktuelle Sekund\u00E4rleistung":3.1}
Client (null) sending PINGREQ
Client (null) received PINGRESP
Client (null) received PUBLISH (d0, q0, r0, m0, 'Wolf/wolflink/CHA_0x8', ... (150 bytes))
{"Kesseltemperatur":41.1,"Heizkreisdurchfluss":13.2,"Sammlertemperatur":38.8,"Sauggastemperatur":8.8,"Ablufttemperatur":6.6,"Drehzahl Ventilator":365}
Client (null) sending PINGREQ
Client (null) received PINGRESP
Client (null) received PUBLISH (d0, q0, r0, m0, 'Wolf/wolflink/CHA_0x8', ... (149 bytes))
{"Kesseltemperatur":41,"Sammlertemperatur":38.9,"Zulufttemperatur":9.1,"Hei\u00DFgastemperatur":55.9,"Sauggastemperatur":9,"Drehzahl Ventilator":353}
Client (null) sending PINGREQ
Client (null) received PINGRESP
Client (null) received PUBLISH (d0, q0, r0, m0, 'Wolf/wolflink/CHA_0x8', ... (75 bytes))
{"Heizkreisdurchfluss":13.3,"Sauggastemperatur":8.9,"Energiemenge HZ":5061}
Client (null) sending PINGREQ
Client (null) received PINGRESP
Client (null) received PUBLISH (d0, q0, r0, m0, 'Wolf/wolflink/DHK_BM-2_0x35', ... (26 bytes))
{"Vorlauftemperatur":38.9}

Mit

root@gogo:~# journalctl -xeu ism7mqtt

kann man Logs einsehen und so z.B. Tippfehler in der parameter.json aufspüren. Der folgende Fehler

 System.Net.Sockets.SocketException (104): Connection reset by peer

führte zum Abbruch des Prozesses. Anschließend erfolgte wie schon dargestellt ein Neustart. Ursache war leider auch hier ein Fehlverhalten des Wolf Schnittstellenmoduls.

Stand: 14.01.2026