Adapter: ebus
-
@dreistein Hallo Dreistein, die Heizung ist seit 2 Wochen verbaut. Ich bekomme beim Start vom ebusd halt immer auch Fehlermeldungen. Es werden Datenpunkte eingelesen wie Hersteller. Software, Hardware etc. aber nicht ein Temperatur Wert oder Statuswert der Heizung. Wie schon geschrieben an der Heizung am ebuds hängt nur das eresa Interface.
-
Mal was zum Probieren :
ebusctl find -F circuit,name,comment
tail -f /var/log/ebusd.log
ebusctl info
Viel Erfolg beim Probieren
-
@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
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 -
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 -
@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.
-
@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
-
@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...
-
@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....
-
@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.
-
@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.
-
@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
-
@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 -
@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.
-
@sandmanyz ignoriere die Fehler doch einfach... Solange du kein "max retries, skip cmd" bekommst, werden die Daten gelesen, wenn auch erst beim zweiten Versuch...
-
@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. -
-
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?
-
@hiltex das wird vom Adapter nicht unterstützt...
-
@Rene_HM
Kein Problem, funktioniert ja auch ohne wunderbar. Danke.Aber vielleicht wäre das eine sinnvolle Erweiterung des Adapters?
