eBUS Adapter 3.0 Inbetriebnahme

[schneivo]

ohne Dämon bekommst du keinen "connect".

LG

das ist richtig so
ja das sollte nicht sein.
Wie ist der Wemos denn auf der Oberfläche konfiguriert? Also ist er bei eBUS RX+TX auf "Adapter 3 RX+TX" eingestellt? Falls nicht, kann er kein Signal feststellen.
Und hast Du die Stromversorgung am Wemos angelegt oder am Adapter J2?
unwahrscheinlich, sonst würde die grüne LED nicht blinken

Inzwischen läuft es.

In der Weboberfläche steht jetzt:

Code Auswählen Erweitern

ebusd connected: yes (inactive)
eBUS signal: acquired
eBUS initial signal: yes

Ich dachte halt, dass der Status in der Web-Oberfläche anzeigt, dass es ein Problem mit der Verbindung zum eBUS des Reglers gibt, aber letztendlich lag es einfach nur daran, dass ebusd noch nicht lief.

Damit hatte ich zuerst auch ein paar Startschwierigkeiten.
Zum Testen habe ich eine VM mit Ubuntu aufgesetzt und dort dann wie im Wiki beschrieben (https://github.com/john30/ebusd/wiki/1.-Build-and-install) ebusd installiert. Wobei ich alle Befehle mit "sudo" ausgeführt habe und vermute, dass meine Problem eventuell dadurch gekommen sind.
Jedenfalls habe ich nach der Installation noch den automatischen Start aktiviert (ebenfalls wie im Wiki beschrieben) und danach dann einfach folgendes Kommando ausgeführt (natürlich habe ich die korrekte IP vom Wemos eingetragen ):

Code Auswählen Erweitern

sudo ebusd --scanconfig --accesslevel=* --latency=20000 -d enh:ip_vom_wemos:9999 --loglevel=debug --address=ff

In den logs unter /var/log/ebusd.log kam allerdings ständig folgende Fehlermeldung:

Code Auswählen Erweitern

2021-03-17 00:53:12.718 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2021-03-17 00:53:12.718 [bus notice] device invalid

Dann habe ich mal ebusd im Vordergrund mit der Flag -f gestartet, also so:

Code Auswählen Erweitern

sudo ebusd --scanconfig --accesslevel=* --latency=20000 -d enh:ip_vom_wemos:9999 --loglevel=debug --address=ff -f


Und siehe da, die Verbindung klappt einwandfrei!

Im System-Monitor von Ubuntu sehe ich nun allerdings 2 laufende ebusd Prozesse. Einmal den mit meinen Optionen und der zweite ist:

Code Auswählen Erweitern

/usr/bin/ebusd --scanconfig

Ich schätze mal, dass das der automatisch gestartete Prozess ist und der ist wohl auch verantwortlich für die oben besagten logs.
Wo die logs von meinem anderen ebusd hingeschrieben werden, weiß ich nicht, aber die Ausgaben kann ich ja auch direkt im Terminal sehen.

Ich bin auf jeden Fall schon mal sehr froh, dass das mit der Verbindung zum Adapter alles zu funktionieren scheint.

Als nächstes versuche ich herauszufinden wie ich Werte der Therme auslesen kann.

Edit:

Hier noch die Ausgabe von ebusctl info:

Code Auswählen Erweitern

tester@tester-VirtualBox:~$ ebusctl info
version: ebusd 21.2.v21.2-12-g86b700c
update check: revision v21.2 available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 146
min arbitration micros: 2
max arbitration micros: 25
min symbol latency: 9
max symbol latency: 48
reconnects: 0
masters: 3
messages: 232
conditional: 0
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address ff: master #25, ebusd

[Reinhart]

du musst in der config ganz oben die hier rot dargestellte Zeile entfernen, bzw. mit Raute sperren!

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

# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"

# MULTIPLE EBUSD INSTANCES WITH SYSV

Code Auswählen Erweitern

# EBUSD_OPTS="--scanconfig"
LG

[Reinhart]

ich habe gestern noch den (WIFI) Fehler von Mitch in Scooby nachstellen können und wir analysieren gerade woher das kommt.
Der USB/RPI Betrieb funktioniert und ist davon nicht betroffen.
John ist allerdings auswärts und kann erst am Wochenende genauer drüber schauen, bitte um etwas Geduld!

LG
Reinhart

[Mitch]

Danke Reinhart!

[Scooby]

Ich danke ebenso Reinhart. Keine Eile

Ich wollte nur noch mitteilen (falls das einen Einfluss haben sollte) daß bei mir der VRC430 mit 10m Kabel am Bus hängt, was möglicherweise Latenz und Signalschwäche mit sich zieht.

Gruß
Michael

[schneivo]

du musst in der config ganz oben die hier rot dargestellte Zeile entfernen, bzw. mit Raute sperren!

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

# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"

# MULTIPLE EBUSD INSTANCES WITH SYSV

Code Auswählen Erweitern

# EBUSD_OPTS="--scanconfig"
LG

Jo danke, ich hatte gestern noch ein bisschen weiter herumprobiert und bin dann auch auf diese Config gestoßen womit es dann auch mit dem Autostart lief.

Danach kam dann das nächste Problem. Der Raumtemperaturregler antwortete bei fast allen Anfragen mit:

Code Auswählen Erweitern

ERR: invalid position in decode

Ich bin dann auf diesen Github-Issue gestoßen: https://github.com/john30/ebusd/issues/196
Dort hatte der User sagittarius0815 das gleiche Problem und meinte, dass die CSV vom VRT 370 mit dem VRT 350 funktionierte.
Das hat bei mir dann auch geklappt. Vielleicht sollte man die CSVs mal updaten.

Mit der neuen CSV konnte ich dann auch verschiedene Werte mit folgenden Befehlen erfolgreich ändern:

Code Auswählen Erweitern

# Datum ändern
ebusctl w -c 350 Date 17.03.2021
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Date

# Zeit ändern
ebusctl w -c 350 Time 14:15:00
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Time

# Tag Modus einschalten
ebusctl w -c 350 Hc1OPMode on
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Hc1OPMode

# Sommer Modus einschalten
ebusctl w -c 350 Hc1OPMode summer
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Hc1OPMode

Ich bin auf jeden Fall beeindruckt wie gut das alles läuft!
Als nächstes werde ich dann mit ebusd auf einen Raspberry Pi umziehen und versuchen die Werte in einem UI anzuzeigen und zu bearbeiten.


Edit:

Ach so, falls noch jemand Probleme mit dem VRT 350 haben sollte, hier nochmal meine Schritte:

1. ebusd-configuration Repository herunterladen

Code Auswählen Erweitern

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

2. den Inhalt aus dem Ordner ebusd-configuration/ebusd-2.1.x/de nach /etc/ebusd kopieren

Code Auswählen Erweitern

cd Downloads/ebusd-configuration/ebusd-2.1.x/de
sudo cp -r * /etc/ebusd/

3. ein Backup der VRT 350 CSV erstellen und sie dann durch die VRT 370 CSV austauschen

Code Auswählen Erweitern

cd /etc/ebusd/vaillant/
sudo cp 15.350.csv 15.350.csv_BACKUP
sudo rm 15.350.csv
sudo cp 15.370.csv 15.350.csv

4. die ebusd Start-Config (/etc/default/ebusd) anpassen, damit sie die lokale Config lädt

Code Auswählen Erweitern

EBUSD_OPTS="--scanconfig --configpath=/etc/ebusd/ --accesslevel=* --latency=20000 -d enh:ip_vom_wemos:9999 --loglevel=debug --address=ff"

5. die ebusd Configs neu laden

Code Auswählen Erweitern

ebusctl reload

[Reinhart]

danke für deinen ausführlichen Hinweise!

daran denken, wenn alles läuft den --loglevel wieder entfernen, ist sonst unnützer Ballast.

LG

[john30]

zum Wifi Thema:

es scheint in der Kommunikation zwischen ebusd und dem Wemos (und evtl. dann zum PIC) ein Timingproblem zu geben. Das muss ich erst noch genau analysieren und komme frühestens am Wochenende dazu.

Bis dahin schafft ein extra "--latency=80" in den EBUSD_OPTS anscheinend Abhilfe.

Danke @Reinhart, dass ich Deine Anlage zur ersten Analyse nutzen durfte!

[rob]

Hallo.

Habe meine LAN-Variante auch vorgestern dankend erhalten. Schön kompakt das kleine Scheißerchen 

Eine Frage: Die Jumper-Config im Wiki ist für die LAN-Kombi verifiziert (J1=RPI; J4=USB; J12=5-6)? Ich meine ja (Foto und 3D-Bild decken sich damit). Doch bevor ich Spannung anlege, frage ich lieber sicherheitshalber, weil bei mir noch J1=USB gesteckt ist. Könnte ja sein, dass bei der Menge an Arbeit eine Kleinigkeit durchgerutscht ist (wenn auch unwahrscheinlich ).

Viele Grüße
rob

[gallich]

Hallo!

Bin gerade bei der Inbetriebname von meinem Adapter (direkt auf RPi aufgesteckt) für meine Luftwärmepumpe AroTherm Split VWL75 mit Systemregler VCR700.
Ich bekomme aber nur ein paar Daten.
Laut meinen Daemon habe ich sehr viele "received unknown MS cmd".
Desweiteren lese ich auch, dass er die Config 76 nicht hat.

Wenn ich "ebusctl i" ausführe dann sehe ich, dass ich kein Signal habe obwohl ein paar Daten reinkommen.

Code Auswählen Erweitern

pi@raspberrypi4host:~ $ ebusctl i
version: ebusd 21.2.v21.2
update check: OK
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

Code Auswählen Erweitern

pi@raspberrypi4host:~ $ sudo ebusd -f --scanconfig -d enh:/dev/ttyAMA0 --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name
2021-03-18 10:01:57.457 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device /dev/ttyAMA0
2021-03-18 10:01:57.703 [bus notice] bus started with own address 31/36
2021-03-18 10:01:57.710 [mqtt notice] connection established
2021-03-18 10:01:57.751 [bus error] device status: unexpected available enhanced following byte 1
2021-03-18 10:01:57.751 [bus notice] signal acquired
2021-03-18 10:01:58.344 [bus notice] device status: reset
2021-03-18 10:01:58.925 [bus notice] new master 71, master count 2
2021-03-18 10:01:58.985 [bus notice] new master 03, master count 3
2021-03-18 10:01:58.985 [update notice] received unknown MS cmd: 7108b5110107 / 0a16ce0001083f00000000
2021-03-18 10:02:02.414 [update notice] received unknown MS cmd: 7108b5110107 / 0a16ce0001083f00000000
2021-03-18 10:02:04.152 [update notice] received unknown MS cmd: 7108b5120e11cb019201b601d1011500040000 / 020237
2021-03-18 10:02:05.546 [bus notice] new master 10, master count 4
2021-03-18 10:02:05.602 [update notice] received unknown MS cmd: 1008b5110101 / 0939320080ffff0100ff
2021-03-18 10:02:05.855 [update notice] received unknown MS cmd: 7108b5110107 / 0a16ce0001083f00000000
2021-03-18 10:02:05.907 [update notice] received unknown MS cmd: 1076b5110101 / 0938329404ff5f0000ff
2021-03-18 10:02:06.177 [update notice] received unknown MS cmd: 1076b512030f0201 / 07fd0200c20115ff
2021-03-18 10:02:06.445 [update notice] received unknown MS cmd: 1008b51009000036ffffff060000 / 0101
2021-03-18 10:02:06.709 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
2021-03-18 10:02:07.887 [bus notice] scan 08: ;Vaillant;HMU00;0405;5103
2021-03-18 10:02:07.887 [update notice] store 08 ident: done
2021-03-18 10:02:07.887 [update notice] sent scan-read scan.08  QQ=31: Vaillant;HMU00;0405;5103
2021-03-18 10:02:07.887 [bus notice] scan 08: ;Vaillant;HMU00;0405;5103
2021-03-18 10:02:08.138 [main notice] read common config file vaillant/scan.csv
2021-03-18 10:02:08.199 [main notice] read common config file vaillant/general.csv
2021-03-18 10:02:08.254 [main notice] read common config file vaillant/broadcast.csv
2021-03-18 10:02:08.313 [main notice] read scan config file vaillant/08.hmu.csv for ID "hmu00", SW0405, HW5103
2021-03-18 10:02:08.427 [main notice] found messages: 61 (0 conditional on 0 conditions, 0 poll, 10 update)
2021-03-18 10:02:08.645 [update notice] sent unknown MS cmd: 3108b5090124 / 09003231313933343030
2021-03-18 10:02:08.834 [update notice] sent scan-read scan.08 id QQ=31:
2021-03-18 10:02:09.020 [update notice] sent scan-read scan.08 id QQ=31:
2021-03-18 10:02:09.208 [update notice] sent scan-read scan.08 id QQ=31: 21;19;34;0010021619;1610;005437;N1
2021-03-18 10:02:09.208 [bus notice] scan 08: ;21;19;34;0010021619;1610;005437;N1
2021-03-18 10:02:11.413 [bus notice] scan 15: ;Vaillant;70000;0613;6903
2021-03-18 10:02:11.413 [update notice] store 15 ident: done
2021-03-18 10:02:11.413 [update notice] sent scan-read scan.15  QQ=31: Vaillant;70000;0613;6903
2021-03-18 10:02:11.413 [bus notice] scan 15: ;Vaillant;70000;0613;6903
2021-03-18 10:02:11.601 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313933343030
2021-03-18 10:02:11.787 [update notice] sent scan-read scan.15 id QQ=31:
2021-03-18 10:02:11.976 [update notice] sent scan-read scan.15 id QQ=31:
2021-03-18 10:02:12.164 [update notice] sent scan-read scan.15 id QQ=31: 21;19;34;0020266797;0082;045585;N0
2021-03-18 10:02:12.164 [bus notice] scan 15: ;21;19;34;0020266797;0082;045585;N0
2021-03-18 10:02:12.349 [main notice] read scan config file vaillant/15.700.csv for ID "70000", SW0613, HW6903
2021-03-18 10:02:12.410 [main notice] found messages: 481 (0 conditional on 0 conditions, 0 poll, 10 update)
2021-03-18 10:02:12.734 [update notice] received read hmu State QQ=71: 22;206;on;8
2021-03-18 10:02:14.614 [bus notice] scan 76: ;Vaillant;VWZ00;0517;5103
2021-03-18 10:02:14.614 [update notice] store 76 ident: done
2021-03-18 10:02:14.614 [update notice] sent scan-read scan.76  QQ=31: Vaillant;VWZ00;0517;5103
2021-03-18 10:02:14.615 [bus notice] scan 76: ;Vaillant;VWZ00;0517;5103
2021-03-18 10:02:14.812 [update notice] sent unknown MS cmd: 3176b5090124 / 09003231313933363030
2021-03-18 10:02:15.046 [main error] unable to load scan config 76: no file from vaillant with prefix 76 found
2021-03-18 10:02:15.046 [main error] scan config 76: ERR: read timeout
2021-03-18 10:02:15.625 [update notice] received read hmu Status01 QQ=10: 28.5;25.0;-;-;-;on
2021-03-18 10:02:15.889 [update notice] received unknown MS cmd: 1076b5110101 / 093832a304ff5f0000ff
2021-03-18 10:02:16.149 [update notice] received unknown MS cmd: 1076b512030f0201 / 07fd0200c30115ff
2021-03-18 10:02:16.412 [update notice] received read hmu State QQ=71: 22;206;on;8
2021-03-18 10:02:16.413 [update notice] received unknown BC cmd: 10feb505025c00
2021-03-18 10:02:16.680 [update notice] received update-write hmu SetMode QQ=10: auto;27.0;-;-;0;1;1;0;0;0
2021-03-18 10:02:16.944 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
2021-03-18 10:02:17.032 [bus notice] max. symbols per second: 108
2021-03-18 10:02:17.212 [update notice] received unknown MS cmd: 1076b5040100 / 0a00ffffffffffffffa304
2021-03-18 10:02:17.451 [update notice] received unknown MS cmd: 1008b507020936 / 020102
2021-03-18 10:02:17.691 [update notice] received update-read broadcast vdatetime QQ=10: 10:02:16;18.03.2021
2021-03-18 10:02:17.954 [update notice] received unknown MS cmd: 1008b5110100 / 09cc011553000900002c
2021-03-18 10:02:18.198 [update notice] received unknown MS cmd: 1076b51303040d00 / 020d00
2021-03-18 10:02:18.413 [update notice] received update-read broadcast outsidetemp QQ=10: 4.578
2021-03-18 10:02:18.647 [update notice] received update-write hmu StatusCirPump QQ=10: on

Hoffe ihr könnt mir da weiterhelfen.

Christian

[Reinhart]

Eine Frage: Die Jumper-Config im Wiki ist für die LAN-Kombi verifiziert (J1=RPI; J4=USB; J12=5-6)? Ich meine ja (Foto und 3D-Bild decken sich damit). Doch bevor ich Spannung anlege, frage ich lieber sicherheitshalber, weil bei mir noch J1=USB gesteckt ist. Könnte ja sein, dass bei der Menge an Arbeit eine Kleinigkeit durchgerutscht ist (wenn auch unwahrscheinlich ).

Die Jumper stehen noch von dem Test so und da wurde ja auf USB getestet. Da ich bei den UNI Varianten ohnehin nicht weiß wie sie betrieben werden laß ich die meist auf USB stecken, hat jetzt nichts mit durchgerutscht zu tun.

LG
Reinhart

[Reinhart]

@gallich

also "ebusctl i" passt nicht zu deinem Log, es wird hier nur der eigene Adapter angeführt. Außerdem hast du zweimal den Device beim Start definiert.

sudo ebusd -f --scanconfig -d enh:/dev/ttyAMA0 --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name

Die vielen "unknown" kommen weil hier keine entsprechenden csv geladen sind und daher werden die Rohdaten nicht dekodiert. Was ich im Log gesehen habe wird nur "15.700.csv" mit 481 Definitionen geladen.

Hast du wirklich die seriellen Einstellungen am Raspi gecheckt ob das alles so passt? Was hast du für einen Raspi?

LG

[Reinhart]

zum Wifi Thema:

es scheint in der Kommunikation zwischen ebusd und dem Wemos (und evtl. dann zum PIC) ein Timingproblem zu geben. Das muss ich erst noch genau analysieren und komme frühestens am Wochenende dazu.

Bis dahin schafft ein extra "--latency=80" in den EBUSD_OPTS anscheinend Abhilfe.

Danke @Reinhart, dass ich Deine Anlage zur ersten Analyse nutzen durfte!

Danke John das du trotz deiner Abwesenheit dich der Sache so schnell angenommen hast und die ersten Analysen durchgeführt hast. Ich habe noch verschiedene Wemos getestet und das Verhalten ist eigentlich bei allen gleich bis auf unterschiedliche Feldstärken. Aktiviere ich noch zusätzlich das MQTT Protokoll versagt auch die latency=80, stelle ich MQTT ab gehts wieder tadellos.

Der Zusammenhang warum es bei einigen Anwendern trotzdem tadellos funktioniert ist mir noch nicht ganz klar, obwohl die auch MQTT nutzen.

LG

[rob]

...hat jetzt nichts mit durchgerutscht zu tun.

Dachte ich mir schon, sollte kein Vorwurf sein. Ich möchte halt Fehler meinerseits vermeiden.

Die Jumper stehen noch von dem Test so und da wurde ja auf USB getestet.

Wenn ich den Adapter an der Therme betreibe, würde ich ihn via USB-Port mit Energie versorgen und das LAN-Kabel zum Switch ziehen (eBus-Leitung damit möglichst kurz). Ist es dann Wurscht, wie J1 gejumpert wird? USB klingt für mich zunächst einleuchtend und so hast ja auch getestet. Aber wenn RPI richtig ist, nehme ich natürlich das

Sorry für die doofen Fragen.

VG
rob

[gallich]

also "ebusctl i" passt nicht zu deinem Log, es wird hier nur der eigene Adapter angeführt. Außerdem hast du zweimal den Device beim Start definiert.

sudo ebusd -f --scanconfig -d enh:/dev/ttyAMA0 --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name

Die vielen "unknown" kommen weil hier keine entsprechenden csv geladen sind und daher werden die Rohdaten nicht dekodiert. Was ich im Log gesehen habe wird nur "15.700.csv" mit 481 Definitionen geladen.

Hast du wirklich die seriellen Einstellungen am Raspi gecheckt ob das alles so passt? Was hast du für einen Raspi?

In der Config Datei hab ich das Device nur 1 mal drinnen.
War ein Kopierfehler von mir als ich ebusd direkt von der Kosole gestartet habe, ändert aber nichts an meinem Problem.
Habe eine Raspberry 4 und habe die seriellen Einstellungen so gemacht wie in der Anleitung steht.
Auf diesem Raspberry laufen noch andere Sache wie IoBroker mit div. Adptern, vielleicht haut mir dass irgendwo einen Hund rein.
Werde es mal mit meinem Raspberry Pi3 mit neu aufgesetztem Image versuchen.