WARP1 steht nach einer gewissen Betriebszeit

[michaelst]

Wir haben vor ca. 1 Jahr eine der letzten WARP1 bei uns installiert.
Ein NFC-Bricklet habe ich irgendwann selbst nachgerüstet, funktioniert prinzipiell einwandfrei..

In dieser Zeit ist es, heute das zweite Mal, passiert, dass die Wallbox stehen bleibt. Vermutlich geht die Firmware in einen deadlock.
D.h. die Box ist komplett ohne Funktion. Es gibt keine Reaktion auf das Anschließen des Autos, keine Reaktion der Led.
Kein Interface ist erreichbar, weder HTTP, noch MQTT, usw. .

Ein kompletter Neustart, also einmal spannungslos schalten, hilft natürlich.
Den Debug-Log nach dem Neustart habe ich angehängt. Hilft auch nur bedingt, aber es gab keine Chance, an den letzten zu kommen.

Beim ersten Mal, Ende April (Firmware 2.0.1), da habe ich es ignoriert und gehofft,
dass eine der folgenden Firmwaren das Problem löst. Jetzt ist die 2.0.7 installiert.

Eine Vermutung, wie die Box in diesen Zustand kommt ist, dass es passiert, wenn die Wallbox eine längere Zeit nicht in Benutzung ist.
Durch private Umstände wurde die Box bei uns aktuell ca. 8 Tage nicht benutzt. Im April waren wir eine Woche im Urlaub.
Es ist natürlich schwer zu sagen, ob dies der Grund ist, aber zumindest ein Ansatz. Ansonsten ist an unserem System nichts geändert worden.

Da ich diverse Werte (Quelle ist MQTT) teils regelmäßig, teils eventgetriggert in einer Datenbank speichere,
kann ich sagen, dass vorher kein Fehler aufgetreten ist. Die Werte bleiben dann einfach auf Null, bedingt durch den Ausfall von MQTT.

Kann ich programmiertechnisch irgendetwas einbauen, um den Fehler ggf. zu erkennen?
 

Lieben Gruß, Michael

debug-report-warp-ULJ-2022-11-08T10-09-42-009.txt

[rtrbt]

55 minutes ago, michaelst said:

Es gibt keine Reaktion auf das Anschließen des Autos, keine Reaktion der Led.

Das ist wirklich interessant: Die LED wird vom Ladecontroller (dem EVSE Bricklet) gesteuert. Die Ladecontroller-Firmware ist so ausgelegt, das selbst wenn der ESP-Brick (über den läuft das Webinterface, MQTT, usw.) nicht funktioniert, das Laden (und die LED) weiterlaufen.

Wenn also nicht mal die LED angeht, wenn du ein Auto ansteckst, dann muss der Ladecontroller selbst hängen. Mir ist ehrlicherweise unklar, wie das passieren kann.

Ich habe gerade getestet, wie sich der ESP-Brick in dem Fall verhält, aber außer vielen Fehlermeldungen im Ereignis-Log der Form

2022-11-08 12:53:13,767  all_data_1 -1

funktioniert alles wie erwartet. Die APIs unter evse/ aktualisieren sich dann nicht mehr, aber prinzipiell bleiben Webinterface, MQTT usw. erreichbar. D.h. irgendwie müssen sowohl EVSE, als auch ESP bei dir (unabhängig voneinander?) in ein Problem laufen.

Wir bauen für die nächste Firmware mal ein, dass das EVSE-Bricklet und der ESP-Brick jeweils neustarten, falls die Kommunikation eine lange Zeit gestört ist (z.B. weil eben die andere Komponente hängt). Ob das bei deinem Problem hilft ist mir aber unklar.

 

1 hour ago, michaelst said:

Kann ich programmiertechnisch irgendetwas einbauen, um den Fehler ggf. zu erkennen?

Je nachdem welche Daten du in deine Datenbank geloggt hast könnten wir vielleicht erkennen, ob sich der Ladecontroller zuerst aufgehangen hat. Hast du einen der häufig wechselnden Werte in die Datenbank geschrieben? (z.B. irgendetwas aus evse/low_level_state).

[michaelst]

OK, verstehe. Da frage ich nochmal meine Frau, ob die Led wirklich aus war ;-)

Nehmen wir an, dass nur der ESP-Brick ausgefallen ist, dann könnte das nicht funktionierende Laden doch damit erklärt werden,
dass der NFC-Tag zum Starten benötigt wird und das NFC-Bricklet am "stehenden" ESP hängt und damit nicht erkannt wird.

Richtig?

Der DB-Server und MQTT-Server läuft über Nacht nicht.
Er fährt um 23:45 Uhr herunter und startet um 5:55 Uhr.

Die erste Tabelle ist eventgetriggert.
Der erste Datensatz des Tages (hier 1489) ist technisch bedingt immer Null.
Die letzte Änderung war am Tag vorher

1490 ist der erste DS nach dem Neustart

 

Der zweiten Tabelle wird jede Stunde ein DS hinzugefügt.
Abends vorher läuft noch alles, am nächsten Tag nicht mehr, erst nach dem Neustart.

[rtrbt]

On 11/8/2022 at 1:32 PM, michaelst said:

Nehmen wir an, dass nur der ESP-Brick ausgefallen ist, dann könnte das nicht funktionierende Laden doch damit erklärt werden,
dass der NFC-Tag zum Starten benötigt wird und das NFC-Bricklet am "stehenden" ESP hängt und damit nicht erkannt wird.

Richtig?

Korrekt. Der ESP schreibt dann nie einen Strom > 0 in die Benutzer-Ladestromgrenze (die auf dem EVSE liegt)

Laut der Daten hat sich also mindestens der ESP in der Nacht vom 7. auf den 8. aufgehangen. Falls du das nochmal erzeugt bekommst, versuche mal, ob du den ESP noch anpingen kannst und ob (notfalls über den Access-Point des ESPs) du auf http://10.0.0.1/recovery (bzw. eine andere IP wenn du nicht über den ESP-Access-Point gehst) kommst. Falls ja zieh da mal einen Debug-Report.

[cord]

Hallo,

ich denke ich habe das gleiche Problem bei meiner Warp2 (V2.0.7-62a1f99c). Sie ist in den letzten 6 Monaten 3x 'tot' gewesen, d.h. kein Laden, kein Verbindung über die Webseite. Nach Aus-/Anschalten ging's sofort. Leider habe ich keine weiteren Daten wie Michael und ich kann auch nicht sagen, ob es erst nach längerer Nicht-Benutzung auftritt. Ich versuche darauf zu achten.

VG, Cord

[floho]

Kann ich hier bestätigen. Meine Warp2 hing die Tage auch. Kein Tag wurde erkannt. 
aufgefallen ist es da sie die Ladefreigabe für die auch vorhandene Warp1 nicht genehmigt hat. Somit ging auch die nicht. 

[rtrbt]

Reagiert bei euch beiden die Wallbox-LED noch darauf, wenn ein Auto angeschlossen wird?

Wenn das der Fall ist, aktualisiert bitte auf 2.0.8 (bzw. WARP1 2.0.7). Wir hatten in den Firmwares davor Probleme mit der WebSocket-Implementierung, die zu genau dem Verhalten geführt haben. Meines Wissens (leider ist die einzige Möglichkeit das zu testen, eine Wallbox ein paar Wochen laufen zu lassen) sollte das aber mit der jeweils aktuellen Firmware nicht mehr auftreten. Falls doch, bitte nochmal Bescheid geben!

[michaelst]

vor 8 Stunden schrieb rtrbt:

.. aktualisiert bitte auf 2.0.8 (bzw. WARP1 2.0.7).

Ich habe die 2.0.7 ja schon vorher drauf gehabt.

[floho]

Same here. Habe die 2.0.7 auf der Warp1 und die 2.0.8 auf der Warp2.

Die LED ging an beim Anstecken des Autos. Der NFC Flicker kam aber nicht beim Hinhalten des Tags. 

bearbeitet November 15, 2022 at 18:34 von floho
Typos

[kaeferfreund]

Bei mir haben sich vor einigen Tagen tatsächlich alle WARP2 aufgehängt - zeitgleich -

Die Webgui wurde nicht mehr vollständig angezeigt und auch EVCC hat gemeldet, dass die WARP ihre Zustände nicht mehr aktualisieren würden.

Alle Boxen waren auf der 2.0.8 und hatten eine Uptime von ungefähr zwei Monaten

[rtrbt]

On 11/15/2022 at 7:33 PM, floho said:

Die LED ging an beim Anstecken des Autos. Der NFC Flicker kam aber nicht beim Hinhalten des Tags. 

D.h. der Ladecontroller lief zumindest noch. Das ist schonmal gut.

On 11/16/2022 at 11:15 AM, kaeferfreund said:

Alle Boxen waren auf der 2.0.8 und hatten eine Uptime von ungefähr zwei Monaten

Das ist sehr interessant. In letzter Zeit häufen sich die Meldungen über genau das Problem und die letzte Firmware ist zwei Monate alt. Wir haben hier zwei Wallboxen laufen, die in der Nacht zum Samstag die 50 Tage Uptime erreichen (=2^32 Millisekunden). Eventuell haben wir uns ein Timestamp-Überlauf-Problem eingetreten (auch wenn der Code das eigentlich korrekt behandelt).

Ich melde mich am Montag nochmal ;)

[michaelst]

vor 9 Minuten schrieb rtrbt:

D.h. der Ladecontroller lief zumindest noch. Das ist schonmal gut.

Das ist sehr interessant. In letzter Zeit häufen sich die Meldungen über genau das Problem und die letzte Firmware ist zwei Monate alt. ...

Wie gesagt, dass erste Mal trat es bei mir im April auf. Es wird also vermutlich nicht an einer der letzten Änderungen liegen.

[mrks]

Hallo zusammen,

ich reihe mich mal mit ein. Gestern Abend hing auch meine WARP1 mit NFC Bricklet (war nicht das erste Mal, habe mir jedoch leider bisher nicht notiert wie das Fehlerbild war und wann es das letzte Mal auftrat. Dürfte das zweite oder dritte Mal gewesen sein). Firmware ist die aktuelle 2.0.7. Fehlerbild wie folgt:

- Beim Anstecken des Autos ging der LED Ring an, leuchtete jedoch dauerhaft

- NFC Chip wurde nicht erkannt bzw. Box reagiert nicht darauf

- Ladevorgang konnte folglich auch nicht gestartet werden

- Webinterface war über den integrierten AP erreichbar, zeigte jedoch keinerlei Daten an (Das Burger Menü war leer, auf der Statusseite waren keine Daten eingetragen, sah aus als würde die API hängen)

Nach dem Trennen vom Netz funktioniert die Box wieder ohne Probleme.

[rtrbt]

Aktualisiert bitte alle mal auf WARP 2.0.8 bzw. WARP2 2.0.9. Das Problem sollte damit weg sein. (FYI hier der Commit, der den Bug behebt: https://github.com/Tinkerforge/esp32-firmware/commit/675387f331678918176ece325fdbf83416a33ae9)

[kaeferfreund]

Ich muss echt sagen

Ihr seid klasse!

Ich hatte vorher mehrere Boxen den Fa. go-e und die sind alle über Monate immer wieder abgestürzt, hat go-e 0,0 interessiert, keine Nachbesserung, kein Bock, einfach auf tot gestellt.

Jetzt stürzt die WARP ein einziges mal seit 10/2021 ab und hier wird der Fehler sofort lokalisiert und behoben. Wo bekommt man heute noch so ein Produkt und solchen Support?

 

Ein großes DANKESCHÖN für ein großartiges Produkt!

bearbeitet December 10, 2022 at 12:24 von kaeferfreund

[thkrmr]

Bei mir hängt die WARP2 gerade, LED reagiert nicht aufs Auto anstecken, NFC Karte dranhalten bringt nix. Das Web Interface lädt zwar kriegt aber keinen Status.

Ich kann die Wallbox nicht ohne Weiteres stromlos machen, da wir keinen Zugang zum Elektroraum haben. Ich könnte lediglich die Abdeckung meiner Wallbox abschrauben.  

Wie krieg ich die WARP2 in dem Fall am besten neugestartet? @rtrbt

 

Danke!

[rtrbt]

Wenn du prinzipiell das Web Interface noch erreichst, kannst du http://10.0.0.1/recovery (10.0.0.1 ersetzen durch IP oder Hostname der Wallbox) versuchen. Da gibt es einen "Force Reboot"-Button.