76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

Bison

Hallo DS_Starter,

ich habe jetzt ca. 2 Jahre lang nur Simple laufen lassen weil ich nur ein Balkonkraftwerk hatte.  ;D
seit Mai habe ich eine Große Anlage und wollte die werte genauer, sowie zusätzlich die Verbrauchsprognose. Nachdem ich umgestellt habe auf ComplexApi AI ist der PV Forecast ganz schlecht. Ich war die Trainingsdaten dürften jetz 90 Tage und mehr sein und ich habe Löcher von 2000 Watt auf 79 Watt. Ich denke ich habe etwas falsch gemacht und bin auf der Suche nach dem Fehler.

Gruß Bison

Raspberry, Homematic, CUL, 50 Device, 260 Entities

300P

Hallo Bisom,

ich hatte mir für meinen Standort letztes Jahr OpenMeteoDWDEnsemble-API ausgesucht und bis ca. August 2025 auch durchgehend so genutzt.

Ab Septemberhabe ich dann weiter "pvCorrectionFactor on_complex_api_ai" genutzt.
- aber auf "setupRadiationAPI OpenMeteoDWD_D2-API" gewechselt.


Der Unterschied ?!?:
- Vorher (bis August) wurden etwas "übertriebene" Erträge vorhergesagt
-Ab September wurde nach dem Modellwechsel dann weiterhin etwas "übertrieben" 

siehe Screenshot von 2025:



Wenn ich jetzt zurückschaue - dann war es mit dem einfachen DWD-Device (leider gibt es keine Stationen mit Strahlungsdaten mehr im meiner direkten Nähe) am besten in den Vorjahren..... :))  :'(Du darfst diesen Dateianhang nicht ansehen.


PS:
Meine Anlage ist aber auch :  3 WR mit 5 Strings in 3 Ausrichtungen 
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

DS_Starter

Zitatich habe jetzt ca. 2 Jahre lang nur Simple laufen lassen weil ich nur ein Balkonkraftwerk hatte.  ;D
seit Mai habe ich eine Große Anlage und wollte die werte genauer...
Das heißt du hast deine Anlage stark vergrößert?
Dann sind die Abweichungen eine Folge. Die Vorhersage verwendet falsche Korrekturfaktoren.
Einfaches Beispiel: Für morgen werden zur Stunde X 5000Wh prognostiziert. Diese werden aber mit dem ermittelten Faktor der alten Anlage behandelt. Der stimmt natürlich nicht, da die Parameter (Leistung, Ausrichtung aller Strings) ja jetzt ganz andere sind. Für die KI ist es noch schlimmer. Sie "weiß" dass bei Sonnenstand x, Strahlungsprognose y und Wetterbedingung z ein Ertrag von W kommen sollte. Das ist aber der Wert auf der Grundlage einer Mischung aus Alt- und Neuanlage.

Ich denke unter diesen Voraussetzungen ist es besser die alten Lerndaten zu entfernen und neu aufzeichnen zu lassen. Es ist wie bei einer Neuanlage.
Heute ist es schon zu spät, aber morgen könnte ich mir anschauen wie man das am Besten tun könnte ohne die Verbrauchsdaten ebenfalls zu löschen.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#4578
@Bison,

mit den nachfolgende Befehlen bleiben die Verbrauchsdaten erhalten.
Um alle gesicherten AI-Rohdaten zu löschen verwendest du:

 set ... reset aiData delDataAll

Alle Korrekturfaktoren und dafür gespeicherten Erzeugungsdaten werden gelöscht mit:

 set ... reset pvCorrection cached
Die letzteren Daten können gesichert und wiederhergestellt werden mit:

 set ... operatingMemory backup | save | recover-<Datei>

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Petrosilius Zwackelmann

Seit einigen Tagen zeigt meine zuvor laufende SolarForecast Konfiguration nur noch folgende Meldung.
ZitatHerzlich Willkommen!
Die nächsten Abfragen führen sie durch die Grundinstallation.
Sind alle Eingaben vorgenommen, prüfen sie bitte die Konfiguration abschließend mit "set SolarForecast plantConfiguration check" oder mit Druck auf das angebotene Icon.
Korrigieren sie bitte eventuelle Fehler und beachten sie mögliche Hinweise.
(Die Anzeigesprache kann mit dem Attribut "ctrlLanguage" umgestellt werden.)
SolarForecast wartet auf Solarvorhersagedaten ...

Ein
Zitatset SolarForecast plantConfiguration check
bescheinigt eine funktionierende Konfiguration.
ZitatHerzlichen Glückwunsch 😊, die Anlagenkonfiguration ist fehlerfrei.

Man könnte annehmen, dass ein Problem mit dem Wetterdaten vorliegt - ein get Solarforecast weatherApiData
Liefert aber sofort Werte.
ZitatOpenMeteo => fc0_0 => StartTime: 2025-11-15 00:00:00
                      rr1c: 0
             fc0_1 => StartTime: 2025-11-15 01:00:00
                      UpdateTime: 2025-11-15 01:45:52
                      don: 0
                      neff: 98
                      rr1c: 0
                      ttt: 9.1
                      ww: 3
             fc0_10 => StartTime: 2025-11-15 10:00:00
                       UpdateTime: 2025-11-15 10:49:17
                       don: 1
                       neff: 100
                       rr1c: 0
                       ttt: 11.6
                       ww: 3


Hat jemand einen Hinweis wie ich das wieder zum Laufen bekommen kann?


Gruß Manuel
FHEM 6 auf RaspPi V3:
HM_LAN / CUNX / HUEBridge /OneWire / Homebridge / SONOS / Harmony

Petrosilius Zwackelmann

Zitat von: Petrosilius Zwackelmann am 23 November 2025, 15:07:39Seit einigen Tagen zeigt meine zuvor laufende SolarForecast Konfiguration nur noch folgende Meldung.
ZitatHerzlich Willkommen!
Die nächsten Abfragen führen sie durch die Grundinstallation.
Sind alle Eingaben vorgenommen, prüfen sie bitte die Konfiguration abschließend mit "set SolarForecast plantConfiguration check" oder mit Druck auf das angebotene Icon.
Korrigieren sie bitte eventuelle Fehler und beachten sie mögliche Hinweise.
(Die Anzeigesprache kann mit dem Attribut "ctrlLanguage" umgestellt werden.)
SolarForecast wartet auf Solarvorhersagedaten ...

Ein
Zitatset SolarForecast plantConfiguration check
bescheinigt eine funktionierende Konfiguration.
ZitatHerzlichen Glückwunsch 😊, die Anlagenkonfiguration ist fehlerfrei.

Man könnte annehmen, dass ein Problem mit dem Wetterdaten vorliegt - ein get Solarforecast weatherApiData
Liefert aber sofort Werte.
ZitatOpenMeteo => fc0_0 => StartTime: 2025-11-15 00:00:00
                      rr1c: 0
             fc0_1 => StartTime: 2025-11-15 01:00:00
                      UpdateTime: 2025-11-15 01:45:52
                      don: 0
                      neff: 98
                      rr1c: 0
                      ttt: 9.1
                      ww: 3
             fc0_10 => StartTime: 2025-11-15 10:00:00
                       UpdateTime: 2025-11-15 10:49:17
                       don: 1
                       neff: 100
                       rr1c: 0
                       ttt: 11.6
                       ww: 3


Es fällt auf dass meine etliche FC Readings nicht mehr aktualisiert werden.
ZitatBattery_NextHour00_SoCforecast_01 59.0 % 2025-11-20 00:38:32
Battery_NextHour01_SoCforecast_01 57.7 % 2025-11-20 00:38:32
Battery_NextHour02_SoCforecast_01 56.6 % 2025-11-20 00:38:32
Battery_NextHour03_SoCforecast_01 48.8 %

