Umbau Phasenumschaltung für WARP 1

[deepflyer911]

@mattsches hab die neuste Version aufgespielt. Was unmittelbar auffällt, dass er nur schwierig eine Zeitsynchronisation hin bekommt. Zudem verliert er alle paar Sekunden den Kontakt zum mqtt server. Zeitgleich wird mir im Browser kurz angezeigt, dass die Verbindung zur Wallbox verloren ist. So als ob das WLAN kurz unterbrochen wäre. ENtsprechendes zeigt er auf der Oberfläche der Wallbox aber nicht an.

Wenn er die Zeit synchronisiert hat, bricht gleichzeitig die Verbindung zu mqtt ab und die Synchronisation geht verloren. Mit jedem Abbruch wird die verfügbare Ladeleistung genullt. Habe aktuell kein Auto zum Laden da, fürchte aber, dass da keine Ladung zustande kommt.

[mattsches]

@deepflyer911, welche Version hattest du denn vorher im Einsatz? Das klingt so, als sei das System ziemlich am Anschlag. Habe gerade mal zuhause reingeschaut, da sieht alles gut aus. Uhrzeit ist da, Leistungsvorgabe wird korrekt angezeigt, nichts Auffälliges. Ich nutze allerdings nicht MQTT, sondern die REST API. Sollte aber keinen Unterschied machen.

[deepflyer911]

@mattsches hatte zuvor die letzte Version der 2.0 von dir im Einsatz. War es 2.0.8? Hattest du etwa im April gedroppt. Den Zwischenschritt auf die 2.1 hatte ich nicht installiert.

[deepflyer911]

Habe gerade nochmal reingeschaut, im Reiter debug wird der counter "Zeit seit Neustart" bei jedem Verlust des mqtt bzw der Synchronisation zurück gesetzt.

Damit erscheint es mir so, als ob die Wallbox neustarten würde. Passt aber irgendwie nicht, da es innerhalb einer halben sekunde passiert. So fix startet die Box nicht...

[MatzeTF]

@deepflyer911 Kannst du mal versuchen, ein Debug-Log runterzuladen und hier anzuhängen?

Außerdem könntest du versuchen, MQTT-Server und was du sonst noch an Hostnamen irgendwo eingetragen hast, durch statische IPs zu ersetzen. Möglicherweise gibt es ein Problem beim Auflösen von Hostnamen, wenn der ESP gerade am Limit läuft.

bearbeitet September 26, 2023 at 11:13 von MatzeTF

[ThomKa]

@mattsches Erst mal wieder vielen Dank für Deinen Pflegeaufwand 🫡.
Version ist aufgespielt und läuft.

Die Beschreibung von deeplyer911 passt zu meinen Beobachtungen der Vergangenheit. Erst kamen die mqtt-Abbrüche, dann war der WARP überhaupt nicht mehrerreichbar. Die PING-Zeiten liefen dabei ins astronomische und brachen dann komplett ab.
Was half war der Werks-Reset und Neukonfiguration.
!! Allerdings war das Vergangenheit !! Seit dem mqtt abgeschaltet ist und die Kommunikation direkt per http erfolgt, ist das komplett entfallen.

@mattsches schreibst Du jetzt unter anderem Synonym oder haben wir jetzt 2 Matthias'e im Chat?

bearbeitet September 26, 2023 at 11:51 von ThomKa

[mattsches]

@ThomKa : Nö, aber falls du @MatzeTF meinst, der ist von Tinkerforge und wird vermutlich auch Matthias heißen (in welcher Buchstabenausstattung auch immer).

Für mich hört sich das nach Abstürzen aufgrund von Ressourcenmangel an (Speicher voll). Ich hatte das Problem zeitweise mit meinem Ladestandsmodul. Die Phasenumschaltung belegt Speicher für die Charts. Wenn MQTT auch Platz braucht, wenn aktiv, ist das vielleicht zu viel des Guten. Ich könnte testweise eine Variante ohne Charts bauen, um es einzugrenzen. Und vielleicht hat Matze ja noch einen Tipp, wenn er Debug Logs bekommt.

[MatzeTF]

On 9/26/2023 at 4:03 PM, mattsches said:

Für mich hört sich das nach Abstürzen aufgrund von Ressourcenmangel an (Speicher voll). Ich hatte das Problem zeitweise mit meinem Ladestandsmodul.

Wie aktuell ist deine Codebasis? Wir haben am 14.9. etwas Speicher freigeschaulfelt. Wenn du glaubst, nah am Speicherlimit zu sein, nimm mal das „Debug“ Front- und Backendmodul mit rein. Das liefert dir jetzt mehr Informationen zum Speicherverbrauch.

[deepflyer911]

@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

[deepflyer911]

Ergänzung Bug Report

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

[MatzeTF]

Daran kann man leider nichts Hilfreiches erkennen. Als du das zweite Debug Log runtergeladen hast, lief die Box seit mehr als 2 Minuten. Hattest du sie vorher selbst neugestartet? Angeblich wurde sie die letzten Male immer per Software neugestartet. Falls du keine Neustarts manuell ausführst, fürchte ich, dass man nur über den USB-Port in der Wallbox an irgendwelche hilfreichen Informationen zu den Neustarts kommt.

Speicher sieht okay aus. 47 KiB frei ist für eine WARP1 nicht ungewöhnlich. Das Log davor mit weniger Uptime sagt allerdings was von 62 KiB frei. Könnte also auch ein Speicherleck sein. In dem Fall gibt es auch nur über USB irgendwas Hilfreiches.

[deepflyer911]

@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

[MatzeTF]

On 9/26/2023 at 6:16 PM, deepflyer911 said:

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

Dann passt da wirklich etwas nicht, was du nur per USB rausfindest.

Die USB-Schnittstelle habe ich dir unten im Bild markiert. Unter Linux kannst du ein Terminalprogramm deiner Wahl benutzen oder einfach unser „ff“-Script aus dem esp32-firmware git. Was man heutzutage unter Windows empfehlen kann, weiß ich nicht. Putty sollte auch serielle Schnittstellen können. Bitrate ist 115200, alles andere auf Default (8bit, ein Stopbit, keine Parität).

[mattsches]

Das Debug-Modul ist im letzten hier geposteten Stand aktiv. @deepflyer911, du hattest die Seite ja schon offen. Wie verhält sich der Speicher denn über die Zeit? Bei mir (MQTT aus) läuft die Kiste seit gut 23 Stunden, ca 75 kB Heap Bytes frei, größter freier Block 30 kB.

Ich habe keinen MQTT Broker am Start, sonst würde ich testweise mal einschalten. Aber ich fürchte, ohne Gegenstelle wird das nicht viel bringen.

bearbeitet September 26, 2023 at 19:41 von mattsches

[deepflyer911]

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

 

[mattsches]

Codestand war das 2.1.4er Release, also vom 23.08. Anbei mal ein Stand auf dem aktuellen 2.1.5 Entwicklungsstand (387bd3e318889d16ce866273f92c9f783b91faff). @MatzeTF, die Debug-Seite habt ihr ja kräftig ausgebaut, cool! Bei mir werden jetzt 78 kB freier Heap und 73 kB als größter Block angezeigt. Die Kiste läuft allewarp_firmware_2_1_5_651335e2_7f4039330db99e6_merged.binrdings erst auch seit ein paar Minuten.

[mattsches]

Dann hier noch eine Variante ohne das SOC-Modul. Das hat zur Zeit noch kein Frontend (Refactoring noch offen), und du brauchst es ja eh nicht.warp_firmware_2_1_5_6513378a_7f4039330db99e6_merged.bin

[MatzeTF]

@deepflyer911 Nur zur Sicherheit: Der MQTT-Server, zu dem sich deine Wallbox verbindet, ist nicht zufällig ioBroker?

Edit: Ich habe gerade in einem deiner alten Posts gefunden, dass du ioBroker benutzt.

Edit 2: Das Problem ist, dass sich ioBroker nicht standardkonform verhält und in der Default-Konfiguration Nachrichten per MQTT sendet, die bei der Wallbox verschiedene Probleme verursachen. Mit 2.1.4 ist es prinzipiell möglich, dass die Wallbox endlos von ioBroker neugestartet wird. Ich vermute stark, dass du genau auf dieses Problem gestoßen bist. Mit der noch nicht veröffentlichten Version 2.1.5, die mattsches netterweise bereits für dich gebaut hat, haben wir die häufigste unsinnige Nachricht von ioBroker rausgefiltert und das Problem sollte nicht mehr so leicht auftreten. Unabhängig davon empfehlen wir, ioBrokers MQTT-Option „Publish own states on connect“ immer zu deaktivieren.

bearbeitet September 27, 2023 at 15:35 von MatzeTF

[deepflyer911]

@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?!

[ThomKa]

Hi Zusammen. Habe mal mitgelesen und mich mal bedeckt gehalten😉. Was ist denn nun für Dich @mattsches einfacher, damit Du nur 1ne Version zu pflegen hast? Soll ich auf der "2.1.4-6511ec66" bleiben oder auch auf die "2.1.5-6513378a" wechseln? Wenn Euch Speicherinformationen von meiner WARP nützlich sein sollten, lasst es mich gerne wissen.

[mattsches]

@ThomKa, du kannst ruhig auf die 2.1.5 gehen. Das war nur ein Merge des aktuellen Standes von TF, der ohnehin irgendwann fällig gewesen wäre. Ist halt nicht das letzte Release, sondern ein Daily Build/Bleeding Edge von deren Seite. Mein Repo lasse ich darauf und mache mit dem Stand weiter. Wenn du updatest, gewinnst du die Statusanzeigen der Phasenumschaltung zurück, die in der 2.1.4 noch gefehlt haben.

Hilfreich wäre es für mich, wenn @deepflyer911 noch den 2.1.5er Stand mit SOC-Modul testen könnte. Das bringt euch nichts (habt ja nicht das passende Auto, außerdem fehlt hier die neue GUI noch komplett). Aber für mich wäre es gut zu wissen, ob das SOC-Modul in die Suppe gespuckt hat oder wie von Matze vermutet ioBroker.

Am 26.9.2023 um 21:56 schrieb mattsches:

warp_firmware_2_1_5_651335e2_7f4039330db99e6_merged.bin

 

[deepflyer911]

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

[ThomKa]

Am 27.9.2023 um 20:30 schrieb mattsches:

@ThomKa, du kannst ruhig auf die 2.1.5 gehen. Das war nur ein Merge des aktuellen Standes von TF, der ohnehin irgendwann fällig gewesen wäre. Ist halt nicht das letzte Release, sondern ein Daily Build/Bleeding Edge von deren Seite. Mein Repo lasse ich darauf und mache mit dem Stand weiter. Wenn du updatest, gewinnst du die Statusanzeigen der Phasenumschaltung zurück, die in der 2.1.4 noch gefehlt haben....

 

Update ist erfolgt. Der DebugReport sagt:

• cpu_usage:0.309521675
• free_heap_bytes:78100
• largest_free_heap_block:65524

Soweit alles prima 👍

[ThomKa]

Am 18.7.2023 um 16:39 schrieb borg:

Probier mal die Kalibrierung im Anhang :)

calibration.json 202 B · 11 downloads

Guten Morgen @borg. Darf ich bitte nochmal kurz nachfragen? Ich bin mir einfach nicht sicher, wie groß die Abweichungen zwischen angeforderter und tatsächlicher Leistung sein dürfen und möchte eigentlich nur meine Erwartungshaltung gerade gerückt bekommen😁.
Bei einer angeforderten Ladeleistung von 2.000W werden z.B. 1.850W als tatsächliche Leistung angezeigt. Bei einer Ladung von 11kW fehlen dann rund 450W. Sind das Abweichungen die "im Rahmen sind" oder sollte da noch mal nachjustiert werden?
Vielen Dank für Deine Mühe und Gruß, Thomas

[borg]

Das ist normal, an der Stelle können wir auch nichts nachjustieren. Die Kalibrierung für WARP1 bezieht sich auf das erkennen des Widerstandes den das Auto anlegt, nicht auf die Pulsweite (welche den Strom vorgibt). Die Pulsweite ist immer genau, da gibt es nichts zu kalibrieren.

Da allerdings viele Autos gerne ein bisschen weniger ziehen als ihnen erlaubt wurde, kannst du unter Wallbox -> Lade­ein­stellungen den "Boost-Modus" aktivieren. Dann legen wir immer eine etwas höhere Pulsweite an als eigentlich eingestellt und es sollte bei dir näher an den eingestellten Wert kommen.