eBUS Adapter 3.0 Inbetriebnahme

Begonnen von Reinhart, 25 Januar 2021, 09:00:45

Vorheriges Thema - Nächstes Thema

rob

Hallo.

Ich habe auch eine Weishaupt und warte schon gespannt auf die Lieferung. Vorab schon einmal ein großes Dankeschön und ein fettes "Respekt" für die ganze Arbeit (schon allein die Bestellinfrastruktur - ist das noch basteln?).

Wenn ich das bzgl. config. zur Weishaupt alles so überfliege, bekomme ich doch kalte Füße. Verstehe ich richtig, dass ich erst diese ganzen CSV-Files begriffen haben muss bevor ich den Adapter in Betrieb nehme?  :o
Es steht im Wiki ja eindeutig, dass ansonsten die Anlage beschädigt werden kann, wenn man nicht weiß was es tut.

Ich dachte ganz naiv: ebusd via docker starten, mit MQTT sprechen lassen und Adapter dran = über Readings freuen. So einfach ist es dann wohl doch nicht.
Den Adapter HW2.2 hatte ich testweise mal für 10 Min dran und bekam ein paar Temperaturwerte für außen. Mit CSV hatte ich dafür noch nichts gemacht - einfach nur mal schnell testen. Viele Wochen später hatte die Anlage ein paar Fehlermeldungen - jetzt sehe ich da doch einen Zusammenhang...

Gibt es eine gute Quelle, wo ich mich in den CSV-Krams gebündelt einlesen sollte oder bleiben allein die Threads?

Vielen Dank und beste Grüße
rob

wak

Hello All!

I receive my rpi-board v3.
THANK YOU for creating the board.

I am trying to connect to my WOLF CGS24 (v1) using ebusd on rpi-v2 with newest OS (Raspbian GNU/Linux 10 (buster)).
WOLF CGS24 is a gas condensing furnace.

The board/ebusd does not recognize my WOLF.

In my logs I can see Kromschroeder.
I do not see WOLF.

Is there someone who managed to run the new board + ebusd + WOLF CGS?

My /etc/default/ebusd

EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 --device=enh:/dev/ttyAMA0 --address=0 --loglevel=debug"


Some logs with scan results:

cat /var/log/ebusd.log | grep -v "received unknow\|received BC cmd\|performing regular tasks\|received MM cmd:\|ERR: read timeout during receive command ACK"

...
2021-03-10 14:53:17.926 [bus notice] scan f6: ;Kromschroeder;  ;0204;0184
2021-03-10 14:53:17.926 [update notice] store f6 ident: done
2021-03-10 14:53:17.926 [update notice] sent scan-read scan.f6  QQ=00: Kromschroeder;  ;0204;0184
2021-03-10 14:53:17.927 [bus debug] notify request: done
2021-03-10 14:53:17.927 [bus notice] scan f6: ;Kromschroeder;  ;0204;0184
2021-03-10 14:53:17.927 [bus debug] switching from send response ACK to send SYN
2021-03-10 14:53:17.939 [bus debug] send/receive symbol latency 11 ms
2021-03-10 14:53:18.085 [main error] unable to load scan config f6: list files in kromschroeder ERR: element not found
2021-03-10 14:53:18.085 [main error] scan config f6: ERR: element not found
2021-03-10 14:53:59.888 [update error] unable to parse update-read broadcast datetime from 30fe070009008014561400000300 / : ERR: argument value out of valid range
2021-03-10 14:54:57.479 [update error] unable to parse update-read broadcast datetime from 30fe070009008011571400000300 / : ERR: argument value out of valid range
2021-03-10 14:55:20.240 [main notice] update check: OK
2021-03-10 14:55:48.574 [update notice] received update-read broadcast id QQ=30: Kromschröder;  ;0208;0186
2021-03-10 14:55:48.776 [update notice] received update-read broadcast id QQ=70: Kromschröder;  ;0208;0186
2021-03-10 14:55:48.940 [update notice] received update-read broadcast id QQ=30: Kromschröder;  ;0204;0184
2021-03-10 14:55:52.625 [update notice] received update-read broadcast id QQ=70: Kromschröder;  ;0204;0184
...

Some other logs.
2021-03-10 14:58:10.251 [main debug] performing regular tasks
2021-03-10 14:58:10.359 [update info] received BC cmd: f1fe050308010540ff84ff0004
2021-03-10 14:58:10.360 [update notice] received unknown BC cmd: f1fe050308010540ff84ff0004
2021-03-10 14:58:13.810 [update info] received MM cmd: 10030800084d2f000480030032
2021-03-10 14:58:13.810 [update notice] received unknown MM cmd: 10030800084d2f000480030032
2021-03-10 14:58:14.997 [update info] received BC cmd: f1fe080008662fe60200090032
2021-03-10 14:58:14.998 [update notice] received unknown BC cmd: f1fe080008662fe60200090032
2021-03-10 14:58:16.273 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:17.542 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:18.790 [update info] received MM cmd: 1003050709bb03f8020100ff64ff
2021-03-10 14:58:18.790 [update notice] received unknown MM cmd: 1003050709bb03f8020100ff64ff
2021-03-10 14:58:19.311 [update info] received BC cmd: 03fe050308010040007c3c2304
2021-03-10 14:58:19.311 [update notice] received unknown BC cmd: 03fe050308010040007c3c2304
2021-03-10 14:58:20.011 [update info] received BC cmd: f1fe050308010540ff7cff0004
2021-03-10 14:58:20.011 [update notice] received unknown BC cmd: f1fe050308010540ff7cff0004
2021-03-10 14:58:20.252 [main debug] performing regular tasks
2021-03-10 14:58:23.783 [update info] received MM cmd: 1003080008802f000480030032
2021-03-10 14:58:23.784 [update notice] received unknown MM cmd: 1003080008802f000480030032
2021-03-10 14:58:24.972 [update info] received BC cmd: f1fe0800081a2fe60200090032
2021-03-10 14:58:24.974 [update notice] received unknown BC cmd: f1fe0800081a2fe60200090032
2021-03-10 14:58:26.249 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:27.517 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:28.813 [update info] received MM cmd: 1003050709bb02f8020100ff64ff
2021-03-10 14:58:28.814 [update notice] received unknown MM cmd: 1003050709bb02f8020100ff64ff
2021-03-10 14:58:30.002 [update info] received BC cmd: f1fe050308010540ff7cff0004
2021-03-10 14:58:30.004 [update notice] received unknown BC cmd: f1fe050308010540ff7cff0004
...
2021-03-10 15:01:58.813 [update info] received BC cmd: 30fe070009008013041500000300
2021-03-10 15:01:58.814 [update error] unable to parse update-read broadcast datetime from 30fe070009008013041500000300 / : ERR: argument value out of valid range
2021-03-10 15:02:00.088 [bus debug] ERR: read timeout during receive command ACK, switching to skip


Errors:

cat /var/log/ebusd.log | grep "ERR" | tail -n 20
2021-03-10 15:17:27.583 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:36.252 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:37.523 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:46.385 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:47.622 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:47.694 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:47.766 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:50.281 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:51.519 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:51.591 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:51.662 [bus debug] ERR: SYN received during receive command ACK, switching to ready
2021-03-10 15:17:57.820 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:59.093 [update error] unable to parse update-read broadcast datetime from 30fe070009008013201500000300 / : ERR: argument value out of valid range
2021-03-10 15:18:00.367 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:06.520 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:07.791 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:16.319 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:17.590 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:26.259 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:27.530 [bus debug] ERR: read timeout during receive command ACK, switching to skip


Some errors from the scan:

cat /var/log/ebusd.log | grep "ERR" | grep -v skip

2021-03-10 14:53:08.778 [main error] unable to load scan config 08: list files in kromschroeder ERR: element not found
2021-03-10 14:53:08.778 [main error] scan config 08: ERR: element not found
2021-03-10 14:53:11.078 [main error] unable to load scan config 15: list files in kromschroeder ERR: element not found
2021-03-10 14:53:11.078 [main error] scan config 15: ERR: element not found
2021-03-10 14:53:13.388 [main error] unable to load scan config 35: list files in kromschroeder ERR: element not found
2021-03-10 14:53:13.389 [main error] scan config 35: ERR: element not found
2021-03-10 14:53:15.724 [main error] unable to load scan config 75: list files in kromschroeder ERR: element not found
2021-03-10 14:53:15.725 [main error] scan config 75: ERR: element not found
2021-03-10 14:53:18.085 [main error] unable to load scan config f6: list files in kromschroeder ERR: element not found
2021-03-10 14:53:18.085 [main error] scan config f6: ERR: element not found

stefan_d

Zitat von: rob am 10 März 2021, 13:09:33
Hallo.

Ich habe auch eine Weishaupt und warte schon gespannt auf die Lieferung. Vorab schon einmal ein großes Dankeschön und ein fettes "Respekt" für die ganze Arbeit (schon allein die Bestellinfrastruktur - ist das noch basteln?).

Wenn ich das bzgl. config. zur Weishaupt alles so überfliege, bekomme ich doch kalte Füße. Verstehe ich richtig, dass ich erst diese ganzen CSV-Files begriffen haben muss bevor ich den Adapter in Betrieb nehme?  :o
Es steht im Wiki ja eindeutig, dass ansonsten die Anlage beschädigt werden kann, wenn man nicht weiß was es tut.

Ich dachte ganz naiv: ebusd via docker starten, mit MQTT sprechen lassen und Adapter dran = über Readings freuen. So einfach ist es dann wohl doch nicht.
Den Adapter HW2.2 hatte ich testweise mal für 10 Min dran und bekam ein paar Temperaturwerte für außen. Mit CSV hatte ich dafür noch nichts gemacht - einfach nur mal schnell testen. Viele Wochen später hatte die Anlage ein paar Fehlermeldungen - jetzt sehe ich da doch einen Zusammenhang...

Gibt es eine gute Quelle, wo ich mich in den CSV-Krams gebündelt einlesen sollte oder bleiben allein die Threads?

Vielen Dank und beste Grüße
rob
Hoi,

solange du nichts auf den BUS schreibst, machst du eigentlich auch nichts kaputt.
Die CSV Dateien werden benötigt, um die ebus-Telegramme zu dekodieren, soweit ich das verstanden habe - also aus einer Geräte ID wird dann ein sprechender Name. Das kann per "--configpath" eingebunden werden. BIn da aber noch nicht viel weiter mit gekommen.

Vielleicht lagern wir die Weishaupt-Diskussion in einen separaten Thread aus?

Reinhart

Das Problem mit den csv bei Wolf, Weishaupt, Kromschröder ist ja, das es keine csv Files am Server gibt. Ihr müsst deshalb den "configpath" auf lokale Umgebung stellen die Files dort hin kopieren, sonst versucht er sie vom Server zu holen wo es sie nicht gibt. Legt dazu einfach ein Verzeichnis /etc/ebusd/de/wolf o.ä an und kopiert die csv dort hinein. Schaut euch dazu einfach die Links unten genauer durch, es gibt dort wertvolle Hinweise zu euren Problemen.

--configpath=/etc/ebusd

JOEK3R hat hier schon sehr wertvolle Arbeit geleistet und seine Files hier zur Verfügung gestellt.

hier einige Links zu dem Thema:
Wolf mit configs
ebusd bei Wolf
Weishaupr am ebusd
Wolf ebus allgemein
Wolf cbg-k-24


Die Erkennung ob Wolf, Kromschroeder etc. erfolgt ja durch auslesen der Hersteller ID und wenn sich euer Gerät so ausgibt dann sind auch die csv so aufgebaut.

r;b,,id,Identifikation,,,0704,,manufacturer,,UCH,0x06=Dungs;0x0f=FH Ostfalia;0x10=TEM;0x11=Lamberti;0x14=CEB;0x15=Landis-Staefa;0x16=FERRO;0x17=MONDIAL;0x18=Wikon;0x19=Wolf;0x20=RAWE;0x30=Satronic;0x40=ENCON;0x50=Kromschröder;0x60=Eberle;0x65=EBV;0x75=Grässlin;0x85=ebm-papst;0x95=SIG;0xa5=Theben;0xa7=Thermowatt;0xb5=Vaillant;0xc0=Toby;0xc5=Weishaupt;0xfd=ebusd.eu,,Geräte-Hersteller,,,id,,,Geräte-ID,software,,PIN,,,Software-Version,hardware,,PIN,,,Hardware-Version


Da keiner von uns ein derartiges Gerät besitzt, können wir da auch nicht so gut unterstützen.

LG
Reinhart


FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

Zitat von: rob am 10 März 2021, 13:09:33
Gibt es eine gute Quelle, wo ich mich in den CSV-Krams gebündelt einlesen sollte oder bleiben allein die Threads?

die Grundlagen dazu hat John im Wiki zusammen gefasst. Das Thema ist aber doch sehr umfangreich und setzt viel Experimentierfreudigkeit voraus! Das Beste ist das bereits gesammelte auszunutzen, was leider sehr verstreut hier zu finden ist. Aber es gibt die Boardsuche die weiter helfen kann.

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

Zitat von: stefan_d am 10 März 2021, 15:22:38
Vielleicht lagern wir die Weishaupt-Diskussion in einen separaten Thread aus?

ja, das ist eine gute Idee, es geht ja nicht um den Adapter selbst sondern allgemein um die Dekodierung bzw. csv Files für die spezifischen Geräte.
Ich habe oben schon ein paar Threads verlinkt, vielleicht passt eh schon einer zum Thema.
Hier möchten wir über den Adapter selber diskutieren, Inbetriebnahme Fehlermeldungen etc. damit die Sache übersichtlich bleibt.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Mitch

Zitat von: Reinhart am 09 Februar 2021, 18:36:52
Achtung

Es erreichen mich immer wieder per Mail oder PN Anfragen das der Adapter zwar soweit funktioniert aber nur spärlich Daten liefert!

Das ist auch richtig so, das Heizgerät liefert nur ein paar Broadcast Daten automatisch, warum sollte es am Bus auch mehr übertragen wenn es die zur internen Steuerung nicht braucht! Je mehr Geräte wie Calormartic etc. miteinander kommunizieren, desto mehr wird am Bus sichtbar werden, aber mit dem Adapter wird keiner von selbst kommunizieren, dieser lauscht lediglich am Bus alles mit!

Wer sich nun die Broadcast Daten genauer anschaut wird aber feststellen das hier schon gut brauchbare Messdaten enthalten sind:

,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,

diese Daten kommen regelmäßig als Broadcast und müssen nicht extra angefragt werden, alles weitere muss vom Benutzer am Bus abgefragt werden!

Beispiel im der Console:
pi@eBus:~ $ ebusctl r -f FlowTemp
54.44;ok


Es gibt dazu verschiedene Ansätze:
- polling über Dämon
- Abfrage über ECMD
- Abfrage über MQTT via "get"
- oder GAEBUS einrichten, dass ist für Anfänger die einfachste Art da hier auch die Polling Steuerung mit enthalten ist und ihr euch nicht weiter kümmern müsst.

Alle Links zu den Infos sind im ersten Post enthalten und sollen euch bei den ersten Schritten weiter helfen und wenn das nicht hilft, dann bitte hier eure Fragen posten! Per PN oder Mail hat das wenig Sinn, dazu ist das Forum da!

LG
Reinhart

Hallo Reinhart,

leider muss auch ich sagen, es werden weniger Daten geliefert.

Bin von ebus v1 auf v3 umgestiegen. Habe also einfach den ebus Adapter gewechselt.
Das Device in fhem ist gleich geblieben. Leider fehlen ganz viele Readings, auch meine GETs und SETs gehen dadurch nicht mehr.

Sehr unschön.
FHEM im Proxmox Container

Reinhart

#22
hast du die config auf enhanced angepasst?

Wenn ja, dann poste bitte ein "ebusctl i".

das oben geschriebene gilt ja nur allgemein, weil einige Anwender hunderte von Datensätzen erwarten die durch den Adapter ins Fhem hereinrieseln, von selbst tut der nix. Du hast eh geschrieben, die müssen durch get oder set abgeholt werden. Wenn das bei dir nicht mehr funktioniert, dann vermute ich das die csv geändert (Server)  oder nicht mehr geladen werden.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Mitch

was meinst du mit enhanced?
-d enh:ip:port habe ich dazu gefügt.

ein ebusctl i liefert:
version: ebusd 21.1.v21.1-12-gccfc025
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
FHEM im Proxmox Container

Reinhart

ok, Version hast du die richtige, denn kleiner als V21 kann kein enhanced.

Dein Adapter hat aber gar kein Signal und kann eigentlich gar nicht funktionieren!
signal: no signal

hast du den alten Adapter auch noch parallel in Betrieb, das es zu einer Adress Kollision kommt?

Jumper auf der V3 hast du gecheckt, J12 1-2 steckt oder kann auxch entfernt werden, das ist der "enhanced" Modus.
Kannst du noch deine config posten?

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Mitch

Da hatte ich gerade einen Fehler gemacht. Hab auch noch schnell einen Update gemacht. Jetzt passt es:
version: ebusd 21.2.v21.2
access: *
signal: acquired
symbol rate: 26
max symbol rate: 101
min arbitration micros: 4
max arbitration micros: 60
min symbol latency: 9
max symbol latency: 59
reconnects: 0
masters: 3
messages: 431
conditional: 19
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004279']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address ff: master #25, ebusd


Jumper sind so, wie das Ding angekommen ist. Müsste ich jetzt mal auf den Dachboden gehen.

Der alte ebus ist natürlich nicht mehr dran.
FHEM im Proxmox Container

Reinhart

ja das sieht besser aus es werden auch die csv geladen, nur woher weiß ich noch nicht? Hast du die lokal genutzt oder vom Server, das sieht man nur aus der config.
Ich vermute das du jetzt die csv vom Server holst und hast vorher die lokalen benutzt und die sind nicht gleich.

Übrigens, du hast die gleiche Umgebung wie ich mit der Calormatic 430.
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

ich würde einmal bei einem Wert der jetzt nicht mehr funktioniert, wie der in der bai00.cfg ( oder wie immer die bei dir heißt) definiert ( Bezeichnung) steht. Und dann schaue mit ebusctl r -f Namen ob das noch passt, ich glaube nicht!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Mitch

Ne, eigentlich hatte ich die Config auch online genutzt.

So sah es in der alten ebusd config aus:
EBUSD_OPTS="--scanconfig --accesslevel=* --mqttport=1887 --mqttjson --mqtthost=192.168.0.202 --mqtttopic=ebusd/%circuit/%name --mqttclientid=ebusd --mqttchanges

so sieht es in der neuen aus:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:10.11.0.75:9999 --loglevel=debug --address=ff --mqttport=1887 --mqttjson --mqtthost=192.168.0.202 --mqtttopic=ebusd/%circuit/%name --mqttclientid=ebusd
FHEM im Proxmox Container

Reinhart

wenn vorher online war und jetzt muss es passen. Ich würde aber trotzddem eine Abfrage so wie in der bai00.cfg definiert mit einer direkten in der Console vergleichen, es kann nur da der Fehler liegen weil es werden ja bei dir 431 Definitionen geladen! Nur die Bezeichnungen müssen noch passen.
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa