Hausverbrauch/Fehlerfall: PV, Speicher und Verbraucher (Follow-up zu #3951) #3959

Der Zähler hat bereits einen Fehlerfall-Mechanismus: Wenn er 60s durchgängig im Fehlerzustand ist, wird auf eine konfigurierte maximale Leistung zurückgegriffen, statt unbegrenzt mit dem letzten bekannten Wert weiterzurechnen (Counter._get_loadmanagement_state). Bei PV, Speicher und Verbrauchern gibt es das nicht — fällt z.B. ein Wechselrichter aus, bleibt sein power-Wert für immer auf dem letzten Stand stehen, und alles, was diesen Wert summiert (Hausverbrauch, Überschussberechnung, self-controlled-consumer-Feed, Dimmung) rechnet unbegrenzt mit veralteten Daten weiter. Das war der Kern der ursprünglichen Diskussion (#3931).

Was würde ich vorschlagen:

• Gleiches Prinzip wie beim Zähler: nach 60s durchgängigem Fehler wird die betroffene Komponente in der Summenbildung (PvAll/BatAll/ConsumerAll) mit 0W berücksichtigt, statt mit dem alten Wert.
• Der einzelne Komponentenwert selbst (pv_data["pv7"].get.power etc.) bleibt unverändert — genau wie beim Zähler wird nur die abgeleitete/summierte Größe angepasst, nicht der Rohwert.
• Bei Verbrauchern ist das etwas aufwändiger: Anders als PV/Speicher gibt es keine einzelne Sammelstelle — Counter._set_power_left() liest jeden Verbraucher direkt, bevor die Verbraucher-Summe überhaupt berechnet wird. Muss also an zwei Stellen mit derselben Logik behandelt werden.
• Vorarbeit dazu ist schon gemacht: fix Counter: Fehlerfall erst nach 60s #3951 hat einen Bug im Zähler-Fehlerfall selbst gefixt (die 60s wurden nicht eingehalten), und in einem separaten PR Geräte mit gemeinsamer Verbindung: Fehlerzustand korreliert setzen #3958 hab ich gerade behoben, dass Geräte mit gemeinsamer Verbindung (RCT, Kostal Piko, sonnenBatterie, u.a.) allen Komponenten unabhängige statt korrelierte Fehlerzustände gaben.

Was noch zu klären wäre:

Wie informieren wir den Nutzer, wenn nach 60s auf 0W umgeschaltet wird?

Zwei Möglichkeiten:

• (a) eine einmalige pub_system_message-Meldung über den bestehenden System-Nachrichten-Kanal, unabhängig von der Modulkarte
• (b) richtige, aussagekräftige Fehlermeldungen direkt am Modul selbst (fault_str), sodass man auf der Modulkarte sieht, was los ist

Ein Punkt, der (b) erschwert: fault_str wird aktuell teilweise von zwei verschiedenen Stellen gesetzt, die sich nicht kennen — dem allgemeinen Timeout-Fallback in loadvars.py (springt ein, wenn der komplette Geräte-Thread nicht rechtzeitig fertig wird) und der Fehlerbehandlung des Moduls selbst (z.B. eine konkrete Verbindungsfehlermeldung). Je nachdem, welche der beiden zuletzt schreibt, zeigt die Modulkarte mal die eine, mal die andere Meldung — für dasselbe zugrundeliegende Problem. Bevor wir dort eine dritte Meldung ("jetzt mit 0W gerechnet") ergänzen, sollten wir klären, ob und wie wir das grundsätzlich vereinheitlichen wollen, oder ob ein sauber getrennter System-Nachrichten-Kanal (a) der pragmatischere Weg ist.

Weitere offene Punkte:

• Die genaue Formulierung der Meldungen steht noch nicht fest.
• Größere, grundsätzliche Frage: Wie sehr können wir fault_state über alle ~100+ Gerätemodule hinweg als verlässliches Signal vertrauen? Der letzte PR hat ein konkretes, bekanntes Muster in 8 Modulen behoben (gemeinsame Verbindung, aber unabhängiger Fehlerzustand pro Komponente). Es ist aber nicht geprüft, ob es in anderen, einzeln geschriebenen Modulen andere Fälle gibt, in denen z.B. eine Exception verschluckt wird, ohne fault_state überhaupt zu setzen (dann bliebe eine Komponente dauerhaft auf "kein Fehler" stehen, obwohl sie es nicht ist), oder .warning() statt .error() gesetzt wird (dann würde unser 60s-Mechanismus, der nur auf ERROR reagiert, nie greifen). Eine vollständige Prüfung wäre ein eigenes, größeres Audit-Thema, unabhängig von dieser PR.