FHEMWiki - Benutzerbeiträge [de]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2025-11-10T16:45:33Z

All-Ex: /* PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) */

{{Baustelle}}
{{Hinweis|Die vorliegende Wiki-Seite befindet sich im Aufbau.}}
{{Infobox Modul
|ModPurpose=Solarprognose und Verbrauchersteuerung
|ModType=d
|ModCmdRef=76_SolarForecast
|ModFTopic=117864
|ModForumArea=Solaranlagen
|ModTechName=76_SolarForecast.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
[[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung|SolarForecast]] ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:
[[Datei:sfc1.png|right|thumb|300px|grafische Ansicht SolarForecast]]

::* zur Gewinnung solarer Prognosewerte können die SolCast API, OpenMeteo API, Forecast.Solar API, Victron VRM Portal API oder alternativ DWD Stahlungswerte-Stationen verwendet werden

::* optionale KI Unterstützung der PV-Prognose bei Verwendung von geeigneten Solar-API's

::* es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose sowie SoC Prognose (bei Batterie-Integration) erstellt

::* Wetterdaten werden über DWD Wetter-Stationen oder verschiedene API integriert. Es können verschiedene API zur Gewinnung von Solar- und Wetterdaten kombiniert werden.

::* Sprachensupport EN / DE

::* die Prognosedaten, Wetterdaten, Verbraucherplanungen und die aktuellen Energieflüsse werden in umfangreich anpassbaren integrierten Grafiken dargestellt

::* es wird keine externe SQL-Datenbank benötigt, die Datenhaltung erfolgt in einer Memory basierten Cachedatenbank inkl. einer Filesystempersistenz zur Datensicherung und Wiederherstellung beim FHEM-Restart

::* die Integration von Geräten wie Wechselrichter, Energy Meter, Batterien, Wetterstationen oder Verbrauchern ist offen und universell gestaltet und bietet dem Anwender maximale Freiheiten bei der Einrichtung seines individuellen Solardatensystems.

::* eine Integration von bis zu 4 Inverter und Smartloader (DC-DC Batterieladegeräte) ist möglich

::* eine Integration von bis zu 3 nicht PV-Energieerzeugern wie BHKW, Windrädern oder Notstromaggregaten ist möglich

::* eine integrierte und umfangreich anpassbare Verbrauchersteuerung vereint die PV Prognose basierte Einplanung der Verbraucher mit der Möglichkeit die Verbraucher durch das Modul schalten zu lassen und dadurch auf PV Erzeugungsschwankungen automatisch dynamisch zu reagieren

::* Einbindung von bis zu drei Batteriespeichersystemen

::* Bereitstellung von Leitwerten zur optimalen Einstellung/Steuerung von Batteriespeichersystemen

::* trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzererlebnis geboten

'''Abgrenzung:''' Das Modul 76_SolarForecast ist nicht zu verwechseln mit der SQL-basierten (DbLog) Prognose-Lösung mit Kostal Plenticore Wechselrichtern, die auf der eigenen Seite '''[[Kostal_Plenticore_10_Plus]]''' behandelt wird. Diese Lösung beschreibt kein monolithisches Modul, sondern basiert auf einer orchestrierbaren Zusammenstellung individueller Perl Programmbausteine.

Im vorliegenden Wiki-Beitrag wird ausschließlich das Modul 76_SolarForecast behandelt.

== Rahmenbedingungen und Voraussetzungen ==

Das Wiki gibt allgemeingültige und teilweise sehr spezifische bzw. tiefgehende Informationen und Handlungsempfehlungen zum SolarForecast Modul. Die dargestellten Informationen beziehen sich auf den zum Zeitpunkt der Wiki-Erstellung vorhandenen Entwicklungsstand des Moduls. Durch die stetige Weiterentwicklung können sich Abweichungen zum beschriebenen Inhalt ergeben oder zur Obsoleszenz dieser Inhalte führen.

Vergleiche deshalb die Informationen immer mit der aktuellen Befehls-Referenz zum Modul!

== Definition ==
Ein SolarForecast Device wird mit dem Befehl

define <Name> SolarForecast

angelegt. Nach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert. Alle Attribute und Readings die eine Einstellung der Anlage bewirken, sind mit dem Präfix "setup" versehen.

Die Verwendung von setup-Readings gestattet es die Anlagenparameter dynamisch im Betrieb zu verändern. So kann mit

set <Name> setupStringAzimuth bzw.
set <Name> setupStringDeclination

die Ausrichtung und der Neigungswinkel der PV-Module ständig angepasst werden, was zum Beispiel bei einer dem Sonnenstand nachgeführten Anlage von Bedeutung ist.

Die abgefragten Einstellungen während des Dialoges sind ausführlich in den entsprechenden Attributen bzw. Set-Kommandos erläutert. Die benötigten Informationen sind anhängig von der gewählten Prognose-API und können im Umfang variieren.

[[Datei:Screenshot 2024-09-21 213257.png|right|thumb|400px|Anlagenprüfung über Drucktaste in der Kopfgrafik]]

Sobald alle verlangten Einstellungen vorgenommen sind, sollte eine Anlagenprüfung mit

set <Name> plantConfiguration check

oder über die angebotene Drucktaste in der Grafik durchgeführt werden. Es wird eine Plausibilitätsprüfung vorgenommen und das Ergebnis sowie eventuelle Hinweise bzw. Fehler ausgegeben.
Die Prüfung kann beliebig wiederholt werden und sollte sich bei jeder Einstellungsänderung der Anlage durchgeführt werden. Dadurch wird die Wahrscheinlichkeit von fehlerhaften Einstellungen minimiert.

Neben den grundlegenden Einstellungen können im Device weitere sekundäre Anlagenkomponenten wie Batteriesystem(e) (Attribut setupBatteryDev1 - setupBatteryDev3), weitere Wetter-Devices (Attribut setupWeatherDev1 - setupWeatherDev3) oder sonstige Erzeuger (z.B. BHKW, Winderzeugung, Notstromaggregat) integriert werden (Attribut setupOtherProducer01 - setupOtherProducer03).

Die verlangten Parameter der Anlage werden in der Online-Hilfe umfassend beschrieben und deren Funktion erschließt sich zum größten Teil selbst. Dennoch soll nachfolgend auf einige Punkte im Zusammenhang der Einrichtung eingegangen werden.

 
=== Hinweise zur Struktur der Attribute ===

Durch die umfangreichen Funktionen des Moduls würde bei Nutzung der im FHEM herkömmlich vorhandenen Attributstruktur die Anzahl der benötigten Attribute extrem stark steigen und nicht sinnvoll genutzt werden können. Deshalb gibt es neben den ''gewöhnlichen'' Attributen mit einfachen Werteauswahlmöglichkeiten oder Eingaben (z.B. ctrlDebug, ctrlSpecialReadings) sogenannte ''zusammengesetzte'' Attribute, deren Inhalt durch '''Schlüssel=Wert Paare''' gebildet wird und dadurch deutlich mehr Funktionen und Informationen transportieren als ein gewöhnliches Attribut.

Für zusammengesetzte Attribute besteht die zusätzliche Möglichkeit, gewünschte Änderungen der Schlüssel=Wert Paare selektiv vornehmen zu können, ohne das gesamte Attribut aufrufen und ändern zu müssen. Die Vorgang, der vor allem für programmtechnische Manipulationen gedacht ist, kann durch eine Set-Funktion ausgeführt werden:

set <Name> attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

Die Funktionen der Attribute werden durch einen Präfix geclustert und so inhaltlich, aber vor allem auch in der Attribute Drop-Down Liste, strukturiert dargestellt.

Die Bedeutung der '''Präfixe''' sind:

* '''ai''' - Steuerungsfunktionen für KI (z.B. aiControl)
* '''consumer''' - Registrierung und Einstellungen für Verbraucher (z.B. consumer02, consumerControl)
* '''ctrl''' - Steuerungsfunktion allgemeiner Art (z.B. ctrlDebug, ctrlSpecialReadings, ctrlUserExitFn)
* '''flowGraphic''' - Einstellungen für die Energieflußgrafik (z.B. flowGraphicControl)
* '''graphic''' - Einstellung für die Grafik allgemein (z.B. graphicSelect, graphicControl)
* '''graphicBeam''' - Einstellungen bestimmte Balkeneigenschaften in der Balkengrafik (z.B. graphicBeamHeightLevel1)
* '''plant''' - übergreifende Einstellungen betreffend der gesamten PV-Anlage bzw. des SolarForecast-Devices (z.B. plantControl)
* '''setup''' - Registrierung von Geräten in der Gesamtanlage und Einstellung deren Eigenschaften (Inverter, Zähler, Batterien usw.)

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

Mit den Attributen setupInverterDev01 bis setupInverterDevXX werden die vorhandenen Wechselrichter der Anlage registriert.
Das Modul unterscheidet verschiedene Wechselrichter-Typen, die sich durch ihre Arbeitsweise innerhalb der Anlage unterscheiden. Die Schlüssel=Wert Paare in den Attributen können mehrzeilig organisiert werden. Das erleichtert die Übersicht wenn viele dieser Parameter eingegeben werden.

;PV-Wechselrichter: Es ist der Standard Wechselrichter in einer PV-Anlage. An ihn sind die Solarzellen bzw. Strings angeschlossen. Die zugeordneten Strings können mit dem Schlüssel '''strings''' zugeordnet werden. Ohne diese Angabe werden diesem Gerät alle definierten Strings (siehe Attribut ''setupInverterStrings'') zugeordnet. Der Wechselrichter liefert seine Energie in das Hausnetz. Alternativ kann mit der Angabe '''feed=grid''' die Funktion des Wechselrichters geändert werden. Diese Angabe sagt aus, dass dieser Wechselrichter ausschließlich in das öffentliche Netz einspeist.

Hier ein Beispiel-Setup eines PV-Wechselrichters (SMA STP):

STP_5000 pvIn=string_1_pdc:kW pvOut=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100

;Solar-Ladegeräte: Solar-Ladegeräte sind DC-DC Wandler und liefern die Energie der angeschlossenen Solarzellen nicht in das Wechselstromnetz, sondern laden direkt eine Batterie bzw. versorgen einen Batteriewechselrichter auf der Gleichstromseite. Die Funktion als Solar-Ladegerät wird mit '''feed=bat''' aktiviert, die relevanten Strings können ebenfalls mit dem Schlüssel '''strings''' zugeordnet werden. Ein Beispiel eines Solar-Ladegerätes ist ein Victron SmartSolar MPPT.

Ein Beispiel für das Setup eines Solar-Ladegeräts (SmartSolar Charger MPPT):

MQTT2_cerboGX_c0619ab34e08_solarcharger_Common pv=Yield_Power_value:W etotal=Yield_System_value:kWh capacity=2080 strings=Schleppdach feed=bat synchron=0 limit=100

;Batterie-Wechselrichter: Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer Batterie (=Gleichstromquelle) und dem Wechselstrom-Hausnetz. Die Funktion als Batterie-Wechselrichter wird mit der Angabe '''strings=none''' aktiviert. Die Schlüssel ''etotal'' und ''pv'' können bei einem Batterie-Wechselrichter ohne zugeordnete Solarzellen nicht gesetzt werden. Ein Beispiel eines Batterie-Wechselrichter ist der Victron MultiPlus II.

Ein Setup-Beispiel für einen Batterie-Wechselrichter (Victron MultiPlus II):

<pre>
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
icon=inverter@darkorange:inverter@grey
asynchron=0
</pre>

Die Eigenschaften des Wechselrichters werden durch eine Reihe von <Schlüssel=Wert> Paaren festgelegt. Auf einige dieser Paramter soll hier eingegangen werden.

 
==== Ausgewählte Schlüssel=Wert Paare ====

 
* '''pvIn=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvIn'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell zugeführte PV-Leistung bereitstellt. Der Schlüssel ist optional und dient in erster Linie dazu den entsprechenden Input-Wert in der Flußgrafik anzuzeigen sofern man das Attribut flowGraphicControl->showGenerators=1 setzt. Dadurch ist auch der Eigenverbrauch des Inverters bzw. dessen Wandlungsverlust visuell abschätzbar.

* '''pvOut=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvOut'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell erzeugte Leistung als positiven Wert liefert. Für einen PV-Wechselrichter (DC->AC) oder Solar-Ladegerät (DC->DC) ist es die erzeugte PV-Leistung.

* '''ac2dc=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter vom Hausnetz in Richtung Batterie (AC->DC) wandelt.

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 
==== Definition von Hybrid-Wechselrichtern ====

Zur Zeit der Erstellung dieses Abschnittes ist es in der SolarForecast Version 1.58.x nicht möglich, einen Hybridwechselrichter nativ zu definieren. Als Workaround wird eine passende Kombination aus PV-Wechselrichter und Batterie-Device oder einer Kombination aus PV-Wechselrichter + Batterie-Wechselrichter und Batterie-Device erstellt.

Bei allen benutzten Methoden ist es sehr wichtig!, dass die geforderten Inhalte der jeweilige Attributschlüssel beachtet und eingehalten werden. So ist zum Beispiel die Angabe von:

* '''pvOut''' - Ein Reading, welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz oder öffentliche Netz geliefert wird, bereitstellt. Es wird ein positiver numerischer Wert erwartet.

bei einem PV-Wechselrichter ein Reading welches ausschließlich die Leistung liefert, die von den Solarzellen-Generatoren erzeugt wird. Elemente von Batterieleistungen oder Gridbestandteile dürfen hier nicht enthalten sein. Sind in den Gerätemodulen diese Readings in dieser Form nicht enthalten, bietet es sich an, userReadings zur Erstellung von zusätzlichen Readings in den Quellendevices zu nutzen um den nötigen Input für SolarForecast bereitzustellen.

So wird zum Beispiel bei einem Batterie-Wechselrichter gefordert, dass die Readings '''ac2dc''' (AC->DC-Leistung Hausnetz zur Batterie) und '''dc2ac''' (DC->AC-Leistung (Batterie zum Hausnetz) '''jeweils als als positiver Wert''' anzugeben ist. Manche Batterie-Devices stellen allerdings nur ein Reading zur Verfügung, welches vorzeichenbehaftet die Leistungen in die Batterie bzw. aus der Batterie heraus liefert. Mit einem userReadings Attribut kann aus diesem Reading zwei neue Readings erzeugt werden:

<pre>
attr <Name> userReadings BatIn:DC_Power_value.* {
my $pwr = ReadingsVal ($name, 'DC_Power_value', 0);
$pwr = $pwr > 0 ? $pwr : 0;
$pwr
},
BatOut:DC_Power_value.* {
my $pwr = ReadingsVal ($name, 'DC_Power_value', 0);
$pwr = $pwr < 0 ? - $pwr : 0;
$pwr
},
</pre>

Ist das Quellenreading ''DC_Power_value'' positiv, stellt der Wert AC->DC-Leistung dar und wird als neues Reading BatIn bereitgestellt. Mit einem negativen Vorzeichen ist es eine DC->AC-Leistung und wird in dem neuen Reading BatOut '''ebenfalls als positiver Wert''' bereitgestellt. Auch hier gilt der Grundsatz, dass zum Beispiel BatOut nur die von der Batterie gelieferte Energie und keinen Mix aus Batterie- und PV-Energie enthalten darf.

===== Integration eines DEYE SUN-12K-SG04LP3-EU =====

[[Datei:Screenshot 2025-09-23 203955.png|right|thumb|400px|DEYE SUN-12K-SG04LP3-EU Grundlegende Systemarchitektur]]

Der DEYE vereint wie wohl alle bzw. die meisten Hybrid-Wechselrichter die Anschlüsse:

* Eingang Solar-Strings
* Anschluß Batteriespeicher
* AC-Anschluß öffnetliches Netz
* AC-Anschluß Ersatzlast (wird bei Netzausfall weiter versorgt)
* AC-Anschluß Notstromgenerator bzw. netzgekoppelter anderer Wechselrichter (hier ist ein Growatt Micro-Wechselrichter angeschlossen)

Für die Integration werden die setup-Attribute durch das FHEM Device ''Deye_Inverter'' besetzt:

* setupInverterStrings zur Definition der vorhandenen Solarstrings
* setupInverterDev01 zur Definition der Inverteranschlüsse und Eigenschaften
* setupBatteryDev01 integriert die Batterie
* setupMeterDev liefert die Daten für Netzbezug und Netzeinspeisung

Das nachfolgend verwendete Device ''Deye_Inverter'' ist ein MQTT-Device. Es bekommt Daten vom Deye-Hybridwechselrichter per MQTT und sendet Einstellungen zum Deye, bspw. maximaler Lade/Entladestrom des Akkus, Laden des Akkus aus dem Netz, Ein- und Ausschalten des Micro-Inverter-Ports.
Das Reading ''Deye_Growatt_power'' im Schlüssel ''pvOut'' ist eine Addition aus den Daten des Deye WR und des angeschlossenen Growatt Micro-Wechselrichters.

<pre>
attr <Name> setupInverterStrings Sueddach,Garagendach
attr <Name> setupInverterDev01 Deye_Inverter pvOut=Deye_Growatt_power:W capacity=15200 etotal=total_pv_production:kWh
attr <Name> setupBatteryDev01 Deye_Inverter pin=-pout pout=battery_output_power:W intotal=total_charge_of_the_battery:kWh outtotal=total_discharge_of_the_battery:kWh cap=15200 charge=SOC_jkbms
attr <Name> setupMeterDev Deye_Inverter gcon=total_grid_power:W contotal=total_energy_bought:kWh gfeedin=-gcon feedtotal=total_energy_sold:kWh
</pre>

''setupInverterStrings'' benennt alle vorhandenen Solarstrings. Werden mehrere Inverter definiert, kann mit dem hier nicht verwendeten Schlüssel ''strings'' eine Zuordnung der Strings zum angeschlossenen Inverter vorgenommen werden.

Im Attribut ''setupInverterDev01'' ist der allgemeine Schlüssel ''capacity'' zur Festlegung der Inverterleistung von 15200 Watt gesetzt. Die spezifischen Schlüssel ''pvOut'' und ''etotal'' teilen dem Modul die aktuell erzeugte PV-Leistung sowie die gesamte erzeugte PV-Energie mit. Letzteres dient unter anderem dazu die stündlich real erzeugte PV-Energie festzuhalten und mit der Prognose zu vergleichen. Die in den schlüsseln hinterlegten dürfen keine Battrie- oder Netzanteile enthalten.

Das Attr ''setupBatteryDev01'' implementiert alle relevanten Batteriewerte. Das Reading ''battery_output_power'' im Schlüssel ''pout'' liefert den Batterie-Output als positiven Wert. Als Besonderheit kann der Wert ''pin'', die Batterie-Ladeleistung, den Wert des Readings in ''pout'' übernehmen wenn dieser Wert ein negatives Vorzeichen hat. Die Schlüssel ''intotal'' und ''outtotal'' liefern die summierten Totalwerte für Batterie Ladung bzw. Entladung. Die Kapazität ''cap'' wird für verschiedene Aspekte der SoC- und Ladesteuerung verwendet.

Abschließend liefern die angebenen Readings in den Schlüsseln des Attributes ''setupMeterDev'' alle notwendigen Werte des Netzbezugs und der Netzeinspeisung.

Nachfolgende Links liefern '''weitere Infos''' wie man Daten aus dem Deye WR ausliest und Einstellungen des Deye WR verändert:

* https://github.com/klatremis/esphome-for-deye
* https://github.com/philipphenkel/esphome-config
* https://github.com/bagges/deye-esp32-bridge

Für eine weiterführende Automation soll der Akku netzdienlich in der Mittagszeit geladen werden. Dazu wurde durch den Anwender folgendes userReadings ''MaxBattCharge_Request'' im Device ''Deye_Inverter'' für den maximalen Ladestrom definiert (bei 90% SOC und bei 100% SOC):

<pre>
MaxBattCharge_Request:SOC_jkbms.* {
if ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) < 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') < 561600)
{100}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) < 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') >= 561600)
{100}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) >= 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') < 561600)
{ceil ((90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310/3.5)}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) >= 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') >= 561600)
{ceil ((100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310/3.0)}
}
</pre>

Das userReading wird in einer Automation benutzt, um den maximalen Ladestrom einzustellen; Ladebeginn bei ausreichend Sonne ist ab 11:30 eingestellt.

 
===== Integration eines Fronius Symo GEN24 10.0 Plus mit (virtuellen) Batterie-Wechselrichter =====

[[Datei:Screenshot 2025-10-04 162422.png|right|thumb|400px|Flußgrafik mit eingebauten Hybrid-Wechselrichter]]

Die Integration des Wechselrichters Fronius Symo GEN24 10.0 Plus benötigt zunächst eine Anbindung in FHEM, was mit dem Modul 98_fronius.pm vorgenommen wurde.

Das Ziel der Kurzdokumentation ist neben der Darstellung eines Hybridwechselrichters aufzuzeigen, wie man den Wandlungsverlust eines PV-Wechselrichters (pvIn – pvOut) in Näherung visualisieren kann.
'''pvIn''' ist dabei die Summe der Produkte aus den DC Strom- und Spannungswerten der einzelnen Strings (hier 2109 W), '''pvOut''' (hier 2065 W) ist die an den Inverterknoten (hier 1105 W) plus die an die Batterie abgegebene Leistung (hier 960 W). Bei dieser Implementierung wird mit einem zusätzlichen (virtuellen) Batterie-Wechselrichter gearbeitet.

In Vorbereitung werden die beiden anzugebenden Readings ''<pvIn>'' und ''<pvOut>'' zum Beispiel als userReadings erstellt, wobei '<pvIn>'' und ''<pvOut>'' natürlich durch Readingnamen ersetzt werden müssen. Diese beiden Readings werden wie folgt berechnet / erstellt:

<pre>
<pvOut> = Inverter_Common_PAC_Value - PowerFlow_Site_P_Akku
<pvIn> = Inverter_Common_IDC_Value * Inverter_Common_UDC_Value + Inverter_Common_IDC_2_Value * Inverter_Common_UDC_2_Value
</pre>

Der '''PV-Wechselrichter''' wird mit dem Attribut setupInverterDev01 definiert, wobei die angelegten Readingnamen in den Schlüsseln ''pvIn'' bzw. ''pvOut'' verwendet werden:

<pre>
SymGen24 icon=inverter@#ff8c00:inverter@grey capacity=10000 strings=suedwest,nordost etotal=User_Produced_PV:kWh pvOut=<pvOut>:W pvIn=<pvIn>:W
</pre>

Dem PV-Wechselrichter sind die Strings ''suedwest'' und ''nordost'' zugewiesen.

Der zusätzliche '''Batterie-Wechselrichter''' wird mit dem Attribut setupInverterDev02 hinzugefügt:

<pre>
SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=-PowerFlow_Site_P_Akku:W dc2ac=PowerFlow_Site_P_Akku:W capacity=7680
</pre>

'''Bemerkungen:''' 
- strings=none sowie die Schlüssel ac2cd und dc2ac sind typisch für einen Batterie-WR bzw. kennzeichnen einen WR als Batterie-Wechselrichter 
- die an die Batterie abgegebene Leistung ist negativ

 
===== Einbindung eines Fronius Symo GEN24 10.0 Plus mit BYD Batterie ohne (virtuellen) Batterie-Wechselrichter =====
Diee Implementierung ist komplett in diesem verlinkten [https://wiki.fhem.de/wiki/Solaranlage_Komplettbeispiel_Fronius_BYD Wiki Beitrag] beschrieben.

Zur Integration des ''Fronius Symo'' in FHEM wird das Modul ''fronius.pm'' verwendet und in dem definierten Device ''Fronius_Symo_Gen24'' diverse userReadings erzeugt. Diese Readings werden in den korrespondierenden Schlüsseln des Attributes ''setupInverterDev01'' angegeben:

<pre>
setupInverterDev01 Fronius_Symo_Gen24 etotal=User_Produced_PV_Energie:kWh pvOut=PowerFlow_Site_P_PV:W capacity=6000 strings=Dach_Ost,Dach_West
</pre>

Am Wechselrichter Fronius Symo Gen24 ist eine BYD Batterie angeschlossen. Das Device ''[https://wiki.fhem.de/wiki/Solaranlage_Komplettbeispiel_Fronius_BYD#PV_Batterie PV-Batterie]'' wird per [https://wiki.fhem.de/wiki/ModbusAttr ModbusAttr] angelegt und gemanaged. Die entsprechenden Readings werden im Attribut ''SetupBatteryDev01'' hinterlegt:

<pre>
PV_Batterie
cap=10240
charge=BatteryChargePercent
icon=@dyn:@dyn:@dyn:@dyn
intotal=Summe_Ladung:Wh
outtotal=Summe_Entladung:Wh
pin=BatteryChargeWatt:W
pout=BatteryDischargeWatt:W
pinmax=10000
show=2
</pre>

 

===== Einbindung eines SMA - Hybrid Sunny Tripower Smart Energy =====

[[Datei:Screenshot 2025-10-05 083530.png|right|thumb|400px|SMAInverter.pm]]

Der genannte Wechselrichter wird über das Modul SMAInverter.pm in FHEM integriert. Die nebenstehende Abbildung zeigt und benennt die einzelnen Readings des Moduls welche in den entsprechenden Schlüsseln der SolarForecast Attribute ''setupInverterDevXX'' und ''setupBatteryDevXX'' zugeordnet werden.

Die Readings des SMAInverter Moduls können vor der Verwendung über geeignete Methoden (userReadings) in Readings mit sprechenden Namen überführt werden um sie mit diesen Namen in die genannten Attributschlüssel einzufügen. In der vorliegenden Lösung befinden sich die Anwendungen SolarForecast und und die Inverter-Steuerung jeweils auf unterschiedlicher Hardware. Als Verbindungslayer wird MQTT genutzt, wobei dadurch bereits die dargestellten Readingnamen entstehen.

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)
;graphicBeamHeightLevel1:Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene (hier Ebene 1)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===
Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und, wenn ein Event eines als 'asynchron' definierten Devices auftritt, gesammelt und daraus permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

=== Wie wird die Verbrauchsprognose erstellt? ===

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

==== Debugging der Verbrauchsprognose ====
Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

=== Wie kann eine fehlerhafte Verbrauchsprognose korrigiert werden? ===
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionHistory 07 21

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
==== Beispiel Auslesen der Batterieladestrategie und Anlegen eines Readings ====

Als Praxisbeispiel soll die aktuelle gesetzte Ladestrategie für Batterie "01" ausgelesen und mit dem Wert ein Reading im SolarForecast Device angelegt werden. 
Dazu wird der folgende Code im Attribut ''ctrlUserExitFn'' hinterlegt:

<syntaxhighlight lang="Perl">
{
my $wert = NexthoursVal ($name, 'NextHour00', 'strategybat01', 'loadRelease');
storeReading ('Ladestrategie', $wert);
}
</syntaxhighlight>

Bei jedem Zyklus des SF-Devices wird der aktuelle Wert von ''strategybat01'' gelesen und im Reading ''Ladestrategie'' gespeichert. Die Paket-Definition ''FHEM::SolarForecast::'' braucht nicht verwendet werden, da der Aufruf im Attribut ctrlUserExitFn innerhalb des SolarForecast-Paketes erfolgt.

Für andere Batterienummern ist der NexthoursVal-Schlüssel ''strategybat01'' entsprechend anzupassen.

 

=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
PVH_SolarForecast_<name> - PV History
PVC_SolarForecast_<name> - PV Circular
PVCfg_SolarForecast_<name> - PV Anlagenkonfiguration
PVCsm_SolarForecast_<name> - Consumer Status
ScApi_SolarForecast_<name> - Strahlungswerte aus verwendeter API
StatApi_SolarForecast_<name> - Statusdaten der verwendeten API's
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - KI Input Daten = Raw Trainigsdaten
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten 3 Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "pvHistory" restored
2023.10.02 09:57:07.969 3: SolCast6 - cached data "pvCircular" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "consumerMaster" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "radiationApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "statusApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "weatherApiData" restored
2023.10.02 09:57:07.974 3: SolCast6 - cached data "aiTrainedData" restored
2023.10.02 09:57:07.976 3: SolCast6 - cached data "aiRawData" restored
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices, d.h. ein einfaches "define <Name> SolarForecast", und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. Anpassen der Dateieigentümer und Berechtigungen: chown fhem:dialout /opt/fhem/FHEM/FhemUtils/*, chmod 774 /opt/fhem/FHEM/FhemUtils/*
* 5. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen
* 7. FHEM Konfiguration sichern und restarten

 
'''Hinweis:''' 
Das zuvor beschriebene Verfahren kann auch angewendet werden um das SolarForcast Device von einer FHEM Installation in eine andere Installation umzuziehen. In diesem Fall ist aber besonders darauf zu achten, vorab alle in den SF-Attributen referenzierten Devices wie Inverter, Meter oder DWD-Devices mit den zutreffenden Namen in der neuen Installation anzulegen.

 
Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices, d.h. ein einfaches "define <Name> SolarForecast", und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. Anpassen der Dateieigentümer und Berechtigungen: chown fhem:dialout /opt/fhem/FHEM/FhemUtils/*, chmod 774 /opt/fhem/FHEM/FhemUtils/*
* 6. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 7. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen
* 8. FHEM Konfiguration sichern und restarten

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere diese Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagementXX lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>] [loadAbort=<SoC1>:<MinPwr>:<SoC2>] [safetyMargin=<Wert>[:<Wert>]] ...

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;stepSoC: Optionale Schrittweite zur optimalen SoC-Berechnung (Battery_OptimumTargetSoC_XX) in %. Mit der Angabe 'stepSoC=0' wird das SoC-Management deaktiviert und Battery_OptimumTargetSoC_XX auf den Wert 'lowSoC' gesetzt. '''Hinweis:''' Die Beziehung 'careCycle * stepSoC = 100' sollte eingehalten werden! Wert: 0..5, default: 5

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten darf. Die Angabe ist optional. (default: 20)

;lcSlot: Es wird ein tägliches Zeitfenster festgelegt, in dem die Ladesteuerung des Moduls für diese Batterie aktiv sein soll. Außerhalb des Zeitfensters wird die Batterieladung mit voller Leistung freigegeben. Das SoC-Management der Batterie ist davon nicht betroffen. Wert: <hh:mm>-<hh:mm>, default: ganztägig

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit. Die Abbruchbedingung ist erfüllt, wenn der angegebene SoC1 (%) erreicht bzw. überschritten ist '''UND''' die angegebene Ladeleistung <MinPwr> (W) unterschritten wurde -> Reading Battery_ChargeAbort_XX=1. Fällt der aktuelle SoC wieder unter den SoC2, wird Battery_ChargeAbort_XX=0 gesetzt. Ist SoC2 nicht angegeben, gilt SoC2=SoC1.

;loadStrategy: Abhängig von der gewählten Ladestrategie wird die Prognose der Batterieladung und ggf. die Generierung der Steuerreadings beeinflusst. Die Angabe ist optional. Wert: loadRelease | optPower | smartPower, default: loadRelease

;loadTarget: Optionaler Ziel-SoC in % für die Berechnung der Ladefreigabe bzw. der optimalen Ladeleistung. Der Zielwert ist eine kalkulatorische Rechengröße. Der reale SoC kann situativ in Grenzen über- oder unterschritten werden. Der höhere Wert aus Reading Battery_OptimumTargetSoC_XX und 'loadTarget' hat für die Berechnung Vorrang. Wert: 0..100, default: 100

;safetyMargin: Bei der Berechnung der Ladefreigabe und optimierten Ladeleistung werden Sicherheitszuschläge auf den prognostizierten Ladungsbedarf berücksichtigt. Abweichend vom Default können mit diesem Parameter individuelle Sicherheitszuschläge getrennt für die Berechnung der Ladefreigabe und optimierten Ladeleistung angegeben werden. Der erste Wert ist der Zuschlag bei der Berechnung der Ladefreigabe, der zweite Wert der Zuschlag bei der Berechnung der optimierten Ladeleistung. Beide Angaben sind Prozentwerte von 0..100.

;weightOwnUse: Optionale Gewichtung der stündlichen Verbrauchsprognose als zusätzlich verwendbaren Anteil zur Batterieladung in %. Technisch wird der verfügbare PV-Überschuß zur Berechnung der optimierten Ladeleistung erhöht indem der kalkulierte Verbrauch um den angegebenen Prozentsatz gesenkt wird. Wert: 0..100 default: 0

Alle SoC-Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Wert 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Wert 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten. Der Fokus der Steuerung mit diesem Reading ist es, die Speicherkapazität der Batterie optimal zur Verhinderung der Überschreitung von Einspeiselimits einzusetzen und dennoch einen maximal möglichen SoC am Tagesende zu erreichen. (siehe das beschriebene [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Berücksichtigung_einer_Wirkleistungsbegrenzung|Nutzungsbeispiel]])

;Battery_ChargeOptTargetPower_XX: Dieses Reading enthält einen Richtwert für die optimierte Ladeleistung für jede Batterie. Die Aufladung wird prognosegeführt über den gesamten Tag verteilt, wobei der Fokus auf eine kontinuierliche, aber möglichst niederige Ladeleistung gelegt wird. (siehe diesen [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|Abschnitt]])

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

;Battery_TargetAchievable_XX: Diese Reading enthält einen Boolean Wert 0|1 und signalisiert ob der im Attribut '''ctrlBatSocManagementXX->loadTarget''' gesetzte Ziel-SoC lt. Prognose am aktuellen Tag tatsächlich erreicht werden kann.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

 

===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und folgenden Tag korrigiert. Das bedeutet, dass der Minimum SoC z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Batterie wieder vollständig zu zuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $bn = '01'; # Batterienummer (evtl. im Aufruf mitgeben)
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) für Victron MPII Verbund
my $preduce = FHEM::SolarForecast::BatteryVal ($name, $bn, 'bpinreduced', $maxcspc); # reduzierte Ladeleistung aus Bat-Konfig (W)
my $actmcc = ReadingsNum ($vicsets, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_'.$bn, 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_'.$bn, 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Ladestrom (A) b. Battery_ChargeRequest
$load = $preduce / 48; # bei 48V Batteriesystem
}
else {
$load = $maxcspc;
}
}

## Einstellung MPII Verbund MaxChargeCurrent
##############################################
if ($actmcc && $load != $actmcc) {
CommandSet (undef, "$vicsets MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vicsets set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_MPII_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Die in diesem Abschnitt beschriebene Ladestrategie '''loadRelease''' wird im Modul als '''Ladefreigabe''' bezeichnet.

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen, oder der im Reading [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|Battery_ChargeOptTargetPower_XX]] angegebenen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten..

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''. Die erreichte Qualität der Steuerungslogik ist stark von der Prognosequaliät abhängig. Um die Steuerung resilienter zu gestalten, wird per default ein Sicherheitsaufschlag von 50% auf die prognostizierte benötigte Ladeenenergie auf Stundenbasis einkalkuliert. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<div class="mw-collapsible mw-collapsed">
'''Code Management Batterieladung über Victron Grid Setpoint ->''' <div class="mw-collapsible-content">
<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>
</div>
</div>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== leistungsoptimierte Beladungssteuerung mit dem Fokus geringe Verlustleistung und Verschleiß ====

Über das Attribut ctrlBatSocManagementXX kann mit dem Schlüssel loadStrategy die Ladestrategie '''optPower''' oder '''smartPower''' eingestellt werden.
Das SF-Modul bietet ein weiteres Reading '''Battery_ChargeOptTargetPower_XX''' zur Batteriesteuerung an. Dieses Reading liefert eine kalkulierte optimale Ladeleistung in Watt.

Die in diesem Abschnitt beschriebene Ladestrategie '''optPower''' wird im Modul als '''optimierte Ladeleistung''', die Ladestrategie '''smartPower''' als '''zieloptimierte Ladeleistung''' bezeichnet.

Beide Strategien kalkulieren die Ladeleistung kontinuierlich neu und berücksichtigen dabei:

* die Prognose der PV-Erzeugung der nächsten Stunden und des (Rest-)Tages
* den prognostizierten Verbrauch auf Stunden- bzw. Tagesbasis
* eine eventuell mögliche Überschreitung des gesetzten Einspeiselimits (plantControl->feedinPowerLimit)
* die gesetzten Leistungsparameter der Batterie
* das Ziel, am Tagesende einen möglichst maximalen SoC der Batterie erreicht zu haben bzw. den eingestellten Ziel-SoC '''loadTarget'''
* die Effizienz der Batterieanlage (Einstellung '''setupBatteryDevXX->efficiency''')

Der Fokus der implementierten Logik liegt dabei auf einer kontinuierlichen Ladeleistung, die aber unter den oben genannten Gesichtspunkten möglichst (relativ) gering sein soll um den Batterieverschleiß und die Verlustleistung zu minimieren. Die im Reading angezeigte Ladeleistung kann mit geeigneten Mitteln direkt in die Leistungssteuerung der Batterie eingebracht werden. Natürlich kann die Leistung auch vorab in einen optimalen Ladestrom umgerechnet werden.

Da das Ergebnis der Kalkulation stark von den Prognosen abhängt, ist zur Erhöhung der Resilienz per Default ein Sicherheitszuschlag von 20% eingebaut. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

Ist kein PV-Überschuß (mehr) vorhanden / prognostiziert oder das Ladeziel erreicht, erfolgt ein Rückfall der Ladeleistung im Reading Battery_ChargeOptTargetPower_XX auf den im Attribut '''setupBatteryDevXX->pinmax''' angegebenen Wert. Ist dieser Wert nicht gesetzt, erfolgt der Rückfall auf "Unendlich" (9223372036854775807).

Im Reading Battery_ChargeOptTargetPower_XX wird der Wert des Parameters '''setupBatteryDevXX->pinreduced''' gesetzt, wenn weniger Ladeleistung als pinreduced berechnet wurde (Einhaltung einer Mindestladeleistung) oder wenn der SoC der Batterie <= [[#Aktivierung_des_Batterie_SOC-_und_Lade-Managements|lowSoC]] beträgt.
Somit wird die Batterie bei einer Anforderungsladung bei Unterschreitung von lowSoC mit nur wenig Leistung aus dem Grid geladen falls es nötig sein sollte.
Es ist demzufolge ratsam den optionalen Parameter '''setupBatteryDevXX->pinreduced''' zu setzen, da ansonsten ebenfalls ein Rückfall auf '''setupBatteryDevXX->pinmax''' bzw. "Unendlich" erfolgt.

Beide Strategien, optPower und smartPower, setzen die zuvor beschriebene Arbeitsweise um.
Ergänzend wird bei der Ladestrategie '''smartPower''' die generelle Erreichbarkeit des Ladeziels bei der Festlegung der Ladeleistung berücksichtigt. Es führt dazu dass:

* die Ladeleistung im Reading Battery_ChargeOptTargetPower_XX auf einen tendenziell höheren Wert als bei der optPower-Strategie gesetzt wird, wenn/solange das eingestellte Ladeziel als unerreichbar kalkuliert wird
* bei kalkulierter Erreichbarkeit des Ladeziels der Sicherheitsaufschlag linear absenkend proportional zum Kehrwert des verfügbaren PV-Überschusses auf die Ladeleistung angewendet wird

Der nächste Abschnitt erläutert die smartPower Funktionen etwas eingehender.

 
===== smartPower - die zieloptimierte Ladeleistung =====
Die hinter smartPower liegende Anpassungslogik wird nachfolgend etwas näher beschrieben.
Ausgangspunkt ist das Ergbnis einer Ratio-Funktion aus dem (Rest)Tages-PV-Überschuß und benötigter Energie zur Erlangung des Batterie Ladeziels.

'''Lineare Interpolation zwischen pinmax und abgesicherter minpower''' 

'''Variablen'''

* '''P''': resultierende Leistung.
* '''pinmax''': maximale Ladeleistung.
* '''limpower''': Leistungslimit, d.h. Ladeleistungssollwert.
* '''r''': Verhältnis in Prozent (r = spday·100 / whneed).
* '''otpMargin''': Prozentwert der Bandbreite, über die die Absenkung linear verläuft (die Steilheit kann mit dem Attributwert ctrlBatSocManagementXX->safetyMargin im Device eingestellt werden).

Die Kennlinie der für smartPower eingesetzten Funktion ist stückweise definiert über das Verhältnis Ratio ''𝑟 = spday x 100 / <benötigte Ladeenergie bis Ziel>''.

* Für 𝑟 ≤ 100: ''𝑃 = pinmax'', Interpretation: Es ist viel Bedarf vorhanden bzw. Überschuss ≤ 100 % des Bedarfs → maximal laden.
* Für 𝑟 ≥ 100 + otpMargin: ''𝑃 = limpower ⋅ (1 + otpMargin / 100 )''
* Für 100 < 𝑟 < 100 + otpMargin: lineare Absenkung von '''P''' mit zunehmendem '''r''' für den Bereich 100 < 𝑟 < 100 + otpMargin. '''P''' wird bei 𝑟 = 100 gleich '''pinmax''' und bei 𝑟 = 100 + otpMargin gleich ''limpower ⋅ ( 1 + otpMargin/100 )'', Interpretation: Sobald der Überschuss über den Bedarf hinausgeht (ratio > 100), wird das Ladeleistungslimit schrittweise von pinmax Richtung limpower reduziert; die Reduktion erfolgt gleichmäßig über die Margin-Spanne.

'''Lineare Interpolation und Steigung'''

Die Differenz ''(pinmax − limpower)'' wird gleichmäßig auf die otpMargin-Prozentpunkte verteilt. Die Steigung der Geraden ist

<pre>
slope = − (pinmax − limpower) / otpMargin
</pre>

das heißt die Leistung sinkt um diesen Betrag pro Prozentpunkt von '''r'''.

Nach Umformung ist der Zusammenhang wie folgt darstellbar:

<pre>
𝑃 = pinmax − ( pinmax − limpower) ⋅ ((𝑟 − 100) / otpMargin)
</pre>

und ist äquivalent zu

<pre>
𝑃 = pinmax + ( 𝑟 − 100 ) ⋅ slope
</pre>

'''Numerisches Beispiel'''

* '''limpower''' = 1000 W, '''pinmax''' = 3000 W, '''otpMargin''' = 20
* Unterschied = 2000 W, Steigung = −2000/20 = −100 W/%
* Für '''r = 105''': 𝑃 = 3000 − 2000 ⋅ ( 5 / 20 ) = 3000 − 500 = 2500 W
* Für '''r = 120''' ergibt die Formel den abgesicherten Endwert 1200 W

Die Formel sorgt dafür, dass die Zielleistung stufenlos und vorhersehbar reduziert wird, wenn der relative Rest-Überschuss des Tages über 100% steigt, und erreicht bei Ende der otpMargin den geplanten abgesicherten Wert.

[[Datei:Ratio Kennlinie.png|right|thumb|200px|abfallend proportionale Anpassungsfunktion]]

In einem grafischen Diagramm stellt sich die abfallend proportionale Anpassungsfunktion der resultierenden Soll-Ladeleistung wie nebenstehend abgebildet dar. Dabei entspricht pow=100 dem jeweiligen pinmax Wert (hier 3000 W). So ist auch pow=0 mit dem abgesicherten Endwert (hier 1200 W) gleichzusetzen. Die Linie verläuft waagerecht bei pinmax solange das das Ratio r ≤ 100 % und knickt an r == 100 mit steigenden r nach unten. Es verringert sich pow linear von pinmax zu limpower zzgl. otpMargin.

Durch diese Maßnahmen wird eine flexible Lademöglichkeit bis pinmax erreicht, die sich bei unvorhergesehenen Aufklarungen mit starker Sonneneintrahlung bei ansonsten sehr bedeckten Himmel positiv auswirkt. Andererseits wird die Erhöhung der Ladeleistung weiter begrenzt, wenn viel PV-Überschuß in Verbindung mit einer generellen Erreichbarkeit des Ladeziels zum Ende des Tages prognostiziert ist. Man könnte die Ladestrategie '''smartPower''' in ihrer Wirkung als einen Mix aus '''optPower''' und '''loadRelease''' ansehen.

Zusammenfassend ist optPower vorwiegend für die Nutzergruppe geeignet, die eine tendenziell sparsamere Ladeleistung bevorzugen und dafür bereit sind eventuelle "Verluste" in Form von Einspeisung zu akzeptieren. 
Demgegenüber eignet sich das aggressivere smartPower für Anwender, die bei niedrigen PV-Erträgen bewusst das Maximum an Batterieladung anstreben und dafür in Kauf nehmen, dass Ladeleistungen weniger knapp kalkuliert sind.

 

===== Unterstützung des Modus "Eigennutzung" bei Hybrid-Wechselrichtern =====
Viele Hybrid-Wechselrichter verteilen die zur Verfügung stehende PV-Leistung nach folgendem Prioritäten, wenn der (übliche) Modus "Eigennutzung" aktiviert ist:

# Nutzung der Leistung zur Deckung des Hausverbrauchs,
# Nutzung der Leistung zur Ladung des bzw. der angeschlossenen Speicher.
# Einspeisung der Leistung in das öffentliche Netz.

Da in aller Regel die Leistung, mit der ein angeschlossener Speicher geladen wird, limitiert werden kann, lassen sich die o.g. Priorität bzgl. des Speichers zugunsten einer Überschusseinspeisung aufweichen. Ein entstehender "Überschuss" steht also ggf. nur deshalb zur Verfügung, weil die Ladeleistung des Speichers begrenzt wurde.

Ab Version 1.58.6 bietet SolarForecat die Möglichkeit, prognostizierte Verbräuche nicht mehr komplett bei der Bestimmung der ''optimalen Ladeleistung'' zu berücksichtigen, sondern nur noch zu einem prozentualen Anteil von 0..100 %. Hierzu muss der Attribut-Schlüssel '''ctrlBatSocManagementXX->weightOwnUse=<Percentage>''' entsprechend gesetzt werden.

So führt beispielsweise weightOwnUse=100 dazu, dass bei der Berechnung der optimalen Ladeleistung prognostizierte Verbräuche nicht mehr berücksichtigt werden indem sie bei der Bestimmung des stündlichen PV-Überschusses unberücksichtigt bleiben. Eine derartige Einstellung kann z.B. sinnvoll sein, wenn alle ansonsten täglich laufende Verbraucher zugunsten einer Batterieladung ausgeschaltet werden können.

Ein Wert von zum Beispiel weightOwnUse=30 lässt 30% der stündlichen Verbrauchslast unberücksichtigt, sodass sich der kalkulierte PV-Überschuß pro Stunde um 30% des prognostizierten Verbrauchs erhöht. Da die Berechnung der optimierten Ladeleistung mit dem zur Verfügung stehenden PV-Überschuß gewichtet erfolgt, würde sich die kalkulierte Ladeleistung in den meisten Fällen ebenfalls um einen gewissen Betrag erhöhen sofern andere Faktoren dies nicht verhindern. Das kann beispielweise der Fall sein, wenn die kalkulierte Ladeleistung zu gering ist und automatisch aif mindestens '''setupBatteryDevXX->pinreduced''' angehoben wurde.

 

==== Welche Ladestrategie soll ich wählen? - eine Möglichkeit zur Best-Practice Findung mit Codebeispiel ====

In den vorangegangenen Abschnitten wurden die verschiedenen Möglichkeiten zur Steuerung der Batterieladung und dem SoC vorgestellt. Diese Steuerungsvarianten optimieren die Arbeitweise der Batterie, haben aber jeweils einen eigenen Fokus auch wenn es gewisse Überschneidungen gibt.

Die Steuerungsvarianten lassen sich folgendermaßen klassifizieren:

# Steuerung der Batterieladung über eine Ladefreigabe, die durch bestimmte Indikatoren festgelegt wird. Diese Variante ist in [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Berücksichtigung_einer_Wirkleistungsbegrenzung|diesem]] Abschnitt beschrieben.
# Steuerung der Batterieladung durch eine optimierte maximale Ladeleistung. Diese Variante ist in [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|diesem]] Abschnitt dargelegt. Zu dieser Variante gehören die Strategien ''optPower'' sowie ''smartPower''. Die Unterschiede beider Strategien sind ebenfalls in dem verlinkten Abschnitt beschrieben.

Die '''Variante 1.)''' gibt die Ladung der Batterie frei wenn der (verbleibende) PV-Überschuß des Tages kleiner oder gleich dem Ladungsbedarf der Batterie ist um einen SoC von 100% bzw. den maximal möglichen SoC am Ende des Tages zu erreichen. Dadurch wird die in der Batterie vorhandene freie Kapazität so lange wie möglich der Einhaltung von besonderen Grenzwerten, z.B. des Einspeiselimits (plantControl->feedinPowerLimit), vorbehalten. Nebeneffekt ist, dass plötzlich und unerwartet auftretende hohe Erzeugungsleistungen in die Batterie geladen werden können und nicht unerwünscht in das öffentliche Netz eingespeist werden.

Die '''Variante 2.)''' lässt die Batterie kontinuierlich laden, wobei die Ladeleistung auf ein optimiertes Minimum reduziert wird ohne das Ziel, einen maximalen SoC am Tagesende zu erreichen, zu ignorieren. Dadurch wird die Batterie schonend, mit möglichst wenig Verlustleistung und verschleißarm geladen. Die Vorhaltung der freien Kapaziäten der Batterie sind in dieser Variante nicht die Prämisse. Die Einhaltung des gesetzten Enispeiselimits wird auch in dieser Variante beachtet sofern es der Ladezustand der Batterie zulässt. Technisch bedingt kann diese Variante nur ungenügend auf unerwartete PV-Überschüsse reagieren, was zu einer Einspeisung in das öffentliche Netz oder im ungünstigsten Fall zur Abregelung der Anlage führen kann. Mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' kann man diesem negativen Aspekt in gewissem Maße entgegenwirken.

Ausgehend von diesen unterschiedlichen Optimierungszielen bietet sich die Variante 1.) vorwiegend in den Übergangs- und Wintermonaten an. Durch die beschriebenen Eigenschaften dieser Variante ist bei tendeziell weniger PV-Überschuß über den Tag die Ladung der Batterie komplett freigegeben, wodurch bei plötzlich auftretenden sonnige Abschnitten und Aufklarungen die Batterie sofort mit dem verfügbaren PV-Überschuß geladen wird. Auch eine Einspeisung über das Einspeiselimit hinaus kann verhindert werden. In der übrigen Zeit wird die Ladeleistung durch den verfügbaren PV-Überschuß begrenzt.
Weiterhin soll der SoC nicht dauerhaft tief absinken und ebenfalls nicht auf einem zu hohen Level verharren was auch einer maximal möglichen Energiespeicherung an sonnigen Tagen entgegenwirken würde.
In dieser Zeit ist die Nutzung der Kombination von [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Nutzung_des_Batterie_SOC-Management|SoC-Management]] und Variante 1.) wohl am Besten geeignet um die Ziele zu verwirklichen sowie Notreserven in den Batterien vorzuhalten.

In den Sommermonaten hingegen ist üblicherweise sehr viel PV-Energie und Überschuß vorhanden. In dieser Periode würden die Batterien mit sehr hoher Leistung sehr zeitig am Tag vollgeladen. Die Variante 1.) ist im Prinzip ebenfalls gut geeignet den Zeitpunkt der Vollladung hinauszuzögern, jedoch erscheint die Varinte 2.) in dieser Zeit besser geeignet mit einer über den gesamten Tag verteilten moderaten Ladeleistung den Ziel-SoC zu erreichen. Auch diese Variante versucht eine Überschreitung des Einspeiselimits zu verhindern sofern der Ladezustand der Batterie dies ermöglicht.

Das nachfolgende Codebeispiel bietet die Möglichkeit über ein Attribut die Ladevariante auszuwählen, über ein weiteres Attribut die SoC-Steuerung zu aktivieren/deaktivieren und integriert auch die Ladesteuerung für eine Batterie-Anforderungsladung bei Unterschreitung von ctrlBatSocManagementXX->lowSoc.

Die gesteuerte Batterieanlage besteht aus:

* 3 x Victron MultiPlusII 3000/48
* Steuergerät CerboGX (in FHEM über MQTT eingebunden)
* einem Batteriestack bestehend aus Pylontech US3000C (wird durch CerboxGX gesteuert)

Zur Umschaltung bzw. Auswahl der Ladestrategie und des SoC-Managements werden zwei User-Attribute im SolarForecast Device angelegt.

<pre>
attr ... userattr userFn_BatterySoCManagement:Ein,Aus userFn_BatteryLoadManagement:Aus,loadRelease,optPower,smartPower
</pre>

Im Code werden diese Attribute ausgewertet. Das nachfolgende Script vereint folgende Funktionalitäten:

* die Aktivierung/Deaktivierung des SoC-Managements via Attribut userFn_BatterySoCManagement
* die Auswahl der Ladestrategie oder Deaktivierung der Ladesteuerung via attribut userFn_BatteryLoadManagement
* Integration einer Anforderungsladung bei Signalisierung durch Reading Battery_ChargeRequest_XX
* Generierung von Readings userFn_Victron_GridSetpoint_set und userFn_MPII_MaxChargeCurrent_set zur Dokumentation der eingestellten Soll-Werte

Bei der Nachnutzung des Scripts sind zunächst die '''Konstanten''' und das Device '''MQTT2_cerboGX_c0619ab34e08_setting'''s sowie dessen Readings im Block '''aktuelle Indikatoren''' anzupassen.

Das Script wird in die Datei '''99_mySolarForecastUtils.pm''' eingetragen und im SolarForecast Attribut '''ctrlUserExitFn''' hinterlegt:

<pre>
attr ... ctrlUserExitFn {
::batLoadMgmnt ($name, '01');
# ::batLoadMgmnt ($name, '02'); # optional für eine weitere Batterie '02'
# ::batLoadMgmnt ($name, '0X'); # optional für weitere Batterien
}
</pre>

Mit diesem Script ist der Nutzer in der Lage, das Batterie Lademanagement entsprechend seiner Motivation und gegebenenfalls abhängig von der Jahreszeit umzustellen und das Ergebnis bzw. die Zielerreichung zu testen.

Das Attribut '''userFn_BatteryLoadManagement''' selektiert die gewünschte Ladestrategie:

;Aus: das Lademangement ist ausgeschaltet

;loadRelease: das Lademangement Variante 1.) Ladestrategie Ladefreigabe ist aktiviert

;optPower: das Lademangement Variante 2.) Ladestrategie optimierte Ladeleistung ist aktiviert

;smartPower: das Lademangement Variante 2.) Ladestrategie zieloptimierte Ladeleistung ist aktiviert

Die selektierte Ladestrategie wird im Script in das SolarForecast Device repliziert, d.h. der Attributschlüssel ctrlBatSocManagement01->loadStrategy wird identisch zum Wert des Attributes userFn_BatteryLoadManagement gesetzt. Dazu wird das Set-Kommando ''attrKeyVal'' verwendet. Das globale Attribut ''autosave'' sollte aus diesem Grund NICHT explizit auf "0" gesetzt sein um eine reibungslose Funktion zu ermöglichen.

Hat man die individuell passende Management-Strategie gefunden, bietet sich auch eine automatische (zum Beispiel durch einen Kalender oder Sonnenstand (Elevation) zur Mittagszeit) Umschaltung der Ladestrategie an. Die Unterschreitung der Elevation unter einen bestimmten Wert würde den Beginn des Winterhalbjahres und reverse Überschreitung den Beginn des Sommerhalbjahres kennzeichnen. Entsprechend würde dann die gewünschte Ladestrategie selektiert. Alternativ könnte auch die PV-Überschußprognose für den aktuellen Tag über das Reading ''Today_PVforecast'' für eine Entscheidung bzgl. der Ladestrategie herangezogen werden.

Das SoC-Management kann über das gesamte Jahr aktiviert bleiben, hat jedoch nach bisherigen Erfahrungen nur im Winterhalbjahr eine starke Relevanz.

<div class="mw-collapsible mw-collapsed">
'''Code Lademanagement ->''' <div class="mw-collapsible-content">
<syntaxhighlight lang="perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Komplettes Batterie Lademanagement
############################################################################
sub batLoadMgmnt {
my $name = shift;
my $bn = shift // '01'; # Batterienummer
my $hash = $defs{$name};

## Konstanten
###############
use constant {
GSPDEF => 20, # Einstellung des Grid Setpoint
FINDEF => 5000, # Default Einspeiselimit
MINSOCDEF => 10, # Default Minimum SoC
MAXPLDEF => 105, # max. Ladestrom (A) Victron MPII
SYSVOLTAG => 48, # Batterie Systemspannung
};

my $batsocmgmt = AttrVal ($name, 'userFn_BatterySoCManagement', 'Aus'); # SoC-Management Vorgabe
my $batloadmgmt = AttrVal ($name, 'userFn_BatteryLoadManagement', 'Aus'); # Lademanagement Vorgabe
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron CerboGX Einstellungen

## Ladestrategie Ist-Einstellung und Soll-Abgleich
####################################################
my $cgbt = AttrVal ($name, 'ctrlBatSocManagement'.$bn, undef);
my $strategy = 'loadRelease';

if ($cgbt) {
my $parsed = FHEM::SolarForecast::__parseAttrBatSoc ($name, $cgbt); # aktuell gesetzte Strategie ermitteln
$strategy = $parsed->{loadStrategy} // $strategy;
}

if ($batloadmgmt ne 'Aus' && $strategy ne $batloadmgmt) {
CommandSet (undef, "$name attrKeyVal ctrlBatSocManagement${bn} loadStrategy=$batloadmgmt");
}

## aktuelle Indikatoren
##########################
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_'.$bn, 0); # Notfallladung
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', GSPDEF); # aktuelle Einstellung Grid Setpoint
my $finplim = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', FINDEF); # Limit plantControl->feedinPowerLimit
my $preduce = FHEM::SolarForecast::BatteryVal ($name, $bn, 'bpinreduced', MAXPLDEF); # reduzierte Ladeleistung Bat-Konfig
my $actmcc = ReadingsNum ($vicsets, 'MaxChargeCurrent', 0); # akt. maximale Ladestromeinstellung
my $actmcp = ReadingsNum ($vicsets, 'MaxChargePower', undef); # akt. Ladeleistungseinstellung
my $load = MAXPLDEF; # initialer Soll-Ladestrom (A)

my $targetgsp = GSPDEF; # Voreinstellung Grid Setpoint
my $ctype = 'default'; # Voreinstellung Steuerungstyp

## Battery SoC Management
###########################
if ($batsocmgmt eq 'Ein') {
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', MINSOCDEF); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_'.$bn, MINSOCDEF); # optimierter Mindest-SoC

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}
}

## Steuerung nach Ladungsfreigabe
###################################
if ($batloadmgmt eq 'loadRelease') {
$ctype = 'loadRelease';
my $unrestrict = ReadingsNum ($name, 'Battery_ChargeUnrestricted_'.$bn, 0); # Ladefreigabe (1 -> Ladefreigabe)

if (!$unrestrict) { # Grid Setpoint absenken wenn keine ..
$targetgsp = GSPDEF - $surp; # ..Batterie Ladefreigabe
my $neggspmax = -1 * $finplim;
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) { # GridSetpoint setzen
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn ChargeMgmnt 'loadRelease' -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

## Steuerung nach optimaler Ladeleistung
##########################################
if ($batloadmgmt =~ /(?:opt|smart)Power/xs) {
$ctype = 'optPower';
my $otp = ReadingsNum ($name, 'Battery_ChargeOptTargetPower_'.$bn, $preduce); # optimale Ladeleistung (W)
$load = sprintf "%.0f", ($otp / SYSVOLTAG);
}

## Anforderungsladung
#######################
if ($bcrq) { # max. Ladeleistung...
$ctype = 'requestCharging'; # bei Battery_ChargeRequest
my $p;

if ($surp < $preduce) {
$p = $preduce;
}
else {
$p = ReadingsNum ($name, 'Battery_ChargeOptTargetPower_'.$bn, $preduce); # optimale Ladeleistung (W)
}

$load = sprintf "%.0f", ($p / SYSVOLTAG);
}

## Stromeinstellung umsetzen
#############################
if ($load != $actmcc) {
CommandSet (undef, "$vicsets MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt '$ctype' -> MaxChargeCurrent in $vicsets set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_MPII_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>
</div>
</div>

 

==== sequentielle Batterie-Ladung mehrerer Batterien mit lcSlot ====

Der Parameter '''ctrlBatSocManagementXX->lcSlot''' ("load control Slot") definiert eine Zeitperiode am aktuellen Tag in der die Steuerungslogik für die Batteriesteuerung aktiviert ist. Ist dieser Parameter nicht gesetzt, ist das eingestellte Lademanagement über den gesamten Tag aktiert und wäre identisch mit der Einstellung:

lcSlot=00:00-23:59

Somit ist die Ladesteuerung per default über den gesamten Tag aktiv.

Durch das Setzen von lcSlot auf einen täglichen Slot wird die Ladesteuerung auf diese Periode eingegrenzt. In der übrigen Zeit ist die Ladung der Batterie freigegeben (Reading Battery_ChargeUnrestricted_XX) bzw. auf die maximal konfigurierte Ladeleistung eingestellt (Reading Battery_ChargeOptTargetPower_XX). Diese Readings können je nach verwendeter Ladestrategie ausgewertet und zur Steuerung der Batterie(n) verwendet werden.
Die SoC-Steuerung wird durch die lcSlot-Angabe nicht beeinflusst.

Mit lcSlot kann zum Beispiel ein sequentielles Laden von mehreren Batterien umgesetzt werden. Nachfolgend wird ein solches Szenario mit drei Batterien skizziert:

1. die Batterie 1 soll mit voller Leistung geladen werden, die anderen Batterien nur bei weiterem Überschuß. Man würde die jeweiligen
ctrlBatSocManagementXX->lcSlot Schlüssel definieren:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
</pre>

;Wie ist der Ablauf: Die Batterie 1 unterliegt keiner Steuerung (nur von 23:00 bis 23:10 als Dummy-Periode). Das Reading Battery_ChargeUnrestricted_01 wird "1" gesetzt, d.h. die Batterie 1 wird zur Ladung uneingeschränkt freigegeben. Die anderen Batterien unterliegen der Steuerung -> Battery_ChargeUnrestricted_02 / 03 sind "0" und sollen nur geladen werden falls ein gesetztes Einspeiselimit überschritten wird.

Ist das Ladeziel der Batterie 1 erreicht, setzt man um die Batterie 2 vollzuladen:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
</pre>

Die Batterien 1 und 3 unterliegen der Steuerung, d.h. Battery_ChargeUnrestricted_01 / 03 haben den Wert "0". Demgegenüber ist Battery_ChargeUnrestricted_02=1 und soll uneingeschränkt geladen werden.

Ist auch die Batterie 2 voll geladen, würde man das Laden der Batterie 3 aktivieren:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=23:00-23:10
</pre>

Das Setzens via '''attrKeyVal''' hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrund peprüft und ggf. ein Fehler zurückgegeben wird, den der Nutzer in seinem Script auswerten kann. Weiterhin werden die Attribute implizit gespeichert sofern global->autosave nicht explizit auf "0" gesetzt ist.

 

==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 
=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 
=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
== Konfigurationsbeispiele ==

=== Visualisierung solare Vorhersage und reale Erzeugung ===

Zu Beginn jedes neuen Tages gegen 00:00 Uhr werden durch das SolarForecast Device Events für die initiale PV Prognose des kommenden Tages erstellt.
Der Readingteil dieser Events heißt

AllPVforecastsToEvent

Die Uhrzeiten der Events sind so aufbereitet und können direkt geloggt werden um sie in einen SVG Plot zu integrieren.
Im SolarForecast Device ist dieses Reading nicht sichtbar, nur die Events werden erstellt.

Die meteorologischen Bedingungen verändern sich über den Tag permanent. Je nach gewählter Strahlungsdatenquelle (eine API oder DWD Device) erfolgt eine mehr oder weniger dynamische Anpassung der Prognose an die sich verändernde Umwelt.

Aktuelle Prognosedaten sowie die reale PV Erzeugung der vergangenen Stunde können über die Readings

LastHourPVforecast
LastHourPVreal

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.<syntaxhighlight lang="perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.
Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten einlesen kann. Der Code wird nur ausgeführt, wenn das Reading nextCycletime ein Event erzeugt.<syntaxhighlight lang="perl">

forecast_json:nextCycletime.* {

use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my $last_start_ts;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => "%Y-%m-%d %H:%M:%S",
time_zone => "Europe/Berlin",
);
my $start_ts;

# Alle NextHour-Daten durchsuchen (als Fallback zur Vermeidung einer Endlosschleife auf max. 100 Std. begrenzen)
while ($hour < 100) {
my $hour_str = sprintf("NextHour%02d", $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "starttime", "na");
my $pvfc = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "pvfc", "na");

# Schleife beenden, wenn keine Vorhersage-Werte mehr vorhanden sind
last if $start_str eq "na" or $pvfc eq "na";

$start_ts = $parser->parse_datetime($start_str); # Zeitzone und Sommer/Winterzeit berücksichtigen

# Zeit nach UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $start_ts->set_time_zone("UTC")->iso8601() . "Z",
end => $start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0 + $pvfc,
};
$hour++;
}

# Prüfen, ob der letzte Wert 23 Uhr war -> zusätzliche Stunde anhängen, damit der Tag
# bei evcc als vollständig angezeigt wird (siehe https://github.com/evcc-io/evcc/issues/22979)
if ($start_ts->hour == 23) {

# Zeit nach UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $start_ts->set_time_zone("UTC")->iso8601() . "Z",
end => $start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0,
};
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
},
</syntaxhighlight>
[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]
Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):<syntaxhighlight>
define WEBapi FHEMWEB 8089
attr WEBapi csrfToken none
</syntaxhighlight>In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json','[]')} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
</syntaxhighlight>Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

=== Poolsteuerung inkl. Eigenverbrauchsoptimierung und zusätzlichem Verbraucher, um Einspeiselimit zu vermeiden + manuelle Steuerung durch Sonderprogramme ===
'''Vorhandene Hardware:'''

* Poolpumpe, die über mehrere Stufen verfügt. Hier werden zwei verwendet.
** Pump Low: Energiesparprogramm um den Pool umzuwälzen, auch wenn nicht genug PV Leistung zur Verfügung steht. -> ca. 250W
** Pump High: Normalbetrieb wenn genug PV Überschuss zur Verfügung steht. -> ca. 800W zusätzlich
* Poolheizung: Wärmepumpe -> ca. 1,5kW elektrisch
* Nachbars Pool: Pumpe + Salzanlage +pH-Regler -> ca. 650W

'''Anforderungen:'''

* Pool muss täglich mindestens 1x umgewälzt werden.
* Im Idealfall wird der Pool > 2x umgewälzt.
* Bei genügend Überschuss soll der Pool geheizt werden. Es soll nur Sonnenstrom für die Poolheizung verwendet werden.
* Um das Einspeiselimit zu vermeiden, soll auch geheizt werden, wenn der Pool schon warm genug ist. (>28,5 °C)
* Sollte trotzdem noch das Einspeiselimit erreicht werden, soll auch der Pool des Nachbarn versorgt werden.

'''Herausforderungen:'''

* Verbraucher dürfen nur in einer gewissen Reihenfolge geschaltet werden, auch wenn der Überschuss eine andere Reihenfolge ergeben würde.
* Pumpe mit mehreren Stufen muss als zwei Consumer abgebildet werden, um die Schaltlogik in SolarForecast abzubilden. Würde die Trennung außerhalb von Solarforecast realisiert, könnte Solarforecast den Verbraucher schlechter "lernen", denn dann wäre es ein Consumer mit ständig wechselndem Verbrauch.
* Pool des Nachbarn darf nicht laut der benötigten Leistung geschaltet werden, sondern in Abhängigkeit der Einspeisebegrenzung.

In diesem Solarforcast-Device sind 16 Verbraucher definiert. Im Weiteren werden jedoch nur die verwendeten betrachtet. Da diese Reglung mittlerweile recht komplex ist, werden auch viele Dinge, die nicht SolarForcast betreffen, aber trotzdem dazu gehören, gezeigt. Es trägt zum Verständnis bei und man kann sich hier sicher Ideen holen.

'''Ergebnis:'''

In den folgenden beiden Bildern sieht man das Regelverhalten recht gut.
[[Datei:Mustertag ohne Wolken.jpg|zentriert|mini|823x823px|Wolkenloser Tag]]
Hier erkennt man gut das Einschalten der jeweiligen Verbraucher (Pump Low, Pump High, Wärmepumpe und Nachbar Pool). Die Wärempumpe schaltet erst bei 5kW Überschuss ein, da der Pool eigentlich schon warm genug ist. Sie dient "nur" dazu, das EInspeiselimit zu verhindern.Auch das Auschalten ist wieder deutlich zu erkennen. Die Regleung folgt dem Überschuss recht gut. (Die Leistungsspitzen auf dem Plateau sind normale Großverbraucher im Haus.)
[[Datei:Wechselhaft.jpg|zentriert|mini|818x818px|Wechselhafter Tag.]]
In diesem Bild sieht man das "verzweifelte" Regeln um das wechselhafte Wetter auszugleichen. Hier gibt es keine korrekte Reaktion und es wird durch die Sperrzeiten und andere Delays versucht, ein zu häufiges hin- und herschalten möglichst zu vermeiden. In Summe aber auch bei so einem Wetter ein akzeptables Verhalten.

'''Definition der Consumer:'''

'''Allgemeine Erklärungen zu den Definitionen:'''

'''asynchron=0''': Da hier die Werte des Überschusses für das Timing der Schaltvorgänge verwendet werden, darf hier keine Eventsteuerung verwendet werden. Sonst kann man nicht mehr sagen, über welchen Zeitraum der Mittelwert oder der Median gebildet wurde. Dafür wurde die Zykluszeit des SolarForecast-Device auf 60 Sekunden geändert, um die Überlegungen zu vereinfachen. Bei Event-Steuerung könnte man nicht sagen ob die letzten 10 Events in den letzten 5 Sekunden oder in den letzten 10 Minuten aufgetreten sind.

'''power=xxx''': Wurde teilweise etwas höher als der tatsächliche Wert gewählt, um nach dem Einschalten sicherzustellen, dass nicht sofort der gesamte Überschuss "verbraucht" wird und somit gleich wieder abgeschaltet wird.

'''auto=xxx''': Jeder Verbraucher benötigt sein eigenes auto-Reading, da die Automatik für die Regelung in verschiedenen Stufen ein- und ausgeschaltet werden muss.

'''dum_valve''': Dummy-Device in dem die Zustände der Regelung abgebildet werden. Notifys lesen bzw. befüllen diesen Dummy und steuern dann die Hardware bzw. wird der Dummy durch Werte aus der Hardware passend befüllt.

'''surpmeth=median_xx:''' Durch das asynchron=0 in allen Consumern und beim Generator wird von Solarforcast genau alle 60 Sekunden ein Zyklus ausgeführt. Das führt dazu, dass der Median genau über xx Minuten gebildet wird.

'''locktime=xx:xx''': Sicherheitsvorkehrung, dass nicht zu oft geschaltet werden kann. Schont die Hardware und verhindert ein Schwingen. Abhänging vom geschalteten Gerät. z.B. soll die Wärmepumpe möglichst wenig takten, um die Lebensdauer zu verlängern.

Es gibt dann auch noch einige weitere Sicherheitsvorkehrungen, um diese Regelung möglichst stabil und hardwareschonend zu gestalten. Die Schwierigkeit sind nicht die Bilderbuchtage mit einem glatten Verlauf der PV-Leistung, sondern Tage mit ständig wechselndem Überschuss in der Nähe der Schaltgrenzen.

'''swoncond= dum_valve:sf_true:{main::xxx_On}:''' Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann einzuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''swoffcond= dum_valve:sf_true:{main::xxx_Off}''': Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann auszuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''Pump Low: (consumer01)'''<syntaxhighlight lang="perl">
dum_valve:Pool+Low
aliasshort=Low
asynchron=0
auto=pump_low_auto
icon=scene_pool
interruptable=0
mintime=SunPath:0:180
mode=must
noshow=0
notafter=08:00
off="pump_low off"
on="pump_low on"
pcurr=pump_low_power
power=250
surpmeth=median_13
switchdev=dum_valve
swoffcond=dum_valve:sf_true:{main::Check_Pump_Low_Off}
swoncond=dum_valve:sf_true:{main::Check_Pump_Low_On}
swstate=pump_low:on:off
type=other
</syntaxhighlight>Erläuterungen:

* Die Pumpe soll ab Sonnenaufgang, bis 180 Minuten nach Sonnenuntergang (mintime=SunPath:0:180), bei mindestens 250W Überschuss (power=250) gestartet werden.
* Die Pumpe muss spätestens um 8:00 eingeplant werden (notafter=08:00), um das Umwälzen auch bei Schlechtwetter zu garantieren.
* Die Pumpe muss gestartet werden (mode=must) sobald sie eingeplant ist.
* swoncond sorgt dafür, dass sie vor 8:00 nur bei genügend Überschuss gestartet wird, oder es 8:00 ist. swondcond ist mit der eigentlichen Einschaltbedingung (eingeplant und mode=must) UND verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* Überschuss wird auch in swoncond mit der gewählten Methode geprüft.
* Die Pumpe darf, wenn sie gestartet wurde, auch bei fehlendem Überschuss nicht mehr unterbrochen werden. (interruptable=0)
* Die Pumpe wird am Ende der Einplanung ausgeschaltet oder wenn swoffcond erfüllt ist. swoffcond wird true, wenn eine gewisse Wassermenge umgewälzt wurde oder die Sicherheitsbedingungen nicht (mehr) erfüllt sind. swoffcond ist mit der eigentlichen Ausschaltbedingung (Planung endet) ODER verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* {'''main::'''xxx} dient dazu, um die Funktion xxx in der 99_mySolarForecastUtils.pm aus Solarforecast erreichbar zu machen.
* dum_valve:sf_true ist ein Reading, das fix 1 ist und als Vergleichswert für den in Klammern folgenden Perlcode dient. Wenn dieses Reading und der Perlcode gleich sind (1==1), ist die swoncond bzw swoffcond erfüllt.

'''Pump High: (consumer03)'''<syntaxhighlight lang="perl">
dum_valve:Pool+High
aliasshort=High
type=other power=1000 asynchron=0
auto=pump_high_auto
icon=scene_pool
pcurr=pump_high_power
switchdev=dum_valve
swstate=pump_high:on:off
mode=can
mintime=SunPath
on="pump_high on"
off="pump_high off"
surpmeth=median_5
noshow=0
locktime=180:300
interruptable=1
swoncond=dum_valve:sf_true:{main::Check_Pump_High_On}
swoffcond=dum_valve:sf_true:{main::Check_Pump_High_Off}
</syntaxhighlight>Erläuterungen:

* Pump HIgh ist die selbe Pumpe, aber eine höhere Durchflussmenge
* Der Mehrverbrauch beträgt eigentlich 800W wird hier aber mit 1000W angegeben, um eine Hysterese von ca. 200W zu erreichen und damit ein schnelles Abschalten nach dem Einschalten zu verhindern.
* Diese Stufe wird nur bei genügend Überschuss aktiviert. (mode=can)
* Diese Stufe wird bei fehlendem Überschuss unterbrochen. (interruptable=1)
* Diese Stufe wird nur während Sonnenschein eingeplant. (mintime=SunPath)
* locktime sorgt dafür, dass bei schnell wechselnden Bedingungen, nicht ständig umgeschaltet wird. -> Schonung der Pumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Heatpump: (consumer05)'''<syntaxhighlight lang="perl">
Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800 asynchron=0
icon=sani_heating_heatpump
auto=heatpump_auto
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
etotal=Pool_Pin32_monotonic_count_EnergyMeter:kWh
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=1
swoffcond=dum_valve:sf_true:{main::CheckWPOff}
</syntaxhighlight>Erläuterungen:

* Der Verbrauch ist hier wieder etwas zu hoch angegeben (1800W statt realen 1500W), um eine Hysterese zu erreichen.
* Da es sich hier um eine Wärmepumpe handelt, die nicht getaktet werden sollte, ist die locktime in beide Schaltrichtungen mit 10 Minuten relativ hoch.
* Die Ermittlung des Medians ist mit 13 Minuten recht lang, um den Überschuss über lange Zeit zu glätten, damit möglichst selten geschaltet wird. Diese 13 Minuten in Kombination mit der Locktime und der Hysterese führten bei dieser Anlage bisher dazu, dass höchstens 5 Zyklen am Tag geschaltet wurden. -> Hier kann das individuelle Schaltverhalten optimiert werden. Besseres Verfolgen des Überschusses vs. weniger Taktungen der Wärmepumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Nachbars Pool: (consumer07)'''<syntaxhighlight lang="perl">
Shelly_Plug_S_1:Kurz+Pool
aliasshort=Kurz
type=other power=650 asynchron=0
icon=scene_pool
auto=pool_kurz_auto
pcurr=power:W
switchdev=dum_valve
swstate=pool_kurz:on:off
mode=can
mintime=SunPath
on="pool_kurz on"
off="pool_kurz off"
surpmeth=median_13
noshow=0
interruptable=1
locktime=600:300
swoncond=dum_valve:sf_true:{main::Check_Pool_Kurz_On}
swoffcond=dum_valve:sf_true:{main::Check_Pool_Kurz_Off}
</syntaxhighlight>Erläuterungen:

* Dieser Consumer dient als Einspeisebegrenzungsschutz und wird aktiviert, sobald sich der Überschuss der Einspeisegrenze nähert. -> siehe '''99_mySolarForecastUtils.pm'''
* Verbraucher kann recht träge geschaltet werden. (surpmeth=median_13 und locktime=600:300)
* Consumer wird ausgeschaltet wenn ein gewisser Überschuss unterschritten wird und somit die Einspeisegrenze wieder weit genug weg ist. -> siehe '''99_mySolarForecastUtils.pm'''
'''99_mySolarForecastUtils.pm'''

Hier sind die Funktionen, die für diese Regelung verwendet werden, der Übersichtlichkeit halber in einzelnen Blöcken mit Erklärungen dargestellt.<syntaxhighlight lang="perl">
package main;
use strict;
use warnings;

my $pool_dummy = 'dum_valve';
my $pool_temperature = 'Pool_Temp';
my $flow_sensor = 'Pool_Pin_A0';
my $water_counter_l1 = 'pump_l1_hc';
my $water_counter_l2 = 'pump_l2_hc';
my $target_temp = 28.4; # maximum temperature for heating, without infeed limit
my $pool_kurz_sw_hofb = 'PwSw_Schalter'; # Homematic switch at pool neighbour
my $pool_kurz_sw_kurz = 'Shelly_Plug_S_1'; # Shelly switch for pool Kurz at home

my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;

my $switch_delay = 160; # just under three minutes

sub
SolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

</syntaxhighlight>

* Hier werden die IDs der Geräte definiert, um über sprechende Namen darauf zugreifen zu können.
* Einige Devices und Parameter, die immer wieder gebraucht werden sind hier angegeben.
* sprintf wird verwendet um sicherzustellen, dass die IDs zweistellig sind. z.B. 3 -> 03

'''Pump Low'''<syntaxhighlight lang="perl">
###################
### Pumpe - LOW ###
###################

sub
Check_Pump_Low_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'surpmethResult','');
my $nom_power = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'power','');
my ($min, $hour) = (localtime())[1,2];
my $timer = 0;
if($hour > 8 || ($hour == 8 && $min >= 0)){$timer=1;}

if(ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ($surplus > $nom_power
|| $timer
)
)
{
return 1;}
else
{
return 0;}
}

sub
Check_Pump_Low_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount > $desired_amount_l1)
&& (ReadingsVal($pool_dummy,"pump_high","on") eq "off" && ReadingsAge($pool_dummy,"pump_high",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{
return 1;
}else{
return 0;
}
}

</syntaxhighlight>Einschalten:

* Es wird der errechnete Wert für den Überschuss von SolarForecast verwendet und auch der benötigte Überschuss aus dem Consumer ausgelesen.
* Das Einschalten wird erst durch erfolgreiche Prüfung der Hardwarevoraussetzungen erlaubt. -> Das Motorventil steht richtig und es ist kein Sonderbetrieb (Reinigung, Massage, Winter, o.ä.) aktiv.
* Es muss entweder genügend Überschuss vorhanden sein oder es ist 8:00.

Ausschalten:

* Wenn der Badebetrieb aktiv ist (bath_mode==1, [bei Außentemperatur > 24°C]) wird nach 90m³ Gesamtumwälzung ausgeschaltet.
* Wenn der Badebetrieb nicht aktiv ist (bath_mode==0, [bei Außentemperatur < 20°C]) wird bereits nach 42m³ Gesamtumwälzung ausgeschaltet.
* Prüfung, ob Pump High schon aus ist. Sollte durch die Logik gar nicht möglich sein, aber es könnte manuell oder durch einen (Logik-)Fehler trotzdem eingeschaltet sein.
* Prüfung, ob alle Hardware-Funktionen in einem für die Automatik geeigneten Zustand sind.
* Es wird auch geprüft, ob Pump High seit mindestens 3 Minuten aus ist, um zu verhindern, dass wegen fehlendem Überschuss gleich mehrere Geräte ausgeschaltet werden.
* Da die Zykluszeit 60 Sekunden ist, führen die 160 Sekunden dazu, dass nach drei Minuten(180 Sekunden) ein definierter Wert gilt. Mit 180 Sekunden könnte es manchaml eine Minute mehr sein.

'''Pump High'''<syntaxhighlight lang="perl">
####################
### Pumpe - HIGH ###
####################

sub
Check_Pump_High_On{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount < $desired_amount_l2)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_low","off") eq "on" && ReadingsAge($pool_dummy,"pump_low",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

sub
Check_Pump_High_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;

if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}
if(($amount > $desired_amount_l2)
&& (ReadingsVal($pool_dummy,"heatpump","on") eq "off" && ReadingsAge($pool_dummy,"heatpump",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs noch nicht erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob Pump Low schon seit mindestens 3 Minuten aktiv ist. (sollte eigentlich immer der Fall sein, wenn die Automatik für Pump High aktiv ist)

Ausschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs bereits erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob die Wärmepumpe schon seit mindestens 3 Minuten aus ist. Ermöglicht drei Minuten lang, den Median für den Überschuss zu aktualisieren.

'''Wärmepumpe'''<syntaxhighlight lang="perl">
##################
### Wärempumpe ###
##################
sub
CheckWPOn(){
my $name = 'energy_mgmt';
my $surplus_on = 5000; # minimum surplus to avoid infeed limit with heatpump
my $surplus_restart = 3000; # minimum surplus to re-enable heatpump, when avoidung infeed limit and a big consumer turned the hp off

my $planstate = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'planstate','');
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if ($planstate =~ /^([^:]+)/) {
$planstate = $1;
}

if(ReadingsVal($flow_sensor,"reading","off") eq "on"
&& (ReadingsVal($pool_dummy,"special_function","") eq "none"
|| ReadingsVal($pool_dummy,"special_function","") eq "party"
)
&& ReadingsVal($pool_dummy,'heat_protection','on') eq "off"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_high","off") eq "on" && ReadingsAge($pool_dummy,"pump_high",0) > $switch_delay)
&& (ReadingsVal($pool_temperature,"temperature",30) < $target_temp
|| (ReadingsVal($pool_temperature,"temperature",15) >= $target_temp
&& ( $surplus > $surplus_on
|| (($planstate eq "replanned") && ($surplus > $surplus_restart))
)
)
)
)
{return 1}
else
{return 0}
}

sub
CheckWPOff{
my $name = 'energy_mgmt';
my $surplus_off = 1000; #minimum surplus to keep heatpump on, when avoiding infeed limit

my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if((ReadingsVal($flow_sensor,"reading","on") eq "off"
|| !((ReadingsVal($pool_dummy,"special_function","") eq "none")
|| (ReadingsVal($pool_dummy,"special_function","") eq "party")
)
|| ReadingsVal($pool_dummy,'heat_protection','off') eq "on"
|| ReadingsVal($pool_dummy,"valve_position","") ne "normal"
|| ((ReadingsVal($pool_temperature,"temperature",15) > $target_temp)
&& ($surplus < $surplus_off)
)
)
&& (ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob Flussensor ein. (Pool_pin_A0) -> Wasser fließt durch die Wärmepumpe.
* Prüfung, ob Pool in Normal- oder Partybetrieb ist und das Ventil in Normalposition ist. In beiden Fällen läuft Pump High.
* Einschalten wenn genug Überschuss da ist und die Temperatur <28.4°C ist oder wenn über 5000W Überschuss (Einspeisebegrenzung bei 5900W) da ist, egal wie warm der Pool ist.
* Sonderfall: Wenn die Wärmepumpe durch einen/mehrere Großverbrucher "kurz" ausgeschaltet wurde (swoffcond) wird sie ausgeplant. Ein Notify plant sie wieder ein. Wenn das passiert, soll die Wärmepumpe aber wieder bei 3000W Überschuss gestartet werden, um die Energie noch weiter zu nutzen bis der Überschuss unter 1000W fällt. (Hysterese von 500W, da die WP nur 1500W braucht)

Ausschalten:

* Ausschalten sobald hardwaremäßig irgendetwas faul ist. (Betriebsart, Ventilstellung, Durchfluss)
* Ausschalten wenn kein Überschuss. (interruptable=1)
* Wenn Wassertemperatur über 28,5°C und der Überschuss kleiner als 1000W ist.
* Nur schalten, wenn Wärmepumpe läuft und seit mindestens 3 Minuten läuft (Sicherheit). Das verhindert das erneute Triggern des Notifys, wenn die Pumpe schon aus ist. Sollte nicht passieren, aber sicher ist sicher.

'''Nachbar Pool'''<syntaxhighlight lang="perl">
###################
### Pool - KURZ ###
###################
sub
Check_Pool_Kurz_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus > 3000)
&& ((ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) >160) || ReadingsVal($pool_dummy,'heat_protection','off') eq 'on' ))
{return 1}
else
{return 0}
}

sub
Check_Pool_Kurz_Off{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus < 1000 )
&& (ReadingsVal($pool_dummy,"pool_kurz","off") eq "on" && ReadingsAge($pool_dummy,"pool_kurz",0) >160))
{return 1}
else
{return 0}
}
</syntaxhighlight>Einschalten:

* Überschuss ist nahe der Einspeisegrenze (5900W) und Wärmepumpe läuft seit mindestens 3 Minuten. Es wird schon bei 3000W eingeschaltet, um dem Nachbarn etwas Gutes zu tun ;-)

Ausschalten:

* Überschuss ist unter 1000W. -> Um noch Reserven für den eigenen Verbrauch zu haben.

'''Hilfsfunktionen'''

'''ctrlUserExitFn'''

Hier erfolgt nach jedem Zyklus die Festlegung der verschiedenen Automatikmodi.<syntaxhighlight lang="perl">
#############################################################
##################### Exit Function #########################
#############################################################
my $ctrl_dummy = "dum_valve"; # dummy device for pool-control
my $automatic = ReadingsNum($ctrl_dummy,"sf_automatic",1);

if($automatic){

my $pump_low_state = ReadingsVal($ctrl_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe

my $pump_high_state = ReadingsVal($ctrl_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe

my $heatpump_state = ReadingsVal($ctrl_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
my $pool_heat_protection = ReadingsVal($ctrl_dummy,'heat_protection','on');

my $pool_kurz_state = ReadingsVal($ctrl_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools

my $pump_low_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'surpmeth', '');
if ($pump_low_delay =~ /_(\d+)/) {
$pump_low_delay = int(($1/2 + 1) * 60);
Log3 ("SolarForecast", 1, "SolarForecast: pump_low_delay: $pump_low_delay");
} else {
$pump_low_delay = 220;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_low is: $pump_low_delay, but must be given as method_number, using fallback value");
}

my $pump_high_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'surpmeth', '');
if ($pump_high_delay =~ /_(\d+)/) {
$pump_high_delay = int(($1/2 + 1) * 60);
} else {
$pump_high_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_high is: $pump_high_delay, but must be given as method_number, using fallback value");
}

my $heatpump_delay = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'surpmeth', '');
if ($heatpump_delay =~ /_(\d+)/) {
$heatpump_delay = int(($1/2 + 1) * 60);
} else {
$heatpump_delay = 290;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for heatpump is: $heatpump_delay, but must be given as method_number, using fallback value");
}

my $pool_kurz_delay = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'surpmeth', '');
if ($pool_kurz_delay =~ /_(\d+)/) {
$pool_kurz_delay = int(($1/2 + 1) * 60);
} else {
$pool_kurz_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pool_kurz is: $pool_kurz_delay, but must be given as method_number");
}

############################
# Überhitzungsschutz aktiv #
############################

if($pool_heat_protection eq 'on'){
if($heatpump_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 0");
}
if($heatpump_state eq "on"){
fhem("set $ctrl_dummy heatpump off")
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pool_kurz_delay && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pump_high_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $pump_high_delay && $pool_kurz_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
##################################
# Überhitzungsschutz nicht aktiv #
##################################
}else{
if($heatpump_auto == 0 && $heatpump_state eq "off"){
if($pool_kurz_state eq "on"){
fhem("set $ctrl_dummy pool_kurz off");
}
if($pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $heatpump_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $heatpump_delay && $heatpump_auto == 0 && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "on" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pool_kurz_delay && $pump_high_state eq "on" && $pool_kurz_auto == 0 && $pump_high_auto == 1 && $heatpump_auto == 1){
# pump_high muss on sein, da sonst die automatik ausgeschaltet wird wenn die pumpe gerade interrupted ist.
# Bei unterschiedlichen Medianlängen ist es möglich, dass WP ein ist und pump_high abschaltet wegen surplus == 0
# Nachbarpool würde auf EIN warten, aber pump_high dürfte nicht wieder einschalten, obwohl genügend Überschuss da ist.
fhem("set $ctrl_dummy pump_high_auto 0");
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $heatpump_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $heatpump_delay && $pool_kurz_auto == 1 && $heatpump_auto == 0 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "off" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pump_high_delay && $heatpump_auto == 1 && $pump_high_auto == 0 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $heatpump_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 1 && $pool_kurz_auto == 0){
# heatpump muss aus sein, da sonst vor Ablauf der Locktime die Automatik ausgeschaltet wird und die WP nicht mehr ausschalten kann.
fhem("set $ctrl_dummy heatpump_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
}
}
#################################################
# Check hardware-state vs. reading-state
# re-trigger notify
#################################################
my $delay_retrigger = 100; #delay time to wait until re-trigger the notify

if(ReadingsVal($ctrl_dummy,'pool_kurz','on') eq 'off' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'on'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: off");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-off must be re-triggered");
DebianMail('clemens@familie-hofbauer.at','Notify Pool Kurz',"Notify hat nicht ausgeschaltet -> re-trigger");
}elsif(ReadingsVal($ctrl_dummy,'pool_kurz','off') eq 'on' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','on') eq 'off'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: on");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-on must be re-triggered");
DebianMail('clemens@familie-hofbauer.at','Notify Pool Kurz',"Notify hat nicht eingeschaltet -> re-trigger");
}elsif((ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_on' || ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_off') && ReadingsAge($pool_kurz_sw_kurz,'state',0) > $delay_retrigger){
# state not clear
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz state unclear");
DebianMail('clemens@familie-hofbauer.at','Status Pool Kurz unklar',"Status HM-Schalter set_xx");
}

}
1;
</syntaxhighlight>
'''Erläuterungen:'''

* '''Verzögerungen der einzelnen Stufen:'''
** Die delays der einzelnen Stufen werden aus den surpmethods berechnet. Das dient dazu, dass der Median mit den Werten nach dem ein-/ausschalten des vorheriegen Verbrauchers bis zur Hälfte + einen Wert gefüllt wird und somit sicher das Umschalten des vorherigen Verbrauchers den Median nicht mehr beeinflusst.
* '''Überhitzungsschutz:'''
** Da durch die Wärmepumpe Überschuss "verheizt" wird, der durch das Einspeiselimit gar nicht produziert würde, kann es vorkommen, dass der Pool unangenehm warm wird.
** Um das zu vermeiden gibt es ein Reading, welches gesetzt wird, wenn der Pool eine gewisse Temperatur überschreitet. Dieses Setzen und Zurücksetzen erfolgt mit einer Hysterese von 0.2°C, um ein Takten der Wärmepumpe zu verhindern. Diese 0.4°C sind bei dieser Wassermenge einige Stunden.
** Wenn der Überhitzungsschutz aktiv ist, wird die Wärmepumpe in der Kette übersprungen.
** Wenn sich der Hitzeschutz während des Betriebs ändert, wird die Wärmepumpe bzw. der Pool vom Nachbarn passend ausgeschaltet und die Modi entsprechend gesetzt.
* '''On-chain:'''
** Wenn am Morgen Pump Low seit $pump_low_delay aktiv ist und alle folgenden Consumer noch nicht, dann wird die nächste Stufe freigegeben. -> Pump High
** Wenn Pump High seit $pump_high_delay aktiv ist und alle folgenden Consumer noch nicht, wird die Wärmepumpe freigegeben. -> Heatpump
** Wenn die Wärmepumpe seit $heatpump_delay aktiv ist und der letzte Consumer noch nicht, wird der letzte Verbraucher freigegeben. -> Pool Kurz Gleichzeitig wird die Automatik für Pump High ausgeschaltet, da dieser Verbraucher erst unterbrochen werden darf wenn die Wärmepumpe aus ist!
** Wenn der letzte Verbraucher aktiviert ist, wird die Automatik der Wärmepumpe deaktiviert, da ja zuerst der letzte Verbraucher (Pool Kurz) wieder ausgeschaltet werden muss, bevor der vorletzte (Wärmepumpe) wieder ausgeschaltet werden darf. Da es keinen nachfolgenden Verbraucher mehr gibt, kann hier auf ein delay verzichtet werden, da es nicht passieren kann, dass zwei Verbraucher wegen sehr hohem Überschuss unmittelbar hintereinander geschaltet werden können.
[[Datei:Poolsteuerung mit unterschiedlichen Automatikmodi.jpg|alternativtext=Poolsteuerung|mini|Consumer der Poolsteuerung|500x500px]]
'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von fehlendem Überschuss jederzeit unterbrochen werden kann und der "folgende" Consumer, der auf das Einschalten wartet. Pump Low ist immer im Automatikmodus, da diese nie unterbrochen wird. (mode=must, interruptable=0)

* '''Off-chain:'''
** Wenn der letzte Verbraucher seit mindestens der delay-Zeit aufgrund von fehlendem Überschuss inaktiv war, im Automatikmodus ist und der vorherige Verbraucher nicht im Automatikmodus ist, wird der vorherige Verbraucher in den Automatikmodus geschaltet und wartet jetzt auch auf das Ausschalten. Wenn der Überschuss steigt, springt man wieder in die on-chain und der letzte Verbraucher wird eingeschaltet und die Automatik des vorletzten Verbrauchers deaktiviert.
** Wenn die Wärmepumpe seit mindestens der delay-Zeit aus ist, sich im Automatikmodus befind und Pump High noch nicht im Automatikmodus ist, wird die Automatik für den Nachbarpool ausgeschaltet, da er ja jetzt nicht mehr einschalten darf, da zuerst die Wärmepumpe ein sein müsste. Die Automatik von Pump High wird wieder aktiviert, da diese jetzt auf das Ausschalten wartet. Steigt der Überschuss wieder, wird in den entsprechenden On-chain Zweig gesprungen.
** Wenn Pump High mindestens die delay-Zeit aus ist, wird die Automatik der Wärmepumpe deaktiviert, da diese ja erst einschalten darf, wenn Pump High wieder läuft. Steigender Überschuss führt wieder zum aktivieren von Pump High und zum Sprung in den entsprechenden On-chain Zweig.
** Wenn Pump Low ausgeschaltet wird, wird sofort die Automatik für Pump High ausgeschaltet, da durch das spätere Ausschalten von (der evtl. wieder eingeschalteten) Pump High, hardwaremäßig wieder Pump Low aktiviert wird, aber durch SolarForecast nie ausgeschaltet wird, da Pump Low vor ein paar Minuten ja schon logisch ausgeschaltet wurde.

'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von neuem Überschuss jederzeit wieder gestartet werden kann und der "vorherige" Consumer, der auf das Ausschalten wartet.

* '''Synchronisation Hardware vs. Reading:'''Manchmal passiert es, dass durch die etwas aufwendigen Umschaltprozesse die Hardware dem Reading nicht folgt/folgen kann. Evtl. Gründe sind Funkunterbrechung, verzögerte Umschaltung usw. Daher wird bei jedem Zyklus der Status geprüft und evtl. das event nochmal getriggert, um die Umschaltung erneut auszuführen. 

'''Hilfs-Notifys für die Automatik'''

Da durch das Verwenden von swoffcond die Verbraucher beim Ausschalten auch ausgeplant werden, aber eigentlich "nur" unterbrochen werden sollen, müssen sie wieder neu eingeplant werden. Dazu sind notifys nötig. Wichtig: IDs müssen zweistellig angegeben werden!

Wärmepumpe:<syntaxhighlight lang="perl">
dum_valve:heatpump:.off sleep 10; set energy_mgmt consumerNewPlanning 05
</syntaxhighlight>
Nachbar Pool:<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.off sleep 10; set energy_mgmt consumerNewPlanning 07
</syntaxhighlight>

'''Eine Pumpe mit einem Energiezähler als zwei Consumer verwenden'''

Die verwendete Pumpe hat vier Betriebsarten mit unterschiedlichen Leistungen. Da sie als zwei Consumer abgebildet wird, führt das dazu, dass die Leistung fälschlicherweise von SolarForecast auch zweimal gezählt wird. Die Lösung sind Dummy-Readings, welche die Leistungsdaten passend auseinander rechnen.<syntaxhighlight lang="perl">
Pool_Strom_Pumpe:Pool_Pin31_monotonic_count_PowerCurrent:.* {
my $power = $EVTPART1;
my $pump_low = ReadingsVal('dum_valve','pump_low','off');
my $pump_high = ReadingsVal('dum_valve','pump_high','off');
my $power_low_sim = 250;

if($pump_low eq "on" && $pump_high eq "on"){
my $power_low = $power_low_sim; #fiktiver Verbrauch der niedrigen Stufe
my $power_high = $power - $power_low_sim;
fhem("set dum_valve pump_low_power $power_low");
fhem("set dum_valve pump_high_power $power_high");
}
elsif($pump_low eq "on" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power $power");
fhem("set dum_valve pump_high_power 0");
}
elsif($pump_low eq "off" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power 0");
}elsif($pump_low eq "off" && $pump_high eq "on"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power $power");
}
}
</syntaxhighlight>
Erläuterungen:

* Es sind alle vier Möglichkeiten der zwei Pumpenlevel abgebildet.
* Wenn die Automatik deaktiviert ist und die Level 1-4 von extern geschaltet werden, zählen sie dadurch korrekterweise nicht zu diesen beiden Consumern.

'''Notifys für das hardwaremäßige Schalten der Consumer'''

Es werden einige Notifys verwendet, die die Umsetzung vom Dummy-Device auf die Hardware erledigen, da ein logisches Ein teilweise hardwaremäßig einige Dinge erfordert.

Notify für Pump Low:<syntaxhighlight lang="perl">
dum_valve:pump_low:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 60; set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin14 off; sleep 5; set Pool_Pin12 off; sleep 15; set Pool_Pin25 off");
}else{
Log3 ("Pool", 4, qq{Notify Level1 - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterungen:

* Beim Einschalten ist es nötig für eine Minute Pump High zu aktivieren, um Luft aus der Elektrolysezelle zu spülen, bevor Pump Low aktiv sein darf. (Pin26 und Pin25 sind die Steuerpins auf der Interfacekarte der Pumpe für die beiden Level.)
* Beim Ausschalten werden zuerst die Salzanlage (Pin14) und die pH-Anlage (Pin12) deaktiviert, damit noch 15 Sekunden lang die Elektrolysezelle mit frischem Wasser gespült wird, um das verbleibende Chlor auszuspülen. 
Notify für Pump High:<syntaxhighlight lang="perl">
dum_valve:pump_high:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 1; set Pool_Pin25 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}else{
Log3 ("Pool", 4, qq{Notify Level 2- parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Da die Interfacekarte immer auf den höchsten Level reagiert, wird beim Umschalten zuerst Pump High aktiviert und nach einer Sekunde Pump Low deaktiviert, um ein "stufenloses" (ohne Ausschalten) Umschalten zu ermöglichen. Beim Ausschalten genauso.

Notify für die Wärmepumpe:<syntaxhighlight lang="perl">
dum_valve:heatpump:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin6 on");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin6 off");
}else{
Log3 ("Pool", 4, qq{Notify heatpump - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Hier reicht ein dirketes Übernehmen aus dem Dummy.

Notify für den Nachbar-Pool:<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.* {
if($EVTPART1 eq "on" && ReadingsVal("Shelly_Plug_S_1","state","on") eq "off"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 on\")}}; sleep 5; set PwSw_Schalter on");
}elsif($EVTPART1 eq "off" && ReadingsVal("Shelly_Plug_S_1","state","off") eq "on"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 off\")}}; sleep 5; set PwSw_Schalter on");
}else{
Log3 ("Pool", 4, qq{Notify Pool Kurz - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung

* Da hier eine Pumpe durch einen 3-poligen Umschalter zwischen zwei Hausanspeisungen umgeschaltet wird, ist es wichtig, dass die Pumpe dazwischen '''gesichert''' zum Stehen gebracht wird! Sonst führt die rotierende Pumpe als Generator zu einem gewaltigen Kurzschluss mit der "fremden" Phase. War nicht schön ...

'''Sonderprogramme für den Poolbetrieb'''

Hier ist das Aus- und Einschalten der Solarforcast-Automatik zu sehen. Es werden alle Stati gespeichert. Danach kann von beliebigen "Sonderfunktionen" (Reinigung des Filters, Massagefunktion, usw.) auf die Hardware zugegriffen werden. Wenn wieder in den Automatikmodus zurückgewechselt wird, wird hardwaremäßig wieder der Zustand der Automatik von vorher hergestellt, die Stati wieder zurück geschrieben und die Automatik wieder aktiviert.<syntaxhighlight lang="perl">
##############################################
# Status speichern und Automatik ausschalten #
##############################################
sub PoolAutoOff{
my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;
my $sf = 'energy_mgmt';

# my $pump_low_state = ReadingsVal($valve_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe
# my $pump_high_state = ReadingsVal($valve_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe
# my $heatpump_state = ReadingsVal($valve_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($sf, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
# my $pool_kurz_state = ReadingsVal($valve_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools
fhem("set $valve_dummy pump_low_auto 0");
fhem("set $valve_dummy pump_high_auto 0");
fhem("set $valve_dummy heatpump_auto 0");
fhem("set $valve_dummy pool_kurz_auto 0");
fhem("setreading $valve_dummy sf_automatic 0");
fhem("setreading $valve_dummy last_auto_pump_low $pump_low_auto");
fhem("setreading $valve_dummy last_auto_pump_high $pump_high_auto");
fhem("setreading $valve_dummy last_auto_heatpump $heatpump_auto");
fhem("setreading $valve_dummy last_auto_pool_kurz $pool_kurz_auto");

my $last_pump_level_1 = ReadingsVal($valve_dummy,"pump_low","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"pump_high","off");
my $last_pump_level_3 = ReadingsVal($pump_level_3,"value","off");
my $last_pump_level_4 = ReadingsVal($pump_level_4,"value","off");
my $last_heatpump = ReadingsVal($valve_dummy,"heatpump","off");
fhem("setreading $valve_dummy last_pump_level_1 $last_pump_level_1");
fhem("setreading $valve_dummy last_pump_level_2 $last_pump_level_2");
fhem("setreading $valve_dummy last_pump_level_3 $last_pump_level_3");
fhem("setreading $valve_dummy last_pump_level_4 $last_pump_level_4");
fhem("setreading $valve_dummy last_heatpump $last_heatpump");
}

##########################################
# Status laden und Automatik einschalten #
##########################################
sub PoolAutoOn{
my $last_pump_level_4 = ReadingsVal($valve_dummy,"last_pump_level_4","off");
my $last_pump_level_3 = ReadingsVal($valve_dummy,"last_pump_level_3","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"last_pump_level_2","off");
my $last_pump_level_1 = ReadingsVal($valve_dummy,"last_pump_level_1","off");
my $last_heatpump = ReadingsVal($valve_dummy,"last_heatpump","off");
fhem("set $pump_level_4 $last_pump_level_4");
fhem("set $pump_level_3 $last_pump_level_3");
fhem("set $pump_level_2 $last_pump_level_2");
if($last_pump_level_1 eq "on" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_2 on; sleep 1; set $pump_level_1 $last_pump_level_1; sleep 28; set $pump_level_2 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "on" && $last_pump_level_2 eq "on" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "off" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}
fhem("sleep 10; set $heatpump $last_heatpump");
fhem("setreading $valve_dummy last_pump_level_1 none");
fhem("setreading $valve_dummy last_pump_level_2 none");
fhem("setreading $valve_dummy last_pump_level_3 none");
fhem("setreading $valve_dummy last_pump_level_4 none");
fhem("setreading $valve_dummy last_heatpump none");
fhem("setreading $valve_dummy valve_position normal");
my $last_auto_pump_low = ReadingsVal($valve_dummy,"last_auto_pump_low",0);
my $last_auto_pump_high = ReadingsVal($valve_dummy,"last_auto_pump_high",0);
my $last_auto_heatpump = ReadingsVal($valve_dummy,"last_auto_heatpump",0);
my $last_auto_pool_kurz = ReadingsVal($valve_dummy,"last_auto_pool_kurz",0);
fhem("set $valve_dummy pump_low_auto $last_auto_pump_low");
fhem("set $valve_dummy pump_high_auto $last_auto_pump_high");
fhem("set $valve_dummy heatpump_auto $last_auto_heatpump");
fhem("set $valve_dummy pool_kurz_auto $last_auto_pool_kurz");
fhem("setreading $valve_dummy last_auto_pump_low none");
fhem("setreading $valve_dummy last_auto_pump_high none");
fhem("setreading $valve_dummy last_auto_heatpump none");
fhem("setreading $valve_dummy last_auto_pool_kurz none");
}
</syntaxhighlight>Erläuterungen:

* pump_level_1 ist Pump Low, pump_level_2 ist Pump High, pump_level_3 und pump_level_4 sind Sonderfunktionen (Filterreinigung, Massage)
* Beim Wiedereinschalten von Pump Low ist es wieder nötig kurz Pump High zu aktivieren, um Luft auszuspülen.
* Es wird der Zustand von Solarforecast gespeichert und danach auf die Hardware geschrieben. -> Stellt sicher, dass nach dem Einschalten der Automatik der logical switchstate zum physical switchstate passt.

== Tips & Tricks ==
* Interruptable verhält sich völlig anders, wenn der Perlcode 1 oder 0 liefert, als wenn man 1 oder 0 in der Config hinterlegt. -> siehe commandref
* Rückgabewert bei swoncond und swoffcond wird mit dem Readingswert verglichen und nicht dirket verwendet. Bsp. wenn das Reading 100 enthält muss auch der Rückgabewert des Perlcodes 100 liefern, um true zu ergeben.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2025-11-10T15:08:46Z

All-Ex: /* PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) */

{{Baustelle}}
{{Hinweis|Die vorliegende Wiki-Seite befindet sich im Aufbau.}}
{{Infobox Modul
|ModPurpose=Solarprognose und Verbrauchersteuerung
|ModType=d
|ModCmdRef=76_SolarForecast
|ModFTopic=117864
|ModForumArea=Solaranlagen
|ModTechName=76_SolarForecast.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
[[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung|SolarForecast]] ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:
[[Datei:sfc1.png|right|thumb|300px|grafische Ansicht SolarForecast]]

::* zur Gewinnung solarer Prognosewerte können die SolCast API, OpenMeteo API, Forecast.Solar API, Victron VRM Portal API oder alternativ DWD Stahlungswerte-Stationen verwendet werden

::* optionale KI Unterstützung der PV-Prognose bei Verwendung von geeigneten Solar-API's

::* es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose sowie SoC Prognose (bei Batterie-Integration) erstellt

::* Wetterdaten werden über DWD Wetter-Stationen oder verschiedene API integriert. Es können verschiedene API zur Gewinnung von Solar- und Wetterdaten kombiniert werden.

::* Sprachensupport EN / DE

::* die Prognosedaten, Wetterdaten, Verbraucherplanungen und die aktuellen Energieflüsse werden in umfangreich anpassbaren integrierten Grafiken dargestellt

::* es wird keine externe SQL-Datenbank benötigt, die Datenhaltung erfolgt in einer Memory basierten Cachedatenbank inkl. einer Filesystempersistenz zur Datensicherung und Wiederherstellung beim FHEM-Restart

::* die Integration von Geräten wie Wechselrichter, Energy Meter, Batterien, Wetterstationen oder Verbrauchern ist offen und universell gestaltet und bietet dem Anwender maximale Freiheiten bei der Einrichtung seines individuellen Solardatensystems.

::* eine Integration von bis zu 4 Inverter und Smartloader (DC-DC Batterieladegeräte) ist möglich

::* eine Integration von bis zu 3 nicht PV-Energieerzeugern wie BHKW, Windrädern oder Notstromaggregaten ist möglich

::* eine integrierte und umfangreich anpassbare Verbrauchersteuerung vereint die PV Prognose basierte Einplanung der Verbraucher mit der Möglichkeit die Verbraucher durch das Modul schalten zu lassen und dadurch auf PV Erzeugungsschwankungen automatisch dynamisch zu reagieren

::* Einbindung von bis zu drei Batteriespeichersystemen

::* Bereitstellung von Leitwerten zur optimalen Einstellung/Steuerung von Batteriespeichersystemen

::* trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzererlebnis geboten

'''Abgrenzung:''' Das Modul 76_SolarForecast ist nicht zu verwechseln mit der SQL-basierten (DbLog) Prognose-Lösung mit Kostal Plenticore Wechselrichtern, die auf der eigenen Seite '''[[Kostal_Plenticore_10_Plus]]''' behandelt wird. Diese Lösung beschreibt kein monolithisches Modul, sondern basiert auf einer orchestrierbaren Zusammenstellung individueller Perl Programmbausteine.

Im vorliegenden Wiki-Beitrag wird ausschließlich das Modul 76_SolarForecast behandelt.

== Rahmenbedingungen und Voraussetzungen ==

Das Wiki gibt allgemeingültige und teilweise sehr spezifische bzw. tiefgehende Informationen und Handlungsempfehlungen zum SolarForecast Modul. Die dargestellten Informationen beziehen sich auf den zum Zeitpunkt der Wiki-Erstellung vorhandenen Entwicklungsstand des Moduls. Durch die stetige Weiterentwicklung können sich Abweichungen zum beschriebenen Inhalt ergeben oder zur Obsoleszenz dieser Inhalte führen.

Vergleiche deshalb die Informationen immer mit der aktuellen Befehls-Referenz zum Modul!

== Definition ==
Ein SolarForecast Device wird mit dem Befehl

define <Name> SolarForecast

angelegt. Nach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert. Alle Attribute und Readings die eine Einstellung der Anlage bewirken, sind mit dem Präfix "setup" versehen.

Die Verwendung von setup-Readings gestattet es die Anlagenparameter dynamisch im Betrieb zu verändern. So kann mit

set <Name> setupStringAzimuth bzw.
set <Name> setupStringDeclination

die Ausrichtung und der Neigungswinkel der PV-Module ständig angepasst werden, was zum Beispiel bei einer dem Sonnenstand nachgeführten Anlage von Bedeutung ist.

Die abgefragten Einstellungen während des Dialoges sind ausführlich in den entsprechenden Attributen bzw. Set-Kommandos erläutert. Die benötigten Informationen sind anhängig von der gewählten Prognose-API und können im Umfang variieren.

[[Datei:Screenshot 2024-09-21 213257.png|right|thumb|400px|Anlagenprüfung über Drucktaste in der Kopfgrafik]]

Sobald alle verlangten Einstellungen vorgenommen sind, sollte eine Anlagenprüfung mit

set <Name> plantConfiguration check

oder über die angebotene Drucktaste in der Grafik durchgeführt werden. Es wird eine Plausibilitätsprüfung vorgenommen und das Ergebnis sowie eventuelle Hinweise bzw. Fehler ausgegeben.
Die Prüfung kann beliebig wiederholt werden und sollte sich bei jeder Einstellungsänderung der Anlage durchgeführt werden. Dadurch wird die Wahrscheinlichkeit von fehlerhaften Einstellungen minimiert.

Neben den grundlegenden Einstellungen können im Device weitere sekundäre Anlagenkomponenten wie Batteriesystem(e) (Attribut setupBatteryDev1 - setupBatteryDev3), weitere Wetter-Devices (Attribut setupWeatherDev1 - setupWeatherDev3) oder sonstige Erzeuger (z.B. BHKW, Winderzeugung, Notstromaggregat) integriert werden (Attribut setupOtherProducer01 - setupOtherProducer03).

Die verlangten Parameter der Anlage werden in der Online-Hilfe umfassend beschrieben und deren Funktion erschließt sich zum größten Teil selbst. Dennoch soll nachfolgend auf einige Punkte im Zusammenhang der Einrichtung eingegangen werden.

 
=== Hinweise zur Struktur der Attribute ===

Durch die umfangreichen Funktionen des Moduls würde bei Nutzung der im FHEM herkömmlich vorhandenen Attributstruktur die Anzahl der benötigten Attribute extrem stark steigen und nicht sinnvoll genutzt werden können. Deshalb gibt es neben den ''gewöhnlichen'' Attributen mit einfachen Werteauswahlmöglichkeiten oder Eingaben (z.B. ctrlDebug, ctrlSpecialReadings) sogenannte ''zusammengesetzte'' Attribute, deren Inhalt durch '''Schlüssel=Wert Paare''' gebildet wird und dadurch deutlich mehr Funktionen und Informationen transportieren als ein gewöhnliches Attribut.

Für zusammengesetzte Attribute besteht die zusätzliche Möglichkeit, gewünschte Änderungen der Schlüssel=Wert Paare selektiv vornehmen zu können, ohne das gesamte Attribut aufrufen und ändern zu müssen. Die Vorgang, der vor allem für programmtechnische Manipulationen gedacht ist, kann durch eine Set-Funktion ausgeführt werden:

set <Name> attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

Die Funktionen der Attribute werden durch einen Präfix geclustert und so inhaltlich, aber vor allem auch in der Attribute Drop-Down Liste, strukturiert dargestellt.

Die Bedeutung der '''Präfixe''' sind:

* '''ai''' - Steuerungsfunktionen für KI (z.B. aiControl)
* '''consumer''' - Registrierung und Einstellungen für Verbraucher (z.B. consumer02, consumerControl)
* '''ctrl''' - Steuerungsfunktion allgemeiner Art (z.B. ctrlDebug, ctrlSpecialReadings, ctrlUserExitFn)
* '''flowGraphic''' - Einstellungen für die Energieflußgrafik (z.B. flowGraphicControl)
* '''graphic''' - Einstellung für die Grafik allgemein (z.B. graphicSelect, graphicControl)
* '''graphicBeam''' - Einstellungen bestimmte Balkeneigenschaften in der Balkengrafik (z.B. graphicBeamHeightLevel1)
* '''plant''' - übergreifende Einstellungen betreffend der gesamten PV-Anlage bzw. des SolarForecast-Devices (z.B. plantControl)
* '''setup''' - Registrierung von Geräten in der Gesamtanlage und Einstellung deren Eigenschaften (Inverter, Zähler, Batterien usw.)

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

Mit den Attributen setupInverterDev01 bis setupInverterDevXX werden die vorhandenen Wechselrichter der Anlage registriert.
Das Modul unterscheidet verschiedene Wechselrichter-Typen, die sich durch ihre Arbeitsweise innerhalb der Anlage unterscheiden. Die Schlüssel=Wert Paare in den Attributen können mehrzeilig organisiert werden. Das erleichtert die Übersicht wenn viele dieser Parameter eingegeben werden.

;PV-Wechselrichter: Es ist der Standard Wechselrichter in einer PV-Anlage. An ihn sind die Solarzellen bzw. Strings angeschlossen. Die zugeordneten Strings können mit dem Schlüssel '''strings''' zugeordnet werden. Ohne diese Angabe werden diesem Gerät alle definierten Strings (siehe Attribut ''setupInverterStrings'') zugeordnet. Der Wechselrichter liefert seine Energie in das Hausnetz. Alternativ kann mit der Angabe '''feed=grid''' die Funktion des Wechselrichters geändert werden. Diese Angabe sagt aus, dass dieser Wechselrichter ausschließlich in das öffentliche Netz einspeist.

Hier ein Beispiel-Setup eines PV-Wechselrichters (SMA STP):

STP_5000 pvIn=string_1_pdc:kW pvOut=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100

;Solar-Ladegeräte: Solar-Ladegeräte sind DC-DC Wandler und liefern die Energie der angeschlossenen Solarzellen nicht in das Wechselstromnetz, sondern laden direkt eine Batterie bzw. versorgen einen Batteriewechselrichter auf der Gleichstromseite. Die Funktion als Solar-Ladegerät wird mit '''feed=bat''' aktiviert, die relevanten Strings können ebenfalls mit dem Schlüssel '''strings''' zugeordnet werden. Ein Beispiel eines Solar-Ladegerätes ist ein Victron SmartSolar MPPT.

Ein Beispiel für das Setup eines Solar-Ladegeräts (SmartSolar Charger MPPT):

MQTT2_cerboGX_c0619ab34e08_solarcharger_Common pv=Yield_Power_value:W etotal=Yield_System_value:kWh capacity=2080 strings=Schleppdach feed=bat synchron=0 limit=100

;Batterie-Wechselrichter: Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer Batterie (=Gleichstromquelle) und dem Wechselstrom-Hausnetz. Die Funktion als Batterie-Wechselrichter wird mit der Angabe '''strings=none''' aktiviert. Die Schlüssel ''etotal'' und ''pv'' können bei einem Batterie-Wechselrichter ohne zugeordnete Solarzellen nicht gesetzt werden. Ein Beispiel eines Batterie-Wechselrichter ist der Victron MultiPlus II.

Ein Setup-Beispiel für einen Batterie-Wechselrichter (Victron MultiPlus II):

<pre>
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
icon=inverter@darkorange:inverter@grey
asynchron=0
</pre>

Die Eigenschaften des Wechselrichters werden durch eine Reihe von <Schlüssel=Wert> Paaren festgelegt. Auf einige dieser Paramter soll hier eingegangen werden.

 
==== Ausgewählte Schlüssel=Wert Paare ====

 
* '''pvIn=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvIn'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell zugeführte PV-Leistung bereitstellt. Der Schlüssel ist optional und dient in erster Linie dazu den entsprechenden Input-Wert in der Flußgrafik anzuzeigen sofern man das Attribut flowGraphicControl->showGenerators=1 setzt. Dadurch ist auch der Eigenverbrauch des Inverters bzw. dessen Wandlungsverlust visuell abschätzbar.

* '''pvOut=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvOut'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell erzeugte Leistung als positiven Wert liefert. Für einen PV-Wechselrichter (DC->AC) oder Solar-Ladegerät (DC->DC) ist es die erzeugte PV-Leistung.

* '''ac2dc=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter vom Hausnetz in Richtung Batterie (AC->DC) wandelt.

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 
==== Definition von Hybrid-Wechselrichtern ====

Zur Zeit der Erstellung dieses Abschnittes ist es in der SolarForecast Version 1.58.x nicht möglich, einen Hybridwechselrichter nativ zu definieren. Als Workaround wird eine passende Kombination aus PV-Wechselrichter und Batterie-Device oder einer Kombination aus PV-Wechselrichter + Batterie-Wechselrichter und Batterie-Device erstellt.

Bei allen benutzten Methoden ist es sehr wichtig!, dass die geforderten Inhalte der jeweilige Attributschlüssel beachtet und eingehalten werden. So ist zum Beispiel die Angabe von:

* '''pvOut''' - Ein Reading, welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz oder öffentliche Netz geliefert wird, bereitstellt. Es wird ein positiver numerischer Wert erwartet.

bei einem PV-Wechselrichter ein Reading welches ausschließlich die Leistung liefert, die von den Solarzellen-Generatoren erzeugt wird. Elemente von Batterieleistungen oder Gridbestandteile dürfen hier nicht enthalten sein. Sind in den Gerätemodulen diese Readings in dieser Form nicht enthalten, bietet es sich an, userReadings zur Erstellung von zusätzlichen Readings in den Quellendevices zu nutzen um den nötigen Input für SolarForecast bereitzustellen.

So wird zum Beispiel bei einem Batterie-Wechselrichter gefordert, dass die Readings '''ac2dc''' (AC->DC-Leistung Hausnetz zur Batterie) und '''dc2ac''' (DC->AC-Leistung (Batterie zum Hausnetz) '''jeweils als als positiver Wert''' anzugeben ist. Manche Batterie-Devices stellen allerdings nur ein Reading zur Verfügung, welches vorzeichenbehaftet die Leistungen in die Batterie bzw. aus der Batterie heraus liefert. Mit einem userReadings Attribut kann aus diesem Reading zwei neue Readings erzeugt werden:

<pre>
attr <Name> userReadings BatIn:DC_Power_value.* {
my $pwr = ReadingsVal ($name, 'DC_Power_value', 0);
$pwr = $pwr > 0 ? $pwr : 0;
$pwr
},
BatOut:DC_Power_value.* {
my $pwr = ReadingsVal ($name, 'DC_Power_value', 0);
$pwr = $pwr < 0 ? - $pwr : 0;
$pwr
},
</pre>

Ist das Quellenreading ''DC_Power_value'' positiv, stellt der Wert AC->DC-Leistung dar und wird als neues Reading BatIn bereitgestellt. Mit einem negativen Vorzeichen ist es eine DC->AC-Leistung und wird in dem neuen Reading BatOut '''ebenfalls als positiver Wert''' bereitgestellt. Auch hier gilt der Grundsatz, dass zum Beispiel BatOut nur die von der Batterie gelieferte Energie und keinen Mix aus Batterie- und PV-Energie enthalten darf.

===== Integration eines DEYE SUN-12K-SG04LP3-EU =====

[[Datei:Screenshot 2025-09-23 203955.png|right|thumb|400px|DEYE SUN-12K-SG04LP3-EU Grundlegende Systemarchitektur]]

Der DEYE vereint wie wohl alle bzw. die meisten Hybrid-Wechselrichter die Anschlüsse:

* Eingang Solar-Strings
* Anschluß Batteriespeicher
* AC-Anschluß öffnetliches Netz
* AC-Anschluß Ersatzlast (wird bei Netzausfall weiter versorgt)
* AC-Anschluß Notstromgenerator bzw. netzgekoppelter anderer Wechselrichter (hier ist ein Growatt Micro-Wechselrichter angeschlossen)

Für die Integration werden die setup-Attribute durch das FHEM Device ''Deye_Inverter'' besetzt:

* setupInverterStrings zur Definition der vorhandenen Solarstrings
* setupInverterDev01 zur Definition der Inverteranschlüsse und Eigenschaften
* setupBatteryDev01 integriert die Batterie
* setupMeterDev liefert die Daten für Netzbezug und Netzeinspeisung

Das nachfolgend verwendete Device ''Deye_Inverter'' ist ein MQTT-Device. Es bekommt Daten vom Deye-Hybridwechselrichter per MQTT und sendet Einstellungen zum Deye, bspw. maximaler Lade/Entladestrom des Akkus, Laden des Akkus aus dem Netz, Ein- und Ausschalten des Micro-Inverter-Ports.
Das Reading ''Deye_Growatt_power'' im Schlüssel ''pvOut'' ist eine Addition aus den Daten des Deye WR und des angeschlossenen Growatt Micro-Wechselrichters.

<pre>
attr <Name> setupInverterStrings Sueddach,Garagendach
attr <Name> setupInverterDev01 Deye_Inverter pvOut=Deye_Growatt_power:W capacity=15200 etotal=total_pv_production:kWh
attr <Name> setupBatteryDev01 Deye_Inverter pin=-pout pout=battery_output_power:W intotal=total_charge_of_the_battery:kWh outtotal=total_discharge_of_the_battery:kWh cap=15200 charge=SOC_jkbms
attr <Name> setupMeterDev Deye_Inverter gcon=total_grid_power:W contotal=total_energy_bought:kWh gfeedin=-gcon feedtotal=total_energy_sold:kWh
</pre>

''setupInverterStrings'' benennt alle vorhandenen Solarstrings. Werden mehrere Inverter definiert, kann mit dem hier nicht verwendeten Schlüssel ''strings'' eine Zuordnung der Strings zum angeschlossenen Inverter vorgenommen werden.

Im Attribut ''setupInverterDev01'' ist der allgemeine Schlüssel ''capacity'' zur Festlegung der Inverterleistung von 15200 Watt gesetzt. Die spezifischen Schlüssel ''pvOut'' und ''etotal'' teilen dem Modul die aktuell erzeugte PV-Leistung sowie die gesamte erzeugte PV-Energie mit. Letzteres dient unter anderem dazu die stündlich real erzeugte PV-Energie festzuhalten und mit der Prognose zu vergleichen. Die in den schlüsseln hinterlegten dürfen keine Battrie- oder Netzanteile enthalten.

Das Attr ''setupBatteryDev01'' implementiert alle relevanten Batteriewerte. Das Reading ''battery_output_power'' im Schlüssel ''pout'' liefert den Batterie-Output als positiven Wert. Als Besonderheit kann der Wert ''pin'', die Batterie-Ladeleistung, den Wert des Readings in ''pout'' übernehmen wenn dieser Wert ein negatives Vorzeichen hat. Die Schlüssel ''intotal'' und ''outtotal'' liefern die summierten Totalwerte für Batterie Ladung bzw. Entladung. Die Kapazität ''cap'' wird für verschiedene Aspekte der SoC- und Ladesteuerung verwendet.

Abschließend liefern die angebenen Readings in den Schlüsseln des Attributes ''setupMeterDev'' alle notwendigen Werte des Netzbezugs und der Netzeinspeisung.

Nachfolgende Links liefern '''weitere Infos''' wie man Daten aus dem Deye WR ausliest und Einstellungen des Deye WR verändert:

* https://github.com/klatremis/esphome-for-deye
* https://github.com/philipphenkel/esphome-config
* https://github.com/bagges/deye-esp32-bridge

Für eine weiterführende Automation soll der Akku netzdienlich in der Mittagszeit geladen werden. Dazu wurde durch den Anwender folgendes userReadings ''MaxBattCharge_Request'' im Device ''Deye_Inverter'' für den maximalen Ladestrom definiert (bei 90% SOC und bei 100% SOC):

<pre>
MaxBattCharge_Request:SOC_jkbms.* {
if ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) < 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') < 561600)
{100}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) < 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') >= 561600)
{100}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) >= 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') < 561600)
{ceil ((90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310/3.5)}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) >= 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') >= 561600)
{ceil ((100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310/3.0)}
}
</pre>

Das userReading wird in einer Automation benutzt, um den maximalen Ladestrom einzustellen; Ladebeginn bei ausreichend Sonne ist ab 11:30 eingestellt.

 
===== Integration eines Fronius Symo GEN24 10.0 Plus mit (virtuellen) Batterie-Wechselrichter =====

[[Datei:Screenshot 2025-10-04 162422.png|right|thumb|400px|Flußgrafik mit eingebauten Hybrid-Wechselrichter]]

Die Integration des Wechselrichters Fronius Symo GEN24 10.0 Plus benötigt zunächst eine Anbindung in FHEM, was mit dem Modul 98_fronius.pm vorgenommen wurde.

Das Ziel der Kurzdokumentation ist neben der Darstellung eines Hybridwechselrichters aufzuzeigen, wie man den Wandlungsverlust eines PV-Wechselrichters (pvIn – pvOut) in Näherung visualisieren kann.
'''pvIn''' ist dabei die Summe der Produkte aus den DC Strom- und Spannungswerten der einzelnen Strings (hier 2109 W), '''pvOut''' (hier 2065 W) ist die an den Inverterknoten (hier 1105 W) plus die an die Batterie abgegebene Leistung (hier 960 W). Bei dieser Implementierung wird mit einem zusätzlichen (virtuellen) Batterie-Wechselrichter gearbeitet.

In Vorbereitung werden die beiden anzugebenden Readings ''<pvIn>'' und ''<pvOut>'' zum Beispiel als userReadings erstellt, wobei '<pvIn>'' und ''<pvOut>'' natürlich durch Readingnamen ersetzt werden müssen. Diese beiden Readings werden wie folgt berechnet / erstellt:

<pre>
<pvOut> = Inverter_Common_PAC_Value - PowerFlow_Site_P_Akku
<pvIn> = Inverter_Common_IDC_Value * Inverter_Common_UDC_Value + Inverter_Common_IDC_2_Value * Inverter_Common_UDC_2_Value
</pre>

Der '''PV-Wechselrichter''' wird mit dem Attribut setupInverterDev01 definiert, wobei die angelegten Readingnamen in den Schlüsseln ''pvIn'' bzw. ''pvOut'' verwendet werden:

<pre>
SymGen24 icon=inverter@#ff8c00:inverter@grey capacity=10000 strings=suedwest,nordost etotal=User_Produced_PV:kWh pvOut=<pvOut>:W pvIn=<pvIn>:W
</pre>

Dem PV-Wechselrichter sind die Strings ''suedwest'' und ''nordost'' zugewiesen.

Der zusätzliche '''Batterie-Wechselrichter''' wird mit dem Attribut setupInverterDev02 hinzugefügt:

<pre>
SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=-PowerFlow_Site_P_Akku:W dc2ac=PowerFlow_Site_P_Akku:W capacity=7680
</pre>

'''Bemerkungen:''' 
- strings=none sowie die Schlüssel ac2cd und dc2ac sind typisch für einen Batterie-WR bzw. kennzeichnen einen WR als Batterie-Wechselrichter 
- die an die Batterie abgegebene Leistung ist negativ

 
===== Einbindung eines Fronius Symo GEN24 10.0 Plus mit BYD Batterie ohne (virtuellen) Batterie-Wechselrichter =====
Diee Implementierung ist komplett in diesem verlinkten [https://wiki.fhem.de/wiki/Solaranlage_Komplettbeispiel_Fronius_BYD Wiki Beitrag] beschrieben.

Zur Integration des ''Fronius Symo'' in FHEM wird das Modul ''fronius.pm'' verwendet und in dem definierten Device ''Fronius_Symo_Gen24'' diverse userReadings erzeugt. Diese Readings werden in den korrespondierenden Schlüsseln des Attributes ''setupInverterDev01'' angegeben:

<pre>
setupInverterDev01 Fronius_Symo_Gen24 etotal=User_Produced_PV_Energie:kWh pvOut=PowerFlow_Site_P_PV:W capacity=6000 strings=Dach_Ost,Dach_West
</pre>

Am Wechselrichter Fronius Symo Gen24 ist eine BYD Batterie angeschlossen. Das Device ''[https://wiki.fhem.de/wiki/Solaranlage_Komplettbeispiel_Fronius_BYD#PV_Batterie PV-Batterie]'' wird per [https://wiki.fhem.de/wiki/ModbusAttr ModbusAttr] angelegt und gemanaged. Die entsprechenden Readings werden im Attribut ''SetupBatteryDev01'' hinterlegt:

<pre>
PV_Batterie
cap=10240
charge=BatteryChargePercent
icon=@dyn:@dyn:@dyn:@dyn
intotal=Summe_Ladung:Wh
outtotal=Summe_Entladung:Wh
pin=BatteryChargeWatt:W
pout=BatteryDischargeWatt:W
pinmax=10000
show=2
</pre>

 

===== Einbindung eines SMA - Hybrid Sunny Tripower Smart Energy =====

[[Datei:Screenshot 2025-10-05 083530.png|right|thumb|400px|SMAInverter.pm]]

Der genannte Wechselrichter wird über das Modul SMAInverter.pm in FHEM integriert. Die nebenstehende Abbildung zeigt und benennt die einzelnen Readings des Moduls welche in den entsprechenden Schlüsseln der SolarForecast Attribute ''setupInverterDevXX'' und ''setupBatteryDevXX'' zugeordnet werden.

Die Readings des SMAInverter Moduls können vor der Verwendung über geeignete Methoden (userReadings) in Readings mit sprechenden Namen überführt werden um sie mit diesen Namen in die genannten Attributschlüssel einzufügen. In der vorliegenden Lösung befinden sich die Anwendungen SolarForecast und und die Inverter-Steuerung jeweils auf unterschiedlicher Hardware. Als Verbindungslayer wird MQTT genutzt, wobei dadurch bereits die dargestellten Readingnamen entstehen.

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)
;graphicBeamHeightLevel1:Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene (hier Ebene 1)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===
Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und, wenn ein Event eines als 'asynchron' definierten Devices auftritt, gesammelt und daraus permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

=== Wie wird die Verbrauchsprognose erstellt? ===

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

==== Debugging der Verbrauchsprognose ====
Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

=== Wie kann eine fehlerhafte Verbrauchsprognose korrigiert werden? ===
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionHistory 07 21

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
==== Beispiel Auslesen der Batterieladestrategie und Anlegen eines Readings ====

Als Praxisbeispiel soll die aktuelle gesetzte Ladestrategie für Batterie "01" ausgelesen und mit dem Wert ein Reading im SolarForecast Device angelegt werden. 
Dazu wird der folgende Code im Attribut ''ctrlUserExitFn'' hinterlegt:

<syntaxhighlight lang="Perl">
{
my $wert = NexthoursVal ($name, 'NextHour00', 'strategybat01', 'loadRelease');
storeReading ('Ladestrategie', $wert);
}
</syntaxhighlight>

Bei jedem Zyklus des SF-Devices wird der aktuelle Wert von ''strategybat01'' gelesen und im Reading ''Ladestrategie'' gespeichert. Die Paket-Definition ''FHEM::SolarForecast::'' braucht nicht verwendet werden, da der Aufruf im Attribut ctrlUserExitFn innerhalb des SolarForecast-Paketes erfolgt.

Für andere Batterienummern ist der NexthoursVal-Schlüssel ''strategybat01'' entsprechend anzupassen.

 

=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
PVH_SolarForecast_<name> - PV History
PVC_SolarForecast_<name> - PV Circular
PVCfg_SolarForecast_<name> - PV Anlagenkonfiguration
PVCsm_SolarForecast_<name> - Consumer Status
ScApi_SolarForecast_<name> - Strahlungswerte aus verwendeter API
StatApi_SolarForecast_<name> - Statusdaten der verwendeten API's
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - KI Input Daten = Raw Trainigsdaten
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten 3 Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "pvHistory" restored
2023.10.02 09:57:07.969 3: SolCast6 - cached data "pvCircular" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "consumerMaster" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "radiationApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "statusApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "weatherApiData" restored
2023.10.02 09:57:07.974 3: SolCast6 - cached data "aiTrainedData" restored
2023.10.02 09:57:07.976 3: SolCast6 - cached data "aiRawData" restored
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices, d.h. ein einfaches "define <Name> SolarForecast", und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. Anpassen der Dateieigentümer und Berechtigungen: chown fhem:dialout /opt/fhem/FHEM/FhemUtils/*, chmod 774 /opt/fhem/FHEM/FhemUtils/*
* 5. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen
* 7. FHEM Konfiguration sichern und restarten

 
'''Hinweis:''' 
Das zuvor beschriebene Verfahren kann auch angewendet werden um das SolarForcast Device von einer FHEM Installation in eine andere Installation umzuziehen. In diesem Fall ist aber besonders darauf zu achten, vorab alle in den SF-Attributen referenzierten Devices wie Inverter, Meter oder DWD-Devices mit den zutreffenden Namen in der neuen Installation anzulegen.

 
Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices, d.h. ein einfaches "define <Name> SolarForecast", und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. Anpassen der Dateieigentümer und Berechtigungen: chown fhem:dialout /opt/fhem/FHEM/FhemUtils/*, chmod 774 /opt/fhem/FHEM/FhemUtils/*
* 6. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 7. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen
* 8. FHEM Konfiguration sichern und restarten

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere diese Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagementXX lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>] [loadAbort=<SoC1>:<MinPwr>:<SoC2>] [safetyMargin=<Wert>[:<Wert>]] ...

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;stepSoC: Optionale Schrittweite zur optimalen SoC-Berechnung (Battery_OptimumTargetSoC_XX) in %. Mit der Angabe 'stepSoC=0' wird das SoC-Management deaktiviert und Battery_OptimumTargetSoC_XX auf den Wert 'lowSoC' gesetzt. '''Hinweis:''' Die Beziehung 'careCycle * stepSoC = 100' sollte eingehalten werden! Wert: 0..5, default: 5

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten darf. Die Angabe ist optional. (default: 20)

;lcSlot: Es wird ein tägliches Zeitfenster festgelegt, in dem die Ladesteuerung des Moduls für diese Batterie aktiv sein soll. Außerhalb des Zeitfensters wird die Batterieladung mit voller Leistung freigegeben. Das SoC-Management der Batterie ist davon nicht betroffen. Wert: <hh:mm>-<hh:mm>, default: ganztägig

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit. Die Abbruchbedingung ist erfüllt, wenn der angegebene SoC1 (%) erreicht bzw. überschritten ist '''UND''' die angegebene Ladeleistung <MinPwr> (W) unterschritten wurde -> Reading Battery_ChargeAbort_XX=1. Fällt der aktuelle SoC wieder unter den SoC2, wird Battery_ChargeAbort_XX=0 gesetzt. Ist SoC2 nicht angegeben, gilt SoC2=SoC1.

;loadStrategy: Abhängig von der gewählten Ladestrategie wird die Prognose der Batterieladung und ggf. die Generierung der Steuerreadings beeinflusst. Die Angabe ist optional. Wert: loadRelease | optPower | smartPower, default: loadRelease

;loadTarget: Optionaler Ziel-SoC in % für die Berechnung der Ladefreigabe bzw. der optimalen Ladeleistung. Der Zielwert ist eine kalkulatorische Rechengröße. Der reale SoC kann situativ in Grenzen über- oder unterschritten werden. Der höhere Wert aus Reading Battery_OptimumTargetSoC_XX und 'loadTarget' hat für die Berechnung Vorrang. Wert: 0..100, default: 100

;safetyMargin: Bei der Berechnung der Ladefreigabe und optimierten Ladeleistung werden Sicherheitszuschläge auf den prognostizierten Ladungsbedarf berücksichtigt. Abweichend vom Default können mit diesem Parameter individuelle Sicherheitszuschläge getrennt für die Berechnung der Ladefreigabe und optimierten Ladeleistung angegeben werden. Der erste Wert ist der Zuschlag bei der Berechnung der Ladefreigabe, der zweite Wert der Zuschlag bei der Berechnung der optimierten Ladeleistung. Beide Angaben sind Prozentwerte von 0..100.

;weightOwnUse: Optionale Gewichtung der stündlichen Verbrauchsprognose als zusätzlich verwendbaren Anteil zur Batterieladung in %. Technisch wird der verfügbare PV-Überschuß zur Berechnung der optimierten Ladeleistung erhöht indem der kalkulierte Verbrauch um den angegebenen Prozentsatz gesenkt wird. Wert: 0..100 default: 0

Alle SoC-Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Wert 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Wert 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten. Der Fokus der Steuerung mit diesem Reading ist es, die Speicherkapazität der Batterie optimal zur Verhinderung der Überschreitung von Einspeiselimits einzusetzen und dennoch einen maximal möglichen SoC am Tagesende zu erreichen. (siehe das beschriebene [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Berücksichtigung_einer_Wirkleistungsbegrenzung|Nutzungsbeispiel]])

;Battery_ChargeOptTargetPower_XX: Dieses Reading enthält einen Richtwert für die optimierte Ladeleistung für jede Batterie. Die Aufladung wird prognosegeführt über den gesamten Tag verteilt, wobei der Fokus auf eine kontinuierliche, aber möglichst niederige Ladeleistung gelegt wird. (siehe diesen [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|Abschnitt]])

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

;Battery_TargetAchievable_XX: Diese Reading enthält einen Boolean Wert 0|1 und signalisiert ob der im Attribut '''ctrlBatSocManagementXX->loadTarget''' gesetzte Ziel-SoC lt. Prognose am aktuellen Tag tatsächlich erreicht werden kann.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

 

===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und folgenden Tag korrigiert. Das bedeutet, dass der Minimum SoC z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Batterie wieder vollständig zu zuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $bn = '01'; # Batterienummer (evtl. im Aufruf mitgeben)
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) für Victron MPII Verbund
my $preduce = FHEM::SolarForecast::BatteryVal ($name, $bn, 'bpinreduced', $maxcspc); # reduzierte Ladeleistung aus Bat-Konfig (W)
my $actmcc = ReadingsNum ($vicsets, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_'.$bn, 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_'.$bn, 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Ladestrom (A) b. Battery_ChargeRequest
$load = $preduce / 48; # bei 48V Batteriesystem
}
else {
$load = $maxcspc;
}
}

## Einstellung MPII Verbund MaxChargeCurrent
##############################################
if ($actmcc && $load != $actmcc) {
CommandSet (undef, "$vicsets MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vicsets set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_MPII_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Die in diesem Abschnitt beschriebene Ladestrategie '''loadRelease''' wird im Modul als '''Ladefreigabe''' bezeichnet.

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen, oder der im Reading [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|Battery_ChargeOptTargetPower_XX]] angegebenen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten..

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''. Die erreichte Qualität der Steuerungslogik ist stark von der Prognosequaliät abhängig. Um die Steuerung resilienter zu gestalten, wird per default ein Sicherheitsaufschlag von 50% auf die prognostizierte benötigte Ladeenenergie auf Stundenbasis einkalkuliert. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<div class="mw-collapsible mw-collapsed">
'''Code Management Batterieladung über Victron Grid Setpoint ->''' <div class="mw-collapsible-content">
<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>
</div>
</div>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== leistungsoptimierte Beladungssteuerung mit dem Fokus geringe Verlustleistung und Verschleiß ====

Über das Attribut ctrlBatSocManagementXX kann mit dem Schlüssel loadStrategy die Ladestrategie '''optPower''' oder '''smartPower''' eingestellt werden.
Das SF-Modul bietet ein weiteres Reading '''Battery_ChargeOptTargetPower_XX''' zur Batteriesteuerung an. Dieses Reading liefert eine kalkulierte optimale Ladeleistung in Watt.

Die in diesem Abschnitt beschriebene Ladestrategie '''optPower''' wird im Modul als '''optimierte Ladeleistung''', die Ladestrategie '''smartPower''' als '''zieloptimierte Ladeleistung''' bezeichnet.

Beide Strategien kalkulieren die Ladeleistung kontinuierlich neu und berücksichtigen dabei:

* die Prognose der PV-Erzeugung der nächsten Stunden und des (Rest-)Tages
* den prognostizierten Verbrauch auf Stunden- bzw. Tagesbasis
* eine eventuell mögliche Überschreitung des gesetzten Einspeiselimits (plantControl->feedinPowerLimit)
* die gesetzten Leistungsparameter der Batterie
* das Ziel, am Tagesende einen möglichst maximalen SoC der Batterie erreicht zu haben bzw. den eingestellten Ziel-SoC '''loadTarget'''
* die Effizienz der Batterieanlage (Einstellung '''setupBatteryDevXX->efficiency''')

Der Fokus der implementierten Logik liegt dabei auf einer kontinuierlichen Ladeleistung, die aber unter den oben genannten Gesichtspunkten möglichst (relativ) gering sein soll um den Batterieverschleiß und die Verlustleistung zu minimieren. Die im Reading angezeigte Ladeleistung kann mit geeigneten Mitteln direkt in die Leistungssteuerung der Batterie eingebracht werden. Natürlich kann die Leistung auch vorab in einen optimalen Ladestrom umgerechnet werden.

Da das Ergebnis der Kalkulation stark von den Prognosen abhängt, ist zur Erhöhung der Resilienz per Default ein Sicherheitszuschlag von 20% eingebaut. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

Ist kein PV-Überschuß (mehr) vorhanden / prognostiziert oder das Ladeziel erreicht, erfolgt ein Rückfall der Ladeleistung im Reading Battery_ChargeOptTargetPower_XX auf den im Attribut '''setupBatteryDevXX->pinmax''' angegebenen Wert. Ist dieser Wert nicht gesetzt, erfolgt der Rückfall auf "Unendlich" (9223372036854775807).

Im Reading Battery_ChargeOptTargetPower_XX wird der Wert des Parameters '''setupBatteryDevXX->pinreduced''' gesetzt, wenn weniger Ladeleistung als pinreduced berechnet wurde (Einhaltung einer Mindestladeleistung) oder wenn der SoC der Batterie <= [[#Aktivierung_des_Batterie_SOC-_und_Lade-Managements|lowSoC]] beträgt.
Somit wird die Batterie bei einer Anforderungsladung bei Unterschreitung von lowSoC mit nur wenig Leistung aus dem Grid geladen falls es nötig sein sollte.
Es ist demzufolge ratsam den optionalen Parameter '''setupBatteryDevXX->pinreduced''' zu setzen, da ansonsten ebenfalls ein Rückfall auf '''setupBatteryDevXX->pinmax''' bzw. "Unendlich" erfolgt.

Beide Strategien, optPower und smartPower, setzen die zuvor beschriebene Arbeitsweise um.
Ergänzend wird bei der Ladestrategie '''smartPower''' die generelle Erreichbarkeit des Ladeziels bei der Festlegung der Ladeleistung berücksichtigt. Es führt dazu dass:

* die Ladeleistung im Reading Battery_ChargeOptTargetPower_XX auf einen tendenziell höheren Wert als bei der optPower-Strategie gesetzt wird, wenn/solange das eingestellte Ladeziel als unerreichbar kalkuliert wird
* bei kalkulierter Erreichbarkeit des Ladeziels der Sicherheitsaufschlag linear absenkend proportional zum Kehrwert des verfügbaren PV-Überschusses auf die Ladeleistung angewendet wird

Der nächste Abschnitt erläutert die smartPower Funktionen etwas eingehender.

 
===== smartPower - die zieloptimierte Ladeleistung =====
Die hinter smartPower liegende Anpassungslogik wird nachfolgend etwas näher beschrieben.
Ausgangspunkt ist das Ergbnis einer Ratio-Funktion aus dem (Rest)Tages-PV-Überschuß und benötigter Energie zur Erlangung des Batterie Ladeziels.

'''Lineare Interpolation zwischen pinmax und abgesicherter minpower''' 

'''Variablen'''

* '''P''': resultierende Leistung.
* '''pinmax''': maximale Ladeleistung.
* '''limpower''': Leistungslimit, d.h. Ladeleistungssollwert.
* '''r''': Verhältnis in Prozent (r = spday·100 / whneed).
* '''otpMargin''': Prozentwert der Bandbreite, über die die Absenkung linear verläuft (die Steilheit kann mit dem Attributwert ctrlBatSocManagementXX->safetyMargin im Device eingestellt werden).

Die Kennlinie der für smartPower eingesetzten Funktion ist stückweise definiert über das Verhältnis Ratio ''𝑟 = spday x 100 / <benötigte Ladeenergie bis Ziel>''.

* Für 𝑟 ≤ 100: ''𝑃 = pinmax'', Interpretation: Es ist viel Bedarf vorhanden bzw. Überschuss ≤ 100 % des Bedarfs → maximal laden.
* Für 𝑟 ≥ 100 + otpMargin: ''𝑃 = limpower ⋅ (1 + otpMargin / 100 )''
* Für 100 < 𝑟 < 100 + otpMargin: lineare Absenkung von '''P''' mit zunehmendem '''r''' für den Bereich 100 < 𝑟 < 100 + otpMargin. '''P''' wird bei 𝑟 = 100 gleich '''pinmax''' und bei 𝑟 = 100 + otpMargin gleich ''limpower ⋅ ( 1 + otpMargin/100 )'', Interpretation: Sobald der Überschuss über den Bedarf hinausgeht (ratio > 100), wird das Ladeleistungslimit schrittweise von pinmax Richtung limpower reduziert; die Reduktion erfolgt gleichmäßig über die Margin-Spanne.

'''Lineare Interpolation und Steigung'''

Die Differenz ''(pinmax − limpower)'' wird gleichmäßig auf die otpMargin-Prozentpunkte verteilt. Die Steigung der Geraden ist

<pre>
slope = − (pinmax − limpower) / otpMargin
</pre>

das heißt die Leistung sinkt um diesen Betrag pro Prozentpunkt von '''r'''.

Nach Umformung ist der Zusammenhang wie folgt darstellbar:

<pre>
𝑃 = pinmax − ( pinmax − limpower) ⋅ ((𝑟 − 100) / otpMargin)
</pre>

und ist äquivalent zu

<pre>
𝑃 = pinmax + ( 𝑟 − 100 ) ⋅ slope
</pre>

'''Numerisches Beispiel'''

* '''limpower''' = 1000 W, '''pinmax''' = 3000 W, '''otpMargin''' = 20
* Unterschied = 2000 W, Steigung = −2000/20 = −100 W/%
* Für '''r = 105''': 𝑃 = 3000 − 2000 ⋅ ( 5 / 20 ) = 3000 − 500 = 2500 W
* Für '''r = 120''' ergibt die Formel den abgesicherten Endwert 1200 W

Die Formel sorgt dafür, dass die Zielleistung stufenlos und vorhersehbar reduziert wird, wenn der relative Rest-Überschuss des Tages über 100% steigt, und erreicht bei Ende der otpMargin den geplanten abgesicherten Wert.

[[Datei:Ratio Kennlinie.png|right|thumb|200px|abfallend proportionale Anpassungsfunktion]]

In einem grafischen Diagramm stellt sich die abfallend proportionale Anpassungsfunktion der resultierenden Soll-Ladeleistung wie nebenstehend abgebildet dar. Dabei entspricht pow=100 dem jeweiligen pinmax Wert (hier 3000 W). So ist auch pow=0 mit dem abgesicherten Endwert (hier 1200 W) gleichzusetzen. Die Linie verläuft waagerecht bei pinmax solange das das Ratio r ≤ 100 % und knickt an r == 100 mit steigenden r nach unten. Es verringert sich pow linear von pinmax zu limpower zzgl. otpMargin.

Durch diese Maßnahmen wird eine flexible Lademöglichkeit bis pinmax erreicht, die sich bei unvorhergesehenen Aufklarungen mit starker Sonneneintrahlung bei ansonsten sehr bedeckten Himmel positiv auswirkt. Andererseits wird die Erhöhung der Ladeleistung weiter begrenzt, wenn viel PV-Überschuß in Verbindung mit einer generellen Erreichbarkeit des Ladeziels zum Ende des Tages prognostiziert ist. Man könnte die Ladestrategie '''smartPower''' in ihrer Wirkung als einen Mix aus '''optPower''' und '''loadRelease''' ansehen.

Zusammenfassend ist optPower vorwiegend für die Nutzergruppe geeignet, die eine tendenziell sparsamere Ladeleistung bevorzugen und dafür bereit sind eventuelle "Verluste" in Form von Einspeisung zu akzeptieren. 
Demgegenüber eignet sich das aggressivere smartPower für Anwender, die bei niedrigen PV-Erträgen bewusst das Maximum an Batterieladung anstreben und dafür in Kauf nehmen, dass Ladeleistungen weniger knapp kalkuliert sind.

 

===== Unterstützung des Modus "Eigennutzung" bei Hybrid-Wechselrichtern =====
Viele Hybrid-Wechselrichter verteilen die zur Verfügung stehende PV-Leistung nach folgendem Prioritäten, wenn der (übliche) Modus "Eigennutzung" aktiviert ist:

# Nutzung der Leistung zur Deckung des Hausverbrauchs,
# Nutzung der Leistung zur Ladung des bzw. der angeschlossenen Speicher.
# Einspeisung der Leistung in das öffentliche Netz.

Da in aller Regel die Leistung, mit der ein angeschlossener Speicher geladen wird, limitiert werden kann, lassen sich die o.g. Priorität bzgl. des Speichers zugunsten einer Überschusseinspeisung aufweichen. Ein entstehender "Überschuss" steht also ggf. nur deshalb zur Verfügung, weil die Ladeleistung des Speichers begrenzt wurde.

Ab Version 1.58.6 bietet SolarForecat die Möglichkeit, prognostizierte Verbräuche nicht mehr komplett bei der Bestimmung der ''optimalen Ladeleistung'' zu berücksichtigen, sondern nur noch zu einem prozentualen Anteil von 0..100 %. Hierzu muss der Attribut-Schlüssel '''ctrlBatSocManagementXX->weightOwnUse=<Percentage>''' entsprechend gesetzt werden.

So führt beispielsweise weightOwnUse=100 dazu, dass bei der Berechnung der optimalen Ladeleistung prognostizierte Verbräuche nicht mehr berücksichtigt werden indem sie bei der Bestimmung des stündlichen PV-Überschusses unberücksichtigt bleiben. Eine derartige Einstellung kann z.B. sinnvoll sein, wenn alle ansonsten täglich laufende Verbraucher zugunsten einer Batterieladung ausgeschaltet werden können.

Ein Wert von zum Beispiel weightOwnUse=30 lässt 30% der stündlichen Verbrauchslast unberücksichtigt, sodass sich der kalkulierte PV-Überschuß pro Stunde um 30% des prognostizierten Verbrauchs erhöht. Da die Berechnung der optimierten Ladeleistung mit dem zur Verfügung stehenden PV-Überschuß gewichtet erfolgt, würde sich die kalkulierte Ladeleistung in den meisten Fällen ebenfalls um einen gewissen Betrag erhöhen sofern andere Faktoren dies nicht verhindern. Das kann beispielweise der Fall sein, wenn die kalkulierte Ladeleistung zu gering ist und automatisch aif mindestens '''setupBatteryDevXX->pinreduced''' angehoben wurde.

 

==== Welche Ladestrategie soll ich wählen? - eine Möglichkeit zur Best-Practice Findung mit Codebeispiel ====

In den vorangegangenen Abschnitten wurden die verschiedenen Möglichkeiten zur Steuerung der Batterieladung und dem SoC vorgestellt. Diese Steuerungsvarianten optimieren die Arbeitweise der Batterie, haben aber jeweils einen eigenen Fokus auch wenn es gewisse Überschneidungen gibt.

Die Steuerungsvarianten lassen sich folgendermaßen klassifizieren:

# Steuerung der Batterieladung über eine Ladefreigabe, die durch bestimmte Indikatoren festgelegt wird. Diese Variante ist in [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Berücksichtigung_einer_Wirkleistungsbegrenzung|diesem]] Abschnitt beschrieben.
# Steuerung der Batterieladung durch eine optimierte maximale Ladeleistung. Diese Variante ist in [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|diesem]] Abschnitt dargelegt. Zu dieser Variante gehören die Strategien ''optPower'' sowie ''smartPower''. Die Unterschiede beider Strategien sind ebenfalls in dem verlinkten Abschnitt beschrieben.

Die '''Variante 1.)''' gibt die Ladung der Batterie frei wenn der (verbleibende) PV-Überschuß des Tages kleiner oder gleich dem Ladungsbedarf der Batterie ist um einen SoC von 100% bzw. den maximal möglichen SoC am Ende des Tages zu erreichen. Dadurch wird die in der Batterie vorhandene freie Kapazität so lange wie möglich der Einhaltung von besonderen Grenzwerten, z.B. des Einspeiselimits (plantControl->feedinPowerLimit), vorbehalten. Nebeneffekt ist, dass plötzlich und unerwartet auftretende hohe Erzeugungsleistungen in die Batterie geladen werden können und nicht unerwünscht in das öffentliche Netz eingespeist werden.

Die '''Variante 2.)''' lässt die Batterie kontinuierlich laden, wobei die Ladeleistung auf ein optimiertes Minimum reduziert wird ohne das Ziel, einen maximalen SoC am Tagesende zu erreichen, zu ignorieren. Dadurch wird die Batterie schonend, mit möglichst wenig Verlustleistung und verschleißarm geladen. Die Vorhaltung der freien Kapaziäten der Batterie sind in dieser Variante nicht die Prämisse. Die Einhaltung des gesetzten Enispeiselimits wird auch in dieser Variante beachtet sofern es der Ladezustand der Batterie zulässt. Technisch bedingt kann diese Variante nur ungenügend auf unerwartete PV-Überschüsse reagieren, was zu einer Einspeisung in das öffentliche Netz oder im ungünstigsten Fall zur Abregelung der Anlage führen kann. Mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' kann man diesem negativen Aspekt in gewissem Maße entgegenwirken.

Ausgehend von diesen unterschiedlichen Optimierungszielen bietet sich die Variante 1.) vorwiegend in den Übergangs- und Wintermonaten an. Durch die beschriebenen Eigenschaften dieser Variante ist bei tendeziell weniger PV-Überschuß über den Tag die Ladung der Batterie komplett freigegeben, wodurch bei plötzlich auftretenden sonnige Abschnitten und Aufklarungen die Batterie sofort mit dem verfügbaren PV-Überschuß geladen wird. Auch eine Einspeisung über das Einspeiselimit hinaus kann verhindert werden. In der übrigen Zeit wird die Ladeleistung durch den verfügbaren PV-Überschuß begrenzt.
Weiterhin soll der SoC nicht dauerhaft tief absinken und ebenfalls nicht auf einem zu hohen Level verharren was auch einer maximal möglichen Energiespeicherung an sonnigen Tagen entgegenwirken würde.
In dieser Zeit ist die Nutzung der Kombination von [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Nutzung_des_Batterie_SOC-Management|SoC-Management]] und Variante 1.) wohl am Besten geeignet um die Ziele zu verwirklichen sowie Notreserven in den Batterien vorzuhalten.

In den Sommermonaten hingegen ist üblicherweise sehr viel PV-Energie und Überschuß vorhanden. In dieser Periode würden die Batterien mit sehr hoher Leistung sehr zeitig am Tag vollgeladen. Die Variante 1.) ist im Prinzip ebenfalls gut geeignet den Zeitpunkt der Vollladung hinauszuzögern, jedoch erscheint die Varinte 2.) in dieser Zeit besser geeignet mit einer über den gesamten Tag verteilten moderaten Ladeleistung den Ziel-SoC zu erreichen. Auch diese Variante versucht eine Überschreitung des Einspeiselimits zu verhindern sofern der Ladezustand der Batterie dies ermöglicht.

Das nachfolgende Codebeispiel bietet die Möglichkeit über ein Attribut die Ladevariante auszuwählen, über ein weiteres Attribut die SoC-Steuerung zu aktivieren/deaktivieren und integriert auch die Ladesteuerung für eine Batterie-Anforderungsladung bei Unterschreitung von ctrlBatSocManagementXX->lowSoc.

Die gesteuerte Batterieanlage besteht aus:

* 3 x Victron MultiPlusII 3000/48
* Steuergerät CerboGX (in FHEM über MQTT eingebunden)
* einem Batteriestack bestehend aus Pylontech US3000C (wird durch CerboxGX gesteuert)

Zur Umschaltung bzw. Auswahl der Ladestrategie und des SoC-Managements werden zwei User-Attribute im SolarForecast Device angelegt.

<pre>
attr ... userattr userFn_BatterySoCManagement:Ein,Aus userFn_BatteryLoadManagement:Aus,loadRelease,optPower,smartPower
</pre>

Im Code werden diese Attribute ausgewertet. Das nachfolgende Script vereint folgende Funktionalitäten:

* die Aktivierung/Deaktivierung des SoC-Managements via Attribut userFn_BatterySoCManagement
* die Auswahl der Ladestrategie oder Deaktivierung der Ladesteuerung via attribut userFn_BatteryLoadManagement
* Integration einer Anforderungsladung bei Signalisierung durch Reading Battery_ChargeRequest_XX
* Generierung von Readings userFn_Victron_GridSetpoint_set und userFn_MPII_MaxChargeCurrent_set zur Dokumentation der eingestellten Soll-Werte

Bei der Nachnutzung des Scripts sind zunächst die '''Konstanten''' und das Device '''MQTT2_cerboGX_c0619ab34e08_setting'''s sowie dessen Readings im Block '''aktuelle Indikatoren''' anzupassen.

Das Script wird in die Datei '''99_mySolarForecastUtils.pm''' eingetragen und im SolarForecast Attribut '''ctrlUserExitFn''' hinterlegt:

<pre>
attr ... ctrlUserExitFn {
::batLoadMgmnt ($name, '01');
# ::batLoadMgmnt ($name, '02'); # optional für eine weitere Batterie '02'
# ::batLoadMgmnt ($name, '0X'); # optional für weitere Batterien
}
</pre>

Mit diesem Script ist der Nutzer in der Lage, das Batterie Lademanagement entsprechend seiner Motivation und gegebenenfalls abhängig von der Jahreszeit umzustellen und das Ergebnis bzw. die Zielerreichung zu testen.

Das Attribut '''userFn_BatteryLoadManagement''' selektiert die gewünschte Ladestrategie:

;Aus: das Lademangement ist ausgeschaltet

;loadRelease: das Lademangement Variante 1.) Ladestrategie Ladefreigabe ist aktiviert

;optPower: das Lademangement Variante 2.) Ladestrategie optimierte Ladeleistung ist aktiviert

;smartPower: das Lademangement Variante 2.) Ladestrategie zieloptimierte Ladeleistung ist aktiviert

Die selektierte Ladestrategie wird im Script in das SolarForecast Device repliziert, d.h. der Attributschlüssel ctrlBatSocManagement01->loadStrategy wird identisch zum Wert des Attributes userFn_BatteryLoadManagement gesetzt. Dazu wird das Set-Kommando ''attrKeyVal'' verwendet. Das globale Attribut ''autosave'' sollte aus diesem Grund NICHT explizit auf "0" gesetzt sein um eine reibungslose Funktion zu ermöglichen.

Hat man die individuell passende Management-Strategie gefunden, bietet sich auch eine automatische (zum Beispiel durch einen Kalender oder Sonnenstand (Elevation) zur Mittagszeit) Umschaltung der Ladestrategie an. Die Unterschreitung der Elevation unter einen bestimmten Wert würde den Beginn des Winterhalbjahres und reverse Überschreitung den Beginn des Sommerhalbjahres kennzeichnen. Entsprechend würde dann die gewünschte Ladestrategie selektiert. Alternativ könnte auch die PV-Überschußprognose für den aktuellen Tag über das Reading ''Today_PVforecast'' für eine Entscheidung bzgl. der Ladestrategie herangezogen werden.

Das SoC-Management kann über das gesamte Jahr aktiviert bleiben, hat jedoch nach bisherigen Erfahrungen nur im Winterhalbjahr eine starke Relevanz.

<div class="mw-collapsible mw-collapsed">
'''Code Lademanagement ->''' <div class="mw-collapsible-content">
<syntaxhighlight lang="perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Komplettes Batterie Lademanagement
############################################################################
sub batLoadMgmnt {
my $name = shift;
my $bn = shift // '01'; # Batterienummer
my $hash = $defs{$name};

## Konstanten
###############
use constant {
GSPDEF => 20, # Einstellung des Grid Setpoint
FINDEF => 5000, # Default Einspeiselimit
MINSOCDEF => 10, # Default Minimum SoC
MAXPLDEF => 105, # max. Ladestrom (A) Victron MPII
SYSVOLTAG => 48, # Batterie Systemspannung
};

my $batsocmgmt = AttrVal ($name, 'userFn_BatterySoCManagement', 'Aus'); # SoC-Management Vorgabe
my $batloadmgmt = AttrVal ($name, 'userFn_BatteryLoadManagement', 'Aus'); # Lademanagement Vorgabe
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron CerboGX Einstellungen

## Ladestrategie Ist-Einstellung und Soll-Abgleich
####################################################
my $cgbt = AttrVal ($name, 'ctrlBatSocManagement'.$bn, undef);
my $strategy = 'loadRelease';

if ($cgbt) {
my $parsed = FHEM::SolarForecast::__parseAttrBatSoc ($name, $cgbt); # aktuell gesetzte Strategie ermitteln
$strategy = $parsed->{loadStrategy} // $strategy;
}

if ($batloadmgmt ne 'Aus' && $strategy ne $batloadmgmt) {
CommandSet (undef, "$name attrKeyVal ctrlBatSocManagement${bn} loadStrategy=$batloadmgmt");
}

## aktuelle Indikatoren
##########################
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_'.$bn, 0); # Notfallladung
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', GSPDEF); # aktuelle Einstellung Grid Setpoint
my $finplim = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', FINDEF); # Limit plantControl->feedinPowerLimit
my $preduce = FHEM::SolarForecast::BatteryVal ($name, $bn, 'bpinreduced', MAXPLDEF); # reduzierte Ladeleistung Bat-Konfig
my $actmcc = ReadingsNum ($vicsets, 'MaxChargeCurrent', 0); # akt. maximale Ladestromeinstellung
my $actmcp = ReadingsNum ($vicsets, 'MaxChargePower', undef); # akt. Ladeleistungseinstellung
my $load = MAXPLDEF; # initialer Soll-Ladestrom (A)

my $targetgsp = GSPDEF; # Voreinstellung Grid Setpoint
my $ctype = 'default'; # Voreinstellung Steuerungstyp

## Battery SoC Management
###########################
if ($batsocmgmt eq 'Ein') {
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', MINSOCDEF); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_'.$bn, MINSOCDEF); # optimierter Mindest-SoC

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}
}

## Steuerung nach Ladungsfreigabe
###################################
if ($batloadmgmt eq 'loadRelease') {
$ctype = 'loadRelease';
my $unrestrict = ReadingsNum ($name, 'Battery_ChargeUnrestricted_'.$bn, 0); # Ladefreigabe (1 -> Ladefreigabe)

if (!$unrestrict) { # Grid Setpoint absenken wenn keine ..
$targetgsp = GSPDEF - $surp; # ..Batterie Ladefreigabe
my $neggspmax = -1 * $finplim;
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) { # GridSetpoint setzen
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn ChargeMgmnt 'loadRelease' -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

## Steuerung nach optimaler Ladeleistung
##########################################
if ($batloadmgmt =~ /(?:opt|smart)Power/xs) {
$ctype = 'optPower';
my $otp = ReadingsNum ($name, 'Battery_ChargeOptTargetPower_'.$bn, $preduce); # optimale Ladeleistung (W)
$load = sprintf "%.0f", ($otp / SYSVOLTAG);
}

## Anforderungsladung
#######################
if ($bcrq) { # max. Ladeleistung...
$ctype = 'requestCharging'; # bei Battery_ChargeRequest
my $p;

if ($surp < $preduce) {
$p = $preduce;
}
else {
$p = ReadingsNum ($name, 'Battery_ChargeOptTargetPower_'.$bn, $preduce); # optimale Ladeleistung (W)
}

$load = sprintf "%.0f", ($p / SYSVOLTAG);
}

## Stromeinstellung umsetzen
#############################
if ($load != $actmcc) {
CommandSet (undef, "$vicsets MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt '$ctype' -> MaxChargeCurrent in $vicsets set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_MPII_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>
</div>
</div>

 

==== sequentielle Batterie-Ladung mehrerer Batterien mit lcSlot ====

Der Parameter '''ctrlBatSocManagementXX->lcSlot''' ("load control Slot") definiert eine Zeitperiode am aktuellen Tag in der die Steuerungslogik für die Batteriesteuerung aktiviert ist. Ist dieser Parameter nicht gesetzt, ist das eingestellte Lademanagement über den gesamten Tag aktiert und wäre identisch mit der Einstellung:

lcSlot=00:00-23:59

Somit ist die Ladesteuerung per default über den gesamten Tag aktiv.

Durch das Setzen von lcSlot auf einen täglichen Slot wird die Ladesteuerung auf diese Periode eingegrenzt. In der übrigen Zeit ist die Ladung der Batterie freigegeben (Reading Battery_ChargeUnrestricted_XX) bzw. auf die maximal konfigurierte Ladeleistung eingestellt (Reading Battery_ChargeOptTargetPower_XX). Diese Readings können je nach verwendeter Ladestrategie ausgewertet und zur Steuerung der Batterie(n) verwendet werden.
Die SoC-Steuerung wird durch die lcSlot-Angabe nicht beeinflusst.

Mit lcSlot kann zum Beispiel ein sequentielles Laden von mehreren Batterien umgesetzt werden. Nachfolgend wird ein solches Szenario mit drei Batterien skizziert:

1. die Batterie 1 soll mit voller Leistung geladen werden, die anderen Batterien nur bei weiterem Überschuß. Man würde die jeweiligen
ctrlBatSocManagementXX->lcSlot Schlüssel definieren:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
</pre>

;Wie ist der Ablauf: Die Batterie 1 unterliegt keiner Steuerung (nur von 23:00 bis 23:10 als Dummy-Periode). Das Reading Battery_ChargeUnrestricted_01 wird "1" gesetzt, d.h. die Batterie 1 wird zur Ladung uneingeschränkt freigegeben. Die anderen Batterien unterliegen der Steuerung -> Battery_ChargeUnrestricted_02 / 03 sind "0" und sollen nur geladen werden falls ein gesetztes Einspeiselimit überschritten wird.

Ist das Ladeziel der Batterie 1 erreicht, setzt man um die Batterie 2 vollzuladen:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
</pre>

Die Batterien 1 und 3 unterliegen der Steuerung, d.h. Battery_ChargeUnrestricted_01 / 03 haben den Wert "0". Demgegenüber ist Battery_ChargeUnrestricted_02=1 und soll uneingeschränkt geladen werden.

Ist auch die Batterie 2 voll geladen, würde man das Laden der Batterie 3 aktivieren:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=23:00-23:10
</pre>

Das Setzens via '''attrKeyVal''' hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrund peprüft und ggf. ein Fehler zurückgegeben wird, den der Nutzer in seinem Script auswerten kann. Weiterhin werden die Attribute implizit gespeichert sofern global->autosave nicht explizit auf "0" gesetzt ist.

 

==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 
=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 
=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
== Konfigurationsbeispiele ==

=== Visualisierung solare Vorhersage und reale Erzeugung ===

Zu Beginn jedes neuen Tages gegen 00:00 Uhr werden durch das SolarForecast Device Events für die initiale PV Prognose des kommenden Tages erstellt.
Der Readingteil dieser Events heißt

AllPVforecastsToEvent

Die Uhrzeiten der Events sind so aufbereitet und können direkt geloggt werden um sie in einen SVG Plot zu integrieren.
Im SolarForecast Device ist dieses Reading nicht sichtbar, nur die Events werden erstellt.

Die meteorologischen Bedingungen verändern sich über den Tag permanent. Je nach gewählter Strahlungsdatenquelle (eine API oder DWD Device) erfolgt eine mehr oder weniger dynamische Anpassung der Prognose an die sich verändernde Umwelt.

Aktuelle Prognosedaten sowie die reale PV Erzeugung der vergangenen Stunde können über die Readings

LastHourPVforecast
LastHourPVreal

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.<syntaxhighlight lang="perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.
Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten einlesen kann. Der Code wird nur ausgeführt, wenn das Reading nextCycletime ein Event erzeugt.<syntaxhighlight lang="perl">
forecast_json:nextCycletime.* {

use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my $last_start_ts;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => "%Y-%m-%d %H:%M:%S",
time_zone => "Europe/Berlin",
);

# Alle NextHour-Daten durchsuchen (als Fallback zur Vermeidung einer Endlosschleife auf max. 100 Std. begrenzen)
while ($hour < 100) {
my $hour_str = sprintf("NextHour%02d", $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "starttime", "na");
my $pvfc = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "pvfc", "na");

# Schleife beenden, wenn keine Vorhersage-Werte mehr vorhanden sind
last if $start_str eq "na" or $pvfc eq "na";

my $start_ts = $parser->parse_datetime($start_str); # Zeitzone und Sommer/Winterzeit berücksichtigen
$last_start_ts = $start_ts->clone; # merken für spätere Prüfung

# Zeit in UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $start_ts->set_time_zone("UTC")->iso8601() . "Z",
end => $start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0 + $pvfc,
};

$hour++;
}

# Prüfen, ob der letzte Start-Wert 23 Uhr war. Dann zusätzlich 2 Stunden anhängen, damit übermorgen
# bei evcc vollständig angezeigt wird (siehe https://github.com/evcc-io/evcc/issues/22979)
if (defined $last_start_ts && $last_start_ts->hour == 23) {

# Zeit nach UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $last_start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
end => $last_start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0,
};
push @output, {
start => $last_start_ts->set_time_zone("UTC")->iso8601() . "Z",
end => $last_start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0,
};
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
},
</syntaxhighlight>
[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]
Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):<syntaxhighlight>
define WEBapi FHEMWEB 8089
attr WEBapi csrfToken none
</syntaxhighlight>In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json','[]')} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
</syntaxhighlight>Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

=== Poolsteuerung inkl. Eigenverbrauchsoptimierung und zusätzlichem Verbraucher, um Einspeiselimit zu vermeiden + manuelle Steuerung durch Sonderprogramme ===
'''Vorhandene Hardware:'''

* Poolpumpe, die über mehrere Stufen verfügt. Hier werden zwei verwendet.
** Pump Low: Energiesparprogramm um den Pool umzuwälzen, auch wenn nicht genug PV Leistung zur Verfügung steht. -> ca. 250W
** Pump High: Normalbetrieb wenn genug PV Überschuss zur Verfügung steht. -> ca. 800W zusätzlich
* Poolheizung: Wärmepumpe -> ca. 1,5kW elektrisch
* Nachbars Pool: Pumpe + Salzanlage +pH-Regler -> ca. 650W

'''Anforderungen:'''

* Pool muss täglich mindestens 1x umgewälzt werden.
* Im Idealfall wird der Pool > 2x umgewälzt.
* Bei genügend Überschuss soll der Pool geheizt werden. Es soll nur Sonnenstrom für die Poolheizung verwendet werden.
* Um das Einspeiselimit zu vermeiden, soll auch geheizt werden, wenn der Pool schon warm genug ist. (>28,5 °C)
* Sollte trotzdem noch das Einspeiselimit erreicht werden, soll auch der Pool des Nachbarn versorgt werden.

'''Herausforderungen:'''

* Verbraucher dürfen nur in einer gewissen Reihenfolge geschaltet werden, auch wenn der Überschuss eine andere Reihenfolge ergeben würde.
* Pumpe mit mehreren Stufen muss als zwei Consumer abgebildet werden, um die Schaltlogik in SolarForecast abzubilden. Würde die Trennung außerhalb von Solarforecast realisiert, könnte Solarforecast den Verbraucher schlechter "lernen", denn dann wäre es ein Consumer mit ständig wechselndem Verbrauch.
* Pool des Nachbarn darf nicht laut der benötigten Leistung geschaltet werden, sondern in Abhängigkeit der Einspeisebegrenzung.

In diesem Solarforcast-Device sind 16 Verbraucher definiert. Im Weiteren werden jedoch nur die verwendeten betrachtet. Da diese Reglung mittlerweile recht komplex ist, werden auch viele Dinge, die nicht SolarForcast betreffen, aber trotzdem dazu gehören, gezeigt. Es trägt zum Verständnis bei und man kann sich hier sicher Ideen holen.

'''Ergebnis:'''

In den folgenden beiden Bildern sieht man das Regelverhalten recht gut.
[[Datei:Mustertag ohne Wolken.jpg|zentriert|mini|823x823px|Wolkenloser Tag]]
Hier erkennt man gut das Einschalten der jeweiligen Verbraucher (Pump Low, Pump High, Wärmepumpe und Nachbar Pool). Die Wärempumpe schaltet erst bei 5kW Überschuss ein, da der Pool eigentlich schon warm genug ist. Sie dient "nur" dazu, das EInspeiselimit zu verhindern.Auch das Auschalten ist wieder deutlich zu erkennen. Die Regleung folgt dem Überschuss recht gut. (Die Leistungsspitzen auf dem Plateau sind normale Großverbraucher im Haus.)
[[Datei:Wechselhaft.jpg|zentriert|mini|818x818px|Wechselhafter Tag.]]
In diesem Bild sieht man das "verzweifelte" Regeln um das wechselhafte Wetter auszugleichen. Hier gibt es keine korrekte Reaktion und es wird durch die Sperrzeiten und andere Delays versucht, ein zu häufiges hin- und herschalten möglichst zu vermeiden. In Summe aber auch bei so einem Wetter ein akzeptables Verhalten.

'''Definition der Consumer:'''

'''Allgemeine Erklärungen zu den Definitionen:'''

'''asynchron=0''': Da hier die Werte des Überschusses für das Timing der Schaltvorgänge verwendet werden, darf hier keine Eventsteuerung verwendet werden. Sonst kann man nicht mehr sagen, über welchen Zeitraum der Mittelwert oder der Median gebildet wurde. Dafür wurde die Zykluszeit des SolarForecast-Device auf 60 Sekunden geändert, um die Überlegungen zu vereinfachen. Bei Event-Steuerung könnte man nicht sagen ob die letzten 10 Events in den letzten 5 Sekunden oder in den letzten 10 Minuten aufgetreten sind.

'''power=xxx''': Wurde teilweise etwas höher als der tatsächliche Wert gewählt, um nach dem Einschalten sicherzustellen, dass nicht sofort der gesamte Überschuss "verbraucht" wird und somit gleich wieder abgeschaltet wird.

'''auto=xxx''': Jeder Verbraucher benötigt sein eigenes auto-Reading, da die Automatik für die Regelung in verschiedenen Stufen ein- und ausgeschaltet werden muss.

'''dum_valve''': Dummy-Device in dem die Zustände der Regelung abgebildet werden. Notifys lesen bzw. befüllen diesen Dummy und steuern dann die Hardware bzw. wird der Dummy durch Werte aus der Hardware passend befüllt.

'''surpmeth=median_xx:''' Durch das asynchron=0 in allen Consumern und beim Generator wird von Solarforcast genau alle 60 Sekunden ein Zyklus ausgeführt. Das führt dazu, dass der Median genau über xx Minuten gebildet wird.

'''locktime=xx:xx''': Sicherheitsvorkehrung, dass nicht zu oft geschaltet werden kann. Schont die Hardware und verhindert ein Schwingen. Abhänging vom geschalteten Gerät. z.B. soll die Wärmepumpe möglichst wenig takten, um die Lebensdauer zu verlängern.

Es gibt dann auch noch einige weitere Sicherheitsvorkehrungen, um diese Regelung möglichst stabil und hardwareschonend zu gestalten. Die Schwierigkeit sind nicht die Bilderbuchtage mit einem glatten Verlauf der PV-Leistung, sondern Tage mit ständig wechselndem Überschuss in der Nähe der Schaltgrenzen.

'''swoncond= dum_valve:sf_true:{main::xxx_On}:''' Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann einzuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''swoffcond= dum_valve:sf_true:{main::xxx_Off}''': Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann auszuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''Pump Low: (consumer01)'''<syntaxhighlight lang="perl">
dum_valve:Pool+Low
aliasshort=Low
asynchron=0
auto=pump_low_auto
icon=scene_pool
interruptable=0
mintime=SunPath:0:180
mode=must
noshow=0
notafter=08:00
off="pump_low off"
on="pump_low on"
pcurr=pump_low_power
power=250
surpmeth=median_13
switchdev=dum_valve
swoffcond=dum_valve:sf_true:{main::Check_Pump_Low_Off}
swoncond=dum_valve:sf_true:{main::Check_Pump_Low_On}
swstate=pump_low:on:off
type=other
</syntaxhighlight>Erläuterungen:

* Die Pumpe soll ab Sonnenaufgang, bis 180 Minuten nach Sonnenuntergang (mintime=SunPath:0:180), bei mindestens 250W Überschuss (power=250) gestartet werden.
* Die Pumpe muss spätestens um 8:00 eingeplant werden (notafter=08:00), um das Umwälzen auch bei Schlechtwetter zu garantieren.
* Die Pumpe muss gestartet werden (mode=must) sobald sie eingeplant ist.
* swoncond sorgt dafür, dass sie vor 8:00 nur bei genügend Überschuss gestartet wird, oder es 8:00 ist. swondcond ist mit der eigentlichen Einschaltbedingung (eingeplant und mode=must) UND verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* Überschuss wird auch in swoncond mit der gewählten Methode geprüft.
* Die Pumpe darf, wenn sie gestartet wurde, auch bei fehlendem Überschuss nicht mehr unterbrochen werden. (interruptable=0)
* Die Pumpe wird am Ende der Einplanung ausgeschaltet oder wenn swoffcond erfüllt ist. swoffcond wird true, wenn eine gewisse Wassermenge umgewälzt wurde oder die Sicherheitsbedingungen nicht (mehr) erfüllt sind. swoffcond ist mit der eigentlichen Ausschaltbedingung (Planung endet) ODER verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* {'''main::'''xxx} dient dazu, um die Funktion xxx in der 99_mySolarForecastUtils.pm aus Solarforecast erreichbar zu machen.
* dum_valve:sf_true ist ein Reading, das fix 1 ist und als Vergleichswert für den in Klammern folgenden Perlcode dient. Wenn dieses Reading und der Perlcode gleich sind (1==1), ist die swoncond bzw swoffcond erfüllt.

'''Pump High: (consumer03)'''<syntaxhighlight lang="perl">
dum_valve:Pool+High
aliasshort=High
type=other power=1000 asynchron=0
auto=pump_high_auto
icon=scene_pool
pcurr=pump_high_power
switchdev=dum_valve
swstate=pump_high:on:off
mode=can
mintime=SunPath
on="pump_high on"
off="pump_high off"
surpmeth=median_5
noshow=0
locktime=180:300
interruptable=1
swoncond=dum_valve:sf_true:{main::Check_Pump_High_On}
swoffcond=dum_valve:sf_true:{main::Check_Pump_High_Off}
</syntaxhighlight>Erläuterungen:

* Pump HIgh ist die selbe Pumpe, aber eine höhere Durchflussmenge
* Der Mehrverbrauch beträgt eigentlich 800W wird hier aber mit 1000W angegeben, um eine Hysterese von ca. 200W zu erreichen und damit ein schnelles Abschalten nach dem Einschalten zu verhindern.
* Diese Stufe wird nur bei genügend Überschuss aktiviert. (mode=can)
* Diese Stufe wird bei fehlendem Überschuss unterbrochen. (interruptable=1)
* Diese Stufe wird nur während Sonnenschein eingeplant. (mintime=SunPath)
* locktime sorgt dafür, dass bei schnell wechselnden Bedingungen, nicht ständig umgeschaltet wird. -> Schonung der Pumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Heatpump: (consumer05)'''<syntaxhighlight lang="perl">
Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800 asynchron=0
icon=sani_heating_heatpump
auto=heatpump_auto
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
etotal=Pool_Pin32_monotonic_count_EnergyMeter:kWh
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=1
swoffcond=dum_valve:sf_true:{main::CheckWPOff}
</syntaxhighlight>Erläuterungen:

* Der Verbrauch ist hier wieder etwas zu hoch angegeben (1800W statt realen 1500W), um eine Hysterese zu erreichen.
* Da es sich hier um eine Wärmepumpe handelt, die nicht getaktet werden sollte, ist die locktime in beide Schaltrichtungen mit 10 Minuten relativ hoch.
* Die Ermittlung des Medians ist mit 13 Minuten recht lang, um den Überschuss über lange Zeit zu glätten, damit möglichst selten geschaltet wird. Diese 13 Minuten in Kombination mit der Locktime und der Hysterese führten bei dieser Anlage bisher dazu, dass höchstens 5 Zyklen am Tag geschaltet wurden. -> Hier kann das individuelle Schaltverhalten optimiert werden. Besseres Verfolgen des Überschusses vs. weniger Taktungen der Wärmepumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Nachbars Pool: (consumer07)'''<syntaxhighlight lang="perl">
Shelly_Plug_S_1:Kurz+Pool
aliasshort=Kurz
type=other power=650 asynchron=0
icon=scene_pool
auto=pool_kurz_auto
pcurr=power:W
switchdev=dum_valve
swstate=pool_kurz:on:off
mode=can
mintime=SunPath
on="pool_kurz on"
off="pool_kurz off"
surpmeth=median_13
noshow=0
interruptable=1
locktime=600:300
swoncond=dum_valve:sf_true:{main::Check_Pool_Kurz_On}
swoffcond=dum_valve:sf_true:{main::Check_Pool_Kurz_Off}
</syntaxhighlight>Erläuterungen:

* Dieser Consumer dient als Einspeisebegrenzungsschutz und wird aktiviert, sobald sich der Überschuss der Einspeisegrenze nähert. -> siehe '''99_mySolarForecastUtils.pm'''
* Verbraucher kann recht träge geschaltet werden. (surpmeth=median_13 und locktime=600:300)
* Consumer wird ausgeschaltet wenn ein gewisser Überschuss unterschritten wird und somit die Einspeisegrenze wieder weit genug weg ist. -> siehe '''99_mySolarForecastUtils.pm'''
'''99_mySolarForecastUtils.pm'''

Hier sind die Funktionen, die für diese Regelung verwendet werden, der Übersichtlichkeit halber in einzelnen Blöcken mit Erklärungen dargestellt.<syntaxhighlight lang="perl">
package main;
use strict;
use warnings;

my $pool_dummy = 'dum_valve';
my $pool_temperature = 'Pool_Temp';
my $flow_sensor = 'Pool_Pin_A0';
my $water_counter_l1 = 'pump_l1_hc';
my $water_counter_l2 = 'pump_l2_hc';
my $target_temp = 28.4; # maximum temperature for heating, without infeed limit
my $pool_kurz_sw_hofb = 'PwSw_Schalter'; # Homematic switch at pool neighbour
my $pool_kurz_sw_kurz = 'Shelly_Plug_S_1'; # Shelly switch for pool Kurz at home

my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;

my $switch_delay = 160; # just under three minutes

sub
SolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

</syntaxhighlight>

* Hier werden die IDs der Geräte definiert, um über sprechende Namen darauf zugreifen zu können.
* Einige Devices und Parameter, die immer wieder gebraucht werden sind hier angegeben.
* sprintf wird verwendet um sicherzustellen, dass die IDs zweistellig sind. z.B. 3 -> 03

'''Pump Low'''<syntaxhighlight lang="perl">
###################
### Pumpe - LOW ###
###################

sub
Check_Pump_Low_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'surpmethResult','');
my $nom_power = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'power','');
my ($min, $hour) = (localtime())[1,2];
my $timer = 0;
if($hour > 8 || ($hour == 8 && $min >= 0)){$timer=1;}

if(ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ($surplus > $nom_power
|| $timer
)
)
{
return 1;}
else
{
return 0;}
}

sub
Check_Pump_Low_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount > $desired_amount_l1)
&& (ReadingsVal($pool_dummy,"pump_high","on") eq "off" && ReadingsAge($pool_dummy,"pump_high",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{
return 1;
}else{
return 0;
}
}

</syntaxhighlight>Einschalten:

* Es wird der errechnete Wert für den Überschuss von SolarForecast verwendet und auch der benötigte Überschuss aus dem Consumer ausgelesen.
* Das Einschalten wird erst durch erfolgreiche Prüfung der Hardwarevoraussetzungen erlaubt. -> Das Motorventil steht richtig und es ist kein Sonderbetrieb (Reinigung, Massage, Winter, o.ä.) aktiv.
* Es muss entweder genügend Überschuss vorhanden sein oder es ist 8:00.

Ausschalten:

* Wenn der Badebetrieb aktiv ist (bath_mode==1, [bei Außentemperatur > 24°C]) wird nach 90m³ Gesamtumwälzung ausgeschaltet.
* Wenn der Badebetrieb nicht aktiv ist (bath_mode==0, [bei Außentemperatur < 20°C]) wird bereits nach 42m³ Gesamtumwälzung ausgeschaltet.
* Prüfung, ob Pump High schon aus ist. Sollte durch die Logik gar nicht möglich sein, aber es könnte manuell oder durch einen (Logik-)Fehler trotzdem eingeschaltet sein.
* Prüfung, ob alle Hardware-Funktionen in einem für die Automatik geeigneten Zustand sind.
* Es wird auch geprüft, ob Pump High seit mindestens 3 Minuten aus ist, um zu verhindern, dass wegen fehlendem Überschuss gleich mehrere Geräte ausgeschaltet werden.
* Da die Zykluszeit 60 Sekunden ist, führen die 160 Sekunden dazu, dass nach drei Minuten(180 Sekunden) ein definierter Wert gilt. Mit 180 Sekunden könnte es manchaml eine Minute mehr sein.

'''Pump High'''<syntaxhighlight lang="perl">
####################
### Pumpe - HIGH ###
####################

sub
Check_Pump_High_On{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount < $desired_amount_l2)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_low","off") eq "on" && ReadingsAge($pool_dummy,"pump_low",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

sub
Check_Pump_High_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;

if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}
if(($amount > $desired_amount_l2)
&& (ReadingsVal($pool_dummy,"heatpump","on") eq "off" && ReadingsAge($pool_dummy,"heatpump",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs noch nicht erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob Pump Low schon seit mindestens 3 Minuten aktiv ist. (sollte eigentlich immer der Fall sein, wenn die Automatik für Pump High aktiv ist)

Ausschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs bereits erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob die Wärmepumpe schon seit mindestens 3 Minuten aus ist. Ermöglicht drei Minuten lang, den Median für den Überschuss zu aktualisieren.

'''Wärmepumpe'''<syntaxhighlight lang="perl">
##################
### Wärempumpe ###
##################
sub
CheckWPOn(){
my $name = 'energy_mgmt';
my $surplus_on = 5000; # minimum surplus to avoid infeed limit with heatpump
my $surplus_restart = 3000; # minimum surplus to re-enable heatpump, when avoidung infeed limit and a big consumer turned the hp off

my $planstate = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'planstate','');
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if ($planstate =~ /^([^:]+)/) {
$planstate = $1;
}

if(ReadingsVal($flow_sensor,"reading","off") eq "on"
&& (ReadingsVal($pool_dummy,"special_function","") eq "none"
|| ReadingsVal($pool_dummy,"special_function","") eq "party"
)
&& ReadingsVal($pool_dummy,'heat_protection','on') eq "off"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_high","off") eq "on" && ReadingsAge($pool_dummy,"pump_high",0) > $switch_delay)
&& (ReadingsVal($pool_temperature,"temperature",30) < $target_temp
|| (ReadingsVal($pool_temperature,"temperature",15) >= $target_temp
&& ( $surplus > $surplus_on
|| (($planstate eq "replanned") && ($surplus > $surplus_restart))
)
)
)
)
{return 1}
else
{return 0}
}

sub
CheckWPOff{
my $name = 'energy_mgmt';
my $surplus_off = 1000; #minimum surplus to keep heatpump on, when avoiding infeed limit

my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if((ReadingsVal($flow_sensor,"reading","on") eq "off"
|| !((ReadingsVal($pool_dummy,"special_function","") eq "none")
|| (ReadingsVal($pool_dummy,"special_function","") eq "party")
)
|| ReadingsVal($pool_dummy,'heat_protection','off') eq "on"
|| ReadingsVal($pool_dummy,"valve_position","") ne "normal"
|| ((ReadingsVal($pool_temperature,"temperature",15) > $target_temp)
&& ($surplus < $surplus_off)
)
)
&& (ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob Flussensor ein. (Pool_pin_A0) -> Wasser fließt durch die Wärmepumpe.
* Prüfung, ob Pool in Normal- oder Partybetrieb ist und das Ventil in Normalposition ist. In beiden Fällen läuft Pump High.
* Einschalten wenn genug Überschuss da ist und die Temperatur <28.4°C ist oder wenn über 5000W Überschuss (Einspeisebegrenzung bei 5900W) da ist, egal wie warm der Pool ist.
* Sonderfall: Wenn die Wärmepumpe durch einen/mehrere Großverbrucher "kurz" ausgeschaltet wurde (swoffcond) wird sie ausgeplant. Ein Notify plant sie wieder ein. Wenn das passiert, soll die Wärmepumpe aber wieder bei 3000W Überschuss gestartet werden, um die Energie noch weiter zu nutzen bis der Überschuss unter 1000W fällt. (Hysterese von 500W, da die WP nur 1500W braucht)

Ausschalten:

* Ausschalten sobald hardwaremäßig irgendetwas faul ist. (Betriebsart, Ventilstellung, Durchfluss)
* Ausschalten wenn kein Überschuss. (interruptable=1)
* Wenn Wassertemperatur über 28,5°C und der Überschuss kleiner als 1000W ist.
* Nur schalten, wenn Wärmepumpe läuft und seit mindestens 3 Minuten läuft (Sicherheit). Das verhindert das erneute Triggern des Notifys, wenn die Pumpe schon aus ist. Sollte nicht passieren, aber sicher ist sicher.

'''Nachbar Pool'''<syntaxhighlight lang="perl">
###################
### Pool - KURZ ###
###################
sub
Check_Pool_Kurz_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus > 3000)
&& ((ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) >160) || ReadingsVal($pool_dummy,'heat_protection','off') eq 'on' ))
{return 1}
else
{return 0}
}

sub
Check_Pool_Kurz_Off{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus < 1000 )
&& (ReadingsVal($pool_dummy,"pool_kurz","off") eq "on" && ReadingsAge($pool_dummy,"pool_kurz",0) >160))
{return 1}
else
{return 0}
}
</syntaxhighlight>Einschalten:

* Überschuss ist nahe der Einspeisegrenze (5900W) und Wärmepumpe läuft seit mindestens 3 Minuten. Es wird schon bei 3000W eingeschaltet, um dem Nachbarn etwas Gutes zu tun ;-)

Ausschalten:

* Überschuss ist unter 1000W. -> Um noch Reserven für den eigenen Verbrauch zu haben.

'''Hilfsfunktionen'''

'''ctrlUserExitFn'''

Hier erfolgt nach jedem Zyklus die Festlegung der verschiedenen Automatikmodi.<syntaxhighlight lang="perl">
#############################################################
##################### Exit Function #########################
#############################################################
my $ctrl_dummy = "dum_valve"; # dummy device for pool-control
my $automatic = ReadingsNum($ctrl_dummy,"sf_automatic",1);

if($automatic){

my $pump_low_state = ReadingsVal($ctrl_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe

my $pump_high_state = ReadingsVal($ctrl_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe

my $heatpump_state = ReadingsVal($ctrl_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
my $pool_heat_protection = ReadingsVal($ctrl_dummy,'heat_protection','on');

my $pool_kurz_state = ReadingsVal($ctrl_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools

my $pump_low_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'surpmeth', '');
if ($pump_low_delay =~ /_(\d+)/) {
$pump_low_delay = int(($1/2 + 1) * 60);
Log3 ("SolarForecast", 1, "SolarForecast: pump_low_delay: $pump_low_delay");
} else {
$pump_low_delay = 220;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_low is: $pump_low_delay, but must be given as method_number, using fallback value");
}

my $pump_high_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'surpmeth', '');
if ($pump_high_delay =~ /_(\d+)/) {
$pump_high_delay = int(($1/2 + 1) * 60);
} else {
$pump_high_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_high is: $pump_high_delay, but must be given as method_number, using fallback value");
}

my $heatpump_delay = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'surpmeth', '');
if ($heatpump_delay =~ /_(\d+)/) {
$heatpump_delay = int(($1/2 + 1) * 60);
} else {
$heatpump_delay = 290;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for heatpump is: $heatpump_delay, but must be given as method_number, using fallback value");
}

my $pool_kurz_delay = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'surpmeth', '');
if ($pool_kurz_delay =~ /_(\d+)/) {
$pool_kurz_delay = int(($1/2 + 1) * 60);
} else {
$pool_kurz_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pool_kurz is: $pool_kurz_delay, but must be given as method_number");
}

############################
# Überhitzungsschutz aktiv #
############################

if($pool_heat_protection eq 'on'){
if($heatpump_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 0");
}
if($heatpump_state eq "on"){
fhem("set $ctrl_dummy heatpump off")
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pool_kurz_delay && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pump_high_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $pump_high_delay && $pool_kurz_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
##################################
# Überhitzungsschutz nicht aktiv #
##################################
}else{
if($heatpump_auto == 0 && $heatpump_state eq "off"){
if($pool_kurz_state eq "on"){
fhem("set $ctrl_dummy pool_kurz off");
}
if($pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $heatpump_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $heatpump_delay && $heatpump_auto == 0 && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "on" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pool_kurz_delay && $pump_high_state eq "on" && $pool_kurz_auto == 0 && $pump_high_auto == 1 && $heatpump_auto == 1){
# pump_high muss on sein, da sonst die automatik ausgeschaltet wird wenn die pumpe gerade interrupted ist.
# Bei unterschiedlichen Medianlängen ist es möglich, dass WP ein ist und pump_high abschaltet wegen surplus == 0
# Nachbarpool würde auf EIN warten, aber pump_high dürfte nicht wieder einschalten, obwohl genügend Überschuss da ist.
fhem("set $ctrl_dummy pump_high_auto 0");
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $heatpump_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $heatpump_delay && $pool_kurz_auto == 1 && $heatpump_auto == 0 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "off" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pump_high_delay && $heatpump_auto == 1 && $pump_high_auto == 0 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $heatpump_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 1 && $pool_kurz_auto == 0){
# heatpump muss aus sein, da sonst vor Ablauf der Locktime die Automatik ausgeschaltet wird und die WP nicht mehr ausschalten kann.
fhem("set $ctrl_dummy heatpump_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
}
}
#################################################
# Check hardware-state vs. reading-state
# re-trigger notify
#################################################
my $delay_retrigger = 100; #delay time to wait until re-trigger the notify

if(ReadingsVal($ctrl_dummy,'pool_kurz','on') eq 'off' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'on'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: off");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-off must be re-triggered");
DebianMail('clemens@familie-hofbauer.at','Notify Pool Kurz',"Notify hat nicht ausgeschaltet -> re-trigger");
}elsif(ReadingsVal($ctrl_dummy,'pool_kurz','off') eq 'on' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','on') eq 'off'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: on");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-on must be re-triggered");
DebianMail('clemens@familie-hofbauer.at','Notify Pool Kurz',"Notify hat nicht eingeschaltet -> re-trigger");
}elsif((ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_on' || ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_off') && ReadingsAge($pool_kurz_sw_kurz,'state',0) > $delay_retrigger){
# state not clear
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz state unclear");
DebianMail('clemens@familie-hofbauer.at','Status Pool Kurz unklar',"Status HM-Schalter set_xx");
}

}
1;
</syntaxhighlight>
'''Erläuterungen:'''

* '''Verzögerungen der einzelnen Stufen:'''
** Die delays der einzelnen Stufen werden aus den surpmethods berechnet. Das dient dazu, dass der Median mit den Werten nach dem ein-/ausschalten des vorheriegen Verbrauchers bis zur Hälfte + einen Wert gefüllt wird und somit sicher das Umschalten des vorherigen Verbrauchers den Median nicht mehr beeinflusst.
* '''Überhitzungsschutz:'''
** Da durch die Wärmepumpe Überschuss "verheizt" wird, der durch das Einspeiselimit gar nicht produziert würde, kann es vorkommen, dass der Pool unangenehm warm wird.
** Um das zu vermeiden gibt es ein Reading, welches gesetzt wird, wenn der Pool eine gewisse Temperatur überschreitet. Dieses Setzen und Zurücksetzen erfolgt mit einer Hysterese von 0.2°C, um ein Takten der Wärmepumpe zu verhindern. Diese 0.4°C sind bei dieser Wassermenge einige Stunden.
** Wenn der Überhitzungsschutz aktiv ist, wird die Wärmepumpe in der Kette übersprungen.
** Wenn sich der Hitzeschutz während des Betriebs ändert, wird die Wärmepumpe bzw. der Pool vom Nachbarn passend ausgeschaltet und die Modi entsprechend gesetzt.
* '''On-chain:'''
** Wenn am Morgen Pump Low seit $pump_low_delay aktiv ist und alle folgenden Consumer noch nicht, dann wird die nächste Stufe freigegeben. -> Pump High
** Wenn Pump High seit $pump_high_delay aktiv ist und alle folgenden Consumer noch nicht, wird die Wärmepumpe freigegeben. -> Heatpump
** Wenn die Wärmepumpe seit $heatpump_delay aktiv ist und der letzte Consumer noch nicht, wird der letzte Verbraucher freigegeben. -> Pool Kurz Gleichzeitig wird die Automatik für Pump High ausgeschaltet, da dieser Verbraucher erst unterbrochen werden darf wenn die Wärmepumpe aus ist!
** Wenn der letzte Verbraucher aktiviert ist, wird die Automatik der Wärmepumpe deaktiviert, da ja zuerst der letzte Verbraucher (Pool Kurz) wieder ausgeschaltet werden muss, bevor der vorletzte (Wärmepumpe) wieder ausgeschaltet werden darf. Da es keinen nachfolgenden Verbraucher mehr gibt, kann hier auf ein delay verzichtet werden, da es nicht passieren kann, dass zwei Verbraucher wegen sehr hohem Überschuss unmittelbar hintereinander geschaltet werden können.
[[Datei:Poolsteuerung mit unterschiedlichen Automatikmodi.jpg|alternativtext=Poolsteuerung|mini|Consumer der Poolsteuerung|500x500px]]
'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von fehlendem Überschuss jederzeit unterbrochen werden kann und der "folgende" Consumer, der auf das Einschalten wartet. Pump Low ist immer im Automatikmodus, da diese nie unterbrochen wird. (mode=must, interruptable=0)

* '''Off-chain:'''
** Wenn der letzte Verbraucher seit mindestens der delay-Zeit aufgrund von fehlendem Überschuss inaktiv war, im Automatikmodus ist und der vorherige Verbraucher nicht im Automatikmodus ist, wird der vorherige Verbraucher in den Automatikmodus geschaltet und wartet jetzt auch auf das Ausschalten. Wenn der Überschuss steigt, springt man wieder in die on-chain und der letzte Verbraucher wird eingeschaltet und die Automatik des vorletzten Verbrauchers deaktiviert.
** Wenn die Wärmepumpe seit mindestens der delay-Zeit aus ist, sich im Automatikmodus befind und Pump High noch nicht im Automatikmodus ist, wird die Automatik für den Nachbarpool ausgeschaltet, da er ja jetzt nicht mehr einschalten darf, da zuerst die Wärmepumpe ein sein müsste. Die Automatik von Pump High wird wieder aktiviert, da diese jetzt auf das Ausschalten wartet. Steigt der Überschuss wieder, wird in den entsprechenden On-chain Zweig gesprungen.
** Wenn Pump High mindestens die delay-Zeit aus ist, wird die Automatik der Wärmepumpe deaktiviert, da diese ja erst einschalten darf, wenn Pump High wieder läuft. Steigender Überschuss führt wieder zum aktivieren von Pump High und zum Sprung in den entsprechenden On-chain Zweig.
** Wenn Pump Low ausgeschaltet wird, wird sofort die Automatik für Pump High ausgeschaltet, da durch das spätere Ausschalten von (der evtl. wieder eingeschalteten) Pump High, hardwaremäßig wieder Pump Low aktiviert wird, aber durch SolarForecast nie ausgeschaltet wird, da Pump Low vor ein paar Minuten ja schon logisch ausgeschaltet wurde.

'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von neuem Überschuss jederzeit wieder gestartet werden kann und der "vorherige" Consumer, der auf das Ausschalten wartet.

* '''Synchronisation Hardware vs. Reading:'''Manchmal passiert es, dass durch die etwas aufwendigen Umschaltprozesse die Hardware dem Reading nicht folgt/folgen kann. Evtl. Gründe sind Funkunterbrechung, verzögerte Umschaltung usw. Daher wird bei jedem Zyklus der Status geprüft und evtl. das event nochmal getriggert, um die Umschaltung erneut auszuführen. 

'''Hilfs-Notifys für die Automatik'''

Da durch das Verwenden von swoffcond die Verbraucher beim Ausschalten auch ausgeplant werden, aber eigentlich "nur" unterbrochen werden sollen, müssen sie wieder neu eingeplant werden. Dazu sind notifys nötig. Wichtig: IDs müssen zweistellig angegeben werden!

Wärmepumpe:<syntaxhighlight lang="perl">
dum_valve:heatpump:.off sleep 10; set energy_mgmt consumerNewPlanning 05
</syntaxhighlight>
Nachbar Pool:<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.off sleep 10; set energy_mgmt consumerNewPlanning 07
</syntaxhighlight>

'''Eine Pumpe mit einem Energiezähler als zwei Consumer verwenden'''

Die verwendete Pumpe hat vier Betriebsarten mit unterschiedlichen Leistungen. Da sie als zwei Consumer abgebildet wird, führt das dazu, dass die Leistung fälschlicherweise von SolarForecast auch zweimal gezählt wird. Die Lösung sind Dummy-Readings, welche die Leistungsdaten passend auseinander rechnen.<syntaxhighlight lang="perl">
Pool_Strom_Pumpe:Pool_Pin31_monotonic_count_PowerCurrent:.* {
my $power = $EVTPART1;
my $pump_low = ReadingsVal('dum_valve','pump_low','off');
my $pump_high = ReadingsVal('dum_valve','pump_high','off');
my $power_low_sim = 250;

if($pump_low eq "on" && $pump_high eq "on"){
my $power_low = $power_low_sim; #fiktiver Verbrauch der niedrigen Stufe
my $power_high = $power - $power_low_sim;
fhem("set dum_valve pump_low_power $power_low");
fhem("set dum_valve pump_high_power $power_high");
}
elsif($pump_low eq "on" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power $power");
fhem("set dum_valve pump_high_power 0");
}
elsif($pump_low eq "off" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power 0");
}elsif($pump_low eq "off" && $pump_high eq "on"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power $power");
}
}
</syntaxhighlight>
Erläuterungen:

* Es sind alle vier Möglichkeiten der zwei Pumpenlevel abgebildet.
* Wenn die Automatik deaktiviert ist und die Level 1-4 von extern geschaltet werden, zählen sie dadurch korrekterweise nicht zu diesen beiden Consumern.

'''Notifys für das hardwaremäßige Schalten der Consumer'''

Es werden einige Notifys verwendet, die die Umsetzung vom Dummy-Device auf die Hardware erledigen, da ein logisches Ein teilweise hardwaremäßig einige Dinge erfordert.

Notify für Pump Low:<syntaxhighlight lang="perl">
dum_valve:pump_low:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 60; set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin14 off; sleep 5; set Pool_Pin12 off; sleep 15; set Pool_Pin25 off");
}else{
Log3 ("Pool", 4, qq{Notify Level1 - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterungen:

* Beim Einschalten ist es nötig für eine Minute Pump High zu aktivieren, um Luft aus der Elektrolysezelle zu spülen, bevor Pump Low aktiv sein darf. (Pin26 und Pin25 sind die Steuerpins auf der Interfacekarte der Pumpe für die beiden Level.)
* Beim Ausschalten werden zuerst die Salzanlage (Pin14) und die pH-Anlage (Pin12) deaktiviert, damit noch 15 Sekunden lang die Elektrolysezelle mit frischem Wasser gespült wird, um das verbleibende Chlor auszuspülen. 
Notify für Pump High:<syntaxhighlight lang="perl">
dum_valve:pump_high:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 1; set Pool_Pin25 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}else{
Log3 ("Pool", 4, qq{Notify Level 2- parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Da die Interfacekarte immer auf den höchsten Level reagiert, wird beim Umschalten zuerst Pump High aktiviert und nach einer Sekunde Pump Low deaktiviert, um ein "stufenloses" (ohne Ausschalten) Umschalten zu ermöglichen. Beim Ausschalten genauso.

Notify für die Wärmepumpe:<syntaxhighlight lang="perl">
dum_valve:heatpump:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin6 on");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin6 off");
}else{
Log3 ("Pool", 4, qq{Notify heatpump - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Hier reicht ein dirketes Übernehmen aus dem Dummy.

Notify für den Nachbar-Pool:<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.* {
if($EVTPART1 eq "on" && ReadingsVal("Shelly_Plug_S_1","state","on") eq "off"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 on\")}}; sleep 5; set PwSw_Schalter on");
}elsif($EVTPART1 eq "off" && ReadingsVal("Shelly_Plug_S_1","state","off") eq "on"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 off\")}}; sleep 5; set PwSw_Schalter on");
}else{
Log3 ("Pool", 4, qq{Notify Pool Kurz - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung

* Da hier eine Pumpe durch einen 3-poligen Umschalter zwischen zwei Hausanspeisungen umgeschaltet wird, ist es wichtig, dass die Pumpe dazwischen '''gesichert''' zum Stehen gebracht wird! Sonst führt die rotierende Pumpe als Generator zu einem gewaltigen Kurzschluss mit der "fremden" Phase. War nicht schön ...

'''Sonderprogramme für den Poolbetrieb'''

Hier ist das Aus- und Einschalten der Solarforcast-Automatik zu sehen. Es werden alle Stati gespeichert. Danach kann von beliebigen "Sonderfunktionen" (Reinigung des Filters, Massagefunktion, usw.) auf die Hardware zugegriffen werden. Wenn wieder in den Automatikmodus zurückgewechselt wird, wird hardwaremäßig wieder der Zustand der Automatik von vorher hergestellt, die Stati wieder zurück geschrieben und die Automatik wieder aktiviert.<syntaxhighlight lang="perl">
##############################################
# Status speichern und Automatik ausschalten #
##############################################
sub PoolAutoOff{
my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;
my $sf = 'energy_mgmt';

# my $pump_low_state = ReadingsVal($valve_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe
# my $pump_high_state = ReadingsVal($valve_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe
# my $heatpump_state = ReadingsVal($valve_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($sf, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
# my $pool_kurz_state = ReadingsVal($valve_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools
fhem("set $valve_dummy pump_low_auto 0");
fhem("set $valve_dummy pump_high_auto 0");
fhem("set $valve_dummy heatpump_auto 0");
fhem("set $valve_dummy pool_kurz_auto 0");
fhem("setreading $valve_dummy sf_automatic 0");
fhem("setreading $valve_dummy last_auto_pump_low $pump_low_auto");
fhem("setreading $valve_dummy last_auto_pump_high $pump_high_auto");
fhem("setreading $valve_dummy last_auto_heatpump $heatpump_auto");
fhem("setreading $valve_dummy last_auto_pool_kurz $pool_kurz_auto");

my $last_pump_level_1 = ReadingsVal($valve_dummy,"pump_low","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"pump_high","off");
my $last_pump_level_3 = ReadingsVal($pump_level_3,"value","off");
my $last_pump_level_4 = ReadingsVal($pump_level_4,"value","off");
my $last_heatpump = ReadingsVal($valve_dummy,"heatpump","off");
fhem("setreading $valve_dummy last_pump_level_1 $last_pump_level_1");
fhem("setreading $valve_dummy last_pump_level_2 $last_pump_level_2");
fhem("setreading $valve_dummy last_pump_level_3 $last_pump_level_3");
fhem("setreading $valve_dummy last_pump_level_4 $last_pump_level_4");
fhem("setreading $valve_dummy last_heatpump $last_heatpump");
}

##########################################
# Status laden und Automatik einschalten #
##########################################
sub PoolAutoOn{
my $last_pump_level_4 = ReadingsVal($valve_dummy,"last_pump_level_4","off");
my $last_pump_level_3 = ReadingsVal($valve_dummy,"last_pump_level_3","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"last_pump_level_2","off");
my $last_pump_level_1 = ReadingsVal($valve_dummy,"last_pump_level_1","off");
my $last_heatpump = ReadingsVal($valve_dummy,"last_heatpump","off");
fhem("set $pump_level_4 $last_pump_level_4");
fhem("set $pump_level_3 $last_pump_level_3");
fhem("set $pump_level_2 $last_pump_level_2");
if($last_pump_level_1 eq "on" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_2 on; sleep 1; set $pump_level_1 $last_pump_level_1; sleep 28; set $pump_level_2 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "on" && $last_pump_level_2 eq "on" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "off" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}
fhem("sleep 10; set $heatpump $last_heatpump");
fhem("setreading $valve_dummy last_pump_level_1 none");
fhem("setreading $valve_dummy last_pump_level_2 none");
fhem("setreading $valve_dummy last_pump_level_3 none");
fhem("setreading $valve_dummy last_pump_level_4 none");
fhem("setreading $valve_dummy last_heatpump none");
fhem("setreading $valve_dummy valve_position normal");
my $last_auto_pump_low = ReadingsVal($valve_dummy,"last_auto_pump_low",0);
my $last_auto_pump_high = ReadingsVal($valve_dummy,"last_auto_pump_high",0);
my $last_auto_heatpump = ReadingsVal($valve_dummy,"last_auto_heatpump",0);
my $last_auto_pool_kurz = ReadingsVal($valve_dummy,"last_auto_pool_kurz",0);
fhem("set $valve_dummy pump_low_auto $last_auto_pump_low");
fhem("set $valve_dummy pump_high_auto $last_auto_pump_high");
fhem("set $valve_dummy heatpump_auto $last_auto_heatpump");
fhem("set $valve_dummy pool_kurz_auto $last_auto_pool_kurz");
fhem("setreading $valve_dummy last_auto_pump_low none");
fhem("setreading $valve_dummy last_auto_pump_high none");
fhem("setreading $valve_dummy last_auto_heatpump none");
fhem("setreading $valve_dummy last_auto_pool_kurz none");
}
</syntaxhighlight>Erläuterungen:

* pump_level_1 ist Pump Low, pump_level_2 ist Pump High, pump_level_3 und pump_level_4 sind Sonderfunktionen (Filterreinigung, Massage)
* Beim Wiedereinschalten von Pump Low ist es wieder nötig kurz Pump High zu aktivieren, um Luft auszuspülen.
* Es wird der Zustand von Solarforecast gespeichert und danach auf die Hardware geschrieben. -> Stellt sicher, dass nach dem Einschalten der Automatik der logical switchstate zum physical switchstate passt.

== Tips & Tricks ==
* Interruptable verhält sich völlig anders, wenn der Perlcode 1 oder 0 liefert, als wenn man 1 oder 0 in der Config hinterlegt. -> siehe commandref
* Rückgabewert bei swoncond und swoffcond wird mit dem Readingswert verglichen und nicht dirket verwendet. Bsp. wenn das Reading 100 enthält muss auch der Rückgabewert des Perlcodes 100 liefern, um true zu ergeben.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2025-09-08T14:20:03Z

All-Ex: /* PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) */

{{Baustelle}}
{{Hinweis|Die vorliegende Wiki-Seite befindet sich im Aufbau.}}
{{Infobox Modul
|ModPurpose=Solarprognose und Verbrauchersteuerung
|ModType=d
|ModCmdRef=76_SolarForecast
|ModFTopic=117864
|ModForumArea=Solaranlagen
|ModTechName=76_SolarForecast.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
[[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung|SolarForecast]] ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:
[[Datei:sfc1.png|right|thumb|300px|grafische Ansicht SolarForecast]]

::* zur Gewinnung solarer Prognosewerte können die SolCast API, OpenMeteo API, Forecast.Solar API, Victron VRM Portal API oder alternativ DWD Stahlungswerte-Stationen verwendet werden

::* optionale KI Unterstützung der PV-Prognose bei Verwendung von geeigneten Solar-API's

::* es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose sowie SoC Prognose (bei Batterie-Integration) erstellt

::* Wetterdaten werden über DWD Wetter-Stationen oder verschiedene API integriert. Es können verschiedene API zur Gewinnung von Solar- und Wetterdaten kombiniert werden.

::* Sprachensupport EN / DE

::* die Prognosedaten, Wetterdaten, Verbraucherplanungen und die aktuellen Energieflüsse werden in umfangreich anpassbaren integrierten Grafiken dargestellt

::* es wird keine externe SQL-Datenbank benötigt, die Datenhaltung erfolgt in einer Memory basierten Cachedatenbank inkl. einer Filesystempersistenz zur Datensicherung und Wiederherstellung beim FHEM-Restart

::* die Integration von Geräten wie Wechselrichter, Energy Meter, Batterien, Wetterstationen oder Verbrauchern ist offen und universell gestaltet und bietet dem Anwender maximale Freiheiten bei der Einrichtung seines individuellen Solardatensystems.

::* eine Integration von bis zu 4 Inverter und Smartloader (DC-DC Batterieladegeräte) ist möglich

::* eine Integration von bis zu 3 nicht PV-Energieerzeugern wie BHKW, Windrädern oder Notstromaggregaten ist möglich

::* eine integrierte und umfangreich anpassbare Verbrauchersteuerung vereint die PV Prognose basierte Einplanung der Verbraucher mit der Möglichkeit die Verbraucher durch das Modul schalten zu lassen und dadurch auf PV Erzeugungsschwankungen automatisch dynamisch zu reagieren

::* Einbindung von bis zu drei Batteriespeichersystemen

::* Bereitstellung von Leitwerten zur optimalen Einstellung/Steuerung von Batteriespeichersystemen

::* trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzererlebnis geboten

'''Abgrenzung:''' Das Modul 76_SolarForecast ist nicht zu verwechseln mit der SQL-basierten (DbLog) Prognose-Lösung mit Kostal Plenticore Wechselrichtern, die auf der eigenen Seite '''[[Kostal_Plenticore_10_Plus]]''' behandelt wird. Diese Lösung beschreibt kein monolithisches Modul, sondern basiert auf einer orchestrierbaren Zusammenstellung individueller Perl Programmbausteine.

Im vorliegenden Wiki-Beitrag wird ausschließlich das Modul 76_SolarForecast behandelt.

== Rahmenbedingungen und Voraussetzungen ==

Das Wiki gibt allgemeingültige und teilweise sehr spezifische bzw. tiefgehende Informationen und Handlungsempfehlungen zum SolarForecast Modul. Die dargestellten Informationen beziehen sich auf den zum Zeitpunkt der Wiki-Erstellung vorhandenen Entwicklungsstand des Moduls. Durch die stetige Weiterentwicklung können sich Abweichungen zum beschriebenen Inhalt ergeben oder zur Obsoleszenz dieser Inhalte führen.

Vergleiche deshalb die Informationen immer mit der aktuellen Befehls-Referenz zum Modul!

== Definition ==
Ein SolarForecast Device wird mit dem Befehl

define <Name> SolarForecast

angelegt. Nach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert. Alle Attribute und Readings die eine Einstellung der Anlage bewirken, sind mit dem Präfix "setup" versehen.

Die Verwendung von setup-Readings gestattet es die Anlagenparameter dynamisch im Betrieb zu verändern. So kann mit

set <Name> setupStringAzimuth bzw.
set <Name> setupStringDeclination

die Ausrichtung und der Neigungswinkel der PV-Module ständig angepasst werden, was zum Beispiel bei einer dem Sonnenstand nachgeführten Anlage von Bedeutung ist.

Die abgefragten Einstellungen während des Dialoges sind ausführlich in den entsprechenden Attributen bzw. Set-Kommandos erläutert. Die benötigten Informationen sind anhängig von der gewählten Prognose-API und können im Umfang variieren.

[[Datei:Screenshot 2024-09-21 213257.png|right|thumb|400px|Anlagenprüfung über Drucktaste in der Kopfgrafik]]

Sobald alle verlangten Einstellungen vorgenommen sind, sollte eine Anlagenprüfung mit

set <Name> plantConfiguration check

oder über die angebotene Drucktaste in der Grafik durchgeführt werden. Es wird eine Plausibilitätsprüfung vorgenommen und das Ergebnis sowie eventuelle Hinweise bzw. Fehler ausgegeben.
Die Prüfung kann beliebig wiederholt werden und sollte sich bei jeder Einstellungsänderung der Anlage durchgeführt werden. Dadurch wird die Wahrscheinlichkeit von fehlerhaften Einstellungen minimiert.

Neben den grundlegenden Einstellungen können im Device weitere sekundäre Anlagenkomponenten wie Batteriesystem(e) (Attribut setupBatteryDev1 - setupBatteryDev3), weitere Wetter-Devices (Attribut setupWeatherDev1 - setupWeatherDev3) oder sonstige Erzeuger (z.B. BHKW, Winderzeugung, Notstromaggregat) integriert werden (Attribut setupOtherProducer01 - setupOtherProducer03).

Die verlangten Parameter der Anlage werden in der Online-Hilfe umfassend beschrieben und deren Funktion erschließt sich zum größten Teil selbst. Dennoch soll nachfolgend auf einige Punkte im Zusammenhang der Einrichtung eingegangen werden.

 
=== Hinweise zur Struktur der Attribute ===

Durch die umfangreichen Funktionen des Moduls würde bei Nutzung der im FHEM herkömmlich vorhandenen Attributstruktur die Anzahl der benötigten Attribute extrem stark steigen und nicht sinnvoll genutzt werden können. Deshalb gibt es neben den ''gewöhnlichen'' Attributen mit einfachen Werteauswahlmöglichkeiten oder Eingaben (z.B. ctrlDebug, ctrlSpecialReadings) sogenannte ''zusammengesetzte'' Attribute, deren Inhalt durch '''Schlüssel=Wert Paare''' gebildet wird und dadurch deutlich mehr Funktionen und Informationen transportieren als ein gewöhnliches Attribut.

Für zusammengesetzte Attribute besteht die zusätzliche Möglichkeit, gewünschte Änderungen der Schlüssel=Wert Paare selektiv vornehmen zu können, ohne das gesamte Attribut aufrufen und ändern zu müssen. Die Vorgang, der vor allem für programmtechnische Manipulationen gedacht ist, kann durch eine Set-Funktion ausgeführt werden:

set <Name> attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

Die Funktionen der Attribute werden durch einen Präfix geclustert und so inhaltlich, aber vor allem auch in der Attribute Drop-Down Liste, strukturiert dargestellt.

Die Bedeutung der '''Präfixe''' sind:

* '''ai''' - Steuerungsfunktionen für KI (z.B. aiControl)
* '''consumer''' - Registrierung und Einstellungen für Verbraucher (z.B. consumer02, consumerControl)
* '''ctrl''' - Steuerungsfunktion allgemeiner Art (z.B. ctrlDebug, ctrlSpecialReadings, ctrlUserExitFn)
* '''flowGraphic''' - Einstellungen für die Energieflußgrafik (z.B. flowGraphicControl)
* '''graphic''' - Einstellung für die Grafik allgemein (z.B. graphicSelect, graphicControl)
* '''graphicBeam''' - Einstellungen bestimmte Balkeneigenschaften in der Balkengrafik (z.B. graphicBeamHeightLevel1)
* '''plant''' - übergreifende Einstellungen betreffend der gesamten PV-Anlage bzw. des SolarForecast-Devices (z.B. plantControl)
* '''setup''' - Registrierung von Geräten in der Gesamtanlage und Einstellung deren Eigenschaften (Inverter, Zähler, Batterien usw.)

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

Mit den Attributen setupInverterDev01 bis setupInverterDevXX werden die vorhandenen Wechselrichter der Anlage registriert.
Das Modul unterscheidet verschiedene Wechselrichter-Typen, die sich durch ihre Arbeitsweise innerhalb der Anlage unterscheiden. Die Schlüssel=Wert Paare in den Attributen können mehrzeilig organisiert werden. Das erleichtert die Übersicht wenn viele dieser Parameter eingegeben werden.

;PV-Wechselrichter: Es ist der Standard Wechselrichter in einer PV-Anlage. An ihn sind die Solarzellen bzw. Strings angeschlossen. Die zugeordneten Strings können mit dem Schlüssel '''strings''' zugeordnet werden. Ohne diese Angabe werden diesem Gerät alle definierten Strings (siehe Attribut ''setupInverterStrings'') zugeordnet. Der Wechselrichter liefert seine Energie in das Hausnetz. Alternativ kann mit der Angabe '''feed=grid''' die Funktion des Wechselrichters geändert werden. Diese Angabe sagt aus, dass dieser Wechselrichter ausschließlich in das öffentliche Netz einspeist.

Hier ein Beispiel-Setup eines PV-Wechselrichters (SMA STP):

STP_5000 pvIn=string_1_pdc:kW pvOut=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100

;Solar-Ladegeräte: Solar-Ladegeräte sind DC-DC Wandler und liefern die Energie der angeschlossenen Solarzellen nicht in das Wechselstromnetz, sondern laden direkt eine Batterie bzw. versorgen einen Batteriewechselrichter auf der Gleichstromseite. Die Funktion als Solar-Ladegerät wird mit '''feed=bat''' aktiviert, die relevanten Strings können ebenfalls mit dem Schlüssel '''strings''' zugeordnet werden. Ein Beispiel eines Solar-Ladegerätes ist ein Victron SmartSolar MPPT.

Ein Beispiel für das Setup eines Solar-Ladegeräts (SmartSolar Charger MPPT):

MQTT2_cerboGX_c0619ab34e08_solarcharger_Common pv=Yield_Power_value:W etotal=Yield_System_value:kWh capacity=2080 strings=Schleppdach feed=bat synchron=0 limit=100

;Batterie-Wechselrichter: Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer Batterie (=Gleichstromquelle) und dem Wechselstrom-Hausnetz. Die Funktion als Batterie-Wechselrichter wird mit der Angabe '''strings=none''' aktiviert. Die Schlüssel ''etotal'' und ''pv'' können bei einem Batterie-Wechselrichter ohne zugeordnete Solarzellen nicht gesetzt werden. Ein Beispiel eines Batterie-Wechselrichter ist der Victron MultiPlus II.

Ein Setup-Beispiel für einen Batterie-Wechselrichter (Victron MultiPlus II):

<pre>
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
icon=inverter@darkorange:inverter@grey
asynchron=0
</pre>

Die Eigenschaften des Wechselrichters werden durch eine Reihe von <Schlüssel=Wert> Paaren festgelegt. Auf einige dieser Paramter soll hier eingegangen werden.

 
==== Ausgewählte Schlüssel=Wert Paare ====

 
* '''pvIn=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvIn'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell zugeführte PV-Leistung bereitstellt. Der Schlüssel ist optional und dient in erster Linie dazu den entsprechenden Input-Wert in der Flußgrafik anzuzeigen sofern man das Attribut flowGraphicControl->showGenerators=1 setzt. Dadurch ist auch der Eigenverbrauch des Inverters bzw. dessen Wandlungsverlust visuell abschätzbar.

* '''pvOut=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvOut'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell erzeugte Leistung als positiven Wert liefert. Für einen PV-Wechselrichter (DC->AC) oder Solar-Ladegerät (DC->DC) ist es die erzeugte PV-Leistung.

* '''ac2dc=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter vom Hausnetz in Richtung Batterie (AC->DC) wandelt.

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)
;graphicBeamHeightLevel1:Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene (hier Ebene 1)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===
Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und, wenn ein Event eines als 'asynchron' definierten Devices auftritt, gesammelt und daraus permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

=== Wie wird die Verbrauchsprognose erstellt? ===

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

==== Debugging der Verbrauchsprognose ====
Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

=== Wie kann eine fehlerhafte Verbrauchsprognose korrigiert werden? ===
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionHistory 07 21

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
PVH_SolarForecast_<name> - PV History
PVC_SolarForecast_<name> - PV Circular
PVCfg_SolarForecast_<name> - PV Anlagenkonfiguration
PVCsm_SolarForecast_<name> - Consumer Status
ScApi_SolarForecast_<name> - Strahlungswerte aus verwendeter API
StatApi_SolarForecast_<name> - Statusdaten der verwendeten API's
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - KI Input Daten = Raw Trainigsdaten
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten 3 Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "pvHistory" restored
2023.10.02 09:57:07.969 3: SolCast6 - cached data "pvCircular" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "consumerMaster" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "radiationApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "statusApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "weatherApiData" restored
2023.10.02 09:57:07.974 3: SolCast6 - cached data "aiTrainedData" restored
2023.10.02 09:57:07.976 3: SolCast6 - cached data "aiRawData" restored
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 5. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. starten von FHEM (die Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere zwei Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese beiden Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagement01 lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>]

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten darf. Die Angabe ist optional. (default: 20)

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit.

Alle Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Wert 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Wert 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten. Der Fokus der Steuerung mit diesem Reading ist es, die Speicherkapazität der Batterie optimal zur Verhinderung der Überschreitung von Einspeiselimits einzusetzen und dennoch einen maximal möglichen SoC am Tagesende zu erreichen. (siehe das beschriebene [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Berücksichtigung_einer_Wirkleistungsbegrenzung|Nutzungsbeispiel]])

;Battery_ChargeOptTargetPower_XX: Dieses Reading enthält einen Richtwert für die optimierte Ladeleistung für jede Batterie. Die Aufladung wird prognosegeführt über den gesamten Tag verteilt, wobei der Fokus auf eine kontinuierliche, aber möglichst niederige Ladeleistung gelegt wird. (siehe diesen [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|Abschnitt]])

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

 

===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und folgenden Tag korrigiert. Das bedeutet, dass der Minimum SoC z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Batterie wieder vollständig zu zuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) Victron MPII Verbund
my $actmcc = ReadingsNum ($vebus, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_01', 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Strom b. Battery_ChargeRequest
$load = 21;
}
else {
$load = $maxcspc;
}
}

## Batterie Einstellung MaxChargeCurrent
##########################################
if ($load != $actmcc) {
CommandSet (undef, "$vebus MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vebus set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''. Die erreichte Qualität der Steuerungslogik ist stark von der Prognosequaliät abhängig. Um die Steuerung resilienter zu gestalten, wird per default ein Sicherheitsaufschlag von 50% auf die prognostizierte benötigte Ladeenenergie auf Stundenbasis einkalkuliert. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== leistungsoptimierte Beladungssteuerung mit dem Fokus geringe Verlustleistung und Verschleiß ====

Das SF-Modul bietet ein weiteres Reading '''Battery_ChargeOptTargetPower_XX''' zur Batteriesteuerung an. Dieses Reading liefert eine kalkulierte optimale Ladeleistung in Watt.

Die Ladeleistung wird kontinuierlich neu kalkuliert und berücksichtigt dabei:

* die Prognose der PV-Erzeugung der nächsten Stunden und des (Rest-)Tages
* den prognostizierten Verbrauch auf Stunden- bzw. Tagesbasis
* eine eventuell mögliche Überschreitung des gesetzten Einspeiselimits (plantControl->feedinPowerLimit)
* die gesetzten Leistungsparameter der Batterie
* das Ziel, am Tagesende einen möglichst maximalen SoC der Batterie erreicht zu haben

Der Fokus der implementierten Logik liegt dabei auf einer kontinuierlichen Ladeleistung, die aber unter den oben genannten Gesichtspunkten möglichst (relativ) gering sein soll um den Batterieverschleiß und die Verlustleistung zu minimieren. Die im Reading angezeigte Ladeleistung kann mit geeigneten Mitteln direkt in die Leistungssteuerung der Batterie eingebracht werden. Natürlich kann die Leistung auch vorab in einen optimalen Ladestrom umgerechnet werden.

Da das Ergebnis der Kalkulation stark von den Prognosen abhängt, ist zur Erhöhung der Resilienz per Default ein Sicherheitszuschlag von 20% eingebaut. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

Ist kein PV-Überschuß (mehr) vorhanden oder das Ladeziel erreicht, erfolgt ein Rückfall der Ladeleistung im Reading auf den Wert angegeben im Attribut '''setupBatteryDevXX->pinreduced'''. Ist setupBatteryDevXX->pinreduced nicht gesetzt, erfolgt ein weiterer Rückfall auf den Attributwert '''setupBatteryDevXX->pinmax'''. Ist dieser Wert ebenfalls nicht gesetzt, erfolgt der Rückfall auf "Unendlich" (9223372036854775807).

Es ist demzufolge ratsam den optionalen Paramter '''setupBatteryDevXX->pinreduced''' zu setzen. Da dieser Wert im Reading gesetzt wird wenn ohnehin kein PV-Überschuß vorliegt und somit keine LAdung durch PV erfolgt, ist er gleichzeitig die Ladeleistung bei einer eventuellen Notladung aus dem Netz bei Unterschreitung von lowSoC. Dadurch wird sichergestellt, die Batterie mit nur wenig Leistung aus dem Grid zu laden falls es nötig sein sollte.

 
==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 
=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 
=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
== Konfigurationsbeispiele ==

=== Visualisierung solare Vorhersage und reale Erzeugung ===

Zu Beginn jedes neuen Tages gegen 00:00 Uhr werden durch das SolarForecast Device Events für die initiale PV Prognose des kommenden Tages erstellt.
Der Readingteil dieser Events heißt

AllPVforecastsToEvent

Die Uhrzeiten der Events sind so aufbereitet und können direkt geloggt werden um sie in einen SVG Plot zu integrieren.
Im SolarForecast Device ist dieses Reading nicht sichtbar, nur die Events werden erstellt.

Die meteorologischen Bedingungen verändern sich über den Tag permanent. Je nach gewählter Strahlungsdatenquelle (eine API oder DWD Device) erfolgt eine mehr oder weniger dynamische Anpassung der Prognose an die sich verändernde Umwelt.

Aktuelle Prognosedaten sowie die reale PV Erzeugung der vergangenen Stunde können über die Readings

LastHourPVforecast
LastHourPVreal

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.<syntaxhighlight lang="perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.
Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten einlesen kann. Der Code wird nur ausgeführt, wenn das Reading nextCycletime ein Event erzeugt.<syntaxhighlight lang="perl">
forecast_json:nextCycletime.* {

use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my $last_start_ts;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => "%Y-%m-%d %H:%M:%S",
time_zone => "Europe/Berlin",
);

# Alle NextHour-Daten durchsuchen (als Fallback zur Vermeidung einer Endlosschleife auf max. 100 Std. begrenzen)
while ($hour < 100) {
my $hour_str = sprintf("NextHour%02d", $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "starttime", "na");
my $pvfc = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "pvfc", "na");

# Schleife beenden, wenn keine Vorhersage-Werte mehr vorhanden sind
last if $start_str eq "na" or $pvfc eq "na";

my $start_ts = $parser->parse_datetime($start_str); # Zeitzone und Sommer/Winterzeit berücksichtigen
$last_start_ts = $start_ts->clone; # merken für spätere Prüfung

# Zeit in UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $start_ts->set_time_zone("UTC")->iso8601() . "Z",
end => $start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0 + $pvfc,
};

$hour++;
}

# Prüfen, ob der letzte Start-Wert 23 Uhr war -> zusätzliche Stunde anhängen, damit der Tag
# bei evcc als vollständig angezeigt wird (siehe https://github.com/evcc-io/evcc/issues/22979)
if (defined $last_start_ts && $last_start_ts->hour == 23) {

# Zeit in UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $last_start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
end => $last_start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0,
};
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
},
</syntaxhighlight>
[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]
Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):<syntaxhighlight>
define WEBapi FHEMWEB 8089
attr WEBapi csrfToken none
</syntaxhighlight>In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json','[]')} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
</syntaxhighlight>Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

=== Poolsteuerung inkl. Eigenverbrauchsoptimierung und zusätzlichem Verbraucher, um Einspeiselimit zu vermeiden + manuelle Steuerung durch Sonderprogramme ===
'''Vorhandene Hardware:'''

* Poolpumpe, die über mehrere Stufen verfügt. Hier werden zwei verwendet.
** Pump Low: Energiesparprogramm um den Pool umzuwälzen, auch wenn nicht genug PV Leistung zur Verfügung steht. -> ca. 250W
** Pump High: Normalbetrieb wenn genug PV Überschuss zur Verfügung steht. -> ca. 800W zusätzlich
* Poolheizung: Wärmepumpe -> ca. 1,5kW elektrisch
* Nachbars Pool: Pumpe + Salzanlage +pH-Regler -> ca. 650W

'''Anforderungen:'''

* Pool muss täglich mindestens 1x umgewälzt werden.
* Im Idealfall wird der Pool > 2x umgewälzt.
* Bei genügend Überschuss soll der Pool geheizt werden. Es soll nur Sonnenstrom für die Poolheizung verwendet werden.
* Um das Einspeiselimit zu vermeiden, soll auch geheizt werden, wenn der Pool schon warm genug ist. (>28,5 °C)
* Sollte trotzdem noch das Einspeiselimit erreicht werden, soll auch der Pool des Nachbarn versorgt werden.

'''Herausforderungen:'''

* Verbraucher dürfen nur in einer gewissen Reihenfolge geschaltet werden, auch wenn der Überschuss eine andere Reihenfolge ergeben würde.
* Pumpe mit mehreren Stufen muss als zwei Consumer abgebildet werden, um die Schaltlogik in SolarForecast abzubilden. Würde die Trennung außerhalb von Solarforecast realisiert, könnte Solarforecast den Verbraucher schlechter "lernen", denn dann wäre es ein Consumer mit ständig wechselndem Verbrauch.
* Pool des Nachbarn darf nicht laut der benötigten Leistung geschaltet werden, sondern in Abhängigkeit der Einspeisebegrenzung.

In diesem Solarforcast-Device sind 16 Verbraucher definiert. Im Weiteren werden jedoch nur die verwendeten betrachtet. Da diese Reglung mittlerweile recht komplex ist, werden auch viele Dinge, die nicht SolarForcast betreffen, aber trotzdem dazu gehören, gezeigt. Es trägt zum Verständnis bei und man kann sich hier sicher Ideen holen.

'''Ergebnis:'''

In den folgenden beiden Bildern sieht man das Regelverhalten recht gut.
[[Datei:Mustertag ohne Wolken.jpg|zentriert|mini|823x823px|Wolkenloser Tag]]
Hier erkennt man gut das Einschalten der jeweiligen Verbraucher (Pump Low, Pump High, Wärmepumpe und Nachbar Pool). Die Wärempumpe schaltet erst bei 5kW Überschuss ein, da der Pool eigentlich schon warm genug ist. Sie dient "nur" dazu, das EInspeiselimit zu verhindern.Auch das Auschalten ist wieder deutlich zu erkennen. Die Regleung folgt dem Überschuss recht gut. (Die Leistungsspitzen auf dem Plateau sind normale Großverbraucher im Haus.)
[[Datei:Wechselhaft.jpg|zentriert|mini|818x818px|Wechselhafter Tag.]]
In diesem Bild sieht man das "verzweifelte" Regeln um das wechselhafte Wetter auszugleichen. Hier gibt es keine korrekte Reaktion und es wird durch die Sperrzeiten und andere Delays versucht, ein zu häufiges hin- und herschalten möglichst zu vermeiden. In Summe aber auch bei so einem Wetter ein akzeptables Verhalten.

'''Definition der Consumer:'''

'''Allgemeine Erklärungen zu den Definitionen:'''

'''asynchron=0''': Da hier die Werte des Überschusses für das Timing der Schaltvorgänge verwendet werden, darf hier keine Eventsteuerung verwendet werden. Sonst kann man nicht mehr sagen, über welchen Zeitraum der Mittelwert oder der Median gebildet wurde. Dafür wurde die Zykluszeit des SolarForecast-Device auf 60 Sekunden geändert, um die Überlegungen zu vereinfachen. Bei Event-Steuerung könnte man nicht sagen ob die letzten 10 Events in den letzten 5 Sekunden oder in den letzten 10 Minuten aufgetreten sind.

'''power=xxx''': Wurde teilweise etwas höher als der tatsächliche Wert gewählt, um nach dem Einschalten sicherzustellen, dass nicht sofort der gesamte Überschuss "verbraucht" wird und somit gleich wieder abgeschaltet wird.

'''auto=xxx''': Jeder Verbraucher benötigt sein eigenes auto-Reading, da die Automatik für die Regelung in verschiedenen Stufen ein- und ausgeschaltet werden muss.

'''dum_valve''': Dummy-Device in dem die Zustände der Regelung abgebildet werden. Notifys lesen bzw. befüllen diesen Dummy und steuern dann die Hardware bzw. wird der Dummy durch Werte aus der Hardware passend befüllt.

'''surpmeth=median_xx:''' Durch das asynchron=0 in allen Consumern und beim Generator wird von Solarforcast genau alle 60 Sekunden ein Zyklus ausgeführt. Das führt dazu, dass der Median genau über xx Minuten gebildet wird.

'''locktime=xx:xx''': Sicherheitsvorkehrung, dass nicht zu oft geschaltet werden kann. Schont die Hardware und verhindert ein Schwingen. Abhänging vom geschalteten Gerät. z.B. soll die Wärmepumpe möglichst wenig takten, um die Lebensdauer zu verlängern.

Es gibt dann auch noch einige weitere Sicherheitsvorkehrungen, um diese Regelung möglichst stabil und hardwareschonend zu gestalten. Die Schwierigkeit sind nicht die Bilderbuchtage mit einem glatten Verlauf der PV-Leistung, sondern Tage mit ständig wechselndem Überschuss in der Nähe der Schaltgrenzen.

'''swoncond= dum_valve:sf_true:{main::xxx_On}:''' Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann einzuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''swoffcond= dum_valve:sf_true:{main::xxx_Off}''': Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann auszuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''Pump Low: (consumer01)'''<syntaxhighlight lang="perl">
dum_valve:Pool+Low
aliasshort=Low
asynchron=0
auto=pump_low_auto
icon=scene_pool
interruptable=0
mintime=SunPath:0:180
mode=must
noshow=0
notafter=08:00
off="pump_low off"
on="pump_low on"
pcurr=pump_low_power
power=250
surpmeth=median_13
switchdev=dum_valve
swoffcond=dum_valve:sf_true:{main::Check_Pump_Low_Off}
swoncond=dum_valve:sf_true:{main::Check_Pump_Low_On}
swstate=pump_low:on:off
type=other
</syntaxhighlight>Erläuterungen:

* Die Pumpe soll ab Sonnenaufgang, bis 180 Minuten nach Sonnenuntergang (mintime=SunPath:0:180), bei mindestens 250W Überschuss (power=250) gestartet werden.
* Die Pumpe muss spätestens um 8:00 eingeplant werden (notafter=08:00), um das Umwälzen auch bei Schlechtwetter zu garantieren.
* Die Pumpe muss gestartet werden (mode=must) sobald sie eingeplant ist.
* swoncond sorgt dafür, dass sie vor 8:00 nur bei genügend Überschuss gestartet wird, oder es 8:00 ist. swondcond ist mit der eigentlichen Einschaltbedingung (eingeplant und mode=must) UND verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* Überschuss wird auch in swoncond mit der gewählten Methode geprüft.
* Die Pumpe darf, wenn sie gestartet wurde, auch bei fehlendem Überschuss nicht mehr unterbrochen werden. (interruptable=0)
* Die Pumpe wird am Ende der Einplanung ausgeschaltet oder wenn swoffcond erfüllt ist. swoffcond wird true, wenn eine gewisse Wassermenge umgewälzt wurde oder die Sicherheitsbedingungen nicht (mehr) erfüllt sind. swoffcond ist mit der eigentlichen Ausschaltbedingung (Planung endet) ODER verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* {'''main::'''xxx} dient dazu, um die Funktion xxx in der 99_mySolarForecastUtils.pm aus Solarforecast erreichbar zu machen.
* dum_valve:sf_true ist ein Reading, das fix 1 ist und als Vergleichswert für den in Klammern folgenden Perlcode dient. Wenn dieses Reading und der Perlcode gleich sind (1==1), ist die swoncond bzw swoffcond erfüllt.

'''Pump High: (consumer03)'''<syntaxhighlight lang="perl">
dum_valve:Pool+High
aliasshort=High
type=other power=1000 asynchron=0
auto=pump_high_auto
icon=scene_pool
pcurr=pump_high_power
switchdev=dum_valve
swstate=pump_high:on:off
mode=can
mintime=SunPath
on="pump_high on"
off="pump_high off"
surpmeth=median_5
noshow=0
locktime=180:300
interruptable=1
swoncond=dum_valve:sf_true:{main::Check_Pump_High_On}
swoffcond=dum_valve:sf_true:{main::Check_Pump_High_Off}
</syntaxhighlight>Erläuterungen:

* Pump HIgh ist die selbe Pumpe, aber eine höhere Durchflussmenge
* Der Mehrverbrauch beträgt eigentlich 800W wird hier aber mit 1000W angegeben, um eine Hysterese von ca. 200W zu erreichen und damit ein schnelles Abschalten nach dem Einschalten zu verhindern.
* Diese Stufe wird nur bei genügend Überschuss aktiviert. (mode=can)
* Diese Stufe wird bei fehlendem Überschuss unterbrochen. (interruptable=1)
* Diese Stufe wird nur während Sonnenschein eingeplant. (mintime=SunPath)
* locktime sorgt dafür, dass bei schnell wechselnden Bedingungen, nicht ständig umgeschaltet wird. -> Schonung der Pumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Heatpump: (consumer05)'''<syntaxhighlight lang="perl">
Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800 asynchron=0
icon=sani_heating_heatpump
auto=heatpump_auto
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
etotal=Pool_Pin32_monotonic_count_EnergyMeter:kWh
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=1
swoffcond=dum_valve:sf_true:{main::CheckWPOff}
</syntaxhighlight>Erläuterungen:

* Der Verbrauch ist hier wieder etwas zu hoch angegeben (1800W statt realen 1500W), um eine Hysterese zu erreichen.
* Da es sich hier um eine Wärmepumpe handelt, die nicht getaktet werden sollte, ist die locktime in beide Schaltrichtungen mit 10 Minuten relativ hoch.
* Die Ermittlung des Medians ist mit 13 Minuten recht lang, um den Überschuss über lange Zeit zu glätten, damit möglichst selten geschaltet wird. Diese 13 Minuten in Kombination mit der Locktime und der Hysterese führten bei dieser Anlage bisher dazu, dass höchstens 5 Zyklen am Tag geschaltet wurden. -> Hier kann das individuelle Schaltverhalten optimiert werden. Besseres Verfolgen des Überschusses vs. weniger Taktungen der Wärmepumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Nachbars Pool: (consumer07)'''<syntaxhighlight lang="perl">
Shelly_Plug_S_1:Kurz+Pool
aliasshort=Kurz
type=other power=650 asynchron=0
icon=scene_pool
auto=pool_kurz_auto
pcurr=power:W
switchdev=dum_valve
swstate=pool_kurz:on:off
mode=can
mintime=SunPath
on="pool_kurz on"
off="pool_kurz off"
surpmeth=median_13
noshow=0
interruptable=1
locktime=600:300
swoncond=dum_valve:sf_true:{main::Check_Pool_Kurz_On}
swoffcond=dum_valve:sf_true:{main::Check_Pool_Kurz_Off}
</syntaxhighlight>Erläuterungen:

* Dieser Consumer dient als Einspeisebegrenzungsschutz und wird aktiviert, sobald sich der Überschuss der Einspeisegrenze nähert. -> siehe '''99_mySolarForecastUtils.pm'''
* Verbraucher kann recht träge geschaltet werden. (surpmeth=median_13 und locktime=600:300)
* Consumer wird ausgeschaltet wenn ein gewisser Überschuss unterschritten wird und somit die Einspeisegrenze wieder weit genug weg ist. -> siehe '''99_mySolarForecastUtils.pm'''
'''99_mySolarForecastUtils.pm'''

Hier sind die Funktionen, die für diese Regelung verwendet werden, der Übersichtlichkeit halber in einzelnen Blöcken mit Erklärungen dargestellt.<syntaxhighlight lang="perl">
package main;
use strict;
use warnings;

my $pool_dummy = 'dum_valve';
my $pool_temperature = 'Pool_Temp';
my $flow_sensor = 'Pool_Pin_A0';
my $water_counter_l1 = 'pump_l1_hc';
my $water_counter_l2 = 'pump_l2_hc';
my $target_temp = 28.4; # maximum temperature for heating, without infeed limit

my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;

my $switch_delay = 160; # just under three minutes

sub
SolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

</syntaxhighlight>

* Hier werden die IDs der Geräte definiert, um über sprechende Namen darauf zugreifen zu können.
* Einige Devices und Parameter, die immer wieder gebraucht werden sind hier angegeben.
* sprintf wird verwendet um sicherzustellen, dass die IDs zweistellig sind. z.B. 3 -> 03

'''Pump Low'''<syntaxhighlight lang="perl">
###################
### Pumpe - LOW ###
###################

sub
Check_Pump_Low_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'surpmethResult','');
my $nom_power = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'power','');
my ($min, $hour) = (localtime())[1,2];
my $timer = 0;
if($hour > 8 || ($hour == 8 && $min >= 0)){$timer=1;}

if(ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ($surplus > $nom_power
|| $timer
)
)
{
return 1;}
else
{
return 0;}
}

sub
Check_Pump_Low_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount > $desired_amount_l1)
&& (ReadingsVal($pool_dummy,"pump_high","on") eq "off" && ReadingsAge($pool_dummy,"pump_high",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{
return 1;
}else{
return 0;
}
}

</syntaxhighlight>Einschalten:

* Es wird der errechnete Wert für den Überschuss von SolarForecast verwendet und auch der benötigte Überschuss aus dem Consumer ausgelesen.
* Das Einschalten wird erst durch erfolgreiche Prüfung der Hardwarevoraussetzungen erlaubt. -> Das Motorventil steht richtig und es ist kein Sonderbetrieb (Reinigung, Massage, Winter, o.ä.) aktiv.
* Es muss entweder genügend Überschuss vorhanden sein oder es ist 8:00.

Ausschalten:

* Wenn der Badebetrieb aktiv ist (bath_mode==1, [bei Außentemperatur > 24°C]) wird nach 90m³ Gesamtumwälzung ausgeschaltet.
* Wenn der Badebetrieb nicht aktiv ist (bath_mode==0, [bei Außentemperatur < 20°C]) wird bereits nach 42m³ Gesamtumwälzung ausgeschaltet.
* Prüfung, ob Pump High schon aus ist. Sollte durch die Logik gar nicht möglich sein, aber es könnte manuell oder durch einen (Logik-)Fehler trotzdem eingeschaltet sein.
* Prüfung, ob alle Hardware-Funktionen in einem für die Automatik geeigneten Zustand sind.
* Es wird auch geprüft, ob Pump High seit mindestens 3 Minuten aus ist, um zu verhindern, dass wegen fehlendem Überschuss gleich mehrere Geräte ausgeschaltet werden.
* Da die Zykluszeit 60 Sekunden ist, führen die 160 Sekunden dazu, dass nach drei Minuten(180 Sekunden) ein definierter Wert gilt. Mit 180 Sekunden könnte es manchaml eine Minute mehr sein.

'''Pump High'''<syntaxhighlight lang="perl">
####################
### Pumpe - HIGH ###
####################

sub
Check_Pump_High_On{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount < $desired_amount_l2)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_low","off") eq "on" && ReadingsAge($pool_dummy,"pump_low",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

sub
Check_Pump_High_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;

if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}
if(($amount > $desired_amount_l2)
&& (ReadingsVal($pool_dummy,"heatpump","on") eq "off" && ReadingsAge($pool_dummy,"heatpump",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs noch nicht erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob Pump Low schon seit mindestens 3 Minuten aktiv ist. (sollte eigentlich immer der Fall sein, wenn die Automatik für Pump High aktiv ist)

Ausschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs bereits erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob die Wärmepumpe schon seit mindestens 3 Minuten aus ist. Ermöglicht drei Minuten lang, den Median für den Überschuss zu aktualisieren.

'''Wärmepumpe'''<syntaxhighlight lang="perl">
##################
### Wärempumpe ###
##################
sub
CheckWPOn(){
my $name = 'energy_mgmt';
my $surplus_on = 5000; # minimum surplus to avoid infeed limit with heatpump
my $surplus_restart = 3000; # minimum surplus to re-enable heatpump, when avoidung infeed limit and a big consumer turned the hp off

my $planstate = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'planstate','');
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if ($planstate =~ /^([^:]+)/) {
$planstate = $1;
}

if(ReadingsVal($flow_sensor,"reading","off") eq "on"
&& (ReadingsVal($pool_dummy,"special_function","") eq "none"
|| ReadingsVal($pool_dummy,"special_function","") eq "party"
)
&& ReadingsVal($pool_dummy,'heat_protection','on') eq "off"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_high","off") eq "on" && ReadingsAge($pool_dummy,"pump_high",0) > $switch_delay)
&& (ReadingsVal($pool_temperature,"temperature",30) < $target_temp
|| (ReadingsVal($pool_temperature,"temperature",15) >= $target_temp
&& ( $surplus > $surplus_on
|| (($planstate eq "replanned") && ($surplus > $surplus_restart))
)
)
)
)
{return 1}
else
{return 0}
}

sub
CheckWPOff{
my $name = 'energy_mgmt';
my $surplus_off = 1000; #minimum surplus to keep heatpump on, when avoiding infeed limit

my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if((ReadingsVal($flow_sensor,"reading","on") eq "off"
|| !((ReadingsVal($pool_dummy,"special_function","") eq "none")
|| (ReadingsVal($pool_dummy,"special_function","") eq "party")
)
|| ReadingsVal($pool_dummy,'heat_protection','off') eq "on"
|| ReadingsVal($pool_dummy,"valve_position","") ne "normal"
|| ((ReadingsVal($pool_temperature,"temperature",15) > $target_temp)
&& ($surplus < $surplus_off)
)
)
&& (ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob Flussensor ein. (Pool_pin_A0) -> Wasser fließt durch die Wärmepumpe.
* Prüfung, ob Pool in Normal- oder Partybetrieb ist und das Ventil in Normalposition ist. In beiden Fällen läuft Pump High.
* Einschalten wenn genug Überschuss da ist und die Temperatur <28.4°C ist oder wenn über 5000W Überschuss (Einspeisebegrenzung bei 5900W) da ist, egal wie warm der Pool ist.
* Sonderfall: Wenn die Wärmepumpe durch einen/mehrere Großverbrucher "kurz" ausgeschaltet wurde (swoffcond) wird sie ausgeplant. Ein Notify plant sie wieder ein. Wenn das passiert, soll die Wärmepumpe aber wieder bei 3000W Überschuss gestartet werden, um die Energie noch weiter zu nutzen bis der Überschuss unter 1000W fällt. (Hysterese von 500W, da die WP nur 1500W braucht)

Ausschalten:

* Ausschalten sobald hardwaremäßig irgendetwas faul ist. (Betriebsart, Ventilstellung, Durchfluss)
* Ausschalten wenn kein Überschuss. (interruptable=1)
* Wenn Wassertemperatur über 28,5°C und der Überschuss kleiner als 1000W ist.
* Nur schalten, wenn Wärmepumpe läuft und seit mindestens 3 Minuten läuft (Sicherheit). Das verhindert das erneute Triggern des Notifys, wenn die Pumpe schon aus ist. Sollte nicht passieren, aber sicher ist sicher.

'''Nachbar Pool'''<syntaxhighlight lang="perl">
###################
### Pool - KURZ ###
###################
sub
Check_Pool_Kurz_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus > 3000)
&& ((ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) >160) || ReadingsVal($pool_dummy,'heat_protection','off') eq 'on' ))
{return 1}
else
{return 0}
}

sub
Check_Pool_Kurz_Off{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus < 1000 )
&& (ReadingsVal($pool_dummy,"pool_kurz","off") eq "on" && ReadingsAge($pool_dummy,"pool_kurz",0) >160))
{return 1}
else
{return 0}
}
</syntaxhighlight>Einschalten:

* Überschuss ist nahe der Einspeisegrenze (5900W) und Wärmepumpe läuft seit mindestens 3 Minuten. Es wird schon bei 3000W eingeschaltet, um dem Nachbarn etwas Gutes zu tun ;-)

Ausschalten:

* Überschuss ist unter 1000W. -> Um noch Reserven für den eigenen Verbrauch zu haben.

'''Hilfsfunktionen'''

'''ctrlUserExitFn'''

Hier erfolgt nach jedem Zyklus die Festlegung der verschiedenen Automatikmodi.<syntaxhighlight lang="perl">
#############################################################
##################### Exit Function #########################
#############################################################
sub
SF_UserExitFn{
my $ctrl_dummy = "dum_valve";
my $pump_low_delay = 220;
my $pump_high_delay = 160;
my $heatpump_delay = 290;
my $pool_kurz_delay = 160;
my $automatic = ReadingsNum($ctrl_dummy,"sf_automatic",1);

if($automatic){

my $pump_low_state = ReadingsVal($ctrl_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe

my $pump_high_state = ReadingsVal($ctrl_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe

my $heatpump_state = ReadingsVal($ctrl_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
my $pool_heat_protection = ReadingsVal($ctrl_dummy,'heat_protection','on');

my $pool_kurz_state = ReadingsVal($ctrl_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools

############################
# Überhitzungsschutz aktiv #
############################

if($pool_heat_protection eq 'on'){
if($heatpump_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 0");
}
if($heatpump_state eq "on"){
fhem("set $ctrl_dummy heatpump off")
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_low_delay && $pump_high_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pump_high_delay && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pump_high_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $pool_kurz_delay && $pool_kurz_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pump_high_delay && $pump_high_auto == 1 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
##################################
# Überhitzungsschutz nicht aktiv #
##################################
}else{
if($heatpump_auto == 0 && $heatpump_state eq "off"){
if($pool_kurz_state eq "on"){
fhem("set $ctrl_dummy pool_kurz off");
}
if($pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_low_delay && $pump_high_auto == 0 && $heatpump_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pump_high_delay && $heatpump_auto == 0 && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "on" && ReadingsAge($ctrl_dummy,'heatpump',0) > $heatpump_delay && $pool_kurz_auto == 0 && $pump_high_auto == 1 && $heatpump_auto == 1){
fhem("set $ctrl_dummy pump_high_auto 0");
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $heatpump_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $pool_kurz_delay && $pool_kurz_auto == 1 && $heatpump_auto == 0 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "off" && ReadingsAge($ctrl_dummy,'heatpump',0) > $heatpump_delay && $heatpump_auto == 1 && $pump_high_auto == 0 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pump_high_delay && $pump_high_auto == 1 && $heatpump_auto == 1 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
}

}
}
</syntaxhighlight>
'''Erläuterungen:'''

* '''Überhitzungsschutz:'''
** Da durch die Wärmepumpe Überschuss "verheizt" wird, der durch das Einspeiselimit gar nicht produziert würde, kann es vorkommen, dass der Pool unangenehm warm wird.
** Um das zu vermeiden gibt es ein Reading, welches gesetzt wird, wenn der Pool eine gewisse Temperatur überschreitet. Dieses Setzen und Zurücksetzen erfolgt mit einer Hysterese von 0.2°C, um ein Takten der Wärmepumpe zu verhindern. Diese 0.4°C sind bei dieser Wassermenge einige Stunden.
** Wenn der Überhitzungsschutz aktiv ist, wird die Wärmepumpe in der Kette übersprungen.
** Wenn sich der Hitzeschutz während des Betriebs ändert, wird die Wärmepumpe bzw. der Pool vom Nachbarn passend ausgeschaltet und die Modi entsprechend gesetzt.
* '''On-chain:'''
** Wenn am Morgen Pump Low seit $pump_low_delay aktiv ist und alle folgenden Consumer noch nicht, dann wird die nächste Stufe freigegeben. -> Pump High
** Wenn Pump High seit $pump_high_delay aktiv ist und alle folgenden Consumer noch nicht, wird die Wärmepumpe freigegeben. -> Heatpump
** Wenn die Wärmepumpe seit $heatpump_delay aktiv ist und der letzte Consumer noch nicht, wird der letzte Verbraucher freigegeben. -> Pool Kurz Gleichzeitig wird die Automatik für Pump High ausgeschaltet, da dieser Verbraucher erst unterbrochen werden darf wenn die Wärmepumpe aus ist!
** Wenn der letzte Verbraucher aktiviert ist, wird die Automatik der Wärmepumpe deaktiviert, da ja zuerst der letzte Verbraucher (Pool Kurz) wieder ausgeschaltet werden muss, bevor der vorletzte (Wärmepumpe) wieder ausgeschaltet werden darf. Da es keinen nachfolgenden Verbraucher mehr gibt, kann hier auf ein delay verzichtet werden, da es nicht passieren kann, dass zwei Verbraucher wegen sehr hohem Überschuss unmittelbar hintereinander geschaltet werden können.
[[Datei:Poolsteuerung mit unterschiedlichen Automatikmodi.jpg|alternativtext=Poolsteuerung|mini|Consumer der Poolsteuerung|500x500px]]
'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von fehlendem Überschuss jederzeit unterbrochen werden kann und der "folgende" Consumer, der auf das Einschalten wartet. Pump Low ist immer im Automatikmodus, da diese nie unterbrochen wird. (mode=must, interruptable=0)

* '''Off-chain:'''
** Wenn der letzte Verbraucher seit mindestens der delay-Zeit aufgrund von fehlendem Überschuss inaktiv war, im Automatikmodus ist und der vorherige Verbraucher nicht im Automatikmodus ist, wird der vorherige Verbraucher in den Automatikmodus geschaltet und wartet jetzt auch auf das Ausschalten. Wenn der Überschuss steigt, springt man wieder in die on-chain und der letzte Verbraucher wird eingeschaltet und die Automatik des vorletzten Verbrauchers deaktiviert.
** Wenn die Wärmepumpe seit mindestens der delay-Zeit aus ist, sich im Automatikmodus befind und Pump High noch nicht im Automatikmodus ist, wird die Automatik für den Nachbarpool ausgeschaltet, da er ja jetzt nicht mehr einschalten darf, da zuerst die Wärmepumpe ein sein müsste. Die Automatik von Pump High wird wieder aktiviert, da diese jetzt auf das Ausschalten wartet. Steigt der Überschuss wieder, wird in den entsprechenden On-chain Zweig gesprungen.
** Wenn Pump High mindestens die delay-Zeit aus ist, wird die Automatik der Wärmepumpe deaktiviert, da diese ja erst einschalten darf, wenn Pump High wieder läuft. Steigender Überschuss führt wieder zum aktivieren von Pump High und zum Sprung in den entsprechenden On-chain Zweig.
** Wenn Pump Low ausgeschaltet wird, wird sofort die Automatik für Pump High ausgeschaltet, da durch das spätere Ausschalten von (der evtl. wieder eingeschalteten) Pump High, hardwaremäßig wieder Pump Low aktiviert wird, aber durch SolarForecast nie ausgeschaltet wird, da Pump Low vor ein paar Minuten ja schon logisch ausgeschaltet wurde.

'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von neuem Überschuss jederzeit wieder gestartet werden kann und der "vorherige" Consumer, der auf das Ausschalten wartet.

'''Hilfs-Notifys für die Automatik'''

Da durch das Verwenden von swoffcond die Verbraucher beim Ausschalten auch ausgeplant werden, aber eigentlich "nur" unterbrochen werden sollen, müssen sie wieder neu eingeplant werden. Dazu sind notifys nötig. Wichtig: IDs müssen zweistellig angegeben werden!

Wärmepumpe:<syntaxhighlight lang="perl">
dum_valve:heatpump:.off sleep 10; set energy_mgmt consumerNewPlanning 05
</syntaxhighlight>
Nachbar Pool:<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.off sleep 10; set energy_mgmt consumerNewPlanning 07
</syntaxhighlight>

'''Eine Pumpe mit einem Energiezähler als zwei Consumer verwenden'''

Die verwendete Pumpe hat vier Betriebsarten mit unterschiedlichen Leistungen. Da sie als zwei Consumer abgebildet wird, führt das dazu, dass die Leistung fälschlicherweise von SolarForecast auch zweimal gezählt wird. Die Lösung sind Dummy-Readings, welche die Leistungsdaten passend auseinander rechnen.<syntaxhighlight lang="perl">
Pool_Strom_Pumpe:Pool_Pin31_monotonic_count_PowerCurrent:.* {
my $power = $EVTPART1;
my $pump_low = ReadingsVal('dum_valve','pump_low','off');
my $pump_high = ReadingsVal('dum_valve','pump_high','off');
my $power_low_sim = 250;

if($pump_low eq "on" && $pump_high eq "on"){
my $power_low = $power_low_sim; #fiktiver Verbrauch der niedrigen Stufe
my $power_high = $power - $power_low_sim;
fhem("set dum_valve pump_low_power $power_low");
fhem("set dum_valve pump_high_power $power_high");
}
elsif($pump_low eq "on" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power $power");
fhem("set dum_valve pump_high_power 0");
}
elsif($pump_low eq "off" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power 0");
}elsif($pump_low eq "off" && $pump_high eq "on"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power $power");
}
}
</syntaxhighlight>
Erläuterungen:

* Es sind alle vier Möglichkeiten der zwei Pumpenlevel abgebildet.
* Wenn die Automatik deaktiviert ist und die Level 1-4 von extern geschaltet werden, zählen sie dadurch korrekterweise nicht zu diesen beiden Consumern.

'''Notifys für das hardwaremäßige Schalten der Consumer'''

Es werden einige Notifys verwendet, die die Umsetzung vom Dummy-Device auf die Hardware erledigen, da ein logisches Ein teilweise hardwaremäßig einige Dinge erfordert.

Notify für Pump Low:<syntaxhighlight lang="perl">
dum_valve:pump_low:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 60; set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin14 off; sleep 5; set Pool_Pin12 off; sleep 15; set Pool_Pin25 off");
}else{
Log3 ("Pool", 4, qq{Notify Level1 - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterungen:

* Beim Einschalten ist es nötig für eine Minute Pump High zu aktivieren, um Luft aus der Elektrolysezelle zu spülen, bevor Pump Low aktiv sein darf. (Pin26 und Pin25 sind die Steuerpins auf der Interfacekarte der Pumpe für die beiden Level.)
* Beim Ausschalten werden zuerst die Salzanlage (Pin14) und die pH-Anlage (Pin12) deaktiviert, damit noch 15 Sekunden lang die Elektrolysezelle mit frischem Wasser gespült wird, um das verbleibende Chlor auszuspülen. Hier wird zusätzlich nochmal die Automatik für Pump High deaktiviert. (Um das finale Ausschalten zu sichern.)

Notify für Pump High:<syntaxhighlight lang="perl">
dum_valve:pump_high:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 1; set Pool_Pin25 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}else{
Log3 ("Pool", 4, qq{Notify Level 2- parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Da die Interfacekarte immer auf den höchsten Level reagiert, wird beim Umschalten zuerst Pump High aktiviert und nach einer Sekunde Pump Low deaktiviert, um ein "stufenloses" (ohne Ausschalten) Umschalten zu ermöglichen. Beim Ausschalten genauso.

Notify für die Wärmepumpe:<syntaxhighlight lang="perl">
dum_valve:heatpump:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin6 on");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin6 off");
}else{
Log3 ("Pool", 4, qq{Notify heatpump - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Hier reicht ein dirketes Übernehmen aus dem Dummy.

Notify für den Nachbar-Pool:<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.* {
if($EVTPART1 eq "on" && ReadingsVal("Shelly_Plug_S_1","state","on") eq "off"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 on\")}}; sleep 5; set PwSw_Schalter on");
}elsif($EVTPART1 eq "off" && ReadingsVal("Shelly_Plug_S_1","state","off") eq "on"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 off\")}}; sleep 5; set PwSw_Schalter on");
}else{
Log3 ("Pool", 4, qq{Notify Pool Kurz - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung

* Da hier eine Pumpe durch einen 3-poligen Umschalter zwischen zwei Hausanspeisungen umgeschaltet wird, ist es wichtig, dass die Pumpe dazwischen '''gesichert''' zum Stehen gebracht wird! Sonst führt die rotierende Pumpe als Generator zu einem gewaltigen Kurzschluss mit der "fremden" Phase. War nicht schön ...

'''Sonderprogramme für den Poolbetrieb'''

Hier ist das Aus- und Einschalten der Solarforcast-Automatik zu sehen. Es werden alle Stati gespeichert. Danach kann von beliebigen "Sonderfunktionen" (Reinigung des Filters, Massagefunktion, usw.) auf die Hardware zugegriffen werden. Wenn wieder in den Automatikmodus zurückgewechselt wird, wird hardwaremäßig wieder der Zustand der Automatik von vorher hergestellt, die Stati wieder zurück geschrieben und die Automatik wieder aktiviert.<syntaxhighlight lang="perl">
##############################################
# Status speichern und Automatik ausschalten #
##############################################
sub PoolAutoOff{
my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;
my $sf = 'energy_mgmt';

# my $pump_low_state = ReadingsVal($valve_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe
# my $pump_high_state = ReadingsVal($valve_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe
# my $heatpump_state = ReadingsVal($valve_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($sf, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
# my $pool_kurz_state = ReadingsVal($valve_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools
fhem("set $valve_dummy pump_low_auto 0");
fhem("set $valve_dummy pump_high_auto 0");
fhem("set $valve_dummy heatpump_auto 0");
fhem("set $valve_dummy pool_kurz_auto 0");
fhem("setreading $valve_dummy sf_automatic 0");
fhem("setreading $valve_dummy last_auto_pump_low $pump_low_auto");
fhem("setreading $valve_dummy last_auto_pump_high $pump_high_auto");
fhem("setreading $valve_dummy last_auto_heatpump $heatpump_auto");
fhem("setreading $valve_dummy last_auto_pool_kurz $pool_kurz_auto");

my $last_pump_level_1 = ReadingsVal($valve_dummy,"pump_low","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"pump_high","off");
my $last_pump_level_3 = ReadingsVal($pump_level_3,"value","off");
my $last_pump_level_4 = ReadingsVal($pump_level_4,"value","off");
my $last_heatpump = ReadingsVal($valve_dummy,"heatpump","off");
fhem("setreading $valve_dummy last_pump_level_1 $last_pump_level_1");
fhem("setreading $valve_dummy last_pump_level_2 $last_pump_level_2");
fhem("setreading $valve_dummy last_pump_level_3 $last_pump_level_3");
fhem("setreading $valve_dummy last_pump_level_4 $last_pump_level_4");
fhem("setreading $valve_dummy last_heatpump $last_heatpump");
}

##########################################
# Status laden und Automatik einschalten #
##########################################
sub PoolAutoOn{
my $last_pump_level_4 = ReadingsVal($valve_dummy,"last_pump_level_4","off");
my $last_pump_level_3 = ReadingsVal($valve_dummy,"last_pump_level_3","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"last_pump_level_2","off");
my $last_pump_level_1 = ReadingsVal($valve_dummy,"last_pump_level_1","off");
my $last_heatpump = ReadingsVal($valve_dummy,"last_heatpump","off");
fhem("set $pump_level_4 $last_pump_level_4");
fhem("set $pump_level_3 $last_pump_level_3");
fhem("set $pump_level_2 $last_pump_level_2");
if($last_pump_level_1 eq "on" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_2 on; sleep 1; set $pump_level_1 $last_pump_level_1; sleep 28; set $pump_level_2 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "on" && $last_pump_level_2 eq "on" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "off" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}
fhem("sleep 10; set $heatpump $last_heatpump");
fhem("setreading $valve_dummy last_pump_level_1 none");
fhem("setreading $valve_dummy last_pump_level_2 none");
fhem("setreading $valve_dummy last_pump_level_3 none");
fhem("setreading $valve_dummy last_pump_level_4 none");
fhem("setreading $valve_dummy last_heatpump none");
fhem("setreading $valve_dummy valve_position normal");
my $last_auto_pump_low = ReadingsVal($valve_dummy,"last_auto_pump_low",0);
my $last_auto_pump_high = ReadingsVal($valve_dummy,"last_auto_pump_high",0);
my $last_auto_heatpump = ReadingsVal($valve_dummy,"last_auto_heatpump",0);
my $last_auto_pool_kurz = ReadingsVal($valve_dummy,"last_auto_pool_kurz",0);
fhem("set $valve_dummy pump_low_auto $last_auto_pump_low");
fhem("set $valve_dummy pump_high_auto $last_auto_pump_high");
fhem("set $valve_dummy heatpump_auto $last_auto_heatpump");
fhem("set $valve_dummy pool_kurz_auto $last_auto_pool_kurz");
fhem("setreading $valve_dummy last_auto_pump_low none");
fhem("setreading $valve_dummy last_auto_pump_high none");
fhem("setreading $valve_dummy last_auto_heatpump none");
fhem("setreading $valve_dummy last_auto_pool_kurz none");
}
</syntaxhighlight>Erläuterungen:

* pump_level_1 ist Pump Low, pump_level_2 ist Pump High, pump_level_3 und pump_level_4 sind Sonderfunktionen (Filterreinigung, Massage)
* Beim Wiedereinschalten von Pump Low ist es wieder nötig kurz Pump High zu aktivieren, um Luft auszuspülen.
* Es wird der Zustand von Solarforecast gespeichert und danach auf die Hardware geschrieben. -> Stellt sicher, dass nach dem Einschalten der Automatik der logical switchstate zum physical switchstate passt.

== Tips & Tricks ==
* Interruptable verhält sich völlig anders, wenn der Perlcode 1 oder 0 liefert, als wenn man 1 oder 0 in der Config hinterlegt. -> siehe commandref
* Rückgabewert bei swoncond und swoffcond wird mit dem Readingswert verglichen und nicht dirket verwendet. Bsp. wenn das Reading 100 enthält muss auch der Rückgabewert des Perlcodes 100 liefern, um true zu ergeben.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2025-08-05T06:23:25Z

All-Ex: /* PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) */

{{Baustelle}}
{{Hinweis|Die vorliegende Wiki-Seite befindet sich im Aufbau.}}
{{Infobox Modul
|ModPurpose=Solarprognose und Verbrauchersteuerung
|ModType=d
|ModCmdRef=76_SolarForecast
|ModFTopic=117864
|ModForumArea=Solaranlagen
|ModTechName=76_SolarForecast.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
[[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung|SolarForecast]] ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:
[[Datei:sfc1.png|right|thumb|300px|grafische Ansicht SolarForecast]]

::* zur Gewinnung solarer Prognosewerte können die SolCast API, OpenMeteo API, Forecast.Solar API, Victron VRM Portal API oder alternativ DWD Stahlungswerte-Stationen verwendet werden

::* optionale KI Unterstützung der PV-Prognose bei Verwendung von geeigneten Solar-API's

::* es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose sowie SoC Prognose (bei Batterie-Integration) erstellt

::* Wetterdaten werden über DWD Wetter-Stationen oder verschiedene API integriert. Es können verschiedene API zur Gewinnung von Solar- und Wetterdaten kombiniert werden.

::* Sprachensupport EN / DE

::* die Prognosedaten, Wetterdaten, Verbraucherplanungen und die aktuellen Energieflüsse werden in umfangreich anpassbaren integrierten Grafiken dargestellt

::* es wird keine externe SQL-Datenbank benötigt, die Datenhaltung erfolgt in einer Memory basierten Cachedatenbank inkl. einer Filesystempersistenz zur Datensicherung und Wiederherstellung beim FHEM-Restart

::* die Integration von Geräten wie Wechselrichter, Energy Meter, Batterien, Wetterstationen oder Verbrauchern ist offen und universell gestaltet und bietet dem Anwender maximale Freiheiten bei der Einrichtung seines individuellen Solardatensystems.

::* eine Integration von bis zu 4 Inverter und Smartloader (DC-DC Batterieladegeräte) ist möglich

::* eine Integration von bis zu 3 nicht PV-Energieerzeugern wie BHKW, Windrädern oder Notstromaggregaten ist möglich

::* eine integrierte und umfangreich anpassbare Verbrauchersteuerung vereint die PV Prognose basierte Einplanung der Verbraucher mit der Möglichkeit die Verbraucher durch das Modul schalten zu lassen und dadurch auf PV Erzeugungsschwankungen automatisch dynamisch zu reagieren

::* Einbindung von bis zu drei Batteriespeichersystemen

::* Bereitstellung von Leitwerten zur optimalen Einstellung/Steuerung von Batteriespeichersystemen

::* trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzererlebnis geboten

'''Abgrenzung:''' Das Modul 76_SolarForecast ist nicht zu verwechseln mit der SQL-basierten (DbLog) Prognose-Lösung mit Kostal Plenticore Wechselrichtern, die auf der eigenen Seite '''[[Kostal_Plenticore_10_Plus]]''' behandelt wird. Diese Lösung beschreibt kein monolithisches Modul, sondern basiert auf einer orchestrierbaren Zusammenstellung individueller Perl Programmbausteine.

Im vorliegenden Wiki-Beitrag wird ausschließlich das Modul 76_SolarForecast behandelt.

== Rahmenbedingungen und Voraussetzungen ==

Das Wiki gibt allgemeingültige und teilweise sehr spezifische bzw. tiefgehende Informationen und Handlungsempfehlungen zum SolarForecast Modul. Die dargestellten Informationen beziehen sich auf den zum Zeitpunkt der Wiki-Erstellung vorhandenen Entwicklungsstand des Moduls. Durch die stetige Weiterentwicklung können sich Abweichungen zum beschriebenen Inhalt ergeben oder zur Obsoleszenz dieser Inhalte führen.

Vergleiche deshalb die Informationen immer mit der aktuellen Befehls-Referenz zum Modul!

== Definition ==
Ein SolarForecast Device wird mit dem Befehl

define <Name> SolarForecast

angelegt. Nach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert. Alle Attribute und Readings die eine Einstellung der Anlage bewirken, sind mit dem Präfix "setup" versehen.

Die Verwendung von setup-Readings gestattet es die Anlagenparameter dynamisch im Betrieb zu verändern. So kann mit

set <Name> setupStringAzimuth bzw.
set <Name> setupStringDeclination

die Ausrichtung und der Neigungswinkel der PV-Module ständig angepasst werden, was zum Beispiel bei einer dem Sonnenstand nachgeführten Anlage von Bedeutung ist.

Die abgefragten Einstellungen während des Dialoges sind ausführlich in den entsprechenden Attributen bzw. Set-Kommandos erläutert. Die benötigten Informationen sind anhängig von der gewählten Prognose-API und können im Umfang variieren.

[[Datei:Screenshot 2024-09-21 213257.png|right|thumb|400px|Anlagenprüfung über Drucktaste in der Kopfgrafik]]

Sobald alle verlangten Einstellungen vorgenommen sind, sollte eine Anlagenprüfung mit

set <Name> plantConfiguration check

oder über die angebotene Drucktaste in der Grafik durchgeführt werden. Es wird eine Plausibilitätsprüfung vorgenommen und das Ergebnis sowie eventuelle Hinweise bzw. Fehler ausgegeben.
Die Prüfung kann beliebig wiederholt werden und sollte sich bei jeder Einstellungsänderung der Anlage durchgeführt werden. Dadurch wird die Wahrscheinlichkeit von fehlerhaften Einstellungen minimiert.

Neben den grundlegenden Einstellungen können im Device weitere sekundäre Anlagenkomponenten wie Batteriesystem(e) (Attribut setupBatteryDev1 - setupBatteryDev3), weitere Wetter-Devices (Attribut setupWeatherDev1 - setupWeatherDev3) oder sonstige Erzeuger (z.B. BHKW, Winderzeugung, Notstromaggregat) integriert werden (Attribut setupOtherProducer01 - setupOtherProducer03).

Die verlangten Parameter der Anlage werden in der Online-Hilfe umfassend beschrieben und deren Funktion erschließt sich zum größten Teil selbst. Dennoch soll nachfolgend auf einige Punkte im Zusammenhang der Einrichtung eingegangen werden.

 
=== Hinweise zur Struktur der Attribute ===

Durch die umfangreichen Funktionen des Moduls würde bei Nutzung der im FHEM herkömmlich vorhandenen Attributstruktur die Anzahl der benötigten Attribute extrem stark steigen und nicht sinnvoll genutzt werden können. Deshalb gibt es neben den ''gewöhnlichen'' Attributen mit einfachen Werteauswahlmöglichkeiten oder Eingaben (z.B. ctrlDebug, ctrlSpecialReadings) sogenannte ''zusammengesetzte'' Attribute, deren Inhalt durch '''Schlüssel=Wert Paare''' gebildet wird und dadurch deutlich mehr Funktionen und Informationen transportieren als ein gewöhnliches Attribut.

Für zusammengesetzte Attribute besteht die zusätzliche Möglichkeit, gewünschte Änderungen der Schlüssel=Wert Paare selektiv vornehmen zu können, ohne das gesamte Attribut aufrufen und ändern zu müssen. Die Vorgang, der vor allem für programmtechnische Manipulationen gedacht ist, kann durch eine Set-Funktion ausgeführt werden:

set <Name> attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

Die Funktionen der Attribute werden durch einen Präfix geclustert und so inhaltlich, aber vor allem auch in der Attribute Drop-Down Liste, strukturiert dargestellt.

Die Bedeutung der '''Präfixe''' sind:

* '''ai''' - Steuerungsfunktionen für KI (z.B. aiControl)
* '''consumer''' - Registrierung und Einstellungen für Verbraucher (z.B. consumer02, consumerControl)
* '''ctrl''' - Steuerungsfunktion allgemeiner Art (z.B. ctrlDebug, ctrlSpecialReadings, ctrlUserExitFn)
* '''flowGraphic''' - Einstellungen für die Energieflußgrafik (z.B. flowGraphicControl)
* '''graphic''' - Einstellung für die Grafik allgemein (z.B. graphicSelect, graphicControl)
* '''graphicBeam''' - Einstellungen bestimmte Balkeneigenschaften in der Balkengrafik (z.B. graphicBeamHeightLevel1)
* '''plant''' - übergreifende Einstellungen betreffend der gesamten PV-Anlage bzw. des SolarForecast-Devices (z.B. plantControl)
* '''setup''' - Registrierung von Geräten in der Gesamtanlage und Einstellung deren Eigenschaften (Inverter, Zähler, Batterien usw.)

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

Mit den Attributen setupInverterDev01 bis setupInverterDevXX werden die vorhandenen Wechselrichter der Anlage registriert.
Das Modul unterscheidet verschiedene Wechselrichter-Typen, die sich durch ihre Arbeitsweise innerhalb der Anlage unterscheiden. Die Schlüssel=Wert Paare in den Attributen können mehrzeilig organisiert werden. Das erleichtert die Übersicht wenn viele dieser Parameter eingegeben werden.

;PV-Wechselrichter: Es ist der Standard Wechselrichter in einer PV-Anlage. An ihn sind die Solarzellen bzw. Strings angeschlossen. Die zugeordneten Strings können mit dem Schlüssel '''strings''' zugeordnet werden. Ohne diese Angabe werden diesem Gerät alle definierten Strings (siehe Attribut ''setupInverterStrings'') zugeordnet. Der Wechselrichter liefert seine Energie in das Hausnetz. Alternativ kann mit der Angabe '''feed=grid''' die Funktion des Wechselrichters geändert werden. Diese Angabe sagt aus, dass dieser Wechselrichter ausschließlich in das öffentliche Netz einspeist.

Hier ein Beispiel-Setup eines PV-Wechselrichters (SMA STP):

STP_5000 pvIn=string_1_pdc:kW pvOut=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100

;Solar-Ladegeräte: Solar-Ladegeräte sind DC-DC Wandler und liefern die Energie der angeschlossenen Solarzellen nicht in das Wechselstromnetz, sondern laden direkt eine Batterie bzw. versorgen einen Batteriewechselrichter auf der Gleichstromseite. Die Funktion als Solar-Ladegerät wird mit '''feed=bat''' aktiviert, die relevanten Strings können ebenfalls mit dem Schlüssel '''strings''' zugeordnet werden. Ein Beispiel eines Solar-Ladegerätes ist ein Victron SmartSolar MPPT.

Ein Beispiel für das Setup eines Solar-Ladegeräts (SmartSolar Charger MPPT):

MQTT2_cerboGX_c0619ab34e08_solarcharger_Common pv=Yield_Power_value:W etotal=Yield_System_value:kWh capacity=2080 strings=Schleppdach feed=bat synchron=0 limit=100

;Batterie-Wechselrichter: Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer Batterie (=Gleichstromquelle) und dem Wechselstrom-Hausnetz. Die Funktion als Batterie-Wechselrichter wird mit der Angabe '''strings=none''' aktiviert. Die Schlüssel ''etotal'' und ''pv'' können bei einem Batterie-Wechselrichter ohne zugeordnete Solarzellen nicht gesetzt werden. Ein Beispiel eines Batterie-Wechselrichter ist der Victron MultiPlus II.

Ein Setup-Beispiel für einen Batterie-Wechselrichter (Victron MultiPlus II):

<pre>
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
icon=inverter@darkorange:inverter@grey
asynchron=0
</pre>

Die Eigenschaften des Wechselrichters werden durch eine Reihe von <Schlüssel=Wert> Paaren festgelegt. Auf einige dieser Paramter soll hier eingegangen werden.

 
==== Ausgewählte Schlüssel=Wert Paare ====

 
* '''pvIn=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvIn'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell zugeführte PV-Leistung bereitstellt. Der Schlüssel ist optional und dient in erster Linie dazu den entsprechenden Input-Wert in der Flußgrafik anzuzeigen sofern man das Attribut flowGraphicControl->showGenerators=1 setzt. Dadurch ist auch der Eigenverbrauch des Inverters bzw. dessen Wandlungsverlust visuell abschätzbar.

* '''pvOut=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvOut'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell erzeugte Leistung als positiven Wert liefert. Für einen PV-Wechselrichter (DC->AC) oder Solar-Ladegerät (DC->DC) ist es die erzeugte PV-Leistung.

* '''ac2dc=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter vom Hausnetz in Richtung Batterie (AC->DC) wandelt.

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)
;graphicBeamHeightLevel1:Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene (hier Ebene 1)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===
Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und, wenn ein Event eines als 'asynchron' definierten Devices auftritt, gesammelt und daraus permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

=== Wie wird die Verbrauchsprognose erstellt? ===

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

==== Debugging der Verbrauchsprognose ====
Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

=== Wie kann eine fehlerhafte Verbrauchsprognose korrigiert werden? ===
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionHistory 07 21

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
PVH_SolarForecast_<name> - PV History
PVC_SolarForecast_<name> - PV Circular
PVCfg_SolarForecast_<name> - PV Anlagenkonfiguration
PVCsm_SolarForecast_<name> - Consumer Status
ScApi_SolarForecast_<name> - Strahlungswerte aus verwendeter API
StatApi_SolarForecast_<name> - Statusdaten der verwendeten API's
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - KI Input Daten = Raw Trainigsdaten
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten 3 Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "pvHistory" restored
2023.10.02 09:57:07.969 3: SolCast6 - cached data "pvCircular" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "consumerMaster" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "radiationApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "statusApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "weatherApiData" restored
2023.10.02 09:57:07.974 3: SolCast6 - cached data "aiTrainedData" restored
2023.10.02 09:57:07.976 3: SolCast6 - cached data "aiRawData" restored
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 5. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. starten von FHEM (die Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere zwei Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese beiden Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagement01 lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>]

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten darf. Die Angabe ist optional. (default: 20)

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit.

Alle Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Inhalt 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Inhalt 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

 

===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und folgenden Tag korrigiert. Das bedeutet, dass der Minimum SoC z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Batterie wieder vollständig zu zuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) Victron MPII Verbund
my $actmcc = ReadingsNum ($vebus, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_01', 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Strom b. Battery_ChargeRequest
$load = 21;
}
else {
$load = $maxcspc;
}
}

## Batterie Einstellung MaxChargeCurrent
##########################################
if ($load != $actmcc) {
CommandSet (undef, "$vebus MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vebus set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 
=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 
=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
== Konfigurationsbeispiele ==

=== Visualisierung solare Vorhersage und reale Erzeugung ===

Zu Beginn jedes neuen Tages gegen 00:00 Uhr werden durch das SolarForecast Device Events für die initiale PV Prognose des kommenden Tages erstellt.
Der Readingteil dieser Events heißt

AllPVforecastsToEvent

Die Uhrzeiten der Events sind so aufbereitet und können direkt geloggt werden um sie in einen SVG Plot zu integrieren.
Im SolarForecast Device ist dieses Reading nicht sichtbar, nur die Events werden erstellt.

Die meteorologischen Bedingungen verändern sich über den Tag permanent. Je nach gewählter Strahlungsdatenquelle (eine API oder DWD Device) erfolgt eine mehr oder weniger dynamische Anpassung der Prognose an die sich verändernde Umwelt.

Aktuelle Prognosedaten sowie die reale PV Erzeugung der vergangenen Stunde können über die Readings

LastHourPVforecast
LastHourPVreal

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.<syntaxhighlight lang="perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.
Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten einlesen kann. Der Code wird nur ausgeführt, wenn das Reading nextCycletime ein Event erzeugt.<syntaxhighlight lang="perl">
forecast_json:nextCycletime.* {

use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => '%Y-%m-%d %H:%M:%S',
time_zone => 'Europe/Berlin',
);

# Alle NextHour-Daten durchsuchen
while ($hour < 100) {
my $hour_str = sprintf('NextHour%02d', $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'starttime', 'na');
my $pvfc = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'pvfc', 'na');

# Schleife beenden, wenn keine Werte mehr vorhanden sind
last if $start_str eq 'na' or $pvfc eq 'na';

# parse und konvertiere Zeit
my $start_dt = $parser->parse_datetime($start_str);
my $end_dt = $start_dt->clone->add(hours => 1);

# nach UTC konvertieren
$start_dt->set_time_zone('UTC');
$end_dt->set_time_zone('UTC');

push @output, {
start => $start_dt->iso8601() . 'Z',
end => $end_dt->iso8601() . 'Z',
value => 0 + $pvfc,
};

$hour++;
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
}
</syntaxhighlight>
[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]
Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):<syntaxhighlight>
define WEBapi FHEMWEB 8089
attr WEBapi csrfToken none
</syntaxhighlight>In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json','[]')} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
</syntaxhighlight>Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2025-08-04T17:27:07Z

All-Ex: /* PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) */

{{Baustelle}}
{{Hinweis|Die vorliegende Wiki-Seite befindet sich im Aufbau.}}
{{Infobox Modul
|ModPurpose=Solarprognose und Verbrauchersteuerung
|ModType=d
|ModCmdRef=76_SolarForecast
|ModFTopic=117864
|ModForumArea=Solaranlagen
|ModTechName=76_SolarForecast.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
[[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung|SolarForecast]] ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:
[[Datei:sfc1.png|right|thumb|300px|grafische Ansicht SolarForecast]]

::* zur Gewinnung solarer Prognosewerte können die SolCast API, OpenMeteo API, Forecast.Solar API, Victron VRM Portal API oder alternativ DWD Stahlungswerte-Stationen verwendet werden

::* optionale KI Unterstützung der PV-Prognose bei Verwendung von geeigneten Solar-API's

::* es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose sowie SoC Prognose (bei Batterie-Integration) erstellt

::* Wetterdaten werden über DWD Wetter-Stationen oder verschiedene API integriert. Es können verschiedene API zur Gewinnung von Solar- und Wetterdaten kombiniert werden.

::* Sprachensupport EN / DE

::* die Prognosedaten, Wetterdaten, Verbraucherplanungen und die aktuellen Energieflüsse werden in umfangreich anpassbaren integrierten Grafiken dargestellt

::* es wird keine externe SQL-Datenbank benötigt, die Datenhaltung erfolgt in einer Memory basierten Cachedatenbank inkl. einer Filesystempersistenz zur Datensicherung und Wiederherstellung beim FHEM-Restart

::* die Integration von Geräten wie Wechselrichter, Energy Meter, Batterien, Wetterstationen oder Verbrauchern ist offen und universell gestaltet und bietet dem Anwender maximale Freiheiten bei der Einrichtung seines individuellen Solardatensystems.

::* eine Integration von bis zu 4 Inverter und Smartloader (DC-DC Batterieladegeräte) ist möglich

::* eine Integration von bis zu 3 nicht PV-Energieerzeugern wie BHKW, Windrädern oder Notstromaggregaten ist möglich

::* eine integrierte und umfangreich anpassbare Verbrauchersteuerung vereint die PV Prognose basierte Einplanung der Verbraucher mit der Möglichkeit die Verbraucher durch das Modul schalten zu lassen und dadurch auf PV Erzeugungsschwankungen automatisch dynamisch zu reagieren

::* Einbindung von bis zu drei Batteriespeichersystemen

::* Bereitstellung von Leitwerten zur optimalen Einstellung/Steuerung von Batteriespeichersystemen

::* trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzererlebnis geboten

'''Abgrenzung:''' Das Modul 76_SolarForecast ist nicht zu verwechseln mit der SQL-basierten (DbLog) Prognose-Lösung mit Kostal Plenticore Wechselrichtern, die auf der eigenen Seite '''[[Kostal_Plenticore_10_Plus]]''' behandelt wird. Diese Lösung beschreibt kein monolithisches Modul, sondern basiert auf einer orchestrierbaren Zusammenstellung individueller Perl Programmbausteine.

Im vorliegenden Wiki-Beitrag wird ausschließlich das Modul 76_SolarForecast behandelt.

== Rahmenbedingungen und Voraussetzungen ==

Das Wiki gibt allgemeingültige und teilweise sehr spezifische bzw. tiefgehende Informationen und Handlungsempfehlungen zum SolarForecast Modul. Die dargestellten Informationen beziehen sich auf den zum Zeitpunkt der Wiki-Erstellung vorhandenen Entwicklungsstand des Moduls. Durch die stetige Weiterentwicklung können sich Abweichungen zum beschriebenen Inhalt ergeben oder zur Obsoleszenz dieser Inhalte führen.

Vergleiche deshalb die Informationen immer mit der aktuellen Befehls-Referenz zum Modul!

== Definition ==
Ein SolarForecast Device wird mit dem Befehl

define <Name> SolarForecast

angelegt. Nach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert. Alle Attribute und Readings die eine Einstellung der Anlage bewirken, sind mit dem Präfix "setup" versehen.

Die Verwendung von setup-Readings gestattet es die Anlagenparameter dynamisch im Betrieb zu verändern. So kann mit

set <Name> setupStringAzimuth bzw.
set <Name> setupStringDeclination

die Ausrichtung und der Neigungswinkel der PV-Module ständig angepasst werden, was zum Beispiel bei einer dem Sonnenstand nachgeführten Anlage von Bedeutung ist.

Die abgefragten Einstellungen während des Dialoges sind ausführlich in den entsprechenden Attributen bzw. Set-Kommandos erläutert. Die benötigten Informationen sind anhängig von der gewählten Prognose-API und können im Umfang variieren.

[[Datei:Screenshot 2024-09-21 213257.png|right|thumb|400px|Anlagenprüfung über Drucktaste in der Kopfgrafik]]

Sobald alle verlangten Einstellungen vorgenommen sind, sollte eine Anlagenprüfung mit

set <Name> plantConfiguration check

oder über die angebotene Drucktaste in der Grafik durchgeführt werden. Es wird eine Plausibilitätsprüfung vorgenommen und das Ergebnis sowie eventuelle Hinweise bzw. Fehler ausgegeben.
Die Prüfung kann beliebig wiederholt werden und sollte sich bei jeder Einstellungsänderung der Anlage durchgeführt werden. Dadurch wird die Wahrscheinlichkeit von fehlerhaften Einstellungen minimiert.

Neben den grundlegenden Einstellungen können im Device weitere sekundäre Anlagenkomponenten wie Batteriesystem(e) (Attribut setupBatteryDev1 - setupBatteryDev3), weitere Wetter-Devices (Attribut setupWeatherDev1 - setupWeatherDev3) oder sonstige Erzeuger (z.B. BHKW, Winderzeugung, Notstromaggregat) integriert werden (Attribut setupOtherProducer01 - setupOtherProducer03).

Die verlangten Parameter der Anlage werden in der Online-Hilfe umfassend beschrieben und deren Funktion erschließt sich zum größten Teil selbst. Dennoch soll nachfolgend auf einige Punkte im Zusammenhang der Einrichtung eingegangen werden.

 
=== Hinweise zur Struktur der Attribute ===

Durch die umfangreichen Funktionen des Moduls würde bei Nutzung der im FHEM herkömmlich vorhandenen Attributstruktur die Anzahl der benötigten Attribute extrem stark steigen und nicht sinnvoll genutzt werden können. Deshalb gibt es neben den ''gewöhnlichen'' Attributen mit einfachen Werteauswahlmöglichkeiten oder Eingaben (z.B. ctrlDebug, ctrlSpecialReadings) sogenannte ''zusammengesetzte'' Attribute, deren Inhalt durch '''Schlüssel=Wert Paare''' gebildet wird und dadurch deutlich mehr Funktionen und Informationen transportieren als ein gewöhnliches Attribut.

Für zusammengesetzte Attribute besteht die zusätzliche Möglichkeit, gewünschte Änderungen der Schlüssel=Wert Paare selektiv vornehmen zu können, ohne das gesamte Attribut aufrufen und ändern zu müssen. Die Vorgang, der vor allem für programmtechnische Manipulationen gedacht ist, kann durch eine Set-Funktion ausgeführt werden:

set <Name> attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

Die Funktionen der Attribute werden durch einen Präfix geclustert und so inhaltlich, aber vor allem auch in der Attribute Drop-Down Liste, strukturiert dargestellt.

Die Bedeutung der '''Präfixe''' sind:

* '''ai''' - Steuerungsfunktionen für KI (z.B. aiControl)
* '''consumer''' - Registrierung und Einstellungen für Verbraucher (z.B. consumer02, consumerControl)
* '''ctrl''' - Steuerungsfunktion allgemeiner Art (z.B. ctrlDebug, ctrlSpecialReadings, ctrlUserExitFn)
* '''flowGraphic''' - Einstellungen für die Energieflußgrafik (z.B. flowGraphicControl)
* '''graphic''' - Einstellung für die Grafik allgemein (z.B. graphicSelect, graphicControl)
* '''graphicBeam''' - Einstellungen bestimmte Balkeneigenschaften in der Balkengrafik (z.B. graphicBeamHeightLevel1)
* '''plant''' - übergreifende Einstellungen betreffend der gesamten PV-Anlage bzw. des SolarForecast-Devices (z.B. plantControl)
* '''setup''' - Registrierung von Geräten in der Gesamtanlage und Einstellung deren Eigenschaften (Inverter, Zähler, Batterien usw.)

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

Mit den Attributen setupInverterDev01 bis setupInverterDevXX werden die vorhandenen Wechselrichter der Anlage registriert.
Das Modul unterscheidet verschiedene Wechselrichter-Typen, die sich durch ihre Arbeitsweise innerhalb der Anlage unterscheiden. Die Schlüssel=Wert Paare in den Attributen können mehrzeilig organisiert werden. Das erleichtert die Übersicht wenn viele dieser Parameter eingegeben werden.

;PV-Wechselrichter: Es ist der Standard Wechselrichter in einer PV-Anlage. An ihn sind die Solarzellen bzw. Strings angeschlossen. Die zugeordneten Strings können mit dem Schlüssel '''strings''' zugeordnet werden. Ohne diese Angabe werden diesem Gerät alle definierten Strings (siehe Attribut ''setupInverterStrings'') zugeordnet. Der Wechselrichter liefert seine Energie in das Hausnetz. Alternativ kann mit der Angabe '''feed=grid''' die Funktion des Wechselrichters geändert werden. Diese Angabe sagt aus, dass dieser Wechselrichter ausschließlich in das öffentliche Netz einspeist.

Hier ein Beispiel-Setup eines PV-Wechselrichters (SMA STP):

STP_5000 pvIn=string_1_pdc:kW pvOut=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100

;Solar-Ladegeräte: Solar-Ladegeräte sind DC-DC Wandler und liefern die Energie der angeschlossenen Solarzellen nicht in das Wechselstromnetz, sondern laden direkt eine Batterie bzw. versorgen einen Batteriewechselrichter auf der Gleichstromseite. Die Funktion als Solar-Ladegerät wird mit '''feed=bat''' aktiviert, die relevanten Strings können ebenfalls mit dem Schlüssel '''strings''' zugeordnet werden. Ein Beispiel eines Solar-Ladegerätes ist ein Victron SmartSolar MPPT.

Ein Beispiel für das Setup eines Solar-Ladegeräts (SmartSolar Charger MPPT):

MQTT2_cerboGX_c0619ab34e08_solarcharger_Common pv=Yield_Power_value:W etotal=Yield_System_value:kWh capacity=2080 strings=Schleppdach feed=bat synchron=0 limit=100

;Batterie-Wechselrichter: Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer Batterie (=Gleichstromquelle) und dem Wechselstrom-Hausnetz. Die Funktion als Batterie-Wechselrichter wird mit der Angabe '''strings=none''' aktiviert. Die Schlüssel ''etotal'' und ''pv'' können bei einem Batterie-Wechselrichter ohne zugeordnete Solarzellen nicht gesetzt werden. Ein Beispiel eines Batterie-Wechselrichter ist der Victron MultiPlus II.

Ein Setup-Beispiel für einen Batterie-Wechselrichter (Victron MultiPlus II):

<pre>
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
icon=inverter@darkorange:inverter@grey
asynchron=0
</pre>

Die Eigenschaften des Wechselrichters werden durch eine Reihe von <Schlüssel=Wert> Paaren festgelegt. Auf einige dieser Paramter soll hier eingegangen werden.

 
==== Ausgewählte Schlüssel=Wert Paare ====

 
* '''pvIn=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvIn'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell zugeführte PV-Leistung bereitstellt. Der Schlüssel ist optional und dient in erster Linie dazu den entsprechenden Input-Wert in der Flußgrafik anzuzeigen sofern man das Attribut flowGraphicControl->showGenerators=1 setzt. Dadurch ist auch der Eigenverbrauch des Inverters bzw. dessen Wandlungsverlust visuell abschätzbar.

* '''pvOut=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvOut'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell erzeugte Leistung als positiven Wert liefert. Für einen PV-Wechselrichter (DC->AC) oder Solar-Ladegerät (DC->DC) ist es die erzeugte PV-Leistung.

* '''ac2dc=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter vom Hausnetz in Richtung Batterie (AC->DC) wandelt.

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)
;graphicBeamHeightLevel1:Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene (hier Ebene 1)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===
Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und, wenn ein Event eines als 'asynchron' definierten Devices auftritt, gesammelt und daraus permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

=== Wie wird die Verbrauchsprognose erstellt? ===

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

==== Debugging der Verbrauchsprognose ====
Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

=== Wie kann eine fehlerhafte Verbrauchsprognose korrigiert werden? ===
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionHistory 07 21

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
PVH_SolarForecast_<name> - PV History
PVC_SolarForecast_<name> - PV Circular
PVCfg_SolarForecast_<name> - PV Anlagenkonfiguration
PVCsm_SolarForecast_<name> - Consumer Status
ScApi_SolarForecast_<name> - Strahlungswerte aus verwendeter API
StatApi_SolarForecast_<name> - Statusdaten der verwendeten API's
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - KI Input Daten = Raw Trainigsdaten
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten 3 Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "pvHistory" restored
2023.10.02 09:57:07.969 3: SolCast6 - cached data "pvCircular" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "consumerMaster" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "radiationApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "statusApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "weatherApiData" restored
2023.10.02 09:57:07.974 3: SolCast6 - cached data "aiTrainedData" restored
2023.10.02 09:57:07.976 3: SolCast6 - cached data "aiRawData" restored
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 5. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. starten von FHEM (die Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere zwei Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese beiden Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagement01 lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>]

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten darf. Die Angabe ist optional. (default: 20)

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit.

Alle Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Inhalt 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Inhalt 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

 

===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und folgenden Tag korrigiert. Das bedeutet, dass der Minimum SoC z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Batterie wieder vollständig zu zuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) Victron MPII Verbund
my $actmcc = ReadingsNum ($vebus, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_01', 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Strom b. Battery_ChargeRequest
$load = 21;
}
else {
$load = $maxcspc;
}
}

## Batterie Einstellung MaxChargeCurrent
##########################################
if ($load != $actmcc) {
CommandSet (undef, "$vebus MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vebus set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 
=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 
=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
== Konfigurationsbeispiele ==

=== Visualisierung solare Vorhersage und reale Erzeugung ===

Zu Beginn jedes neuen Tages gegen 00:00 Uhr werden durch das SolarForecast Device Events für die initiale PV Prognose des kommenden Tages erstellt.
Der Readingteil dieser Events heißt

AllPVforecastsToEvent

Die Uhrzeiten der Events sind so aufbereitet und können direkt geloggt werden um sie in einen SVG Plot zu integrieren.
Im SolarForecast Device ist dieses Reading nicht sichtbar, nur die Events werden erstellt.

Die meteorologischen Bedingungen verändern sich über den Tag permanent. Je nach gewählter Strahlungsdatenquelle (eine API oder DWD Device) erfolgt eine mehr oder weniger dynamische Anpassung der Prognose an die sich verändernde Umwelt.

Aktuelle Prognosedaten sowie die reale PV Erzeugung der vergangenen Stunde können über die Readings

LastHourPVforecast
LastHourPVreal

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.<syntaxhighlight lang="perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.
Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten verwenden kann:<syntaxhighlight lang="perl">
forecast_json {

use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => '%Y-%m-%d %H:%M:%S',
time_zone => 'Europe/Berlin',
);

# Alle NextHour-Daten durchsuchen
while ($hour < 100) {
my $hour_str = sprintf('NextHour%02d', $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'starttime', 'na');
my $pvfc = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'pvfc', 'na');

# Schleife beenden, wenn keine Werte mehr vorhanden sind
last if $start_str eq 'na' or $pvfc eq 'na';

# parse und konvertiere Zeit
my $start_dt = $parser->parse_datetime($start_str);
my $end_dt = $start_dt->clone->add(hours => 1);

# nach UTC konvertieren
$start_dt->set_time_zone('UTC');
$end_dt->set_time_zone('UTC');

push @output, {
start => $start_dt->iso8601() . 'Z',
end => $end_dt->iso8601() . 'Z',
value => 0 + $pvfc,
};

$hour++;
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
}
</syntaxhighlight>
[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]
Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):<syntaxhighlight>
define WEBapi FHEMWEB 8089
attr WEBapi csrfToken none
</syntaxhighlight>In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json','[]')} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
</syntaxhighlight>Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2025-08-04T15:57:45Z

All-Ex: /* PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) */

{{Baustelle}}
{{Hinweis|Die vorliegende Wiki-Seite befindet sich im Aufbau.}}
{{Infobox Modul
|ModPurpose=Solarprognose und Verbrauchersteuerung
|ModType=d
|ModCmdRef=76_SolarForecast
|ModFTopic=117864
|ModForumArea=Solaranlagen
|ModTechName=76_SolarForecast.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
[[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung|SolarForecast]] ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:
[[Datei:sfc1.png|right|thumb|300px|grafische Ansicht SolarForecast]]

::* zur Gewinnung solarer Prognosewerte können die SolCast API, OpenMeteo API, Forecast.Solar API, Victron VRM Portal API oder alternativ DWD Stahlungswerte-Stationen verwendet werden

::* optionale KI Unterstützung der PV-Prognose bei Verwendung von geeigneten Solar-API's

::* es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose sowie SoC Prognose (bei Batterie-Integration) erstellt

::* Wetterdaten werden über DWD Wetter-Stationen oder verschiedene API integriert. Es können verschiedene API zur Gewinnung von Solar- und Wetterdaten kombiniert werden.

::* Sprachensupport EN / DE

::* die Prognosedaten, Wetterdaten, Verbraucherplanungen und die aktuellen Energieflüsse werden in umfangreich anpassbaren integrierten Grafiken dargestellt

::* es wird keine externe SQL-Datenbank benötigt, die Datenhaltung erfolgt in einer Memory basierten Cachedatenbank inkl. einer Filesystempersistenz zur Datensicherung und Wiederherstellung beim FHEM-Restart

::* die Integration von Geräten wie Wechselrichter, Energy Meter, Batterien, Wetterstationen oder Verbrauchern ist offen und universell gestaltet und bietet dem Anwender maximale Freiheiten bei der Einrichtung seines individuellen Solardatensystems.

::* eine Integration von bis zu 4 Inverter und Smartloader (DC-DC Batterieladegeräte) ist möglich

::* eine Integration von bis zu 3 nicht PV-Energieerzeugern wie BHKW, Windrädern oder Notstromaggregaten ist möglich

::* eine integrierte und umfangreich anpassbare Verbrauchersteuerung vereint die PV Prognose basierte Einplanung der Verbraucher mit der Möglichkeit die Verbraucher durch das Modul schalten zu lassen und dadurch auf PV Erzeugungsschwankungen automatisch dynamisch zu reagieren

::* Einbindung von bis zu drei Batteriespeichersystemen

::* Bereitstellung von Leitwerten zur optimalen Einstellung/Steuerung von Batteriespeichersystemen

::* trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzererlebnis geboten

'''Abgrenzung:''' Das Modul 76_SolarForecast ist nicht zu verwechseln mit der SQL-basierten (DbLog) Prognose-Lösung mit Kostal Plenticore Wechselrichtern, die auf der eigenen Seite '''[[Kostal_Plenticore_10_Plus]]''' behandelt wird. Diese Lösung beschreibt kein monolithisches Modul, sondern basiert auf einer orchestrierbaren Zusammenstellung individueller Perl Programmbausteine.

Im vorliegenden Wiki-Beitrag wird ausschließlich das Modul 76_SolarForecast behandelt.

== Rahmenbedingungen und Voraussetzungen ==

Das Wiki gibt allgemeingültige und teilweise sehr spezifische bzw. tiefgehende Informationen und Handlungsempfehlungen zum SolarForecast Modul. Die dargestellten Informationen beziehen sich auf den zum Zeitpunkt der Wiki-Erstellung vorhandenen Entwicklungsstand des Moduls. Durch die stetige Weiterentwicklung können sich Abweichungen zum beschriebenen Inhalt ergeben oder zur Obsoleszenz dieser Inhalte führen.

Vergleiche deshalb die Informationen immer mit der aktuellen Befehls-Referenz zum Modul!

== Definition ==
Ein SolarForecast Device wird mit dem Befehl

define <Name> SolarForecast

angelegt. Nach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert. Alle Attribute und Readings die eine Einstellung der Anlage bewirken, sind mit dem Präfix "setup" versehen.

Die Verwendung von setup-Readings gestattet es die Anlagenparameter dynamisch im Betrieb zu verändern. So kann mit

set <Name> setupStringAzimuth bzw.
set <Name> setupStringDeclination

die Ausrichtung und der Neigungswinkel der PV-Module ständig angepasst werden, was zum Beispiel bei einer dem Sonnenstand nachgeführten Anlage von Bedeutung ist.

Die abgefragten Einstellungen während des Dialoges sind ausführlich in den entsprechenden Attributen bzw. Set-Kommandos erläutert. Die benötigten Informationen sind anhängig von der gewählten Prognose-API und können im Umfang variieren.

[[Datei:Screenshot 2024-09-21 213257.png|right|thumb|400px|Anlagenprüfung über Drucktaste in der Kopfgrafik]]

Sobald alle verlangten Einstellungen vorgenommen sind, sollte eine Anlagenprüfung mit

set <Name> plantConfiguration check

oder über die angebotene Drucktaste in der Grafik durchgeführt werden. Es wird eine Plausibilitätsprüfung vorgenommen und das Ergebnis sowie eventuelle Hinweise bzw. Fehler ausgegeben.
Die Prüfung kann beliebig wiederholt werden und sollte sich bei jeder Einstellungsänderung der Anlage durchgeführt werden. Dadurch wird die Wahrscheinlichkeit von fehlerhaften Einstellungen minimiert.

Neben den grundlegenden Einstellungen können im Device weitere sekundäre Anlagenkomponenten wie Batteriesystem(e) (Attribut setupBatteryDev1 - setupBatteryDev3), weitere Wetter-Devices (Attribut setupWeatherDev1 - setupWeatherDev3) oder sonstige Erzeuger (z.B. BHKW, Winderzeugung, Notstromaggregat) integriert werden (Attribut setupOtherProducer01 - setupOtherProducer03).

Die verlangten Parameter der Anlage werden in der Online-Hilfe umfassend beschrieben und deren Funktion erschließt sich zum größten Teil selbst. Dennoch soll nachfolgend auf einige Punkte im Zusammenhang der Einrichtung eingegangen werden.

 
=== Hinweise zur Struktur der Attribute ===

Durch die umfangreichen Funktionen des Moduls würde bei Nutzung der im FHEM herkömmlich vorhandenen Attributstruktur die Anzahl der benötigten Attribute extrem stark steigen und nicht sinnvoll genutzt werden können. Deshalb gibt es neben den ''gewöhnlichen'' Attributen mit einfachen Werteauswahlmöglichkeiten oder Eingaben (z.B. ctrlDebug, ctrlSpecialReadings) sogenannte ''zusammengesetzte'' Attribute, deren Inhalt durch '''Schlüssel=Wert Paare''' gebildet wird und dadurch deutlich mehr Funktionen und Informationen transportieren als ein gewöhnliches Attribut.

Für zusammengesetzte Attribute besteht die zusätzliche Möglichkeit, gewünschte Änderungen der Schlüssel=Wert Paare selektiv vornehmen zu können, ohne das gesamte Attribut aufrufen und ändern zu müssen. Die Vorgang, der vor allem für programmtechnische Manipulationen gedacht ist, kann durch eine Set-Funktion ausgeführt werden:

set <Name> attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

Die Funktionen der Attribute werden durch einen Präfix geclustert und so inhaltlich, aber vor allem auch in der Attribute Drop-Down Liste, strukturiert dargestellt.

Die Bedeutung der '''Präfixe''' sind:

* '''ai''' - Steuerungsfunktionen für KI (z.B. aiControl)
* '''consumer''' - Registrierung und Einstellungen für Verbraucher (z.B. consumer02, consumerControl)
* '''ctrl''' - Steuerungsfunktion allgemeiner Art (z.B. ctrlDebug, ctrlSpecialReadings, ctrlUserExitFn)
* '''flowGraphic''' - Einstellungen für die Energieflußgrafik (z.B. flowGraphicControl)
* '''graphic''' - Einstellung für die Grafik allgemein (z.B. graphicSelect, graphicControl)
* '''graphicBeam''' - Einstellungen bestimmte Balkeneigenschaften in der Balkengrafik (z.B. graphicBeamHeightLevel1)
* '''plant''' - übergreifende Einstellungen betreffend der gesamten PV-Anlage bzw. des SolarForecast-Devices (z.B. plantControl)
* '''setup''' - Registrierung von Geräten in der Gesamtanlage und Einstellung deren Eigenschaften (Inverter, Zähler, Batterien usw.)

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

Mit den Attributen setupInverterDev01 bis setupInverterDevXX werden die vorhandenen Wechselrichter der Anlage registriert.
Das Modul unterscheidet verschiedene Wechselrichter-Typen, die sich durch ihre Arbeitsweise innerhalb der Anlage unterscheiden. Die Schlüssel=Wert Paare in den Attributen können mehrzeilig organisiert werden. Das erleichtert die Übersicht wenn viele dieser Parameter eingegeben werden.

;PV-Wechselrichter: Es ist der Standard Wechselrichter in einer PV-Anlage. An ihn sind die Solarzellen bzw. Strings angeschlossen. Die zugeordneten Strings können mit dem Schlüssel '''strings''' zugeordnet werden. Ohne diese Angabe werden diesem Gerät alle definierten Strings (siehe Attribut ''setupInverterStrings'') zugeordnet. Der Wechselrichter liefert seine Energie in das Hausnetz. Alternativ kann mit der Angabe '''feed=grid''' die Funktion des Wechselrichters geändert werden. Diese Angabe sagt aus, dass dieser Wechselrichter ausschließlich in das öffentliche Netz einspeist.

Hier ein Beispiel-Setup eines PV-Wechselrichters (SMA STP):

STP_5000 pvIn=string_1_pdc:kW pvOut=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100

;Solar-Ladegeräte: Solar-Ladegeräte sind DC-DC Wandler und liefern die Energie der angeschlossenen Solarzellen nicht in das Wechselstromnetz, sondern laden direkt eine Batterie bzw. versorgen einen Batteriewechselrichter auf der Gleichstromseite. Die Funktion als Solar-Ladegerät wird mit '''feed=bat''' aktiviert, die relevanten Strings können ebenfalls mit dem Schlüssel '''strings''' zugeordnet werden. Ein Beispiel eines Solar-Ladegerätes ist ein Victron SmartSolar MPPT.

Ein Beispiel für das Setup eines Solar-Ladegeräts (SmartSolar Charger MPPT):

MQTT2_cerboGX_c0619ab34e08_solarcharger_Common pv=Yield_Power_value:W etotal=Yield_System_value:kWh capacity=2080 strings=Schleppdach feed=bat synchron=0 limit=100

;Batterie-Wechselrichter: Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer Batterie (=Gleichstromquelle) und dem Wechselstrom-Hausnetz. Die Funktion als Batterie-Wechselrichter wird mit der Angabe '''strings=none''' aktiviert. Die Schlüssel ''etotal'' und ''pv'' können bei einem Batterie-Wechselrichter ohne zugeordnete Solarzellen nicht gesetzt werden. Ein Beispiel eines Batterie-Wechselrichter ist der Victron MultiPlus II.

Ein Setup-Beispiel für einen Batterie-Wechselrichter (Victron MultiPlus II):

<pre>
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
icon=inverter@darkorange:inverter@grey
asynchron=0
</pre>

Die Eigenschaften des Wechselrichters werden durch eine Reihe von <Schlüssel=Wert> Paaren festgelegt. Auf einige dieser Paramter soll hier eingegangen werden.

 
==== Ausgewählte Schlüssel=Wert Paare ====

 
* '''pvIn=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvIn'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell zugeführte PV-Leistung bereitstellt. Der Schlüssel ist optional und dient in erster Linie dazu den entsprechenden Input-Wert in der Flußgrafik anzuzeigen sofern man das Attribut flowGraphicControl->showGenerators=1 setzt. Dadurch ist auch der Eigenverbrauch des Inverters bzw. dessen Wandlungsverlust visuell abschätzbar.

* '''pvOut=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvOut'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell erzeugte Leistung als positiven Wert liefert. Für einen PV-Wechselrichter (DC->AC) oder Solar-Ladegerät (DC->DC) ist es die erzeugte PV-Leistung.

* '''ac2dc=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter vom Hausnetz in Richtung Batterie (AC->DC) wandelt.

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)
;graphicBeamHeightLevel1:Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene (hier Ebene 1)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===
Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und, wenn ein Event eines als 'asynchron' definierten Devices auftritt, gesammelt und daraus permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

=== Wie wird die Verbrauchsprognose erstellt? ===

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

==== Debugging der Verbrauchsprognose ====
Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

=== Wie kann eine fehlerhafte Verbrauchsprognose korrigiert werden? ===
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionHistory 07 21

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
PVH_SolarForecast_<name> - PV History
PVC_SolarForecast_<name> - PV Circular
PVCfg_SolarForecast_<name> - PV Anlagenkonfiguration
PVCsm_SolarForecast_<name> - Consumer Status
ScApi_SolarForecast_<name> - Strahlungswerte aus verwendeter API
StatApi_SolarForecast_<name> - Statusdaten der verwendeten API's
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - KI Input Daten = Raw Trainigsdaten
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten 3 Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "pvHistory" restored
2023.10.02 09:57:07.969 3: SolCast6 - cached data "pvCircular" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "consumerMaster" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "radiationApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "statusApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "weatherApiData" restored
2023.10.02 09:57:07.974 3: SolCast6 - cached data "aiTrainedData" restored
2023.10.02 09:57:07.976 3: SolCast6 - cached data "aiRawData" restored
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 5. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. starten von FHEM (die Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere zwei Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese beiden Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagement01 lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>]

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten darf. Die Angabe ist optional. (default: 20)

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit.

Alle Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Inhalt 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Inhalt 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

 

===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und folgenden Tag korrigiert. Das bedeutet, dass der Minimum SoC z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Batterie wieder vollständig zu zuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) Victron MPII Verbund
my $actmcc = ReadingsNum ($vebus, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_01', 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Strom b. Battery_ChargeRequest
$load = 21;
}
else {
$load = $maxcspc;
}
}

## Batterie Einstellung MaxChargeCurrent
##########################################
if ($load != $actmcc) {
CommandSet (undef, "$vebus MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vebus set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 
=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 
=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
== Konfigurationsbeispiele ==

=== Visualisierung solare Vorhersage und reale Erzeugung ===

Zu Beginn jedes neuen Tages gegen 00:00 Uhr werden durch das SolarForecast Device Events für die initiale PV Prognose des kommenden Tages erstellt.
Der Readingteil dieser Events heißt

AllPVforecastsToEvent

Die Uhrzeiten der Events sind so aufbereitet und können direkt geloggt werden um sie in einen SVG Plot zu integrieren.
Im SolarForecast Device ist dieses Reading nicht sichtbar, nur die Events werden erstellt.

Die meteorologischen Bedingungen verändern sich über den Tag permanent. Je nach gewählter Strahlungsdatenquelle (eine API oder DWD Device) erfolgt eine mehr oder weniger dynamische Anpassung der Prognose an die sich verändernde Umwelt.

Aktuelle Prognosedaten sowie die reale PV Erzeugung der vergangenen Stunde können über die Readings

LastHourPVforecast
LastHourPVreal

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.<syntaxhighlight lang="perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.
Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten verwenden kann:<syntaxhighlight lang="perl">
forecast_json {

use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => '%Y-%m-%d %H:%M:%S',
time_zone => 'Europe/Berlin',
);

# Alle NextHour-Daten durchsuchen
while ($hour < 100) {
my $hour_str = sprintf('NextHour%02d', $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'starttime', 'na');
my $pvfc = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'pvfc', 'na');

# Schleife beenden, wenn keine Werte mehr vorhanden sind
last if $start_str eq 'na' or $pvfc eq 'na';

# parse und konvertiere Zeit
my $start_dt = $parser->parse_datetime($start_str);
my $end_dt = $start_dt->clone->add(hours => 1);

# nach UTC konvertieren
$start_dt->set_time_zone('UTC');
$end_dt->set_time_zone('UTC');

push @output, {
start => $start_dt->iso8601() . 'Z',
end => $end_dt->iso8601() . 'Z',
value => 0 + $pvfc,
};

$hour++;
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
}
</syntaxhighlight>
[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]
Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):<syntaxhighlight>
defmod WEBapi FHEMWEB 8089
attr WEBapi csrfToken none
</syntaxhighlight>In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json',<nowiki>''</nowiki>)} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%27%29%7D&XHR=1
</syntaxhighlight>Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2025-08-04T15:47:14Z

All-Ex: /* PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) */

{{Baustelle}}
{{Hinweis|Die vorliegende Wiki-Seite befindet sich im Aufbau.}}
{{Infobox Modul
|ModPurpose=Solarprognose und Verbrauchersteuerung
|ModType=d
|ModCmdRef=76_SolarForecast
|ModFTopic=117864
|ModForumArea=Solaranlagen
|ModTechName=76_SolarForecast.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
[[SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung|SolarForecast]] ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:
[[Datei:sfc1.png|right|thumb|300px|grafische Ansicht SolarForecast]]

::* zur Gewinnung solarer Prognosewerte können die SolCast API, OpenMeteo API, Forecast.Solar API, Victron VRM Portal API oder alternativ DWD Stahlungswerte-Stationen verwendet werden

::* optionale KI Unterstützung der PV-Prognose bei Verwendung von geeigneten Solar-API's

::* es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose sowie SoC Prognose (bei Batterie-Integration) erstellt

::* Wetterdaten werden über DWD Wetter-Stationen oder verschiedene API integriert. Es können verschiedene API zur Gewinnung von Solar- und Wetterdaten kombiniert werden.

::* Sprachensupport EN / DE

::* die Prognosedaten, Wetterdaten, Verbraucherplanungen und die aktuellen Energieflüsse werden in umfangreich anpassbaren integrierten Grafiken dargestellt

::* es wird keine externe SQL-Datenbank benötigt, die Datenhaltung erfolgt in einer Memory basierten Cachedatenbank inkl. einer Filesystempersistenz zur Datensicherung und Wiederherstellung beim FHEM-Restart

::* die Integration von Geräten wie Wechselrichter, Energy Meter, Batterien, Wetterstationen oder Verbrauchern ist offen und universell gestaltet und bietet dem Anwender maximale Freiheiten bei der Einrichtung seines individuellen Solardatensystems.

::* eine Integration von bis zu 4 Inverter und Smartloader (DC-DC Batterieladegeräte) ist möglich

::* eine Integration von bis zu 3 nicht PV-Energieerzeugern wie BHKW, Windrädern oder Notstromaggregaten ist möglich

::* eine integrierte und umfangreich anpassbare Verbrauchersteuerung vereint die PV Prognose basierte Einplanung der Verbraucher mit der Möglichkeit die Verbraucher durch das Modul schalten zu lassen und dadurch auf PV Erzeugungsschwankungen automatisch dynamisch zu reagieren

::* Einbindung von bis zu drei Batteriespeichersystemen

::* Bereitstellung von Leitwerten zur optimalen Einstellung/Steuerung von Batteriespeichersystemen

::* trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzererlebnis geboten

'''Abgrenzung:''' Das Modul 76_SolarForecast ist nicht zu verwechseln mit der SQL-basierten (DbLog) Prognose-Lösung mit Kostal Plenticore Wechselrichtern, die auf der eigenen Seite '''[[Kostal_Plenticore_10_Plus]]''' behandelt wird. Diese Lösung beschreibt kein monolithisches Modul, sondern basiert auf einer orchestrierbaren Zusammenstellung individueller Perl Programmbausteine.

Im vorliegenden Wiki-Beitrag wird ausschließlich das Modul 76_SolarForecast behandelt.

== Rahmenbedingungen und Voraussetzungen ==

Das Wiki gibt allgemeingültige und teilweise sehr spezifische bzw. tiefgehende Informationen und Handlungsempfehlungen zum SolarForecast Modul. Die dargestellten Informationen beziehen sich auf den zum Zeitpunkt der Wiki-Erstellung vorhandenen Entwicklungsstand des Moduls. Durch die stetige Weiterentwicklung können sich Abweichungen zum beschriebenen Inhalt ergeben oder zur Obsoleszenz dieser Inhalte führen.

Vergleiche deshalb die Informationen immer mit der aktuellen Befehls-Referenz zum Modul!

== Definition ==
Ein SolarForecast Device wird mit dem Befehl

define <Name> SolarForecast

angelegt. Nach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert. Alle Attribute und Readings die eine Einstellung der Anlage bewirken, sind mit dem Präfix "setup" versehen.

Die Verwendung von setup-Readings gestattet es die Anlagenparameter dynamisch im Betrieb zu verändern. So kann mit

set <Name> setupStringAzimuth bzw.
set <Name> setupStringDeclination

die Ausrichtung und der Neigungswinkel der PV-Module ständig angepasst werden, was zum Beispiel bei einer dem Sonnenstand nachgeführten Anlage von Bedeutung ist.

Die abgefragten Einstellungen während des Dialoges sind ausführlich in den entsprechenden Attributen bzw. Set-Kommandos erläutert. Die benötigten Informationen sind anhängig von der gewählten Prognose-API und können im Umfang variieren.

[[Datei:Screenshot 2024-09-21 213257.png|right|thumb|400px|Anlagenprüfung über Drucktaste in der Kopfgrafik]]

Sobald alle verlangten Einstellungen vorgenommen sind, sollte eine Anlagenprüfung mit

set <Name> plantConfiguration check

oder über die angebotene Drucktaste in der Grafik durchgeführt werden. Es wird eine Plausibilitätsprüfung vorgenommen und das Ergebnis sowie eventuelle Hinweise bzw. Fehler ausgegeben.
Die Prüfung kann beliebig wiederholt werden und sollte sich bei jeder Einstellungsänderung der Anlage durchgeführt werden. Dadurch wird die Wahrscheinlichkeit von fehlerhaften Einstellungen minimiert.

Neben den grundlegenden Einstellungen können im Device weitere sekundäre Anlagenkomponenten wie Batteriesystem(e) (Attribut setupBatteryDev1 - setupBatteryDev3), weitere Wetter-Devices (Attribut setupWeatherDev1 - setupWeatherDev3) oder sonstige Erzeuger (z.B. BHKW, Winderzeugung, Notstromaggregat) integriert werden (Attribut setupOtherProducer01 - setupOtherProducer03).

Die verlangten Parameter der Anlage werden in der Online-Hilfe umfassend beschrieben und deren Funktion erschließt sich zum größten Teil selbst. Dennoch soll nachfolgend auf einige Punkte im Zusammenhang der Einrichtung eingegangen werden.

 
=== Hinweise zur Struktur der Attribute ===

Durch die umfangreichen Funktionen des Moduls würde bei Nutzung der im FHEM herkömmlich vorhandenen Attributstruktur die Anzahl der benötigten Attribute extrem stark steigen und nicht sinnvoll genutzt werden können. Deshalb gibt es neben den ''gewöhnlichen'' Attributen mit einfachen Werteauswahlmöglichkeiten oder Eingaben (z.B. ctrlDebug, ctrlSpecialReadings) sogenannte ''zusammengesetzte'' Attribute, deren Inhalt durch '''Schlüssel=Wert Paare''' gebildet wird und dadurch deutlich mehr Funktionen und Informationen transportieren als ein gewöhnliches Attribut.

Für zusammengesetzte Attribute besteht die zusätzliche Möglichkeit, gewünschte Änderungen der Schlüssel=Wert Paare selektiv vornehmen zu können, ohne das gesamte Attribut aufrufen und ändern zu müssen. Die Vorgang, der vor allem für programmtechnische Manipulationen gedacht ist, kann durch eine Set-Funktion ausgeführt werden:

set <Name> attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

Die Funktionen der Attribute werden durch einen Präfix geclustert und so inhaltlich, aber vor allem auch in der Attribute Drop-Down Liste, strukturiert dargestellt.

Die Bedeutung der '''Präfixe''' sind:

* '''ai''' - Steuerungsfunktionen für KI (z.B. aiControl)
* '''consumer''' - Registrierung und Einstellungen für Verbraucher (z.B. consumer02, consumerControl)
* '''ctrl''' - Steuerungsfunktion allgemeiner Art (z.B. ctrlDebug, ctrlSpecialReadings, ctrlUserExitFn)
* '''flowGraphic''' - Einstellungen für die Energieflußgrafik (z.B. flowGraphicControl)
* '''graphic''' - Einstellung für die Grafik allgemein (z.B. graphicSelect, graphicControl)
* '''graphicBeam''' - Einstellungen bestimmte Balkeneigenschaften in der Balkengrafik (z.B. graphicBeamHeightLevel1)
* '''plant''' - übergreifende Einstellungen betreffend der gesamten PV-Anlage bzw. des SolarForecast-Devices (z.B. plantControl)
* '''setup''' - Registrierung von Geräten in der Gesamtanlage und Einstellung deren Eigenschaften (Inverter, Zähler, Batterien usw.)

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

Mit den Attributen setupInverterDev01 bis setupInverterDevXX werden die vorhandenen Wechselrichter der Anlage registriert.
Das Modul unterscheidet verschiedene Wechselrichter-Typen, die sich durch ihre Arbeitsweise innerhalb der Anlage unterscheiden. Die Schlüssel=Wert Paare in den Attributen können mehrzeilig organisiert werden. Das erleichtert die Übersicht wenn viele dieser Parameter eingegeben werden.

;PV-Wechselrichter: Es ist der Standard Wechselrichter in einer PV-Anlage. An ihn sind die Solarzellen bzw. Strings angeschlossen. Die zugeordneten Strings können mit dem Schlüssel '''strings''' zugeordnet werden. Ohne diese Angabe werden diesem Gerät alle definierten Strings (siehe Attribut ''setupInverterStrings'') zugeordnet. Der Wechselrichter liefert seine Energie in das Hausnetz. Alternativ kann mit der Angabe '''feed=grid''' die Funktion des Wechselrichters geändert werden. Diese Angabe sagt aus, dass dieser Wechselrichter ausschließlich in das öffentliche Netz einspeist.

Hier ein Beispiel-Setup eines PV-Wechselrichters (SMA STP):

STP_5000 pvIn=string_1_pdc:kW pvOut=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100

;Solar-Ladegeräte: Solar-Ladegeräte sind DC-DC Wandler und liefern die Energie der angeschlossenen Solarzellen nicht in das Wechselstromnetz, sondern laden direkt eine Batterie bzw. versorgen einen Batteriewechselrichter auf der Gleichstromseite. Die Funktion als Solar-Ladegerät wird mit '''feed=bat''' aktiviert, die relevanten Strings können ebenfalls mit dem Schlüssel '''strings''' zugeordnet werden. Ein Beispiel eines Solar-Ladegerätes ist ein Victron SmartSolar MPPT.

Ein Beispiel für das Setup eines Solar-Ladegeräts (SmartSolar Charger MPPT):

MQTT2_cerboGX_c0619ab34e08_solarcharger_Common pv=Yield_Power_value:W etotal=Yield_System_value:kWh capacity=2080 strings=Schleppdach feed=bat synchron=0 limit=100

;Batterie-Wechselrichter: Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer Batterie (=Gleichstromquelle) und dem Wechselstrom-Hausnetz. Die Funktion als Batterie-Wechselrichter wird mit der Angabe '''strings=none''' aktiviert. Die Schlüssel ''etotal'' und ''pv'' können bei einem Batterie-Wechselrichter ohne zugeordnete Solarzellen nicht gesetzt werden. Ein Beispiel eines Batterie-Wechselrichter ist der Victron MultiPlus II.

Ein Setup-Beispiel für einen Batterie-Wechselrichter (Victron MultiPlus II):

<pre>
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
icon=inverter@darkorange:inverter@grey
asynchron=0
</pre>

Die Eigenschaften des Wechselrichters werden durch eine Reihe von <Schlüssel=Wert> Paaren festgelegt. Auf einige dieser Paramter soll hier eingegangen werden.

 
==== Ausgewählte Schlüssel=Wert Paare ====

 
* '''pvIn=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvIn'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell zugeführte PV-Leistung bereitstellt. Der Schlüssel ist optional und dient in erster Linie dazu den entsprechenden Input-Wert in der Flußgrafik anzuzeigen sofern man das Attribut flowGraphicControl->showGenerators=1 setzt. Dadurch ist auch der Eigenverbrauch des Inverters bzw. dessen Wandlungsverlust visuell abschätzbar.

* '''pvOut=<Readingname>:<Einheit>'''

Dem Schlüssel ''pvOut'' wird ein Reading und dessen Einheit (W,kW) des Wechselrichter-Device zugeordnet, welches die aktuell erzeugte Leistung als positiven Wert liefert. Für einen PV-Wechselrichter (DC->AC) oder Solar-Ladegerät (DC->DC) ist es die erzeugte PV-Leistung.

* '''ac2dc=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter vom Hausnetz in Richtung Batterie (AC->DC) wandelt.

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)
;graphicBeamHeightLevel1:Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene (hier Ebene 1)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===
Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und, wenn ein Event eines als 'asynchron' definierten Devices auftritt, gesammelt und daraus permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

=== Wie wird die Verbrauchsprognose erstellt? ===

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

==== Debugging der Verbrauchsprognose ====
Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

=== Wie kann eine fehlerhafte Verbrauchsprognose korrigiert werden? ===
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionHistory 07 21

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
PVH_SolarForecast_<name> - PV History
PVC_SolarForecast_<name> - PV Circular
PVCfg_SolarForecast_<name> - PV Anlagenkonfiguration
PVCsm_SolarForecast_<name> - Consumer Status
ScApi_SolarForecast_<name> - Strahlungswerte aus verwendeter API
StatApi_SolarForecast_<name> - Statusdaten der verwendeten API's
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - KI Input Daten = Raw Trainigsdaten
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten 3 Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "pvHistory" restored
2023.10.02 09:57:07.969 3: SolCast6 - cached data "pvCircular" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "consumerMaster" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "radiationApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "statusApiData" restored
2023.10.02 09:57:07.970 3: SolCast6 - cached data "weatherApiData" restored
2023.10.02 09:57:07.974 3: SolCast6 - cached data "aiTrainedData" restored
2023.10.02 09:57:07.976 3: SolCast6 - cached data "aiRawData" restored
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 5. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. starten von FHEM (die Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere zwei Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese beiden Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagement01 lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>]

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten darf. Die Angabe ist optional. (default: 20)

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit.

Alle Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Inhalt 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Inhalt 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

 

===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und folgenden Tag korrigiert. Das bedeutet, dass der Minimum SoC z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Batterie wieder vollständig zu zuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) Victron MPII Verbund
my $actmcc = ReadingsNum ($vebus, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_01', 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Strom b. Battery_ChargeRequest
$load = 21;
}
else {
$load = $maxcspc;
}
}

## Batterie Einstellung MaxChargeCurrent
##########################################
if ($load != $actmcc) {
CommandSet (undef, "$vebus MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vebus set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten.

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 
=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 
=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
== Konfigurationsbeispiele ==

=== Visualisierung solare Vorhersage und reale Erzeugung ===

Zu Beginn jedes neuen Tages gegen 00:00 Uhr werden durch das SolarForecast Device Events für die initiale PV Prognose des kommenden Tages erstellt.
Der Readingteil dieser Events heißt

AllPVforecastsToEvent

Die Uhrzeiten der Events sind so aufbereitet und können direkt geloggt werden um sie in einen SVG Plot zu integrieren.
Im SolarForecast Device ist dieses Reading nicht sichtbar, nur die Events werden erstellt.

Die meteorologischen Bedingungen verändern sich über den Tag permanent. Je nach gewählter Strahlungsdatenquelle (eine API oder DWD Device) erfolgt eine mehr oder weniger dynamische Anpassung der Prognose an die sich verändernde Umwelt.

Aktuelle Prognosedaten sowie die reale PV Erzeugung der vergangenen Stunde können über die Readings

LastHourPVforecast
LastHourPVreal

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.<syntaxhighlight lang="perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[[Datei:Screenshot 2025-08-04 104835.png|mini|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.

Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten verwenden kann:<syntaxhighlight lang="perl">
forecast_json {

use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => '%Y-%m-%d %H:%M:%S',
time_zone => 'Europe/Berlin',
);

# Alle NextHour-Daten durchsuchen
while ($hour < 100) {
my $hour_str = sprintf('NextHour%02d', $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'starttime', 'na');
my $pvfc = FHEM::SolarForecast::NexthoursVal ('sol.forecast_ai', $hour_str, 'pvfc', 'na');

# Schleife beenden, wenn keine Werte mehr vorhanden sind
last if $start_str eq 'na' or $pvfc eq 'na';

# parse und konvertiere Zeit
my $start_dt = $parser->parse_datetime($start_str);
my $end_dt = $start_dt->clone->add(hours => 1);

# nach UTC konvertieren
$start_dt->set_time_zone('UTC');
$end_dt->set_time_zone('UTC');

push @output, {
start => $start_dt->iso8601() . 'Z',
end => $end_dt->iso8601() . 'Z',
value => 0 + $pvfc,
};

$hour++;
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
}
</syntaxhighlight>Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):<syntaxhighlight>
defmod WEBapi FHEMWEB 8089
attr WEBapi csrfToken none
</syntaxhighlight>In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json',<nowiki>''</nowiki>)} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%27%29%7D&XHR=1
</syntaxhighlight>Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]