Hat jemand einen Hinweis wie ich das wieder zum Laufen bekommen kann?



Gruß Manuel
FHEM 6 auf RaspPi V3:
HM_LAN / CUNX / HUEBridge /OneWire / Homebridge / SONOS / Harmony

Petrosilius Zwackelmann

Problem ist gelöst:
Es lag wohl an einigen Modulen welche auf meinem Raspberry nach Umzug nicht installiert waren.
LWP::UserAgent
DateTime
HTTP::Request

nun läuft alles wieder. 
FHEM 6 auf RaspPi V3:
HM_LAN / CUNX / HUEBridge /OneWire / Homebridge / SONOS / Harmony

Max_Meyer

Zitat von: DS_Starter am 14 November 2025, 16:48:10Für einen Consumertyp "HeatPump" könnte sich jemand ähnliche Gedanken machen wegen möglicher Besonderheiten

Hallo Heiko,
habe zum o.g. Topic mal meine Ideen und Erfahrungen aus 5 Jahren  WP-PV-Kopplung zusammengeschrieben. Ist ein langer Text geworden - daher hab ich hier das Word (auch als PDF) reingehangen - da ist das ganze Konzept (aus meiner Sicht übersichtlich gegliedert) beschrieben. Obwohl das relativ viel Text geworden ist bleibt es für SF übersichtlich - glaube ich wenigstens. Unbedingt notwendig ist der prognostizierte 24h Energiebedarf der WP. Der meiste Inhalt entstand aus der Beschreibung des Warum.
Bei Fragen bitte melden.
@all
Anmerkungen, Ergänzungen bzw. andere Ideen gerne beitragen
Gruß Gerd
FHEM: PI3...5 FB7590/7530/EnOcean/FS20 /Revolt/FHEM2FHEM/HTTPMOD-->Solmaxx-, Deye-, Bosswerk-Inverter/ModBusTCP -->SMA-Inverter, GoE-Charger, BröntjeWP/Solarforecast/DbLog/DbRep/PostgreSQLDB/Grafana/MQTT-->Shelly,FHEM,HMS/HCCON/Netatmo/KLF etc.

DS_Starter

Hallo Gerd,

vielen Dank. Ich habe mir einen Link zu diesem Post gelegt für später.

Zur Info ...
momentan bin ich stark mit dem Aufbau einer KI (neuronales Netz) für die Verbrauchsprognose beschäftigt.
Die ersten Tests laufen bereits und sehen schon ziemlich vielversprechend aus. Viel hängt auch von den Netzparametern ab und ich probiere etliche Einstellungen aus. Das ist eine ganz neue Welt für mich.
Sobald ich der Meinung bin einen gewissen Reifegrad erreicht zu haben stelle ich diese Version für interessierte Mitstreiter zur Verfügung.
Sobald das gut läuft und Prognosen für Häuser mit WP / EV brauchbar sind, kann man darauf aufbauen.

Grüße,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

ch.eick

Zitat von: Max_Meyer am 26 November 2025, 08:43:41Hallo Heiko,
habe zum o.g. Topic mal meine Ideen und Erfahrungen aus 5 Jahren  WP-PV-Kopplung zusammengeschrieben. Ist ein langer Text geworden - daher hab ich hier das Word (auch als PDF) reingehangen - da ist das ganze Konzept (aus meiner Sicht übersichtlich gegliedert) beschrieben. Obwohl das relativ viel Text geworden ist bleibt es für SF übersichtlich - glaube ich wenigstens. Unbedingt notwendig ist der prognostizierte 24h Energiebedarf der WP. Der meiste Inhalt entstand aus der Beschreibung des Warum.
Bei Fragen bitte melden.
@all
Anmerkungen, Ergänzungen bzw. andere Ideen gerne beitragen
Hallo Gerd,
ich habe da erstmal eine Frage zur WP, ist es bei Dir normal, dass die so oft Taktet? Ich zähle da bei Deinem Beispiel ca. 17 mal.
Bei mir komme ich an kalten Tagen auf ca. 6 mal, inklusive WW für einen zwei Personen Haushalt.

