eBus Schaltung V2 in Betrieb nehmen

[john30]

Oder gibt es für das CRC-Problem eine andere Lösung?

eine andere Lösung, als dafür zu sorgen, dass alle Bytes wohlbehalten bei ebusd ankommen, sehe ich nicht

[ClausL]

Hallo,

eine andere Lösung, als dafür zu sorgen, dass alle Bytes wohlbehalten bei ebusd ankommen, sehe ich nicht

ja, aber viele Wege führen nach Rom. Und vieleicht weiß ja jemand eine Abkürzung. . Ist aber wohl nicht mehr erforderlich. Die Daten kommen jetzt wieder gut rüber. Nun wird die alte Hardware untersucht.

Ach ja, die für einen Abgleich so wichtige Sequenz <aa finde ich bei mir nicht. Es ist anscheinend zuviel los auf diesem Bus. ebusctl info liefert inzwischen 1134 messages.

Viele Grüße, Claus

[john30]

Ach ja, die für einen Abgleich so wichtige Sequenz <aa finde ich bei mir nicht. Es ist anscheinend zuviel los auf diesem Bus.

das kann nicht sein, denn ohne "<aa" geht auf dem eBUS überhaupt nichts.
Hast Du evtl. die alte Anleitung für einen älteren ebusd genutzt? Inzwischen muss man statt "--lograwdata" nämlich "--lograwdata=bytes" verwenden.

[ClausL]

Hallo,

das kann nicht sein, denn ohne "<aa" geht auf dem eBUS überhaupt nichts.
Hast Du evtl. die alte Anleitung für einen älteren ebusd genutzt? Inzwischen muss man statt "--lograwdata" nämlich "--lograwdata=bytes" verwenden.

Das ist so gewesen. Ich habe mich da an die Anleitung aus dem Wiki gehalten. Da lauten die Optionen noch ganz anders. Ich habe das eben mit dieser Option ausprobiert.  Und jede Menge <aa gesehen.

Ansonsten funktioniert es jetzt recht Ordentlich. Die vorhandenen Geräte werden schnell und zuverlässig erkannt.

Ich habe nur noch einen Bus-Error. Den aber immer nur bei einem Wert.

2018-05-01 00:00:19.238 [bus error] poll ui YieldThisYear failed: ERR: arbitration lost

Einige Sekunden später kommt der Wert dann:

2018-05-01 00:00:33.259 [bus notice] poll ui YieldThisYear: 3;52;102;230;0;0;0;0;0;0;0;0

Verwunderlich ist dabei, nur dieser Wert kommt als "bus error" oder "bus notice". Die übrigen Werte kommen als "update notice". Und das verstehe ich noch nicht wirklich.

Viele Grüße, Claus

[ClausL]

Hallo,

ich glaube, ich steh auf dem Schlauch. Nachdem nun die Hardware stabil arbeitet, habe ich noch einige Verständnisprobleme. Wenn ich ebusctl info absetze, erhalte ich das folgende ergebnis:

Code Auswählen Erweitern


version: ebusd 3.1.p20180428
update check: revision v3.1-1-g60a18d1 available, broadcast.csv: different version available, vaillant/06.pms.csv: different version available, vaillant/0a   .pmw.hwc.csv: different version available, vaillant/15.ui.csv: different version available, vaillant/26.solsy.hc.csv: different version available, vaillant   /52.mc2.mc.4.cs
access: *
signal: acquired
symbol rate: 43
max symbol rate: 407
min arbitration micros: 708
max arbitration micros: 7918
min symbol latency: 0
max symbol latency: 21
reconnects: 0
masters: 5
messages: 1139
conditional: 26
poll: 1
update: 10
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0204;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=UI   ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address 52: slave, scanned "MF=Vaillant;ID=MC2  ;SW=0500;HW=6301", loaded "vaillant/52.mc2.mc.4.csv"
address 53: slave, scanned "MF=Vaillant;ID=MC2  ;SW=0500;HW=6301", loaded "vaillant/53.mc2.mc.5.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"


Das meiste sieht ja gut aus. Aber warum werden den Adressen 12, 25 und fc keine cvs zugeordnert. Für 12 gibt es einen Link, der 12.pwm.sc.csv heißt. Für 25 gibt es 25.solsy.hwc.csv und für fc gibt es fc.pwm.sc.csv. Müssten die nicht geladen werden?

Mein rückständiger Versionsstand ist dem aktuellen Raspbian geschuldet. Dies kann den aktuellen ebusd nicht automatisch laden. Warum diverse csv veraltet sein sollen, ist mir auch schleierhaft. git pull ergibt "Bereits aktuell" (eben nochmal probiert).

Dann habe ich immer noch öfter einen bus error mit dem Hinweis arbitration lost. Ich starte den ebusd mit den folgenden Optionen:

Code Auswählen Erweitern

EBUSD_OPTS="--scanconfig -d /dev/ttyUSB0 -p 8888 -l /var/log/ebusmqt.log --accesslevel=* --mqtthost=192.168.178.34 --mqttport=1883 --mqttjson --mqtttopic=sonoff_ebus/%circuit/%name  --receivetimeout=75000"

receivetimeout habe ich eingefügt, weil ich hoffte, damit den Fehler "arbitration lost" los zu werden. Hat aber nichts gebracht. Mehr Möglichkeiten zu schrauben habe ich nicht gefunden. Was aber auch an meinen nur marginal vorhandenen Englisch-Kenntnissen liegen kann. .

MQTT läuft noch nicht so richtig bei mir. Was aber mehr an der abnehmenden Seite liegt.

Viele Grüße und schon im Vorraus vielen Dank für jede Hilfe, Claus

[john30]

warum werden den Adressen 12, 25 und fc keine cvs zugeordnert. Für 12 gibt es einen Link, der 12.pwm.sc.csv heißt. Für 25 gibt es 25.solsy.hwc.csv und für fc gibt es fc.pwm.sc.csv. Müssten die nicht geladen werden?

vielleicht warst du einfach etwas zu schnell, das Laden läuft asynchron mit gewissem zeitlichen Abstand.
Und *.pwm.*.csv passt natürlich nicht zu einem Device, das sich als PMW... identifiziert.

Dann habe ich immer noch öfter einen bus error mit dem Hinweis arbitration lost.

das kann bei der Menge an Geräten an Deinem Bus schon mal passieren.

[ClausL]

Hallo, John

pwm ist natürlich ein Schreibfehler. Das kommt davon, wenn die Finger zu dick sind und man alle 10 zum schreiben nimmt . Das Gerät identifiziert sich mit PMW01 und der Link heißt 12.pmw.sc.csv. Den Rest habe ich dann aber richtig geschrieben. Und was zu früh angeht: Ich habe heute morgen nochmal abgefragt. Das Ergebnis hat sich nicht geändert. Und seit gestern ist auf dem Raspi in der Heizung nichts mehr passiert. Also kein Neustart oder sowas. Auch den ebusd habe ich in Ruhe gelassen.

Hinsichtlich der Bus Error wäre ich beruhigt, wenn diese nicht ausschließlich bei einem Wert auftauchen würden. Ich habe eben nochmal einen größeren Teil des aktuellen Protokolls überprüft. Einen Bus Error habe ich nur bei dem Wert YieldThisYear. Ich werde da also doch noch weiter suchen.

Was das Problem mit dem Autostart angeht, habe ich noch einen Hinweis. Das Problem gibt es wohl nur auf dem Raspberry mit dem aktuellem Raspbian. Ich hatte vorher den ebusd auf einem Thin Client mit Debian Stretch laufen. Da war das Problem nicht vorhanden.

Viele Grüße und einen schönen Sonntag, Claus

[ClausL]

Hallo An Alle 

Ich glaube ich brauche Hilfe. 

Habe Raspberry nach Anleitung von Reinhardt installiert.

Bei mir geht der Autostart nicht richtig.

Code Auswählen Erweitern


pi@raspberrypi2:~ $ sudo systemctl status ebusd
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/etc/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: [color=red]failed[/color] (Result: exit-code) since Fri 2018-04-27 12:13:56 CEST; 2min 8s ago
  Process: 441 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=22)

Apr 27 12:13:56 raspberrypi2 systemd[1]: [color=red]Failed to start ebusd, the daemon for communication with eBUS heating systems..[/color]
Apr 27 12:13:56 raspberrypi2 systemd[1]: ebusd.service: Unit entered failed state.
Apr 27 12:13:56 raspberrypi2 systemd[1]: ebusd.service: Failed with result 'exit-code'.
Apr 27 12:13:56 raspberrypi2 systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Apr 27 12:13:56 raspberrypi2 systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Apr 27 12:13:56 raspberrypi2 systemd[1]: ebusd.service: Start request repeated too quickly.
Apr 27 12:13:56 raspberrypi2 systemd[1]: [color=red]Failed to start ebusd, the daemon for communication with eBUS heating systems..[/color]
Apr 27 12:13:56 raspberrypi2 systemd[1]: ebusd.service: Unit entered failed state.
Apr 27 12:13:56 raspberrypi2 systemd[1]: ebusd.service: Failed with result 'exit-code'.
pi@raspberrypi2:~ $ sudo systemctl start ebusd
pi@raspberrypi2:~ $ sudo systemctl status ebusd
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/etc/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: [color=green]active (running) [/color]since Fri 2018-04-27 12:16:27 CEST; 5s ago
  Process: 2173 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 2174 (ebusd)
   CGroup: /system.slice/ebusd.service
           └─2174 /usr/bin/ebusd -d 192.168.178.141:8891 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01

Apr 27 12:16:27 raspberrypi2 systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Apr 27 12:16:27 raspberrypi2 systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi2:~ $



Nach reboot kommt der Fehler und wenn ich Sekunden danach manuell starte läuft ebusd

Wo ist der Fehler

Vorab schon mal Danke

VG Lutz

Hallo, Lutz

ich habe mich heute nochmal mit diesem Problem beschäftigt. Bei mir startet der aus den aktuellen Quellen neu übersetzte ebusd jetzt zuverlässig, wenn in der Datei ebusd.service nach der Zeile Restart=always noch RestartSec=15 eingesetzt ist. Die Zeit kann man sicher auch kürzer wählen.

