UI dauerhaft nicht mehr erreichbar und Ladesteuerung hängt nach kurzzeitigem Ausfall von Tibber #17925
Closed
1 task done
Labels
question
Rather clarification than issue
Comments
|
evcc läuft nicht ohne funktionierenden Netzzähler. Wenn Tibber zu unzuverlässig ist muss es aus der Position raus :( |
Bitte evcc mit |
|
"--profile" ist eingebaut. |
|
Hm, evcc läuft mit --profile. UI ist nicht erreichbar wie oben aber es gibt kein Profile. Die Situation kann ich vorübergehend einfach mal bestehen lassen bis heute Nacht, einen der beiden Container auch länger. Wenn du Anweisungen erteilen kannst, was ich tun / probieren könnte, her damit. Bin heute in Kundenterminen, ab etwa 18 Uhr kann ich was dran probieren. |
Wirklich? Das wäre das erste mal. |
|
Wird das nur beim Crash geschrieben oder auch, wenn evcc weiterläuft? Ich hab den gesamten Container abgesucht nach profile und debug aber nix passendes gefunden. --profile bekommt keinen zusätzlichen Parameter, oder? |
|
|
... oder muss das Profile-Verzeichnis vorher angelegt werden? |
|
Muss jetzt leider erstmal los. Passiert das bei keinem anderen der Tibber-Evcc-Leute? Hätte da jetzt eigentlich ein globaleres Problem erwartet, da bei mir auch immer beide Hütten betrofen sind. |
|
Hab mal versucht, mit delve zu debuggen. Das funktioniert aber im laufenden Container nicht, da der nicht privilegiert ist, daher /proc/sys ro gemounted ist und auch vom root-user nicht remounted werden kann. So gan ohne Erfahrung mit go komme ich da erstmal nicht alleine weiter |
|
Einfach /debug/pprof im Browser aufrufen. |
|
Ach so, ich war im Dateisystem unterwegs.... Ergebnis ist leider nicht wie erwartet: |
|
<title>/debug/pprof/</title>
<style>
.profile-name{
display:inline-block;
width:6rem;
}
</style>
/debug/pprof/
Set debug=1 as a query parameter to export in legacy text format Types of profiles available:
Profile Descriptions:
|
|
Stack dump daraus ziehen? |
|
|
|
Ich sehe da leider nichts Auffälliges. Offensichtlich laufen Tibber Tarif, Tibber Pulse und eine Easee. Kein Deadlock erkennbar. /cc @GrimmiMeloni siehst Du evtl. was? |
|
Es gibt da noch die deadlock-Debug-Ausgabe, die ist binär. Hilft die? |
|
Ich geh nochmal auf die Suche, ob irgendwas anderes in Container oder drumrum Probleme bereitet. Wenn kein anderer mit diesem Problem konfrontiert ist, sieht das doch irgendwie nach Grund außerhalb von evcc aus. |
|
Also ist das UI doch erreichbar! |
|
Jepp. Aber nur innerhalb des Containers selbst. Ich habe jetzt einen der Docker-Container gestoppt und wieder gestartet. Das repariert die Situation für diesen Container. Offenbar liegt das Problem also irgendwo in der Docker-Schicht des Containers. Wenn da noch jemand eine Idee zu hat, gerne, ansonsten schau ich mal die Health-Bedingung an und/oder baue was außen drumrum, was den Container alle 15 Minuten neu startet, solange Tibber nicht erreichbar ist. Danke erstmal für das ganze Debug-Kram! |
|
Ich sehe auf die Schnelle erstmal nichts auffälliges. Nur zur Sicherheit gefragt: Die Logs von evcc laufen weiter durch, d.h. in jedem Intervall werden Logs geschrieben? Wenn ja, kannst Du mal ein Trace Log erzeugen? Ansonsten noch als Idee: Vielleicht ist der Tibber auch ein Red Herring und nur ein Seiteneffekt von einer generellen Connectivity Problematik. Wie sieht denn der Netzwerk Stack da ansonsten aus? Traeffik als Reverse Proxy davor hab ich mal aus dem Kontext gelesen. Wie ist der Container denn vernetzt? Bridge, Host? |
|
Also, Netzwerktechnisch haben die Docker-Compose-Files folgenden Eintrag Das Netzwerk dazu: Die EVCC-Container exportieren die Ports nicht, da das die einfachste Möglichkeit ist, sie nicht ins Internet zu exportieren. Traefik dient als Reverse-Proxy und greift über seine Docker-Integration direkt in die Container, sorgt für eine Authentifizierung, SSL usw. und exportiert die EVCC-UI dann über Hostnamen ins Internet. Die Logs laufen regelmäßig weiter und liefern konsequent wie oben beschrieben den "grid power: outdated"-Block. Gerne weiter nachfragen. Ich stelle jetzt mal alles auf trace, muss dann aber warten, bis das Problem wieder auftritt, bis weitere Trace-Ausgaben da sind. |
Ist das so? Muss nicht zumindest ein expose her? Und steht nicht nur der Traeffik mit einem Bein im Internet? |
|
Ja, das ist so. Alles ist im Docker-Netzwerk unterwegs und funktioniert ja auch sonst. Setzen wir so bei diversen Anwendungen ein. Den zweiten Absatz hab ich nicht verstanden. |
|
Irgendwas muss bei dem Problem hier ja aber auch innerhalb des Containers "sichtbar" sein, denn evcc fühlt sich ja unhealthy. |
|
Hab nun ein Trace zum Zeitpunkt des Ausfalls: Und dann, wenn "outdated" erkannt wird: |
Mein Fehler. Ich hatte an einen Forward Proxy gedacht, aber das ist ja im Falle von Traeffik nicht gegeben. |
Der Status unhealthy kommt mit hoher Wahrscheinlichkeit weil vorher der Fehler mit Tibber auftritt. Der health Status vom evcc Core basiert darauf das ein Regelzyklus innerhalb von |
|
Trotzdem läuft ja evcc offensichtlich ( |
|
Ja, das hatten wir ja oben schon festgestellt, wenn man direkt im Container das UI mit curl aufruft. Ich bin ja jetzt auf der Suche nach dem Problem im Container. Dass sich EVCC nicht wieder selbständig verbindet, löse ich jetzt mit Health und healing-Container. |
|
Ich kanns jetzt zeitweise nachstellen, indem ich EVCC mit Tibber starte, aber eine falsche Home-ID in der Config stehen habe. EVCC fährt hoch, setzt den Container erstmal auf starting nach einer Minute dann aber auf healthy. Und siehe da, mit Debug-Log in Traefik gibts folgende Erklär-Zeile im Log: Traefik filtert unhealthy-Container weg. Das erklärt den 404. Frage also erledigt. Schönen Sonntag dann! |
|
Erstmal Danke dafür, daß Du die Erklärung für den unresponsive UI geteilt hast. |
V.a. gabs dazu auch schon Fixes die reproduzierbar funktionieren. Lösen die alle Probleme? Anscheinend nicht.
Offensichtlich haben Gerät oder API ja eine Macke, also klar. Und natürlich lässt sich das lösen. Dafür brauchts aber einen reproduzierbaren Fall den man sich im Debugger anschauen kann. Bisher gibts den nicht. Wenn Du da bessere Ideen hast: gerne! |
|
Gerät (Pulse) schließe ich aus, da beider Häuser gleichzeitig betroffen waren. Laut Log kommt offenbar seitens der Tibber-API die Meldung "unable to start stream api" 8 mal, mit Delay ~0s. Im Stack oben steht EVCC in tibber-pulse:117. Das ist das Close auf dem GraphQL-Client. Vielleicht hängt da was. Zumindest wird das in beiden Stacktrace-Varianten ausgegeben. Vielleicht mal eine TRACE-Ausgabe an den Stellen einbauen, wo ein Retry erwartet wird und ggf. nicht kommt. Die 8 Retrys hab ich im Code nicht nachvollziehen können. |
Hallo zusammen, |
|
Du verwendest auch Docker? |
|
ja, ich nutze auch Docker (synology) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Es gab letzte Nacht mal wieder einen vermutlich kurzzeitigen Ausfall der Tibber-API, so dass der Zugriff zu den Pulse-Daten für EVCC vorübergehend nicht möglich war. Die gleiche Situation hatte ich neulich schon einmal, jetzt konnte ich aber zumindest ein paar Daten aus dem Log einsammeln.
Es waren zeitgleich beide EVCC-Instanzen betroffen. Das Log ist nicht ganz gleich. Es gibt beim Ausfall einen Unterschied. Siehe unten.
Auf EVCC-Seite sieht das dann so aus, dass die UI nicht mehr erreichbar ist und "404 page not found" angezeigt wird. Beide Instanzen gleich. Im Log steht weiterhin, dass die GRID-Daten outdated seien. Allerdings sind die Daten in der Tibber-App sichtbar und aktiv. Außerdem führt ein Neustart in 4 von 4 Fällen sofort zu einem funktionierenden EVCC.
Noch blöder an der ganzen Sache ist aber, dass EVCC dann die Ladung nicht freigibt. Geplante Ladung von 4:00 bis 6:00. Es wurde nicht geladen. Die gesamte Ladesteuerung von EVCC ist offenbar bis zum Restart auf Eis gelegt, weil EVCC nicht merkt, dass die Tibber-Pulse-Daten wieder zur Verfügung stünden.
Bitte baut eine Absicherung ein, dass sich die Steuerung wieder sortiert, so dass auf alle Fälle wie geplant geladen wird und die UI erreichbar ist.
Steps to reproduce
2.Tibber-Api lahm legen :)
Ich hab keine Ahnung, ob man wirklich die gleiche Situation wie beschrieben nachstellen kann.
Ich hab zwar unten ankreuzen müssen, dass ich es mit nightly nachstellen kann, da Pflichtfeld, kann ich aber natürlich nicht.
Configuration details
Log details
What type of operating system are you running?
Docker container
Nightly build
Version
0.131.12
The text was updated successfully, but these errors were encountered: