Weishaupt WTC am eBus mit ebusd

[littleyoda]

Hallo rob,

danke, dass hilft mir schon mal ungemein.

Extrem schade, dass die WTC so wichtig Werte liefert.
Vor- und Rücklauf wären für mich interessant gewesen, da ich mal ermitteln wollte, ob unser Haus langfristig für eine Luftwärmepumpe geeignet ist.

Da meine Heizung von 2011 ist, wird meine wohl nicht mehr können, als deine.

Gruß,
Sven

[rob]

Nativ liefert die WTC das zwar nicht, aber über FHEM lässt sich das anderweitig nachrüsten: z.B. 2x 1-Wire Temp-Sensoren (DS18S20) an die Rohre dran. Hab es selber zeitl. noch nicht geschafft, werde das aber noch tun. Und den Gaszähler werde ich wohl ebenfalls noch bestücken müssen

BTW: Der ebus-Adapter wurde extra so gut durchdacht gebaut, dass man dort auch die Sensoren dranhängen kann.

Ja, ist schade, dass der elegantere Weg nicht klappt. Dann halt mit basteln 

VG
rob

[Trony]

Hallo,

ich habe auch eine WTC-15. Bekomme auch Daten von Adapter. Leider nicht sehr viele und meistens 0.
Ich verwende einen Raspi mit ebusd von john30 und den Konfigurationsdateien von J0EK3R.
Ich wollte einmal in die Runde fragen, wie ich die Daten, welche J0EK3R so schön als Screenshot hat, auslesen kann. Mich interessieren eigentlich nur die Daten, welche auch auf seinem Screenshot zu sehen sind, nichts spezielles.
Ich frage über http ab.

Bin für jede Anregung dankbar. Komme seit Tagen einfach nicht weiter.

Michael

[rob]

Hallo Michael.

Welche Screenshots meinst Du genau: die Charts im Github (https://github.com/J0EK3R/ebusd-configuration-weishaupt) ?
Solche kannst Du in FHEM erzeugen, sofern die Werte in ein Log-File geschrieben werden. Im LOG-Device gibt es dann einen Link "Create SVG plot" und von dort geht es recht intuitiv weiter.

Bekomme auch Daten von Adapter. Leider nicht sehr viele und meistens 0.

Solange das so ist, kannst Du die Charts ggf. nicht sinnvoll aufbauen. Dann haut ggf. noch etwas nicht so hin wie es sollte. Readings, sprich Daten, müssten durch die CSV einige kommen.
Wenn der ebusd direkt auf dem Raspi läuft, was sagt "ebusctl i" von der Kommandozeile aus?

Bei mir schaut das so aus:

Code Auswählen Erweitern


version: ebusd 21.2.v21.2
update check: OK
access: *
signal: acquired
symbol rate: 23
max symbol rate: 69
min arbitration micros: 12
max arbitration micros: 15
min symbol latency: 7
max symbol latency: 7
reconnects: 0
masters: 5
messages: 356
conditional: 0
poll: 0
update: 8
address 03: master #11
address 04: slave #25, ebusd
address 07: master #16
address 08: slave #11, scanned "MF=Kromschroeder;ID=W ;SW=1200;HW=0302", loaded "kromschroeder/08..sc.csv"
address 0c: slave #16, scanned "MF=-;ID=??;SW=-;HW=-"
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID=W ;SW=2726;HW=-", loaded "kromschroeder/35..hc1.csv"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=1200;HW=0302", loaded "kromschroeder/f6..sc.csv"
address ff: master #25, ebusd


Welche Readings bekommst Du denn bereits?

VG
rob

[rob]

Vor- und Rücklauf wären für mich interessant gewesen...

Hallo Sven.

Sorry, ich muss mich korrigieren. Zumindest die Vorlaufwerte Ist/Soll habe ich nun identifizieren können. Gibt eine ganze Menge was alles ähnlich heißt und ich hab leider nicht alles auseinander klamüsern können/ verstanden (z.B. gibt es viele Readings mit DHWTemp und alle haben denselben Wert - woran erkennt man, was das ist?  ).

@Michael: Danke Dir für den Denkanstoß. Denn in den Charts steht ja eindeutig Vorlauftemp drin, also muss es die ja geben 

Hab gschwind in den CSV und Readings geprüft und testweise drei SVG erstellt. Mal beobachten, ob ich die richtigen Readings erwischt hab (den Screenshots sehe ich leider nicht, welche Readings bzw. CSV-Werte dahinter stecken).

VG
rob

[Trony]

Hallo Rob,

mir ist schon klar, dass ich für die Auswertung erst einmal die Werte brauche. Das ist ja genau mein Problem. 
Ich verstehe nicht, was ich falsch mache beim Einbinden der csv's. Oder muss ich die meisten Werte aktiv pollen? Wenn ja, wie?
Sorry für diese Anfaengerfragen.

Leider bekomme ich momentan nicht so viele... :

Code Auswählen Erweitern

version: ebusd 21.2.v21.2
update check: OK
signal: acquired
symbol rate: 22
max symbol rate: 142
min arbitration micros: 559
max arbitration micros: 580
min symbol latency: 5
max symbol latency: 7
reconnects: 0
masters: 3
messages: 2
conditional: 0
poll: 0
update: 0
address 30: master #3
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=0306;HW=0301"

Code Auswählen Erweitern


{
"scan.35": {
"messages": {
"": {
"name": "",
"passive": false,
"write": false,
"lastup": 0
}
}
},
"scan.f6": {
"messages": {
"": {
"name": "",
"passive": false,
"write": false,
"lastup": 1636481059,
"zz": 246,
"fields": {
"MF": {
"value": "Kromschroeder"
},
"ID": {
"value": "WWST?"
},
"SW": {
"value": "0306"
},
"HW": {
"value": "0301"
}
}
}
}
},
"global": {
"version": "21.2.v21.2",
"updatecheck": "OK",
"signal": true,
"symbolrate": 22,
"maxsymbolrate": 142,
"minarbitrationmicros": 559,
"maxarbitrationmicros": 580,
"minsymbollatency": 5,
"maxsymbollatency": 7,
"qq": 49,
"reconnects": 0,
"masters": 3,
"messages": 2,
"lastup": 1636481059
}
}


Viele Grüsse

Michael

[rob]

Ah OK, dann hab ich Dein Problem jetzt besser verstanden. Sorry, sollte nicht doof rüber kommen.

Also, es gibt schon einige Werte die man aktiv holen muss. Aber die wichtigsten nicht, die kommen von selber - naja, sollten es 

Schaut so aus, als wäre nur das _template.csv geladen. Da kommt wirklich nix weiter außer Hersteller und manchmal Außentemp.
Wie genau hast Du ebusd am Laufen und wie konkret die CSV eingebunden?

Vielleicht lässt sich da schon etwas finden. Müssen leider detektivisch vorgehen. Bei mir ist es alles via Docker eingebunden. Aber so groß sollten die Unterschiede nicht sein.

[Trony]

Hallo Rob,

ich habe einen Raspi 4 oben bei meiner Heizung. Daran hängt ein USB-ebus-Adapter.

So sieht meine ebusd Konfiguration aus. Im Moment verwende ich eine kurze Version, um mich langsam voranzutasten. Meine ursprüngliche ist auskommentiert.

Code Auswählen Erweitern


# /etc/default/ebusd:
# config file for ebusd service.

# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig=full --configpath=/etc/ebusd/configtest --httpport=8889 --htmlpath=/var/ebusd/html"
#EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 --scanconfig --latency=10000 --receivetimeout=100000 -l /var/log/ebusd.log --configpath=/etc/ebusd/config  --httpport=8889 --htmlpath=/var/ebusd/html --mqtthost=192.168.1.221 --mqtttopic=ebusd/%circuit/%name/%field"
#EBUSD_OPTS="--scanconfig=full -d /dev/ttyUSB0 -p 8888 --httpport=8889 --htmlpath=/var/ebusd/html"
#EBUSD_OPTS="-d 192.168.1.23:8889 --httpport=9092 -l /var/log/ebusd.log --loglevel=error --latency=60000 --scanconfig --mqtthost=localhost --mqttport=1883 --mqttjson --mqttretain --mqttuser=homeassistant --mqttpass=Gr1sul0n386 --mqttversion=3.1.1"




# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"

# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.


Mein configtest Verzeichnis sieht so aus:

[rob]

Es schaut so aus, als wäre es ein Kombi aus zwei Themen. Wenn ich nicht ganz falsch liege, könnte das erste Thema der selbe Stolperstein sein, über den ich auch springen musste: die Ordnerstruktur. Das zweite Thema: selbst wenn, die CSV richtig liegen, könnte dennoch nichts weiter geladen werden, weil die Adressen andere sind: #36 gibt es in den CSV noch nicht. Aber eins nach dem anderen.

Thema1:
- anhand der Herstellerkennung möchte ebusd im passenden Unterordner suchen
- leider sendet Weishaupt Kromschröder, statt Weishaupt --> deshalb braucht man einen Link zum Unterordner weishaupt (wie in Jokers Repo)
- eigentlich sogar nach Sprachschlüssel unterteilt, aber das soll uns jetzt nicht jucken

Versuch bitte mal folgendes:
- Unterordner "weishaupt" in Deinem Verzeichnis /etc/ebusd/configtest anlegen und alle CSV dorthinein verschieben
- einen Symlink "kromschroeder" auf den Folder weishaupt legen
- muss genauso aussehen wie in jokers Repo (https://github.com/J0EK3R/ebusd-configuration-weishaupt); alternativ kannst auch gleich das Repo in Deinen Pfad clonen
- nun aus john30s Repo (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de) noch diese Dateien holen und direkt ablegen unter /etc/ebusd/configtest:
   _templates.csv
   broadcast.csv
   memory.csv

Schaut bei mir so aus:

Code Auswählen Erweitern


-rw-r--r-- 1 dietpi dietpi  1253 Jul 14 19:38 broadcast.csv
lrwxrwxrwx 1 dietpi dietpi     9 Jul 12 11:06 kromschroeder -> weishaupt
-rw-r--r-- 1 dietpi dietpi 35141 Jul 12 11:06 LICENSE
-rw-r--r-- 1 dietpi dietpi   754 Jul 14 19:38 memory.csv
-rw-r--r-- 1 dietpi dietpi  1734 Jul 12 11:06 README.md
-rw-r--r-- 1 dietpi dietpi  1228 Jul 14 19:38 _templates.csv
drwxr-xr-x 4 dietpi dietpi  4096 Aug 22 11:13 weishaupt


Und innerhalb ./weishaupt schauts so aus:

Code Auswählen Erweitern


-rw-r--r-- 1 dietpi dietpi   442 Jul 12 11:06 04..EA.csv
-rw-r--r-- 1 dietpi dietpi   572 Jul 12 11:06 05..EA.csv
-rw-r--r-- 1 dietpi dietpi   230 Jul 12 11:06 08..sc.csv
-rw-r--r-- 1 dietpi dietpi  1435 Jul 12 11:06 1c..hc4.csv
-rw-r--r-- 1 dietpi dietpi  1435 Jul 12 11:06 24..hc8.csv
-rw-r--r-- 1 dietpi dietpi  1970 Jul 12 11:06 35..hc1.csv
-rw-r--r-- 1 dietpi dietpi  1435 Jul 12 11:06 3c..hc5.csv
-rw-r--r-- 1 dietpi dietpi  1367 Jul 12 11:06 51..hc2.csv
-rw-r--r-- 1 dietpi dietpi  1435 Jul 12 11:06 75..hc2.csv
-rw-r--r-- 1 dietpi dietpi  1435 Jul 12 11:06 7c..hc6.csv
drwxr-xr-x 2 dietpi dietpi  4096 Jul 12 11:06 Documentation
-rw-r--r-- 1 dietpi dietpi  1435 Jul 12 11:06 f5..hc3.csv
-rw-r--r-- 1 dietpi dietpi  2822 Jul 12 11:06 f6..sc.csv
-rw-r--r-- 1 dietpi dietpi  1435 Jul 12 11:06 fc..hc7.csv
drwxr-xr-x 2 dietpi dietpi  4096 Jul 12 11:06 FHEM
-rw-r--r-- 1 dietpi dietpi  1774 Jul 12 11:06 hc.expert2.inc
-rw-r--r-- 1 dietpi dietpi  1951 Jul 12 11:06 hc.expert.inc
-rw-r--r-- 1 dietpi dietpi  1575 Jul 12 11:06 hc.processvalues.inc
-rw-r--r-- 1 dietpi dietpi 13515 Aug 16 12:39 hc.timer.inc
-rw-r--r-- 1 dietpi dietpi  1742 Jul 12 11:06 hc.userholiday.inc
-rw-r--r-- 1 dietpi dietpi  1361 Jul 12 11:06 hc.user.inc
-rw-r--r-- 1 dietpi dietpi  1209 Jul 12 11:06 hwc.expert.inc
-rw-r--r-- 1 dietpi dietpi   801 Jul 12 11:06 hwc.processvalues.inc
-rw-r--r-- 1 dietpi dietpi  5049 Aug 16 13:08 hwc.timercc.inc
-rw-r--r-- 1 dietpi dietpi  4958 Aug 16 12:57 hwc.timer.inc
-rw-r--r-- 1 dietpi dietpi   874 Jul 12 11:06 hwc.user.inc
-rw-r--r-- 1 dietpi dietpi  1022 Jul 12 11:06 sc.enduser.inc
-rw-r--r-- 1 dietpi dietpi  9969 Jul 21 15:04 sc.errorhistory.inc
-rw-r--r-- 1 dietpi dietpi  1279 Jul 12 11:06 sc.manufacturer.inc
-rw-r--r-- 1 dietpi dietpi  1631 Jul 12 11:06 sc.processvalues.inc
-rw-r--r-- 1 dietpi dietpi  6345 Jul 12 11:06 sc.statistic.inc
-rw-r--r-- 1 dietpi dietpi  3644 Jul 12 11:06 sc.systemheatcontrol.inc
-rw-r--r-- 1 dietpi dietpi  3804 Aug 22 11:13 _templates.csv


Dann bzgl. Startparameter sehen meine so aus

Code Auswählen Erweitern


-f --scanconfig -d enh:localIP:9999 --latency=20 --accesslevel=* --address=ff --mqttport=1883 --mqttjson --mqtthost=fehmIP --mqtttopic=ebusd/%circuit/%name --mqttchanges --configpath=/etc/ebusd

Unterhalb von /etc/ebusd liegen bei mir also die oben genannten Files/Folder.

Nach einem Restart vom ebusd sollte es mit etwas Glück besser aussehen. Vielleicht kommt sogar schon etwas mehr in Fhem an.
Falls nicht, schauen wir was "ebusctl i" dann sagt und müssten ggf. nach Thema2 weiterforschen.

Ich drück schonmal die Daumen

[Trony]

Hallo Rob!

Wow, das sieht ja vielversprechend aus 
Werde es in den nächsten Tagen ausprobieren und dir Rückmeldung geben.
Erst einmal vielen, vielen Dank für Deine Hilfe!!!!

Michael

[zenlight777]

Hallo,

Wenn ich mir diesen Aufwand ansehe, habe ich den Eindruck, dass es einen einfacheren Weg geben könnte.

Ich habe dieses Forum gefunden.

https://www.plumbersforums.net/threads/nest-opentherm-ebus-interface.120120/

Sie haben erfolgreich ein Nest 3-Thermostat (OpenTherm-basiert) an eine EBUS-Zentralheizung angeschlossen.
Da OpenTherm ein etabliertes Protokoll und Standard ist, enthält es alle Befehle, die Sie zurückentwickeln möchten.
Und alles, was Sie tun müssen, ist einen Hardware-Mapper von OpenTherm an EBUS anzuschließen.

Übersehe ich hier etwas? Oder könnte man stattdessen einfach einen Raspberry Pi zu OpenTherm Adapter entwickeln?
Dann ist kein Reverse-Engineering-Aufwand mehr erforderlich.

Auf der Suche nach einem Kommentar dazu.

Dankeschön!

[rob]

Hi.

Klingt interessant! 
Mit OpenTherm kenne ich mich leider auch nicht aus. Im Prinzip wäre es für diesen Weg auch nötig, dass sich wer mit Ahnung damit auseinander setzt, damit Noobs wie ich davon profitieren können. Also welche Hardware muss wie angeschl. werden, wo kauft man das ran oder was muss gebastelt werden. Welche Software wird benötigt, wie kommt an die Daten und welche Daten/ Befehle sind wie zu interpretieren.

Wenn ich es richtig verstehe, wäre genau dieser Aufwand deutlich geringer und somit progressiver bzgl. konkreter Anlagen. Die Abhängigkeit der User von demjenigen, der sich dann konkret reinvertieft bliebe ggf. gleich.
Gäbe es jemanden, der schon Erfahrung damit hat und dies hier teilen würde, das wäre super. Ich würde da leider bei Null anfangen und kann das schwer einschätzen 

VG
rob

[zenlight777]

Hi.

Klingt interessant! 
Mit OpenTherm kenne ich mich leider auch nicht aus. Im Prinzip wäre es für diesen Weg auch nötig, dass sich wer mit Ahnung damit auseinander setzt, damit Noobs wie ich davon profitieren können. Also welche Hardware muss wie angeschl. werden, wo kauft man das ran oder was muss gebastelt werden. Welche Software wird benötigt, wie kommt an die Daten und welche Daten/ Befehle sind wie zu interpretieren.

Wenn ich es richtig verstehe, wäre genau dieser Aufwand deutlich geringer und somit progressiver bzgl. konkreter Anlagen. Die Abhängigkeit der User von demjenigen, der sich dann konkret reinvertieft bliebe ggf. gleich.
Gäbe es jemanden, der schon Erfahrung damit hat und dies hier teilen würde, das wäre super. Ich würde da leider bei Null anfangen und kann das schwer einschätzen 

VG
rob

Danke rob!

Ich war etwas zu gespannt auf eine Lösung mit OpenTherm und einer vereinfachten Einrichtung.
Was ich aber nicht gesagt habe war, dass man einen zweiten Adapter kaufen müsste, also bleibt vielleicht die ideale Lösung das Reverse Engineering und der USB - EBUS Adapter.
Auch der Vorteil, das Heizsystem möglicherweise zu modulieren und auch auf versteckte / zusätzliche Parameter zuzugreifen. Mit OpenTherm ist dies vielleicht nicht möglich.

Stromdiagramm:
RaspberryPI <-> USB auf EBUS Adapter <-> EBUS Zentralheizung

Alternativdiagramm:
RaspberryPI <-> OpenThermGateway Adapter [1] <-> OpenTherm auf EBUS Adapter [2] <-> EBUS Zentralheizung

[1]
https://www.nodo-shop.nl/en/opentherm-gateway/188-opentherm-gateway.html - http://otgw.tclcode.com/
http://ihormelnyk.com/opentherm_adapter
[2] https://cvdeals.eu/product/0020092426-opentherm-module-advanced-awb/

Auf jeden Fall, für jemanden ohne viel Erfahrung mit EBUS/Debugging des Systems, der nur eine schnellere Lösung möchte, könnte das alternative Diagramm eine Lösung sein. Außerdem würde es OpenTherm verwenden, was ein besserer Standard ist und hoffentlich die Kompatibilität mit jeder Art von Heizsystem ermöglicht.

Ich bin tatsächlich in dieser Situation und würde mich sehr freuen, wenn jemand darauf hinweisen würde, dass es eine einfache Möglichkeit gibt, Raspberry Pi mit Weishaupt-Heizsystemen zu verwenden.
Meine Frau besteht darauf, nur ein nicht angeschlossenes EBUS-Thermostat zu verwenden.
Aber wenn es einfach wäre, würde ich lieber RaspberryPi verwenden.

Vielen Dank!

[Trony]

rob,

bin noch nicht dazu gekommen... Gattin wollte Wohnzimmer neu tapezieren.
Melde mich aber, sobald ich es ausprobiert habe.

Gruss
Michael

[rob]

Kein Thema, nimm Dir die Zeit, die Du halt benötigst