deepflyer911

@mattsches das geht ja wie das Brezel backen. Neuste Version ist installiert. Berichte bei Problemen.

Grüße zusammen,

@mattsches hatte deinen letzten build die Woche endlich instaliert, führte dazu, dass die Box alle 23sec, mit absoluter Regelmäßigkeit, neu gestartet hat. Ging soweit, bis sie sich ins Nirvana geschossen hatte.

Habe jetzt mqtt deaktiviert und schon läuft sie geschmeidig durch. Hoffe das meine Überschusssteuerung mit @ThomKa Unterstützung per http läuft.

Schönes Wochenende noch.

@mattsches die Box hatte ich aus der Ferne neu gestartet, um einenen neuen Ladeversuch zu initiieren. War zu der Zeit nicht zuhause. Deswegen alles remote.

Das Verhalten welches @ThomKa beschreibt, Schütze zihen für 30-180sec an, würde zu meinen Beobachtungen passen. Nur dass es bei mir halt eine PV Ladung war. Blöd, dass sich dazu nichts im Log findet.

Lade die neue Version hoch und schaue wie es sich verhält. Wird aber dauern, da ich derzeit auch fernab der Heimat bin.

@mattsches die anderen sichtbaren Ladungen sind jeweils durch Schnelladungen, also manueller Start erfolgt. Da gab es einen unmittelbaren zeitlichen Zusammenhang vom Einstecken zum Ladestart.

Das du aus dem Log liest, dass überhaupt keine Ladung zustande kam erstaunt mich. Hatte es in der Weboberfläche beobachtet, und da konnte man erkennen, dass für kurze Zeit eine Ladungen erfolgte, bevor es wieder abbrach. Hatte gehofft, dass man das im Log auch erkennen kann.

Grüße zusammen,

@mattsches gibt es eine Vermutung, was die Ursache für mein Problem sein könnte?

Grüße Zusammen,

nach dem letzten Update war heute erstmalig wieder saolarer Überschuss vorhanden und das Auto an der Wallbox. Leider klappte das Laden nicht. Nach wenigen Minuten brach die Wallbox den Ladevorgang ab. Im Webinterface stand nur EVSE hat den Ladevorgang abgebrochen. Log in der Anlage

debug-report-warp-SMq-2023-12-18T14-56-52-099.txt

Hab die neuste Variante insatlliert. Zunächst mal ohne Probleme. Im Debug ist zu erkennen, dass sich die freien Bytes stabil über 50k bewegen. Der größte Block ist wieder bei 38-43k.

Werde es weiter beobachten und berichten.

Am 8.11.2023 um 11:34 schrieb MatzeTF:

@deepflyer911 Ich habe mir gerade dein Log von Sonntag angesehen und es sieht so aus, als wäre deine Box im SoC-Modul wegen zu wenig freiem Speicher abgestürzt. MQTT verbraucht recht viel Speicher, von daher wundert mich das nicht.

Die gute Nachricht ist: Für neue Features für WARP2 und den WEM reduzieren wir gerade den Speicherverbrauch verschiedener Module. Davon wird auch die WARP1 profitieren und Abstürze wegen zu wenig freiem Speicher sollten dann seltener auftreten.

Dann ist die Variante von @mattsches ohne SOC Modul ja genau die richtige Option 😁

Am 6.11.2023 um 22:14 schrieb mattsches:

Und kommt es mit der Version ohne SOC-Modul auch zu den Abbrüchen?

Bislang ohne Probleme.

@mattsches mit der originalen Version zeigt es mir rund 42k bis 44k freie Heap-Byte an. Größter Block 38-44k

mit der Version ohne SOC rund 50 bis 52 freie Byte und 47-51 größter Block

danke dir @ThomKa jetzt habe ich Lesestoff :D

@ThomKa sehr gerne schaue ich mit das mit http an. Wollte mich ohnehin damit beschäftigen, da ich deine Lösung für EPEX LAden nutzen möchte

Am 5.11.2023 um 20:55 schrieb mattsches:

Hast du dir dein Log mal angeschaut? Darin  wimmelt es nur so vor Fehlern zu Wifi und MQTT. Und um 12:35:03,500 haut es die Kiste zusammen mit einer Exception. Einen Zusammenhang zum ad hoc-Laden kann ich da spontan nicht erkennen. Zumal ich daran nichts geändert habe. Ich tippe eher auf einen Speicherengpass. Ich habe dir mal eine Variante ohne das SOC-Modul gebaut. Schau mal, ob es damit besser geht. Wenn nein, dann habe ich auch keine Idee. Mit Meldungen wie

MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE?