Da ich noch eine zyklische WP habe wurde das durch mich am Anfang optimiert, um weniger Einschaltungen, dafür aber einen etwas längeren Lauf zu haben.
Tagsüber mache ich eine Temperatur Anhebung um 4K, um das Gebäude stärker zu heizen. In der Nacht senke ich um 8K ab und schalte sogar die Heizung noch
zusätzlich aus, wenn es nicht zu kalt ist. Das sind alles grundlegende Optimierungen bevor dann die Prognose und andere Dinge dazu kommen.

VG  Christian

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Max_Meyer

Zitat von: ch.eick am 26 November 2025, 14:17:33ch habe da erstmal eine Frage zur WP, ist es bei Dir normal, dass die so oft Taktet? Ich zähle da bei Deinem Beispiel ca. 17 mal.
Bei mir komme ich an kalten Tagen auf ca. 6 mal, inklusive WW für einen zwei Personen Haushalt.

Hallo Christian,
ja-das ist den baulichen und örtlichen Umständen zuzuschreiben - ein EFH WSVO 95 hält eben die Wärme nicht wie ein EFH WSVO 55 oder neuer. Und hier kann es es eben bis unter -20°C werden (2-3x im Winter regelmäßig) - darauf ist die WP ausgelegt - der abgebildete Tag hatte ein Temperaurspektrum von -7°C bis -10°C - die von dir beschrieben 'Grundoptimierung' habe ich mit einem Offset von 5K und diversen Schedulern abgebildet - das führt i.d.R. dazu das nachts ab 19:00 Uhr die WP nicht mehr anspringt wobei die Tageszeit bei einer Sole-Wasser-Anlage eigentlich irrelevant ist.
Aber ja du hast Recht die Taktung ist ungünstig - würde ich noch einmal WP neu starten würde ich vermutlich zwei 6KW-WP anstatt einer 12KW einbauen lassen.
Der einzige Vorteil der Taktung ist, das dadurch der COP höher wird - lange WP-Laufzeiten bewirken ein Absinken der Quellentemperatur um 2-3K - durch ca. 20 min Pause ist das wieder auf Norm 8-10°C - das Absinken reduziert den COP um ca. 1. Im Großen und Ganzen bin ich der Meinung mit den den baulichen und örtlichen Gegebenheiten ein gewisses Optimum gefunden zu haben. SCOP etwa 5.
Forecast will ich dazu verwenden die WP (stromgesteuert) über die Zeit mit PV-Angebot laufen zu lassen und die Wärme zu puffern.
Gruß Gerd 
FHEM: PI3...5 FB7590/7530/EnOcean/FS20 /Revolt/FHEM2FHEM/HTTPMOD-->Solmaxx-, Deye-, Bosswerk-Inverter/ModBusTCP -->SMA-Inverter, GoE-Charger, BröntjeWP/Solarforecast/DbLog/DbRep/PostgreSQLDB/Grafana/MQTT-->Shelly,FHEM,HMS/HCCON/Netatmo/KLF etc.

TheTrumpeter

Ich habe auch eine Wärmepumpe in Kombination mit einem sehr gut isolierten Haus mit hoher Speichermasse. Meine Wärmepumpe kann ebenfalls nicht modulieren, d.h. verbraucht immer (in erster Näherung) gleich viel Strom.
Mit dem Tag-/Nachtprogramm habe ich eine prinzipielle Vorgabe realisiert, um den Verbrauch überwiegend in die Tagstunden zu legen. Dazu ist die Tag-Soll-Temperatur um 0.5K über und die Nacht-Soll-Temperatur 1.5K unter der gewünschten Temperatur. Das führt dazu, dass im Normalfall erst zwischen 08:45 und 09:30 zu heizen begonnen wird. Die WP läuft dann solange bis die erforderliche Wärmemenge eingebracht ist und springt danach am gleichen Tag nicht mehr an. (Um 08:45 wird auf das Tagprogramm umgeschaltet. Selbst am kürzesten Tag des Jahres ist - sofern wolkenlos - dann ausreichend PV-Leistung vorhanden, um die Wärmepumpe damit zu betreiben.)

