Läuft: Heizung mit eBus-Schnittstelle

[Reinhart]

habe gestern ausgecheckt

Version:

Code Auswählen Erweitern

ebusd 3.4.v3.4-20

LG

[theotherhalf]

War auch meine Idee das parallel zu machen...

Bei dem Versuch die Lib zu installieren kommt folgende Meldung

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo apt install libmosquitto-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libmosquitto1
The following NEW packages will be installed:
  libmosquitto-dev libmosquitto1
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 87.7 kB of archives.
After this operation, 214 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Err:1 http://raspbian.raspberrypi.org/raspbian stretch/main armhf libmosquitto1                                                                                                                                                              armhf 1.4.10-3+deb9u2
  404  Not Found [IP: 93.93.128.193 80]
Err:2 http://raspbian.raspberrypi.org/raspbian stretch/main armhf libmosquitto-d                                                                                                                                                             ev armhf 1.4.10-3+deb9u2
  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/m/mosquitt                                                                                                                                                             o/libmosquitto1_1.4.10-3+deb9u2_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/m/mosquitt                                                                                                                                                             o/libmosquitto-dev_1.4.10-3+deb9u2_armhf.deb  404  Not Found [IP: 93.93.128.193                                                                                                                                                              80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-mis                                                                                                                                                             sing?

Sollte das noch passen?

[theotherhalf]

ist geklärt...
Musste erst mal Stretch aktualisieren....

[theotherhalf]

in meiner ebusd config steht derzeit folgendes:

Code Auswählen Erweitern

EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000"

Ich habe zwei ebus Adapter an einem Raspi, je an einem USB Port.

Die neuen sehen dann so aus?

Code Auswählen Erweitern

EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000 --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.167.178.9 --mqtttopic=ebusd/%circuit/%name --address=01"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000 --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.167.178.9 --mqtttopic=ebusd/%circuit/%name --address=01"

[schneeball]

Hi,

ich bin gestern auf das Thema hier mit dem ebus-Adapter gestossen und finde es sehr interessant! Ich habe schon länger mit dem Gedanken gespielt, meine Vaillant Gastherme "smart" zu machen und das hier scheint genau das zu sein wonach ich gesucht habe!

Im Wiki (des alten 1.x Adapters) steht folgender Disclaimer:

Die Verwendung des EBUS zur Ansteuerung eines Heizungssystems kann dieses bei unsachgemäßer Anwendung beschädigen. Für unmittelbare oder mittelbare Folgen, die sich aus dem Nachbau des Interfaces oder der Verwendung der hier zur Verfügung gestellten Information ergeben, übernimmt der Autor keine Haftung.

Kann jemand sagen was damit gemeint ist und vielleicht ein Beispiel geben?
Ist es möglich über die ebus-Schnittstelle Nachrichten zu verschicken, die meine Gastherme tatsächlich beschädigen könnten?

Sagen wir, ich habe einen perfekt funktionierenden Adapter und schliesse in korrekt an die ebus-Pins der Gastherme an. Was könnte schlimmstenfalls passieren?

Ich bin noch komplett neu auf dem Gebiet, also verzeiht mir meine Unwissenheit (oder tut es nicht, damit kann ich auch leben... ).

LG,

schneeball

[pc1246]

Moin
Und willkommen im Forum. Ich beschreibe mal kurz was passieren koennte.
Deine Hausautomatisierung (fhem, vorzugweise!) schreibt ueber den eBus Adapter wilde Werte auf die Heizung, die im schlimmsten FallDeine Heizung beschaedigen koennten. Hier waere jetzt eine viel zu hohe oder auch zu niedrige Temperatur das wahrscheinlichste Szenario. Inwieweit man aber wirklich die Werte so verstellen kann, das etwas passiert weiss ich nicht. Letztendlich ist man ja nur Teilnehmer auf dem Bus und kann Anhand der passenden CSV die richtigen Werte lesen und schreiben.Eine gewisse Unschaerfe bleibt natuerlich immer, weshalb man hier auch oft Fragen liest, ob man das Schreiben physisch unterbinden kann. Um jetzt nicht bewusst etwas falsch zu machen, sind viele Werte gar nicht von sich aus beschreibbar, und muessen in der CSV erst entsprechend freigegebne werden. (Trotzdem kann natuerlich irgendwelcher Muell auf der Datenleitung etwas anderes bewirken.)
Letztendlich hat sich der Autor des Artikels nur absichern wollen und klargestellt, dass das alles auf eigenen Gefahr geschieht!
Gruss Christoph

[theotherhalf]

Habe eben das Update für den Daemon starten wollen mit

Code Auswählen Erweitern

git clone https://github.com/john30/ebusd.git

Dann bekomme ich als Antwort:

Code Auswählen Erweitern

pi@raspberrypi:~ $ git clone https://github.com/john30/ebusd.git
fatal: destination path 'ebusd' already exists and is not an empty directory.

Könnt ihr mir sagen was hier zu tun ist?
Ich möchte gerne das letzte release mit mqtt Unterstützung über die alte Version installieren.

[schneeball]

Moin
Und willkommen im Forum. Ich beschreibe mal kurz was passieren koennte.
Deine Hausautomatisierung (fhem, vorzugweise!) schreibt ueber den eBus Adapter wilde Werte auf die Heizung, die im schlimmsten FallDeine Heizung beschaedigen koennten. Hier waere jetzt eine viel zu hohe oder auch zu niedrige Temperatur das wahrscheinlichste Szenario. Inwieweit man aber wirklich die Werte so verstellen kann, das etwas passiert weiss ich nicht. Letztendlich ist man ja nur Teilnehmer auf dem Bus und kann Anhand der passenden CSV die richtigen Werte lesen und schreiben.Eine gewisse Unschaerfe bleibt natuerlich immer, weshalb man hier auch oft Fragen liest, ob man das Schreiben physisch unterbinden kann. Um jetzt nicht bewusst etwas falsch zu machen, sind viele Werte gar nicht von sich aus beschreibbar, und muessen in der CSV erst entsprechend freigegebne werden. (Trotzdem kann natuerlich irgendwelcher Muell auf der Datenleitung etwas anderes bewirken.)
Letztendlich hat sich der Autor des Artikels nur absichern wollen und klargestellt, dass das alles auf eigenen Gefahr geschieht!
Gruss Christoph

Hey Christoph,
Danke für die Antwort! War auf jeden Fall schon mal aufschlussreich!
Hunderprozentig sicher kann man natürlich nie sein, aber so eine Schnittstelle wie der eBus muss ja schon von irgendwem getestet und abgenommen werden. Von daher hatte ich auch vermutet, dass man wahrscheinlich nicht allzu viel Schaden darüber anrichten kann. Naja, ich werde mich auf jeden Fall noch ein bisschen weiter in das Thema einlesen. Sehr spannend das ganze!

[theotherhalf]

Bin einen Schritt weiter, jedoch habe ich noch das Problem, das ich nicht beide Instanzen meines ebusd gleichzeitig ans Laufen bekomme. Mit einer Instanz läuft es wie es soll.

Meine beiden Instanzen sind:

Code Auswählen Erweitern

EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000"

Also OPTS1 und OPTS2.

Ich werde nicht ganz schlau aus der Beschreibung in /etc/default/ebusd:

Code Auswählen Erweitern

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

Bedeutet dies, das ich die vorhandene ebusd.service Datei umbenenne in den angegebenen Namen ebusd-2.service?

Und den Inhalt darin ändere?

Code Auswählen Erweitern

type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS

Die Zeile mit Environment startend löschen -> OK
Aber wie muss die Zeile danach aussehen?

[john30]

Bin einen Schritt weiter, jedoch habe ich noch das Problem, das ich nicht beide Instanzen meines ebusd gleichzeitig ans Laufen bekomme. Mit einer Instanz läuft es wie es soll.

Meine beiden Instanzen sind:

Code Auswählen Erweitern

EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000"

Also OPTS1 und OPTS2.

Ich werde nicht ganz schlau aus der Beschreibung in /etc/default/ebusd:

Code Auswählen Erweitern

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

Bedeutet dies, das ich die vorhandene ebusd.service Datei umbenenne in den angegebenen Namen ebusd-2.service?

Und den Inhalt darin ändere?

Code Auswählen Erweitern

type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS

Die Zeile mit Environment startend löschen -> OK
Aber wie muss die Zeile danach aussehen?

genau, auf einem systemd basierten System muss man /usr/lib/systemd/system/ebusd.service "clonen" und dann entsprechend darin direkt die richtigen Optionen an die Zeile mit "ExecStart=..." hinhängen (und "$EBUSD_OPTS" rauswerfen) oder darin "$EBUSD_OPTS" durch das entsprechende aus dem /etc/default/ebusd ersetzen (also bspw. "$EBUSD_OPTS2").

[beaune]

Hallo,

ich interessiere mich auch dafür, meine ecoTEC plus in fhem einzubinden. Mich bewegt aber noch folgende Frage: Aktuell steuere ich die Therme über eine calorMATIC 470f, also über Funk (868 MHz), sehe dort die aktuellen Temperaturwerte, kann Kalendereinträge zu Anwesenheits- /Abwesenheitstagen machen usw. Also Zugriff auf alles, was mich in fhem auch interessieren würde. Natürlich könnte ich jetzt auch ein eBUS-Interface an meinen Raspberry anbauen, aber ist das zwingend nötig? Einen CUL für 868 Mhz hätte ich ja schon...

Hat sich schon mal jemand mit der Frage beschäftigt, ob man die bestehende Funkverbindung in fhem mitnutzen kann? Oder ist das eBUS-Interface die einzige Option?

Gruß
beaune

[metserver1]

Hallo Forum,

ich habe in den letzten Tagen meinen V1.6 Adapter zum Laufen gebracht. Reinhart, Dir nochmals ein Dankeschön für Deine Hilfe. Jetzt geht es bei mir mit den Softwarefragen hier in diesem Thread weiter.

Als Grundlage arbeite ich mit den Weishaupt-Konfigurationsdateien, die das Mitglied J0EK3R zur Verfügung gestellt hat.

Zum Einen gibt es darunter CSV-Dateien, die zwar gesendete Nachrichten erkennen, diese aber, zumindest in meinem Fall, nicht immer richtig dekodieren. In den meisten Fällen liegt das an den verwendeten Datentypen bzw. Templates.

Zum Anderen gibt es Nachrichten, die noch nicht erkannt werden, weil ich eine andere Anlagenkonfiguration habe.

Für den ersten Fall, also um die Telegramme zu entziffern, suche ich nach einer Möglichkeit, ein ebusctl grab result decode für ein anzugebendes Telegramm oder Teile davon aufzurufen. Etwa so:

Code Auswählen Erweitern


ebusctl "fff65000054573b413a5 / 0b002f00000000000000cf00" decode

oder gar

Code Auswählen Erweitern


ebusctl "0b002f00000000000000cf00" decode


Geht das mit ebusctl?
Ich habe ebusctl define und ebusctl decode gesehen. Wenn diese Befehle dazu dienen sollen, dann habe ich nicht verstanden, wie. Sorry.


Zur Definition von Templates steht in der Doku:

[DIVIDER/VALUES]: either a DIVIDER or VALUE=NAME[;VALUE=NAME]*
The divider to apply on the numeric base type or a list of name/value associations separated by semicolon (value either in decimal or starting with "0x" for hex).

DIVIDER wird mit Trenner übersetzt. Deshalb habe ich einen anzugebenden Feldtrenner vermutet. Tatsächlich ist in diesem Feld ein "DIVISOR" anzugeben, der auf den Wert in der zuvor angegebenen Variablen angewendet werden wird.




Bei Abfragen über die Kommandozeile bekomme ich zu einigen Datenelementen diese Fehlermeldungen:
ERR: SYN received, ERR: wrong symbol received und ERR: read timeout

Andere gehen einwandfrei durch. (Info: der daemon läuft gleichzeitig im Hintergrund und füllt die Datenbank)

Code Auswählen Erweitern


jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic7
0;31;109;0;11416799;29;-;25

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic3
ERR: SYN received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic3
ERR: SYN received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r datetime
5.000;14:07:-;28.12.2020

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic1
ERR: SYN received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic7
0;31;109;0;11416799;29;-;25

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic6
0;0;223;145;16;0;0;40448;0;0;0;0

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic5
ERR: SYN received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic4
ERR: wrong symbol received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic4
ERR: read timeout

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic4
ERR: read timeout

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic6
0;0;224;145;16;0;0;40448;0;0;0;0

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic7
0;31;109;0;11416800;29;-;25

jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received




Das Log dazu:

Code Auswählen Erweitern


2020-12-28 14:05:49.666 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:49.866 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:50.066 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:50.265 [bus error] send to 08: ERR: SYN received
2020-12-28 14:05:50.266 [bus error] send message part 0: ERR: SYN received
2020-12-28 14:05:55.354 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:55.509 [bus error] send to 08: ERR: CRC error, retry
2020-12-28 14:05:55.713 [bus error] send to 08: ERR: CRC error, retry
2020-12-28 14:05:55.975 [bus error] send to 08: ERR: SYN received
2020-12-28 14:05:55.976 [bus error] send message part 0: ERR: SYN received
2020-12-28 14:06:00.187 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:00.395 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:00.634 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:00.832 [bus error] send to 08: ERR: SYN received
2020-12-28 14:06:00.832 [bus error] send message part 0: ERR: SYN received
2020-12-28 14:06:06.124 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;49.50;-;-;35.0;-
2020-12-28 14:06:12.542 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;1;1;0;1;Heating;58;48.0;-;40.0;0.0;4;3.270;49
2020-12-28 14:06:14.929 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 0600043028313a
2020-12-28 14:06:25.285 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:25.486 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:25.685 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:25.885 [bus error] send to 08: ERR: SYN received
2020-12-28 14:06:25.885 [bus error] send message part 0: ERR: SYN received


2020-12-28 14:07:13.164 [bus error] send to 08: ERR: wrong symbol received, retry
2020-12-28 14:07:13.332 [bus error] send to 08: ERR: read timeout, retry
2020-12-28 14:07:13.496 [bus error] send to 08: ERR: wrong symbol received, retry
2020-12-28 14:07:13.660 [bus error] send to 08: ERR: read timeout
2020-12-28 14:07:13.660 [bus error] send message part 0: ERR: read timeout


2020-12-28 14:17:56.879 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:17:57.093 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:17:57.292 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:17:57.492 [bus error] send to 08: ERR: SYN received
2020-12-28 14:17:57.492 [bus error] send message part 0: ERR: SYN received



Ich hatte solche Abfragen unter den gleichen Bedingungen schon erfolgreich durchgeführt. Am System wurde zwischenzeitlich nichts verändert.

Danke für Tipps.

Gruß,

Jochen

[chri123]

Hallo,

ich habe eine Vaillant mit:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0311;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

alles neu aufgesetzt.

Ich habe mich über die neuen PrFuels* gefreut.

Leider werden die Werte der PrFuelSum, -SumHc und SumHwc nur 24stündlich aktualisiert.
Ist das so?
Kann man die Anlage ermuntern, stündlich upzudaten?

Und sind das reale physikalische Werte oder nur ge-time-te Zähler?

Gruss
Christoph

[rob uboot]

hallo wieder mal!

eine neue idee wirft leider ein neues kleines problem auf.

meine 08.hmu übertragt über das hcmode.inc file im Status01
(Status01r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,)
die werte Aussentemperatur/WW Temperatur/Speichertemperatur nicht:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl -p 8888 read status01
47.5;40.0;-;-;-;off


das müsste ich wohl adaptieren komme aber mit den werten aus den hex daten nicht klar.
der grab auf der 08 adresse ergibt nur diese paar werte die das system nicht kennt:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl -p 8888 grab result
1008b507010a / 03768207 = 34
1008b5110100 / 09f302ff000000008100 = 1816
3108b507010a / 03708207 = 5
3108b5110100 / 098002ffc80a090081c8 = 10
1008b507020900 / 023802 = 691
1008b50702093f / 02a601 = 18
1008b507020940 / 026801 = 96
1008b507020941 / 026301 = 80
1008b507020942 / 025d01 = 121
1008b507020943 / 025a01 = 673
1008b507020944 / 025d01 = 243
1008b5120204ff / 0101 = 366
1008b513020528 / 0101 = 368


bitte um eure hilfe!
die mit den 02xxxx sind wohl temperatur werte.
aktuell sind es aber minus grade, wo findet man diese?
und wo ist der systemdruck versteckt?   
mit dem decode befehl komme ich leider auch nicht weiter.

[john30]

Hat sich schon mal jemand mit der Frage beschäftigt, ob man die bestehende Funkverbindung in fhem mitnutzen kann? Oder ist das eBUS-Interface die einzige Option?

dazu müsste jemand das Protokoll hacken (viel Spaß dabei  ). Nachdem aber immer eine physische eBUS Leitung da ist, ist die Nutzung dieser viel einfacher