Hallo zusammen,
in diesem Thread sammle ich Themen/Diskussionen rund um das Thema ebusd-enhanced (https://github.com/john30/ebusd/tree/enhanced_device) in Kombination mit ebusd-esp auf Wemos D1 mini (https://github.com/john30/ebusd-esp).
VG John
Okay, dann lege ich mal gleich los mit meinen Beobachtungen:
Vorab ein kleines kosmetisches Problem: die ebusd-esp sendet auf der seriellen Schnittstelle die Zeilenumbrüche so, dass PuTTY nur in die nächste Zeile springt, ohne wieder am Zeilenanfang anzufangen [putty.jpg].
Nun zum eigentlichen Funktionsproblem:
Vorab: ich habe die normale TCP oder UDP Funktion gar nicht getestet, weil ich allein an der low-latency Funktion interessiert bin. Compiliert habe ich den Branch enhanced_device mit Stand vom 23.09.2018 (https://github.com/john30/ebusd/commit/ce4f500198108d7caafee68e18535b07d8e127b0).
Dieser läuft nun ganz normal mit direkt angeschlossenem EBus-FT232-Adapter produktiv. Dazu starte ich eine zweite Instanz, die sich mit dem Wemos-Adapter am gleichen Bus verbindet:
ebusd --scanconfig -d enhtcp:<ip>:9999 --accesslevel=* --configpath /etc/ebusd/ --enablehex -l /opt/ebusd_enh.log --pidfile /var/run/ebusd_enh.pid -p 8889 --address=33
Dieser startet zunächst ganz normal, bringt dann aber reproduzierbar nach etwas mehr als 10s nach jeder empfangenen Nachricht den Fehler "[bus error] arbitration start error":
2018-10-19 10:16:33.132 [main notice] ebusd 3.2.v3.2-25-gce4f500 started with auto scan
2018-10-19 10:16:33.326 [bus notice] bus started with own address 33/38
2018-10-19 10:16:33.328 [bus notice] signal acquired
2018-10-19 10:16:36.386 [bus notice] new master 10, master count 2
2018-10-19 10:16:36.453 [bus notice] new master 03, master count 3
2018-10-19 10:16:36.454 [update notice] received unknown MS cmd: 1008b5110101 / 095eff800900ff4000ff
2018-10-19 10:16:36.761 [update notice] received unknown MS cmd: 1026b5230106 / 10bd02af02470200809d02170204034000
2018-10-19 10:16:37.058 [update notice] received unknown MS cmd: 1026b5230107 / 0f06030080008000800000800080fc05
2018-10-19 10:16:37.336 [update notice] received unknown MS cmd: 1008b5100900000058ffff010000 / 0101
2018-10-19 10:16:40.169 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-10-19 10:16:40.423 [update notice] received unknown MS cmd: 1026b523040200014e / 0201e2
2018-10-19 10:16:40.675 [update notice] received unknown MS cmd: 1026b523040201014c / 02010a
2018-10-19 10:16:46.481 [update notice] received unknown MS cmd: 1008b5110101 / 095eff800900ff4000ff
2018-10-19 10:16:46.531 [bus error] arbitration start error
2018-10-19 10:16:46.786 [update notice] received unknown MS cmd: 1026b5230106 / 10bd02ac02440200809a02170204034000
2018-10-19 10:16:46.834 [bus error] arbitration start error
2018-10-19 10:16:47.086 [update notice] received unknown MS cmd: 1026b5230107 / 0f06030080008000800000800080fc05
2018-10-19 10:16:47.175 [bus error] arbitration start error
2018-10-19 10:16:47.364 [update notice] received unknown MS cmd: 1008b5100900000058ffff010000 / 0101
2018-10-19 10:16:47.454 [bus error] arbitration start error
2018-10-19 10:16:50.204 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-10-19 10:16:50.292 [bus error] arbitration start error
2018-10-19 10:16:50.450 [update notice] received unknown MS cmd: 1026b523040200014e / 0201e2
2018-10-19 10:16:50.499 [bus error] arbitration start error
2018-10-19 10:16:50.705 [update notice] received unknown MS cmd: 1026b523040201014c / 02010a
Außerdem ist die Instanz dann nicht wirklich ansprechbar - ein "ebusctl -p 8889 info" blockiert endlos, bis ich es abbreche, ohne eine Ausgabe zu geben.
Starte ich das ganze mit "--readonly" entfällt natürlich der Fehler, aber wirklich sauber läuft es auch dann nicht - CSVs, die eigentlich mit der anderen Instanz problemlos laufen (Parameter sind bis auf --device, --port, --address, --pidfile und --logfile identisch), haben angeblich auf einmal Fehler:
2018-10-19 10:21:00.569 [main error] scan config 08: ERR: element not found
[...]
2018-10-19 10:21:02.586 [main error] scan config 15: ERR: element not found
2018-10-19 10:21:04.606 [main error] scan config 26: ERR: element not found
Wenn ich über die (produktive) erste Instanz einen Scan initiiere, lädt die zweite Instanz außer der _broadcast.csv manchmal(!) eine weitere, aber offenbar nicht immer:
Erster Versuch:
version: ebusd 3.2.v3.2-25-gce4f500
update check: revision v3.2-8-g0f77a9d available, broadcast.csv: newer version available, vaillant/06.pms.csv: different version available, vaillant/0a.pmw.hwc.csv: newer version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: newer version available, vaillant/hwcmode.inc: newer version available
access: *
signal: acquired
symbol rate: 62
max symbol rate: 143
reconnects: 0
masters: 6
messages: 304
conditional: 15
poll: 0
update: 7
address 00: master #1
address 01: master #6
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=1203;HW=3103"
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503"
address 31: master #8
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address ed: slave
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
Zweiter Versuch:
version: ebusd 3.2.v3.2-25-gce4f500
update check: revision v3.2-8-g0f77a9d available, broadcast.csv: newer version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 140
reconnects: 0
masters: 6
messages: 220
conditional: 0
poll: 0
update: 7
address 00: master #1
address 01: master #6
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=1203;HW=3103"
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave #2
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503"
address 31: master #8
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
Zum Vergleich die Ausgabe der ersten Instanz (Soll-Zustand):
update check: revision v3.2-8-g0f77a9d available, broadcast.csv: newer version available, vaillant/06.pms.csv: different version available, vaillant/08.bai.csv: newer version available, vaillant/0a.pmw.hwc.csv: newer version available, vaillant/15.700.csv: different version available, vaillant/26.vr_71.csv: newer version available, vaillant/broadcast.csv: different version available, vaillant/ed.pms.sc.csv: different version available, vaillant/errors.inc: newer version available, vaillant/hwcmode.inc: newer version available
access: *
signal: acquired
symbol rate: 53
max symbol rate: 141
min arbitration micros: 1684
max arbitration micros: 1684
min symbol latency: 5
max symbol latency: 15
reconnects: 0
masters: 6
messages: 1175
conditional: 18
poll: 0
update: 7
address 00: master #1
address 01: master #6
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=1203;HW=3103"
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401", loaded "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
An den beiden Instanzen sollte es eigentlich nicht liegen, weil ich auch schon versucht habe, nur die Wemos-Instanz zu starten - mit gleichem Ergebnis, nur dass ich im --readonly Mode natürlich keinen Scan initiieren konnte...
Frage: wie kann ich das ganze irgendwie Debuggen, welche Optionen könnte ich versuchen um es zum Laufen zu kriegen?
Nachtrag:
Es hatte mir nun keine Ruhe gelassen und ich habe mal den normalen TCP Mode probiert.
Im Readonly verhält es sich genauso wie oben beschrieben. Ohne den Parameter ist die Instanz etwas träger bei einem "ebusctl -p 8889 info", zeigt letztlich aber irgendwann etwas an - leider auch mit der Einschränkung, nicht alle CSVs zu laden.
Ich habe damit dann mal versucht, auf den Bus zu schreiben und bekomme nur:
$ ebusctl -p 8889 hex 15070400
ERR: arbitration lost
Das Log dazu:
2018-10-19 11:29:09.898 [main notice] hex cmd: 3315070400
2018-10-19 11:29:13.566 [update notice] received unknown MS cmd: 1008b5110101 / 0960ffd00a00ff4500ff
2018-10-19 11:29:13.867 [update notice] received unknown MS cmd: 1026b5230106 / 109b027e023f020080c4024b0201034000
2018-10-19 11:29:14.165 [update notice] received unknown MS cmd: 1026b5230107 / 0f00030080008000800000800080fc05
2018-10-19 11:29:14.352 [bus error] send to 15: ERR: arbitration lost, retry
2018-10-19 11:29:14.427 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2018-10-19 11:29:14.709 [update notice] received unknown MS cmd: 1008b5100900005b58ffff000000 / 0101
2018-10-19 11:29:17.274 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-10-19 11:29:17.524 [update notice] received unknown MS cmd: 1026b523040200014b / 0201dd
2018-10-19 11:29:17.711 [bus error] send to 15: ERR: arbitration lost, retry
2018-10-19 11:29:17.780 [update notice] received unknown MS cmd: 1026b523040201014a / 020105
2018-10-19 11:29:23.631 [update notice] received unknown MS cmd: 1008b5110101 / 0960ffd00a00ff4500ff
2018-10-19 11:29:23.936 [update notice] received unknown MS cmd: 1026b5230106 / 109b027b023a020080c5024c0201034000
2018-10-19 11:29:24.237 [update notice] received unknown MS cmd: 1026b5230107 / 0f00030080008000800000800080fc05
2018-10-19 11:29:24.423 [bus error] send to 15: ERR: arbitration lost, retry
2018-10-19 11:29:24.516 [update notice] received unknown MS cmd: 1008b5100900005b58ffff000000 / 0101
2018-10-19 11:29:27.307 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-10-19 11:29:27.563 [update notice] received unknown MS cmd: 1026b523040200014b / 0201f1
2018-10-19 11:29:27.814 [update notice] received unknown MS cmd: 1026b523040201014a / 02010a
2018-10-19 11:29:33.570 [bus error] send to 15: ERR: arbitration lost
2018-10-19 11:29:33.570 [main error] hex: ERR: arbitration lost
Das Ganze ist unabhängig davon, ob die erste Instanz läuft oder nicht. Hat der Adapter vielleicht generell Probleme beim Schreiben??
Dann läge das Problem ja nicht an der Enhanced-Implementierung...
PS: Bei Wemos-Anbindung scheint ja "info" keine "min/max arbitration micros" anzuzeigen. Zumindest im Enhanced-Mode übernimmt das ja wohl auch der ESP selbst; könnte man diese Infos dann mit im Webinterface anzeigen?
Halb OT:
Zitat von: Sven77 am 19 Oktober 2018, 10:34:17..Vorab ein kleines kosmetisches Problem: die ebusd-esp sendet auf der seriellen Schnittstelle die Zeilenumbrüche so, dass PuTTY nur in die nächste Zeile springt, ohne wieder am Zeilenanfang anzufangen...
Das sollte doch per Terminal-Konfiguration in der jeweiligen Putty-Session anpaßbar sein... :)
Ohjeee.... und noch ein Nachtrag. >:(
Ich Hornochse ::) - sorry für die Verwirrung!!
Da ich noch nicht sicher war, in welches Gehäuse ich das ganze packen werde, habe ich die LEDs erstmal nicht bestückt.
Ein Blick in den Schaltplan mit dem Gedanken "vielleicht klappt Senden ja gar nicht, was könnte defekt sein" zeigt sofort:
Ohne rote LED wird auch nichts gesendet...
Ich behebe das heute und melde mich dann mit dem Ergebnis. :o
@sua:
Ja, ist es natürlich - aber bisher musste ich das für keinen Client umstellen, also scheint ebusd-esp hier etwas anders zu machen als alle anderen... Ist ja auch nicht wichtig, aber könnte im nächsten Release geändert werden.
immer noch halb OT:
Zitat von: Sven77 am 19 Oktober 2018, 13:12:54Ja, ist es natürlich - aber bisher musste ich das für keinen Client umstellen, also scheint ebusd-esp hier etwas anders zu machen als alle anderen... Ist ja auch nicht wichtig, aber könnte im nächsten Release geändert werden.
Ich denke, die Diskussion, ob nach einem CR ein LF kommt oder ob ein LF auch ein CR beinhaltet, ist so alt, wie es anpaßbare "Terminals" gibt, also bestimmt schon seit ca. 70 Jahre... ;D
Meine persönliche Meinung:
Wenn so etwas im Quellcode wirklich nur das Einfügen eines Bytes erfordert, ok könnte man abändern (sendezeitkritisch?), ansonst würde ich da keine Zeit investieren, das "Terminal" hat sich eben dem "Sender" anzupassen, dazu gibt es ja die Optionen...
Gut, gut - nun ist es amtlich:
Dank meiner Blödheit, die TX-LED nicht zu bestücken, konnte der Adapter nicht schreiben, was zu den Problemen im TCP Mode führte.
Dennoch habe ich im Enhanced Mode nach spätestens 2 empfangenen Nachrichten im Log den Fehler "[bus error] arbitration start error"!
Und somit weiterhin das Problem, dass nicht immer alle CSVs gelesen werden (also ein Folgefehler von nicht vorhandener Schreib/Arbitrierungsmöglichkeit).
Kann man das Schreiben im Enhanced Mode irgendwie debuggen/anpassen?
Zitat von: Sven77 am 19 Oktober 2018, 18:01:05
Dennoch habe ich im Enhanced Mode nach spätestens 2 empfangenen Nachrichten im Log den Fehler "[bus error] arbitration start error"!
Und somit weiterhin das Problem, dass nicht immer alle CSVs gelesen werden (also ein Folgefehler von nicht vorhandener Schreib/Arbitrierungsmöglichkeit).
Kann man das Schreiben im Enhanced Mode irgendwie debuggen/anpassen?
das lässt sich im Moment nur durch Einschalten des raw logging mit Bytes in ebusd näher analysieren. Ich vermute, dass die anderen Geräte, die bei Dir am Bus hängen, deutlich schneller als in der laut Spec. vorgesehenen Zeit mit Arbitrierung beginnen, weshalb das trotz Hardware-Unterstützung immer noch nicht genügt.
Also; das kann zwar theoretisch sein - ABER...
Der Grund, eine low-latency-Verion einzusetzen ist bei mir folgender:
Von Zeit zu Zeit kann meine VRC700 den icoVIT nicht erfolgreich nach der Außentemperatur fragen. Das macht sie normalerweise minütlich und wenn mal 2 Minuten aufeinander die Abfrage nicht erfolgt (oder vielleicht sofort und ebusd kommt nur nicht immer mit dem Loggen nach), fällt die Steuerung auf ein Fallback von -40°C zurück und fährt alle Vorlauftemperaturen auf Maximum. Das ist zwar dumm gelöst, aber Vaillant wird daran nichts ändern, zumal sie den Fehler bisher nicht nachstellen konnten.
Allem Anschein nach kommt dieses Problem auch immer dann, wenn ebusd durch zu hohe Latenz die Bus-Arbitrierung "versaut" und dazwischen funkt, obwohl es gar nicht an der Reihe ist.
Nun zum Testaufbau:
Ich habe neben den Vaillant Geräten (00/05="VR900", 01/06/ed="VPM-20S", 03/08="icoVIT 156/3", 0a/12/f7/fc="VPM-20W", 10/15/ec="VRC700/4", 26="VR71") noch einen Adapter mit FT232 auf Addresse 31 und den Wemos auf Adresse 33.
Ich wollte die Funktion des Wemos erst komplett testen, bevor ich den USB-Adapter außer Betrieb nehme, daher die Dopplung.
Ich kann natürlich auch mal den USB-Adapter zu Readonly kastrieren, dass dieser erstmal nicht den Bus stören kann oder ihn ganz raus nehmen.
Mir fiel gerade auch noch auf, dass ich beim USB Adapter mal "--receivetimeout=100000" hinzugefügt hatte, das habe ich jetzt für den Wemos übernommen.
Dennoch sehe ich (auch ohne laufende Instanz für den USB) immer wieder "[bus error] arbitration start error" - was genau meint er mit "start error"? Ist das normal und ich kann es ignorieren?
Außerdem seltsam: heute zeigt er mit plötzlich beim Wemos-Adapter (im enh Mode) auch die "min/max arbitration micros" an - auch wenn diese nach wie vor gigantisch groß sind:
$ ebusctl -p 8888 info
version: ebusd 3.2.v3.2-25-gce4f500
update check: revision v3.2-11-g18bd21f available, broadcast.csv: newer version available, vaillant/06.pms.csv: different version available, vaillant/08.bai.csv: newer version available, vaillant/0a.pmw.hwc.csv: newer version available, vaillant/26.vr_71.csv: newer version available, vaillant/broadcast.csv: different version available, vaillant/ed.pms.sc.csv: different version available, vaillant/errors.inc: newer version available, vaillant/hwcmode.inc: newer version available
access: *
signal: acquired
symbol rate: 32
max symbol rate: 133
min arbitration micros: 2744
max arbitration micros: 2744
min symbol latency: 4
max symbol latency: 31
reconnects: 0
masters: 6
messages: 738
conditional: 18
poll: 0
update: 7
address 00: master #1
address 01: master #6
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=1203;HW=3103"
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401", loaded "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
Zitat von: Sven77 am 21 Oktober 2018, 13:09:11
Allem Anschein nach kommt dieses Problem auch immer dann, wenn ebusd durch zu hohe Latenz die Bus-Arbitrierung "versaut" und dazwischen funkt, obwohl es gar nicht an der Reihe ist.
du könntest mal mit Master Adresse 0x00 arbeiten, dann sollte ebusd eigentlich immer die Arbitrierung gewinnen, zumindest wenn das Timing einigermaßen zusammenpasst und flott genug ist.
Ja, das scheint dann die einzige Möglichkeit...
Dummerweise ist die schon vom VR900 belegt - dann muss ich das Ding mal abklemmen!
Auf meinem Bus sind ohne meine Interaktion fast nur Nachrichten vom Master 10 (VRC700/4) zu sehen - das Ding ist aber auch echt gesprächig... Nun habe ich schon die kleinste freie Masteradresse 07 probiert, aber die Reihenfolge scheint ja wohl 00 -> 10 -> 30 -> ... -> 01 -> 11 -> ... usw. zu sein >:(
Und mit der 30 war es leider auch nicht besser.
Ich habe jetzt zur Entspannung der Situation erstmal noch die Optionen "--receivetimeout=100000 --acquiretimeout=20000 --acquireretries=10 --sendretries=10" ergänzt, seitdem läuft das Schreiben erstmal zuverlässiger; aber "arbitration start error" erscheint weiterhin.
Ich melde mich wieder, wenn ich den VR900 abgebaut und mit der 00 probiert habe.
Wie versprochen das Feedback:
Einen halben Tag lang auf Adresse 00 --> keine Bus arbitration start error mehr.
Leider ist die ja bei mir schon besetzt und ich betrachte diesen "Fehler" nun als "Warnung" und betreibe Ebusd mit den erhöhten Retries...
Zitat von: Sven77 am 24 Oktober 2018, 09:00:20
Einen halben Tag lang auf Adresse 00 --> keine Bus arbitration start error mehr.
Leider ist die ja bei mir schon besetzt und ich betrachte diesen "Fehler" nun als "Warnung" und betreibe Ebusd mit den erhöhten Retries...
ok, Danke. Dein Lösungsansatz klingt vernünftig :-)
Ich muss hier leider doch nochmal ansetzen...
Ich frage in einem Script zyklisch alle 30s ein paar Werte mittels "ebusctl r ..." ab. Seit der Umstellung auf Wemos/Wifi/Enhanced funktioniert das irgendwann nicht mehr, weil irgendein Read blockiert. Mit den Werten oben dauerte es letztlich nicht mal mehr eine Stunde, bis nichts mehr ging.
Ich habe jetzt auf "--acquiretimeout=12000 --acquireretries=5 --sendretries=5" reduziert und es läuft wenigstens einen oder ein paar Tage, doch auch dann ist irgendwann Schluss!
Wenn ich in diesem Zustand irgendeinen 'ebusctl' Befehl absetze, blockiert dieser einfach. Ein Blick mit 'ps' oder 'top' in die Prozessliste zeigt den Leseversuch als "sleeping" und die Zeit bei "Time" zählt alle ca. 20s um 1s hoch:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30259 pi 20 0 3420 20 8 S 0.0 0.0 0:18.13 ebusctl
Wenn ich nun diesen Prozeß kille, geht es (erstmal) weiter - aber was passiert hier und warum so lange?
Aktuell steht dieser Zustand seit ca. 12,5h - zumindest hat seitdem mein Script keine Werte mehr aktualisiert.
Ich weiß nun nicht, wie Ebusd arbeitet - aber wenn ich vom "worst case" ausgehe, wie meine Werte zu interpretieren sind, dann sollte er pro Nachricht maximal 8,5h (500 Min) warten:
100s (receivetimeout) * 5 (sendretries) * 12s (acquiretimeout) * 5 (acquireretries) = 30000s = 500 Min
Wenn diese Berechnung stimmt, könnte es aber bei den Standardwerten auch schon gute 15 Minuten dauert, bevor 'ebusctl' abbricht - was ich so nie erlebt habe, und das obwohl ich schon von Anfang an mit "--receivetimeout=100000" arbeite, was dann 1h Wartezeit ergeben würde.
Also zum eigentlichen Problem:
Was könnte hier zur Blockade führen?
Warum alle 30 Sekunden abfragen? Mein erster Ansatz wäre, das nur 1x pro Minute zu tun.
LG
pah
Das sollte nicht das Problem sein!
Es sind nur wenig Werte, die ich 2x pro Minute abfrage, die meisten anderen sogar nur alle 2 Min - davon abgesehen laufen die Abfragen immer seriell und auch alle bevorzugt aus dem Cache. Die Blockaden kommen aber auch bei Cache-Abfragen aufgefangener Broadcasts - damit sollte Ebusd alle 30s eigentlich nicht überfordert sein.
Dazu kommt: mit einer älteren Ebusd und USB-Adapter hatte ich das Problem nie. Ich könnte jetzt auch mit dieser aktuellen Version mal auf einen USB-Adapter oder zur "normalen" TCP Anbindung wechseln und vergleichen - ich persönlich denke aber, dass es entweder mit "enh" oder generell mit "tcp" auftritt.
Und aus akademischer Sicht sollte man vielleicht auch die Ursache suchen, statt nur das Auftreten zu umgehen... ;)
Ach ja, vielleicht eine interessante Randbemerkung:
Ebusd selbst loggt unbeirrt weiter die eintreffenden Reads vom Bus - allein der Clientport 8888 scheint eben nicht mehr zu funktionieren... Ich würde es nicht mal auf den Schreib-Teil beschränken, denn ein "ebusctl info" sollte doch nicht aktiv auf dem Bus schreiben, oder?
Ich habe immer noch Probleme die aktuelle ebusd-esp Version auf den D1 mini zu flashen. Auf insgesamt drei verschiedenen Boards, darunter ein "original Wemos" habe ich immer die gleichen Probleme, d.h. WLAN "EBUS" verbindet sich kurz um sofort wieder zu verschwinden. Auf der seriellen Konsole wiederholt sich dabei immer wieder folgendes:
Welcome to eBUS adapter 2.0, build 20181020
Configured as WIFI access point EBUS without password.
For configuration with web browser, connect to this WIFI and open http://192.168.4.1/
Entering configuration mode.
Chip ID: 00DE049C
Exception (28):
epc1=0x40218210 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: cont
sp: 3fff28a0 end: 3fff2cf0 offset: 01a0
>>>stack>>>
3fff2a40: 4021690c 3fff2b40 3fff2add 40212c30
3fff2a50: 00000006 3fff06cc 3fff06cc 40222778
3fff2a60: 3ffe8304 0000000d 00000010 3ffebd84
3fff2a70: 3fff2ae3 3ffea8b0 3fff434c 40104552
3fff2a80: 402187db 3fff434c 3fff4392 3ffea8bc
3fff2a90: 00000000 3ffe8304 3fff2b40 40216d6c
3fff2aa0: 00000000 ffffffff 00000000 00000000
3fff2ab0: 00000006 0000000a 3f302073 3fff2b20
3fff2ac0: 4021690c 3fff2bc0 3fff2b62 40212c30
3fff2ad0: 00000001 3fff4338 3fff434c 304544f8
3fff2ae0: 00433934 00005801 0000000a 3ffebd84
3fff2af0: 3fff2b63 3ffeb6c8 00000000 4010053d
3fff2b00: 3fff2c70 3fff2c40 0000000c 00000008
3fff2b10: 3ffea8bb 0000000a 3fff2bc0 3fff2f28
3fff2b20: 00000010 00000010 00000000 3fff1ad4
3fff2b30: 3fff1bfc 3ffe8304 00000040 4021474d
3fff2b40: 3fff2bfa 00000002 00000035 ffff0208
3fff2b50: 3fff2bf0 0000003f 3fff4c34 4021089f
3fff2b60: 3fff4a6c 00000004 3fff4c34 402108eb
3fff2b70: 4020fd1d 00000030 3fff4c34 4021091d
3fff2b80: 3fff2c74 3fff18d8 3fff4c34 40210a20
3fff2b90: 00000001 3ffeb6cb 3fff4c0c 40210a48
3fff2ba0: 3fff2f28 000002d2 000002d2 3fff1ad4
3fff2bb0: 3fff2f28 00000008 3fff1bfc 40214790
3fff2bc0: 3fff2c70 3fff2c40 00000008 40211cd4
3fff2bd0: 00000000 3fff4a44 3fff4ab4 00000012
3fff2be0: 3fff1bfc 00000008 3fff2bf0 4020fe8c <
3fff2bf0: 74736f48 656d616e 4430203a 39343045
3fff2c00: 40000a43 3fff18d8 3fff4c64 40218b0f
3fff2c10: 3fff2f28 3fff18d8 3fff4c64 4020996a
3fff2c20: 00000000 40211770 3fff2c74 40100690
3fff2c30: 3fff2c70 3fff2c40 00000008 4020a680
3fff2c40: 3fff1a74 40211770 00000000 0000007e
3fff2c50: 6000001c 00000012 00000000 00000002
3fff2c60: 3ffea8b0 00000000 3fff2c40 3fff2c70
3fff2c70: 40208bb7 3fff1bfc 3fff2c90 3fff1ad4
3fff2c80: 3fff1a74 00000000 3fff1bfc 402069a0
3fff2c90: 00000000 00000000 00000000 3ffeb6d8
3fff2ca0: 0104a8c0 feefeffe feefeffe feefeffe
3fff2cb0: feefeffe feefeffe feefeffe feefeffe
3fff2cc0: feefeffe feefeffe feefeffe 3fff1cbc
3fff2cd0: 3fffdad0 00000000 3fff1cb5 40211420
3fff2ce0: feefeffe feefeffe 3fff1cd0 40100710
<<<stack<<<
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v4ceabea9
~ld
Bei der Internetrecherche zu der Fehlermeldung ets Jan 8 2013,rst cause:2, boot mode:(3,6) finden sich verschiedene Hinweise, dass bei der Programmierung die Pin-Nummern falsch "verdrahtet" werden: https://www.computerhilfen.de/info/esp8266-nodemcu-loesung-fuer-ets-jan-8-2013rst-cause4-boot-mode36.html
Was tun?
In dem Artikel geht es um "rst cause:4", bei dir meldet er aber "2".
Hier (https://github.com/esp8266/Arduino/issues/1013#issuecomment-156318049) steht, dass das den Reset-Pin betrifft bzw. eine zu schwache Spannungsversorgung.
Allerdings schreibt hier (https://github.com/esp8266/Arduino/issues/2414) ganz unten auch jemand, dass das Löschen des gesamten Flashspeichers für ihn das Problem behoben hat...
Zitat von: Sven77 am 03 November 2018, 10:56:49
In dem Artikel geht es um "rst cause:4", bei dir meldet er aber "2".
Oh, das mit dem "rst cause" hatte ich übersehen.
Zitat von: Sven77 am 03 November 2018, 10:56:49
Hier (https://github.com/esp8266/Arduino/issues/1013#issuecomment-156318049) steht, dass das den Reset-Pin betrifft bzw. eine zu schwache Spannungsversorgung.
Auf dem gleichen Board funktioniert die ebusd-esp von Ende 2017 problemlos, für mich ein Indiz, dass es nicht an der Spannungsversorgung liegen kann - oder doch?
Zitat von: Sven77 am 03 November 2018, 10:56:49
Allerdings schreibt hier (https://github.com/esp8266/Arduino/issues/2414) ganz unten auch jemand, dass das Löschen des gesamten Flashspeichers für ihn das Problem behoben hat...
Löschen des Flash mittels "esptool.py erase_flash" als auch mit EraseEsp8266Flash (https://github.com/kentaylor/EraseEsp8266Flash) bisher ohne Erfolg...
Im vorletzten Post schreibt jemand "I had the same problem. It was caused by using delayMicroseconds() many times consecutively."
@John30: verwendest Du das in Deinem Code?
Zitat von: dkreutz am 03 November 2018, 11:46:00
Im vorletzten Post schreibt jemand "I had the same problem. It was caused by using delayMicroseconds() many times consecutively."
@John30: verwendest Du das in Deinem Code?
nein, das wird nicht benutzt.
Zitat von: Sven77 am 30 Oktober 2018, 09:51:54
Was könnte hier zur Blockade führen?
Du nimmst jetzt den enhanced Branch richtig?
also der ist natürlich noch als experimentell einzustufen (darum auch der separate Branch), da hier der Teil mit der Arbitrierung umgezogen wurde und für die Verwendung im Wemos auch umgeschrieben werden musste. Ich kann nur annehmen, dass noch ein weiterer client request in der Queue hängt und dieser wegen eines Bugs in dem neu geschriebenen Code und/oder in der Kommunikation mit Wemos nicht ordentlich beendet wird. Das würde zumindest genau zu dem beschriebenen Phänomen führen. Leider komme ich mindestens die nächsten 3 Wochen nicht dazu, das zu analysieren.
Es drängt ja nichts!!
Ja, ich verwende den enhanced_device Branch und hatte auch den "enh" Mode aktiviert. Vor einer Stunde habe ich es mal (mit gleichem Binary/Branch) auf normales TCP gestellt und beobachte damit noch. Im Grunde geht es ja auch mir darum, diese Entwicklung zu unterstützen - auch wenn ich es "produktiv" nutze, ist mir der experimentelle Status durchaus bewusst... wenn es mal nicht geht, stimmen halt meine angezeigten Temperaturen nicht - zu kalt oder zu warm wird es im Haus dennoch nicht. :-)
@john30:
Wie ich das gesehen habe, kann man den enhanced_mode ja auch bei serieller Anbindung nutzen, richtig?
Ich würde das auch gern probieren - auf Dauer würde mir das WLAN dazwischen ohnehin nicht gefallen, aber:
Was muss ich auf der esbud-esp Seite bei "6. ebusd RX+TX PINs" konfigurieren und wie lautet dann der richtige "ebusd device string"?
Zitat von: Sven77 am 05 November 2018, 12:10:26
Wie ich das gesehen habe, kann man den enhanced_mode ja auch bei serieller Anbindung nutzen, richtig?
richtig
Zitat von: Sven77 am 05 November 2018, 12:10:26
Was muss ich auf der esbud-esp Seite bei "6. ebusd RX+TX PINs" konfigurieren und wie lautet dann der richtige "ebusd device string"?
auf ebusd-esp Seite: ebusd connection auf enhanced mit Port "0" setzen, was nur geht, wenn RX+TX PINs auf "mixed software D1 + TX1 D4" steht, womit Du dann natürlich die Verdrahtung anpassen musst.
auf ebusd Seite: "-d enh:/dev/ttyUSB0" (oder welcher Port auch immer)
Okay, Verkabelung geändert, direkt am Host angeschlossen (spart ja gleichzeitig die separate Stromversorgung), aber es geht nicht. :-(
Empfangen scheint zu funktionieren, Senden vermutlich nicht - oder der Empfang ist fehlerhaft, jedenfalls bekomme ich gleich von Anfang an reichlich Fehlermeldungen "ERR: wrong symbol received" und er lädt daraufhin keine CSVs:
2018-11-05 19:56:06.378 [main notice] ebusd 3.2.v3.2-25-gce4f500 started with auto scan
2018-11-05 19:56:06.600 [bus notice] bus started with own address 31/36
2018-11-05 19:56:06.619 [bus notice] signal acquired
2018-11-05 19:56:09.273 [bus notice] new master 10, master count 2
2018-11-05 19:56:09.340 [bus notice] new master 03, master count 3
2018-11-05 19:56:09.340 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:56:09.642 [update notice] received unknown MS cmd: 1026b5230106 / 104202ed01f80100806d021a023a034000
2018-11-05 19:56:09.943 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:56:10.220 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:56:11.006 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:56:11.258 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:56:11.510 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:56:19.362 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:56:19.421 [main error] scan config 08: ERR: wrong symbol received
2018-11-05 19:56:19.664 [update notice] received unknown MS cmd: 1026b5230106 / 104102f001f80100806d021a023a034000
2018-11-05 19:56:19.964 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:56:20.226 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2018-11-05 19:56:20.509 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:56:20.791 [update notice] received unknown MS cmd: 1008b5040100 / 0a0338581905110118900a
2018-11-05 19:56:21.033 [update notice] received unknown BC cmd: 10feb516080035581905110118
2018-11-05 19:56:21.310 [update notice] received unknown MS cmd: 1008b5110100 / 086002100000080081
2018-11-05 19:56:21.605 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:56:21.665 [main error] scan config 15: ERR: wrong symbol received
2018-11-05 19:56:21.856 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:56:22.110 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:56:22.332 [update notice] received unknown BC cmd: 10feb5160301900a
2018-11-05 19:56:29.420 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:56:29.478 [main error] scan config 26: ERR: wrong symbol received
2018-11-05 19:56:29.725 [update notice] received unknown MS cmd: 1026b5230106 / 104102f001f80100806c021a023a034000
2018-11-05 19:56:30.021 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:56:30.302 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:56:31.083 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:56:31.340 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:56:31.587 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:56:39.443 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:56:39.746 [update notice] received unknown MS cmd: 1026b5230106 / 104102f001f80100806c021a023a034000
2018-11-05 19:56:40.044 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:56:40.325 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:56:41.108 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:56:41.364 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:56:41.614 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:56:41.629 [main error] scan config 08: ERR: wrong symbol received
2018-11-05 19:56:49.464 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:56:49.522 [main error] scan config 15: ERR: wrong symbol received
2018-11-05 19:56:49.768 [update notice] received unknown MS cmd: 1026b5230106 / 104102f501f80100806c0219023a034000
2018-11-05 19:56:50.071 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:56:50.326 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2018-11-05 19:56:50.606 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:56:51.172 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:56:51.422 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:56:51.674 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:56:51.692 [main error] scan config 26: ERR: wrong symbol received
2018-11-05 19:56:59.524 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:56:59.826 [update notice] received unknown MS cmd: 1026b5230106 / 104102f501f80100806c0219023a034000
2018-11-05 19:57:00.125 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:57:00.401 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:57:01.189 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:57:01.442 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:57:01.693 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:57:09.544 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:57:09.604 [main error] scan config 08: ERR: wrong symbol received
2018-11-05 19:57:09.850 [update notice] received unknown MS cmd: 1026b5230106 / 104102f301f80100806c0219023a034000
2018-11-05 19:57:10.148 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:57:10.431 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:57:11.216 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:57:11.466 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:57:11.720 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:57:19.613 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:57:19.672 [main error] scan config 15: ERR: wrong symbol received
2018-11-05 19:57:19.915 [update notice] received unknown MS cmd: 1026b5230106 / 104102f101f80100806c0219023a034000
2018-11-05 19:57:20.216 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:57:20.477 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2018-11-05 19:57:20.764 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:57:21.046 [update notice] received unknown MS cmd: 1008b5040100 / 0a0339591905110118900a
2018-11-05 19:57:21.291 [update notice] received unknown BC cmd: 10feb516080036591905110118
2018-11-05 19:57:21.562 [update notice] received unknown MS cmd: 1008b5110100 / 086602100000080081
2018-11-05 19:57:21.855 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:57:21.870 [main error] scan config 26: ERR: wrong symbol received
2018-11-05 19:57:22.107 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:57:22.358 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:57:22.579 [update notice] received unknown BC cmd: 10feb5160301900a
2018-11-05 19:57:22.841 [update notice] received unknown MS cmd: 100ab504030d0001 / 05320100802c
2018-11-05 19:57:23.092 [update notice] received unknown MS cmd: 1008b5100305ff01 / 00
2018-11-05 19:57:23.336 [update notice] received unknown MS cmd: 1008b512020064 / 00
2018-11-05 19:57:23.587 [update notice] received unknown MS cmd: 1008b5120204ff / 00
2018-11-05 19:57:23.840 [bus notice] new master 01, master count 4
2018-11-05 19:57:23.840 [update notice] received unknown MS cmd: 1006b5080707010150039002 / 00
2018-11-05 19:57:24.087 [update notice] received unknown MS cmd: 1008b513020508 / 00
2018-11-05 19:57:24.301 [update notice] received unknown BC cmd: 10feb510020601
2018-11-05 19:57:24.568 [update notice] received unknown MS cmd: 1006b50903295600 / 0656001b000000
2018-11-05 19:57:29.609 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:57:29.914 [update notice] received unknown MS cmd: 1026b5230106 / 104102eb01f80100806b0219023a034000
2018-11-05 19:57:30.213 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:57:30.491 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:57:31.317 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:57:31.575 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:57:31.821 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:57:39.666 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:57:39.681 [main error] scan config 06: ERR: wrong symbol received
2018-11-05 19:57:39.969 [update notice] received unknown MS cmd: 1026b5230106 / 104102e601f70100806b0219023a034000
2018-11-05 19:57:40.270 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:57:40.551 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:57:41.333 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:57:41.586 [update notice] received unknown MS cmd: 1026b523040200014c / 02013c
2018-11-05 19:57:41.836 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:57:41.895 [main error] scan config 08: ERR: wrong symbol received
2018-11-05 19:57:49.700 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:57:50.087 [update notice] received unknown MS cmd: 1026b5230106 / 104002df01f70100806b0219023a034000
2018-11-05 19:57:50.146 [main error] scan config 0a: ERR: wrong symbol received
2018-11-05 19:57:50.385 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:57:50.648 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2018-11-05 19:57:50.928 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:57:51.021 [bus notice] max. symbols per second: 101
2018-11-05 19:57:51.356 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:57:51.607 [update notice] received unknown MS cmd: 1026b523040200014c / 02013c
2018-11-05 19:57:51.860 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:57:55.326 [bus notice] device invalid
2018-11-05 19:58:00.344 [bus notice] re-opened /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2018-11-05 19:58:00.406 [bus error] signal lost
2018-11-05 19:58:00.411 [main error] scan config 15: ERR: no signal
2018-11-05 19:58:07.665 [main notice] ebusd 3.2.v3.2-25-gce4f500 started with auto scan
2018-11-05 19:58:07.740 [bus notice] bus started with own address 31/36
2018-11-05 19:58:09.089 [bus notice] signal acquired
2018-11-05 19:58:09.725 [bus notice] new master 10, master count 2
2018-11-05 19:58:09.789 [bus notice] new master 03, master count 3
2018-11-05 19:58:09.789 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:58:10.096 [update notice] received unknown MS cmd: 1026b5230106 / 104002e801f70100806b0219023a034000
2018-11-05 19:58:10.395 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:58:10.674 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:58:11.461 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:58:11.712 [update notice] received unknown MS cmd: 1026b523040200014c / 02013c
2018-11-05 19:58:11.964 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:58:19.814 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:58:19.872 [main error] scan config 08: ERR: wrong symbol received
2018-11-05 19:58:20.120 [update notice] received unknown MS cmd: 1026b5230106 / 104002e801f70100806a0219023a034000
2018-11-05 19:58:20.419 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:58:20.680 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2018-11-05 19:58:20.956 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:58:21.008 [bus notice] max. symbols per second: 105
2018-11-05 19:58:21.240 [update notice] received unknown MS cmd: 1008b5040100 / 0a0340002005110118900a
2018-11-05 19:58:21.481 [update notice] received unknown BC cmd: 10feb516080037002005110118
2018-11-05 19:58:21.757 [update notice] received unknown MS cmd: 1008b5110100 / 086002100000080081
2018-11-05 19:58:22.051 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:58:22.110 [main error] scan config 15: ERR: wrong symbol received
2018-11-05 19:58:22.368 [update notice] received unknown MS cmd: 1026b523040200014c / 02013c
2018-11-05 19:58:22.556 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 19:58:22.778 [update notice] received unknown BC cmd: 10feb5160301900a
2018-11-05 19:58:29.872 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:58:30.268 [update notice] received unknown MS cmd: 1026b5230106 / 104002ee01f70100806a0219023a034000
2018-11-05 19:58:30.327 [main error] scan config 26: ERR: wrong symbol received
2018-11-05 19:58:30.565 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:58:30.846 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:58:31.540 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:58:31.793 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:58:32.046 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
Und nach den beiden erfolglosen Versuchen der Start mit Port 9999 über "enhtcp", ohne etwas an der Verkabelung oder RX/TX-Einstellung zu ändern:
2018-11-05 19:59:49.635 [main notice] ebusd 3.2.v3.2-25-gce4f500 started with auto scan
2018-11-05 19:59:49.983 [bus notice] bus started with own address 31/36
2018-11-05 19:59:49.998 [bus notice] signal acquired
2018-11-05 19:59:50.079 [bus notice] new master 10, master count 2
2018-11-05 19:59:50.143 [bus notice] new master 03, master count 3
2018-11-05 19:59:50.144 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 19:59:50.446 [update notice] received unknown MS cmd: 1026b5230106 / 103f02f301f7010080690218023a034000
2018-11-05 19:59:50.751 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 19:59:51.005 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2018-11-05 19:59:51.281 [update notice] received unknown MS cmd: 1008b5100900005e58ffff000000 / 0101
2018-11-05 19:59:51.844 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 19:59:52.092 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 19:59:52.343 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 20:00:00.185 [update notice] received unknown MS cmd: 1008b5110101 / 094cff900a00ff4000ff
2018-11-05 20:00:00.351 [bus notice] scan 08: ;Vaillant;BAI00;0902;7401
2018-11-05 20:00:00.352 [update notice] store 08 ident: done
2018-11-05 20:00:00.354 [update notice] sent scan-read scan.08 QQ=31: Vaillant;BAI00;0902;7401
2018-11-05 20:00:00.354 [bus notice] scan 08: ;Vaillant;BAI00;0902;7401
2018-11-05 20:00:00.530 [main notice] read common config file vaillant/broadcast.csv
2018-11-05 20:00:00.533 [main notice] read common config file vaillant/scan.csv
2018-11-05 20:00:00.581 [update notice] received unknown MS cmd: 1026b5230106 / 103f02f001f7010080690218023a034000
2018-11-05 20:00:00.873 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0902, HW7401
2018-11-05 20:00:00.878 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 20:00:00.879 [main notice] found messages: 245 (3 conditional on 1 conditions, 0 poll, 7 update)
2018-11-05 20:00:01.012 [bus notice] max. symbols per second: 108
2018-11-05 20:00:01.163 [update notice] received write bai ExtFlowTempDesired QQ=10: 00;47.0;44.0;-;ff;00;00;00
2018-11-05 20:00:01.330 [update notice] sent unknown MS cmd: 3108b5090124 / 09000000000000000000
2018-11-05 20:00:01.502 [update notice] sent scan-read scan.08 id QQ=31:
2018-11-05 20:00:01.679 [update notice] sent scan-read scan.08 id QQ=31:
2018-11-05 20:00:01.738 [bus error] arbitration start error
2018-11-05 20:00:01.901 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 20:00:02.029 [bus notice] max. symbols per second: 121
2018-11-05 20:00:02.149 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 20:00:02.307 [update notice] sent scan-read scan.08 id QQ=31: ;;;;;;
2018-11-05 20:00:02.308 [bus notice] scan 08: ;;;;;;;
2018-11-05 20:00:02.483 [update notice] received unknown MS cmd: 1026b5230402010140 / 020100
2018-11-05 20:00:10.249 [update notice] received read bai Status01 QQ=10: 38.0;-;10.562;0.0;-;40 00 ff
2018-11-05 20:00:10.391 [bus notice] scan 15: ;Vaillant;70000;0510;6403
2018-11-05 20:00:10.391 [update notice] store 15 ident: done
2018-11-05 20:00:10.455 [update notice] sent scan-read scan.15 QQ=31: Vaillant;70000;0510;6403
2018-11-05 20:00:10.455 [bus notice] scan 15: ;Vaillant;70000;0510;6403
2018-11-05 20:00:10.609 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313833333030
2018-11-05 20:00:10.845 [update notice] sent scan-read scan.15 id QQ=31:
2018-11-05 20:00:10.999 [update notice] sent scan-read scan.15 id QQ=31:
2018-11-05 20:00:11.003 [bus notice] max. symbols per second: 139
2018-11-05 20:00:11.058 [bus error] arbitration start error
2018-11-05 20:00:11.219 [update notice] received unknown MS cmd: 1026b5230107 / 0ff2020080008000800000800080fc05
2018-11-05 20:00:11.501 [update notice] received write bai ExtFlowTempDesired QQ=10: 00;47.0;44.0;-;ff;00;00;00
2018-11-05 20:00:11.669 [update notice] sent scan-read scan.15 id QQ=31: 21;18;33;0020218356;0082;005988;N0
2018-11-05 20:00:11.670 [bus notice] scan 15: ;21;18;33;0020218356;0082;005988;N0
2018-11-05 20:00:11.891 [update notice] received unknown MS cmd: 1026b5230f05ffff00000000ffffffff00000000 / 0101
2018-11-05 20:00:12.151 [update notice] received unknown MS cmd: 1026b523040200014c / 020137
2018-11-05 20:00:12.362 [main notice] read scan config file vaillant/15.700.csv for ID "70000", SW0510, HW6403
Da ebusd als root läuft, dürfte es ja nicht an irgendwelchen Berechtigungen liegen?!
Zitat von: Sven77 am 05 November 2018, 20:16:16
Empfangen scheint zu funktionieren, Senden vermutlich nicht - oder der Empfang ist fehlerhaft, jedenfalls bekomme ich gleich von Anfang an reichlich Fehlermeldungen "ERR: wrong symbol received" und er lädt daraufhin keine CSVs:
hm, da müsstest Du mal das raw log anschauen, vielleicht wird hier was verschlulckt, was eigentlich nicht sein sollte. Und es sieht so aus, als würde der Wemos zwischendurch mal rebooten, sollte natürlich auch nicht sein...
Zitat von: john30 am 07 November 2018, 08:00:01
Und es sieht so aus, als würde der Wemos zwischendurch mal rebooten, sollte natürlich auch nicht sein...
Sorry, das hätte ich dazu schreiben sollen: den Reboot habe ich ausgelöst, weil ich dachte den Fehler dadurch beheben zu können. Ich habe dann beides im Log gelassen, um zu zeigen, dass es keine Ausnahme war...
Nun aber zu den "raw logs":
1. Versuch: "TCP on port 0", device string "/dev/ttyUSB0":
LogRawDatafile bleibt komplett leer, normales Log berichtet nur vom Start des Daemon:
2018-11-07 20:28:17.398 [main notice] ebusd 3.2.v3.2-25-gce4f500 started with auto scan
2018-11-07 20:28:17.743 [bus notice] bus started with own address 31/362. Versuch: "ENHANCED on port 0", device string "enh:/dev/ttyUSB0":
Normales Log schreibt wie oben gepostet "[main error] scan config ...: ERR: wrong symbol received", LogRawData zeigt, dass offenbar keine komplette Scannachricht geschickt wird!
Meistens sind nur Quell- und Zieladresse zu sehen, einmal sogar auch nur die Quelladresse:
2018-11-07 20:30:37.722 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:30:37.972 <1026b52304020001485b0002010fb800
2018-11-07 20:30:38.222 <1026b523040201013d3800020100b700
2018-11-07 20:30:46.083 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:30:46.385 <1026b5230106d000101b022002e20100804002ff01300340002700
2018-11-07 20:30:46.690 <1026b5230107d1000f96020080008000800000800080fc053a00
2018-11-07 20:30:46.944 <1008b51101028a0005033c9650827e00
2018-11-07 20:30:47.223 <1008b5100900005a58ffff000000670001019a00
2018-11-07 20:30:47.783 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:30:47.873 >3108<ff
2018-11-07 20:30:48.035 <1026b52304020001485b0002010fb800
2018-11-07 20:30:48.290 <1026b523040201013d3800020100b700
2018-11-07 20:30:56.142 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:30:56.228 >3115<ff
2018-11-07 20:30:56.443 <1026b5230106d000101b022002e20100804002ff01300340002700
2018-11-07 20:30:56.743 <1026b5230107d1000f96020080008000800000800080fc053a00
2018-11-07 20:30:57.019 <1008b5100900005a58ffff000000670001019a00
2018-11-07 20:30:57.802 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:30:58.051 <1026b52304020001485b0002010fb800
2018-11-07 20:30:58.303 <1026b523040201013d3800020100b700
2018-11-07 20:30:58.393 >3126<ff
2018-11-07 20:31:06.158 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:31:06.463 <1026b5230106d000101b022002e20100804002ff01300340002700
2018-11-07 20:31:06.762 <1026b5230107d1000f96020080008000800000800080fc053a00
2018-11-07 20:31:07.040 <1008b5100900005a58ffff000000670001019a00
2018-11-07 20:31:07.870 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:31:08.118 <1026b52304020001485b0002010fb800
2018-11-07 20:31:08.374 <1026b523040201013d3800020100b700
2018-11-07 20:31:16.226 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:31:16.316 >3108<ff
2018-11-07 20:31:16.532 <1026b5230106d000101b021f02e20100804002ff0130034000c600
2018-11-07 20:31:16.831 <1026b5230107d1000f96020080008000800000800080fc053a00
2018-11-07 20:31:17.104 <1008b51101028a0005033c9650827e00
2018-11-07 20:31:17.366 <1008b5100900005a58ffff000000670001019a00
2018-11-07 20:31:17.646 <1008b50401003d000a0343332007110318400c1b00
2018-11-07 20:31:17.890 <10feb51608004333200711031888
2018-11-07 20:31:18.313 <1008b51101008800083a020f00000800813e00
2018-11-07 20:31:18.458 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:31:18.546 >3115<ff
2018-11-07 20:31:18.708 <1026b52304020001485b0002010fb800
2018-11-07 20:31:18.960 <1026b523040201013d3800020100b700
2018-11-07 20:31:19.183 <10feb5160301400c18
2018-11-07 20:31:26.231 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:31:26.315 >3126<ff
2018-11-07 20:31:26.529 <1026b5230106d000101b021f02e20100804002ff0130034000c600
2018-11-07 20:31:26.831 <1026b5230107d1000f96020080008000800000800080fc053a00
2018-11-07 20:31:27.109 <1008b5100900005a58ffff000000670001019a00
2018-11-07 20:31:27.936 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:31:28.188 <1026b52304020001485b0002010fb800
2018-11-07 20:31:28.438 <1026b523040201013d3800020100b700
2018-11-07 20:31:36.299 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:31:36.602 <1026b5230106d000101b021f02e20100804002ff0130034000c600
2018-11-07 20:31:36.903 <1026b5230107d1000f96020080008000800000800080fc053a00
2018-11-07 20:31:37.182 <1008b5100900005a58ffff000000670001019a00
2018-11-07 20:31:37.971 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:31:38.220 <1026b52304020001485b0002010fb800
2018-11-07 20:31:38.473 <1026b523040201013d3800020100b700
2018-11-07 20:31:38.562 >3108<ff
2018-11-07 20:31:46.322 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:31:46.412 >31<ff
2018-11-07 20:31:46.713 <1026b5230106d000101a021f02e20100803f02ff0130034000b800
2018-11-07 20:31:46.801 >3115<ff
2018-11-07 20:31:47.011 <1026b5230107d1000f96020080008000800000800080fc053a00
2018-11-07 20:31:47.275 <1008b51101028a0005033c9650827e00
2018-11-07 20:31:47.551 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:31:47.981 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:31:48.233 <1026b52304020001485b0002010fb800
2018-11-07 20:31:48.486 <1026b523040201013d3800020100b700
3. Versuch: "ENHANCED on port 9999", device string "enh:<ipaddress>:9999":
Normales Log fehlerfrei, LogRawData sieht auch besser aus:
2018-11-07 20:35:08.762 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:35:09.006 <1026b52304020001485b0002011ea90000
2018-11-07 20:35:09.308 <1026b523040201013d3800020100b700
2018-11-07 20:35:17.110 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:35:17.409 <1026b5230106d0001018020002e20100803d02fd012f0340009100
2018-11-07 20:35:17.710 <1026b5230107d1000f95020080008000800000800080fc05a500
2018-11-07 20:35:17.969 <1008b51101028a0005033c9650827e00
2018-11-07 20:35:18.249 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:35:18.436 >3108070400d1<000ab5424149303009027401f6>00
2018-11-07 20:35:18.640 <1008b50401003d000a0344372007110318400c9000
2018-11-07 20:35:18.885 <10feb5160800433720071103182a
2018-11-07 20:35:19.167 <1008b511010088000839020f0000080081df00
2018-11-07 20:35:19.320 >3108b509012448<00090000000000000000009c>00
2018-11-07 20:35:19.497 >3108b509012549<00090000000000000000009c>00
2018-11-07 20:35:19.626 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:35:19.744 >3108b50901264a<00090000000000000000009c>00
2018-11-07 20:35:19.910 >3108b50901274b<00090000000000000000009c>00
2018-11-07 20:35:20.042 <1026b52304020001485b0002011ea90000
2018-11-07 20:35:20.295 <1026b523040201013d3800020100b700
2018-11-07 20:35:20.519 <10feb5160301400c18
2018-11-07 20:35:27.134 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:35:27.278 >31150704008b<000ab5373030303005106403a900>00
2018-11-07 20:35:27.429 >3115b509012406<00090032313138333330309f>00
2018-11-07 20:35:27.564 <1026b5230106d0001018020102e20100803d02fd012f0340009f00
2018-11-07 20:35:27.663 >3115b509012507<00093230323138333536307b>00
2018-11-07 20:35:27.828 >3115b509012604<000930383230303539383890>00
2018-11-07 20:35:27.928 >31<20
2018-11-07 20:35:28.046 <1026b5230107d1000f95020080008000800000800080fc05a500
2018-11-07 20:35:28.324 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:35:28.472 >3115b509012705<00094e30000000000000007b>00
2018-11-07 20:35:28.823 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:35:29.075 <1026b52304020001485b0002011ea90000
2018-11-07 20:35:29.333 <1026b523040201013d3800020100b700
2018-11-07 20:35:37.201 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:35:37.332 >31260704003c<000ab556525f37310104050395>00
2018-11-07 20:35:37.541 >3126b5090124ac<000900323131373430303086>00
2018-11-07 20:35:37.677 <1026b5230106d0001018020102e20100803d02fd012f0340009f00
2018-11-07 20:35:37.816 >3126b5090125ad<00093230313834383436305c>00
2018-11-07 20:35:38.007 >3126b5090126ae<0009303832303038333037fa>00
2018-11-07 20:35:38.104 >31<20
2018-11-07 20:35:38.225 <1026b5230107d1000f95020080008000800000800080fc05a500
2018-11-07 20:35:38.518 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:35:38.714 >3126b5090127af<00094e3800000000000000a7>00
2018-11-07 20:35:38.960 <1026b5230f05ffff00000000ffffffff00000000600001019a00
2018-11-07 20:35:39.206 <1026b52304020001485b0002011ea90000
2018-11-07 20:35:39.457 <1026b523040201013d3800020100b700
2018-11-07 20:35:47.211 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:35:47.517 <1026b5230106d0001018020002e20100803d02fd012f0340009100
2018-11-07 20:35:47.820 <1026b5230107d1000f95020080008000800000800080fc05a500
2018-11-07 20:35:48.079 <1008b51101028a0005033c9650827e00
2018-11-07 20:35:48.347 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:35:48.908
2018-11-07 20:35:49.167 <1026b52304020001485b0002011ea90000
2018-11-07 20:35:49.411 <1026b523040201013d3800020100b700
2018-11-07 20:35:57.281 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:35:57.581
2018-11-07 20:35:57.881 <1026b5230107d1000f95020080008000800000800080fc05a500
2018-11-07 20:35:58.161 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:35:58.946
2018-11-07 20:35:59.201 <1026b52304020001485b0002011ea90000
2018-11-07 20:35:59.447 <1026b523040201013d3800020100b700
2018-11-07 20:36:07.308 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:36:07.603
2018-11-07 20:36:07.902 <1026b5230107d1000f95020080008000800000800080fc05a500
2018-11-07 20:36:08.203 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:36:09.021
2018-11-07 20:36:09.242 <1026b52304020001485b0002011ea90000
2018-11-07 20:36:09.491 <1026b523040201013d3800020100b700
2018-11-07 20:36:17.507 <1008b511010189000946ff400c00ff0000ffb200
2018-11-07 20:36:17.631
2018-11-07 20:36:17.931 <1026b5230107d1000f95020080008000800000800080fc05a500
2018-11-07 20:36:18.208 <1008b51101028a0005033c9650827e00
2018-11-07 20:36:18.479 <1008b5100900005b58ffff0000009a0001019a00
2018-11-07 20:36:18.778 <1008b50401003d000a0344382007110318400cc300
Seltsam finde ich dennoch die Zeilen mit nur ">31<20" bzw. nur dem Timestamp, ganz ohne Nachricht. Hier nochmal die zugehörigen Meldungen im normalen Log zu diesem Zeitpunkt - zu besseren Übersicht habe ich die eintreffenden Nachrichten entfernt und beide Logs wieder vereint, dass man sieht welche Raw-Zeile zu welcher Meldung gehört:
2018-11-07 20:35:18.432 [bus notice] scan 08: ;Vaillant;BAI00;0902;7401
2018-11-07 20:35:18.432 [update notice] store 08 ident: done
2018-11-07 20:35:18.433 [update notice] sent scan-read scan.08 QQ=31: Vaillant;BAI00;0902;7401
2018-11-07 20:35:18.433 [bus notice] scan 08: ;Vaillant;BAI00;0902;7401
2018-11-07 20:35:18.436 >3108070400d1<000ab5424149303009027401f6>00
2018-11-07 20:35:19.320 [update notice] sent unknown MS cmd: 3108b5090124 / 09000000000000000000
2018-11-07 20:35:19.320 >3108b509012448<00090000000000000000009c>00
2018-11-07 20:35:19.492 [update notice] sent scan-read scan.08 id QQ=31:
2018-11-07 20:35:19.497 >3108b509012549<00090000000000000000009c>00
2018-11-07 20:35:19.743 [update notice] sent scan-read scan.08 id QQ=31:
2018-11-07 20:35:19.744 >3108b50901264a<00090000000000000000009c>00
2018-11-07 20:35:19.909 [update notice] sent scan-read scan.08 id QQ=31: ;;;;;;
2018-11-07 20:35:19.910 [bus notice] scan 08: ;;;;;;;
2018-11-07 20:35:19.910 >3108b50901274b<00090000000000000000009c>00
2018-11-07 20:35:27.278 [bus notice] scan 15: ;Vaillant;70000;0510;6403
2018-11-07 20:35:27.278 [update notice] store 15 ident: done
2018-11-07 20:35:27.278 [update notice] sent scan-read scan.15 QQ=31: Vaillant;70000;0510;6403
2018-11-07 20:35:27.278 [bus notice] scan 15: ;Vaillant;70000;0510;6403
2018-11-07 20:35:27.278 >31150704008b<000ab5373030303005106403a900>00
2018-11-07 20:35:27.428 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313833333030
2018-11-07 20:35:27.429 >3115b509012406<00090032313138333330309f>00
2018-11-07 20:35:27.663 [update notice] sent scan-read scan.15 id QQ=31:
2018-11-07 20:35:27.663 >3115b509012507<00093230323138333536307b>00
2018-11-07 20:35:27.828 [update notice] sent scan-read scan.15 id QQ=31:
2018-11-07 20:35:27.828 >3115b509012604<000930383230303539383890>00
2018-11-07 20:35:27.883 [bus error] arbitration start error
2018-11-07 20:35:27.928 >31<20
2018-11-07 20:35:28.468 [update notice] sent scan-read scan.15 id QQ=31: 21;18;33;0020218356;0082;005988;N0
2018-11-07 20:35:28.468 [bus notice] scan 15: ;21;18;33;0020218356;0082;005988;N0
2018-11-07 20:35:28.472 >3115b509012705<00094e30000000000000007b>00
2018-11-07 20:35:37.332 [bus notice] scan 26: ;Vaillant;VR_71;0104;0503
2018-11-07 20:35:37.332 [update notice] store 26 ident: done
2018-11-07 20:35:37.332 [update notice] sent scan-read scan.26 QQ=31: Vaillant;VR_71;0104;0503
2018-11-07 20:35:37.332 [bus notice] scan 26: ;Vaillant;VR_71;0104;0503
2018-11-07 20:35:37.332 >31260704003c<000ab556525f37310104050395>00
2018-11-07 20:35:37.541 [update notice] sent unknown MS cmd: 3126b5090124 / 09003231313734303030
2018-11-07 20:35:37.541 >3126b5090124ac<000900323131373430303086>00
2018-11-07 20:35:37.804 [update notice] sent scan-read scan.26 id QQ=31:
2018-11-07 20:35:37.816 >3126b5090125ad<00093230313834383436305c>00
2018-11-07 20:35:38.001 [update notice] sent scan-read scan.26 id QQ=31:
2018-11-07 20:35:38.007 >3126b5090126ae<0009303832303038333037fa>00
2018-11-07 20:35:38.063 [bus error] arbitration start error
2018-11-07 20:35:38.104 >31<20
2018-11-07 20:35:38.703 [update notice] sent scan-read scan.26 id QQ=31: 21;17;40;0020184846;0082;008307;N8
2018-11-07 20:35:38.707 [bus notice] scan 26: ;21;17;40;0020184846;0082;008307;N8
2018-11-07 20:35:38.714 >3126b5090127af<00094e3800000000000000a7>00
2018-11-07 20:35:48.908 [update notice] received write vr_71 SetActorState QQ=10: -;-;off;off;off;off;-;-;-;-;off;off;00 00
2018-11-07 20:35:48.908
2018-11-07 20:35:57.572 [update notice] received read vr_71 SensorData1 QQ=10: 33.50;31.88;30.12;-;35.81;31.81;50.94;40 00
2018-11-07 20:35:57.581
2018-11-07 20:35:58.934 [update notice] received write vr_71 SetActorState QQ=10: -;-;off;off;off;off;-;-;-;-;off;off;00 00
2018-11-07 20:35:58.946
2018-11-07 20:36:07.599 [update notice] received read vr_71 SensorData1 QQ=10: 33.50;31.81;30.12;-;35.81;31.81;50.94;40 00
2018-11-07 20:36:07.603
2018-11-07 20:36:09.012 [update notice] received write vr_71 SetActorState QQ=10: -;-;off;off;off;off;-;-;-;-;off;off;00 00
2018-11-07 20:36:09.021
2018-11-07 20:36:17.631 [update notice] received read vr_71 SensorData1 QQ=10: 33.50;32.00;30.12;-;35.81;31.81;50.94;40 00
2018-11-07 20:36:17.631Die Leerzeilen gehören also offenbar zu Nachrichten, die eigentlich korrekt empfangen wurden. Die "nur-Quelladresse" Zeilen zu einem "arbitration start error".
Ich hoffe, das hilft bei der Fehlersuche. Vor allem wundert mich auch, dass der nicht-enhanced Modus mit "Serial over USB" rein gar nichts macht - er meldet aber auch kein "invalid device" o.ä.!
Es gibt wieder eine neue Adapterversion V2.2!
hier geht's zur Sammelbestellung V2.2! (https://forum.fhem.de/index.php/topic,93190.msg857894.html#msg857894)
LG
Reinhart
@john30:
Hattest du meine Logs vom 7. November gesehen?
Kannst du nachstellen, dass mit der aktuellen Firmware offenbar keine direkte serielle Verbindung genutzt werden kann bzw. kannst du erklären, warum im Nicht-Enhanced-SerialMode bei mir rein gar nichts ankommt?
Aufgrund der genannten Problemchen betreibe ich den Ebusd aktuell ohne "enhanced" über TCP, was recht gut funktioniert - ABER: ich würde erstens gern die Entwicklung des enhanced_mode unterstützen und außerdem gern auf die Wifi-Verbindung verzichten, also direkt die serielle Verbindung des USB am Wemos nutzen!
Zitat von: Sven77 am 27 November 2018, 08:19:54
Hattest du meine Logs vom 7. November gesehen?
ja habs gesehen, hatte aber noch keine Zeit, mir das anzuschauen
Ich muss das Thema "enhanced" mal wieder hochholen...
Gibt es außer mir noch jemanden, der die ebusd-esp Firmware nutzt?
Der einzig brauchbare Modus scheint ja aktuell der normale (also nicht "enhanced") und über WiFi zu sein. Leider kommt es da bei mir immer mal wieder zu Verbindungsabbrüchen - ich kann leider nicht sagen, ob diese vom WLAN oder Ebus kommen.
Beispiele:
2019-04-03 08:17:21.099 [bus error] send to 15: ERR: wrong symbol received, retry
2019-04-03 08:17:23.855 [bus notice] arbitration won in invalid state skip
2019-04-03 08:17:25.040 [bus error] signal lost
2019-04-03 08:17:25.041 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:25.041 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:25.310 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:25.310 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:25.580 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:25.581 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:25.850 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:25.850 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:26.120 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:26.120 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:26.392 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:26.392 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:30.710 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:30.711 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:41.240 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:41.240 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:43.670 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:43.671 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:45.020 [bus error] send to 0a: ERR: no signal, give up
2019-04-03 08:17:45.020 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:45.290 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:45.291 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:45.560 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:45.560 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:46.640 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:46.641 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:52.040 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:52.041 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:53.931 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:53.931 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:54.201 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:54.201 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:55.280 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:55.281 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:56.090 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:56.090 [bus error] send message part 0: ERR: no signal
2019-04-03 08:18:01.760 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:18:01.760 [bus error] send message part 0: ERR: no signal
2019-04-03 08:18:03.387 [bus notice] signal acquired
Oder auch:
2019-04-03 08:34:30.323 [bus error] send to 15: ERR: SYN received, retry
2019-04-03 08:34:30.560 [bus error] send to 15: ERR: read timeout, retry
2019-04-03 08:34:31.116 [bus error] send to 15: ERR: wrong symbol received
2019-04-03 08:34:31.116 [bus error] send message part 0: ERR: wrong symbol received
...
2019-04-03 08:35:17.306 [bus error] send to 08: ERR: wrong symbol received, retry
2019-04-03 08:35:18.003 [update notice] sent read bai CounterStartattempts1 QQ=31: 0
2019-04-03 08:35:18.188 [bus error] send to 08: ERR: SYN received, retry
2019-04-03 08:35:19.220 [bus error] send to 08: ERR: read timeout, retry
Nun sehe ich auf Github zwar einige Commits im Branch enhanced_device, aber diese scheinen eher kosmetischer Natur bzw. die Übernahme vom master Branch. Im ebusd-esp sieht es ähnlich ruhig aus...
Gibt es irgendetwas, wie ich eventuell helfen könnte? Ich wäre sehr an einer Lösung interessiert, die von der Latenz dichter an die Ebus-Spezifikation herankommt!
Zitat von: Sven77 am 03 April 2019, 08:53:32
Der einzig brauchbare Modus scheint ja aktuell der normale (also nicht "enhanced") und über WiFi zu sein. Leider kommt es da bei mir immer mal wieder zu Verbindungsabbrüchen - ich kann leider nicht sagen, ob diese vom WLAN oder Ebus kommen.
...
Nun sehe ich auf Github zwar einige Commits im Branch enhanced_device, aber diese scheinen eher kosmetischer Natur bzw. die Übernahme vom master Branch. Im ebusd-esp sieht es ähnlich ruhig aus...
Gibt es irgendetwas, wie ich eventuell helfen könnte? Ich wäre sehr an einer Lösung interessiert, die von der Latenz dichter an die Ebus-Spezifikation herankommt!
mir fehlt es hier einfach an Zeit, um das weiter zu pushen.
Um die Latenzprobleme endgültig los zu werden gibt es eigentlich nur die Variante, das enhanced Protokoll noch weiter zu treiben und auf ganze Messages umzustellen, d.h. der wemos macht das ganze eBUS Protokoll Handling und tauscht nur noch ganze Nachrichten (bzw. ganze master/slave Teile) mit ebusd aus. Damit wären dann WIFI Latenzen auch mehrerer 100 ms völlig egal.
Aber das ist wieder ein enormer Umbau im ebusd und auch dafür fehlt die Zeit leider.
Ein anderer Ansatz wäre die jetzigen Latenzprobleme zu debuggen, was ebenfalls sehr zeitintensiv und zudem schwierig ist, da im Wemos debuggt werden muss. Ist also reichlich umständlich.
Wenn es hilft kann ich ohne großen Zeitaufwand noch den WIFI Status inkl. Signalstärke in die ebusd-esp Statusseite reinnehmen, vielleicht ist auch einfach die Strecke bei dir außergewöhnlich schlecht.
Ich habe bei meinen Tests aber auch schon mal gesehen, dass derleit Probleme bspw. auftreten wenn jemand anders im gleichen Netz ein Videostreaming am Laufen hat. Insofern ist mein Gefühl (ohne Beweis), dass das WIFI Handling im Wemos nicht besonders stabil ist. Hier könnte evtl. ein erneutes Update der Buildumgebung auf den aktuellen Stand Verbesserung bringen, mal schauen ob sich am WIFI Stack hier etwas getan hat.
Zitat von: Sven77 am 03 April 2019, 08:53:32
Im ebusd-esp sieht es ähnlich ruhig aus...
ich habe jetzt mal SDK und Arduino Core aktualisiert und RSSI eingebaut. Mit dabei ist auch ein lwIP Update, was auch helfen könnte.
Schau doch mal, ob es dadurch besser wird.
Parallel lasse ich auch mal einen Wemos permanent laufen, um disconnects zumindest mal mengenmäßig zu erfassen.
Hallo John,
ja - das mit der Zeit ist mir völlig klar, daher habe ich ja auch lange nicht mehr nachgefragt.
Das mit den Störungen im WLAN würde ich ja am liebsten komplett ausklammern, indem ich den Wemos seriell anbinde - nur das klappt ja bei mir im enhanced_mode irgendwie gar nicht!
Und selbst ohne enhanced_mode kann ich eine direkte serielle Verbindung mit dem Wemos überhaupt nicht nutzen (s. Post vom 07.11.2018).
Mir geht es also in erster Linie gar nicht um Weiterentwicklungen, sondern in der korrekten Nutzung des vorhandenen.
Ich probiere auf jeden Fall mal die neue Firmware aus - aber klappt denn bei dir eine serielle Verbindung zum Wemos??
UPDATE: Nur zur Info, die RSSI steht bei mir auf "100% (-40dBm)" - der Wemos liegt schließlich auch nur ca. 50cm vom AccessPoint entfernt.
Zitat von: Sven77 am 07 April 2019, 23:23:32
Ich probiere auf jeden Fall mal die neue Firmware aus - aber klappt denn bei dir eine serielle Verbindung zum Wemos??
das hatte ich jetzt nicht mehr auf dem Schirm und insofern auch überhaupt nicht mehr getestet.
Zitat von: Sven77 am 07 April 2019, 23:23:32
UPDATE: Nur zur Info, die RSSI steht bei mir auf "100% (-40dBm)" - der Wemos liegt schließlich auch nur ca. 50cm vom AccessPoint entfernt.
bei mir ist die Empfangsstärke auch recht gut und insofern keine Erklärung für die bisherigen Probleme.
Aber das core/sdk/SoftwareSerial Update hat bei mir im Dauertest zumindest deutliche Verbesserung gebracht.
Mein Update-Check meckert ständig, dass es schon eine Version 3.3 gibt...
Macht es Sinn, sich mit dem Thema "enhanced_mode" weiter zu beschäftigen, oder ist das erstmal ganz vom Tisch?
Mir würde schon daran liegen, eine latenzfreiere Lösung zu haben - gebe aber auch zu, dass ich bisher noch nie den modifizierten Raspi-Kerneltreiber probiert habe (weil ich schlichtweg aktuell keinen Raspi, sondern ein anderes embedded device im Einsatz habe).
In der aktuellen Implementierung hat jedenfalls meine Vaillant Steuerung immer mal wieder (ca. 2x pro Monat) Schwierigkeiten den Ölbrenner nach der Außentemperatur zu befragen und geht dann in einen Notfallmodus und nimmt -40°C an. Ist natürlich selten dämlich implementiert, aber Vaillant kann/will/darf daran offenbar nichts ändern.
Zitat von: Sven77 am 27 August 2019, 17:17:27
Mein Update-Check meckert ständig, dass es schon eine Version 3.3 gibt...
Macht es Sinn, sich mit dem Thema "enhanced_mode" weiter zu beschäftigen, oder ist das erstmal ganz vom Tisch?
auf welchem Stand bist du denn? ich nehme an, du hast selbst gecloned und compiliert?
enhanced ist für mich nicht vom Tisch, insbesondere da das in Verbindung mit dem ebusd-esp nur eine erste quasi beispielhafte Implementierung war. Da soll es künftig noch eine weitere Hardware Variante geben, die direkt das enhanced Protokoll spricht. Aber da ale extrem beschäftigt sind, geht hier nicht viel vorwärts. Vielleicht wieder eher was für den Winter :)
Zitat von: john30 am 05 September 2019, 08:21:37
auf welchem Stand bist du denn? ich nehme an, du hast selbst gecloned und compiliert?
Ja, nach meinem Kenntnisstand war/ist das nötig, um überhaupt den enhanced_mode zu bekommen.
Und auch Github (https://github.com/john30/ebusd/tree/enhanced_device) sagt "This branch is 20 commits ahead, 51 commits behind master."
Okay - das es eine Hardwarevariante geben soll, die dann das Protkoll spricht, war mir neu - naja, ich hatte mir gerade 2 Stück von der aktuellen zugelegt, aber warten wir ab, was sich da noch tut. Es wäre jedenfalls sicher auch für alle anderen sinnvoll, eine halbwegs spezifikationstreue Lösung zu bekommen. :D
Zitat von: Sven77 am 05 September 2019, 08:38:43
Und auch Github (https://github.com/john30/ebusd/tree/enhanced_device) sagt "This branch is 20 commits ahead, 51 commits behind master."
ah stimmt, im ebusd-esp ist es im Hauptbranch und im ebusd noch nicht. Die muss ich mal wieder zusammenführen.
Zitat von: Sven77 am 05 September 2019, 08:38:43
Okay - das es eine Hardwarevariante geben soll, die dann das Protkoll spricht, war mir neu - naja, ich hatte mir gerade 2 Stück von der aktuellen zugelegt, aber warten wir ab, was sich da noch tut.
bis dahin wird es sicher noch eine gute Weile dauern, weil alle sehr beschäftigt sind.
Zitat von: Sven77 am 05 September 2019, 08:38:43
Es wäre jedenfalls sicher auch für alle anderen sinnvoll, eine halbwegs spezifikationstreue Lösung zu bekommen. :D
wir jammern ja alle auf hohem Niveau (im Vergleich zu vor ein paar Jahren) ;)