ebusd enhanced mit ebusd-esp auf Wemos

Begonnen von john30, 19 Oktober 2018, 09:30:15

Vorheriges Thema - Nächstes Thema

john30

Hallo zusammen,
in diesem Thread sammle ich Themen/Diskussionen rund um das Thema ebusd-enhanced in Kombination mit ebusd-esp auf Wemos D1 mini.
VG John
author of ebusd

Sven77

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.
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?
VG, Sven

Sven77

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?
VG, Sven

sua

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...  :)

Sven77

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.
VG, Sven

sua

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...

Sven77

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?
VG, Sven

john30

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.
author of ebusd

Sven77

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"
VG, Sven

john30

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.
author of ebusd

Sven77

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.
VG, Sven

Sven77

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...
VG, Sven

john30

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 :-)
author of ebusd

Sven77

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?
VG, Sven

Prof. Dr. Peter Henning

Warum alle 30 Sekunden abfragen? Mein erster Ansatz wäre, das nur 1x pro Minute zu tun.

LG

pah