Mein Hauptproblem bzgl. PV-optimierter Steuerung liegt in der Übergangszeit bzw. an eher warmen oder sonnig-kalten Tagen, weil dann die nötige Laufzeit deutlich kleiner als die Anzahl der möglichen Sonnenstunden ist oder der Start schon vor 09:00 erfolgen sollte.
Derzeit schaltet sich die Wärmepumpe  mittels Tagprogramm wie gesagt um ca. 09:00 ein an eher warmen Tagen nach 2-3 h schon wieder aus. Wenn es bis Mittag nebelig ist, wäre es besser erst später einzuschalten.
Umgekehrt wäre es an sehr kurzen Tagen mit nötiger Laufzeit > der Sonnenstunden sinnvoll, schon vor 08:45 einzuschalten, um einen etwaigen Überschuss davor "auch noch mitzunehmen". (Ich habe keine Batterie.)


Für mich gibt es also 2 Herausforderungen:
  • Voraussichtliche Laufzeit der Wärmepumpe vorhersagen. Das könnte ich mit ein bisschen Code in einem User-Modul problemlos abbilden. Dazu würde ich einfach abhängig der (prognostizierten) Außentemperatur und/oder Sonnenscheindauer die Laufzeit ermitteln.
  • Steuerung durch SF
    • Die voraussichtliche Laufzeit könnte ich dem Consumer in SF als "mintime" füttern sowie "not-before" und "not-after" so setzen, dass die Einplanung sinnvoll erfolgt. (not-after gibt soweit ich weiß den spätestmöglichen Startzeitpunkt an, d.h. ich müsste verhindern, dass bei 3h Laufzeit nicht erst um 15:00 eingeplant wird.)
    • Die Wärmepumpe würde ich dann permanent im "Nachtprogramm" laufen lassen & mittels SF auf das "Tagprogramm" umschalten.
    • Beenden würde ich nicht über SF machen, sondern extern. Sobald die Wärmepumpe abschaltet, schalte ich wieder auf "Nachtprogramm". (Für die WW-Bereitung mache ich das ähnlich. Da wird auch über SF ein- aber extern ausgeschaltet.)


Warum habe ich das bisher noch nicht gemacht?
Die Wärmepumpe ist aktuell so konfiguriert, dass sie auch ohne FHEM halbwegs sinnvoll funktioniert, d.h. es gibt
  • ein WW-Programm, das am Nachmittag für die WW-Bereitung sorgt, falls es nicht davor schon durch SF erfolgt ist.
  • ein Heizprogramm, das tagsüber sicher für Wärmeeintrag sorgt.
Ich habe noch keine Idee, wie ich trotz SF-Steuerung eine "Rückfallebene" sicherstellen kann, drum habe ich bisher davon die Finger gelassen, ihr wisst schon, WAF und so...
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Max_Meyer

