Adapter: ebus

[A Former User]

Mal was zum Probieren :

ebusctl find -F circuit,name,comment

tail -f /var/log/ebusd.log

ebusctl info

Spoiler

version: ebusd 22.2.p20220227
update check: revision v22.2 available
device: /dev/ttyUSB0
signal: acquired
symbol rate: 23
max symbol rate: 168
min arbitration micros: 325
max arbitration micros: 5564
min symbol latency: 5
max symbol latency: 10
reconnects: 0
masters: 4
messages: 644
conditional: 3
poll: 0
update: 10
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0602;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

Viel Erfolg beim Probieren

[Dirk99]

@dreistein said in Adapter: ebus:

ebusctl info

das sieht bei mir wie folgt aus. Ich vermute es liegt am EMM00, denn das kann ich in keiner csv finden.

root@ebusd:~# ebusctl info
version: ebusd 22.2.p20220227
update check: revision v22.2 available
device: /dev/ttyUSB0
signal: acquired
symbol rate: 23
max symbol rate: 58
min arbitration micros: 248
max arbitration micros: 7901
min symbol latency: 0
max symbol latency: 21
reconnects: 0
masters: 4
messages: 14
conditional: 0
poll: 0
update: 2
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0704;HW=7603", loaded "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=EMM00;SW=0104;HW=8503"
address 31: master #8, ebusd
address 36: slave #8, ebusd

[Dirk99]

@dirk99
Ich bekomme jetzt schon mal die Werte, indem ich eine andere CSV auf die 15.emm.cvs mit Symlink verwiesen habe, danke für den Support

[Sandmanyz]

Bei mir erscheinen dauerhaft unzählige Fehlermeldungen. Wie kann ich die abstellen?
Installiert ist der ebus-Adapter in der Version 3.0.2 und der ebus Daemon in der Version 22.2.
Die Werte werden ordnungsgemäß von der Heizung abgeholt obwohl diese Fehler erscheinen. Es betrifft meines Erachtens nur die Datenpunkte die ich im ebus-Adapter unter "ABGEFRAGTE DATENPUNKTE" eingetragen habe.

ebus.0	2022-06-14 08:45:17.359	info	all http done
ebus.0	2022-06-14 08:45:17.321	info	found ebusd update version version 22.3, vaillant/08
ebus.0	2022-06-14 08:45:17.317	info	found ebusd version 22.2
ebus.0	2022-06-14 08:45:16.533	error	max retries, skip cmd read -f Hc1HeatCurve
ebus.0	2022-06-14 08:45:16.532	error	sent read -f Hc1HeatCurve , received ERR: arbitration lost for {"circuit":"","name":"Hc1HeatCurve","parameter":""}
ebus.0	2022-06-14 08:45:15.965	error	sent read -f Hc1HeatCurve , received ERR: arbitration lost for {"circuit":"","name":"Hc1HeatCurve","parameter":""}
ebus.0	2022-06-14 08:45:15.398	error	sent read -f Hc1HeatCurve , received ERR: arbitration lost for {"circuit":"","name":"Hc1HeatCurve","parameter":""}
ebus.0	2022-06-14 08:45:14.831	error	sent read -f Hc1HeatCurve , received ERR: arbitration lost for {"circuit":"","name":"Hc1HeatCurve","parameter":""}
ebus.0	2022-06-14 08:45:14.263	error	sent read -f Hc1HeatCurve , received ERR: arbitration lost for {"circuit":"","name":"Hc1HeatCurve","parameter":""}
ebus.0	2022-06-14 08:45:13.696	error	sent read -f Hc1HeatCurve , received ERR: arbitration lost for {"circuit":"","name":"Hc1HeatCurve","parameter":""}
ebus.0	2022-06-14 08:40:29.980	info	all http done
ebus.0	2022-06-14 08:40:29.933	info	found ebusd update version version 22.3, vaillant/08
ebus.0	2022-06-14 08:40:29.926	info	found ebusd version 22.2

[MassiveAttack]

@sandmanyz
"arbitration lost" bekomme ich auch manchmal, vielleicht fragst du auch zu schnell die Werte ab.

In diesem Fall verstehe ich die Abfrage ohnehin nicht, was soll sich an der Heizkurve ändern? Die stellst du einmal ein, und änderst sie im optimalen Fall nie wieder.

[Rene_HM]

@sandmanyz sagte in Adapter: ebus:

Bei mir erscheinen dauerhaft unzählige Fehlermeldungen. Wie kann ich die abstellen?

Die Ursache des Fehlers sind Kollisionen auf dem Bus. Die Abfagen müssen in eine Lücke passieren, während andere Busteilnehmer gerade nichts senden. Wenn man zu viele Daten zu häufig abfragt, werden die Lücken immer kleiner und das führt zu dem Fehler: also weniger Daten in größeren Zeitabständen abfragen, dann ist die Wahrscheinlichkeit einer Kollision auf dem Bus geringer

[Sandmanyz]

@rene_hm @MassiveAttack
Danke für eure Antworten.

Ich sehe im ioBroker Protokoll, dass alle fünf Minuten ein Fehlereintrag erscheint. Warum passiert alle fünf Minuten etwas wenn nirgends fünf Minuten konfiguriert sind? Habt Ihr eine Idee?

Die Zeitplanung der Instanz ist auch auf 60 Minuten konfiguriert...

[Rene_HM]

@sandmanyz Der Adapter ist seit 3.0 kein "scheduled" Adapter mehr, sondern ein ganz normaler, der per interner Zeitsteuerung arbeitet. Die Einstellung für "scheduled" sollte eigentlich gar nicht mehr vorhanden sein. Evtl. ist beim update von 2.x auf 3.0 hier etwas schief gelaufen. Normalerweise würde ich erwarten, dass der Adapter bei dir alle 120 Minuten die Daten liest. Evtl. den Adapter mal komplett löschen und neu installieren....

[Sandmanyz]

@rene_hm
Ich habe den Adapter entfernt und neu installiert. Nun laufen die Abfragen, wie konfiguriert, alle halbe Stunde. Das ist schon mal gut.

Die Meldungen erscheinen dennoch. Mache ich beim eingeben der Datenpunkte was falsch? Aber sie werden ja aktualisiert obwohl Fehler im Protokoll erschienen.

[Rene_HM]

@sandmanyz aus meiner Sicht kannst du den Fehler ignorieren, da das eine Eigenheit vom ebus ist. Jeder Busteilnehmer versucht etwas auf dem Bus zu senden, wenn er denkt, es ist Zeit dafür. Wenn ein anderer Busteilnehmer zur ähnlichen Zeit senden will, gewinnt der der die höchste Priorität hat. Der andere meldet "arbitration lost" also "Zuteilung verloren". Im adapter ist ein retry eingebaut, der den Befehl dann einfach nochmal sendet. Deshalb funktioniert das Abholen der Daten ja auch... Wenn du auf debug log schaltest, wirst du Meldungen wie "retry to send data" finden. Eine Meldung "max retries, skip cmd" solltest du nicht sehen...

Ich würde prüfen, ob es notwendig ist, deine Daten alle aktiv abzufragen. In vielen Fällen benötigen andere Busteilnehmer diesen Wert auch und sie werden deshalb bereits durch andere Busteilnehmer abgefragt. Der ebusd lauscht auf alle Nachrichten auf dem Bus und notiert Daten-Änderungen, die er auf dem Bus sieht.

[Sandmanyz]

@rene_hm
Ich habe die Datenpunkte ursprünglich mal in die Liste aufgenommen weil sie nicht aktualisierten. Jetzt habe ich alle Datenpunkte aus der Liste "abgefragte Datenpunkte" entfernt und beobachte mal ob/wann sie aktualisiert werden.

Danke erst einmal für die Unterstützung

[Hiltex]

@sandmanyz
Lass die Datenpunkte ruhig drin, sollten sie nicht mehr aktualisiert werden. Meine Therme sendet fast nichts von alleine, ich muss alles aktiv abfragen, was mich interessiert

[Sandmanyz]

@rene_hm
Ich habe es ohne Abfrage der Datenpunkte getestet. Leider aktualisieren die Datenpunkte dann nicht. Wie @Hiltex geschrieben hat, müssen bei mir auch viele Punkte aktiv abbgefragt werden weil die Datenpunkte sonst nicht aktualisieren.

Bin jetzt auf die Version 2.5.1 des Adapters gegangen und habe nich mehr diese vielen Fehler im Protokoll.

EDIT: Zu früh gefreut, kommen doch wieder die Fehler.

[Rene_HM]

@sandmanyz ignoriere die Fehler doch einfach... Solange du kein "max retries, skip cmd" bekommst, werden die Daten gelesen, wenn auch erst beim zweiten Versuch...

[Hiltex]

@rene_hm
Könntest du daraus nicht eine Info-Meldung machen? Ich glaube das ist der Punkt, an dem man sich leicht stören kann.

[Sandmanyz]

@hiltex
Genau das ist der Punkt. Ich kontrolliere regelmäßig die Logs und die sind immer voll mit 100derten Meldungen des ebus Adapters.
@Rene_HM
Wenn das möglich wäre, wäre das klasse

[Hiltex]

Ich habe zufällig gerade gesehen, dass es auch einen sendTo-Baustein für den ebus-Adapter gibt.
Weiß jemand, wie die parameter zu füllen sind und ob der Befehl dann auch direkt gesendet wird?

[Rene_HM]

@hiltex das wird vom Adapter nicht unterstützt...

[Hiltex]

@Rene_HM
Kein Problem, funktioniert ja auch ohne wunderbar. Danke.

Aber vielleicht wäre das eine sinnvolle Erweiterung des Adapters?

[GiMichael]

Hallo, ich habe in der Suche nichts gefunden. Deswegen frage ich hier einfach mal.

Der EBUSD daemon läuft. Trotzdemwirft mir der iobroker keine Werte raus. Scheinbar liegt das an der Konfiguration. Ich nutze --scanconfig=full. EBUSD findet 4 Teilnehmer an Adresse 08/15/26 und 35. Leider gibt der Scan nur bei 35 etwas raus, nämlich die ID V8100 (ist wohl die VR81). Da das file 35.v81.1.csv leer ist, kann der EBUSD diesen Teilnehmer nicht auswerten.

 "scan.08": {
  "messages": {   "": {
    "name": "",
    "passive": false,
    "write": false,
    "lastup": 0
   }
  }
 },
 "scan.15": {
  "messages": {   "": {
    "name": "",
    "passive": false,
    "write": false,
    "lastup": 0
   }
  }
 },
 "scan.26": {
  "messages": {   "": {
    "name": "",
    "passive": false,
    "write": false,
    "lastup": 0
   }
  }
 },
 "scan.35": {
  "messages": {   "": {
    "name": "",
    "passive": false,
    "write": false,
    "lastup": 1666536401,
    "zz": 53,
    "fields": {
     "MF": {"value": "Vaillant"},
     "ID": {"value": "V8100"},
     "SW": {"value": "0103"},
     "HW": {"value": "2502"}
    }
   }
  }

Die Adresse 15 müsste die calorMatic VRC 430 sein. Aber der Scan von Addr. 15 ist immer leer. Kann ich dem EBUSD irgendwie zwingen, dass er das File 15.430.csv nimmt, welches für die calormatic VRC 430 vorgesehen ist?