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.

[Sumpfdotter]

As a reader of this discussion, I have perceived different wishes from various participants as to how the system should behave. I would like to contribute with a requirements proposal/clarification so that - assuming the proposal is accepted - the implementation concepts can go in this direction.

Here is the proposal for how evcc should behave, initially regardless of the effort required to create this behaviour. I would like to simplify the system behaviour with the proposal by directing the start case (which is the issue here) directly to an operating state that occurs anyway.

Here is the proposed requirement:

1. if a component connected to evcc fails (or the connection to it fails) while evcc is running, the connection is automatically re-established as soon as the component is available or connectable again.
2. this also applies if several connected components fail, or even all of them.
3. the operator of evcc is made aware of the connection statuses or the reasons for errors (this could be log files, status displays or notifications).
4. if connected components are currently not available, this can result in evcc having to degrade the corresponding functions. In the simplest case, evcc stops its entire behaviour when connected components fail until all failed components are reconnected.
5. In addition, gradual and dependency-orientated degradation is aimed for. For example, the local charging control should not be stopped completely if an Internet service for CO2 has failed. However, it is inevitable that charging control must be stopped if the connection to the wallbox is interrupted. Now comes the real point:
6. evcc's start state is defined as equivalent to the state evcc enters if all connected components have failed during operation.

With requirement 6. evcc does not require its own boot procedure, but can be booted directly into the ‘all connections are down’ state. From then on, the recovery procedures for this state, which are required here anyway, take effect and, if all connected components are available, all connections are established shortly after the start - without the need for a separate boot procedure.

I personally see the reason for these requirements in the assumption that the affected systems are all systems that are ideally in operation 24/7:

• Wallbox
• PV incl. battery
• EV charging controller (evcc)
• Network components such as routers, switches, ...
• Internet, Internet services ...
• ...

One indication that the systems should not wait for each other when starting up is shown in particular by the coupling of evcc with the wallbox: A wallbox is connected to the HEMS (evcc in this case) and vice versa. If both systems required the other when booting, a connection would never be established in first boot or after each complete shutdown, e.g. after power losses.

I am fully aware that the behaviour described here cannot be implemented easily. With this proposal, I want to work towards a consensus on the desired behaviour.

In other words: Is there a counter-reason why the boot behaviour should deviate from the behaviour when everything around evcc was once down in operation and is now available again? Personally, I can't see any reason right now, so I'd like to challenge that here.

[andig]

The reason right now is that the desired behavior is not in place. Nobody debates this is not being the desired state.

[Sumpfdotter]

My proposal introduces something new: it clearly states that no dedicated boot routine is wished. This is because there are different views on it in this thread, indicating that there are reasons for such a routine without clearly stating them.

The reason right now is that the desired behavior is not in place. Nobody debates this is not being the desired state.

As I said that is not true. There are serveral comments in this thread of people indicating that it is evcc's "design" to implement a fast fail routine at boot up. In fact, nobody stated the source of that requirement here but also nobody clearly contradicted that this requirement is not present. Examples:

User:

Das aktuelle Verhalten ist eine bewusste Designentscheidung, so weit ich weiß ist eine Änderung dieses Verhaltens nicht gewünscht, und es gab schon Contributions die dieses Problem zu lösen versuchten. Die Argumentation ist folgende: Es wird erwartet, dass alle Komponenten stabil funktionieren und bei einem Ausfall einer Komponente der Neustart fehlschlägt, damit man Fehler sofort erkennen kann und sie nicht durch die vorhandenen Fehlerkorrekturen unentdeckt bleiben (fail early).

User:

Ich musste leider gerade feststellen, dass dieses Verhalten sehr dringend notwendig wäre. Bei mir hat sich ein Shelly verabschiedet

Reply:

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

(in other words: dear user, please fix your setup, rather than prioritizing a change in evcc's bootup behavior)

The only comment indicating that the current boot behaviour is not wished it that one:

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.

But also that one does not clearly state if and why a dedicated boot routine is required.

If we agree on not having such a routine, the migration plan is (not easy) but clear:

1. Introduce a state model (connected/disconnted/...) for depending devices and services and implement it for the corresponding integrations (if not yet implemented)
2. Make states and failiures available for operators (assuminlgy this is already implemented with logfiles and error notifications within the UI)
3. Implement a retry and backoff strategy for reconnecting to failing devices/services (if not yet implemented)
4. Implement a more fine granular degradation of functions e.g. if single wallboxes or internet services are not present (if not yet implemented)
5. Replace bootup procedure by directly entering state "disconnected" for all lintegrations (will trigger retry&backoff right at the beginning)

This plan doesn't make sense if there are reasons for having a boot sequence. And those are indicated, but not stated so far. I don't know any, personally. That's why I'm challenging.