Viele Grüße, Claus

[carlos]

Hallo,
Ich habe jetzt auch eine ebus Platine V2 in Betrieb genommen.
Ich habe sie noch nicht am ebus meiner Heizung angeschlossen, weil ich erst so testen wollte ob alles funktioniert.
Mein Problem ist folgendes, Im Webinterface wird immer folgendes angezeigt:

Code Auswählen Erweitern

Build: 20171230
Chip ID: 003405cc
CPU frequency: 80
Free heap: 37000
Hostname: ebus-3405cc
ebusd device string: 192.168.178.191:9999
ebusd connected: no
eBUS signal: no signal
Der ebus daemon läuft aber mit folgender Konfiguration:

Code Auswählen Erweitern

--scanconfig -d 192.168.178.191:9999 -l /var/log/ebusd.log -c /etc/ebusd --latency=20000 --loglevel=debug --receivetimeout=50000

müsste dann nicht ebusd connected: yes angezeigt werden?
Wenn ich mit telnet 192.168.178.191 9999 drauf gehe kommt:

Code Auswählen Erweitern

ebusd connected: yes (inactive)

Was ist hier falsch oder ist das ok so?

Gruß

Carlos

[john30]

müsste dann nicht ebusd connected: yes angezeigt werden?

im Prinzip schon, aber mangels Signal könnte das schon sein

[john30]

ich habe mich heute nochmal mit diesem Problem beschäftigt. Bei mir startet der aus den aktuellen Quellen neu übersetzte ebusd jetzt zuverlässig, wenn in der Datei ebusd.service nach der Zeile Restart=always noch RestartSec=15 eingesetzt ist. Die Zeit kann man sicher auch kürzer wählen.

es wäre mal interessant, was da fehlt. das sollte eigentlich aus dem syslog ersichtlich sein. Ich vermute, dass die Devices noch nicht alle "fertig" sind zu dem Zeitpunkt, an dem ebusd gestartet wird.

[john30]

Hinsichtlich der Bus Error wäre ich beruhigt, wenn diese nicht ausschließlich bei einem Wert auftauchen würden. Ich habe eben nochmal einen größeren Teil des aktuellen Protokolls überprüft. Einen Bus Error habe ich nur bei dem Wert YieldThisYear. Ich werde da also doch noch weiter suchen.

der Wert ist insofern etwas speziell, als das sich die Message aus mehreren Teilen zusammensetzt. Da braucht es schon 12 einzelne Nachrichten, um alle Teile zusammen zu bekommen. Und dass da dann eine mal nicht klappt, ist also deutlich wahrscheinlicher.

Bzgl. des arbitration Themas wäre es aber generell interessant, welche ebusd Version Du nutzt. Da war mal eine Änderung in den letzten Wochen (oder Monaten), die dafür sorgt, dass bei Arbitration Problemen nicht sofort aufgegeben wird.

Seit heute gibt es jetzt auch die ebusd 3.2 Release, vielleicht magst Du das mal ausprobieren.

[ClausL]

Hallo, John

vielen Dank für die Antwort. Die neue Version wäre bis gesten noch etwas problematisch gewesen. Aber heute vormittag konnte ich das Autostartproblem auf dem Raspberry lösen (siehe etwas weiter oben). Daher läuft jetzt bei mir die Version 3.1.v3.1-64-g35afd99. Ich nehme an, dass ist die Neue. Hinsichtlich des problematischen Wertes gingen meine Überlegungen auch schon in diese Richtung. In den nächsten Tagen will ich den Raspi gegen einen Orange Pi Zero austauschen. Ich denke der Raspi 3 ist nur mit dem ebusd doch etwas unterfordert. Dann werde ich nochmal die selbst verlegten Kabel überprüfen und alle Schrauben festziehen. Und wenn das nicht weiter hilft, werde ich mich zurück lehnen und darauf vertrauen, dass mich der Fehler nicht weiter stört. Im Moment scheint das so zu sein.

Was mich wundert ist, dass ich immer noch den Hinweis auf etliche neuere CSV-Dateien bekomme. Wenn ich aber im Verzeichnis ebusd-configuration sudo git pull auslöse, bekomme ich "Bereits aktuell".

Viele Grüße, Claus

[carlos]

Hallo John,
Willst du mir damit sagen ich soll den ebus anschließen und dann sollte es funktionieren?
Komisch finde ich nur, dass der telnet von ebus host ein connected liefert.
Habe den ebusd jetzt auf eine PI2 umgezogen, gleiches Verhalten.
Na dann werde ich mal das ebus Kabel anschließen.
Gruß
Carlos

[john30]

Willst du mir damit sagen ich soll den ebus anschließen und dann sollte es funktionieren?

davon gehe ich aus.

Komisch finde ich nur, dass der telnet von ebus host ein connected liefert.

hm, das ist in der Tat seltsam. Allerdings hat die Anzeige einen Timeout, sprich wenn kein Traffic nach dem Verbindungsaufbau stattfindet, dann geht die Firmware davon aus, dass die Verbindung unterbrochen ist. Das wird es vermutlich sein.