NEWS
Adapter: ebus
-
ebusctl muss weg. Ohne hat es geklappt. Aber ich meine der Befehl muss alle 30 sek erfolgen, weil der Regler den Wert sonst wieder überschreibt.
@cino said in Adapter: ebus:
ebusctl muss weg. Ohne hat es geklappt.
in der console? wäre mir neu das das ohne ebusctl geht.
@cino said in Adapter: ebus:
Aber ich meine der Befehl muss alle 30 sek erfolgen, weil der Regler den Wert sonst wieder überschreibt.
das würde ich an deiner stelle mal schick lassen. das hat einen Grund, das der sollwert überschrieben wird.
Warum nicht z1DayTemp ? ist das nicht der Raumtemp. sollwert ? -
Hallo Zusammen,
ich bin gerade dabei eine Vaillant Heizung mit einem Eresa Adapter an den Ebus zu bekommen. Am Ebus ist kein weiteres Gerät angeschaltet? Ich bekomme einfach keine vernünftige Daten übermittelt. Ist es eventuell nur möglich, wenn ein Abgesetztes Steuergerät installiert ist? Schnüffelt der ebusd nur an Meldungen zwischen Heizung und Steuergerät oder spuckt die Heizung zyklisch die vorhandenen Daten von der Heizung auf den Bus?
Vielen Dank im Voraus
-
Hallo Zusammen,
ich bin gerade dabei eine Vaillant Heizung mit einem Eresa Adapter an den Ebus zu bekommen. Am Ebus ist kein weiteres Gerät angeschaltet? Ich bekomme einfach keine vernünftige Daten übermittelt. Ist es eventuell nur möglich, wenn ein Abgesetztes Steuergerät installiert ist? Schnüffelt der ebusd nur an Meldungen zwischen Heizung und Steuergerät oder spuckt die Heizung zyklisch die vorhandenen Daten von der Heizung auf den Bus?
Vielen Dank im Voraus
@dirk-howold
Wie alt ist dein Heizung ? Ich habe, wie schon geschrieben, 2 Jahre gebraucht um heruszufinden das in der Heizung der falsche Regler verbaut war.
Ist ColoMatic oder so, soll aber Multimatic 700/x sein.Wie ebusd funktioniert kann ich nicht sagen. Vermute aber das der einmal "gelesene" Datenpunkte immer wieder einliesst.
Wo der das Speichert, keine Ahnung. ich habe haufenweise leere Datenpunkte die der an den Iobroker ebus adapter schickt.
Diese habe ich beim Probieren einmal eingelesen und bekomme die nun immer wieder.
Ein Löschen im ioBroker Adapter bringt leider auch nichts.
Ein neues Aufsetzen des RP3 mit ebusd kommt nicht in Frage. Bin ja froh da das überhaupt irgendwie funktioniert.Viel Lesen, Viel Probieren und viel Geduld.
-
@dirk-howold
Wie alt ist dein Heizung ? Ich habe, wie schon geschrieben, 2 Jahre gebraucht um heruszufinden das in der Heizung der falsche Regler verbaut war.
Ist ColoMatic oder so, soll aber Multimatic 700/x sein.Wie ebusd funktioniert kann ich nicht sagen. Vermute aber das der einmal "gelesene" Datenpunkte immer wieder einliesst.
Wo der das Speichert, keine Ahnung. ich habe haufenweise leere Datenpunkte die der an den Iobroker ebus adapter schickt.
Diese habe ich beim Probieren einmal eingelesen und bekomme die nun immer wieder.
Ein Löschen im ioBroker Adapter bringt leider auch nichts.
Ein neues Aufsetzen des RP3 mit ebusd kommt nicht in Frage. Bin ja froh da das überhaupt irgendwie funktioniert.Viel Lesen, Viel Probieren und viel Geduld.
@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
-
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 -
@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 -
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 -
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.
-
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 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 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...
-
@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.
-
@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.
-
@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 :+1:
-
@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 :+1:
@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 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 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
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...
780
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge