ebusd-configuration
ebusd-configuration copied to clipboard
john30
Vaillant ecoCompact 206 + VRC 700
scan result (bai ist kopiert aus 7401): 08;Vaillant;BAI00;0116;9602;21;15;45;0010015600;3100;008228;N4 15;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4 ec;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4
unknown (nach ca. 1 Tag): 1008b5100305ff01 / 0101 1008b512020000 / 00 1008b512020064 / 00 1008b5120204ff / 0101 1008b513020508 / 00 1008b5160111 / 09010104020402040204 1008b516081000ffff04002120 / 0b0000ff0400212000000000 1008b516081002ffff0400811f / 0b32ffff0400811f00000000
Hallo John, weiß nicht ob "Issues" die richtige Liste war um diese Meldung vor 2 Tagen zu senden. Finde nicht mehr die anderen Meldungen mit "unknowns". Da wollte ich eigentlich hin. Kannst Du zu obigen Messages was sagen? Danke, Dietmar
Einige davon kann ich bestätigen, auch weitere hinzufügen - kenne aber auch noch nicht deren Bedeutung. Interessant ist, dass zu meinem icoVit156 bie b510..05 immer mit "ff03" gesetzt wird, bei dir offenbar mir "ff01", ist das bei dir auch statisch?
grep 1008b5100305 /var/log/ebusd.log |cut -d ' ' -f 8-10|sort -u
1008b5100305ff03 / 00
Die b512..00 wechselt bei mir und ich habe folgende Vermutung:
1008b512020064 / 00 --> Warmwasser-Bedarf 1008b512020000 / 00 --> kein Warmwasser-Bedarf
Die b512..04 kommt bei mir jede Minute, (fast) immer mit "ff" - ein einziges Mal kam allerdings eine "00"; etwa zu der Zeit als ein Systemfehler vom Brenner gemeldet wurde, allerdings war es in der nächsten Minute gleich wieder "ff", noch bevor der Fehler behoben war. Außerdem geht ja die Meldung vom Regler zum Brenner..... Was ich fast übersehen hätte: mein Brenner antwortet darauf anders:
1008b5120204ff / 00
Die b513..05 kommt auch vor, ebenfalls mit "08".
B516 kann mein Brenner offenbar nicht:
1008b5160111 / 00 Ich würde daher mal vermuten, dass es die Verbrauchsabfrage ist - zeigt deine VRC bei Strom/Brennstoff-Verbauch etwas an? Dann würde ich die b516er mal genauer beobachten und die Inhalte versuchen zu erraten!
Vom Inhalt könnten sie zu meinen weiteren unbekannten ähnlich sein:
1008b5100900000058ffff010000 / 0101 1008b510090000005cffff010000 / 0101 1008b5100900009958ffff000000 / 0101 1008b5110101 / 095eff301000ff4000ff 1008b5110101 / 095eff601000ff4000ff 1008b5110101 / 0964ff500e00ff4000ff 1008b5110101 / 096effc00f00ff0000ff 1008b5110101 / 0976ffe00600ff0000ff 1008b5110101 / 097eff800200ff0000ff 1008b5110101 / 097eff800200ff0100ff 1008b5110101 / 0984ff600a00ff0000ff 1008b5110102 / 05033c965082
Und bevor es langweilig wird, noch ein paar Meldungen vom VR900 Internetmodul:
0008b503020002 / 0affffffffffffffffffff 0008b509022802 / 0402cf040c 0008b509022803 / 0403ae0902
SEHR seltsam übrigens, dass die Abfrage der ScanIDs auch als "unknown" gemeldet werden, obwohl diese ja definiert sind:
0008b5090124 / 09003231313533343030 0008b5090125 / 09313030313036373433 0008b5090126 / 09313030303035363238 0008b5090127 / 094e343c3c3c3c3c3c3c
Bis dahin, Sven
@dwarning: ich kann nicht viel dazu sagen, weil ich keine der komponenten besitze. Die unknown Meldungen findest Du im ebusd Logfile. @Giermann: was meinst du mit "Abfrage der ScanIDs auch als unkown"?
Am 16.04.2016 um 12:14 schrieb Sven Giermann:
Einige davon kann ich bestätigen, auch weitere hinzufügen - kenne aber auch noch nicht deren Bedeutung. Interessant ist, dass zu meinem icoVit156 bie b510..05 immer mit "ff03" gesetzt wird, bei dir offenbar mir "ff01", ist das bei dir auch statisch?
# grep 1008b5100305 /var/log/ebusd.log |cut -d ' ' -f 8-10|sort -u 1008b5100305ff03 / 00Bei mir kommt eine 1008b5100305ff01 / 0101 alle Minute mit ff01 - kein Wechsel am Tag.
Die b512..00 wechselt bei mir und ich habe folgende Vermutung:
1008b512020064 / 00 --> Warmwasser-Bedarf 1008b512020000 / 00 --> kein Warmwasser-BedarfFolgende Wechsel treten bei mir auf: 2016-04-15 09:59:34.856 [update notice] update unknown08 block1200 QQ=10: 64 2016-04-15 10:00:34.937 [update notice] update unknown08 block1200 QQ=10: 00 . 2016-04-15 14:59:03.355 [update notice] update unknown08 block1200 QQ=10: 00 2016-04-15 15:00:03.441 [update notice] update unknown08 block1200 QQ=10: 64 . 2016-04-15 21:59:43.433 [update notice] update unknown08 block1200 QQ=10: 64 2016-04-15 22:00:43.541 [update notice] update unknown08 block1200 QQ=10: 00 . 2016-04-16 05:59:29.842 [update notice] update unknown08 block1200 QQ=10: 00 2016-04-16 06:00:29.932 [update notice] update unknown08 block1200 QQ=10: 64
Das ist ähnlich dem programmierten Zeitprogramm meiner Zirku im VRC. Als wenn da eine Std. Versatz wäre.
Die b512..04 kommt bei mir jede Minute, (fast) immer mit "ff" - ein einziges Mal kam allerdings eine "00"; etwa zu der Zeit als ein Systemfehler vom Brenner gemeldet wurde, allerdings war es in der nächsten Minute gleich wieder "ff", noch bevor der Fehler behoben war. Außerdem geht ja die Meldung vom Regler zum Brenner..... Was ich fast übersehen hätte: mein Brenner antwortet darauf anders:
1008b5120204ff / 00Die b513..05 kommt auch vor, ebenfalls mit "08".
B516 kann mein Brenner offenbar nicht:
1008b5160111 / 00 Ich würde daher mal vermuten, dass es die Verbrauchsabfrage ist - zeigt deine VRC bei Strom/Brennstoff-Verbauch etwas an? Dann würde ich die b516er mal genauer beobachten und die Inhalte versuchen zu erraten!Irgendwo war da eine Anzeige, die immer auf 0 steht. (Lt. Vaillant für exclusive Wandgeräte vorgesehen.)
Vom Inhalt könnten sie zu meinen weiteren unbekannten ähnlich sein:
1008b5100900000058ffff010000 / 0101 1008b510090000005cffff010000 / 0101 1008b5100900009958ffff000000 / 0101 1008b5110101 / 095eff301000ff4000ff 1008b5110101 / 095eff601000ff4000ff 1008b5110101 / 0964ff500e00ff4000ff 1008b5110101 / 096effc00f00ff0000ff 1008b5110101 / 0976ffe00600ff0000ff 1008b5110101 / 097eff800200ff0000ff 1008b5110101 / 097eff800200ff0100ff 1008b5110101 / 0984ff600a00ff0000ff 1008b5110102 / 05033c965082Und bevor es langweilig wird, noch ein paar Meldungen vom VR900 Internetmodul:
0008b503020002 / 0affffffffffffffffffff 0008b509022802 / 0402cf040c 0008b509022803 / 0403ae0902SEHR seltsam übrigens, dass die Abfrage der ScanIDs auch als "unknown" gemeldet werden, obwohl diese ja definiert sind:
0008b5090124 / 09003231313533343030 0008b5090125 / 09313030313036373433 0008b5090126 / 09313030303035363238 0008b5090127 / 094e343c3c3c3c3c3c3cBis dahin, Sven
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/john30/ebusd-configuration/issues/20#issuecomment-210785187
@Giermann: was meinst du mit "Abfrage der ScanIDs auch als unkown"?
Naja, ich bekomme täglich solche "unknowns":
2016-04-16 02:01:53.358 [update notice] unknown MS cmd: 0008b5090124 / 09003231313533343030 2016-04-16 02:01:53.550 [update notice] unknown MS cmd: 0008b5090125 / 09313030313036373433 2016-04-16 02:01:53.742 [update notice] unknown MS cmd: 0008b5090126 / 09313030303035363238 2016-04-16 02:01:53.933 [update notice] unknown MS cmd: 0008b5090127 / 094e343c3c3c3c3c3c3c
Obwohl diese meiner Meinung nach aus der /etc/ebusd/vaillant/scan.csv bekannt sein sollten:
*r,scan,,,,,B509,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, r,scan,id,Scan ID,,,,24;25;26;27,,,IGN,,,,prefix,,STR:2,,,,year,,STR:2,,,,week,,STR:2,,,,product,,STR:10,,,,supplier,,STR:4,,,,counter,,STR:6,,,,suffix,,STR:2,,,
Am 20.04.2016 um 07:28 schrieb John:
das ist vrdialog, der die messages sendet, oder?
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/john30/ebusd-configuration/issues/20#issuecomment-212265491
Etwas schwierig - falls Du mich meinst, ich habe kein vrdialog. Ich glaube Sven auch nicht.
Das ist meine Anlage - wie im Betreff genannt:
pi@raspberrypi ~ $ ebusctl scan result 08;Vaillant;BAI00;0116;9602;21;15;45;0010015600;3100;008228;N4 15;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4 ec;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4
pi@raspberrypi ~ $ ebusctl info version: ebusd 2.0.5ccdb76 signal: acquired symbol rate: 39 masters: 3 messages: 464 address 03: master #3 address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/08.bai.HW9602.csv" address 10: master #6 address 15: slave #6, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103", loaded "vaillant/15.700.csv" address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103"
das ist vrdialog, der die messages sendet, oder?
Nein, das VR900 Internetmodul! (vrDialog habe ich nicht, die Vermutung war richtig.) Ich vermute jedoch, dass diese Meldungen auch dann kommen würden, wenn man einen zweiten ebusd an den gleichen Bus hängt und dieser gerade scannt. Könnte ich gern testen, habe noch einen Reserve-Adapter...
Laut anderen inc Files könnte die b503 etwas mit Fehlern oder Fehlerhistorie zu tun zu haben, bei meiner ecoTEC 146 taucht die ebenfalls auf:
1052b5030c0700ffffffffffffffffffff / 0101 = 1
Könnte das sein?
hm, das könnte schon etwas mit Fehler und -Historie zu tun haben, aber die 07 ist mir zumindest bis jetzt noch nicht untergekommen.
@dwarning you could check if https://github.com/john30/ebusd-configuration/pull/107 provides the better definition for your bai than the default.
Hallo, ich will noch mal auf die b512 unknowns von oben zurück kommen.
pi@raspberrypi:~ $ ebusctl grab result
1008b512020000 / 00 = 165
1008b512020064 / 00 = 222
1008b5120204ff / 0101 = 385
Die Bedeutung ist eigentlich mehrfach erkannt worden u.a. im Dokument Vaillant_eBUS_v0.6.0_mod.pdf von pah. Also die 0000 und 0064 sind bei mir der Schaltzustand der Zirkulationspumpe. Die 04ff ist nicht ganz so klar, scheint aber ähnlicher Zustand einer Pumpe zu sein. Nun habe ich an das Ende von hcmode.inc folgendes rangehängt:
*r,,,,,,"B512",,,,,,,
r,,ZirkuPumpe1,,,,,00,,,UCH,,,
r,,ZirkuPumpe2,,,,,04,,,UCH,,,
Dies führt dann aber folgendem Problem im log file:
2019-09-24 21:16:27.563 [update error] unable to parse read bai ZirkuPumpe1 from 1008b512020064 / 00: ERR: invalid position
2019-09-24 21:16:27.807 [update notice] received read bai ZirkuPumpe2 QQ=10: 1
Der in der csv angegebene Identifier 00 für die ZirkuPumpe1 scheint nicht anzusprechen. Mein Verständnisproblem ist: Ich will die von der bai ausgegebene message 00 oder 64 auswerten und nicht die Antwort des Reglers, die immer 00 ist. Genauso mit der 04ff. Die immergleiche Antwort 0101 interessiert mich nicht.
Eigentlich wollte ich das template onoff nutzen, aber das spricht wohl nicht auf die '100' an.
Entschuldigung: Das Einfügen von mehrzeiligem code scheint nicht zu gelingen, Zeilenumbrüche sind im preview nicht zu sehen. Gruß Dietmar
wegen der leeren Antwort vom Slave ist 1008b512020000 / 00 ein klassisches "write", ergo lautet die Definition dafür auf "w,..." bzw. wohl eher auf "uw,...", da man hier üblicherweise nicht via ebusd dem Controller 0x10 dazwischen funken sollte. Statt UCH wäre dann vermutlich percent zu nehmen, da 0x64=100 und es lediglich 0 und 100 als Werte zu geben scheint.
Bei ID 04 ist es vermutlich ein kombiniertes Schreiben+Lesen, sprich der Controller fordert 0xff als Aktion an und der Slave antwortet mit "01". Was sich dahinter verbirgt, weiß ich aber auch nicht.
OK - ich habe jetzt bei mir in hcmode.inc
*uw,,,,,,"B512",,,,,,,
uw,,ZirkuPumpe,Status Zirkulationspumpe,,,,00,,,UCH,0=off;100=on,,
angefügt und erhalte korrekte Anzeigen im logfile. Vielleicht lässt sich das so ähnlich auf github verewigen. Danke, Dietmar Edit: Die Zeilenumbrüche kommen nicht korrekt in der Code Sektion!
@dwarning doch, Zeilenumbrüche klappen prima, wenn du den richtigen Markdown Code verwendest. Ich jetzt in f5da9da mal die Definition dazu genommen
John,
ich sehe zwar den commit "added potential cc pump status (fix for #20)" in hcmode.inc bzgl. StatusCirPump:
+*uw,,,,,,"B512",02,,,,,, +uw,,StatusCirPump,Status Zirkulationspumpe,,,,00,,,UCH,0=off;100=on,,
aber ich bekomme nach wie vor die B51202 als unknown wenn ich über web config laufen lasse.
Mit einer lokalen config und Eintrag in hcmode.inc
*uw,,,,,,"B512",,,,,,, uw,,ZirkuPumpe,Status Zirkulationspumpe,,,,00,,,UCH,0=off;100=on,,
klappt es.
OK, hab jetzt configpath auf das lokale git Verzeichnis gelegt und die "02" hinter B512 in hcmode.inc gelöscht. Dann funktioniert es. Mit der Längenangabe 02 kommen unknowns.
was denn für eine Längenangabe 02? Von der war ja noch nie die Rede und die darf auch nirgends in die Definition rein.
Dein commit vom 10.11. 18:14:
+*uw,,,,,,"B512",02,,,,,,
ich meine das 02h byte - wohl auch Identifier genannt.
Wenn ich das angebe, funktioniert es nicht.
Am 09.12.2019 um 08:42 schrieb John:
was denn für eine Längenangabe 02? Von der war ja noch nie die Rede und die darf auch nirgends in die Definition rein.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/john30/ebusd-configuration/issues/20?email_source=notifications&email_token=AEMWNTHYUHSPMOJKKPK4S73QXXZGPA5CNFSM4CAZLOC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGIFFDQ#issuecomment-563106446, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMWNTFBTHCIFCPJK3NMJRDQXXZGPANCNFSM4CAZLOCQ.
ah, gut dass das noch nicht deployed war, so ist es natürlich falsch. korrigiert mit f9612ec
Danke, John.
Am 14.12.2019 um 13:03 schrieb John:
ah, gut dass das noch nicht deployed war, so ist es natürlich falsch. korrigiert mit f9612ec https://github.com/john30/ebusd-configuration/commit/f9612ecc295b778c8799c111b191f656a960f7f0
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/john30/ebusd-configuration/issues/20?email_source=notifications&email_token=AEMWNTFIEUV6KXCMM7V45W3QYTDS5A5CNFSM4CAZLOC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4BCAY#issuecomment-565711107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMWNTFUIDLA3G7RASBLLDDQYTDS5ANCNFSM4CAZLOCQ.
Hallo John, auch wenn die Geschichte nicht so wichtig ist, der Status der Zirku (s. commit f9612ec) wirkt bei mir immer noch nicht. Nutze die web configuration standardmäßig: `pi@raspberrypi:~ $ ebusctl info version: ebusd 3.4.v3.4-14-gfb32960 update check: revision v3.4 available access: * signal: acquired symbol rate: 23 max symbol rate: 166 min arbitration micros: 7 max arbitration micros: 222 min symbol latency: 0 max symbol latency: 13 reconnects: 0 masters: 3 messages: 601 conditional: 2 poll: 0 update: 9 address 03: master #11 address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/bai.0010015600.inc" ([PROD='0010015600']), "vaillant/08.bai.csv" address 10: master #2 address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103", loaded "vaillant/15.700.csv" address 31: master #8, ebusd address 36: slave #8, ebusd address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103"
pi@raspberrypi:~ $ ebusctl scan result 08;Vaillant;BAI00;0116;9602;21;15;45;0010015600;3100;008228;N4 15;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4 ec;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4
pi@raspberrypi:~ $ ebusctl grab result 1008b5110100 / 08ec01140000080081 = 25 1008b512020000 / 00 = 17 1008b512020064 / 00 = 8 1008b5120204ff / 0101 = 25 1008b513020508 / 00 = 3 1008b5100305ff01 / 0101 = 25 ` Die beiden 1008b51202xxxx unknowns sind nach wie vor drin. Ist das noch nicht "deployed"? Danke, Dietmar