und

2023-11-05 12:34:00,581  JSON doc overflow while converting to string! Doc capacity is zero but needed 6784.

kann ich auch nichts anfangen, die kommen nicht von meinem Code. Und die Codebasis ist das offizielle 2.1.5er Release von TF.

@ThomKa, du nutzt doch auch MQTT. Kommen da auch solche Meldungen im Log vor?

 

warp_firmware_2_1_5_6547f1b1_323bedfa4d03273_merged.bin 2.09 MB · 0 downloads

Die Probleme mit mqtt bestehen seit anbeginn der Zeit. Immerwieder Abbrüche. Keine Ahnung was das soll. Habe nur einen Broker, keine doppelte Belastung oder dergleichen...

Grüße zusammen,

@mattsches

die neue Version macht Probleme beim ad hoc laden. Bricht die Ladung eigenständig nach kurzer Zeit ab.

Log ist angehängt.

debug-report-warp-SMq-2023-11-05T12-38-37-553.txt

@ThomKa im Grunde passt deine Beschreibung ganz gut. Fahrzeug angestöpselt aber keine Ladung unmittelbar gestartet. Wenn man zu einem späteren Zeitpunkt laden will, startet die Wallbox nicht. Im Status steht dann "warte auf Freigabe". Dabei ist es egal ob der Überschuss genutzt werden soll oder ich eine ad hoc Ladung starten möchte. Nur das Abziehen und neue anstecken des Autos hilft. Beim Ad hoc kommt noch hinzu, dass ich sowohl mit dem Taster als auch in der Software die Ladung starten muss. Da hoffe ich, das der neue  Button zum Sofortladen Abhilfe schafft.

@mattsches Aktualisierung erfolgreich. Mal schauen, wenn die SOnne irgendwann scheint und ausreichend Überschuss vorhanden ist, wie es läuft.

Hinsichtlich des "Aufweckens" des Autos, damit nach längerer inaktiver Phase eine Ladung starten kann, @ThomKa konntest du meine Problemstellung nadchvollziehen? @mattsches was wäre nötig, um diese Option zu integrieren?

Hey @mattsches,

die Einstellungen sind analog jener bei mir.

Vermute das Problem auch beim Enyaq. Dieser zeigt mir in der Situation in der App, dass der Status unbekannt ist.

Denke der hat einen Zeitablauf.

Da es früher nciht der Fall war, hatte ich zunächst vermutet, dass die Software der Wallbox asich geändert hat. Tatsächlich hat aber auch der Enyaq ein größeres Update erhalten. Ggf ist die Urwsache darin zu finden.

Grüße zusammen,

was mir aufgefallen ist, aber glaube auch schon bei den vorherigen Version der Fall war, wenn ich das Auto anstecke, bevor ein Überschuß vorhanden ist, startet die Ladung zu einem späteren Zeitpunkt nicht automatisch, wenn ausreichend Überschuß vorhanden ist. Das Auto neu anstecken hilft dann.

Gibt es da eine Einstellung die dieses Problem behebt?

Grüße,

neuste Version läuft ohne Probleme. Die erste Ladung heute bei feiner Sonne ohne Einschränkungen.

@mattsches auch mit dem soc modul funktioniert die Version 2.1.5 ohne Probleme. Läuft mit 31%cpu Last sauber vor sich hin.

@mattsches herzlichen Dank für deine schnellen Mühen. Habe die Version ohne SOC installiert und läuft bislang ohne Aussetzter.

@MatzeTF richtig, nutze iobroker. Allerdings war das "status senden bei Verbindung" in meiner mqtt Instanz bereits deaktiviert.  Dennoch scheint ja der mqtt browser probleme verursacht zu haben, wenn das die einzige substantielle Änderung von 2.1.4 auf 2.1.5 ist?!

@mattsches nach dem Neustart geht es mit rund 65k bytes los. Diese sinken innerhalb kurzer Zeit ab. Wenn der Wert unter 51k bytes fällt kommt der Neustart. Größter freier Block ist dann um die 45k.

@MatzeTF angefügt der aktuelle Report. Habe seit 16:59 keinerlei änderungen vorgenommen.

wo hat die Box denn eine USB Schnittstelle?

debug-report-warp-SMq-2023-09-26T18-15-43-290.txt

Ergänzung Bug Report

debug-report-warp-SMq-2023-09-26T16-59-24-748.txt

@MatzeTF anbei der Debug Report während des typischen Verhaltens. Die IP der Wallbox und des MQTT Servers sind statisch im Netzwerk festgelegt.

debug-report-warp-SMq-2023-09-26T16-56-50-876.txt