Zitat von: TheTrumpeter am 27 November 2025, 08:06:07Ich habe noch keine Idee, wie ich trotz SF-Steuerung eine "Rückfallebene" sicherstellen kann, drum habe ich bisher davon die Finger gelassen, ihr wisst schon, WAF und so...
Hallo  TheTrumpeter,
Die Idee eine WP mit SF prognosebasiert zu steuern basiert auf der Annahme dass man wenn man den prognostizierten 24h-WP-Energiebedarf kennt, diesen möglichst punktgenau mit PV erzeugen kann.  Da der PV-Überschuss im Laufe des Tages unterschiedlich ist könnte man jeweils stundenweise diesen Überschuss an die WP weitergeben.Bei modulierenden Anlagen Watt-genau (ähnlich Batterieladen) bei wärmegeführter Steuerung (d.h. die WP-Steuerung ist führend) bekommt die WP 'nur' ein Angebot an Leistung ob das angenommen wird entscheidet die WP - ein Rückfall muss hier nicht betrachtet werden- wird kein Angebot geliefert arbeitet die WP autark. Bei unmodulierenden Anlagen z.B. mit SG-READY Funktion würde ich den Rückfall mittels Relais sicherstellen, das stromlos 'Fernsteuerung AUS' signalisiert.
Ob sich der Aufwand lohnt muss jeder für sich entscheiden, im Winter sieht es mit der möglichen PV-Unterstüzung eher mau aus.

Gruß Gerd
FHEM: PI3...5 FB7590/7530/EnOcean/FS20 /Revolt/FHEM2FHEM/HTTPMOD-->Solmaxx-, Deye-, Bosswerk-Inverter/ModBusTCP -->SMA-Inverter, GoE-Charger, BröntjeWP/Solarforecast/DbLog/DbRep/PostgreSQLDB/Grafana/MQTT-->Shelly,FHEM,HMS/HCCON/Netatmo/KLF etc.

ch.eick

Hallo zusammen,
um den angesprochenen WAF zu optimieren läuft meine WP bereits ohne FHEM ziemlich optimal in einem Fenster von 10-16 Uhr mit der angesprochenen Tagesanhebung/Nachtabsenkung.
Das Haus ist sehr gut gedämmt und zusätzlich eine KWL (ohne Heizung). Die letzten Prozente der Optimierung habe ich dann noch mit FHEM herausgeholt, indem ich die nächtlichen WP Einschaltungen durch abschalten der Heizung in der WP erreiche. nur wenn es sehr kalt wird schalte ich bereits früh am Morgen die Heizung ein, dann ist der Wärmepuffer auch so gerade eben bei der Nachtabsenkung und muss wieder geladen werden.
Damit spart man sich die ganze Energiekalkulation und den Abgleich mit SF. Die Trefferquote für PV ist sehr hoch.
Der PV-Modus mit dem Überheizen und WW mit 60°C wird nur verwendet, wenn es heute Überschuss gibt und es morgen zuwenig PV gibt. Über eine Fernbedienung (von den Schweden) kann meine Frau den PV-Modus mit 45 Minuten Vorlauf selber noch starten um heißes Putzwasser zu bekommen. Wenn die Kiddies kommen ist das auch praktisch für die Dauerduscher.

Ohne SF lief die WP heute mit WW von 10-13 Uhr und von 13:30-14:30 Uhr, da die Außentemperatur bei 7° liegt.

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

TheTrumpeter

Zitat von: Max_Meyer am 27 November 2025, 09:07:16Bei unmodulierenden Anlagen z.B. mit SG-READY Funktion würde ich den Rückfall mittels Relais sicherstellen, das stromlos 'Fernsteuerung AUS' signalisiert.
So einfach ist das nicht.
"Stromlos" wäre das Relais nur dann, wenn beispielsweise FHEM "geordnet runtergefahren" wird oder der RasPi stromlos wird. Es sind natürlich auch Szenarien denkbar, wo sowas nicht greift.

Abgesehen davon will ich ja nicht beliebig takten. Meine WP schaltet sich typischerweise 1x am Tag ein, daran will ich eher nichts ändern, weil es ohnehin kaum was bringen würde.
Wie gesagt, den Zeitbedarf vorzugeben ist nicht das Problem, aber eine automatische (Rück-) Umschaltung auf den "normalen" Betriebspunkt kann ich nicht sicherstellen. Das wäre für mich die Rückfallebene.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110