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: |
|
Läuft seit heute Nacht im Test. Ist es erwartetes Verhalten, dass alle vier Minuten die Meldung im Log auftaucht? Kommt nicht in der UI, da wohl nicht über den normalen Logger mit Timestamp etc. gelogged wird. Passend dazu ändert sich dann wohl auch die Subscription-ID. Hier der Auszug aus der UI-Loganzeige: Andreas |
|
das ist aktuell bei mir auch so, liegt aber ziemlich sicher nicht am Nightly, sondern an Tibber. Es gibt gute und schlechte Phasen. EVCC bricht die Verbindung ab (und startet sie dann sofort neu), wenn 10 Sekunden keine Daten eingegangen sind. Ich bekomme von Tibber ca. alle 4-5 Sekunden einen Messwert, wenn also einer fehlt, dann kann das schon einen Re-Connect triggern. Warum EVCC die Daten so schnell haben muss, weiß ich nicht. Es ist aber auch nicht von der Hand zu weisen, dass die Tibber-API nicht besonders zuverlässig liefert. Wir warten aktuell darauf, dass eine solche Meldung vom Server kommt (dann steht hinten "server" statt "client"). Wenn Evcc das überlebt, war der Fix erfolgreich. |
Schwer zu beurteilen - unvollständige Logs helfe nicht bei der Analyse.
Warum teilst Du denn nicht das vollständige Log, aus dem Du oben zitierst? Damit könnten wir vermutlich schon mehr sagen. |
|
Bei mir gab es auch 3x den Eintrag Wobei sich die Ich weiß nicht wie relevant das ist, da der Fehler aber erst seit dem nightly-build (b7a9abb) auftritt hier einmal der gesamte Log vom Start gestern Abend bis jetzt. EDIT: |
|
Relevant ist nur ob sich evcc aufhängt oder Messwerte liefert |
|
Im Log von @dustin-ha ist der Fehler nicht zu sehen. Ganz konkret suchen wir nach dem Verhalten des aktuellen Nightlies wenn folgender ERROR auftritt: Der Nightly sollte im Anschluß wieder versuchen neu zu verbinden. |
|
Der eigentlich gesuchte Fehler ist bei mir bisher nicht aufgetreten. Mein Log sieht aber so aus, als ob in der neuen Version EVCC nun alle 4 Minuten eine neue Session-ID bekommt, vielleicht weil es die Subscription alle 4 Minuten neu anfordert. Nicht dass durch dieses Verhalten jetzt API-Limits gerissen werden. Daher meine Frage oben, ob das so gedacht ist. Dazu hab ich noch keine Antwort bekommen. Wenn dazu mein Log hilft, hänge ich es gerne dran. Mir ging es eigentlich nur erstmal darum zu erfahren, ob nun eine regelmäßige neue Subscription angefordert wird, auch wenn die alte noch besteht und funktioniert. Andreas Log aus der GUI evcc-20250203-205012-trace.log.zip Log im Docker-Container |
|
Ist bei mir nicht so, nur wenn der (auch bisher schon unkritische) timeout auftritt, bei dem evcc sich danach neu mit der Tibber-API verbindet. Das passiert in unregelmäßigen Abständen, aber nicht alle vier Minuten. Mal eine Stunde, mal ein paar Stunden... |
|
Im GUI-Log müsste auch noch folgende Meldung drin stecken, die vor einer Stunde (19:56) gekommen ist, sagt mir das rote Ausrufezeichen:
Andreas |
Generell ist das nicht so. Evcc führt ohne Anlass (also wenn die Verbindung einmal steht) keinen Reconnect durch. Ich habe mir das nun geteilte Log angeschaut. Man kann darin erkennen, das ca. alle 4 Minuten für 10-20 Sekunden Timeouts auftreten. Es gibt da also definitiv ein wiederkehrend auftretendes Problem mit der Netzwerkverbindung des Pulse.
Der gezeigte Fehler tritt nach einem disconnect auf. Ich gehe hier erstmal von einem Folgefehler aus. Fazit bis hier her:
|
|
Ich hab eben mal Pulse und Bridge neu gestartet. Das Verhalten bleibt aber gleich. Im anderen Zuhause tritt es nicht auf. Andere Idee: Ich habe ja zur Zeit zwei EVCCs (Latest wie immer und zum Testen Nightly mit gleicher Tibber-Home-ID) laufen. Könnte es ggf. damit zusammenhängen? Ich werde eine davon mal vorübergehend stoppen und schauen, ob das etwas ändert. |
JA! Natürlich - siehe Fehlermeldung die Du geteilt hast. Der Pulse mag ganz klar nicht zwei Clients gleichzeitig. |
|
Hm. Am doppelten EVCC liegt es aber wohl nicht. Gleiches Verhalten auch mit einem einzelnen laufenden EVCC. Position der Bridge auch nochmal kontrolliert. Status in der App: Batterie "ausgezeichnet", Verbindungen "gut". Im Tibber-API-Explorer wird konstant alle drei Sekunden das Subscription-Ergebnis angezeigt, ohne Abbruch. Mit und ohne ein oder zwei parallel laufende EVCCs. Aber ich werde nochmal ausprobieren und dabei die Familie von der Tibber-App fernhalten.... |
|
Diskutieren wir jetzt darüber wie das Logfile aussieht oder ob es noch echte Probleme gibt? Falls Letzteres: welche sind das? |
|
Schaut Euch mal das Log von heute an, insbesondere ab 09:46. Nightly ist die von heute Nacht. Hatte heute Morgen update gezogen. Anm: Mein Cron-Job zur Überwachung des Logs auf "grid power: outdated" läuft alle 10 Minuten, deswegen hat der dann um 09:50 den Service neu gestartet. |
|
exakt um diese uhrzeit trat der fehler auch bei mir auf. |
|
Hast Du auch die Nightly laufen? Und sieht Dein Log irgendwie anders aus als meins? (Bzw. hast Du was nach 09:50...?) |
|
Bei mir gab es den selben Fehler, aber 2x seit dieser Nacht. Ich hätte auch einen Log, der hat aber leider fast 50MB und ich kann ihn hier mal wieder nicht hochladen. Wenn sich den noch gerne wer ansehen möchte müsste ich nur wissen wo ich den hochladen soll |
|
02:14 habe ich nicht. Kann das die DSL-Zwangstrennung o.ä. gewesen sein? Die führt auch schon mal zu Gruß |
Gute Idee, die |
ich bekomms grad nicht hin mein log zu exportieren aber es entspricht soweit ich das sehe deinem. installierte Version: 0.132.0 |
|
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! |
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: