pvtom / rscp2mqtt

Bridge between an E3/DC home power station and an MQTT broker based on the RSCP protocol
MIT License
29 stars 7 forks source link

RscpMqttMain.cpp(1930) Error: Maximum buffer size exceeded 69632 #55

Closed timmost closed 3 months ago

timmost commented 4 months ago

Hi Thomas

ich habe seit einiger Zeit diese Meldungen im Log, und das Schreiben auf die influx DB klappt nicht. Scheint, dass die Verbindung zum e3DC nicht klappt. Nach einem Neustart des Docker Containers geht's wieder einige Zeit.

Any hints? VG timmo

Version: org.opencontainers.image.version | v3.17-with-influxdb

[2024-03-23 13:57:08] pid=1 ppid=0 RscpMqttMain.cpp(2515) Connecting to server 192.168.178.58:5033 [2024-03-23 13:57:08] pid=1 ppid=0 RscpMqttMain.cpp(2522) Success: E3DC connected. [2024-03-23 13:57:08] pid=1 ppid=0 RscpMqttMain.cpp(1930) Error: Maximum buffer size exceeded 69632

Nach dem Restart des Docker Containers kommen folgende Logs, In influx kommen wieder Daten an:

rscp2mqtt [v3.17.influxdb] E3DC system >192.168.178.58:5033< user: >(private)< MQTT broker >localhost:1883< qos = >0< retain = >false< client id >✗< prefix >e3dc< INFLUXDB v2 >localhost:8086< orga = >home< bucket = >e3dc_new< measurement = >e3dc< Fetching data every 15 seconds. Requesting PVI ✓ | PM (0) | DCB ✓ (1 battery string) | Wallbox (0) ✓ | Autorefresh ✗ Log level = 0 Stdout to pipe/file [2024-03-23 14:00:39] pid=1 ppid=0 RscpMqttMain.cpp(2515) Connecting to server 192.168.178.58:5033 [2024-03-23 14:00:39] pid=1 ppid=0 RscpMqttMain.cpp(2522) Success: E3DC connected. [2024-03-23 14:00:39] pid=1 ppid=0 RscpMqttMain.cpp(1533) RSCP authentication level 10 [2024-03-23 14:00:39] pid=1 ppid=0 RscpMqttMain.cpp(2063) Connecting to broker localhost:1883 [2024-03-23 14:00:39] pid=1 ppid=0 RscpMqttMain.cpp(313) MQTT: starting listener loop [2024-03-23 14:00:39] pid=1 ppid=0 RscpMqttMain.cpp(2075) Success: MQTT broker connected. [2024-03-23 14:00:44] pid=1 ppid=0 RscpMqttMain.cpp(1943) Error: Response receive timeout (retry) [2024-03-23 14:00:48] pid=1 ppid=0 RscpMqttMain.cpp(1943) Error: Response receive timeout (retry)

pvtom commented 4 months ago

Hallo Timmo, der Timeout und der "Max. buffer size exceeded"-Fehler treten bei Code-Stellen, an denen auf das Hauskraftwerk zugegriffen wird, auf. Eine Erklärung habe ich nicht. Im Netz findet man einige Anwender, die über ähnliche Probleme mit Docker Containern, die Netzwerkzugriffe machen, berichten. Teilweise reichte ein Restart der Docker-Umgebung oder des Rechners, auf dem Docker läuft, aus... Ich habe da keine Erfahrung, betreibe rscp2mqtt lokal. Tritt das Problem auch auf, wenn Du rscp2mqtt lokal (nicht als Docker Container) laufen lässt? Gruß Thomas

timmost commented 4 months ago

Hi Thomas, Ich schaue nochmals nach den Netzwerkparametern. Mache das über Network Mode = Host, da das Docker eigene Netz relativ langsam ist und ich den Abstraction layer nicht wirklich brauche. Der Restart hat immer geholfen, aber der Overrun kam so nach einem halben Tag wieder... also kein dauerhafter Fix. Habe jetzt mal zum Testen das direkte Schreiben nach influx disabeled (einfachster Test). Bis jetzt (24 std) scheint es keinen Buffer Overrun mehr zu geben. Ohne Docker habe ich es noch nicht versucht... mal schauen (Docker ist auf der einen Seite etwas intransparent und komplexer, aber Neueinrichten des Raspies ist soooo viel einfacher....)

Mal schauen, was passiert.

vG Timmo

timmost commented 4 months ago

Hi Thomas, Hat nichts geholfen, habe wieder den Fehler...

[2024-03-26 20:35:45] pid=1 ppid=0 RscpMqttMain.cpp(2628) Success: E3DC connected. [2024-03-26 20:35:45] pid=1 ppid=0 RscpMqttMain.cpp(2015) Error: Maximum buffer size exceeded 69632

Ich fange mal an zu recherchieren..

VG timmo

pvtom commented 4 months ago

Hi Timmo, ich stochere auch ein bisschen rum.

Vielleicht kannst folgende Änderungen in der Datei RscpMqttMain.cpp vornehmen und testen?

Die Zeile if (bStopExecution) sleep(RETRY_AFTER_DELAY); entfernen. Die habe ich, warum auch immer, mit v3.14 eingeführt.

Außerdem diesen Block übernehmen (nach: "while (!bStopExecution && ((iReceivedBytes > 0) || iReceivedRscpFrames == 0))" suchen) bzw. die drei Zeilen mit "beobachten" und 2 x "zuruecksetzen" einbauen:

while (!bStopExecution && ((iReceivedBytes > 0) || iReceivedRscpFrames == 0)) {

printf("receiveLoop %zu(%zu)\n", vecDynamicBuffer.size(), RSCP_MAX_FRAME_LENGTH); // beobachten // check and expand buffer if ((vecDynamicBuffer.size() - iReceivedBytes) < 4096) { // check maximum size if (vecDynamicBuffer.size() > RSCP_MAX_FRAME_LENGTH) { // something went wrong and the size is more than possible by the RSCP protocol logMessage(cfg.logfile, (char )FILE, LINE, (char )"Error: Maximum buffer size exceeded %zu\n", vecDynamicBuffer.size()); vecDynamicBuffer.resize(0); // bei max buffer, zuruecksetzen iReceivedBytes = 0; // bei max buffer, zuruecksetzen bStopExecution = true; break; } // increase buffer size by 4096 bytes each time the remaining size is smaller than 4096 vecDynamicBuffer.resize(vecDynamicBuffer.size() + 4096); }

Erstens wird damit dann die "Entwicklung" der Buffergröße ausgegeben und außerdem im Falle des "buffer size exceeded" die beiden statischen Variablen zurückgesetzt, was evtl. für Folgeanfragen an das Hauskraftwerk helfen kann.

Gruß Thomas

timmost commented 3 months ago

Hi Thomas, danke Dir - ich komme über Ostern nicht zum Probieren, wir sind unterwegs, melde mich! VG timmo

timmost commented 3 months ago

Hi Thomas Kleines Update - ich habe mittlerweile meinen USB Stick im Verdacht... der hat haufenweise Lesefehler am Raspi 4 erzeugt, die auch andere Docker container aus der Bahn geworfen haben. Mittlerweile alles neu aufgesetzt, SSD USB Platte dran (vieeeel schneller), mal schauen. Melde mich, wenn der Fehler wieder auftaucht. VG Timmo

pvtom commented 3 months ago

Die Lösung steht jetzt mit v3.20 zur Verfügung.

timmost commented 2 months ago

Läuft auch mit Docker stabil, vielen Dank! PS - war einige Zeit offline, da es meinen Wechselrichter gerichtet hat - ist aber wieder ok VG timmo

pvtom commented 2 months ago

Hallo Timmo, prima, dass das jetzt läuft. Wie alt ist denn Dein Hauskraftwerk, dass da der Wechselrichter schon ausgestiegen ist? Musstest Du lange auf das Ersatzteil und die Montage warten? Gruß Thomas

timmost commented 2 months ago

Hi Tom,

Anlage läuft seit 2017- also 7 Jahre.

E3DC hat in 12 std Remote Diagnose gemacht, und nach 3 Tagen war der Techie da und hat das gefixt.

Insofern nicht schön dass der Wechselrichter so schnell aufgibt - aber guter Service in der Garantie.

Viele Grüße - Timmo

Timmo Sturm Wittelsbacherstr. 8 85622 Feldkirchen +49 151 402 71 711

Thomas Heiny @.***> schrieb am Mi. 1. Mai 2024 um 10:14:

Hallo Timmo, prima, dass das jetzt läuft. Wie alt ist denn Dein Hauskraftwerk, dass da der Wechselrichter schon ausgestiegen ist? Musstest Du lange auf das Ersatzteil und die Montage warten? Gruß Thomas

— Reply to this email directly, view it on GitHub https://github.com/pvtom/rscp2mqtt/issues/55#issuecomment-2088135539, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4FS6YKSRRJDG7H5LZHV6DZACP7FAVCNFSM6AAAAABFEUQH3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGEZTKNJTHE . You are receiving this because you authored the thread.Message ID: @.***>