SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

An dieser Seite wird momentan noch gearbeitet.

Die vorliegende Wiki-Seite befindet sich im Aufbau.

76_SolarForecast
Zweck / Funktion
Solarprognose und Verbrauchersteuerung
Allgemein
Typ	Gerätemodul
Details
Dokumentation	EN / DE Thema
Support (Forum)	Solaranlagen
Modulname	76_SolarForecast.pm
Ersteller	DS_Starter (Forum /Wiki)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

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:

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 bei Verwendung von DWD Stahlungswerten

• 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 3 Invertern 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 3 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.

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.

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).

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.

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 ctrlShowLink 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.

#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis<br>Sunset:special_todayConForecastTillSunset
Verbrauch bis<br>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<br>Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

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

MPII Limit<br>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<br>(1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu

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.

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 "<br>". 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.

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 Wettervohersage 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:

• grundsätzliche Layout Definitionen

Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11

graphicLayoutType

Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik

graphicHourStyle

Format der Zeitangabe in der Balkengrafik

graphicHourCount

Anzahl der darzustellenden Balken/Stunden in der Balkengrafk

graphicEnergyUnit

definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik

graphicHistoryHour

Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden

graphicBeamWidth

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

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)

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

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.

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 gespeichert. 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.

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 ctrlInterval) 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:

      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

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:

...
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
...

Wie wird die Verbrauchsprognose erstellt?

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvHistory wird der Durchschnitt der vergangenen Tage ermittelt und für den kommenden Tag angewendet. Dabei geht per default jeder historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut affectConsForecastIdentWeekdays = 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.

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)

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:

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
...

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":

      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

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 consumption 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 ctrlInterval eingestellt.

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

get ... pvHistory [Tag]

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.

get ... pvCircular 

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.

get ... nextHours

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

get ... radiationApiData

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.

get ... valCurrent

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.

get ... valConsumerMaster [XX]

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 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::]CurrentVal ('<Name>', '<Key>', <default>)
  entspricht der Abfrage mit "get ... valCurrent".

• [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>', '<c>', '<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:

     <Name>     - Name des SolarForecast Devices
     <Day>      - abzufragender Tag (01 - 31)
     <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'
     <c>        - Nummer des Verbrauchers (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

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:

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

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:

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

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 bis dato vorliegende Lade-Enenergiemenge als fortlaufenden Zähler liefert (optional)

• ein Reading welches die bis dato vorliegende Entlade-Enenergiemenge 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 setupBatteryDevXX 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.

Aktivierung des Batterie SOC-Managements

Das integrierte SOC-Management verfolgt das Ziel; insbesondere in den Monaten mit geringerer PV-Erzeugung; den Ladezustand der Batterie(n) zu optmimieren. 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.

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 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)

Alle Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

1. 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.
   
2. 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.
   
   
3. 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.
   
   
4. 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.
   
   
5. Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt.
   
   
6. 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-Überschuss 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 minimalisiert 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 fünfprozentige 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:

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

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut ctrlInterval) 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:

############################################################################
#  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;
}

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-Überschuss vorhanden ist.

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

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-Überschuss 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_ChargeRecommended_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).

Üblicherweise wird die Batterie geladen. sobald PV-Überschuss 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.

Aktivierung und Arbeitsweise

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird durch die Angabe des Schlüssels limit in den setupInverterDevXX Atributen aktiviert. Sie arbeitet wie folgt:

Der resultierende Schwellenwert der Wirkleistungsbegrenzung

der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit 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-Überschuss für eine Ladung auf maxSoC im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading Battery_ChargeRecommended_XX = 0.

Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschussprognose

zzgl. eines Sicherheitspuffers unterschritten, wird Battery_ChargeRecommended_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.

Bei Victron GX Venus kann man das z.B. über den Grid Setpoint steuern, was ich auch noch beschreiben werde.

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 Überschusseinspeisung gelegt wird.

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_ChargeRecommended_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:

1. die Batterie nicht geladen
2. die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuss eingespeist.

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die 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-überschuss des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann. Sollte der Differenz-Grenzwert erreicht sein, wird Battery_ChargeRecommended_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 gesamten installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte werden 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.

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äte für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device welche 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.

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

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 abgeben, 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:

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

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 Überschuß 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 Überschuß 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 Überschuß. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuß.

must

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

Mit notbefore wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuß 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-Überschuß vorliegt. Diese Bedingung wird durch die Angabe von power=1700 bewirkt. Soll der zwangsweise PV Überschuß ignoriert werden, kann power=0 angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuß mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

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

Ü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:

# 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

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:

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"

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:

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 timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
attr Rep.Del.AllPVforecastsToEvent verbose 2

Das angegebene DbLog-Device LogDBShort ist natürlich anzupassen

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 Contrib von DS_Starter dazu nutzen

55_DWD_OpenData.pm

135.7 KB ​

28892

DS_Starter

55_DWD_OpenData: contrib 1.17.5

define DWD DWD_OpenData
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 H568
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 Blintrop   -(state fc_time)
attr DWD verbose 2

InverterDummy

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

SMA_Energymeter

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

BatteryDummy

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

"Berechnungs"-Notify der Werte für Batterie- und InverterDummy

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

SolarForecast

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 consumerAdviceIcon light_light_dim_100@gold
attr Forecast consumerLegend icon_top
attr Forecast consumerLink 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 ctrlGenPVdeviation continuously
attr Forecast ctrlInterval 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\
Überschuß: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_ChargeRecommended_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_ChargeRecommended_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_ChargeRecommended_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRecommended_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

So sollte es dann als Ergebnis aussehen:

Ergebnis nach kompletter Einrichtung

Praxisbeispiele und Lösungsansätze für Steuerungen

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 (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 ctrlInterval) ausgeführt. In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

{ 
  ## 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 Überschußenergie 
  $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");
}

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.

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:

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

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, ein 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.

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

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.

weiterführende Links

• Forenthema "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