eBUS Adapter 3.0 Inbetriebnahme

[Mitch]

Ich habe am WE nochmal einige Test gemacht.

Um WiFi Probleme auszuschließen habe ich einen Wemos Pro mit externer Antenne benutzt.
WiFi 78% wenn ich den Wemos alleine am Standort betreibe. Sobald der Wemos auf dem ebus steckt, kaum mehr bis gar keinen Wifi Empfang.
Ich gehe mitlerweile von einem defekt des ebus-Board aus.

Wie kann ich das ebus-Board umtauschen?

[Reinhart]

@Swuwe

deine regexp kann hier absolut nicht greifen, weil die für Vaillant Geräte ausgelegt ist und deine nicht gefiltert werden, daher landen die alle im Quelldevice.

Da du nur die beiden Devices "feuerung" und "MM1" hast müsste die regexp wie folgt aussehen. Versuche das mal so. allerdings musst du dann die falsch zugeordneten Einträge löschen, bzw. den eBusd neu starten dann wird ein neuer ebusd_xxx angelegt und du kannst den alten komplett löschen.

Code Auswählen Erweitern

(ebus.)[^/]*/(feuerung|MM1|)/.*:.* "$1"
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"

LG

[Mümmelmann]

Hallo Reinhart,

ich hätte da einmal eine Verständnisfrage zu MQTT und Ebusd, da ich gerade bei einem Problem kleben bleibe.

Wie aus den vergangenen Beiträgen von letzter Woche ersichtlich, läuft bei mir Ebusd als Daemon einwandfrei, auch werden mir alle verfügbaren STATEs via MQTT im IOBroker (ja, ich weiß, du schriebst, das Du IOBroker nicht so gut kennst) regelmäßig vom Ebusd-Daemon im IOBroker MQTT-Server publiziert und angezeigt. Also funktioniert schon mal eine Richtung via MQTT (Daten vom Ebusd -> MQTT-Server).

Nun war ich bischen in Node-Red am basteln gewesen und da fiel mir etwas entscheidenes auf: Wenn ich ein State (z.B. Hc1DayTemp) im MQTT Server ändere, ging ich davon aus, das der Ebusd-Daemon diese Änderung empfängt und die gewünschte Änderung mittels des Adapters an den Ebus weiter gibt und der Wert gändert wird. Dem ist aber nicht so.

Gehe ich Recht in der Annahme, das ich via MQTT alle States vom Ebusd-Daemon zwar empfangen kann, aber die States über Ebusd via MQTT nicht ändern kann? Bliebe mir dann nur der Weg über "ebusctl" mittels "ebusctl write -c 350 Hc1DayTemp 20" mittels "exec" , wobei Du ja expliziet "ebusdctl" nur als Progamm zum testen der korrekten Funktionsweise des Ebusd-Daemons ausgewiesen hattest?

Lg

[Swuwe]

@ Reinhart

Hervorragend, somit kommen die Readings immerhin schonmal direkt im MQTT2_ebusd an. Jetzt habe ich auch verstanden was ich machen muss, wenn ich später noch andere Sachen vom Bus lesen möchte. Eigentlich müsste es noch mehr geben (Mischer kon. Heizung und Mischer Fußbodenheizung im Einsatz) . Aber da suche ich mal selber nach.

Trotzdem wird weiterhin bei jedem Neustart ein neues Device QTT2_ebusd_21.2_xxxxx angelegt. Erwartungsgemäß, oder habe ich da noch einen Fehler zu beheben? Autocreate bleibt ja eigentlich an, oder?

Danke und Grüße

[Reinhart]

Trotzdem wird weiterhin bei jedem Neustart ein neues Device QTT2_ebusd_21.2_xxxxx angelegt. Erwartungsgemäß, oder habe ich da noch einen Fehler zu beheben? Autocreate bleibt ja eigentlich an, oder?

Ja das ist bekannt, dass hier immer ein neues Devices angelegt wird, deshalb sollte da auch nix landen. Autocreate bleibt an, sonst werden neue Daten nicht zugeordnet.
Schön wenn du den Mechanismus verstanden hast und dir jetzt klar ist warum das vorher nicht klappte. Die regexp kannst ja beliebig erweitern und auch noch andere "Gruppen" erfassen. ich bin auch nicht der regexp Spezialist, aber du kannst ja einfach probieren bis du es hast so wie du es dir vorstellst.

LG

[Reinhart]

Gehe ich Recht in der Annahme, das ich via MQTT alle States vom Ebusd-Daemon zwar empfangen kann, aber die States über Ebusd via MQTT nicht ändern kann? Bliebe mir dann nur der Weg über "ebusctl" mittels "ebusctl write -c 350 Hc1DayTemp 20" mittels "exec" , wobei Du ja expliziet "ebusdctl" nur als Progamm zum testen der korrekten Funktionsweise des Ebusd-Daemons ausgewiesen hattest?

MQTT ist ja ein standardisiertes Protokoll, dass keine Point to Point Verbindung ist, sondern mi "publish" (senden)  und "subscribed" (empfangen) kommuniziert. Wenn du jetzt den "state" änderst, wirkt sich das nicht auf MQTT aus. Du musst schon einen Publish Befehl mit der Topic senden, damit du eine Antwort bekommst, bzw. in ein Register vom eBus Device schreiben kannst.
MQTT hat ja nix spezifisches mit eBus zu tun, sondern ist ein Protokoll für Datenübertragung und der eBus Dämon unterstützt dieses.

Beispiel:

Code Auswählen Erweitern

set ebusMQTT publish ebusd/bai/FlowTemp/get
wenn du den "state" des Vorlaufs haben willst, dann musst du einen "publish" durchführen. Das gilt natürlich auch für schreibbare Daten beim eBus. Neuen Wert setzen, daher mit "publish".


LG

[Reinhart]

@Mitch
bevor ich hier alles durchlese, von wem hast du den Adapter seinerzeit bekommen, von John oder von mir?

LG

[john30]

Um WiFi Probleme auszuschließen habe ich einen Wemos Pro mit externer Antenne benutzt.
WiFi 78% wenn ich den Wemos alleine am Standort betreibe. Sobald der Wemos auf dem ebus steckt, kaum mehr bis gar keinen Wifi Empfang.
Ich gehe mitlerweile von einem defekt des ebus-Board aus.

was für eine Stromversorgung nutzt Du und wie hast Du diese angesteckt?

[Mitch]

@Mitch
bevor ich hier alles durchlese, von wem hast du den Adapter seinerzeit bekommen, von John oder von mir?

LG

Kam von John.

[Mitch]

was für eine Stromversorgung nutzt Du und wie hast Du diese angesteckt?

Guter Punkt John. Ich hatte hier auch schon den Adapter in Verdacht. Mittlerweile habe ich drei Stück ausprobiert.
Einen vom iPhone, einen NoName und einen vom Amazon Echo. Kein Unterschied.
Angesteckt immer über den Wemos, ebus Adapter bekommt ja davon dann Strom.

Ich habe jetzt nochmal an meinem Setup gearbeitet und teste gerade (habe einen anderen AP installiert (U6-LR).
Mal sehen, wie es sich jetzt verhält.
Ich werde weiter beobachten und berichten. Im Zweifel würde ich mich über einen Austausch freuen, oder, du schickst mir noch einen zum testen. Wenn es die gleichen Probleme gibt, dann liegt es an mir und meiner Heizung 
Wobei ja der ebus Adapter v1 seit Jahren ohne Probleme lief.

[schneivo]

Hallo nochmal,

ist es eigentlich möglich beim ebusd Docker-Image eine eigene Config per --configpath=PATH zu verwenden? Und wenn ja, bezieht sich der PATH dann auf das Dateisystem des Docker-Containers oder das des Host-Systems?

[john30]

Guter Punkt John. Ich hatte hier auch schon den Adapter in Verdacht. Mittlerweile habe ich drei Stück ausprobiert.
Einen vom iPhone, einen NoName und einen vom Amazon Echo. Kein Unterschied.
Angesteckt immer über den Wemos, ebus Adapter bekommt ja davon dann Strom.

mir ist noch was eingefallen:
kannst Du mal Wemos+eBUS vom Adapter trennen, USB Stromversorgung auf J2 geben und am J4 den Strom zwischen Pin 2 und 3 messen? Der sollte unter 90 mA liegen.
Danach könntest Du den Wemos aufstecken und nochmal die gleiche Messung durchführen (also Wemos via J2 versorgen). Das dürfte insgesamt nicht über 160 mA gehen.

Ach ja: hast Du beim Wemos pro den 0 Ohm auch umgelötet, damit die externe Antenne überhaupt genutzt wird?

[john30]

ist es eigentlich möglich beim ebusd Docker-Image eine eigene Config per --configpath=PATH zu verwenden? Und wenn ja, bezieht sich der PATH dann auf das Dateisystem des Docker-Containers oder das des Host-Systems?

ja klar. Das Filesystem ist immer das innerhalb des Containers. Du kannst aber via Bind Mount einen Pfad vom Host in den Container hängen. Bspw. mit "-v /var/ebusd-config:/etc/ebusd" und dann via "-c /etc/ebusd" nutzen.

[schneivo]

ja klar. Das Filesystem ist immer das innerhalb des Containers. Du kannst aber via Bind Mount einen Pfad vom Host in den Container hängen. Bspw. mit "-v /var/ebusd-config:/etc/ebusd" und dann via "-c /etc/ebusd" nutzen.

Werde ich ausprobieren, danke!

[jutonium]

Vielen, vielen Dank an das eBus-Adapter-Team. Super Arbeit!

Heizung: VCW206/5-5 R5 ("bai00", SW0609, HW5502) + VT 350 ("35000", SW0114, HW7102)
Setup: RPi 4, 8GB mit SSD + RPI-RF-MOD auf HB-RF-USB-2 (wegen der USB3.0 Störstrahlung) + ebus Adapter 3 via Ethernet
Software: Home Assistant + debmatic + ebusd

Platine kam an, Jumper überprüft, einen umgesetzt, an den eBus gehangen und dann kam die Lernkurve unterbrochen von Layer 8 Problemen

Dinge, die mir aufgefallen sind: Das Docker Image (latest) läuft nicht auf einem 64 bit Raspberry Pi unter Debian Buster (Geschmacksrichtung Raspberry Pi OS). Der Parameter --platform linux/arm64/v8  hilft nicht, nach umschalten auf devel ging es ohne jegliches zutun. Bugreport dazu auf Github geöffnet.

Code Auswählen Erweitern


sysop@homepi:~ $ sudo docker run  --rm -it -p 8888 john30/ebusd -f --scanconfig -d enh:192.168.182.13:9999 --latency=20 -f
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
standard_init_linux.go:219: exec user process caused: exec format error

sysop@homepi:~ $ sudo docker run --platform linux/arm64/v8 --rm -it -p 8888 john30/ebusd -f --scanconfig -d enh:192.168.182.13:9999 --latency=20 -f
Unable to find image 'john30/ebusd:latest' locally
latest: Pulling from john30/ebusd
Digest: sha256:fb8cb181acdec4444b32f1742f5ceaa2cfd9a763b9631c0ff21269176cdd65e9
Status: Image is up to date for john30/ebusd:latest
docker: Error response from daemon: image with reference john30/ebusd was found but does not match the specified platform: wanted linux/arm64/v8, actual: linux/amd64.
See 'docker run --help'.

sysop@homepi:~ $ sudo docker run  --rm -it -p 8888 john30/ebusd[b]:devel[/b] -f --scanconfig -d enh:192.168.182.13:9999 --latency=20 -f
2021-04-02 09:05:12.412 [main notice] ebusd 21.2.v21.2-12-g86b700c started with auto scan on enhanced device 192.168.182.13:9999
2021-04-02 09:05:12.732 [bus notice] bus started with own address 31/36
2021-04-02 09:05:12.762 [bus notice] signal acquired
2021-04-02 09:05:12.960 [bus notice] new master 10, master count 2
2021-04-02 09:05:12.988 [bus notice] new master 03, master count 3
2021-04-02 09:05:12.988 [update notice] received unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2021-04-02 09:05:12.995 [bus notice] device status: reset
2021-04-02 09:05:17.051 [update notice] received unknown MS cmd: 1008b5110101 / 095857008043530000ff
2021-04-02 09:05:22.896 [bus notice] scan 08: ;Vaillant;BAI00;0609;5502
2021-04-02 09:05:22.896 [update notice] store 08 ident: done
2021-04-02 09:05:22.897 [update notice] sent scan-read scan.08  QQ=31: Vaillant;BAI00;0609;5502
2021-04-02 09:05:22.897 [bus notice] scan 08: ;Vaillant;BAI00;0609;5502
2021-04-02 09:05:23.220 [main notice] read common config file vaillant/scan.csv
2021-04-02 09:05:23.258 [update notice] received unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2021-04-02 09:05:23.292 [main notice] read common config file vaillant/general.csv
2021-04-02 09:05:23.368 [main notice] read common config file vaillant/broadcast.csv
2021-04-02 09:05:23.444 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0609, HW5502
2021-04-02 09:05:23.633 [update notice] sent scan-read scan.08 id QQ=31:
2021-04-02 09:05:23.797 [update notice] sent scan-read scan.08 id QQ=31:
2021-04-02 09:05:23.960 [update notice] sent scan-read scan.08 id QQ=31:
2021-04-02 09:05:24.124 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:24.401 [main notice] found messages: 212 (3 conditional on 26 conditions, 0 poll, 10 update)
2021-04-02 09:05:24.590 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:24.753 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:24.917 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:25.081 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:25.081 [bus notice] scan 08: ;21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:27.246 [update notice] received read bai Status01 QQ=10: 44.0;43.5;-;33.5;41.5;off
2021-04-02 09:05:27.401 [bus notice] scan 15: ;Vaillant;35000;0114;7102
2021-04-02 09:05:27.401 [update notice] store 15 ident: done
2021-04-02 09:05:27.401 [update notice] sent scan-read scan.15  QQ=31: Vaillant;35000;0114;7102
2021-04-02 09:05:27.402 [bus notice] scan 15: ;Vaillant;35000;0114;7102
2021-04-02 09:05:27.584 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313633303030
2021-04-02 09:05:27.766 [update notice] sent scan-read scan.15 id QQ=31:
2021-04-02 09:05:27.947 [update notice] sent scan-read scan.15 id QQ=31:
2021-04-02 09:05:28.002 [bus notice] max. symbols per second: 114
2021-04-02 09:05:28.129 [update notice] sent scan-read scan.15 id QQ=31: 21;16;30;0020124472;0082;022440;N0
2021-04-02 09:05:28.129 [bus notice] scan 15: ;21;16;30;0020124472;0082;022440;N0
2021-04-02 09:05:28.313 [main notice] read scan config file vaillant/15.350.csv for ID "35000", SW0114, HW7102
2021-04-02 09:05:28.314 [main notice] found messages: 412 (7 conditional on 29 conditions, 0 poll, 10 update)
2021-04-02 09:05:29.191 [update notice] received update-read broadcast vdatetime QQ=10: 11:05:31;02.04.2021
2021-04-02 09:05:29.429 [update notice] received update-write bai StatusCirPump QQ=10: off
2021-04-02 09:05:33.232 [update notice] received update-write bai SetMode QQ=10: auto;0.0;-;-;1;0;1;0;0;0
...


Dann also erstmal lokal installiert, für die Parameterfindungsphase.

Aktueller manueller Aufruf:

Code Auswählen Erweitern

ebusd -d enh:192.168.x.x:9999 --scanconfig --latency=20 --accesslevel=* --mqtthost=192.168.x.x --mqttport=1883 --mqttuser=ein_user --mqttpass=geheim --mqttjson --configlang=de -f --configpath=/etc/ebusd/

Tipp: Falls readall.sh, ebusctl, ... nicht richtig spielen wollen, aber durch den Parameter -f eine Ausgabe an einem vorbeiflimmert, mit ps -ely | grep ebus sicherstellen, dass nur eine Instanz läuft. Eigene Erfahrung 

Zunächst im Home Assistant mit dem ebusd-Plugin einige Werte am ebusd abgeholt, ging grundsätzlich aber die Möglichkeiten sind doch sehr beschränkt; bai ist bekannt VT350 nicht.

Also auf zu MQTT
Eine Möglichkeit für einen Broker unter HA ist hier beschrieben: https://github.com/home-assistant/addons/blob/master/mosquitto/DOCS.md
Mir ging es dann wie einigen Anderen, dass ich mich gewundert habe, dass nichts ankommt und keine "Sensoren entstehen".

Zum manuellen Lesen und Abfragen von Werten und Beobachten der Kommunikation ist der MQTT-Explorer eine gute Hilfe: https://github.com/thomasnordquist/MQTT-Explorer/releases
Achtung! Die neuste Release wollte auf meinem Mac nicht starten. Die 0.3.6 funktioniert, auch wenn ein Helper beim Start crasht und eine Fehlermeldung kommt.

Eine weitere gute Inspiration für ebusd + MQTT + Home Assistant ist hier zu finden: https://community.home-assistant.io/t/ebus-integration/47343/54

Mit dem folgenden Code Schnipsel werden einige Temperaturen alle 5 Minuten ausgelesen (Besipiel).

Code Auswählen Erweitern


automation:
  - alias: ebusd_mqtt_update
    initial_state: on
    trigger:
      - platform: time_pattern
        minutes: "/5"
    action:
      - service: mqtt.publish
        data:
          topic: "ebusd/bai/ReturnTemp/get"
          payload: "1"
      - service: mqtt.publish
        data:
          topic: "ebusd/bai/ReturnTempExternal/get"
          payload: "1"


Um sich einen eigenen Schnipsel zu bauen die CSV Datei in Open/Libre Office, Excel, whatever öffnen und dann:

• Alle spalten entfernen bis auf die Bezeichnungen der Werte,
• alle Header entfernen,
• alle nicht benötigten Werte entfernen,
• alles zusammenschieben, so dass links von den Bezeichnern eine freie Spalte existiert,
• alle Felder der linken Spalte mit _x_ füllen,
• alle Felder der Spalte rechts von den Bezeichnern mit _y_ füllen (siehe Bild),
• in einer neuen Datei speichern,
• Datei in einem Texteditor öffnen,
• mit suchen und ersetzen die _x_, tauschen durch >>       - service: mqtt.publish
          data:
            topic: "<<,
• mit suchen und ersetzen die _y_, tauschen durch >>"
            payload: "1"<< und
• in die Automation einfügen.

>><< markieren die Codeschnipsel, code funktioniert nicht in einer Aufzählung.
Für andere Heimautomatisierungssysteme wird man andere Codeschnipsel benötigen, aber für das schnelle erstellen von Konfigurationen ohne Typos wird das vorgehen auch hilfreich sein.

Nach dem VT350-VT370 hack gibt es weniger ERR Meldungen. Aber bei der Kommunikation mit der Therme gibt es noch viele solcher Nachrichten. Hier bräuchte ich ein wenig Hilfe. Wo finde ich die "Rohdaten-Nachrichten", um mich selber an der Dekodierung zu versuchen?