Tibber: evcc hängt nach kurzzeitigem Ausfall von Tibber #17925
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: |
|
Hier ist mein Log dazu. Vom letzten Messwert bis in den Endlos-Loop mit Gridpower outdated. Mir scheint es, als ob der Fix eigentlich funktioniert, aber vielleicht zu schnell versucht wird, den Stream wieder zu öffnen?! |
|
Aus meiner Sicht sieht die Korrektur erfolgreich aus. EVCC fängt sich nach einiger Zeit wieder. Und das war bei mir erst um 9:50. Hier der relevante Teil aus dem Log: Vollständig im Anhang. Andreas |
Ah, das ist interessant. Hatte auch schon Sorgen, dass mein Cronjob das zu früh abgebrochen hat und habe die Frequenz der Prüfung jetzt mal auf 30 Minuten hochgestellt |
|
Bei @foto-andreas hat irgendetwas evcc neugestartet. Zu erkennen an:
Das Log von @pschwed erscheint mir schlüssig. Der Server/Pulse beendet die Subscription. Somit macht es auch Sinn, daß er danach immer wieder meldet das es keine Subscription mehr gibt, weil wir nie neu subscriben. @andig meiner Ansicht nach reicht hier ein |
War bei mir definitiv nicht so, EVCC lief bei mir bis 16:27:08 weiter und hat sich nicht wieder gefangen. Das einzig seltsame ist um 11:10:32 passiert, da gab es einen unmarshal error, der vorher noch nie aufgetreten ist (den loop aber auch nicht weiter beeinflusst hat). Ist vermutlich irrelevant.. |
Ach ja, das ist ja nicht mehr die parallel laufende Testinstanz. Da hat das autoheal zugeschlagen. Andreas |
|
@GrimmiMeloni wäre Klasse wenn du das machen könntest. Vielen Dank! |
|
@GrimmiMeloni meinst Du wir können das Zusatzlogging in graphql wieder ausbauen? Und hier zu machen? |
|
Hier erstmal zu, ja. |
|
Könntet Ihr Euch das bitte nochmal anschauen? Gruß |
|
Bitte morgen nochmal probieren |
|
Ein weiterer Fix wurde gerade gemerged. Bitte ab morgen nochmal mit dem Nightly testen. |
|
Hi @GrimmiMeloni, eben (14:15) gab es einen Fehler im Zugriff auf die Tibber-API, der verdammt nach unserem Problem aussieht. |
Ja, das sieht erstmal gut aus.
Das hingegen sieht irgendwie immer noch nicht wie erwartet aus. Läuft die Instanz so wie im Log gezeigt noch, oder wurde diese zwischenzeitlich restartet? Falls die noch läuft, wäre ein Thread Dump super interessant. |
Sie läuft noch. Aber nicht im profiling Modus gestartet. Dann komme ich nicht an einen Thread Dump ran, oder? Wenn es hilft, starte ich aber mal eine mit profiling |
|
Korrekt. Nachträglich lässt sich das nicht aktivieren. |
Ok, habe es jetzt in einer screen-shell interaktiv mit --profile laufen, melde mich, wenn es wieder auftritt |
|
Bei mir auch von ca. 14:16 bis 15:50 Verbindungsprobleme und grid power: outdated. Danach hat er sich wieder gefangen - wenn ich richtig gezählt habe, mit 77 neuen Subscriptions. Evcc lief trotzdem weiter, hat aber jeden Messwert von Tibber eben 77 mal bekommen... Hier ist mein pprof: Log gerne per Mail oder so, sollte aber so aussehen wie das von @machristoph1 |
|
Danke für das pprof. Dort sehe ich zumindest schonmal keine hängenden Routinen, und scheinbar leaken wir auch keine Routinen. Ich würde das passende Log zu dieser Instanz gerne einmal sehen.
--> bitte an [email protected] senden Danke! |
|
Wir haben gerade nochmal eine Anpassung gemerged, die hoffentlich auch die doppelten Subscriptions entfernt. Bitte ab morgen mal mit dem Nightly testen. |
Danke, wird getestet, melde mich! |
|
So, gerade scheint der Stream-Abriss bei Tibber aufgetreten zu sein Für mich sieht das jetzt ziemlich gut aus. Braucht Ihr mehr? Komplettes Log, Profiling-Daten? |
|
Bestätigung. Sieht erst mal sehr gut aus! Der letzte Messwert kam um 13:21:15, danach hat Evcc immer wieder versucht, den Stream neu zu starten. Um 13:24:40 war wieder eine funktionierende Subscription da - und zwar wirklich nur eine. Super! |
|
Prima. Dann können wir das ja jetzt erstmal als erledigt betrachten. |
|
Danke Euch, insbesondere Dir, für die erfolgreiche Arbeit an der Problemlösung |
|
Ja, echt super! Auch Dank an die anderen betroffenen, die sich hier eingebracht haben, während ich anderweitig eingespannt war und in letzter Zeit nicht so Infos liefern konnte, wie ich mir gewünscht hätte. Andreas |
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: