Läuft: Heizung mit eBus-Schnittstelle

[cs-online]

was passiert denn, wenn Du den fehlerhaften an das Ende der Liste bringst ? Dann würde ja theoretisch "nur" kein Wert kommen. Würde auch ein gecachter, aber ein wenig älterer Wert reichen ? Dann das "-f" weglassen.

[TiPpFeHlEr]

hmm.....

ich kanns mal probieren....

aber das Problem mit der extremen Latenz seitens der Lüftung (RecoVair+Vr32) ist mir ja bekannt und lässt sich nur mit einem 2ten Bus-Koppler direkt am RecoVair Ebus vor dem VR32 lösen.

meine Frage ist halt, der ebusd hat ja 9mal ein retry versucht nach 1er Sekunde. Kann man dieses erhöhen kann auf zb. 15 retry's ?

Die andere Sache ist ja auch noch, das er ja den Wert bekommen hat und dem falschen device zuordnet, das dürfte auch in keinem Fall passieren.

und heute nochmal, diesmal hat es öfter versucht plus einem "main error".

Code Auswählen Erweitern

2017-09-18 13:12:00.428 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:01.171 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:02.741 [update notice] update bai Status01 QQ=10: 29.0;29.0;16.375;-;49.0;off
2017-09-18 13:12:03.056 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:05.356 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:06.317 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:07.284 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:08.768 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:09.539 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:10.971 [bus error] send to 38: ERR: read timeout
2017-09-18 13:12:10.971 [main error] send message part 0: ERR: read timeout
2017-09-18 13:12:11.743 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:12.486 [update notice] update bai Mode QQ=10: Standby
2017-09-18 13:12:12.701 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:13.655 [update notice] update bai Status01 QQ=10: 29.0;29.0;16.375;-;49.0;off
2017-09-18 13:12:13.877 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:14.575 [bus error] send to 38: ERR: read timeout, retry


Auszug aus der Fhem Log

Code Auswählen Erweitern

2017.09.18 13:12:07 5: Cmd: >get WaermeRueck WaermeRueck<
2017.09.18 13:12:07 5: ECMDDevice: Analyze command >{"r -f ByPass \n"}<
2017.09.18 13:12:10 5: Starting notify loop for EBUS, 1 event(s), first is FAILED
2017.09.18 13:12:10 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:10 5: End notify loop for EBUS
2017.09.18 13:12:13 5: Starting notify loop for EBUS, 1 event(s), first is DISCONNECTED
2017.09.18 13:12:13 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:13 5: End notify loop for EBUS
2017.09.18 13:12:13 5: Postprocessing "empty string" with perl command { $_ }.
2017.09.18 13:12:13 5: Postprocessed value is "empty string"
2017.09.18 13:12:13 5: Starting notify loop for WaermeRueck, 1 event(s), first is WaermeRueck
2017.09.18 13:12:13 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:13 5: End notify loop for WaermeRueck
2017.09.18 13:12:13 5: Cmd: >get Disbalance Disbalance<
2017.09.18 13:12:13 5: ECMDDevice: Analyze command >{"r -f Disbalance \n"}<
2017.09.18 13:12:13 5: Postprocessing "on\n\n (\157\156\012\012)" with perl command { $_ }.
2017.09.18 13:12:13 5: Postprocessed value is "on\n\n (\157\156\012\012)".
2017.09.18 13:12:13 1: PERL WARNING: Argument "on\n\n" isn't numeric in sprintf at (eval 55536) line 1.
2017.09.18 13:12:13 5: Starting notify loop for Disbalance, 2 event(s), first is Disbalance: on\n\n
2017.09.18 13:12:13 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:13 5: End notify loop for Disbalance


diesmal hing er bei "get WaermeRueck WaermeRueck" und nach 3 Sekunden startet er den nächsten Befehl "get Disbalance Disbalance" dort erhält er nun den Wert "on" dieser stammt aber von "WaermeRueck".


mfg Maik

[TiPpFeHlEr]

So,

habe jetzt

Code Auswählen Erweitern

ECMDDevice: Analyze command >{"r -f ByPass \n"}< gegen

Code Auswählen Erweitern

ECMDDevice: Analyze command >{"r ByPass \n"}< getauscht.
mal sehen was passiert.

habe auch parallel auf ebusd 3.0 geupdated.
leider bindet er nun meine 38.v32.csv nicht mehr ein.
Geräte werden korrekt erkannt.

Code Auswählen Erweitern

pi@ospi ~ $ ebusctl info
version: ebusd 3.0.v3.0
update check: OK, broadcast.csv: different version available, vaillant/08.bai.csv: different version available, vaillant/15.470.csv: different version available, vaillant/hcmode.inc: different version av
signal: acquired
symbol rate: 22
max symbol rate: 133
reconnects: 0
masters: 4
messages: 463
conditional: 3
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004276']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 26: slave, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"



Code Auswählen Erweitern

pi@ospi ~ $ ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;11;32;0010004276;0001;007809;N3
15;Vaillant;47000;0420;1403;21;14;32;0020171280;0082;031167;N9
26;Vaillant;47000;0420;1403;21;14;32;0020171280;0082;031167;N9
38;Vaillant;V32;0117;9802


mfg maik

[rellla]

Hallo zusammen,

ich habe mich mit dem Ebus Protokoll meiner Bartl Sole-Wärmepumpe Eco 6S HG mit TEM Controller beschäftigt und kann erste Ergebnisse vorlegen.
Grundlegende Parameter wie Soll-Ist-Werte (für Heizkreis, Wärmepumpe und Warmwasser) sind https://github.com/rellla/ebusd-configuration/tree/bartl_tem (vorerst nur lesend) in eine csv Datei verpackt.
Bevor ich mich ans Werte schreiben wage, würde ich mich gerne zuerst mit dem Auslesen der Expertenmenüs befassen. Hier könnte ich Hilfe gebrauchen:

Für den Zugriff auf die Fachmann-Parameter müssen an der Masterfernbedienung erst 2 Passwörter eingegeben werden, dann habe ich Zugriff auf die Parameter. Nach 15 min. Inaktivität wird das zurückgesetzt. Das funktioniert an der Wärmepumpe direkt einwandfrei.

1. Frage: Wie verbaue die Abfrage dieser Parameter inkl. der notwendigen Passwort Eingabe in meine Ebus Konfiguration? Oder muss fhem oder wer auch immer bei einer Abfrage dafür sorgen, dass die Passwörter vorher geschrieben werden oder eine Abfrage stattfindet, in welcher Menü-Ebene (0,1,2) wir uns befinden? Ohne Passworteingabe kommt übrigens bei Abfrage der versteckten Werte ein Error zurück.
2. Frage: Nach Eingabe der Passwörter verschieben sich die Adressräume des Controllers. D.h. Ein Wert auf Expertenebene (z.B. 0x0080004a) steht plötzlich für einen anderen Parameter als auf Userebene.

Gibt es das Problem auch bei anderen Herstellern bzw. hat jemand einen Ansatz parat, wie das zu lösen ist?

Ich bin relativer Neueinsteiger bei Ebusd und erstmal froh, was auslesen zu können. Mit fhem oder sonstigen Frontends habe ich mich noch nicht befasst.

Danke für eure Hilfe.

Gruß
Andreas

[Prof. Dr. Peter Henning]

Oder muss fhem oder wer auch immer bei einer Abfrage dafür sorgen, dass die Passwörter vorher geschrieben werden oder eine Abfrage stattfindet, in welcher Menü-Ebene (0,1,2) wir uns befinden?

Der Zugriff über EBUS kann durchaus unabhängig von der Bedienoberfläche sein. Bei Vaillant sind Experteneinstellungen auch durch Codenummern schützbar - können über EBUS aber trotzdem ausgelesen und modifiziert werden.

Sollte das bei diesem Hersteller wirklich anders sein (da bin ich noch skeptisch...), müsste man in der Tat etwas (z.B. in FHEM) programmieren, das dieses dann zustandsbehaftete Protokoll korrekt ausführt.

LG

pah

[rellla]

Danke für die schnelle Antwort. Leider ist es wohl so, siehe z.B. :

im Usermenu:

Code Auswählen Erweitern


01 15 0621 04 6581000e / 0a b342 8d02f4016400 e001

-> b342 enspricht Parameter 05-051 (Warmwasser-Sollwert) und ergibt e001, d.h. 48.0 °C

nach Eingabe Passwort bekommt derselbe Menupunkt aber den Code 6592000e:

Code Auswählen Erweitern


01 15 0621 04 6592000e / 0a b342 8d02f4016400 e001

und 6581000e wird zu 03-093 (Timer Zinenzuordnung)

Code Auswählen Erweitern


01 15 0621 04 6581000e / 0a dd41 0900ffffff01 0000


Ohne Passworteingabe bringt ein Abruf von 6592000e durch Ebus einen Error.

Mir stellt sich die Frage, ob die verschiedenen Zugriffscodes für Warmwasser irgendwie gekoppelt sind (evtl. durch bit-Operationen) oder nach Passworteingabe einfach nur neu vergeben werden, was ich vermute. Dann müsste ich herausfinden, wie die Masterfernbedienung von der aktuellen Zugriffsebene erfährt bzw. diese aktiv abfragt, damit die Codes richtig gewählt werden. In irgendeiner Nachricht müssten da ja bits versteckt sein!?

Gruß
Andreas

[rellla]

Ich antworte mir schnell selbst. Ich glaube, ich habe es gefunden:

Code Auswählen Erweitern


Warmwasser:
0115062104 04 ab004e / 0a 2b820000ff0000000000 = 2 (user-menu)
0115062104 04 ab004e / 0a 2b820000ff0000000200 = 6 (exp-menu)
Wärmepumpe:
0115062104 04 ab0042 / 0a 2b820000ff0000000000 = 1 (user-menu)
0115062104 04 ab0042 / 0a 2b820000ff0000000200 = 12 (exp-menu)
Heizkreis:
0115062104 04 ab004a / 0a 2b820000ff0000000000 = 5 (user-menu)
0115062104 04 ab004a / 0a 2b820000ff0000000200 = 13 (exp-menu)


Das taucht jeweils auf, wenn ich das Einstellungsmenu öffne - jeweils mit und ohne Passwort. Ich vermute, dass die letzten 2 byte der Antwort das Level angeben - 0 und 2.
Wenn ich mich nicht täusche, versucht die Master-FB hier zu erfahren, welche Einstellungsebene durch das Passwort geöffnet wurde. 2b82, sprich 04-043 ist in der Bedienungsanleitung nirgends vermerkt, würde nummernmäßig aber nahe an 04-040 Service-Passwort stehen

D.h. für die Abfrage eines Wertes müsste man
für Experten-Ebene
(evtl. aktuelles Level abfragen) -> ggfs. Passwort setzen -> Wert abfragen mit Codes für Exp.
und für User-Ebene
aktuelles Level abfragen -> Wert abfragen mit Codes für User-Menu

Soweit so gut. Muss das dann Ebusd regeln, oder fhem?

Gruß
Andreas

[TiPpFeHlEr]

UPDATE

das ändern von

Code Auswählen Erweitern

"r -f ByPass \n"auf

Code Auswählen Erweitern

"r ByPass \n" hat nichts gebracht.
Auch ein Update auf ebusd 3.0 brachte keine Änderung.

nun habe ich mal in den Start Befehl geschaut

Code Auswählen Erweitern

EBUSD_OPTS="--receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /var/log/ebusd.log"
dort taucht

Code Auswählen Erweitern

--receivetimeout=100000auf,
diesen habe ich jetzt mal erhöht auf

Code Auswählen Erweitern

--receivetimeout=200000
zur Verständniss Frage, sind das Millisekunden?oder Was??
100.000 millis = 100 Sek. ?


nochwas....
kann ich bei

Code Auswählen Erweitern

-l /var/log/ebusd.log auch Datums oder Zeit Platzhalter benutzen, damit das Log nicht so gross wird??

mfg Maik

[Reinhart]

nochwas....
kann ich bei

Code Auswählen Erweitern

-l /var/log/ebusd.log auch Datums oder Zeit Platzhalter benutzen, damit das Log nicht so gross wird??

nimm doch Logrotate, dann hast du die Größe im Griff!

LG

[john30]

Habe ich gerade eben versucht, das gleiche Problem.
Gibt es eine Möglichkeit die knotig manuell zu erstellen?

ja klar. für die aktuelle config aus github kannst Du folgendes Kommando benutzen:

Code Auswählen Erweitern

svn export --force https://github.com/john30/ebusd-configuration.git/trunk/ebusd-2.1.x/de/ /etc/ebusd/

[john30]

aber das Problem mit der extremen Latenz seitens der Lüftung (RecoVair+Vr32) ist mir ja bekannt und lässt sich nur mit einem 2ten Bus-Koppler direkt am RecoVair Ebus vor dem VR32 lösen.
meine Frage ist halt, der ebusd hat ja 9mal ein retry versucht nach 1er Sekunde. Kann man dieses erhöhen kann auf zb. 15 retry's ?

das Problem mit dem VR32 ist, dass sich das Gerät als Bridge zu einem weiteren eBUS nicht an die standardisierten Zeiten der Spezifikation halten kann, denn es werden ja Nachrichten auf einem Bus empfangen, ausgewertet, an den anderen Bus gesendet, die Antwort abgewartet, und dann an den urspr. Bus als Antwort abgegeben.
Hier hilft nur, die Antwortzeit drastisch zu erhöhen mit "--receivetimeout=..." beim ebusd Start, andernfalls kann das gar nicht klappen.

[john30]

leider bindet er nun meine 38.v32.csv nicht mehr ein.

was sagt denn das Logfile dazu?

[john30]

diesen habe ich jetzt mal erhöht auf

Code Auswählen Erweitern

--receivetimeout=200000
zur Verständniss Frage, sind das Millisekunden?oder Was??
100.000 millis = 100 Sek. ?

Steht sowohl im wiki wie auch auf der Kommandozeilenhilfe von ebusd

[TiPpFeHlEr]

Steht sowohl im wiki wie auch auf der Kommandozeilenhilfe von ebusd

hi John,

mehr als 100.000 geht nicht!?
wenn ich mehr als 100000 angebe kommt das

Code Auswählen Erweitern

pi@ospi /dev/serial/by-id $ sudo service ebusd start
[....] Starting ebusd: ebusdebusd: invalid receivetimeout
Try `ebusd --help' or `ebusd --usage' for more information.


also sind es laut Wiki 0,1 Sek ? 1.000.000µs = 1 Sek
mehr geht nicht??

werde dann wohl nen 2ten Ebus-Koppler benutzen müssen , schade.

mfg maik

[john30]

mehr als 100.000 geht nicht!?

richtig, Maximum ist derzeit 100 ms, was im Normalfall schon weit hinter jeder sinnvollen Antwortzeit liegt.

werde dann wohl nen 2ten Ebus-Koppler benutzen müssen , schade.

Du kannst ja mal in src/ebusd/main.cpp Zeile 389 noch eine 0 an die 100000 dranhängen und dann höhere Werte probieren.