eBus Schaltung V2 in Betrieb nehmen

[dkreutz]

Hallo John,

Der Slave sendet in der ID-Abfrage eine Antwort, die nicht der Spezifikation entspricht. Demzufolge lässt sich das Scan Ergebnis nicht zur automatischen Konfiguration nutzen.

Danke für die Erklärung. Kannst Du mir noch einen Ansatzpunkt geben, wo ich jetzt weiter suchen muss?

Ich habe hier im Forum noch den Wolf R12 Thread gefunden und daraus die zusätzlichen CSVs nach /etc/ebusd/wolf kopiert. 
Mir ist auch noch nicht klar wohin ich die _templates.csv und broadcast.csv kopieren muss, nach /etc/ebusd oder in den Unterordner /etc/ebusd/wolf?

Schadet es wenn ich den Unterordner "Vaillant" lösche, den benötige ich ja sowieso nicht?

Welche Bedeutung hat die Option "--address=01" in dem Konfigurationsstring EBUSD_OPTS?
mit der Option

Code Auswählen Erweitern

address 01: master #6, ebusd
address 06: slave #6, ebusd
address f1: master #10
address f6: slave #10
ohne

Code Auswählen Erweitern

address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10

[Prince]

@ john30 & Reinhart

In die Funktionsmatrix der Erweiterungsplatine könnte auch noch die Fähigkeit des Ebusd-esp-Wemos aufgenommen werden, die RX/TX-Pins zu swappen. Dann sind nur 2 Brücken (SJ7 und SJ8) ausreichend

Sehe ich das richtig?.

6. RX+TX PINs: swapped D8+D7 (GPIO 13+15)

[Reinhart]

@ john30 & Reinhart

In die Funktionsmatrix der Erweiterungsplatine könnte auch noch die Fähigkeit des Ebusd-esp-Wemos aufgenommen werden, die RX/TX-Pins zu swappen. Dann sind nur 2 Brücken (SJ7 und SJ8) ausreichend

Sehe ich das richtig?.

Du siehst das richtig, aber swappen haben wir ausgiebig getestet und als schlecht empfunden weil dann die Anpassung der Schaltung nicht mehr stimmt. Der Wemos hat an Rx und Tx intern 470 Ohm Widerstande in Reihe geschalten und die Schaltung ist darauf von Galileo so berechnet worden. Wenn du swappst, dann stimmt die Anpassung nicht mehr und es kommt zu Signalverzerrungen. Das hat uns in den ersten Testwochen sehr beschäftig um die Schaltung so zu gestalten, das möglichst viele Komponenten trotz unterschiedlichster Innenwiderstände einsetzbar sind. Galileo hat immer wieder neue Berechnungen anstellen müssen und alle Varianten durchgerechnet. Besonders kritisch war da das Rx Signal, das möglichst ein Rechteck sein sollte und es hat lange gebraucht das so zu erreichen. Die Schaltung sollte auch möglichst unempfindlich auf Streuung der Bauteile sein um Nachbauprobleme von vornherein zu vermeiden.

Wenn du swappst, kann alles perfekt funktionieren, bei anderen vielleicht aber nicht.

Betreffend der Jumper Beschriftung möchte ich trotzdem bei 1-2-3 bleiben, weil das in den Gehirnen so verankert ist, dass man oben links  zu lesen beginnt. Da tauschen wir lieber die Beschriftung im Schaltplan aus, das macht aber Chons in Eagle aber der hat jetzt seinen wohlverdienten Urlaub.

LG

[ihatedenhasen]

ja, das ist in der Tat merkwürdig, muss ich mir anschauen.

Ich schaue da nicht mehr durch, ich habe auch Versionsunterschiede bei ebusd -V und ebusctl info.
Das da "no signal" steht ist schon noch richtig, erst die SW dann geht es den Bus.
Ist das hier so in Ordnung?

Code Auswählen Erweitern

pi@FHEM:~ $ service ebusd status
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-12-30 09:49:48 CET; 1min 5s ago
  Process: 587 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 607 (ebusd)
   CGroup: /system.slice/ebusd.service
           └─607 /usr/bin/ebusd --scanconfig

Dec 30 09:49:48 FHEM systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dec 30 09:49:48 FHEM systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
pi@FHEM:~ $ ebusd -V
ebusd 3.1.v3.0-36-g60a18d1
pi@FHEM:~ $ ebusctl info
version: ebusd 3.0.v3.0-30-g89c4612
signal: no signal

[JHo]

Hallo dkreuz,

habe auch die R12-5W (ebusctl info "MF=Kromschroeder;ID=  ;SW=0121;HW=0107"), da können wir uns ja zusammentun und die Configfiles noch weiter voranbringen. Bin allerdings auf dem Gebiet bisher extremer Laie...

Mir ist auch noch nicht klar wohin ich die _templates.csv und broadcast.csv kopieren muss, nach /etc/ebusd oder in den Unterordner /etc/ebusd/wolf?

Für die _templates steht in Johns Wiki: kopiert in den Geräte-Unterordner = gilt nur für diesen Ordner. Funktioniert, soweit ich das überblicke: ich bekomme jetzt immerhin "sollw" und "betrd" angezeigt.
Für die broadcast mal in den deutlich besser gefüllten Vaillant-Ordner auf github geschaut: da liegt auch eine broadcast.csv drin, dann wird das vergleichbar zu den _templates sein.

Beim installieren der config-deb-files wurde der symlink kromschroeder --> wolf bei mir nicht mit angelegt. Habe das dann als root erledigt, allerdings konnte ebusd dann trotzdem nicht drauf zugreifen - erst, als ich den symlink-Besitzer auf pi:pi geändert habe, ging es.

Viele Grüße,
Jan

[Reinhart]

Welche Bedeutung hat die Option "--address=01" in dem Konfigurationsstring EBUSD_OPTS?

Du vergibst damit der Platine die Adresse 01. Der Dämon vergibt ohne Angabe einer Adresse als Default 31. Wir haben das zum Test gebraucht, weil wir da ja mehre Adapter parallel am Bus hatten.

Achtung: man kann nicht jede beleibige Adresse nehmen, weil darin auch die Priorität kodiert ist und das muss nach der Spezifikation Kapitel 6.2.2.1 passen! Es sind auch nur maximal 25 möglich!

LG
Reinhart

[dkreutz]

Hallo Jan,

habe auch die R12-5W (ebusctl info "MF=Kromschroeder;ID=  ;SW=0121;HW=0107"), da können wir uns ja zusammentun und die Configfiles noch weiter voranbringen. Bin allerdings auf dem Gebiet bisher extremer Laie...

Für die _templates steht in Johns Wiki: kopiert in den Geräte-Unterordner = gilt nur für diesen Ordner. Funktioniert, soweit ich das überblicke: ich bekomme jetzt immerhin "sollw" und "betrd" angezeigt.
Für die broadcast mal in den deutlich besser gefüllten Vaillant-Ordner auf github geschaut: da liegt auch eine broadcast.csv drin, dann wird das vergleichbar zu den _templates sein.

Ja, da können wir uns gerne austauschen. Bei mir wird ja noch nicht die R12 erkannt, bei Dir aber schon? Ich nehme an, Du verwendest das ebus-configuration Release 2.x.x? Ich werde meinen Konfigurationsordner noch einmal leeren und neu installieren..
Vielleicht verlagern wir dann die Detail-Diskussion in den Wolf R12 Thread?

Hallo Reinhart,

Du vergibst damit der Platine die Adresse 01. Der Dämon vergibt ohne Angabe einer Adresse als Default 31. Wir haben das zum Test gebraucht, weil wir da ja mehre Adapter parallel am Bus hatten.

Achtung: man kann nicht jede beleibige Adresse nehmen, weil darin auch die Priorität kodiert ist und das muss nach der Spezifikation Kapitel 6.2.2.1 passen! Es sind auch nur maximal 25 möglich!

Da ich ja nur eBus-Adapter und die Wolf R12 am Bus betreibe, sollte ich ja keine Problee mit den Adressen haben. Wenn ich das richtig verstehe, dann bin ich ohne "--adress=01" auf der sicheren Seite.

VG
Dominik

[Reinhart]

ja genau, bei einer Platine ist es nicht notwendig die Adresse zu ändern!

LG

[Markus.]

Ich schaue da nicht mehr durch, ich habe auch Versionsunterschiede bei ebusd -V und ebusctl info.
Das da "no signal" steht ist schon noch richtig, erst die SW dann geht es den Bus.
Ist das hier so in Ordnung?

Code Auswählen Erweitern

pi@FHEM:~ $ service ebusd status
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-12-30 09:49:48 CET; 1min 5s ago
  Process: 587 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 607 (ebusd)
   CGroup: /system.slice/ebusd.service
           └─607 /usr/bin/ebusd --scanconfig

Dec 30 09:49:48 FHEM systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dec 30 09:49:48 FHEM systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
pi@FHEM:~ $ ebusd -V
ebusd 3.1.v3.0-36-g60a18d1
pi@FHEM:~ $ ebusctl info
version: ebusd 3.0.v3.0-30-g89c4612
signal: no signal

Da wird bei mir die selbe (falsche) Version angezeigt obwohl ich die 3.1 installiert habe..

Gruß

Markus

[john30]

Da wird bei mir die selbe (falsche) Version angezeigt obwohl ich die 3.1 installiert habe..

ja, da ist beim Bauen des Release der Versionstag vom Git Repo nicht aktualisiert worden. Wenn man hat nicht immer an alles denkt...
Relevant ist der vordere Teil (also vor ".v3."):
ebusd 3.1.v3.0-36-g60a18d1

Wenn Du allerdings mit ebusctl info ein anderes Ergebnis als mit ebusd -V bekommst, dann läuft da noch eine alte Version des Dienstes, der bereits auf dem Port 888 lauscht, d.h. auch wenn Du einen neuen startest, kann der nicht mehr den Port verwenden.
Somit musst Du entweder "service ebusd restart" oder "systemctl restart ebusd" aufrufen, oder evtl. das System ein Mal neu starten.
Ob und wieviele Dienste laufen, lässt sich einfach mit "ps ax|grep ebusd|grep -v grep" herausfinden:

Code Auswählen Erweitern

19563 pts/1    Sl+   84:27 ./git/ebusd/src/ebusd/ebusd --pollinterval 5 -c scanconfig -f --loglevel notice --logareas all -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600c16W-if00-port0 --htmlpath ./git/ebusd/contrib/html --httpport 8080 --scanconfig --enablehex --mqttport=1883 --mqtttopic=ebusd0 --mqttjson
19616 pts/5    Sl+   12:18 ./git/ebusd/src/ebusd/ebusd --pollinterval 60 -c scanconfig -f --loglevel notice --logareas all -d udp:192.168.123.99:20107 --latency=80000 -p 8088 --scanconfig=ec --initsend --enablehex --mqttport=1883 --mqtttopic=ebusd1 --mqttjson
24519 pts/6    Sl+   21:27 ./git/ebusd/src/ebusd/ebusd --pollinterval 60 -c scanconfig -f --loglevel notice --logareas all -d tcp:192.168.123.98:20108 --latency=80000 -p 8188 --scanconfig --enablehex --mqttport=1883 --mqtttopic=ebusd2 --mqttjson
Ich starte den Dienst für jeden eBUS separat in einem screen, deshalb sieht das im Normalbetrieb nicht so aus.
Jedenfalls ist in der ersten Spalte die Prozess-ID angegeben und wenn jetzt bspw. mehr als eine Instanz läuft, dann lassen sich diese durch "kill PID" (PID durch diese Prozess-ID ersetzen) beenden (evtl. sudo/su).

[Markus.]

ja, da ist beim Bauen des Release der Versionstag vom Git Repo nicht aktualisiert worden. Wenn man hat nicht immer an alles denkt...
Relevant ist der vordere Teil (also vor ".v3."):
ebusd 3.1.v3.0-36-g60a18d1

Wenn Du allerdings mit ebusctl info ein anderes Ergebnis als mit ebusd -V bekommst, dann läuft da noch eine alte Version des Dienstes, der bereits auf dem Port 888 lauscht, d.h. auch wenn Du einen neuen startest, kann der nicht mehr den Port verwenden.
Somit musst Du entweder "service ebusd restart" oder "systemctl restart ebusd" aufrufen, oder evtl. das System ein Mal neu starten.
Ob und wieviele Dienste laufen, lässt sich einfach mit "ps ax|grep ebusd|grep -v grep" herausfinden:

Code Auswählen Erweitern

19563 pts/1    Sl+   84:27 ./git/ebusd/src/ebusd/ebusd --pollinterval 5 -c scanconfig -f --loglevel notice --logareas all -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600c16W-if00-port0 --htmlpath ./git/ebusd/contrib/html --httpport 8080 --scanconfig --enablehex --mqttport=1883 --mqtttopic=ebusd0 --mqttjson
19616 pts/5    Sl+   12:18 ./git/ebusd/src/ebusd/ebusd --pollinterval 60 -c scanconfig -f --loglevel notice --logareas all -d udp:192.168.123.99:20107 --latency=80000 -p 8088 --scanconfig=ec --initsend --enablehex --mqttport=1883 --mqtttopic=ebusd1 --mqttjson
24519 pts/6    Sl+   21:27 ./git/ebusd/src/ebusd/ebusd --pollinterval 60 -c scanconfig -f --loglevel notice --logareas all -d tcp:192.168.123.98:20108 --latency=80000 -p 8188 --scanconfig --enablehex --mqttport=1883 --mqtttopic=ebusd2 --mqttjson
Ich starte den Dienst für jeden eBUS separat in einem screen, deshalb sieht das im Normalbetrieb nicht so aus.
Jedenfalls ist in der ersten Spalte die Prozess-ID angegeben und wenn jetzt bspw. mehr als eine Instanz läuft, dann lassen sich diese durch "kill PID" (PID durch diese Prozess-ID ersetzen) beenden (evtl. sudo/su).

Wie kann ich den jetzt am saubersten ein Update machen, damit ich die richtige Version angezeigt bekomme?
Ich weiß, ist wohl eher ein "Kosmetisches Problem"..
Bei mir werden ja, wie gesagt, mit beiden Versionsabfragen die selbe Version abgefragt...

Gruß

Markus

[john30]

Code Auswählen Erweitern


pi@FHEM:~ $ ebusd -V
ebusd 3.1.v3.0-36-g60a18d1
pi@FHEM:~ $ ebusctl info
version: ebusd 3.0.v3.0-30-g89c4612

Die beiden Versionen sind unterschieldlich und das kann nur dann passieren, wenn Du bspw. die 3.1 installiert hast, aber den Dienst noch nicht neu gestartet, oder wenn eine alte Dienstinstanz sich nicht beenden mag. Da würde ich einfach mal das System booten, dann ist da sicher alles wieder weg. Oder halt Dienst beenden und dann mit kill noch evtl. verbleibende Instanzen beenden und dann erst den Dienst wieder starten.

[john30]

Wie kann ich den jetzt am saubersten ein Update machen, damit ich die richtige Version angezeigt bekomme?

Im Moment gar nicht, außer Du baust das Release selbst nach git pull etc.
EDIT: mit der nächsten Release 3.2 ist das hoffentlich erledigt, hab gerade die Build Scripts angepasst.

[dkreutz]

ja, da ist beim Bauen des Release der Versionstag vom Git Repo nicht aktualisiert worden. Wenn man hat nicht immer an alles denkt...
Relevant ist der vordere Teil (also vor ".v3."):
ebusd 3.1.v3.0-36-g60a18d1

Ich habe ein Raspberry Pi3 mit Jessie und ebusd-3.1_armhf-jessie.deb vom 26.12. installiert.

Code Auswählen Erweitern

$ ebusd -V
ebusd 3.0pre.bbc4d04
Auch nach Neuinstallation (mit vorherigen dpkg purge/remove) und Neustart des Raspberry bleibt das so. Ist das auch ein kosmetischer Fehler - bei Markus., der ja anscheinend auch einen Raspberry hat, wird ja eine andere Versionsnummer angezeigt?

[ihatedenhasen]

Die beiden Versionen sind unterschieldlich und das kann nur dann passieren, wenn Du bspw. die 3.1 installiert hast, aber den Dienst noch nicht neu gestartet, oder wenn eine alte Dienstinstanz sich nicht beenden mag. Da würde ich einfach mal das System booten, dann ist da sicher alles wieder weg. Oder halt Dienst beenden und dann mit kill noch evtl. verbleibende Instanzen beenden und dann erst den Dienst wieder starten.

Code Auswählen Erweitern

pi@FHEM:~ $ sudo ps ax|grep ebusd|grep -v grep
  607 ?        Ssl    0:14 /usr/bin/ebusd --scanconfig
reboot natürlich schon öfters durchgeführt. Möchte doch nur ein sauberes System haben ....