Startup if not all wallboxes, meters, integrations are reachable

[naltatis]

Currently, evcc requires all configured devices to be reachable on startup. When this is not the case (e.g. a meter is not responding) evcc will run in a failsafe mode (control loop and many UI features disabled) and automatically restarts every 15min for retry until everything is reachable.

In some scenarios (unreliable hardware, broken devices), this behavior is problematic and requires temporary reconfiguration of evcc (e.g. disable a device) to get back into a functioning state.

To change this, we have to rework how initialization is done and may need to introduce concepts like device health status, per device retry mechanisms, discuss effects on e.g. load balancing, autodetect and visualize the affected parts correctly in the UI (e.g. disable loadpoint controls because a charger is not responding for a longer time).

\cc @andig

[StefanSchoof]

For inverter only (without an battery) there is the extra problem, that many of them go into a power saving mode after sunset and preventing evcc from restarting in the night, see #10972.

[Sumpfdotter]

Thanks for that description. I add this comment so that this issue can be found by users having that issue as well:
Related log messages, e.g. if eebus wallbox is down during bootup:
cannot create charger
cannot create charger type 'eebus': i/o timeout
FATAL will attempt restart in: 15m0s

[armin-ei]

I have similar issue with two wallboxes configured in evcc: as soon as one Wallbox is off or offline, then evcc cannot be used anymore for the other wallbox, even though it is online. evcc should be able to start in such case for the wallbox that is in operation. The Workaround to use two different yaml files is not a good WA.

[SolarPower2024]

Ich musste leider gerade feststellen, dass dieses Verhalten sehr dringend notwendig wäre.

Bei mir hat sich ein Shelly verabschiedet, der als PV Meter diente. (1 von 2 PV meters)
Der shelly wurde über die UI konfiguriert und obwohl das PV Meter rein für die Darstellung dient, Steuerung erfolgt ja via grid meter, startet evcc nicht mehr hoch.
Einzige Lösung: löschen der DB Einträge die mit dem PV Meter zusammen hingen.

Auch ein Failsafe Modus startete nicht. Eigentlich sollte der ja bereits vorhanden sein oder? Oder habe ich das falsch verstanden?

[andig]

Meine PV läuft seit 14 Jahren ohne einen einzigen Ausfall von irgendeiner Komponente. Eine Shelly ist auch eher Bastelware.

[SolarPower2024]

Meine PV läuft seit 14 Jahren ohne einen einzigen Ausfall von irgendeiner Komponente. Eine Shelly ist auch eher Bastelware.

Da stimme ich dir zu.
Ist auch nur das BKW ;-)

[naltatis]

@umrath @SolarPower2024 Lass uns nicht hier das Thema neu diskutieren. Konkrete Lösungen oder PRs sind natürlich immer willkommen.

[andi0b]

Wechselrichter im Powersafe-Mode macht gerade im Winter 16 Stunden am Tag permanent rote Fehlermeldungen in der UI. In meinem Fall startet evcc zum Glück trotzdem.

Ich habe auch einen mobilen charger in evcc drinnen, wenn ich den an/abstecke muss ich derzeit die Config immer neu schreiben und evcc neu starten.

Meine PV läuft seit 14 Jahren ohne einen einzigen Ausfall von irgendeiner Komponente. Eine Shelly ist auch eher Bastelware.

Das ist schön!

[voruti]

Bei mir ist letztens das Internet ausgefallen und ich habe folgende Meldung im Log beim Start erhalten (Ausschnitt):

[gsi   ] ERROR 2024/12/10 20:45:45 Get ""https://api.corrently.io/v2.0/gsi/prediction?zip=***"": dial tcp 172.67.133.68:443: i/o timeout
[main  ] FATAL 2024/12/10 20:45:45 cannot create tariff type 'grünstromindex': Get ""https://api.corrently.io/v2.0/gsi/prediction?zip=***"": dial tcp 172.67.133.68:443: i/o timeout
[main  ] FATAL 2024/12/10 20:45:45 will attempt restart in: 15m0s

Entsprechend lief evcc nicht, obwohl Wallbox, etc. im lokalen Netz noch vollständig verfügbar waren.
Ich nehme an, dies zählt auch zu diesem Issue?

Generell versuche ich, möglichst unabhängig von Cloud-Diensten zu sein und verwende daher gerne Open-Source-Software und offene Komponenten. Mit dem Fehler ist es halt wieder sehr schade, an der Stelle vom Internet abhängig zu sein und das Auto nicht laden zu können.

[andi0b]

Ich nehme an, dies zählt auch zu diesem Issue?

Leider ist dieser Issue überwiegend eine bewusste und so gewünschte Design-Entscheidung. EVCC funktioniert ja überwiegend problemlos auch ohne diese Daten. Ich bin am Überlegen einen Sidecar-Container mit einem HTTP-Proxy einzurichten, der einfach auf alle HTTP-Fehler mit einer gecachten 200 OK Response antwortet. Das wird bei einigen Modulen zwar zu Logik-Fehlern führen, aber EVCC kann sich in der Regel sehr gut davon erholen.

Nur beim ersten Start werden alle Fehler als krtisch erachtet und der Start wird verweigert. In vielen Fällen kann man EVCC also nur in gewissen Situationen neu starten, bzw landet in einer gewissen Mieserie. Ich kann beispielsweise EVCC nur während die PV-Anlage Strom produziert starten, im Winter also nur zwischen 8 und 16 Uhr. Wenn ich also nach 16 Uhr EVCC stoppe, kann es sein dass es zu hohen Kosten kommt wenn dann Hausakku oder Auto bei extremen Strompreisen einfach weiterlädt.

PS: evcc ist leider nicht open source im klassischen sinne (free software), sondern enthält viele kommerzielle Codestücke quer durch die code base, daher kann die community aus Lizenzgründen leider keine alternativen Versionen bereitstellen, die diese Fehler beheben.

[SolarPower2024]

Das ist möglicherweise eine Idee, um die (in meinen Augen) falsche Designentscheidung auszuhebeln: Einen Proxy dazwischen schalten, der grundsätzlich alle Verbindungsanfragen positiv beantwortet, egal ob das Device dahinter antwortet oder nicht.

Hast du Home Assistant im Einsatz? Ich habe dies damit gelöst. Die Geräte sind in Home Assistant eingebunden und werden per mqtt an evcc geschickt. Sollten die Geräte wie zb mein PV oder grid meter nicht verfügbar sein, so sendet HA halt den Wert 0.
Dadurch habe ich die Fehler für mich abgefangen.

[StefanSchoof]

Damit Tarifs kein Startup Error erzeugen gab es vor einiger Zeit #16258

[andig]

Leider ist dieser Issue überwiegend eine bewusste und so gewünschte Design-Entscheidung.

Wenn es eine Design "entscheidung" wäre dann könnten wir hier als wontfix zu machen. Es ist schlicht der Stand der Implementierung. Zu gegebener Zeit werden wir das ändern. Wem das zu langsam geht der darf gerne in den Code schauen und einen Vorschlag machen. Danke.

[andig]

@umrath @andi0b macht gerne eine Discussion zu alternativen Lösungen die ihr hier verlinken könnt. Hier gehts um das evcc Verhalten.