eBUS Adapter 3.0 Inbetriebnahme

[john30]

Eine Frage hätte ich noch zum Scannen: Wenn ebusd startet, bekomme ich von dem CC und HWC (Adresse 23 und 25) sehr oft den Fehler

Code Auswählen Erweitern

[main error] scan config 23: ERR: read timeout

das heißt, dass das Gerät nicht rechtzeitig antwortet. Sollte eigentlich nicht passieren, aber ich bräuchte mehr Kontext, um das besser beurteilen zu können. Also bspw. mal raw log anschalten, wo man dann das Timing genau sehen kann.
Hast Du die "--latency=" eingestellt?

Eine ganz dumme Frage hätte ich noch: Was bedeutet BAI ausgeschrieben?

das weiß ich auch nicht. Das ist die ID, mit der sich das Gerät meldet. Bspw. "EHP" steht für eletric heat pump, oder "HWC" steht für hot water circuit und CC für circulation circuit.

[raimundl]

Guten Morgen!
Da nun alles problemlos läuft eine Frage zum traffic am ebus:

Dieses Thema wird ja sehr häufig diskutiert - ich kann jedoch keinen Schluss daraus für mich ziehen.
Viele der Aktualisierungen am ebus finden bei mir alle 10 Sekunden statt. Ist diese Aktualisierungsfrequenz im Hinblick auf eine eventuelle Belastung des Gerätes in Ordnung?
Oder sollte man nur aktiv den ebus mit bestimmten Werten abfragen?

[Pretender]

Ohne --scanconfig hast Du ihm diese Auswahl bereits abgenommen, indem Du nur die für Deine Anlage relevanten Dateien in den --configpath gelegt hast. Der ebusd läd dann einfach von vornherein immer sämtliche Dateien, die er dort findet.

Alles klar! Man sollte dann auch die include-Dateien löschen, die man nicht benötigt richtig? Das 08.bai.csv zieht ja die inc-Datei an, die dem Scanergebnis entspricht. Bei mir wird die bai.308523.inc geladen, d.h. das "last resort" wenn man so sagen will. Aber ansonsten müsste ich doch in die csv reinschreiben:

Code Auswählen Erweitern

!load,bai.<meine-anlage>.inc,,,
Denn mehrere incs enthalten z.B. den Wert WaterHcFlowMax und dann gewinnt wahrscheinlich die zuletzt geladene Konfiguration.

Danke und viele Grüße
Reinhard

[Pretender]

Also bspw. mal raw log anschalten, wo man dann das Timing genau sehen kann.
Hast Du die "--latency=" eingestellt?

Ja. Meine Startparameter sehen so aus:

Code Auswählen Erweitern

EBUSD_OPTS="--scanconfig --configpath=/etc/ebusd --accesslevel=* --mqttport=1883 --mqtthost=localhost --mqtttopic=ebusd/%circuit/%name --latency=20000 -d enh:/dev/ttyAMA0 --log=all:error --log=main:info --log=bus:info --address=ff"

Den Latenzwert habe ich nicht verändert.

Was brauchst du beim Raw Log genau?
Reicht es bei laufendem ebusd unter ebusctl raw logging zu aktivieren, ein scan Kommando abzusetzen und dann wieder deaktivieren, oder brauchst du das ab Start des ebusd?

Danke Dir und viele Grüße
Reinhard

[chris371]

eine Frage zum traffic am ebus:
Dieses Thema wird ja sehr häufig diskutiert - ich kann jedoch keinen Schluss daraus für mich ziehen.
Viele der Aktualisierungen am ebus finden bei mir alle 10 Sekunden statt. Ist diese Aktualisierungsfrequenz im Hinblick auf eine eventuelle Belastung des Gerätes in Ordnung?

Ich tue mich auch etwas schwer damit, mich für ein bestimmtes Vorgehen zu entscheiden. Aber ich verstehe auch nicht ganz, was Du mit "Aktualisierungen" meinst.

• Der Bus ist ja dazu da, damit sich die einzelnen Komponenten der Heizungsanlage unterhalten können. Das tun sie ganz unabhängig vom ebusd und dem Adapter natürlich auch. Normalerweise passiert das in einem bestimmten Rhythmus, der sich der Hersteller so ausgedacht hat, und ist natürlich in dieser Form damit auch vollkommen okay. Man weiß aber nie, ob/wann sich dieser Rhythmus vielleicht auch mal im Betrieb ändern könnte.
• Diesen Traffic kann man mit dem ebusd gefahrlos "belauschen" und diese Daten verwenden. Egal, wie viele "Aktualisierungen" da pro Zeit passieren.
• Potentiell heikel wird es erst, wenn der ebusd selber aktiv auf den Bus zugreift. Dann wäre es denkbar, dass er damit die Kommunikation der restlichen Teilnehmer durcheinanderbringt.

Die gute Nachricht ist, dass man dieses Risiko durch die Wahl der (ja auch hier empfohlenen) --address=ff recht klein halten kann. Diese Master-Adresse für den ebusd sorgt zusammen mit dem Arbitrierungsmechanismus aus der eBus-Spezifikation dafür, dass der ebusd keinen der anderen Master vom Bus "verdrängen" kann - WENN sich denn alle Geräte exakt an die Spezifikation halten und auch keine Bugs in der Implementation (auch bei den Geräten der vorhandenen Heizung!) schlummern.

Da alle Entwickler nur Menschen sind und wir nun mal Fehler machen, kann man also nie ganz ausschließen, dass aktives Senden des ebusd "irgendwas" der normalen Buskommunikation durcheinanderbringt. Daher kann eigentlich fürs aktive Senden nur gelten:
So wenig wie möglich und nur so viel wie nötig.

[chris371]

Man sollte dann auch die include-Dateien löschen, die man nicht benötigt richtig? Das 08.bai.csv zieht ja die inc-Datei an, die dem Scanergebnis entspricht.

Gute Frage. Das Scan-Ergebnis liegt ja bei der statischen Konfiguration gar nicht vor. Mal sehen, was John dazu sagt. 

[raimundl]

Ich tue mich auch etwas schwer damit, mich für ein bestimmtes Vorgehen zu entscheiden. Aber ich verstehe auch nicht ganz, was Du mit "Aktualisierungen" meinst.

Die gute Nachricht ist, dass man dieses Risiko durch die Wahl der (ja auch hier empfohlenen) --address=ff recht klein halten kann. Diese Master-Adresse für den ebusd sorgt zusammen mit dem Arbitrierungsmechanismus aus der eBus-Spezifikation dafür, dass der ebusd keinen der anderen Master vom Bus "verdrängen" kann - WENN sich denn alle Geräte exakt an die Spezifikation halten und auch keine Bugs in der Implementation (auch bei den Geräten der vorhandenen Heizung!) schlummern.

Danke Chris371!
Mit dieser Aussage habe ich meine Entscheidung getroffen - das Busgeschehen werde ich nicht beeinflussen, meine abgesetzten read/write Befehle halten sich wirklich in Grenzen. Daher widme ich mich nun der Visualisierung der Werte.
LG

[Gurker]

errorhistory braucht noch eine Eingabe, da das eine Liste von Messages ist mit Index.
die "restlichen" zu dekodieren ist halt Fleißarbeit. Messages als hex anschauen (bspw. via grab result) und passende Werte identifizieren und Datentypen zuordnen (da hilft evtl. auch grab result decode).

Vielleicht hier eine Frage, ich habe inzwischen mit grab "herumgespielt" - es ist in der Tat Fleißarbeit, und was ggf helfen würde, was ich aber noch nicht gefunden habe. Einen Sniffer gibt es nicht, oder? Also die Möglichkeit das ganze zur Laufzeit auch schon gruppiert zu bekommen.
Beispiel wäre dann die Datenbytes in der Anzeige laufend zu überschreiben wenn von gleicher Quelle an das gleiche Ziel mit gleicher Dienstgruppe Daten gesendet wird. Würde mir helfen... bin ich zu blöd das einzustellen?

[Hispanic]

Hallo,

ich melde mich jetzt auch mal zu Wort. Habe den Adapter jetzt bereits seit 27.01.2021 und ihn am 31.01.2021 mit einem Wemos D1 Mini in Betrieb genommen.
Alle aktuellen Builds sowohl auf den ESP8266 als auch beim ebusd installiert (hatte für die Testphase noch ältere Versionen drauf, dank DHL kam es ja aber nicht dazu  ).
Seit diesem Datum lief alles auch ohne Probleme zusammen mit HomeAssistant und der ebusd Integration. Habe dann zwischenzeitlich noch begonnen über MQTT weitere Werte abzurufen, bin aber bei ersten Tests bei einem hängen geblieben und seitdem fehlte die Zeit das ganze komplett über MQTT abzufragen ohne die ebusd-Integration.
Nun fiel mir aber am Sonntag (11.04.2021) plötzlich auf, dass keine neueren Daten mehr kommen. Erste Vermutung HomeAssistant macht quatsch (dort bastelt man ja am meisten rum), also Docker neu gestartet, aber nichts...
Wieder zu Hause nach geschaut, LEDs am Adapter blinken weiterhin schön vor sich hin, auch der Wemos blinkt wie immer. Trotz allem dort mal auf die Weboberfläche geschaut. Trotz blinken stand dort das keine Verbindung zum Bus bestehen würde, also neu gestartet. Läuft.

Kennt ihr das schon, ist das nach den knappen 2,5 Monaten ein Speichervolllaufen oder ähnliches?
In der Weboberfläche stand noch was von freeHeap oder so, das hat sich nach dem Neustart als einzigstes merklich geändert.

[jutonium]

@Hispanic:
Ist mir auch so passiert, aber mit einem eBus Adapter mit Ethernet (USR-ES1). Ich denke, dass der Adapter ca. 2 Wochen lief.
Am 19.04. gegen 4:20 kamen die letzten Werte im Home Assistant an.
Adapter war nicht pingbar, mehrfach neu gestartet, anderer Port am Switch und der Adapter hat wieder eine IP bekommen und war pingbar. Aber ebusd konnte nicht mit dem Adapter kommunizieren.

ebusd:

Code Auswählen Erweitern


2021-04-19 21:21:30.370 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device 192.168.x.x:9999
2021-04-19 21:21:30.382 [bus error] unable to open 192.168.x.x:9999: ERR: generic I/O error
2021-04-19 21:21:30.383 [bus notice] bus started with own address 31/36
2021-04-19 21:21:30.383 [bus notice] device invalid
2021-04-19 21:21:35.383 [bus error] unable to open 192.168.x.x:9999: ERR: generic I/O error

Wobei sich die letzten beiden Zeilen wiederholt haben.
Nachdem der Adapter eine Weile stromlos war, konnte ebusd wieder Kontakt aufnehmen.
Die fraglichen Ports am Switch waren in einem Test alle in Ordnung.

Ähnlich wie hier:
https://forum.fhem.de/index.php/topic,116418.msg1117577.html#msg1117577

[DieterPN]

Hallo,

ich bin mit meinem eBUS Adapter vom Raspberry PI 3+ auf einen PI 4 gewechselt und habe alles neu installiert.

'ebusd' läuft wie vorher aber ich kann keinen Autostart einrichten:

sudo systemctl enable ebusd
ebusd.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ebusd

Habt ihr Tipps was ich anders machen muss?

Grüße

Dieter

[Pretender]

sudo systemctl enable ebusd
ebusd.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ebusd

Moin,

Du nutzt die deb-Pakete zur Installation?
Da hatte ich das Problem auch. Ich bin mit der aktuellen Version (21.2) in das Abenteuer ebus gestartet, daher keine Ahnung wie es vorher war.
Wenn Du Dir den Paketinhalt ansiehst, wirst du sehen, dass kein systemd Servicefile vorhanden ist.
Ich habe mir das daher direkt aus Github geholt, https://github.com/john30/ebusd/tree/master/contrib/debian/systemd.
Das kopierst Du dann nach /usr/lib/systemd/system/ und passt ggf. die Rechte analog zu den anderen Service-Dateien an.
Evtl. ist noch ein systemctl daemon-reload notwendig. Danach solltest Du ebusd wie gewohnt steuern können.

Grüße
Reinhard

[Hispanic]

@Hispanic:
Ist mir auch so passiert, aber mit einem eBus Adapter mit Ethernet (USR-ES1). Ich denke, dass der Adapter ca. 2 Wochen lief.
Am 19.04. gegen 4:20 kamen die letzten Werte im Home Assistant an.
Adapter war nicht pingbar, mehrfach neu gestartet, anderer Port am Switch und der Adapter hat wieder eine IP bekommen und war pingbar. Aber ebusd konnte nicht mit dem Adapter kommunizieren.

[...]

Wobei sich die letzten beiden Zeilen wiederholt haben.
Nachdem der Adapter eine Weile stromlos war, konnte ebusd wieder Kontakt aufnehmen.
Die fraglichen Ports am Switch waren in einem Test alle in Ordnung.

Ähnlich wie hier:
https://forum.fhem.de/index.php/topic,116418.msg1117577.html#msg1117577

Ich gehe hier sogar über WLAN, da hat der ESP ja sogar noch eine eigene Firmware.
Das ganze läuft ansich auch total stabil, bis auf den einen kleinen Hänger.
Gibt es in irgendwelchen Optionen oder ähnlichem die Möglichkeit den ESP aus der Heimautomatisierung neu zu starten?
Ich werde mich wieder melden sobald das Problem noch einmal auftreten sollte, eventuell möchte das dann jemand Live untersuchen?

[Reinhart]

du könntest einen Watchdog mit einem notify einrichten, der irgend einen Wert vom eBus überwacht ( zB: Disconnected oder Vorlauf Error ) und dann einen "reopen" einleitet.

Code Auswählen Erweitern

define EBUS.Watchdog notify (EBUS.*DISCONNECTED.*)|(Vorlauf:Vorlauf.*err) { EBUSrecover("notify EBUS.Watchdog",0)}
attr EBUS.Watchdog group ECMD
attr EBUS.Watchdog icon dog_silhouette

die Definition in Fhem, bei "Vorlauf error" wird die Subroutine "EBUSrecover" aufgerufen

Code Auswählen Erweitern

sub EBUSrecover($$)
{   
  my ($evt,$num) = @_;
  Log 1,"[EBUS] Recover triggered from $evt, attempt No. $num";
  if(Value("EBUS") ne "opened"){
    if( $num < 7){
      $num++;
      fhem("set EBUS reopen");
      DebianMail('Ausfall eBus FHEM','Ausfall Ebus, reconnect wird versucht');
      fhem("define EBUSrecoverdly at +00:01:00   
            {EBUSrecover('EBUSrecover',$num)}");
    }else{
      fhem("set Device.warn EBUS")
    }
  }
}
und hier die Subroutine dazu die man in die 99_myUtils legen kann. Es wird ein "reopen" initiiert! Hier wird auch noch eine Mail abgesetzt damit ich das mitbekomme.

Den ESP kannst dabei aber so nicht neu starten, dazu müsstest du die Spannungsversorgung gleichzeitig kurz unterbrechen.

LG

[DieterPN]

Ich habe mir das daher direkt aus Github geholt, https://github.com/john30/ebusd/tree/master/contrib/debian/systemd.
Das kopierst Du dann nach /usr/lib/systemd/system/ und passt ggf. die Rechte analog zu den anderen Service-Dateien an.
Evtl. ist noch ein systemctl daemon-reload notwendig. Danach solltest Du ebusd wie gewohnt steuern können.

Danke! Hat funktioniert.