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: |
|
@GrimmiMeloni Du meinst go func() {
for {
select {
case <-ctx.Done():
return
default:
var message OperationMessage
if err := conn.ReadJSON(&message); err != nil {
// manual EOF check
if err == io.EOF || strings.Contains(err.Error(), "EOF") || errors.Is(err, net.ErrClosed) || strings.Contains(err.Error(), "connection reset by peer") {
sc.errorChan <- errRetry
return
}und for {
select {
case <-ctx.Done():
return sc.close(subContext)
case e := <-sc.errorChan:
if sc.getClientStatus() == scStatusClosing {
return nil
}
// stop the subscription if the error has stop message
if e == ErrSubscriptionStopped {
return sc.close(subContext)
}
if e == errRetry {
return sc.Run()
}
if sc.onError != nil {
if err := sc.onError(sc, e); err != nil {
sc.close(subContext)
return err
} else {
return sc.Run()
}
}
}
}Wir können ins Nightly ja mal mehr Logging für die Stelle einbauen! |
|
@foto-andreas bitte nightly verwenden- dort gibt es jetzt mehr Logging. |
|
Ok. Nightly läuft und loggt mit... |
|
@andig ja, das ist die Stelle. Das logging in der geforkten Lib sollte zumindest Klarheit darüber schaffen ob dies der Auslöser ist. |
|
klasse, dass ihr euch da nochmals dahinterklemmt |
This comment has been minimized.
This comment has been minimized.
|
So, jetzt ist es wieder passiert. Hier das Log-File rund um den entsprechenden Zeitpunkt Pprof-Sachen habe ich im Anhang als tar.gz zusammengepackt. Ich hoffe, damit könnt Ihr was anfangen... P. S. Bei mir läuft EVCC nicht in einem Docker-Container! |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@pschwed nicht das nightly? Solche Logs kennen wir schon, wo ist die neue Information? |
|
@machristoph1 dein evcc läuft weiter, ui erreichbar? |
|
Habe inzwischen neu gestartet, damit ich laden konnte. Aber ja. UI erreichbar. Zeigt das rote Warn- Dreieck für Fehler. Laden geht aber nicht. |
This comment has been minimized.
This comment has been minimized.
|
@SmartVolker bitte keine epischen Screenshots die einfach nur "ich auch" sagen. Das hilft Niemandem. Danke. |
|
@machristoph1 @GrimmiMeloni das Log in #17925 (comment) ist sehr interessant, ich verstehe es aber nicht. Hier passiert ja (mehrfach): Im letzten Fall gehen wir dann aber nicht mehr in den Retry: Ich sehe nicht, wie das mit den Änderungen aus hasura/go-graphql-client@master...andig:go-graphql-client:log möglich ist. Mit jedem Ideen? |
|
@machristoph1 bitte in 30min nochmal neues Log mit neuem Nightly. Vermutung: beim retry wird |
|
Ist ok, starte ich nachher. Kann halt etwas dauern, bis der Fehler auftritt… Edit: läuft (im Moment ohne --profile, hoffe das ist ok, brauche morgen sehr früh sicher ein geladenes Auto, deshalb lasse ich evcc nicht interaktiv, sondern über den Dienst laufen und starte den über cron im Fehlerfall neu, morgen früh kann ich im Zweifel wieder auf interaktiv mit --profile umstellen |
|
@andig ich schaue gerne nochmal mit drauf - würde jetzt aber erst mal abwarten was der neue Nightly bringt. |
|
Von heute Nacht gibt es wieder ein paar Log-Meldungen, die so aussehen, als ob tibberseitig das Problem aufgetreten wäre. EVCC ist aber diesmal nicht in den gridpower: outdated Status gefallen und hat weiterhin funktioniert. |
Gab es kurz nach 01:09:53 heute Nacht irgendeine Besonderheit in Deinen Logs, @machristoph1 ? Bei mir gab es danach keine weiteren Einträge im Log. UI war heute morgen unresponsive. EVCC lief manuell gestartet mit --profile im Testmodus - aktuelles Nightly (evcc:arm64 (0.133.0+1737367712, 0.133.0+1737568052)) |
|
Dann haben wir immer noch nicht die Stelle gefunden wo das passiert :( |
Nein, der Zeitpunkt ist bei mir völlig unauffällig.
Kann es bei @pschwed was anderes gewesen sein? Stehendes UI ist eigentlich auch nicht das Kennzeichen des Fehlers (wobei es evtl. in Docker-Umgebungen anders ist.). Bei mir war immer das UI ansprechbar, hat ERROR-Hinweis gezeigt, hat aber nicht mehr registriert, ob ich das Auto angesteckt habe 08:52 ist übrigens gerade genau das gleiche passiert wie heute Nacht 02:43. Hat er aber überlebt, diesmal ohne angeschlossenes Auto. Wie sieht das bei Dir aus @pschwed? |
|
Nochmal mehr Logging ergänzt. Uns interessieren nur noch neu Logs. Es interessieren nur Hängern, kein "da war auch was". |
Zu dem Zeitpunkt lief evcc bei mir leider nicht, sorry. Irgendwie hatte ich gehofft, dass ihr noch Ideen habt, wie ich den Grund des Crashes aus irgendwelchen anderen logs rausziehen kann.. Ich sehe allerdings auch in meinen logs den "context deadline" Fehler, falls es das ist, was Du meinst.
ist bei mir ein Pi und EVCC läuft derzeit im Testmodus (manuell über die Konsole gestartet) und piped das log in eine Datei. Ich hatte aber auch noch nie vorher eine unresponsive UI, bisher war es immer so, wie von Dir beschrieben und die UI weiter erreichbar. War deshalb auch eine Lernkurve zu vestehen, dass das neue Logging nicht über die UI angezeigt wird (zumindest bei mir nicht).
läuft. Hoffentlich stürzt nicht wieder der ganze Prozess ab.. |
Schwer vorstellbar. Bisher ist evcc noch nie ohne Log abgestürzt. Wir machen hier wieder auf, wenns ein Log aus dem aktuellen Nightly gibt. |
Ist es ja auch nicht.
Ich kann Dir massenweise Logs aus dem aktuellen Nightly schicken. Aber wir warten hier alle darauf, dass der Fehler auftritt, gel? |
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: