eBus Schaltung Rpi in Betrieb nehmen!

[Oppilibee]

Beim eBus darf man grundsätzlich immer nur Plus mit Plus und Minus mit Minus verbinden.
Alle hier beschriebenen Schaltungen, also auch der RPI Print haben am Bus-Eingang einen Brückengleichrichter, der die richtige Polung automatisch herstellt, egal wie man den Bus anschließt.
Das mag für andere Produkte aber durchaus nicht der Fall sein.

Danke Dir! Es ist also völlig egal was die Gegenseite macht, mit den Adaptern aus dem Forum ist eine Verpolung ausgeschlossen

[Sandmanyz]

Habe nun alles am Laufen. War, wie zu erwarten ein Konfigurationsproblem meinerseits (im ioBroker). Werte auslesen klappt und sie werden auch aktualisiert. Danke an alle Beteiligten!

Ich habe noch ein Problem mit dem Schreiben (SetMode) und habe dazu auch einige Beiträge, u.a. bei Github, gelesen.Zum Beispiel diesem hier: https://github.com/john30/ebusd/issues/179. Leider besitzt mein Gehirn gerade nicht die Fähigkeit die ganzen Zusammenhänge zu verstehen .

Meine Vaillant Heizung (inkl. VR 700) hat Sonderbetriebsarten welche alle mit "SetMode auto;30;-;-;0;0;0;0;0;0" aktiviert oder deaktiviert werden. So wird bspw. Stoßlüften mit "auto;0.0;-;-;1;0;0;0;0;0" aktiviert und mit "SetMode auto;30;-;-;0;0;0;0;0;0" deaktiviert. Dies konnte ich mit "listen" sehen.

Code Auswählen Erweitern


ebusctl read -v -c bai SetMode

bai SetMode hcmode=auto;flowtempdesired=25.0;hwctempdesired=-;hwcflowtempdesired=-;disablehc=0;disablehwctapping=0;disablehwcload=0;remoteControlHcPump=0;releaseBackup=0;releaseCooling=0


Dem Github Beitrag konnte ich nun entnehmen, dass der Wert nicht schreibbar ist weil es in der Datei "hcmode.inc" so definiert ist. Wenn ich jedoch das "u" am Anfang entferne, sollte es funktionieren. Vermutlich werden die gesetzten Werte dann vom VR 700 wieder überschrieben. Habe ich das bis hierher richtig verstanden?

uw,,SetMode,Betriebsart,,,,00,,,hcmode,,,,flowtempdesired,,temp1,,,,hwctempdesired,,temp1,,,,hwcflowtempdesired,,temp0,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2,,,,

Jetzt nicht böse werden wenn ich daneben liege...
Im Normalfall bezieht der ebusd seine Konfigurationsdateien automatisch (ab Version 3.2). Sofern ich die Dateien lokal liegen haben bzw. anpassen möchte (um bspw. das besagte "u" zu entfernen), muss ich in der Datei ebuds den Pfad festlegen "--configpath=/etc/ebusd". Ist das richtig?

Oder gibt es evtl. andere Möglichkeiten die Sonderbetriebsarten zu aktivieren?

[john30]

Habe nun alles am Laufen. War, wie zu erwarten ein Konfigurationsproblem meinerseits (im ioBroker). Werte auslesen klappt und sie werden auch aktualisiert. Danke an alle Beteiligten!

Ich habe noch ein Problem mit dem Schreiben (SetMode) und habe dazu auch einige Beiträge, u.a. bei Github, gelesen.Zum Beispiel diesem hier: https://github.com/john30/ebusd/issues/179. Leider besitzt mein Gehirn gerade nicht die Fähigkeit die ganzen Zusammenhänge zu verstehen .

Meine Vaillant Heizung (inkl. VR 700) hat Sonderbetriebsarten welche alle mit "SetMode auto;30;-;-;0;0;0;0;0;0" aktiviert oder deaktiviert werden. So wird bspw. Stoßlüften mit "auto;0.0;-;-;1;0;0;0;0;0" aktiviert und mit "SetMode auto;30;-;-;0;0;0;0;0;0" deaktiviert. Dies konnte ich mit "listen" sehen.

Code Auswählen Erweitern


ebusctl read -v -c bai SetMode

bai SetMode hcmode=auto;flowtempdesired=25.0;hwctempdesired=-;hwcflowtempdesired=-;disablehc=0;disablehwctapping=0;disablehwcload=0;remoteControlHcPump=0;releaseBackup=0;releaseCooling=0


Dem Github Beitrag konnte ich nun entnehmen, dass der Wert nicht schreibbar ist weil es in der Datei "hcmode.inc" so definiert ist. Wenn ich jedoch das "u" am Anfang entferne, sollte es funktionieren. Vermutlich werden die gesetzten Werte dann vom VR 700 wieder überschrieben. Habe ich das bis hierher richtig verstanden?

Jetzt nicht böse werden wenn ich daneben liege...
Im Normalfall bezieht der ebusd seine Konfigurationsdateien automatisch (ab Version 3.2). Sofern ich die Dateien lokal liegen haben bzw. anpassen möchte (um bspw. das besagte "u" zu entfernen), muss ich in der Datei ebuds den Pfad festlegen "--configpath=/etc/ebusd". Ist das richtig?

Oder gibt es evtl. andere Möglichkeiten die Sonderbetriebsarten zu aktivieren?

alles richtig soweit, d.h. du musst das config repo clonen, deine Anpassungen machen und ebusd auf die lokale Kopie konfigurieren.

[Sandmanyz]

alles richtig soweit, d.h. du musst das config repo clonen, deine Anpassungen machen und ebusd auf die lokale Kopie konfigurieren.

Ich Danke Dir!

Heute bin ich, wegen zu wenig Arbeitsspeicher, von einem Raspberry 3 auf einen Raspberry 4 umgestiegen. Leider werden auf dem Raspi 4  keine Werte mehr ausgelesen/angezeigt.

Mit "ls -l /dev" wird kein ttyAMA0 mehr angezeigt, "ttyebus" ist aufgeführt. lsmod zeigt ebenfalls "ttyebus | 16384 | 1".

Auszug aus dem syslog:

Code Auswählen Erweitern


systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems...
.
.
.
kernel: [    1.974179] ttyebus: loading out-of-tree module taints kernel.
kernel: [    1.975199] ttyebus: Found RASPI model 4
kernel: [    1.975568] ttyebus: Successfully requested IRQ 34


Code Auswählen Erweitern


ebusctl i

version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd


Was kann ich tun damit's beim Raspi 4 genauso wie beim Raspi 3 funktioniert?

[chons]

Was kann ich tun damit's beim Raspi 4 genauso wie beim Raspi 3 funktioniert?

Hast du dich an die Anleitung für RPI4 gehalten?
Poste bitte deine

Code Auswählen Erweitern

/boot/config.txt

[Sandmanyz]

Ich bin ganz ehrlich, ich habe das fett geschriebene "Raspberry 4" übersehen . Ich danke dir für den Hinweis, es läuft nun 

Code Auswählen Erweitern


On Raspberry Pi 4 verify that file /boot/config.txt does NOT contain a line "enable_uart=0". If the line exists remove or comment (#) this line.


[fisch3009]

Hallo,
ich bin nun auch dazu gekommen meinen eBus Adapter für Raspberry v2.2 in Betrieb zu nehmen. (Raspberry Pi 1B)
Leider bisher noch nicht so erfolgreich.
Angeschlossen ist er an eine Vaillant Ecotec.
Im Ebusd Log steht:

Code Auswählen Erweitern

2020-06-06 17:40:49.034 [bus error] signal lost
2020-06-06 17:40:49.150 [bus notice] signal acquired
2020-06-06 17:40:51.014 [bus error] signal lost
2020-06-06 17:40:51.172 [bus notice] signal acquired

ebusctl i sagt:

Code Auswählen Erweitern

version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
signal: acquired
symbol rate: 0
max symbol rate: 42
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd

Die LED1 ist nur ab und zu kurz am blinken.

Wenn ich den Raspberry neustarte und den ebusd noch nicht gestartet habe blinkt die LED1 die ganze Zeit sehr schnell (so als wäre viel auf dem Bus los). Sobald der ebusd gestartet wird (starte ich noch von Hand) kommt wieder das ab und zu blinken.
Mache ich da irgendwas grundsätzlich falsch?
Nachdem ich jetzt an der Heizung (die hat eine zusätzliche Calormatic 470 Steuerung) etwas mache, fängt die LED1 wieder schnell an zu blinken und jetzt tauchen auch plötzlich etwas sinnvollere? Einträge im ebusd.log auf:

Code Auswählen Erweitern


2020-06-06 17:53:43.881 [main error] scan config 08: ERR: wrong symbol received
2020-06-06 17:53:45.903 [main error] scan config 15: ERR: wrong symbol received
2020-06-06 17:53:49.982 [update notice] received unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2020-06-06 17:53:50.250 [update notice] received unknown MS cmd: 1008b5110101 / 095458f00eff800000ff
2020-06-06 17:53:50.509 [update notice] received unknown MS cmd: 1008b5110102 / 06033c96468c6e
2020-06-06 17:53:54.012 [update notice] received unknown MS cmd: 1008b5110101 / 095458f00eff800000ff
2020-06-06 17:53:56.013 [update notice] received unknown MS cmd: 1008b5040100 / 0a0357531806060620200f
2020-06-06 17:53:57.919 [main error] scan config 08: ERR: wrong symbol received
2020-06-06 17:53:59.977 [update notice] received unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2020-06-06 17:53:59.995 [main error] scan config 15: ERR: wrong symbol received
2020-06-06 17:54:03.991 [update notice] received unknown MS cmd: 1008b5110101 / 095458200fff800000ff
2020-06-06 17:54:05.963 [update notice] received unknown MS cmd: 1008b5100305ff01 / 0101

ebusctl i sagt seitdem:

Code Auswählen Erweitern

version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
signal: no signal
reconnects: 1
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd

Nach kurzer Zeit (ich schätze mal, wenn die Calormatic in Standby geht. Lande ich wieder bei obigem Wechsel zwischen "Signal lost" und "Signal acquired".
Wie kann ich weiter vorgehen?

Edit:
Mittlerweile habe ich noch folgende Einträge im ebusd-Log gefunden

Code Auswählen Erweitern


2020-06-08 04:59:13.451 [update notice] received unknown BC cmd: 10feb516080013590508060120
2020-06-08 04:59:13.668 [update notice] received unknown BC cmd: 10feb5160304e00e
2020-06-08 04:59:22.259 [main error] scan config 08: ERR: arbitration lost
2020-06-08 04:59:28.897 [main error] scan config 15: ERR: arbitration lost
2020-06-08 04:59:43.810 [main error] scan config 08: ERR: arbitration lost
2020-06-08 04:59:46.732 [main error] scan config 15: ERR: arbitration lost


[Reinhart]

so wie du das schilderst, scheint die Hardware in Ordnung zu sein, denn wenn der eBus am Konverter hängt funktioniert noch alles (blinken)!
Die Probleme beginnen sobald du den Dämon startest.

Ich glaube eher, das der Fehler in der Software liegt. Hast du den schon einmal nachgesehen ob der ttyebus Treiber auch wirklich ordentlich installiert ist?

Code Auswählen Erweitern

ls -l /dev
hier muss der ttyebus Treiber sichtbar sein, und der AMA0 verschwunden!
Checke das bitte nochmals und schau eventuell im Syslog ( var/log/syslog ) ob da Ungereimtheiten betreffend ttyebus auftauchen.

Und poste bitte einmal deine Config ( etc/default/ebusd ).

LG

[galileo]

Das device heißt "ttyebus" und nicht ttyEBUS.

[Reinhart]

Hallo,

möchte ebusd mit einem symbolischen link an "ttyEBUS" starten, dazu habe ich --device=/dev/ttyEBUS als Option mitgegeben.

Leider findet er das device nicht (log-ebus):

Code Auswählen Erweitern

2020-06-11 13:29:10.357 [bus error] unable to open /dev/ttyEBUS: ERR: element not found

ttyEBUS ist aber unter /dev gelistet und mit Rechten 777 angelegt ...

wie Galileo dir schon geschrieben hat stimmt die Schreibweise nicht, steht das irgendwo so geschrieben, wenn ja dann sage uns wo damit wir das ausbessern können!

[Reinhart]

warum hast du den Link händisch angelegt, das wird doch alles bei Treiberinstallation automatisch durchgeführt?
Hat die Treiberinstallation denn nicht korrekt funktioniert?

Ist hier beschrieben.

LG

[schachti]

Ich habe mir dieses Wochenende endlich mal Zeit genommen, den Adapter, den Reinhart mir bereits im Herbst zugesendet hat, in Betrieb zu nehmen. Nach 2 Tagen Lesen, Suchen und Ausprobieren funktioniert nun alles so, wie ich es mir (zunächst) vorstelle. An dieser Stelle ein riesiges Lob für die super Arbeit, die in Planung, Entwicklung und Bestellabwicklung des Adapters, in die Entwicklung des ebusd, den tollen Support hier im Forum und die ganzen Arbeiten im Hintergrund, die man nicht direkt sieht, geflossen ist! Das, was hier einige Freiwillige in ihrer Freizeit auf die Beine gestellt haben, muss sich auch vor großen kommerziellen Projekten nicht verstecken!

Für die, die nach mir vor den gleichen Problemen stehen sollten, hier ein paar Tipps und Erfahrungen, worüber ich gestolpert bin:
* Die aktuelle Version des ebusd unterstützt laut dem, was ich gelesen habe, einige Geräte out-of-the-box inkl. automatischer Erkennung und Download des passenden .csv. Leider gilt das scheinbar nicht für die Viessmann Vitovent 300-W, ich musste ein passendes .csv manuell aktivieren. Die Dateien von https://github.com/dstrigl/ebusd-config-brink-renovent-excellent-300 haben bei mir nicht funktioniert, dafür das auf der Seite dort ganz unten verlinkte .csv von paddyx von mikrocontroller.net.
* Ich bin über das Problem gestolpert, dass FHEM mir nach jedem Restart des ebusd ein neues MQTT2_DEVICE nach dem Namensschema ebusd_Version_Zeitstempel angelegt hat. Das konnte ich beheben, indem ich in der Datei /etc/default/ebusd den Parameter --mqttclientid=ebusd hinzugefügt habe.
* Das Vorgehen bzgl. der Templates, das im Wiki unter https://wiki.fhem.de/wiki/EBUS-MQTT2 beschrieben ist, hat bei mir nicht so recht geklappt, vielleicht einfach, weil es für mein Gerät kein passendes Template gibt oder schlicht das Namensschema in der .csv nicht passt (evtl. ist ein Namensschema erforderlich, das die von ebusd automatisch heruntergeladenen .csv Dateien erfüllen). Lässt sich aber meiner Erfahrung nach auch gut manuell ohne Template anlegen, ich habe autocreate auf complex gesetzt, dann den ebusd gestartet und bin dann im Bedienteil der Lüftung durch die beiden Info-Menüs gegangen. Dadurch schickt das Bedienteil entsprechende Anfragen über den Bus an die Anlage, der ebusd liest mit und in FHEM werden die Readings passend angelegt. Wenn man Readings für Schreibbefehle haben will, steuert man im Bedienteil einfach die gewünschten Einträge an und stellt sie ein.
* Ich glaube, dass ich das json-Geraffel nicht brauche und habe daher in /etc/default/ebusd den Parameter --mqttjson entfernt, dadurch haben die Readings nicht mehr den störenden Suffix, den sie sonst bekommen.

Erstmal bin ich mit dem Ergebnis sehr zufrieden, Fragen kommen später bestimmt, wenn die eigenen Ansprüche steigen!

[fisch3009]

so wie du das schilderst, scheint die Hardware in Ordnung zu sein, denn wenn der eBus am Konverter hängt funktioniert noch alles (blinken)!
Die Probleme beginnen sobald du den Dämon startest.

Die Probleme sind jetzt anscheinend verschwunden, nachdem ich an der Calormatic 470 (VRC 470) einmal auf die Fachhandwerkerebene gegangen bin, danach kamen plötzlich Daten, sowohl im Log, als auch über Mqtt.
Seitdem kommt zyklisch (1min) die Außentemperatur und Datum und Uhrzeit. Die "restlichen" Daten nur, wenn ich in der Calormatic 470 auf die Fachhandwerkerebene gehe.

Der Vollständigkeit halber

Code Auswählen Erweitern

ls -l /dev/
...
crw-rw-rw- 1 root root    10,  58 Jun  8 05:43 ttyebus
...

ttyama0 ist auch nicht dabei.

Meine Konfiguration:

Code Auswählen Erweitern


pi@raspberrypi:~ $ cat /etc/default/ebusd
# /etc/default/ebusd:
# config file for ebusd service.

# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --latency=10000 --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=192.168.178.23 --mqtttopic=ebusd/%name"
... nur noch auskommentierte Zeilen!


Soweit sieht das für mich also so aus, als wäre die Hardware in Ordnung und Software grundsätzlich auch.

ebusctl info liefert:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
signal: acquired
symbol rate: 32
max symbol rate: 98
reconnects: 11
masters: 3
messages: 211
conditional: 3
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd


Mein Ziel wäre jetzt, die Heizung über MQTT (ich verwende kein FHEM) gezielt in den Sommer bzw. Wintermodus zu bringen, sowie die Heißwasserbereitung zu aktivieren/deaktivieren.
Ich bekomme, sobald ich etwas über die Colormatic ändere auch schon sinnvolle Werte im MQTT angezeigt, die 1. Frage wäre, wie kann ich zyklisch diesen Status auslesen?
Geht das über MQTT und Get?
Z.B. habe ich folgende Mqtt-Topics

Code Auswählen Erweitern

ebusd/Status01
Value:
{
     "0": {"name": "temp1", "value": 57.0},
     "1": {"name": "temp1", "value": 57.0},
     "2": {"name": "temp2", "value": 17.188},
     "3": {"name": "temp1", "value": null},
     "4": {"name": "temp1", "value": 53.5},
     "5": {"name": "pumpstate", "value": "off"}}

und

Code Auswählen Erweitern


ebusd/SetMode
Value:
{
     "hcmode": {"value": "auto"},
     "flowtempdesired": {"value": 0.0},
     "hwctempdesired": {"value": null},
     "hwcflowtempdesired": {"value": null},
     "disablehc": {"value": 1},
     "disablehwctapping": {"value": 0},
     "disablehwcload": {"value": 0},
     "remoteControlHcPump": {"value": 0},
     "releaseBackup": {"value": 0},
     "releaseCooling": {"value": 0}}

Über den letzteren Topic, setzt die Calomatic anscheinend die Betriebsart der Heizung. (momentan im Sommermodus, deshalb disablehc:1, nehme ich an)

[fisch3009]

Ergänzung:
Meine Vermutung ist, dass das Gerät mit dem ich kommuniziere die Therme ist und die Calormatic 470 gar nicht am EBUS hängt, der Regler ist nämlich direkt aufgesteckt auf das Heizungsmainboard und dann wird eine 3 polige Stiftleiste gesteckt. Wenn die Calormatic abgesetzt montiert wird, wird der EBUS über eine andere 2 polige Stiftleiste an die Calormatic angeschlossen.

[Reinhart]

Nein, das passt schon so, ich habe die Calormatic auch direkt in der Therme am vorgesehenen Steckplatz aufgesteckt. Das funktioniert schon so.

Es kommen ja im Normalbetrieb nur Brodcast und das funktioniert ja bei dir. Wenn du mehr benötigst dann frage die Werte (über Timer etc.) einfach ab, dazu gibt es genug Beispiele.

Hier ein Beispiel für einen Timer via MQTT2 mit ein paar Werten:

Code Auswählen Erweitern

define EBUS.MQTT at +*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;;\
set ebusMQTT publish ebusd/430/HwcTempDesired/get;;\
set ebusMQTT publish ebusd/bai/WaterPressure/get;;\
set ebusMQTT publish ebusd/bai/FlowTemp/get;;\
set ebusMQTT publish ebusd/bai/ReturnTemp/get;;\
set ebusMQTT publish ebusd/bai/FanSpeed/get;;\
set ebusMQTT publish ebusd/bai/WPPWMPower/get;;\
set ebusMQTT publish ebusd/bai/Status02/get;;\
set ebusMQTT publish ebusd/bai/HcHours/get;;\
set ebusMQTT publish ebusd/bai/HwcStarts/get
attr EBUS.MQTT group timer
attr EBUS.MQTT room MQTT2_DEVICE

LG