FHEMWiki - Benutzerbeiträge [de]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2026-10-11T13:05:20Z

Maista: Weitere vertipper korrigiert

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

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

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

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

::* optionale KI Unterstützung der Prognose des Energieverbrauchs der kommenden Stunden

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

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

::* Sprachensupport EN / DE

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

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

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

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

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

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

::* Einbindung von bis zu 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.

== Rahmenbedingungen und Voraussetzungen ==

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

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

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

define <Name> SolarForecast

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

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

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

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

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

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

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

set <Name> plantConfiguration check

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

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

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

 
=== Hinweise zur Struktur der Attribute ===

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

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

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

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

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

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

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

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

icon=inverter@darkorange:inverter@gray

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

icon=:inverter@gray

(beachte den führenden ':')

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===== Einbindung eines Fronius Symo GEN24 10.0 Plus mit BYD Batterie ohne (virtuellen) Batterie-Wechselrichter =====
Die Implementierung ist komplett auf der Seite [[Solaranlage Komplettbeispiel Fronius BYD]] beschrieben.

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

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

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

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

===== Einbindung eines SMA - Hybrid Sunny Tripower Smart Energy =====
[[Datei:Screenshot 2025-10-05 083530.png|right|thumb|400px|SMAInverter.pm]]

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

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

 
=== Einbindung und Visualisierung von Umweltdaten ===

Im Attribut '''setupEnvironment''' werden ''Schlüssel=Wert'' Paare definiert, die zur Erfassung von Umwelt- und Umfeldfaktoren dienen, die im Kontext des Moduleinsatzes und Prognosen wichtig oder hilfreich sind.

;gridStatus: Eine <Gerät>:<Reading>:<Regex> Kombination für den Verbindungsstatus zum öffentlichen Netz. Der angegebene reguläre Ausdruck muß Boolean 'true' für den Status 'Netz verfügbar/verbunden' ergeben, sonst 'false'.

;outsideTemp: Eine <Gerät>:<Reading> Kombination, die die aktuell gemessene Außentemperatur in °C liefert.

;presence: Eine <Gerät>:<Reading>:<Regex> Kombination, die den Anwesenheitsstatus der Bewohner liefert. Der angegebene reguläre Ausdruck muß Boolean 'true' für den Status 'Anwesenheit' ergeben, sonst 'false'.

;windSpeed: Eine <Gerät>:<Reading> Kombination, die die aktuell gemessene Windgeschwindigkeit in m/s liefert.

Mit dem Attribut und Schlüssel '''graphicControl->headerShowEnv''' können diese Daten im Grafikkopf visualisiert werden. Bestimmte Umweltdaten sind die Prognosefunktionen relevant und werden bei Bedarf aufbereitet und gespeichert. Siehe dazu auch den Abschnitt [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Integration_von_Umwelt-_und_Kontextfaktoren_in_die_Prognose|"Integration von Umwelt- und Kontextfaktoren in die Prognose"]]

'''Erkennung Netzausfall (öffentliches Netz)'''

Mit der Einbindung einer geeigneten <Device>:<Reading> Kombination im Schlüssel ''gridStatus'' erfasst SolarForecast die Verbindung zum öffentlichen Stromnetz. Der Verbindungsstatus des Netzes kann im Grafikkopf mit '''graphicControl->headerShowEnv=gridStatus''' neben weiteren Informationen visualisiert werden. Die Erfassung des aktuellen Netzverbindungsstatus ist eine reine Information für den Anwender.

 

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

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

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

....@<Device-Name>

an den Parameter erreicht werden.

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

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

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

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

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

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

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

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

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

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

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

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

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

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

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

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

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

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

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

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

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

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

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

;graphicControl->beamHeightlevel:Faktor zur Berechnung der Höhenverhältnisse der jeweiligen Ebene (siehe auch diesen [[#Wirkung_von_graphicControl->beamHeightlevel_auf_die_Zonen_(z1_bis_z3)_je_nach_layoutType|Abschnitt]]).
;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== Wirkung von graphicControl->beamHeightlevel auf die Zonen (z1 bis z3) je nach layoutType ====

🎯 '''Grundprinzip''' 

Jede der verfügbaren Ebenen ist in Zonen aufgeteilt. Die Wirkung und der Einsatz der Zonen ist vom verwendeten ''graphicControl->layoutType'' abhängig. 
''graphicControl->beamHeightlevel'' ist ein '''Skalierungsfaktor''', der verwendet wird um für jede Zone die '''resultierende Zonenhöhe (px)''' zu berechnen:

<pre>
𝑝𝑥 = 𝑔𝑟𝑜𝑢𝑛𝑑 + (𝑣𝑎𝑙 / 𝑚𝑎𝑥𝑉𝑎𝑙) ⋅ (𝑏𝑒𝑎𝑚𝐻𝑒𝑖𝑔ℎ𝑡𝑙𝑒𝑣𝑒𝑙 − 𝑔𝑟𝑜𝑢𝑛𝑑)
</pre>

Das bedeutet:
* beamHeightlevel bestimmt die '''maximale mögliche Höhe''', die ein Balken erreichen kann,
* aber die tatsächliche Höhe hängt '''immer''' vom Verhältnis val / maxVal und vom scaleMode ab.

🧩 '''Zonenmodell (z1–z3)''' 

Unabhängig vom layoutType besteht jede Balkenebene (z.Zt. Ebene 1 bis 3) aus Zonen, die übereinander angeordnet sind:

{| class="wikitable"
! Zone !! Bedeutung !! Sichtbare Wirkung
|-
| '''z1''' || Freiraum über dem Balken (Abstand, Zahlen, Icons) || Abstand nach oben
|-
| '''z2''' || Balken mit dem höchsten positiven Wert oder oberer Teil eines Stapels || sichtbarer höherer (primärer) Balken
|-
| '''z3''' || Balken mit dem niedrigeren positiven Wert double/staple oder negativer Bereich (diff) || kleinerer (sekundärer) Balken oder negativer Balken
|}

Die Summe aus z1 + z2 + z3 ergibt die '''Gesamthöhe''', die durch ''beamHeightlevel'' '''skaliert''', aber nicht fest vorgegeben wird.

🧩 '''Wirkung pro layoutType''' 

[[Datei:Zonenskizze.png|right|thumb|400px|Zonenskizze]]
🟦 '''layoutType = single'''

Zonen:
* z1 = Freiraum
* z2 = Balken (beam1)
* z3 = nicht genutzt

Wirkung von ''beamHeightlevel'':
* skaliert die Gesamthöhe von z1 + z2
* z2 wächst proportional zu ''val / maxVal''
* z1 ist der verbleibende Rest
* kleine Werte können bei linearer Skalierung sehr klein werden
* ''scaleMode=log'' macht kleine Werte sichtbar größer

🟩 '''layoutType = double''' 

Zonen:
* z1 = Freiraum
* z2 = größerer Wert (beam1 oder beam2)
* z3 = kleinerer Wert oder Stapelanteil

Wirkung von ''beamHeightlevel'':
* skaliert die Gesamthöhe des Balkenpaares
* z2 und z3 teilen sich die Höhe proportional
* bei großen Wertunterschieden wird z3 sehr dünn
* bei ''scaleMode=staple'' werden beide Werte übereinander gestapelt
* bei ''scaleMode=log'' werden Unterschiede geglättet

🟥 '''layoutType = diff''' 

Zonen:
* z1 = positiver Freiraum
* z2 = positiver Balken (falls diff > 0)
* z3 = negativer Balken (falls diff < 0) Hinweis: technisch existiert auch z4 als Freiraum unterhalb, aber visuell Teil von z3

Wirkung von ''beamHeightlevel'':
* skaliert die Gesamthöhe der diff‑Darstellung
* die Null-Linie wird '''dynamisch verschoben''', abhängig von maxDif/minDif
* dadurch ändern sich die relativen Höhen von z1/z2/z3
* große Ausreißer verschieben die Null-Linie stark
* kleine Werte können optisch verschwinden
* ''scaleMode=log'' kann die Darstellung stabilisieren

⚙️ '''Einfluss des scaleMode''' 

{| class="wikitable"
! scaleMode !! Wirkung auf die Zonen
|-
| '''lin''' || z2/z3 werden proportional zu den Rohwerten skaliert → große Unterschiede sichtbar
|-
| '''log''' || z2/z3 werden logarithmisch gedämpft → kleine Werte werden sichtbarer
|-
| '''staple''' || nur für layoutType=double: z2 und z3 werden übereinander gestapelt
|}

''beamHeightlevel'' wirkt in allen Modi als '''Multiplikator''', der die resultierenden Höhen streckt oder staucht.

 

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

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

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

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

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

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

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

== Bestimmung von Sonnenaufgang und Sonnenuntergang ==

Im Modul werden die Zeiten für den Sonnenaufgang und Sonnenuntergang aus alternativen Quellen verwendet. Es gelten dabei die folgenden Prioritäten.

* sind die lokalen Koordinaten ''latitude, longitude, altitude'' im ''global'' Device gesetzt, erfolgt die Berechnung dieser Daten mit dem Parameter '''HORIZON=-0.833''' (vgl. CommandRef zu [https://fhem.de/commandref_DE.html#SUNRISE_EL SUNRISE_EL]).

* sollten die lokalen Koordinaten nicht gesetzt sein, werden die Angaben aus dem in Attribut ''setupWeatherDev1'' angegebenen Wetter-Device entnommen.

Der Wert ''−0.833°'' entspricht dem international üblichen Standard für die Berechnung von Sonnenauf‑ und untergangszeiten. Er berücksichtigt sowohl die atmosphärische Refraktion als auch den halben Sonnendurchmesser und beschreibt damit den Moment, in dem der obere Sonnenrand scheinbar den Horizont berührt. Viele astronomische Algorithmen und [https://metacpan.org/release/JFORGET/DateTime-Event-Sunrise-0.0505/view/lib/DateTime/Event/Sunrise.pm Bibliotheken] verwenden diesen Wert als Default, weshalb er auch in SolarForecast eingesetzt wird.

 

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

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

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

Mit dem Kommando

"get ... pvHistory [Tag]"

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

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

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

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

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

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

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

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

'''Ausblick (ab V 2.0.0, aktuell in Entwicklung):''' 
Die Verbrauchsprognose kann zukünftig auf '''herkömmliche Weise (Legacy)''' erstellt oder '''durch eine KI''' erstellt werden. Es ist auch eine prozentual einstellbare Kombination aus beiden Ergebnissen möglich. Weiter unten werden beide Varianten beschrieben. Bitte beachten, dass beide Technologien ihre spezifischen Attribute zur Einstellung haben.

Die KI-gestützte Prognose verwendet Langzeitdaten, die sich in einem speziellen Datenspeicher befinden und mit

get <Name> valDecTree aiRawData

eingesehen werden können. Wie lange diese Daten aufbewahrt werden, ist mit dem Attribut

attr <Name> aiControl->aiStorageDuration

einstellbar. Eine Pflege dieser Daten ist mit dem Befehl

set <Name> reset aiData ...

möglich.

 

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===

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

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und ebenfalls bei auftreten von Events eines als 'asynchron' definierten Devices gesammelt. Daraus wird permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

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

bzw.

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

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

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

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

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

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

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

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

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

get <name> pvHistory [<Tag>]

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

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

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

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

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

 

=== Die Legacy-Verbrauchsprognose einstellen ===
==== Wie wird die Legacy-Verbrauchsprognose erstellt? ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

angezeigt.

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

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

 
==== Debugging der Legacy-Verbrauchsprognose ====

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

attr <Name> ctrlDebug consumption_long

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

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

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

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

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

 

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

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

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

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

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

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

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

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

get <Name> pvHistory 07

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

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

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

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

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

set <Name> reset consumptionShort 07 21

 

=== Die KI‑Verbrauchsprognose mit AI::FANN aktivieren und einstellen ===

FANN steht für '''Fast Artificial Neural Network'''.
Es handelt sich um eine sehr schnelle, leichtgewichtige Open‑Source‑Bibliothek zur Erstellung und zum Training künstlicher neuronaler Netze. Ein Manual dieser Library ist [https://fann.sourceforge.net/reference/index.html hier] verfügbar.

* FANN ist die '''technische Grundlage''' der KI‑Verbrauchsprognose.
* ws berechnet aus historischen Verbrauchsdaten ein Modell, das zukünftige Werte vorhersagen kann.
* es ist '''robust, schnell und ressourcenschonend''', ideal für Systeme, die regelmäßig neu trainiert werden müssen.
* FANN arbeitet mit klassischen Feed‑Forward‑Netzen und Backpropagation‑Training – also bewährten, stabilen Methoden.

'''AI::FANN''' ist ein Perl‑Modul, das als Schnittstelle (Binding) zwischen SolarForecast und der FANN‑Bibliothek dient.

* AI::FANN ist die Brücke, über die unser Prognosesystem mit FANN kommuniziert.
* es ermöglicht dem System:
::* Trainingsdaten an FANN zu übergeben
::* ein neuronales Netz zu erzeugen
::* das Training zu steuern
::* das fertige Modell zu speichern und später für Prognosen zu nutzen

==== Voraussetzungen ====

===== Installation der FANN‑Library (Linux) =====

<pre>
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install gcc
sudo apt-get install libfann-dev libfann2
</pre>

RPM‑basierte Systeme:

<pre>
sudo dnf install fann-devel
</pre>

RPM‑basierte Systeme sind Linux‑Distributionen, die das Paketformat RPM (Red Hat Package Manager) verwenden.

Typische RPM‑basierte Linux‑Distributionen:
* Red Hat Enterprise Linux (RHEL)
* CentOS / CentOS Stream
* Fedora
* openSUSE / SUSE Linux Enterprise
* Rocky Linux
* AlmaLinux
* Mageia

===== Installation der FANN‑Library (Windows) =====

* der Installations- bzw. Erstellungsprozess der dll ist [https://fann.sourceforge.net/reference/x26.html hier] beschrieben
* fann.dll in PATH oder FHEM‑Verzeichnis kopieren
* Perl‑Installation muss DLL laden können

 

===== Installation des Perl‑Moduls AI::FANN =====

<pre>
cpan install AI::FANN
</pre>

Auf Debian Linux Systemen kann das Modul auch mit

<pre>
sudo apt-get install libai-fann-perl
</pre>

installiert werden.

Alternativ kann natürlich auch cpanm oder der [https://wiki.fhem.de/wiki/Meta#Der_FHEM_Installer FHEM Installer] verwendet werden.

 

==== Bestandteile der Machine-Learning (ML)‑Pipeline ====

===== Datenaufbereitung =====

Die Datenaufbereitung ist der wichtigste Schritt jeder ML‑Pipeline, da sie die Qualität der Eingabedaten sicherstellt.
Schlechte oder unskalierte Daten führen fast immer zu schlechten Modellen.

* '''Normalisierung / Skalierung'''
:- ML‑Modelle benötigen Eingabewerte in vergleichbaren Größenordnungen.
:- Beispiel: PV‑Leistung (0–10 000 W) vs. Uhrzeit (0–23).
:- Ohne Normalisierung würden große Werte die kleinen dominieren.

* '''Feature‑Engineering'''
: Aus Rohdaten werden zusätzliche Merkmale erzeugt, die Muster besser sichtbar machen:
::- Lags: Verbrauch der letzten Minuten/Stunden
::- Deltas: Änderungen gegenüber vorherigen Zeitpunkten
::- Zeitmerkmale: Stunde, Wochentag, Feiertag
::- PV‑Prognosen: erwartete Erzeugung als Einflussfaktor
::- Saisonale Merkmale: Sommer/Winter, Temperatur
::- Semantik (Erstellung von Interaktionen)
::- Rolling‑Statistics

📊 ''Rolling‑Statistics'' 
„Rolling“ bedeutet, dass die Kennzahlen nicht einmalig über den gesamten Datensatz berechnet werden, sondern gleitend über ein Zeitfenster (z. B. 24 h, 7 Tage, 100 Samples). So werden Trends, Drift, Modellverschlechterung oder saisonale Muster besser erkannt.

* '''Integration zusätzlicher Verbraucher'''
: Wärmepumpen oder E‑Autos erzeugen starke, unregelmäßige Peaks.
: Diese können als zusätzliche Features einfließen.

'''Es wird umgesetzt:'''
* ✔ Normalisierung auf physikalische Grenzen (PV‑Maximalleistung, Hausverbrauchs‑Maxima)
* ✔ Feature‑Engineering wie Lags, Deltas, Rolling‑Statistics, Zeitmerkmale, PV/PV-Prognosen als Input und weitere Semantik
* ✔ Optionale Zusatzlasten (WP/EV)

===== Trainingsdaten‑Split =====

Der Split trennt Daten in Trainingsdaten (zum Lernen) und Validierungsdaten (zur Qualitätskontrolle).

* '''Training'''
: Das Modell lernt Muster aus historischen Daten.

* '''Validierung'''
: Das Modell wird auf Daten getestet, die es nicht gesehen hat.
: Dadurch erkennt man Overfitting.

* '''Shuffling'''
: Durchmischen der Daten, um Reihenfolgeeffekte zu vermeiden.
: Besonders wichtig bei Zeitreihen.

'''Es wird umgesetzt:'''
* ✔ Training/Validierung‑Split
* ✔ Shuffling je nach Einstellung von aiControl->aiConShuffleMode
* ✔ Shuffle‑Perioden während des Trainings

===== Netzarchitektur =====

Die Architektur bestimmt, wie das neuronale Netz aufgebaut ist.

* '''Inputs'''
: Anzahl der Merkmale (Features), die das Modell erhält.

* '''Hidden Layers'''
: Anzahl und Größe der verdeckten Schichten bestimmen, wie komplexe Muster erkannt werden können.

* '''Output Layer'''
: bei SolarForecast: 1 Wert = Verbrauchsprognose (Wh).

'''Es wird umgesetzt:'''
* ✔ Dynamische Input‑Anzahl je nach aktivierten Features
* ✔ Konfigurierbare Hidden Layers (z. B. 80‑40‑20)
* ✔ 1 Output‑Neuron
* ✔ Konfigurierbare Aktivierungsfunktionen

===== Training =====

Hier werden die Gewichte des Netzes angepasst, um Fehler zu minimieren.

* '''Trainingsalgorithmus'''
: RPROP: stabil, robust
: INCREMENTAL: schneller, aber empfindlicher

* '''Lernrate (Learning Rate)'''
: Wie stark Gewichte pro Schritt angepasst werden.

* '''Momentum'''
: Glättet die Lernbewegung, verhindert Zickzack‑Verhalten.

* '''Steepness'''
: Steuert die Empfindlichkeit der Aktivierungsfunktion.

* '''Shuffle‑Perioden'''
: Wie oft die Trainingsdaten neu gemischt werden.

* '''Early‑Stopping'''
: Training wird beendet, wenn Validierungsfehler nicht mehr sinkt.

'''Es wird umgesetzt:'''
* ✔ RPROP und INCREMENTAL
* ✔ Learning Rate, Momentum, Steepness konfigurierbar
* ✔ Shuffle‑Perioden
* ✔ Early‑Stopping über Validierungsfehler
* ✔ Mehrere Trainingsläufe (Runs) zur Modellselektion

===== Modellselektion und Fehlerevaluierung =====

Hier wird entschieden, welches Modell am Ende verwendet wird.
Die Ergebnisse des Trainings werden während des Traininglaufs fortlaufend überwacht und die Einhaltung von intern vorgegebenen Kennzahlen von einem Retrain-Guard überprüft.

'''Evaluation'''
* MAE, MAPE, RMSE, R²
* BitFail
* Bias/Slope
* P95/P99

📈 ''Fehlermaße: MAE, MAPE, RMSE, R²'' 
* '''MAE''' – Mean Absolute Error (durchschnittlicher absoluter Fehler)
::: MAE=1/𝑛∑∣𝑦−𝑦^∣
* '''MAPE''' – Mean Absolute Percentage Error (prozentualer Fehler)
::: MAPE=100/𝑛∑∣(𝑦−𝑦^)/𝑦∣
::* Achtung: '''problematisch bei kleinen oder Null‑Werten''' (klassisch bei Verbrauchsdaten nachts).
* '''RMSE''' – Root Mean Squared Error (Quadratischer Fehler, stärker empfindlich für Ausreißer)
::* gut, wenn große Fehler besonders kritisch sind
* '''R²''' – Bestimmtheitsmaß (Anteil der Varianz, den das Modell erklärt)
::: 𝑅2=1−(SSE/SST)
::* 1.0 = perfekt, 0 = nicht besser als Mittelwert, <0 = schlechter als Mittelwert
* '''P95 / P99''' (Quantile) - Quantile beschreiben, wie groß der Fehler in den schlechtesten X % der Fälle ist.
::* '''P95:''' 95 % der Fehler liegen darunter → die schlechtesten 5 % sind größer
::* '''P99:''' 99 % der Fehler liegen darunter → zeigt Extremfehler
* '''Bias / Slope''' (Regression‑Diagnostik) - Diese beiden Werte stammen aus einer linearen Regression zwischen '''Vorhersage''' und '''Ist‑Wert'''.
::* Diese beiden Werte sind extrem hilfreich, um Modell‑Drift oder fehlerhafte Normalisierung zu erkennen.
::* Slope - Ideal: 1.0
:::* < 1 → Modell unterschätzt hohe Werte
:::* >= 1 → Modell überschätzt hohe Werte
:::* zeigt systematische Skalierungsfehler
::* Bias - Ideal: 0
:::* positiv → Modell sagt im Schnitt zu wenig vorher
:::* negativ → Modell sagt im Schnitt zu viel vorher
:::* zeigt systematische Verschiebung
* '''BitFail'''
::* FANN verwendet „BitFail“ als Zählwert, wie viele Ausgaben eines Samples „falsch“ sind. Ein Output gilt als falsch, wenn der Fehler größer ist als ein definierter BitFail‑Schwellwert (z. B. 0.35).
::* Bei Regressionen ist BitFail weniger aussagekräftig, aber:
:::- es zeigt, wie viele Samples „deutlich daneben“ liegen.
:::- gut zur schnellen Qualitätskontrolle während des Trainings.

Wird die geforderte Güte nicht erreicht, initiiert der Guard eine Wiederholung des Trainings bis zu einer maximalen Anzahl von Durchläufen.

* '''Bestes Modell speichern'''
: Das Modell mit dem niedrigsten Validierungsfehler wird ausgewählt.

* '''Verwendung nur des besten Modells'''
: Schlechtere Modelle werden verworfen.

* '''Trainingsmodus ohne Prognose'''
: Nützlich, wenn man nur trainieren, aber noch nicht prognostizieren möchte.
: einschalten mit aiControl ->aiConActivate=2

'''Es wird umgesetzt:'''
* ✔ Monitoring mit Fehlerevaluierung
* ✔ bestes Modell wird automatisch gespeichert
* ✔ Prognosen basieren ausschließlich auf dem besten Modell
* ✔ Trainingsmodus only möglich (aiConActivate=2)
* ✔ Ausgabe detaillierter Trainingsmetriken

 

==== Einstellbare Parameter über 'attr <Name> aiControl' ====

Die Einstellung von '''aiConActivate''', '''aiConAlpha''' und '''aiConTrainStart''' wirken sofort, alle anderen Parameter werden erst beim nächsten Trainingslauf wirksam.

'''aiConActivate'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0 || KI deaktiviert
|-
| 1 || KI aktiviert (Standard)
|-
| 2 || Trainingsmodus aktiv, die KI-Prognose ist deaktiviert. Es wird maximal eine Trainingswiederholung ausgeführt.
|}

'''Best‑Practice:''' 
* 1 ab 2000–3000 verfügbaren Datensätzen (siehe get <Name> valDecTree aiRawData), bei WP/EV > 5000
* Der Trainingsmodus dient dazu verschiedene Einstellungen testen zu können. Zur Zeitersparnis wird maximal eine Trainingswiederholung ausgeführt, unabhängig von der Güte des Trainingsergebisses

'''aiConAlpha'''

Mit diesem Parameter kann ein Hybridergebnis aus klassischen (Legacy‑)Prognosen und durch die KI ermittelten Prognosewerten erzeugt werden. Das Hybridergebnis wird durch eine prozentuale Mischung beider Resultate erstellt.

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0 || die KI-Ergebnisse werden nicht verwendet, nur Legacy Werte gehen in das finale Ergebnis ein
|-
| 0.x || die KI-Ergebnisse gehen zu 0.x * 100%, die Legacy Werte zu (1-0.x) * 100% in die finale Prognose ein
|-
| 1 || es werden ausschließlich KI-Ergebnisse verwendet, Legacy Werte gehen nicht in das finale Ergebnis ein
|}

'''Best‑Practice:''' 
* 1 wenn die Genauigkeit der KI-Prognose überzeugend ist, ansonsten kann ein Mix aus KI und Legacy-Prognose hergestellt werden

'''aiConTrainStart'''

Legt fest, wann das Modul ein atomatisches Erst- bzw. Folgetraining durchführt. Im Standard erfolgt das Training alle 7 Tage.

Format: `<Tage>:<Stunde>`, z. B. `7:3`.

'''Best‑Practice:''' 
* 7–14 Tage für normale Haushalte
* 3–5 Tage bei WP/EV

'''aiConActFunc'''

{| class="wikitable"
! Funktion !! Eigenschaften
|-
| SIGMOID || + bewährt, stabil, gut für kontinuierliche, monotone Zusammenhänge
– kann bei großen Inputs saturieren, aber bei Verbrauchsprognose meistens gut
|-
| GAUSSIAN || + gut für glatte Muster
– schlecht für harte Peaks (EV, Trockner), kann „vergessen“ und saturieren
|-
| ELLIOT || + schnellere, numerisch robustere Approximation von Sigmoid/Tanh, weniger Rechenaufwand
+ oft etwas „härter“ in der Reaktion, kann Peaks besser durchreichen 
– immer noch S‑förmig, also keine Wunderwaffe gegen komplett unmodellierte EV‑Ereignisse
|}

'''Best‑Practice:''' 
* SIGMOID oder SIGMOID_SYMMETRIC als Standard
* bei allen weiteren Aktivierungsfunktionen kommt es auf den Versuch an

'''aiConHiddenLayers'''

{| class="wikitable"
! Typ !! Beispiel !! Eigenschaften
|-
| klein || 50‑25 || schnell, weniger genau
|-
| mittel || 64‑32 || guter Kompromiss
|-
| tief || 64‑32‑16 / 80‑40‑20 || erkennt komplexe Muster
|}

'''Best‑Practice:''' 
* < 3000 verfügbaren Datensätzen → `50-25`
* 3000–8000 verfügbaren Datensätzen → `64-32`
* > 8000 verfügbaren Datensätzen oder WP/EV → `80-40-20`

'''aiConLearnRate'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0.001 || sehr stabil, langsam
|-
| 0.005 || guter Kompromiss
|-
| 0.01–0.05 || schnell, aber instabil
|}

'''Best‑Practice:''' 
* 0.005, bei WP/EV 0.001

'''aiConBitFailLimit'''

Das Bit‑Fail‑Limit bestimmt, '''ab welcher Abweichung zwischen Prognose und echtem Wert''' ein Trainingspunkt als „Fehler“ gezählt wird.
Ein kleinerer Wert macht das Training '''strenger''', ein größerer Wert macht es '''toleranter'''.

* '''kleineres Limit → Modell versucht Peaks stärker zu treffen''' → kann instabil werden, besonders mit INCREMENTAL
* '''größeres Limit → Modell glättet stärker''' → robuster, aber weniger peak‑sensitiv

{| class="wikitable"
! Wert !! Bedeutung
|-
| kleineres Limit (0.10–0.25) || Das Modell versucht Peaks und schnelle Änderungen genauer zu treffen, kann aber instabiler werden.
|-
| mittleres Limit (0.25–0.35) || Gute Balance zwischen Genauigkeit und Stabilität. Empfohlener Startbereich.
|-
| größeres Limit (0.35–0.50) || Das Modell wird robuster gegen Ausreißer und Rauschen, reagiert aber weniger stark auf Spitzenlasten.
|}

🌪️ '''Was bedeutet „verrauschter Haushalt“?''' 
Ein Haushalt gilt als „verrauscht“, wenn der Stromverbrauch viele kleine, unregelmäßige Schwankungen hat, die nicht durch klare Muster (z. B. PV, Wärmepumpe, feste Tagesabläufe) erklärbar sind.
Dazu gehören spontane Gerätewechsel, impulsartige Lasten oder allgemein unruhige Verbrauchsprofile.

Für solche Haushalte ist ein höheres Bit‑Fail‑Limit sinnvoll, weil das Modell dadurch robuster wird und nicht versucht, jede kleine Zufallsschwankung exakt vorherzusagen.

'''Best‑Practice:''' 
* versuche deinen Haushalt gemäß der oben beschriebenen Rauscheigenschaft einzuordnen und entscheide dann, ob ein Training unterhalb oder oberhalb des Defaultwertes (0.35) bei dir sinnvoll sein könnte. Bleibe dann bei der Einstellung die bei dir die besten Ergebnisse liefert.

'''aiConMomentum'''

{| class="wikitable"
! Bereich !! Bedeutung
|-
| 0.2 || reagiert direkt, schwankt stärker
|-
| 0.5–0.8 || stabil, guter Kompromiss
|-
| 0.9 || sehr stark geglättet
|}

'''Best‑Practice:''' 
* 0.5, bei WP/EV 0.7–0.8

'''aiConShuffleMode'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0 || chronologisch
|-
| 1 || chronologischer Split + Shuffle
|-
| 2 || vollständiges Shuffle
|}

'''Best‑Practice:''' 
* 2, bei saisonalen Mustern 1

'''aiConShufflePeriod'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 10 || viel Variation
|-
| 15–20 || stabiler Kompromiss
|-
| >20 || Gefahr von Overfitting
|}

'''Best‑Practice:''' 
* 10, bei großen Datensätzen 15–20

'''aiConSteepness'''

{| class="wikitable"
! Bereich !! Bedeutung
|-
| <0.4 || starke Glättung
|-
| 0.5 || Standard
|-
| >0.7 || schärfere Muster
|}

'''Best‑Practice:''' 
* 0.9, bei glattem Verbrauch 0.5

'''aiConTrainAlgo'''

{| class="wikitable"
! Algorithmus !! Eigenschaften
|-
| RPROP || stabil, wenig Parameter
|-
| INCREMENTAL || schneller, empfindlicher
|}

'''Best‑Practice:''' 
* RPROP bei WP/EV
* INCREMENTAL bei einfachen Profilen

'''aiConProfile'''

Die folgenden Profile bestimmen, welche Verbrauchslogiken und Semantiken im Modell aktiviert werden. Sie beeinflussen, wie stark das Modell auf typische Haushaltsaktivitäten, PV‑Erzeugung und Wärmepumpenverhalten reagiert.

Damit Nutzer das passende Profil wählen können, sind die Profile hier verständlich beschrieben.

{| class="wikitable"
! Profil !! Eigenschaften
|-
| v1_common || Dieses Profil bildet den typischen menschlichen Tagesrhythmus ab:
* Morgenaktivität (Aufstehen, Geräte an)
* Mittagsaktivität (Kochen, Haushalt)
* Abendaktivität (Kochen, Licht, Geräte)
* Später Abend (Geräte gehen aus)
* Wochenendverhalten
* Tagesmuster vom Vortag
* Grundlast nachts

Es nutzt Zeitstruktur, saisonale Muster, Wetter und Verbrauchsdynamik — aber '''keine PV‑ oder Wärmepumpenlogik'''. 
'''Empfohlen für:'''
Haushalte mit reinem Stromverbrauch ohne besondere Geräte und wenig PV Einfluß, z.B. mit kleiner Balkon PV-Anlage.

|-
| v1_common_active || Für '''Haushalte mit stark ausgeprägten Aktivitätsmustern''' 
Wie ''v1_common'', aber mit stärkerer Betonung auf:
* Verbrauchssprüngen
* Trendbrüchen
* Volatilität (z. B. Kochen, Gerätewechsel)
* Wiederkehrenden Peaks

Dieses Profil reagiert sensibler auf '''kurzfristige Verbrauchsdynamik'''. 
'''Empfohlen für:'''
Haushalte mit unregelmäßigen oder dynamischen Verbrauchsprofilen (z.B. viele Geräte, Homeoffice, Familien).

|-
| v1_common_pv || Für '''Haushalte mit PV-getriebenen Verbrauchern''' 
Erweitert ''v1_common'' um PV‑Semantik:
* PV‑Erzeugung + Tageszeit
* PV‑Drop‑Erkennung (Wolke → Lastabfall)
* PV‑abhängige Verbrauchsverschiebung
* PV‑Mittagsspitzen‑Verstärker
* PV‑Temperatur‑Interaktionen (Heizung, Batterie, Geräteverhalten)

Das Modell versteht, dass Haushalte '''mittags anders verbrauchen''', wenn PV‑Strom verfügbar ist. 
'''Empfohlen für:'''
Haushalte mit größerer PV‑Anlage, aber ohne Wärmepumpe.

|-
| v1_common_active_pv || Für '''Haushalte mit dynamisch PV-getriebenen Verbrauchsverhalten''' 
Kombiniert:
* Dynamik‑Semantik aus v1_common_active
* PV‑Semantik aus v1_common_pv

Dieses Profil erkennt:
* spontane Peaks bei PV‑Überschuss
* Verbrauchssprünge + PV‑Erzeugung
* Trendverstärker mittags
* PV‑Drop‑Reaktionen
* Volatilität + PV‑Interaktionen

'''Empfohlen für:'''
PV‑Haushalte mit aktiven Verbrauchern (z.B. Kochen, Waschmaschine, Trockner usw.).

|-
| v1_heatpump || Für '''Haushalte mit Wärmepumpe (ohne dominante PV)''' 
Aktiviert die komplette Wärmepumpen‑Semantik:
* Heizmodus, Kühlmodus
* Warmwasser (morgens/abends, Zyklen, Kaltstart)
* Frostschutz
* Temperaturtrends
* Effizienzindikatoren (COP‑Proxy)
* Heiz‑/Kühlbedarf
* Temperaturdeltas und -historie

Das Modell versteht typische WP‑Verbrauchsmuster:
* morgens und abends Heizen
* Warmwasserzyklen
* Frostschutz nachts
* Reaktion auf Temperaturstürze

'''Empfohlen für:'''
Haushalte mit Wärmepumpe, aber ohne dominante PV.

|-
| v1_heatpump_pv || Für '''Wärmepumpen‑Haushalte mit dominanter PV''' 
Kombiniert:
* Wärmepumpen‑Semantik
* PV‑Semantik
* PV‑Warmwasser‑Boost
* PV‑Mittagsverschiebung
* PV‑abhängige Heiz-/WW‑Strategien
* Das Modell erkennt:
* PV‑Überschuss → Warmwasser
* PV‑Erzeugung → Heiz-/Kühlverhalten
* PV‑Drop → Lastabfall
* PV + Kälte → Heizspitzen

'''Empfohlen für:'''
Haushalte mit Wärmepumpe und dominanter PV‑Anlage.

|-
| v1_heatpump_active_pv || Für '''Wärmepumpe + PV + dynamisches Verbrauchsverhalten''' 
Das umfassendste Profil. Es kombiniert:
* Wärmepumpen‑Semantik
* PV‑Semantik
* Dynamik‑Semantik (Trend, Volatilität, Peaks)
* Spezial‑Booster (z. B. heatpump_boost_special, pv_mittag_peak_boost_special)

Dieses Profil erkennt:
* spontane Verbrauchssprünge
* WP‑Zyklen + PV‑Überschuss
* Trendbrüche + Temperaturdeltas
* dynamische Mittagspeaks
* komplexe Interaktionen zwischen PV, WP und menschlichem Verhalten

'''Empfohlen für:'''
Haushalte mit Wärmepumpe, PV und sehr aktivem Verbrauchsverhalten.

|-
| ||
|}

'''Best‑Practice:''' 
Die oben angegebenen Profileigenschaften beschreiben die implementierten Verstärkungen bzw. auch Abschwächungen zur Unterstützung des Lernprozesses der künstlichen Intelligenz. Teste Trainings mit unterschiedlichen Profilen und wähle das Profil mit dem die besten Ergebnisse erzielt werden. Beginne mit dem Profil welches wahrscheinlich am Besten zu deinem Haushalt passen könnte.

 

==== Integration von Umwelt- und Kontextfaktoren in die Prognose ====

Die Verbrauchscharakteristik eines Haushalts wird nicht nur durch die eingesetzten elektrischen Geräte bestimmt, sondern auch durch verschiedene systemische Einflussfaktoren, darunter:

* Anwesenheit bzw. Abwesenheit der Bewohner
* Außentemperaturen
* Abweichungen vom üblichen Tagesmuster, z.B. durch Feiertage oder Urlaubszeiten

'''Einbindung von Sensoren und Kontextdaten'''

Außentemperatursensoren, Windsensoren sowie Geräte zur Anwesenheits- oder Bewegungsdetektion werden im Attribut '''setupEnvironment''' hinterlegt. Die dafür erforderliche Syntax ist in der Online‑Hilfe des Moduls dokumentiert. SolarForecast nutzt diese Informationen, um Verbrauchsprognosen an reale Rahmenbedingungen anzupassen.

Die erfassten Umweltdaten sind Momentanwerte, die – sofern sie eine ausreichende Dynamik aufweisen – auf das in SolarForecast verwendete Stundenraster normiert oder geglättet werden.

::* '''Außentemperaturen:''' Temperaturen ändern sich vergleichsweise langsam und werden daher direkt übernommen. Ist kein Temperatursensor definiert, wird die Temperatur des verwendeten Wetterdienstes genutzt.
::* '''Anwesenheit:''' Für jede Stunde wird der Anwesenheitsstatus anhand des überwiegenden Zustands innerhalb dieser Stunde bestimmt.
::::- '''Beispiel:''' Verlassen die Bewohner das Haus erst zehn Minuten vor Ende der Stunde, würde eine reine Momentaufnahme den Status ''„abwesend“'' speichern. Da dies sachlich nicht zutrifft, wird der überwiegende Status der Stunde bewertet und gespeichert.
::* '''Windgeschwindigkeit:''' Zur Bewertung der Windverhältnisse werden zwei geglättete Windgeschwindigkeiten berechnet - eine '''schnelle''' und eine '''langsame''' Komponente. Beide verwenden '''exponentielles Glätten''', bei dem neue Messwerte stärker gewichtet werden als ältere.
:::: - '''Fast (10 Minuten):''' Reagiert schnell auf kurzfristige Änderungen, z. B. durch vorbeiziehende Wolken.
:::: - '''Slow (40 Minuten):''' Spiegelt die Großwetterlage bzw. den längerfristigen Trend wider.
:::: Die Glättung erfolgt nach dem Prinzip:
:::::: <code> neuer Wert = α · aktueller Messwert + (1 − α) · vorheriger geglätteter Wert </code>
:::: wobei <code>α</code> abhängig von der jeweiligen Zeitkonstante berechnet wird.

'''Feiertage und Urlaubszeiten'''

Für die Berücksichtigung von Feiertagen und Urlaub wird das in FHEM etablierte Verfahren über [https://fhem.de/commandref_DE.html#holiday holiday]-Devices verwendet.
Dazu werden die entsprechenden holiday‑Devices im globalen Attribut ''holiday2we'' registriert. SolarForecast liest die dort eingetragenen holiday‑Devices aus und übernimmt die darin definierten Daten (z.B. gesetzliche Feiertage, benutzerdefinierte freie Tage oder Urlaubszeiträume).

 

==== Das Training durchführen und produktiv setzen (Best Practice Ansatz) ====

Sind alle [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Voraussetzungen|Voraussetzungen]] erfüllt, kann das Verbauchsprognose-Modell trainiert und – sofern das Ergebnis überzeugt – für den Produktivbetrieb aktiviert werden.

1️⃣ '''Training‑Only‑Modus aktivieren'''

Für das initiale Training wird FANN im ''Training‑Only‑Modus'' aktiviert:

attr <Name> aiControl aiConActivate=2

In diesem Modus kann das Modell beliebig oft trainiert, bewertet und durch Anpassung der [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Einstellbare_Parameter_über_'attr_<Name>_aiControl|Steuerungsparameter]] optimiert werden – ohne dass die produktive Prognose beeinflusst wird. Es kann jederzeit ein neues Training gestartet werden.

Wer den Trainingsablauf und die internen Prüfungen live verfolgen möchte, aktiviert zusätzlich:

attr <Name> ctrlDebug aiProcess

2️⃣ '''Training starten'''

Mit der FANN-Aktivierung durch aiControl aiConActivate=2 (oder 1) werden automatisch sinnvolle '''Standardparameter''' für FANN gesetzt. Für den Einstieg empfiehlt es sich, zunächst mit diesen Defaults zu trainieren und Änderungen an Parametern schrittweise vorzunehmen, neu zu trainieren und die Veränderungen im Ergebnis zu bewerten. Als Hilfestellung gibt es dazu einen separaten [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Auswertung_der_Trainingskennwerte|Abschnitt]].

Das Training wird manuell gestartet mit:

set <Name> aiDecTree runConTrain

'''Hinweis:''' Ein bereits laufendes Training wird durch einen erneuten Start mit ''runConTrain'' automatisch abgebrochen.

Ein laufendes Training kann jederzeit manuell beendet werden:

set <Name> aiDecTree stopConTrain

3️⃣ '''Wie das Training intern abläuft'''

Der Trainingsprozess wird vollständig durch die interne Steuerungslogik des Moduls geführt:

* Ein Trainingsjob umfasst '''bis zu 6 Trainingswiederholungen''', jede mit '''maximal 15000''' Epochen.
* Ein '''Snapshot‑Guard''' überwacht kontinuierlich die Modellverbesserung und speichert bessere Modelle als Best Snapshot.
* Ein integrierter '''Early‑Stopping‑Mechanismus''' beendet Trainingsläufe, die sich nicht weiter verbessern.
* Ein interner '''Retrain‑Indikator''' bewertet den besten Snapshot. Ein '''Quality Gate''' entscheidet, ob ein weiterer Retrain durchgeführt wird.
* Die Anzahl der Retrains wird '''adaptiv''' anhand interner Kriterien bestimmt.
* Mit aktiviertem Debug‑Modus werden alle Entscheidungen im Log dokumentiert.

Der gesamte Prozess läuft in einem '''Nebenprozess''', um FHEM nicht zu blockieren.
Je nach Hardware, Datenmenge und Parametern kann das Training sehr lange dauern – im Extremfall mehrere Stunden. Ein CPU‑Kern kann dabei dauerhaft zu 100 % ausgelastet sein.

4️⃣ '''Ergebnis bewerten'''

Nach Abschluss des Trainings sollte das Ergebnis '''[[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Auswertung_der_Trainingskennwerte|manuell bewertet]]''' werden.

'''Wichtige Hinweise:''' 
* Auch bei '''nicht perfekten Kennzahlen''' lohnt sich eine visuelle Prüfung.
* Auch bei '''zu perfekten Kennzahlen''' ist Vorsicht geboten – dies kann auf Overfitting hindeuten.

5️⃣ '''Modell produktiv setzen'''

Zur visuellen Begutachtung und für den Produktivbetrieb wird das trainierte Modell aktiviert:

attr <Name> aiControl aiConActivate=1

Im nächsten Zyklus des Moduls (siehe 'attr ... plantControl cycleInterval') erscheinen die KI‑Prognosen in der Balkengrafik, sofern diese Ansicht aktiviert ist. Wenn die Prognose zufriedenstellend ist, bleibt das Modell aktiv. Falls nicht, kann jederzeit wieder in den ''Training‑Only''‑Modus gewechselt werden, um Parameter anzupassen und erneut zu trainieren.

6️⃣ '''Automatisches (Re)Training'''

Bei aktivem FANN‑Modus (aiConActivate=1 oder 2) wird automatisch alle '''7 Tage um 03:00 Uhr''' ein Retraining durchgeführt.
Der Zeitpunkt kann angepasst werden:

attr <Name> aiControl aiConTrainStart ...

7️⃣ '''Hybrid‑Modus'''

Das Modul unterstützt einen '''Hybrid‑Modus''', bei dem KI‑Prognosen mit den klassischen (Legacy‑)Prognosen gewichtet kombiniert werden.
Gesteuert wird dieser Modus über:

attr <Name> aiControl aiConAlpha <Wert>

Ein höherer Wert von [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Einstellbare_Parameter_über_'attr_<Name>_aiControl'|'''aiConAlpha''']] bedeutet stärkere Gewichtung der KI‑Prognose.

8️⃣ '''Debug‑Log'''

Für eine detaillierte Nachvollziehbarkeit des Trainingsprozesses kann der Debug‑Modus aktiviert werden.
Im Debug‑Log protokolliert das Modul sämtliche Schritte der Trainingslogik, darunter:

* Start und Ende einzelner Trainingsläufe
* Verbesserungen der Modellgüte
* Snapshot‑Updates
* Early‑Stopping‑Ereignisse
* Entscheidungen des Quality Gates
* Auslösung von Retrains
* Abschlussbewertung des besten Modells

Dies erleichtert sowohl die Diagnose ungewöhnlicher Trainingsverläufe als auch die Bewertung, ob Parameteranpassungen sinnvoll sind.

<div class="mw-collapsible mw-collapsed">
Ein '''auszugsweises Beispiel''' eines Trainingslogs -> <div class="mw-collapsible-content">
<pre>
2026.01.01 15:40:06.690 1: SolCast DEBUG> First attempt 0 with Seed=407496
2026.01.01 15:40:06.696 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7931,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.5,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=6344, Test=1586),
Data shuffle=2 (period=10)
2026.01.01 15:40:06.818 1: SolCast DEBUG> Epoche 1: Train MSE=0.001532, Val MSE=0.002521, Val MAE=0.028206, Val MedAE=0.020769, Bit_Fail=5 -> Snap saved (bit improved)
2026.01.01 15:40:07.534 1: SolCast DEBUG> Epoche 8: Train MSE=0.001472, Val MSE=0.002520, Val MAE=0.028199, Val MedAE=0.020764, Bit_Fail=5 -> Snap saved (metric improved)
2026.01.01 15:40:13.541 1: SolCast DEBUG> Epoche 67: Train MSE=0.001477, Val MSE=0.002518, Val MAE=0.026941, Val MedAE=0.018749, Bit_Fail=5 -> Snap saved (metric improved)
2026.01.01 15:40:13.748 1: SolCast DEBUG> Epoche 69: Train MSE=0.001476, Val MSE=0.002517, Val MAE=0.026928, Val MedAE=0.018728, Bit_Fail=5 -> Snap saved (metric improved)
...
2026.01.01 15:40:21.048 1: SolCast DEBUG> Epoche 140: Train MSE=0.001181, Val MSE=0.002253, Val MAE=0.023585, Val MedAE=0.012176, Bit_Fail=5 -> Snap saved (metric improved)
2026.01.01 15:40:27.191 1: SolCast DEBUG> Epoche 200: Train MSE=0.001181, Val MSE=0.001860, Val MAE=0.022984, Val MedAE=0.012926, Bit_Fail=4
2026.01.01 15:40:27.704 1: SolCast DEBUG> Epoche 205: Train MSE=0.000982, Val MSE=0.001821, Val MAE=0.022794, Val MedAE=0.012760, Bit_Fail=4 -> Snap saved (bit improved)
2026.01.01 15:40:29.356 1: SolCast DEBUG> Epoche 221: Train MSE=0.000894, Val MSE=0.001654, Val MAE=0.021991, Val MedAE=0.012736, Bit_Fail=4 -> Snap saved (metric improved)
...
2026.01.01 15:40:30.508 1: SolCast DEBUG> Epoche 232: Train MSE=0.000806, Val MSE=0.001516, Val MAE=0.020531, Val MedAE=0.011495, Bit_Fail=4 -> Snap saved (metric improved)
2026.01.01 15:40:30.615 1: SolCast DEBUG> Epoche 233: Train MSE=0.000797, Val MSE=0.001498, Val MAE=0.020435, Val MedAE=0.011480, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 15:40:30.722 1: SolCast DEBUG> Epoche 234: Train MSE=0.000787, Val MSE=0.001479, Val MAE=0.020336, Val MedAE=0.011380, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 15:40:30.829 1: SolCast DEBUG> Epoche 235: Train MSE=0.000777, Val MSE=0.001460, Val MAE=0.020232, Val MedAE=0.011321, Bit_Fail=2 -> Snap saved (metric improved)
...
2026.01.01 15:40:34.103 1: SolCast DEBUG> Epoche 266: Train MSE=0.000347, Val MSE=0.000621, Val MAE=0.015564, Val MedAE=0.010886, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 15:40:34.209 1: SolCast DEBUG> Epoche 267: Train MSE=0.000336, Val MSE=0.000598, Val MAE=0.015326, Val MedAE=0.010661, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 15:40:34.322 1: SolCast DEBUG> Epoche 268: Train MSE=0.000325, Val MSE=0.000576, Val MAE=0.015095, Val MedAE=0.010564, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 15:40:34.431 1: SolCast DEBUG> Epoche 269: Train MSE=0.000314, Val MSE=0.000555, Val MAE=0.014870, Val MedAE=0.010315, Bit_Fail=0 -> Snap saved (metric improved)
...
2026.01.01 15:45:53.259 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000188, Val MSE=0.000286, Val MAE=0.011095, Val MedAE=0.007725, Bit_Fail=0
2026.01.01 15:46:00.439 1: SolCast DEBUG> Early stopping bei Epoche 3368 (no improvement since 2000 epochs)
2026.01.01 15:46:00.439 1: === Snapshot-Statistik ===
2026.01.01 15:46:00.440 1: Metric-Improvement Snapshots: 67 (letzte Epoche: 1368)
2026.01.01 15:46:00.440 1: Bit-Improvement Snapshots: 5 (letzte Epoche: 267)
2026.01.01 15:46:00.441 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 15:46:00.443 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 1368: Train MSE=0.000188, Val MSE=0.000286, Val MAE=0.010789, Val MedAE=0.006938, Bit_Fail=0,
2026.01.01 15:46:00.444 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 15:46:00.475 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000188, Validation MSE=0.000286, Validation Bit_Fail=0
2026.01.01 15:46:00.476 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000188
Val MSE=0.000286
Val Mean=0.0002908456
VAL/TRAIN MSE Ratio=1.525656 (limit=2.5)
Diff=0.000099 (limit=0.005)
ValStd=0.0000052738 (limit=7.27113936211133e-05)
-- At Original Scale: --
MAE=96.4264081498789
RMSE/MAE=1.5680 (limit=1.5)
Slope=0.846171 (limit=0.7 .. 1.3)
Bias=104.79 (limit=+-48.2132040749395)
R2=0.886437100872621
P95=283.1830 (limit=385.705632599516)
P99=538.2559 (limit=771.411265199031)
-- Robustness Indicators: --
RMSE relative=24 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
</pre>
</div>
</div>

<div class="mw-collapsible mw-collapsed">
Ein '''komplettes Beispiel mit 3 Wiederholungen''' eines Trainingslogs -> <div class="mw-collapsible-content">
<pre>
2026.01.01 18:03:45.037 1: SolCast DEBUG> AI FANN Training for Consumption Forecast BlockingCall PID "813631" with Timeout 86400 s started
2026.01.01 18:03:46.046 1: SolCast DEBUG> AI FANN - There are 503 Records skipped due to incomplete or invalid data. Index:
2025013115, 2025020401, 2025020414, 2025020415, 2025020416, 2025021813, 2025021816, 2025021913, 2025021914, 2025021915, 2025022013, 2025022316, 2025030216, 2025030310, 2025030315, 2025030316, 2025030416, 2025030511, 2025030512, 2025030516, 2025030517, 2025030610, 2025030611, 2025030612, 2025030616, 2025030710, 2025030711, 2025030712, 2025030713, 2025030716, 2025030810, 2025030910, 2025030916, 2025030917, 2025031010, 2025031114, 2025031519, 2025031609, 2025031709, 2025031710, 2025031716, 2025031717, 2025031810, 2025031811, 2025031814, 2025031815, 2025031816, 2025031817, 2025031909, 2025031910, 2025031911, 2025031915, 2025031916, 2025031917, 2025032010, 2025032011, 2025032014, 2025032015, 2025032016, 2025032017, 2025032110, 2025032114, 2025032115, 2025032116, 2025032117, 2025032209, 2025032210, 2025032211, 2025032214, 2025032215, 2025032814, 2025032815, 2025032817, 2025033003, 2025040211, 2025040212, 2025040215, 2025040216, 2025040217, 2025040314, 2025040315, 2025040316, 2025040317, 2025040318, 2025040410, 2025040411, 2025040413, 2025040414, 2025040418, 2025040510, 2025040517, 2025040518, 2025040612, 2025040617, 2025040618, 2025040711, 2025040811, 2025040812, 2025040813, 2025041017, 2025041018, 2025041110, 2025041111, 2025041216, 2025041217, 2025041218, 2025041312, 2025041316, 2025041317, 2025041417, 2025041418, 2025041611, 2025041617, 2025041618, 2025042017, 2025042018, 2025042115, 2025042117, 2025042118, 2025042218, 2025042609, 2025042610, 2025042611, 2025042612, 2025042617, 2025042618, 2025042710, 2025042711, 2025042712, 2025042714, 2025042715, 2025042717, 2025042718, 2025042810, 2025042811, 2025042813, 2025042814, 2025042817, 2025042818, 2025042911, 2025042913, 2025042914, 2025042917, 2025042918, 2025050110, 2025050111, 2025050114, 2025050117, 2025050118, 2025050210, 2025050211, 2025050213, 2025050518, 2025050610, 2025050611, 2025050614, 2025050617, 2025050618, 2025050706, 2025050707, 2025050708, 2025050810, 2025050812, 2025050816, 2025050817, 2025050910, 2025050911, 2025050912, 2025050917, 2025050918, 2025051009, 2025051010, 2025051011, 2025051012, 2025051017, 2025051018, 2025051109, 2025051210, 2025051211, 2025051212, 2025051213, 2025051214, 2025051218, 2025051310, 2025051313, 2025051314, 2025051317, 2025051318, 2025051411, 2025051413, 2025051414, 2025051418, 2025051510, 2025051610, 2025051611, 2025051710, 2025051713, 2025051916, 2025052010, 2025052011, 2025052017, 2025052018, 2025052111, 2025052113, 2025052114, 2025052115, 2025052118, 2025052211, 2025052409, 2025052410, 2025052416, 2025052417, 2025052609, 2025052616, 2025052617, 2025052618, 2025052817, 2025052910, 2025052911, 2025052917, 2025053010, 2025053013, 2025053017, 2025053018, 2025053109, 2025053110, 2025053111, 2025053112, 2025053113, 2025053115, 2025053117, 2025060210, 2025060215, 2025060217, 2025060310, 2025060312, 2025060317, 2025060318, 2025060513, 2025060517, 2025060609, 2025060610, 2025060618, 2025060710, 2025060711, 2025060712, 2025060713, 2025060811, 2025060812, 2025060816, 2025060817, 2025060818, 2025060909, 2025060910, 2025060911, 2025060912, 2025060913, 2025060917, 2025060918, 2025061015, 2025061016, 2025061109, 2025061114, 2025061117, 2025061118, 2025061119, 2025061209, 2025061210, 2025061211, 2025061212, 2025061213, 2025061214, 2025061215, 2025061217, 2025061218, 2025061309, 2025061310, 2025061311, 2025061312, 2025061313, 2025061314, 2025061315, 2025061317, 2025061318, 2025061319, 2025061410, 2025061411, 2025061413, 2025061414, 2025061417, 2025061418, 2025061710, 2025061713, 2025061714, 2025061717, 2025061718, 2025061724, 2025062010, 2025062011, 2025062013, 2025062014, 2025062017, 2025062018, 2025062109, 2025062110, 2025062111, 2025062112, 2025062114, 2025062117, 2025062118, 2025062209, 2025062210, 2025062211, 2025062212, 2025062213, 2025062214, 2025062217, 2025062218, 2025062309, 2025062310, 2025062311, 2025062317, 2025062318, 2025062409, 2025062410, 2025062411, 2025062818, 2025062911, 2025062913, 2025062918, 2025063009, 2025063011, 2025063013, 2025063014, 2025063017, 2025063018, 2025070110, 2025070111, 2025070112, 2025070113, 2025070117, 2025070118, 2025070210, 2025070211, 2025070212, 2025070213, 2025070217, 2025070218, 2025070318, 2025070410, 2025070411, 2025070412, 2025070417, 2025070418, 2025070510, 2025070511, 2025070512, 2025070610, 2025070611, 2025070615, 2025070717, 2025070810, 2025071013, 2025071017, 2025071112, 2025071113, 2025071117, 2025071311, 2025071318, 2025071410, 2025071411, 2025071812, 2025071818, 2025071910, 2025071911, 2025071912, 2025071913, 2025071918, 2025072009, 2025072510, 2025072514, 2025073110, 2025073118, 2025080118, 2025080210, 2025080310, 2025080410, 2025080417, 2025080418, 2025080616, 2025080617, 2025080715, 2025080716, 2025080717, 2025080718, 2025080917, 2025080918, 2025081015, 2025081016, 2025081017, 2025081018, 2025081115, 2025081116, 2025081117, 2025081118, 2025081120, 2025081121, 2025081122, 2025081123, 2025081124, 2025081215, 2025081216, 2025081217, 2025081315, 2025081316, 2025081317, 2025081318, 2025081415, 2025081416, 2025081417, 2025081418, 2025081516, 2025081517, 2025081617, 2025081816, 2025081817, 2025081818, 2025081915, 2025081916, 2025081917, 2025082015, 2025082016, 2025082017, 2025082018, 2025082115, 2025082116, 2025082117, 2025082416, 2025082516, 2025082517, 2025082518, 2025082519, 2025082612, 2025082613, 2025082614, 2025082618, 2025082716, 2025082717, 2025083110, 2025083111, 2025083113, 2025083118, 2025090110, 2025090215, 2025090311, 2025090317, 2025090411, 2025090414, 2025090417, 2025090517, 2025090610, 2025090611, 2025090612, 2025090618, 2025090710, 2025090711, 2025090713, 2025090714, 2025090718, 2025090810, 2025090813, 2025090910, 2025090911, 2025091217, 2025091816, 2025091817, 2025091915, 2025091916, 2025091917, 2025092014, 2025092015, 2025092016, 2025092017, 2025092113, 2025092115, 2025092315, 2025092316, 2025092417, 2025092910, 2025092911, 2025092912, 2025092917, 2025093011, 2025093012, 2025093013, 2025093017, 2025100316, 2025100317, 2025110320, 2025122222, 2025122223, 2025122224, 2025122510
2026.01.01 18:03:46.940 1: SolCast - DBG F[7300]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.942 1: SolCast - DBG F[7301]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.944 1: SolCast - DBG F[7302]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.945 1: SolCast - DBG F[7303]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.947 1: SolCast - DBG F[7304]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.949 1: SolCast - DBG F[7305]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.951 1: SolCast - DBG F[7306]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.953 1: SolCast - DBG F[7307]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.954 1: SolCast - DBG F[7308]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.956 1: SolCast - DBG F[7309]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.958 1: SolCast - DBG F[7310]: lag1=0.002 lag2=0.001 lag24=0.002 d1p=0.036 d1n=0.000 rollstd=0.000 up=1 down=0 upS=0.036 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.960 1: SolCast - DBG F[7311]: lag1=0.026 lag2=0.002 lag24=0.008 d1p=0.004 d1n=0.000 rollstd=0.033 up=0 down=0 upS=0.004 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.962 1: SolCast - DBG F[7312]: lag1=0.029 lag2=0.026 lag24=0.012 d1p=0.000 d1n=0.008 rollstd=0.044 up=0 down=1 upS=0.000 downS=0.008 vol=0 pvX=0 break=0
2026.01.01 18:03:46.963 1: SolCast - DBG F[7313]: lag1=0.023 lag2=0.029 lag24=0.016 d1p=0.011 d1n=0.000 rollstd=0.045 up=1 down=0 upS=0.011 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.965 1: SolCast - DBG F[7314]: lag1=0.031 lag2=0.023 lag24=0.018 d1p=0.000 d1n=0.003 rollstd=0.044 up=0 down=0 upS=0.000 downS=0.003 vol=0 pvX=0 break=0
2026.01.01 18:03:46.967 1: SolCast - DBG F[7315]: lag1=0.028 lag2=0.031 lag24=0.017 d1p=0.002 d1n=0.000 rollstd=0.036 up=0 down=0 upS=0.002 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.968 1: SolCast - DBG F[7316]: lag1=0.030 lag2=0.028 lag24=0.008 d1p=0.000 d1n=0.002 rollstd=0.009 up=0 down=0 upS=0.000 downS=0.002 vol=0 pvX=0 break=0
2026.01.01 18:03:46.970 1: SolCast - DBG F[7317]: lag1=0.028 lag2=0.030 lag24=0.002 d1p=0.000 d1n=0.005 rollstd=0.009 up=0 down=1 upS=0.000 downS=0.005 vol=0 pvX=0 break=0
2026.01.01 18:03:46.974 1: SolCast - DBG F[7318]: lag1=0.025 lag2=0.028 lag24=0.002 d1p=0.005 d1n=0.000 rollstd=0.010 up=1 down=0 upS=0.005 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.976 1: SolCast - DBG F[7319]: lag1=0.028 lag2=0.025 lag24=0.001 d1p=0.008 d1n=0.000 rollstd=0.007 up=1 down=0 upS=0.008 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:47.013 1: SolCast DEBUG> First attempt 0 with Seed=439288
2026.01.01 18:03:47.024 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 18:03:47.208 1: SolCast DEBUG> Epoche 1: Train MSE=0.002194, Val MSE=0.002834, Val MAE=0.031901, Val MedAE=0.027985, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 18:03:47.528 1: SolCast DEBUG> Epoche 3: Train MSE=0.002192, Val MSE=0.002833, Val MAE=0.031892, Val MedAE=0.027975, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:03:54.175 1: SolCast DEBUG> Epoche 48: Train MSE=0.001736, Val MSE=0.002765, Val MAE=0.029706, Val MedAE=0.016374, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:04:02.843 1: SolCast DEBUG> Epoche 100: Train MSE=0.001736, Val MSE=0.001509, Val MAE=0.026824, Val MedAE=0.022443, Bit_Fail=1
2026.01.01 18:04:07.181 1: SolCast DEBUG> Epoche 127: Train MSE=0.000623, Val MSE=0.001033, Val MAE=0.022203, Val MedAE=0.017074, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 18:04:07.341 1: SolCast DEBUG> Epoche 128: Train MSE=0.000611, Val MSE=0.001012, Val MAE=0.021994, Val MedAE=0.017013, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:07.519 1: SolCast DEBUG> Epoche 129: Train MSE=0.000599, Val MSE=0.000990, Val MAE=0.021783, Val MedAE=0.016793, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:07.994 1: SolCast DEBUG> Epoche 131: Train MSE=0.000577, Val MSE=0.000943, Val MAE=0.021456, Val MedAE=0.016655, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.185 1: SolCast DEBUG> Epoche 132: Train MSE=0.000566, Val MSE=0.000922, Val MAE=0.021240, Val MedAE=0.016463, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.344 1: SolCast DEBUG> Epoche 133: Train MSE=0.000554, Val MSE=0.000901, Val MAE=0.021025, Val MedAE=0.016355, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.508 1: SolCast DEBUG> Epoche 134: Train MSE=0.000543, Val MSE=0.000881, Val MAE=0.020809, Val MedAE=0.016328, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.684 1: SolCast DEBUG> Epoche 135: Train MSE=0.000532, Val MSE=0.000860, Val MAE=0.020593, Val MedAE=0.016227, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.840 1: SolCast DEBUG> Epoche 136: Train MSE=0.000521, Val MSE=0.000841, Val MAE=0.020381, Val MedAE=0.016031, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.989 1: SolCast DEBUG> Epoche 137: Train MSE=0.000511, Val MSE=0.000822, Val MAE=0.020175, Val MedAE=0.015652, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.144 1: SolCast DEBUG> Epoche 138: Train MSE=0.000501, Val MSE=0.000803, Val MAE=0.019972, Val MedAE=0.015495, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.297 1: SolCast DEBUG> Epoche 139: Train MSE=0.000492, Val MSE=0.000786, Val MAE=0.019773, Val MedAE=0.015409, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.458 1: SolCast DEBUG> Epoche 140: Train MSE=0.000481, Val MSE=0.000777, Val MAE=0.019495, Val MedAE=0.015158, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.615 1: SolCast DEBUG> Epoche 141: Train MSE=0.000473, Val MSE=0.000760, Val MAE=0.019325, Val MedAE=0.015145, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.767 1: SolCast DEBUG> Epoche 142: Train MSE=0.000465, Val MSE=0.000745, Val MAE=0.019163, Val MedAE=0.015044, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.919 1: SolCast DEBUG> Epoche 143: Train MSE=0.000457, Val MSE=0.000730, Val MAE=0.019008, Val MedAE=0.015017, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.080 1: SolCast DEBUG> Epoche 144: Train MSE=0.000449, Val MSE=0.000716, Val MAE=0.018857, Val MedAE=0.014983, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.245 1: SolCast DEBUG> Epoche 145: Train MSE=0.000442, Val MSE=0.000702, Val MAE=0.018714, Val MedAE=0.014883, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.400 1: SolCast DEBUG> Epoche 146: Train MSE=0.000436, Val MSE=0.000690, Val MAE=0.018579, Val MedAE=0.014777, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.705 1: SolCast DEBUG> Epoche 148: Train MSE=0.000424, Val MSE=0.000667, Val MAE=0.018328, Val MedAE=0.014732, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.858 1: SolCast DEBUG> Epoche 149: Train MSE=0.000418, Val MSE=0.000656, Val MAE=0.018213, Val MedAE=0.014659, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:11.447 1: SolCast DEBUG> Epoche 153: Train MSE=0.000398, Val MSE=0.000655, Val MAE=0.017918, Val MedAE=0.014430, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 18:04:11.597 1: SolCast DEBUG> Epoche 154: Train MSE=0.000394, Val MSE=0.000648, Val MAE=0.017836, Val MedAE=0.014356, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:11.780 1: SolCast DEBUG> Epoche 155: Train MSE=0.000390, Val MSE=0.000641, Val MAE=0.017757, Val MedAE=0.014209, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:11.968 1: SolCast DEBUG> Epoche 156: Train MSE=0.000386, Val MSE=0.000635, Val MAE=0.017685, Val MedAE=0.014026, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:12.119 1: SolCast DEBUG> Epoche 157: Train MSE=0.000383, Val MSE=0.000629, Val MAE=0.017617, Val MedAE=0.013986, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:15.889 1: SolCast DEBUG> Epoche 180: Train MSE=0.000338, Val MSE=0.000530, Val MAE=0.017079, Val MedAE=0.013927, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:19.269 1: SolCast DEBUG> Epoche 200: Train MSE=0.000338, Val MSE=0.000535, Val MAE=0.016673, Val MedAE=0.013893, Bit_Fail=0
2026.01.01 18:04:35.878 1: SolCast DEBUG> Epoche 290: Train MSE=0.000288, Val MSE=0.000524, Val MAE=0.016388, Val MedAE=0.013535, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:36.582 1: SolCast DEBUG> Epoche 293: Train MSE=0.000287, Val MSE=0.000523, Val MAE=0.016367, Val MedAE=0.013507, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:37.370 1: SolCast DEBUG> Epoche 296: Train MSE=0.000287, Val MSE=0.000522, Val MAE=0.016353, Val MedAE=0.013413, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:38.343 1: SolCast DEBUG> Epoche 300: Train MSE=0.000287, Val MSE=0.000500, Val MAE=0.016520, Val MedAE=0.014059, Bit_Fail=0
2026.01.01 18:04:53.153 1: SolCast DEBUG> Epoche 360: Train MSE=0.000276, Val MSE=0.000498, Val MAE=0.016213, Val MedAE=0.013363, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:05:03.452 1: SolCast DEBUG> Epoche 400: Train MSE=0.000276, Val MSE=0.000492, Val MAE=0.016416, Val MedAE=0.013627, Bit_Fail=0
2026.01.01 18:05:29.137 1: SolCast DEBUG> Epoche 500: Train MSE=0.000276, Val MSE=0.000500, Val MAE=0.016208, Val MedAE=0.013216, Bit_Fail=0
2026.01.01 18:05:51.013 1: SolCast DEBUG> Epoche 600: Train MSE=0.000276, Val MSE=0.000500, Val MAE=0.016319, Val MedAE=0.012971, Bit_Fail=0
2026.01.01 18:06:14.772 1: SolCast DEBUG> Epoche 700: Train MSE=0.000276, Val MSE=0.000511, Val MAE=0.016383, Val MedAE=0.013241, Bit_Fail=0
2026.01.01 18:06:36.483 1: SolCast DEBUG> Epoche 800: Train MSE=0.000276, Val MSE=0.000509, Val MAE=0.016792, Val MedAE=0.013049, Bit_Fail=0
2026.01.01 18:06:52.867 1: SolCast DEBUG> Epoche 900: Train MSE=0.000276, Val MSE=0.000495, Val MAE=0.015972, Val MedAE=0.012938, Bit_Fail=0
2026.01.01 18:06:52.877 1: SolCast DEBUG> Epoche 900: Train MSE=0.000242, Val MSE=0.000495, Val MAE=0.015972, Val MedAE=0.012938, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:09.391 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000242, Val MSE=0.000493, Val MAE=0.016187, Val MedAE=0.013015, Bit_Fail=0
2026.01.01 18:07:14.202 1: SolCast DEBUG> Epoche 1027: Train MSE=0.000237, Val MSE=0.000491, Val MAE=0.015971, Val MedAE=0.012928, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:18.001 1: SolCast DEBUG> Epoche 1050: Train MSE=0.000234, Val MSE=0.000486, Val MAE=0.015890, Val MedAE=0.012757, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:18.455 1: SolCast DEBUG> Epoche 1053: Train MSE=0.000234, Val MSE=0.000485, Val MAE=0.015881, Val MedAE=0.012678, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:25.760 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000234, Val MSE=0.000480, Val MAE=0.015846, Val MedAE=0.012669, Bit_Fail=0
2026.01.01 18:07:25.766 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000233, Val MSE=0.000480, Val MAE=0.015846, Val MedAE=0.012669, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:42.102 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000233, Val MSE=0.000484, Val MAE=0.016233, Val MedAE=0.012505, Bit_Fail=0
2026.01.01 18:07:43.824 1: SolCast DEBUG> Epoche 1210: Train MSE=0.000227, Val MSE=0.000470, Val MAE=0.015552, Val MedAE=0.012390, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:57.828 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000227, Val MSE=0.000520, Val MAE=0.017539, Val MedAE=0.013492, Bit_Fail=0
2026.01.01 18:08:14.430 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000227, Val MSE=0.000460, Val MAE=0.016046, Val MedAE=0.012304, Bit_Fail=0
2026.01.01 18:08:16.132 1: SolCast DEBUG> Epoche 1410: Train MSE=0.000222, Val MSE=0.000452, Val MAE=0.015408, Val MedAE=0.011884, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:17.883 1: SolCast DEBUG> Epoche 1420: Train MSE=0.000220, Val MSE=0.000443, Val MAE=0.015258, Val MedAE=0.011811, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:29.901 1: SolCast DEBUG> Epoche 1490: Train MSE=0.000218, Val MSE=0.000439, Val MAE=0.014983, Val MedAE=0.011569, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:30.803 1: SolCast DEBUG> Epoche 1496: Train MSE=0.000218, Val MSE=0.000438, Val MAE=0.014960, Val MedAE=0.011509, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:31.440 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000218, Val MSE=0.000439, Val MAE=0.015419, Val MedAE=0.011971, Bit_Fail=0
2026.01.01 18:08:47.448 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000218, Val MSE=0.000454, Val MAE=0.016309, Val MedAE=0.012168, Bit_Fail=0
2026.01.01 18:08:50.500 1: SolCast DEBUG> Epoche 1620: Train MSE=0.000214, Val MSE=0.000431, Val MAE=0.014770, Val MedAE=0.011218, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:03.800 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000214, Val MSE=0.000439, Val MAE=0.015947, Val MedAE=0.012095, Bit_Fail=0
2026.01.01 18:09:12.275 1: SolCast DEBUG> Epoche 1755: Train MSE=0.000210, Val MSE=0.000414, Val MAE=0.014646, Val MedAE=0.011210, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:19.335 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000210, Val MSE=0.000427, Val MAE=0.015787, Val MedAE=0.011912, Bit_Fail=0
2026.01.01 18:09:36.229 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000210, Val MSE=0.000417, Val MAE=0.015680, Val MedAE=0.011996, Bit_Fail=0
2026.01.01 18:09:45.972 1: SolCast DEBUG> Epoche 1960: Train MSE=0.000204, Val MSE=0.000388, Val MAE=0.014589, Val MedAE=0.011116, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:51.969 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000204, Val MSE=0.000404, Val MAE=0.015606, Val MedAE=0.012356, Bit_Fail=0
2026.01.01 18:09:53.511 1: SolCast DEBUG> Epoche 2010: Train MSE=0.000202, Val MSE=0.000386, Val MAE=0.014313, Val MedAE=0.011006, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:55.063 1: SolCast DEBUG> Epoche 2020: Train MSE=0.000201, Val MSE=0.000383, Val MAE=0.014131, Val MedAE=0.010774, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:10:08.287 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000201, Val MSE=0.000380, Val MAE=0.014528, Val MedAE=0.011353, Bit_Fail=0
2026.01.01 18:10:24.098 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000201, Val MSE=0.000370, Val MAE=0.013946, Val MedAE=0.010416, Bit_Fail=0
2026.01.01 18:10:24.104 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000197, Val MSE=0.000370, Val MAE=0.013946, Val MedAE=0.010416, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:10:39.646 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000197, Val MSE=0.000374, Val MAE=0.014907, Val MedAE=0.011753, Bit_Fail=0
2026.01.01 18:10:56.682 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000197, Val MSE=0.000356, Val MAE=0.013705, Val MedAE=0.010006, Bit_Fail=0
2026.01.01 18:10:56.693 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000192, Val MSE=0.000356, Val MAE=0.013705, Val MedAE=0.010006, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:11:12.550 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000192, Val MSE=0.000375, Val MAE=0.015257, Val MedAE=0.012743, Bit_Fail=0
2026.01.01 18:11:15.676 1: SolCast DEBUG> Epoche 2520: Train MSE=0.000191, Val MSE=0.000355, Val MAE=0.013591, Val MedAE=0.009674, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:11:17.824 1: SolCast DEBUG> Epoche 2531: Train MSE=0.000190, Val MSE=0.000346, Val MAE=0.013480, Val MedAE=0.009639, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:11:28.987 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000190, Val MSE=0.000339, Val MAE=0.013649, Val MedAE=0.010530, Bit_Fail=0
2026.01.01 18:11:45.115 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000190, Val MSE=0.000354, Val MAE=0.014651, Val MedAE=0.011877, Bit_Fail=0
2026.01.01 18:12:01.075 1: SolCast DEBUG> Epoche 2790: Train MSE=0.000186, Val MSE=0.000341, Val MAE=0.013362, Val MedAE=0.009487, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:12:02.671 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000186, Val MSE=0.000333, Val MAE=0.013606, Val MedAE=0.010687, Bit_Fail=0
2026.01.01 18:12:18.422 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000186, Val MSE=0.000335, Val MAE=0.013448, Val MedAE=0.010124, Bit_Fail=0
2026.01.01 18:12:35.464 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000186, Val MSE=0.000327, Val MAE=0.013352, Val MedAE=0.010017, Bit_Fail=0
2026.01.01 18:12:56.411 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000186, Val MSE=0.000333, Val MAE=0.013996, Val MedAE=0.011160, Bit_Fail=0
2026.01.01 18:13:10.994 1: SolCast DEBUG> Epoche 3162: Train MSE=0.000181, Val MSE=0.000328, Val MAE=0.013113, Val MedAE=0.009469, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:13:18.736 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000181, Val MSE=0.000320, Val MAE=0.013393, Val MedAE=0.010591, Bit_Fail=0
2026.01.01 18:13:39.675 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000181, Val MSE=0.000319, Val MAE=0.013325, Val MedAE=0.010389, Bit_Fail=0
2026.01.01 18:14:00.271 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000181, Val MSE=0.000325, Val MAE=0.014006, Val MedAE=0.011521, Bit_Fail=0
2026.01.01 18:14:22.409 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000181, Val MSE=0.000344, Val MAE=0.014666, Val MedAE=0.012138, Bit_Fail=0
2026.01.01 18:14:38.101 1: SolCast DEBUG> Epoche 3580: Train MSE=0.000177, Val MSE=0.000319, Val MAE=0.012991, Val MedAE=0.009430, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:14:42.467 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000177, Val MSE=0.000314, Val MAE=0.013079, Val MedAE=0.010056, Bit_Fail=0
2026.01.01 18:15:03.838 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000177, Val MSE=0.000333, Val MAE=0.014308, Val MedAE=0.011807, Bit_Fail=0
2026.01.01 18:15:16.053 2: HUEBridge: http request failed: read from http://192.168.2.7:80 timed out
2026.01.01 18:15:30.476 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000177, Val MSE=0.000321, Val MAE=0.013020, Val MedAE=0.009413, Bit_Fail=0
2026.01.01 18:15:45.037 1: SolCast DEBUG> Epoche 3870: Train MSE=0.000174, Val MSE=0.000317, Val MAE=0.012911, Val MedAE=0.009292, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:15:52.131 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000174, Val MSE=0.000312, Val MAE=0.013464, Val MedAE=0.010556, Bit_Fail=0
2026.01.01 18:16:12.390 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000174, Val MSE=0.000320, Val MAE=0.013974, Val MedAE=0.011455, Bit_Fail=0
2026.01.01 18:16:29.091 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000174, Val MSE=0.000312, Val MAE=0.013592, Val MedAE=0.010912, Bit_Fail=0
2026.01.01 18:16:52.505 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000174, Val MSE=0.000302, Val MAE=0.012962, Val MedAE=0.010156, Bit_Fail=0
2026.01.01 18:17:16.099 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000174, Val MSE=0.000303, Val MAE=0.013023, Val MedAE=0.010334, Bit_Fail=0
2026.01.01 18:17:31.066 1: openMeteo - Open-Meteo API server response: start_SSL https://api.open-meteo.com:443 timed out
2026.01.01 18:17:38.285 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000174, Val MSE=0.000302, Val MAE=0.013197, Val MedAE=0.010550, Bit_Fail=0
2026.01.01 18:17:52.429 1: SolCast DEBUG> Epoche 4460: Train MSE=0.000170, Val MSE=0.000311, Val MAE=0.012837, Val MedAE=0.009137, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:17:58.628 1: SolCast DEBUG> Epoche 4490: Train MSE=0.000170, Val MSE=0.000305, Val MAE=0.012794, Val MedAE=0.009134, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:18:01.453 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000170, Val MSE=0.000301, Val MAE=0.012898, Val MedAE=0.009802, Bit_Fail=0
2026.01.01 18:18:23.799 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000170, Val MSE=0.000298, Val MAE=0.012957, Val MedAE=0.010201, Bit_Fail=0
2026.01.01 18:18:39.811 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000170, Val MSE=0.000301, Val MAE=0.013527, Val MedAE=0.011413, Bit_Fail=0
2026.01.01 18:18:56.354 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000170, Val MSE=0.000298, Val MAE=0.013255, Val MedAE=0.011018, Bit_Fail=0
2026.01.01 18:19:12.392 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000170, Val MSE=0.000295, Val MAE=0.013216, Val MedAE=0.010940, Bit_Fail=0
2026.01.01 18:19:27.987 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000170, Val MSE=0.000293, Val MAE=0.013073, Val MedAE=0.010728, Bit_Fail=0
2026.01.01 18:19:32.327 1: SolCast DEBUG> Epoche 5030: Train MSE=0.000167, Val MSE=0.000297, Val MAE=0.012698, Val MedAE=0.009102, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:19:43.670 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000167, Val MSE=0.000298, Val MAE=0.013300, Val MedAE=0.010884, Bit_Fail=0
2026.01.01 18:19:59.190 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000167, Val MSE=0.000294, Val MAE=0.013167, Val MedAE=0.010790, Bit_Fail=0
2026.01.01 18:20:10.606 1: SolCast DEBUG> Epoche 5262: Train MSE=0.000166, Val MSE=0.000295, Val MAE=0.012677, Val MedAE=0.009089, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:20:16.409 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000166, Val MSE=0.000292, Val MAE=0.013247, Val MedAE=0.011177, Bit_Fail=0
2026.01.01 18:20:34.708 1: SolCast DEBUG> Epoche 5400: Train MSE=0.000166, Val MSE=0.000291, Val MAE=0.012964, Val MedAE=0.010392, Bit_Fail=0
2026.01.01 18:20:57.206 1: SolCast DEBUG> Epoche 5500: Train MSE=0.000166, Val MSE=0.000288, Val MAE=0.012996, Val MedAE=0.010552, Bit_Fail=0
2026.01.01 18:21:21.536 1: SolCast DEBUG> Epoche 5600: Train MSE=0.000166, Val MSE=0.000286, Val MAE=0.012927, Val MedAE=0.010610, Bit_Fail=0
2026.01.01 18:21:43.826 1: SolCast DEBUG> Epoche 5700: Train MSE=0.000166, Val MSE=0.000284, Val MAE=0.012811, Val MedAE=0.010111, Bit_Fail=0
2026.01.01 18:21:46.073 1: SolCast DEBUG> Epoche 5710: Train MSE=0.000164, Val MSE=0.000292, Val MAE=0.012617, Val MedAE=0.009052, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:22:05.636 1: SolCast DEBUG> Epoche 5800: Train MSE=0.000164, Val MSE=0.000311, Val MAE=0.013979, Val MedAE=0.012142, Bit_Fail=0
2026.01.01 18:22:28.019 1: SolCast DEBUG> Epoche 5900: Train MSE=0.000164, Val MSE=0.000284, Val MAE=0.012679, Val MedAE=0.009654, Bit_Fail=0
2026.01.01 18:22:44.531 1: SolCast DEBUG> Epoche 6000: Train MSE=0.000164, Val MSE=0.000333, Val MAE=0.014735, Val MedAE=0.013016, Bit_Fail=0
2026.01.01 18:23:00.239 1: SolCast DEBUG> Epoche 6100: Train MSE=0.000164, Val MSE=0.000286, Val MAE=0.012652, Val MedAE=0.009522, Bit_Fail=0
2026.01.01 18:23:16.145 1: SolCast DEBUG> Epoche 6200: Train MSE=0.000164, Val MSE=0.000283, Val MAE=0.012623, Val MedAE=0.009526, Bit_Fail=0
2026.01.01 18:23:31.970 1: SolCast DEBUG> Epoche 6300: Train MSE=0.000164, Val MSE=0.000294, Val MAE=0.013520, Val MedAE=0.011589, Bit_Fail=0
2026.01.01 18:23:48.995 1: SolCast DEBUG> Epoche 6400: Train MSE=0.000164, Val MSE=0.000290, Val MAE=0.013238, Val MedAE=0.011187, Bit_Fail=0
2026.01.01 18:24:04.958 1: SolCast DEBUG> Epoche 6500: Train MSE=0.000164, Val MSE=0.000283, Val MAE=0.013087, Val MedAE=0.011112, Bit_Fail=0
2026.01.01 18:24:20.473 1: SolCast DEBUG> Epoche 6600: Train MSE=0.000164, Val MSE=0.000291, Val MAE=0.012657, Val MedAE=0.009198, Bit_Fail=0
2026.01.01 18:24:35.890 1: SolCast DEBUG> Epoche 6700: Train MSE=0.000164, Val MSE=0.000290, Val MAE=0.013459, Val MedAE=0.011749, Bit_Fail=0
2026.01.01 18:24:52.891 1: SolCast DEBUG> Epoche 6800: Train MSE=0.000164, Val MSE=0.000289, Val MAE=0.013364, Val MedAE=0.011509, Bit_Fail=0
2026.01.01 18:25:08.802 1: SolCast DEBUG> Epoche 6900: Train MSE=0.000164, Val MSE=0.000283, Val MAE=0.013144, Val MedAE=0.011185, Bit_Fail=0
2026.01.01 18:25:24.371 1: SolCast DEBUG> Epoche 7000: Train MSE=0.000164, Val MSE=0.000278, Val MAE=0.012650, Val MedAE=0.009934, Bit_Fail=0
2026.01.01 18:25:39.968 1: SolCast DEBUG> Epoche 7100: Train MSE=0.000164, Val MSE=0.000320, Val MAE=0.014405, Val MedAE=0.012857, Bit_Fail=0
2026.01.01 18:25:56.650 1: SolCast DEBUG> Epoche 7200: Train MSE=0.000164, Val MSE=0.000281, Val MAE=0.013030, Val MedAE=0.011100, Bit_Fail=0
2026.01.01 18:26:12.530 1: SolCast DEBUG> Epoche 7300: Train MSE=0.000164, Val MSE=0.000277, Val MAE=0.012556, Val MedAE=0.009580, Bit_Fail=0
2026.01.01 18:26:28.387 1: SolCast DEBUG> Epoche 7400: Train MSE=0.000164, Val MSE=0.000275, Val MAE=0.012574, Val MedAE=0.009786, Bit_Fail=0
2026.01.01 18:26:44.426 1: SolCast DEBUG> Epoche 7500: Train MSE=0.000164, Val MSE=0.000282, Val MAE=0.013197, Val MedAE=0.011348, Bit_Fail=0
2026.01.01 18:27:00.108 1: SolCast DEBUG> Epoche 7600: Train MSE=0.000164, Val MSE=0.000279, Val MAE=0.012521, Val MedAE=0.009349, Bit_Fail=0
2026.01.01 18:27:17.631 1: SolCast DEBUG> Epoche 7700: Train MSE=0.000164, Val MSE=0.000334, Val MAE=0.014836, Val MedAE=0.013130, Bit_Fail=0
2026.01.01 18:27:19.201 1: SolCast DEBUG> Early stopping bei Epoche 7710 (no improvement since 2000 epochs)
2026.01.01 18:27:19.203 1: === Snapshot-Statistik ===
2026.01.01 18:27:19.206 1: Metric-Improvement Snapshots: 59 (letzte Epoche: 5710)
2026.01.01 18:27:19.208 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 153)
2026.01.01 18:27:19.211 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 18:27:19.222 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 5710: Train MSE=0.000164, Val MSE=0.000292, Val MAE=0.012617, Val MedAE=0.009052, Bit_Fail=0,
2026.01.01 18:27:19.225 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 18:27:19.269 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000164, Validation MSE=0.000292, Validation Bit_Fail=0
2026.01.01 18:27:19.272 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000164
Val MSE=0.000292
Val Mean=0.0003006352
VAL/TRAIN MSE Ratio=1.778317 (limit=2.5)
Diff=0.000128 (limit=0.005)
ValStd=0.0000223852 (limit=7.51588070934039e-05)
-- At Original Scale: --
MAE=207.818584965433
RMSE/MAE=1.3545 (limit=1.5)
Slope=0.930345 (limit=0.7 .. 1.3)
Bias=-1.81 (limit=+-103.909292482717)
R2=0.896675647742538
P95=565.7317 (limit=831.274339861732)
P99=813.5925 (limit=1662.54867972346)
-- Robustness Indicators: --
RMSE relative=60 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 18:27:19.280 1: SolCast DEBUG> Retry attempt 1 with Seed=16816002
2026.01.01 18:27:19.287 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 18:27:19.448 1: SolCast DEBUG> Epoche 1: Train MSE=0.002204, Val MSE=0.002840, Val MAE=0.031967, Val MedAE=0.027950, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 18:27:27.760 1: SolCast DEBUG> Epoche 55: Train MSE=0.001883, Val MSE=0.002825, Val MAE=0.030076, Val MedAE=0.017712, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:27.909 1: SolCast DEBUG> Epoche 56: Train MSE=0.001848, Val MSE=0.002787, Val MAE=0.029877, Val MedAE=0.017254, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:28.093 1: SolCast DEBUG> Epoche 57: Train MSE=0.001806, Val MSE=0.002742, Val MAE=0.029648, Val MedAE=0.016877, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:28.250 1: SolCast DEBUG> Epoche 58: Train MSE=0.001759, Val MSE=0.002690, Val MAE=0.029392, Val MedAE=0.016720, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:28.410 1: SolCast DEBUG> Epoche 59: Train MSE=0.001704, Val MSE=0.002632, Val MAE=0.029109, Val MedAE=0.016686, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:34.691 1: SolCast DEBUG> Epoche 100: Train MSE=0.001704, Val MSE=0.001681, Val MAE=0.026853, Val MedAE=0.019229, Bit_Fail=1
2026.01.01 18:27:39.980 1: SolCast DEBUG> Epoche 133: Train MSE=0.000733, Val MSE=0.001267, Val MAE=0.023793, Val MedAE=0.017436, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 18:27:40.226 1: SolCast DEBUG> Epoche 134: Train MSE=0.000722, Val MSE=0.001247, Val MAE=0.023624, Val MedAE=0.017294, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.470 1: SolCast DEBUG> Epoche 135: Train MSE=0.000710, Val MSE=0.001225, Val MAE=0.023450, Val MedAE=0.017111, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.655 1: SolCast DEBUG> Epoche 136: Train MSE=0.000698, Val MSE=0.001204, Val MAE=0.023271, Val MedAE=0.017081, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.821 1: SolCast DEBUG> Epoche 137: Train MSE=0.000686, Val MSE=0.001182, Val MAE=0.023085, Val MedAE=0.017060, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.979 1: SolCast DEBUG> Epoche 138: Train MSE=0.000674, Val MSE=0.001160, Val MAE=0.022895, Val MedAE=0.016883, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:41.140 1: SolCast DEBUG> Epoche 139: Train MSE=0.000661, Val MSE=0.001138, Val MAE=0.022701, Val MedAE=0.016711, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:41.929 1: SolCast DEBUG> Epoche 144: Train MSE=0.000598, Val MSE=0.000999, Val MAE=0.021734, Val MedAE=0.016540, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.090 1: SolCast DEBUG> Epoche 145: Train MSE=0.000586, Val MSE=0.000978, Val MAE=0.021522, Val MedAE=0.016349, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.280 1: SolCast DEBUG> Epoche 146: Train MSE=0.000574, Val MSE=0.000958, Val MAE=0.021306, Val MedAE=0.016107, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.459 1: SolCast DEBUG> Epoche 147: Train MSE=0.000562, Val MSE=0.000937, Val MAE=0.021088, Val MedAE=0.015901, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.613 1: SolCast DEBUG> Epoche 148: Train MSE=0.000550, Val MSE=0.000918, Val MAE=0.020870, Val MedAE=0.015669, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.760 1: SolCast DEBUG> Epoche 149: Train MSE=0.000539, Val MSE=0.000898, Val MAE=0.020654, Val MedAE=0.015555, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.090 1: SolCast DEBUG> Epoche 151: Train MSE=0.000519, Val MSE=0.000853, Val MAE=0.020213, Val MedAE=0.015324, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.274 1: SolCast DEBUG> Epoche 152: Train MSE=0.000508, Val MSE=0.000834, Val MAE=0.019989, Val MedAE=0.015218, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.427 1: SolCast DEBUG> Epoche 153: Train MSE=0.000498, Val MSE=0.000815, Val MAE=0.019775, Val MedAE=0.015098, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.588 1: SolCast DEBUG> Epoche 154: Train MSE=0.000489, Val MSE=0.000798, Val MAE=0.019572, Val MedAE=0.015089, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.765 1: SolCast DEBUG> Epoche 155: Train MSE=0.000480, Val MSE=0.000781, Val MAE=0.019377, Val MedAE=0.014943, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.922 1: SolCast DEBUG> Epoche 156: Train MSE=0.000471, Val MSE=0.000765, Val MAE=0.019192, Val MedAE=0.014814, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:44.099 1: SolCast DEBUG> Epoche 157: Train MSE=0.000463, Val MSE=0.000750, Val MAE=0.019017, Val MedAE=0.014635, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:44.451 1: SolCast DEBUG> Epoche 159: Train MSE=0.000448, Val MSE=0.000722, Val MAE=0.018698, Val MedAE=0.014553, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:45.216 1: SolCast DEBUG> Epoche 164: Train MSE=0.000417, Val MSE=0.000649, Val MAE=0.018205, Val MedAE=0.014516, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 18:27:45.399 1: SolCast DEBUG> Epoche 165: Train MSE=0.000412, Val MSE=0.000640, Val MAE=0.018099, Val MedAE=0.014421, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:45.558 1: SolCast DEBUG> Epoche 166: Train MSE=0.000407, Val MSE=0.000632, Val MAE=0.017999, Val MedAE=0.014286, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:45.726 1: SolCast DEBUG> Epoche 167: Train MSE=0.000402, Val MSE=0.000624, Val MAE=0.017906, Val MedAE=0.014177, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:45.885 1: SolCast DEBUG> Epoche 168: Train MSE=0.000398, Val MSE=0.000617, Val MAE=0.017820, Val MedAE=0.014094, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:46.051 1: SolCast DEBUG> Epoche 169: Train MSE=0.000394, Val MSE=0.000610, Val MAE=0.017740, Val MedAE=0.014051, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:50.636 1: SolCast DEBUG> Epoche 200: Train MSE=0.000394, Val MSE=0.000539, Val MAE=0.016987, Val MedAE=0.013961, Bit_Fail=0
2026.01.01 18:27:50.644 1: SolCast DEBUG> Epoche 200: Train MSE=0.000340, Val MSE=0.000539, Val MAE=0.016987, Val MedAE=0.013961, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:51.095 1: SolCast DEBUG> Epoche 203: Train MSE=0.000338, Val MSE=0.000538, Val MAE=0.016940, Val MedAE=0.013888, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:55.790 1: SolCast DEBUG> Epoche 233: Train MSE=0.000321, Val MSE=0.000535, Val MAE=0.016852, Val MedAE=0.013875, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:03.726 1: SolCast DEBUG> Epoche 281: Train MSE=0.000308, Val MSE=0.000524, Val MAE=0.016435, Val MedAE=0.013831, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:04.363 1: SolCast DEBUG> Epoche 285: Train MSE=0.000307, Val MSE=0.000523, Val MAE=0.016426, Val MedAE=0.013765, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:06.794 1: SolCast DEBUG> Epoche 300: Train MSE=0.000307, Val MSE=0.000550, Val MAE=0.017907, Val MedAE=0.015240, Bit_Fail=0
2026.01.01 18:28:08.309 1: SolCast DEBUG> Epoche 310: Train MSE=0.000306, Val MSE=0.000520, Val MAE=0.016274, Val MedAE=0.013632, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:08.614 1: SolCast DEBUG> Epoche 312: Train MSE=0.000305, Val MSE=0.000519, Val MAE=0.016257, Val MedAE=0.013585, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:09.360 1: SolCast DEBUG> Epoche 317: Train MSE=0.000304, Val MSE=0.000518, Val MAE=0.016235, Val MedAE=0.013539, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:18.741 1: SolCast DEBUG> Epoche 370: Train MSE=0.000293, Val MSE=0.000514, Val MAE=0.016166, Val MedAE=0.013205, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:23.398 1: SolCast DEBUG> Epoche 400: Train MSE=0.000293, Val MSE=0.000498, Val MAE=0.016166, Val MedAE=0.013530, Bit_Fail=0
2026.01.01 18:28:27.156 1: SolCast DEBUG> Epoche 420: Train MSE=0.000286, Val MSE=0.000497, Val MAE=0.015836, Val MedAE=0.012658, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:27.956 1: SolCast DEBUG> Epoche 424: Train MSE=0.000286, Val MSE=0.000496, Val MAE=0.015803, Val MedAE=0.012630, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:28.927 1: SolCast DEBUG> Epoche 429: Train MSE=0.000285, Val MSE=0.000495, Val MAE=0.015779, Val MedAE=0.012568, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:37.533 1: SolCast DEBUG> Epoche 470: Train MSE=0.000278, Val MSE=0.000490, Val MAE=0.015754, Val MedAE=0.012467, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:44.668 1: SolCast DEBUG> Epoche 500: Train MSE=0.000278, Val MSE=0.000512, Val MAE=0.015775, Val MedAE=0.011966, Bit_Fail=0
2026.01.01 18:28:49.391 1: SolCast DEBUG> Epoche 520: Train MSE=0.000270, Val MSE=0.000477, Val MAE=0.015651, Val MedAE=0.012339, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:53.585 1: SolCast DEBUG> Epoche 539: Train MSE=0.000270, Val MSE=0.000475, Val MAE=0.015648, Val MedAE=0.012191, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:05.842 1: SolCast DEBUG> Epoche 590: Train MSE=0.000265, Val MSE=0.000474, Val MAE=0.015526, Val MedAE=0.012056, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:08.065 1: SolCast DEBUG> Epoche 600: Train MSE=0.000265, Val MSE=0.000468, Val MAE=0.015894, Val MedAE=0.012751, Bit_Fail=0
2026.01.01 18:29:28.474 1: SolCast DEBUG> Epoche 690: Train MSE=0.000256, Val MSE=0.000470, Val MAE=0.015276, Val MedAE=0.011856, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:30.383 1: SolCast DEBUG> Epoche 699: Train MSE=0.000255, Val MSE=0.000467, Val MAE=0.015250, Val MedAE=0.011836, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:30.639 1: SolCast DEBUG> Epoche 700: Train MSE=0.000255, Val MSE=0.000478, Val MAE=0.016548, Val MedAE=0.013898, Bit_Fail=0
2026.01.01 18:29:52.830 1: SolCast DEBUG> Epoche 800: Train MSE=0.000255, Val MSE=0.000465, Val MAE=0.016306, Val MedAE=0.013391, Bit_Fail=0
2026.01.01 18:30:04.934 1: SolCast DEBUG> Epoche 850: Train MSE=0.000244, Val MSE=0.000461, Val MAE=0.015129, Val MedAE=0.011815, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:30:17.777 1: SolCast DEBUG> Epoche 900: Train MSE=0.000244, Val MSE=0.000448, Val MAE=0.015585, Val MedAE=0.012575, Bit_Fail=0
2026.01.01 18:30:40.850 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000244, Val MSE=0.000450, Val MAE=0.015295, Val MedAE=0.012324, Bit_Fail=0
2026.01.01 18:30:56.457 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000244, Val MSE=0.000443, Val MAE=0.015695, Val MedAE=0.012932, Bit_Fail=0
2026.01.01 18:31:07.100 1: SolCast DEBUG> Epoche 1160: Train MSE=0.000229, Val MSE=0.000432, Val MAE=0.014957, Val MedAE=0.011802, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:31:13.278 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000229, Val MSE=0.000439, Val MAE=0.015822, Val MedAE=0.012868, Bit_Fail=0
2026.01.01 18:31:29.055 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000229, Val MSE=0.000435, Val MAE=0.015613, Val MedAE=0.012747, Bit_Fail=0
2026.01.01 18:31:43.689 1: SolCast DEBUG> Epoche 1390: Train MSE=0.000219, Val MSE=0.000426, Val MAE=0.014936, Val MedAE=0.011470, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:31:45.625 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000219, Val MSE=0.000414, Val MAE=0.014586, Val MedAE=0.011035, Bit_Fail=0
2026.01.01 18:31:45.635 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000218, Val MSE=0.000414, Val MAE=0.014586, Val MedAE=0.011035, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:32:02.161 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000218, Val MSE=0.000449, Val MAE=0.016432, Val MedAE=0.013464, Bit_Fail=0
2026.01.01 18:32:18.086 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000218, Val MSE=0.000403, Val MAE=0.014934, Val MedAE=0.011695, Bit_Fail=0
2026.01.01 18:32:32.114 1: SolCast DEBUG> Epoche 1690: Train MSE=0.000209, Val MSE=0.000404, Val MAE=0.014320, Val MedAE=0.010320, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:32:33.832 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000209, Val MSE=0.000428, Val MAE=0.016037, Val MedAE=0.012994, Bit_Fail=0
2026.01.01 18:32:49.865 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000209, Val MSE=0.000410, Val MAE=0.015653, Val MedAE=0.012577, Bit_Fail=0
2026.01.01 18:33:02.182 1: SolCast DEBUG> Epoche 1870: Train MSE=0.000205, Val MSE=0.000383, Val MAE=0.014067, Val MedAE=0.010133, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:33:06.890 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000205, Val MSE=0.000376, Val MAE=0.014446, Val MedAE=0.011115, Bit_Fail=0
2026.01.01 18:33:22.858 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000205, Val MSE=0.000368, Val MAE=0.014258, Val MedAE=0.010752, Bit_Fail=0
2026.01.01 18:33:38.578 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000205, Val MSE=0.000440, Val MAE=0.016680, Val MedAE=0.014515, Bit_Fail=0
2026.01.01 18:33:41.611 1: SolCast DEBUG> Epoche 2120: Train MSE=0.000198, Val MSE=0.000367, Val MAE=0.013801, Val MedAE=0.009661, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:33:54.354 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000198, Val MSE=0.000417, Val MAE=0.016140, Val MedAE=0.013713, Bit_Fail=0
2026.01.01 18:34:11.686 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000198, Val MSE=0.000362, Val MAE=0.014348, Val MedAE=0.010921, Bit_Fail=0
2026.01.01 18:34:18.148 1: SolCast DEBUG> Epoche 2340: Train MSE=0.000195, Val MSE=0.000356, Val MAE=0.013592, Val MedAE=0.009300, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:34:27.489 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000195, Val MSE=0.000355, Val MAE=0.014051, Val MedAE=0.010411, Bit_Fail=0
2026.01.01 18:34:43.305 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000195, Val MSE=0.000349, Val MAE=0.013577, Val MedAE=0.009666, Bit_Fail=0
2026.01.01 18:34:58.973 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000195, Val MSE=0.000377, Val MAE=0.015170, Val MedAE=0.012456, Bit_Fail=0
2026.01.01 18:35:15.415 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000195, Val MSE=0.000340, Val MAE=0.013970, Val MedAE=0.010876, Bit_Fail=0
2026.01.01 18:35:32.017 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000195, Val MSE=0.000382, Val MAE=0.015341, Val MedAE=0.012854, Bit_Fail=0
2026.01.01 18:35:47.827 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000195, Val MSE=0.000328, Val MAE=0.013411, Val MedAE=0.009790, Bit_Fail=0
2026.01.01 18:35:52.375 1: SolCast DEBUG> Epoche 2931: Train MSE=0.000186, Val MSE=0.000331, Val MAE=0.013276, Val MedAE=0.009297, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:04.885 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000186, Val MSE=0.000333, Val MAE=0.013785, Val MedAE=0.010478, Bit_Fail=0
2026.01.01 18:36:20.725 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000186, Val MSE=0.000329, Val MAE=0.013228, Val MedAE=0.009287, Bit_Fail=0
2026.01.01 18:36:20.735 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000184, Val MSE=0.000329, Val MAE=0.013228, Val MedAE=0.009287, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:34.489 1: SolCast DEBUG> Epoche 3180: Train MSE=0.000182, Val MSE=0.000327, Val MAE=0.013125, Val MedAE=0.008939, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:38.029 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000182, Val MSE=0.000320, Val MAE=0.013228, Val MedAE=0.009632, Bit_Fail=0
2026.01.01 18:36:45.842 1: SolCast DEBUG> Epoche 3250: Train MSE=0.000183, Val MSE=0.000323, Val MAE=0.013096, Val MedAE=0.008886, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:53.303 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000183, Val MSE=0.000320, Val MAE=0.013318, Val MedAE=0.009760, Bit_Fail=0
2026.01.01 18:37:09.545 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000183, Val MSE=0.000327, Val MAE=0.013922, Val MedAE=0.011272, Bit_Fail=0
2026.01.01 18:37:24.189 1: SolCast DEBUG> Epoche 3490: Train MSE=0.000180, Val MSE=0.000319, Val MAE=0.013041, Val MedAE=0.008820, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:37:25.723 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000180, Val MSE=0.000323, Val MAE=0.013588, Val MedAE=0.010386, Bit_Fail=0
2026.01.01 18:37:47.590 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000180, Val MSE=0.000323, Val MAE=0.013730, Val MedAE=0.010947, Bit_Fail=0
2026.01.01 18:37:53.258 1: SolCast DEBUG> Epoche 3630: Train MSE=0.000178, Val MSE=0.000318, Val MAE=0.012948, Val MedAE=0.008677, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:38:09.034 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000178, Val MSE=0.000312, Val MAE=0.013378, Val MedAE=0.010497, Bit_Fail=0
2026.01.01 18:38:30.192 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000178, Val MSE=0.000312, Val MAE=0.013379, Val MedAE=0.010674, Bit_Fail=0
2026.01.01 18:38:52.224 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000178, Val MSE=0.000318, Val MAE=0.012933, Val MedAE=0.008471, Bit_Fail=0
2026.01.01 18:39:13.603 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000178, Val MSE=0.000306, Val MAE=0.013228, Val MedAE=0.010395, Bit_Fail=0
2026.01.01 18:39:34.047 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000178, Val MSE=0.000318, Val MAE=0.013793, Val MedAE=0.011333, Bit_Fail=0
2026.01.01 18:39:54.812 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000178, Val MSE=0.000309, Val MAE=0.013388, Val MedAE=0.010831, Bit_Fail=0
2026.01.01 18:40:02.202 1: SolCast DEBUG> Epoche 4230: Train MSE=0.000175, Val MSE=0.000309, Val MAE=0.012845, Val MedAE=0.008584, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:40:16.021 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000175, Val MSE=0.000303, Val MAE=0.013012, Val MedAE=0.009822, Bit_Fail=0
2026.01.01 18:40:34.355 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000175, Val MSE=0.000310, Val MAE=0.012884, Val MedAE=0.008766, Bit_Fail=0
2026.01.01 18:40:57.218 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000175, Val MSE=0.000302, Val MAE=0.013128, Val MedAE=0.010345, Bit_Fail=0
2026.01.01 18:41:22.220 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000175, Val MSE=0.000302, Val MAE=0.013191, Val MedAE=0.010385, Bit_Fail=0
2026.01.01 18:41:43.986 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000175, Val MSE=0.000301, Val MAE=0.013269, Val MedAE=0.010709, Bit_Fail=0
2026.01.01 18:42:05.591 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000175, Val MSE=0.000327, Val MAE=0.012984, Val MedAE=0.008358, Bit_Fail=0
2026.01.01 18:42:28.817 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000175, Val MSE=0.000300, Val MAE=0.013196, Val MedAE=0.010534, Bit_Fail=0
2026.01.01 18:42:51.092 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000175, Val MSE=0.000298, Val MAE=0.013025, Val MedAE=0.010142, Bit_Fail=0
2026.01.01 18:43:13.597 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000175, Val MSE=0.000296, Val MAE=0.012895, Val MedAE=0.009981, Bit_Fail=0
2026.01.01 18:43:36.900 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000175, Val MSE=0.000298, Val MAE=0.012955, Val MedAE=0.009983, Bit_Fail=0
2026.01.01 18:43:58.243 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000175, Val MSE=0.000305, Val MAE=0.013474, Val MedAE=0.010999, Bit_Fail=0
2026.01.01 18:44:20.399 1: SolCast DEBUG> Epoche 5400: Train MSE=0.000175, Val MSE=0.000296, Val MAE=0.012941, Val MedAE=0.009892, Bit_Fail=0
2026.01.01 18:44:37.326 1: SolCast DEBUG> Epoche 5500: Train MSE=0.000175, Val MSE=0.000301, Val MAE=0.013345, Val MedAE=0.010900, Bit_Fail=0
2026.01.01 18:44:53.049 1: SolCast DEBUG> Epoche 5600: Train MSE=0.000175, Val MSE=0.000297, Val MAE=0.012997, Val MedAE=0.010176, Bit_Fail=0
2026.01.01 18:45:10.274 1: SolCast DEBUG> Epoche 5700: Train MSE=0.000175, Val MSE=0.000303, Val MAE=0.013484, Val MedAE=0.011050, Bit_Fail=0
2026.01.01 18:45:27.329 1: SolCast DEBUG> Epoche 5800: Train MSE=0.000175, Val MSE=0.000300, Val MAE=0.013419, Val MedAE=0.011095, Bit_Fail=0
2026.01.01 18:45:42.673 1: SolCast DEBUG> Epoche 5900: Train MSE=0.000175, Val MSE=0.000295, Val MAE=0.013058, Val MedAE=0.010464, Bit_Fail=0
2026.01.01 18:45:59.007 1: SolCast DEBUG> Epoche 6000: Train MSE=0.000175, Val MSE=0.000299, Val MAE=0.012793, Val MedAE=0.009330, Bit_Fail=0
2026.01.01 18:46:14.775 1: SolCast DEBUG> Epoche 6100: Train MSE=0.000175, Val MSE=0.000294, Val MAE=0.013040, Val MedAE=0.010396, Bit_Fail=0
2026.01.01 18:46:29.912 1: SolCast DEBUG> Epoche 6200: Train MSE=0.000175, Val MSE=0.000305, Val MAE=0.013656, Val MedAE=0.011383, Bit_Fail=0
2026.01.01 18:46:34.543 1: SolCast DEBUG> Early stopping bei Epoche 6230 (no improvement since 2000 epochs)
2026.01.01 18:46:34.546 1: === Snapshot-Statistik ===
2026.01.01 18:46:34.547 1: Metric-Improvement Snapshots: 63 (letzte Epoche: 4230)
2026.01.01 18:46:34.549 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 164)
2026.01.01 18:46:34.552 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 18:46:34.559 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 4230: Train MSE=0.000175, Val MSE=0.000309, Val MAE=0.012845, Val MedAE=0.008584, Bit_Fail=0,
2026.01.01 18:46:34.561 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 18:46:34.602 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000175, Validation MSE=0.000309, Validation Bit_Fail=0
2026.01.01 18:46:34.605 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000175
Val MSE=0.000309
Val Mean=0.0003042089
VAL/TRAIN MSE Ratio=1.763249 (limit=2.5)
Diff=0.000134 (limit=0.005)
ValStd=0.0000076839 (limit=7.60522365479913e-05)
-- At Original Scale: --
MAE=211.576764064665
RMSE/MAE=1.3694 (limit=1.5)
Slope=0.935893 (limit=0.7 .. 1.3)
Bias=4.36 (limit=+-105.788382032332)
R2=0.890528595577006
P95=585.8856 (limit=846.307056258658)
P99=968.7970 (limit=1692.61411251732)
-- Robustness Indicators: --
RMSE relative=62 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 18:46:34.613 1: SolCast DEBUG> Retry attempt 2 with Seed=16325084
2026.01.01 18:46:34.619 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 18:46:34.804 1: SolCast DEBUG> Epoche 1: Train MSE=0.002232, Val MSE=0.002836, Val MAE=0.031928, Val MedAE=0.027901, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 18:46:35.250 1: SolCast DEBUG> Epoche 4: Train MSE=0.002191, Val MSE=0.002835, Val MAE=0.031923, Val MedAE=0.027895, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:35.703 1: SolCast DEBUG> Epoche 7: Train MSE=0.002187, Val MSE=0.002834, Val MAE=0.031919, Val MedAE=0.027892, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:42.846 1: SolCast DEBUG> Epoche 54: Train MSE=0.002012, Val MSE=0.002830, Val MAE=0.030056, Val MedAE=0.024398, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:42.997 1: SolCast DEBUG> Epoche 55: Train MSE=0.001999, Val MSE=0.002816, Val MAE=0.029980, Val MedAE=0.024096, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.151 1: SolCast DEBUG> Epoche 56: Train MSE=0.001984, Val MSE=0.002799, Val MAE=0.029892, Val MedAE=0.023790, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.302 1: SolCast DEBUG> Epoche 57: Train MSE=0.001966, Val MSE=0.002780, Val MAE=0.029791, Val MedAE=0.023427, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.459 1: SolCast DEBUG> Epoche 58: Train MSE=0.001945, Val MSE=0.002756, Val MAE=0.029676, Val MedAE=0.022958, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.623 1: SolCast DEBUG> Epoche 59: Train MSE=0.001920, Val MSE=0.002728, Val MAE=0.029540, Val MedAE=0.022374, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:44.667 1: SolCast DEBUG> Epoche 65: Train MSE=0.001639, Val MSE=0.002678, Val MAE=0.029156, Val MedAE=0.016122, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:50.165 1: SolCast DEBUG> Epoche 100: Train MSE=0.001639, Val MSE=0.001617, Val MAE=0.027389, Val MedAE=0.021329, Bit_Fail=1
2026.01.01 18:46:57.117 1: SolCast DEBUG> Epoche 140: Train MSE=0.000582, Val MSE=0.000982, Val MAE=0.021762, Val MedAE=0.016481, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 18:46:57.374 1: SolCast DEBUG> Epoche 141: Train MSE=0.000571, Val MSE=0.000963, Val MAE=0.021553, Val MedAE=0.016314, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:57.625 1: SolCast DEBUG> Epoche 142: Train MSE=0.000559, Val MSE=0.000944, Val MAE=0.021340, Val MedAE=0.015998, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:57.814 1: SolCast DEBUG> Epoche 143: Train MSE=0.000548, Val MSE=0.000925, Val MAE=0.021128, Val MedAE=0.015847, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.048 1: SolCast DEBUG> Epoche 144: Train MSE=0.000537, Val MSE=0.000906, Val MAE=0.020921, Val MedAE=0.015525, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.217 1: SolCast DEBUG> Epoche 145: Train MSE=0.000526, Val MSE=0.000888, Val MAE=0.020716, Val MedAE=0.015427, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.387 1: SolCast DEBUG> Epoche 146: Train MSE=0.000516, Val MSE=0.000871, Val MAE=0.020515, Val MedAE=0.015357, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.797 1: SolCast DEBUG> Epoche 148: Train MSE=0.000497, Val MSE=0.000838, Val MAE=0.020132, Val MedAE=0.015318, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.986 1: SolCast DEBUG> Epoche 149: Train MSE=0.000488, Val MSE=0.000822, Val MAE=0.019953, Val MedAE=0.015200, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.141 1: SolCast DEBUG> Epoche 150: Train MSE=0.000482, Val MSE=0.000817, Val MAE=0.019792, Val MedAE=0.015107, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.316 1: SolCast DEBUG> Epoche 151: Train MSE=0.000474, Val MSE=0.000802, Val MAE=0.019630, Val MedAE=0.014972, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.471 1: SolCast DEBUG> Epoche 152: Train MSE=0.000466, Val MSE=0.000788, Val MAE=0.019477, Val MedAE=0.014905, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.637 1: SolCast DEBUG> Epoche 153: Train MSE=0.000459, Val MSE=0.000775, Val MAE=0.019332, Val MedAE=0.014836, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.795 1: SolCast DEBUG> Epoche 154: Train MSE=0.000452, Val MSE=0.000763, Val MAE=0.019196, Val MedAE=0.014833, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.953 1: SolCast DEBUG> Epoche 155: Train MSE=0.000446, Val MSE=0.000751, Val MAE=0.019068, Val MedAE=0.014766, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.128 1: SolCast DEBUG> Epoche 156: Train MSE=0.000440, Val MSE=0.000740, Val MAE=0.018949, Val MedAE=0.014751, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.423 1: SolCast DEBUG> Epoche 157: Train MSE=0.000434, Val MSE=0.000729, Val MAE=0.018837, Val MedAE=0.014571, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.580 1: SolCast DEBUG> Epoche 158: Train MSE=0.000429, Val MSE=0.000719, Val MAE=0.018732, Val MedAE=0.014399, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.738 1: SolCast DEBUG> Epoche 159: Train MSE=0.000423, Val MSE=0.000710, Val MAE=0.018632, Val MedAE=0.014296, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 18:47:04.664 1: SolCast DEBUG> Epoche 185: Train MSE=0.000352, Val MSE=0.000570, Val MAE=0.017726, Val MedAE=0.014241, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:04.823 1: SolCast DEBUG> Epoche 186: Train MSE=0.000351, Val MSE=0.000568, Val MAE=0.017700, Val MedAE=0.014157, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:04.998 1: SolCast DEBUG> Epoche 187: Train MSE=0.000350, Val MSE=0.000567, Val MAE=0.017676, Val MedAE=0.014128, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:05.330 1: SolCast DEBUG> Epoche 189: Train MSE=0.000347, Val MSE=0.000565, Val MAE=0.017630, Val MedAE=0.014111, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:07.326 1: SolCast DEBUG> Epoche 200: Train MSE=0.000347, Val MSE=0.000560, Val MAE=0.017645, Val MedAE=0.014294, Bit_Fail=0
2026.01.01 18:47:08.430 1: SolCast DEBUG> Epoche 207: Train MSE=0.000336, Val MSE=0.000557, Val MAE=0.017581, Val MedAE=0.014098, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:08.925 1: SolCast DEBUG> Epoche 210: Train MSE=0.000332, Val MSE=0.000551, Val MAE=0.017149, Val MedAE=0.014015, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:09.251 1: SolCast DEBUG> Epoche 212: Train MSE=0.000331, Val MSE=0.000549, Val MAE=0.017106, Val MedAE=0.014013, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:09.543 1: SolCast DEBUG> Epoche 214: Train MSE=0.000330, Val MSE=0.000548, Val MAE=0.017079, Val MedAE=0.014009, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:19.704 1: SolCast DEBUG> Epoche 280: Train MSE=0.000312, Val MSE=0.000539, Val MAE=0.016444, Val MedAE=0.013594, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:22.914 1: SolCast DEBUG> Epoche 300: Train MSE=0.000312, Val MSE=0.000547, Val MAE=0.017776, Val MedAE=0.014873, Bit_Fail=0
2026.01.01 18:47:36.920 1: SolCast DEBUG> Epoche 390: Train MSE=0.000299, Val MSE=0.000534, Val MAE=0.016256, Val MedAE=0.013227, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:37.075 1: SolCast DEBUG> Epoche 391: Train MSE=0.000299, Val MSE=0.000533, Val MAE=0.016248, Val MedAE=0.013207, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:37.692 1: SolCast DEBUG> Epoche 395: Train MSE=0.000298, Val MSE=0.000532, Val MAE=0.016231, Val MedAE=0.013184, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:38.408 1: SolCast DEBUG> Epoche 400: Train MSE=0.000298, Val MSE=0.000533, Val MAE=0.016139, Val MedAE=0.013128, Bit_Fail=0
2026.01.01 18:47:43.011 1: SolCast DEBUG> Epoche 430: Train MSE=0.000294, Val MSE=0.000524, Val MAE=0.016053, Val MedAE=0.013160, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:53.755 1: SolCast DEBUG> Epoche 500: Train MSE=0.000294, Val MSE=0.000533, Val MAE=0.017601, Val MedAE=0.015372, Bit_Fail=0
2026.01.01 18:48:03.268 1: SolCast DEBUG> Epoche 560: Train MSE=0.000278, Val MSE=0.000499, Val MAE=0.015935, Val MedAE=0.013052, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:48:10.654 1: SolCast DEBUG> Epoche 600: Train MSE=0.000278, Val MSE=0.000497, Val MAE=0.016063, Val MedAE=0.013071, Bit_Fail=0
2026.01.01 18:48:17.120 1: SolCast DEBUG> Epoche 640: Train MSE=0.000270, Val MSE=0.000494, Val MAE=0.015925, Val MedAE=0.012746, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:48:26.254 1: SolCast DEBUG> Epoche 700: Train MSE=0.000270, Val MSE=0.000494, Val MAE=0.016121, Val MedAE=0.012865, Bit_Fail=0
2026.01.01 18:48:41.338 1: SolCast DEBUG> Epoche 800: Train MSE=0.000270, Val MSE=0.000496, Val MAE=0.016486, Val MedAE=0.013111, Bit_Fail=0
2026.01.01 18:48:50.270 1: SolCast DEBUG> Epoche 860: Train MSE=0.000251, Val MSE=0.000491, Val MAE=0.015786, Val MedAE=0.012241, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:48:56.298 1: SolCast DEBUG> Epoche 900: Train MSE=0.000251, Val MSE=0.000539, Val MAE=0.017781, Val MedAE=0.014813, Bit_Fail=0
2026.01.01 18:49:00.767 1: openMeteo - Open-Meteo API server response: start_SSL https://api.open-meteo.com:443 timed out
2026.01.01 18:49:11.666 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000251, Val MSE=0.000487, Val MAE=0.015740, Val MedAE=0.012296, Bit_Fail=0
2026.01.01 18:49:28.665 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000251, Val MSE=0.000491, Val MAE=0.015728, Val MedAE=0.012462, Bit_Fail=0
2026.01.01 18:49:39.207 1: SolCast DEBUG> Epoche 1168: Train MSE=0.000235, Val MSE=0.000479, Val MAE=0.015557, Val MedAE=0.012237, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:49:44.096 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000235, Val MSE=0.000477, Val MAE=0.015613, Val MedAE=0.012266, Bit_Fail=0
2026.01.01 18:49:59.330 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000235, Val MSE=0.000469, Val MAE=0.015970, Val MedAE=0.012473, Bit_Fail=0
2026.01.01 18:50:02.607 1: SolCast DEBUG> Epoche 1320: Train MSE=0.000230, Val MSE=0.000474, Val MAE=0.015490, Val MedAE=0.011887, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:50:15.063 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000230, Val MSE=0.000469, Val MAE=0.016083, Val MedAE=0.012479, Bit_Fail=0
2026.01.01 18:50:31.357 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000230, Val MSE=0.000461, Val MAE=0.015731, Val MedAE=0.012435, Bit_Fail=0
2026.01.01 18:50:43.405 1: SolCast DEBUG> Epoche 1570: Train MSE=0.000219, Val MSE=0.000452, Val MAE=0.015217, Val MedAE=0.011832, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:50:48.687 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000219, Val MSE=0.000452, Val MAE=0.015676, Val MedAE=0.012380, Bit_Fail=0
2026.01.01 18:51:00.785 1: SolCast DEBUG> Epoche 1680: Train MSE=0.000216, Val MSE=0.000447, Val MAE=0.015153, Val MedAE=0.011761, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:02.263 1: SolCast DEBUG> Epoche 1690: Train MSE=0.000215, Val MSE=0.000446, Val MAE=0.015014, Val MedAE=0.011740, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:03.808 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000215, Val MSE=0.000444, Val MAE=0.015548, Val MedAE=0.012346, Bit_Fail=0
2026.01.01 18:51:19.267 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000215, Val MSE=0.000456, Val MAE=0.016255, Val MedAE=0.012272, Bit_Fail=0
2026.01.01 18:51:28.478 1: SolCast DEBUG> Epoche 1860: Train MSE=0.000211, Val MSE=0.000430, Val MAE=0.014967, Val MedAE=0.011675, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:32.128 1: SolCast DEBUG> Epoche 1885: Train MSE=0.000210, Val MSE=0.000429, Val MAE=0.014936, Val MedAE=0.011634, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:34.991 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000210, Val MSE=0.000431, Val MAE=0.015557, Val MedAE=0.012006, Bit_Fail=0
2026.01.01 18:51:36.961 1: SolCast DEBUG> Epoche 1910: Train MSE=0.000209, Val MSE=0.000427, Val MAE=0.014927, Val MedAE=0.011633, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:44.135 1: SolCast DEBUG> Epoche 1950: Train MSE=0.000207, Val MSE=0.000425, Val MAE=0.014852, Val MedAE=0.011568, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:51.659 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000207, Val MSE=0.000419, Val MAE=0.015028, Val MedAE=0.011705, Bit_Fail=0
2026.01.01 18:52:07.280 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000207, Val MSE=0.000419, Val MAE=0.015127, Val MedAE=0.011801, Bit_Fail=0
2026.01.01 18:52:22.353 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000207, Val MSE=0.000409, Val MAE=0.014933, Val MedAE=0.011578, Bit_Fail=0
2026.01.01 18:52:25.518 1: SolCast DEBUG> Epoche 2220: Train MSE=0.000201, Val MSE=0.000401, Val MAE=0.014505, Val MedAE=0.011123, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:52:38.140 1: SolCast DEBUG> Epoche 2280: Train MSE=0.000200, Val MSE=0.000398, Val MAE=0.014426, Val MedAE=0.010998, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:52:40.466 1: SolCast DEBUG> Epoche 2290: Train MSE=0.000199, Val MSE=0.000397, Val MAE=0.014408, Val MedAE=0.010918, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:52:42.754 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000199, Val MSE=0.000395, Val MAE=0.014771, Val MedAE=0.011372, Bit_Fail=0
2026.01.01 18:53:06.020 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000199, Val MSE=0.000386, Val MAE=0.014179, Val MedAE=0.010473, Bit_Fail=0
2026.01.01 18:53:06.031 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000196, Val MSE=0.000386, Val MAE=0.014179, Val MedAE=0.010473, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:53:27.648 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000196, Val MSE=0.000394, Val MAE=0.015055, Val MedAE=0.011719, Bit_Fail=0
2026.01.01 18:53:48.669 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000196, Val MSE=0.000393, Val MAE=0.015223, Val MedAE=0.011833, Bit_Fail=0
2026.01.01 18:54:04.615 1: SolCast DEBUG> Epoche 2670: Train MSE=0.000190, Val MSE=0.000363, Val MAE=0.014023, Val MedAE=0.010343, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:10.539 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000190, Val MSE=0.000399, Val MAE=0.015520, Val MedAE=0.012166, Bit_Fail=0
2026.01.01 18:54:22.630 1: SolCast DEBUG> Epoche 2762: Train MSE=0.000188, Val MSE=0.000359, Val MAE=0.014009, Val MedAE=0.010303, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:28.642 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000188, Val MSE=0.000422, Val MAE=0.016216, Val MedAE=0.013541, Bit_Fail=0
2026.01.01 18:54:36.250 1: SolCast DEBUG> Epoche 2850: Train MSE=0.000187, Val MSE=0.000356, Val MAE=0.013892, Val MedAE=0.010014, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:37.817 1: SolCast DEBUG> Epoche 2860: Train MSE=0.000186, Val MSE=0.000353, Val MAE=0.013781, Val MedAE=0.009785, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:43.894 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000186, Val MSE=0.000373, Val MAE=0.014968, Val MedAE=0.011754, Bit_Fail=0
2026.01.01 18:54:51.665 1: SolCast DEBUG> Epoche 2950: Train MSE=0.000184, Val MSE=0.000350, Val MAE=0.013709, Val MedAE=0.009744, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:56.355 1: SolCast DEBUG> Epoche 2980: Train MSE=0.000185, Val MSE=0.000344, Val MAE=0.013542, Val MedAE=0.009640, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:59.391 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000185, Val MSE=0.000345, Val MAE=0.013771, Val MedAE=0.010299, Bit_Fail=0
2026.01.01 18:55:15.914 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000185, Val MSE=0.000338, Val MAE=0.013390, Val MedAE=0.009239, Bit_Fail=0
2026.01.01 18:55:15.920 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000183, Val MSE=0.000338, Val MAE=0.013390, Val MedAE=0.009239, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:55:31.223 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000183, Val MSE=0.000374, Val MAE=0.015348, Val MedAE=0.013113, Bit_Fail=0
2026.01.01 18:55:46.650 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000183, Val MSE=0.000395, Val MAE=0.015892, Val MedAE=0.013867, Bit_Fail=0
2026.01.01 18:55:55.663 1: SolCast DEBUG> Epoche 3360: Train MSE=0.000178, Val MSE=0.000336, Val MAE=0.013102, Val MedAE=0.009038, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:55:57.156 1: SolCast DEBUG> Epoche 3370: Train MSE=0.000178, Val MSE=0.000328, Val MAE=0.013027, Val MedAE=0.008576, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:56:01.837 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000178, Val MSE=0.000331, Val MAE=0.013966, Val MedAE=0.010989, Bit_Fail=0
2026.01.01 18:56:18.127 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000178, Val MSE=0.000317, Val MAE=0.013546, Val MedAE=0.010578, Bit_Fail=0
2026.01.01 18:56:33.705 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000178, Val MSE=0.000326, Val MAE=0.013924, Val MedAE=0.011087, Bit_Fail=0
2026.01.01 18:56:49.380 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000178, Val MSE=0.000313, Val MAE=0.013647, Val MedAE=0.011350, Bit_Fail=0
2026.01.01 18:57:04.360 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000178, Val MSE=0.000315, Val MAE=0.013759, Val MedAE=0.011353, Bit_Fail=0
2026.01.01 18:57:20.079 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000178, Val MSE=0.000317, Val MAE=0.013889, Val MedAE=0.011544, Bit_Fail=0
2026.01.01 18:57:36.568 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000178, Val MSE=0.000303, Val MAE=0.013266, Val MedAE=0.010514, Bit_Fail=0
2026.01.01 18:57:51.815 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000178, Val MSE=0.000297, Val MAE=0.013051, Val MedAE=0.010491, Bit_Fail=0
2026.01.01 18:58:07.665 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000178, Val MSE=0.000298, Val MAE=0.013165, Val MedAE=0.010657, Bit_Fail=0
2026.01.01 18:58:22.874 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000178, Val MSE=0.000299, Val MAE=0.012652, Val MedAE=0.009298, Bit_Fail=0
2026.01.01 18:58:39.872 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000178, Val MSE=0.000299, Val MAE=0.013357, Val MedAE=0.010952, Bit_Fail=0
2026.01.01 18:58:55.060 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000178, Val MSE=0.000293, Val MAE=0.012888, Val MedAE=0.010075, Bit_Fail=0
2026.01.01 18:59:10.645 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000178, Val MSE=0.000296, Val MAE=0.013170, Val MedAE=0.010801, Bit_Fail=0
2026.01.01 18:59:26.299 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000178, Val MSE=0.000289, Val MAE=0.012813, Val MedAE=0.010297, Bit_Fail=0
2026.01.01 18:59:41.390 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000178, Val MSE=0.000288, Val MAE=0.012730, Val MedAE=0.010022, Bit_Fail=0
2026.01.01 18:59:58.018 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000178, Val MSE=0.000288, Val MAE=0.012927, Val MedAE=0.010486, Bit_Fail=0
2026.01.01 19:00:16.580 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000178, Val MSE=0.000300, Val MAE=0.013538, Val MedAE=0.011570, Bit_Fail=0
2026.01.01 19:00:22.430 1: VRMAPI DEBUG> start add AI raw data for hour: 19
2026.01.01 19:00:22.434 1: VRMAPI DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.01.01 19:00:22.507 1: VRMAPI DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_VRMAPI
2026.01.01 19:00:23.036 1: SolCast DEBUG> start add AI raw data for hour: 19
2026.01.01 19:00:23.041 1: SolCast DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.01.01 19:00:23.490 1: SolCast DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_SolCast
2026.01.01 19:00:25.468 1: openMeteo DEBUG> start add AI raw data for hour: 19
2026.01.01 19:00:25.471 1: openMeteo DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.01.01 19:00:25.529 1: openMeteo DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_openMeteo
2026.01.01 19:00:36.434 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000178, Val MSE=0.000287, Val MAE=0.012656, Val MedAE=0.009749, Bit_Fail=0
2026.01.01 19:00:52.824 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000178, Val MSE=0.000315, Val MAE=0.014053, Val MedAE=0.012264, Bit_Fail=0
2026.01.01 19:01:08.326 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000178, Val MSE=0.000291, Val MAE=0.013064, Val MedAE=0.010484, Bit_Fail=0
2026.01.01 19:01:18.912 1: SolCast DEBUG> Early stopping bei Epoche 5370 (no improvement since 2000 epochs)
2026.01.01 19:01:18.914 1: === Snapshot-Statistik ===
2026.01.01 19:01:18.916 1: Metric-Improvement Snapshots: 64 (letzte Epoche: 3370)
2026.01.01 19:01:18.918 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 159)
2026.01.01 19:01:18.919 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 19:01:18.925 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 3370: Train MSE=0.000178, Val MSE=0.000328, Val MAE=0.013027, Val MedAE=0.008576, Bit_Fail=0,
2026.01.01 19:01:18.927 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 19:01:18.969 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000178, Validation MSE=0.000328, Validation Bit_Fail=0
2026.01.01 19:01:18.971 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000178
Val MSE=0.000328
Val Mean=0.0002956156
VAL/TRAIN MSE Ratio=1.837433 (limit=2.5)
Diff=0.000149 (limit=0.005)
ValStd=0.0000173294 (limit=7.39038913958514e-05)
-- At Original Scale: --
MAE=214.560321844596
RMSE/MAE=1.3893 (limit=1.5)
Slope=0.916647 (limit=0.7 .. 1.3)
Bias=2.25 (limit=+-107.280160922298)
R2=0.884124888835566
P95=585.2166 (limit=858.241287378382)
P99=942.9805 (limit=1716.48257475676)
-- Robustness Indicators: --
RMSE relative=64 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 19:01:18.979 1: SolCast DEBUG> Retry attempt 3 with Seed=16689959
2026.01.01 19:01:18.985 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 19:01:19.145 1: SolCast DEBUG> Epoche 1: Train MSE=0.002202, Val MSE=0.002839, Val MAE=0.031937, Val MedAE=0.027914, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 19:01:25.133 1: SolCast DEBUG> Epoche 40: Train MSE=0.002098, Val MSE=0.002825, Val MAE=0.031158, Val MedAE=0.027367, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:27.800 1: SolCast DEBUG> Epoche 57: Train MSE=0.001969, Val MSE=0.002810, Val MAE=0.029915, Val MedAE=0.021870, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:27.982 1: SolCast DEBUG> Epoche 58: Train MSE=0.001947, Val MSE=0.002786, Val MAE=0.029801, Val MedAE=0.021464, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.134 1: SolCast DEBUG> Epoche 59: Train MSE=0.001921, Val MSE=0.002758, Val MAE=0.029673, Val MedAE=0.020903, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.609 1: SolCast DEBUG> Epoche 62: Train MSE=0.001810, Val MSE=0.002716, Val MAE=0.029480, Val MedAE=0.017887, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.767 1: SolCast DEBUG> Epoche 63: Train MSE=0.001761, Val MSE=0.002660, Val MAE=0.029224, Val MedAE=0.017446, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.915 1: SolCast DEBUG> Epoche 64: Train MSE=0.001706, Val MSE=0.002597, Val MAE=0.028944, Val MedAE=0.016968, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:29.063 1: SolCast DEBUG> Epoche 65: Train MSE=0.001645, Val MSE=0.002528, Val MAE=0.028652, Val MedAE=0.016879, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:29.207 1: SolCast DEBUG> Epoche 66: Train MSE=0.001581, Val MSE=0.002455, Val MAE=0.028362, Val MedAE=0.016529, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:34.406 1: SolCast DEBUG> Epoche 100: Train MSE=0.001581, Val MSE=0.001674, Val MAE=0.026943, Val MedAE=0.019938, Bit_Fail=1
2026.01.01 19:01:41.897 1: SolCast DEBUG> Epoche 149: Train MSE=0.000574, Val MSE=0.000953, Val MAE=0.021557, Val MedAE=0.017213, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 19:01:43.755 1: SolCast DEBUG> Epoche 160: Train MSE=0.000466, Val MSE=0.000806, Val MAE=0.019501, Val MedAE=0.014848, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:43.926 1: SolCast DEBUG> Epoche 161: Train MSE=0.000458, Val MSE=0.000792, Val MAE=0.019351, Val MedAE=0.014777, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.118 1: SolCast DEBUG> Epoche 162: Train MSE=0.000451, Val MSE=0.000778, Val MAE=0.019209, Val MedAE=0.014629, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.334 1: SolCast DEBUG> Epoche 163: Train MSE=0.000444, Val MSE=0.000764, Val MAE=0.019075, Val MedAE=0.014565, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.504 1: SolCast DEBUG> Epoche 164: Train MSE=0.000438, Val MSE=0.000752, Val MAE=0.018948, Val MedAE=0.014360, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.716 1: SolCast DEBUG> Epoche 165: Train MSE=0.000432, Val MSE=0.000740, Val MAE=0.018829, Val MedAE=0.014227, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.952 1: SolCast DEBUG> Epoche 166: Train MSE=0.000426, Val MSE=0.000729, Val MAE=0.018714, Val MedAE=0.014165, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:45.151 1: SolCast DEBUG> Epoche 167: Train MSE=0.000421, Val MSE=0.000718, Val MAE=0.018605, Val MedAE=0.014070, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 19:01:45.311 1: SolCast DEBUG> Epoche 168: Train MSE=0.000416, Val MSE=0.000708, Val MAE=0.018500, Val MedAE=0.013993, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:45.475 1: SolCast DEBUG> Epoche 169: Train MSE=0.000411, Val MSE=0.000699, Val MAE=0.018400, Val MedAE=0.013928, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:50.312 1: SolCast DEBUG> Epoche 200: Train MSE=0.000411, Val MSE=0.000558, Val MAE=0.017252, Val MedAE=0.013991, Bit_Fail=0
2026.01.01 19:01:50.478 1: SolCast DEBUG> Epoche 201: Train MSE=0.000341, Val MSE=0.000558, Val MAE=0.017237, Val MedAE=0.013915, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:50.920 1: SolCast DEBUG> Epoche 204: Train MSE=0.000338, Val MSE=0.000557, Val MAE=0.017191, Val MedAE=0.013805, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:51.226 1: SolCast DEBUG> Epoche 206: Train MSE=0.000337, Val MSE=0.000556, Val MAE=0.017163, Val MedAE=0.013746, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:58.095 1: SolCast DEBUG> Epoche 250: Train MSE=0.000319, Val MSE=0.000554, Val MAE=0.016637, Val MedAE=0.013530, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:58.382 1: SolCast DEBUG> Epoche 252: Train MSE=0.000318, Val MSE=0.000553, Val MAE=0.016627, Val MedAE=0.013499, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:00.397 1: SolCast DEBUG> Epoche 266: Train MSE=0.000315, Val MSE=0.000552, Val MAE=0.016535, Val MedAE=0.013373, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:06.185 1: SolCast DEBUG> Epoche 300: Train MSE=0.000315, Val MSE=0.000521, Val MAE=0.016463, Val MedAE=0.014001, Bit_Fail=0
2026.01.01 19:02:17.223 1: SolCast DEBUG> Epoche 371: Train MSE=0.000296, Val MSE=0.000522, Val MAE=0.016217, Val MedAE=0.013366, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:21.515 1: SolCast DEBUG> Epoche 400: Train MSE=0.000296, Val MSE=0.000500, Val MAE=0.016347, Val MedAE=0.013895, Bit_Fail=0
2026.01.01 19:02:23.239 1: SolCast DEBUG> Epoche 410: Train MSE=0.000290, Val MSE=0.000518, Val MAE=0.016152, Val MedAE=0.013203, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:23.555 1: SolCast DEBUG> Epoche 412: Train MSE=0.000290, Val MSE=0.000517, Val MAE=0.016144, Val MedAE=0.013196, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:24.223 1: SolCast DEBUG> Epoche 416: Train MSE=0.000289, Val MSE=0.000516, Val MAE=0.016133, Val MedAE=0.013144, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:36.913 1: SolCast DEBUG> Epoche 500: Train MSE=0.000289, Val MSE=0.000513, Val MAE=0.016033, Val MedAE=0.012459, Bit_Fail=0
2026.01.01 19:02:36.920 1: SolCast DEBUG> Epoche 500: Train MSE=0.000274, Val MSE=0.000513, Val MAE=0.016033, Val MedAE=0.012459, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:37.941 1: SolCast DEBUG> Epoche 507: Train MSE=0.000273, Val MSE=0.000512, Val MAE=0.016016, Val MedAE=0.012419, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:52.279 1: SolCast DEBUG> Epoche 600: Train MSE=0.000273, Val MSE=0.000491, Val MAE=0.015793, Val MedAE=0.012659, Bit_Fail=0
2026.01.01 19:03:07.863 1: SolCast DEBUG> Epoche 700: Train MSE=0.000273, Val MSE=0.000531, Val MAE=0.017652, Val MedAE=0.014846, Bit_Fail=0
2026.01.01 19:03:22.755 1: SolCast DEBUG> Epoche 800: Train MSE=0.000273, Val MSE=0.000485, Val MAE=0.015777, Val MedAE=0.012388, Bit_Fail=0
2026.01.01 19:03:22.761 1: SolCast DEBUG> Epoche 800: Train MSE=0.000246, Val MSE=0.000485, Val MAE=0.015777, Val MedAE=0.012388, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:03:38.201 1: SolCast DEBUG> Epoche 900: Train MSE=0.000246, Val MSE=0.000489, Val MAE=0.015804, Val MedAE=0.012387, Bit_Fail=0
2026.01.01 19:03:53.934 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000246, Val MSE=0.000491, Val MAE=0.016320, Val MedAE=0.012996, Bit_Fail=0
2026.01.01 19:04:12.553 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000246, Val MSE=0.000500, Val MAE=0.016762, Val MedAE=0.013013, Bit_Fail=0
2026.01.01 19:04:29.863 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000246, Val MSE=0.000472, Val MAE=0.015815, Val MedAE=0.012588, Bit_Fail=0
2026.01.01 19:04:39.395 1: SolCast DEBUG> Epoche 1240: Train MSE=0.000226, Val MSE=0.000476, Val MAE=0.015690, Val MedAE=0.012238, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:04:44.449 1: SolCast DEBUG> Epoche 1260: Train MSE=0.000226, Val MSE=0.000472, Val MAE=0.015617, Val MedAE=0.012095, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:04:54.273 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000226, Val MSE=0.000469, Val MAE=0.015375, Val MedAE=0.012019, Bit_Fail=0
2026.01.01 19:04:54.283 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000225, Val MSE=0.000469, Val MAE=0.015375, Val MedAE=0.012019, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:05:19.860 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000225, Val MSE=0.000476, Val MAE=0.016232, Val MedAE=0.012583, Bit_Fail=0
2026.01.01 19:05:46.230 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000225, Val MSE=0.000460, Val MAE=0.015477, Val MedAE=0.012145, Bit_Fail=0
2026.01.01 19:06:01.555 1: SolCast DEBUG> Epoche 1560: Train MSE=0.000215, Val MSE=0.000450, Val MAE=0.015175, Val MedAE=0.011698, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:06:11.656 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000215, Val MSE=0.000446, Val MAE=0.015338, Val MedAE=0.011925, Bit_Fail=0
2026.01.01 19:06:19.086 1: SolCast DEBUG> Epoche 1630: Train MSE=0.000213, Val MSE=0.000443, Val MAE=0.015005, Val MedAE=0.011380, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:06:37.018 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000213, Val MSE=0.000456, Val MAE=0.016104, Val MedAE=0.012245, Bit_Fail=0
2026.01.01 19:06:41.728 1: SolCast DEBUG> Epoche 1720: Train MSE=0.000209, Val MSE=0.000437, Val MAE=0.014979, Val MedAE=0.011226, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:06:54.098 1: SolCast DEBUG> Epoche 1770: Train MSE=0.000208, Val MSE=0.000428, Val MAE=0.014866, Val MedAE=0.011051, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:01.420 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000208, Val MSE=0.000421, Val MAE=0.014909, Val MedAE=0.011181, Bit_Fail=0
2026.01.01 19:07:09.022 1: SolCast DEBUG> Epoche 1830: Train MSE=0.000206, Val MSE=0.000425, Val MAE=0.014835, Val MedAE=0.010975, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:18.661 1: SolCast DEBUG> Epoche 1870: Train MSE=0.000205, Val MSE=0.000422, Val MAE=0.014635, Val MedAE=0.010337, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:26.451 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000205, Val MSE=0.000421, Val MAE=0.015039, Val MedAE=0.011242, Bit_Fail=0
2026.01.01 19:07:35.709 1: SolCast DEBUG> Epoche 1950: Train MSE=0.000204, Val MSE=0.000412, Val MAE=0.014563, Val MedAE=0.010315, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:43.401 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000204, Val MSE=0.000478, Val MAE=0.017001, Val MedAE=0.013903, Bit_Fail=0
2026.01.01 19:07:59.225 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000204, Val MSE=0.000400, Val MAE=0.014424, Val MedAE=0.010221, Bit_Fail=0
2026.01.01 19:07:59.231 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000200, Val MSE=0.000400, Val MAE=0.014424, Val MedAE=0.010221, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:08:14.654 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000200, Val MSE=0.000399, Val MAE=0.014978, Val MedAE=0.011324, Bit_Fail=0
2026.01.01 19:08:28.453 1: SolCast DEBUG> Epoche 2290: Train MSE=0.000196, Val MSE=0.000390, Val MAE=0.014290, Val MedAE=0.009855, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:08:29.937 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000196, Val MSE=0.000391, Val MAE=0.014139, Val MedAE=0.009359, Bit_Fail=0
2026.01.01 19:08:46.992 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000196, Val MSE=0.000429, Val MAE=0.016088, Val MedAE=0.013370, Bit_Fail=0
2026.01.01 19:08:59.193 1: SolCast DEBUG> Epoche 2480: Train MSE=0.000193, Val MSE=0.000378, Val MAE=0.014148, Val MedAE=0.009492, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:09:02.241 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000193, Val MSE=0.000384, Val MAE=0.014816, Val MedAE=0.011437, Bit_Fail=0
2026.01.01 19:09:18.312 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000193, Val MSE=0.000373, Val MAE=0.014435, Val MedAE=0.010892, Bit_Fail=0
2026.01.01 19:09:27.592 1: SolCast DEBUG> Epoche 2660: Train MSE=0.000190, Val MSE=0.000367, Val MAE=0.013899, Val MedAE=0.009407, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:09:33.631 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000190, Val MSE=0.000364, Val MAE=0.014131, Val MedAE=0.010351, Bit_Fail=0
2026.01.01 19:09:50.479 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000190, Val MSE=0.000374, Val MAE=0.014829, Val MedAE=0.011905, Bit_Fail=0
2026.01.01 19:10:06.433 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000190, Val MSE=0.000358, Val MAE=0.013816, Val MedAE=0.009626, Bit_Fail=0
2026.01.01 19:10:17.130 1: SolCast DEBUG> Epoche 2970: Train MSE=0.000184, Val MSE=0.000354, Val MAE=0.013688, Val MedAE=0.009390, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:10:21.510 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000184, Val MSE=0.000376, Val MAE=0.015092, Val MedAE=0.012492, Bit_Fail=0
2026.01.01 19:10:37.294 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000184, Val MSE=0.000344, Val MAE=0.013896, Val MedAE=0.010700, Bit_Fail=0
2026.01.01 19:10:52.935 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000184, Val MSE=0.000340, Val MAE=0.013841, Val MedAE=0.010725, Bit_Fail=0
2026.01.01 19:11:09.459 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000184, Val MSE=0.000343, Val MAE=0.014114, Val MedAE=0.011228, Bit_Fail=0
2026.01.01 19:11:25.191 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000184, Val MSE=0.000329, Val MAE=0.013537, Val MedAE=0.010090, Bit_Fail=0
2026.01.01 19:11:40.627 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000184, Val MSE=0.000338, Val MAE=0.014317, Val MedAE=0.012038, Bit_Fail=0
2026.01.01 19:11:56.504 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000184, Val MSE=0.000338, Val MAE=0.014292, Val MedAE=0.011860, Bit_Fail=0
2026.01.01 19:12:13.062 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000184, Val MSE=0.000318, Val MAE=0.013443, Val MedAE=0.010655, Bit_Fail=0
2026.01.01 19:12:28.812 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000184, Val MSE=0.000314, Val MAE=0.013299, Val MedAE=0.010337, Bit_Fail=0
2026.01.01 19:12:44.335 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000184, Val MSE=0.000316, Val MAE=0.013177, Val MedAE=0.009737, Bit_Fail=0
2026.01.01 19:12:59.748 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000184, Val MSE=0.000344, Val MAE=0.014781, Val MedAE=0.012876, Bit_Fail=0
2026.01.01 19:13:16.661 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000184, Val MSE=0.000307, Val MAE=0.013173, Val MedAE=0.010441, Bit_Fail=0
2026.01.01 19:13:31.964 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000184, Val MSE=0.000338, Val MAE=0.013368, Val MedAE=0.008535, Bit_Fail=0
2026.01.01 19:13:31.971 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000173, Val MSE=0.000338, Val MAE=0.013368, Val MedAE=0.008535, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:13:47.873 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000173, Val MSE=0.000322, Val MAE=0.014152, Val MedAE=0.012068, Bit_Fail=0
2026.01.01 19:14:02.737 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000173, Val MSE=0.000317, Val MAE=0.013926, Val MedAE=0.011788, Bit_Fail=0
2026.01.01 19:14:18.079 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000173, Val MSE=0.000301, Val MAE=0.013120, Val MedAE=0.010500, Bit_Fail=0
2026.01.01 19:14:34.780 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000173, Val MSE=0.000300, Val MAE=0.013251, Val MedAE=0.011131, Bit_Fail=0
2026.01.01 19:14:50.749 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000173, Val MSE=0.000316, Val MAE=0.013979, Val MedAE=0.011920, Bit_Fail=0
2026.01.01 19:15:07.488 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000173, Val MSE=0.000298, Val MAE=0.013297, Val MedAE=0.011209, Bit_Fail=0
2026.01.01 19:15:24.075 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000173, Val MSE=0.000299, Val MAE=0.013338, Val MedAE=0.011219, Bit_Fail=0
2026.01.01 19:15:40.613 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000173, Val MSE=0.000301, Val MAE=0.012879, Val MedAE=0.009926, Bit_Fail=0
2026.01.01 19:15:57.651 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000173, Val MSE=0.000296, Val MAE=0.013288, Val MedAE=0.011301, Bit_Fail=0
2026.01.01 19:16:13.287 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000173, Val MSE=0.000299, Val MAE=0.013429, Val MedAE=0.011297, Bit_Fail=0
2026.01.01 19:16:29.416 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000173, Val MSE=0.000326, Val MAE=0.014362, Val MedAE=0.012558, Bit_Fail=0
2026.01.01 19:16:52.624 1: SolCast DEBUG> Epoche 5400: Train MSE=0.000173, Val MSE=0.000293, Val MAE=0.013008, Val MedAE=0.010932, Bit_Fail=0
2026.01.01 19:17:15.448 1: SolCast DEBUG> Epoche 5500: Train MSE=0.000173, Val MSE=0.000303, Val MAE=0.013566, Val MedAE=0.011497, Bit_Fail=0
2026.01.01 19:17:36.891 1: SolCast DEBUG> Epoche 5600: Train MSE=0.000173, Val MSE=0.000290, Val MAE=0.012844, Val MedAE=0.010516, Bit_Fail=0
2026.01.01 19:17:59.157 1: SolCast DEBUG> Epoche 5700: Train MSE=0.000173, Val MSE=0.000301, Val MAE=0.013589, Val MedAE=0.011589, Bit_Fail=0
2026.01.01 19:18:20.531 1: SolCast DEBUG> Epoche 5800: Train MSE=0.000173, Val MSE=0.000289, Val MAE=0.012913, Val MedAE=0.010712, Bit_Fail=0
2026.01.01 19:18:35.740 1: SolCast DEBUG> Epoche 5900: Train MSE=0.000173, Val MSE=0.000291, Val MAE=0.013056, Val MedAE=0.010867, Bit_Fail=0
2026.01.01 19:18:51.160 1: SolCast DEBUG> Epoche 6000: Train MSE=0.000173, Val MSE=0.000305, Val MAE=0.013648, Val MedAE=0.011687, Bit_Fail=0
2026.01.01 19:19:08.256 1: SolCast DEBUG> Epoche 6100: Train MSE=0.000173, Val MSE=0.000290, Val MAE=0.012878, Val MedAE=0.010646, Bit_Fail=0
2026.01.01 19:19:23.867 1: SolCast DEBUG> Epoche 6200: Train MSE=0.000173, Val MSE=0.000289, Val MAE=0.012900, Val MedAE=0.010677, Bit_Fail=0
2026.01.01 19:19:23.869 1: SolCast DEBUG> Early stopping bei Epoche 6200 (no improvement since 2000 epochs)
2026.01.01 19:19:23.871 1: === Snapshot-Statistik ===
2026.01.01 19:19:23.873 1: Metric-Improvement Snapshots: 47 (letzte Epoche: 4200)
2026.01.01 19:19:23.875 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 167)
2026.01.01 19:19:23.877 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 19:19:23.884 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 4200: Train MSE=0.000173, Val MSE=0.000338, Val MAE=0.013368, Val MedAE=0.008535, Bit_Fail=0,
2026.01.01 19:19:23.886 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 19:19:23.930 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000173, Validation MSE=0.000338, Validation Bit_Fail=0
2026.01.01 19:19:23.933 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000173
Val MSE=0.000338
Val Mean=0.0002966460
VAL/TRAIN MSE Ratio=1.953186 (limit=2.5)
Diff=0.000165 (limit=0.005)
ValStd=0.0000123896 (limit=7.41615117947988e-05)
-- At Original Scale: --
MAE=220.184381409254
RMSE/MAE=1.3759 (limit=1.5)
Slope=0.914758 (limit=0.7 .. 1.3)
Bias=-38.97 (limit=+-110.092190704627)
R2=0.880327221041415
P95=605.3179 (limit=880.737525637016)
P99=868.5353 (limit=1761.47505127403)
-- Robustness Indicators: --
RMSE relative=65 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 19:19:23.945 1: SolCast DEBUG> Best model after retries comes from Attempt=3 with:
Seed=16689959,
Model Slope=0.91,
Model Bias=-38.97,
VAL MedAE=140.59,
VAL MAE=220.18,
VAL RMSE=302.94,
VAL RMSE relative=65 %,
VAL RMSE_Rating=very bad,
VAL R2=0.88,
Val MSE=0.000338
</pre>
</div>
</div>

 

==== Auswertung der Trainingskennwerte ====

Abrufbar über:

<pre>
get <Name> valDecTree aiNeuralNetConState
</pre>

===== Modellparameter =====

{| class="wikitable"
! Kennwert !! Bedeutung
|-
| Normierungsgrenzen || Skalierung der Eingabedaten
|-
| Trainingsdaten || Anzahl der Datensätze (Training/Validierung)
|-
| Architektur || Inputs, Hidden Layers, Outputs
|-
| Hyperparameter || Learning Rate, Momentum, BitFail‑Limit
|-
| Aktivierungen || Hidden/Output‑Aktivierungsfunktionen
|-
| Zufallsgenerator || Shuffle‑Mode und Shuffle‑Periode
|}

===== Trainingsmetriken =====

{| class="wikitable"
! Kennwert !! Interpretation
|-
| bestes Modell bei Epoche || Zeitpunkt minimalen Validierungsfehlers
|-
| Training MSE / Validation MSE || Fehlermaße; sollten niedrig und ähnlich sein
|-
| Validation Bit_Fail || Anzahl fehlerhafter Klassifikationen
|-
| bester Trainingslauf || Lauf mit bestem Ergebnis
|-
| Trainingsbewertung || Qualitätsindikator (Varianz, Mittelwert)
|}

===== Fehlermaße der Prognosen =====

{| class="wikitable"
! Kennwert !! Bedeutung
|-
| MAE || mittlerer absoluter Fehler (Wh)
|-
| MedAE || medianer Fehler
|-
| RMSE || quadratischer Fehler, betont Ausreißer
|-
| MAPE || prozentualer Fehler
|-
| MdAPE || medianer prozentualer Fehler
|-
| R² || Gütemaß (0–1)
|}

===== Interpretation des Beispielmodells =====

Die Modellkennzahlen können nach ausgführten Training mit

get <Name> valDecTree aiNeuralNetConState

angezeigt werden. Eine Beispielausgabe sieht etwa so aus:

<pre>
letztes KI-Training: 25.12.2025 03:52:41 / Laufzeit in Sekunden: 1951
letzte KI-Ergebnis Generierungsdauer: 20.37 ms

=== Modellparameter ===

Normierungsgrenzen: PV=9276 W, Hausverbrauch: Min=0 W / Max=8937 W
Trainingsdaten: 7760 Datensätze (Training=6208, Validierung=1552)
Architektur: Inputs=41, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 8690 (von max. 15000)
Training MSE: 0.000
Validation MSE: 0.000
Validation Bit_Fail: 0
bester Trainingslauf: 2
Trainingsbewertung: ok (Val MSE Standard Deviation=0.000000, Val MSE Avg=0.000003)

=== Fehlermaße der Prognosen ===

MAE: 122.74 Wh
MedAE: 69.28 Wh
RMSE: 0.002
MAPE: 17.526 %
MdAPE: 10.611 %
R²: 0.847
</pre>

Die Interpretation dieser Daten wird im angezeigten Popup mit ausgegeben und ist diesem Fall:

* 7760 Datensätze → sehr gute Basis
* 80‑40‑20 Architektur → geeignet für komplexe Muster
* MSE ≈ 0 → exzellente Modellanpassung
* MAE 122 Wh → sehr präzise
* R² = 0.847 → hohe Erklärungsqualität

Das Modell ist stabil, generalisiert gut und liefert sehr brauchbare Prognosen.

 
==== DriftSlope – Bedeutung, Berechnung und Interpretation ====
🧩 '''Was ist DriftSlope?''' 

'''DriftSlope''' beschreibt, wie stark sich die Dynamik des Modells im Vergleich zur Realität verändert hat. 
Dynamik bedeutet hier: '''Wie stark steigen oder fallen die Werte im Verhältnis zueinander?'''

Ein Modell kann also:
* '''zu flach''' sein (reagiert zu wenig auf Veränderungen),
* '''zu steil''' sein (überreagiert),
* oder '''perfekt''' zur Realität passen.

DriftSlope misst genau diese Abweichung.

🧮 '''Wie wird DriftSlope berechnet?''' 
[[Datei:DriftSlope.png|right|thumb|400px|DriftSlope]]

Die Formel lautet:

<pre>
DriftSlope = SlopeLive / SlopeModel
</pre>

* '''SlopeLive''' = Steigung aus den letzten Live‑Daten
* '''SlopeModel''' = Steigung aus dem ursprünglichen Modelltraining

Damit ist DriftSlope ein '''Verhältnis''', kein Unterschied.

🎯 '''Warum ist das ein Verhältnis und keine Differenz?''' 

Ein Verhältnis ist robust gegenüber Skalierung und Lastniveau.

'''Beispiel:'''
* Modell: Slope = 0.9 / Live: Slope = 0.9 → Verhältnis = 1.0 → '''perfekt'''
* Modell: 0.9 / Live: 0.45 → Verhältnis = 0.5 → '''Modell ist doppelt so steil wie die Realität'''
* Modell: 0.9 / Live: 1.35 → Verhältnis = 1.5 → '''Modell ist zu flach'''

Eine Differenz (z. B. 0.9 − 0.45 = 0.45) wäre nicht interpretierbar, weil sie nicht skaliert.

📊 '''Wie interpretiert man DriftSlope?''' 

{| class="wikitable"
! DriftSlope !! Bedeutung !! Interpretation
|-
| ≈ 1.0 || perfekt || Modell und Realität haben die gleiche Dynamik
|-
| 0.85 - 1.15 || leichte Abweichung || Modell ist etwas flacher oder steiler
|-
| 0.70 - 1.30 || moderate Drift || Modell reagiert spürbar anders als die Realität
|-
| || starke Drift || Modell ist deutlich zu flach oder zu steil
|}

🧭 '''Warum ist die Richtung wichtig?''' 

* DriftSlope > 1.0
::→ Live‑Dynamik ist stärker
::→ Modell reagiert zu wenig
::→ Prognosen müssen verstärkt werden

* DriftSlope < 1.0
::→ Live‑Dynamik ist schwächer
::→ Modell reagiert zu stark
::→ Prognosen müssen abgeschwächt werden

Damit steuert DriftSlope die '''multiplikative Korrektur''' des Modells.

🧠 '''Zusammenfassung''' 

'''DriftSlope''' ist ein Verhältnis:

DriftSlope = SlopeLive / SlopeModel

Es zeigt:
* wie gut das Modell die reale Dynamik abbildet
* ob das Modell zu flach oder zu steil ist
* wie stark die Drift ist
* wie stark die Korrektur ausfallen soll

DriftSlope ist damit ein zentraler Baustein der Drift‑Erkennung und der automatischen Modellkorrektur.

 
==== automatische Bias‑ und Drift‑Korrektur (Überblick) ====

📘 Die Verbrauchs‑Prognose nutzt ein neuronales Netz, das aus historischen Verbrauchsdaten lernt. Damit die Vorhersagen auch bei veränderten Haushaltsmustern stabil und realistisch bleiben, wird das Roh‑Ergebnis des Modells bei jeder Prognoseerstellung durch zwei zusätzliche Korrekturschritte verbessert.

===== 🔧 1. Modell‑Bias‑Korrektur (Feinabstimmung) =====

Das neuronale Netz kann nach dem Training einen kleinen systematischen Fehler haben – zum Beispiel leicht zu hoch oder zu niedrig liegen. Dieser Fehler wird als <code>ModelBias</code> gemessen.

Die Bias‑Korrektur:

* wirkt nur im Grundlastbereich (keine Peak‑Verzerrung)
* ist additiv – korrigiert wird aber nicht um einen festen Wert, sondern um einen '''Anteil''' des gemessenen Bias, der von der Modellgüte abhängt
* wird über eine Zonenlogik gesteuert:
** Zone 1 (grün): Modell ist sehr stabil → 70 % des Bias werden korrigiert
** Zone 2 (gelb): Modell ist moderat stabil → 50 % des Bias werden korrigiert
** Zone 2b (nur bei bestimmten Haushaltsprofilen): 25 % des Bias werden korrigiert
** Zone 3 (rot): Modellqualität reicht nicht aus → keine additive Korrektur

Damit wird das Modell feinjustiert, ohne Peaks oder Lastspitzen zu verändern.

===== 🌡️ 2. Drift‑Korrektur (Anpassung an aktuelles Verbrauchsverhalten) =====

Der Verbrauch eines Haushalts kann sich im Laufe der Zeit ändern (z. B. neue Geräte, anderes Verhalten, Jahreszeit). Die Drift‑Analyse erkennt solche Veränderungen anhand von:

* <code>DriftSlope</code> – Verhältnis zwischen aktueller und zuletzt kalibrierter Regressionssteigung
* <code>DriftRmseRelRatio</code> – Verhältnis der aktuellen relativen Fehlerlage (RMSE) zur Referenz
* <code>DriftBias</code> – aktuelle systematische Verschiebung gegenüber der Referenz

Wenn Drift erkannt wird, wird die Prognose angepasst:

'''✔ Level‑Korrektur''' 
Die Vorhersage wird proportional verstärkt oder abgeschwächt, je nachdem wie stark sich das aktuelle Verbrauchsniveau von der zuletzt kalibrierten Referenz unterscheidet.

'''✔ Drift‑Bias''' 
Ein zusätzlicher Korrekturwert wird – ebenfalls nur im Grundlastbereich – addiert.

'''✔ Adaptive Drift‑Gewichtung''' 
Die Stärke der Drift‑Korrektur hängt dynamisch ab von:
* Abweichung des Slopes von der Referenz
* Stärke der relativen Fehlerabweichung (RMSE)
* allgemeiner Modellqualität (MAE)

'''✔ Drift‑Zonenlogik''' 
Zusätzlich wird die Drift in drei Stufen eingeteilt:
* Drift‑Grün: kaum Drift → nur 10 % der Level‑Korrektur wirksam
* Drift‑Gelb: moderater Drift → 40 % der Level‑Korrektur wirksam
* Drift‑Rot: starker Drift → 70 % der Level‑Korrektur wirksam

Damit reagiert die Prognose sanft bei kleinen Veränderungen und stärker bei echten Strukturbrüchen. '''Nachts (00–06 Uhr)''' sowie bei einem frisch trainierten Modell wird die Drift‑Level‑Korrektur automatisch deaktiviert.

🎯 '''Warum das wichtig ist'''

Ohne Bias‑ und Drift‑Korrektur würden Prognosen:
* bei veränderten Verbrauchsgewohnheiten zu hoch oder zu niedrig liegen
* Peaks falsch einschätzen
* langsam oder gar nicht auf neue Muster reagieren

Mit der Korrektur:
* bleibt die Prognose realistisch und stabil
* passt sich automatisch an das aktuelle Verhalten an
* schützt Peaks vor Überkorrektur
* liefert visuell plausible Verläufe

===== 🔄 3. Rekalibrierung nach einem neuen Training (Drift‑Reset) =====

Nach jedem KI‑Training startet das Modell mit einem neutralen Drift‑Zustand. Das ist wichtig, weil die Drift‑Analyse auf einem Zeitfenster der jüngsten Vergangenheit basiert (standardmäßig 96 Stunden, je nach Situation automatisch zwischen 48 und 144 Stunden angepasst) – unmittelbar nach dem Training stammen diese Daten aber noch vom alten Modell.

Damit keine falsche Drift entsteht, wird die Drift‑Pipeline automatisch zurückgesetzt:

* <code>DriftBias</code> wird auf 0.0 gesetzt
* <code>DriftSlope</code> wird auf 1.0 gesetzt
* <code>DriftFlag</code> wird auf <code>fresh_model</code> gesetzt
* die übrigen Drift‑Kennzahlen (u. a. <code>DriftScore</code>, <code>DriftRmseRelRatio</code>, <code>DriftIndex</code>) werden gelöscht und im UI als „‑" angezeigt, bis wieder ausreichend Live‑Daten vorliegen
* die Referenzwerte für die Korrektur (<code>DriftRefBias</code>, <code>DriftRefSlope</code>) werden auf die Werte aus dem aktuellen Training gesetzt

Erkennt das System über mehrere Stunden hinweg '''anhaltende und plausible''' Drift, werden die Korrektur‑Referenzwerte sanft an die realen Verbrauchsdaten angepasst:

* <code>DriftRefBias</code> ersetzt den bisherigen Referenzwert als neue Basislinie für die additive Korrektur. → Das Modell verschiebt sein Grundniveau, damit die Vorhersage im Mittel wieder stimmt.
* <code>DriftRefSlope</code> ersetzt den bisherigen Referenzwert als neue Basis für die Level‑Korrektur. → Das Modell reagiert wieder angemessen auf Verbrauchsänderungen.
* Die ursprünglichen Trainingswerte <code>ModelBias</code>/<code>ModelSlope</code> bleiben davon unberührt als Referenz erhalten.

Diese Rekalibrierung geschieht bewusst nur in kleinen, gedämpften Schritten (nie ein voller Sprung auf die Live‑Werte) und '''erst, wenn eine Sicherheitsprüfung sie zulässt''' – siehe nächster Abschnitt.

===== 🛡️ Schutz vor Fehlalarmen =====

Bevor eine Rekalibrierung tatsächlich durchgeführt wird, prüft das System die aktuelle Datenlage auf Plausibilität. Erkannt und '''blockiert''' werden unter anderem:

* typische Nacht‑/Grundlastphasen (keine echte Drift, nur niedriger Verbrauch)
* unplausible oder stark schwankende Slope‑/Bias‑Werte (Hinweis auf Sensor‑ oder API‑Fehler statt echter Verhaltensänderung)
* Fälle, in denen das Modell zwar generell ungenau, aber '''nicht driftend''' ist (hier hilft ein Retraining mehr als eine Rekalibrierung)

Nur wenn keiner dieser Fälle vorliegt, wird tatsächlich rekalibriert. Bleibt die Drift trotzdem über viele Stunden bestehen, meldet das System stattdessen eine Retraining‑Empfehlung.

===== ⏳ 4. Drift‑Sperrmechanismus (ModelAgeHours) =====

Damit die Drift‑Analyse nur auf echten Live‑Daten des neuen Modells basiert, wird sie erst aktiviert, wenn genügend neue Daten vorliegen.

Das Modellalter wird automatisch berechnet:
* aus dem Zeitstempel des letzten Trainings
* und dem Zeitindex der neuesten Verbrauchsdaten

Solange das Modell jünger als die konfigurierte Mindestreife (aktuell 6 Stunden) ist:
* wird keine Drift berechnet
* alle Drift‑Parameter bleiben neutral
* die Prognose nutzt nur das neuronale Netz und die Modell‑Bias‑Korrektur
* <code>DriftFlag = fresh_model</code>
* Drift‑Kennzahlen werden im UI als „‑" angezeigt

Nach Ablauf dieser Mindestzeit wird die Drift‑Analyse automatisch freigeschaltet.

🎯 '''Warum diese Mechanismen wichtig sind'''

Ohne Rekalibrierung, Sicherheitsprüfung und Sperrmechanismus würden:
* direkt nach dem Training falsche Drift‑Signale entstehen
* die Prognose durch alte Fehlerbilder verzerrt
* Bias‑ und Drift‑Korrektur in die falsche Richtung wirken
* severe‑Drift‑Alarme auftreten, obwohl das Modell frisch ist – oder obwohl nur ein Sensor gerade falsche Werte liefert

Mit dieser Logik:
* startet jedes Modell neutral und stabil
* Drift wird erst aktiv, wenn genügend neue Live‑Daten existieren
* offensichtlich unplausible Datenlagen lösen keine Rekalibrierung aus
* die Prognose bleibt ruhig, plausibel und robust
* Fehlalarme werden deutlich reduziert

----
''Eine ausführliche, technische Beschreibung mit allen Formeln, Zonenschwellen und der zugrunde liegenden ML‑Theorie findet sich im Deep‑Dive‑Artikel: [[Driftmanagement und Bias-Korrektur im SolarForecast KI-Prognosesystem]]''

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Die Bedeutung der Platzhalter sind:

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

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

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

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

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

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

 

=== Auswerten von internen Arrays ===

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

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

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

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

 

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

<pre>
Init_SolarForecast_<name> - initiatiale Daten die vor dem Einlesen weiterer Daten oder Attribute geladen werden
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 APIs
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - PV-KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - PV-KI Input Daten = Raw Trainigsdaten
NeuralNet_SolarForecast_<name> - Daten des neuronalen Netztes (KI Verbrauchsprognose)
Messages_SolarForecast_<name> - Daten des Nachrichten- und Informationssystems
</pre>

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

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

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

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "Initialize" restored
2023.10.02 09:57:07.967 3: SolCast6 - set init data writeForceType=db before load over data
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
2023.10.02 09:57:07.976 3: SolCast6 - cached data "NeuralNetwork" restored for FANN type 'con'
</pre>

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

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

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

 
'''Hinweis:''' 
Das zuvor beschriebene Verfahren kann auch angewendet werden um das SolarForcast Device von einer FHEM Installation in eine andere Installation umzuziehen. In diesem Fall ist aber besonders darauf zu achten, vorab alle in den SF-Attributen referenzierten Devices wie Inverter, Meter oder DWD-Devices mit den zutreffenden Namen in der neuen Installation anzulegen. Weiterhin muß beachtet werden, dass die '''Daten nicht zwischen 32 Bit-Systemen und 64 Bit-Systemen ausgetauscht werden können'''. So können z.B. auf einem 32 Bit-System geschriebene Dateien auf einem 64 Bit-System nicht gelesen werden und vice versa.

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

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

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

== Batterieintegration und -steuerung ==

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

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten sollte. Anders formuliert legt careCycle fest, alle wieviel Tage mindestens einmal maxSoC erreicht werden sollte. Die Angabe ist optional. (default: 20)

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

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

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

;loadTarget: Optionaler Ziel-SoC in % für die Berechnung der Ladefreigabe bzw. der optimalen Ladeleistung. Der Zielwert ist eine kalkulatorische Rechengröße. Der reale SoC kann situativ in Grenzen über- oder unterschritten werden. Der höhere Wert aus Reading Battery_OptimumTargetSoC_XX und 'loadTarget' hat für die Berechnung Vorrang. Wert: 0..100, default=100. In loadTarget kann eine Zielzeit angegeben werden, wann der Ziel-SoC erreicht werden soll. Die optimale Ladeleistung wird entsprechend angepasst. Die Zeitangabe als positive Ganzzahl ist ein Absolutwert (Stunde), in der der Ziel-SoC erreicht sein soll. Ein negativer Integer (z.B. -3) besagt, dass drei Stunden vor dem [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Bestimmung_von_Sonnenaufgang_und_Sonnenuntergang|Sonnenuntergang]] des aktuellen Tages der Ziel-SoC erreicht sein soll. D.h. negative Zahlen sind Relativangaben. Generell wird der Ziel-SoC zur Wunschzeit nur dann erreicht sein, wenn genügend PV-Leistung verfügbar ist.

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

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

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

lowSoc < upSoC < maxSoC

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

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

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

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

🎯 '''Kurzfazit: Was beschreibt Battery_OptimumTargetSoC_XX?''' 

Battery_OptimumTargetSoC_XX definiert den optimalen Ziel‑SoC, den die Batterie erreichen bzw. nicht unterschreiten sollte, um prognostizierte PV‑Überschüsse aufzunehmen, ausreichende Energiereserven bereitzuhalten und die erforderlichen Pflegezyklen sicherzustellen. Der Wert bezieht sich dabei nicht auf die physikalischen Eigenschaften der Batteriezellen, sondern ergibt sich ausschließlich aus den Steuerungszielen des Moduls – basierend auf den eingestellten Parametern und den prognostizierten Umweltfaktoren.

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

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

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

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

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

so zum Beispiel:

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

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

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

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

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die erwartete PV Erzeugung des aktuellen und folgenden Tages 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 laden.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

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

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

batSocChargeMgmnt ('<Name SolarForecast Device>');

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

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

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

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

return;
}

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

1;
</syntaxhighlight>

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

 

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

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

'''Hintergründe:'''

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Die Logik arbeitet wie folgt:

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

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

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

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

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

ODER

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

ODER

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

ODER

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

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

 

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

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

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

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

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

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

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

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

userattr <Name> userFn_GridSetpointManagement:ein,aus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

return;
}

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

'''Variablen'''

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

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

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

'''Lineare Interpolation und Steigung'''

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

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

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

Nach Umformung ist der Zusammenhang wie folgt darstellbar:

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

und ist äquivalent zu

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

'''Numerisches Beispiel'''

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

Die Steuerungsvarianten lassen sich folgendermaßen klassifizieren:

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

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

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

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

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

===== Codebeispiel zur Steuerung eines in ein Victron System eingebundenen Pylontech Batteriestack via Cerbo GX =====

Das '''nachfolgende Codebeispiel''' bietet die Möglichkeit über ein Attribut die Ladevariante auszuwählen, über ein weiteres Attribut die SoC-Steuerung zu aktivieren/deaktivieren, integriert die Ladesteuerung für eine Batterie-Anforderungsladung bei Unterschreitung von ctrlBatSocManagementXX->lowSoc, und ergänzt eine zellspannungsbasierte Ladestrom-Drosselung ('''TermVoltageTaper''') zum Schutz der Einzelzellen nahe Vollladung.

Die verwendeten Devices werden über eine MQTT Verbindung CerboGX -> FHEM erzeugt und aktualisiert. Der Code wurde mit Venus OS Version v3.72 auf Cerbo GX getestet bzw. mit dieser Version produktiv eingesetzt.

Die gesteuerte Batterieanlage besteht aus:
* 3 x Victron MultiPlusII 3000/48
* Steuergerät CerboGX (in FHEM über MQTT eingebunden)
* einem Batteriestack bestehend aus mehreren Pylontech US3000C (wird durch CerboGX gesteuert und über die separate MQTT-Verbindung als Batteriestack-Device eingebunden)
* zusätzlich, für TermVoltageTaper: das FHEM-Modul '''PylonLowVoltage''', welches je US3000C-Pack über RS485 die 15 Einzelzellspannungen ausliest (Readings ''cellVoltage_01'' … ''cellVoltage_15'')

Zur Umschaltung bzw. Auswahl der Ladestrategie und des SoC-Managements werden zwei User-Attribute im SolarForecast Device angelegt.
<pre>
attr ... userattr userFn_BatterySoCManagement:Ein,Aus userFn_BatteryLoadManagement:Aus,loadRelease,optPower,smartPower
</pre>

Im Code werden diese Attribute ausgewertet. Das nachfolgende Script vereint folgende Funktionalitäten:
* die Aktivierung/Deaktivierung des SoC-Managements via Attribut userFn_BatterySoCManagement
* die Auswahl der Ladestrategie oder Deaktivierung der Ladesteuerung via Attribut userFn_BatteryLoadManagement
* Integration einer Anforderungsladung bei Signalisierung durch Reading Battery_ChargeRequest_XX
* eine zellspannungsbasierte Sicherheitsdrosselung des Ladestroms nahe Vollladung ('''TermVoltageTaper''', siehe unten)
* Generierung von Readings userFn_Victron_GridSetpoint_set und userFn_MPII_MaxChargeCurrent_set zur Dokumentation der eingestellten Soll-Werte, sowie userFn_LoadController_* zur Dokumentation des TermVoltageTaper-Verhaltens

Bei der Nachnutzung des Scripts sind zunächst die '''Konstanten''' und die verwendeten Devices (z.B. MQTT2_cerboGX_c0619ab34e08_settings) sowie deren Readings im Block '''aktuelle Indikatoren''' anzupassen. Für TermVoltageTaper sind zusätzlich die drei Zellspannungs-Parameter (siehe unten) an die eigene Zellchemie und die eigenen Messwerte anzupassen.

Das Script wird in die Datei '''99_mySolarForecastUtils.pm''' eingetragen und im SolarForecast Attribut '''ctrlUserExitFn''' hinterlegt:
<pre>
attr ... ctrlUserExitFn {
::batLoadMgmnt ($name, '01');
# ::batLoadMgmnt ($name, '02'); # optional für eine weitere Batterie '02'
# ::batLoadMgmnt ($name, '0X'); # optional für weitere Batterien
}
</pre>

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

Das Attribut '''userFn_BatteryLoadManagement''' selektiert die gewünschte Ladestrategie:
;Aus: das Lademanagement ist ausgeschaltet

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

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

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

Die in SolarForecast eingestellte Ladestrategie (Attributschlüssel '''ctrlBatSocManagement01->loadStrategy''') wird in dem Steuerungscode in jedem Zyklus aktuell ausgelesen und berücksichtigt.

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

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

'''TermVoltageTaper - Zellschutz nahe Vollladung'''

'''Motivation'''

Ein hoher SoC-Stand allein ist bei LiFePO4-Zellen unkritisch. Problematisch sind vielmehr die bei ungünstigem Ladeverlauf auftretenden hohen '''Einzelzellspannungen''' nahe Vollladung – ein globales, SoC-basiertes Lademanagement (wie es SolarForecast über ''Battery_ChargeOptTargetPower_XX'' liefert) kennt die Streuung der Einzelzellen innerhalb eines Batteriestacks nicht und kann daher eine ausbrechende Einzelzelle nicht erkennen. TermVoltageTaper schließt diese Lücke, indem es den von SolarForecast vorgegebenen Ladestrom in der kritischen Endphase anhand der '''höchsten gemessenen Einzelzellspannung im gesamten Stack''' begrenzt. Die Lösung basiert auf dem Konzept des Forenusers '''Parallix''' (siehe [https://forum.fhem.de/index.php?msg=1359855 #5467] und [https://forum.fhem.de/index.php?msg=1358509 #5199]).

'''Physikalischer Hintergrund: OCV-Kurve und Kniezone'''

Die '''OCV-Kurve''' (Open Circuit Voltage) beschreibt die Ruhespannung einer Zelle in Abhängigkeit vom SoC – also die Spannung ohne fließenden Strom, nach ausreichender Relaxationszeit. Bei LiFePO4-Zellen verläuft diese Kurve zwischen ca. 20 % und 90 % SoC sehr '''flach''': Die Spannung ändert sich über einen weiten SoC-Bereich kaum, weshalb eine SoC-Schätzung über die Spannung in diesem Bereich unzuverlässig ist (die BMS-SoC-Schätzung basiert daher primär auf Coulomb-Zählung).

Erst kurz vor Vollladung – der '''Kniezone''' – steigt die Spannung deutlich steiler an. Genau das macht die Zellspannung in diesem Bereich zu einem empfindlichen, geeigneten Steuersignal: Sie reagiert dort auf SoC- bzw. Ladezustandsänderungen viel stärker als im Flachbereich, und sie macht – anders als der globale Pack-SoC – auch '''Streuungen zwischen Einzelzellen''' sichtbar, da jede Zelle einzeln gemessen wird.

[[File:OCV_Kniezone_TermVoltageTaper.png|thumb|420px|OCV-Kurve (grün) und Ladespannung inkl. IR-Drop (orange, gestrichelt) einer LiFePO4-Zelle über dem SoC. Ab ca. 90 % SoC beginnt die Kniezone mit deutlich steilerem Spannungsanstieg. lowerTermVoltage und upperTermVoltage begrenzen den TermVoltageTaper-Regelbereich.]]

Zusätzlich zur reinen Ruhespannung (OCV) liegt bei fließendem Ladestrom noch der '''IR-Drop''' (Spannungsabfall am Zell-Innenwiderstand, U_IR = I × R_innen) auf der gemessenen Klemmspannung – daher liegt die tatsächlich gemessene Ladespannung stets etwas über der reinen OCV-Kurve (siehe orangene, gestrichelte Kurve in der Grafik).

'''Regelparameter'''

TermVoltageTaper arbeitet mit drei zentralen Spannungsparametern (aktuell als lokale Variablen in der Sub definiert, nicht als Attribut):

;LOWER_TERMVOLTAGE (aktuell 3.420 V): Zellspannung, ab der die Drosselung des Ladestroms einsetzt. Der Wert sollte deutlich unterhalb der bei ca. 99 % SoC beobachteten Zellspannung liegen (bei den hier verwendeten US3000C-Packs ca. 3.480 V) und idealerweise empirisch aus den eigenen Log-Daten (Zellspannung über Zeit/SoC während eines vollständigen Ladevorgangs) ermittelt werden.

;UPPER_TERMVOLTAGE (aktuell 3.490 V): Höchste zulässige Zellspannung. Wird sie überschritten, wird der Ladestrom hart auf 0 gesetzt. Der Wert muss mit klarem Sicherheitsabstand unterhalb der BMS-eigenen Überspannungsschutzschwelle liegen (bei US3000C ca. 3.600 V je Zelle).

;VOLTAGE_OFFSET (aktuell 0): IR-Drop-Kompensation für den linearen SoC-Bereich. Bei den in der Praxis auftretenden geringen Lade-C-Raten ist der IR-Drop meist im Bereich der Messauflösung und kann vernachlässigt werden; bei höheren Ladeströmen sollte dieser Wert ggf. SoC-abhängig ergänzt werden.

[[File:Screenshot 2026-08-09 153126.png|thumb|420px|Arbeitsbereich des TermVoltageTaper (orange eingekreist). Deutlich erkennbar ist die Abregelung von OTP auf 'OTP capped' bei Überschreitung der VOLTAGE_OFFSET Rampe. Durch Einsatz der Hysterese UPPER_TERMVOLTAGE_HYST wird ein gleichmäßiger Regelverlauf realisiert.]]

;UPPER_TERMVOLTAGE_HYST (aktuell 0.030 V): Hysterese-Band unterhalb von UPPER_TERMVOLTAGE zur Vermeidung von Oszillationen des Ladestroms. Ohne Hysterese würde eine Proportionalregelung an dieser harten oberen Schwelle zu einem Grenzzyklus neigen: Nach dem Cutoff (current = 0) relaxiert die Zellspannung durch den Wegfall des IR-Drops, unterschreitet dadurch kurzzeitig UPPER_TERMVOLTAGE, der Regler gibt sofort wieder vollen Strom frei, wodurch die Spannung erneut über die Schwelle steigt – der Zyklus beginnt von vorn, oft im Sekundentakt. Mit der Hysterese bleibt ein einmal ausgelöster Cutoff so lange aktiv (Schmitt-Trigger-Verhalten), bis maxCellVolt die niedrigere Freigabeschwelle (UPPER_TERMVOLTAGE − UPPER_TERMVOLTAGE_HYST) tatsächlich unterschreitet. Der aktuelle Zustand (aktiv/inaktiv) wird im Reading ''userFn_LoadController_cutoffActive'' dokumentiert. Der Wert ist ein empirisch ermittelter Startwert; ist die Oszillation trotzdem noch spürbar, kann UPPER_TERMVOLTAGE_HYST schrittweise erhöht werden, auf Kosten einer etwas trägeren Wiederfreigabe nach einem Cutoff.

[[File:Screenshot 2026-08-09 184604.png|thumb|420px|Cutoff löst sich im Bereich der Volladung nur selten (OTP Capped steigt bis ca. 2786 W), bis bei übersteigen UPPER_TERMVOLTAGE erneut gecuttet wird. Jedes Mal, wenn sich der Cutoff löst, ist max. Zellenspannung spürbar unter die eingestellte Release-Schwelle (3.460 V) gefallen. Das ist erwünschtes, kontrolliertes Verhalten – kein Bug.]]

Der Taper wirkt als lineare Rampe zwischen ''lowerTermVoltage'' und ''upperTermVoltage'':
<pre>
current *= 1.0 - (maxCellVolt - lowerTermVoltage) / (upperTermVoltage - lowerTermVoltage);
current = 0.0 if maxCellVolt > upperTermVoltage;
</pre>

'''Ermittlung der maximalen Zellspannung'''

TermVoltageTaper ermittelt ''maxCellVolt'' als Maximum über '''alle''' Zellen '''aller''' im System vorhandenen ''PylonLowVoltage''-Devices (bei Parallelschaltung mehrerer US3000C-Packs am gemeinsamen DC-Bus muss die kritischste Einzelzelle über den gesamten Stack hinweg erkannt werden, nicht nur pro Pack). Dabei wird zusätzlich das Alter jedes einzelnen ''cellVoltage_XX''-Readings geprüft (Parameter ''PYLON_MAXAGE'', aktuell 300 Sekunden): Ist ein Reading älter, wird sein Wert ignoriert und protokolliert. Werden veraltete Werte gefunden, wird der Ladestrom sicherheitshalber unabhängig vom berechneten ''maxCellVolt'' auf ''batMinChgCurrent'' (aktuell 0) gesetzt – ein Fail-Safe-Verhalten, das eine durch Buskommunikationsprobleme (z. B. RS485-Kollisionen bei mehreren gleichzeitig pollenden Pack-Devices) bedingte Fehlmessung nie unbemerkt in einen zu hohen Ladestrom münden lässt.

'''Einbindung in batLoadMgmnt'''

TermVoltageTaper wird als eigenständige Sub aufgerufen und liefert die um den Zellspannungs-Taper gedeckelte Ladeleistung (''otpCapped'') zurück:
<pre>
my $otpCapped = TermVoltageTaper ($name, $otp, $voltage);
$otpCapped = List::Util::min ($otp, $otpCapped);
</pre>
''otpCapped'' wird anstelle von ''otp'' in die anschließende GridSetpoint-Berechnung übernommen. Damit wirkt der Zellschutz '''innerhalb desselben Regelpfads''', den SolarForecast ohnehin für die PV-Überschuss-basierte Ladesteuerung nutzt: Erreicht ''maxCellVolt'' die Kniezone, sinkt ''otpCapped'', wodurch automatisch mehr PV-Leistung über den GridSetpoint Richtung Netz/Hausverbrauch statt in die Batterie geleitet wird – ohne zusätzlichen, parallelen Regelkreis.

'''Wichtiger Hinweis bei DC-gekoppelten Anlagen mit separatem MPPT'''

Die GridSetpoint-basierte Drosselung wirkt auch dann korrekt, wenn zusätzlich zu den MultiPlusII-Geräten ein direkt am Batterie-DC-Bus hängender MPPT-Solarladeregler im System vorhanden ist. Da MPPT, Batterie und MultiPlusII am selben Gleichstrombus hängen, gilt näherungsweise:
<pre>
Ladeleistung_Batterie ≈ Leistung_MPPT - Leistung_MultiPlusII
</pre>
Erhöht man über den GridSetpoint die vom MultiPlusII Richtung Netz/Hausverbrauch gewandelte Leistung, sinkt automatisch der für die Batterie verbleibende Rest – auch der vom MPPT erzeugte Anteil wird dabei über den MultiPlusII abgeführt und steht folglich nicht mehr für die Batterieladung zur Verfügung. Ein separater Eingriff am MPPT selbst ist für den regulären Taper-Betrieb also nicht erforderlich.

Diese indirekte Drosselung ist zudem verlustfrei: Die abgeregelte Leistung wird nicht am MPPT verworfen (kein Curtailment), sondern produktiv ins Netz oder den Haushalt geleitet.

Die Methode stößt jedoch an eine Grenze, sobald die '''maximale Einspeiseleistung''' (Attribut/Reading ''feedinPowerLimit'' bzw. bei Zero-Feed-in-Konfigurationen der Wert 0) bereits ausgeschöpft ist bzw. der GridSetpoint seinen zulässigen negativen Grenzwert (''neggspmax'') erreicht hat: In diesem Fall kann die vom MPPT erzeugte Leistung nicht mehr vollständig abgeführt werden, und ein Rest-Ladestrom bleibt trotz ''current = 0'' bestehen. Für den harten Cutoff-Fall (''maxCellVolt > upperTermVoltage'') ist dieser Grenzfall relevant und sollte bedacht werden.

'''Auswertung / Monitoring'''

Für die Beobachtung des Regelverhaltens legt TermVoltageTaper folgende Readings an (mit Event-Erzeugung, ''readingsEndUpdate ($hash, 1)'', damit FileLog/DbLog diese erfassen können):

;userFn_LoadController_maxCellVolt: aktuell ermittelte maximale Zellspannung im Stack (V)

;userFn_LoadController_maxCellSrc: Pack/Zelle, aus der die maximale Zellspannung stammt (z. B. ''Pylon3:cellVoltage_06''), hilfreich zur Diagnose bei auffälligem Verhalten einzelner Packs

;userFn_LoadController_otp: vom Modul errechnete optimale Ladeleistung (W) zur Erreichung des Ladeziels ohne Kenntnis der Zellspannungen

;userFn_LoadController_otpCapped: daraus resultierende gedeckelte Ladeleistung (W), die in die weitere GridSetpoint-Berechnung einfließt

;userFn_LoadController_cutoffActive: dokumentiert den Hysterese-Zustand des harten Spannungs-Cutoffs (1 = ausgelöst, Ladeleistung auf 0 W reduziert; 0 = nicht aktiv). '''Zu beachten:''' otpCapped kann auch bei cutoffActive=0 den Wert 0 annehmen, nämlich wenn der Stale-Data-Fail-Safe greift (veraltete Zellspannungsdaten) oder wenn die Taper-Rampe rechnerisch auf 0 rundet, ohne dass UPPER_TERMVOLTAGE überschritten wurde. cutoffActive zeigt also ausschließlich, ob speziell der Hysterese-Mechanismus gerade aktiv ist – nicht jede Ursache für otpCapped=0.

Ein gemeinsamer Plot aus ''userFn_LoadController_maxCellVolt'', ''userFn_LoadController_current'' bzw. ''userFn_LoadController_otpCapped'' sowie ''Battery_ChargeOptTargetPower_XX'' (als ungedrosselter Referenzwert) zeigt den Taper-Effekt sehr anschaulich: Bis zum Erreichen von ''lowerTermVoltage'' laufen beide Kurven deckungsgleich, danach knickt ''otpCapped'' zunehmend unter den ungedrosselten Zielwert ab, bis bei Erreichen von ''upperTermVoltage'' der harte Cutoff auf 0 greift.

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

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

# ab hier eigenen Code eintragen

############################################################################
# komplettes Batterie Lademanagement (SOC + Ladeleistung)
############################################################################
sub batLoadMgmnt {
my $name = shift;
my $bn = shift // '01'; # Batterienummer
my $hash = $defs{$name};

## Konstanten
###############
use constant {
GSPDEF => 20, # Default Einstellung des Grid Setpoint
FINDEF => 5000, # Default Einspeiselimit
MINSOCDEF => 10, # Default Minimum SoC
MAXPLDEF => 105, # max. Ladestrom (A) für Victron MPII Verbund
SYS_VOLTAGE => 48, # Batterie Systemspannung
PYLON_MAXAGE => 300, # max. erlaubtes Alter (s) eines cellVoltage-Readings
LOWER_TERMVOLTAGE => 3.420, # Zellspannung -> Start Drosselung, deutlich vor 3480 mV bei 99 %
UPPER_TERMVOLTAGE => 3.490, # höchste Zellspannung (oberhalb keine weitere Ladung)
# ... (nahe dem vom Hersteller intendierten "voll"-Punkt, mit klarem
# ... Sicherheitsabstand zur 3600 mV Schutzschwelle)
VOLTAGE_OFFSET => 0, # Spannungsabfall am Innenwiderstand der Zelle für ein SOC in [20,90]
# ... andernfalls VOLTAGE_OFFSET=0
UPPER_TERMVOLTAGE_HYST => 0.030, # Hysterese-Band um UPPER_TERMVOLTAGE (V)
};

my $batsocmgmt = AttrVal ($name, 'userFn_BatterySoCManagement', 'Aus'); # Aus / Ein
my $batloadmgmt = AttrVal ($name, 'userFn_BatteryLoadManagement', 'Aus'); # Soll: Aus|loadRelease|(opt|smart)Power
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron CerboGX Einstellungen
my $batterydev = 'MQTT2_cerboGX_c0619ab34e08_battery'; # Device für Pylontech BatteryStack
my $ctype = 'Aus'; # Voreinstellung Steuerungstyp
my $voltage = ReadingsNum ($batterydev, 'DC_Voltage_value', SYS_VOLTAGE); # akt. Batteriespannung Bat-Paket (V)

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

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

if ($batloadmgmt ne 'Aus') {
$ctype = $batloadmgmt;

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

## aktuelle Indikatoren
##########################
my $finplim = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', FINDEF); # Limit plantControl->feedinPowerLimit (W)
my $preduce = FHEM::SolarForecast::BatteryVal ($name, $bn, 'bpinreduced', MAXPLDEF); # reduzierte Ladeleistung aus Bat-Konfig (W)

my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_'.$bn, 0); # Notfallladung
my $unrestrict = ReadingsNum ($name, 'Battery_ChargeUnrestricted_'.$bn, 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', GSPDEF); # aktuelle Einstellung Grid Setpoint
my $otp = ReadingsNum ($name, 'Battery_ChargeOptTargetPower_'.$bn, $preduce); # optimale Ladeleistung (W)
my $actmcc = ReadingsNum ($vicsets, 'MaxChargeCurrent', 0); # akt. maximale Ladestromeinstellung
my $load = MAXPLDEF; # initialer Soll-Ladestrom MPII (A)
my $neggspmax = -1 * $finplim;

my $gridsetpoint = GSPDEF; # Voreinstellung Grid Setpoint

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

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

####################################
## Battery Lade-Management
####################################

# TermVoltageTaper - Ladestrom-Drosselung anhand Zellspannung (Kniezone)
# Konzept nach Forenuser 'Parallix'
############################################################################
my $otpCapped = TermVoltageTaper ($name, $otp, $voltage, $bn); # OTP eventuell drosseln
$otpCapped = List::Util::min ($otp, $otpCapped); # $otp mit der Taper-Grenze deckeln,
# BEVOR GridSetpoint/Load daraus berechnet werden

## Steuerung nach Ladungsfreigabe
###################################
if ($batloadmgmt eq 'loadRelease') {
if (!$unrestrict) { # Grid Setpoint absenken bis
# ... Ladeleistung = 0
$gridsetpoint = GSPDEF - $surp;
}
}

## Steuerung nach optimaler Ladeleistung
##########################################
if ($batloadmgmt =~ /(?:opt|smart)Power/xs) {
if (!$unrestrict) { # Grid Setpoint absenken bis
my $gridin = $surp - $otpCapped; # ... Ladeleistung = otpCapped
$gridsetpoint = GSPDEF - $gridin;
}
}

## max. Ladestrom der MultiPlusII rechnen
###########################################
if ($batloadmgmt ne 'Aus') {
$load = $otpCapped / $voltage; # Ladestrombegrenzung MPII
}

## Anforderungsladung (überschreibt max. Ladestrom)
#####################################################
if ($bcrq) { # max. Ladeleistung b. Battery_ChargeRequest
$ctype = 'requestCharging';

if ($surp < $preduce) {
my $p = $preduce;
$load = $p / $voltage; # Soll-Ladestrom (A)
}
}

## GridSetpoint und max. Ladestrom der MultiPlusII umsetzen
#############################################################
$gridsetpoint = List::Util::min (GSPDEF, $gridsetpoint); # GridSetpoint darf nicht > GSPDEF sein
$gridsetpoint = List::Util::max ($neggspmax, $gridsetpoint); # GridSetpoint darf nicht < max. Einspeiseleistung sein
$gridsetpoint = sprintf "%.0f", $gridsetpoint;

$load = List::Util::max (0, List::Util::min (MAXPLDEF, $load)); # clampen
$load = sprintf "%.0f", $load;

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

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

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

readingsBeginUpdate ($hash);
readingsBulkUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $gridsetpoint);
readingsBulkUpdate ($hash, 'userFn_MPII_MaxChargeCurrent_set', $load);
readingsEndUpdate ($hash, 0);

return;
}

############################################################################
# TermVoltageTaper - Ladestrom-Drosselung anhand Zellspannung (Kniezone)
# Idee/Konzept: https://forum.fhem.de/index.php?msg=1358509
# https://forum.fhem.de/index.php?msg=1359855
# Konzept nach Forenuser 'Parallix'
# Eingang: OTP, Bat-Spannung
# return: gedrosselter OTP
############################################################################
sub TermVoltageTaper {
my ($name, $otp, $voltage, $bn) = @_;

my $current = $otp / $voltage;
my $hash = $defs{$name};

my $termVoltageRange = UPPER_TERMVOLTAGE - LOWER_TERMVOLTAGE;
my $releaseVoltage = UPPER_TERMVOLTAGE - UPPER_TERMVOLTAGE_HYST;
my $batMinChgCurrent = 0;

state @allPylonDevs;
@allPylonDevs = devspec2array ("TYPE=PylonLowVoltage") if !@allPylonDevs;

my $maxCellVolt = 0;
my $maxCellSrc = '';
my $staleFound = 0;

for my $pd (@allPylonDevs) {
for my $cells (1..15) {
my $cell = sprintf "%02d", $cells;
my $rn = "cellVoltage_$cell";
my $age = ReadingsAge ($pd, $rn, PYLON_MAXAGE + 1); # Alter in Sekunden

if ($age > PYLON_MAXAGE) {
$staleFound = 1;

Log3 ($name, 2, "$name - batTaper[$bn]: $pd $rn is outdated (${age}s) - value will be ignored")
if(FHEM::SolarForecast::askLogtime ($name, "ageIutdated_$pd", PYLON_MAXAGE - 10));

next;
}

my $v = ReadingsNum ($pd, $rn, 0);

if ($v > $maxCellVolt) {
$maxCellVolt = $v;
$maxCellSrc = "$pd:$rn";
}
}
}

# Fail-safe: Wenn veraltete Daten gefunden wurden, sicherheitshalber Strom kappen,
# unabhängig vom (evtl. unvollständig ermittelten) $maxCellVolt
if ($staleFound) {
$current = $batMinChgCurrent;
Log3 ($name, 2, "$name - batTaper[$bn]: outdated cell voltage data - set charge current to minimum as a precaution");
}

Log3 ($name, 4, "$name - batTaper[$bn]: maxCellVolt=$maxCellVolt V ($maxCellSrc)");

## Taper-Rampe
################
if ($maxCellVolt > LOWER_TERMVOLTAGE + VOLTAGE_OFFSET) {
$current *= 1.0 - ($maxCellVolt - LOWER_TERMVOLTAGE) / $termVoltageRange;
$current = $current < $batMinChgCurrent ? $batMinChgCurrent : $current;
}

## Hysterese um UPPER_TERMVOLTAGE (Schmitt-Trigger)
#######################################################
my $cutoffActive = $hash->{HELPER}{'TVT_CUTOFF'.$bn} // 0;

if ($cutoffActive) {
if ($maxCellVolt <= $releaseVoltage) {
$cutoffActive = 0; # Freigabe: unter Release-Schwelle gefallen
Log3 ($name, 4, "$name - batTaper[$bn]: TermVoltageTaper cutoff released (maxCellVolt=$maxCellVolt <= $releaseVoltage)");
}
else {
$current = 0.0; # weiterhin gesperrt, solange über Release-Schwelle
}
}
elsif ($maxCellVolt > UPPER_TERMVOLTAGE) {
$cutoffActive = 1;
$current = 0.0;

Log3 ($name, 3, "$name - batTaper[$bn]: TermVoltageTaper cutoff engaged (maxCellVolt=$maxCellVolt > "
.UPPER_TERMVOLTAGE.")");
}

$hash->{HELPER}{'TVT_CUTOFF'.$bn} = $cutoffActive;

$current = sprintf "%.0f", $current;
my $otpCapped = List::Util::min ($otp, $current * $voltage);

readingsBeginUpdate ($hash);
readingsBulkUpdate ($hash, 'userFn_LoadController_maxCellVolt', $maxCellVolt);
readingsBulkUpdate ($hash, 'userFn_LoadController_maxCellSrc', $maxCellSrc);
readingsBulkUpdate ($hash, 'userFn_LoadController_otpCapped', $otpCapped);
readingsBulkUpdate ($hash, 'userFn_LoadController_otp', $otp);
readingsBulkUpdate ($hash, 'userFn_LoadController_cutoffActive', $cutoffActive);
readingsEndUpdate ($hash, 0);

return $otpCapped;
}

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

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

 

==== barrierSoC - der Parameter den nicht jeder braucht ====

Wie bereits hinlänglich beschrieben, aktiviert das Attribut '''ctrlBatSocManagementXX''' mit diversen Schlüsseln die Batterie SoC- und Ladesteuerung. Für die alltägliche Nutzung und um schnell sichtbare Ergebnisse zu erzielen, ist die die Verwendung der obligatorischen Schlüssel lowSoc, upSoC und vielleicht noch die Auswahl der gewünschten Ladestrategie zunächst völlig ausreichend. Das Modul stellt für die Batteriesteuerung aber noch einige weitere Schlüssel zu Verfügung, die besondere Anforderungen an die Batteriesteuerung unterstützen. Einer dieser Parameter ist der '''barrierSoC''' Schlüssel.

Wird eine der beschriebenen Batterie Ladestrategien ''optPower'' oder ''smartPower'' eingesetzt, wird die Batterieladungsleistung vom aktuell vorhandenen SoC bis zum Ziel-SoC optmiert im Reading Battery_ChargeOptTargetPower_XX bereitgestellt. Dabei wird auch eine eventuell in ''ctrlBatSocManagementXX->loadTarget'' eingestellte Zielzeit berücksichtigt. Möglicherweise besteht der Wunsch die Batterieladung bis zu einem bestimmten Mindest-SoC so schnell wie möglich aufzuladen um z.B. zügig eine Netzausfallreserve aufzubauen.

Zu diesem Zweck kann der optionale Parameter ''ctrlBatSocManagementXX->barrierSoC'' verwendet werden. In dem Ladebereich

lowSoC <= SoC < barrierSoC

kann der User Einfluß auf die berechnete Ladeleistung nehmen und sie ggf. bis zur maximal möglichen Leistung abändern. Das bedeutet alle Manipulationen erfolgen ausschließlich diesem SoC-Bereich.
Dazu kann dem Parameter mit einer bestimmten Syntax das Änderungsverhalten vorgegeben werden:

<pre>
barrierSoC=XX:<Aktion>:<Wert> oder
barrierSoC=XX:<Aktion>:<Reading>:<default>
</pre>

Dabei bedeutet:

<pre>
XX - der Wert von barrierSoC in %. Es gilt lowSoC < XX < maxSoC
</pre>

Mit der '''<Aktion>''' wird eine der möglichen Manipulations-Varianten festgelegt:

;max: - das Ladeleistungslimit wird auf setupBatteryDevXX->pinmax festgelegt
;set: - das Ladeleistungslimit wird auf einen festen Wert oder Readingswert gesetzt
;inc: - das Ladeleistungslimit wird um einen festen Wert oder Readingswert erhöht
;dec: - das Ladeleistungslimit wird um einen festen Wert oder Readingswert verringert
;prc: - das Ladeleistungslimit wird um einen prozentualen Wert / Readingswert geändert

Diese Aktion (außer ''max'') wird auf den angegeben Wert bzw. den Wert des angegebenen Readings angewendet. Das Reading muß im SolarForecast Device enthalten sein. Bei Verwendung eines Readings wird mit ''<default>'' der Standardrückgabewert festgelegt falls das Reading keinen Wert liefert oder nicht vorhanden ist.

Hier sind einige Beispiele für einen barrierSoC. Zur Vereinfachung wird ein barrierSoC von 40 % verwendet und kann natürlich auf einen anderen passenden Wert abgeändert werden.

<pre>
barrierSoC=40:max:- -> das Ladeleistungslimit wird auf setupBatteryDevXX->pinmax gesetzt
barrierSoC=40:set:<Reading>:<default> -> das Ladeleistungslimit auf den Wert <Reading> setzen
barrierSoC=40:set:1350 -> das Ladeleistungslimit wird auf 1350 W gesetzt
barrierSoC=40:inc:<Reading>:<default> -> das Ladeleistungslimit um den Wert <Reading> erhöhen
barrierSoC=40:inc:200 -> das Ladeleistungslimit wird um 200 W erhöht
barrierSoC=40:dec:<Reading>:<default> -> das Ladeleistungslimit um den Wert <Reading> verringern
barrierSoC=40:dec:100 -> das Ladeleistungslimit wird um 100 W verringert
barrierSoC=40:prc:<Reading>:<default> -> das Ladeleistungslimit um <Reading> Prozent ändern (+ erhöhen, - verringern)
barrierSoC=40:prc:50 -> das Ladeleistungslimit um 50% ändern (+ erhöhen, - verringern)
</pre>

 

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

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

lcSlot=00:00-23:59

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

Zur Verdeutlichung soll das Beispiel dienen:

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

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

Ab diesem Moment wird:

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

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

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

 

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

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

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

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

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

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

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

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

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

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

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

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

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

=== Die Phasen der Verbrauchersteuerung ===

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

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

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

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

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

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

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

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

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

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

{| class="wikitable"
|dryer
|90 Minuten
|-
|fridge
|1440 Minuten
|-
|bev
|600 Minuten
|-
|dehydrator
|600 Minuten
|-
|heatpump
|Sonderfall

KI-Prognose (ab V2.0.0) beachten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 

=== Automatiksteuerung der Verbraucher ===

==== Was ist die Automatiksteuerung? ====

Die Automatiksteuerung ist der zentrale Mechanismus, mit dem SolarForecast einen Verbraucher (Consumer) eigenständig anhand von PV-Überschuss, Planungsdaten und den konfigurierten Rahmenbedingungen (Zeitfenster, Sperrzeiten, Prioritäten etc.) ein- und ausschaltet. Sie ist die Voraussetzung dafür, dass ein Consumer überhaupt automatisch geschaltet werden kann.

Ist die Automatik für einen Consumer '''deaktiviert''', greift SF nicht in dessen Schaltzustand ein – der Consumer kann dann ausschließlich manuell (per Schalter am Gerät, per Set-Befehl, über eine andere Automatisierung etc.) bedient werden.

Ist die Automatik '''aktiviert''', übernimmt SolarForecast die Kontrolle über den Consumer im Rahmen der jeweiligen Planungs- und Überschusslogik (Modus <code>can</code>/<code>must</code>/<code>mustNot</code>).

==== Konfiguration: das Attribut <code>consumerXX->auto</code> ====

Für jeden Consumer wird über das consumerspezifische Attribut-Element <code>consumerXX->auto</code> festgelegt, '''welches Reading''' des Consumer-Devices die Automatikfreigabe liefert:

<pre>
auto=<Readingname>
</pre>

Beispiel:

<pre>
auto=Automatik
</pre>

'''Wirkung:'''

* Das referenzierte Reading wird von SolarForecast bei jedem Zyklus ausgelesen.
* Wert <code>1</code> (bzw. jeder als "wahr" interpretierbare Wert) → Automatik '''aktiv''': SolarForecast darf den Consumer schalten.
* Wert <code>0</code> → Automatik '''inaktiv''': SolarForecast plant zwar ggf. weiter im Hintergrund, führt aber '''keine Schaltbefehle''' aus.
* Ist kein <code>auto</code>-Schlüssel gesetzt, verhält sich der Consumer standardmäßig so, als wäre die Automatik dauerhaft aktiv (Default <code>1</code>).

==== Zusammenspiel von Automatik-Reading und grafischem Schalter im Consumer-Panel ====

[[Datei:Screenshot 2026-08-02 220921.png|right|thumb|400px|Automatik-Schalter im Consumer Panel]]

Im Consumer-Panel (Bereich "Consumer Legend") wird für jeden Consumer ein Schieberegler/Schalter für die Automatik angezeigt. Dieser Schalter ist '''keine eigenständige SolarForecast-interne Logik''', sondern lediglich eine grafische Repräsentation des unter <code>auto</code> hinterlegten Readings:

* Betätigung des Schalters im Panel setzt den Wert des referenzierten Readings am zugeordneten Device auf 0 oder 1.
* SolarForecast liest ausschließlich dieses Reading aus – nicht den Schalterzustand selbst. Der Schalter ist also nur die Benutzeroberfläche für das Reading, keine separate Speicherstelle.
* Wird das Reading auf anderem Weg verändert (z.B. durch eine andere Automatisierung, ein Notify, etc.), zeigt der Panel-Schalter dies beim nächsten SolarForecast-Zyklus entsprechend an – die Wirkung auf SolarForecast ist identisch, unabhängig davon, auf welchem Weg das Reading gesetzt wurde.

'''Praktisch bedeutet das:''' Ob der Automatikmodus über den Panel-Schalter, ein Skript oder eine andere FHEM-Automatisierung umgeschaltet wird, spielt für SolarForecast keine Rolle – entscheidend ist ausschließlich der aktuelle Wert des konfigurierten Readings.

 

==== Manuelle Eingriffe während aktiver Automatik ====

SolarForecast erkennt, wenn ein Consumer '''außerhalb der eigenen Schaltlogik''' geschaltet wird (z.B. per Schalter an der Steckdose, per App, durch eine andere Automatisierung), während die Automatik für diesen Consumer aktiv ist. Ein solcher externer Schaltvorgang wird im consumerXX-Reading mit dem Hinweis <code>von extern umgeschaltet</code> protokolliert.

'''Grundprinzip:''' SolarForecast unterbricht in diesem Fall bewusst seine eigene Schaltungslogik für diesen Consumer, um nicht störend in eine manuelle Aktion einzugreifen (z.B. laufende Wartung, kurzzeitiges Nachladen eines Wäschestücks in eine bereits laufende Waschmaschine, etc.).

===== Fall 1: Automatik wird aus- und wieder eingeschaltet =====

Wird die Automatik für einen Consumer '''bewusst deaktiviert und anschließend wieder aktiviert''' (Flanke AUS → EIN am <code>auto</code>-Reading), so übernimmt SolarForecast die Kontrolle '''in jedem Fall wieder''' – unabhängig davon, ob der Schaltzustand des Consumers zwischenzeitlich manuell verändert wurde oder nicht, und unabhängig davon, ob dieser Zustand vor der Reaktivierung wiederhergestellt wurde.

Dieser Vorgang wird im Consumer-Reading mit dem Hinweis <code>Automatik fortgesetzt</code> quittiert.

'''Merksatz:''' Die bewusste Reaktivierung der Automatik ist der eindeutigste Weg, die Kontrolle zuverlässig wieder an SF zu übergeben.

===== Fall 2: Automatik bleibt durchgehend aktiv, Ursprungszustand wird wiederhergestellt =====

Bleibt die Automatik durchgehend '''aktiviert''' und der Consumer wird manuell geschaltet, erkennt SolarForecast automatisch, wenn der '''Schaltzustand vor der manuellen Aktion wiederhergestellt''' wird – also z.B.:

* Consumer war automatisch ein → manuell aus → manuell wieder ein
* Consumer war automatisch aus → manuell ein → manuell wieder aus

In diesem Fall übernimmt die Automatik ebenfalls wieder selbstständig, sobald der Ursprungszustand erreicht ist – auch ohne dass die Automatik zwischenzeitlich deaktiviert wurde. Auch dieser Vorgang wird mit <code>Automatik nach Rundlauf fortgesetzt</code> quittiert.

'''Wichtig:''' Wird der Ursprungszustand '''nicht''' wiederhergestellt (z.B. Consumer war automatisch ein und wird manuell aus geschaltet, bleibt dann aber dauerhaft aus), bleibt der Consumer zunächst planungstechnisch "eingefroren" – siehe folgenden Abschnitt.

===== Fall 3: Consumer bleibt manuell abweichend vom Automatikstatus stehen =====

Wird ein Consumer manuell geschaltet und der neue Zustand '''nicht''' wieder in den Ursprungszustand zurückgeführt (z.B. manuell dauerhaft ausgeschaltet, während die Automatik ihn eigentlich eingeschaltet lassen würde), bleibt der Consumer zunächst '''nicht''' unter aktiver Kontrolle der Automatik.

Die Automatik übernimmt in diesem Fall '''trotzdem wieder''', sobald sie den Consumer im Rahmen ihrer normalen Zyklen einmal selbst "berührt" – am häufigsten durch eine kurzzeitige Unterbrechung mangels ausreichendem PV-Überschuss. Sobald dieser interne Abgleich stattgefunden hat, ist der intern gespeicherte Schaltzustand wieder deckungsgleich mit dem tatsächlichen physischen Zustand, und die Automatik behandelt den Consumer ab diesem Zeitpunkt wieder vollständig regulär – inklusive automatischem Wiedereinschalten bei ausreichendem Überschuss.

'''Praktische Konsequenz:''' Bei Consumern mit häufig schwankendem Überschuss (typisch bei wechselhafter Bewölkung oder gleichzeitig aktiven anderen Verbrauchern) kann dieser interne Abgleich vergleichsweise schnell erfolgen – oft innerhalb weniger Minuten. Ein manuelles dauerhaftes Abschalten sollte deshalb '''nicht ausschließlich''' auf diesem impliziten Mechanismus beruhen, sondern nötigenfalls durch Deaktivieren der Automatik (siehe Fall 1) oder eine geeignete Ausschlussbedingung (z.B. <code>swoffcond</code>) zuverlässig gegen ungewollten Wiederanlauf abgesichert werden.

==== Best Practice ====

Für ein zuverlässiges und nachvollziehbares Verhalten der Automatiksteuerung gilt:

* '''Kurzzeitige manuelle Eingriffe''' (z.B. kurz nachschauen, ein Wäschestück nachlegen) bei '''aktiver''' Automatik sind unproblematisch, solange der Ursprungszustand danach wiederhergestellt wird – die Automatik erkennt dies und läuft danach normal weiter.

* '''Soll ein Consumer dauerhaft und zuverlässig von der Automatik ausgenommen werden''' (z.B. für längere Wartungsarbeiten, bewusstes Stilllegen), empfiehlt es sich, die Automatik für diesen Consumer '''explizit zu deaktivieren''' (<code>auto</code>-Reading auf <code>0</code> setzen), statt sich auf einen dauerhaft abweichenden Schaltzustand zu verlassen. Nur so ist sichergestellt, dass SolarForecast in der Zwischenzeit keine Schaltbefehle ausführt.

* '''Soll die Kontrolle anschließend zuverlässig wieder an SolarForecast übergeben werden''', die Automatik bewusst wieder aktivieren (Flanke AUS → EIN). Dies ist der eindeutigste und sofortige Weg, unabhängig vom aktuellen Schaltzustand des Consumers.

* Für Consumer, die '''dauerhaft manuell abweichend''' von der Automatik-Empfehlung bleiben sollen, obwohl die Automatik selbst aktiv bleibt, empfiehlt sich zusätzlich eine passende <code>swoffcond</code>/<code>swoncond</code>-Bedingung, um ein unbeabsichtigtes Wiedereinschalten durch den in Fall 3 beschriebenen impliziten Abgleich zuverlässig zu verhindern.

* Der Status jedes Schaltvorgangs (inkl. "extern umgeschaltet"- und "Rundlauf fortgesetzt"-Hinweise) ist jederzeit im jeweiligen <code>consumer<XX></code>-Reading im Feld <code>info=</code> nachvollziehbar.

 

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

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

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

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

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

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

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

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

 

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

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

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

* consumerNewPlanning

* consumerImmediatePlanning

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

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

 

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

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

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

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

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

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

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

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

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

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

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

=== Beispiel Sonderregistrierung einer Wärmepumpe ===

Das nachfolgende Beispiel zeigt die besondere Möglichkeit zur Registrierung (ab V2.0.0.) einer Wärmepumpe - aber nur wenn '''aiConActivate=1''' => KI-Consumerprognose <== gesetzt und genutzt wird!

Hinweis : Aktuell ist "nur" die Datensammlung für den 'opmode' aktiv - noch keine CON-Betrachtung dieser Werte bis V2.8.1 -> 04-.07.2026)

<pre>
EM_Waermepumpe
aliasshort=WP
type=heatpump
etotal=Bezug_Wirkleistung_Zaehler:kWh
icon=sani_heating_heatpump@orange
mode=mustNot
modulation=MQTT_EMSwp:boiler_data_heatingpumpmod
noshow=0
opmode=Forecast:user_wpmodus
pcurr=Bezug_Wirkleistung:W:100
power=3183
switchdev=MQTT_EMSwp ### extra wg. swstate Reading auf MQTT_EMSwp
swstate=boiler_data_hpactivity:heating|cooling|hot.*|pool|poolheating|defrost:off
</pre>

Erläuterungen zu diesen 'besondern' Einträgen
{| class="wikitable"
|'''type'''
|'''heatpump'''
|-
|
|Für Wärmepumpen / Klimaanlagen etc.
Es aktiviert sich ein Feature-Set für Wärmepumpen. Dadurch ändern sich die Strukturen und das 'runConTrain' muß erneuert gestartet werden.
In dem Status des Consumer-KI-Status-Popup ist auch erkennbar ob die Wärmepumpe erkannt wird und welches Featureset verwendet wird. Es sollte aber dann z.B. beim ''<nowiki/>'attr aiControl aiConProfile=XYX'<nowiki/>'' das Flag '''heatpump''<nowiki/>' zusätzlich gesetzt werden.
|-
|
|
|-
|'''etotal'''
|der Schlüssel ist Pflichtangabe
|-
|
|
|-
|'''mode'''
|mustNot (Empfehlung bei modulierenden Gerätetypen)
|-
|
|''Bei dem Verbrauchertyp '''heatpump''' ist sicherzustellen, dass keine doppelte Regelung durch SolarForecast und die native Gerätesteuerung erfolgt. Daher sollte bei modulierenden Verbrauchern dieses Types der Eintrag meist genutzt werden.''
''Ab V2.8.1 kann auch ein "can" oder "must" - wie bei allen anderen Verbrauchertypen - zur Einplanung / Steuerung durch Solarforecast genutzt werden.''
|-
|'''modulation'''
|Modulation des Aggregates in % (Pflichtangabe). Die mögliche Syntax ist:
|-
|
|'''<Device>:<Reading>''' - Kombination welche die aktuelle Modulation ('''0..100''') in % liefert
|-
|
|'''100''' - feste Modulation von 100% für nichtmodulierende Geräte
|-
|
|
|-
|'''opmode'''
|definiert eine <Device>:<Reading> Kombination welche den aktuellen Betriebsmodus liefert (Pflichtangabe).
|-
|
|Syntax: '''<Device>:<Reading>'''
|-
|
|Die Rückgabe muß genau ein Wert der folgenden Auswahl sein: '''off heating defrost hotwater cooling pool poolheating'''
|-
|
|
|-
|'''pcurr'''
|der Schlüssel ist Pflichtangabe - Maximale Leistungsaufnahme der Wärmepumpe / Klimaanlage etc. in W.
|-
|
|
|-
|'''power'''
|maximale Leistungsaufnahme in W. Der Wert darf nicht! 0 sein. Der Schlüssel ist Pflichtangabe.
|-
|
|
|-
|'''swstate'''
|Schaltstatus des Kompressors. Die Syntax bleibt wie bei den anderen Consumern.
|-
|
|Abweichend von anderen Consumern ist die Angabe verpflichtend, auch wenn der default verwendet werden soll.
Durch Erstellung eines passenden userReadings (WP-komplett / WP-Heizen / WP-Kühlen / WP-WW-Aufbereitung etc.) kann damit gesteuert werden, ob man sowohl Laufzeiten für Heiz- und Kühlbetrieb, Warmwassererzeugung und Heizstabbetrieb etc. in einem Consumer zusammenfassen will, oder ob man z.B. ausschließlich nur die Laufzeiten des Heiz- und Kühlbetriebs als aktive Zeiten für die Heizung (Kühlung) in dem jeweiligen consumerXX separat erfassen möchte.
|-
|
|
|-
|
|Alle hier nicht angezogen Parameter sind wie in allen Verbrauchern zu nutzen
|}

=== Beispiel Registrierung eines Shelly Devices ===

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

Zwingende Angaben sind

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

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

consumerXX Shelly.shellyplug3 type=heater power=1700

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

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

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

Es werden weitere Schlüsseleingaben vorgenommen:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

'''Lösungsweg:'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

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

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

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

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

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

gfeedin: 4, feedprice: 0.1269

....

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

etotal=Total_Export_Energy_from_PV:kWh

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

Man kann mit dem Attribut:

ctrlDebug=collectData

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

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

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

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

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

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

 
=== Ich beobachte Blockierungen in meinem FHEM - ist SolarForecast eventuell der Verursacher? ===

==== Übersicht ====

Dieses Dokument beschreibt die systematische Vorgehensweise zur Analyse und Lokalisierung von Blockierungszuständen im Kontext von SolarForecast (SF). Es dient als allgemeine Handlungsanleitung, um Ursachen für Systemverzögerungen oder hängende Prozesse einzugrenzen.

==== Grundprinzipien der SF-Architektur ====

Bevor mit der Analyse begonnen wird, sind folgende Architekturmerkmale von SF zu verstehen:

* '''Alle API-Abfragen sind non-blocking''' ausgeführt. SF selbst blockiert den FHEM-Interpreter durch API-Kommunikation grundsätzlich nicht.
* '''Geräteabfragen und Datensammlungen''' erfolgen ausschließlich durch das Auslesen von Readings – '''nicht''' durch direkte Geräteabfragen. Die direkte Gerätekommunikation ist Aufgabe der jeweiligen Gerätemodule.
* '''Schaltvorgänge von Verbrauchern''' (Consumer) können potenziell Blockierungen verursachen, wenn das zugehörige Gerätemodul beim Schalten auf ein Schaltergebnis wartet (blockierender Aufruf im Gerätemodul).
* '''SF schreibt in regelmäßigen Abständen''' modulinterne Datenstrukturen in das Filesystem. Ein fehlerhaftes oder langsames Filesystem kann daher eine Blockierungsquelle darstellen.

==== Schritt-für-Schritt-Analyse ====

===== Schritt 1: Meldungen im Log identifizieren und zuordnen =====

Beim Auftreten von Auffälligkeiten zunächst das FHEM-Log auf bekannte Meldungen prüfen und deren Herkunft bestimmen.

{| class="wikitable"
! Beispielmeldung !! Herkunft !! Bedeutung
|-
| <code>Data cycle triggered, watch readings</code> || Rückmeldung der SF-Zentralschleife (von get <SF-Device> data) || Normaler Abschluss eines SF-Zyklus – zu diesem Zeitpunkt ist die Verarbeitung vollständig abgeschlossen. Kein Hinweis auf eine SF-interne Blockierung.
|-
| <code>SolCast DEBUG> AI FANN drift data type 'con' successfully written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_SolCast</code> || Eine Log-Ausgabe mit aktiviertem Debug || Logausgaben von SF erfolgen IMMER mit Angabe des SF-Namens (hier 'SolCast')
|-
| <code>There are still path commands in the action queue</code> || Nicht von SF stammende Rückmeldung || Hinweis auf eine Warteschlange in einem Gerätemodul. Ursache im jeweiligen Gerätemodul suchen, nicht in SF.
|}

'''Hinweis:''' Meldungen, die nicht von SF generiert werden, müssen beim Hersteller bzw. Maintainer des jeweiligen Gerätemoduls analysiert werden.

===== Schritt 2: Laufzeit der SF-Zentralschleife messen =====

Um zu beurteilen, ob SF selbst verzögert läuft, das Special Reading <code>runTimeCentralTask</code> aktivieren:

attr <SF-Device> ctrlSpecialReadings runTimeCentralTask

Dieses Reading liefert die '''Gesamtlaufzeit eines SF-Schleifenzyklus''' inklusive aller enthaltenen Abfragen und Verarbeitungsschritte.

'''Typische Werte:''' 0,2 – 0,3 Sekunden

===== Schritt 3: Laufzeiten loggen und auswerten =====

Die Werte des Readings <code>special_runTimeCentralTask</code> dauerhaft mitschreiben, um Ausreißer und zeitliche Muster zu erkennen:

* '''Logging:''' via FileLog oder DbLog
* '''Auswertung:''' via SVG-Plot oder DbRep

Durch die zeitliche Auswertung lässt sich erkennen:
* '''ob''' Blockierungen auftreten
* '''wann''' sie auftreten (Uhrzeit, Regelmäßigkeit)
* '''im Zusammenhang womit''' sie auftreten (z. B. Consumer-Schaltvorgänge)

===== Schritt 4: Consumer-Schaltvorgänge als Ursache prüfen =====

Falls Verbraucher (Consumer) aktiv geschaltet werden, ist dies eine '''priorisierte Spur''':

* Identifizieren, welche Gerätemodule beim Schalten eines Consumers involviert sind.
* Prüfen, ob diese Module '''blockierend''' auf ein Schaltergebnis warten.
* Zeitliche Korrelation zwischen Schaltvorgängen und erhöhten <code>runTimeCentralTask</code>-Werten im Log prüfen.

===== Schritt 5: Filesystem prüfen =====

Falls keine Consumer-Schaltvorgänge als Ursache infrage kommen oder die Blockierungen unregelmäßig und zeitlich nicht korreliert auftreten:

* '''Filesystem-Gesundheit''' des Systems prüfen (z. B. SD-Karte bei Raspberry Pi, NFS-Mounts, volle Partitionen).
* SF schreibt regelmäßig Datenstrukturen auf das Filesystem. Latenzen oder Fehler dabei können SF-Zyklen verzögern.
* Systemlogs (<code>dmesg</code>, <code>syslog</code>) auf I/O-Fehler oder -Warnungen prüfen.

==== Zusammenfassung: Checkliste ====

{| class="wikitable"
! # !! Prüfpunkt !! Tool / Methode
|-
| 1 || Log-Meldungen SF-intern oder fremd? || FHEM Logfile
|-
| 2 || <code>runTimeCentralTask</code> aktivieren || <code>ctrlSpecialReadings</code>
|-
| 3 || Laufzeiten loggen || FileLog / DbLog
|-
| 4 || Ausreißer zeitlich auswerten || SVG / DbRep
|-
| 5 || Korrelation mit Consumer-Schaltvorgängen? || Zeitvergleich im Log
|-
| 6 || Gerätemodul des Consumers auf blockierende Aufrufe prüfen || Modul-Doku / Maintainer
|-
| 7 || Filesystem auf Fehler / Latenz prüfen || <code>dmesg</code>, <code>df</code>, <code>iostat</code>
|}

==== Hinweise ====

* SF ist '''nicht''' der unmittelbare Verursacher, wenn Fremdmodule blockierende Aufrufe ausführen.
* Die Analyse sollte immer mit dem '''Logging der Laufzeiten''' beginnen, da nur so eine fundierte Aussage über Zeitpunkt und Häufigkeit möglich ist.
* Bei Meldungen unbekannter Herkunft stets das verantwortliche Gerätemodul identifizieren, bevor SF-interne Ursachen untersucht 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

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

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

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

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

</syntaxhighlight>

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

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

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

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

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

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

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

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

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

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

X+120 bis X+300

fertig sein.

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

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

Solange die Bedingung

mrest >= (mneed - msum)

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

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

</pre>

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

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

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

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

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

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

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

my $dhash = $defs{$dryer};

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

}
}

return;
}
</syntaxhighlight>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

return;
}
</syntaxhighlight>

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

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

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

 

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

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

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

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

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

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

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

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

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

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

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

my $loadcur = $maxcspc;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<syntaxhighlight lang="Perl">
forecast_json:nextCycletime.* {
use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

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

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

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

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

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

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

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

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

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
},
</syntaxhighlight>

[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]

Soll der Code zur Erstellung des userReadings forecast_json in die 99_myUtils ausgelagert werden, erstelle die Funktion ''forecast_json'' mit ergänztem Code:

<syntaxhighlight lang="Perl">
# - Perl Module laden
use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

forecast_json { <--- ändern
my $NAME = @_; <--- ergänzen
my $hour = 0;
my $last_start_ts;
my @output;
....
</syntaxhighlight>

Die Definition von userReadings in SolarForecast ändert sich zum Aufruf der Funktion in:

<pre>
userReadings forecast_json:nextCycletime.* { main::forecast_json($NAME) }
</pre>

Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):

<syntaxhighlight lang="Text">
define WEBapi FHEMWEB 8089 ---> (define WEBapi FHEMWEB IPV6:8089 global bei Verwendung von IPV6)
attr WEBapi csrfToken none
</syntaxhighlight>

==== evcc Integration ====
'''Konfiguration über die Datei evcc.yaml''' 

In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json','[]')} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.

<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
</syntaxhighlight>

'''Konfiguration über den UI-Editor''' 

In der aktuellen evcc-Version wird die Vorhersageintegration über den UI-Editor mit einer veränderten Syntax vorgenommen:

<syntaxhighlight lang="Perl">
tariff: solar
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
jq: |
map({
"start": .start,
"end": .end,
"value": .value
}) | tostring
</syntaxhighlight>

Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

 

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

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

'''Anforderungen:'''

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

'''Herausforderungen:'''

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

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

'''Ergebnis:'''

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

'''Definition der Consumer:'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

'''Pump High: (consumer03)'''
<syntaxhighlight lang="Perl">
dum_valve:Pool+High
aliasshort=High
type=other power=1000 asynchron=0
auto=pump_high_auto
icon=scene_pool
pcurr=pump_high_power
switchdev=dum_valve
swstate=pump_high:on:off
mode=can
mintime=SunPath
on="pump_high on"
off="pump_high off"
surpmeth=median_5
noshow=0
locktime=180:300
interruptable=1
swoncond=dum_valve:sf_true:{main::Check_Pump_High_On}
swoffcond=dum_valve:sf_true:{main::Check_Pump_High_Off}
</syntaxhighlight>Erläuterungen:

* Pump HIgh ist die selbe Pumpe, aber eine höhere Durchflussmenge
* Der Mehrverbrauch beträgt eigentlich 800W wird hier aber mit 1000W angegeben, um eine Hysterese von ca. 200W zu erreichen und damit ein schnelles Abschalten nach dem Einschalten zu verhindern.
* Diese Stufe wird nur bei genügend Überschuss aktiviert. (mode=can)
* Diese Stufe wird bei fehlendem Überschuss unterbrochen. (interruptable=1)
* Diese Stufe wird nur während Sonnenschein eingeplant. (mintime=SunPath)
* locktime sorgt dafür, dass bei schnell wechselnden Bedingungen, nicht ständig umgeschaltet wird. -> Schonung der Pumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Heatpump: (consumer05)'''
<syntaxhighlight lang="perl">
Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800 asynchron=0
icon=sani_heating_heatpump
auto=heatpump_auto
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
etotal=Pool_Pin32_monotonic_count_EnergyMeter:kWh
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=1
swoffcond=dum_valve:sf_true:{main::CheckWPOff}
</syntaxhighlight>Erläuterungen:

* Der Verbrauch ist hier wieder etwas zu hoch angegeben (1800W statt realen 1500W), um eine Hysterese zu erreichen.
* Da es sich hier um eine Wärmepumpe handelt, die nicht getaktet werden sollte, ist die locktime in beide Schaltrichtungen mit 10 Minuten relativ hoch.
* Die Ermittlung des Medians ist mit 13 Minuten recht lang, um den Überschuss über lange Zeit zu glätten, damit möglichst selten geschaltet wird. Diese 13 Minuten in Kombination mit der Locktime und der Hysterese führten bei dieser Anlage bisher dazu, dass höchstens 5 Zyklen am Tag geschaltet wurden. -> Hier kann das individuelle Schaltverhalten optimiert werden. Besseres Verfolgen des Überschusses vs. weniger Taktungen der Wärmepumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Nachbars Pool: (consumer07)'''
<syntaxhighlight lang="perl">
Shelly_Plug_S_1:Kurz+Pool
aliasshort=Kurz
type=other power=650 asynchron=0
icon=scene_pool
auto=pool_kurz_auto
pcurr=power:W
switchdev=dum_valve
swstate=pool_kurz:on:off
mode=can
mintime=SunPath
on="pool_kurz on"
off="pool_kurz off"
surpmeth=median_13
noshow=0
interruptable=1
locktime=600:300
swoncond=dum_valve:sf_true:{main::Check_Pool_Kurz_On}
swoffcond=dum_valve:sf_true:{main::Check_Pool_Kurz_Off}
</syntaxhighlight>Erläuterungen:

* Dieser Consumer dient als Einspeisebegrenzungsschutz und wird aktiviert, sobald sich der Überschuss der Einspeisegrenze nähert. -> siehe '''99_mySolarForecastUtils.pm'''
* Verbraucher kann recht träge geschaltet werden. (surpmeth=median_13 und locktime=600:300)
* Consumer wird ausgeschaltet wenn ein gewisser Überschuss unterschritten wird und somit die Einspeisegrenze wieder weit genug weg ist. -> siehe '''99_mySolarForecastUtils.pm'''
'''99_mySolarForecastUtils.pm'''

Hier sind die Funktionen, die für diese Regelung verwendet werden, der Übersichtlichkeit halber in einzelnen Blöcken mit Erklärungen dargestellt.
<syntaxhighlight lang="perl">
package main;
use strict;
use warnings;

my $pool_dummy = 'dum_valve';
my $pool_temperature = 'Pool_Temp';
my $flow_sensor = 'Pool_Pin_A0';
my $water_counter_l1 = 'pump_l1_hc';
my $water_counter_l2 = 'pump_l2_hc';
my $target_temp = 28.4; # maximum temperature for heating, without infeed limit
my $pool_kurz_sw_hofb = 'PwSw_Schalter'; # Homematic switch at pool neighbour
my $pool_kurz_sw_kurz = 'Shelly_Plug_S_1'; # Shelly switch for pool Kurz at home

my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;

my $switch_delay = 160; # just under three minutes

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

</syntaxhighlight>

* Hier werden die IDs der Geräte definiert, um über sprechende Namen darauf zugreifen zu können.
* Einige Devices und Parameter, die immer wieder gebraucht werden sind hier angegeben.
* sprintf wird verwendet um sicherzustellen, dass die IDs zweistellig sind. z.B. 3 -> 03

'''Pump Low'''
<syntaxhighlight lang="perl">
###################
### Pumpe - LOW ###
###################

sub
Check_Pump_Low_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'surpmethResult','');
my $nom_power = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'power','');
my ($min, $hour) = (localtime())[1,2];
my $timer = 0;
if($hour > 8 || ($hour == 8 && $min >= 0)){$timer=1;}

if(ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ($surplus > $nom_power
|| $timer
)
)
{
return 1;}
else
{
return 0;}
}

sub
Check_Pump_Low_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount > $desired_amount_l1)
&& (ReadingsVal($pool_dummy,"pump_high","on") eq "off" && ReadingsAge($pool_dummy,"pump_high",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{
return 1;
}else{
return 0;
}
}

</syntaxhighlight>Einschalten:

* Es wird der errechnete Wert für den Überschuss von SolarForecast verwendet und auch der benötigte Überschuss aus dem Consumer ausgelesen.
* Das Einschalten wird erst durch erfolgreiche Prüfung der Hardwarevoraussetzungen erlaubt. -> Das Motorventil steht richtig und es ist kein Sonderbetrieb (Reinigung, Massage, Winter, o.ä.) aktiv.
* Es muss entweder genügend Überschuss vorhanden sein oder es ist 8:00.

Ausschalten:

* Wenn der Badebetrieb aktiv ist (bath_mode==1, [bei Außentemperatur > 24°C]) wird nach 90m³ Gesamtumwälzung ausgeschaltet.
* Wenn der Badebetrieb nicht aktiv ist (bath_mode==0, [bei Außentemperatur < 20°C]) wird bereits nach 42m³ Gesamtumwälzung ausgeschaltet.
* Prüfung, ob Pump High schon aus ist. Sollte durch die Logik gar nicht möglich sein, aber es könnte manuell oder durch einen (Logik-)Fehler trotzdem eingeschaltet sein.
* Prüfung, ob alle Hardware-Funktionen in einem für die Automatik geeigneten Zustand sind.
* Es wird auch geprüft, ob Pump High seit mindestens 3 Minuten aus ist, um zu verhindern, dass wegen fehlendem Überschuss gleich mehrere Geräte ausgeschaltet werden.
* Da die Zykluszeit 60 Sekunden ist, führen die 160 Sekunden dazu, dass nach drei Minuten(180 Sekunden) ein definierter Wert gilt. Mit 180 Sekunden könnte es manchaml eine Minute mehr sein.

'''Pump High'''
<syntaxhighlight lang="perl">
####################
### Pumpe - HIGH ###
####################

sub
Check_Pump_High_On{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount < $desired_amount_l2)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_low","off") eq "on" && ReadingsAge($pool_dummy,"pump_low",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

sub
Check_Pump_High_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;

if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}
if(($amount > $desired_amount_l2)
&& (ReadingsVal($pool_dummy,"heatpump","on") eq "off" && ReadingsAge($pool_dummy,"heatpump",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs noch nicht erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob Pump Low schon seit mindestens drei Minuten aktiv ist. (sollte eigentlich immer der Fall sein, wenn die Automatik für Pump High aktiv ist)

Ausschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs bereits erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob die Wärmepumpe schon seit mindestens drei Minuten aus ist. Ermöglicht drei Minuten lang, den Median für den Überschuss zu aktualisieren.

'''Wärmepumpe'''
<syntaxhighlight lang="perl">
##################
### Wärempumpe ###
##################
sub
CheckWPOn(){
my $name = 'energy_mgmt';
my $surplus_on = 5000; # minimum surplus to avoid infeed limit with heatpump
my $surplus_restart = 3000; # minimum surplus to re-enable heatpump, when avoidung infeed limit and a big consumer turned the hp off

my $planstate = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'planstate','');
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if ($planstate =~ /^([^:]+)/) {
$planstate = $1;
}

if(ReadingsVal($flow_sensor,"reading","off") eq "on"
&& (ReadingsVal($pool_dummy,"special_function","") eq "none"
|| ReadingsVal($pool_dummy,"special_function","") eq "party"
)
&& ReadingsVal($pool_dummy,'heat_protection','on') eq "off"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_high","off") eq "on" && ReadingsAge($pool_dummy,"pump_high",0) > $switch_delay)
&& (ReadingsVal($pool_temperature,"temperature",30) < $target_temp
|| (ReadingsVal($pool_temperature,"temperature",15) >= $target_temp
&& ( $surplus > $surplus_on
|| (($planstate eq "replanned") && ($surplus > $surplus_restart))
)
)
)
)
{return 1}
else
{return 0}
}

sub
CheckWPOff{
my $name = 'energy_mgmt';
my $surplus_off = 1000; #minimum surplus to keep heatpump on, when avoiding infeed limit

my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if((ReadingsVal($flow_sensor,"reading","on") eq "off"
|| !((ReadingsVal($pool_dummy,"special_function","") eq "none")
|| (ReadingsVal($pool_dummy,"special_function","") eq "party")
)
|| ReadingsVal($pool_dummy,'heat_protection','off') eq "on"
|| ReadingsVal($pool_dummy,"valve_position","") ne "normal"
|| ((ReadingsVal($pool_temperature,"temperature",15) > $target_temp)
&& ($surplus < $surplus_off)
)
)
&& (ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob Flussensor ein. (Pool_pin_A0) -> Wasser fließt durch die Wärmepumpe.
* Prüfung, ob Pool in Normal- oder Partybetrieb ist und das Ventil in Normalposition ist. In beiden Fällen läuft Pump High.
* Einschalten wenn genug Überschuss da ist und die Temperatur <28.4°C ist oder wenn über 5000W Überschuss (Einspeisebegrenzung bei 5900W) da ist, egal wie warm der Pool ist.
* Sonderfall: Wenn die Wärmepumpe durch einen/mehrere Großverbrucher "kurz" ausgeschaltet wurde (swoffcond) wird sie ausgeplant. Ein Notify plant sie wieder ein. Wenn das passiert, soll die Wärmepumpe aber wieder bei 3000W Überschuss gestartet werden, um die Energie noch weiter zu nutzen bis der Überschuss unter 1000W fällt. (Hysterese von 500W, da die WP nur 1500W braucht)

Ausschalten:

* Ausschalten sobald hardwaremäßig irgendetwas faul ist. (Betriebsart, Ventilstellung, Durchfluss)
* Ausschalten wenn kein Überschuss. (interruptable=1)
* Wenn Wassertemperatur über 28,5°C und der Überschuss kleiner als 1000W ist.
* Nur schalten, wenn Wärmepumpe läuft und seit mindestens drei Minuten läuft (Sicherheit). Das verhindert das erneute Triggern des Notifys, wenn die Pumpe schon aus ist. Sollte nicht passieren, aber sicher ist sicher.

'''Nachbar Pool'''
<syntaxhighlight lang="perl">
###################
### Pool - KURZ ###
###################
sub
Check_Pool_Kurz_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus > 3000)
&& ((ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) >160) || ReadingsVal($pool_dummy,'heat_protection','off') eq 'on' ))
{return 1}
else
{return 0}
}

sub
Check_Pool_Kurz_Off{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus < 1000 )
&& (ReadingsVal($pool_dummy,"pool_kurz","off") eq "on" && ReadingsAge($pool_dummy,"pool_kurz",0) >160))
{return 1}
else
{return 0}
}
</syntaxhighlight>Einschalten:

* Überschuss ist nahe der Einspeisegrenze (5900W) und Wärmepumpe läuft seit mindestens drei Minuten. Es wird schon bei 3000W eingeschaltet, um dem Nachbarn etwas Gutes zu tun ;-)

Ausschalten:

* Überschuss ist unter 1000W. -> Um noch Reserven für den eigenen Verbrauch zu haben.

'''Hilfsfunktionen'''

'''ctrlUserExitFn'''

Hier erfolgt nach jedem Zyklus die Festlegung der verschiedenen Automatikmodi.
<syntaxhighlight lang="perl">
#############################################################
##################### Exit Function #########################
#############################################################
my $ctrl_dummy = "dum_valve"; # dummy device for pool-control
my $automatic = ReadingsNum($ctrl_dummy,"sf_automatic",1);

if($automatic){

my $pump_low_state = ReadingsVal($ctrl_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe

my $pump_high_state = ReadingsVal($ctrl_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe

my $heatpump_state = ReadingsVal($ctrl_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
my $pool_heat_protection = ReadingsVal($ctrl_dummy,'heat_protection','on');

my $pool_kurz_state = ReadingsVal($ctrl_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools

my $pump_low_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'surpmeth', '');
if ($pump_low_delay =~ /_(\d+)/) {
$pump_low_delay = int(($1/2 + 1) * 60);
Log3 ("SolarForecast", 1, "SolarForecast: pump_low_delay: $pump_low_delay");
} else {
$pump_low_delay = 220;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_low is: $pump_low_delay, but must be given as method_number, using fallback value");
}

my $pump_high_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'surpmeth', '');
if ($pump_high_delay =~ /_(\d+)/) {
$pump_high_delay = int(($1/2 + 1) * 60);
} else {
$pump_high_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_high is: $pump_high_delay, but must be given as method_number, using fallback value");
}

my $heatpump_delay = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'surpmeth', '');
if ($heatpump_delay =~ /_(\d+)/) {
$heatpump_delay = int(($1/2 + 1) * 60);
} else {
$heatpump_delay = 290;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for heatpump is: $heatpump_delay, but must be given as method_number, using fallback value");
}

my $pool_kurz_delay = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'surpmeth', '');
if ($pool_kurz_delay =~ /_(\d+)/) {
$pool_kurz_delay = int(($1/2 + 1) * 60);
} else {
$pool_kurz_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pool_kurz is: $pool_kurz_delay, but must be given as method_number");
}

############################
# Überhitzungsschutz aktiv #
############################

if($pool_heat_protection eq 'on'){
if($heatpump_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 0");
}
if($heatpump_state eq "on"){
fhem("set $ctrl_dummy heatpump off")
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pool_kurz_delay && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pump_high_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $pump_high_delay && $pool_kurz_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
##################################
# Überhitzungsschutz nicht aktiv #
##################################
}else{
if($heatpump_auto == 0 && $heatpump_state eq "off"){
if($pool_kurz_state eq "on"){
fhem("set $ctrl_dummy pool_kurz off");
}
if($pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $heatpump_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $heatpump_delay && $heatpump_auto == 0 && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "on" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pool_kurz_delay && $pump_high_state eq "on" && $pool_kurz_auto == 0 && $pump_high_auto == 1 && $heatpump_auto == 1){
# pump_high muss on sein, da sonst die automatik ausgeschaltet wird wenn die pumpe gerade interrupted ist.
# Bei unterschiedlichen Medianlängen ist es möglich, dass WP ein ist und pump_high abschaltet wegen surplus == 0
# Nachbarpool würde auf EIN warten, aber pump_high dürfte nicht wieder einschalten, obwohl genügend Überschuss da ist.
fhem("set $ctrl_dummy pump_high_auto 0");
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $heatpump_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $heatpump_delay && $pool_kurz_auto == 1 && $heatpump_auto == 0 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "off" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pump_high_delay && $heatpump_auto == 1 && $pump_high_auto == 0 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $heatpump_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 1 && $pool_kurz_auto == 0){
# heatpump muss aus sein, da sonst vor Ablauf der Locktime die Automatik ausgeschaltet wird und die WP nicht mehr ausschalten kann.
fhem("set $ctrl_dummy heatpump_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
}
}
#################################################
# Check hardware-state vs. reading-state
# re-trigger notify
#################################################
my $delay_retrigger = 100; #delay time to wait until re-trigger the notify

if(ReadingsVal($ctrl_dummy,'pool_kurz','on') eq 'off' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'on'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: off");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-off must be re-triggered");
DebianMail('mail@example.org','Notify Pool Kurz',"Notify hat nicht ausgeschaltet -> re-trigger");
}elsif(ReadingsVal($ctrl_dummy,'pool_kurz','off') eq 'on' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','on') eq 'off'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: on");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-on must be re-triggered");
DebianMail('mail@example.org','Notify Pool Kurz',"Notify hat nicht eingeschaltet -> re-trigger");
}elsif((ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_on' || ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_off') && ReadingsAge($pool_kurz_sw_kurz,'state',0) > $delay_retrigger){
# state not clear
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz state unclear");
DebianMail('mail@example.org','Status Pool Kurz unklar',"Status HM-Schalter set_xx");
}

}
1;
</syntaxhighlight>
'''Erläuterungen:'''

* '''Verzögerungen der einzelnen Stufen:'''
** Die delays der einzelnen Stufen werden aus den surpmethods berechnet. Das dient dazu, dass der Median mit den Werten nach dem ein-/ausschalten des vorheriegen Verbrauchers bis zur Hälfte + einen Wert gefüllt wird und somit sicher das Umschalten des vorherigen Verbrauchers den Median nicht mehr beeinflusst.
* '''Überhitzungsschutz:'''
** Da durch die Wärmepumpe Überschuss "verheizt" wird, der durch das Einspeiselimit gar nicht produziert würde, kann es vorkommen, dass der Pool unangenehm warm wird.
** Um das zu vermeiden gibt es ein Reading, welches gesetzt wird, wenn der Pool eine gewisse Temperatur überschreitet. Dieses Setzen und Zurücksetzen erfolgt mit einer Hysterese von 0.2°C, um ein Takten der Wärmepumpe zu verhindern. Diese 0.4°C sind bei dieser Wassermenge einige Stunden.
** Wenn der Überhitzungsschutz aktiv ist, wird die Wärmepumpe in der Kette übersprungen.
** Wenn sich der Hitzeschutz während des Betriebs ändert, wird die Wärmepumpe bzw. der Pool vom Nachbarn passend ausgeschaltet und die Modi entsprechend gesetzt.
* '''On-chain:'''
** Wenn am Morgen Pump Low seit $pump_low_delay aktiv ist und alle folgenden Consumer noch nicht, dann wird die nächste Stufe freigegeben. -> Pump High
** Wenn Pump High seit $pump_high_delay aktiv ist und alle folgenden Consumer noch nicht, wird die Wärmepumpe freigegeben. -> Heatpump
** Wenn die Wärmepumpe seit $heatpump_delay aktiv ist und der letzte Consumer noch nicht, wird der letzte Verbraucher freigegeben. -> Pool Kurz Gleichzeitig wird die Automatik für Pump High ausgeschaltet, da dieser Verbraucher erst unterbrochen werden darf wenn die Wärmepumpe aus ist!
** Wenn der letzte Verbraucher aktiviert ist, wird die Automatik der Wärmepumpe deaktiviert, da ja zuerst der letzte Verbraucher (Pool Kurz) wieder ausgeschaltet werden muss, bevor der vorletzte (Wärmepumpe) wieder ausgeschaltet werden darf. Da es keinen nachfolgenden Verbraucher mehr gibt, kann hier auf ein delay verzichtet werden, da es nicht passieren kann, dass zwei Verbraucher wegen sehr hohem Überschuss unmittelbar hintereinander geschaltet werden können.
[[Datei:Poolsteuerung mit unterschiedlichen Automatikmodi.jpg|alternativtext=Poolsteuerung|mini|Consumer der Poolsteuerung|500x500px]]
'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von fehlendem Überschuss jederzeit unterbrochen werden kann und der "folgende" Consumer, der auf das Einschalten wartet. Pump Low ist immer im Automatikmodus, da diese nie unterbrochen wird. (mode=must, interruptable=0)

* '''Off-chain:'''
** Wenn der letzte Verbraucher seit mindestens der delay-Zeit aufgrund von fehlendem Überschuss inaktiv war, im Automatikmodus ist und der vorherige Verbraucher nicht im Automatikmodus ist, wird der vorherige Verbraucher in den Automatikmodus geschaltet und wartet jetzt auch auf das Ausschalten. Wenn der Überschuss steigt, springt man wieder in die on-chain und der letzte Verbraucher wird eingeschaltet und die Automatik des vorletzten Verbrauchers deaktiviert.
** Wenn die Wärmepumpe seit mindestens der delay-Zeit aus ist, sich im Automatikmodus befind und Pump High noch nicht im Automatikmodus ist, wird die Automatik für den Nachbarpool ausgeschaltet, da er ja jetzt nicht mehr einschalten darf, da zuerst die Wärmepumpe ein sein müsste. Die Automatik von Pump High wird wieder aktiviert, da diese jetzt auf das Ausschalten wartet. Steigt der Überschuss wieder, wird in den entsprechenden On-chain Zweig gesprungen.
** Wenn Pump High mindestens die delay-Zeit aus ist, wird die Automatik der Wärmepumpe deaktiviert, da diese ja erst einschalten darf, wenn Pump High wieder läuft. Steigender Überschuss führt wieder zum aktivieren von Pump High und zum Sprung in den entsprechenden On-chain Zweig.
** Wenn Pump Low ausgeschaltet wird, wird sofort die Automatik für Pump High ausgeschaltet, da durch das spätere Ausschalten von (der evtl. wieder eingeschalteten) Pump High, hardwaremäßig wieder Pump Low aktiviert wird, aber durch SolarForecast nie ausgeschaltet wird, da Pump Low vor ein paar Minuten ja schon logisch ausgeschaltet wurde.

'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von neuem Überschuss jederzeit wieder gestartet werden kann und der "vorherige" Consumer, der auf das Ausschalten wartet.

* '''Synchronisation Hardware vs. Reading:'''Manchmal passiert es, dass durch die etwas aufwendigen Umschaltprozesse die Hardware dem Reading nicht folgt/folgen kann. Evtl. Gründe sind Funkunterbrechung, verzögerte Umschaltung usw. Daher wird bei jedem Zyklus der Status geprüft und evtl. das event nochmal getriggert, um die Umschaltung erneut auszuführen. 

'''Hilfs-Notifys für die Automatik'''

Da durch das Verwenden von swoffcond die Verbraucher beim Ausschalten auch ausgeplant werden, aber eigentlich "nur" unterbrochen werden sollen, müssen sie wieder neu eingeplant werden. Dazu sind notifys nötig. Wichtig: IDs müssen zweistellig angegeben werden!

Wärmepumpe:
<syntaxhighlight lang="perl">
dum_valve:heatpump:.off sleep 10; set energy_mgmt consumerNewPlanning 05
</syntaxhighlight>
Nachbar Pool:
<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.off sleep 10; set energy_mgmt consumerNewPlanning 07
</syntaxhighlight>

'''Eine Pumpe mit einem Energiezähler als zwei Consumer verwenden'''

Die verwendete Pumpe hat vier Betriebsarten mit unterschiedlichen Leistungen. Da sie als zwei Consumer abgebildet wird, führt das dazu, dass die Leistung fälschlicherweise von SolarForecast auch zweimal gezählt wird. Die Lösung sind Dummy-Readings, welche die Leistungsdaten passend auseinander rechnen.
<syntaxhighlight lang="perl">
Pool_Strom_Pumpe:Pool_Pin31_monotonic_count_PowerCurrent:.* {
my $power = $EVTPART1;
my $pump_low = ReadingsVal('dum_valve','pump_low','off');
my $pump_high = ReadingsVal('dum_valve','pump_high','off');
my $power_low_sim = 250;

if($pump_low eq "on" && $pump_high eq "on"){
my $power_low = $power_low_sim; #fiktiver Verbrauch der niedrigen Stufe
my $power_high = $power - $power_low_sim;
fhem("set dum_valve pump_low_power $power_low");
fhem("set dum_valve pump_high_power $power_high");
}
elsif($pump_low eq "on" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power $power");
fhem("set dum_valve pump_high_power 0");
}
elsif($pump_low eq "off" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power 0");
}elsif($pump_low eq "off" && $pump_high eq "on"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power $power");
}
}
</syntaxhighlight>
Erläuterungen:

* Es sind alle vier Möglichkeiten der zwei Pumpenlevel abgebildet.
* Wenn die Automatik deaktiviert ist und die Level 1-4 von extern geschaltet werden, zählen sie dadurch korrekterweise nicht zu diesen beiden Consumern.

'''Notifys für das hardwaremäßige Schalten der Consumer'''

Es werden einige Notifys verwendet, die die Umsetzung vom Dummy-Device auf die Hardware erledigen, da ein logisches Ein teilweise hardwaremäßig einige Dinge erfordert.

Notify für Pump Low:
<syntaxhighlight lang="perl">
dum_valve:pump_low:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 60; set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin14 off; sleep 5; set Pool_Pin12 off; sleep 15; set Pool_Pin25 off");
}else{
Log3 ("Pool", 4, qq{Notify Level1 - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterungen:

* Beim Einschalten ist es nötig für eine Minute Pump High zu aktivieren, um Luft aus der Elektrolysezelle zu spülen, bevor Pump Low aktiv sein darf. (Pin26 und Pin25 sind die Steuerpins auf der Interfacekarte der Pumpe für die beiden Level.)
* Beim Ausschalten werden zuerst die Salzanlage (Pin14) und die pH-Anlage (Pin12) deaktiviert, damit noch 15 Sekunden lang die Elektrolysezelle mit frischem Wasser gespült wird, um das verbleibende Chlor auszuspülen. 
Notify für Pump High:
<syntaxhighlight lang="perl">
dum_valve:pump_high:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 1; set Pool_Pin25 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}else{
Log3 ("Pool", 4, qq{Notify Level 2- parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Da die Interfacekarte immer auf den höchsten Level reagiert, wird beim Umschalten zuerst Pump High aktiviert und nach einer Sekunde Pump Low deaktiviert, um ein "stufenloses" (ohne Ausschalten) Umschalten zu ermöglichen. Beim Ausschalten genauso.

Notify für die Wärmepumpe:
<syntaxhighlight lang="perl">
dum_valve:heatpump:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin6 on");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin6 off");
}else{
Log3 ("Pool", 4, qq{Notify heatpump - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Hier reicht ein dirketes Übernehmen aus dem Dummy.

Notify für den Nachbar-Pool:
<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.* {
if($EVTPART1 eq "on" && ReadingsVal("Shelly_Plug_S_1","state","on") eq "off"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 on\")}}; sleep 5; set PwSw_Schalter on");
}elsif($EVTPART1 eq "off" && ReadingsVal("Shelly_Plug_S_1","state","off") eq "on"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 off\")}}; sleep 5; set PwSw_Schalter on");
}else{
Log3 ("Pool", 4, qq{Notify Pool Kurz - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung

* Da hier eine Pumpe durch einen 3-poligen Umschalter zwischen zwei Hausanspeisungen umgeschaltet wird, ist es wichtig, dass die Pumpe dazwischen '''gesichert''' zum Stehen gebracht wird! Sonst führt die rotierende Pumpe als Generator zu einem gewaltigen Kurzschluss mit der "fremden" Phase. War nicht schön ...

'''Sonderprogramme für den Poolbetrieb'''

Hier ist das Aus- und Einschalten der Solarforcast-Automatik zu sehen. Es werden alle Stati gespeichert. Danach kann von beliebigen "Sonderfunktionen" (Reinigung des Filters, Massagefunktion, usw.) auf die Hardware zugegriffen werden. Wenn wieder in den Automatikmodus zurückgewechselt wird, wird hardwaremäßig wieder der Zustand der Automatik von vorher hergestellt, die Stati wieder zurück geschrieben und die Automatik wieder aktiviert.
<syntaxhighlight lang="perl">
##############################################
# Status speichern und Automatik ausschalten #
##############################################
sub PoolAutoOff{
my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;
my $sf = 'energy_mgmt';

# my $pump_low_state = ReadingsVal($valve_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe
# my $pump_high_state = ReadingsVal($valve_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe
# my $heatpump_state = ReadingsVal($valve_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($sf, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
# my $pool_kurz_state = ReadingsVal($valve_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools
fhem("set $valve_dummy pump_low_auto 0");
fhem("set $valve_dummy pump_high_auto 0");
fhem("set $valve_dummy heatpump_auto 0");
fhem("set $valve_dummy pool_kurz_auto 0");
fhem("setreading $valve_dummy sf_automatic 0");
fhem("setreading $valve_dummy last_auto_pump_low $pump_low_auto");
fhem("setreading $valve_dummy last_auto_pump_high $pump_high_auto");
fhem("setreading $valve_dummy last_auto_heatpump $heatpump_auto");
fhem("setreading $valve_dummy last_auto_pool_kurz $pool_kurz_auto");

my $last_pump_level_1 = ReadingsVal($valve_dummy,"pump_low","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"pump_high","off");
my $last_pump_level_3 = ReadingsVal($pump_level_3,"value","off");
my $last_pump_level_4 = ReadingsVal($pump_level_4,"value","off");
my $last_heatpump = ReadingsVal($valve_dummy,"heatpump","off");
fhem("setreading $valve_dummy last_pump_level_1 $last_pump_level_1");
fhem("setreading $valve_dummy last_pump_level_2 $last_pump_level_2");
fhem("setreading $valve_dummy last_pump_level_3 $last_pump_level_3");
fhem("setreading $valve_dummy last_pump_level_4 $last_pump_level_4");
fhem("setreading $valve_dummy last_heatpump $last_heatpump");
}

##########################################
# Status laden und Automatik einschalten #
##########################################
sub PoolAutoOn{
my $last_pump_level_4 = ReadingsVal($valve_dummy,"last_pump_level_4","off");
my $last_pump_level_3 = ReadingsVal($valve_dummy,"last_pump_level_3","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"last_pump_level_2","off");
my $last_pump_level_1 = ReadingsVal($valve_dummy,"last_pump_level_1","off");
my $last_heatpump = ReadingsVal($valve_dummy,"last_heatpump","off");
fhem("set $pump_level_4 $last_pump_level_4");
fhem("set $pump_level_3 $last_pump_level_3");
fhem("set $pump_level_2 $last_pump_level_2");
if($last_pump_level_1 eq "on" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_2 on; sleep 1; set $pump_level_1 $last_pump_level_1; sleep 28; set $pump_level_2 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "on" && $last_pump_level_2 eq "on" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "off" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}
fhem("sleep 10; set $heatpump $last_heatpump");
fhem("setreading $valve_dummy last_pump_level_1 none");
fhem("setreading $valve_dummy last_pump_level_2 none");
fhem("setreading $valve_dummy last_pump_level_3 none");
fhem("setreading $valve_dummy last_pump_level_4 none");
fhem("setreading $valve_dummy last_heatpump none");
fhem("setreading $valve_dummy valve_position normal");
my $last_auto_pump_low = ReadingsVal($valve_dummy,"last_auto_pump_low",0);
my $last_auto_pump_high = ReadingsVal($valve_dummy,"last_auto_pump_high",0);
my $last_auto_heatpump = ReadingsVal($valve_dummy,"last_auto_heatpump",0);
my $last_auto_pool_kurz = ReadingsVal($valve_dummy,"last_auto_pool_kurz",0);
fhem("set $valve_dummy pump_low_auto $last_auto_pump_low");
fhem("set $valve_dummy pump_high_auto $last_auto_pump_high");
fhem("set $valve_dummy heatpump_auto $last_auto_heatpump");
fhem("set $valve_dummy pool_kurz_auto $last_auto_pool_kurz");
fhem("setreading $valve_dummy last_auto_pump_low none");
fhem("setreading $valve_dummy last_auto_pump_high none");
fhem("setreading $valve_dummy last_auto_heatpump none");
fhem("setreading $valve_dummy last_auto_pool_kurz none");
}
</syntaxhighlight>Erläuterungen:

* pump_level_1 ist Pump Low, pump_level_2 ist Pump High, pump_level_3 und pump_level_4 sind Sonderfunktionen (Filterreinigung, Massage)
* Beim Wiedereinschalten von Pump Low ist es wieder nötig kurz Pump High zu aktivieren, um Luft auszuspülen.
* Es wird der Zustand von Solarforecast gespeichert und danach auf die Hardware geschrieben. -> Stellt sicher, dass nach dem Einschalten der Automatik der logical switchstate zum physical switchstate passt.

=== Wärmepumpe (Buderus oder Bosch) per MQTT-Modul & BBQKees-EMS-Modul als besonderen ConsumerXX (Heatpump) für die Consumption-Prognose bei den Berechnungen in der AI::FANN einbinden ===
'''Vorhandene Hardware:'''

* FHEM auf einer bestehenden Hardware mit bestehendem Solarforecast
* Buderus WLW186-i 7 MB AR E
* WW-Speicher 290 ltr.
* Heizungspuffer 120 ltr.
* HK1 = FBH - - mit 1 x HK-Pumpe ON/OFF und 1x Mischer
* HK2 = (Rest-)Heizkörper im EG/1OG/Handtuchw. - mit 1 x HK-Pumpe ON/OFF (ohne Mischer)
* HK3 = Heizkörper KG (einheitlich max 16 Grad) - mit 1 x HK-Pumpe ON/OFF (ohne Mischer)
* Zusatzheizstab für Sommerbetrieb im WW-Speicher - Nutzung erfolgt nur bei PV-Überschuß tagsüber oder genügend Batterierladung am frühen Morgen gegen 04:00 Uhr.

'''Anforderungen / notwendige Einstellung :'''

* SF ist in Betrieb und die AI::FANN sollte sich aktiv im Einsatz.
* Wärmepumpe befindet sich dauerhaft im temperaturgeführten Betriebsmodus.
* BBQKees-EMS-ESP-Modul ist angeschlossen, installiert, in Betrieb und kann per Webbrowser erreicht werden. Beispieleinrichtung: [[Datei:Einstellung - MQTT - BBQKees.png|ohne|mini|300x300px|Einstellung - MQTT - BBQKees]]
* '''MQTT-Modul greift in FHEM auf die WP mittels BBQKees-EMS-Modul zu.''' Beispiel-Device:
<syntaxhighlight lang="perl">
defmod MQTT_EMSwp MQTT2_DEVICE MQTT_EMSwp
attr MQTT_EMSwp DbLogExclude BSSID,IODev,IPv4_address,IPv4_gateway,IPv4_nameserver,IPv6_address,MAC,SSID,apicalls,\
apifails,attrTemplateVersion,boiler_data_auxheaterdelay,boiler_data_auxheaterlevel,\
boiler_data_auxheateroff,boiler_data_auxheateronly,\
boiler_data_auxheatersource,boiler_data_auxheatrmode,boiler_data_auxlimitstart,\
boiler_data_auxmaxlimit,boiler_data_burn2workmin,\
boiler_data_burnstarts,boiler_data_burnworkmin,boiler_data_dhw_alternatingop,boiler_data_dhw_altopprio,\
boiler_data_dhw_altopprioheat,boiler_data_dhw_comfdiff,boiler_data_dhw_comfort1,\
boiler_data_dhw_comfstop,boiler_data_dhw_disinfecting,boiler_data_dhw_disinfectiontemp,\
boiler_data_dhw_ecodiff,boiler_data_dhw_ecoplusdiff,\
boiler_data_dhw_ecoplusoff,boiler_data_dhw_ecoplusstop,boiler_data_dhw_ecostop,\
boiler_data_dhw_flowtempoffset,boiler_data_dhw_hystoff,boiler_data_dhw_hyston,boiler_data_dhw_maxheat,\
boiler_data_dhw_onetime,boiler_data_dhw_recharging,boiler_data_dhw_seltemp,\
boiler_data_dhw_seltemplow,boiler_data_dhw_seltempsingle,boiler_data_dhw_tempecoplus,\
boiler_data_dhw_workm,bootTime,boot_time,bus_status,connected,freemem,heartbeat_.*,mqttcount,mqttfails,\
mqttreconnects,network,rssi,rxfails,rxreceived,txfails,txreads,txwrites,uptime,uptime_sec,wifistrength,wifireconnects,\
thermostat_data_datetime
attr MQTT_EMSwp autocreate 1
attr MQTT_EMSwp bridgeRegexp heartbeat:.* { json2nameValue($EVENT) }
attr MQTT_EMSwp comment
Autorisierung / Token: \
The bearer Access Token (JWT) is used to authenticate HTTP requests and can be obtained from the \
WebUI's Settings->Security->Manage Users page and then clicking on the key icon for the user that has admin privileges (is Admin set). \
The token is generated using a combination of the username and a secret key which is the super user (su) password found in the WebUI's Settings->Security->Security Settings page. \
This 152 character long string must be included in the HTTP header as "Authorization: Bearer {ACCESS_TOKEN}". Note the token has no expiry date.\
\
<bearer Acts Token> "dieser WLW186-7 MB AR E" = {ACCESS_TOKEN}\
Beispiele :\
#############\
# Most GETs do not need authentication\
% curl http://ems-esp.local/api/thermostat/seltemp\
\
# POSTs (with -d) need authentication tokens\
% curl http://ems-esp.local/api/thermostat/seltemp \\
-H 'Content-Type: application/json' \\
-H 'Authorization: Bearer <bearer Acts Token>' \\
-d '{ "value" : 22.5 }'\
\
# GET with authentication using query parameter with token\
% curl http://ems-esp.local/api/system/publish\?access_token\="ey.......0"\
\
# GET to restart EMS-ESP\
curl http://ems-esp.local/api/system/restart -H 'Authorization: Bearer ey....0'\
\
# This example will get the system info, via a GET request\
curl -X GET ${emsesp_url}/api/system/info\
\
# This example will execute a read command on product ID 8 and type ID 1\
curl -X POST \\
-H "Authorization: Bearer ${<bearer Acts Token>}" \\
-H "Content-Type: application/json" \\
-d '{"data":"8 1"}' \\
${emsesp_url}/api/system/read\
\
# This example will export all values to a json file, including custom entities, sensors and schedules\
curl -X POST \\
-H "Authorization: Bearer ${<bearer Acts Token>}" \\
-H "Content-Type: application/json" \\
-d '{"action":"export", "param":"allvalues"}' \\
${emsesp_url}/rest/action
attr MQTT_EMSwp disable 0
attr MQTT_EMSwp event-min-interval .*:600
attr MQTT_EMSwp event-on-change-reading .*
attr MQTT_EMSwp icon air_water_heating_pump
attr MQTT_EMSwp model ems-esp_heater_device
attr MQTT_EMSwp readingList MQTT_EMSwp:ems-esp/heartbeat:.* { json2nameValue($EVENT) }\
MQTT_EMSwp:ems-esp/status:.* status\
MQTT_EMSwp:ems-esp/info:.* { json2nameValue($EVENT) }\
MQTT_EMSwp:ems-esp/heating_active:.* heating_active\
MQTT_EMSwp:ems-esp/tapwater_active:.* tapwater_active\
MQTT_EMSwp:ems-esp/boiler_data:.* { json2nameValue($EVENT, 'boiler_data_', $JSONMAP) }\
MQTT_EMSwp:ems-esp/thermostat_data:.* { json2nameValue($EVENT, 'thermostat_data_', $JSONMAP) }\
MQTT_EMSwp:ems-esp/mixer_data:.* { json2nameValue($EVENT, 'mixer_data_', $JSONMAP) }
attr MQTT_EMSwp room EnergieWP,MQTT2_DEVICE
attr MQTT_EMSwp setList restart:noArg heartbeat:.* { json2nameValue($EVENT) }
attr MQTT_EMSwp stateFormat T=>> Out: boiler_data_outdoortemp ModeCirc: thermostat_data_dhw_circmode WW: boiler_data_dhw_curtemp Circ: boiler_data_dhw_circ VL: boiler_data_curflowtemp RL: boiler_data_rettemp HC1-Flow: mixer_data_hc1_flowtemphc P.-Status HK1: mixer_data_hc1_pumpstatus P.-Status HK2: mixer_data_hc2_pumpstatus HP_Power_Current: boiler_data_hpcurrpower HP_Power_Reduction: boiler_data_powerreduction
attr MQTT_EMSwp userReadings user_WP_JAZ_overall {\
if ((ReadingsNum($name,"boiler_data_metertotal",0) > 0) && (ReadingsNum($name,"boiler_data_nrgtotal",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum($name,"boiler_data_nrgtotal",0)/ReadingsNum($name,"boiler_data_metertotal",0))));;;;\
}\
},\
\
user_WP_JAZ_year \
{\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionYear",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalYear",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalYear",0)/ReadingsNum("Dum.Energy","WPGridConsumptionYear",1))));;;;\
}\
},\
\
user_WP_JAZ_month {\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionMonth",0) > 0)&& (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalMonth",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalMonth",0)/ReadingsNum("Dum.Energy","WPGridConsumptionMonth",1))));;;;\
}\
},\
\
user_WP_JAZ_day {\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionDay",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalDay",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalDay",0)/ReadingsNum("Dum.Energy","WPGridConsumptionDay",1))));;;;\
}\
}, \
\
user_WP_JAZ_hour {\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionHour",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalhour",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalhour",0)/ReadingsNum("Dum.Energy","WPGridConsumptionHour",1))));;;;\
}\
}, \
</syntaxhighlight>Anmerkung: user_WP_JAZ_XXXX für Tag/Monat/Jahr werden in einem separatem Dummy (für diese Zeiträume) bei mir berechnet. Allein user_JAZ-overall (Betrachtung der gesamten WP-Betriebszeit) wird in diesem MQTT-Device aus den hier im Device vorhanden Zahlenwerte berechnet.
* '''Definierung des attr Heatpump-"consumerXX" in SF'''
<syntaxhighlight lang="perl">
SMA_Elgris_EM2
####>>> EM-Gesamtenergieflüsse der WP
type=heatpump
####>>> "Spezial"-Consumer - keine ON/OFF-Schaltung des Consumer durch SF bei Typ heatpump möglich !!!
power=2500
####>>> ich untertreibe hier immer etwas extra - es wird bei mir sehr wenig bis zu 3100 W verbraucht
icon=sani_heating_heatpump@orange
####>>> oder ein anderes icon nach Wahl oder des Vorhandenseins.
pcurr=Bezug_Wirkleistung:W
####>>> aus dem EM
etotal=Bezug_Wirkleistung_Zaehler:kWh ## aus dem EM
####>>> aus dem EM
switchdev=MQTT_EMSwp
####>>> wenn man zukünftig evtl. selber schaltent eingreifen möchte
swstate=boiler_data_hpactivity:heating|cooling|hot.*:off
####>>> auf die WP-Readings zugreifen
comforttemp=MQTT_EMSwp:thermostat_data_hc1_comforttemp
####>>> Komfortemperatur des Referenzraumes (Wert für Prognose AI::FANN) meist der Wohnraum
####>>> Komfortemperatur kann auch als fester Wert - z.B. 20 - eingeben werden.fest
</syntaxhighlight>Anmerkung: Kommentarzeilen bitte besser löschen falls dieser Beispiel-Code 1:1 genutzt werden soll.
* '''Definierung des attr "setupEnviroment" in SF'''
<syntaxhighlight lang="perl">
outsideTemp=MQTT_EMSwp:boiler_data_outdoortemp
####>>> Aussentemperatur - alternativ ein anderer T-Füher oder Wetter-App-Wert
presence=Forecast:user_presence:present
####>>> Anwesenheit der Bewohner mitteilen - ansonsten geht die AI::FANN in SF immer von "Anwesend" aus
</syntaxhighlight>Anmerkung:

Kommentarzeilen bitte besser löschen falls dieser Beispiel-Code 1:1 genutzt werden soll.

* '''Definierung von notwendigen zusätzlichen "UserReadings" für "presence" in SF:'''
<syntaxhighlight lang="perl">

user_presence {if(ReadingsVal("Handy_01","state","") eq "present") {return "present"} elsif (ReadingsVal("Handy_02","state","") eq "present") {return "present"} else {return 0}},

</syntaxhighlight>Anmerkung: Hier wird (über die Fritzbox / PRESENCE - Device) mittels der Handys für 2 Personen die Anwesenheit festgestellt und SF bzw. der AI::FANN über das obige setupEnviroment dann (entweder - oder) als "true" mitgeteilt. Erweiterung auf 3/4/5.... möglich.
* Definierung der AI::FANN: Beispiel : -> muss nicht zutreffend sein -> auch ich habe lange getestet und ändere ab und an mal die Einstellung -> Ergänzung bei Einsatz der AI::FANN (nicht Ersatz für bestehende eintrage ohne AI::FANN)

'''Ergebnis:'''

Im folgenden Bild sieht man das Ergebnis:
[[Datei:Ergebnis AI-FANN Consumer-Forecast.png|ohne|mini|Ergebnis der AI-FANN Prognose]]

== Tips & Tricks ==
* Interruptable verhält sich völlig anders, wenn der Perlcode 1 oder 0 liefert, als wenn man 1 oder 0 in der Config hinterlegt. -> siehe commandref
* Rückgabewert bei swoncond und swoffcond wird mit dem Readingswert verglichen und nicht dirket verwendet. Bsp. wenn das Reading 100 enthält muss auch der Rückgabewert des Perlcodes 100 liefern, um true zu ergeben.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung

2026-10-11T12:39:14Z

Maista: zwei kleine Verbesserungen

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

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

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

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

::* optionale KI Unterstützung der Prognose des Energieverbrauchs der kommenden Stunden

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

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

::* Sprachensupport EN / DE

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

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

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

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

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

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

::* Einbindung von bis zu 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.

== Rahmenbedingungen und Voraussetzungen ==

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

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

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

define <Name> SolarForecast

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

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

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

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

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

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

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

set <Name> plantConfiguration check

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

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

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

 
=== Hinweise zur Struktur der Attribute ===

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

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

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

Beispiele für zusammengesetzte Attribute sind:

* aiControl
* plantControl
* setup* Attribute

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

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

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

 

=== Einrichtung der Wechselrichter mit setupInverterDevXX ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* '''dc2ac=<Readingname>:<Einheit>'''

Dieser Schlüssel ist nur für einen Batterie-Wechselrichter setzbar. Das Reading liefert die aktuelle Leistung, die der Wechselrichter aus einer Gleichstromquelle, d.h. einer Batterie oder einem Solar-Ladegerät, in Richtung des Hausnetzes (AC) wandelt .

* '''capacity=<max. WR-Leistung>'''

In dem Schlüssel ''capacity'' wird die maximal mögliche Leistung in Watt (ohne Einheit) angegeben, die der Wechselrichter lt. seinem Datenblatt in der Lage ist zu leisten.

Die Angabe ''capacity'' hat in erster Linie die Aufgabe, die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die installierten Peak-Leistungen der PV-Module höher als die angeschlossene Wechselrichter-Leistung bzw. kommt es vor, dass die KI / (korrigierte) API-Prognose über der maximal möglichen Wechselrichter-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene ''capacity'' begrenzt.

Der Wert in diesem Schlüssel kann, wie andere Schlüssel auch, dynamisch zur Laufzeit mit dem Set-Befehl "[[#Hinweise zur Struktur der Attribute|set <Name> attrKeyVal ...]]" geändert werden. Ein Beispiel zur Anwendung ergibt sich aus folgendem Szenario.

Gegeben sei eine Anlage die aus Solarzellen (1300 W Peak) mit einem Solar-Ladegerät mit max. 1800 W Leistung, einer Batterie und einem Batterie-Wechselrichter besteht. Die Anlage versorgt nur das Hausnetz. Eine Netzeinspeisung ist nicht vorgesehen oder nicht erlaubt.

Nehmen wir an, es ist ein Tag voller Sonnenschein prognostiziert und die Batterie ist zunächst entladen. Der Haushalt verbraucht 300 W. Dann würden die PV-Module Module ihre volle Leistung von 1300 W Peak leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, weil:

* sie niedriger ist als die nominale und angegebene Wechselrichter Kapazität von ''capacity=1800''
* die erzeugte Energie anteilig für die Verorgung des Hauses und die Aufladung der Batterie verwendet wird

Anders verhält es sich wenn nach einer gewissen Zeit die Batterie voll ist und weiterhin volle PV Leistung zur Verfügung steht. In diesem Fall würde der Haushalt seine benötigte Leistung von 300 W abnehmen, aber das Solar-Ladegerät kann keine weitere Leistung mehr abgeben, da die Batterie bereits voll geladen ist, d.h. die Anlagensteuerung würde die PV-Anlage abregeln. In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Energie auf 300 Wh (bzw. den durchschnittlichen Energieverbrauch des Hauses pro Stunde) begrenzt werden, damit die PV-Prognose nach unten angepasst wird und so eine realitätsnahere Prognose ermöglicht wird.

* '''icon=<aktiv>[@<Farbe>][:<inaktiv>[@<Farbe>]]'''

Jeder Wechselrichter wird im Standard durch ein Icon getrennt nach Tag und Nacht, d.h. je nach Aktiv-Status und Inaktiv-Status, symbolisiert.

;Tag bzw. Aktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Sonnensymbol im Standard verwendet. Batterie-Wechselrichter verwenden ein gefärbtes Invertersymbol.

;Nacht bzw. Inaktivität: Für Wechselrichter mit angeschlossenen PV-Modulen wird ein entsprechend gefärbtes Symbol der aktuellen Mondphasen im Standard verwendet. Batterie-Wechselrichter verwenden ein ausgegrautes Invertersymbol.

Wie angegeben, kann man für Tag und Nacht jeweils ein Wunsch-Icon, wenn gewünscht mit einer alternativen Färbung, auswählen.

icon=inverter@darkorange:inverter@gray

Soll nur das Icon für die Nacht bzw. Inaktivät geändert werden, kann dies in dieser Form angegeben werden:

icon=:inverter@gray

(beachte den führenden ':')

 
==== Definition von Hybrid-Wechselrichtern ====

Zur Zeit der Erstellung dieses Abschnittes ist es in der SolarForecast Version 1.58.x nicht möglich, einen Hybridwechselrichter nativ zu definieren. Als Workaround wird eine passende Kombination aus PV-Wechselrichter und Batterie-Device oder einer Kombination aus PV-Wechselrichter + Batterie-Wechselrichter und Batterie-Device erstellt.

Bei allen benutzten Methoden ist es sehr wichtig!, dass die geforderten Inhalte der jeweilige Attributschlüssel beachtet und eingehalten werden. So ist zum Beispiel die Angabe von:

* '''pvOut''' - Ein Reading, welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz oder öffentliche Netz geliefert wird, bereitstellt. Es wird ein positiver numerischer Wert erwartet.

bei einem PV-Wechselrichter ein Reading welches ausschließlich die Leistung liefert, die von den Solarzellen-Generatoren erzeugt wird. Elemente von Batterieleistungen oder Gridbestandteile dürfen hier nicht enthalten sein. Sind in den Gerätemodulen diese Readings in dieser Form nicht enthalten, bietet es sich an, userReadings zur Erstellung von zusätzlichen Readings in den Quellendevices zu nutzen um den nötigen Input für SolarForecast bereitzustellen.

So wird zum Beispiel bei einem Batterie-Wechselrichter gefordert, dass die Readings '''ac2dc''' (AC->DC-Leistung Hausnetz zur Batterie) und '''dc2ac''' (DC->AC-Leistung (Batterie zum Hausnetz) '''jeweils als als positiver Wert''' anzugeben ist. Manche Batterie-Devices stellen allerdings nur ein Reading zur Verfügung, welches vorzeichenbehaftet die Leistungen in die Batterie bzw. aus der Batterie heraus liefert. Mit einem userReadings Attribut kann aus diesem Reading zwei neue Readings erzeugt werden:

<pre>
attr <Name> userReadings BatIn:DC_Power_value.* {
my $pwr = ReadingsVal ($name, 'DC_Power_value', 0);
$pwr = $pwr > 0 ? $pwr : 0;
$pwr
},
BatOut:DC_Power_value.* {
my $pwr = ReadingsVal ($name, 'DC_Power_value', 0);
$pwr = $pwr < 0 ? - $pwr : 0;
$pwr
},
</pre>

Ist das Quellenreading ''DC_Power_value'' positiv, stellt der Wert AC->DC-Leistung dar und wird als neues Reading BatIn bereitgestellt. Mit einem negativen Vorzeichen ist es eine DC->AC-Leistung und wird in dem neuen Reading BatOut '''ebenfalls als positiver Wert''' bereitgestellt. Auch hier gilt der Grundsatz, dass zum Beispiel BatOut nur die von der Batterie gelieferte Energie und keinen Mix aus Batterie- und PV-Energie enthalten darf.

===== Integration eines DEYE SUN-12K-SG04LP3-EU =====

[[Datei:Screenshot 2025-09-23 203955.png|right|thumb|400px|DEYE SUN-12K-SG04LP3-EU Grundlegende Systemarchitektur]]

Der DEYE vereint wie wohl alle bzw. die meisten Hybrid-Wechselrichter die Anschlüsse:

* Eingang Solar-Strings
* Anschluß Batteriespeicher
* AC-Anschluß öffnetliches Netz
* AC-Anschluß Ersatzlast (wird bei Netzausfall weiter versorgt)
* AC-Anschluß Notstromgenerator bzw. netzgekoppelter anderer Wechselrichter (hier ist ein Growatt Micro-Wechselrichter angeschlossen)

Für die Integration werden die setup-Attribute durch das FHEM Device ''Deye_Inverter'' besetzt:

* setupInverterStrings zur Definition der vorhandenen Solarstrings
* setupInverterDev01 zur Definition der Inverteranschlüsse und Eigenschaften
* setupBatteryDev01 integriert die Batterie
* setupMeterDev liefert die Daten für Netzbezug und Netzeinspeisung

Das nachfolgend verwendete Device ''Deye_Inverter'' ist ein MQTT-Device. Es bekommt Daten vom Deye-Hybridwechselrichter per MQTT und sendet Einstellungen zum Deye, bspw. maximaler Lade/Entladestrom des Akkus, Laden des Akkus aus dem Netz, Ein- und Ausschalten des Micro-Inverter-Ports.
Das Reading ''Deye_Growatt_power'' im Schlüssel ''pvOut'' ist eine Addition aus den Daten des Deye WR und des angeschlossenen Growatt Micro-Wechselrichters.

<pre>
attr <Name> setupInverterStrings Sueddach,Garagendach
attr <Name> setupInverterDev01 Deye_Inverter pvOut=Deye_Growatt_power:W capacity=15200 etotal=total_pv_production:kWh
attr <Name> setupBatteryDev01 Deye_Inverter pin=-pout pout=battery_output_power:W intotal=total_charge_of_the_battery:kWh outtotal=total_discharge_of_the_battery:kWh cap=15200 charge=SOC_jkbms
attr <Name> setupMeterDev Deye_Inverter gcon=total_grid_power:W contotal=total_energy_bought:kWh gfeedin=-gcon feedtotal=total_energy_sold:kWh
</pre>

''setupInverterStrings'' benennt alle vorhandenen Solarstrings. Werden mehrere Inverter definiert, kann mit dem hier nicht verwendeten Schlüssel ''strings'' eine Zuordnung der Strings zum angeschlossenen Inverter vorgenommen werden.

Im Attribut ''setupInverterDev01'' ist der allgemeine Schlüssel ''capacity'' zur Festlegung der Inverterleistung von 15200 Watt gesetzt. Die spezifischen Schlüssel ''pvOut'' und ''etotal'' teilen dem Modul die aktuell erzeugte PV-Leistung sowie die gesamte erzeugte PV-Energie mit. Letzteres dient unter anderem dazu die stündlich real erzeugte PV-Energie festzuhalten und mit der Prognose zu vergleichen. Die in den schlüsseln hinterlegten dürfen keine Batterie- oder Netzanteile enthalten.

Das Attr ''setupBatteryDev01'' implementiert alle relevanten Batteriewerte. Das Reading ''battery_output_power'' im Schlüssel ''pout'' liefert den Batterie-Output als positiven Wert. Als Besonderheit kann der Wert ''pin'', die Batterie-Ladeleistung, den Wert des Readings in ''pout'' übernehmen wenn dieser Wert ein negatives Vorzeichen hat. Die Schlüssel ''intotal'' und ''outtotal'' liefern die summierten Totalwerte für Batterie Ladung bzw. Entladung. Die Kapazität ''cap'' wird für verschiedene Aspekte der SoC- und Ladesteuerung verwendet.

Abschließend liefern die angegebenen Readings in den Schlüsseln des Attributes ''setupMeterDev'' alle notwendigen Werte des Netzbezugs und der Netzeinspeisung.

Nachfolgende Links liefern '''weitere Infos''' wie man Daten aus dem Deye WR ausliest und Einstellungen des Deye WR verändert:

* https://github.com/klatremis/esphome-for-deye
* https://github.com/philipphenkel/esphome-config
* https://github.com/bagges/deye-esp32-bridge

Für eine weiterführende Automation soll der Akku netzdienlich in der Mittagszeit geladen werden. Dazu wurde durch den Anwender folgendes userReadings ''MaxBattCharge_Request'' im Device ''Deye_Inverter'' für den maximalen Ladestrom definiert (bei 90% SOC und bei 100% SOC):

<pre>
MaxBattCharge_Request:SOC_jkbms.* {
if ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) < 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') < 561600)
{100}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) < 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') >= 561600)
{100}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) >= 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') < 561600)
{ceil ((90-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310/3.5)}
elsif ((ReadingsNum('mySolarForecast','RestOfDayPVforecast','')
- ReadingsNum('mySolarForecast','special_todayConForecastTillSunset','')
- (100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310*51.2) >= 400
and ReadingsAge('JK_BMS','capacity_full_timestamp','') >= 561600)
{ceil ((100-ReadingsNum('JK_BMS','capacity_remaining',''))/100*310/3.0)}
}
</pre>

Das userReading wird in einer Automation benutzt, um den maximalen Ladestrom einzustellen; Ladebeginn bei ausreichend Sonne ist ab 11:30 eingestellt.

 
===== Integration eines Fronius Symo GEN24 10.0 Plus mit (virtuellen) Batterie-Wechselrichter =====

[[Datei:Screenshot 2025-10-04 162422.png|right|thumb|400px|Flußgrafik mit eingebauten Hybrid-Wechselrichter]]

Die Integration des Wechselrichters Fronius Symo GEN24 10.0 Plus benötigt zunächst eine Anbindung in FHEM, was mit dem Modul 98_fronius.pm vorgenommen wurde.

Das Ziel der Kurzdokumentation ist neben der Darstellung eines Hybridwechselrichters aufzuzeigen, wie man den Wandlungsverlust eines PV-Wechselrichters (pvIn – pvOut) in Näherung visualisieren kann.
'''pvIn''' ist dabei die Summe der Produkte aus den DC Strom- und Spannungswerten der einzelnen Strings (hier 2109 W), '''pvOut''' (hier 2065 W) ist die an den Inverterknoten (hier 1105 W) plus die an die Batterie abgegebene Leistung (hier 960 W). Bei dieser Implementierung wird mit einem zusätzlichen (virtuellen) Batterie-Wechselrichter gearbeitet.

In Vorbereitung werden die beiden anzugebenden Readings ''<pvIn>'' und ''<pvOut>'' zum Beispiel als userReadings erstellt, wobei '<pvIn>'' und ''<pvOut>'' natürlich durch Readingnamen ersetzt werden müssen. Diese beiden Readings werden wie folgt berechnet / erstellt:

<pre>
<pvOut> = Inverter_Common_PAC_Value - PowerFlow_Site_P_Akku
<pvIn> = Inverter_Common_IDC_Value * Inverter_Common_UDC_Value + Inverter_Common_IDC_2_Value * Inverter_Common_UDC_2_Value
</pre>

Der '''PV-Wechselrichter''' wird mit dem Attribut setupInverterDev01 definiert, wobei die angelegten Readingnamen in den Schlüsseln ''pvIn'' bzw. ''pvOut'' verwendet werden:

<pre>
SymGen24 icon=inverter@#ff8c00:inverter@grey capacity=10000 strings=suedwest,nordost etotal=User_Produced_PV:kWh pvOut=<pvOut>:W pvIn=<pvIn>:W
</pre>

Dem PV-Wechselrichter sind die Strings ''suedwest'' und ''nordost'' zugewiesen.

Der zusätzliche '''Batterie-Wechselrichter''' wird mit dem Attribut setupInverterDev02 hinzugefügt:

<pre>
SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=-PowerFlow_Site_P_Akku:W dc2ac=PowerFlow_Site_P_Akku:W capacity=7680
</pre>

'''Bemerkungen:''' 
- strings=none sowie die Schlüssel ac2cd und dc2ac sind typisch für einen Batterie-WR bzw. kennzeichnen einen WR als Batterie-Wechselrichter 
- die an die Batterie abgegebene Leistung ist negativ

===== Einbindung eines Fronius Symo GEN24 10.0 Plus mit BYD Batterie ohne (virtuellen) Batterie-Wechselrichter =====
Diee Implementierung ist komplett auf der Seite [[Solaranlage Komplettbeispiel Fronius BYD]] beschrieben.

Zur Integration des ''Fronius Symo'' in FHEM wird das Modul ''fronius.pm'' verwendet und in dem definierten Device ''Fronius_Symo_Gen24'' diverse userReadings erzeugt. Diese Readings werden in den korrespondierenden Schlüsseln des Attributes ''setupInverterDev01'' angegeben:

<pre>
setupInverterDev01 Fronius_Symo_Gen24 etotal=User_Produced_PV_Energie:kWh pvOut=PowerFlow_Site_P_PV:W capacity=6000 strings=Dach_Ost,Dach_West
</pre>

Am Wechselrichter Fronius Symo Gen24 ist eine BYD Batterie angeschlossen. Das Device ''PV-Batterie'' wird per [[ModbusAttr]] angelegt und gemanaged. Die entsprechenden Readings werden im Attribut ''SetupBatteryDev01'' hinterlegt:

<pre>
PV_Batterie
cap=10240
charge=BatteryChargePercent
icon=@dyn:@dyn:@dyn:@dyn
intotal=Summe_Ladung:Wh
outtotal=Summe_Entladung:Wh
pin=BatteryChargeWatt:W
pout=BatteryDischargeWatt:W
pinmax=10000
show=2
</pre>

===== Einbindung eines SMA - Hybrid Sunny Tripower Smart Energy =====
[[Datei:Screenshot 2025-10-05 083530.png|right|thumb|400px|SMAInverter.pm]]

Der genannte Wechselrichter wird über das Modul SMAInverter.pm in FHEM integriert. Die nebenstehende Abbildung zeigt und benennt die einzelnen Readings des Moduls welche in den entsprechenden Schlüsseln der SolarForecast Attribute ''setupInverterDevXX'' und ''setupBatteryDevXX'' zugeordnet werden.

Die Readings des SMAInverter Moduls können vor der Verwendung über geeignete Methoden (userReadings) in Readings mit sprechenden Namen überführt werden um sie mit diesen Namen in die genannten Attributschlüssel einzufügen. In der vorliegenden Lösung befinden sich die Anwendungen SolarForecast und und die Inverter-Steuerung jeweils auf unterschiedlicher Hardware. Als Verbindungslayer wird MQTT genutzt, wobei dadurch bereits die dargestellten Readingnamen entstehen.

 
=== Einbindung und Visualisierung von Umweltdaten ===

Im Attribut '''setupEnvironment''' werden ''Schlüssel=Wert'' Paare definiert, die zur Erfassung von Umwelt- und Umfeldfaktoren dienen, die im Kontext des Moduleinsatzes und Prognosen wichtig oder hilfreich sind.

;gridStatus: Eine <Gerät>:<Reading>:<Regex> Kombination für den Verbindungsstatus zum öffentlichen Netz. Der angegebene reguläre Ausdruck muß Boolean 'true' für den Status 'Netz verfügbar/verbunden' ergeben, sonst 'false'.

;outsideTemp: Eine <Gerät>:<Reading> Kombination, die die aktuell gemessene Außentemperatur in °C liefert.

;presence: Eine <Gerät>:<Reading>:<Regex> Kombination, die den Anwesenheitsstatus der Bewohner liefert. Der angegebene reguläre Ausdruck muß Boolean 'true' für den Status 'Anwesenheit' ergeben, sonst 'false'.

;windSpeed: Eine <Gerät>:<Reading> Kombination, die die aktuell gemessene Windgeschwindigkeit in m/s liefert.

Mit dem Attribut und Schlüssel '''graphicControl->headerShowEnv''' können diese Daten im Grafikkopf visualisiert werden. Bestimmte Ummweltdaten sind die Prognosefunktionen relevant und werden bei Bedarf aufbereitet und gespeichert. Siehe dazu auch den Abschnitt [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Integration_von_Umwelt-_und_Kontextfaktoren_in_die_Prognose|"Integration von Umwelt- und Kontextfaktoren in die Prognose"]]

'''Erkennung Netzausfall (öffentliches Netz)'''

Mit der Einbindung einer geeigneten <Device>:<Reading> Kombination im Schlüssel ''gridStatus'' erfasst SolarForecast die Verbindung zum öffentlichen Stromnetz. Der Verbindungsstatus des Netzes kann im Grafikkopf mit '''graphicControl->headerShowEnv=gridStatus''' neben weiteren Informationen visualisiert werden. Die Erfassung des aktuellen Netzverbindungsstatus ist eine reine Information für den Anwender.

 

== Der integrierte SolarForecast Grafikbereich ==
Das SolarForecast Modul beinhaltet eine Grafikdarstellung die sich in mehrere Bereiche gliedert. Diese Bereiche können über Attribute ein- bzw. ausgeblendet sowie die Inhalte festgelegt werden.

[[Datei:Screenshot 2024-09-21 223545.png|right|thumb|400px|Bereiche der integrierten Grafik]]

Der nebenstehende Screenshot gibt die Gliederung der Grafikbereiche wieder:

1 - der Kopfbereich (Graphic Header)
2 - durch den Nutzer selbst definierbarer Inhalt (Graphic Header Own Specification) als Teil des Kopfbereiches
3 - Bereich Verbraucherdarstellung (Consumer Legend)
4 - Bereich Balkengrafik (Beam Graphic)
5 - Energieflußgrafik (Flow Graphic)

Jeder dieser Bereiche hat spezifische Steuerungsattribute zur Anpassung des Verhaltens und ggf. des Inhalts.

=== 1 - Der Grafik Kopfbereich ===
Im Kopfbereich befinden sich fest verankerte Informationen zur verwendeten Vorhersage-API sowie deren Status, Informationen zum Sonnenaufgang und Sonnenuntergang, dem aktuellen Gesamtstatus des SolarForecast Devices, Abweichungskennzahlen der PV Vorhersage sowie weitere Kennzeichen zur Verfügung.
Über zwei Drucktasten kann eine Anlagenprüfung durchgeführt und in den Spportthread des Moduls im FHEM Forum abgesprungen werden.

Mit dem Attribut '''graphicHeaderShow''' kann der gesamte Kopfbereich 1 und 2 (nutzereigener Teilbereich) ausgeblendet werden. Wird der Kopbereich ausgeblendet, ist es hilfreich mit dem Attribut '''plantControl->showLink''' einen Link zur Detailgrafik einzufügen da der in der Kopfgrafik integrierte Link in diesem Fall nicht mehr zur Verfügung steht.

Das Attribut '''graphicHeaderDetail''' definiert welche Bereiche des Grafikkopfes angezeigt werden sollen. Es kann die Anzeige des Energieverbrauches, der PV-Erzeugung und der vom Nutzer selbst definierte Inhalt miteinander frei kombiniert werden.

=== 2 - Der Bereich mit selbst definierbarem Inhalt (Graphic Header Own Specification) ===
In diesem Bereich kann der User beliebige Readings, Set-Kommandos und Attribute des SolarForecast Devices oder anderer Devices, die sich im gleichen FHEM-System wie das SolarForecast Device befinden, anzeigen lassen.

Dieser Bereich ist als Tabelle mit einer beliebigen Anzahl von Zeilen organisiert. Jede Zeile beinhaltet ein Kommentarfeld und vier Nutzfelder zur Darstellung ausgewähler Werte + Label. Der Bereich bzw. der Inhalt des Bereiches wird mit dem Attribut '''graphicHeaderOwnspec''' definiert.

Das nachfolgende Beispiel zeigt ein real gesetztes graphicHeaderOwnspec Attribut. Die Leerzeilen sind nicht notwendig, erhöhen aber die Lesbarkeit der Struktur.

<pre>
#
Autarkierate:Current_AutarkyRate
PV übermorgen:special_dayAfterTomorrowPVforecast
Verbrauch bis Sunset:special_todayConForecastTillSunset
Verbrauch bis nächsten Sunrise:special_conForecastTillNextSunrise

#Batterie
BatteryLive Status:userFn_BatLive_State
SoC Limit:Settings_CGwacs_BatteryLife_MinimumSocLimit_value@MQTT2_cerboGX_c0619ab34e08_settings
SoC Ist:SOC_value@MQTT2_cerboGX_c0619ab34e08_battery
SOC Optimum:Battery_OptimumTargetSoC

#
aktuelle Ladung:userFn_Bat_EnergyState
Verfügbar:userFn_BatLive_UsableEnergy
benötigte Ladeenergie:userFn_Bat_EnergyRemain
Ladefreigabe:Battery_ChargeRecommended

#
akt. DC Strom:DC_Current_value@MQTT2_cerboGX_c0619ab34e08_battery
Restladezeit Ziel:userFn_Bat_HoursUntilChargeFinish
MPII Ladestrom Limit Soll:userFn_Bat_MaxChargeCurrent_set
:

#Settings
Batterie Lademanagement:userFn_BatteryChargeManagement
SoC Management:userFn_BatterySoCManagement
MPII Ladestrom Limit Ist:MaxChargeCurrent@MQTT2_cerboGX_c0619ab34e08_vebus
SmartSolar Einspeisung:OvervoltageFeedIn@MQTT2_cerboGX_c0619ab34e08_settings

MPII Limit Einspeisung (W):MaxFeedInPower@MQTT2_cerboGX_c0619ab34e08_settings
SOC Limit Soll:MinimumSocLimit@MQTT2_cerboGX_c0619ab34e08_settings
Verbr. Neuplanung:consumerNewPlanning
Wetteranzeige:graphicShowWeather

Anzeige Nachtstunden:graphicShowNight
hist. Stunden:graphicHistoryHour
Autokorrektur:pvCorrectionFactor_Auto
Victron BatteryLife (1=an,10=aus):BatteryLife@MQTT2_cerboGX_c0619ab34e08_settings

Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
Debug:ctrlDebu
</pre>

Das Kommentarfeld am Beginn einer Zeile wird durch ein '''#''' gekennzeichnet. Folgt dem # ein String, wird dieser String als Kommentarangabe gewertet und in der Grafik ausgegeben. Ein leeres Kommentarfeld wird lediglich durch ein # gefolgt von einem Leerzeichen oder NL beschrieben:

#:<Text> (bzw nur # für einen 'leeren' Titel)

Ein Netzfeld bzw. ein Datensatz wird durch die Angabe von einem Label und dem darzustellenden Wert getrennt durch ':' definiert:

<Label>:<Reading, Attribut oder Set-Kommando>

Das System erkennt selbständig, ob es sich bei der Angabe um ein Reading, Attribut oder ein Set-Kommando handelt. Sollen Readings, Set-Kommandos und Attribute anderer Devices als dem SolarForecast-Device angezeigt werden, kann dies einfach durch Zusatz von

....@<Device-Name>

an den Parameter erreicht werden.

[[Datei:Screenshot 2024-12-05 203916.png|right|thumb|400px|Darstellung eigener Grafikbereich]]
Die Eingabe kann mehrzeilig erfolgen. Werte mit den Einheiten "Wh" bzw. "kWh" werden entsprechend der Einstellung des Attributs '''graphicEnergyUnit''' umgerechnet. Im Label sind Leerzeichen durch "&nbsp;" einzufügen, ein Zeilenumbruch durch " ". Ein leeres Feld in einer Zeile wird durch ":" ohne eine weitere Angabe erzeugt.

Die nebenstehende Abbildung zeigt die reale Darstellung der oben angegebenen Struktur im Attribut graphicHeaderOwnspec.

==== Formatierung der Inhalte im Bereich "Graphic Header Own Specification" ====

Die angezeigten Inhalte, wie z.B. Readingwerte, des User eigenen Bereiches (Attribut graphicHeaderOwnspec) können durch Spezifikationen im Attribut '''graphicHeaderOwnspecValForm''' manipuliert werden.

Die Online-Hilfe zum Attribut graphicHeaderOwnspecValForm erläutert die verfügbaren Möglichkeiten und Optionen.
Als Beispiel hier einige mögliche Notationen:

<pre>
{
'userFn_Bat_HoursUntilChargeFinish' => "($VALUE).' Stunden'",
'MQTT2_cerboGX_c0619ab34e08_battery.SOC_value' => "%.1f %%",
'Settings_CGwacs_BatteryLife_MinimumSocLimit_value' => "%.1f %%",
'Info_MaxChargeCurrent_value' => "($VALUE).' A'",
'DC_Current_value' => "%.0f A",
'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common.Regulated' => "($VALUE eq '1' ? 'Ja' : 'Nein')"
}
</pre>

Eine Besonderheit besteht bei darzustellenden Werten die die Einheiten 'Wh' bzw. 'kWh' besitzen. Diese Werte und Einheiten werden automatisch entsprechend des gesetzten Attributes graphicEnergyUnit umgerechnet und angezeigt.

Soll in diesen Fällen eine automatische Formatierung umgangen werden, kann eine solche Notation verwendet werden:

<pre>
{
'Today_PVforecast' => "(sprintf '%.1f &nbsp;kWh', ($VALUE / 1000))",
}
</pre>

Die Angabe von &nbsp; vor 'kWh' verhindert die Erkennung der Einheit und so auch die automatische Umsetzung durch das Modul.

=== 3 - Bereich Verbraucherdarstellung (Consumer Legend) ===
Dieser Grafikbereich zeigt die im Modul registrierten Verbraucher sowie deren Status und weitere Informationen an. Sind die Voraussetzungen gegeben, d.h. entsprechende Schlüssel in der ConsumerXX-Attributen gesetzt, können die Verbraucher über das Paneel manuell geschaltet werden.

Zur Anpassung der Darstellung sind verschiedene Attribute verfügbar:

;consumerControl->showLegend: Definiert die Lage bzw. Darstellungsweise der Verbraucherlegende sofern Verbraucher im SolarForecast Device registriert sind.
;consumerControl->adviceIcon: Definiert die Art der Information über die geplanten Schaltzeiten eines Verbrauchers in der Verbraucherlegende.
;consumerControl->detailLink: Wenn gesetzt, ist der jeweilige Verbraucher klickbar um direkt zur Detailansicht des jeweiligen Geräts auf einer neuen Browserseite zu gelangen.

Im Standard wird das Verbraucherpaneel zwischen dem Kopfbereich und der ersten Balkengrafik Ebene dargestellt. Mit dem Attribut '''consumerControl->showLegend''' und Argument '''icon_bottom''' oder '''text_bottom''' kann das Verbraucherpaneel an das Ende des Grafikbereiches verschoben werden.
Die Verwendung von '''text_bottom''' oder '''text_top''' blendet die Icon-Spalte im Verbraucherpaneel aus.

<gallery>
File:Screenshot 2025-02-08 093239.png|Darstellung mit consumerControl showLegend=icon_top (default)
File:Screenshot 2025-02-08 093646.png|Darstellung mit consumerControl showLegend=icon_bottom
File:Screenshot 2025-02-08 152018.png|Darstellung mit consumerControl showLegend=text_top bzw. text_bottom
</gallery>

[[Datei:Screenshot 2025-02-08 213634.png|right|thumb|400px|]]
Ein Mouse-Over über das Uhrensymbol zeigt nähere Informationen zum Status, den Planungsdaten, Modus und weitere Daten des Verbrauchers. Der Schalter "Aus/Ein" visualisiert den Schaltzustand des Verbrauchers und können auch zum manuellen Schalten des Verbrauchers dienen. Voraussetzung ist, dass im consumer-Attribut die Schlüssel "on" und "off" mit den Set-Kommandos zum Schalten des Verbrauchers defininiert sind.

[[Datei:Screenshot 2025-02-08 222210.png|right|thumb|300px|]]
Der Auto-Schieberegler zeigt einerseits den Freigabestatus zum Schalten des Verbrauchers durch das SolarForecast Modul und kann andererseits manuell betätigt werden. Der Status des Reglers korrespondiert mit dem im zugehörigen Consumer Attribut vorhandenen Schlüssel '''auto''' angegebenen Reading-Wert.

Die Verbraucherbezeichnungen in dem Paneel können in der Standardkonfiguration angeklickt werden um direkt zur Detailansicht des Devices zu gelangen. Mit dem Attribut '''consumerControl->detailLink''' kann der Link zur Detailansicht deaktiviert werden.

Das Uhrensymbol kann mit dem Attribut '''consumerControl->adviceIcon''' geändert und/oder dessen Farbe angepasst, sowie einen Informationstext statt eines Icons angezeigt werden.

=== 4 - Bereich Balkengrafik (Beam Graphic) ===

Die Balkengrafik des Moduls ist ein wesentliches Visualisierungshilfsmittel. Im Auslieferungszustand existiert eine Balkengrafikebene, die '''Ebene 1'''.
Jede Ebene kann zwei Balkendiagramme mit auswählbaren Inhalten, Farben und einstellbarem LayoutTyp darstellen. In Ebene 1 kann die Wettervorhersage eingebettet oder, bei Vorhandensein von Batteriegeräten, die zukünftigen Zeiten mit empfohlener Ladefreigabe und SoC-Prognose eingeblendet werden.

Welche Daten in welchen Zeiträumen dargestellt werden sollen, die Bestimmung des Layouts, die Gestaltung der Balken und einiges mehr wird durch Attribute gesteuert. Ein Teil dieser Einstellungen wird über das zusammengesetzete Attribut '''graphicControl->'Schlüssel'='Wert'''' eingestellt:

::*'''grundsätzliche Layout Definitionen'''
[[Datei:Screenshot 2025-01-12 204342.png|right|thumb|400px|Standardanzeige mit Wetter-Icons, gesetzen Attributen graphicBeam1Color=D4C177, graphicHistoryHour=11]]

;graphicControl->beamHeightlevel:Faktor zur Berechnung der Höhenverhältnisse der jeweiligen Ebene (siehe auch diesen [[#Wirkung_von_graphicControl->beamHeightlevel_auf_die_Zonen_(z1_bis_z3)_je_nach_layoutType|Abschnitt]]).
;graphicControl->beamPaddingTop:Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten Text- oder Iconreihe dieser Ebene eingefügt wird.
;graphicControl->beamPaddingBottom:Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene und dem unteren Rand dieser Ebene eingefügt wird.
;graphicControl->layoutType:Layout-Optionen zur grundlegenden Gestaltung der Balkengrafik
;graphicControl->hourStyle:Format der Zeitangabe in der Balkengrafik
;graphicControl->hourCount:Anzahl der darzustellenden Balken/Stunden in der Balkengrafk
[[Datei:Screenshot Screenshot 2025-05-21 153613.png|right|thumb|400px|Erweiterung des oberen und unteren Abstandes mit den Attributen graphicControl->beamPaddingTop und graphicControl->beamPaddingBottom]]
;graphicControl->energyUnit:definiert die Einheit zur Anzeige der elektrischen Leistung in der Grafik
;graphicHistoryHour:Anzahl der vorangegangenen Stunden die in der Balkengrafik dargestellt werden
;graphicControl->beamWidth:Vorgabe Breite der Balken der Balkengrafik in px (sonst automatische Bestimmung)

::*'''Definition der Inhalte und Balkeneigenschaften'''

[[Datei:Screenshot 2025-01-12 204756.png|right|thumb|400px|Wie oben aber mit gesetzem Attribut graphicShowNight=1]]
;graphicBeam1Color:Farbauswahl des primären Balkens (Ebene 1)
;graphicBeam2Color:Farbauswahl des sekundären Balkens (Ebene 1)
;graphicBeam1Content:Legt den darzustellenden Inhalt des primären Balken fest (Ebene 1)
;graphicBeam2Content:Legt den darzustellenden Inhalt des sekundären Balken fest (Ebene 1)
;graphicBeam1FontColor:Auswahl der Schriftfarbe des primären Balkens (Ebene 1)
;graphicBeam2FontColor:Auswahl der Schriftfarbe des sekundären Balkens (Ebene 1)
[[Datei:Screenshot 2025-01-12 205024.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=0 (ohne Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

::*'''zusätzliche Optionen'''

;graphicShowNight:Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik
;graphicShowWeather:Wettericons in der Balkengrafik anzeigen/verbergen (nur Ebene 1)
;graphicWeatherColor:Farbe der Wetter-Icons für die Tagesstunden
;graphicWeatherColorNight:Farbe der Wetter-Icons für die Nachtstunden
;graphicShowDiff:Zusätzliche Anzeige der Differenz "<primärer Balkeninhalt> - <sekundärer Balkeninhalt>" im Kopf- oder Fußbereich der Balkengrafik

Die genaue Beschreibung und deren Optionen sind der aktuellen Online-Hilfe zu entnehmen.

'''Für alle Ebenen gilt:''' Ein Attribut mit einer ungeraden Balkennummer (z.B. graphicBeam1Content) bezieht sich immer auf den primären Balken, ein Attribut mit einer geraden Balkennummer (z.B. graphicBeam2Content) bezieht sich immer auf den sekundären Balken.

Die Balken haben, wie die meisten Elemente in der Balkengrafik, eine Mouse-Over Eigenschaft welche relevante Informationen zu den dargestellten Werten anzeigt.

Sind die Nachtunden mit '''graphicShowNight''' ausgeblendet, werden keine Balken angezeigt sofern es keine Werte anzuzeigen gibt. Sollten dennoch Werte ungleich 0 anzuzeigen sein, werden diese Werte auch trotz ausgeblendeter Nachstunden angezeigt.

==== Aktivierung der Balkengrafik Ebene 2 ====
[[Datei:Screenshot 2025-01-12 211741.png|right|thumb|400px|Balkengrafik mit aktivierter Ebene 2, gesetzem Attribut graphicShowNight=01 (mit Zeitsynchronisation zwischen Ebene 1 und Ebene 2)]]

Um die '''Ebene 2''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam3Content''' und/oder '''graphicBeam4Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 4 für Balken 4) vorhanden ist.

'''Hinweis:''' Die Wetter-Icons können nur in Ebene 1 integriert werden.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 2 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 2 gibt, eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgende Ebene.

==== Aktivierung der Balkengrafik Ebene 3 ====

Um die '''Ebene 3''' der Balkengrafik zu aktivieren, setzt man das Attribut '''graphicBeam5Content''' und/oder '''graphicBeam6Content''' mit den gewünschten darzustellenden Inhalten. Die weiteren Darstellungsoptionen, wie graphicBeamCColor, können ebenfalls für den jeweiligen Balken selektiv definiert werden wenn ein Attribut mit der entsprechenden Nummer (z.B. 5 für Balken 5) vorhanden ist.

Werden in der Balkengrafik die Nachtstunden ausgeblendet ('''graphicShowNight=0''' bzw. default), findet zwischen der Ebene 1 und der Ebene 3 keine Synchronisation der Zeitebene statt. Falls es einen inhaltlichen Zusammenhang zwischen den Werten der Ebene 1 und Ebene 3 gibt, ist eine Zeitsynchronisation zwischen den Ebenen wünschenswert und sinnvoll. Durch Setzen des Attrbut '''graphicShowNight=01''' kann diese Synchronisation eingeschaltet werden.

Dabei ist die Ebene 1 die führende Ebene, d.h. diese Ebene vererbt die exkludierten bzw. eventuell inkludierten Nachtstunden (wenn Werte in den Balken der Ebene 1 angezeigt werden sollen) an die nachfolgenden Ebenen, d.h. auch auf die Ebene 3.

==== Wirkung von graphicControl->beamHeightlevel auf die Zonen (z1 bis z3) je nach layoutType ====

🎯 '''Grundprinzip''' 

Jede der verfügbaren Ebenen ist in Zonen aufgeteilt. Die Wirkung und der Einsatz der Zonen ist vom verwendeten ''graphicControl->layoutType'' abhängig. 
''graphicControl->beamHeightlevel'' ist ein '''Skalierungsfaktor''', der verwendet wird um für jede Zone die '''resultierende Zonenhöhe (px)''' zu berechnen:

<pre>
𝑝𝑥 = 𝑔𝑟𝑜𝑢𝑛𝑑 + (𝑣𝑎𝑙 / 𝑚𝑎𝑥𝑉𝑎𝑙) ⋅ (𝑏𝑒𝑎𝑚𝐻𝑒𝑖𝑔ℎ𝑡𝑙𝑒𝑣𝑒𝑙 − 𝑔𝑟𝑜𝑢𝑛𝑑)
</pre>

Das bedeutet:
* beamHeightlevel bestimmt die '''maximale mögliche Höhe''', die ein Balken erreichen kann,
* aber die tatsächliche Höhe hängt '''immer''' vom Verhältnis val / maxVal und vom scaleMode ab.

🧩 '''Zonenmodell (z1–z3)''' 

Unabhängig vom layoutType besteht jede Balkenebene (z.Zt. Ebene 1 bis 3) aus Zonen, die übereinander angeordnet sind:

{| class="wikitable"
! Zone !! Bedeutung !! Sichtbare Wirkung
|-
| '''z1''' || Freiraum über dem Balken (Abstand, Zahlen, Icons) || Abstand nach oben
|-
| '''z2''' || Balken mit dem höchsten positiven Wert oder oberer Teil eines Stapels || sichtbarer höherer (primärer) Balken
|-
| '''z3''' || Balken mit dem niedrigeren positiven Wert double/staple oder negativer Bereich (diff) || kleinerer (sekundärer) Balken oder negativer Balken
|}

Die Summe aus z1 + z2 + z3 ergibt die '''Gesamthöhe''', die durch ''beamHeightlevel'' '''skaliert''', aber nicht fest vorgegeben wird.

🧩 '''Wirkung pro layoutType''' 

[[Datei:Zonenskizze.png|right|thumb|400px|Zonenskizze]]
🟦 '''layoutType = single'''

Zonen:
* z1 = Freiraum
* z2 = Balken (beam1)
* z3 = nicht genutzt

Wirkung von ''beamHeightlevel'':
* skaliert die Gesamthöhe von z1 + z2
* z2 wächst proportional zu ''val / maxVal''
* z1 ist der verbleibende Rest
* kleine Werte können bei linearer Skalierung sehr klein werden
* ''scaleMode=log'' macht kleine Werte sichtbar größer

🟩 '''layoutType = double''' 

Zonen:
* z1 = Freiraum
* z2 = größerer Wert (beam1 oder beam2)
* z3 = kleinerer Wert oder Stapelanteil

Wirkung von ''beamHeightlevel'':
* skaliert die Gesamthöhe des Balkenpaares
* z2 und z3 teilen sich die Höhe proportional
* bei großen Wertunterschieden wird z3 sehr dünn
* bei ''scaleMode=staple'' werden beide Werte übereinander gestapelt
* bei ''scaleMode=log'' werden Unterschiede geglättet

🟥 '''layoutType = diff''' 

Zonen:
* z1 = positiver Freiraum
* z2 = positiver Balken (falls diff > 0)
* z3 = negativer Balken (falls diff < 0) Hinweis: technisch existiert auch z4 als Freiraum unterhalb, aber visuell Teil von z3

Wirkung von ''beamHeightlevel'':
* skaliert die Gesamthöhe der diff‑Darstellung
* die Null-Linie wird '''dynamisch verschoben''', abhängig von maxDif/minDif
* dadurch ändern sich die relativen Höhen von z1/z2/z3
* große Ausreißer verschieben die Null-Linie stark
* kleine Werte können optisch verschwinden
* ''scaleMode=log'' kann die Darstellung stabilisieren

⚙️ '''Einfluss des scaleMode''' 

{| class="wikitable"
! scaleMode !! Wirkung auf die Zonen
|-
| '''lin''' || z2/z3 werden proportional zu den Rohwerten skaliert → große Unterschiede sichtbar
|-
| '''log''' || z2/z3 werden logarithmisch gedämpft → kleine Werte werden sichtbarer
|-
| '''staple''' || nur für layoutType=double: z2 und z3 werden übereinander gestapelt
|}

''beamHeightlevel'' wirkt in allen Modi als '''Multiplikator''', der die resultierenden Höhen streckt oder staucht.

 

=== 5 - Die Energieflußgrafik (Flow Graphic) ===
[[Datei:Screenshot 2025-02-13 213424.png|right|thumb|400px|Energieflußgrafik mit Verbrauchern in der Nachtdarstellung (Mondphasen) nach Sonnenuntergang]]

Die Energieflußgrafik stellt die registrierten Erzeuger, Batterien, Netzzugänge und Verbraucher strukturiert in mehreren Ebenen dar:

;Ebene 1: In der oberen Ebene befinden sich die PV-Generatoren, Smart-Loader sowie sonstigen Erzeuger
;Ebene 2: Die mittlere Ebene organisiert den Zugang zum öffentlichen Netz, dem Hausknoten, dem Batterieknoten sowie einem Dummy-Verbraucher (Lampensymbol) für den Energieverbrauch des Hauses der keinem der registrierten Verbraucher zugeordnet werden kann.
;Ebene 3: In der unteren Ebene werden die registrierten Verbraucher dargestellt. Unterhalb der Verbrauchersymbole werden der aktuelle Verbrauch (bzw. der On/Off-Zustand) sowie darunter die Restlaufzeit (Minuten) des Verbrauchers, sofern er durch das Modul geplant und gestartet wurde.

Die Position und Gestaltung der Grafikelemente ist umfangreich über das Attribut '''flowGraphicControl''' und den darin verfügbaren Schlüsseln einstellbar.
Die Bedeutung der Schlüssel ist in der Online-Hilfe zum Attribut mit einem Beispiel beschrieben.

Darüber hinaus enthalten die Setup-Attribute '''setupInverterDevXX''', '''setupOtherProducerXX''' und '''consumerXX''' weitere Einstellungsmöglichkeiten um deren Icons und Färbungen in der Flußgrafik individuell einstellen zu können. So sind zum Beispiel die Icons der PV-Inverter und deren Färbung mit dem Schlüssel '''icon''' der setupInverterDevXX-Attribute in Abhängigkeit von Tag und Nacht separat definierbar.

In den Verbraucher-Attributen ist mit dem Schlüssel '''noshow''' die Sichtbarkeit in der Flußgrafik definierbar.

Generell steuert das Attribut '''graphicSelect''' die Ein- bzw. Ausblendung der gesamten Flußgrafik.

== Bestimmung von Sonnenaufgang und Sonnenuntergang ==

Im Modul werden die Zeiten für den Sonnenaufgang und Sonnenuntergang aus alternativen Quellen verwendet. Es gelten dabei die folgenden Prioritäten.

* sind die lokalen Koordinaten ''latitude, longitude, altitude'' im ''global'' Device gesetzt, erfolgt die Berechnung dieser Daten mit dem Parameter '''HORIZON=-0.833''' (vgl. CommandRef zu [https://fhem.de/commandref_DE.html#SUNRISE_EL SUNRISE_EL]).

* sollten die lokalen Koordinaten nicht gesetzt sein, werden die Angaben aus dem in Attribut ''setupWeatherDev1'' angegebenen Wetter-Device entnommen.

Der Wert ''−0.833°'' entspricht dem international üblichen Standard für die Berechnung von Sonnenauf‑ und untergangszeiten. Er berücksichtigt sowohl die atmosphärische Refraktion als auch den halben Sonnendurchmesser und beschreibt damit den Moment, in dem der obere Sonnenrand scheinbar den Horizont berührt. Viele astronomische Algorithmen und [https://metacpan.org/release/JFORGET/DateTime-Event-Sunrise-0.0505/view/lib/DateTime/Event/Sunrise.pm Bibliotheken] verwenden diesen Wert als Default, weshalb er auch in SolarForecast eingesetzt wird.

 

== Die Verbrauchsprognose ==
Im Gegensatz zu der PV Prognose gibt es keine API oder andere externen Datenquellen die für die Verbrauchsprognose herangezogen werden könnten.

Zum Zweck der Verbrauchsermittlung verwendet das Modul die Meterdaten aus dem Attribut ''setupMeterDev'' sowie den weiteren setup-Attributen ''setupInverterDevXX''.
Sind auch andere Erzeuger (BHKW, Windanlagen, etc.) bzw. eine Batterie vorhanden, sind ebenfalls die Attribute ''setupOtherProducerXX'' bzw. ''setupBatteryDev'' für die Berechnung des Hausverbrauchs relevant. In diesen Attributen gibt es die Schlüssel ''*total'' die teilweise optional sind. Für die Verbrauchsprognose bilden sie jedoch die Berechnungsgrundlage und sind deswegen für diese Funktionalität wichtig anzugeben.

Die Verbrauchswerte werden stundengenau erfasst und im Datenspeicher ''pvHistory'' für 31 Tage, sowie im Datenspeicher ''pvCircular'' 210 Tage gespeichert. Die beiden Datenspeicher übernehmen unterschiedliche Aufgaben im Rahmen der Prognoseerstellung. Auf Grundlage der gespeicherten und somit historischen Verbrauchswerte erstellt das Modul eine Prognose für die kommende Zeit.

Mit dem Kommando

"get ... pvHistory [Tag]"

wird der Inhalt aufgelistet. Die Schlüssel ''confc'', ''con'' und ''gcon'' zeigen die Verbrauchsprognose, den Verbrauch und den Netzbezug der jeweiligen Stunde des gewählten Tages.
Die Stunde "99" zeigt die Summen dieser Schlüsssel für den Tag:

99 => etotal: , pvfc: 782, pvrl: 0, rad1h: -
confc: 14540, con: 13873, gcon: 13873, gfeedin: 0
batintotal: , batin: 0, batouttotal: , batout: 0
batmaxsoc: -, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: So
cyclescsm01: 0
cyclescsm02: 0
cyclescsm03: 0
cyclescsm04: 1, hourscsme04: 0.00
cyclescsm05: 0
cyclescsm06: 0
cyclescsm07: 1, hourscsme07: 0.00
cyclescsm08: 1, hourscsme08: 0.00
cyclescsm09: 1, hourscsme09: 0.03

In dem Beispiel wurden für den Tag 14540 Wh Verbrauch prognostiziert, 13873 Wh tatsächlich verbraucht und davon 13873 Wh aus dem Netz bezogen. Leider war an diesem Tag keinerlei PV Ertrag vorhanden, was man auch an dem Schlüssel ''pvrl'' erkennen kann.

Den Inhalt des pvCircular-Speichers kann mit dem Befehl

"get ... pvCircular [Tag]"

angezeigt werden. Das nachfolgende Beispiel zeigt die Ausgabe für die Tagesstunde 23:

23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: -, batin03: -
batout01: 619, batout02: -, batout03: -
confc: 650, gcon: 23, gfeedin: 0, wcc: 40, rr1c: 0.00
temp: -6.00, wid: 100, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: -, pprl02: -, pprl03: -
...
con_all => Sa @ 617 762
Di @ 693 645
Mo @ 620 679
So @ 669 666 636
Mi @ 701 626
Do @ 612 642
Fr @ 615 606

Der Schüssel ''con_all'' enthält einen Hash aus Arrays die für jeden Wochentag (Mo..So) bis zu 30 Verbrauchswerte (in Wh) für die angezeigte Stunde speichern. Wie hier erkennbar ist, wurden an den drei vergangenen Sonntagen jweils 669 Wh, 666 Wh bzw. 636 Wh in der Stunde 23 (22:00-22:59) verbraucht.
Der Median aus diesen Werten geht in die Verbrauchsprognose ein.

'''Hinweis:''' Die Wochentagsnamen Mo..So sind von den installierten Locales auf Betriebsystemebene abhängig. Ist keine deutsche locale installiert, werden die englischen Wochentagsnamen Mon..Sun verwendet.

'''Ausblick (ab V 2.0.0, aktuell in Entwicklung):''' 
Die Verbrauchsprognose kann zukünftig auf '''herkömmliche Weise (Legacy)''' erstellt oder '''durch eine KI''' erstellt werden. Es ist auch eine prozentual einstellbare Kombination aus beiden Ergebnissen möglich. Weiter unten werden beide Varianten beschrieben. Bitte beachten, dass beide Technologien ihre spezifischen Attribute zur Einstellung haben.

Die KI-gestützte Prognose verwendet Langzeitdaten, die sich in einem speziellen Datenspeicher befinden und mit

get <Name> valDecTree aiRawData

eingesehen werden können. Wie lange diese Daten aufbewahrt werden, ist mit dem Attribut

attr <Name> aiControl->aiStorageDuration

einstellbar. Eine Pflege dieser Daten ist mit dem Befehl

set <Name> reset aiData ...

möglich.

 

=== Wie wird der Verbrauch des Hauses ermittelt und gespeichert? ===

Die Verbrauchsdaten des Hauses werden auf Stundenbasis ermittelt und gespeichert. Das "Haus" steht als Synonym aller im Kontext des Solarforecast Devices zusammengeführten Inverter (setupInverterDevXX), sonstigen Erzeuger (setupOtherProducerXX), Netzanschlüsse (setupMeterDev), Verbraucher (consumerXX) und Batterien (setupBatteryDev).

Alle diese Daten werden durch das Modul mit jedem ausgeführten Zyklus (Attribut plantControl->cycleInterval) und ebenfalls bei auftreten von Events eines als 'asynchron' definierten Devices gesammelt. Daraus wird permanent ein aktualisierter Verbrauch berechnet. Die Berechnung beschreibt folgende Formel:

PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0

bzw.

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
con = PV + PP - GridIn + GridCon - BatIn + BatOut

Die PV-Erzeugung beinhaltet die Summe aller durch die angegebnen Inverter (setupInverterDev01 .. setupInverterDevXX) erzeugten Energien. Die "sonstige Erzeugung" summiert sich aus den Werten aller angegebenen Producer (setupOtherProducer01 .. setupOtherProducerXX). Der Verbrauch wird durch die registrierten Geräte consumerXX teilweise direkt erfasst, ist aber grundsätzlich unvollständig da nicht alle Verbrauchswerte im "Haus" gemessen und durch das Modul erfasst werden können.

Das folgende Beispiel zeigt das Ergebnis bei 300 Wh PV-Erzeugung und gleichzeitige 500 Wh Netzbezug:

Verbrauch = 300 + 0 - 0 + 500 - 0 + 0 = 800 Wh

Bei 1300Wh PV-Erzeugung, 100 Wh Netzeinspeisung sowie 200 Wh Batterieladung ergibt sich der Verbrauch zu:

Verbrauch = 1300 + 0 - 100 + 0 - 200 + 0 = 1000 Wh

Ohne Erzeugung, aber mit der Energielieferung von 500 Wh aus der Batterie, 800 Wh Netzbezug (mit einem Anteil Batterienachladung aus dem Netz von 200 Wh) sieht die Verbrauchsrechnung wie folgt aus:

Verbrauch = 0 + 0 - 0 + 800 - 200 + 500 = 1100 Wh

Der so ermittelte Verbrauchsert wird mit jedem Zyklus in der pvHistory im Schlüssel "con" gespeichert. Man kann sich die gespeicherten Werte mit dem Befehl

get <name> pvHistory [<Tag>]

angezeigt werden. Nachfolgendes Beispiel zeigt einen Datensatz für die Stunde 8 eines Tages:

<pre>
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 62940734, etotali02: 2928860, etotali03: -
pvrl01: 0, pvrl02: 0, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 630, con: 962, gcons: 962, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: 0, sunaz: 120, sunalt: -3
batintotal: 3713815.07742543, batouttotal: 3604468.26993988, batin: 0, batout: 0
wid: 161, wcc: 89, rr1c: 0.00, pvcorrf: 0.27/0.00 temp: 7.40,
csmt01: 110996.12, csme01: 32.1399999999994, minutescsm01: 30
minutescsm02: 0
csmt03: 2513.67, csme03: 0, minutescsm03: 0
csmt04: 1581293.6, csme04: 136.5, minutescsm04: 60
csmt05: 1662.17, csme05: 0, minutescsm05: 0
csmt06: 90.53, csme06: 0, minutescsm06: 0
csmt07: 39.75, csme07: 0, minutescsm07: 0
csmt08: 38050, csme08: 0, minutescsm08: 0
csmt09: 131627, csme09: 33.2000000000116, minutescsm09: 39
minutescsm10: 0
</pre>

Im Schlüssel "con" ist der gespeicherte Verbrauch von 962 Wh ersichtlich.

Zur Laufzeit bekommt man mit dem Attribut ''ctrlDebug=collectData'' einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen:

<pre>
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
</pre>

 

=== Die Legacy-Verbrauchsprognose einstellen ===
==== Wie wird die Legacy-Verbrauchsprognose erstellt? ====

Aus den gespeicherten con-Werten (Verbrauchsdaten) der pvCircular (Schlüssel con_all) sowie Einträgen der pvHistory wird der Median der historischen Tage ermittelt und für den kommenden Tag bzw. die kommen Stunden zur Prognose angewendet. Dabei geht per default jeder verfügbare historische Tag gleichberechtigt in die Prognose ein. Mit dem Attribut '''plantControl->consForecastIdentWeekdays=1''' kann festgelegt werden, dass nur gleiche Wochentage (Mo..So) für die Prognose verwendet werden. Hierbei spielt die Vermutung, dass das Verbrauchsverhalten eine gewisse Korrelation zum Wochentag hat, eine Rolle.

Verwendet man die Einstellung consForecastIdentWeekdays=1, hat es sich als vorteilhaft erwiesen, das Attribut '''plantControl->consForecastLastDays''' auf einen niedrigeren Wert als den Default zu setzen. Eine Einstellung auf '8' zum Beispiel verwendet den Median der gleichen Wochentage der vergangenenen 8 Wochen. Dadurch wird nicht zu weit in die Vergangenheit verzweigt und so eine langsame Veränderung des Verbrauchsmedian, zum Beispiel hervorgerufen durch den Übergang vom Winter in das Frühjahr hinein, abgebildet.

Weiteren Einfluß auf die Verbrauchsprognose kann mit dem Schlüssel '''exconfc''' im Consumerattribut genommen werden. Insbesondere bei der unregelmäßigen Nutzung von Verbrauchern mit hoher Leistung kann die Projektion der aufgezeichneten historischen Werte in die Prognose zu unverhältnismäßig hohen Verbrauchswerwartunden führen.

Möglicherweise führt in Fällen die Verwendung eine der nachfolgenden Optionen zu einem besseren Ergebnis:

* '''1 -''' die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
* '''2 -''' wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.

Wird '''exconfc''' in einem der Consumer verwendet, sollte

* '''plantControl->consForecastIdentWeekdays=1'''
* '''plantControl->consForecastLastDays=4'''

eingestellt werden. Hintergrund ist, dass die Verbrauchsanteile der jeweiligen Verbraucher nur maximal 31 Tage in der pvHistory verfügbar sind. Für längere Zeiträume stehen nur Gesamtsummen des Verbrauchs in der pvCircular zu Verfügung.

Mit '''exconfc=1''' werden die in der Historie aufgezeichneten Verbrauchsbestandteile aus einer Prognose herausgerechnet. Konkret werden die in der pvHistory aufgezeichneten Verbrauchsbestandteile für die relevante Stunde ermittelt und daraus ein Durchschnitt gebildet der vom Prognosewert subtrahiert wird. Mit dem Attributwert plantControl->consForecastIdentWeekdays=1 werden wiederum nur identische Wochentage (Mo .. So) zusammengefasst.

Mit '''exconfc=2''' erfolgt ebenso die Eliminierung des Verbrauchsanteils, es wird jedoch auf die Planungsdaten für diesen Verbraucher zugegriffen und die geplanten Energieanteile wiederum der Verbrauchsprognose für die kommenden Stunden hinzugerechnet.

In beiden Anwendungsfällen ist es notwendig, dass dem Modul durch die Angabe entsprechender Readings der Energieverbrauch im Setup des Consumers bekannt gemacht wird damit diese Energieanteile registriert werden können. Allgemein funktioniert die Verbrauchsprognose gut wenn Verbrauchsprozesse regelmäßig in einem wiederkehrenden Zeitraster ablaufen, der Verbrauch durch persönliche Rituale bestimmt ist. So zum Beispiel könnte am Dienstag und Samstag gewöhnlich die Waschmaschine laufen, das E-Auto täglich aufgeladen werden und gebügelt wird oft am Sonntag Nachmittag.

Unregelmäßige Nutzung, vor allem vom Großverbrauchern, lässt sich nur sehr schwer und ungenügend auf zukünftige Verbrauchsprognosen projizieren.

Das Ergebnis der Prognose wird im Kopf der Grafik in der Zeile ''Verbrauch'' sowie in diversen Readings wie

* '''RestOfDayConsumptionForecast''' (Verbrauchsprognose für den Rest des Tages)
* '''NextHours_Sum04_ConsumptionForecast''' (Verbrauchsprognose für die nächsten 4 Stunden)
* '''Tomorrow_ConsumptionForecast''' (Verbrauchsprognose für den kommenden Tag)

angezeigt.

Weitere Aggregationen kann man sich über das Attribut '''ctrlStatisticReadings''' bei Bedarf zuschalten:

* '''conForecastTillNextSunrise''' - Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
* '''todayConForecastTillSunset''' - Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
* '''todayConsumptionForecast''' - Verbrauchsprognose aufgesplittet pro Stunde des aktuellen Tages (01-24)

 
==== Debugging der Legacy-Verbrauchsprognose ====

Um sich einen Einblick über die Erstellung der Verbrauchsprognose zu verschaffen, bietet sich die Einschaltung von:

attr <Name> ctrlDebug consumption_long

an. Mit diesem gesetzten Attribut wird die Erstellung der Prognose im Log protokolliert:

<pre>
2025.02.27 19:52:00.063 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.02.27 19:52:00.063 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.27 19:52:00.064 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 01 - 74.43 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 10 - 290.77 Wh
2025.02.27 19:52:00.065 1: SolCast DEBUG> consumer '03' register for exclude day 13, hod: 24 - 660.70 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '03' register for exclude day 20, hod: 07 - 459.93 Wh
2025.02.27 19:52:00.066 1: SolCast DEBUG> consumer '07' register for exclude day 20, hod: 02 - 0.33 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> consumer '03' register for exclude day 30, hod: 08 - 264.78 Wh
2025.02.27 19:52:00.067 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.27 19:52:00.067 1: SolCast DEBUG> excl. hist 74 Wh for Hour 01, Considered value numbers: 1
2025.02.27 19:52:00.067 1: SolCast DEBUG> estimated cons of Hour 01: 436 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> excl. hist 0 Wh for Hour 02, Considered value numbers: 1
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 02: 428 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 4
2025.02.27 19:52:00.068 1: SolCast DEBUG> estimated cons of Hour 04: 503 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 05: 489 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 06: 482 Wh, Considered value numbers: 4
2025.02.27 19:52:00.069 1: SolCast DEBUG> excl. hist 460 Wh for Hour 07, Considered value numbers: 1
2025.02.27 19:52:00.069 1: SolCast DEBUG> estimated cons of Hour 07: 274 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 265 Wh for Hour 08, Considered value numbers: 1
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 08: 441 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> estimated cons of Hour 09: 558 Wh, Considered value numbers: 4
2025.02.27 19:52:00.070 1: SolCast DEBUG> excl. hist 291 Wh for Hour 10, Considered value numbers: 1
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 10: 443 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 11: 881 Wh, Considered value numbers: 4
2025.02.27 19:52:00.071 1: SolCast DEBUG> estimated cons of Hour 12: 794 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 13: 840 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 14: 660 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 15: 812 Wh, Considered value numbers: 4
2025.02.27 19:52:00.072 1: SolCast DEBUG> estimated cons of Hour 16: 752 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 17: 597 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 18: 652 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 19: 634 Wh, Considered value numbers: 4
2025.02.27 19:52:00.073 1: SolCast DEBUG> estimated cons of Hour 20: 628 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 21: 713 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 22: 596 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> estimated cons of Hour 23: 629 Wh, Considered value numbers: 3
2025.02.27 19:52:00.074 1: SolCast DEBUG> excl. hist 661 Wh for Hour 24, Considered value numbers: 1
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 3
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.27 19:52:00.075 1: SolCast DEBUG> estimated cons Tomorrow: 16848 Wh, Individual hourly values considered: 72, exclude: 0 Wh (avg of 0 entities)
2025.02.27 19:52:00.075 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour00' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store circular/history hod '20' confc: 628
2025.02.27 19:52:00.076 1: SolCast DEBUG> store 'NextHour01' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '21' confc: 713
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour02' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store circular/history hod '22' confc: 596
2025.02.27 19:52:00.077 1: SolCast DEBUG> store 'NextHour03' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '23' confc: 629
2025.02.27 19:52:00.078 1: SolCast DEBUG> store 'NextHour04' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.078 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour05' hod '01' confc: 436, confcEx: 436
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour06' hod '02' confc: 428, confcEx: 428
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour07' hod '03' confc: 458, confcEx: 458
2025.02.27 19:52:00.079 1: SolCast DEBUG> store 'NextHour08' hod '04' confc: 503, confcEx: 503
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour09' hod '05' confc: 489, confcEx: 489
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour10' hod '06' confc: 482, confcEx: 482
2025.02.27 19:52:00.080 1: SolCast DEBUG> store 'NextHour11' hod '07' confc: 274, confcEx: 274
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour12' hod '08' confc: 441, confcEx: 441
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour13' hod '09' confc: 558, confcEx: 558
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour14' hod '10' confc: 443, confcEx: 443
2025.02.27 19:52:00.081 1: SolCast DEBUG> store 'NextHour15' hod '11' confc: 881, confcEx: 881
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour16' hod '12' confc: 794, confcEx: 794
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour17' hod '13' confc: 840, confcEx: 840
2025.02.27 19:52:00.082 1: SolCast DEBUG> store 'NextHour18' hod '14' confc: 660, confcEx: 660
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour19' hod '15' confc: 812, confcEx: 812
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour20' hod '16' confc: 752, confcEx: 752
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour21' hod '17' confc: 597, confcEx: 597
2025.02.27 19:52:00.083 1: SolCast DEBUG> store 'NextHour22' hod '18' confc: 652, confcEx: 652
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour23' hod '19' confc: 634, confcEx: 634
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour24' hod '20' confc: 628, confcEx: 628
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour25' hod '21' confc: 713, confcEx: 713
2025.02.27 19:52:00.084 1: SolCast DEBUG> store 'NextHour26' hod '22' confc: 596, confcEx: 596
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour27' hod '23' confc: 629, confcEx: 629
2025.02.27 19:52:00.085 1: SolCast DEBUG> store 'NextHour28' hod '24' confc: 660, confcEx: 660
2025.02.27 19:52:00.086 1: SolCast DEBUG> consumption calculated - day: 27, hod: 20, con: 574 Wh
2025.02.27 19:52:00.086 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 11210 Wh
</pre>

Die Ausgabe startet mit ''"Start Consumption forecast''", es werden die zu exkludierenden historischen Daten für jeden Consumer bzgl. jedem Tag (day) und Stunde des Tages (hod) getrennt registriert. Diese Werte werden durch die gespeicherte Einträge in der pvHistory (max. 31 historische Tage) geliefert.

Im nächsten Abschnitt ''"Consumption forecast for the next Hours (new median)"'' werden die Prognosen für die nächsten Stunden kalkuliert und die zuvor registrierten Excludes angewendet. Die Prognose für den kommenden Tag ist im Abschnitt ''"Consumption forecast for the next day (new median)"'' protokolliert. Die Prognose für den kommenden Tag ist nicht einfach die Summe der Prognose der nächsten Stunden, denn in den kommenden Stunden werden auch die verfügbaren Planungen der Consumer einbezogen. Für den kommenden Tag können diese Werte unter Umständen nicht einbezogen werden da sie zum Zeitpunkt X noch nicht verfügbar sind.

Im Abschnitt ''"Store Consumption forecast values (new median)"'' erscheinen die effektiv gespeicherten Werte. Diese sind die Grandlage für die grafische Darstellung sowie weiteren Kalkulationen.

 

==== Wie kann eine fehlerhafte Legacy-Verbrauchsprognose korrigiert werden? ====
Wie im vorherigen Abschnitt beschrieben, wird die Prognose aus den gespeicherten "con"-Werten der vergangenen Tage (bzw. Stunden) abgeleitet.
Grundsätzlich muß zunächst sichergestellt werden, dass die auszulesenden Readings der angegebenen Energiezähler sowie deren Einheiten! korrekt eingestellt sind. Das gilt ebenfalls für die registrierten Verbraucher im Modul.

Für einen ersten Überblick bietet sich das Debug Attribut an zu setzen:

attr <Name> ctrlDebug consumption_long

Beispielausgabe des Debug:

<pre>
2024.09.21 13:28:27.041 1: SolCast DEBUG> ################### Consumption forecast for the next day ###################
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >01< considering possible exclusions: 14082
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >08< considering possible exclusions: 16446
2024.09.21 13:28:27.042 1: SolCast DEBUG> History Consumption day >15< considering possible exclusions: 14568
2024.09.21 13:28:27.043 1: SolCast DEBUG> History Consumption day >25< considering possible exclusions: 15522
2024.09.21 13:28:27.043 1: SolCast DEBUG> estimated Consumption for tomorrow: 15154, days for avg: 4
2024.09.21 13:28:27.043 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 14 -> 850 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 14 -> 643 Wh
2024.09.21 13:28:27.044 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 14 -> 590 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 14 -> 522 Wh
2024.09.21 13:28:27.045 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 13:00:00, confc: 651, days for avg: 4, hist. consumption registered consumers: 560.97
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 15 -> 720 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 15 -> 743 Wh
2024.09.21 13:28:27.046 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 15 -> 897 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 15 -> 557 Wh
2024.09.21 13:28:27.047 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 14:00:00, confc: 729, days for avg: 4, hist. consumption registered consumers: 620.97
2024.09.21 13:28:27.047 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 16 -> 676 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 16 -> 790 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 16 -> 785 Wh
2024.09.21 13:28:27.048 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 16 -> 581 Wh
2024.09.21 13:28:27.049 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 15:00:00, confc: 708, days for avg: 4, hist. consumption registered consumers: 647.29
2024.09.21 13:28:27.049 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 17 -> 622 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 17 -> 639 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 17 -> 646 Wh
2024.09.21 13:28:27.050 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 17 -> 572 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 16:00:00, confc: 619, days for avg: 4, hist. consumption registered consumers: 618.30
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 18 -> 596 Wh
2024.09.21 13:28:27.051 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 18 -> 614 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 18 -> 580 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 18 -> 480 Wh
2024.09.21 13:28:27.052 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 17:00:00, confc: 567, days for avg: 4, hist. consumption registered consumers: 583.41
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 19 -> 615 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 19 -> 1659 Wh
2024.09.21 13:28:27.053 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 19 -> 597 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 19 -> 618 Wh
2024.09.21 13:28:27.054 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 18:00:00, confc: 872, days for avg: 4, hist. consumption registered consumers: 636.97
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 20 -> 611 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 20 -> 1124 Wh
2024.09.21 13:28:27.055 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 20 -> 546 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 20 -> 479 Wh
2024.09.21 13:28:27.056 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 19:00:00, confc: 690, days for avg: 4, hist. consumption registered consumers: 578.87
2024.09.21 13:28:27.056 1: SolCast DEBUG> historical Consumption added for Sa -> date: 07, hod: 21 -> 1474 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 14, hod: 21 -> 596 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 24, hod: 21 -> 619 Wh
2024.09.21 13:28:27.057 1: SolCast DEBUG> historical Consumption added for Sa -> date: 31, hod: 21 -> 433 Wh
2024.09.21 13:28:27.058 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96
...
</pre>

Im ersten Teil wird die erwartete Consumption für den nächsten Tag unter Berücksichtigung möglicher Ausschlüsse von Verbrauchern ausgegeben. Ausschlüsse von Verbrauchern ergeben sich wenn in dem Verbraucherattribut der Schlüssel '''exconfc''' gesetzt ist. Er besagt, dass die Verbrauchswerte des Verbrauchers in eine zukünftige Prognose nicht eingehen sollen. Zum Beispiel wenn ein Verbraucher mit sehr hohen Verbrauchswerten nur sporadisch eingesetzt wird und dadurch die Prognose stark verfälschen würde. Es ist auch zu sehen, dass bedingt durch das Attribut '''affectConsForecastIdentWeekdays = 1''' nur die historischen Tage 01, 08, 15 und 25 berücksichtigt werden.

Im zweiten Teil wird die berechnete Erwartung für die nächsten Stunden ausgegeben.
Zur Beschreibung der Fehlersuche gehen wir davon aus, dass die Prognose von 780 Wh am 2024-09-21 20:00:00 zu hoch erscheint weil am Tag "07" ein Wert von 1474 Wh gespeichert ist:

SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-09-21 20:00:00, confc: 780, days for avg: 4, hist. consumption registered consumers: 584.96

Im nächsten Schritt geben wir die historischen Werte für den Tag 07 aus:

get <Name> pvHistory 07

In dem Datensatz interessiert die Stunde 21. Sie resultiert aus der obigen Angabe "starttime: xxxx-xx-xx 20:00:00":

<pre>
21 => etotal: 64354660, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 496, con: 1474, gcons: 23, conprice: 0.2958
gfeedin: 5, feedprice: 0.1269
DoN: 0, sunaz: 289, sunalt: -8
batintotal: 3064096.92456668, batouttotal: 2958021.37946804, batin: 0, batout: 1460
wid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/-temp: 26.00,
csmt01: 64262.43, csme01: 28.8099999999977, minutescsm01: 25
minutescsm02: 0
csmt03: 0, csme03: 0, minutescsm03: 0
csmt04: 1389417.4, csme04: 94.5, minutescsm04: 60
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 290.15, csme06: 6.66999999999996, minutescsm06: 54
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 32800, csme08: 0, minutescsm08: 0
csmt09: 103987.8, csme09: 38, minutescsm09: 43
csmt10: 9151.24999999783, csme10: 3.99999999997999, minutescsm10: 60
</pre>

In dem Datensatz sind die Energieverbrauchsanteile der im Device registrierten Verbraucher mit dem Schlüssel "csmeXX" gespeichert. Dabei ist "XX" die Verbrauchernummer. In dem Beispiel existieren die Anteile csme01 und csme03 - csme10. Keiner dieser Verbraucher hat einen auffälligen Verbrauchswert gespeichert, d.h. die Messung der Verbraucher scheidet als Problemquelle aus. Wäre ein unverhältmismäßig hoher Verbrauch bei einem der Verbraucher feststellbar, müssten die Schlüssel '''pcurr''' und '''etotal''' im consumerXX-Attribut geprüft, sowie die Datenlieferung des Consumerdevices selbst geprüft werden.

Es wurde offensichtlich ein hoher Verbrauch von einem nicht registrierten Verbraucher verursacht oder durch die Übertragung eines Meßfehlers des Devices, angegeben im Attribut '''setupMeterDev''', in das SolarForecast Device übertragen. Eine weitere Analyse ist an dieser Stelle nicht möglich.

Zur Behebung des falschen Wertes kann ein Reset der gespeicherten Consumption der relevanten Stunde durchgeführt werden:

set <Name> reset consumptionShort 07 21

 

=== Die KI‑Verbrauchsprognose mit AI::FANN aktivieren und einstellen ===

FANN steht für '''Fast Artificial Neural Network'''.
Es handelt sich um eine sehr schnelle, leichtgewichtige Open‑Source‑Bibliothek zur Erstellung und zum Training künstlicher neuronaler Netze. Ein Manual dieser Library ist [https://fann.sourceforge.net/reference/index.html hier] verfügbar.

* FANN ist die '''technische Grundlage''' der KI‑Verbrauchsprognose.
* ws berechnet aus historischen Verbrauchsdaten ein Modell, das zukünftige Werte vorhersagen kann.
* es ist '''robust, schnell und ressourcenschonend''', ideal für Systeme, die regelmäßig neu trainiert werden müssen.
* FANN arbeitet mit klassischen Feed‑Forward‑Netzen und Backpropagation‑Training – also bewährten, stabilen Methoden.

'''AI::FANN''' ist ein Perl‑Modul, das als Schnittstelle (Binding) zwischen SolarForecast und der FANN‑Bibliothek dient.

* AI::FANN ist die Brücke, über die unser Prognosesystem mit FANN kommuniziert.
* es ermöglicht dem System:
::* Trainingsdaten an FANN zu übergeben
::* ein neuronales Netz zu erzeugen
::* das Training zu steuern
::* das fertige Modell zu speichern und später für Prognosen zu nutzen

==== Voraussetzungen ====

===== Installation der FANN‑Library (Linux) =====

<pre>
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install gcc
sudo apt-get install libfann-dev libfann2
</pre>

RPM‑basierte Systeme:

<pre>
sudo dnf install fann-devel
</pre>

RPM‑basierte Systeme sind Linux‑Distributionen, die das Paketformat RPM (Red Hat Package Manager) verwenden.

Typische RPM‑basierte Linux‑Distributionen:
* Red Hat Enterprise Linux (RHEL)
* CentOS / CentOS Stream
* Fedora
* openSUSE / SUSE Linux Enterprise
* Rocky Linux
* AlmaLinux
* Mageia

===== Installation der FANN‑Library (Windows) =====

* der Installations- bzw. Erstellungsprozess der dll ist [https://fann.sourceforge.net/reference/x26.html hier] beschrieben
* fann.dll in PATH oder FHEM‑Verzeichnis kopieren
* Perl‑Installation muss DLL laden können

 

===== Installation des Perl‑Moduls AI::FANN =====

<pre>
cpan install AI::FANN
</pre>

Auf Debian Linux Systemen kann das Modul auch mit

<pre>
sudo apt-get install libai-fann-perl
</pre>

installiert werden.

Alternativ kann natürlich auch cpanm oder der [https://wiki.fhem.de/wiki/Meta#Der_FHEM_Installer FHEM Installer] verwendet werden.

 

==== Bestandteile der Machine-Learning (ML)‑Pipeline ====

===== Datenaufbereitung =====

Die Datenaufbereitung ist der wichtigste Schritt jeder ML‑Pipeline, da sie die Qualität der Eingabedaten sicherstellt.
Schlechte oder unskalierte Daten führen fast immer zu schlechten Modellen.

* '''Normalisierung / Skalierung'''
:- ML‑Modelle benötigen Eingabewerte in vergleichbaren Größenordnungen.
:- Beispiel: PV‑Leistung (0–10 000 W) vs. Uhrzeit (0–23).
:- Ohne Normalisierung würden große Werte die kleinen dominieren.

* '''Feature‑Engineering'''
: Aus Rohdaten werden zusätzliche Merkmale erzeugt, die Muster besser sichtbar machen:
::- Lags: Verbrauch der letzten Minuten/Stunden
::- Deltas: Änderungen gegenüber vorherigen Zeitpunkten
::- Zeitmerkmale: Stunde, Wochentag, Feiertag
::- PV‑Prognosen: erwartete Erzeugung als Einflussfaktor
::- Saisonale Merkmale: Sommer/Winter, Temperatur
::- Semantik (Erstellung von Interaktionen)
::- Rolling‑Statistics

📊 ''Rolling‑Statistics'' 
„Rolling“ bedeutet, dass die Kennzahlen nicht einmalig über den gesamten Datensatz berechnet werden, sondern gleitend über ein Zeitfenster (z. B. 24 h, 7 Tage, 100 Samples). So werden Trends, Drift, Modellverschlechterung oder saisonale Muster besser erkannt.

* '''Integration zusätzlicher Verbraucher'''
: Wärmepumpen oder E‑Autos erzeugen starke, unregelmäßige Peaks.
: Diese können als zusätzliche Features einfließen.

'''Es wird umgesetzt:'''
* ✔ Normalisierung auf physikalische Grenzen (PV‑Maximalleistung, Hausverbrauchs‑Maxima)
* ✔ Feature‑Engineering wie Lags, Deltas, Rolling‑Statistics, Zeitmerkmale, PV/PV-Prognosen als Input und weitere Semantik
* ✔ Optionale Zusatzlasten (WP/EV)

===== Trainingsdaten‑Split =====

Der Split trennt Daten in Trainingsdaten (zum Lernen) und Validierungsdaten (zur Qualitätskontrolle).

* '''Training'''
: Das Modell lernt Muster aus historischen Daten.

* '''Validierung'''
: Das Modell wird auf Daten getestet, die es nicht gesehen hat.
: Dadurch erkennt man Overfitting.

* '''Shuffling'''
: Durchmischen der Daten, um Reihenfolgeeffekte zu vermeiden.
: Besonders wichtig bei Zeitreihen.

'''Es wird umgesetzt:'''
* ✔ Training/Validierung‑Split
* ✔ Shuffling je nach Einstellung von aiControl->aiConShuffleMode
* ✔ Shuffle‑Perioden während des Trainings

===== Netzarchitektur =====

Die Architektur bestimmt, wie das neuronale Netz aufgebaut ist.

* '''Inputs'''
: Anzahl der Merkmale (Features), die das Modell erhält.

* '''Hidden Layers'''
: Anzahl und Größe der verdeckten Schichten bestimmen, wie komplexe Muster erkannt werden können.

* '''Output Layer'''
: bei SolarForecast: 1 Wert = Verbrauchsprognose (Wh).

'''Es wird umgesetzt:'''
* ✔ Dynamische Input‑Anzahl je nach aktivierten Features
* ✔ Konfigurierbare Hidden Layers (z. B. 80‑40‑20)
* ✔ 1 Output‑Neuron
* ✔ Konfigurierbare Aktivierungsfunktionen

===== Training =====

Hier werden die Gewichte des Netzes angepasst, um Fehler zu minimieren.

* '''Trainingsalgorithmus'''
: RPROP: stabil, robust
: INCREMENTAL: schneller, aber empfindlicher

* '''Lernrate (Learning Rate)'''
: Wie stark Gewichte pro Schritt angepasst werden.

* '''Momentum'''
: Glättet die Lernbewegung, verhindert Zickzack‑Verhalten.

* '''Steepness'''
: Steuert die Empfindlichkeit der Aktivierungsfunktion.

* '''Shuffle‑Perioden'''
: Wie oft die Trainingsdaten neu gemischt werden.

* '''Early‑Stopping'''
: Training wird beendet, wenn Validierungsfehler nicht mehr sinkt.

'''Es wird umgesetzt:'''
* ✔ RPROP und INCREMENTAL
* ✔ Learning Rate, Momentum, Steepness konfigurierbar
* ✔ Shuffle‑Perioden
* ✔ Early‑Stopping über Validierungsfehler
* ✔ Mehrere Trainingsläufe (Runs) zur Modellselektion

===== Modellselektion und Fehlerevaluierung =====

Hier wird entschieden, welches Modell am Ende verwendet wird.
Die Ergebnisse des Trainings werden während des Traininglaufs fortlaufend überwacht und die Einhaltung von intern vorgegebenen Kennzahlen von einem Retrain-Guard überprüft.

'''Evaluation'''
* MAE, MAPE, RMSE, R²
* BitFail
* Bias/Slope
* P95/P99

📈 ''Fehlermaße: MAE, MAPE, RMSE, R²'' 
* '''MAE''' – Mean Absolute Error (durchschnittlicher absoluter Fehler)
::: MAE=1/𝑛∑∣𝑦−𝑦^∣
* '''MAPE''' – Mean Absolute Percentage Error (prozentualer Fehler)
::: MAPE=100/𝑛∑∣(𝑦−𝑦^)/𝑦∣
::* Achtung: '''problematisch bei kleinen oder Null‑Werten''' (klassisch bei Verbrauchsdaten nachts).
* '''RMSE''' – Root Mean Squared Error (Quadratischer Fehler, stärker empfindlich für Ausreißer)
::* gut, wenn große Fehler besonders kritisch sind
* '''R²''' – Bestimmtheitsmaß (Anteil der Varianz, den das Modell erklärt)
::: 𝑅2=1−(SSE/SST)
::* 1.0 = perfekt, 0 = nicht besser als Mittelwert, <0 = schlechter als Mittelwert
* '''P95 / P99''' (Quantile) - Quantile beschreiben, wie groß der Fehler in den schlechtesten X % der Fälle ist.
::* '''P95:''' 95 % der Fehler liegen darunter → die schlechtesten 5 % sind größer
::* '''P99:''' 99 % der Fehler liegen darunter → zeigt Extremfehler
* '''Bias / Slope''' (Regression‑Diagnostik) - Diese beiden Werte stammen aus einer linearen Regression zwischen '''Vorhersage''' und '''Ist‑Wert'''.
::* Diese beiden Werte sind extrem hilfreich, um Modell‑Drift oder fehlerhafte Normalisierung zu erkennen.
::* Slope - Ideal: 1.0
:::* < 1 → Modell unterschätzt hohe Werte
:::* >= 1 → Modell überschätzt hohe Werte
:::* zeigt systematische Skalierungsfehler
::* Bias - Ideal: 0
:::* positiv → Modell sagt im Schnitt zu wenig vorher
:::* negativ → Modell sagt im Schnitt zu viel vorher
:::* zeigt systematische Verschiebung
* '''BitFail'''
::* FANN verwendet „BitFail“ als Zählwert, wie viele Ausgaben eines Samples „falsch“ sind. Ein Output gilt als falsch, wenn der Fehler größer ist als ein definierter BitFail‑Schwellwert (z. B. 0.35).
::* Bei Regressionen ist BitFail weniger aussagekräftig, aber:
:::- es zeigt, wie viele Samples „deutlich daneben“ liegen.
:::- gut zur schnellen Qualitätskontrolle während des Trainings.

Wird die geforderte Güte nicht erreicht, initiiert der Guard eine Wiederholung des Trainings bis zu einer maximalen Anzahl von Durchläufen.

* '''Bestes Modell speichern'''
: Das Modell mit dem niedrigsten Validierungsfehler wird ausgewählt.

* '''Verwendung nur des besten Modells'''
: Schlechtere Modelle werden verworfen.

* '''Trainingsmodus ohne Prognose'''
: Nützlich, wenn man nur trainieren, aber noch nicht prognostizieren möchte.
: einschalten mit aiControl ->aiConActivate=2

'''Es wird umgesetzt:'''
* ✔ Monitoring mit Fehlerevaluierung
* ✔ bestes Modell wird automatisch gespeichert
* ✔ Prognosen basieren ausschließlich auf dem besten Modell
* ✔ Trainingsmodus only möglich (aiConActivate=2)
* ✔ Ausgabe detaillierter Trainingsmetriken

 

==== Einstellbare Parameter über 'attr <Name> aiControl' ====

Die Einstellung von '''aiConActivate''', '''aiConAlpha''' und '''aiConTrainStart''' wirken sofort, alle anderen Parameter werden erst beim nächsten Trainingslauf wirksam.

'''aiConActivate'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0 || KI deaktiviert
|-
| 1 || KI aktiviert (Standard)
|-
| 2 || Trainingsmodus aktiv, die KI-Prognose ist deaktiviert. Es wird maximal eine Trainingswiederholung ausgeführt.
|}

'''Best‑Practice:''' 
* 1 ab 2000–3000 verfügbaren Datensätzen (siehe get <Name> valDecTree aiRawData), bei WP/EV > 5000
* Der Trainingsmodus dient dazu verschiedene Einstellungen testen zu können. Zur Zeitersparnis wird maximal eine Trainingswiederholung ausgeführt, unabhängig von der Güte des Trainingsergebisses

'''aiConAlpha'''

Mit diesem Parameter kann ein Hybridergebnis aus klassischen (Legacy‑)Prognosen und durch die KI ermittelten Prognosewerten erzeugt werden. Das Hybridergebnis wird durch eine prozentuale Mischung beider Resultate erstellt.

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0 || die KI-Ergebnisse werden nicht verwendet, nur Legacy Werte gehen in das finale Ergebnis ein
|-
| 0.x || die KI-Ergebnisse gehen zu 0.x * 100%, die Legacy Werte zu (1-0.x) * 100% in die finale Prognose ein
|-
| 1 || es werden ausschließlich KI-Ergebnisse verwendet, Legacy Werte gehen nicht in das finale Ergebnis ein
|}

'''Best‑Practice:''' 
* 1 wenn die Genauigkeit der KI-Prognose überzeugend ist, ansonsten kann ein Mix aus KI und Legacy-Prognose hergestellt werden

'''aiConTrainStart'''

Legt fest, wann das Modul ein atomatisches Erst- bzw. Folgetraining durchführt. Im Standard erfolgt das Training alle 7 Tage.

Format: `<Tage>:<Stunde>`, z. B. `7:3`.

'''Best‑Practice:''' 
* 7–14 Tage für normale Haushalte
* 3–5 Tage bei WP/EV

'''aiConActFunc'''

{| class="wikitable"
! Funktion !! Eigenschaften
|-
| SIGMOID || + bewährt, stabil, gut für kontinuierliche, monotone Zusammenhänge
– kann bei großen Inputs saturieren, aber bei Verbrauchsprognose meistens gut
|-
| GAUSSIAN || + gut für glatte Muster
– schlecht für harte Peaks (EV, Trockner), kann „vergessen“ und saturieren
|-
| ELLIOT || + schnellere, numerisch robustere Approximation von Sigmoid/Tanh, weniger Rechenaufwand
+ oft etwas „härter“ in der Reaktion, kann Peaks besser durchreichen 
– immer noch S‑förmig, also keine Wunderwaffe gegen komplett unmodellierte EV‑Ereignisse
|}

'''Best‑Practice:''' 
* SIGMOID oder SIGMOID_SYMMETRIC als Standard
* bei allen weiteren Aktivierungsfunktionen kommt es auf den Versuch an

'''aiConHiddenLayers'''

{| class="wikitable"
! Typ !! Beispiel !! Eigenschaften
|-
| klein || 50‑25 || schnell, weniger genau
|-
| mittel || 64‑32 || guter Kompromiss
|-
| tief || 64‑32‑16 / 80‑40‑20 || erkennt komplexe Muster
|}

'''Best‑Practice:''' 
* < 3000 verfügbaren Datensätzen → `50-25`
* 3000–8000 verfügbaren Datensätzen → `64-32`
* > 8000 verfügbaren Datensätzen oder WP/EV → `80-40-20`

'''aiConLearnRate'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0.001 || sehr stabil, langsam
|-
| 0.005 || guter Kompromiss
|-
| 0.01–0.05 || schnell, aber instabil
|}

'''Best‑Practice:''' 
* 0.005, bei WP/EV 0.001

'''aiConBitFailLimit'''

Das Bit‑Fail‑Limit bestimmt, '''ab welcher Abweichung zwischen Prognose und echtem Wert''' ein Trainingspunkt als „Fehler“ gezählt wird.
Ein kleinerer Wert macht das Training '''strenger''', ein größerer Wert macht es '''toleranter'''.

* '''kleineres Limit → Modell versucht Peaks stärker zu treffen''' → kann instabil werden, besonders mit INCREMENTAL
* '''größeres Limit → Modell glättet stärker''' → robuster, aber weniger peak‑sensitiv

{| class="wikitable"
! Wert !! Bedeutung
|-
| kleineres Limit (0.10–0.25) || Das Modell versucht Peaks und schnelle Änderungen genauer zu treffen, kann aber instabiler werden.
|-
| mittleres Limit (0.25–0.35) || Gute Balance zwischen Genauigkeit und Stabilität. Empfohlener Startbereich.
|-
| größeres Limit (0.35–0.50) || Das Modell wird robuster gegen Ausreißer und Rauschen, reagiert aber weniger stark auf Spitzenlasten.
|}

🌪️ '''Was bedeutet „verrauschter Haushalt“?''' 
Ein Haushalt gilt als „verrauscht“, wenn der Stromverbrauch viele kleine, unregelmäßige Schwankungen hat, die nicht durch klare Muster (z. B. PV, Wärmepumpe, feste Tagesabläufe) erklärbar sind.
Dazu gehören spontane Gerätewechsel, impulsartige Lasten oder allgemein unruhige Verbrauchsprofile.

Für solche Haushalte ist ein höheres Bit‑Fail‑Limit sinnvoll, weil das Modell dadurch robuster wird und nicht versucht, jede kleine Zufallsschwankung exakt vorherzusagen.

'''Best‑Practice:''' 
* versuche deinen Haushalt gemäß der oben beschriebenen Rauscheigenschaft einzuordnen und entscheide dann, ob ein Training unterhalb oder oberhalb des Defaultwertes (0.35) bei dir sinnvoll sein könnte. Bleibe dann bei der Einstellung die bei dir die besten Ergebnisse liefert.

'''aiConMomentum'''

{| class="wikitable"
! Bereich !! Bedeutung
|-
| 0.2 || reagiert direkt, schwankt stärker
|-
| 0.5–0.8 || stabil, guter Kompromiss
|-
| 0.9 || sehr stark geglättet
|}

'''Best‑Practice:''' 
* 0.5, bei WP/EV 0.7–0.8

'''aiConShuffleMode'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 0 || chronologisch
|-
| 1 || chronologischer Split + Shuffle
|-
| 2 || vollständiges Shuffle
|}

'''Best‑Practice:''' 
* 2, bei saisonalen Mustern 1

'''aiConShufflePeriod'''

{| class="wikitable"
! Wert !! Bedeutung
|-
| 10 || viel Variation
|-
| 15–20 || stabiler Kompromiss
|-
| >20 || Gefahr von Overfitting
|}

'''Best‑Practice:''' 
* 10, bei großen Datensätzen 15–20

'''aiConSteepness'''

{| class="wikitable"
! Bereich !! Bedeutung
|-
| <0.4 || starke Glättung
|-
| 0.5 || Standard
|-
| >0.7 || schärfere Muster
|}

'''Best‑Practice:''' 
* 0.9, bei glattem Verbrauch 0.5

'''aiConTrainAlgo'''

{| class="wikitable"
! Algorithmus !! Eigenschaften
|-
| RPROP || stabil, wenig Parameter
|-
| INCREMENTAL || schneller, empfindlicher
|}

'''Best‑Practice:''' 
* RPROP bei WP/EV
* INCREMENTAL bei einfachen Profilen

'''aiConProfile'''

Die folgenden Profile bestimmen, welche Verbrauchslogiken und Semantiken im Modell aktiviert werden. Sie beeinflussen, wie stark das Modell auf typische Haushaltsaktivitäten, PV‑Erzeugung und Wärmepumpenverhalten reagiert.

Damit Nutzer das passende Profil wählen können, sind die Profile hier verständlich beschrieben.

{| class="wikitable"
! Profil !! Eigenschaften
|-
| v1_common || Dieses Profil bildet den typischen menschlichen Tagesrhythmus ab:
* Morgenaktivität (Aufstehen, Geräte an)
* Mittagsaktivität (Kochen, Haushalt)
* Abendaktivität (Kochen, Licht, Geräte)
* Später Abend (Geräte gehen aus)
* Wochenendverhalten
* Tagesmuster vom Vortag
* Grundlast nachts

Es nutzt Zeitstruktur, saisonale Muster, Wetter und Verbrauchsdynamik — aber '''keine PV‑ oder Wärmepumpenlogik'''. 
'''Empfohlen für:'''
Haushalte mit reinem Stromverbrauch ohne besondere Geräte und wenig PV Einfluß, z.B. mit kleiner Balkon PV-Anlage.

|-
| v1_common_active || Für '''Haushalte mit stark ausgeprägten Aktivitätsmustern''' 
Wie ''v1_common'', aber mit stärkerer Betonung auf:
* Verbrauchssprüngen
* Trendbrüchen
* Volatilität (z. B. Kochen, Gerätewechsel)
* Wiederkehrenden Peaks

Dieses Profil reagiert sensibler auf '''kurzfristige Verbrauchsdynamik'''. 
'''Empfohlen für:'''
Haushalte mit unregelmäßigen oder dynamischen Verbrauchsprofilen (z.B. viele Geräte, Homeoffice, Familien).

|-
| v1_common_pv || Für '''Haushalte mit PV-getriebenen Verbrauchern''' 
Erweitert ''v1_common'' um PV‑Semantik:
* PV‑Erzeugung + Tageszeit
* PV‑Drop‑Erkennung (Wolke → Lastabfall)
* PV‑abhängige Verbrauchsverschiebung
* PV‑Mittagsspitzen‑Verstärker
* PV‑Temperatur‑Interaktionen (Heizung, Batterie, Geräteverhalten)

Das Modell versteht, dass Haushalte '''mittags anders verbrauchen''', wenn PV‑Strom verfügbar ist. 
'''Empfohlen für:'''
Haushalte mit größerer PV‑Anlage, aber ohne Wärmepumpe.

|-
| v1_common_active_pv || Für '''Haushalte mit dynamisch PV-getriebenen Verbrauchsverhalten''' 
Kombiniert:
* Dynamik‑Semantik aus v1_common_active
* PV‑Semantik aus v1_common_pv

Dieses Profil erkennt:
* spontane Peaks bei PV‑Überschuss
* Verbrauchssprünge + PV‑Erzeugung
* Trendverstärker mittags
* PV‑Drop‑Reaktionen
* Volatilität + PV‑Interaktionen

'''Empfohlen für:'''
PV‑Haushalte mit aktiven Verbrauchern (z.B. Kochen, Waschmaschine, Trockner usw.).

|-
| v1_heatpump || Für '''Haushalte mit Wärmepumpe (ohne dominante PV)''' 
Aktiviert die komplette Wärmepumpen‑Semantik:
* Heizmodus, Kühlmodus
* Warmwasser (morgens/abends, Zyklen, Kaltstart)
* Frostschutz
* Temperaturtrends
* Effizienzindikatoren (COP‑Proxy)
* Heiz‑/Kühlbedarf
* Temperaturdeltas und -historie

Das Modell versteht typische WP‑Verbrauchsmuster:
* morgens und abends Heizen
* Warmwasserzyklen
* Frostschutz nachts
* Reaktion auf Temperaturstürze

'''Empfohlen für:'''
Haushalte mit Wärmepumpe, aber ohne dominante PV.

|-
| v1_heatpump_pv || Für '''Wärmepumpen‑Haushalte mit dominanter PV''' 
Kombiniert:
* Wärmepumpen‑Semantik
* PV‑Semantik
* PV‑Warmwasser‑Boost
* PV‑Mittagsverschiebung
* PV‑abhängige Heiz-/WW‑Strategien
* Das Modell erkennt:
* PV‑Überschuss → Warmwasser
* PV‑Erzeugung → Heiz-/Kühlverhalten
* PV‑Drop → Lastabfall
* PV + Kälte → Heizspitzen

'''Empfohlen für:'''
Haushalte mit Wärmepumpe und dominanter PV‑Anlage.

|-
| v1_heatpump_active_pv || Für '''Wärmepumpe + PV + dynamisches Verbrauchsverhalten''' 
Das umfassendste Profil. Es kombiniert:
* Wärmepumpen‑Semantik
* PV‑Semantik
* Dynamik‑Semantik (Trend, Volatilität, Peaks)
* Spezial‑Booster (z. B. heatpump_boost_special, pv_mittag_peak_boost_special)

Dieses Profil erkennt:
* spontane Verbrauchssprünge
* WP‑Zyklen + PV‑Überschuss
* Trendbrüche + Temperaturdeltas
* dynamische Mittagspeaks
* komplexe Interaktionen zwischen PV, WP und menschlichem Verhalten

'''Empfohlen für:'''
Haushalte mit Wärmepumpe, PV und sehr aktivem Verbrauchsverhalten.

|-
| ||
|}

'''Best‑Practice:''' 
Die oben angegebenen Profileigenschaften beschreiben die implementierten Verstärkungen bzw. auch Abschwächungen zur Unterstützung des Lernprozesses der künstlichen Intelligenz. Teste Trainings mit unterschiedlichen Profilen und wähle das Profil mit dem die besten Ergebnisse erzielt werden. Beginne mit dem Profil welches wahrscheinlich am Besten zu deinem Haushalt passen könnte.

 

==== Integration von Umwelt- und Kontextfaktoren in die Prognose ====

Die Verbrauchscharakteristik eines Haushalts wird nicht nur durch die eingesetzten elektrischen Geräte bestimmt, sondern auch durch verschiedene systemische Einflussfaktoren, darunter:

* Anwesenheit bzw. Abwesenheit der Bewohner
* Außentemperaturen
* Abweichungen vom üblichen Tagesmuster, z.B. durch Feiertage oder Urlaubszeiten

'''Einbindung von Sensoren und Kontextdaten'''

Außentemperatursensoren, Windsensoren sowie Geräte zur Anwesenheits- oder Bewegungsdetektion werden im Attribut '''setupEnvironment''' hinterlegt. Die dafür erforderliche Syntax ist in der Online‑Hilfe des Moduls dokumentiert. SolarForecast nutzt diese Informationen, um Verbrauchsprognosen an reale Rahmenbedingungen anzupassen.

Die erfassten Umweltdaten sind Momentanwerte, die – sofern sie eine ausreichende Dynamik aufweisen – auf das in SolarForecast verwendete Stundenraster normiert oder geglättet werden.

::* '''Außentemperaturen:''' Temperaturen ändern sich vergleichsweise langsam und werden daher direkt übernommen. Ist kein Temperatursensor definiert, wird die Temperatur des verwendeten Wetterdienstes genutzt.
::* '''Anwesenheit:''' Für jede Stunde wird der Anwesenheitsstatus anhand des überwiegenden Zustands innerhalb dieser Stunde bestimmt.
::::- '''Beispiel:''' Verlassen die Bewohner das Haus erst zehn Minuten vor Ende der Stunde, würde eine reine Momentaufnahme den Status ''„abwesend“'' speichern. Da dies sachlich nicht zutrifft, wird der überwiegende Status der Stunde bewertet und gespeichert.
::* '''Windgeschwindigkeit:''' Zur Bewertung der Windverhältnisse werden zwei geglättete Windgeschwindigkeiten berechnet - eine '''schnelle''' und eine '''langsame''' Komponente. Beide verwenden '''exponentielles Glätten''', bei dem neue Messwerte stärker gewichtet werden als ältere.
:::: - '''Fast (10 Minuten):''' Reagiert schnell auf kurzfristige Änderungen, z. B. durch vorbeiziehende Wolken.
:::: - '''Slow (40 Minuten):''' Spiegelt die Großwetterlage bzw. den längerfristigen Trend wider.
:::: Die Glättung erfolgt nach dem Prinzip:
:::::: <code> neuer Wert = α · aktueller Messwert + (1 − α) · vorheriger geglätteter Wert </code>
:::: wobei <code>α</code> abhängig von der jeweiligen Zeitkonstante berechnet wird.

'''Feiertage und Urlaubszeiten'''

Für die Berücksichtigung von Feiertagen und Urlaub wird das in FHEM etablierte Verfahren über [https://fhem.de/commandref_DE.html#holiday holiday]-Devices verwendet.
Dazu werden die entsprechenden holiday‑Devices im globalen Attribut ''holiday2we'' registriert. SolarForecast liest die dort eingetragenen holiday‑Devices aus und übernimmt die darin definierten Daten (z.B. gesetzliche Feiertage, benutzerdefinierte freie Tage oder Urlaubszeiträume).

 

==== Das Training durchführen und produktiv setzen (Best Practice Ansatz) ====

Sind alle [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Voraussetzungen|Voraussetzungen]] erfüllt, kann das Verbauchsprognose-Modell trainiert und – sofern das Ergebnis überzeugt – für den Produktivbetrieb aktiviert werden.

1️⃣ '''Training‑Only‑Modus aktivieren'''

Für das initiale Training wird FANN im ''Training‑Only‑Modus'' aktiviert:

attr <Name> aiControl aiConActivate=2

In diesem Modus kann das Modell beliebig oft trainiert, bewertet und durch Anpassung der [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Einstellbare_Parameter_über_'attr_<Name>_aiControl|Steuerungsparameter]] optimiert werden – ohne dass die produktive Prognose beeinflusst wird. Es kann jederzeit ein neues Training gestartet werden.

Wer den Trainingsablauf und die internen Prüfungen live verfolgen möchte, aktiviert zusätzlich:

attr <Name> ctrlDebug aiProcess

2️⃣ '''Training starten'''

Mit der FANN-Aktivierung durch aiControl aiConActivate=2 (oder 1) werden automatisch sinnvolle '''Standardparameter''' für FANN gesetzt. Für den Einstieg empfiehlt es sich, zunächst mit diesen Defaults zu trainieren und Änderungen an Parametern schrittweise vorzunehmen, neu zu trainieren und die Veränderungen im Ergebnis zu bewerten. Als Hilfestellung gibt es dazu einen separaten [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Auswertung_der_Trainingskennwerte|Abschnitt]].

Das Training wird manuell gestartet mit:

set <Name> aiDecTree runConTrain

'''Hinweis:''' Ein bereits laufendes Training wird durch einen erneuten Start mit ''runConTrain'' automatisch abgebrochen.

Ein laufendes Training kann jederzeit manuell beendet werden:

set <Name> aiDecTree stopConTrain

3️⃣ '''Wie das Training intern abläuft'''

Der Trainingsprozess wird vollständig durch die interne Steuerungslogik des Moduls geführt:

* Ein Trainingsjob umfasst '''bis zu 6 Trainingswiederholungen''', jede mit '''maximal 15000''' Epochen.
* Ein '''Snapshot‑Guard''' überwacht kontinuierlich die Modellverbesserung und speichert bessere Modelle als Best Snapshot.
* Ein integrierter '''Early‑Stopping‑Mechanismus''' beendet Trainingsläufe, die sich nicht weiter verbessern.
* Ein interner '''Retrain‑Indikator''' bewertet den besten Snapshot. Ein '''Quality Gate''' entscheidet, ob ein weiterer Retrain durchgeführt wird.
* Die Anzahl der Retrains wird '''adaptiv''' anhand interner Kriterien bestimmt.
* Mit aktiviertem Debug‑Modus werden alle Entscheidungen im Log dokumentiert.

Der gesamte Prozess läuft in einem '''Nebenprozess''', um FHEM nicht zu blockieren.
Je nach Hardware, Datenmenge und Parametern kann das Training sehr lange dauern – im Extremfall mehrere Stunden. Ein CPU‑Kern kann dabei dauerhaft zu 100 % ausgelastet sein.

4️⃣ '''Ergebnis bewerten'''

Nach Abschluss des Trainings sollte das Ergebnis '''[[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Auswertung_der_Trainingskennwerte|manuell bewertet]]''' werden.

'''Wichtige Hinweise:''' 
* Auch bei '''nicht perfekten Kennzahlen''' lohnt sich eine visuelle Prüfung.
* Auch bei '''zu perfekten Kennzahlen''' ist Vorsicht geboten – dies kann auf Overfitting hindeuten.

5️⃣ '''Modell produktiv setzen'''

Zur visuellen Begutachtung und für den Produktivbetrieb wird das trainierte Modell aktiviert:

attr <Name> aiControl aiConActivate=1

Im nächsten Zyklus des Moduls (siehe 'attr ... plantControl cycleInterval') erscheinen die KI‑Prognosen in der Balkengrafik, sofern diese Ansicht aktiviert ist. Wenn die Prognose zufriedenstellend ist, bleibt das Modell aktiv. Falls nicht, kann jederzeit wieder in den ''Training‑Only''‑Modus gewechselt werden, um Parameter anzupassen und erneut zu trainieren.

6️⃣ '''Automatisches (Re)Training'''

Bei aktivem FANN‑Modus (aiConActivate=1 oder 2) wird automatisch alle '''7 Tage um 03:00 Uhr''' ein Retraining durchgeführt.
Der Zeitpunkt kann angepasst werden:

attr <Name> aiControl aiConTrainStart ...

7️⃣ '''Hybrid‑Modus'''

Das Modul unterstützt einen '''Hybrid‑Modus''', bei dem KI‑Prognosen mit den klassischen (Legacy‑)Prognosen gewichtet kombiniert werden.
Gesteuert wird dieser Modus über:

attr <Name> aiControl aiConAlpha <Wert>

Ein höherer Wert von [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Einstellbare_Parameter_über_'attr_<Name>_aiControl'|'''aiConAlpha''']] bedeutet stärkere Gewichtung der KI‑Prognose.

8️⃣ '''Debug‑Log'''

Für eine detaillierte Nachvollziehbarkeit des Trainingsprozesses kann der Debug‑Modus aktiviert werden.
Im Debug‑Log protokolliert das Modul sämtliche Schritte der Trainingslogik, darunter:

* Start und Ende einzelner Trainingsläufe
* Verbesserungen der Modellgüte
* Snapshot‑Updates
* Early‑Stopping‑Ereignisse
* Entscheidungen des Quality Gates
* Auslösung von Retrains
* Abschlussbewertung des besten Modells

Dies erleichtert sowohl die Diagnose ungewöhnlicher Trainingsverläufe als auch die Bewertung, ob Parameteranpassungen sinnvoll sind.

<div class="mw-collapsible mw-collapsed">
Ein '''auszugsweises Beispiel''' eines Trainingslogs -> <div class="mw-collapsible-content">
<pre>
2026.01.01 15:40:06.690 1: SolCast DEBUG> First attempt 0 with Seed=407496
2026.01.01 15:40:06.696 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7931,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.5,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=6344, Test=1586),
Data shuffle=2 (period=10)
2026.01.01 15:40:06.818 1: SolCast DEBUG> Epoche 1: Train MSE=0.001532, Val MSE=0.002521, Val MAE=0.028206, Val MedAE=0.020769, Bit_Fail=5 -> Snap saved (bit improved)
2026.01.01 15:40:07.534 1: SolCast DEBUG> Epoche 8: Train MSE=0.001472, Val MSE=0.002520, Val MAE=0.028199, Val MedAE=0.020764, Bit_Fail=5 -> Snap saved (metric improved)
2026.01.01 15:40:13.541 1: SolCast DEBUG> Epoche 67: Train MSE=0.001477, Val MSE=0.002518, Val MAE=0.026941, Val MedAE=0.018749, Bit_Fail=5 -> Snap saved (metric improved)
2026.01.01 15:40:13.748 1: SolCast DEBUG> Epoche 69: Train MSE=0.001476, Val MSE=0.002517, Val MAE=0.026928, Val MedAE=0.018728, Bit_Fail=5 -> Snap saved (metric improved)
...
2026.01.01 15:40:21.048 1: SolCast DEBUG> Epoche 140: Train MSE=0.001181, Val MSE=0.002253, Val MAE=0.023585, Val MedAE=0.012176, Bit_Fail=5 -> Snap saved (metric improved)
2026.01.01 15:40:27.191 1: SolCast DEBUG> Epoche 200: Train MSE=0.001181, Val MSE=0.001860, Val MAE=0.022984, Val MedAE=0.012926, Bit_Fail=4
2026.01.01 15:40:27.704 1: SolCast DEBUG> Epoche 205: Train MSE=0.000982, Val MSE=0.001821, Val MAE=0.022794, Val MedAE=0.012760, Bit_Fail=4 -> Snap saved (bit improved)
2026.01.01 15:40:29.356 1: SolCast DEBUG> Epoche 221: Train MSE=0.000894, Val MSE=0.001654, Val MAE=0.021991, Val MedAE=0.012736, Bit_Fail=4 -> Snap saved (metric improved)
...
2026.01.01 15:40:30.508 1: SolCast DEBUG> Epoche 232: Train MSE=0.000806, Val MSE=0.001516, Val MAE=0.020531, Val MedAE=0.011495, Bit_Fail=4 -> Snap saved (metric improved)
2026.01.01 15:40:30.615 1: SolCast DEBUG> Epoche 233: Train MSE=0.000797, Val MSE=0.001498, Val MAE=0.020435, Val MedAE=0.011480, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 15:40:30.722 1: SolCast DEBUG> Epoche 234: Train MSE=0.000787, Val MSE=0.001479, Val MAE=0.020336, Val MedAE=0.011380, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 15:40:30.829 1: SolCast DEBUG> Epoche 235: Train MSE=0.000777, Val MSE=0.001460, Val MAE=0.020232, Val MedAE=0.011321, Bit_Fail=2 -> Snap saved (metric improved)
...
2026.01.01 15:40:34.103 1: SolCast DEBUG> Epoche 266: Train MSE=0.000347, Val MSE=0.000621, Val MAE=0.015564, Val MedAE=0.010886, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 15:40:34.209 1: SolCast DEBUG> Epoche 267: Train MSE=0.000336, Val MSE=0.000598, Val MAE=0.015326, Val MedAE=0.010661, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 15:40:34.322 1: SolCast DEBUG> Epoche 268: Train MSE=0.000325, Val MSE=0.000576, Val MAE=0.015095, Val MedAE=0.010564, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 15:40:34.431 1: SolCast DEBUG> Epoche 269: Train MSE=0.000314, Val MSE=0.000555, Val MAE=0.014870, Val MedAE=0.010315, Bit_Fail=0 -> Snap saved (metric improved)
...
2026.01.01 15:45:53.259 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000188, Val MSE=0.000286, Val MAE=0.011095, Val MedAE=0.007725, Bit_Fail=0
2026.01.01 15:46:00.439 1: SolCast DEBUG> Early stopping bei Epoche 3368 (no improvement since 2000 epochs)
2026.01.01 15:46:00.439 1: === Snapshot-Statistik ===
2026.01.01 15:46:00.440 1: Metric-Improvement Snapshots: 67 (letzte Epoche: 1368)
2026.01.01 15:46:00.440 1: Bit-Improvement Snapshots: 5 (letzte Epoche: 267)
2026.01.01 15:46:00.441 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 15:46:00.443 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 1368: Train MSE=0.000188, Val MSE=0.000286, Val MAE=0.010789, Val MedAE=0.006938, Bit_Fail=0,
2026.01.01 15:46:00.444 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 15:46:00.475 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000188, Validation MSE=0.000286, Validation Bit_Fail=0
2026.01.01 15:46:00.476 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000188
Val MSE=0.000286
Val Mean=0.0002908456
VAL/TRAIN MSE Ratio=1.525656 (limit=2.5)
Diff=0.000099 (limit=0.005)
ValStd=0.0000052738 (limit=7.27113936211133e-05)
-- At Original Scale: --
MAE=96.4264081498789
RMSE/MAE=1.5680 (limit=1.5)
Slope=0.846171 (limit=0.7 .. 1.3)
Bias=104.79 (limit=+-48.2132040749395)
R2=0.886437100872621
P95=283.1830 (limit=385.705632599516)
P99=538.2559 (limit=771.411265199031)
-- Robustness Indicators: --
RMSE relative=24 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
</pre>
</div>
</div>

<div class="mw-collapsible mw-collapsed">
Ein '''komplettes Beispiel mit 3 Wiederholungen''' eines Trainingslogs -> <div class="mw-collapsible-content">
<pre>
2026.01.01 18:03:45.037 1: SolCast DEBUG> AI FANN Training for Consumption Forecast BlockingCall PID "813631" with Timeout 86400 s started
2026.01.01 18:03:46.046 1: SolCast DEBUG> AI FANN - There are 503 Records skipped due to incomplete or invalid data. Index:
2025013115, 2025020401, 2025020414, 2025020415, 2025020416, 2025021813, 2025021816, 2025021913, 2025021914, 2025021915, 2025022013, 2025022316, 2025030216, 2025030310, 2025030315, 2025030316, 2025030416, 2025030511, 2025030512, 2025030516, 2025030517, 2025030610, 2025030611, 2025030612, 2025030616, 2025030710, 2025030711, 2025030712, 2025030713, 2025030716, 2025030810, 2025030910, 2025030916, 2025030917, 2025031010, 2025031114, 2025031519, 2025031609, 2025031709, 2025031710, 2025031716, 2025031717, 2025031810, 2025031811, 2025031814, 2025031815, 2025031816, 2025031817, 2025031909, 2025031910, 2025031911, 2025031915, 2025031916, 2025031917, 2025032010, 2025032011, 2025032014, 2025032015, 2025032016, 2025032017, 2025032110, 2025032114, 2025032115, 2025032116, 2025032117, 2025032209, 2025032210, 2025032211, 2025032214, 2025032215, 2025032814, 2025032815, 2025032817, 2025033003, 2025040211, 2025040212, 2025040215, 2025040216, 2025040217, 2025040314, 2025040315, 2025040316, 2025040317, 2025040318, 2025040410, 2025040411, 2025040413, 2025040414, 2025040418, 2025040510, 2025040517, 2025040518, 2025040612, 2025040617, 2025040618, 2025040711, 2025040811, 2025040812, 2025040813, 2025041017, 2025041018, 2025041110, 2025041111, 2025041216, 2025041217, 2025041218, 2025041312, 2025041316, 2025041317, 2025041417, 2025041418, 2025041611, 2025041617, 2025041618, 2025042017, 2025042018, 2025042115, 2025042117, 2025042118, 2025042218, 2025042609, 2025042610, 2025042611, 2025042612, 2025042617, 2025042618, 2025042710, 2025042711, 2025042712, 2025042714, 2025042715, 2025042717, 2025042718, 2025042810, 2025042811, 2025042813, 2025042814, 2025042817, 2025042818, 2025042911, 2025042913, 2025042914, 2025042917, 2025042918, 2025050110, 2025050111, 2025050114, 2025050117, 2025050118, 2025050210, 2025050211, 2025050213, 2025050518, 2025050610, 2025050611, 2025050614, 2025050617, 2025050618, 2025050706, 2025050707, 2025050708, 2025050810, 2025050812, 2025050816, 2025050817, 2025050910, 2025050911, 2025050912, 2025050917, 2025050918, 2025051009, 2025051010, 2025051011, 2025051012, 2025051017, 2025051018, 2025051109, 2025051210, 2025051211, 2025051212, 2025051213, 2025051214, 2025051218, 2025051310, 2025051313, 2025051314, 2025051317, 2025051318, 2025051411, 2025051413, 2025051414, 2025051418, 2025051510, 2025051610, 2025051611, 2025051710, 2025051713, 2025051916, 2025052010, 2025052011, 2025052017, 2025052018, 2025052111, 2025052113, 2025052114, 2025052115, 2025052118, 2025052211, 2025052409, 2025052410, 2025052416, 2025052417, 2025052609, 2025052616, 2025052617, 2025052618, 2025052817, 2025052910, 2025052911, 2025052917, 2025053010, 2025053013, 2025053017, 2025053018, 2025053109, 2025053110, 2025053111, 2025053112, 2025053113, 2025053115, 2025053117, 2025060210, 2025060215, 2025060217, 2025060310, 2025060312, 2025060317, 2025060318, 2025060513, 2025060517, 2025060609, 2025060610, 2025060618, 2025060710, 2025060711, 2025060712, 2025060713, 2025060811, 2025060812, 2025060816, 2025060817, 2025060818, 2025060909, 2025060910, 2025060911, 2025060912, 2025060913, 2025060917, 2025060918, 2025061015, 2025061016, 2025061109, 2025061114, 2025061117, 2025061118, 2025061119, 2025061209, 2025061210, 2025061211, 2025061212, 2025061213, 2025061214, 2025061215, 2025061217, 2025061218, 2025061309, 2025061310, 2025061311, 2025061312, 2025061313, 2025061314, 2025061315, 2025061317, 2025061318, 2025061319, 2025061410, 2025061411, 2025061413, 2025061414, 2025061417, 2025061418, 2025061710, 2025061713, 2025061714, 2025061717, 2025061718, 2025061724, 2025062010, 2025062011, 2025062013, 2025062014, 2025062017, 2025062018, 2025062109, 2025062110, 2025062111, 2025062112, 2025062114, 2025062117, 2025062118, 2025062209, 2025062210, 2025062211, 2025062212, 2025062213, 2025062214, 2025062217, 2025062218, 2025062309, 2025062310, 2025062311, 2025062317, 2025062318, 2025062409, 2025062410, 2025062411, 2025062818, 2025062911, 2025062913, 2025062918, 2025063009, 2025063011, 2025063013, 2025063014, 2025063017, 2025063018, 2025070110, 2025070111, 2025070112, 2025070113, 2025070117, 2025070118, 2025070210, 2025070211, 2025070212, 2025070213, 2025070217, 2025070218, 2025070318, 2025070410, 2025070411, 2025070412, 2025070417, 2025070418, 2025070510, 2025070511, 2025070512, 2025070610, 2025070611, 2025070615, 2025070717, 2025070810, 2025071013, 2025071017, 2025071112, 2025071113, 2025071117, 2025071311, 2025071318, 2025071410, 2025071411, 2025071812, 2025071818, 2025071910, 2025071911, 2025071912, 2025071913, 2025071918, 2025072009, 2025072510, 2025072514, 2025073110, 2025073118, 2025080118, 2025080210, 2025080310, 2025080410, 2025080417, 2025080418, 2025080616, 2025080617, 2025080715, 2025080716, 2025080717, 2025080718, 2025080917, 2025080918, 2025081015, 2025081016, 2025081017, 2025081018, 2025081115, 2025081116, 2025081117, 2025081118, 2025081120, 2025081121, 2025081122, 2025081123, 2025081124, 2025081215, 2025081216, 2025081217, 2025081315, 2025081316, 2025081317, 2025081318, 2025081415, 2025081416, 2025081417, 2025081418, 2025081516, 2025081517, 2025081617, 2025081816, 2025081817, 2025081818, 2025081915, 2025081916, 2025081917, 2025082015, 2025082016, 2025082017, 2025082018, 2025082115, 2025082116, 2025082117, 2025082416, 2025082516, 2025082517, 2025082518, 2025082519, 2025082612, 2025082613, 2025082614, 2025082618, 2025082716, 2025082717, 2025083110, 2025083111, 2025083113, 2025083118, 2025090110, 2025090215, 2025090311, 2025090317, 2025090411, 2025090414, 2025090417, 2025090517, 2025090610, 2025090611, 2025090612, 2025090618, 2025090710, 2025090711, 2025090713, 2025090714, 2025090718, 2025090810, 2025090813, 2025090910, 2025090911, 2025091217, 2025091816, 2025091817, 2025091915, 2025091916, 2025091917, 2025092014, 2025092015, 2025092016, 2025092017, 2025092113, 2025092115, 2025092315, 2025092316, 2025092417, 2025092910, 2025092911, 2025092912, 2025092917, 2025093011, 2025093012, 2025093013, 2025093017, 2025100316, 2025100317, 2025110320, 2025122222, 2025122223, 2025122224, 2025122510
2026.01.01 18:03:46.940 1: SolCast - DBG F[7300]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.942 1: SolCast - DBG F[7301]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.944 1: SolCast - DBG F[7302]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.945 1: SolCast - DBG F[7303]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.947 1: SolCast - DBG F[7304]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.949 1: SolCast - DBG F[7305]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.951 1: SolCast - DBG F[7306]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.953 1: SolCast - DBG F[7307]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.954 1: SolCast - DBG F[7308]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.956 1: SolCast - DBG F[7309]: lag1=0.001 lag2=0.001 lag24=0.001 d1p=0.000 d1n=0.000 rollstd=0.000 up=0 down=0 upS=0.000 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.958 1: SolCast - DBG F[7310]: lag1=0.002 lag2=0.001 lag24=0.002 d1p=0.036 d1n=0.000 rollstd=0.000 up=1 down=0 upS=0.036 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.960 1: SolCast - DBG F[7311]: lag1=0.026 lag2=0.002 lag24=0.008 d1p=0.004 d1n=0.000 rollstd=0.033 up=0 down=0 upS=0.004 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.962 1: SolCast - DBG F[7312]: lag1=0.029 lag2=0.026 lag24=0.012 d1p=0.000 d1n=0.008 rollstd=0.044 up=0 down=1 upS=0.000 downS=0.008 vol=0 pvX=0 break=0
2026.01.01 18:03:46.963 1: SolCast - DBG F[7313]: lag1=0.023 lag2=0.029 lag24=0.016 d1p=0.011 d1n=0.000 rollstd=0.045 up=1 down=0 upS=0.011 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.965 1: SolCast - DBG F[7314]: lag1=0.031 lag2=0.023 lag24=0.018 d1p=0.000 d1n=0.003 rollstd=0.044 up=0 down=0 upS=0.000 downS=0.003 vol=0 pvX=0 break=0
2026.01.01 18:03:46.967 1: SolCast - DBG F[7315]: lag1=0.028 lag2=0.031 lag24=0.017 d1p=0.002 d1n=0.000 rollstd=0.036 up=0 down=0 upS=0.002 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.968 1: SolCast - DBG F[7316]: lag1=0.030 lag2=0.028 lag24=0.008 d1p=0.000 d1n=0.002 rollstd=0.009 up=0 down=0 upS=0.000 downS=0.002 vol=0 pvX=0 break=0
2026.01.01 18:03:46.970 1: SolCast - DBG F[7317]: lag1=0.028 lag2=0.030 lag24=0.002 d1p=0.000 d1n=0.005 rollstd=0.009 up=0 down=1 upS=0.000 downS=0.005 vol=0 pvX=0 break=0
2026.01.01 18:03:46.974 1: SolCast - DBG F[7318]: lag1=0.025 lag2=0.028 lag24=0.002 d1p=0.005 d1n=0.000 rollstd=0.010 up=1 down=0 upS=0.005 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:46.976 1: SolCast - DBG F[7319]: lag1=0.028 lag2=0.025 lag24=0.001 d1p=0.008 d1n=0.000 rollstd=0.007 up=1 down=0 upS=0.008 downS=0.000 vol=0 pvX=0 break=0
2026.01.01 18:03:47.013 1: SolCast DEBUG> First attempt 0 with Seed=439288
2026.01.01 18:03:47.024 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 18:03:47.208 1: SolCast DEBUG> Epoche 1: Train MSE=0.002194, Val MSE=0.002834, Val MAE=0.031901, Val MedAE=0.027985, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 18:03:47.528 1: SolCast DEBUG> Epoche 3: Train MSE=0.002192, Val MSE=0.002833, Val MAE=0.031892, Val MedAE=0.027975, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:03:54.175 1: SolCast DEBUG> Epoche 48: Train MSE=0.001736, Val MSE=0.002765, Val MAE=0.029706, Val MedAE=0.016374, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:04:02.843 1: SolCast DEBUG> Epoche 100: Train MSE=0.001736, Val MSE=0.001509, Val MAE=0.026824, Val MedAE=0.022443, Bit_Fail=1
2026.01.01 18:04:07.181 1: SolCast DEBUG> Epoche 127: Train MSE=0.000623, Val MSE=0.001033, Val MAE=0.022203, Val MedAE=0.017074, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 18:04:07.341 1: SolCast DEBUG> Epoche 128: Train MSE=0.000611, Val MSE=0.001012, Val MAE=0.021994, Val MedAE=0.017013, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:07.519 1: SolCast DEBUG> Epoche 129: Train MSE=0.000599, Val MSE=0.000990, Val MAE=0.021783, Val MedAE=0.016793, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:07.994 1: SolCast DEBUG> Epoche 131: Train MSE=0.000577, Val MSE=0.000943, Val MAE=0.021456, Val MedAE=0.016655, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.185 1: SolCast DEBUG> Epoche 132: Train MSE=0.000566, Val MSE=0.000922, Val MAE=0.021240, Val MedAE=0.016463, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.344 1: SolCast DEBUG> Epoche 133: Train MSE=0.000554, Val MSE=0.000901, Val MAE=0.021025, Val MedAE=0.016355, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.508 1: SolCast DEBUG> Epoche 134: Train MSE=0.000543, Val MSE=0.000881, Val MAE=0.020809, Val MedAE=0.016328, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.684 1: SolCast DEBUG> Epoche 135: Train MSE=0.000532, Val MSE=0.000860, Val MAE=0.020593, Val MedAE=0.016227, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.840 1: SolCast DEBUG> Epoche 136: Train MSE=0.000521, Val MSE=0.000841, Val MAE=0.020381, Val MedAE=0.016031, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:08.989 1: SolCast DEBUG> Epoche 137: Train MSE=0.000511, Val MSE=0.000822, Val MAE=0.020175, Val MedAE=0.015652, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.144 1: SolCast DEBUG> Epoche 138: Train MSE=0.000501, Val MSE=0.000803, Val MAE=0.019972, Val MedAE=0.015495, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.297 1: SolCast DEBUG> Epoche 139: Train MSE=0.000492, Val MSE=0.000786, Val MAE=0.019773, Val MedAE=0.015409, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.458 1: SolCast DEBUG> Epoche 140: Train MSE=0.000481, Val MSE=0.000777, Val MAE=0.019495, Val MedAE=0.015158, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.615 1: SolCast DEBUG> Epoche 141: Train MSE=0.000473, Val MSE=0.000760, Val MAE=0.019325, Val MedAE=0.015145, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.767 1: SolCast DEBUG> Epoche 142: Train MSE=0.000465, Val MSE=0.000745, Val MAE=0.019163, Val MedAE=0.015044, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:09.919 1: SolCast DEBUG> Epoche 143: Train MSE=0.000457, Val MSE=0.000730, Val MAE=0.019008, Val MedAE=0.015017, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.080 1: SolCast DEBUG> Epoche 144: Train MSE=0.000449, Val MSE=0.000716, Val MAE=0.018857, Val MedAE=0.014983, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.245 1: SolCast DEBUG> Epoche 145: Train MSE=0.000442, Val MSE=0.000702, Val MAE=0.018714, Val MedAE=0.014883, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.400 1: SolCast DEBUG> Epoche 146: Train MSE=0.000436, Val MSE=0.000690, Val MAE=0.018579, Val MedAE=0.014777, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.705 1: SolCast DEBUG> Epoche 148: Train MSE=0.000424, Val MSE=0.000667, Val MAE=0.018328, Val MedAE=0.014732, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:10.858 1: SolCast DEBUG> Epoche 149: Train MSE=0.000418, Val MSE=0.000656, Val MAE=0.018213, Val MedAE=0.014659, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:04:11.447 1: SolCast DEBUG> Epoche 153: Train MSE=0.000398, Val MSE=0.000655, Val MAE=0.017918, Val MedAE=0.014430, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 18:04:11.597 1: SolCast DEBUG> Epoche 154: Train MSE=0.000394, Val MSE=0.000648, Val MAE=0.017836, Val MedAE=0.014356, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:11.780 1: SolCast DEBUG> Epoche 155: Train MSE=0.000390, Val MSE=0.000641, Val MAE=0.017757, Val MedAE=0.014209, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:11.968 1: SolCast DEBUG> Epoche 156: Train MSE=0.000386, Val MSE=0.000635, Val MAE=0.017685, Val MedAE=0.014026, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:12.119 1: SolCast DEBUG> Epoche 157: Train MSE=0.000383, Val MSE=0.000629, Val MAE=0.017617, Val MedAE=0.013986, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:15.889 1: SolCast DEBUG> Epoche 180: Train MSE=0.000338, Val MSE=0.000530, Val MAE=0.017079, Val MedAE=0.013927, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:19.269 1: SolCast DEBUG> Epoche 200: Train MSE=0.000338, Val MSE=0.000535, Val MAE=0.016673, Val MedAE=0.013893, Bit_Fail=0
2026.01.01 18:04:35.878 1: SolCast DEBUG> Epoche 290: Train MSE=0.000288, Val MSE=0.000524, Val MAE=0.016388, Val MedAE=0.013535, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:36.582 1: SolCast DEBUG> Epoche 293: Train MSE=0.000287, Val MSE=0.000523, Val MAE=0.016367, Val MedAE=0.013507, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:37.370 1: SolCast DEBUG> Epoche 296: Train MSE=0.000287, Val MSE=0.000522, Val MAE=0.016353, Val MedAE=0.013413, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:04:38.343 1: SolCast DEBUG> Epoche 300: Train MSE=0.000287, Val MSE=0.000500, Val MAE=0.016520, Val MedAE=0.014059, Bit_Fail=0
2026.01.01 18:04:53.153 1: SolCast DEBUG> Epoche 360: Train MSE=0.000276, Val MSE=0.000498, Val MAE=0.016213, Val MedAE=0.013363, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:05:03.452 1: SolCast DEBUG> Epoche 400: Train MSE=0.000276, Val MSE=0.000492, Val MAE=0.016416, Val MedAE=0.013627, Bit_Fail=0
2026.01.01 18:05:29.137 1: SolCast DEBUG> Epoche 500: Train MSE=0.000276, Val MSE=0.000500, Val MAE=0.016208, Val MedAE=0.013216, Bit_Fail=0
2026.01.01 18:05:51.013 1: SolCast DEBUG> Epoche 600: Train MSE=0.000276, Val MSE=0.000500, Val MAE=0.016319, Val MedAE=0.012971, Bit_Fail=0
2026.01.01 18:06:14.772 1: SolCast DEBUG> Epoche 700: Train MSE=0.000276, Val MSE=0.000511, Val MAE=0.016383, Val MedAE=0.013241, Bit_Fail=0
2026.01.01 18:06:36.483 1: SolCast DEBUG> Epoche 800: Train MSE=0.000276, Val MSE=0.000509, Val MAE=0.016792, Val MedAE=0.013049, Bit_Fail=0
2026.01.01 18:06:52.867 1: SolCast DEBUG> Epoche 900: Train MSE=0.000276, Val MSE=0.000495, Val MAE=0.015972, Val MedAE=0.012938, Bit_Fail=0
2026.01.01 18:06:52.877 1: SolCast DEBUG> Epoche 900: Train MSE=0.000242, Val MSE=0.000495, Val MAE=0.015972, Val MedAE=0.012938, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:09.391 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000242, Val MSE=0.000493, Val MAE=0.016187, Val MedAE=0.013015, Bit_Fail=0
2026.01.01 18:07:14.202 1: SolCast DEBUG> Epoche 1027: Train MSE=0.000237, Val MSE=0.000491, Val MAE=0.015971, Val MedAE=0.012928, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:18.001 1: SolCast DEBUG> Epoche 1050: Train MSE=0.000234, Val MSE=0.000486, Val MAE=0.015890, Val MedAE=0.012757, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:18.455 1: SolCast DEBUG> Epoche 1053: Train MSE=0.000234, Val MSE=0.000485, Val MAE=0.015881, Val MedAE=0.012678, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:25.760 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000234, Val MSE=0.000480, Val MAE=0.015846, Val MedAE=0.012669, Bit_Fail=0
2026.01.01 18:07:25.766 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000233, Val MSE=0.000480, Val MAE=0.015846, Val MedAE=0.012669, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:42.102 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000233, Val MSE=0.000484, Val MAE=0.016233, Val MedAE=0.012505, Bit_Fail=0
2026.01.01 18:07:43.824 1: SolCast DEBUG> Epoche 1210: Train MSE=0.000227, Val MSE=0.000470, Val MAE=0.015552, Val MedAE=0.012390, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:07:57.828 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000227, Val MSE=0.000520, Val MAE=0.017539, Val MedAE=0.013492, Bit_Fail=0
2026.01.01 18:08:14.430 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000227, Val MSE=0.000460, Val MAE=0.016046, Val MedAE=0.012304, Bit_Fail=0
2026.01.01 18:08:16.132 1: SolCast DEBUG> Epoche 1410: Train MSE=0.000222, Val MSE=0.000452, Val MAE=0.015408, Val MedAE=0.011884, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:17.883 1: SolCast DEBUG> Epoche 1420: Train MSE=0.000220, Val MSE=0.000443, Val MAE=0.015258, Val MedAE=0.011811, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:29.901 1: SolCast DEBUG> Epoche 1490: Train MSE=0.000218, Val MSE=0.000439, Val MAE=0.014983, Val MedAE=0.011569, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:30.803 1: SolCast DEBUG> Epoche 1496: Train MSE=0.000218, Val MSE=0.000438, Val MAE=0.014960, Val MedAE=0.011509, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:08:31.440 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000218, Val MSE=0.000439, Val MAE=0.015419, Val MedAE=0.011971, Bit_Fail=0
2026.01.01 18:08:47.448 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000218, Val MSE=0.000454, Val MAE=0.016309, Val MedAE=0.012168, Bit_Fail=0
2026.01.01 18:08:50.500 1: SolCast DEBUG> Epoche 1620: Train MSE=0.000214, Val MSE=0.000431, Val MAE=0.014770, Val MedAE=0.011218, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:03.800 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000214, Val MSE=0.000439, Val MAE=0.015947, Val MedAE=0.012095, Bit_Fail=0
2026.01.01 18:09:12.275 1: SolCast DEBUG> Epoche 1755: Train MSE=0.000210, Val MSE=0.000414, Val MAE=0.014646, Val MedAE=0.011210, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:19.335 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000210, Val MSE=0.000427, Val MAE=0.015787, Val MedAE=0.011912, Bit_Fail=0
2026.01.01 18:09:36.229 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000210, Val MSE=0.000417, Val MAE=0.015680, Val MedAE=0.011996, Bit_Fail=0
2026.01.01 18:09:45.972 1: SolCast DEBUG> Epoche 1960: Train MSE=0.000204, Val MSE=0.000388, Val MAE=0.014589, Val MedAE=0.011116, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:51.969 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000204, Val MSE=0.000404, Val MAE=0.015606, Val MedAE=0.012356, Bit_Fail=0
2026.01.01 18:09:53.511 1: SolCast DEBUG> Epoche 2010: Train MSE=0.000202, Val MSE=0.000386, Val MAE=0.014313, Val MedAE=0.011006, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:09:55.063 1: SolCast DEBUG> Epoche 2020: Train MSE=0.000201, Val MSE=0.000383, Val MAE=0.014131, Val MedAE=0.010774, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:10:08.287 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000201, Val MSE=0.000380, Val MAE=0.014528, Val MedAE=0.011353, Bit_Fail=0
2026.01.01 18:10:24.098 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000201, Val MSE=0.000370, Val MAE=0.013946, Val MedAE=0.010416, Bit_Fail=0
2026.01.01 18:10:24.104 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000197, Val MSE=0.000370, Val MAE=0.013946, Val MedAE=0.010416, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:10:39.646 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000197, Val MSE=0.000374, Val MAE=0.014907, Val MedAE=0.011753, Bit_Fail=0
2026.01.01 18:10:56.682 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000197, Val MSE=0.000356, Val MAE=0.013705, Val MedAE=0.010006, Bit_Fail=0
2026.01.01 18:10:56.693 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000192, Val MSE=0.000356, Val MAE=0.013705, Val MedAE=0.010006, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:11:12.550 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000192, Val MSE=0.000375, Val MAE=0.015257, Val MedAE=0.012743, Bit_Fail=0
2026.01.01 18:11:15.676 1: SolCast DEBUG> Epoche 2520: Train MSE=0.000191, Val MSE=0.000355, Val MAE=0.013591, Val MedAE=0.009674, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:11:17.824 1: SolCast DEBUG> Epoche 2531: Train MSE=0.000190, Val MSE=0.000346, Val MAE=0.013480, Val MedAE=0.009639, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:11:28.987 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000190, Val MSE=0.000339, Val MAE=0.013649, Val MedAE=0.010530, Bit_Fail=0
2026.01.01 18:11:45.115 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000190, Val MSE=0.000354, Val MAE=0.014651, Val MedAE=0.011877, Bit_Fail=0
2026.01.01 18:12:01.075 1: SolCast DEBUG> Epoche 2790: Train MSE=0.000186, Val MSE=0.000341, Val MAE=0.013362, Val MedAE=0.009487, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:12:02.671 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000186, Val MSE=0.000333, Val MAE=0.013606, Val MedAE=0.010687, Bit_Fail=0
2026.01.01 18:12:18.422 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000186, Val MSE=0.000335, Val MAE=0.013448, Val MedAE=0.010124, Bit_Fail=0
2026.01.01 18:12:35.464 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000186, Val MSE=0.000327, Val MAE=0.013352, Val MedAE=0.010017, Bit_Fail=0
2026.01.01 18:12:56.411 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000186, Val MSE=0.000333, Val MAE=0.013996, Val MedAE=0.011160, Bit_Fail=0
2026.01.01 18:13:10.994 1: SolCast DEBUG> Epoche 3162: Train MSE=0.000181, Val MSE=0.000328, Val MAE=0.013113, Val MedAE=0.009469, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:13:18.736 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000181, Val MSE=0.000320, Val MAE=0.013393, Val MedAE=0.010591, Bit_Fail=0
2026.01.01 18:13:39.675 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000181, Val MSE=0.000319, Val MAE=0.013325, Val MedAE=0.010389, Bit_Fail=0
2026.01.01 18:14:00.271 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000181, Val MSE=0.000325, Val MAE=0.014006, Val MedAE=0.011521, Bit_Fail=0
2026.01.01 18:14:22.409 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000181, Val MSE=0.000344, Val MAE=0.014666, Val MedAE=0.012138, Bit_Fail=0
2026.01.01 18:14:38.101 1: SolCast DEBUG> Epoche 3580: Train MSE=0.000177, Val MSE=0.000319, Val MAE=0.012991, Val MedAE=0.009430, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:14:42.467 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000177, Val MSE=0.000314, Val MAE=0.013079, Val MedAE=0.010056, Bit_Fail=0
2026.01.01 18:15:03.838 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000177, Val MSE=0.000333, Val MAE=0.014308, Val MedAE=0.011807, Bit_Fail=0
2026.01.01 18:15:16.053 2: HUEBridge: http request failed: read from http://192.168.2.7:80 timed out
2026.01.01 18:15:30.476 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000177, Val MSE=0.000321, Val MAE=0.013020, Val MedAE=0.009413, Bit_Fail=0
2026.01.01 18:15:45.037 1: SolCast DEBUG> Epoche 3870: Train MSE=0.000174, Val MSE=0.000317, Val MAE=0.012911, Val MedAE=0.009292, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:15:52.131 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000174, Val MSE=0.000312, Val MAE=0.013464, Val MedAE=0.010556, Bit_Fail=0
2026.01.01 18:16:12.390 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000174, Val MSE=0.000320, Val MAE=0.013974, Val MedAE=0.011455, Bit_Fail=0
2026.01.01 18:16:29.091 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000174, Val MSE=0.000312, Val MAE=0.013592, Val MedAE=0.010912, Bit_Fail=0
2026.01.01 18:16:52.505 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000174, Val MSE=0.000302, Val MAE=0.012962, Val MedAE=0.010156, Bit_Fail=0
2026.01.01 18:17:16.099 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000174, Val MSE=0.000303, Val MAE=0.013023, Val MedAE=0.010334, Bit_Fail=0
2026.01.01 18:17:31.066 1: openMeteo - Open-Meteo API server response: start_SSL https://api.open-meteo.com:443 timed out
2026.01.01 18:17:38.285 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000174, Val MSE=0.000302, Val MAE=0.013197, Val MedAE=0.010550, Bit_Fail=0
2026.01.01 18:17:52.429 1: SolCast DEBUG> Epoche 4460: Train MSE=0.000170, Val MSE=0.000311, Val MAE=0.012837, Val MedAE=0.009137, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:17:58.628 1: SolCast DEBUG> Epoche 4490: Train MSE=0.000170, Val MSE=0.000305, Val MAE=0.012794, Val MedAE=0.009134, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:18:01.453 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000170, Val MSE=0.000301, Val MAE=0.012898, Val MedAE=0.009802, Bit_Fail=0
2026.01.01 18:18:23.799 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000170, Val MSE=0.000298, Val MAE=0.012957, Val MedAE=0.010201, Bit_Fail=0
2026.01.01 18:18:39.811 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000170, Val MSE=0.000301, Val MAE=0.013527, Val MedAE=0.011413, Bit_Fail=0
2026.01.01 18:18:56.354 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000170, Val MSE=0.000298, Val MAE=0.013255, Val MedAE=0.011018, Bit_Fail=0
2026.01.01 18:19:12.392 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000170, Val MSE=0.000295, Val MAE=0.013216, Val MedAE=0.010940, Bit_Fail=0
2026.01.01 18:19:27.987 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000170, Val MSE=0.000293, Val MAE=0.013073, Val MedAE=0.010728, Bit_Fail=0
2026.01.01 18:19:32.327 1: SolCast DEBUG> Epoche 5030: Train MSE=0.000167, Val MSE=0.000297, Val MAE=0.012698, Val MedAE=0.009102, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:19:43.670 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000167, Val MSE=0.000298, Val MAE=0.013300, Val MedAE=0.010884, Bit_Fail=0
2026.01.01 18:19:59.190 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000167, Val MSE=0.000294, Val MAE=0.013167, Val MedAE=0.010790, Bit_Fail=0
2026.01.01 18:20:10.606 1: SolCast DEBUG> Epoche 5262: Train MSE=0.000166, Val MSE=0.000295, Val MAE=0.012677, Val MedAE=0.009089, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:20:16.409 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000166, Val MSE=0.000292, Val MAE=0.013247, Val MedAE=0.011177, Bit_Fail=0
2026.01.01 18:20:34.708 1: SolCast DEBUG> Epoche 5400: Train MSE=0.000166, Val MSE=0.000291, Val MAE=0.012964, Val MedAE=0.010392, Bit_Fail=0
2026.01.01 18:20:57.206 1: SolCast DEBUG> Epoche 5500: Train MSE=0.000166, Val MSE=0.000288, Val MAE=0.012996, Val MedAE=0.010552, Bit_Fail=0
2026.01.01 18:21:21.536 1: SolCast DEBUG> Epoche 5600: Train MSE=0.000166, Val MSE=0.000286, Val MAE=0.012927, Val MedAE=0.010610, Bit_Fail=0
2026.01.01 18:21:43.826 1: SolCast DEBUG> Epoche 5700: Train MSE=0.000166, Val MSE=0.000284, Val MAE=0.012811, Val MedAE=0.010111, Bit_Fail=0
2026.01.01 18:21:46.073 1: SolCast DEBUG> Epoche 5710: Train MSE=0.000164, Val MSE=0.000292, Val MAE=0.012617, Val MedAE=0.009052, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:22:05.636 1: SolCast DEBUG> Epoche 5800: Train MSE=0.000164, Val MSE=0.000311, Val MAE=0.013979, Val MedAE=0.012142, Bit_Fail=0
2026.01.01 18:22:28.019 1: SolCast DEBUG> Epoche 5900: Train MSE=0.000164, Val MSE=0.000284, Val MAE=0.012679, Val MedAE=0.009654, Bit_Fail=0
2026.01.01 18:22:44.531 1: SolCast DEBUG> Epoche 6000: Train MSE=0.000164, Val MSE=0.000333, Val MAE=0.014735, Val MedAE=0.013016, Bit_Fail=0
2026.01.01 18:23:00.239 1: SolCast DEBUG> Epoche 6100: Train MSE=0.000164, Val MSE=0.000286, Val MAE=0.012652, Val MedAE=0.009522, Bit_Fail=0
2026.01.01 18:23:16.145 1: SolCast DEBUG> Epoche 6200: Train MSE=0.000164, Val MSE=0.000283, Val MAE=0.012623, Val MedAE=0.009526, Bit_Fail=0
2026.01.01 18:23:31.970 1: SolCast DEBUG> Epoche 6300: Train MSE=0.000164, Val MSE=0.000294, Val MAE=0.013520, Val MedAE=0.011589, Bit_Fail=0
2026.01.01 18:23:48.995 1: SolCast DEBUG> Epoche 6400: Train MSE=0.000164, Val MSE=0.000290, Val MAE=0.013238, Val MedAE=0.011187, Bit_Fail=0
2026.01.01 18:24:04.958 1: SolCast DEBUG> Epoche 6500: Train MSE=0.000164, Val MSE=0.000283, Val MAE=0.013087, Val MedAE=0.011112, Bit_Fail=0
2026.01.01 18:24:20.473 1: SolCast DEBUG> Epoche 6600: Train MSE=0.000164, Val MSE=0.000291, Val MAE=0.012657, Val MedAE=0.009198, Bit_Fail=0
2026.01.01 18:24:35.890 1: SolCast DEBUG> Epoche 6700: Train MSE=0.000164, Val MSE=0.000290, Val MAE=0.013459, Val MedAE=0.011749, Bit_Fail=0
2026.01.01 18:24:52.891 1: SolCast DEBUG> Epoche 6800: Train MSE=0.000164, Val MSE=0.000289, Val MAE=0.013364, Val MedAE=0.011509, Bit_Fail=0
2026.01.01 18:25:08.802 1: SolCast DEBUG> Epoche 6900: Train MSE=0.000164, Val MSE=0.000283, Val MAE=0.013144, Val MedAE=0.011185, Bit_Fail=0
2026.01.01 18:25:24.371 1: SolCast DEBUG> Epoche 7000: Train MSE=0.000164, Val MSE=0.000278, Val MAE=0.012650, Val MedAE=0.009934, Bit_Fail=0
2026.01.01 18:25:39.968 1: SolCast DEBUG> Epoche 7100: Train MSE=0.000164, Val MSE=0.000320, Val MAE=0.014405, Val MedAE=0.012857, Bit_Fail=0
2026.01.01 18:25:56.650 1: SolCast DEBUG> Epoche 7200: Train MSE=0.000164, Val MSE=0.000281, Val MAE=0.013030, Val MedAE=0.011100, Bit_Fail=0
2026.01.01 18:26:12.530 1: SolCast DEBUG> Epoche 7300: Train MSE=0.000164, Val MSE=0.000277, Val MAE=0.012556, Val MedAE=0.009580, Bit_Fail=0
2026.01.01 18:26:28.387 1: SolCast DEBUG> Epoche 7400: Train MSE=0.000164, Val MSE=0.000275, Val MAE=0.012574, Val MedAE=0.009786, Bit_Fail=0
2026.01.01 18:26:44.426 1: SolCast DEBUG> Epoche 7500: Train MSE=0.000164, Val MSE=0.000282, Val MAE=0.013197, Val MedAE=0.011348, Bit_Fail=0
2026.01.01 18:27:00.108 1: SolCast DEBUG> Epoche 7600: Train MSE=0.000164, Val MSE=0.000279, Val MAE=0.012521, Val MedAE=0.009349, Bit_Fail=0
2026.01.01 18:27:17.631 1: SolCast DEBUG> Epoche 7700: Train MSE=0.000164, Val MSE=0.000334, Val MAE=0.014836, Val MedAE=0.013130, Bit_Fail=0
2026.01.01 18:27:19.201 1: SolCast DEBUG> Early stopping bei Epoche 7710 (no improvement since 2000 epochs)
2026.01.01 18:27:19.203 1: === Snapshot-Statistik ===
2026.01.01 18:27:19.206 1: Metric-Improvement Snapshots: 59 (letzte Epoche: 5710)
2026.01.01 18:27:19.208 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 153)
2026.01.01 18:27:19.211 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 18:27:19.222 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 5710: Train MSE=0.000164, Val MSE=0.000292, Val MAE=0.012617, Val MedAE=0.009052, Bit_Fail=0,
2026.01.01 18:27:19.225 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 18:27:19.269 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000164, Validation MSE=0.000292, Validation Bit_Fail=0
2026.01.01 18:27:19.272 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000164
Val MSE=0.000292
Val Mean=0.0003006352
VAL/TRAIN MSE Ratio=1.778317 (limit=2.5)
Diff=0.000128 (limit=0.005)
ValStd=0.0000223852 (limit=7.51588070934039e-05)
-- At Original Scale: --
MAE=207.818584965433
RMSE/MAE=1.3545 (limit=1.5)
Slope=0.930345 (limit=0.7 .. 1.3)
Bias=-1.81 (limit=+-103.909292482717)
R2=0.896675647742538
P95=565.7317 (limit=831.274339861732)
P99=813.5925 (limit=1662.54867972346)
-- Robustness Indicators: --
RMSE relative=60 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 18:27:19.280 1: SolCast DEBUG> Retry attempt 1 with Seed=16816002
2026.01.01 18:27:19.287 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 18:27:19.448 1: SolCast DEBUG> Epoche 1: Train MSE=0.002204, Val MSE=0.002840, Val MAE=0.031967, Val MedAE=0.027950, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 18:27:27.760 1: SolCast DEBUG> Epoche 55: Train MSE=0.001883, Val MSE=0.002825, Val MAE=0.030076, Val MedAE=0.017712, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:27.909 1: SolCast DEBUG> Epoche 56: Train MSE=0.001848, Val MSE=0.002787, Val MAE=0.029877, Val MedAE=0.017254, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:28.093 1: SolCast DEBUG> Epoche 57: Train MSE=0.001806, Val MSE=0.002742, Val MAE=0.029648, Val MedAE=0.016877, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:28.250 1: SolCast DEBUG> Epoche 58: Train MSE=0.001759, Val MSE=0.002690, Val MAE=0.029392, Val MedAE=0.016720, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:28.410 1: SolCast DEBUG> Epoche 59: Train MSE=0.001704, Val MSE=0.002632, Val MAE=0.029109, Val MedAE=0.016686, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:27:34.691 1: SolCast DEBUG> Epoche 100: Train MSE=0.001704, Val MSE=0.001681, Val MAE=0.026853, Val MedAE=0.019229, Bit_Fail=1
2026.01.01 18:27:39.980 1: SolCast DEBUG> Epoche 133: Train MSE=0.000733, Val MSE=0.001267, Val MAE=0.023793, Val MedAE=0.017436, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 18:27:40.226 1: SolCast DEBUG> Epoche 134: Train MSE=0.000722, Val MSE=0.001247, Val MAE=0.023624, Val MedAE=0.017294, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.470 1: SolCast DEBUG> Epoche 135: Train MSE=0.000710, Val MSE=0.001225, Val MAE=0.023450, Val MedAE=0.017111, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.655 1: SolCast DEBUG> Epoche 136: Train MSE=0.000698, Val MSE=0.001204, Val MAE=0.023271, Val MedAE=0.017081, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.821 1: SolCast DEBUG> Epoche 137: Train MSE=0.000686, Val MSE=0.001182, Val MAE=0.023085, Val MedAE=0.017060, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:40.979 1: SolCast DEBUG> Epoche 138: Train MSE=0.000674, Val MSE=0.001160, Val MAE=0.022895, Val MedAE=0.016883, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:41.140 1: SolCast DEBUG> Epoche 139: Train MSE=0.000661, Val MSE=0.001138, Val MAE=0.022701, Val MedAE=0.016711, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:41.929 1: SolCast DEBUG> Epoche 144: Train MSE=0.000598, Val MSE=0.000999, Val MAE=0.021734, Val MedAE=0.016540, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.090 1: SolCast DEBUG> Epoche 145: Train MSE=0.000586, Val MSE=0.000978, Val MAE=0.021522, Val MedAE=0.016349, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.280 1: SolCast DEBUG> Epoche 146: Train MSE=0.000574, Val MSE=0.000958, Val MAE=0.021306, Val MedAE=0.016107, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.459 1: SolCast DEBUG> Epoche 147: Train MSE=0.000562, Val MSE=0.000937, Val MAE=0.021088, Val MedAE=0.015901, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.613 1: SolCast DEBUG> Epoche 148: Train MSE=0.000550, Val MSE=0.000918, Val MAE=0.020870, Val MedAE=0.015669, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:42.760 1: SolCast DEBUG> Epoche 149: Train MSE=0.000539, Val MSE=0.000898, Val MAE=0.020654, Val MedAE=0.015555, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.090 1: SolCast DEBUG> Epoche 151: Train MSE=0.000519, Val MSE=0.000853, Val MAE=0.020213, Val MedAE=0.015324, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.274 1: SolCast DEBUG> Epoche 152: Train MSE=0.000508, Val MSE=0.000834, Val MAE=0.019989, Val MedAE=0.015218, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.427 1: SolCast DEBUG> Epoche 153: Train MSE=0.000498, Val MSE=0.000815, Val MAE=0.019775, Val MedAE=0.015098, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.588 1: SolCast DEBUG> Epoche 154: Train MSE=0.000489, Val MSE=0.000798, Val MAE=0.019572, Val MedAE=0.015089, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.765 1: SolCast DEBUG> Epoche 155: Train MSE=0.000480, Val MSE=0.000781, Val MAE=0.019377, Val MedAE=0.014943, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:43.922 1: SolCast DEBUG> Epoche 156: Train MSE=0.000471, Val MSE=0.000765, Val MAE=0.019192, Val MedAE=0.014814, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:44.099 1: SolCast DEBUG> Epoche 157: Train MSE=0.000463, Val MSE=0.000750, Val MAE=0.019017, Val MedAE=0.014635, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:44.451 1: SolCast DEBUG> Epoche 159: Train MSE=0.000448, Val MSE=0.000722, Val MAE=0.018698, Val MedAE=0.014553, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:27:45.216 1: SolCast DEBUG> Epoche 164: Train MSE=0.000417, Val MSE=0.000649, Val MAE=0.018205, Val MedAE=0.014516, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 18:27:45.399 1: SolCast DEBUG> Epoche 165: Train MSE=0.000412, Val MSE=0.000640, Val MAE=0.018099, Val MedAE=0.014421, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:45.558 1: SolCast DEBUG> Epoche 166: Train MSE=0.000407, Val MSE=0.000632, Val MAE=0.017999, Val MedAE=0.014286, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:45.726 1: SolCast DEBUG> Epoche 167: Train MSE=0.000402, Val MSE=0.000624, Val MAE=0.017906, Val MedAE=0.014177, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:45.885 1: SolCast DEBUG> Epoche 168: Train MSE=0.000398, Val MSE=0.000617, Val MAE=0.017820, Val MedAE=0.014094, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:46.051 1: SolCast DEBUG> Epoche 169: Train MSE=0.000394, Val MSE=0.000610, Val MAE=0.017740, Val MedAE=0.014051, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:50.636 1: SolCast DEBUG> Epoche 200: Train MSE=0.000394, Val MSE=0.000539, Val MAE=0.016987, Val MedAE=0.013961, Bit_Fail=0
2026.01.01 18:27:50.644 1: SolCast DEBUG> Epoche 200: Train MSE=0.000340, Val MSE=0.000539, Val MAE=0.016987, Val MedAE=0.013961, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:51.095 1: SolCast DEBUG> Epoche 203: Train MSE=0.000338, Val MSE=0.000538, Val MAE=0.016940, Val MedAE=0.013888, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:27:55.790 1: SolCast DEBUG> Epoche 233: Train MSE=0.000321, Val MSE=0.000535, Val MAE=0.016852, Val MedAE=0.013875, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:03.726 1: SolCast DEBUG> Epoche 281: Train MSE=0.000308, Val MSE=0.000524, Val MAE=0.016435, Val MedAE=0.013831, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:04.363 1: SolCast DEBUG> Epoche 285: Train MSE=0.000307, Val MSE=0.000523, Val MAE=0.016426, Val MedAE=0.013765, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:06.794 1: SolCast DEBUG> Epoche 300: Train MSE=0.000307, Val MSE=0.000550, Val MAE=0.017907, Val MedAE=0.015240, Bit_Fail=0
2026.01.01 18:28:08.309 1: SolCast DEBUG> Epoche 310: Train MSE=0.000306, Val MSE=0.000520, Val MAE=0.016274, Val MedAE=0.013632, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:08.614 1: SolCast DEBUG> Epoche 312: Train MSE=0.000305, Val MSE=0.000519, Val MAE=0.016257, Val MedAE=0.013585, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:09.360 1: SolCast DEBUG> Epoche 317: Train MSE=0.000304, Val MSE=0.000518, Val MAE=0.016235, Val MedAE=0.013539, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:18.741 1: SolCast DEBUG> Epoche 370: Train MSE=0.000293, Val MSE=0.000514, Val MAE=0.016166, Val MedAE=0.013205, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:23.398 1: SolCast DEBUG> Epoche 400: Train MSE=0.000293, Val MSE=0.000498, Val MAE=0.016166, Val MedAE=0.013530, Bit_Fail=0
2026.01.01 18:28:27.156 1: SolCast DEBUG> Epoche 420: Train MSE=0.000286, Val MSE=0.000497, Val MAE=0.015836, Val MedAE=0.012658, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:27.956 1: SolCast DEBUG> Epoche 424: Train MSE=0.000286, Val MSE=0.000496, Val MAE=0.015803, Val MedAE=0.012630, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:28.927 1: SolCast DEBUG> Epoche 429: Train MSE=0.000285, Val MSE=0.000495, Val MAE=0.015779, Val MedAE=0.012568, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:37.533 1: SolCast DEBUG> Epoche 470: Train MSE=0.000278, Val MSE=0.000490, Val MAE=0.015754, Val MedAE=0.012467, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:44.668 1: SolCast DEBUG> Epoche 500: Train MSE=0.000278, Val MSE=0.000512, Val MAE=0.015775, Val MedAE=0.011966, Bit_Fail=0
2026.01.01 18:28:49.391 1: SolCast DEBUG> Epoche 520: Train MSE=0.000270, Val MSE=0.000477, Val MAE=0.015651, Val MedAE=0.012339, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:28:53.585 1: SolCast DEBUG> Epoche 539: Train MSE=0.000270, Val MSE=0.000475, Val MAE=0.015648, Val MedAE=0.012191, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:05.842 1: SolCast DEBUG> Epoche 590: Train MSE=0.000265, Val MSE=0.000474, Val MAE=0.015526, Val MedAE=0.012056, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:08.065 1: SolCast DEBUG> Epoche 600: Train MSE=0.000265, Val MSE=0.000468, Val MAE=0.015894, Val MedAE=0.012751, Bit_Fail=0
2026.01.01 18:29:28.474 1: SolCast DEBUG> Epoche 690: Train MSE=0.000256, Val MSE=0.000470, Val MAE=0.015276, Val MedAE=0.011856, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:30.383 1: SolCast DEBUG> Epoche 699: Train MSE=0.000255, Val MSE=0.000467, Val MAE=0.015250, Val MedAE=0.011836, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:29:30.639 1: SolCast DEBUG> Epoche 700: Train MSE=0.000255, Val MSE=0.000478, Val MAE=0.016548, Val MedAE=0.013898, Bit_Fail=0
2026.01.01 18:29:52.830 1: SolCast DEBUG> Epoche 800: Train MSE=0.000255, Val MSE=0.000465, Val MAE=0.016306, Val MedAE=0.013391, Bit_Fail=0
2026.01.01 18:30:04.934 1: SolCast DEBUG> Epoche 850: Train MSE=0.000244, Val MSE=0.000461, Val MAE=0.015129, Val MedAE=0.011815, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:30:17.777 1: SolCast DEBUG> Epoche 900: Train MSE=0.000244, Val MSE=0.000448, Val MAE=0.015585, Val MedAE=0.012575, Bit_Fail=0
2026.01.01 18:30:40.850 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000244, Val MSE=0.000450, Val MAE=0.015295, Val MedAE=0.012324, Bit_Fail=0
2026.01.01 18:30:56.457 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000244, Val MSE=0.000443, Val MAE=0.015695, Val MedAE=0.012932, Bit_Fail=0
2026.01.01 18:31:07.100 1: SolCast DEBUG> Epoche 1160: Train MSE=0.000229, Val MSE=0.000432, Val MAE=0.014957, Val MedAE=0.011802, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:31:13.278 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000229, Val MSE=0.000439, Val MAE=0.015822, Val MedAE=0.012868, Bit_Fail=0
2026.01.01 18:31:29.055 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000229, Val MSE=0.000435, Val MAE=0.015613, Val MedAE=0.012747, Bit_Fail=0
2026.01.01 18:31:43.689 1: SolCast DEBUG> Epoche 1390: Train MSE=0.000219, Val MSE=0.000426, Val MAE=0.014936, Val MedAE=0.011470, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:31:45.625 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000219, Val MSE=0.000414, Val MAE=0.014586, Val MedAE=0.011035, Bit_Fail=0
2026.01.01 18:31:45.635 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000218, Val MSE=0.000414, Val MAE=0.014586, Val MedAE=0.011035, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:32:02.161 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000218, Val MSE=0.000449, Val MAE=0.016432, Val MedAE=0.013464, Bit_Fail=0
2026.01.01 18:32:18.086 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000218, Val MSE=0.000403, Val MAE=0.014934, Val MedAE=0.011695, Bit_Fail=0
2026.01.01 18:32:32.114 1: SolCast DEBUG> Epoche 1690: Train MSE=0.000209, Val MSE=0.000404, Val MAE=0.014320, Val MedAE=0.010320, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:32:33.832 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000209, Val MSE=0.000428, Val MAE=0.016037, Val MedAE=0.012994, Bit_Fail=0
2026.01.01 18:32:49.865 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000209, Val MSE=0.000410, Val MAE=0.015653, Val MedAE=0.012577, Bit_Fail=0
2026.01.01 18:33:02.182 1: SolCast DEBUG> Epoche 1870: Train MSE=0.000205, Val MSE=0.000383, Val MAE=0.014067, Val MedAE=0.010133, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:33:06.890 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000205, Val MSE=0.000376, Val MAE=0.014446, Val MedAE=0.011115, Bit_Fail=0
2026.01.01 18:33:22.858 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000205, Val MSE=0.000368, Val MAE=0.014258, Val MedAE=0.010752, Bit_Fail=0
2026.01.01 18:33:38.578 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000205, Val MSE=0.000440, Val MAE=0.016680, Val MedAE=0.014515, Bit_Fail=0
2026.01.01 18:33:41.611 1: SolCast DEBUG> Epoche 2120: Train MSE=0.000198, Val MSE=0.000367, Val MAE=0.013801, Val MedAE=0.009661, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:33:54.354 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000198, Val MSE=0.000417, Val MAE=0.016140, Val MedAE=0.013713, Bit_Fail=0
2026.01.01 18:34:11.686 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000198, Val MSE=0.000362, Val MAE=0.014348, Val MedAE=0.010921, Bit_Fail=0
2026.01.01 18:34:18.148 1: SolCast DEBUG> Epoche 2340: Train MSE=0.000195, Val MSE=0.000356, Val MAE=0.013592, Val MedAE=0.009300, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:34:27.489 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000195, Val MSE=0.000355, Val MAE=0.014051, Val MedAE=0.010411, Bit_Fail=0
2026.01.01 18:34:43.305 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000195, Val MSE=0.000349, Val MAE=0.013577, Val MedAE=0.009666, Bit_Fail=0
2026.01.01 18:34:58.973 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000195, Val MSE=0.000377, Val MAE=0.015170, Val MedAE=0.012456, Bit_Fail=0
2026.01.01 18:35:15.415 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000195, Val MSE=0.000340, Val MAE=0.013970, Val MedAE=0.010876, Bit_Fail=0
2026.01.01 18:35:32.017 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000195, Val MSE=0.000382, Val MAE=0.015341, Val MedAE=0.012854, Bit_Fail=0
2026.01.01 18:35:47.827 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000195, Val MSE=0.000328, Val MAE=0.013411, Val MedAE=0.009790, Bit_Fail=0
2026.01.01 18:35:52.375 1: SolCast DEBUG> Epoche 2931: Train MSE=0.000186, Val MSE=0.000331, Val MAE=0.013276, Val MedAE=0.009297, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:04.885 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000186, Val MSE=0.000333, Val MAE=0.013785, Val MedAE=0.010478, Bit_Fail=0
2026.01.01 18:36:20.725 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000186, Val MSE=0.000329, Val MAE=0.013228, Val MedAE=0.009287, Bit_Fail=0
2026.01.01 18:36:20.735 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000184, Val MSE=0.000329, Val MAE=0.013228, Val MedAE=0.009287, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:34.489 1: SolCast DEBUG> Epoche 3180: Train MSE=0.000182, Val MSE=0.000327, Val MAE=0.013125, Val MedAE=0.008939, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:38.029 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000182, Val MSE=0.000320, Val MAE=0.013228, Val MedAE=0.009632, Bit_Fail=0
2026.01.01 18:36:45.842 1: SolCast DEBUG> Epoche 3250: Train MSE=0.000183, Val MSE=0.000323, Val MAE=0.013096, Val MedAE=0.008886, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:36:53.303 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000183, Val MSE=0.000320, Val MAE=0.013318, Val MedAE=0.009760, Bit_Fail=0
2026.01.01 18:37:09.545 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000183, Val MSE=0.000327, Val MAE=0.013922, Val MedAE=0.011272, Bit_Fail=0
2026.01.01 18:37:24.189 1: SolCast DEBUG> Epoche 3490: Train MSE=0.000180, Val MSE=0.000319, Val MAE=0.013041, Val MedAE=0.008820, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:37:25.723 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000180, Val MSE=0.000323, Val MAE=0.013588, Val MedAE=0.010386, Bit_Fail=0
2026.01.01 18:37:47.590 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000180, Val MSE=0.000323, Val MAE=0.013730, Val MedAE=0.010947, Bit_Fail=0
2026.01.01 18:37:53.258 1: SolCast DEBUG> Epoche 3630: Train MSE=0.000178, Val MSE=0.000318, Val MAE=0.012948, Val MedAE=0.008677, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:38:09.034 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000178, Val MSE=0.000312, Val MAE=0.013378, Val MedAE=0.010497, Bit_Fail=0
2026.01.01 18:38:30.192 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000178, Val MSE=0.000312, Val MAE=0.013379, Val MedAE=0.010674, Bit_Fail=0
2026.01.01 18:38:52.224 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000178, Val MSE=0.000318, Val MAE=0.012933, Val MedAE=0.008471, Bit_Fail=0
2026.01.01 18:39:13.603 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000178, Val MSE=0.000306, Val MAE=0.013228, Val MedAE=0.010395, Bit_Fail=0
2026.01.01 18:39:34.047 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000178, Val MSE=0.000318, Val MAE=0.013793, Val MedAE=0.011333, Bit_Fail=0
2026.01.01 18:39:54.812 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000178, Val MSE=0.000309, Val MAE=0.013388, Val MedAE=0.010831, Bit_Fail=0
2026.01.01 18:40:02.202 1: SolCast DEBUG> Epoche 4230: Train MSE=0.000175, Val MSE=0.000309, Val MAE=0.012845, Val MedAE=0.008584, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:40:16.021 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000175, Val MSE=0.000303, Val MAE=0.013012, Val MedAE=0.009822, Bit_Fail=0
2026.01.01 18:40:34.355 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000175, Val MSE=0.000310, Val MAE=0.012884, Val MedAE=0.008766, Bit_Fail=0
2026.01.01 18:40:57.218 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000175, Val MSE=0.000302, Val MAE=0.013128, Val MedAE=0.010345, Bit_Fail=0
2026.01.01 18:41:22.220 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000175, Val MSE=0.000302, Val MAE=0.013191, Val MedAE=0.010385, Bit_Fail=0
2026.01.01 18:41:43.986 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000175, Val MSE=0.000301, Val MAE=0.013269, Val MedAE=0.010709, Bit_Fail=0
2026.01.01 18:42:05.591 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000175, Val MSE=0.000327, Val MAE=0.012984, Val MedAE=0.008358, Bit_Fail=0
2026.01.01 18:42:28.817 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000175, Val MSE=0.000300, Val MAE=0.013196, Val MedAE=0.010534, Bit_Fail=0
2026.01.01 18:42:51.092 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000175, Val MSE=0.000298, Val MAE=0.013025, Val MedAE=0.010142, Bit_Fail=0
2026.01.01 18:43:13.597 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000175, Val MSE=0.000296, Val MAE=0.012895, Val MedAE=0.009981, Bit_Fail=0
2026.01.01 18:43:36.900 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000175, Val MSE=0.000298, Val MAE=0.012955, Val MedAE=0.009983, Bit_Fail=0
2026.01.01 18:43:58.243 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000175, Val MSE=0.000305, Val MAE=0.013474, Val MedAE=0.010999, Bit_Fail=0
2026.01.01 18:44:20.399 1: SolCast DEBUG> Epoche 5400: Train MSE=0.000175, Val MSE=0.000296, Val MAE=0.012941, Val MedAE=0.009892, Bit_Fail=0
2026.01.01 18:44:37.326 1: SolCast DEBUG> Epoche 5500: Train MSE=0.000175, Val MSE=0.000301, Val MAE=0.013345, Val MedAE=0.010900, Bit_Fail=0
2026.01.01 18:44:53.049 1: SolCast DEBUG> Epoche 5600: Train MSE=0.000175, Val MSE=0.000297, Val MAE=0.012997, Val MedAE=0.010176, Bit_Fail=0
2026.01.01 18:45:10.274 1: SolCast DEBUG> Epoche 5700: Train MSE=0.000175, Val MSE=0.000303, Val MAE=0.013484, Val MedAE=0.011050, Bit_Fail=0
2026.01.01 18:45:27.329 1: SolCast DEBUG> Epoche 5800: Train MSE=0.000175, Val MSE=0.000300, Val MAE=0.013419, Val MedAE=0.011095, Bit_Fail=0
2026.01.01 18:45:42.673 1: SolCast DEBUG> Epoche 5900: Train MSE=0.000175, Val MSE=0.000295, Val MAE=0.013058, Val MedAE=0.010464, Bit_Fail=0
2026.01.01 18:45:59.007 1: SolCast DEBUG> Epoche 6000: Train MSE=0.000175, Val MSE=0.000299, Val MAE=0.012793, Val MedAE=0.009330, Bit_Fail=0
2026.01.01 18:46:14.775 1: SolCast DEBUG> Epoche 6100: Train MSE=0.000175, Val MSE=0.000294, Val MAE=0.013040, Val MedAE=0.010396, Bit_Fail=0
2026.01.01 18:46:29.912 1: SolCast DEBUG> Epoche 6200: Train MSE=0.000175, Val MSE=0.000305, Val MAE=0.013656, Val MedAE=0.011383, Bit_Fail=0
2026.01.01 18:46:34.543 1: SolCast DEBUG> Early stopping bei Epoche 6230 (no improvement since 2000 epochs)
2026.01.01 18:46:34.546 1: === Snapshot-Statistik ===
2026.01.01 18:46:34.547 1: Metric-Improvement Snapshots: 63 (letzte Epoche: 4230)
2026.01.01 18:46:34.549 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 164)
2026.01.01 18:46:34.552 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 18:46:34.559 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 4230: Train MSE=0.000175, Val MSE=0.000309, Val MAE=0.012845, Val MedAE=0.008584, Bit_Fail=0,
2026.01.01 18:46:34.561 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 18:46:34.602 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000175, Validation MSE=0.000309, Validation Bit_Fail=0
2026.01.01 18:46:34.605 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000175
Val MSE=0.000309
Val Mean=0.0003042089
VAL/TRAIN MSE Ratio=1.763249 (limit=2.5)
Diff=0.000134 (limit=0.005)
ValStd=0.0000076839 (limit=7.60522365479913e-05)
-- At Original Scale: --
MAE=211.576764064665
RMSE/MAE=1.3694 (limit=1.5)
Slope=0.935893 (limit=0.7 .. 1.3)
Bias=4.36 (limit=+-105.788382032332)
R2=0.890528595577006
P95=585.8856 (limit=846.307056258658)
P99=968.7970 (limit=1692.61411251732)
-- Robustness Indicators: --
RMSE relative=62 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 18:46:34.613 1: SolCast DEBUG> Retry attempt 2 with Seed=16325084
2026.01.01 18:46:34.619 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 18:46:34.804 1: SolCast DEBUG> Epoche 1: Train MSE=0.002232, Val MSE=0.002836, Val MAE=0.031928, Val MedAE=0.027901, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 18:46:35.250 1: SolCast DEBUG> Epoche 4: Train MSE=0.002191, Val MSE=0.002835, Val MAE=0.031923, Val MedAE=0.027895, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:35.703 1: SolCast DEBUG> Epoche 7: Train MSE=0.002187, Val MSE=0.002834, Val MAE=0.031919, Val MedAE=0.027892, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:42.846 1: SolCast DEBUG> Epoche 54: Train MSE=0.002012, Val MSE=0.002830, Val MAE=0.030056, Val MedAE=0.024398, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:42.997 1: SolCast DEBUG> Epoche 55: Train MSE=0.001999, Val MSE=0.002816, Val MAE=0.029980, Val MedAE=0.024096, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.151 1: SolCast DEBUG> Epoche 56: Train MSE=0.001984, Val MSE=0.002799, Val MAE=0.029892, Val MedAE=0.023790, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.302 1: SolCast DEBUG> Epoche 57: Train MSE=0.001966, Val MSE=0.002780, Val MAE=0.029791, Val MedAE=0.023427, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.459 1: SolCast DEBUG> Epoche 58: Train MSE=0.001945, Val MSE=0.002756, Val MAE=0.029676, Val MedAE=0.022958, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:43.623 1: SolCast DEBUG> Epoche 59: Train MSE=0.001920, Val MSE=0.002728, Val MAE=0.029540, Val MedAE=0.022374, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:44.667 1: SolCast DEBUG> Epoche 65: Train MSE=0.001639, Val MSE=0.002678, Val MAE=0.029156, Val MedAE=0.016122, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 18:46:50.165 1: SolCast DEBUG> Epoche 100: Train MSE=0.001639, Val MSE=0.001617, Val MAE=0.027389, Val MedAE=0.021329, Bit_Fail=1
2026.01.01 18:46:57.117 1: SolCast DEBUG> Epoche 140: Train MSE=0.000582, Val MSE=0.000982, Val MAE=0.021762, Val MedAE=0.016481, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 18:46:57.374 1: SolCast DEBUG> Epoche 141: Train MSE=0.000571, Val MSE=0.000963, Val MAE=0.021553, Val MedAE=0.016314, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:57.625 1: SolCast DEBUG> Epoche 142: Train MSE=0.000559, Val MSE=0.000944, Val MAE=0.021340, Val MedAE=0.015998, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:57.814 1: SolCast DEBUG> Epoche 143: Train MSE=0.000548, Val MSE=0.000925, Val MAE=0.021128, Val MedAE=0.015847, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.048 1: SolCast DEBUG> Epoche 144: Train MSE=0.000537, Val MSE=0.000906, Val MAE=0.020921, Val MedAE=0.015525, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.217 1: SolCast DEBUG> Epoche 145: Train MSE=0.000526, Val MSE=0.000888, Val MAE=0.020716, Val MedAE=0.015427, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.387 1: SolCast DEBUG> Epoche 146: Train MSE=0.000516, Val MSE=0.000871, Val MAE=0.020515, Val MedAE=0.015357, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.797 1: SolCast DEBUG> Epoche 148: Train MSE=0.000497, Val MSE=0.000838, Val MAE=0.020132, Val MedAE=0.015318, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:58.986 1: SolCast DEBUG> Epoche 149: Train MSE=0.000488, Val MSE=0.000822, Val MAE=0.019953, Val MedAE=0.015200, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.141 1: SolCast DEBUG> Epoche 150: Train MSE=0.000482, Val MSE=0.000817, Val MAE=0.019792, Val MedAE=0.015107, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.316 1: SolCast DEBUG> Epoche 151: Train MSE=0.000474, Val MSE=0.000802, Val MAE=0.019630, Val MedAE=0.014972, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.471 1: SolCast DEBUG> Epoche 152: Train MSE=0.000466, Val MSE=0.000788, Val MAE=0.019477, Val MedAE=0.014905, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.637 1: SolCast DEBUG> Epoche 153: Train MSE=0.000459, Val MSE=0.000775, Val MAE=0.019332, Val MedAE=0.014836, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.795 1: SolCast DEBUG> Epoche 154: Train MSE=0.000452, Val MSE=0.000763, Val MAE=0.019196, Val MedAE=0.014833, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:46:59.953 1: SolCast DEBUG> Epoche 155: Train MSE=0.000446, Val MSE=0.000751, Val MAE=0.019068, Val MedAE=0.014766, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.128 1: SolCast DEBUG> Epoche 156: Train MSE=0.000440, Val MSE=0.000740, Val MAE=0.018949, Val MedAE=0.014751, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.423 1: SolCast DEBUG> Epoche 157: Train MSE=0.000434, Val MSE=0.000729, Val MAE=0.018837, Val MedAE=0.014571, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.580 1: SolCast DEBUG> Epoche 158: Train MSE=0.000429, Val MSE=0.000719, Val MAE=0.018732, Val MedAE=0.014399, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 18:47:00.738 1: SolCast DEBUG> Epoche 159: Train MSE=0.000423, Val MSE=0.000710, Val MAE=0.018632, Val MedAE=0.014296, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 18:47:04.664 1: SolCast DEBUG> Epoche 185: Train MSE=0.000352, Val MSE=0.000570, Val MAE=0.017726, Val MedAE=0.014241, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:04.823 1: SolCast DEBUG> Epoche 186: Train MSE=0.000351, Val MSE=0.000568, Val MAE=0.017700, Val MedAE=0.014157, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:04.998 1: SolCast DEBUG> Epoche 187: Train MSE=0.000350, Val MSE=0.000567, Val MAE=0.017676, Val MedAE=0.014128, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:05.330 1: SolCast DEBUG> Epoche 189: Train MSE=0.000347, Val MSE=0.000565, Val MAE=0.017630, Val MedAE=0.014111, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:07.326 1: SolCast DEBUG> Epoche 200: Train MSE=0.000347, Val MSE=0.000560, Val MAE=0.017645, Val MedAE=0.014294, Bit_Fail=0
2026.01.01 18:47:08.430 1: SolCast DEBUG> Epoche 207: Train MSE=0.000336, Val MSE=0.000557, Val MAE=0.017581, Val MedAE=0.014098, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:08.925 1: SolCast DEBUG> Epoche 210: Train MSE=0.000332, Val MSE=0.000551, Val MAE=0.017149, Val MedAE=0.014015, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:09.251 1: SolCast DEBUG> Epoche 212: Train MSE=0.000331, Val MSE=0.000549, Val MAE=0.017106, Val MedAE=0.014013, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:09.543 1: SolCast DEBUG> Epoche 214: Train MSE=0.000330, Val MSE=0.000548, Val MAE=0.017079, Val MedAE=0.014009, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:19.704 1: SolCast DEBUG> Epoche 280: Train MSE=0.000312, Val MSE=0.000539, Val MAE=0.016444, Val MedAE=0.013594, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:22.914 1: SolCast DEBUG> Epoche 300: Train MSE=0.000312, Val MSE=0.000547, Val MAE=0.017776, Val MedAE=0.014873, Bit_Fail=0
2026.01.01 18:47:36.920 1: SolCast DEBUG> Epoche 390: Train MSE=0.000299, Val MSE=0.000534, Val MAE=0.016256, Val MedAE=0.013227, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:37.075 1: SolCast DEBUG> Epoche 391: Train MSE=0.000299, Val MSE=0.000533, Val MAE=0.016248, Val MedAE=0.013207, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:37.692 1: SolCast DEBUG> Epoche 395: Train MSE=0.000298, Val MSE=0.000532, Val MAE=0.016231, Val MedAE=0.013184, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:38.408 1: SolCast DEBUG> Epoche 400: Train MSE=0.000298, Val MSE=0.000533, Val MAE=0.016139, Val MedAE=0.013128, Bit_Fail=0
2026.01.01 18:47:43.011 1: SolCast DEBUG> Epoche 430: Train MSE=0.000294, Val MSE=0.000524, Val MAE=0.016053, Val MedAE=0.013160, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:47:53.755 1: SolCast DEBUG> Epoche 500: Train MSE=0.000294, Val MSE=0.000533, Val MAE=0.017601, Val MedAE=0.015372, Bit_Fail=0
2026.01.01 18:48:03.268 1: SolCast DEBUG> Epoche 560: Train MSE=0.000278, Val MSE=0.000499, Val MAE=0.015935, Val MedAE=0.013052, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:48:10.654 1: SolCast DEBUG> Epoche 600: Train MSE=0.000278, Val MSE=0.000497, Val MAE=0.016063, Val MedAE=0.013071, Bit_Fail=0
2026.01.01 18:48:17.120 1: SolCast DEBUG> Epoche 640: Train MSE=0.000270, Val MSE=0.000494, Val MAE=0.015925, Val MedAE=0.012746, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:48:26.254 1: SolCast DEBUG> Epoche 700: Train MSE=0.000270, Val MSE=0.000494, Val MAE=0.016121, Val MedAE=0.012865, Bit_Fail=0
2026.01.01 18:48:41.338 1: SolCast DEBUG> Epoche 800: Train MSE=0.000270, Val MSE=0.000496, Val MAE=0.016486, Val MedAE=0.013111, Bit_Fail=0
2026.01.01 18:48:50.270 1: SolCast DEBUG> Epoche 860: Train MSE=0.000251, Val MSE=0.000491, Val MAE=0.015786, Val MedAE=0.012241, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:48:56.298 1: SolCast DEBUG> Epoche 900: Train MSE=0.000251, Val MSE=0.000539, Val MAE=0.017781, Val MedAE=0.014813, Bit_Fail=0
2026.01.01 18:49:00.767 1: openMeteo - Open-Meteo API server response: start_SSL https://api.open-meteo.com:443 timed out
2026.01.01 18:49:11.666 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000251, Val MSE=0.000487, Val MAE=0.015740, Val MedAE=0.012296, Bit_Fail=0
2026.01.01 18:49:28.665 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000251, Val MSE=0.000491, Val MAE=0.015728, Val MedAE=0.012462, Bit_Fail=0
2026.01.01 18:49:39.207 1: SolCast DEBUG> Epoche 1168: Train MSE=0.000235, Val MSE=0.000479, Val MAE=0.015557, Val MedAE=0.012237, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:49:44.096 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000235, Val MSE=0.000477, Val MAE=0.015613, Val MedAE=0.012266, Bit_Fail=0
2026.01.01 18:49:59.330 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000235, Val MSE=0.000469, Val MAE=0.015970, Val MedAE=0.012473, Bit_Fail=0
2026.01.01 18:50:02.607 1: SolCast DEBUG> Epoche 1320: Train MSE=0.000230, Val MSE=0.000474, Val MAE=0.015490, Val MedAE=0.011887, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:50:15.063 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000230, Val MSE=0.000469, Val MAE=0.016083, Val MedAE=0.012479, Bit_Fail=0
2026.01.01 18:50:31.357 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000230, Val MSE=0.000461, Val MAE=0.015731, Val MedAE=0.012435, Bit_Fail=0
2026.01.01 18:50:43.405 1: SolCast DEBUG> Epoche 1570: Train MSE=0.000219, Val MSE=0.000452, Val MAE=0.015217, Val MedAE=0.011832, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:50:48.687 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000219, Val MSE=0.000452, Val MAE=0.015676, Val MedAE=0.012380, Bit_Fail=0
2026.01.01 18:51:00.785 1: SolCast DEBUG> Epoche 1680: Train MSE=0.000216, Val MSE=0.000447, Val MAE=0.015153, Val MedAE=0.011761, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:02.263 1: SolCast DEBUG> Epoche 1690: Train MSE=0.000215, Val MSE=0.000446, Val MAE=0.015014, Val MedAE=0.011740, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:03.808 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000215, Val MSE=0.000444, Val MAE=0.015548, Val MedAE=0.012346, Bit_Fail=0
2026.01.01 18:51:19.267 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000215, Val MSE=0.000456, Val MAE=0.016255, Val MedAE=0.012272, Bit_Fail=0
2026.01.01 18:51:28.478 1: SolCast DEBUG> Epoche 1860: Train MSE=0.000211, Val MSE=0.000430, Val MAE=0.014967, Val MedAE=0.011675, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:32.128 1: SolCast DEBUG> Epoche 1885: Train MSE=0.000210, Val MSE=0.000429, Val MAE=0.014936, Val MedAE=0.011634, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:34.991 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000210, Val MSE=0.000431, Val MAE=0.015557, Val MedAE=0.012006, Bit_Fail=0
2026.01.01 18:51:36.961 1: SolCast DEBUG> Epoche 1910: Train MSE=0.000209, Val MSE=0.000427, Val MAE=0.014927, Val MedAE=0.011633, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:44.135 1: SolCast DEBUG> Epoche 1950: Train MSE=0.000207, Val MSE=0.000425, Val MAE=0.014852, Val MedAE=0.011568, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:51:51.659 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000207, Val MSE=0.000419, Val MAE=0.015028, Val MedAE=0.011705, Bit_Fail=0
2026.01.01 18:52:07.280 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000207, Val MSE=0.000419, Val MAE=0.015127, Val MedAE=0.011801, Bit_Fail=0
2026.01.01 18:52:22.353 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000207, Val MSE=0.000409, Val MAE=0.014933, Val MedAE=0.011578, Bit_Fail=0
2026.01.01 18:52:25.518 1: SolCast DEBUG> Epoche 2220: Train MSE=0.000201, Val MSE=0.000401, Val MAE=0.014505, Val MedAE=0.011123, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:52:38.140 1: SolCast DEBUG> Epoche 2280: Train MSE=0.000200, Val MSE=0.000398, Val MAE=0.014426, Val MedAE=0.010998, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:52:40.466 1: SolCast DEBUG> Epoche 2290: Train MSE=0.000199, Val MSE=0.000397, Val MAE=0.014408, Val MedAE=0.010918, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:52:42.754 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000199, Val MSE=0.000395, Val MAE=0.014771, Val MedAE=0.011372, Bit_Fail=0
2026.01.01 18:53:06.020 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000199, Val MSE=0.000386, Val MAE=0.014179, Val MedAE=0.010473, Bit_Fail=0
2026.01.01 18:53:06.031 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000196, Val MSE=0.000386, Val MAE=0.014179, Val MedAE=0.010473, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:53:27.648 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000196, Val MSE=0.000394, Val MAE=0.015055, Val MedAE=0.011719, Bit_Fail=0
2026.01.01 18:53:48.669 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000196, Val MSE=0.000393, Val MAE=0.015223, Val MedAE=0.011833, Bit_Fail=0
2026.01.01 18:54:04.615 1: SolCast DEBUG> Epoche 2670: Train MSE=0.000190, Val MSE=0.000363, Val MAE=0.014023, Val MedAE=0.010343, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:10.539 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000190, Val MSE=0.000399, Val MAE=0.015520, Val MedAE=0.012166, Bit_Fail=0
2026.01.01 18:54:22.630 1: SolCast DEBUG> Epoche 2762: Train MSE=0.000188, Val MSE=0.000359, Val MAE=0.014009, Val MedAE=0.010303, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:28.642 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000188, Val MSE=0.000422, Val MAE=0.016216, Val MedAE=0.013541, Bit_Fail=0
2026.01.01 18:54:36.250 1: SolCast DEBUG> Epoche 2850: Train MSE=0.000187, Val MSE=0.000356, Val MAE=0.013892, Val MedAE=0.010014, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:37.817 1: SolCast DEBUG> Epoche 2860: Train MSE=0.000186, Val MSE=0.000353, Val MAE=0.013781, Val MedAE=0.009785, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:43.894 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000186, Val MSE=0.000373, Val MAE=0.014968, Val MedAE=0.011754, Bit_Fail=0
2026.01.01 18:54:51.665 1: SolCast DEBUG> Epoche 2950: Train MSE=0.000184, Val MSE=0.000350, Val MAE=0.013709, Val MedAE=0.009744, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:56.355 1: SolCast DEBUG> Epoche 2980: Train MSE=0.000185, Val MSE=0.000344, Val MAE=0.013542, Val MedAE=0.009640, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:54:59.391 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000185, Val MSE=0.000345, Val MAE=0.013771, Val MedAE=0.010299, Bit_Fail=0
2026.01.01 18:55:15.914 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000185, Val MSE=0.000338, Val MAE=0.013390, Val MedAE=0.009239, Bit_Fail=0
2026.01.01 18:55:15.920 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000183, Val MSE=0.000338, Val MAE=0.013390, Val MedAE=0.009239, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:55:31.223 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000183, Val MSE=0.000374, Val MAE=0.015348, Val MedAE=0.013113, Bit_Fail=0
2026.01.01 18:55:46.650 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000183, Val MSE=0.000395, Val MAE=0.015892, Val MedAE=0.013867, Bit_Fail=0
2026.01.01 18:55:55.663 1: SolCast DEBUG> Epoche 3360: Train MSE=0.000178, Val MSE=0.000336, Val MAE=0.013102, Val MedAE=0.009038, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:55:57.156 1: SolCast DEBUG> Epoche 3370: Train MSE=0.000178, Val MSE=0.000328, Val MAE=0.013027, Val MedAE=0.008576, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 18:56:01.837 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000178, Val MSE=0.000331, Val MAE=0.013966, Val MedAE=0.010989, Bit_Fail=0
2026.01.01 18:56:18.127 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000178, Val MSE=0.000317, Val MAE=0.013546, Val MedAE=0.010578, Bit_Fail=0
2026.01.01 18:56:33.705 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000178, Val MSE=0.000326, Val MAE=0.013924, Val MedAE=0.011087, Bit_Fail=0
2026.01.01 18:56:49.380 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000178, Val MSE=0.000313, Val MAE=0.013647, Val MedAE=0.011350, Bit_Fail=0
2026.01.01 18:57:04.360 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000178, Val MSE=0.000315, Val MAE=0.013759, Val MedAE=0.011353, Bit_Fail=0
2026.01.01 18:57:20.079 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000178, Val MSE=0.000317, Val MAE=0.013889, Val MedAE=0.011544, Bit_Fail=0
2026.01.01 18:57:36.568 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000178, Val MSE=0.000303, Val MAE=0.013266, Val MedAE=0.010514, Bit_Fail=0
2026.01.01 18:57:51.815 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000178, Val MSE=0.000297, Val MAE=0.013051, Val MedAE=0.010491, Bit_Fail=0
2026.01.01 18:58:07.665 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000178, Val MSE=0.000298, Val MAE=0.013165, Val MedAE=0.010657, Bit_Fail=0
2026.01.01 18:58:22.874 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000178, Val MSE=0.000299, Val MAE=0.012652, Val MedAE=0.009298, Bit_Fail=0
2026.01.01 18:58:39.872 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000178, Val MSE=0.000299, Val MAE=0.013357, Val MedAE=0.010952, Bit_Fail=0
2026.01.01 18:58:55.060 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000178, Val MSE=0.000293, Val MAE=0.012888, Val MedAE=0.010075, Bit_Fail=0
2026.01.01 18:59:10.645 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000178, Val MSE=0.000296, Val MAE=0.013170, Val MedAE=0.010801, Bit_Fail=0
2026.01.01 18:59:26.299 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000178, Val MSE=0.000289, Val MAE=0.012813, Val MedAE=0.010297, Bit_Fail=0
2026.01.01 18:59:41.390 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000178, Val MSE=0.000288, Val MAE=0.012730, Val MedAE=0.010022, Bit_Fail=0
2026.01.01 18:59:58.018 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000178, Val MSE=0.000288, Val MAE=0.012927, Val MedAE=0.010486, Bit_Fail=0
2026.01.01 19:00:16.580 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000178, Val MSE=0.000300, Val MAE=0.013538, Val MedAE=0.011570, Bit_Fail=0
2026.01.01 19:00:22.430 1: VRMAPI DEBUG> start add AI raw data for hour: 19
2026.01.01 19:00:22.434 1: VRMAPI DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.01.01 19:00:22.507 1: VRMAPI DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_VRMAPI
2026.01.01 19:00:23.036 1: SolCast DEBUG> start add AI raw data for hour: 19
2026.01.01 19:00:23.041 1: SolCast DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.01.01 19:00:23.490 1: SolCast DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_SolCast
2026.01.01 19:00:25.468 1: openMeteo DEBUG> start add AI raw data for hour: 19
2026.01.01 19:00:25.471 1: openMeteo DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.01.01 19:00:25.529 1: openMeteo DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_openMeteo
2026.01.01 19:00:36.434 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000178, Val MSE=0.000287, Val MAE=0.012656, Val MedAE=0.009749, Bit_Fail=0
2026.01.01 19:00:52.824 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000178, Val MSE=0.000315, Val MAE=0.014053, Val MedAE=0.012264, Bit_Fail=0
2026.01.01 19:01:08.326 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000178, Val MSE=0.000291, Val MAE=0.013064, Val MedAE=0.010484, Bit_Fail=0
2026.01.01 19:01:18.912 1: SolCast DEBUG> Early stopping bei Epoche 5370 (no improvement since 2000 epochs)
2026.01.01 19:01:18.914 1: === Snapshot-Statistik ===
2026.01.01 19:01:18.916 1: Metric-Improvement Snapshots: 64 (letzte Epoche: 3370)
2026.01.01 19:01:18.918 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 159)
2026.01.01 19:01:18.919 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 19:01:18.925 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 3370: Train MSE=0.000178, Val MSE=0.000328, Val MAE=0.013027, Val MedAE=0.008576, Bit_Fail=0,
2026.01.01 19:01:18.927 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 19:01:18.969 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000178, Validation MSE=0.000328, Validation Bit_Fail=0
2026.01.01 19:01:18.971 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000178
Val MSE=0.000328
Val Mean=0.0002956156
VAL/TRAIN MSE Ratio=1.837433 (limit=2.5)
Diff=0.000149 (limit=0.005)
ValStd=0.0000173294 (limit=7.39038913958514e-05)
-- At Original Scale: --
MAE=214.560321844596
RMSE/MAE=1.3893 (limit=1.5)
Slope=0.916647 (limit=0.7 .. 1.3)
Bias=2.25 (limit=+-107.280160922298)
R2=0.884124888835566
P95=585.2166 (limit=858.241287378382)
P99=942.9805 (limit=1716.48257475676)
-- Robustness Indicators: --
RMSE relative=64 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 19:01:18.979 1: SolCast DEBUG> Retry attempt 3 with Seed=16689959
2026.01.01 19:01:18.985 1: SolCast DEBUG> AI FANN Training started with Params:
num input datasets=7314,
training algo=FANN_TRAIN_INCREMENTAL,
output AF=LINEAR,
hidden AF=SIGMOID,
hidden Neurons=80,40,20,
hidden steepness=0.9,
Epoches=15000,
mse_error=0.001,
learning rate=0.00500,
learning momentum=0.7,
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=5851, Test=1462),
Data shuffle=2 (period=10)
2026.01.01 19:01:19.145 1: SolCast DEBUG> Epoche 1: Train MSE=0.002202, Val MSE=0.002839, Val MAE=0.031937, Val MedAE=0.027914, Bit_Fail=2 -> Snap saved (bit improved)
2026.01.01 19:01:25.133 1: SolCast DEBUG> Epoche 40: Train MSE=0.002098, Val MSE=0.002825, Val MAE=0.031158, Val MedAE=0.027367, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:27.800 1: SolCast DEBUG> Epoche 57: Train MSE=0.001969, Val MSE=0.002810, Val MAE=0.029915, Val MedAE=0.021870, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:27.982 1: SolCast DEBUG> Epoche 58: Train MSE=0.001947, Val MSE=0.002786, Val MAE=0.029801, Val MedAE=0.021464, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.134 1: SolCast DEBUG> Epoche 59: Train MSE=0.001921, Val MSE=0.002758, Val MAE=0.029673, Val MedAE=0.020903, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.609 1: SolCast DEBUG> Epoche 62: Train MSE=0.001810, Val MSE=0.002716, Val MAE=0.029480, Val MedAE=0.017887, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.767 1: SolCast DEBUG> Epoche 63: Train MSE=0.001761, Val MSE=0.002660, Val MAE=0.029224, Val MedAE=0.017446, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:28.915 1: SolCast DEBUG> Epoche 64: Train MSE=0.001706, Val MSE=0.002597, Val MAE=0.028944, Val MedAE=0.016968, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:29.063 1: SolCast DEBUG> Epoche 65: Train MSE=0.001645, Val MSE=0.002528, Val MAE=0.028652, Val MedAE=0.016879, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:29.207 1: SolCast DEBUG> Epoche 66: Train MSE=0.001581, Val MSE=0.002455, Val MAE=0.028362, Val MedAE=0.016529, Bit_Fail=2 -> Snap saved (metric improved)
2026.01.01 19:01:34.406 1: SolCast DEBUG> Epoche 100: Train MSE=0.001581, Val MSE=0.001674, Val MAE=0.026943, Val MedAE=0.019938, Bit_Fail=1
2026.01.01 19:01:41.897 1: SolCast DEBUG> Epoche 149: Train MSE=0.000574, Val MSE=0.000953, Val MAE=0.021557, Val MedAE=0.017213, Bit_Fail=1 -> Snap saved (bit improved)
2026.01.01 19:01:43.755 1: SolCast DEBUG> Epoche 160: Train MSE=0.000466, Val MSE=0.000806, Val MAE=0.019501, Val MedAE=0.014848, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:43.926 1: SolCast DEBUG> Epoche 161: Train MSE=0.000458, Val MSE=0.000792, Val MAE=0.019351, Val MedAE=0.014777, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.118 1: SolCast DEBUG> Epoche 162: Train MSE=0.000451, Val MSE=0.000778, Val MAE=0.019209, Val MedAE=0.014629, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.334 1: SolCast DEBUG> Epoche 163: Train MSE=0.000444, Val MSE=0.000764, Val MAE=0.019075, Val MedAE=0.014565, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.504 1: SolCast DEBUG> Epoche 164: Train MSE=0.000438, Val MSE=0.000752, Val MAE=0.018948, Val MedAE=0.014360, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.716 1: SolCast DEBUG> Epoche 165: Train MSE=0.000432, Val MSE=0.000740, Val MAE=0.018829, Val MedAE=0.014227, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:44.952 1: SolCast DEBUG> Epoche 166: Train MSE=0.000426, Val MSE=0.000729, Val MAE=0.018714, Val MedAE=0.014165, Bit_Fail=1 -> Snap saved (metric improved)
2026.01.01 19:01:45.151 1: SolCast DEBUG> Epoche 167: Train MSE=0.000421, Val MSE=0.000718, Val MAE=0.018605, Val MedAE=0.014070, Bit_Fail=0 -> Snap saved (bit improved)
2026.01.01 19:01:45.311 1: SolCast DEBUG> Epoche 168: Train MSE=0.000416, Val MSE=0.000708, Val MAE=0.018500, Val MedAE=0.013993, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:45.475 1: SolCast DEBUG> Epoche 169: Train MSE=0.000411, Val MSE=0.000699, Val MAE=0.018400, Val MedAE=0.013928, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:50.312 1: SolCast DEBUG> Epoche 200: Train MSE=0.000411, Val MSE=0.000558, Val MAE=0.017252, Val MedAE=0.013991, Bit_Fail=0
2026.01.01 19:01:50.478 1: SolCast DEBUG> Epoche 201: Train MSE=0.000341, Val MSE=0.000558, Val MAE=0.017237, Val MedAE=0.013915, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:50.920 1: SolCast DEBUG> Epoche 204: Train MSE=0.000338, Val MSE=0.000557, Val MAE=0.017191, Val MedAE=0.013805, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:51.226 1: SolCast DEBUG> Epoche 206: Train MSE=0.000337, Val MSE=0.000556, Val MAE=0.017163, Val MedAE=0.013746, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:58.095 1: SolCast DEBUG> Epoche 250: Train MSE=0.000319, Val MSE=0.000554, Val MAE=0.016637, Val MedAE=0.013530, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:01:58.382 1: SolCast DEBUG> Epoche 252: Train MSE=0.000318, Val MSE=0.000553, Val MAE=0.016627, Val MedAE=0.013499, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:00.397 1: SolCast DEBUG> Epoche 266: Train MSE=0.000315, Val MSE=0.000552, Val MAE=0.016535, Val MedAE=0.013373, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:06.185 1: SolCast DEBUG> Epoche 300: Train MSE=0.000315, Val MSE=0.000521, Val MAE=0.016463, Val MedAE=0.014001, Bit_Fail=0
2026.01.01 19:02:17.223 1: SolCast DEBUG> Epoche 371: Train MSE=0.000296, Val MSE=0.000522, Val MAE=0.016217, Val MedAE=0.013366, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:21.515 1: SolCast DEBUG> Epoche 400: Train MSE=0.000296, Val MSE=0.000500, Val MAE=0.016347, Val MedAE=0.013895, Bit_Fail=0
2026.01.01 19:02:23.239 1: SolCast DEBUG> Epoche 410: Train MSE=0.000290, Val MSE=0.000518, Val MAE=0.016152, Val MedAE=0.013203, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:23.555 1: SolCast DEBUG> Epoche 412: Train MSE=0.000290, Val MSE=0.000517, Val MAE=0.016144, Val MedAE=0.013196, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:24.223 1: SolCast DEBUG> Epoche 416: Train MSE=0.000289, Val MSE=0.000516, Val MAE=0.016133, Val MedAE=0.013144, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:36.913 1: SolCast DEBUG> Epoche 500: Train MSE=0.000289, Val MSE=0.000513, Val MAE=0.016033, Val MedAE=0.012459, Bit_Fail=0
2026.01.01 19:02:36.920 1: SolCast DEBUG> Epoche 500: Train MSE=0.000274, Val MSE=0.000513, Val MAE=0.016033, Val MedAE=0.012459, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:37.941 1: SolCast DEBUG> Epoche 507: Train MSE=0.000273, Val MSE=0.000512, Val MAE=0.016016, Val MedAE=0.012419, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:02:52.279 1: SolCast DEBUG> Epoche 600: Train MSE=0.000273, Val MSE=0.000491, Val MAE=0.015793, Val MedAE=0.012659, Bit_Fail=0
2026.01.01 19:03:07.863 1: SolCast DEBUG> Epoche 700: Train MSE=0.000273, Val MSE=0.000531, Val MAE=0.017652, Val MedAE=0.014846, Bit_Fail=0
2026.01.01 19:03:22.755 1: SolCast DEBUG> Epoche 800: Train MSE=0.000273, Val MSE=0.000485, Val MAE=0.015777, Val MedAE=0.012388, Bit_Fail=0
2026.01.01 19:03:22.761 1: SolCast DEBUG> Epoche 800: Train MSE=0.000246, Val MSE=0.000485, Val MAE=0.015777, Val MedAE=0.012388, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:03:38.201 1: SolCast DEBUG> Epoche 900: Train MSE=0.000246, Val MSE=0.000489, Val MAE=0.015804, Val MedAE=0.012387, Bit_Fail=0
2026.01.01 19:03:53.934 1: SolCast DEBUG> Epoche 1000: Train MSE=0.000246, Val MSE=0.000491, Val MAE=0.016320, Val MedAE=0.012996, Bit_Fail=0
2026.01.01 19:04:12.553 1: SolCast DEBUG> Epoche 1100: Train MSE=0.000246, Val MSE=0.000500, Val MAE=0.016762, Val MedAE=0.013013, Bit_Fail=0
2026.01.01 19:04:29.863 1: SolCast DEBUG> Epoche 1200: Train MSE=0.000246, Val MSE=0.000472, Val MAE=0.015815, Val MedAE=0.012588, Bit_Fail=0
2026.01.01 19:04:39.395 1: SolCast DEBUG> Epoche 1240: Train MSE=0.000226, Val MSE=0.000476, Val MAE=0.015690, Val MedAE=0.012238, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:04:44.449 1: SolCast DEBUG> Epoche 1260: Train MSE=0.000226, Val MSE=0.000472, Val MAE=0.015617, Val MedAE=0.012095, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:04:54.273 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000226, Val MSE=0.000469, Val MAE=0.015375, Val MedAE=0.012019, Bit_Fail=0
2026.01.01 19:04:54.283 1: SolCast DEBUG> Epoche 1300: Train MSE=0.000225, Val MSE=0.000469, Val MAE=0.015375, Val MedAE=0.012019, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:05:19.860 1: SolCast DEBUG> Epoche 1400: Train MSE=0.000225, Val MSE=0.000476, Val MAE=0.016232, Val MedAE=0.012583, Bit_Fail=0
2026.01.01 19:05:46.230 1: SolCast DEBUG> Epoche 1500: Train MSE=0.000225, Val MSE=0.000460, Val MAE=0.015477, Val MedAE=0.012145, Bit_Fail=0
2026.01.01 19:06:01.555 1: SolCast DEBUG> Epoche 1560: Train MSE=0.000215, Val MSE=0.000450, Val MAE=0.015175, Val MedAE=0.011698, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:06:11.656 1: SolCast DEBUG> Epoche 1600: Train MSE=0.000215, Val MSE=0.000446, Val MAE=0.015338, Val MedAE=0.011925, Bit_Fail=0
2026.01.01 19:06:19.086 1: SolCast DEBUG> Epoche 1630: Train MSE=0.000213, Val MSE=0.000443, Val MAE=0.015005, Val MedAE=0.011380, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:06:37.018 1: SolCast DEBUG> Epoche 1700: Train MSE=0.000213, Val MSE=0.000456, Val MAE=0.016104, Val MedAE=0.012245, Bit_Fail=0
2026.01.01 19:06:41.728 1: SolCast DEBUG> Epoche 1720: Train MSE=0.000209, Val MSE=0.000437, Val MAE=0.014979, Val MedAE=0.011226, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:06:54.098 1: SolCast DEBUG> Epoche 1770: Train MSE=0.000208, Val MSE=0.000428, Val MAE=0.014866, Val MedAE=0.011051, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:01.420 1: SolCast DEBUG> Epoche 1800: Train MSE=0.000208, Val MSE=0.000421, Val MAE=0.014909, Val MedAE=0.011181, Bit_Fail=0
2026.01.01 19:07:09.022 1: SolCast DEBUG> Epoche 1830: Train MSE=0.000206, Val MSE=0.000425, Val MAE=0.014835, Val MedAE=0.010975, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:18.661 1: SolCast DEBUG> Epoche 1870: Train MSE=0.000205, Val MSE=0.000422, Val MAE=0.014635, Val MedAE=0.010337, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:26.451 1: SolCast DEBUG> Epoche 1900: Train MSE=0.000205, Val MSE=0.000421, Val MAE=0.015039, Val MedAE=0.011242, Bit_Fail=0
2026.01.01 19:07:35.709 1: SolCast DEBUG> Epoche 1950: Train MSE=0.000204, Val MSE=0.000412, Val MAE=0.014563, Val MedAE=0.010315, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:07:43.401 1: SolCast DEBUG> Epoche 2000: Train MSE=0.000204, Val MSE=0.000478, Val MAE=0.017001, Val MedAE=0.013903, Bit_Fail=0
2026.01.01 19:07:59.225 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000204, Val MSE=0.000400, Val MAE=0.014424, Val MedAE=0.010221, Bit_Fail=0
2026.01.01 19:07:59.231 1: SolCast DEBUG> Epoche 2100: Train MSE=0.000200, Val MSE=0.000400, Val MAE=0.014424, Val MedAE=0.010221, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:08:14.654 1: SolCast DEBUG> Epoche 2200: Train MSE=0.000200, Val MSE=0.000399, Val MAE=0.014978, Val MedAE=0.011324, Bit_Fail=0
2026.01.01 19:08:28.453 1: SolCast DEBUG> Epoche 2290: Train MSE=0.000196, Val MSE=0.000390, Val MAE=0.014290, Val MedAE=0.009855, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:08:29.937 1: SolCast DEBUG> Epoche 2300: Train MSE=0.000196, Val MSE=0.000391, Val MAE=0.014139, Val MedAE=0.009359, Bit_Fail=0
2026.01.01 19:08:46.992 1: SolCast DEBUG> Epoche 2400: Train MSE=0.000196, Val MSE=0.000429, Val MAE=0.016088, Val MedAE=0.013370, Bit_Fail=0
2026.01.01 19:08:59.193 1: SolCast DEBUG> Epoche 2480: Train MSE=0.000193, Val MSE=0.000378, Val MAE=0.014148, Val MedAE=0.009492, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:09:02.241 1: SolCast DEBUG> Epoche 2500: Train MSE=0.000193, Val MSE=0.000384, Val MAE=0.014816, Val MedAE=0.011437, Bit_Fail=0
2026.01.01 19:09:18.312 1: SolCast DEBUG> Epoche 2600: Train MSE=0.000193, Val MSE=0.000373, Val MAE=0.014435, Val MedAE=0.010892, Bit_Fail=0
2026.01.01 19:09:27.592 1: SolCast DEBUG> Epoche 2660: Train MSE=0.000190, Val MSE=0.000367, Val MAE=0.013899, Val MedAE=0.009407, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:09:33.631 1: SolCast DEBUG> Epoche 2700: Train MSE=0.000190, Val MSE=0.000364, Val MAE=0.014131, Val MedAE=0.010351, Bit_Fail=0
2026.01.01 19:09:50.479 1: SolCast DEBUG> Epoche 2800: Train MSE=0.000190, Val MSE=0.000374, Val MAE=0.014829, Val MedAE=0.011905, Bit_Fail=0
2026.01.01 19:10:06.433 1: SolCast DEBUG> Epoche 2900: Train MSE=0.000190, Val MSE=0.000358, Val MAE=0.013816, Val MedAE=0.009626, Bit_Fail=0
2026.01.01 19:10:17.130 1: SolCast DEBUG> Epoche 2970: Train MSE=0.000184, Val MSE=0.000354, Val MAE=0.013688, Val MedAE=0.009390, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:10:21.510 1: SolCast DEBUG> Epoche 3000: Train MSE=0.000184, Val MSE=0.000376, Val MAE=0.015092, Val MedAE=0.012492, Bit_Fail=0
2026.01.01 19:10:37.294 1: SolCast DEBUG> Epoche 3100: Train MSE=0.000184, Val MSE=0.000344, Val MAE=0.013896, Val MedAE=0.010700, Bit_Fail=0
2026.01.01 19:10:52.935 1: SolCast DEBUG> Epoche 3200: Train MSE=0.000184, Val MSE=0.000340, Val MAE=0.013841, Val MedAE=0.010725, Bit_Fail=0
2026.01.01 19:11:09.459 1: SolCast DEBUG> Epoche 3300: Train MSE=0.000184, Val MSE=0.000343, Val MAE=0.014114, Val MedAE=0.011228, Bit_Fail=0
2026.01.01 19:11:25.191 1: SolCast DEBUG> Epoche 3400: Train MSE=0.000184, Val MSE=0.000329, Val MAE=0.013537, Val MedAE=0.010090, Bit_Fail=0
2026.01.01 19:11:40.627 1: SolCast DEBUG> Epoche 3500: Train MSE=0.000184, Val MSE=0.000338, Val MAE=0.014317, Val MedAE=0.012038, Bit_Fail=0
2026.01.01 19:11:56.504 1: SolCast DEBUG> Epoche 3600: Train MSE=0.000184, Val MSE=0.000338, Val MAE=0.014292, Val MedAE=0.011860, Bit_Fail=0
2026.01.01 19:12:13.062 1: SolCast DEBUG> Epoche 3700: Train MSE=0.000184, Val MSE=0.000318, Val MAE=0.013443, Val MedAE=0.010655, Bit_Fail=0
2026.01.01 19:12:28.812 1: SolCast DEBUG> Epoche 3800: Train MSE=0.000184, Val MSE=0.000314, Val MAE=0.013299, Val MedAE=0.010337, Bit_Fail=0
2026.01.01 19:12:44.335 1: SolCast DEBUG> Epoche 3900: Train MSE=0.000184, Val MSE=0.000316, Val MAE=0.013177, Val MedAE=0.009737, Bit_Fail=0
2026.01.01 19:12:59.748 1: SolCast DEBUG> Epoche 4000: Train MSE=0.000184, Val MSE=0.000344, Val MAE=0.014781, Val MedAE=0.012876, Bit_Fail=0
2026.01.01 19:13:16.661 1: SolCast DEBUG> Epoche 4100: Train MSE=0.000184, Val MSE=0.000307, Val MAE=0.013173, Val MedAE=0.010441, Bit_Fail=0
2026.01.01 19:13:31.964 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000184, Val MSE=0.000338, Val MAE=0.013368, Val MedAE=0.008535, Bit_Fail=0
2026.01.01 19:13:31.971 1: SolCast DEBUG> Epoche 4200: Train MSE=0.000173, Val MSE=0.000338, Val MAE=0.013368, Val MedAE=0.008535, Bit_Fail=0 -> Snap saved (metric improved)
2026.01.01 19:13:47.873 1: SolCast DEBUG> Epoche 4300: Train MSE=0.000173, Val MSE=0.000322, Val MAE=0.014152, Val MedAE=0.012068, Bit_Fail=0
2026.01.01 19:14:02.737 1: SolCast DEBUG> Epoche 4400: Train MSE=0.000173, Val MSE=0.000317, Val MAE=0.013926, Val MedAE=0.011788, Bit_Fail=0
2026.01.01 19:14:18.079 1: SolCast DEBUG> Epoche 4500: Train MSE=0.000173, Val MSE=0.000301, Val MAE=0.013120, Val MedAE=0.010500, Bit_Fail=0
2026.01.01 19:14:34.780 1: SolCast DEBUG> Epoche 4600: Train MSE=0.000173, Val MSE=0.000300, Val MAE=0.013251, Val MedAE=0.011131, Bit_Fail=0
2026.01.01 19:14:50.749 1: SolCast DEBUG> Epoche 4700: Train MSE=0.000173, Val MSE=0.000316, Val MAE=0.013979, Val MedAE=0.011920, Bit_Fail=0
2026.01.01 19:15:07.488 1: SolCast DEBUG> Epoche 4800: Train MSE=0.000173, Val MSE=0.000298, Val MAE=0.013297, Val MedAE=0.011209, Bit_Fail=0
2026.01.01 19:15:24.075 1: SolCast DEBUG> Epoche 4900: Train MSE=0.000173, Val MSE=0.000299, Val MAE=0.013338, Val MedAE=0.011219, Bit_Fail=0
2026.01.01 19:15:40.613 1: SolCast DEBUG> Epoche 5000: Train MSE=0.000173, Val MSE=0.000301, Val MAE=0.012879, Val MedAE=0.009926, Bit_Fail=0
2026.01.01 19:15:57.651 1: SolCast DEBUG> Epoche 5100: Train MSE=0.000173, Val MSE=0.000296, Val MAE=0.013288, Val MedAE=0.011301, Bit_Fail=0
2026.01.01 19:16:13.287 1: SolCast DEBUG> Epoche 5200: Train MSE=0.000173, Val MSE=0.000299, Val MAE=0.013429, Val MedAE=0.011297, Bit_Fail=0
2026.01.01 19:16:29.416 1: SolCast DEBUG> Epoche 5300: Train MSE=0.000173, Val MSE=0.000326, Val MAE=0.014362, Val MedAE=0.012558, Bit_Fail=0
2026.01.01 19:16:52.624 1: SolCast DEBUG> Epoche 5400: Train MSE=0.000173, Val MSE=0.000293, Val MAE=0.013008, Val MedAE=0.010932, Bit_Fail=0
2026.01.01 19:17:15.448 1: SolCast DEBUG> Epoche 5500: Train MSE=0.000173, Val MSE=0.000303, Val MAE=0.013566, Val MedAE=0.011497, Bit_Fail=0
2026.01.01 19:17:36.891 1: SolCast DEBUG> Epoche 5600: Train MSE=0.000173, Val MSE=0.000290, Val MAE=0.012844, Val MedAE=0.010516, Bit_Fail=0
2026.01.01 19:17:59.157 1: SolCast DEBUG> Epoche 5700: Train MSE=0.000173, Val MSE=0.000301, Val MAE=0.013589, Val MedAE=0.011589, Bit_Fail=0
2026.01.01 19:18:20.531 1: SolCast DEBUG> Epoche 5800: Train MSE=0.000173, Val MSE=0.000289, Val MAE=0.012913, Val MedAE=0.010712, Bit_Fail=0
2026.01.01 19:18:35.740 1: SolCast DEBUG> Epoche 5900: Train MSE=0.000173, Val MSE=0.000291, Val MAE=0.013056, Val MedAE=0.010867, Bit_Fail=0
2026.01.01 19:18:51.160 1: SolCast DEBUG> Epoche 6000: Train MSE=0.000173, Val MSE=0.000305, Val MAE=0.013648, Val MedAE=0.011687, Bit_Fail=0
2026.01.01 19:19:08.256 1: SolCast DEBUG> Epoche 6100: Train MSE=0.000173, Val MSE=0.000290, Val MAE=0.012878, Val MedAE=0.010646, Bit_Fail=0
2026.01.01 19:19:23.867 1: SolCast DEBUG> Epoche 6200: Train MSE=0.000173, Val MSE=0.000289, Val MAE=0.012900, Val MedAE=0.010677, Bit_Fail=0
2026.01.01 19:19:23.869 1: SolCast DEBUG> Early stopping bei Epoche 6200 (no improvement since 2000 epochs)
2026.01.01 19:19:23.871 1: === Snapshot-Statistik ===
2026.01.01 19:19:23.873 1: Metric-Improvement Snapshots: 47 (letzte Epoche: 4200)
2026.01.01 19:19:23.875 1: Bit-Improvement Snapshots: 3 (letzte Epoche: 167)
2026.01.01 19:19:23.877 1: Bit-Tradeoff Snapshots: 0 (letzte Epoche: 0)
2026.01.01 19:19:23.884 1: SolCast DEBUG> Best Snapshot reloaded from Epoche 4200: Train MSE=0.000173, Val MSE=0.000338, Val MAE=0.013368, Val MedAE=0.008535, Bit_Fail=0,
2026.01.01 19:19:23.886 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.01 19:19:23.930 1: SolCast DEBUG> Validation finished - Best Training MSE=0.000173, Validation MSE=0.000338, Validation Bit_Fail=0
2026.01.01 19:19:23.933 1: SolCast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.000173
Val MSE=0.000338
Val Mean=0.0002966460
VAL/TRAIN MSE Ratio=1.953186 (limit=2.5)
Diff=0.000165 (limit=0.005)
ValStd=0.0000123896 (limit=7.41615117947988e-05)
-- At Original Scale: --
MAE=220.184381409254
RMSE/MAE=1.3759 (limit=1.5)
Slope=0.914758 (limit=0.7 .. 1.3)
Bias=-38.97 (limit=+-110.092190704627)
R2=0.880327221041415
P95=605.3179 (limit=880.737525637016)
P99=868.5353 (limit=1761.47505127403)
-- Robustness Indicators: --
RMSE relative=65 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
-> Retrain
2026.01.01 19:19:23.945 1: SolCast DEBUG> Best model after retries comes from Attempt=3 with:
Seed=16689959,
Model Slope=0.91,
Model Bias=-38.97,
VAL MedAE=140.59,
VAL MAE=220.18,
VAL RMSE=302.94,
VAL RMSE relative=65 %,
VAL RMSE_Rating=very bad,
VAL R2=0.88,
Val MSE=0.000338
</pre>
</div>
</div>

 

==== Auswertung der Trainingskennwerte ====

Abrufbar über:

<pre>
get <Name> valDecTree aiNeuralNetConState
</pre>

===== Modellparameter =====

{| class="wikitable"
! Kennwert !! Bedeutung
|-
| Normierungsgrenzen || Skalierung der Eingabedaten
|-
| Trainingsdaten || Anzahl der Datensätze (Training/Validierung)
|-
| Architektur || Inputs, Hidden Layers, Outputs
|-
| Hyperparameter || Learning Rate, Momentum, BitFail‑Limit
|-
| Aktivierungen || Hidden/Output‑Aktivierungsfunktionen
|-
| Zufallsgenerator || Shuffle‑Mode und Shuffle‑Periode
|}

===== Trainingsmetriken =====

{| class="wikitable"
! Kennwert !! Interpretation
|-
| bestes Modell bei Epoche || Zeitpunkt minimalen Validierungsfehlers
|-
| Training MSE / Validation MSE || Fehlermaße; sollten niedrig und ähnlich sein
|-
| Validation Bit_Fail || Anzahl fehlerhafter Klassifikationen
|-
| bester Trainingslauf || Lauf mit bestem Ergebnis
|-
| Trainingsbewertung || Qualitätsindikator (Varianz, Mittelwert)
|}

===== Fehlermaße der Prognosen =====

{| class="wikitable"
! Kennwert !! Bedeutung
|-
| MAE || mittlerer absoluter Fehler (Wh)
|-
| MedAE || medianer Fehler
|-
| RMSE || quadratischer Fehler, betont Ausreißer
|-
| MAPE || prozentualer Fehler
|-
| MdAPE || medianer prozentualer Fehler
|-
| R² || Gütemaß (0–1)
|}

===== Interpretation des Beispielmodells =====

Die Modellkennzahlen können nach ausgführten Training mit

get <Name> valDecTree aiNeuralNetConState

angezeigt werden. Eine Beispielausgabe sieht etwa so aus:

<pre>
letztes KI-Training: 25.12.2025 03:52:41 / Laufzeit in Sekunden: 1951
letzte KI-Ergebnis Generierungsdauer: 20.37 ms

=== Modellparameter ===

Normierungsgrenzen: PV=9276 W, Hausverbrauch: Min=0 W / Max=8937 W
Trainingsdaten: 7760 Datensätze (Training=6208, Validierung=1552)
Architektur: Inputs=41, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 8690 (von max. 15000)
Training MSE: 0.000
Validation MSE: 0.000
Validation Bit_Fail: 0
bester Trainingslauf: 2
Trainingsbewertung: ok (Val MSE Standard Deviation=0.000000, Val MSE Avg=0.000003)

=== Fehlermaße der Prognosen ===

MAE: 122.74 Wh
MedAE: 69.28 Wh
RMSE: 0.002
MAPE: 17.526 %
MdAPE: 10.611 %
R²: 0.847
</pre>

Die Interpretation dieser Daten wird im angezeigten Popup mit ausgegeben und ist diesem Fall:

* 7760 Datensätze → sehr gute Basis
* 80‑40‑20 Architektur → geeignet für komplexe Muster
* MSE ≈ 0 → exzellente Modellanpassung
* MAE 122 Wh → sehr präzise
* R² = 0.847 → hohe Erklärungsqualität

Das Modell ist stabil, generalisiert gut und liefert sehr brauchbare Prognosen.

 
==== DriftSlope – Bedeutung, Berechnung und Interpretation ====
🧩 '''Was ist DriftSlope?''' 

'''DriftSlope''' beschreibt, wie stark sich die Dynamik des Modells im Vergleich zur Realität verändert hat. 
Dynamik bedeutet hier: '''Wie stark steigen oder fallen die Werte im Verhältnis zueinander?'''

Ein Modell kann also:
* '''zu flach''' sein (reagiert zu wenig auf Veränderungen),
* '''zu steil''' sein (überreagiert),
* oder '''perfekt''' zur Realität passen.

DriftSlope misst genau diese Abweichung.

🧮 '''Wie wird DriftSlope berechnet?''' 
[[Datei:DriftSlope.png|right|thumb|400px|DriftSlope]]

Die Formel lautet:

<pre>
DriftSlope = SlopeLive / SlopeModel
</pre>

* '''SlopeLive''' = Steigung aus den letzten Live‑Daten
* '''SlopeModel''' = Steigung aus dem ursprünglichen Modelltraining

Damit ist DriftSlope ein '''Verhältnis''', kein Unterschied.

🎯 '''Warum ist das ein Verhältnis und keine Differenz?''' 

Ein Verhältnis ist robust gegenüber Skalierung und Lastniveau.

'''Beispiel:'''
* Modell: Slope = 0.9 / Live: Slope = 0.9 → Verhältnis = 1.0 → '''perfekt'''
* Modell: 0.9 / Live: 0.45 → Verhältnis = 0.5 → '''Modell ist doppelt so steil wie die Realität'''
* Modell: 0.9 / Live: 1.35 → Verhältnis = 1.5 → '''Modell ist zu flach'''

Eine Differenz (z. B. 0.9 − 0.45 = 0.45) wäre nicht interpretierbar, weil sie nicht skaliert.

📊 '''Wie interpretiert man DriftSlope?''' 

{| class="wikitable"
! DriftSlope !! Bedeutung !! Interpretation
|-
| ≈ 1.0 || perfekt || Modell und Realität haben die gleiche Dynamik
|-
| 0.85 - 1.15 || leichte Abweichung || Modell ist etwas flacher oder steiler
|-
| 0.70 - 1.30 || moderate Drift || Modell reagiert spürbar anders als die Realität
|-
| || starke Drift || Modell ist deutlich zu flach oder zu steil
|}

🧭 '''Warum ist die Richtung wichtig?''' 

* DriftSlope > 1.0
::→ Live‑Dynamik ist stärker
::→ Modell reagiert zu wenig
::→ Prognosen müssen verstärkt werden

* DriftSlope < 1.0
::→ Live‑Dynamik ist schwächer
::→ Modell reagiert zu stark
::→ Prognosen müssen abgeschwächt werden

Damit steuert DriftSlope die '''multiplikative Korrektur''' des Modells.

🧠 '''Zusammenfassung''' 

'''DriftSlope''' ist ein Verhältnis:

DriftSlope = SlopeLive / SlopeModel

Es zeigt:
* wie gut das Modell die reale Dynamik abbildet
* ob das Modell zu flach oder zu steil ist
* wie stark die Drift ist
* wie stark die Korrektur ausfallen soll

DriftSlope ist damit ein zentraler Baustein der Drift‑Erkennung und der automatischen Modellkorrektur.

 
==== automatische Bias‑ und Drift‑Korrektur (Überblick) ====

📘 Die Verbrauchs‑Prognose nutzt ein neuronales Netz, das aus historischen Verbrauchsdaten lernt. Damit die Vorhersagen auch bei veränderten Haushaltsmustern stabil und realistisch bleiben, wird das Roh‑Ergebnis des Modells bei jeder Prognoseerstellung durch zwei zusätzliche Korrekturschritte verbessert.

===== 🔧 1. Modell‑Bias‑Korrektur (Feinabstimmung) =====

Das neuronale Netz kann nach dem Training einen kleinen systematischen Fehler haben – zum Beispiel leicht zu hoch oder zu niedrig liegen. Dieser Fehler wird als <code>ModelBias</code> gemessen.

Die Bias‑Korrektur:

* wirkt nur im Grundlastbereich (keine Peak‑Verzerrung)
* ist additiv – korrigiert wird aber nicht um einen festen Wert, sondern um einen '''Anteil''' des gemessenen Bias, der von der Modellgüte abhängt
* wird über eine Zonenlogik gesteuert:
** Zone 1 (grün): Modell ist sehr stabil → 70 % des Bias werden korrigiert
** Zone 2 (gelb): Modell ist moderat stabil → 50 % des Bias werden korrigiert
** Zone 2b (nur bei bestimmten Haushaltsprofilen): 25 % des Bias werden korrigiert
** Zone 3 (rot): Modellqualität reicht nicht aus → keine additive Korrektur

Damit wird das Modell feinjustiert, ohne Peaks oder Lastspitzen zu verändern.

===== 🌡️ 2. Drift‑Korrektur (Anpassung an aktuelles Verbrauchsverhalten) =====

Der Verbrauch eines Haushalts kann sich im Laufe der Zeit ändern (z. B. neue Geräte, anderes Verhalten, Jahreszeit). Die Drift‑Analyse erkennt solche Veränderungen anhand von:

* <code>DriftSlope</code> – Verhältnis zwischen aktueller und zuletzt kalibrierter Regressionssteigung
* <code>DriftRmseRelRatio</code> – Verhältnis der aktuellen relativen Fehlerlage (RMSE) zur Referenz
* <code>DriftBias</code> – aktuelle systematische Verschiebung gegenüber der Referenz

Wenn Drift erkannt wird, wird die Prognose angepasst:

'''✔ Level‑Korrektur''' 
Die Vorhersage wird proportional verstärkt oder abgeschwächt, je nachdem wie stark sich das aktuelle Verbrauchsniveau von der zuletzt kalibrierten Referenz unterscheidet.

'''✔ Drift‑Bias''' 
Ein zusätzlicher Korrekturwert wird – ebenfalls nur im Grundlastbereich – addiert.

'''✔ Adaptive Drift‑Gewichtung''' 
Die Stärke der Drift‑Korrektur hängt dynamisch ab von:
* Abweichung des Slopes von der Referenz
* Stärke der relativen Fehlerabweichung (RMSE)
* allgemeiner Modellqualität (MAE)

'''✔ Drift‑Zonenlogik''' 
Zusätzlich wird die Drift in drei Stufen eingeteilt:
* Drift‑Grün: kaum Drift → nur 10 % der Level‑Korrektur wirksam
* Drift‑Gelb: moderater Drift → 40 % der Level‑Korrektur wirksam
* Drift‑Rot: starker Drift → 70 % der Level‑Korrektur wirksam

Damit reagiert die Prognose sanft bei kleinen Veränderungen und stärker bei echten Strukturbrüchen. '''Nachts (00–06 Uhr)''' sowie bei einem frisch trainierten Modell wird die Drift‑Level‑Korrektur automatisch deaktiviert.

🎯 '''Warum das wichtig ist'''

Ohne Bias‑ und Drift‑Korrektur würden Prognosen:
* bei veränderten Verbrauchsgewohnheiten zu hoch oder zu niedrig liegen
* Peaks falsch einschätzen
* langsam oder gar nicht auf neue Muster reagieren

Mit der Korrektur:
* bleibt die Prognose realistisch und stabil
* passt sich automatisch an das aktuelle Verhalten an
* schützt Peaks vor Überkorrektur
* liefert visuell plausible Verläufe

===== 🔄 3. Rekalibrierung nach einem neuen Training (Drift‑Reset) =====

Nach jedem KI‑Training startet das Modell mit einem neutralen Drift‑Zustand. Das ist wichtig, weil die Drift‑Analyse auf einem Zeitfenster der jüngsten Vergangenheit basiert (standardmäßig 96 Stunden, je nach Situation automatisch zwischen 48 und 144 Stunden angepasst) – unmittelbar nach dem Training stammen diese Daten aber noch vom alten Modell.

Damit keine falsche Drift entsteht, wird die Drift‑Pipeline automatisch zurückgesetzt:

* <code>DriftBias</code> wird auf 0.0 gesetzt
* <code>DriftSlope</code> wird auf 1.0 gesetzt
* <code>DriftFlag</code> wird auf <code>fresh_model</code> gesetzt
* die übrigen Drift‑Kennzahlen (u. a. <code>DriftScore</code>, <code>DriftRmseRelRatio</code>, <code>DriftIndex</code>) werden gelöscht und im UI als „‑" angezeigt, bis wieder ausreichend Live‑Daten vorliegen
* die Referenzwerte für die Korrektur (<code>DriftRefBias</code>, <code>DriftRefSlope</code>) werden auf die Werte aus dem aktuellen Training gesetzt

Erkennt das System über mehrere Stunden hinweg '''anhaltende und plausible''' Drift, werden die Korrektur‑Referenzwerte sanft an die realen Verbrauchsdaten angepasst:

* <code>DriftRefBias</code> ersetzt den bisherigen Referenzwert als neue Basislinie für die additive Korrektur. → Das Modell verschiebt sein Grundniveau, damit die Vorhersage im Mittel wieder stimmt.
* <code>DriftRefSlope</code> ersetzt den bisherigen Referenzwert als neue Basis für die Level‑Korrektur. → Das Modell reagiert wieder angemessen auf Verbrauchsänderungen.
* Die ursprünglichen Trainingswerte <code>ModelBias</code>/<code>ModelSlope</code> bleiben davon unberührt als Referenz erhalten.

Diese Rekalibrierung geschieht bewusst nur in kleinen, gedämpften Schritten (nie ein voller Sprung auf die Live‑Werte) und '''erst, wenn eine Sicherheitsprüfung sie zulässt''' – siehe nächster Abschnitt.

===== 🛡️ Schutz vor Fehlalarmen =====

Bevor eine Rekalibrierung tatsächlich durchgeführt wird, prüft das System die aktuelle Datenlage auf Plausibilität. Erkannt und '''blockiert''' werden unter anderem:

* typische Nacht‑/Grundlastphasen (keine echte Drift, nur niedriger Verbrauch)
* unplausible oder stark schwankende Slope‑/Bias‑Werte (Hinweis auf Sensor‑ oder API‑Fehler statt echter Verhaltensänderung)
* Fälle, in denen das Modell zwar generell ungenau, aber '''nicht driftend''' ist (hier hilft ein Retraining mehr als eine Rekalibrierung)

Nur wenn keiner dieser Fälle vorliegt, wird tatsächlich rekalibriert. Bleibt die Drift trotzdem über viele Stunden bestehen, meldet das System stattdessen eine Retraining‑Empfehlung.

===== ⏳ 4. Drift‑Sperrmechanismus (ModelAgeHours) =====

Damit die Drift‑Analyse nur auf echten Live‑Daten des neuen Modells basiert, wird sie erst aktiviert, wenn genügend neue Daten vorliegen.

Das Modellalter wird automatisch berechnet:
* aus dem Zeitstempel des letzten Trainings
* und dem Zeitindex der neuesten Verbrauchsdaten

Solange das Modell jünger als die konfigurierte Mindestreife (aktuell 6 Stunden) ist:
* wird keine Drift berechnet
* alle Drift‑Parameter bleiben neutral
* die Prognose nutzt nur das neuronale Netz und die Modell‑Bias‑Korrektur
* <code>DriftFlag = fresh_model</code>
* Drift‑Kennzahlen werden im UI als „‑" angezeigt

Nach Ablauf dieser Mindestzeit wird die Drift‑Analyse automatisch freigeschaltet.

🎯 '''Warum diese Mechanismen wichtig sind'''

Ohne Rekalibrierung, Sicherheitsprüfung und Sperrmechanismus würden:
* direkt nach dem Training falsche Drift‑Signale entstehen
* die Prognose durch alte Fehlerbilder verzerrt
* Bias‑ und Drift‑Korrektur in die falsche Richtung wirken
* severe‑Drift‑Alarme auftreten, obwohl das Modell frisch ist – oder obwohl nur ein Sensor gerade falsche Werte liefert

Mit dieser Logik:
* startet jedes Modell neutral und stabil
* Drift wird erst aktiv, wenn genügend neue Live‑Daten existieren
* offensichtlich unplausible Datenlagen lösen keine Rekalibrierung aus
* die Prognose bleibt ruhig, plausibel und robust
* Fehlalarme werden deutlich reduziert

----
''Eine ausführliche, technische Beschreibung mit allen Formeln, Zonenschwellen und der zugrunde liegenden ML‑Theorie findet sich im Deep‑Dive‑Artikel: [[Driftmanagement und Bias-Korrektur im SolarForecast KI-Prognosesystem]]''

 

== Modulinterne Datenstrukturen ==
Das Modul speichert die verschiedenen historischen und aktuellen Daten wie PV-Prognose, Witterungsdaten (Regen, Bewölkung), Strahlungsdaten, Einspeisung, Bezug, reale Erzeugungsdaten und vieles mehr zur Laufzeit im Arbeitsspeicher. Dadurch ist die Verarbeitung dieser Daten im Vergleich zu Lesevorgängen aus dem Filesystem bzw. einer Datenbank sehr performant. Allerdings würden diese Daten bei einem FHEM Absturz bzw. bei einem regulären Shutdown verlorengehen.

Deswegen werden die relevanten Daten regelmäßig in Dateien gesichert und bei Bedarf wiederhergestellt. Diese Dateien befinden sich im Verzeichnis '''../fhem/FHEM/FhemUtils''' und heißen '''.*_SolarForecast_.*'''.

Die Daten werden in jedem Zyklus der Zentralschleife (CentralTask) gesammelt bzw. berechnet. Der Zyklus wird mit dem Attribut '''plantControl->cycleInterval''' eingestellt.

Zur Laufzeit können diese Daten über get-Kommandos abgerufen werden.

<pre>
get ... pvHistory [Tag]
</pre>

Der pvHistory Datenspeicher enthält die vergangenen Kennwerte der letzten 31 Tage mit einer Genauigkeit von einer Stunde. Es werden die Prognosewerte für Erzeugung und Verbrauch, die realen Werte für Erzeugung und Verbrauch sowie ebenso die Laufzeiten jedes einzelnen Verbrauchers (Consumer) festgehalten. Für jeden Tag gibt es die Stunde "99" die eine Summierung der Stundenwerte des Tages bzw. Sonderschlüssel enthält.

Bei Bedarf lässt sich mit dem Befehl "set ... reset pvHistory" der gesamte Inhalt des Speichers löschen (nicht empfohlen). Selektiver funktioniert die Datenlöschung mit "set ... reset pvHistory <Tag>" (Daten eines bestimmten Tages löschen) bzw. "set ... reset pvHistory <Tag> <Stunde>" (Daten der Stunde eines bestimmten Tages löschen). Die letzten beiden Kommandos müssen über die Kommandozeile im Browser ausgeführt werden.

<pre>
get ... pvCircular
</pre>

Dieser Ringspeicher enthält Daten der letzten 24 Stunden sowie fortwährend berechnete Werte wie Korrekturfaktoren der PV-Erzeugung und Prognosequalität.
Neue Stundenwerte des Tages überschreiben die gespeicherten Schüssel des vorangegangenen Tages sofern es sich nicht um fortwährend berechnete Werte handelt.

<pre>
get ... nextHours
</pre>

Der Speicher enthält sämtliche Prognosewerte der kommenden Stunden beginnend mit der aktuellen Stunde.

<pre>
get ... radiationApiData
</pre>

Abhängig von der ausgewählten Strahlungsdaten API enthält dieser Speicher die von der API gelieferten Rohdaten sowie evtl. weitere für die Funktion benötigte Daten wie API-Keys, Response Messages, Anzahl der API Abruf und weitere.

<pre>
get ... valCurrent
</pre>

Diese Struktur wird nicht regelmäßig im Filesystem gespeichert und enthält immer aktuell gesammelte oder berechnete/gelieferte Daten wie z.B. die Autarkierate, letze Laufzeit der Zentralschleife (CentralTask), Zeit des Sonnenauf- und untergangs sowie weitere Betriebsdaten.

<pre>
get ... valConsumerMaster [XX]
</pre>

Zeigt die Daten der aktuell im SolarForecast Device registrierten Verbraucher. Mit der Nummer '''XX''' kann ein bestimmter Verbraucher angesprungen werden. Die Nummer korrespondiert mit dem entsprechenden '''consumerXX''' Attribut.
Neben anderen Betriebs- und Energiedaten werden insbesondere folgende Daten ermittelt, die für die zukünftige Planung der Verbraucherschaltzeiten relevant sind:

* epieces - prognostizierte Energiescheiben pro Betriebsstunde

Ausgehend von gespeicherten historischen Verbrauchsdaten des Verbrauchers wird der Energieverbrauch des Verbrauchers in seiner ersten Betriebsstunde prognostiziert, was insbesondere für die Planung der optimalen Startzeit des Verbrauchers in Bezug zu der prognostizierten PV Energie und den Verbrauchswerten weiterer vorhandener bzw. zu planender Verbraucher Berücksichtigung findet. Weitere Informationen zur Verbrauchersteuerung in diesem [[#Verbrauchersteuerung_-_Registrieren_und_visualisieren_von_Verbrauchern|Abschnitt]].

=== Schnittstelle für Modulautoren bzw. eigenen Code ===

Die im vorherigen Artikel beschriebenen internen Datenstrukturen können durch externen Code abgefragt und ausgewertet werden.
Dazu stehen die folgenden Funktionen zur Verfügung.

::* [FHEM::SolarForecast::]BatteryVal ('<Name>', '<Bn>', '<Key>', <default>) entspricht der Abfrage mit "get ... valBattery".

::* [FHEM::SolarForecast::]CurrentVal ('<Name>', '<Key>', <default>) entspricht der Abfrage mit "get ... valCurrent".

::* [FHEM::SolarForecast::]InverterVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valInverter".

::* [FHEM::SolarForecast::]ProducerVal ('<Name>', '<Nr>', <Key>', <default>) entspricht der Abfrage mit "get ... valProducer".

::* [FHEM::SolarForecast::]HistoryVal ('<Name>', '<Day>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvHistory".

::* [FHEM::SolarForecast::]CircularVal ('<Name>', '<HoD>', '<Key>', <default>) entspricht der Abfrage mit "get ... pvCircular".

::* [FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>) entspricht der Abfrage mit "get ... nextHours".

::* [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>) entspricht der Abfrage mit "get ... valConsumerMaster".

::* [FHEM::SolarForecast::]RadiationAPIVal ('<Name>', '<String>', '<DateTime>', '<Key>', <default>) entspricht der Abfrage mit "get ... radiationApiData".

::* [FHEM::SolarForecast::]WeatherAPIVal ('<Name>', '<APIname>', '<TimeCode>', '<Key>', <default>) entspricht der Abfrage mit "get ... weatherApiData".

::* [FHEM::SolarForecast::]StatusAPIVal ('<Name>', '<APIname>', '<QTag>', '<Key>', <default>) entspricht der Abfrage mit "get ... statusApiData".

::* [FHEM::SolarForecast::]StringVal ('<Name>', '<String>', '<Key>', <default>) entspricht der Abfrage mit "get ... valStrings".

Die Angabe des Packages (FHEM::SolarForecast::) ist nur notwendig wenn die Funktionen von außerhalb des SolarForecast-Devices aufgerufen werden. Innerhalb des Devices (Code-Ausführung im Attribut ''ctrlUserExitFn'') kann darauf verzichtet werden.

Die Bedeutung der Platzhalter sind:

<pre>
<Name> - Name des SolarForecast Devices
<Day> - abzufragender Tag (01 - 31)
<Bn> - Batterie Nummer (01, 02, ...)
<DateTime> - Startzeit der Form YYYY-MM-DD hh:00:00
<TimeCode> - Zeitwert der Form fcX_XX (z.B. fc1_19)
<APIname> - Hauptname der API gemäß setupWeatherDev1 (z.B. OpenMeteo)
<String> - Name des PV-Modulstrings wie im Attribut 'setupInverterStrings'
<QTag> - Question Tag, z.B. '?All'
<Nr> - laufende Nummer des Verbrauchers / Gerätes (01, 02, 03, 04,...)
<HoD> - abzufragende Stunde (01 - 24, 99)
<nhr> - nächste Stunde (NextHour00, NextHour01,...)
<Key> - der abzufragende Schlüssel
<default> - def default-Rückgabewert
</pre>

 
==== Beispiel Auslesen der Batterieladestrategie und Anlegen eines Readings ====

Als Praxisbeispiel soll die aktuelle gesetzte Ladestrategie für Batterie "01" ausgelesen und mit dem Wert ein Reading im SolarForecast Device angelegt werden. 
Dazu wird der folgende Code im Attribut ''ctrlUserExitFn'' hinterlegt:

<syntaxhighlight lang="Perl">
{
my $wert = NexthoursVal ($name, 'NextHour00', 'strategybat01', 'loadRelease');
storeReading ('Ladestrategie', $wert);
}
</syntaxhighlight>

Bei jedem Zyklus des SF-Devices wird der aktuelle Wert von ''strategybat01'' gelesen und im Reading ''Ladestrategie'' gespeichert. Die Paket-Definition ''FHEM::SolarForecast::'' braucht nicht verwendet werden, da der Aufruf im Attribut ctrlUserExitFn innerhalb des SolarForecast-Paketes erfolgt.

Für andere Batterienummern ist der NexthoursVal-Schlüssel ''strategybat01'' entsprechend anzupassen.

 

=== Auswerten von internen Arrays ===

Die meisten der internen Datenstrukturen liefern bei der Abfrage einen einfachen String oder numerischen Wert der ausgewertet werden kann. Es gibt allerdings auch intern gespeicherte Wertelisten. Werden die Listenstrukturen mit den oben beschriebenen Befehlen abgefragt, wird eine Referenz auf die Liste geliefert sofern sie vorhanden ist.

Um auf die Werte einer solchen Liste zuzugreifen, ist am Beispiel des Arrays ''surplusslidereg'' aus dem Current-Speicher (get ... valCurrent) dargestellt:

<syntaxhighlight lang="Perl">
my $splref = CurrentVal ($name, 'surplusslidereg', '.');
my $spser = ref $splref eq 'ARRAY' ? join ' ', @{$splref} : undef;
</syntaxhighlight>

Die Variable $spser enthält bei Vorhandensein der Liste einen String, der die Listenelemente von 'surplusslidereg' durch Leerzeichen getrennt enthält.

 

== Backup und Wiederherstellung der Moduldaten ==
Neben der Datenhaltung in den Attributen und Readings des SolarForecast Devices, erzeugt jedes SolarForecast Device Dateien im Verzeichnis '''../fhem/FHEM/FhemUtils''' mit folgenden Inhalten:

<pre>
Init_SolarForecast_<name> - initiatiale Daten die vor dem Einlesen weiterer Daten oder Attribute geladen werden
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 APIs
WeatherApi_SolarForecast_<name> - Wetterdaten der gewählten Wetter-API (außer DWD-Device)
AItra_SolarForecast_<name> - PV-KI Entscheidungsquelle (trainierte Daten)
AIraw_SolarForecast_<name> - PV-KI Input Daten = Raw Trainigsdaten
NeuralNet_SolarForecast_<name> - Daten des neuronalen Netztes (KI Verbrauchsprognose)
Messages_SolarForecast_<name> - Daten des Nachrichten- und Informationssystems
</pre>

Je nach Ausprägung und eingesetzten Features des SolarForecast Devices sind alle oder nur ein Teil dieser Dateien vorhanden. Dabei ist '''<name>''' der Name des SolarForecast Devices.

Bei einem Filebackup des FHEM-Servers ist darauf zu achten, dass diese Dateien in dem Backup enthalten sind. Der Inhalt der Dateien ist nicht statisch, sondern kann sich dynamisch aktualisieren. Um im Bedarfsfall einen aktuellen Datenstand zu haben, ist mindestens ein tägliches Backup dieser Dateien empfehlenswert. Eventuell auch öfter mit Hilfe einer Versionierung welche z.B. immer die letzten drei Versionen aufbewahrt.

Beim Start von FHEM werden bestimmte Dateien automatisch gelesen und in das SolarForecast Device importiert.
Der Vorgang ist mit verbose=3 im Log protokolliert:

<pre>
2023.10.02 09:57:07.967 3: SolCast6 - cached data "Initialize" restored
2023.10.02 09:57:07.967 3: SolCast6 - set init data writeForceType=db before load over data
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
2023.10.02 09:57:07.976 3: SolCast6 - cached data "NeuralNetwork" restored for FANN type 'con'
</pre>

Bestimmte Betriebsdaten, wie z.B. die witterungsabhängigen Korrekturfaktoren (circular) oder die KI-Daten (aitrained/airaw), bauen sich über die Zeit immer granularer auf und stellen einen wertvollen Datenbestand dar.

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

* 1. definieren des neuen SolarForecast Devices, d.h. ein einfaches "define <Name> SolarForecast", und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. Anpassen der Dateieigentümer und Berechtigungen: chown fhem:dialout /opt/fhem/FHEM/FhemUtils/*, chmod 774 /opt/fhem/FHEM/FhemUtils/*
* 5. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 6. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen
* 7. FHEM Konfiguration sichern und restarten

 
'''Hinweis:''' 
Das zuvor beschriebene Verfahren kann auch angewendet werden um das SolarForcast Device von einer FHEM Installation in eine andere Installation umzuziehen. In diesem Fall ist aber besonders darauf zu achten, vorab alle in den SF-Attributen referenzierten Devices wie Inverter, Meter oder DWD-Devices mit den zutreffenden Namen in der neuen Installation anzulegen. Weiterhin muß beachtet werden, dass die '''Daten nicht zwischen 32 Bit-Systemen und 64 Bit-Systemen ausgetauscht werden können'''. So können z.B. auf einem 32 Bit-System geschriebene Dateien auf einem 64 Bit-System nicht gelesen werden und vice versa.

 
Soll das neue SolarForecast Device mit einem anderen Namen oder weitere SolarForecast Devices erstellt werden, welche die Betriebsdaten des primären Devices verwenden sollen, ist wie folgt vorzugehen:

* 1. definieren des neuen SolarForecast Devices, d.h. ein einfaches "define <Name> SolarForecast", und sichern der FHEM Konfiguration (der Konfigurationsdialog muß nicht durchgeführt werden)
* 2. FHEM stoppen
* 3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
* 4. umbenenen der Dateien, wobei <name> durch den Namen des neuen SolarForecast Devices ersetzt wird
* 5. Anpassen der Dateieigentümer und Berechtigungen: chown fhem:dialout /opt/fhem/FHEM/FhemUtils/*, chmod 774 /opt/fhem/FHEM/FhemUtils/*
* 6. starten von FHEM (bestimmte Daten werden automatisch importiert)
* 7. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen
* 8. FHEM Konfiguration sichern und restarten

Wenn sich die SolarForecast Devices hinsichtlich ihres Models oder der integrierten Consumer unterscheiden, sind die Dateien "PVCsm_SolarForecast_<name> " , "ScApi_SolarForecast_<name>" von dem Verfahren auszuschließen.

== Batterieintegration und -steuerung ==

=== Wie eine Batterie eingebunden wird ===
Wie immer muß die Batterieanlage zunächst mit einem für die Batterie spezifischen FHEM-Device in FHEM definiert sein.
In diesem Device werden Readings erwartet die folgende Werte bereitstellen:

::* ein Reading welches die aktuelle Batterieladeleistung liefert

::* ein Reading welches die aktuelle Batterieentladeleistung liefert

::* ein Reading welches die installierte Batteriekapazität liefert ('''Hinweis:''' dieser Schlüssel ist für die Aktivierung des Batterie SOC-Managements und die grafische Anzeige des SOC wesentlich!)

::* ein Reading welches die bis dato vorliegende Lade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* ein Reading welches die bis dato vorliegende Entlade-Energiemenge als fortlaufenden Zähler liefert (optional)

::* Reading welches den aktuellen Ladezustand (SOC in Prozent) liefert (optional)

Die Batterie, bzw. das Batteriedevice wird mit dem Attribut '''setupBatteryDev''' im SolarForecast Device registriert. Die Syntax des Attributes ist in der Online-Hilfe zum Attribut umfassend erläutert.
Auch wenn manche Readings optional sind, wird empfohlen alle Werte bereitzustellen um alle Batterie-Funktionen im Modul nutzen zu können. Durch die Weiterentwicklung des Moduls können optionale Readings später auch obligatorisch werden.

==== Visualisierung der Batterie in der Balkengrafik ====

Das Attribut '''setupBatteryDevXX''' verfügt über den Schlüssel '''show''', mit dem die Einblendung des bzw. der Batteriesymbole in den Ebenen der Balkengrafik gesteuert werden kann:
[[Datei:Screenshot 2025-02-23 192002.png|right|thumb|400px|Einblendung der Batterieleiste und Darstellung des Batterie-SoC als Balkencontent in der zweiten Ebene]]

* 0 - keine Anzeige des Gerätes (default)
* 1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
* 2 - Anzeige des Gerätes in der Balkengrafik Ebene 2

Die Symbole und die Farbgebung der Batterie(n) können mittels des Schlüssels '''icon''' verändert werden. Die Online-Hilfe gibt weitere Informationen zur Ausgestaltung.

In der Batteriedarstellung wird das Symbol der aktuellen Stunde hervorgehoben. Ein Mouse-Over zeigt wesentliche Betriebszustände der Batterie. Die Batteriesymbole vergangener Stunden zeigen mit einem Mouse-Over die erreichten SoC (State of Charge) Stände. Die kommenden Stunden visualisieren die folgenden Prognosen:

* der prognostizierte SoC unter Berücksichtigung der PV-Prognose und der [[#Aktivierung_des_Batterie_SOC-Managements|Batteriesteuerung]] sofern sie im Modul aktiviert ist.
* eine Freigabe bzw. Empfehlung der Batterieladung zur [[#Unterstützung_eines_netzdienlichen_Verhaltens|Unterstützung eines netzdienlichen Verhaltens]]

Neben der Einblendung der Batterieleiste über der Balkengrafik selbst können bestimmte Batteriekennwerte als Balkeninhalt dargestellt werden. Die Auswahl erfolgt über das Attribut '''graphicBeamXContent'''.

=== Aktivierung des Batterie SOC- und Lade-Managements ===
Das integrierte SOC- und Lade-Management verfolgt insbesondere diese Ziele:

* den Ladezustand der Batterie(n) zu optmimieren, was besonders in den Monaten mit geringerer PV-Erzeugung einen wertvollen Beitrag zur Erhöhung der Autarkierate und Batteriepflege leisten kann

* eine PV-Prognose und Verbrauch optimierte Beladungssteuerung, die in den Monaten mit hoher PV-Erzeugung hilft eine evtl. Abregelung der Anlage zu verhindern, die Batterie ausgewogen über den Tag zu laden und ein netzdienliches Verhalten zu unterstützen

Diese Aspekte der Batteriesteuerung werden in den folgenden Abschnitten beschrieben. Sind mehrere Batterien installiert, kann die Steuerung getrennt für jede einzelne Batterie aktiviert und eingestellt werden. Dabei ist zu beachten, dass vom Modul nur Signale und Readings bereitgestellt werden, die durch eine entsprechende Routine ausgewertet werden können um spezifische Befehle zur Umsetzung der Steuerung an das Batteriesystem zu senden.

Für eine Aktivierung des Managements muß zunächst das Batterie-Device wie im vorigen Abschnitt im SolarForecast Device registriert werden.
Das Attribut '''ctrlBatSocManagementXX''' aktiviert die im Modul integrierte SOC- und Lade-Management Routine:

attr <Device> ctrlBatSocManagementXX lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>] [loadAbort=<SoC1>:<MinPwr>:<SoC2>] [safetyMargin=<Wert>[:<Wert>]] ...

Die einzelnen Schlüssel werden der Kalkulationsroutine als Steuerungsparameter übergeben und bedeuten:

;lowSoc:unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (muß > 0 sein). Dieser Wert kann zum Beispiel dazu dienen, stets eine Mindestenergiemenge für den Fall eines Stromausfalls im öffentlichen Netz in den Batterien vorzuhalten.

;upSoC:oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohen PV-Überschuß tendenziell zwischen 'lowSoC' und 'upSoC', in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuß bewegt sich der optimale SoC tendenziell zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.

;maxSoC:maximaler Mindest-SoC, d.h. der SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht werden muß um den Ladungsausgleich im Speicherverbund auszuführen. Die Angabe ist optional (muß <= 100 sein, default: 95)

;stepSoC: Optionale Schrittweite zur optimalen SoC-Berechnung (Battery_OptimumTargetSoC_XX) in %. Mit der Angabe 'stepSoC=0' wird das SoC-Management deaktiviert und Battery_OptimumTargetSoC_XX auf den Wert 'lowSoC' gesetzt. '''Hinweis:''' Die Beziehung 'careCycle * stepSoC = 100' sollte eingehalten werden! Wert: 0..5, default: 5

;careCycle:maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC' auftreten sollte. Anders formuliert legt careCycle fest, alle wieviel Tage mindestens einmal maxSoC erreicht werden sollte. Die Angabe ist optional. (default: 20)

;lcSlot: Es wird ein tägliches Zeitfenster festgelegt, in dem die Ladesteuerung des Moduls für diese Batterie aktiv sein soll. Außerhalb des Zeitfensters wird die Batterieladung mit voller Leistung freigegeben. Das SoC-Management der Batterie ist davon nicht betroffen. Wert: <hh:mm>-<hh:mm>, default: ganztägig

;loadAbort: definiert eine vom Anwender gewünnschte Bedingung für einen generellen Ladeabbruch und Wiederfreigabe der Lademöglichkeit. Die Abbruchbedingung ist erfüllt, wenn der angegebene SoC1 (%) erreicht bzw. überschritten ist '''UND''' die angegebene Ladeleistung <MinPwr> (W) unterschritten wurde -> Reading Battery_ChargeAbort_XX=1. Fällt der aktuelle SoC wieder unter den SoC2, wird Battery_ChargeAbort_XX=0 gesetzt. Ist SoC2 nicht angegeben, gilt SoC2=SoC1.

;loadStrategy: Abhängig von der gewählten Ladestrategie wird die Prognose der Batterieladung und ggf. die Generierung der Steuerreadings beeinflusst. Die Angabe ist optional. Wert: loadRelease | optPower | smartPower, default=loadRelease

;loadTarget: Optionaler Ziel-SoC in % für die Berechnung der Ladefreigabe bzw. der optimalen Ladeleistung. Der Zielwert ist eine kalkulatorische Rechengröße. Der reale SoC kann situativ in Grenzen über- oder unterschritten werden. Der höhere Wert aus Reading Battery_OptimumTargetSoC_XX und 'loadTarget' hat für die Berechnung Vorrang. Wert: 0..100, default=100. In loadTarget kann eine Zielzeit angegeben werden, wann der Ziel-SoC erreicht werden soll. Die optimale Ladeleistung wird entsprechend angepasst. Die Zeitangabe als positive Ganzzahl ist ein Absolutwert (Stunde), in der der Ziel-SoC erreicht sein soll. Ein negativer Integer (z.B. -3) besagt, dass drei Stunden vor dem [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Bestimmung_von_Sonnenaufgang_und_Sonnenuntergang|Sonnenuntergang]] des aktuellen Tages der Ziel-SoC erreicht sein soll. D.h. negative Zahlen sind Relativangaben. Generell wird der Ziel-SoC zur Wunschzeit nur dann erreicht sein, wenn genügend PV-Leistung verfügbar ist.

;safetyMargin: Bei der Berechnung der Ladefreigabe und optimierten Ladeleistung werden Sicherheitszuschläge auf den prognostizierten Ladungsbedarf berücksichtigt. Abweichend vom Default können mit diesem Parameter individuelle Sicherheitszuschläge getrennt für die Berechnung der Ladefreigabe und optimierten Ladeleistung angegeben werden. Der erste Wert ist der Zuschlag bei der Berechnung der Ladefreigabe, der zweite Wert der Zuschlag bei der Berechnung der optimierten Ladeleistung. Beide Angaben sind Prozentwerte von 0..100.

;weightOwnUse: Optionale Gewichtung der stündlichen Verbrauchsprognose als zusätzlich verwendbaren Anteil zur Batterieladung in %. Technisch wird der verfügbare PV-Überschuß zur Berechnung der optimierten Ladeleistung erhöht indem der kalkulierte Verbrauch um den angegebenen Prozentsatz gesenkt wird. Wert: 0..100 default: 0

Alle SoC-Werte sind ganze Zahlen in %. Dabei gilt:

lowSoc < upSoC < maxSoC

==== Erläuterung der Batterie-Steuerungsreadings ====

Für die Steuerung des Batteriesystems gibt es im SolarForecast einen Satz an Readings, die unterschiedliche Zustände signalisieren und für entsprechende Steuerungsaufgaben bezüglich der Batteriesysteme eingesetzt werden können. In den nachfolgenden Abschnitten werden diese Zusammenhänge noch dataillierter beschrieben.

;Hinweis: SolarForecast stellt lediglich Steuerungsinformationen zur Verfügung. Die Umsetzung des Eingriffs in das Batteriesystem erfolgt durch den Anwender selbst über entsprechende Skripte. In den thematischen Abschnitten werden Beispiele für solche Steuerungsskripte vorgestellt.

Alle erstellten Readings gelten für ein Batteriesystem, es können mehrere Batteriesysteme in SolarForecast integriert sein. Die Endung ''XX'' der Readings beschreibt die Nummer des Batteriesystems und korrespondiert mit der Endung des entsprechenden Attributes ''ctrlBatSocManagementXX'' bzw. ''setupBatteryDevXX''.

;Battery_OptimumTargetSoC_XX: Mit den im Attribut ''ctrlBatSocManagementXX'' hinterlegten Parametern unter Berücksichtigung von PV- und Verbrauchsprognosen wird ein optimaler SOC-Wert errechnet. Dieser Wert dient zur Einstellung des unteren SOC des Batteriesystems.

;Battery_ChargeRequest_XX: Dieses Reading signalisiert mit 1 eine Anforderung zur Zwangsladung der Batterie um die Batterie vor Schäden zu schützen (wenn der SOC unter ctrlBatSocManagementXX->lowSoc gefallen ist) oder wenn der aktuelle SOC unter den berechneten Mindest-SOC gefallen ist.

;Battery_ChargeUnrestricted_XX: Dieses Reading kann den Wert '''0''' oder '''1''' einnehmen. Ist der Wert 0, sollte die Batterie nur geladen werden, wenn der im Attribut ''plantControl->feedinPowerLimit'' definierte Wert überschritten wird. Ist der Wert 1, sollte die Batterie mit der vollen zur Verfügung stehenden Ladeleistung angesteuert werden, um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten. Der Fokus der Steuerung mit diesem Reading ist es, die Speicherkapazität der Batterie optimal zur Verhinderung der Überschreitung von Einspeiselimits einzusetzen und dennoch einen maximal möglichen SoC am Tagesende zu erreichen. (siehe das beschriebene [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Berücksichtigung_einer_Wirkleistungsbegrenzung|Nutzungsbeispiel]])

;Battery_ChargeOptTargetPower_XX: Dieses Reading enthält einen Richtwert für die optimierte Ladeleistung für jede Batterie. Die Aufladung wird prognosegeführt über den gesamten Tag verteilt, wobei der Fokus auf eine kontinuierliche, aber möglichst niederige Ladeleistung gelegt wird. (siehe diesen [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|Abschnitt]])

;Battery_ChargeAbort_XX: Im Attribut ''ctrlBatSocManagementXX'' kann mit dem Schlüssel ''loadAbort'' eine Bedingung definiert werden, bei deren Eintritt die Ladung der Batterie abgebrochen werden soll. In diesem Fall wird ''Battery_ChargeAbort_XX=1'' gesetzt. Mit einem entsprechenden Befehl kann der Anwender das Batteriesystem anweisen den Ladevorgang abzubrechen.

;Battery_TargetAchievable_XX: Diese Reading enthält einen Boolean Wert 0|1 und signalisiert ob der im Attribut '''ctrlBatSocManagementXX->loadTarget''' gesetzte Ziel-SoC lt. Prognose am aktuellen Tag tatsächlich erreicht werden kann.

 

==== Nutzung des Batterie SOC-Management ====

Oftmals wird durch die Anlagenhersteller ein hoher statischer SOC eingestellt bzw. empfohlen, der eine längere Verharrungszeit auf einem tiefen SOC-Wert verhindern soll. Allerdings wechseln sich in auch in den Herbst-, Frühlings- und Wintermonaten Zeiten mit wenig PV-Erzeugung mit Phasen stärkerer Solarstrahlung bei klarem Himmel und Sonnenschein ab.

Ein statischer SOC würde dazu führen, dass in den erwähnten Phasen zuviel Energie in das öffentliche Netz eingespeist wird. Dies soll verhindert werden da die wertvolle Energie besser im eigenen Netz gespeichert und in Dunkelphasen verwendet werden kann. Andererseits soll die Batterie nicht zu lange auf einem tiefen SOC verbleiben und außerdem in gewissen Abständen auf einen so hohen SOC geladen werden der den internen Zellausgleich ermöglicht.

Die SOC Kalkulationsroutine des Moduls errechnet unter Berücksichtigung des prognostizierten PV-Ertrages der kommenden Tage, des aktuellen SOC und der im Attribut '''ctrlBatSocManagementXX''' (nachfolgend beschrieben) angegebenen Steuerparameter den Vorschlag für eine optimale SOC-Einstellung. Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.

Durch das Modul selbst findet keine Steuerung der Batterie statt. Es stellt entsprechende Readings zur Verfügung:

::* das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen SoC.

::* das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SoC unter den optimalen SoC gefallen ist. In diesem Fall sollte die Batterie, unter Umständen mit Netzstrom, zwangsgeladen werden.

Die Readings können zur Steuerung des SoC (State of Charge) sowie zur Steuerung des verwendeten Ladestroms der Batterie verwendet werden.

Die Ermittlung des optimalen SOC erfolgt nach folgender Logik:

# Ausgehend von 'lowSoc' wird der Mindest-SoC kurz vor Sonnenuntergang um 5% inkrementiert sofern am laufenden Tag 'maxSoC' nicht erreicht wurde und die PV-Prognose keinen hinreichenden Ertrag des kommenden Tages vorhersagt. 
# Wird 'maxSoC' (wieder) erreicht, wird Mindest-SoC um 5%, aber nicht tiefer als 'lowSoc', verringert. Ist der berechnete Mindest-SoC größer als 'upSoc', wird der Mindest-SoC auf 'upSoc' gesetzt. 
# Mindest-SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages von der Batterie aufgenommen werden kann. Mindest-SoC wird typisch auf 'upSoc' und nicht tiefer als 'lowSoc' verringert. 
# Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle' Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten 'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Zeitpunkt rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut. 
# Im fünften Schritt werden die Grenzen 'lowSoc' und 'upSoc' berücksichtigt. 
# Im letzten Schritt erfolgt Generierung des Readings '''Battery_ChargeRequest_XX''' zur Signalisierung einer eventuell empfohlenen Zwangsladung auf den berechneten Min-SoC.

Bei sehr wenig Erzeugungungsprognose, d.h. wenn sich der berechnete Min-SoC oberhalb von 'upSoC' bewegt, wird 'upSoC' eingestellt. Liegt der berechnete Min-SoC unterhalb von 'upSoC', ist jedoch größer als 'lowSoC', wird der berechnete SOC im Reading '''Battery_OptimumTargetSoC_XX''' eingestellt. Somit eignet sich die Angabe im Schlüssel 'upSoC' um in Zeiten geringer Solarenergieerzeugung die Batterie für eine Notstromerzeugung auf mindestens diesem Wert zu halten. Sollte die PV-Prognose kurzfristig einen größeren Ertrag vorhersagen als die Batterie durch die Einhaltung von 'upSoC' aufnehmen kann, wird der Min-SoC unter 'upSoC' abgesenkt um möglichst allen PV-Überschuß in der Batterie zu speichern und somit dem Eigenverbrauch zuzuführen.

Der berechnete Mindest-SoC ist immer nur ein unterer Grenzwert. Die Batterie kann durch Ladevorgänge natürlich jederzeit einen höheren als den im Reading '''Battery_OptimumTargetSoC_XX''' dargestellten optimalen SoC haben. Der optimale SoC sollte nicht unterschritten werden um die oben genannten Zusammenhänge abbilden zu können.

🎯 '''Kurzfazit: Was beschreibt Battery_OptimumTargetSoC_XX?''' 

Battery_OptimumTargetSoC_XX definiert den optimalen Ziel‑SoC, den die Batterie erreichen bzw. nicht unterschreiten sollte, um prognostizierte PV‑Überschüsse aufzunehmen, ausreichende Energiereserven bereitzuhalten und die erforderlichen Pflegezyklen sicherzustellen. Der Wert bezieht sich dabei nicht auf die physikalischen Eigenschaften der Batteriezellen, sondern ergibt sich ausschließlich aus den Steuerungszielen des Moduls – basierend auf den eingestellten Parametern und den prognostizierten Umweltfaktoren.

 
===== Die dynamische SOC Steuerung mit Umsetzungsbeispiel =====
Das Modul bietet eine Unterstützung zur automatisierten Einstellung eines optimalen SoC Wertes.

Ziel ist es, den Minimum SoC in Abhängigkeit der zu erwartenden Solarerträge des aktuellen und des folgenden Tages so einzustellen, dass der prognostizierte Solarertrag von der Batterie aufgenommen werden kann. Die Einspeisung in das öffentliche Netz soll minimiert werden.

Weiterhin soll ein unterer SoC nicht unterschritten, sowie ein oberer Minimum SoC im Normalfall nicht überschritten werden. Der obere Grenzwert stellt sicher, dass die Batterie mindestens bis zu diesem Wert wieder entladen werden kann. Dadurch bleibt innerhalb der Batterie immer genügend Kapazität verfügbar um unvorhergesehene PV Energie aufnehmen zu können.

Aktiviert wird die Unterstützung der Batteriesteuerung durch das Setzen des Attributes '''ctrlBatSocManagementXX''' z.B. mit diesen Angaben:

ctrlBatSocManagementXX lowSoc=x upSoC=x maxSoC=x careCycle=x

so zum Beispiel:

ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20

Dabei steht 'XX' für die Nummer der Batterie, welche mit dem Attribut setupBatteryDevXX korrespondiert.
Ist dieses Attribut gesetzt, werden Steuerungs-Readings erstellt, die der Nutzer auswerten und seine Batterieanlage z.B. via notify oder DOIF steuern kann. 
Das Reading '''Battery_OptimumTargetSoC_XX''' enthält den vom Modul berechneten optimalen Mindest-SoC.
Das Reading '''Battery_ChargeRequest_XX''' wird auf '1' gesetzt, wenn der aktuelle SOC unter den optimalen SOC bzw. minimalen SOC gefallen ist.

Die Schlüssel '''lowSoc''' und '''upSoC''' sind die unteren und oberen Grenzen, zwischen denen sich der Minimum SoC im normalen Betrieb bewegen soll.
Der Schlüssel '''maxSoC''' stellt eine Ladungsgrenze dar, die mindestens alle X (careCycle) Tage erreicht werden soll. Zu diesem Zweck errechnet das Modul die Anzahl der nötigen Erhöhungen der Minimum Batterieladung von 5% pro Tag um ausgehend vom aktuellen SoC-Level. Der resultierende Minimum SoC Wert wird entsprechend angepasst. Wurde der einstellte maxSoC Level erreicht, startet der Wartungszyklus (careCycle) erneut. 
Der maxSoC in Verbindung mit dem durch '''careCycle''' definierten Zyklus soll sicherstellen, dass der Batterieverbund in regelmäßigen Abständen einen Ladungsausgleich vollziehen kann.

Durch die Modullogik erfolgt eine 5 protentige Anhebung des Minimum SoC wenn am Vortag maxSoC nicht erreicht wurde. Die Anhebung erfolgt aber nicht über upSoC. upSoC ist die obere Grenze des Minimum SoC. Wird am Vortag mindestens die maxSoC Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als lowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die erwartete PV Erzeugung des aktuellen und folgenden Tages 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 laden.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem dauerhaften tiefen SoC geschützt.

 
===== Umsetzungsbeispiel =====

Wie das Reading '''Battery_OptimumTargetSoC_XX''' genutzt werden kann, wird am Beispiel einer Victron Batterieanlage gezeigt. Die Anlage wird durch Cerbo GX Gerät gesteuert. Der Cerbo GX ist per MQTT2 in FHEM eingebunden. Umgesetzt ist die Steuerung der Batterie '01', d.h. die Angabe 'XX' ist durch '01' ersetzt.

Die folgende kleine Logik ist in einem '''99_mySolarForecastUtils.pm''' File eingebaut und wird regelmäßig mit

batSocChargeMgmnt ('<Name SolarForecast Device>');

aufgerufen. Der Aufruf erfolgt durch Angabe der Routine im Attribut '''ctrlUserExitFn''' des SolarForecast Devices:

<pre>
{
# Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
::batSocChargeMgmnt ($name);
return;
}
</pre>

Die Routine wird dadurch automatisch am Ende jedes Zyklus (siehe Attribut plantControl->cycleInterval) ausgeführt.
Um die SOC Managementfunktion nach Bedarf ein- bzw. ausschalten zu können wird zunächst im SolarForecast Device ein userattr zur Steuerung der SOC-Logik angelegt:

attr <Device> userattr userFn_BatterySoCManagement:ein,aus

Die Perl Routine '''batSocChargeMgmnt''' ist wie folgt aufgebaut:

<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $bn = '01'; # Batterienummer (evtl. im Aufruf mitgeben)
my $hash = $defs{$name};

my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen

my $maxcspc = 105; # max. Ladestrom (A) für Victron MPII Verbund
my $preduce = FHEM::SolarForecast::BatteryVal ($name, $bn, 'bpinreduced', $maxcspc); # reduzierte Ladeleistung aus Bat-Konfig (W)
my $actmcc = ReadingsNum ($vicsets, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)

## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');

if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_'.$bn, 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_'.$bn, 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}

if ($bcrq && $surp < 1000) { # max. Ladestrom (A) b. Battery_ChargeRequest
$load = $preduce / 48; # bei 48V Batteriesystem
}
else {
$load = $maxcspc;
}
}

## Einstellung MPII Verbund MaxChargeCurrent
##############################################
if ($actmcc && $load != $actmcc) {
CommandSet (undef, "$vicsets MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vicsets set }.
qq{from old $actmcc A to $load A});
}

readingsSingleUpdate ($hash, 'userFn_MPII_MaxChargeCurrent_set', $load, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>

Ist im SolarForecast Device das Reading '''Battery_ChargeRequest_01''' gesetzt, ist der aktuelle SOC kleiner als der optimale SOC und die Batterie wird (eventuell aus dem öffentlichen Netz) geladen. Das kann automatisch durch den Cerbo GX bzw. in anderen Anlagen durch einen entsprechenden Befehl erfolgen.
Damit die Netzbeladung nicht mit der vollen Ladestromstärke geschieht, wird der Ladestrom auf den gewünschten Wert (hier 21 A -> ca. 1000 W bei einem 48V System) reduziert sofern kein oder zu wenig PV-Überschuß vorhanden ist.

 

==== weitere mögliche Aspekte der SOC- und Batterieladesteuerung ====

SolarForecast liefert durch seine internen Logiken bereits sehr hilfreiche Signale zur Steuerung von Batteriesystemen in Form von Readings an. Abhängig von den individuellen Möglichkeiten der vorhandenen Anlage käme zum Beispiel zusätzlich zu einer Steurung des optimalen SOC oder der Zeitfenster für die Batterieaufladung auch eine Steuerung des Ladestroms bzw. der verwendeten Ladeleistung in Betracht.

'''Hintergründe:'''

* Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Langlebigkeit aus, was u.a. auch daran liegt, dass der Temperaturstreß im Akku bei langsamer Energiezuführung nur gering ist.

* Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.

* Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.

* Ein geringer Ladestrom kann zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.

* Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Weiterhin kann auch die Verweildauer oder die Begrenzung des SOC, auf den die Batterie maximal geladen werden soll, Gegenstand von Optimierungen sein.

Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass ''SOC=100%'' üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellenwert überschreitet, der – würde dieser Schwellenwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen könnte. Schädlich sind insbesondere häufige Nachladevorgänge bei Werten um die 100% SOC, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellenwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut. Dieser Wert muss nach einem erreichten SOC von 100% unterschritten werden, bevor überhaupt eine weitere Ladung erfolgt. Insbesondere in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit auf ''SOC=100%'' geladen wird. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

SolarForecast unterstützt die oben betrachtete Batteriesteuerung durch die optionale Angabe von '''loadAbort''' im Attribut '''ctrlBatSocManagementXX'''. Das in diesem Kontext erstellte Reading '''Battery_ChargeAbort_XX''' stellt die auswertbaren Steuerungsinformationen zur Verfügung.

 

==== PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung ====

[[Datei:Screenshot 2025-04-25 143910.png|right|thumb|400px|Batterie Popup "nur laden wenn Einspeiselimit überschritten"]]

Die in diesem Abschnitt beschriebene Ladestrategie '''loadRelease''' wird im Modul als '''Ladefreigabe''' bezeichnet.

Üblicherweise wird die Batterie geladen. sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer unter Umständen schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Energie (je nach Ausrichtung) in das öffentliche Netz. Dann könnte es zu einer Begrenzung der PV-Leistung durch einen Schwellenwert (z.B. 70%-Regelung) oder eventuell Zwangsabregelung durch den Netzbetreiber kommen.

Hintergrund dieser Erweiterung ist das Bestreben, eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einen Beitrag zur Netzstabilität zu leisten.
Das Ziel der Beladungssteuerung der Batterie ist es, die Ladung der Batterie über den Tag verteilt so zu steuern, dass die Batterie erst dann geladen wird, wenn durch den PV-Überschuß eine Netzeinspeisung erfolgen würde bzw. ein Grenzwert erreicht werden würde, der zu einer Abregelung der PV-Anlage führen könnte.
Es kann auch zu einer Zwangsabregelung durch den Netzbetreiber führen, was vermieden werden soll.

Die interne Kalkulationslogik erstellt zu diesem Zweck ein Reading '''Battery_ChargeUnrestricted_XX'''.
Dieses Reading gibt dem User ein Signal, ob zu der aktuellen Stunde der Ladevorgang der Batterie freigegeben (1) oder nicht freigegeben werden sollte (0). Die Freigabe zur Ladung bedeutet dass:

* '''Battery_ChargeUnrestricted_XX=1''' die Batterie mit ihrer vollen, oder der im Reading [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|Battery_ChargeOptTargetPower_XX]] angegebenen Ladeleistung angesteuert werden sollte um wie prognostiziert am Ende des Sonnentages die volle bzw. maximal mögliche Ladung zu erhalten..

* '''Battery_ChargeUnrestricted_XX=0''' die Batterie nur geladen werden sollte wenn der im Attribut plantControl->feedinPowerLimit definierte Wert überschritten wird

Ist keine Freigabe zur Ladung vorhanden, kann bzw. sollte dennoch eine Ladung der Batterie vorgenommen werden, sofern eine über dem im 
Attribut '''plantControl->feedinPowerLimit''' definierten Limit liegende Einspeiseleistung vorhanden ist. In diesem Status sollte die Batterie nur mit der Differenzleistung von vorhandener Einspeiseleistung und dem gesetzen Einspeiselimit geladen werden und damit das gesetzte Einspeiselimit einhalten ohne die Anlage abzuregeln. Ist die Batterie in einer Balkengrafikebene dargestellt, wird im Mouse-Over Popup die Battrie mit ''"nur laden wenn Einspeiselimit überschritten"'' gekennzeichnet.

Die Möglichkeiten der Batteriesteuerung sind stark von der individuellen Anlage abhängig und können hier nicht beschrieben werden. Ein Umsetzungsbeispiel mit einer Victron-Anlage mit Pylontech Batterie ist weiter unten dargestellt.

 
===== Aktivierung und Arbeitsweise =====

Die implementierte Logik zur optimierten Batterie Beladungssteuerung wird aktiviert, wenn folgende Kriterien erfüllt sind:

* der Schlüssel '''capacity''' in den setupInverterDevXX Atributen ist gesetzt
* das Attribut '''ctrlBatSocManagementXX''' für die jeweilige Batterie ist gesetzt
* der Schlüssel '''cap''' im Attribut setupBatteryDevXX der jeweiligen Batterie ist gesetzt

Die Logik arbeitet wie folgt:

;Der resultierende Schwellenwert der Wirkleistungsbegrenzung: der Gesamtanlage wird durch die Auswertung der in den Inverter-Attributen setupInverterDevXX gesetzen Schlüssel limit (optional) und capacity ermittelt. Inverter mit gesetztem Schlüssel feed = grid (deren Energie wird ausschließlich in das öffentlich Netz eingespeist) werden von der Betrachtung in diesem Kontext ausgeschlossen.

;Die benötigte Beladung bis zu maxSoC (im Attribut setupBatteryDevXX) : wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt. Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit erreicht UND noch genügend PV-Überschuß für eine Ladung auf ''maxSoC'' im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading '''Battery_ChargeUnrestricted_XX = 0'''. Die erreichte Qualität der Steuerungslogik ist stark von der Prognosequaliät abhängig. Um die Steuerung resilienter zu gestalten, wird per default ein Sicherheitsaufschlag von 50% auf die prognostizierte benötigte Ladeenenergie auf Stundenbasis einkalkuliert. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

;Wird das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose: zzgl. eines Sicherheitspuffers unterschritten, wird '''Battery_ChargeUnrestricted_XX = 1''' gesetzt. Der User kann darauf reagieren und den Batterie Ladevorgang aktivieren. Die Möglichkeiten der Aktivierung sind natürlich von der installierten Anlage abhängig. Das SolarForecast Device greift nicht in die Batteriesteuerung direkt ein.

Anders ausgedrückt erfolgt immer dann eine Ladefreigabe, wenn einer der nachfolgenden Sachverhalte ''wahr'' ist:

- die benötigte Ladeenergie (aller installierten Batterien) >= PV-Restüberschuß des Tages (Reading RestOfDayPVforecast) zzgl. Sicherheitsaufschlag

ODER

- der Zeitpunkt des PV-Erzeugungszenit des laufenden Tages überschritten ist (Reading Today_MaxPVforecastTime)

ODER

- wenn die aktuelle PV Leistung >= einer eventuellen Wechselrichter-Leistungsbegrenzung ist (Summe aller WR-Begrenzungen)

ODER

- wenn das BatSoc-Management _nicht_ aktiviert ist (nicht alle oben genannten Aktivierungskriterien erfüllt sind)

Sind mehrere Batterien installiert und durch das Management einer Batterie die Einhaltung der genannten Kriterien bzw. Sachverhalte erwirkt wird, bleiben die weiteren Batterien im Modus Ladefreigabe (Battery_ChargeUnrestricted_XX=1).

 

===== Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint =====

Ziel der Steuerung ist es abhängig vom Wert des Readings Battery_ChargeUnrestricted_XX (z.B. Battery_ChargeUnrestricted_01) die Ladung des angeschlossenen Batteriesystems zu aktivieren bzw. zu deaktivieren.
Das vorliegende Beispiel soll umzusetzen:

* Battery_ChargeUnrestricted_01 = 0 -> Batterie nicht aufladen bzw. nur laden wenn Einspeiselimit überschritten (Attribut plantControl->feedinPowerLimit)
* Battery_ChargeUnrestricted_01 = 1 -> Batterie aufladen

Der Grid Setpoint ist ein Parameter in den Victron Systemeinstellungen. Das Victron System wird den eingestellten Grid Setpoint versuchen einzuhalten und bei einem positiven Wert Energie aus dem Netz beziehen bzw. bei einem negativen Grid Setpoint Energie in das Netz einspeisen.

Normalerweise wird das Victron System die erzeugte PV Energie zunächst zur Deckung des Hausverbrauchs verwenden, ist dann noch ein PV Überschuß vorhanden, die Batterien aufladen und bei weiter vohandenen PV Überschuß diese Energie in das öffentliche Netz einspeisen sofern dem System eine Einspeisung erlaubt ist. Anderenfalls werden die Wechselrichter oder MPPT Smartloader heruntergeregelt bzw. limitiert.

In der Standardeinstellung ist beim Victron System ein Grid Setpoint von ca. 20 bis 50 Watt, d.h. das System strebt danach diese Vorgabe zu erfüllen zieht ständig Energie in diesem Bereich aus dem öffentlich Netz von einem gelegentlichen Überschwingen der Regelung abgesehen. Damit ein eventueller PV Überschuß nicht zum Laden der Batterie verwendet, sondern statt dessen in das öffentliche Netz eingespeist wird, muß der Grid Setpoint um diesen Betrag abgesenkt werden.

[[Datei:Screenshot 2025-02-24 114403.png|right|thumb|400px|Integration des Grid Setpoint-Managements in den Own_Spec-Bereich]]

Damit man später per Attribut bzw. über den [[#Formatierung_der_Inhalte_im_Bereich_"Graphic_Header_Own_Specification"|Own_Spec-Bereich]] die automatische Ladesteuerung über den Grid Setpoint ein- bzw. ausschalten kann, legen wir ein userattr an:

userattr <Name> userFn_GridSetpointManagement:ein,aus

Weiterhin sind einige Vorbereitungen im Device MQTT2_cerboGX_c0619ab34e08_settings vorzunehmen. Dieses Device ist im vorliegenden Beispiel ein in FHEM vorhandenes MQTT2_DEVICE, über das die Victron CerboGX Einstellungen zugreifbar sowie einstellbar sind. Die Vorgehensweise zur Erstellung des MQTT2_DEVICE ist hier nicht beschrieben und wird vorausgesetzt.

Damit ein entsprechender Set-Befehl zur Einstellung des Grid Setpoints vorhanden ist, werden folgende Attribute gesetzt:

attr MQTT2_cerboGX_c0619ab34e08_settings jsonMap Settings_CGwacs_AcPowerSetPoint_value:GridSetpoint
attr MQTT2_cerboGX_c0619ab34e08_settings setList GridSetpoint W/c0619ab34e08/settings/0/Settings/CGwacs/AcPowerSetPoint {"value":$EVTPART1}

Nach dieser Attributierung kann mit einem "''set MQTT2_cerboGX_c0619ab34e08_settings GridSetpoint <Wert>''" der Grid Setpoint eingestellt werden.

Das Attribut userFn_GridSetpointManagement kann nun im Perl Code ausgewertet werden um das Grid Setpoint-Management ein- bzw. auszuschalten.
Der nachfolgende Code wird in die Datei '''99_mySolarForecastUtils.pm''' eingefügt. Ist diese Datei nicht vorhanden, legen wir sie vorab als Kopie der ausgelieferten 99_myUtils.pm an.

<div class="mw-collapsible mw-collapsed">
'''Code Management Batterieladung über Victron Grid Setpoint ->''' <div class="mw-collapsible-content">
<syntaxhighlight lang="Perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen
###############################################################################

############################################################################
# Steuerung Start/Stop der Batterieladung über den Victron Grid Setpoint
############################################################################
sub gridSetpointMgmt {
my $name = shift;
my $hash = $defs{$name};

my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron Einstellungen
my $gspdef = 20; # Default Einstellung des Grid Setpoint
my $targetgsp = $gspdef; # Voreinstellung Grid Setpoint
my $neggspmax = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', 5000); # max. gewünschte Einspeiseleistung in Watt
$neggspmax = $neggspmax * -1;
my $gspm = AttrVal ($name, 'userFn_GridSetpointManagement', 'aus'); # Freischaltung des Grid Setpoint-Managements
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', $gspdef); # aktuelle Einstellung Grid Setpoint

if ($gspm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeUnrestricted_01', 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß

if (!$bcrq) { # Grid Setpoint absenken wenn keine ..
$targetgsp = $gspdef - $surp; # ..Batterie Ladefreigabe
$targetgsp = $neggspmax if($targetgsp < $neggspmax); # Begrenzung der Einspeiseleistung
}
}

if ($curgsp != $targetgsp) {
fhem ("set $vicsets GridSetpoint $targetgsp");
Log3 ($name, 3, qq{$name - userFn gridSetpointMgmt -> GridSetpoint in $vicsets set to $targetgsp});
}

readingsSingleUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $targetgsp, 0);

return;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>
</div>
</div>

Der Vergleich des Setpoints mit der Vorgabe von ''$neggspmax'' dient dazu die maximale Einspeiseleistung in das öffentliche Netz zu begrenzen. Ist diese Grenze erreicht, wird der noch verbleibende Überschuß in die Batterie geladen. Dadurch wird eine Abregelung der Anlage vermieden wenn der Schwellenwert ''$neggspmax''erreicht ist sofern die Batterie aufnahmefähig ist und nicht voll geladen ist.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an:

<pre>
attr <Name> ctrlUserExitFn {
::gridSetpointMgmt ($name);
}
</pre>

Zum Management des automatischen Grid Setpoint und der Anzeige des eingestellten Wertes wird das Attribut und die Readinganzeige in den Own_Spec-Bereich eingebunden, z.B.:

<pre>
attr <Name> graphicHeaderOwnspec #Settings
SetPoint Management:userFn_GridSetpointManagement
Grid Setpoint:GridSetpoint@MQTT2_cerboGX_c0619ab34e08_settings
</pre>

 

==== leistungsoptimierte Beladungssteuerung mit dem Fokus geringe Verlustleistung und Verschleiß ====

Über das Attribut ctrlBatSocManagementXX kann mit dem Schlüssel loadStrategy die Ladestrategie '''optPower''' oder '''smartPower''' eingestellt werden.
Das SF-Modul bietet ein weiteres Reading '''Battery_ChargeOptTargetPower_XX''' zur Batteriesteuerung an. Dieses Reading liefert eine kalkulierte optimale Ladeleistung in Watt.

Die in diesem Abschnitt beschriebene Ladestrategie '''optPower''' wird im Modul als '''optimierte Ladeleistung''', die Ladestrategie '''smartPower''' als '''zieloptimierte Ladeleistung''' bezeichnet.

Beide Strategien kalkulieren die Ladeleistung kontinuierlich neu und berücksichtigen dabei:

* die Prognose der PV-Erzeugung der nächsten Stunden und des (Rest-)Tages
* den prognostizierten Verbrauch auf Stunden- bzw. Tagesbasis
* eine eventuell mögliche Überschreitung des gesetzten Einspeiselimits (plantControl->feedinPowerLimit)
* die gesetzten Leistungsparameter der Batterie
* das Ziel, am Tagesende einen möglichst maximalen SoC der Batterie erreicht zu haben bzw. den eingestellten Ziel-SoC '''loadTarget'''
* die Effizienz der Batterieanlage (Einstellung '''setupBatteryDevXX->efficiency''')

Der Fokus der implementierten Logik liegt dabei auf einer kontinuierlichen Ladeleistung, die aber unter den oben genannten Gesichtspunkten möglichst (relativ) gering sein soll um den Batterieverschleiß und die Verlustleistung zu minimieren. Die im Reading angezeigte Ladeleistung kann mit geeigneten Mitteln direkt in die Leistungssteuerung der Batterie eingebracht werden. Natürlich kann die Leistung auch vorab in einen optimalen Ladestrom umgerechnet werden.

Da das Ergebnis der Kalkulation stark von den Prognosen abhängt, ist zur Erhöhung der Resilienz per Default ein Sicherheitszuschlag von 20% eingebaut. Dieser Wert kann mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' individuell angepasst werden.

Ist kein PV-Überschuß (mehr) vorhanden / prognostiziert oder das Ladeziel erreicht, erfolgt ein Rückfall der Ladeleistung im Reading Battery_ChargeOptTargetPower_XX auf den im Attribut '''setupBatteryDevXX->pinmax''' angegebenen Wert. Ist dieser Wert nicht gesetzt, erfolgt der Rückfall auf "Unendlich" (9223372036854775807).

Im Reading Battery_ChargeOptTargetPower_XX wird der Wert des Parameters '''setupBatteryDevXX->pinreduced''' gesetzt, wenn weniger Ladeleistung als pinreduced berechnet wurde (Einhaltung einer Mindestladeleistung) oder wenn der SoC der Batterie <= [[#Aktivierung_des_Batterie_SOC-_und_Lade-Managements|lowSoC]] beträgt.
Somit wird die Batterie bei einer Anforderungsladung bei Unterschreitung von lowSoC mit nur wenig Leistung aus dem Grid geladen falls es nötig sein sollte.
Es ist demzufolge ratsam den optionalen Parameter '''setupBatteryDevXX->pinreduced''' zu setzen, da ansonsten ebenfalls ein Rückfall auf '''setupBatteryDevXX->pinmax''' bzw. "Unendlich" erfolgt.

Beide Strategien, optPower und smartPower, setzen die zuvor beschriebene Arbeitsweise um.
Ergänzend wird bei der Ladestrategie '''smartPower''' die generelle Erreichbarkeit des Ladeziels bei der Festlegung der Ladeleistung berücksichtigt. Es führt dazu dass:

* die Ladeleistung im Reading Battery_ChargeOptTargetPower_XX auf einen tendenziell höheren Wert als bei der optPower-Strategie gesetzt wird, wenn/solange das eingestellte Ladeziel als unerreichbar kalkuliert wird
* bei kalkulierter Erreichbarkeit des Ladeziels der Sicherheitsaufschlag linear absenkend proportional zum Kehrwert des verfügbaren PV-Überschusses auf die Ladeleistung angewendet wird

Der nächste Abschnitt erläutert die smartPower Funktionen etwas eingehender.

 
===== smartPower - die zieloptimierte Ladeleistung =====
Die hinter smartPower liegende Anpassungslogik wird nachfolgend etwas näher beschrieben.
Ausgangspunkt ist das Ergbnis einer Ratio-Funktion aus dem (Rest)Tages-PV-Überschuß und benötigter Energie zur Erlangung des Batterie Ladeziels.

'''Lineare Interpolation zwischen pinmax und abgesicherter minpower''' 

'''Variablen'''

* '''P''': resultierende Leistung.
* '''pinmax''': maximale Ladeleistung.
* '''limpower''': Leistungslimit, d.h. Ladeleistungssollwert.
* '''r''': Verhältnis in Prozent (r = spday·100 / whneed).
* '''otpMargin''': Prozentwert der Bandbreite, über die die Absenkung linear verläuft (die Steilheit kann mit dem Attributwert ctrlBatSocManagementXX->safetyMargin im Device eingestellt werden).

Die Kennlinie der für smartPower eingesetzten Funktion ist stückweise definiert über das Verhältnis Ratio ''𝑟 = spday x 100 / <benötigte Ladeenergie bis Ziel>''.

* Für 𝑟 ≤ 100: ''𝑃 = pinmax'', Interpretation: Es ist viel Bedarf vorhanden bzw. Überschuss ≤ 100 % des Bedarfs → maximal laden.
* Für 𝑟 ≥ 100 + otpMargin: ''𝑃 = limpower ⋅ (1 + otpMargin / 100 )''
* Für 100 < 𝑟 < 100 + otpMargin: lineare Absenkung von '''P''' mit zunehmendem '''r''' für den Bereich 100 < 𝑟 < 100 + otpMargin. '''P''' wird bei 𝑟 = 100 gleich '''pinmax''' und bei 𝑟 = 100 + otpMargin gleich ''limpower ⋅ ( 1 + otpMargin/100 )'', Interpretation: Sobald der Überschuss über den Bedarf hinausgeht (ratio > 100), wird das Ladeleistungslimit schrittweise von pinmax Richtung limpower reduziert; die Reduktion erfolgt gleichmäßig über die Margin-Spanne.

'''Lineare Interpolation und Steigung'''

Die Differenz ''(pinmax − limpower)'' wird gleichmäßig auf die otpMargin-Prozentpunkte verteilt. Die Steigung der Geraden ist

<pre>
slope = − (pinmax − limpower) / otpMargin
</pre>

das heißt die Leistung sinkt um diesen Betrag pro Prozentpunkt von '''r'''.

Nach Umformung ist der Zusammenhang wie folgt darstellbar:

<pre>
𝑃 = pinmax − ( pinmax − limpower) ⋅ ((𝑟 − 100) / otpMargin)
</pre>

und ist äquivalent zu

<pre>
𝑃 = pinmax + ( 𝑟 − 100 ) ⋅ slope
</pre>

'''Numerisches Beispiel'''

* '''limpower''' = 1000 W, '''pinmax''' = 3000 W, '''otpMargin''' = 20
* Unterschied = 2000 W, Steigung = −2000/20 = −100 W/%
* Für '''r = 105''': 𝑃 = 3000 − 2000 ⋅ ( 5 / 20 ) = 3000 − 500 = 2500 W
* Für '''r = 120''' ergibt die Formel den abgesicherten Endwert 1200 W

Die Formel sorgt dafür, dass die Zielleistung stufenlos und vorhersehbar reduziert wird, wenn der relative Rest-Überschuss des Tages über 100% steigt, und erreicht bei Ende der otpMargin den geplanten abgesicherten Wert.

[[Datei:Ratio Kennlinie.png|right|thumb|200px|abfallend proportionale Anpassungsfunktion]]

In einem grafischen Diagramm stellt sich die abfallend proportionale Anpassungsfunktion der resultierenden Soll-Ladeleistung wie nebenstehend abgebildet dar. Dabei entspricht pow=100 dem jeweiligen pinmax Wert (hier 3000 W). So ist auch pow=0 mit dem abgesicherten Endwert (hier 1200 W) gleichzusetzen. Die Linie verläuft waagerecht bei pinmax solange das das Ratio r ≤ 100 % und knickt an r == 100 mit steigenden r nach unten. Es verringert sich pow linear von pinmax zu limpower zzgl. otpMargin.

Durch diese Maßnahmen wird eine flexible Lademöglichkeit bis pinmax erreicht, die sich bei unvorhergesehenen Aufklarungen mit starker Sonneneintrahlung bei ansonsten sehr bedeckten Himmel positiv auswirkt. Andererseits wird die Erhöhung der Ladeleistung weiter begrenzt, wenn viel PV-Überschuß in Verbindung mit einer generellen Erreichbarkeit des Ladeziels zum Ende des Tages prognostiziert ist. Man könnte die Ladestrategie '''smartPower''' in ihrer Wirkung als einen Mix aus '''optPower''' und '''loadRelease''' ansehen.

Zusammenfassend ist optPower vorwiegend für die Nutzergruppe geeignet, die eine tendenziell sparsamere Ladeleistung bevorzugen und dafür bereit sind eventuelle "Verluste" in Form von Einspeisung zu akzeptieren. 
Demgegenüber eignet sich das aggressivere smartPower für Anwender, die bei niedrigen PV-Erträgen bewusst das Maximum an Batterieladung anstreben und dafür in Kauf nehmen, dass Ladeleistungen weniger knapp kalkuliert sind.

 

===== Unterstützung des Modus "Eigennutzung" bei Hybrid-Wechselrichtern =====
Viele Hybrid-Wechselrichter verteilen die zur Verfügung stehende PV-Leistung nach folgendem Prioritäten, wenn der (übliche) Modus "Eigennutzung" aktiviert ist:

# Nutzung der Leistung zur Deckung des Hausverbrauchs,
# Nutzung der Leistung zur Ladung des bzw. der angeschlossenen Speicher.
# Einspeisung der Leistung in das öffentliche Netz.

Da in aller Regel die Leistung, mit der ein angeschlossener Speicher geladen wird, limitiert werden kann, lassen sich die o.g. Priorität bzgl. des Speichers zugunsten einer Überschusseinspeisung aufweichen. Ein entstehender "Überschuss" steht also ggf. nur deshalb zur Verfügung, weil die Ladeleistung des Speichers begrenzt wurde.

Ab Version 1.58.6 bietet SolarForecat die Möglichkeit, prognostizierte Verbräuche nicht mehr komplett bei der Bestimmung der ''optimalen Ladeleistung'' zu berücksichtigen, sondern nur noch zu einem prozentualen Anteil von 0..100 %. Hierzu muss der Attribut-Schlüssel '''ctrlBatSocManagementXX->weightOwnUse=<Percentage>''' entsprechend gesetzt werden.

So führt beispielsweise weightOwnUse=100 dazu, dass bei der Berechnung der optimalen Ladeleistung prognostizierte Verbräuche nicht mehr berücksichtigt werden indem sie bei der Bestimmung des stündlichen PV-Überschusses unberücksichtigt bleiben. Eine derartige Einstellung kann z.B. sinnvoll sein, wenn alle ansonsten täglich laufende Verbraucher zugunsten einer Batterieladung ausgeschaltet werden können.

Ein Wert von zum Beispiel weightOwnUse=30 lässt 30% der stündlichen Verbrauchslast unberücksichtigt, sodass sich der kalkulierte PV-Überschuß pro Stunde um 30% des prognostizierten Verbrauchs erhöht. Da die Berechnung der optimierten Ladeleistung mit dem zur Verfügung stehenden PV-Überschuß gewichtet erfolgt, würde sich die kalkulierte Ladeleistung in den meisten Fällen ebenfalls um einen gewissen Betrag erhöhen sofern andere Faktoren dies nicht verhindern. Das kann beispielweise der Fall sein, wenn die kalkulierte Ladeleistung zu gering ist und automatisch aif mindestens '''setupBatteryDevXX->pinreduced''' angehoben wurde.

 

==== Welche Ladestrategie soll ich wählen? - eine Möglichkeit zur Best-Practice Findung mit Codebeispiel ====

In den vorangegangenen Abschnitten wurden die verschiedenen Möglichkeiten zur Steuerung der Batterieladung und dem SoC vorgestellt. Diese Steuerungsvarianten optimieren die Arbeitweise der Batterie, haben aber jeweils einen eigenen Fokus auch wenn es gewisse Überschneidungen gibt.

Die Steuerungsvarianten lassen sich folgendermaßen klassifizieren:

# Steuerung der Batterieladung über eine Ladefreigabe, die durch bestimmte Indikatoren festgelegt wird. Diese Variante ist in [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Berücksichtigung_einer_Wirkleistungsbegrenzung|diesem]] Abschnitt beschrieben.
# Steuerung der Batterieladung durch eine optimierte maximale Ladeleistung. Diese Variante ist in [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#leistungsoptimierte_Beladungssteuerung_mit_dem_Fokus_geringe_Verlustleistung_und_Verschleiß|diesem]] Abschnitt dargelegt. Zu dieser Variante gehören die Strategien ''optPower'' sowie ''smartPower''. Die Unterschiede beider Strategien sind ebenfalls in dem verlinkten Abschnitt beschrieben.

Die '''Variante 1.)''' gibt die Ladung der Batterie frei wenn der (verbleibende) PV-Überschuß des Tages kleiner oder gleich dem Ladungsbedarf der Batterie ist um einen SoC von 100% bzw. den maximal möglichen SoC am Ende des Tages zu erreichen. Dadurch wird die in der Batterie vorhandene freie Kapazität so lange wie möglich der Einhaltung von besonderen Grenzwerten, z.B. des Einspeiselimits (plantControl->feedinPowerLimit), vorbehalten. Nebeneffekt ist, dass plötzlich und unerwartet auftretende hohe Erzeugungsleistungen in die Batterie geladen werden können und nicht unerwünscht in das öffentliche Netz eingespeist werden.

Die '''Variante 2.)''' lässt die Batterie kontinuierlich laden, wobei die Ladeleistung auf ein optimiertes Minimum reduziert wird ohne das Ziel, einen maximalen SoC am Tagesende zu erreichen, zu ignorieren. Dadurch wird die Batterie schonend, mit möglichst wenig Verlustleistung und verschleißarm geladen. Die Vorhaltung der freien Kapaziäten der Batterie sind in dieser Variante nicht die Prämisse. Die Einhaltung des gesetzten Enispeiselimits wird auch in dieser Variante beachtet sofern es der Ladezustand der Batterie zulässt. Technisch bedingt kann diese Variante nur ungenügend auf unerwartete PV-Überschüsse reagieren, was zu einer Einspeisung in das öffentliche Netz oder im ungünstigsten Fall zur Abregelung der Anlage führen kann. Mit dem Attribut '''ctrlBatSocManagementXX->safetyMargin''' kann man diesem negativen Aspekt in gewissem Maße entgegenwirken.

Ausgehend von diesen unterschiedlichen Optimierungszielen bietet sich die Variante 1.) vorwiegend in den Übergangs- und Wintermonaten an. Durch die beschriebenen Eigenschaften dieser Variante ist bei tendeziell weniger PV-Überschuß über den Tag die Ladung der Batterie komplett freigegeben, wodurch bei plötzlich auftretenden sonnige Abschnitten und Aufklarungen die Batterie sofort mit dem verfügbaren PV-Überschuß geladen wird. Auch eine Einspeisung über das Einspeiselimit hinaus kann verhindert werden. In der übrigen Zeit wird die Ladeleistung durch den verfügbaren PV-Überschuß begrenzt.
Weiterhin soll der SoC nicht dauerhaft tief absinken und ebenfalls nicht auf einem zu hohen Level verharren was auch einer maximal möglichen Energiespeicherung an sonnigen Tagen entgegenwirken würde.
In dieser Zeit ist die Nutzung der Kombination von [[SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Nutzung_des_Batterie_SOC-Management|SoC-Management]] und Variante 1.) wohl am Besten geeignet um die Ziele zu verwirklichen sowie Notreserven in den Batterien vorzuhalten.

In den Sommermonaten hingegen ist üblicherweise sehr viel PV-Energie und Überschuß vorhanden. In dieser Periode würden die Batterien mit sehr hoher Leistung sehr zeitig am Tag vollgeladen. Die Variante 1.) ist im Prinzip ebenfalls gut geeignet den Zeitpunkt der Vollladung hinauszuzögern, jedoch erscheint die Varinte 2.) in dieser Zeit besser geeignet mit einer über den gesamten Tag verteilten moderaten Ladeleistung den Ziel-SoC zu erreichen. Auch diese Variante versucht eine Überschreitung des Einspeiselimits zu verhindern sofern der Ladezustand der Batterie dies ermöglicht.

===== Codebeispiel zur Steuerung eines in ein Victron System eingebundenen Pylontech Batteriestack via Cerbo GX =====

Das '''nachfolgende Codebeispiel''' bietet die Möglichkeit über ein Attribut die Ladevariante auszuwählen, über ein weiteres Attribut die SoC-Steuerung zu aktivieren/deaktivieren, integriert die Ladesteuerung für eine Batterie-Anforderungsladung bei Unterschreitung von ctrlBatSocManagementXX->lowSoc, und ergänzt eine zellspannungsbasierte Ladestrom-Drosselung ('''TermVoltageTaper''') zum Schutz der Einzelzellen nahe Vollladung.

Die verwendeten Devices werden über eine MQTT Verbindung CerboGX -> FHEM erzeugt und aktualisiert. Der Code wurde mit Venus OS Version v3.72 auf Cerbo GX getestet bzw. mit dieser Version produktiv eingesetzt.

Die gesteuerte Batterieanlage besteht aus:
* 3 x Victron MultiPlusII 3000/48
* Steuergerät CerboGX (in FHEM über MQTT eingebunden)
* einem Batteriestack bestehend aus mehreren Pylontech US3000C (wird durch CerboGX gesteuert und über die separate MQTT-Verbindung als Batteriestack-Device eingebunden)
* zusätzlich, für TermVoltageTaper: das FHEM-Modul '''PylonLowVoltage''', welches je US3000C-Pack über RS485 die 15 Einzelzellspannungen ausliest (Readings ''cellVoltage_01'' … ''cellVoltage_15'')

Zur Umschaltung bzw. Auswahl der Ladestrategie und des SoC-Managements werden zwei User-Attribute im SolarForecast Device angelegt.
<pre>
attr ... userattr userFn_BatterySoCManagement:Ein,Aus userFn_BatteryLoadManagement:Aus,loadRelease,optPower,smartPower
</pre>

Im Code werden diese Attribute ausgewertet. Das nachfolgende Script vereint folgende Funktionalitäten:
* die Aktivierung/Deaktivierung des SoC-Managements via Attribut userFn_BatterySoCManagement
* die Auswahl der Ladestrategie oder Deaktivierung der Ladesteuerung via Attribut userFn_BatteryLoadManagement
* Integration einer Anforderungsladung bei Signalisierung durch Reading Battery_ChargeRequest_XX
* eine zellspannungsbasierte Sicherheitsdrosselung des Ladestroms nahe Vollladung ('''TermVoltageTaper''', siehe unten)
* Generierung von Readings userFn_Victron_GridSetpoint_set und userFn_MPII_MaxChargeCurrent_set zur Dokumentation der eingestellten Soll-Werte, sowie userFn_LoadController_* zur Dokumentation des TermVoltageTaper-Verhaltens

Bei der Nachnutzung des Scripts sind zunächst die '''Konstanten''' und die verwendeten Devices (z.B. MQTT2_cerboGX_c0619ab34e08_settings) sowie deren Readings im Block '''aktuelle Indikatoren''' anzupassen. Für TermVoltageTaper sind zusätzlich die drei Zellspannungs-Parameter (siehe unten) an die eigene Zellchemie und die eigenen Messwerte anzupassen.

Das Script wird in die Datei '''99_mySolarForecastUtils.pm''' eingetragen und im SolarForecast Attribut '''ctrlUserExitFn''' hinterlegt:
<pre>
attr ... ctrlUserExitFn {
::batLoadMgmnt ($name, '01');
# ::batLoadMgmnt ($name, '02'); # optional für eine weitere Batterie '02'
# ::batLoadMgmnt ($name, '0X'); # optional für weitere Batterien
}
</pre>

Mit diesem Script ist der Nutzer in der Lage, das Batterie Lademanagement entsprechend seiner Motivation und gegebenenfalls abhängig von der Jahreszeit umzustellen und das Ergebnis bzw. die Zielerreichung zu testen.

Das Attribut '''userFn_BatteryLoadManagement''' selektiert die gewünschte Ladestrategie:
;Aus: das Lademanagement ist ausgeschaltet

;loadRelease: das Lademanagement Variante 1.) Ladestrategie Ladefreigabe ist aktiviert

;optPower: das Lademanagement Variante 2.) Ladestrategie optimierte Ladeleistung ist aktiviert

;smartPower: das Lademanagement Variante 2.) Ladestrategie zieloptimierte Ladeleistung ist aktiviert

Die in SolarForecast eingestellte Ladestrategie (Attributschlüssel '''ctrlBatSocManagement01->loadStrategy''') wird in dem Steuerungscode in jedem Zyklus aktuell ausgelesen und berücksichtigt.

Hat man die individuell passende Management-Strategie gefunden, bietet sich auch eine automatische (zum Beispiel durch einen Kalender oder Sonnenstand (Elevation) zur Mittagszeit) Umschaltung der Ladestrategie an. Die Unterschreitung der Elevation unter einen bestimmten Wert würde den Beginn des Winterhalbjahres und reverse Überschreitung den Beginn des Sommerhalbjahres kennzeichnen. Entsprechend würde dann die gewünschte Ladestrategie selektiert. Alternativ könnte auch die PV-Überschußprognose für den aktuellen Tag über das Reading ''Today_PVforecast'' für eine Entscheidung bzgl. der Ladestrategie herangezogen werden.

Das SoC-Management kann über das gesamte Jahr aktiviert bleiben, hat jedoch nach bisherigen Erfahrungen nur im Winterhalbjahr eine starke Relevanz.

'''TermVoltageTaper - Zellschutz nahe Vollladung'''

'''Motivation'''

Ein hoher SoC-Stand allein ist bei LiFePO4-Zellen unkritisch. Problematisch sind vielmehr die bei ungünstigem Ladeverlauf auftretenden hohen '''Einzelzellspannungen''' nahe Vollladung – ein globales, SoC-basiertes Lademanagement (wie es SolarForecast über ''Battery_ChargeOptTargetPower_XX'' liefert) kennt die Streuung der Einzelzellen innerhalb eines Batteriestacks nicht und kann daher eine ausbrechende Einzelzelle nicht erkennen. TermVoltageTaper schließt diese Lücke, indem es den von SolarForecast vorgegebenen Ladestrom in der kritischen Endphase anhand der '''höchsten gemessenen Einzelzellspannung im gesamten Stack''' begrenzt. Die Lösung basiert auf dem Konzept des Forenusers '''Parallix''' (siehe [https://forum.fhem.de/index.php?msg=1359855 #5467] und [https://forum.fhem.de/index.php?msg=1358509 #5199]).

'''Physikalischer Hintergrund: OCV-Kurve und Kniezone'''

Die '''OCV-Kurve''' (Open Circuit Voltage) beschreibt die Ruhespannung einer Zelle in Abhängigkeit vom SoC – also die Spannung ohne fließenden Strom, nach ausreichender Relaxationszeit. Bei LiFePO4-Zellen verläuft diese Kurve zwischen ca. 20 % und 90 % SoC sehr '''flach''': Die Spannung ändert sich über einen weiten SoC-Bereich kaum, weshalb eine SoC-Schätzung über die Spannung in diesem Bereich unzuverlässig ist (die BMS-SoC-Schätzung basiert daher primär auf Coulomb-Zählung).

Erst kurz vor Vollladung – der '''Kniezone''' – steigt die Spannung deutlich steiler an. Genau das macht die Zellspannung in diesem Bereich zu einem empfindlichen, geeigneten Steuersignal: Sie reagiert dort auf SoC- bzw. Ladezustandsänderungen viel stärker als im Flachbereich, und sie macht – anders als der globale Pack-SoC – auch '''Streuungen zwischen Einzelzellen''' sichtbar, da jede Zelle einzeln gemessen wird.

[[File:OCV_Kniezone_TermVoltageTaper.png|thumb|420px|OCV-Kurve (grün) und Ladespannung inkl. IR-Drop (orange, gestrichelt) einer LiFePO4-Zelle über dem SoC. Ab ca. 90 % SoC beginnt die Kniezone mit deutlich steilerem Spannungsanstieg. lowerTermVoltage und upperTermVoltage begrenzen den TermVoltageTaper-Regelbereich.]]

Zusätzlich zur reinen Ruhespannung (OCV) liegt bei fließendem Ladestrom noch der '''IR-Drop''' (Spannungsabfall am Zell-Innenwiderstand, U_IR = I × R_innen) auf der gemessenen Klemmspannung – daher liegt die tatsächlich gemessene Ladespannung stets etwas über der reinen OCV-Kurve (siehe orangene, gestrichelte Kurve in der Grafik).

'''Regelparameter'''

TermVoltageTaper arbeitet mit drei zentralen Spannungsparametern (aktuell als lokale Variablen in der Sub definiert, nicht als Attribut):

;LOWER_TERMVOLTAGE (aktuell 3.420 V): Zellspannung, ab der die Drosselung des Ladestroms einsetzt. Der Wert sollte deutlich unterhalb der bei ca. 99 % SoC beobachteten Zellspannung liegen (bei den hier verwendeten US3000C-Packs ca. 3.480 V) und idealerweise empirisch aus den eigenen Log-Daten (Zellspannung über Zeit/SoC während eines vollständigen Ladevorgangs) ermittelt werden.

;UPPER_TERMVOLTAGE (aktuell 3.490 V): Höchste zulässige Zellspannung. Wird sie überschritten, wird der Ladestrom hart auf 0 gesetzt. Der Wert muss mit klarem Sicherheitsabstand unterhalb der BMS-eigenen Überspannungsschutzschwelle liegen (bei US3000C ca. 3.600 V je Zelle).

;VOLTAGE_OFFSET (aktuell 0): IR-Drop-Kompensation für den linearen SoC-Bereich. Bei den in der Praxis auftretenden geringen Lade-C-Raten ist der IR-Drop meist im Bereich der Messauflösung und kann vernachlässigt werden; bei höheren Ladeströmen sollte dieser Wert ggf. SoC-abhängig ergänzt werden.

[[File:Screenshot 2026-08-09 153126.png|thumb|420px|Arbeitsbereich des TermVoltageTaper (orange eingekreist). Deutlich erkennbar ist die Abregelung von OTP auf 'OTP capped' bei Überschreitung der VOLTAGE_OFFSET Rampe. Durch Einsatz der Hysterese UPPER_TERMVOLTAGE_HYST wird ein gleichmäßiger Regelverlauf realisiert.]]

;UPPER_TERMVOLTAGE_HYST (aktuell 0.030 V): Hysterese-Band unterhalb von UPPER_TERMVOLTAGE zur Vermeidung von Oszillationen des Ladestroms. Ohne Hysterese würde eine Proportionalregelung an dieser harten oberen Schwelle zu einem Grenzzyklus neigen: Nach dem Cutoff (current = 0) relaxiert die Zellspannung durch den Wegfall des IR-Drops, unterschreitet dadurch kurzzeitig UPPER_TERMVOLTAGE, der Regler gibt sofort wieder vollen Strom frei, wodurch die Spannung erneut über die Schwelle steigt – der Zyklus beginnt von vorn, oft im Sekundentakt. Mit der Hysterese bleibt ein einmal ausgelöster Cutoff so lange aktiv (Schmitt-Trigger-Verhalten), bis maxCellVolt die niedrigere Freigabeschwelle (UPPER_TERMVOLTAGE − UPPER_TERMVOLTAGE_HYST) tatsächlich unterschreitet. Der aktuelle Zustand (aktiv/inaktiv) wird im Reading ''userFn_LoadController_cutoffActive'' dokumentiert. Der Wert ist ein empirisch ermittelter Startwert; ist die Oszillation trotzdem noch spürbar, kann UPPER_TERMVOLTAGE_HYST schrittweise erhöht werden, auf Kosten einer etwas trägeren Wiederfreigabe nach einem Cutoff.

[[File:Screenshot 2026-08-09 184604.png|thumb|420px|Cutoff löst sich im Bereich der Volladung nur selten (OTP Capped steigt bis ca. 2786 W), bis bei übersteigen UPPER_TERMVOLTAGE erneut gecuttet wird. Jedes Mal, wenn sich der Cutoff löst, ist max. Zellenspannung spürbar unter die eingestellte Release-Schwelle (3.460 V) gefallen. Das ist erwünschtes, kontrolliertes Verhalten – kein Bug.]]

Der Taper wirkt als lineare Rampe zwischen ''lowerTermVoltage'' und ''upperTermVoltage'':
<pre>
current *= 1.0 - (maxCellVolt - lowerTermVoltage) / (upperTermVoltage - lowerTermVoltage);
current = 0.0 if maxCellVolt > upperTermVoltage;
</pre>

'''Ermittlung der maximalen Zellspannung'''

TermVoltageTaper ermittelt ''maxCellVolt'' als Maximum über '''alle''' Zellen '''aller''' im System vorhandenen ''PylonLowVoltage''-Devices (bei Parallelschaltung mehrerer US3000C-Packs am gemeinsamen DC-Bus muss die kritischste Einzelzelle über den gesamten Stack hinweg erkannt werden, nicht nur pro Pack). Dabei wird zusätzlich das Alter jedes einzelnen ''cellVoltage_XX''-Readings geprüft (Parameter ''PYLON_MAXAGE'', aktuell 300 Sekunden): Ist ein Reading älter, wird sein Wert ignoriert und protokolliert. Werden veraltete Werte gefunden, wird der Ladestrom sicherheitshalber unabhängig vom berechneten ''maxCellVolt'' auf ''batMinChgCurrent'' (aktuell 0) gesetzt – ein Fail-Safe-Verhalten, das eine durch Buskommunikationsprobleme (z. B. RS485-Kollisionen bei mehreren gleichzeitig pollenden Pack-Devices) bedingte Fehlmessung nie unbemerkt in einen zu hohen Ladestrom münden lässt.

'''Einbindung in batLoadMgmnt'''

TermVoltageTaper wird als eigenständige Sub aufgerufen und liefert die um den Zellspannungs-Taper gedeckelte Ladeleistung (''otpCapped'') zurück:
<pre>
my $otpCapped = TermVoltageTaper ($name, $otp, $voltage);
$otpCapped = List::Util::min ($otp, $otpCapped);
</pre>
''otpCapped'' wird anstelle von ''otp'' in die anschließende GridSetpoint-Berechnung übernommen. Damit wirkt der Zellschutz '''innerhalb desselben Regelpfads''', den SolarForecast ohnehin für die PV-Überschuss-basierte Ladesteuerung nutzt: Erreicht ''maxCellVolt'' die Kniezone, sinkt ''otpCapped'', wodurch automatisch mehr PV-Leistung über den GridSetpoint Richtung Netz/Hausverbrauch statt in die Batterie geleitet wird – ohne zusätzlichen, parallelen Regelkreis.

'''Wichtiger Hinweis bei DC-gekoppelten Anlagen mit separatem MPPT'''

Die GridSetpoint-basierte Drosselung wirkt auch dann korrekt, wenn zusätzlich zu den MultiPlusII-Geräten ein direkt am Batterie-DC-Bus hängender MPPT-Solarladeregler im System vorhanden ist. Da MPPT, Batterie und MultiPlusII am selben Gleichstrombus hängen, gilt näherungsweise:
<pre>
Ladeleistung_Batterie ≈ Leistung_MPPT - Leistung_MultiPlusII
</pre>
Erhöht man über den GridSetpoint die vom MultiPlusII Richtung Netz/Hausverbrauch gewandelte Leistung, sinkt automatisch der für die Batterie verbleibende Rest – auch der vom MPPT erzeugte Anteil wird dabei über den MultiPlusII abgeführt und steht folglich nicht mehr für die Batterieladung zur Verfügung. Ein separater Eingriff am MPPT selbst ist für den regulären Taper-Betrieb also nicht erforderlich.

Diese indirekte Drosselung ist zudem verlustfrei: Die abgeregelte Leistung wird nicht am MPPT verworfen (kein Curtailment), sondern produktiv ins Netz oder den Haushalt geleitet.

Die Methode stößt jedoch an eine Grenze, sobald die '''maximale Einspeiseleistung''' (Attribut/Reading ''feedinPowerLimit'' bzw. bei Zero-Feed-in-Konfigurationen der Wert 0) bereits ausgeschöpft ist bzw. der GridSetpoint seinen zulässigen negativen Grenzwert (''neggspmax'') erreicht hat: In diesem Fall kann die vom MPPT erzeugte Leistung nicht mehr vollständig abgeführt werden, und ein Rest-Ladestrom bleibt trotz ''current = 0'' bestehen. Für den harten Cutoff-Fall (''maxCellVolt > upperTermVoltage'') ist dieser Grenzfall relevant und sollte bedacht werden.

'''Auswertung / Monitoring'''

Für die Beobachtung des Regelverhaltens legt TermVoltageTaper folgende Readings an (mit Event-Erzeugung, ''readingsEndUpdate ($hash, 1)'', damit FileLog/DbLog diese erfassen können):

;userFn_LoadController_maxCellVolt: aktuell ermittelte maximale Zellspannung im Stack (V)

;userFn_LoadController_maxCellSrc: Pack/Zelle, aus der die maximale Zellspannung stammt (z. B. ''Pylon3:cellVoltage_06''), hilfreich zur Diagnose bei auffälligem Verhalten einzelner Packs

;userFn_LoadController_otp: vom Modul errechnete optimale Ladeleistung (W) zur Erreichung des Ladeziels ohne Kenntnis der Zellspannungen

;userFn_LoadController_otpCapped: daraus resultierende gedeckelte Ladeleistung (W), die in die weitere GridSetpoint-Berechnung einfließt

;userFn_LoadController_cutoffActive: dokumentiert den Hysterese-Zustand des harten Spannungs-Cutoffs (1 = ausgelöst, Ladeleistung auf 0 W reduziert; 0 = nicht aktiv). '''Zu beachten:''' otpCapped kann auch bei cutoffActive=0 den Wert 0 annehmen, nämlich wenn der Stale-Data-Fail-Safe greift (veraltete Zellspannungsdaten) oder wenn die Taper-Rampe rechnerisch auf 0 rundet, ohne dass UPPER_TERMVOLTAGE überschritten wurde. cutoffActive zeigt also ausschließlich, ob speziell der Hysterese-Mechanismus gerade aktiv ist – nicht jede Ursache für otpCapped=0.

Ein gemeinsamer Plot aus ''userFn_LoadController_maxCellVolt'', ''userFn_LoadController_current'' bzw. ''userFn_LoadController_otpCapped'' sowie ''Battery_ChargeOptTargetPower_XX'' (als ungedrosselter Referenzwert) zeigt den Taper-Effekt sehr anschaulich: Bis zum Erreichen von ''lowerTermVoltage'' laufen beide Kurven deckungsgleich, danach knickt ''otpCapped'' zunehmend unter den ungedrosselten Zielwert ab, bis bei Erreichen von ''upperTermVoltage'' der harte Cutoff auf 0 greift.

<div class="mw-collapsible mw-collapsed">
'''Code Lademanagement ->''' <div class="mw-collapsible-content">
<syntaxhighlight lang="perl">
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;
use feature 'state';

sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

# ab hier eigenen Code eintragen

############################################################################
# komplettes Batterie Lademanagement (SOC + Ladeleistung)
############################################################################
sub batLoadMgmnt {
my $name = shift;
my $bn = shift // '01'; # Batterienummer
my $hash = $defs{$name};

## Konstanten
###############
use constant {
GSPDEF => 20, # Default Einstellung des Grid Setpoint
FINDEF => 5000, # Default Einspeiselimit
MINSOCDEF => 10, # Default Minimum SoC
MAXPLDEF => 105, # max. Ladestrom (A) für Victron MPII Verbund
SYS_VOLTAGE => 48, # Batterie Systemspannung
PYLON_MAXAGE => 300, # max. erlaubtes Alter (s) eines cellVoltage-Readings
LOWER_TERMVOLTAGE => 3.420, # Zellspannung -> Start Drosselung, deutlich vor 3480 mV bei 99 %
UPPER_TERMVOLTAGE => 3.490, # höchste Zellspannung (oberhalb keine weitere Ladung)
# ... (nahe dem vom Hersteller intendierten "voll"-Punkt, mit klarem
# ... Sicherheitsabstand zur 3600 mV Schutzschwelle)
VOLTAGE_OFFSET => 0, # Spannungsabfall am Innenwiderstand der Zelle für ein SOC in [20,90]
# ... andernfalls VOLTAGE_OFFSET=0
UPPER_TERMVOLTAGE_HYST => 0.030, # Hysterese-Band um UPPER_TERMVOLTAGE (V)
};

my $batsocmgmt = AttrVal ($name, 'userFn_BatterySoCManagement', 'Aus'); # Aus / Ein
my $batloadmgmt = AttrVal ($name, 'userFn_BatteryLoadManagement', 'Aus'); # Soll: Aus|loadRelease|(opt|smart)Power
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Device Victron CerboGX Einstellungen
my $batterydev = 'MQTT2_cerboGX_c0619ab34e08_battery'; # Device für Pylontech BatteryStack
my $ctype = 'Aus'; # Voreinstellung Steuerungstyp
my $voltage = ReadingsNum ($batterydev, 'DC_Voltage_value', SYS_VOLTAGE); # akt. Batteriespannung Bat-Paket (V)

## Ladestrategie Ist-Einstellung und Soll-Abgleich
####################################################
my $cgbt = AttrVal ($name, 'ctrlBatSocManagement'.$bn, undef);
my $strategy = 'loadRelease';

if ($cgbt) {
my $parsed = FHEM::SolarForecast::__parseAttrBatSoc ($name, $cgbt); # aktuell gesetzte Strategie ermitteln
$strategy = $parsed->{loadStrategy} // $strategy;
}

if ($batloadmgmt ne 'Aus') {
$ctype = $batloadmgmt;

if ($strategy ne $batloadmgmt) {
CommandSet (undef, "$name attrKeyVal ctrlBatSocManagement${bn} loadStrategy=$batloadmgmt");
}
}

## aktuelle Indikatoren
##########################
my $finplim = FHEM::SolarForecast::CurrentVal ($name, 'feedinPowerLimit', FINDEF); # Limit plantControl->feedinPowerLimit (W)
my $preduce = FHEM::SolarForecast::BatteryVal ($name, $bn, 'bpinreduced', MAXPLDEF); # reduzierte Ladeleistung aus Bat-Konfig (W)

my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest_'.$bn, 0); # Notfallladung
my $unrestrict = ReadingsNum ($name, 'Battery_ChargeUnrestricted_'.$bn, 0); # Ladefreigabe (1 -> Bat Ladefreigabe)
my $curgsp = ReadingsNum ($vicsets, 'GridSetpoint', GSPDEF); # aktuelle Einstellung Grid Setpoint
my $otp = ReadingsNum ($name, 'Battery_ChargeOptTargetPower_'.$bn, $preduce); # optimale Ladeleistung (W)
my $actmcc = ReadingsNum ($vicsets, 'MaxChargeCurrent', 0); # akt. maximale Ladestromeinstellung
my $load = MAXPLDEF; # initialer Soll-Ladestrom MPII (A)
my $neggspmax = -1 * $finplim;

my $gridsetpoint = GSPDEF; # Voreinstellung Grid Setpoint

####################################
## Battery SoC Management
####################################
if ($batsocmgmt eq 'Ein') {
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', MINSOCDEF); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC_'.$bn, MINSOCDEF); # optimierter Mindest-SoC

if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}
}

####################################
## Battery Lade-Management
####################################

# TermVoltageTaper - Ladestrom-Drosselung anhand Zellspannung (Kniezone)
# Konzept nach Forenuser 'Parallix'
############################################################################
my $otpCapped = TermVoltageTaper ($name, $otp, $voltage, $bn); # OTP eventuell drosseln
$otpCapped = List::Util::min ($otp, $otpCapped); # $otp mit der Taper-Grenze deckeln,
# BEVOR GridSetpoint/Load daraus berechnet werden

## Steuerung nach Ladungsfreigabe
###################################
if ($batloadmgmt eq 'loadRelease') {
if (!$unrestrict) { # Grid Setpoint absenken bis
# ... Ladeleistung = 0
$gridsetpoint = GSPDEF - $surp;
}
}

## Steuerung nach optimaler Ladeleistung
##########################################
if ($batloadmgmt =~ /(?:opt|smart)Power/xs) {
if (!$unrestrict) { # Grid Setpoint absenken bis
my $gridin = $surp - $otpCapped; # ... Ladeleistung = otpCapped
$gridsetpoint = GSPDEF - $gridin;
}
}

## max. Ladestrom der MultiPlusII rechnen
###########################################
if ($batloadmgmt ne 'Aus') {
$load = $otpCapped / $voltage; # Ladestrombegrenzung MPII
}

## Anforderungsladung (überschreibt max. Ladestrom)
#####################################################
if ($bcrq) { # max. Ladeleistung b. Battery_ChargeRequest
$ctype = 'requestCharging';

if ($surp < $preduce) {
my $p = $preduce;
$load = $p / $voltage; # Soll-Ladestrom (A)
}
}

## GridSetpoint und max. Ladestrom der MultiPlusII umsetzen
#############################################################
$gridsetpoint = List::Util::min (GSPDEF, $gridsetpoint); # GridSetpoint darf nicht > GSPDEF sein
$gridsetpoint = List::Util::max ($neggspmax, $gridsetpoint); # GridSetpoint darf nicht < max. Einspeiseleistung sein
$gridsetpoint = sprintf "%.0f", $gridsetpoint;

$load = List::Util::max (0, List::Util::min (MAXPLDEF, $load)); # clampen
$load = sprintf "%.0f", $load;

if ($curgsp != $gridsetpoint) { # GridSetpoint setzen
fhem ("set $vicsets GridSetpoint $gridsetpoint");
Log3 ($name, 3, qq{$name - userFn ChargeMgmnt '$ctype' -> GridSetpoint in $vicsets set to $gridsetpoint});
}

if ($load != $actmcc) {
CommandSet (undef, "$vicsets MaxChargeCurrent $load");

Log3 ($name, 3, qq{$name - userFn ChargeMgmnt '$ctype' -> MaxChargeCurrent MultiPlusII in $vicsets set }.
qq{from old $actmcc A to $load A});
}

readingsBeginUpdate ($hash);
readingsBulkUpdate ($hash, 'userFn_Victron_GridSetpoint_set', $gridsetpoint);
readingsBulkUpdate ($hash, 'userFn_MPII_MaxChargeCurrent_set', $load);
readingsEndUpdate ($hash, 0);

return;
}

############################################################################
# TermVoltageTaper - Ladestrom-Drosselung anhand Zellspannung (Kniezone)
# Idee/Konzept: https://forum.fhem.de/index.php?msg=1358509
# https://forum.fhem.de/index.php?msg=1359855
# Konzept nach Forenuser 'Parallix'
# Eingang: OTP, Bat-Spannung
# return: gedrosselter OTP
############################################################################
sub TermVoltageTaper {
my ($name, $otp, $voltage, $bn) = @_;

my $current = $otp / $voltage;
my $hash = $defs{$name};

my $termVoltageRange = UPPER_TERMVOLTAGE - LOWER_TERMVOLTAGE;
my $releaseVoltage = UPPER_TERMVOLTAGE - UPPER_TERMVOLTAGE_HYST;
my $batMinChgCurrent = 0;

state @allPylonDevs;
@allPylonDevs = devspec2array ("TYPE=PylonLowVoltage") if !@allPylonDevs;

my $maxCellVolt = 0;
my $maxCellSrc = '';
my $staleFound = 0;

for my $pd (@allPylonDevs) {
for my $cells (1..15) {
my $cell = sprintf "%02d", $cells;
my $rn = "cellVoltage_$cell";
my $age = ReadingsAge ($pd, $rn, PYLON_MAXAGE + 1); # Alter in Sekunden

if ($age > PYLON_MAXAGE) {
$staleFound = 1;

Log3 ($name, 2, "$name - batTaper[$bn]: $pd $rn is outdated (${age}s) - value will be ignored")
if(FHEM::SolarForecast::askLogtime ($name, "ageIutdated_$pd", PYLON_MAXAGE - 10));

next;
}

my $v = ReadingsNum ($pd, $rn, 0);

if ($v > $maxCellVolt) {
$maxCellVolt = $v;
$maxCellSrc = "$pd:$rn";
}
}
}

# Fail-safe: Wenn veraltete Daten gefunden wurden, sicherheitshalber Strom kappen,
# unabhängig vom (evtl. unvollständig ermittelten) $maxCellVolt
if ($staleFound) {
$current = $batMinChgCurrent;
Log3 ($name, 2, "$name - batTaper[$bn]: outdated cell voltage data - set charge current to minimum as a precaution");
}

Log3 ($name, 4, "$name - batTaper[$bn]: maxCellVolt=$maxCellVolt V ($maxCellSrc)");

## Taper-Rampe
################
if ($maxCellVolt > LOWER_TERMVOLTAGE + VOLTAGE_OFFSET) {
$current *= 1.0 - ($maxCellVolt - LOWER_TERMVOLTAGE) / $termVoltageRange;
$current = $current < $batMinChgCurrent ? $batMinChgCurrent : $current;
}

## Hysterese um UPPER_TERMVOLTAGE (Schmitt-Trigger)
#######################################################
my $cutoffActive = $hash->{HELPER}{'TVT_CUTOFF'.$bn} // 0;

if ($cutoffActive) {
if ($maxCellVolt <= $releaseVoltage) {
$cutoffActive = 0; # Freigabe: unter Release-Schwelle gefallen
Log3 ($name, 4, "$name - batTaper[$bn]: TermVoltageTaper cutoff released (maxCellVolt=$maxCellVolt <= $releaseVoltage)");
}
else {
$current = 0.0; # weiterhin gesperrt, solange über Release-Schwelle
}
}
elsif ($maxCellVolt > UPPER_TERMVOLTAGE) {
$cutoffActive = 1;
$current = 0.0;

Log3 ($name, 3, "$name - batTaper[$bn]: TermVoltageTaper cutoff engaged (maxCellVolt=$maxCellVolt > "
.UPPER_TERMVOLTAGE.")");
}

$hash->{HELPER}{'TVT_CUTOFF'.$bn} = $cutoffActive;

$current = sprintf "%.0f", $current;
my $otpCapped = List::Util::min ($otp, $current * $voltage);

readingsBeginUpdate ($hash);
readingsBulkUpdate ($hash, 'userFn_LoadController_maxCellVolt', $maxCellVolt);
readingsBulkUpdate ($hash, 'userFn_LoadController_maxCellSrc', $maxCellSrc);
readingsBulkUpdate ($hash, 'userFn_LoadController_otpCapped', $otpCapped);
readingsBulkUpdate ($hash, 'userFn_LoadController_otp', $otp);
readingsBulkUpdate ($hash, 'userFn_LoadController_cutoffActive', $cutoffActive);
readingsEndUpdate ($hash, 0);

return $otpCapped;
}

###############################################################################
# Ende eigener Code

1;
</syntaxhighlight>
</div>
</div>

 

==== barrierSoC - der Parameter den nicht jeder braucht ====

Wie bereits hinlänglich beschrieben, aktiviert das Attribut '''ctrlBatSocManagementXX''' mit diversen Schlüsseln die Batterie SoC- und Ladesteuerung. Für die alltägliche Nutzung und um schnell sichtbare Ergebnisse zu erzielen, ist die die Verwendung der obligatorischen Schlüssel lowSoc, upSoC und vielleicht noch die Auswahl der gewünschten Ladestrategie zunächst völlig ausreichend. Das Modul stellt für die Batteriesteuerung aber noch einige weitere Schlüssel zu Verfügung, die besondere Anforderungen an die Batteriesteuerung unterstützen. Einer dieser Parameter ist der '''barrierSoC''' Schlüssel.

Wird eine der beschriebenen Batterie Ladestrategien ''optPower'' oder ''smartPower'' eingesetzt, wird die Batterieladungsleistung vom aktuell vorhandenen SoC bis zum Ziel-SoC optmiert im Reading Battery_ChargeOptTargetPower_XX bereitgestellt. Dabei wird auch eine eventuell in ''ctrlBatSocManagementXX->loadTarget'' eingestellte Zielzeit berücksichtigt. Möglicherweise besteht der Wunsch die Batterieladung bis zu einem bestimmten Mindest-SoC so schnell wie möglich aufzuladen um z.B. zügig eine Netzausfallreserve aufzubauen.

Zu diesem Zweck kann der optionale Parameter ''ctrlBatSocManagementXX->barrierSoC'' verwendet werden. In dem Ladebereich

lowSoC <= SoC < barrierSoC

kann der User Einfluß auf die berechnete Ladeleistung nehmen und sie ggf. bis zur maximal möglichen Leistung abändern. Das bedeutet alle Manipulationen erfolgen ausschließlich diesem SoC-Bereich.
Dazu kann dem Parameter mit einer bestimmten Syntax das Änderungsverhalten vorgegeben werden:

<pre>
barrierSoC=XX:<Aktion>:<Wert> oder
barrierSoC=XX:<Aktion>:<Reading>:<default>
</pre>

Dabei bedeutet:

<pre>
XX - der Wert von barrierSoC in %. Es gilt lowSoC < XX < maxSoC
</pre>

Mit der '''<Aktion>''' wird eine der möglichen Manipulations-Varianten festgelegt:

;max: - das Ladeleistungslimit wird auf setupBatteryDevXX->pinmax festgelegt
;set: - das Ladeleistungslimit wird auf einen festen Wert oder Readingswert gesetzt
;inc: - das Ladeleistungslimit wird um einen festen Wert oder Readingswert erhöht
;dec: - das Ladeleistungslimit wird um einen festen Wert oder Readingswert verringert
;prc: - das Ladeleistungslimit wird um einen prozentualen Wert / Readingswert geändert

Diese Aktion (außer ''max'') wird auf den angegeben Wert bzw. den Wert des angegebenen Readings angewendet. Das Reading muß im SolarForecast Device enthalten sein. Bei Verwendung eines Readings wird mit ''<default>'' der Standardrückgabewert festgelegt falls das Reading keinen Wert liefert oder nicht vorhanden ist.

Hier sind einige Beispiele für einen barrierSoC. Zur Vereinfachung wird ein barrierSoC von 40 % verwendet und kann natürlich auf einen anderen passenden Wert abgeändert werden.

<pre>
barrierSoC=40:max:- -> das Ladeleistungslimit wird auf setupBatteryDevXX->pinmax gesetzt
barrierSoC=40:set:<Reading>:<default> -> das Ladeleistungslimit auf den Wert <Reading> setzen
barrierSoC=40:set:1350 -> das Ladeleistungslimit wird auf 1350 W gesetzt
barrierSoC=40:inc:<Reading>:<default> -> das Ladeleistungslimit um den Wert <Reading> erhöhen
barrierSoC=40:inc:200 -> das Ladeleistungslimit wird um 200 W erhöht
barrierSoC=40:dec:<Reading>:<default> -> das Ladeleistungslimit um den Wert <Reading> verringern
barrierSoC=40:dec:100 -> das Ladeleistungslimit wird um 100 W verringert
barrierSoC=40:prc:<Reading>:<default> -> das Ladeleistungslimit um <Reading> Prozent ändern (+ erhöhen, - verringern)
barrierSoC=40:prc:50 -> das Ladeleistungslimit um 50% ändern (+ erhöhen, - verringern)
</pre>

 

==== sequentielle Batterie-Ladung mehrerer Batterien mit lcSlot ====

Der Parameter '''ctrlBatSocManagementXX->lcSlot''' ("load control Slot") definiert eine Zeitperiode am aktuellen Tag in der die Steuerungslogik für die Batteriesteuerung aktiviert ist. Ist dieser Parameter nicht gesetzt, ist das eingestellte Lademanagement über den gesamten Tag aktiert und wäre identisch mit der Einstellung:

lcSlot=00:00-23:59

Somit ist die Ladesteuerung per default über den gesamten Tag aktiv.

Durch das Setzen von lcSlot auf einen täglichen Slot wird die Ladesteuerung auf diese Periode eingegrenzt. In der übrigen Zeit ist die Ladung der Batterie freigegeben (Reading Battery_ChargeUnrestricted_XX) bzw. auf die maximal konfigurierte Ladeleistung eingestellt (Reading Battery_ChargeOptTargetPower_XX). Diese Readings können je nach verwendeter Ladestrategie ausgewertet und zur Steuerung der Batterie(n) verwendet werden.
Die SoC-Steuerung wird durch die lcSlot-Angabe nicht beeinflusst.

Mit lcSlot kann zum Beispiel ein sequentielles Laden von mehreren Batterien umgesetzt werden. Nachfolgend wird ein solches Szenario mit drei Batterien skizziert:

1. die Batterie 1 soll mit voller Leistung geladen werden, die anderen Batterien nur bei weiterem Überschuß. Man würde die jeweiligen
ctrlBatSocManagementXX->lcSlot Schlüssel definieren:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
</pre>

;Wie ist der Ablauf: Die Batterie 1 unterliegt keiner Steuerung (nur von 23:00 bis 23:10 als Dummy-Periode). Das Reading Battery_ChargeUnrestricted_01 wird "1" gesetzt, d.h. die Batterie 1 wird zur Ladung uneingeschränkt freigegeben. Die anderen Batterien unterliegen der Steuerung -> Battery_ChargeUnrestricted_02 / 03 sind "0" und sollen nur geladen werden falls ein gesetztes Einspeiselimit überschritten wird.

Ist das Ladeziel der Batterie 1 erreicht, setzt man um die Batterie 2 vollzuladen:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
</pre>

Die Batterien 1 und 3 unterliegen der Steuerung, d.h. Battery_ChargeUnrestricted_01 / 03 haben den Wert "0". Demgegenüber ist Battery_ChargeUnrestricted_02=1 und soll uneingeschränkt geladen werden.

Ist auch die Batterie 2 voll geladen, würde man das Laden der Batterie 3 aktivieren:

<pre>
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=23:00-23:10
</pre>

Das Setzens via '''attrKeyVal''' hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrund peprüft und ggf. ein Fehler zurückgegeben wird, den der Nutzer in seinem Script auswerten kann. Weiterhin werden die Attribute implizit gespeichert sofern global->autosave nicht explizit auf "0" gesetzt ist.

 

==== Unterstützung eines netzdienlichen Verhaltens ====

Der Steuerungsprozess der Batterieanlage leistet insgesamt einen kleinen Beitrag zur Netzstabilität, indem die Speicherladung in den Zeitraum der meisten prognostizierten Überschußeinspeisung gelegt wird. Im Sommer kann sich dieser Zeitraum in die Zeit nach dem Maxmimum des prognostizierten PV-Überschusses verlagern, wenn auch danach noch genügend Überschußenergie zu Volladung der Batterie prognostiziert wird. In dem Zusammenhang sollte im Attribut '''plantControl->feedinPowerLimit''' ein Einspeiselimit gesetzt werden.

Zur Verdeutlichung soll das Beispiel dienen:

* die Batterie ist zu 60% geladen
* der User hat upSoC=40 eingestellt
* der User hat maxSoC=90 eingestellt

Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet.
Zu diesem Zeitpunkt wird das Reading '''Battery_ChargeUnrestricted_XX''' auf den Wert "0" gesetzt. Durch den Nutzer erfolgt daraufhin, zum Beipiel über ein Notify, ein anlagenspezifischer Befehl "Ladestop" an die Batterieanlage.

Ab diesem Moment wird:

# die Batterie nicht geladen
# die erzeugte PV-Energie dem Haushalt zur Verfügung gestellt bzw. der verbleibende Überschuß eingespeist, sofern der Überschuß unterhalb des im Attribut '''plantControl->feedinPowerLimit''' definierten Limits liegt.
# ein eventuell über dem Limit '''plantControl->feedinPowerLimit''' vorhandener Überschuß in die Batterie geladen und so die Netzlast verringert sowie die Batterie schonend geladen. (dieser Punkt trifft in den Monaten mit wenig PV-Erzeugung eher nicht zu)

Gleichzeitig liefert die Batterie Energie an das Hausnetz und wird von 60% bis maximal einem SoC-Wert entladen, der durch die [[#Die_dynamische_SOC_Steuerung_mit_Umsetzungsbeispiel|dynamische SOC Steuerung]] bestimmt wird. Dazu muß diese Steuerung natürlich implementiert sein. Sofern der berechnete SoC größer als upSoC ist, wird der maximale Entladungs-SoC auf upSoC gesetzt.

Zusätzlich überprüft das Modul permanent bei jedem Zyklus die Differenz des aktuell vorhandenen SoC zum eingestellten maxSoC.
Sie soll nicht größer sein um mit dem (noch) zu erwartenden PV-überschuß des Tages der eingestellte maxSoC bzw. dessen Nähe wahrscheinlich erreicht werden kann.
Sollte der Differenz-Grenzwert erreicht sein, wird '''Battery_ChargeUnrestricted_XX=1''' gesetzt und der Nutzer sollte dann über einen geeigneten Befehl seine Anlage in den Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

 

=== Nutzung von batteryTrigger ===
Ergänzt werden die Möglichkeiten durch das set-Kommando:

batteryTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Das Kommando setzt Triggerpunkte bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).

Der verwendete SoC wird als resultierender SoC als Summe der aktuellen Ladung aller registrierten Batterie-Geräte im Verhältnis zur installierten Gesamtkapazität gebildet. Das bedeutet, dass alle einzelnen Batterie-Geräte als ein gemeinsamer Cluster betrachtet werden.

Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.
Überschreiten die letzten drei SoC-Messungen eine definierte Xon-Bedingung, wird das Reading '''batteryTrigger_X = on''' erstellt/gesetzt.
Unterschreiten die letzten drei SoC-Messungen eine definierte Xoff-Bedingung, wird das Reading '''batteryTrigger_X = off''' erstellt/gesetzt.

Der Inhalt der Readings kann durch ein User-Programm oder, bei Erzeugung von entsprechenden Events, mittels notify-Device ausgewertet werden um bei Eintreten eines definierten Ereignisses entsprechende Reaktionen auszulösen. Das kann zum Beispiel die Freigabe eines Heizstabes oberhalb eines bestimmten SOC sein oder ein Entladeverbot der Batterie unterhalb eines SOC-Wertes um Reserven für einen eventuellen Stromausfall zu behalten.

Damit die Batterietrigger dynamisch geändert werden können, ist die Einstellung als Set-Kommando und nicht als Attribut ausgeführt.

Alle Triggerpunkte können mit dem set-Befehl:

reset batteryTriggerSet

wieder gelöscht werden.

== Verbrauchersteuerung - Registrieren und visualisieren von Verbrauchern ==

Das Modul gestattet es beliebige Verbraucher (Devices) über die Attribute '''consumerXX''' zu registrieren. Durch die Registrierung wird dem Modul der Namen des Devices sowie dessen Eingenschaften durch die Angabe von Schlüssel-Wert Paaren bekannt gemacht.

Nach der Registrierung können die Verbraucher durch das Modul genutzt werden:

* es erfolgt eine Planung der Ein- und Ausschaltzeiten abhängig von der solaren Prognose in Bezug zu den Leistungsdaten des Verbrauchers sowie der anderen registrierten Consumer
* das Modul kann die Ein- und Ausschaltsteuerung der Consumer übernehmen (optional)
* die aktuellen Status (Verbrauchsdaten) werden in der Energiefußgrafik dargestellt
* das Modul lernt mit der Zeit das Verbrauchsverhalten der registrierten Verbraucher

Um einen Verbaucher zu registrieren, wird ein freies '''consumerXX''' Attribut, zum Beispiel consumer01, gesetzt.

Die Eigenschaften und das Schaltverhalten wird durch die Angabe der verfügbaren Schlüssel gesteuert. Die Möglichkeiten sind sehr umfangreich. Die nachfolgenden Abschnitte beschreiben die Verwendung am Beispiel oft vorkommender bzw. nachgefragter Sachverhalte.

=== Die Phasen der Verbrauchersteuerung ===

Jeder Zyklus eines Verbrauchers durchläuft im Modul die folgenden Phasen:

# '''Planung''' der Aktivzeiten des Verbrauchers, d.h. wann der Verbraucher geplant eingeschaltet sowie geplant ausgeschaltet wird und damit der Zyklus beendet wird.
# '''Start''' des Zyklus, d.h. Einschalten des Verbrauchers entsprechend der Planungsdaten sofern weitere, in den Consumer-Schlüsseln definierbare Rahmenbedingungen das Einschalten nicht verhindern (z.B. kein oder zu wenig PV-Energieerzeugung / PV-Überschuss)
# '''Permanente Überprüfung von''' eventuell vorhandenen '''Interruptbedingungen''' die den Verbraucher temporär ausschalten und, sofern die Interruptbedingung nicht mehr vorliegt, den Verbraucher wieder einschalten und so den gestarteten Zyklus fortsetzen.
# '''Beendigung''' der Zyklus. Die Beendigung erfolgt entweder (normalerweise) wenn die geplante Endezeit der Zyklus erreicht ist oder eine optionale Endebedingung erfüllt ist.

==== Steuerung der Phasen ====
Der Ablauf der Phasen kann durch verschiedene Schlüssel-Wert Paare beeinflusst und gesteuert werden.

Mit dem optionalen Schlüssel '''swoncond''' kann eine '''zusätzliche externe Bedingung''' definiert werden um den Einschaltvorgang des Consumers freizugeben. Ist die Bedingung (Regex) nicht erfüllt, erfolgt kein Einschalten des Verbrauchers auch wenn die sonstigen Voraussetzungen wie Zeitplanung, on-Schlüssel, auto-Mode und aktuelle PV-Leistung gegeben sind. Es erfolgt somit eine '''UND-Verknüpfung''' des Schlüssels swoncond mit den Planungsdaten und weiteren Einschaltbedingungen.

Der optionale Schlüssel '''swoffcond''' definiert eine '''vorrangige Ausschaltbedingung''' (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist ('''ODER-Verknüpfung'''). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

Mit dem optionalen Schlüssel '''interruptable''' kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Der Verbraucher wird temporär ausgeschaltet (interrupted) und wieder eingeschaltet (continued) wenn die Interrupt-Bedingung nicht mehr vorliegt. Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst!

Der Schlüssel '''power''' gibt die nominale Leistungsaufnahme des Verbrauchers gemäß seines Datenblattes an. Dieser Wert wird verwendet um die Schaltzeiten des Verbrauchers zu planen und das Schalten in Abhängigkeit des tatsächlichen PV-Überschusses zum Einplanungszeitpunkt zu steuern. Ist '''power=0''' gesetzt, wird der Verbraucher unabhängig von einem zum Zeitpunkt des Zyklus-Start eventuell nicht ausreichend vorhandenem PV-Überschuss wie geplant eingeschaltet und somit der Zyklus gestartet.

Durch die Schlüssel '''notbefore''' und '''notafter''' kann der Startzeitpunkt des Verbrauchers so gesteuert werden, dass der Start des Zyklus nicht vor bzw. nach der angegebenen Zeit eingeplant wird. Diese Steuerung bezieht sich auf die ''Planung'', d.h. der eigentliche Start des Verbrauchers kann sich unter Umständen durch vorhandene Rahmenbedingungen verzögern.

Der Schlüssel '''mintime''' legt die geplanten Einschaltzeit, d.h. die Laufzeit des Zyklus fest. Der Name '''mintime''' ist nicht als MInimum-Zeit zu deuten, sondern beschreibt die angegebene Zeit in Minuten die der Zyklus dauern soll.

Dieser Schlüssel ist optional, da sich die Standard-Laufzeit des Verbrauchers von dessen Typ abgeleitet wird. Diese Standard Laufzeiten sind:

{| class="wikitable"
|dryer
|90 Minuten
|-
|fridge
|1440 Minuten
|-
|bev
|600 Minuten
|-
|dehydrator
|600 Minuten
|-
|heatpump
|Sonderfall

KI-Prognose (ab V2.0.0) beachten
|-
|dishwasher
|180 Minuten
|-
|washingmachine
|120 Minuten
|-
|heater
|240 Minuten
|-
|charger
|120 Minuten
|-
|other
|60 Minuten
|}

 

=== Automatiksteuerung der Verbraucher ===

==== Was ist die Automatiksteuerung? ====

Die Automatiksteuerung ist der zentrale Mechanismus, mit dem SolarForecast einen Verbraucher (Consumer) eigenständig anhand von PV-Überschuss, Planungsdaten und den konfigurierten Rahmenbedingungen (Zeitfenster, Sperrzeiten, Prioritäten etc.) ein- und ausschaltet. Sie ist die Voraussetzung dafür, dass ein Consumer überhaupt automatisch geschaltet werden kann.

Ist die Automatik für einen Consumer '''deaktiviert''', greift SF nicht in dessen Schaltzustand ein – der Consumer kann dann ausschließlich manuell (per Schalter am Gerät, per Set-Befehl, über eine andere Automatisierung etc.) bedient werden.

Ist die Automatik '''aktiviert''', übernimmt SolarForecast die Kontrolle über den Consumer im Rahmen der jeweiligen Planungs- und Überschusslogik (Modus <code>can</code>/<code>must</code>/<code>mustNot</code>).

==== Konfiguration: das Attribut <code>consumerXX->auto</code> ====

Für jeden Consumer wird über das consumerspezifische Attribut-Element <code>consumerXX->auto</code> festgelegt, '''welches Reading''' des Consumer-Devices die Automatikfreigabe liefert:

<pre>
auto=<Readingname>
</pre>

Beispiel:

<pre>
auto=Automatik
</pre>

'''Wirkung:'''

* Das referenzierte Reading wird von SolarForecast bei jedem Zyklus ausgelesen.
* Wert <code>1</code> (bzw. jeder als "wahr" interpretierbare Wert) → Automatik '''aktiv''': SolarForecast darf den Consumer schalten.
* Wert <code>0</code> → Automatik '''inaktiv''': SolarForecast plant zwar ggf. weiter im Hintergrund, führt aber '''keine Schaltbefehle''' aus.
* Ist kein <code>auto</code>-Schlüssel gesetzt, verhält sich der Consumer standardmäßig so, als wäre die Automatik dauerhaft aktiv (Default <code>1</code>).

==== Zusammenspiel von Automatik-Reading und grafischem Schalter im Consumer-Panel ====

[[Datei:Screenshot 2026-08-02 220921.png|right|thumb|400px|Automatik-Schalter im Consumer Panel]]

Im Consumer-Panel (Bereich "Consumer Legend") wird für jeden Consumer ein Schieberegler/Schalter für die Automatik angezeigt. Dieser Schalter ist '''keine eigenständige SolarForecast-interne Logik''', sondern lediglich eine grafische Repräsentation des unter <code>auto</code> hinterlegten Readings:

* Betätigung des Schalters im Panel setzt den Wert des referenzierten Readings am zugeordneten Device auf 0 oder 1.
* SolarForecast liest ausschließlich dieses Reading aus – nicht den Schalterzustand selbst. Der Schalter ist also nur die Benutzeroberfläche für das Reading, keine separate Speicherstelle.
* Wird das Reading auf anderem Weg verändert (z.B. durch eine andere Automatisierung, ein Notify, etc.), zeigt der Panel-Schalter dies beim nächsten SolarForecast-Zyklus entsprechend an – die Wirkung auf SolarForecast ist identisch, unabhängig davon, auf welchem Weg das Reading gesetzt wurde.

'''Praktisch bedeutet das:''' Ob der Automatikmodus über den Panel-Schalter, ein Skript oder eine andere FHEM-Automatisierung umgeschaltet wird, spielt für SolarForecast keine Rolle – entscheidend ist ausschließlich der aktuelle Wert des konfigurierten Readings.

 

==== Manuelle Eingriffe während aktiver Automatik ====

SolarForecast erkennt, wenn ein Consumer '''außerhalb der eigenen Schaltlogik''' geschaltet wird (z.B. per Schalter an der Steckdose, per App, durch eine andere Automatisierung), während die Automatik für diesen Consumer aktiv ist. Ein solcher externer Schaltvorgang wird im consumerXX-Reading mit dem Hinweis <code>von extern umgeschaltet</code> protokolliert.

'''Grundprinzip:''' SolarForecast unterbricht in diesem Fall bewusst seine eigene Schaltungslogik für diesen Consumer, um nicht störend in eine manuelle Aktion einzugreifen (z.B. laufende Wartung, kurzzeitiges Nachladen eines Wäschestücks in eine bereits laufende Waschmaschine, etc.).

===== Fall 1: Automatik wird aus- und wieder eingeschaltet =====

Wird die Automatik für einen Consumer '''bewusst deaktiviert und anschließend wieder aktiviert''' (Flanke AUS → EIN am <code>auto</code>-Reading), so übernimmt SolarForecast die Kontrolle '''in jedem Fall wieder''' – unabhängig davon, ob der Schaltzustand des Consumers zwischenzeitlich manuell verändert wurde oder nicht, und unabhängig davon, ob dieser Zustand vor der Reaktivierung wiederhergestellt wurde.

Dieser Vorgang wird im Consumer-Reading mit dem Hinweis <code>Automatik fortgesetzt</code> quittiert.

'''Merksatz:''' Die bewusste Reaktivierung der Automatik ist der eindeutigste Weg, die Kontrolle zuverlässig wieder an SF zu übergeben.

===== Fall 2: Automatik bleibt durchgehend aktiv, Ursprungszustand wird wiederhergestellt =====

Bleibt die Automatik durchgehend '''aktiviert''' und der Consumer wird manuell geschaltet, erkennt SolarForecast automatisch, wenn der '''Schaltzustand vor der manuellen Aktion wiederhergestellt''' wird – also z.B.:

* Consumer war automatisch ein → manuell aus → manuell wieder ein
* Consumer war automatisch aus → manuell ein → manuell wieder aus

In diesem Fall übernimmt die Automatik ebenfalls wieder selbstständig, sobald der Ursprungszustand erreicht ist – auch ohne dass die Automatik zwischenzeitlich deaktiviert wurde. Auch dieser Vorgang wird mit <code>Automatik nach Rundlauf fortgesetzt</code> quittiert.

'''Wichtig:''' Wird der Ursprungszustand '''nicht''' wiederhergestellt (z.B. Consumer war automatisch ein und wird manuell aus geschaltet, bleibt dann aber dauerhaft aus), bleibt der Consumer zunächst planungstechnisch "eingefroren" – siehe folgenden Abschnitt.

===== Fall 3: Consumer bleibt manuell abweichend vom Automatikstatus stehen =====

Wird ein Consumer manuell geschaltet und der neue Zustand '''nicht''' wieder in den Ursprungszustand zurückgeführt (z.B. manuell dauerhaft ausgeschaltet, während die Automatik ihn eigentlich eingeschaltet lassen würde), bleibt der Consumer zunächst '''nicht''' unter aktiver Kontrolle der Automatik.

Die Automatik übernimmt in diesem Fall '''trotzdem wieder''', sobald sie den Consumer im Rahmen ihrer normalen Zyklen einmal selbst "berührt" – am häufigsten durch eine kurzzeitige Unterbrechung mangels ausreichendem PV-Überschuss. Sobald dieser interne Abgleich stattgefunden hat, ist der intern gespeicherte Schaltzustand wieder deckungsgleich mit dem tatsächlichen physischen Zustand, und die Automatik behandelt den Consumer ab diesem Zeitpunkt wieder vollständig regulär – inklusive automatischem Wiedereinschalten bei ausreichendem Überschuss.

'''Praktische Konsequenz:''' Bei Consumern mit häufig schwankendem Überschuss (typisch bei wechselhafter Bewölkung oder gleichzeitig aktiven anderen Verbrauchern) kann dieser interne Abgleich vergleichsweise schnell erfolgen – oft innerhalb weniger Minuten. Ein manuelles dauerhaftes Abschalten sollte deshalb '''nicht ausschließlich''' auf diesem impliziten Mechanismus beruhen, sondern nötigenfalls durch Deaktivieren der Automatik (siehe Fall 1) oder eine geeignete Ausschlussbedingung (z.B. <code>swoffcond</code>) zuverlässig gegen ungewollten Wiederanlauf abgesichert werden.

==== Best Practice ====

Für ein zuverlässiges und nachvollziehbares Verhalten der Automatiksteuerung gilt:

* '''Kurzzeitige manuelle Eingriffe''' (z.B. kurz nachschauen, ein Wäschestück nachlegen) bei '''aktiver''' Automatik sind unproblematisch, solange der Ursprungszustand danach wiederhergestellt wird – die Automatik erkennt dies und läuft danach normal weiter.

* '''Soll ein Consumer dauerhaft und zuverlässig von der Automatik ausgenommen werden''' (z.B. für längere Wartungsarbeiten, bewusstes Stilllegen), empfiehlt es sich, die Automatik für diesen Consumer '''explizit zu deaktivieren''' (<code>auto</code>-Reading auf <code>0</code> setzen), statt sich auf einen dauerhaft abweichenden Schaltzustand zu verlassen. Nur so ist sichergestellt, dass SolarForecast in der Zwischenzeit keine Schaltbefehle ausführt.

* '''Soll die Kontrolle anschließend zuverlässig wieder an SolarForecast übergeben werden''', die Automatik bewusst wieder aktivieren (Flanke AUS → EIN). Dies ist der eindeutigste und sofortige Weg, unabhängig vom aktuellen Schaltzustand des Consumers.

* Für Consumer, die '''dauerhaft manuell abweichend''' von der Automatik-Empfehlung bleiben sollen, obwohl die Automatik selbst aktiv bleibt, empfiehlt sich zusätzlich eine passende <code>swoffcond</code>/<code>swoncond</code>-Bedingung, um ein unbeabsichtigtes Wiedereinschalten durch den in Fall 3 beschriebenen impliziten Abgleich zuverlässig zu verhindern.

* Der Status jedes Schaltvorgangs (inkl. "extern umgeschaltet"- und "Rundlauf fortgesetzt"-Hinweise) ist jederzeit im jeweiligen <code>consumer<XX></code>-Reading im Feld <code>info=</code> nachvollziehbar.

 

=== Der Verbraucher wurde nicht gestartet obwohl die Startzeit der Einplanung erreicht wurde ===

Wenn die Startzeit des Consumers entsprechend der Einplanung erreicht oder überschritten ist, wird der Consumer eingeschaltet wenn die weiteren Voraussetzungen wahr sind:

* es ist aktuell ein PV-Überschuss vorhanden und der PV-Überschuss deckt die kalkulierten Leistungsaufnahme des Verbrauchers ab. Mit den Schlüsseln '''power''' und '''spignorecond''' kann die Einschaltung trotz fehlendem PV-Überschuss ermöglicht werden.

* die Angabe im Schlüssel '''swoncond''' ist wahr (sofern gesetzt)

* das Schalten ist über den Schlüssel '''auto''' freigegeben (sofern gesetzt)

* im Schlüssel '''on''' ist ein valides Einschaltkommando hinterlegt

Sind diese zusätzlichen Bedingungen nicht erfüllt, erfolgt kein Start des eingeplanten Zyklus. Der Verbraucher verbleibt in diesem Fall weiterhin im Status ''planned'' oder ''suspended''. Die Startbedingungen werden regelmäßig reviewed und der Consumer gestartet sobald alle Startbedingungen wahr sind bzw. Start verhindernde Bedingungen entfallen sind.

Dieser Vorgang erfolgt bis das geplante Ende des Verbaucherzyklus erreicht ist oder die Bedingung im Schlüssel '''swoffcond''' zutrifft. Sobald die Bedingung im Schlüssel '''swoffcond''' wahr ist, wird der gesamte Planungszyklus des Consumers beendet.

 

=== Kann manuell / automatisiert in den Planungszyklus eines Verbrauchers eingegriffen werden? ===

Die Einplanung und die darauf aufbauenden Schaltprozesse laufen gemäß den hinterlegten Schlüsseloptionen im Modul automatatisch ab ohne dass ein Eingriff durch den Anwender erfolgen muß.

Dennoch kann es gewünscht sein eine Neuplanung oder eine Sofortplanung eines Consumers vorzunehmen weil der Bedarf dazu besteht. Zu diesem Zweck stehen die Set-Kommandos

* consumerNewPlanning

* consumerImmediatePlanning

zur Verfügung.
Beide Befehle initiieren die Consumer-Neuplanung, wobei mit dem Befehl ''consumerImmediatePlanning'' die eventuell im consumerXX Attribut gesetzten Schlüssel notbefore, notafter bzw. mode werden nicht beachtet werden. Dagenen beachtet der Befehl ''consumerNewPlanning'' alle definierten Schlüsseloptionen und dient gewöhnlich dazu einen abgeschlossenen Verbraucherzyklus wiederholt ausführen zu lassen weil die aktuelle Witterungslage dazu geeignet ist.

Ein Anwendungsbeispiel dafür ist zum Beispiel die Ausführung von mehreren Waschmaschinen-Zyklen an einem langen, sonnigen Sommertag.
Diese beiden Set-Befehle können zum Beispiel über ein auf einen Schalter/Taster reagierendes Notify oder DOIF Device ausgeführt werden.

 

=== Registrierung eines Verbrauchers mit getrennten Geräten für Messung und Schalten ===

Es existieren in FHEM Geräte, die über verschiedene Kanäle für unterschiedliche Aufgaben verfügen. Diese Kanäle werden jeweils in einem gesonderten Device abgebildet. HomeMatic oder readingsProxy sind Beispiele für solche Varianten.

Um solche Verbraucher einzubinden gibt es im consumerXX Attribut den Schlüssel '''switchdev'''.

Bei der Registrierung gibt man als Consumerdevice das Gerät für die Messung an und im Schüssel switchdev das entsprechende FHEM-Device, welches für die Schaltvorgänge benutzt wird.
Ist switchdev angegeben, beziehen sich die weiteren Schlüssel on, off, swstate, auto und asynchron auf dieses Gerät.

In dem nachfolgenden Beispiel (Homematic) ist ''eg.az.fridge_Pwr'' FHEM Device für die Energiemessung. Die Schlüssel ''pcurr'' und ''etotal'' geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel ''switchdev'' das zugehörige Schalter-Device der Kombination angegeben.

<pre>
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
</pre>

=== Registrierung von Verbrauchern ohne Zeitplanung und aktivem Schalten ===
Manchmal besteht der Wunsch, Verbraucher in SolarForecast zu integrieren um lediglich folgende Sachverhalte abzubilden:

* Visualisierung des Schaltstatus in der Consumer Legende und/oder der Energieflußgrafik
* Darstellung des aktuellen Energieverbrauchs in der Energieflußgrafik
* Erfassung der (externen) Schaltzeiten, d.h. der Zeiten der Gerätenutzung sowie der Verbrauchsdaten um deren Einfluß bei den Planungszeiten anderer Geräte durch SolarForecast berücksichtigen zu lassen

In solchen Fällen werden bei der Registrierung die Schlüssel ''swstate, pcurr'' und ''etotal'' zur Erfassung der Schaltzustände und der Energieverbrauchs angegeben, jedoch zur Verhinderung der Zeitplanung durch SolarForecast der Schlüssel '''type=noSchedule''' gesetzt sowie die Schlüssel ''on'' und ''off'' '''nicht''' gesetzt.

Das nachfolgende Beispiel zeigt eine mögliche Registrierung eines Zwischensteckers (Shelly) zur Erfassung der Daten eines Gefrierschrankes:

<pre>
Shelly.shellyplug4
type=noSchedule power=65 asynchron=1
icon=gefrierschrank
swstate=state:.*on.*:.*off.*
pcurr=relay_0_power:W:5 etotal=relay_0_energy_Wh:Wh
</pre>

=== Beispiel Sonderregistrierung einer Wärmepumpe ===

Das nachfolgende Beispiel zeigt die besondere Möglichkeit zur Registrierung (ab V2.0.0.) einer Wärmepumpe - aber nur wenn '''aiConActivate=1''' => KI-Consumerprognose <== gesetzt und genutzt wird!

Hinweis : Aktuell ist "nur" die Datensammlung für den 'opmode' aktiv - noch keine CON-Betrachtung dieser Werte bis V2.8.1 -> 04-.07.2026)

<pre>
EM_Waermepumpe
aliasshort=WP
type=heatpump
etotal=Bezug_Wirkleistung_Zaehler:kWh
icon=sani_heating_heatpump@orange
mode=mustNot
modulation=MQTT_EMSwp:boiler_data_heatingpumpmod
noshow=0
opmode=Forecast:user_wpmodus
pcurr=Bezug_Wirkleistung:W:100
power=3183
switchdev=MQTT_EMSwp ### extra wg. swstate Reading auf MQTT_EMSwp
swstate=boiler_data_hpactivity:heating|cooling|hot.*|pool|poolheating|defrost:off
</pre>

Erläuterungen zu diesen 'besondern' Einträgen
{| class="wikitable"
|'''type'''
|'''heatpump'''
|-
|
|Für Wärmepumpen / Klimaanlagen etc.
Es aktiviert sich ein Feature-Set für Wärmepumpen. Dadurch ändern sich die Strukturen und das 'runConTrain' muß erneuert gestartet werden.
In dem Status des Consumer-KI-Status-Popup ist auch erkennbar ob die Wärmepumpe erkannt wird und welches Featureset verwendet wird. Es sollte aber dann z.B. beim ''<nowiki/>'attr aiControl aiConProfile=XYX'<nowiki/>'' das Flag '''heatpump''<nowiki/>' zusätzlich gesetzt werden.
|-
|
|
|-
|'''etotal'''
|der Schlüssel ist Pflichtangabe
|-
|
|
|-
|'''mode'''
|mustNot (Empfehlung bei modulierenden Gerätetypen)
|-
|
|''Bei dem Verbrauchertyp '''heatpump''' ist sicherzustellen, dass keine doppelte Regelung durch SolarForecast und die native Gerätesteuerung erfolgt. Daher sollte bei modulierenden Verbrauchern dieses Types der Eintrag meist genutzt werden.''
''Ab V2.8.1 kann auch ein "can" oder "must" - wie bei allen anderen Verbrauchertypen - zur Einplanung / Steuerung durch Solarforecast genutzt werden.''
|-
|'''modulation'''
|Modulation des Aggregates in % (Pflichtangabe). Die mögliche Syntax ist:
|-
|
|'''<Device>:<Reading>''' - Kombination welche die aktuelle Modulation ('''0..100''') in % liefert
|-
|
|'''100''' - feste Modulation von 100% für nichtmodulierende Geräte
|-
|
|
|-
|'''opmode'''
|definiert eine <Device>:<Reading> Kombination welche den aktuellen Betriebsmodus liefert (Pflichtangabe).
|-
|
|Syntax: '''<Device>:<Reading>'''
|-
|
|Die Rückgabe muß genau ein Wert der folgenden Auswahl sein: '''off heating defrost hotwater cooling pool poolheating'''
|-
|
|
|-
|'''pcurr'''
|der Schlüssel ist Pflichtangabe - Maximale Leistungsaufnahme der Wärmepumpe / Klimaanlage etc. in W.
|-
|
|
|-
|'''power'''
|maximale Leistungsaufnahme in W. Der Wert darf nicht! 0 sein. Der Schlüssel ist Pflichtangabe.
|-
|
|
|-
|'''swstate'''
|Schaltstatus des Kompressors. Die Syntax bleibt wie bei den anderen Consumern.
|-
|
|Abweichend von anderen Consumern ist die Angabe verpflichtend, auch wenn der default verwendet werden soll.
Durch Erstellung eines passenden userReadings (WP-komplett / WP-Heizen / WP-Kühlen / WP-WW-Aufbereitung etc.) kann damit gesteuert werden, ob man sowohl Laufzeiten für Heiz- und Kühlbetrieb, Warmwassererzeugung und Heizstabbetrieb etc. in einem Consumer zusammenfassen will, oder ob man z.B. ausschließlich nur die Laufzeiten des Heiz- und Kühlbetriebs als aktive Zeiten für die Heizung (Kühlung) in dem jeweiligen consumerXX separat erfassen möchte.
|-
|
|
|-
|
|Alle hier nicht angezogen Parameter sind wie in allen Verbrauchern zu nutzen
|}

=== Beispiel Registrierung eines Shelly Devices ===

Nachfolgendes Beispiel zeigt eine Registrierung eines Heizlüfters der an einem Shelly Zwischenstecker angeschlossen ist und durch das Modul gesteuert werden soll. Dabei soll die Steuerung nicht nur von der Solarprognose, sondern auch von der Raumtemperatur abhängig erfolgen. Im Beispiel wird das Attribut consumer03 verwendet.

Zwingende Angaben sind

consumerXX <Device Name> type=<type> power=<power>

Alle Angaben können mehrzeilig eingegeben werden. Die Schlüssel-Werte Paare sind jeweils durch ein Leerzeichen getrennt.

consumerXX Shelly.shellyplug3 type=heater power=1700

In dem Beispiel ist Shelly.shellyplug3 der Devicename des Shellies in FHEM. Der Schlüssel '''type''' definiert die Art des Verbrauchers. In der Hilfe sind die möglichen Typen aufgeführt. Den richtigen Typ anzugeben hat Einfluß auf die spätere Einschätzung des Leistungsverhaltens über die Laufzeit. So wird von einem '''heater''' gleich nach dem Einschalten die angegebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern die Leistungsaufnahme sich über die Einschaltdauer.

Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuss festgestellt wird.

Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letztendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuss vorgenommen wird.

Es werden weitere Schlüsseleingaben vorgenommen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off

Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:

;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuss. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuss.

;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuss vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuss.

Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuss vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.

Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.

Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:

Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh
pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2

In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.

In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:

userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }

Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.

'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch kann man zu bestimmten Zeiten (Urlaub, Feiertage, etc.) die Schaltung temporär deaktivieren.

Wie oben beschrieben, soll der Heizlüfter als weitere Schaltbedingung die Abhängigkeit von der Raumtemperatur beachten. Konkret soll der Heizlüfter mit einer Hysterese von 0.2 (Grad) bei Erreichen einer Soll-Raumtemperatur ausschalten und bei Unterschreiten einer bestimmten Temperatur einschalten.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaltsequenzen.

Zunächst wird in dem Sensordevice (In dem Beispiel ein Homatic Wandthermostat HM-TC-IT-WM-W-EU) ein Reading erstellt welches dann im Schlüssel '''interruptable''' angegeben wird. Dieses Reading soll einen Wert enthalten auf den der angegebene Regex ([0-9]\.[0-9]) matchen soll um Shelly.shellyplug3 temporär auszuschalten.
Im Wandthermostat wird dazu ein userReading angelegt:

userReadings diff-temp:desired-temp.* {
sprintf "%.1f", ReadingsVal ($name, 'measured-temp', 0) - ReadingsVal ($name, 'desired-temp', 0)
}

Das bedeutet, wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:

interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2

und Shelly.shellyplug3 wird ausgeschaltet.
Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung, dass ein entsprechender PV-Überschuss vorliegt. Diese Bedingung wird durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuss ignoriert werden, kann '''power=0''' angegeben werden. Alternativ kann die Berücksichtigung des zwangsweisen PV Überschuss mit dem Schlüssel "spignorecond" im Consumer-Attribut ausgesteuert werden.

 

== zusätzliche Readings bzw. Erzeugung von statistischen Readings ==

Zusätzlich zu den zahlreichen im Modul per Standard erzeugten Readings kann der Anwender weitere Readings generieren lassen.
Diese zusätzlichen Readings geben entweder einen bestimmten Sachverhalt (Laufzeit, Status der API-Abfragen, etc.) oder einen statistischen Wert, z.B. die Batterieentladung des aktuellen Tages, wieder.

Die zusätzlich erstellten Readings sind durch den Präfix '''special_''' im Device gekennzeichnet.

Diese zusätzlichen Informationen können durch das Setzen einer oder mehrerer Kennzeichen im Attribut '''ctrlSpecialReadings''' erzeugt werden. Die mögliche Auswahl wird je nach Bedarf ausgebaut und umfasst zum aktuellen Zeitpunkt (07.02.2025) diese Möglichkeiten:

;BatPowerIn_Sum: die Summe der momentanen Batterieladeleistung aller definierten Batterie Geräte
;BatPowerOut_Sum: die Summe der momentanen Batterieentladeleistung aller definierten Batterie Geräte
;allStringsFullfilled: Erfüllungsstatus der fehlerfreien Generierung aller Strings
;conForecastTillNextSunrise: Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang
;currentAPIinterval: das aktuelle Abrufintervall der gewählten Strahlungsdaten-API in Sekunden
;currentRunMtsConsumer_XX: die Laufzeit (Minuten) des Verbrauchers "XX" seit dem letzten Einschalten. (letzter Laufzyklus)
;dayAfterTomorrowPVforecast: liefert die Vorhersage der PV Erzeugung für Übermorgen (sofern verfügbar) ohne Autokorrektur (Rohdaten).
;daysUntilBatteryCare_XX: Tage bis zur nächsten Batterie XX Pflege (Erreichen der Ladung 'maxSoC' aus Attribut ctrlBatSocManagementXX)
;lastretrieval_time: der letzte Abrufzeitpunkt der gewählten Strahlungsdaten-API
;lastretrieval_timestamp: der Timestamp der letzen Abrufzeitpunkt der gewählten Strahlungsdaten-API
;response_message: die letzte Statusmeldung der gewählten Strahlungsdaten-API
;runTimeAvgDayConsumer_XX: die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag
;runTimeCentralTask: die Laufzeit des letzten SolarForecast Intervalls (Gesamtprozess) in Sekunden
;runTimeTrainAI: die Laufzeit des letzten KI Trainingszyklus in Sekunden
;runTimeLastAPIAnswer: die letzte Antwortzeit des Strahlungsdaten-API Abrufs auf einen Request in Sekunden
;runTimeLastAPIProc: die letzte Prozesszeit zur Verarbeitung der empfangenen Strahlungsdaten-API Daten
;SunMinutes_Remain: die verbleibenden Minuten bis Sonnenuntergang des aktuellen Tages
;SunHours_Remain: die verbleibenden Stunden bis Sonnenuntergang des aktuellen Tages
;todayConsumptionForecast: Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
;todayConForecastTillSunset: Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
;todayDoneAPIcalls: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Calls
;todayDoneAPIrequests: die Anzahl der am aktuellen Tag ausgeführten Strahlungsdaten-API Requests
;todayConsumption: der gesamte Energieverbrauch (Wh) des Hauses am aktuellen Tag
;todayGridConsumption: die aus dem öffentlichen Netz bezogene Energie am aktuellen Tag
;todayGridFeedIn: die in das öffentliche Netz eingespeiste PV Energie am aktuellen Tag
;todayMaxAPIcalls: die maximal mögliche Anzahl Strahlungsdaten-API Calls. Ein Call kann mehrere API Requests enthalten.
;todayRemainingAPIcalls: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Calls
;todayRemainingAPIrequests: die Anzahl der am aktuellen Tag noch möglichen Strahlungsdaten-API Requests
;todayBatIn_XX: die am aktuellen Tag in die Batterie XX geladene Energie
;todayBatInSum: Summe der am aktuellen Tag in alle Batterien geladene Energie
;todayBatOut_XX: die am aktuellen Tag aus der Batterie XX entnommene Energie
;todayBatOutSum: Summe der am aktuellen Tag aus allen Batterien entnommene Energie

'''Wichtig:''' Manche Angaben sind im Setup des Moduls optional, d.h. sie müssen nicht zwingend beim Setup angegeben werden. Allerdings sind diese Angaben für die Erstellung eines zusätzlichen Readings unter Umständen Voraussetzung. Es empfiehlt sich deshalb bei Setup so viele Informationen wie möglich zu übermitteln.

So ist zum Beispiel für die sinnvolle Erstellung der Informationen '''todayBatInSum''' und '''todayBatOutSum''' (Readings special_todayBatInSum und special_todayBatOutSum) das Vorhandensein der Schlüssel ''intotal'' und ''outtotal'' im Attribut setupBatteryDevXX notwendig (Beispiel):

<pre>
attr <Name> setupBatteryDev01 MQTT2_cerboGX_c0619ab34e08_battery
pin=BatIn:W pout=BatOut:W charge=SOC_value intotal=BatInTotal:Wh outtotal=BatOutTotal:Wh
cap=InstalledCapacity_Wh:Wh asynchron=1 show=1
</pre>

 

== Hinweise zur Fehlersuche ==
Das Modul SolarForecast ist sehr komplex und es die verschiedensten Datenquellen ausgewertet, zusammengeführt und daraus Ergebnisse berechnet und/oder visualisiert. Wird etwas nicht wie erwartet durch das Modul geliefert, können die Ursachen vielfältig sein. Natürlich kann ein Fehler im Modulcode vorliegen, oftmals gibt es aber andere Ursachen.

Die nachfolgenden Hinweise sollen Hilfe zur Selbsthilfe geben und sind eine Zusammenfassung von realen Fällen die mit dem beschriebenen Wegen und Verfahren gelöst wurden.

=== Die erwartete erzeugte PV-Energie ist im Modul zu gering und wird im Balkendiagramm nicht angezeigt ===

Die erzeugte PV-Energie wird nicht richtig angezeigt: Am Vormittag sind keine Werte vorhanden und, wenn dann etwas kommt, ist die Anzeige zu gering. Für 13 und 14 Uhr wurden ca. 5.000Wh erwartet (im Vergleich mit den Daten aus einer anderen Auswertungsquelle).

'''Lösungsweg:'''

Aus dem List des Devices wurden die für den Fall wesentlichen Readings herausgezogen:

<pre>
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh

2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh

2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh

2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh

2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh

2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh

2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh

2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh

2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh

2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
</pre>

Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in der Balkengrafik nichts dargestellt. Auch danach bleibt die registrierte PV-Energie hinter den Erwartungen zurück. Zuständig für die Lieferung der PV-Energie an das Modul ist das Reading im Schlüssel:

setupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach

Welche Änderungen es zwischen den Stunden gab, sieht man mit einem "get ... pvHistory XX" ("XX" steht für das Datum, d.h. den Tag, z.B. 02). 
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59). 
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380 Wh). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher in Wh umgerechnet.

10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -

etotali01: 63364714, etotali02: 3044110, etotali03: -

pvrl01: 380, pvrl02: 150, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 574, con: 518, gcons: 22, conprice: 0.2958

gfeedin: 1, feedprice: 0.1269

DoN: 1, sunaz: 137, sunalt: 12

....

11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -

etotali01: 63365094, etotali02: 3044260, etotali03: -

pvrl01: 1392, pvrl02: 470, pvrl03: -

etotalp01: -, etotalp02: -, etotalp03: -

pprl01: -, pprl02: -, pprl03: -

confc: 774, con: 609, gcons: 25, conprice: 0.2958

gfeedin: 4, feedprice: 0.1269

....

D.h. wenn zwischen den beiden Stunden keine Differenzen zu finden sind, liegt es sehr wahrscheinlich am Input des Readings:

etotal=Total_Export_Energy_from_PV:kWh

welches sich in den ersten Stunden nicht ändert und danach auch nur wenig.

Man kann mit dem Attribut:

ctrlDebug=collectData

die Datensammlung verfolgen (leider entstehen viele Daten im Log). Man sieht welche Werte von dem Inverter/Reading geliefert werden:

....
2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
....

Dieser Wert muß bei PV Erzeugung kontinuierlich hochzählen. Wenn nicht, muss das angegebene Reading, d.h. die Quelle überprüft werden.

'''Ergebnis der Prüfung:'''

Tatsächlich wurde ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" wurde "Total_export_energy_from_PV" genutzt. In diesem Reading wurde immer die in die Batterie gespeicherte Energie von der gesamten erzeugten Energie abgezogen. Daher war auch vormittags alles 0, da in dieser Periode alle PV-Energie in die Batterie geladen wurde bzw. in weiteren Stunden ein Anteil der dann bei dem PV-Erzeugungswert fehlte.

Nachdem die Ursache beseitigt war, zeigt SolarForecast wieder die erwarteten PV-Erzeugungswerte an.

 
=== Ich beobachte Blockierungen in meinem FHEM - ist SolarForecast eventuell der Verursacher? ===

==== Übersicht ====

Dieses Dokument beschreibt die systematische Vorgehensweise zur Analyse und Lokalisierung von Blockierungszuständen im Kontext von SolarForecast (SF). Es dient als allgemeine Handlungsanleitung, um Ursachen für Systemverzögerungen oder hängende Prozesse einzugrenzen.

==== Grundprinzipien der SF-Architektur ====

Bevor mit der Analyse begonnen wird, sind folgende Architekturmerkmale von SF zu verstehen:

* '''Alle API-Abfragen sind non-blocking''' ausgeführt. SF selbst blockiert den FHEM-Interpreter durch API-Kommunikation grundsätzlich nicht.
* '''Geräteabfragen und Datensammlungen''' erfolgen ausschließlich durch das Auslesen von Readings – '''nicht''' durch direkte Geräteabfragen. Die direkte Gerätekommunikation ist Aufgabe der jeweiligen Gerätemodule.
* '''Schaltvorgänge von Verbrauchern''' (Consumer) können potenziell Blockierungen verursachen, wenn das zugehörige Gerätemodul beim Schalten auf ein Schaltergebnis wartet (blockierender Aufruf im Gerätemodul).
* '''SF schreibt in regelmäßigen Abständen''' modulinterne Datenstrukturen in das Filesystem. Ein fehlerhaftes oder langsames Filesystem kann daher eine Blockierungsquelle darstellen.

==== Schritt-für-Schritt-Analyse ====

===== Schritt 1: Meldungen im Log identifizieren und zuordnen =====

Beim Auftreten von Auffälligkeiten zunächst das FHEM-Log auf bekannte Meldungen prüfen und deren Herkunft bestimmen.

{| class="wikitable"
! Beispielmeldung !! Herkunft !! Bedeutung
|-
| <code>Data cycle triggered, watch readings</code> || Rückmeldung der SF-Zentralschleife (von get <SF-Device> data) || Normaler Abschluss eines SF-Zyklus – zu diesem Zeitpunkt ist die Verarbeitung vollständig abgeschlossen. Kein Hinweis auf eine SF-interne Blockierung.
|-
| <code>SolCast DEBUG> AI FANN drift data type 'con' successfully written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_SolCast</code> || Eine Log-Ausgabe mit aktiviertem Debug || Logausgaben von SF erfolgen IMMER mit Angabe des SF-Namens (hier 'SolCast')
|-
| <code>There are still path commands in the action queue</code> || Nicht von SF stammende Rückmeldung || Hinweis auf eine Warteschlange in einem Gerätemodul. Ursache im jeweiligen Gerätemodul suchen, nicht in SF.
|}

'''Hinweis:''' Meldungen, die nicht von SF generiert werden, müssen beim Hersteller bzw. Maintainer des jeweiligen Gerätemoduls analysiert werden.

===== Schritt 2: Laufzeit der SF-Zentralschleife messen =====

Um zu beurteilen, ob SF selbst verzögert läuft, das Special Reading <code>runTimeCentralTask</code> aktivieren:

attr <SF-Device> ctrlSpecialReadings runTimeCentralTask

Dieses Reading liefert die '''Gesamtlaufzeit eines SF-Schleifenzyklus''' inklusive aller enthaltenen Abfragen und Verarbeitungsschritte.

'''Typische Werte:''' 0,2 – 0,3 Sekunden

===== Schritt 3: Laufzeiten loggen und auswerten =====

Die Werte des Readings <code>special_runTimeCentralTask</code> dauerhaft mitschreiben, um Ausreißer und zeitliche Muster zu erkennen:

* '''Logging:''' via FileLog oder DbLog
* '''Auswertung:''' via SVG-Plot oder DbRep

Durch die zeitliche Auswertung lässt sich erkennen:
* '''ob''' Blockierungen auftreten
* '''wann''' sie auftreten (Uhrzeit, Regelmäßigkeit)
* '''im Zusammenhang womit''' sie auftreten (z. B. Consumer-Schaltvorgänge)

===== Schritt 4: Consumer-Schaltvorgänge als Ursache prüfen =====

Falls Verbraucher (Consumer) aktiv geschaltet werden, ist dies eine '''priorisierte Spur''':

* Identifizieren, welche Gerätemodule beim Schalten eines Consumers involviert sind.
* Prüfen, ob diese Module '''blockierend''' auf ein Schaltergebnis warten.
* Zeitliche Korrelation zwischen Schaltvorgängen und erhöhten <code>runTimeCentralTask</code>-Werten im Log prüfen.

===== Schritt 5: Filesystem prüfen =====

Falls keine Consumer-Schaltvorgänge als Ursache infrage kommen oder die Blockierungen unregelmäßig und zeitlich nicht korreliert auftreten:

* '''Filesystem-Gesundheit''' des Systems prüfen (z. B. SD-Karte bei Raspberry Pi, NFS-Mounts, volle Partitionen).
* SF schreibt regelmäßig Datenstrukturen auf das Filesystem. Latenzen oder Fehler dabei können SF-Zyklen verzögern.
* Systemlogs (<code>dmesg</code>, <code>syslog</code>) auf I/O-Fehler oder -Warnungen prüfen.

==== Zusammenfassung: Checkliste ====

{| class="wikitable"
! # !! Prüfpunkt !! Tool / Methode
|-
| 1 || Log-Meldungen SF-intern oder fremd? || FHEM Logfile
|-
| 2 || <code>runTimeCentralTask</code> aktivieren || <code>ctrlSpecialReadings</code>
|-
| 3 || Laufzeiten loggen || FileLog / DbLog
|-
| 4 || Ausreißer zeitlich auswerten || SVG / DbRep
|-
| 5 || Korrelation mit Consumer-Schaltvorgängen? || Zeitvergleich im Log
|-
| 6 || Gerätemodul des Consumers auf blockierende Aufrufe prüfen || Modul-Doku / Maintainer
|-
| 7 || Filesystem auf Fehler / Latenz prüfen || <code>dmesg</code>, <code>df</code>, <code>iostat</code>
|}

==== Hinweise ====

* SF ist '''nicht''' der unmittelbare Verursacher, wenn Fremdmodule blockierende Aufrufe ausführen.
* Die Analyse sollte immer mit dem '''Logging der Laufzeiten''' beginnen, da nur so eine fundierte Aussage über Zeitpunkt und Häufigkeit möglich ist.
* Bei Meldungen unbekannter Herkunft stets das verantwortliche Gerätemodul identifizieren, bevor SF-interne Ursachen untersucht 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

[[Datei:Screenshot 2024-10-20 134050.png|right|thumb|400px|Übersicht solare Vorhersage]]
geloggt werden.

Werden alle drei Werte in einem SVG kombiniert, kann die Entwicklung der Prognose über den Tag und die Beziehung von Prognose zu realer PV Erzeugnung pro Stunde visualisiert werden.

Für das rechts abgebildete Beispiel des Plots aus einer Datenbank "LogDBShort" sieht das gplot-File wie folgt aus:

<pre>
# Created by FHEM/98_SVG.pm, 2024-03-08 15:05:31
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:7500]
set y2range [0:7500]

#LogDBShort SolCast:LastHourPVforecast:::
#LogDBShort SolCast:LastHourPVreal:::
#LogDBShort SolCast:AllPVforecastsToEvent:::

plot "<IN>" using 1:2 axes x1y2 title 'aktuelle PV Vorhersage' ls l6fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'reale PV Erzeugung' ls l2fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'initiale PV Vorhersage' ls l4 lw 1 with lines
</pre>

'''Hinweis:''' In manchen Fällen werden die Vorhersagewerte im SVG-Plot nicht angezeigt wenn FileLog verwendet wird. Ein Setzen des Attribute "fixedrange=3days +1" im SVG löst das Problem. Die Definition des SVG-Devices:

<pre>
define SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast fixedrange 3days +1
attr SVG_LogDBShort_SolCast room Energie->SolarPrognose
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"
</pre>

Technisch bedingt werden an einem Tag X kurz nach 00:00 Uhr die am Vortag für den Tag X erzeugten Events aktualisiert. Diese Daten erzeugen in der Datenbank einen zweiten Satz an Daten mit dem gleichen Timestamp was für die Anzeige unvorteilhaft ist.
Um nur die aktualisierten Events von '''AllPVforecastsToEvent''' in der Datenbank zu erhalten, bietet sich ein DbRep-Device an. Die nachfolgende Vorschlagsdefinition kann per at-Device jeden Tag kurz vor Mitternacht (z.B. 23:57:10) ausgeführt werden. Es werden immer die in der Vergangenheit geschriebenen (veralteten) Daten aus der Datenbank gelöscht, doppelte Datesätze vermieden und immer die aktuellste initiale Prognose gespeichert:

<pre>
define Rep.Del.AllPVforecastsToEvent DbRep LogDBShort
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent room Datenbank->Produktiv
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end current_month_end
attr Rep.Del.AllPVforecastsToEvent verbose 2
</pre>

Das angegebene DbLog-Device '''LogDBShort''' ist natürlich anzupassen.

Das at-Device zum Starten der Datenbankbereinigung sieht folgendermaßen aus:

<pre>
define At.Del.AllPVforecastsToEvent at *23:58:10 set Rep.Del.AllPVforecastsToEvent delEntries
attr At.Del.AllPVforecastsToEvent alias Start Löschen Readings AllPVforecastsToEventn LogDBShort
attr At.Del.AllPVforecastsToEvent icon clock
attr At.Del.AllPVforecastsToEvent room Datenbank->Produktiv
</pre>

Natürlich sind auch hier die eigenen Devicenamen entsprechend anzupassen.

Ab SolarForecast Version 1.51.7 kann die Eventerzeugung für bestimmte SVG Plot-Typen optimiert werden. 
Die Aktivierung dieser Optimierungen ist in der Online Hilfe zum Attribut '''plantControl->genPVforecastsToEvent''' beschrieben. Bei Nutzung des Attributes plantControl->genPVforecastsToEvent ist ebenfalls das Attribut '''event-on-update-reading=AllPVforecastsToEvent''' zu setzen.

 

=== Beispielkonfiguration 1 ===
Dies ist eine Konfiguration mit

SummenDummy für 2 BatterieWR (Namen : SBS25 / SBS25_2)

SummenDummy für 3 PV-Wechselrichter (Namen : SB25 / SB30 / SB40)

mit verschiedenen InverterStrings / ModulDirection / ModulTiltAngle, ModulPeakString

und auch mit den notwendigen zugehörigen anderen Modul-Konfigs.

'''ACHTUNG:''' Zusätzlich enthalten ist bei dem Beispiel-Notify eine Sonderkonstellation für eine Brennstoffzelle "FCU" als weitere bzw. zusätzliche Stromerzeugungsquelle. Diese "FCU" wird dadurch mit in der Grafik mit deren Erzeugungsleistung Tag und Nacht in der Erzeugersumme (am Symbol = Sonne) berücksichtigt.

''(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)''

==== DWD ====
Bitte dabei diese DWD-Version aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter Contrib] von DS_Starter dazu nutzen
{| class="wikitable"
|55_DWD_OpenData.pm
|136.2 KB
|29260
|DS_Starter
|55_DWD_OpenData: contrib 1.17.7
|}
<syntaxhighlight lang="Perl">
define DWD DWD_OpenData
attr DWD downloadTimeout 120
attr DWD comment Im DWD Wetterdevice verwendet Solarforecast : \
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet \
zusätzlich ist jedoch auch noch Rad1h notwendig \
wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
Die Station 10418 (Lüdenscheid) überträgt aktuell am 09.03.2025 (noch) Rad1h.\
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation 10418
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at fc_description -(state fc_time)
attr DWD verbose 2

</syntaxhighlight>

==== InverterDummy ====
<syntaxhighlight lang="Perl">
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f kW Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
ReadingsVal($name,"total_pac",0)/1,\
ReadingsNum("Forecast","Today_PVforecast",0)/1000,\
ReadingsVal($name,"etoday",0)/1,\
ReadingsVal($name,"etotal",0)/1,)}
attr InverterDummy verbose 2
</syntaxhighlight>

==== SMA_Energymeter ====
<syntaxhighlight lang="Perl">
defmod SMA_Energymeter SMAEM
attr SMA_Energymeter DbLogExclude state
attr SMA_Energymeter diffAccept 50
attr SMA_Energymeter disable 0
attr SMA_Energymeter disableSernoInReading 1
attr SMA_Energymeter event-on-update-reading state,Saldo_Wirkleistung,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
attr SMA_Energymeter feedinPrice 0.08
attr SMA_Energymeter group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter powerCost 0.25
attr SMA_Energymeter room 015_Zaehler,020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2
</syntaxhighlight>

==== BatteryDummy ====
<syntaxhighlight lang="Perl">
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % "}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
</syntaxhighlight>

==== "Berechnungs"-Notify der Werte für Batterie- und InverterDummy ====
<syntaxhighlight lang="Perl">
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("MB_USRW610_004","Power_Sum__W",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
#fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)/1000)+(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
# Batterie-Bezug -Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme InverterDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal InverterDummyBatterie mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus InverterDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac InverterDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-total_pac InverterDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
# möglicher Aufruf einer Batterie-Bebladung-Routine....SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
</syntaxhighlight>

==== SolarForecast ====
<syntaxhighlight lang="Perl">
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude Current_BatCharge999
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
attr Forecast affect70percentRule 0
attr Forecast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm"\
"13.01.2025 mit der Version 76_SolarForecast.pm:v1.43.2-s29518/2025-01-12"
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest FCU-Erzeugung ;:Current_PP01\
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto surpmeth=default
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto surpmeth=default
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto surpmeth=default
attr Forecast consumerControl adviceIcon=light_light_dim_100@gold
attr Forecast consumerControl showLegend=icon_top
attr Forecast consumerControl detailLink=1
attr Forecast ctrlAIdataStorageDuration 1825
attr Forecast ctrlAIshiftTrainStart 2
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=99 careCycle=20
attr Forecast ctrlDebug none
attr Forecast plantControl genPVdeviation=continuously
attr Forecast plantControl cycleInterval=15
attr Forecast ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
attr Forecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr Forecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests
attr Forecast disable 0
attr Forecast event-min-interval .*:1800
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_02
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_01
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec #PV\
PV ;Heute ;real:Today_PVreal\
PV ;Morgen ;erwartet:Tomorrow_PVforecast\
PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast\
:\
#\
AutarkyRate:Current_AutarkyRate\
Überschuss:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
:\
#Verbrauch\
bis ;Sonnenuntergang:special_todayConForecastTillSunset\
bis ;Sonnenaufgang ;:special_conForecastTillNextSunrise\
:\
:\
#Batterie01\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_01\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_01\
Ladung ;heute:special_todayBatIn_01\
Entladung ;heute:special_todayBatOut_01\
#Batterie01_tmp\
Current_PowerBatIn_01:Current_PowerBatIn_01\
Current_PowerBatOut_01:Current_PowerBatOut_01\
:\
:\
#Batterie02\
Batt.-Ladeanforderung ;:Battery_ChargeRequest_02\
Batt.-Ladung ;empfohlen:Battery_ChargeUnrestricted_02\
Ladung ;heute:special_todayBatIn_02\
Entladung ;heute:special_todayBatOut_02\
#Batterie02_tmp\
Current_PowerBatIn_02:Current_PowerBatIn_02\
Current_PowerBatOut_02:Current_PowerBatOut_02\
:\
:\
#Settings\
Autokorrektur:pvCorrectionFactor_Auto \
Wetter:graphicShowWeather\
History:graphicHistoryHour\
ShowNight:graphicShowNight\
Debug:ctrlDebug\
FCU-Modus:FCU-Betriebsmodus@FCU
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1
attr Forecast graphicShowWeather 1
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.200 HausSE2=2.200
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PV
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}
attr Forecast verbose 2

setstate Forecast 0 W
setstate Forecast 2025-01-13 18:53:55 .FCU_FCU-Betriebsmodus 2
setstate Forecast 2025-01-13 18:53:55 .Forecast_ctrlDebug none
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicHistoryHour 4
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowNight 1
setstate Forecast 2025-01-13 18:53:55 .Forecast_graphicShowWeather 1
setstate Forecast 2025-01-13 08:24:25 .associatedWith SMA_Energymeter FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 tuya_local_bf5037060f450bdbd4rl0q tuya_local_bfac44fb487476efd1vhdu SBS25 SBS25_2 SB25 SB30 SB40 DWD MB_USRW610_004
setstate Forecast 2025-01-13 18:53:54 .lastupdateForecastValues 1736790834
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2025-01-13 01:00:05 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2025-01-13 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2025-01-13 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2025-01-13 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2025-01-13 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2025-01-13 06:00:06 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2025-01-13 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2025-01-13 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2025-01-13 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2025-01-13 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2025-01-13 11:00:05 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2025-01-13 12:00:02 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_apipercentil done
setstate Forecast 2025-01-13 13:00:02 .pvCorrectionFactor_13_cloudcover done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_apipercentil done
setstate Forecast 2025-01-13 14:00:03 .pvCorrectionFactor_14_cloudcover done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_apipercentil done
setstate Forecast 2025-01-13 15:00:05 .pvCorrectionFactor_15_cloudcover done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_apipercentil done
setstate Forecast 2025-01-13 16:00:06 .pvCorrectionFactor_16_cloudcover done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate Forecast 2025-01-13 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate Forecast 2025-01-13 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate Forecast 2025-01-13 18:53:54 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2025-01-13 01:00:05 .signaldone_01 done
setstate Forecast 2025-01-13 02:00:04 .signaldone_02 done
setstate Forecast 2025-01-13 03:00:04 .signaldone_03 done
setstate Forecast 2025-01-13 04:00:05 .signaldone_04 done
setstate Forecast 2025-01-13 05:00:05 .signaldone_05 done
setstate Forecast 2025-01-13 06:00:06 .signaldone_06 done
setstate Forecast 2025-01-13 07:00:04 .signaldone_07 done
setstate Forecast 2025-01-13 08:00:03 .signaldone_08 done
setstate Forecast 2025-01-13 09:00:04 .signaldone_09 done
setstate Forecast 2025-01-13 10:00:05 .signaldone_10 done
setstate Forecast 2025-01-13 11:00:05 .signaldone_11 done
setstate Forecast 2025-01-13 12:00:02 .signaldone_12 done
setstate Forecast 2025-01-13 13:00:02 .signaldone_13 done
setstate Forecast 2025-01-13 14:00:03 .signaldone_14 done
setstate Forecast 2025-01-13 15:00:05 .signaldone_15 done
setstate Forecast 2025-01-13 16:00:06 .signaldone_16 done
setstate Forecast 2025-01-13 17:00:05 .signaldone_17 done
setstate Forecast 2025-01-13 18:00:04 .signaldone_18 done
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeUnrestricted_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_01 1
setstate Forecast 2025-01-13 18:53:54 Battery_ChargeRequest_02 1
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour00_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour01_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour02_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour03_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour04_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour05_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour06_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour07_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour08_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour09_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour10_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour11_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour12_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour13_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour14_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour15_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour16_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_01 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour17_SoCforecast_02 10.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour18_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour19_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_01 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour20_SoCforecast_02 42.6 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour21_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour22_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_01 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_NextHour23_SoCforecast_02 40.0 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_01 40 %
setstate Forecast 2025-01-13 18:53:54 Battery_OptimumTargetSoC_02 40 %
setstate Forecast 2025-01-13 18:53:54 Current_AutarkyRate 83 %
setstate Forecast 2025-01-13 18:53:55 Current_BatCharge999 10
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_01 12 %
setstate Forecast 2025-01-13 18:53:54 Current_BatCharge_02 8 %
setstate Forecast 2025-01-13 18:53:54 Current_Consumption 626 W
setstate Forecast 2025-01-13 18:53:54 Current_GridConsumption 2 W
setstate Forecast 2025-01-13 18:53:54 Current_GridFeedIn 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PP_01 746.0 W
setstate Forecast 2025-01-13 18:53:54 Current_PV 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_01 0 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatIn_02 132 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_01 10 W
setstate Forecast 2025-01-13 18:53:54 Current_PowerBatOut_02 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumption 0 W
setstate Forecast 2025-01-13 18:53:54 Current_SelfConsumptionRate 0 %
setstate Forecast 2025-01-13 18:53:54 Current_Surplus 120 W
setstate Forecast 2025-01-13 18:00:00 LastHourGridconsumptionReal 5 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVforecast 0 Wh
setstate Forecast 2025-01-13 18:00:00 LastHourPVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_ConsumptionForecast 2944 Wh
setstate Forecast 2025-01-13 18:53:54 NextHours_Sum04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayConsumptionForecast 3609 Wh
setstate Forecast 2025-01-13 18:53:54 RestOfDayPVforecast 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_01 272 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridConsumption 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PPreal_01 748 Wh
setstate Forecast 2025-01-13 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_01 266 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridConsumption 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PPreal_01 787 Wh
setstate Forecast 2025-01-13 01:59:58 Today_Hour02_PVreal 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_01 271 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatIn_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_01 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_BatOut_02 0 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridConsumption 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PPreal_01 750 Wh
setstate Forecast 2025-01-13 02:59:53 Today_Hour03_PVreal 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_01 266 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatIn_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_01 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_BatOut_02 0 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridConsumption 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PPreal_01 745 Wh
setstate Forecast 2025-01-13 03:59:52 Today_Hour04_PVreal 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_01 267 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatIn_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_01 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_BatOut_02 0 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridConsumption 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PPreal_01 758 Wh
setstate Forecast 2025-01-13 04:59:56 Today_Hour05_PVreal 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_01 255 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridConsumption 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_GridFeedIn 1 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PPreal_01 752 Wh
setstate Forecast 2025-01-13 05:59:59 Today_Hour06_PVreal 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_01 226 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatIn_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_01 50 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_BatOut_02 0 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridConsumption 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_GridFeedIn 2 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PPreal_01 681 Wh
setstate Forecast 2025-01-13 06:59:52 Today_Hour07_PVreal 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatIn_02 233 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_01 845 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_BatOut_02 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridConsumption 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PPreal_01 0 Wh
setstate Forecast 2025-01-13 07:59:50 Today_Hour08_PVreal 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_01 37 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatIn_02 90 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_01 351 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_BatOut_02 188 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridConsumption 447 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_GridFeedIn 4 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PPreal_01 0 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVforecast 127 Wh
setstate Forecast 2025-01-13 08:59:57 Today_Hour09_PVreal 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridConsumption 1650 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PPreal_01 0 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVforecast 478 Wh
setstate Forecast 2025-01-13 09:59:58 Today_Hour10_PVreal 26 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatIn_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_BatOut_02 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridConsumption 513 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PPreal_01 0 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVforecast 868 Wh
setstate Forecast 2025-01-13 10:59:58 Today_Hour11_PVreal 97 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatIn_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_BatOut_02 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridConsumption 576 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PPreal_01 0 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVforecast 1157 Wh
setstate Forecast 2025-01-13 11:59:49 Today_Hour12_PVreal 320 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_01 8 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatIn_02 4 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_BatOut_02 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridConsumption 1272 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_GridFeedIn 7 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PPreal_01 0 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVforecast 1238 Wh
setstate Forecast 2025-01-13 12:59:49 Today_Hour13_PVreal 945 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_01 410 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatIn_02 53 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_BatOut_02 0 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridConsumption 955 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_GridFeedIn 31 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PPreal_01 562 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVforecast 1168 Wh
setstate Forecast 2025-01-13 13:59:49 Today_Hour14_PVreal 1410 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_01 703 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatIn_02 500 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_01 22 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_BatOut_02 18 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridConsumption 32 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_GridFeedIn 71 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PPreal_01 777 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVforecast 1630 Wh
setstate Forecast 2025-01-13 14:59:49 Today_Hour15_PVreal 1416 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_01 296 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatIn_02 70 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_01 74 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_BatOut_02 258 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridConsumption 13 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_GridFeedIn 17 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PPreal_01 732 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVforecast 880 Wh
setstate Forecast 2025-01-13 15:59:50 Today_Hour16_PVreal 1051 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_01 47 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatIn_02 126 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_01 102 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_BatOut_02 75 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridConsumption 15 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_GridFeedIn 23 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PPreal_01 771 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVforecast 117 Wh
setstate Forecast 2025-01-13 16:59:49 Today_Hour17_PVreal 86 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_01 0 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatIn_02 410 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_01 758 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_BatOut_02 67 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridConsumption 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_GridFeedIn 5 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PPreal_01 723 Wh
setstate Forecast 2025-01-13 17:59:54 Today_Hour18_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_01 349 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatIn_02 124 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_01 73 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_BatOut_02 450 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridConsumption 8 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_GridFeedIn 6 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PPreal_01 671 Wh
setstate Forecast 2025-01-13 18:53:54 Today_Hour19_PVreal 0 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecast 1630 Wh
setstate Forecast 2025-01-13 18:53:54 Today_MaxPVforecastTime 2025-01-13 14:00:00
setstate Forecast 2025-01-13 18:53:54 Today_PVdeviation 30.17 %
setstate Forecast 2025-01-13 18:53:54 Today_PVforecast 7663 Wh
setstate Forecast 2025-01-13 18:53:54 Today_PVreal 5351 Wh
setstate Forecast 2025-01-13 18:53:54 Today_SunRise 08:28
setstate Forecast 2025-01-13 18:53:54 Today_SunSet 16:46
setstate Forecast 2025-01-13 18:53:54 Tomorrow_ConsumptionForecast 17043 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour01_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour02_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour03_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour04_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour05_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour06_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour07_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour08_PVforecast 10 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour09_PVforecast 161 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour10_PVforecast 275 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour11_PVforecast 532 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour12_PVforecast 730 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour13_PVforecast 1252 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour14_PVforecast 818 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour15_PVforecast 1465 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour16_PVforecast 303 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour17_PVforecast 20 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour18_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour19_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour20_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour21_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour22_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour23_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_Hour24_PVforecast 0 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_PVforecast 5566 Wh
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunRise 08:27
setstate Forecast 2025-01-13 18:53:54 Tomorrow_SunSet 16:47
setstate Forecast 2025-01-13 18:53:54 consumer01 name='_Waschmaschine' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer01_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_start 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer01_planned_stop 14.01.2025 11:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02 name='_Esszimmer' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer02_currentPower 15.3 W
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer02_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03 name='_FCU' state='on' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer03_currentPower 7.15 W
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer03_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04 name='_Brunnen' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer04_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_start 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer04_planned_stop 14.01.2025 09:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05 name='_Zisterne' state='off' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer05_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer05_planned_stop 14.01.2025 08:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06 name='SW Trockner' state='unknown' mode='can' planningstate='planned'
setstate Forecast 2025-01-13 18:53:54 consumer06_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_start 14.01.2025 07:00:00
setstate Forecast 2025-01-13 18:53:54 consumer06_planned_stop 14.01.2025 08:30:00
setstate Forecast 2025-01-13 18:53:54 consumer07 name='SW Urlaubslicht-Wohnzimmer' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Forecast 2025-01-13 18:53:54 consumer07_currentPower 0 W
setstate Forecast 2025-01-13 18:53:54 nextCycletime 18:54:09
setstate Forecast 2025-01-13 10:00:05 pvCorrectionFactor_10 0.53 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate Forecast 2025-01-13 11:00:05 pvCorrectionFactor_11 0.56 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 70, Days in range: 1)
setstate Forecast 2025-01-13 12:00:02 pvCorrectionFactor_12 0.64 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 13:00:02 pvCorrectionFactor_13 0.88 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 60, Days in range: 1)
setstate Forecast 2025-01-13 14:00:03 pvCorrectionFactor_14 1.10 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-01-13 15:00:05 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.06, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 16:00:06 pvCorrectionFactor_16 1.09 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 45, Days in range: 1)
setstate Forecast 2025-01-13 17:00:05 pvCorrectionFactor_17 0.28 (automatic - old factor: 0.52, Sun Alt range: 0, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-01-13 18:53:54 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
setstate Forecast 2025-01-13 18:53:54 special_BatPowerIn_Sum 132 W
setstate Forecast 2025-01-13 18:53:54 special_BatPowerOut_Sum 10 W
setstate Forecast 2025-01-13 18:53:54 special_SunHours_Remain 0.00
setstate Forecast 2025-01-13 18:53:54 special_SunMinutes_Remain 0
setstate Forecast 2025-01-13 18:53:54 special_allStringsFullfilled 1
setstate Forecast 2025-01-13 18:53:54 special_conForecastTillNextSunrise 9467 Wh
setstate Forecast 2025-01-13 18:53:54 special_currentAPIinterval 0
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_01 132 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_02 184 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_03 329512 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_04 200 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_05 27 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_06 193 min
setstate Forecast 2025-01-13 18:53:54 special_currentRunMtsConsumer_07 106 min
setstate Forecast 2025-01-13 18:53:54 special_dayAfterTomorrowPVforecast 7344 Wh
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_01 12
setstate Forecast 2025-01-13 18:53:54 special_daysUntilBatteryCare_02 12
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_time 2025-01-13 18:53:54
setstate Forecast 2025-01-13 18:53:54 special_lastretrieval_timestamp 1736790834
setstate Forecast 2025-01-13 18:53:54 special_response_message success
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_01 545.94 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_02 382.10 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_03 1430.13 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_04 262.05 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_05 28.80 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_06 622.63 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeAvgDayConsumer_07 276.51 min
setstate Forecast 2025-01-13 18:53:54 special_runTimeCentralTask 0.3744
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIAnswer -
setstate Forecast 2025-01-13 18:53:54 special_runTimeLastAPIProc -
setstate Forecast 2025-01-13 18:53:54 special_runTimeTrainAI 1.2529
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_01 3683.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatIn_02 1617.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_01 2287.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayBatOut_02 1057.0 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConForecastTillSunset 0 Wh
setstate Forecast 2025-01-13 00:59:59 special_todayConsumptionForecast_01 509 Wh
setstate Forecast 2025-01-13 01:59:58 special_todayConsumptionForecast_02 499 Wh
setstate Forecast 2025-01-13 02:59:53 special_todayConsumptionForecast_03 501 Wh
setstate Forecast 2025-01-13 03:59:52 special_todayConsumptionForecast_04 511 Wh
setstate Forecast 2025-01-13 04:59:56 special_todayConsumptionForecast_05 503 Wh
setstate Forecast 2025-01-13 05:59:59 special_todayConsumptionForecast_06 495 Wh
setstate Forecast 2025-01-13 06:59:52 special_todayConsumptionForecast_07 504 Wh
setstate Forecast 2025-01-13 07:59:50 special_todayConsumptionForecast_08 561 Wh
setstate Forecast 2025-01-13 08:59:57 special_todayConsumptionForecast_09 768 Wh
setstate Forecast 2025-01-13 09:59:58 special_todayConsumptionForecast_10 783 Wh
setstate Forecast 2025-01-13 10:59:58 special_todayConsumptionForecast_11 692 Wh
setstate Forecast 2025-01-13 11:59:49 special_todayConsumptionForecast_12 791 Wh
setstate Forecast 2025-01-13 12:59:49 special_todayConsumptionForecast_13 910 Wh
setstate Forecast 2025-01-13 13:59:49 special_todayConsumptionForecast_14 1022 Wh
setstate Forecast 2025-01-13 14:59:49 special_todayConsumptionForecast_15 965 Wh
setstate Forecast 2025-01-13 15:59:50 special_todayConsumptionForecast_16 812 Wh
setstate Forecast 2025-01-13 16:59:49 special_todayConsumptionForecast_17 884 Wh
setstate Forecast 2025-01-13 17:59:54 special_todayConsumptionForecast_18 928 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_19 874 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_20 763 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_21 750 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_22 765 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_23 643 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayConsumptionForecast_24 601 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIcalls 0
setstate Forecast 2025-01-13 18:53:54 special_todayDoneAPIrequests 4532
setstate Forecast 2025-01-13 18:53:54 special_todayGridConsumption 5500.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayGridFeedIn 178.9 Wh
setstate Forecast 2025-01-13 18:53:54 special_todayMaxAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIcalls n.a.
setstate Forecast 2025-01-13 18:53:54 special_todayRemainingAPIrequests n.a.
setstate Forecast 2025-01-13 18:53:55 state updated
</syntaxhighlight>
So sollte es dann als Ergebnis aussehen:
[[Datei:Bildschirmfoto 2025-01-13.png|zentriert|mini|Ergebnis nach kompletter Einrichtung]]
[[Datei:Bildschirmfoto 2025-01-13 Teil II.png|alternativtext=Unterer Teil der Anzeige|zentriert|mini]]

== Praxisbeispiele und Lösungsansätze für Steuerungen ==
=== Fallstudie: Trockner darf pausiert werden, wenn nicht genug PV-Überschuss vorhanden ist, soll aber nach spätestens X Stunden fertig sein ===
Für diese Aufgabenstellung sind mehrere Schlüssel essentiell wichtig, '''power''', '''mintime''', '''mode''' und '''interruptable'''.

Die Bedingung, dass der Trockner nach spätestens X Stunden fertig sein soll, steht in einem Widerspruch zu der Möglichkeit den Trockner bei zu wenig PV-Überschuss unterbrechen zu können. Im Extremfall könnte nach dem Start die gesamte Planungszeit ungenügender Überschuss vorliegen und der Trockner nicht arbeiten. Der Schlüssel '''mintime''' (in Minuten) wird nun wie folgt angesetzt:

mintime = 2,5 x <gewöhnliche Betriebszeit für einen Trockengang (mneed, z.B. 120)> = 300 Minuten

Das bedeutet, der Trockner wird nach 300 Minuten Laufzeit abgeschaltet werden bzw. vom Netz getrennt. Der Trockenvorgang wird natürlich bereits nach 120 Minuten beendet sein, sofern nach Start keine Unterbrechnung des Vorganges erfolgte. Wurde der Vorgang unterbrochen, soll der Trockner innerhalb

X+120 bis X+300

fertig sein.

Demnach ist die ausgeführte Laufzeit des Trockners permanent zu überwachen, zu summieren (rtsum) und die notwendige Restzeit (mneed - rtsum) mit der noch verbleibenden Restzeit (mrest) bis zur geplanten Abschaltung des Consumers zu vergleichen. Ist der Consumer gestartet, wird die Laufzeit in der pvHistory für jede Stunde des Tages im Schlüssel ''minutescsmXX'' (XX = Consumernummer) aufgezeichnet und kann darüber ausgewertet werden. Somit ist:

msum = for (01 .. 24) {Summe von minutescsmXX} des aktuellen Tages

Solange die Bedingung

mrest >= (mneed - msum)

zutrifft, darf der Trockner unterbrochen werden, anderenfalls darf er nicht mehr unterbrochen werden da die Restzeit evtl. nicht ausreichen könnte um den Vorgang abzuschließen. Für die Planung des Trockners wird der Consumer wie gewöhnlich nach dem Bedarf im Modul registriert. Für die Steuerung der Unterbrechbarkeit wird noch ein Code erstellt, welcher im Trockner-Device ''Dryerdev'' das Reading ''SF_Int'' zur Unterbrechnungssteuerung verwaltet. Dieses Reading wird dem Schlüssel '''interruptable''' übergeben. Für das Beispiel wird der Consumer '07' verwendet, es kann natürlich jede andere freie Nummer verwendet werden:

<pre>
attr <Name> consumer07 Dryerdev:Trockner
icon=scene_cloves_dryer type=dryer power=2000 mode=must mintime=300
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic asynchron=1
interruptable=Dryerdev:SF_Int:1

</pre>

Die Kombination '''auto=automatic''' eröffnet die Möglickeit, in der Consumer-Legende den Trockner-Start zusätzlich manuell freizugeben oder zu verbieten.

Im nachfolgenden Code werden modulinterne Subroutinen verwendet. Diese sind inklusive dem Paket ''FHEM::SolarForecast::'' anzugeben. Die erstellte Subroutine wird in die 99_mySolarForecastUtils.pm eingefügt. Die Datei 99_mySolarForecastUtils.pm wird vorher von 99_myUtils.pm kopiert und enthält für die Übersichtlichkeit nur Routinen für SolarForecast.

<syntaxhighlight lang="Perl">
############################################################################
# Trocknersteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub dryControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # gewöhlich benötigte Zeit für
# einen Trockengang, z.B. 120 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $dryer = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename des Trockners
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($name, $startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Trockner-Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit des Trockners
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

my $dhash = $defs{$dryer};

if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe

}
}

return;
}
</syntaxhighlight>

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die gewöhnliche Laufzeit des Trockners für einen Trockenvorgang (120 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::dryControl ($name, '07', 120);
}
</pre>

 
=== Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden ===

Die Vorgehensweise ähnelt der Fallstudie zuvor. Verändernd kommt hinzu, dass der Planungszeitraum bewusst sehr lang angesetzt wird mit der Option, den Zyklus des Consumers vorfristig zu beenden sobald die Laufzeit von X Stunden am Tag erreicht ist.
Im folgenden Beispiel soll die Pumpe 5 Stunden am Tag (300 Minuten) laufen und dabei mögliche PV-Überschüsse ausnutzen.

<pre>
attr <Name> consumer07 Pump:Zirkulationspumpe
icon=sani_pump type=other power=50 mode=must mintime=780 notafter=09
on=on off=off etotal=energy_Wh:Wh pcurr=power:W
auto=automatic
interruptable=1 swoffcond=Pump:SF_Abort:1
</pre>

Mit dieser Registrierung wird die Pumpe ca. 09 Uhr täglich starten. Wenn kein bzw. ungenügender PV-Überschuß vorhanden ist, erfolgt eine Unterbrechung nach dem Start. Ist genügender PV-Überschuß (wieder) vorhanden, erfolgt keine Unterbrechnung (mehr). Zusätzlich wird über den Schlüssel '''swoffcond''' eine vorfristige Beendigung veranlasst, sobald die gewünschte Tageslaufzeit erreicht ist.

Zur Verwaltung des Schlüssels ''interruptable'' und des Readings ''SF_Abort'' verwenden wir eine leicht veränderte Subroutine aus dem vorhergehenden Fallbeispiel:

<syntaxhighlight lang="Perl">
############################################################################
# Pumpensteuerung (einfügen in 99_mySolarForecastUtils.pm)
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)

$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};

readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung

if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);

my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($name, $startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;

for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}

if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}

if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
}

return;
}
</syntaxhighlight>

Der Befehl ''attrKeyVal'' setzt den Schlüssel ''interruptable'' im Attribut ''consumer07'' dynamisch. Diese Strukturänderung wird automatisch im System gespeichert, sofern ''global->autosave=1'' gesetzt ist. Diese Einstellung ist der FHEM default.

Damit die Routine mit jedem Zyklus im Modul ausgeführt wird, legen wir sie im Attribut '''ctrlUserExitFn''' an. Es werden der Name des SolarForecast-Devices, die Verbrauchernummer (07) und die Mindestlaufzeit der Umwälzpumpe (300 Minuten) übergeben:

<pre>
attr <Name> ctrlUserExitFn {
::pumpControl ($name, '07', 300);
}
</pre>

 

=== Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie ===
Die nachfolgend beschriebene Lösung soll als Anregung für eigene Optimierungen verstanden werden und ist weiter ausbaufähig bzw. erweiterbar um zum Beipiel jahreszeitliche Anpassungen des Verfahrens.

Die MultiPlus II Batteriewechselrichter von Victron sollten die Batterien nicht mit dem maximal möglichen Ladestrom beladen, da sich die Effizienz deutlich verschlechtert wenn sich die Ströme den jeweiligen Grenzwerten nähern ([https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf Lesestoff]).
Andererseits sollen die Ladeleistungen so gewählt werden, dass die verfügbare Solarenergie eine volle Aufladung der Akkus ermöglicht.

Das Victron System ermöglicht das Auslesen und die Steuerung der Anlage via MQTT. Die Einbindung in FHEM über MQTT soll hier nicht beschrieben werden.
Aber wenn dies erfolgt ist, kann der Ladestrom z.B. mit dem Kommando:

set <Device> MaxChargeCurrent <Wert>

eingestellt bzw. variiert werden.

Das Modul bietet dem Nutzer die Möglichkeit in dem Attribut ''ctrlUserExitFn'' eigenen Code zur Auführung zu bringen. Der in diesem Attribut enthaltene Code wird am Ende jedes Zyklus (siehe Attribut ''plantControl->cycleInterval'') ausgeführt.
In dem Attribut wird dieser Code eingetragen dessen Funktion und Zusammenspiel nachfolgend erläutert wird:

<syntaxhighlight lang="Perl">
{
## Vars
########
my $batdev = (split " ", ReadingsVal ($name, 'currentBatteryDev', ''))[0]; # Batteriedevice
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $mppt1 = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common'; # SmartLoader Device
my $maxcspc = 105; # max. Ladesollstrom (A) nominal
my $spcorr = 0.9; # Korrekturfaktor Überschuss 90%
my $sch = 0.25; # Verkürzungsfaktor Zeit bis Vollladung vor Sunset

my $cclvl0 = 15; # Ladestrom Level 0 max. 5 A (240 W) pro WR (720 W)
my $cclvl1 = 27; # Ladestrom Level 1 max. 9 A (432 W) pro WR (1296 W)
my $cclvl2 = 54; # Ladestrom Level 2 max. 18 A (864 W) pro WR (2592 W)
my $cclvl3 = 81; # Ladestrom Level 3 max. 27 A (1296 W) pro WR (3888 W)
###############

my $cofc = ReadingsNum ($name, 'special_todayConForecastTillSunset', 0);
my $pvfc = ReadingsNum ($name, 'RestOfDayPVforecast', 0);
my $cpv = ReadingsNum ($name, 'Current_PV', 0);
my $mppt1c = ReadingsNum ($mppt1, 'DC_0_Current_value', 0); # Load I MPPT1 (max. 44 A)
my $ssts = CurrentVal ($hash, 'sunsetTodayTs', 0);
my $srts = CurrentVal ($hash, 'sunriseTodayTs', 0);
my $sdiff = ($ssts - $srts) / 3600; # Sonnengang heute in h

my $solh = ReadingsNum ($name, 'special_SunHours_Remain', 0); # h bis SunSet
$solh = $solh - ($sdiff * $sch); # h bis SunSet - X
$solh = $solh < 0 ? 0 : $solh;

my $ahrem = ReadingsNum ($batdev, 'EnergyRemain', 0) / 48; # Ah Bat bis SOC
$ahrem = sprintf "%.0f", $ahrem;

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur d. noch prognostizierten Überschussenergie
$fcdiff = $fcdiff < 0 ? 0 : $fcdiff; # Wh

my $loadcur = $maxcspc;

if ($cpv && $solh && $ahrem && $fcdiff > $ahrem) { # Ladeanforderung und Überschuss übersteigt
# Lademenge
my $cspc = sprintf "%.2f", ($ahrem / $solh); # A = Ah / h -> A Soll Schätzung

Log3 ($name, 3, qq{$name - userFn -> Battery charging process should be completed }.
qq{in >$solh< hours});
Log3 ($name, 3, qq{$name - userFn -> raw Target charging current: $cspc});

$cspc = sprintf "%.2f", ($cspc - $mppt1c); # SmartLoader IST berücksichtigen

Log3 ($name, 3, qq{$name - userFn -> Charge Current minus MPPT load Current >$mppt1c<: $cspc});

$loadcur = $cspc <= 0 ? 0 : # nur MPPT Ladung
$cspc <= $cclvl0 ? $cclvl0 : # Übergangsbereich
$cspc <= $cclvl1 ? $cclvl1 : # Ladung mit Level 1 Leistung
$cspc <= $cclvl2 ? $cclvl2 : # Ladung mit Level 2 Leistung
$cspc <= $cclvl3 ? $cclvl3 : # Ladung mit Level 3 Leistung
$maxcspc; # max. Ladesollstrom

Log3 ($name, 3, qq{$name - userFn -> MaxChargeCurrent calculated: $loadcur});
}

readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent', $loadcur.' A', 1);
readingsSingleUpdate ($hash, 'userFn_Bat_HoursUntilChargeFinish', sprintf ("%.2f",$solh), 1);
CommandSet (undef, "$vebus MaxChargeCurrent $loadcur");
}
</syntaxhighlight>

[[Datei:Screenshot 2023-05-03 201457.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]
Zunächst wird der am aktuellen Tag zu erwartende Totalüberschuss solarer Energie ermittelt. Das erfolgt aus der Differenz von ''RestOfDayPVforecast'' und ''RestOfDayConsumptionForecast'' unter Berücksichtigung eines Sicherheitsabschlages. Das Ergebnis liegt in Wh vor und wird bezogen auf 48 V (die Spannung des Batteriesystems) in Ah umgerechnet.

Die noch benötigte Ladung der Batterie zur Erreichung des Soll SOC-Wertes ermittelt das ReadingsNum ''special_SunHours_Remain'' aus dem Batteriedevice, welches vom Modulreading ''currentBatteryDev'' ausgelesen wird.

Sofern der so ermittelte solare Überschuss des (Rest)Tages die benötigte Lademenge der Batterie übersteigt, wird der DC Ladestrom so verringert, dass er sich in einem effizienten Bereich des MultiPlus II bewegt und dennoch rechnerisch ausreicht auf den Soll SOC-Wert zu laden.

Zu diesem Zweck wird im Modul über die Auswahl von ''SunHours_Remain'' im Attribut ''ctrlStatisticReadings'' das zusätzliche Reading ''special_SunHours_Remain'' erzeugt. Aus dem (noch) erforderlichen Ladungswert '''EnergyRemain''' (Ah) und der um eine Sicherheitszeit (''Verkürzungsfaktor Zeit bis Vollladung vor Sunset'') reduzierte Zeit bis zum Sonnenuntergang wird die rechnerisch erforderliche mindest Ladestromstärke ermittelt.

Dieser Wert wird auf die zu Anfang des Codeblocks definierten Ladelevel (''Ladestrom Level X'') abstrahiert und ein passender '''effizienter''' Ladestrom-Bereich ausgewählt.

[[Datei:Screenshot 2023-05-03 201719.png|right|thumb|300px|Vorhersage PV Erzeugung und Energieverbrauch des (restlichen) Tages]]

In allen anderen Fällen, wenn z.B. rechnerisch nicht genügend oder keine Solarenergie erzeugt wird (Nachts) oder der Speicher gefüllt ist, wird der maximale (Sollwert) des Ladestroms ''$maxcspc = 35'' eingestellt. Dieser Wert entspricht dem maximalen Ladestrom gemäß Herstellerunterlagen Pylontech.

Die Einstellung erfolgt per Set-Kommando im Victron vebus MQTT Device ''MQTT2_cerboGX_c0619ab34e08_vebus''. Dieses Device wurde auch während der MQTT Intergration des Victron Systems angelegt und wird hier nicht näher diskutiert.
Zur Kontrolle des kalkulierten Wertes werden noch die Readings ''SolCast_userFn_MaxChargeCurrent'' im Batteriedevice und ''userFn_Bat_MaxChargeCurrent'' im SolarForecast Device generiert.

Neben der Effizienzoptimierung hat dieses Verfahren auch den Vorteil einer möglichst schonenden Batterieaufladung was der Lebensdauer der Komponenten zugute kommen sollte.

=== Poolheizung in Abhängigkeit von vorhandenem Photovoltaik-Überschuss aktivieren/deaktivieren (Eigenverbrauch optimieren) ===
Eine (Whirl-)Poolheizung soll bei ausreichend überschüssiger Energie aus einer Photovoltaikanlage dynamisch gesteuert werden (Eigenverbrauchsoptimierung). Im folgenden Beispiel ist ein Device mit der Bezeichnung ''Forecast'' des Typs ''SolarForecast bereits'' angelegt und konfiguriert. Ein freies Consumer-Attribut ''consumer01'' wird beispielhaft wie folgt definiert:

<syntaxhighlight lang="Perl">
attr Forecast consumer01 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20
</syntaxhighlight>

Die Poolheizung ist innerhalb FHEM bereits im Device ''MQTT2_layzspa'' integriert und lässt sich normalerweise per FHEM-Befehl "set ''MQTT2_layzspa heater on"'' oder ''"set MQTT2_layzspa heater off"'' steuern. Entsprechend werden die Schlüssel-Wert-Paare ''"on="'' und ''"off="'' definiert.

Der Stromverbrauch einer aktiven Poolheizung ist uns bekannt und wird im Schlüssel ''"power=1950"'' definiert. Die Heizfunktion soll nur bei ausreichend Überschuss aktiviert werden dürfen und muss bei Unterschreitung sofort abgeschaltet werden. Diese Eigenschaften werden über die Schlüssel ''"mode=can"'' und ''"interruptable="1"'' festgelegt. Zuletzt soll grundsätzlich nur in der Zeit zwischen 08:00 Uhr bis 20:00 Uhr geheizt werden dürfen.

Die Schlüssel ''"notbefore=8"'' und ''"notafter=20"'' legen diese Eigenschaften fest. Zur Anzeige des Schaltzustands der Heizung wurde der Schlüssel ''"swstate=heaterstate:1:0"'' hinzugefügt (Wert 1 = Heizung aktiv, Wert 0= Heizung aus).

==== Priorisierung vor externen PV-Überschuss gesteuerten Verbrauchern ====
Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, einen Consumer auch ohne ausreichend PV-Überschuss einzuschalten. Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuss vorliegt. Im obigen Beispiel existiert in der Haus-Elektroinstallation eine Elektroauto-Ladestation mit eigener (externer) dynamischer PV-gesteuerter Fahrzeugladung ohne Integration in ''SolarForecast''.

In Abhängigkeit von PV-Generatorleistung und Sonneneinstrahlung besteht manchmal eine Möglichkeit, dass der gesamte PV-Überschuss zur Fahrzeugladung genutzt wird. Das Modul SolarForecast würde entsprechend keinen (oder zu wenig) PV-Überschuss erkennen und den Consumer ''MQTT2_layzspa'' nicht aktivieren.

Durch Verwendung von ''spignorecond=EVCharger22:LadungMitPVUeberschussActive:1'' wird die Poolheizung gegenüber der Ladestation jedoch priorisiert mit PV-Überschuss versorgt. In diesem Beispiel wird Consumer1 aktiviert, wenn die Ladestation "''EVCharger22''" sich im PV-Überschuss-Modus befindet '''und''' momentan ein Fahrzeug lädt. In der Folge würde der Hausstromverbrauch um ca. 1950 Watt steigen, die externe Fahrzeugladestation diese Änderung registrieren und die Fahrzeugladeleistung entsprechend verringern oder ganz abbrechen.

=== Luftentfeuchter PV-Überschuss gesteuert mit externer Zwangs-Einschaltbedingung ===
Im folgenden Beispiel wird ein Luftentfeuchter normalerweise nur bei ausreichend PV-Überschuss Energie eingeschaltet (Eigenverbrauchsoptimierung), soll jedoch bei hoher Luftfeuchtigkeit zusätzlich aktiviert werden.
<syntaxhighlight lang="Perl">
attr Forecast SolarForecast ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:high icon=Ventilator_fett
</syntaxhighlight>Das in FHEM bereits angelegte Device namens ''ShellyPlug1'' dient als Zwischenstecker zur Steuerung des Luftentfeuchters. Der Schlüsselwert "''mintime=SunPath''" definiert die zeitliche Einplanung von Sonnenauf- bis untergang. Jedoch soll das Gerät unter keinen Umständen in der Nacht eingeschaltet werden, was über die Schlüssel ''"notbefore=07"'' bzw. ''"notafter=22"'' festgelegt ist. Weiterhin wurde im Schlüssel ''"locktime=900"'' festgelegt, dass zwischen (möglichen) Ein- und Ausschaltintervallen wenigstens 15 Minuten Wartezeit vergehen soll.

Der Schlüssel-Wert '''"spignorecond="''' bietet optional die Möglichkeit, ein Consumer bei erfüllter Bedingung auch ohne ausreichend PV-Überschuss einzuschalten. In diesem Beispiel wird ein Raumluftsensor abgefragt. Bei Vorhandensein der Einschaltschwelle "high" aktiviert sich der Consumer zur geplanten Laufzeit zwischen 07:00 bis 22:00 Uhr solange, bis der Raumluftsensor einen abweichenden Wert meldet.

=== PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ===
[https://evcc.io evcc] ist ein Energie-Management-System, mit dem u.a. Überschussladen von Elektroautos möglich ist. Hier ist beschreiben, wie die SolarForecast-Vorhersagedaten per API von evcc abgerufen werden.
Lege im SolarForecast-Device ein User-Reading mit dem Namen forecast_json an. Es wandelt die Forecast-Werte in JSON und ins UTC-Zeitformat um, so dass evcc die Daten einlesen kann. Der Code wird nur ausgeführt, wenn das Reading nextCycletime ein Event erzeugt.

<syntaxhighlight lang="Perl">
forecast_json:nextCycletime.* {
use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

my $hour = 0;
my $last_start_ts;
my @output;

# Parser für Datum mit CET/CEST
my $parser = DateTime::Format::Strptime->new(
pattern => "%Y-%m-%d %H:%M:%S",
time_zone => "Europe/Berlin",
);
my $start_ts;

# Alle NextHour-Daten durchsuchen (als Fallback zur Vermeidung einer Endlosschleife auf max. 100 Std. begrenzen)
while ($hour < 100) {
my $hour_str = sprintf("NextHour%02d", $hour);
my $start_str = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "starttime", "na");
my $pvfc = FHEM::SolarForecast::NexthoursVal("$NAME", $hour_str, "pvfc", "na");

# Schleife beenden, wenn keine Vorhersage-Werte mehr vorhanden sind
last if $start_str eq "na" or $pvfc eq "na";

$start_ts = $parser->parse_datetime($start_str); # Zeitzone und Sommer/Winterzeit berücksichtigen

# Zeit nach UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $start_ts->set_time_zone("UTC")->iso8601() . "Z",
end => $start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0 + $pvfc,
};
$hour++;
}

# Prüfen, ob der letzte Wert 23 Uhr war -> zusätzliche Stunde anhängen, damit der Tag
# bei evcc als vollständig angezeigt wird (siehe https://github.com/evcc-io/evcc/issues/22979)
if ($start_ts->hour == 23) {

# Zeit nach UTC und ISO 8601 konvertieren und Vorhersagewert ergänzen
push @output, {
start => $start_ts->set_time_zone("UTC")->iso8601() . "Z",
end => $start_ts->add(hours => 1)->set_time_zone("UTC")->iso8601() . "Z",
value => 0,
};
}

# Ausgabe als JSON
my $json = JSON->new->utf8->pretty->encode(\@output);
return $json;
},
</syntaxhighlight>

[[Datei:Screenshot 2025-08-04 104835.png|right|thumb|300px|Darstellung der PV-Vorhersage in evcc auf Basis der SolarForecast-Daten]]

Soll der Code zur Erstellung des userReadings forecast_json in die 99_myUtils ausgelagert werden, erstelle die Funktion ''forecast_json'' mit ergänztem Code:

<syntaxhighlight lang="Perl">
# - Perl Module laden
use strict;
use warnings;
use JSON;
use DateTime;
use DateTime::Format::Strptime;

forecast_json { <--- ändern
my $NAME = @_; <--- ergänzen
my $hour = 0;
my $last_start_ts;
my @output;
....
</syntaxhighlight>

Die Definition von userReadings in SolarForecast ändert sich zum Aufruf der Funktion in:

<pre>
userReadings forecast_json:nextCycletime.* { main::forecast_json($NAME) }
</pre>

Die Kommunikation läuft über den integrierten FHEM-Webserver, der die JSON-Daten aus dem Reading forecast_json veröffentlicht. Dazu wird in FHEM eine separate Webinstanz auf einem neuen Port erstellt, die ohne [[CsrfToken-HowTo|CSFR-Token]] (Achtung, Auswirkungen auf die Sicherheit beachten!) und nur von localhost aufrufbar ist (Voraussetzung: evcc läuft auf derselben Maschine wie FHEM):

<syntaxhighlight lang="Text">
define WEBapi FHEMWEB 8089 ---> (define WEBapi FHEMWEB IPV6:8089 global bei Verwendung von IPV6)
attr WEBapi csrfToken none
</syntaxhighlight>

==== evcc Integration ====
'''Konfiguration über die Datei evcc.yaml''' 

In der [https://docs.evcc.io/docs/tariffs#pv-vorhersage evcc-Konfig unter tariffs] steht die Quelle für die Solar-Vorhersage. Der FHEM-Befehl {ReadingsVal('solarforecast_dev','forecast_json','[]')} wird encoded und in die uri eingetragen. Trage statt solarforecast_dev den passenden Namen deines SolarForecast-Device ein. evcc holt die Daten aus dem Reading forecast_json dann regelmäßig ab.

<syntaxhighlight lang="yaml">
solar:
type: custom
interval: 20m
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
</syntaxhighlight>

'''Konfiguration über den UI-Editor''' 

In der aktuellen evcc-Version wird die Vorhersageintegration über den UI-Editor mit einer veränderten Syntax vorgenommen:

<syntaxhighlight lang="Perl">
tariff: solar
forecast:
source: http
uri: http://localhost:8089/fhem?cmd=%7BReadingsVal%28%27solarforecast_dev%27%2C%27forecast_json%27%2C%27%5B%5D%27%29%7D&XHR=1
jq: |
map({
"start": .start,
"end": .end,
"value": .value
}) | tostring
</syntaxhighlight>

Zur Verbesserung der Sicherheit kann das neue WEBapi Device auch ein [[CsrfToken-HowTo#csrfToken festlegen|festes CSFR-Token]] verwenden. Dieses Token muss dann in der evcc-Konfiguration an die uri mittels &fwcsrf=<festes token> angehängt werden.

 

=== Poolsteuerung inkl. Eigenverbrauchsoptimierung und zusätzlichem Verbraucher, um Einspeiselimit zu vermeiden + manuelle Steuerung durch Sonderprogramme ===
'''Vorhandene Hardware:'''

* Poolpumpe, die über mehrere Stufen verfügt. Hier werden zwei verwendet.
** Pump Low: Energiesparprogramm um den Pool umzuwälzen, auch wenn nicht genug PV Leistung zur Verfügung steht. -> ca. 250W
** Pump High: Normalbetrieb wenn genug PV Überschuss zur Verfügung steht. -> ca. 800W zusätzlich
* Poolheizung: Wärmepumpe -> ca. 1,5kW elektrisch
* Nachbars Pool: Pumpe + Salzanlage +pH-Regler -> ca. 650W

'''Anforderungen:'''

* Pool muss täglich mindestens 1x umgewälzt werden.
* Im Idealfall wird der Pool > 2x umgewälzt.
* Bei genügend Überschuss soll der Pool geheizt werden. Es soll nur Sonnenstrom für die Poolheizung verwendet werden.
* Um das Einspeiselimit zu vermeiden, soll auch geheizt werden, wenn der Pool schon warm genug ist. (>28,5 °C)
* Sollte trotzdem noch das Einspeiselimit erreicht werden, soll auch der Pool des Nachbarn versorgt werden.

'''Herausforderungen:'''

* Verbraucher dürfen nur in einer gewissen Reihenfolge geschaltet werden, auch wenn der Überschuss eine andere Reihenfolge ergeben würde.
* Pumpe mit mehreren Stufen muss als zwei Consumer abgebildet werden, um die Schaltlogik in SolarForecast abzubilden. Würde die Trennung außerhalb von Solarforecast realisiert, könnte Solarforecast den Verbraucher schlechter "lernen", denn dann wäre es ein Consumer mit ständig wechselndem Verbrauch.
* Pool des Nachbarn darf nicht laut der benötigten Leistung geschaltet werden, sondern in Abhängigkeit der Einspeisebegrenzung.

In diesem Solarforcast-Device sind 16 Verbraucher definiert. Im Weiteren werden jedoch nur die verwendeten betrachtet. Da diese Reglung mittlerweile recht komplex ist, werden auch viele Dinge, die nicht SolarForcast betreffen, aber trotzdem dazu gehören, gezeigt. Es trägt zum Verständnis bei und man kann sich hier sicher Ideen holen.

'''Ergebnis:'''

In den folgenden beiden Bildern sieht man das Regelverhalten recht gut.
[[Datei:Mustertag ohne Wolken.jpg|zentriert|mini|823x823px|Wolkenloser Tag]]
Hier erkennt man gut das Einschalten der jeweiligen Verbraucher (Pump Low, Pump High, Wärmepumpe und Nachbar Pool). Die Wärempumpe schaltet erst bei 5kW Überschuss ein, da der Pool eigentlich schon warm genug ist. Sie dient "nur" dazu, das EInspeiselimit zu verhindern.Auch das Auschalten ist wieder deutlich zu erkennen. Die Regleung folgt dem Überschuss recht gut. (Die Leistungsspitzen auf dem Plateau sind normale Großverbraucher im Haus.)
[[Datei:Wechselhaft.jpg|zentriert|mini|818x818px|Wechselhafter Tag.]]
In diesem Bild sieht man das "verzweifelte" Regeln um das wechselhafte Wetter auszugleichen. Hier gibt es keine korrekte Reaktion und es wird durch die Sperrzeiten und andere Delays versucht, ein zu häufiges hin- und herschalten möglichst zu vermeiden. In Summe aber auch bei so einem Wetter ein akzeptables Verhalten.

'''Definition der Consumer:'''

'''Allgemeine Erklärungen zu den Definitionen:'''

'''asynchron=0''': Da hier die Werte des Überschusses für das Timing der Schaltvorgänge verwendet werden, darf hier keine Eventsteuerung verwendet werden. Sonst kann man nicht mehr sagen, über welchen Zeitraum der Mittelwert oder der Median gebildet wurde. Dafür wurde die Zykluszeit des SolarForecast-Device auf 60 Sekunden geändert, um die Überlegungen zu vereinfachen. Bei Event-Steuerung könnte man nicht sagen ob die letzten 10 Events in den letzten 5 Sekunden oder in den letzten 10 Minuten aufgetreten sind.

'''power=xxx''': Wurde teilweise etwas höher als der tatsächliche Wert gewählt, um nach dem Einschalten sicherzustellen, dass nicht sofort der gesamte Überschuss "verbraucht" wird und somit gleich wieder abgeschaltet wird.

'''auto=xxx''': Jeder Verbraucher benötigt sein eigenes auto-Reading, da die Automatik für die Regelung in verschiedenen Stufen ein- und ausgeschaltet werden muss.

'''dum_valve''': Dummy-Device in dem die Zustände der Regelung abgebildet werden. Notifys lesen bzw. befüllen diesen Dummy und steuern dann die Hardware bzw. wird der Dummy durch Werte aus der Hardware passend befüllt.

'''surpmeth=median_xx:''' Durch das asynchron=0 in allen Consumern und beim Generator wird von Solarforcast genau alle 60 Sekunden ein Zyklus ausgeführt. Das führt dazu, dass der Median genau über xx Minuten gebildet wird.

'''locktime=xx:xx''': Sicherheitsvorkehrung, dass nicht zu oft geschaltet werden kann. Schont die Hardware und verhindert ein Schwingen. Abhänging vom geschalteten Gerät. z.B. soll die Wärmepumpe möglichst wenig takten, um die Lebensdauer zu verlängern.

Es gibt dann auch noch einige weitere Sicherheitsvorkehrungen, um diese Regelung möglichst stabil und hardwareschonend zu gestalten. Die Schwierigkeit sind nicht die Bilderbuchtage mit einem glatten Verlauf der PV-Leistung, sondern Tage mit ständig wechselndem Überschuss in der Nähe der Schaltgrenzen.

'''swoncond= dum_valve:sf_true:{main::xxx_On}:''' Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann einzuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''swoffcond= dum_valve:sf_true:{main::xxx_Off}''': Hier werden verschiedene Zustände geprüft, um ein Gerät nur dann auszuschalten, wenn es sinnvoll und sicher ist.

Details unter '''99_mySolarForecastUtils.pm'''

'''Pump Low: (consumer01)'''
<syntaxhighlight lang="Perl">
dum_valve:Pool+Low
aliasshort=Low
asynchron=0
auto=pump_low_auto
icon=scene_pool
interruptable=0
mintime=SunPath:0:180
mode=must
noshow=0
notafter=08:00
off="pump_low off"
on="pump_low on"
pcurr=pump_low_power
power=250
surpmeth=median_13
switchdev=dum_valve
swoffcond=dum_valve:sf_true:{main::Check_Pump_Low_Off}
swoncond=dum_valve:sf_true:{main::Check_Pump_Low_On}
swstate=pump_low:on:off
type=other
</syntaxhighlight>Erläuterungen:

* Die Pumpe soll ab Sonnenaufgang, bis 180 Minuten nach Sonnenuntergang (mintime=SunPath:0:180), bei mindestens 250W Überschuss (power=250) gestartet werden.
* Die Pumpe muss spätestens um 8:00 eingeplant werden (notafter=08:00), um das Umwälzen auch bei Schlechtwetter zu garantieren.
* Die Pumpe muss gestartet werden (mode=must) sobald sie eingeplant ist.
* swoncond sorgt dafür, dass sie vor 8:00 nur bei genügend Überschuss gestartet wird, oder es 8:00 ist. swondcond ist mit der eigentlichen Einschaltbedingung (eingeplant und mode=must) UND verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* Überschuss wird auch in swoncond mit der gewählten Methode geprüft.
* Die Pumpe darf, wenn sie gestartet wurde, auch bei fehlendem Überschuss nicht mehr unterbrochen werden. (interruptable=0)
* Die Pumpe wird am Ende der Einplanung ausgeschaltet oder wenn swoffcond erfüllt ist. swoffcond wird true, wenn eine gewisse Wassermenge umgewälzt wurde oder die Sicherheitsbedingungen nicht (mehr) erfüllt sind. swoffcond ist mit der eigentlichen Ausschaltbedingung (Planung endet) ODER verknüpft. -> siehe '''99_mySolarForecastUtils.pm'''
* {'''main::'''xxx} dient dazu, um die Funktion xxx in der 99_mySolarForecastUtils.pm aus Solarforecast erreichbar zu machen.
* dum_valve:sf_true ist ein Reading, das fix 1 ist und als Vergleichswert für den in Klammern folgenden Perlcode dient. Wenn dieses Reading und der Perlcode gleich sind (1==1), ist die swoncond bzw swoffcond erfüllt.

'''Pump High: (consumer03)'''
<syntaxhighlight lang="Perl">
dum_valve:Pool+High
aliasshort=High
type=other power=1000 asynchron=0
auto=pump_high_auto
icon=scene_pool
pcurr=pump_high_power
switchdev=dum_valve
swstate=pump_high:on:off
mode=can
mintime=SunPath
on="pump_high on"
off="pump_high off"
surpmeth=median_5
noshow=0
locktime=180:300
interruptable=1
swoncond=dum_valve:sf_true:{main::Check_Pump_High_On}
swoffcond=dum_valve:sf_true:{main::Check_Pump_High_Off}
</syntaxhighlight>Erläuterungen:

* Pump HIgh ist die selbe Pumpe, aber eine höhere Durchflussmenge
* Der Mehrverbrauch beträgt eigentlich 800W wird hier aber mit 1000W angegeben, um eine Hysterese von ca. 200W zu erreichen und damit ein schnelles Abschalten nach dem Einschalten zu verhindern.
* Diese Stufe wird nur bei genügend Überschuss aktiviert. (mode=can)
* Diese Stufe wird bei fehlendem Überschuss unterbrochen. (interruptable=1)
* Diese Stufe wird nur während Sonnenschein eingeplant. (mintime=SunPath)
* locktime sorgt dafür, dass bei schnell wechselnden Bedingungen, nicht ständig umgeschaltet wird. -> Schonung der Pumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Heatpump: (consumer05)'''
<syntaxhighlight lang="perl">
Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800 asynchron=0
icon=sani_heating_heatpump
auto=heatpump_auto
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
etotal=Pool_Pin32_monotonic_count_EnergyMeter:kWh
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=1
swoffcond=dum_valve:sf_true:{main::CheckWPOff}
</syntaxhighlight>Erläuterungen:

* Der Verbrauch ist hier wieder etwas zu hoch angegeben (1800W statt realen 1500W), um eine Hysterese zu erreichen.
* Da es sich hier um eine Wärmepumpe handelt, die nicht getaktet werden sollte, ist die locktime in beide Schaltrichtungen mit 10 Minuten relativ hoch.
* Die Ermittlung des Medians ist mit 13 Minuten recht lang, um den Überschuss über lange Zeit zu glätten, damit möglichst selten geschaltet wird. Diese 13 Minuten in Kombination mit der Locktime und der Hysterese führten bei dieser Anlage bisher dazu, dass höchstens 5 Zyklen am Tag geschaltet wurden. -> Hier kann das individuelle Schaltverhalten optimiert werden. Besseres Verfolgen des Überschusses vs. weniger Taktungen der Wärmepumpe.
* swoncond und swoffcond -> siehe '''99_mySolarForecastUtils.pm'''

'''Nachbars Pool: (consumer07)'''
<syntaxhighlight lang="perl">
Shelly_Plug_S_1:Kurz+Pool
aliasshort=Kurz
type=other power=650 asynchron=0
icon=scene_pool
auto=pool_kurz_auto
pcurr=power:W
switchdev=dum_valve
swstate=pool_kurz:on:off
mode=can
mintime=SunPath
on="pool_kurz on"
off="pool_kurz off"
surpmeth=median_13
noshow=0
interruptable=1
locktime=600:300
swoncond=dum_valve:sf_true:{main::Check_Pool_Kurz_On}
swoffcond=dum_valve:sf_true:{main::Check_Pool_Kurz_Off}
</syntaxhighlight>Erläuterungen:

* Dieser Consumer dient als Einspeisebegrenzungsschutz und wird aktiviert, sobald sich der Überschuss der Einspeisegrenze nähert. -> siehe '''99_mySolarForecastUtils.pm'''
* Verbraucher kann recht träge geschaltet werden. (surpmeth=median_13 und locktime=600:300)
* Consumer wird ausgeschaltet wenn ein gewisser Überschuss unterschritten wird und somit die Einspeisegrenze wieder weit genug weg ist. -> siehe '''99_mySolarForecastUtils.pm'''
'''99_mySolarForecastUtils.pm'''

Hier sind die Funktionen, die für diese Regelung verwendet werden, der Übersichtlichkeit halber in einzelnen Blöcken mit Erklärungen dargestellt.
<syntaxhighlight lang="perl">
package main;
use strict;
use warnings;

my $pool_dummy = 'dum_valve';
my $pool_temperature = 'Pool_Temp';
my $flow_sensor = 'Pool_Pin_A0';
my $water_counter_l1 = 'pump_l1_hc';
my $water_counter_l2 = 'pump_l2_hc';
my $target_temp = 28.4; # maximum temperature for heating, without infeed limit
my $pool_kurz_sw_hofb = 'PwSw_Schalter'; # Homematic switch at pool neighbour
my $pool_kurz_sw_kurz = 'Shelly_Plug_S_1'; # Shelly switch for pool Kurz at home

my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;

my $switch_delay = 160; # just under three minutes

sub
SolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}

</syntaxhighlight>

* Hier werden die IDs der Geräte definiert, um über sprechende Namen darauf zugreifen zu können.
* Einige Devices und Parameter, die immer wieder gebraucht werden sind hier angegeben.
* sprintf wird verwendet um sicherzustellen, dass die IDs zweistellig sind. z.B. 3 -> 03

'''Pump Low'''
<syntaxhighlight lang="perl">
###################
### Pumpe - LOW ###
###################

sub
Check_Pump_Low_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'surpmethResult','');
my $nom_power = FHEM::SolarForecast::ConsumerVal ($name,$pump_low_id,'power','');
my ($min, $hour) = (localtime())[1,2];
my $timer = 0;
if($hour > 8 || ($hour == 8 && $min >= 0)){$timer=1;}

if(ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ($surplus > $nom_power
|| $timer
)
)
{
return 1;}
else
{
return 0;}
}

sub
Check_Pump_Low_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount > $desired_amount_l1)
&& (ReadingsVal($pool_dummy,"pump_high","on") eq "off" && ReadingsAge($pool_dummy,"pump_high",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{
return 1;
}else{
return 0;
}
}

</syntaxhighlight>Einschalten:

* Es wird der errechnete Wert für den Überschuss von SolarForecast verwendet und auch der benötigte Überschuss aus dem Consumer ausgelesen.
* Das Einschalten wird erst durch erfolgreiche Prüfung der Hardwarevoraussetzungen erlaubt. -> Das Motorventil steht richtig und es ist kein Sonderbetrieb (Reinigung, Massage, Winter, o.ä.) aktiv.
* Es muss entweder genügend Überschuss vorhanden sein oder es ist 8:00.

Ausschalten:

* Wenn der Badebetrieb aktiv ist (bath_mode==1, [bei Außentemperatur > 24°C]) wird nach 90m³ Gesamtumwälzung ausgeschaltet.
* Wenn der Badebetrieb nicht aktiv ist (bath_mode==0, [bei Außentemperatur < 20°C]) wird bereits nach 42m³ Gesamtumwälzung ausgeschaltet.
* Prüfung, ob Pump High schon aus ist. Sollte durch die Logik gar nicht möglich sein, aber es könnte manuell oder durch einen (Logik-)Fehler trotzdem eingeschaltet sein.
* Prüfung, ob alle Hardware-Funktionen in einem für die Automatik geeigneten Zustand sind.
* Es wird auch geprüft, ob Pump High seit mindestens 3 Minuten aus ist, um zu verhindern, dass wegen fehlendem Überschuss gleich mehrere Geräte ausgeschaltet werden.
* Da die Zykluszeit 60 Sekunden ist, führen die 160 Sekunden dazu, dass nach drei Minuten(180 Sekunden) ein definierter Wert gilt. Mit 180 Sekunden könnte es manchaml eine Minute mehr sein.

'''Pump High'''
<syntaxhighlight lang="perl">
####################
### Pumpe - HIGH ###
####################

sub
Check_Pump_High_On{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;
if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}

if(($amount < $desired_amount_l2)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_low","off") eq "on" && ReadingsAge($pool_dummy,"pump_low",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

sub
Check_Pump_High_Off{
my $bath_mode = ReadingsVal($pool_dummy,"bath_mode",0);
my $m3_l1 = ReadingsVal($water_counter_l1,"waterAmount",0);
my $m3_l2 = ReadingsVal($water_counter_l2,"waterAmount",0);
my $water_volume = AttrVal($pool_dummy,"water_volume",42); #42m³
my $desired_cf_l1 = AttrVal($pool_dummy,"desired_cf_l1",0); #circulation_factor_level1
my $desired_cf_l2 = AttrVal($pool_dummy,"desired_cf_l2",0); #circulation_factor_level2
my $bathmode_factor = AttrVal($pool_dummy,"bathmode_factor",1);
my $desired_amount_l1;
my $desired_amount_l2;
my $amount = $m3_l1 + $m3_l2;

if($bath_mode == 1){
$desired_amount_l1 = $desired_cf_l1 * $water_volume;
$desired_amount_l2 = $desired_cf_l2 * $water_volume;
}else{
$desired_amount_l1 = $desired_cf_l1 * $water_volume/$bathmode_factor;
$desired_amount_l2 = $desired_cf_l2 * $water_volume/$bathmode_factor;
}
if(($amount > $desired_amount_l2)
&& (ReadingsVal($pool_dummy,"heatpump","on") eq "off" && ReadingsAge($pool_dummy,"heatpump",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs noch nicht erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob Pump Low schon seit mindestens drei Minuten aktiv ist. (sollte eigentlich immer der Fall sein, wenn die Automatik für Pump High aktiv ist)

Ausschalten:

* Prüfung, ob die gewünschte Umwälzung bezüglich des Badebetriebs bereits erreicht wurde.
* Prüfung der Hardwarevoraussetzungen.
* Prüfung, ob die Wärmepumpe schon seit mindestens drei Minuten aus ist. Ermöglicht drei Minuten lang, den Median für den Überschuss zu aktualisieren.

'''Wärmepumpe'''
<syntaxhighlight lang="perl">
##################
### Wärempumpe ###
##################
sub
CheckWPOn(){
my $name = 'energy_mgmt';
my $surplus_on = 5000; # minimum surplus to avoid infeed limit with heatpump
my $surplus_restart = 3000; # minimum surplus to re-enable heatpump, when avoidung infeed limit and a big consumer turned the hp off

my $planstate = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'planstate','');
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if ($planstate =~ /^([^:]+)/) {
$planstate = $1;
}

if(ReadingsVal($flow_sensor,"reading","off") eq "on"
&& (ReadingsVal($pool_dummy,"special_function","") eq "none"
|| ReadingsVal($pool_dummy,"special_function","") eq "party"
)
&& ReadingsVal($pool_dummy,'heat_protection','on') eq "off"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
&& (ReadingsVal($pool_dummy,"pump_high","off") eq "on" && ReadingsAge($pool_dummy,"pump_high",0) > $switch_delay)
&& (ReadingsVal($pool_temperature,"temperature",30) < $target_temp
|| (ReadingsVal($pool_temperature,"temperature",15) >= $target_temp
&& ( $surplus > $surplus_on
|| (($planstate eq "replanned") && ($surplus > $surplus_restart))
)
)
)
)
{return 1}
else
{return 0}
}

sub
CheckWPOff{
my $name = 'energy_mgmt';
my $surplus_off = 1000; #minimum surplus to keep heatpump on, when avoiding infeed limit

my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$heatpump_id,'surpmethResult','');
if((ReadingsVal($flow_sensor,"reading","on") eq "off"
|| !((ReadingsVal($pool_dummy,"special_function","") eq "none")
|| (ReadingsVal($pool_dummy,"special_function","") eq "party")
)
|| ReadingsVal($pool_dummy,'heat_protection','off') eq "on"
|| ReadingsVal($pool_dummy,"valve_position","") ne "normal"
|| ((ReadingsVal($pool_temperature,"temperature",15) > $target_temp)
&& ($surplus < $surplus_off)
)
)
&& (ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) > $switch_delay)
)
{return 1}
else
{return 0}
}

</syntaxhighlight>Einschalten:

* Prüfung, ob Flussensor ein. (Pool_pin_A0) -> Wasser fließt durch die Wärmepumpe.
* Prüfung, ob Pool in Normal- oder Partybetrieb ist und das Ventil in Normalposition ist. In beiden Fällen läuft Pump High.
* Einschalten wenn genug Überschuss da ist und die Temperatur <28.4°C ist oder wenn über 5000W Überschuss (Einspeisebegrenzung bei 5900W) da ist, egal wie warm der Pool ist.
* Sonderfall: Wenn die Wärmepumpe durch einen/mehrere Großverbrucher "kurz" ausgeschaltet wurde (swoffcond) wird sie ausgeplant. Ein Notify plant sie wieder ein. Wenn das passiert, soll die Wärmepumpe aber wieder bei 3000W Überschuss gestartet werden, um die Energie noch weiter zu nutzen bis der Überschuss unter 1000W fällt. (Hysterese von 500W, da die WP nur 1500W braucht)

Ausschalten:

* Ausschalten sobald hardwaremäßig irgendetwas faul ist. (Betriebsart, Ventilstellung, Durchfluss)
* Ausschalten wenn kein Überschuss. (interruptable=1)
* Wenn Wassertemperatur über 28,5°C und der Überschuss kleiner als 1000W ist.
* Nur schalten, wenn Wärmepumpe läuft und seit mindestens drei Minuten läuft (Sicherheit). Das verhindert das erneute Triggern des Notifys, wenn die Pumpe schon aus ist. Sollte nicht passieren, aber sicher ist sicher.

'''Nachbar Pool'''
<syntaxhighlight lang="perl">
###################
### Pool - KURZ ###
###################
sub
Check_Pool_Kurz_On{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus > 3000)
&& ((ReadingsVal($pool_dummy,"heatpump","off") eq "on" && ReadingsAge($pool_dummy,"heatpump",0) >160) || ReadingsVal($pool_dummy,'heat_protection','off') eq 'on' ))
{return 1}
else
{return 0}
}

sub
Check_Pool_Kurz_Off{
my $name = 'energy_mgmt';
my $surplus = FHEM::SolarForecast::ConsumerVal ($name,$pool_kurz_id,'surpmethResult','');
if(($surplus < 1000 )
&& (ReadingsVal($pool_dummy,"pool_kurz","off") eq "on" && ReadingsAge($pool_dummy,"pool_kurz",0) >160))
{return 1}
else
{return 0}
}
</syntaxhighlight>Einschalten:

* Überschuss ist nahe der Einspeisegrenze (5900W) und Wärmepumpe läuft seit mindestens drei Minuten. Es wird schon bei 3000W eingeschaltet, um dem Nachbarn etwas Gutes zu tun ;-)

Ausschalten:

* Überschuss ist unter 1000W. -> Um noch Reserven für den eigenen Verbrauch zu haben.

'''Hilfsfunktionen'''

'''ctrlUserExitFn'''

Hier erfolgt nach jedem Zyklus die Festlegung der verschiedenen Automatikmodi.
<syntaxhighlight lang="perl">
#############################################################
##################### Exit Function #########################
#############################################################
my $ctrl_dummy = "dum_valve"; # dummy device for pool-control
my $automatic = ReadingsNum($ctrl_dummy,"sf_automatic",1);

if($automatic){

my $pump_low_state = ReadingsVal($ctrl_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe

my $pump_high_state = ReadingsVal($ctrl_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe

my $heatpump_state = ReadingsVal($ctrl_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
my $pool_heat_protection = ReadingsVal($ctrl_dummy,'heat_protection','on');

my $pool_kurz_state = ReadingsVal($ctrl_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools

my $pump_low_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_low_id, 'surpmeth', '');
if ($pump_low_delay =~ /_(\d+)/) {
$pump_low_delay = int(($1/2 + 1) * 60);
Log3 ("SolarForecast", 1, "SolarForecast: pump_low_delay: $pump_low_delay");
} else {
$pump_low_delay = 220;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_low is: $pump_low_delay, but must be given as method_number, using fallback value");
}

my $pump_high_delay = FHEM::SolarForecast::ConsumerVal ($name, $pump_high_id, 'surpmeth', '');
if ($pump_high_delay =~ /_(\d+)/) {
$pump_high_delay = int(($1/2 + 1) * 60);
} else {
$pump_high_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pump_high is: $pump_high_delay, but must be given as method_number, using fallback value");
}

my $heatpump_delay = FHEM::SolarForecast::ConsumerVal ($name, $heatpump_id, 'surpmeth', '');
if ($heatpump_delay =~ /_(\d+)/) {
$heatpump_delay = int(($1/2 + 1) * 60);
} else {
$heatpump_delay = 290;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for heatpump is: $heatpump_delay, but must be given as method_number, using fallback value");
}

my $pool_kurz_delay = FHEM::SolarForecast::ConsumerVal ($name, $pool_kurz_id, 'surpmeth', '');
if ($pool_kurz_delay =~ /_(\d+)/) {
$pool_kurz_delay = int(($1/2 + 1) * 60);
} else {
$pool_kurz_delay = 160;
Log3 ("SolarForecast", 1, "SolarForecast: warning - surpmeth for pool_kurz is: $pool_kurz_delay, but must be given as method_number");
}

############################
# Überhitzungsschutz aktiv #
############################

if($pool_heat_protection eq 'on'){
if($heatpump_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 0");
}
if($heatpump_state eq "on"){
fhem("set $ctrl_dummy heatpump off")
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $pool_kurz_delay && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $pump_high_auto == 1){
fhem("set $ctrl_dummy pump_high_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $pump_high_delay && $pool_kurz_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
##################################
# Überhitzungsschutz nicht aktiv #
##################################
}else{
if($heatpump_auto == 0 && $heatpump_state eq "off"){
if($pool_kurz_state eq "on"){
fhem("set $ctrl_dummy pool_kurz off");
}
if($pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
}
}
#################
#### on-chain ###
#################
if($pump_low_state eq "on" && ReadingsAge($ctrl_dummy,'pump_low',0) > $pump_high_delay && $pump_high_auto == 0 && $heatpump_auto == 0 && $pool_kurz_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "on" && ReadingsAge($ctrl_dummy,'pump_high',0) > $heatpump_delay && $heatpump_auto == 0 && $pool_kurz_auto == 0 && $pump_high_auto == 1){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "on" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pool_kurz_delay && $pump_high_state eq "on" && $pool_kurz_auto == 0 && $pump_high_auto == 1 && $heatpump_auto == 1){
# pump_high muss on sein, da sonst die automatik ausgeschaltet wird wenn die pumpe gerade interrupted ist.
# Bei unterschiedlichen Medianlängen ist es möglich, dass WP ein ist und pump_high abschaltet wegen surplus == 0
# Nachbarpool würde auf EIN warten, aber pump_high dürfte nicht wieder einschalten, obwohl genügend Überschuss da ist.
fhem("set $ctrl_dummy pump_high_auto 0");
fhem("set $ctrl_dummy pool_kurz_auto 1");
}elsif($pool_kurz_state eq "on" && $pool_kurz_auto == 1 && $heatpump_auto == 1 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 0");
}

#################
### off-chain ###
#################
if($pool_kurz_state eq "off" && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $heatpump_delay && $pool_kurz_auto == 1 && $heatpump_auto == 0 && $pump_high_auto == 0){
fhem("set $ctrl_dummy heatpump_auto 1");
}elsif($heatpump_state eq "off" && ReadingsAge($ctrl_dummy,'heatpump',0) > $pump_high_delay && $heatpump_auto == 1 && $pump_high_auto == 0 && $pool_kurz_auto == 1){
fhem("set $ctrl_dummy pool_kurz_auto 0");
fhem("set $ctrl_dummy pump_high_auto 1");
}elsif($pump_high_state eq "off" && $heatpump_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 1 && $pool_kurz_auto == 0){
# heatpump muss aus sein, da sonst vor Ablauf der Locktime die Automatik ausgeschaltet wird und die WP nicht mehr ausschalten kann.
fhem("set $ctrl_dummy heatpump_auto 0");
}elsif($pump_low_state eq "off" && $pump_high_state eq "off" && $pump_high_auto == 1 && $heatpump_auto == 0){
fhem("set $ctrl_dummy pump_high_auto 0");
}
}
}
#################################################
# Check hardware-state vs. reading-state
# re-trigger notify
#################################################
my $delay_retrigger = 100; #delay time to wait until re-trigger the notify

if(ReadingsVal($ctrl_dummy,'pool_kurz','on') eq 'off' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'on'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: off");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-off must be re-triggered");
DebianMail('mail@example.org','Notify Pool Kurz',"Notify hat nicht ausgeschaltet -> re-trigger");
}elsif(ReadingsVal($ctrl_dummy,'pool_kurz','off') eq 'on' && ReadingsAge($ctrl_dummy,'pool_kurz',0) > $delay_retrigger && ReadingsVal($pool_kurz_sw_kurz,'state','on') eq 'off'){
# re-trigger notify
fhem("trigger dum_valve pool_kurz: on");
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz-on must be re-triggered");
DebianMail('mail@example.org','Notify Pool Kurz',"Notify hat nicht eingeschaltet -> re-trigger");
}elsif((ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_on' || ReadingsVal($pool_kurz_sw_kurz,'state','off') eq 'set_off') && ReadingsAge($pool_kurz_sw_kurz,'state',0) > $delay_retrigger){
# state not clear
Log3 ("SolarForecast", 1, "SolarForecast: Pool-Kurz state unclear");
DebianMail('mail@example.org','Status Pool Kurz unklar',"Status HM-Schalter set_xx");
}

}
1;
</syntaxhighlight>
'''Erläuterungen:'''

* '''Verzögerungen der einzelnen Stufen:'''
** Die delays der einzelnen Stufen werden aus den surpmethods berechnet. Das dient dazu, dass der Median mit den Werten nach dem ein-/ausschalten des vorheriegen Verbrauchers bis zur Hälfte + einen Wert gefüllt wird und somit sicher das Umschalten des vorherigen Verbrauchers den Median nicht mehr beeinflusst.
* '''Überhitzungsschutz:'''
** Da durch die Wärmepumpe Überschuss "verheizt" wird, der durch das Einspeiselimit gar nicht produziert würde, kann es vorkommen, dass der Pool unangenehm warm wird.
** Um das zu vermeiden gibt es ein Reading, welches gesetzt wird, wenn der Pool eine gewisse Temperatur überschreitet. Dieses Setzen und Zurücksetzen erfolgt mit einer Hysterese von 0.2°C, um ein Takten der Wärmepumpe zu verhindern. Diese 0.4°C sind bei dieser Wassermenge einige Stunden.
** Wenn der Überhitzungsschutz aktiv ist, wird die Wärmepumpe in der Kette übersprungen.
** Wenn sich der Hitzeschutz während des Betriebs ändert, wird die Wärmepumpe bzw. der Pool vom Nachbarn passend ausgeschaltet und die Modi entsprechend gesetzt.
* '''On-chain:'''
** Wenn am Morgen Pump Low seit $pump_low_delay aktiv ist und alle folgenden Consumer noch nicht, dann wird die nächste Stufe freigegeben. -> Pump High
** Wenn Pump High seit $pump_high_delay aktiv ist und alle folgenden Consumer noch nicht, wird die Wärmepumpe freigegeben. -> Heatpump
** Wenn die Wärmepumpe seit $heatpump_delay aktiv ist und der letzte Consumer noch nicht, wird der letzte Verbraucher freigegeben. -> Pool Kurz Gleichzeitig wird die Automatik für Pump High ausgeschaltet, da dieser Verbraucher erst unterbrochen werden darf wenn die Wärmepumpe aus ist!
** Wenn der letzte Verbraucher aktiviert ist, wird die Automatik der Wärmepumpe deaktiviert, da ja zuerst der letzte Verbraucher (Pool Kurz) wieder ausgeschaltet werden muss, bevor der vorletzte (Wärmepumpe) wieder ausgeschaltet werden darf. Da es keinen nachfolgenden Verbraucher mehr gibt, kann hier auf ein delay verzichtet werden, da es nicht passieren kann, dass zwei Verbraucher wegen sehr hohem Überschuss unmittelbar hintereinander geschaltet werden können.
[[Datei:Poolsteuerung mit unterschiedlichen Automatikmodi.jpg|alternativtext=Poolsteuerung|mini|Consumer der Poolsteuerung|500x500px]]
'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von fehlendem Überschuss jederzeit unterbrochen werden kann und der "folgende" Consumer, der auf das Einschalten wartet. Pump Low ist immer im Automatikmodus, da diese nie unterbrochen wird. (mode=must, interruptable=0)

* '''Off-chain:'''
** Wenn der letzte Verbraucher seit mindestens der delay-Zeit aufgrund von fehlendem Überschuss inaktiv war, im Automatikmodus ist und der vorherige Verbraucher nicht im Automatikmodus ist, wird der vorherige Verbraucher in den Automatikmodus geschaltet und wartet jetzt auch auf das Ausschalten. Wenn der Überschuss steigt, springt man wieder in die on-chain und der letzte Verbraucher wird eingeschaltet und die Automatik des vorletzten Verbrauchers deaktiviert.
** Wenn die Wärmepumpe seit mindestens der delay-Zeit aus ist, sich im Automatikmodus befind und Pump High noch nicht im Automatikmodus ist, wird die Automatik für den Nachbarpool ausgeschaltet, da er ja jetzt nicht mehr einschalten darf, da zuerst die Wärmepumpe ein sein müsste. Die Automatik von Pump High wird wieder aktiviert, da diese jetzt auf das Ausschalten wartet. Steigt der Überschuss wieder, wird in den entsprechenden On-chain Zweig gesprungen.
** Wenn Pump High mindestens die delay-Zeit aus ist, wird die Automatik der Wärmepumpe deaktiviert, da diese ja erst einschalten darf, wenn Pump High wieder läuft. Steigender Überschuss führt wieder zum aktivieren von Pump High und zum Sprung in den entsprechenden On-chain Zweig.
** Wenn Pump Low ausgeschaltet wird, wird sofort die Automatik für Pump High ausgeschaltet, da durch das spätere Ausschalten von (der evtl. wieder eingeschalteten) Pump High, hardwaremäßig wieder Pump Low aktiviert wird, aber durch SolarForecast nie ausgeschaltet wird, da Pump Low vor ein paar Minuten ja schon logisch ausgeschaltet wurde.

'''Wichtig:''' Es dürfen immer nur maximal zwei unterbrechbare Consumer im Automatikmodus sein. Der "aktuelle", der ja aufgrund von neuem Überschuss jederzeit wieder gestartet werden kann und der "vorherige" Consumer, der auf das Ausschalten wartet.

* '''Synchronisation Hardware vs. Reading:'''Manchmal passiert es, dass durch die etwas aufwendigen Umschaltprozesse die Hardware dem Reading nicht folgt/folgen kann. Evtl. Gründe sind Funkunterbrechung, verzögerte Umschaltung usw. Daher wird bei jedem Zyklus der Status geprüft und evtl. das event nochmal getriggert, um die Umschaltung erneut auszuführen. 

'''Hilfs-Notifys für die Automatik'''

Da durch das Verwenden von swoffcond die Verbraucher beim Ausschalten auch ausgeplant werden, aber eigentlich "nur" unterbrochen werden sollen, müssen sie wieder neu eingeplant werden. Dazu sind notifys nötig. Wichtig: IDs müssen zweistellig angegeben werden!

Wärmepumpe:
<syntaxhighlight lang="perl">
dum_valve:heatpump:.off sleep 10; set energy_mgmt consumerNewPlanning 05
</syntaxhighlight>
Nachbar Pool:
<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.off sleep 10; set energy_mgmt consumerNewPlanning 07
</syntaxhighlight>

'''Eine Pumpe mit einem Energiezähler als zwei Consumer verwenden'''

Die verwendete Pumpe hat vier Betriebsarten mit unterschiedlichen Leistungen. Da sie als zwei Consumer abgebildet wird, führt das dazu, dass die Leistung fälschlicherweise von SolarForecast auch zweimal gezählt wird. Die Lösung sind Dummy-Readings, welche die Leistungsdaten passend auseinander rechnen.
<syntaxhighlight lang="perl">
Pool_Strom_Pumpe:Pool_Pin31_monotonic_count_PowerCurrent:.* {
my $power = $EVTPART1;
my $pump_low = ReadingsVal('dum_valve','pump_low','off');
my $pump_high = ReadingsVal('dum_valve','pump_high','off');
my $power_low_sim = 250;

if($pump_low eq "on" && $pump_high eq "on"){
my $power_low = $power_low_sim; #fiktiver Verbrauch der niedrigen Stufe
my $power_high = $power - $power_low_sim;
fhem("set dum_valve pump_low_power $power_low");
fhem("set dum_valve pump_high_power $power_high");
}
elsif($pump_low eq "on" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power $power");
fhem("set dum_valve pump_high_power 0");
}
elsif($pump_low eq "off" && $pump_high eq "off"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power 0");
}elsif($pump_low eq "off" && $pump_high eq "on"){
fhem("set dum_valve pump_low_power 0");
fhem("set dum_valve pump_high_power $power");
}
}
</syntaxhighlight>
Erläuterungen:

* Es sind alle vier Möglichkeiten der zwei Pumpenlevel abgebildet.
* Wenn die Automatik deaktiviert ist und die Level 1-4 von extern geschaltet werden, zählen sie dadurch korrekterweise nicht zu diesen beiden Consumern.

'''Notifys für das hardwaremäßige Schalten der Consumer'''

Es werden einige Notifys verwendet, die die Umsetzung vom Dummy-Device auf die Hardware erledigen, da ein logisches Ein teilweise hardwaremäßig einige Dinge erfordert.

Notify für Pump Low:
<syntaxhighlight lang="perl">
dum_valve:pump_low:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 60; set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin14 off; sleep 5; set Pool_Pin12 off; sleep 15; set Pool_Pin25 off");
}else{
Log3 ("Pool", 4, qq{Notify Level1 - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterungen:

* Beim Einschalten ist es nötig für eine Minute Pump High zu aktivieren, um Luft aus der Elektrolysezelle zu spülen, bevor Pump Low aktiv sein darf. (Pin26 und Pin25 sind die Steuerpins auf der Interfacekarte der Pumpe für die beiden Level.)
* Beim Ausschalten werden zuerst die Salzanlage (Pin14) und die pH-Anlage (Pin12) deaktiviert, damit noch 15 Sekunden lang die Elektrolysezelle mit frischem Wasser gespült wird, um das verbleibende Chlor auszuspülen. 
Notify für Pump High:
<syntaxhighlight lang="perl">
dum_valve:pump_high:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin26 on; sleep 1; set Pool_Pin25 off");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin25 on; sleep 1; set Pool_Pin26 off");
}else{
Log3 ("Pool", 4, qq{Notify Level 2- parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Da die Interfacekarte immer auf den höchsten Level reagiert, wird beim Umschalten zuerst Pump High aktiviert und nach einer Sekunde Pump Low deaktiviert, um ein "stufenloses" (ohne Ausschalten) Umschalten zu ermöglichen. Beim Ausschalten genauso.

Notify für die Wärmepumpe:
<syntaxhighlight lang="perl">
dum_valve:heatpump:.* {
if($EVTPART1 eq "on"){
fhem("set Pool_Pin6 on");
}elsif($EVTPART1 eq "off"){
fhem("set Pool_Pin6 off");
}else{
Log3 ("Pool", 4, qq{Notify heatpump - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung:

* Hier reicht ein dirketes Übernehmen aus dem Dummy.

Notify für den Nachbar-Pool:
<syntaxhighlight lang="perl">
dum_valve:pool_kurz:.* {
if($EVTPART1 eq "on" && ReadingsVal("Shelly_Plug_S_1","state","on") eq "off"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 on\")}}; sleep 5; set PwSw_Schalter on");
}elsif($EVTPART1 eq "off" && ReadingsVal("Shelly_Plug_S_1","state","off") eq "on"){
fhem("set PwSw_Schalter off; sleep 3;{if(ReadingsAge(\"PwSw_Schalter\",\"state\",0)<4 && ReadingsVal(\"PwSw_Schalter\",\"state\",\"on\") eq \"off\"){fhem(\"set Shelly_Plug_S_1 off\")}}; sleep 5; set PwSw_Schalter on");
}else{
Log3 ("Pool", 4, qq{Notify Pool Kurz - parameter is not on or off});
}
}
</syntaxhighlight>Erläuterung

* Da hier eine Pumpe durch einen 3-poligen Umschalter zwischen zwei Hausanspeisungen umgeschaltet wird, ist es wichtig, dass die Pumpe dazwischen '''gesichert''' zum Stehen gebracht wird! Sonst führt die rotierende Pumpe als Generator zu einem gewaltigen Kurzschluss mit der "fremden" Phase. War nicht schön ...

'''Sonderprogramme für den Poolbetrieb'''

Hier ist das Aus- und Einschalten der Solarforcast-Automatik zu sehen. Es werden alle Stati gespeichert. Danach kann von beliebigen "Sonderfunktionen" (Reinigung des Filters, Massagefunktion, usw.) auf die Hardware zugegriffen werden. Wenn wieder in den Automatikmodus zurückgewechselt wird, wird hardwaremäßig wieder der Zustand der Automatik von vorher hergestellt, die Stati wieder zurück geschrieben und die Automatik wieder aktiviert.
<syntaxhighlight lang="perl">
##############################################
# Status speichern und Automatik ausschalten #
##############################################
sub PoolAutoOff{
my $pump_low_id = sprintf "%02d", 1;
my $pump_high_id = sprintf "%02d", 3;
my $heatpump_id = sprintf "%02d", 5;
my $pool_kurz_id = sprintf "%02d", 7;
my $sf = 'energy_mgmt';

# my $pump_low_state = ReadingsVal($valve_dummy,'pump_low','on');
my $pump_low_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_low_id, 'auto', ''); # Automatikmodus der Pumpe
# my $pump_high_state = ReadingsVal($valve_dummy,'pump_high','on');
my $pump_high_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pump_high_id, 'auto', ''); # Automatikmodus der Pumpe
# my $heatpump_state = ReadingsVal($valve_dummy,'heatpump','on');
my $heatpump_auto = FHEM::SolarForecast::ConsumerVal ($sf, $heatpump_id, 'auto', ''); # Automatikmodus der Wärmepumpe
# my $pool_kurz_state = ReadingsVal($valve_dummy,'pool_kurz','on');
my $pool_kurz_auto = FHEM::SolarForecast::ConsumerVal ($sf, $pool_kurz_id, 'auto', ''); # Automatikmodus des Pools
fhem("set $valve_dummy pump_low_auto 0");
fhem("set $valve_dummy pump_high_auto 0");
fhem("set $valve_dummy heatpump_auto 0");
fhem("set $valve_dummy pool_kurz_auto 0");
fhem("setreading $valve_dummy sf_automatic 0");
fhem("setreading $valve_dummy last_auto_pump_low $pump_low_auto");
fhem("setreading $valve_dummy last_auto_pump_high $pump_high_auto");
fhem("setreading $valve_dummy last_auto_heatpump $heatpump_auto");
fhem("setreading $valve_dummy last_auto_pool_kurz $pool_kurz_auto");

my $last_pump_level_1 = ReadingsVal($valve_dummy,"pump_low","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"pump_high","off");
my $last_pump_level_3 = ReadingsVal($pump_level_3,"value","off");
my $last_pump_level_4 = ReadingsVal($pump_level_4,"value","off");
my $last_heatpump = ReadingsVal($valve_dummy,"heatpump","off");
fhem("setreading $valve_dummy last_pump_level_1 $last_pump_level_1");
fhem("setreading $valve_dummy last_pump_level_2 $last_pump_level_2");
fhem("setreading $valve_dummy last_pump_level_3 $last_pump_level_3");
fhem("setreading $valve_dummy last_pump_level_4 $last_pump_level_4");
fhem("setreading $valve_dummy last_heatpump $last_heatpump");
}

##########################################
# Status laden und Automatik einschalten #
##########################################
sub PoolAutoOn{
my $last_pump_level_4 = ReadingsVal($valve_dummy,"last_pump_level_4","off");
my $last_pump_level_3 = ReadingsVal($valve_dummy,"last_pump_level_3","off");
my $last_pump_level_2 = ReadingsVal($valve_dummy,"last_pump_level_2","off");
my $last_pump_level_1 = ReadingsVal($valve_dummy,"last_pump_level_1","off");
my $last_heatpump = ReadingsVal($valve_dummy,"last_heatpump","off");
fhem("set $pump_level_4 $last_pump_level_4");
fhem("set $pump_level_3 $last_pump_level_3");
fhem("set $pump_level_2 $last_pump_level_2");
if($last_pump_level_1 eq "on" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_2 on; sleep 1; set $pump_level_1 $last_pump_level_1; sleep 28; set $pump_level_2 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "on" && $last_pump_level_2 eq "on" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}elsif($last_pump_level_1 eq "off" && $last_pump_level_2 eq "off" && $last_pump_level_3 eq "off" && $last_pump_level_4 eq "off"){
fhem("set $pump_level_1 off; set $valve_dummy sf_automatic 1");
}
fhem("sleep 10; set $heatpump $last_heatpump");
fhem("setreading $valve_dummy last_pump_level_1 none");
fhem("setreading $valve_dummy last_pump_level_2 none");
fhem("setreading $valve_dummy last_pump_level_3 none");
fhem("setreading $valve_dummy last_pump_level_4 none");
fhem("setreading $valve_dummy last_heatpump none");
fhem("setreading $valve_dummy valve_position normal");
my $last_auto_pump_low = ReadingsVal($valve_dummy,"last_auto_pump_low",0);
my $last_auto_pump_high = ReadingsVal($valve_dummy,"last_auto_pump_high",0);
my $last_auto_heatpump = ReadingsVal($valve_dummy,"last_auto_heatpump",0);
my $last_auto_pool_kurz = ReadingsVal($valve_dummy,"last_auto_pool_kurz",0);
fhem("set $valve_dummy pump_low_auto $last_auto_pump_low");
fhem("set $valve_dummy pump_high_auto $last_auto_pump_high");
fhem("set $valve_dummy heatpump_auto $last_auto_heatpump");
fhem("set $valve_dummy pool_kurz_auto $last_auto_pool_kurz");
fhem("setreading $valve_dummy last_auto_pump_low none");
fhem("setreading $valve_dummy last_auto_pump_high none");
fhem("setreading $valve_dummy last_auto_heatpump none");
fhem("setreading $valve_dummy last_auto_pool_kurz none");
}
</syntaxhighlight>Erläuterungen:

* pump_level_1 ist Pump Low, pump_level_2 ist Pump High, pump_level_3 und pump_level_4 sind Sonderfunktionen (Filterreinigung, Massage)
* Beim Wiedereinschalten von Pump Low ist es wieder nötig kurz Pump High zu aktivieren, um Luft auszuspülen.
* Es wird der Zustand von Solarforecast gespeichert und danach auf die Hardware geschrieben. -> Stellt sicher, dass nach dem Einschalten der Automatik der logical switchstate zum physical switchstate passt.

=== Wärmepumpe (Buderus oder Bosch) per MQTT-Modul & BBQKees-EMS-Modul als besonderen ConsumerXX (Heatpump) für die Consumption-Prognose bei den Berechnungen in der AI::FANN einbinden ===
'''Vorhandene Hardware:'''

* FHEM auf einer bestehenden Hardware mit bestehendem Solarforecast
* Buderus WLW186-i 7 MB AR E
* WW-Speicher 290 ltr.
* Heizungspuffer 120 ltr.
* HK1 = FBH - - mit 1 x HK-Pumpe ON/OFF und 1x Mischer
* HK2 = (Rest-)Heizkörper im EG/1OG/Handtuchw. - mit 1 x HK-Pumpe ON/OFF (ohne Mischer)
* HK3 = Heizkörper KG (einheitlich max 16 Grad) - mit 1 x HK-Pumpe ON/OFF (ohne Mischer)
* Zusatzheizstab für Sommerbetrieb im WW-Speicher - Nutzung erfolgt nur bei PV-Überschuß tagsüber oder genügend Batterierladung am frühen Morgen gegen 04:00 Uhr.

'''Anforderungen / notwendige Einstellung :'''

* SF ist in Betrieb und die AI::FANN sollte sich aktiv im Einsatz.
* Wärmepumpe befindet sich dauerhaft im temperaturgeführten Betriebsmodus.
* BBQKees-EMS-ESP-Modul ist angeschlossen, installiert, in Betrieb und kann per Webbrowser erreicht werden. Beispieleinrichtung: [[Datei:Einstellung - MQTT - BBQKees.png|ohne|mini|300x300px|Einstellung - MQTT - BBQKees]]
* '''MQTT-Modul greift in FHEM auf die WP mittels BBQKees-EMS-Modul zu.''' Beispiel-Device:
<syntaxhighlight lang="perl">
defmod MQTT_EMSwp MQTT2_DEVICE MQTT_EMSwp
attr MQTT_EMSwp DbLogExclude BSSID,IODev,IPv4_address,IPv4_gateway,IPv4_nameserver,IPv6_address,MAC,SSID,apicalls,\
apifails,attrTemplateVersion,boiler_data_auxheaterdelay,boiler_data_auxheaterlevel,\
boiler_data_auxheateroff,boiler_data_auxheateronly,\
boiler_data_auxheatersource,boiler_data_auxheatrmode,boiler_data_auxlimitstart,\
boiler_data_auxmaxlimit,boiler_data_burn2workmin,\
boiler_data_burnstarts,boiler_data_burnworkmin,boiler_data_dhw_alternatingop,boiler_data_dhw_altopprio,\
boiler_data_dhw_altopprioheat,boiler_data_dhw_comfdiff,boiler_data_dhw_comfort1,\
boiler_data_dhw_comfstop,boiler_data_dhw_disinfecting,boiler_data_dhw_disinfectiontemp,\
boiler_data_dhw_ecodiff,boiler_data_dhw_ecoplusdiff,\
boiler_data_dhw_ecoplusoff,boiler_data_dhw_ecoplusstop,boiler_data_dhw_ecostop,\
boiler_data_dhw_flowtempoffset,boiler_data_dhw_hystoff,boiler_data_dhw_hyston,boiler_data_dhw_maxheat,\
boiler_data_dhw_onetime,boiler_data_dhw_recharging,boiler_data_dhw_seltemp,\
boiler_data_dhw_seltemplow,boiler_data_dhw_seltempsingle,boiler_data_dhw_tempecoplus,\
boiler_data_dhw_workm,bootTime,boot_time,bus_status,connected,freemem,heartbeat_.*,mqttcount,mqttfails,\
mqttreconnects,network,rssi,rxfails,rxreceived,txfails,txreads,txwrites,uptime,uptime_sec,wifistrength,wifireconnects,\
thermostat_data_datetime
attr MQTT_EMSwp autocreate 1
attr MQTT_EMSwp bridgeRegexp heartbeat:.* { json2nameValue($EVENT) }
attr MQTT_EMSwp comment
Autorisierung / Token: \
The bearer Access Token (JWT) is used to authenticate HTTP requests and can be obtained from the \
WebUI's Settings->Security->Manage Users page and then clicking on the key icon for the user that has admin privileges (is Admin set). \
The token is generated using a combination of the username and a secret key which is the super user (su) password found in the WebUI's Settings->Security->Security Settings page. \
This 152 character long string must be included in the HTTP header as "Authorization: Bearer {ACCESS_TOKEN}". Note the token has no expiry date.\
\
<bearer Acts Token> "dieser WLW186-7 MB AR E" = {ACCESS_TOKEN}\
Beispiele :\
#############\
# Most GETs do not need authentication\
% curl http://ems-esp.local/api/thermostat/seltemp\
\
# POSTs (with -d) need authentication tokens\
% curl http://ems-esp.local/api/thermostat/seltemp \\
-H 'Content-Type: application/json' \\
-H 'Authorization: Bearer <bearer Acts Token>' \\
-d '{ "value" : 22.5 }'\
\
# GET with authentication using query parameter with token\
% curl http://ems-esp.local/api/system/publish\?access_token\="ey.......0"\
\
# GET to restart EMS-ESP\
curl http://ems-esp.local/api/system/restart -H 'Authorization: Bearer ey....0'\
\
# This example will get the system info, via a GET request\
curl -X GET ${emsesp_url}/api/system/info\
\
# This example will execute a read command on product ID 8 and type ID 1\
curl -X POST \\
-H "Authorization: Bearer ${<bearer Acts Token>}" \\
-H "Content-Type: application/json" \\
-d '{"data":"8 1"}' \\
${emsesp_url}/api/system/read\
\
# This example will export all values to a json file, including custom entities, sensors and schedules\
curl -X POST \\
-H "Authorization: Bearer ${<bearer Acts Token>}" \\
-H "Content-Type: application/json" \\
-d '{"action":"export", "param":"allvalues"}' \\
${emsesp_url}/rest/action
attr MQTT_EMSwp disable 0
attr MQTT_EMSwp event-min-interval .*:600
attr MQTT_EMSwp event-on-change-reading .*
attr MQTT_EMSwp icon air_water_heating_pump
attr MQTT_EMSwp model ems-esp_heater_device
attr MQTT_EMSwp readingList MQTT_EMSwp:ems-esp/heartbeat:.* { json2nameValue($EVENT) }\
MQTT_EMSwp:ems-esp/status:.* status\
MQTT_EMSwp:ems-esp/info:.* { json2nameValue($EVENT) }\
MQTT_EMSwp:ems-esp/heating_active:.* heating_active\
MQTT_EMSwp:ems-esp/tapwater_active:.* tapwater_active\
MQTT_EMSwp:ems-esp/boiler_data:.* { json2nameValue($EVENT, 'boiler_data_', $JSONMAP) }\
MQTT_EMSwp:ems-esp/thermostat_data:.* { json2nameValue($EVENT, 'thermostat_data_', $JSONMAP) }\
MQTT_EMSwp:ems-esp/mixer_data:.* { json2nameValue($EVENT, 'mixer_data_', $JSONMAP) }
attr MQTT_EMSwp room EnergieWP,MQTT2_DEVICE
attr MQTT_EMSwp setList restart:noArg heartbeat:.* { json2nameValue($EVENT) }
attr MQTT_EMSwp stateFormat T=>> Out: boiler_data_outdoortemp ModeCirc: thermostat_data_dhw_circmode WW: boiler_data_dhw_curtemp Circ: boiler_data_dhw_circ VL: boiler_data_curflowtemp RL: boiler_data_rettemp HC1-Flow: mixer_data_hc1_flowtemphc P.-Status HK1: mixer_data_hc1_pumpstatus P.-Status HK2: mixer_data_hc2_pumpstatus HP_Power_Current: boiler_data_hpcurrpower HP_Power_Reduction: boiler_data_powerreduction
attr MQTT_EMSwp userReadings user_WP_JAZ_overall {\
if ((ReadingsNum($name,"boiler_data_metertotal",0) > 0) && (ReadingsNum($name,"boiler_data_nrgtotal",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum($name,"boiler_data_nrgtotal",0)/ReadingsNum($name,"boiler_data_metertotal",0))));;;;\
}\
},\
\
user_WP_JAZ_year \
{\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionYear",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalYear",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalYear",0)/ReadingsNum("Dum.Energy","WPGridConsumptionYear",1))));;;;\
}\
},\
\
user_WP_JAZ_month {\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionMonth",0) > 0)&& (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalMonth",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalMonth",0)/ReadingsNum("Dum.Energy","WPGridConsumptionMonth",1))));;;;\
}\
},\
\
user_WP_JAZ_day {\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionDay",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalDay",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalDay",0)/ReadingsNum("Dum.Energy","WPGridConsumptionDay",1))));;;;\
}\
}, \
\
user_WP_JAZ_hour {\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionHour",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalhour",0) > 0))\
{ \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalhour",0)/ReadingsNum("Dum.Energy","WPGridConsumptionHour",1))));;;;\
}\
}, \
</syntaxhighlight>Anmerkung: user_WP_JAZ_XXXX für Tag/Monat/Jahr werden in einem separatem Dummy (für diese Zeiträume) bei mir berechnet. Allein user_JAZ-overall (Betrachtung der gesamten WP-Betriebszeit) wird in diesem MQTT-Device aus den hier im Device vorhanden Zahlenwerte berechnet.
* '''Definierung des attr Heatpump-"consumerXX" in SF'''
<syntaxhighlight lang="perl">
SMA_Elgris_EM2
####>>> EM-Gesamtenergieflüsse der WP
type=heatpump
####>>> "Spezial"-Consumer - keine ON/OFF-Schaltung des Consumer durch SF bei Typ heatpump möglich !!!
power=2500
####>>> ich untertreibe hier immer etwas extra - es wird bei mir sehr wenig bis zu 3100 W verbraucht
icon=sani_heating_heatpump@orange
####>>> oder ein anderes icon nach Wahl oder des Vorhandenseins.
pcurr=Bezug_Wirkleistung:W
####>>> aus dem EM
etotal=Bezug_Wirkleistung_Zaehler:kWh ## aus dem EM
####>>> aus dem EM
switchdev=MQTT_EMSwp
####>>> wenn man zukünftig evtl. selber schaltent eingreifen möchte
swstate=boiler_data_hpactivity:heating|cooling|hot.*:off
####>>> auf die WP-Readings zugreifen
comforttemp=MQTT_EMSwp:thermostat_data_hc1_comforttemp
####>>> Komfortemperatur des Referenzraumes (Wert für Prognose AI::FANN) meist der Wohnraum
####>>> Komfortemperatur kann auch als fester Wert - z.B. 20 - eingeben werden.fest
</syntaxhighlight>Anmerkung: Kommentarzeilen bitte besser löschen falls dieser Beispiel-Code 1:1 genutzt werden soll.
* '''Definierung des attr "setupEnviroment" in SF'''
<syntaxhighlight lang="perl">
outsideTemp=MQTT_EMSwp:boiler_data_outdoortemp
####>>> Aussentemperatur - alternativ ein anderer T-Füher oder Wetter-App-Wert
presence=Forecast:user_presence:present
####>>> Anwesenheit der Bewohner mitteilen - ansonsten geht die AI::FANN in SF immer von "Anwesend" aus
</syntaxhighlight>Anmerkung:

Kommentarzeilen bitte besser löschen falls dieser Beispiel-Code 1:1 genutzt werden soll.

* '''Definierung von notwendigen zusätzlichen "UserReadings" für "presence" in SF:'''
<syntaxhighlight lang="perl">

user_presence {if(ReadingsVal("Handy_01","state","") eq "present") {return "present"} elsif (ReadingsVal("Handy_02","state","") eq "present") {return "present"} else {return 0}},

</syntaxhighlight>Anmerkung: Hier wird (über die Fritzbox / PRESENCE - Device) mittels der Handys für 2 Personen die Anwesenheit festgestellt und SF bzw. der AI::FANN über das obige setupEnviroment dann (entweder - oder) als "true" mitgeteilt. Erweiterung auf 3/4/5.... möglich.
* Definierung der AI::FANN: Beispiel : -> muss nicht zutreffend sein -> auch ich habe lange getestet und ändere ab und an mal die Einstellung -> Ergänzung bei Einsatz der AI::FANN (nicht Ersatz für bestehende eintrage ohne AI::FANN)

'''Ergebnis:'''

Im folgenden Bild sieht man das Ergebnis:
[[Datei:Ergebnis AI-FANN Consumer-Forecast.png|ohne|mini|Ergebnis der AI-FANN Prognose]]

== Tips & Tricks ==
* Interruptable verhält sich völlig anders, wenn der Perlcode 1 oder 0 liefert, als wenn man 1 oder 0 in der Config hinterlegt. -> siehe commandref
* Rückgabewert bei swoncond und swoffcond wird mit dem Readingswert verglichen und nicht dirket verwendet. Bsp. wenn das Reading 100 enthält muss auch der Rückgabewert des Perlcodes 100 liefern, um true zu ergeben.

== weiterführende Links ==
* Forenthema "{{Link2Forum|Topic=137058|LinkText=76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support}}"
* Solcast API Toolkit: https://toolkit.solcast.com.au
* Kostal Plenticore 10 Plus mit SQL-Datenbank Integration ([[Kostal Plenticore 10 Plus]])
* Photovoltaik Ingenieurbüro Junge: https://www.ing-büro-junge.de/html/photovoltaik.html

[[Kategorie:Energieerzeugungsmessung]]

SetList

2025-11-21T13:43:29Z

Maista: Es waren falscher Devicenamen im userReadings (oil) angegeben

{{SEITENTITEL:setList}} 


Das Attribut [[setList]] dient dazu, bei generischen Devices die Liste der möglichen set Kommandos zu spezifizieren.

{{Todo|Bitte analog zu [[eventMap]] mit Inhalt füllen.}}

== Syntax ==
Das ''setList'' Attribut wird in der folgenden Weise spezifiziert:
:<code><nowiki>attr <device> setList <Reading1>:⟨<Modifier1>,⟩<Value1>,<Value2>,<...> <Reading2>:⟨<Modifier2>,⟩<Value1>,<Value2>,<...> ...</nowiki></code>
Es ist auch möglich, zur Verbesserung der Übersichtlichkeit und Lesbarkeit, das setList Attribut mehrzeilig zu formulieren.

== Einschränkungen ==
Dieses Attribut existiert nur bei [[DOIF]]-, [[dummy]]-, [[MSwitch]]- und [[readingsProxy]]-Devices.
[[MQTT2 DEVICE]] nutzt setList um Änderungen an State bzw. Readings an den Server zu übermitteln, der diese dann an die eigentlichen Geräte weitergibt oder dort vorhält. Für jedes Reading ist eine eigene Zeile erforderlich, das Aussehen in der Detailansicht des Geräts kann direkt über eine entsprechende widget-Definition vorgenommen werden.

== Beispiele ==

In diesem ersten Beispiel wird der ''state'' als Schiebebalken (slider) angezeigt. Wobei die erste Zahl den niedrigsten möglichen Wert angibt. Die zweite den Wert, um den jeweils erhöht wird. Und die dritte den maximal möglichen Wert.
define Raumtemperatur dummy
attr Raumtemperatur setList :slider,10,0.5,30

Wenn beim Einstellen per Slider auch Fließkommazahlen angezeigt werden sollen, kann man den optionalen Parameter ''isFloat'' auf 1 setzen. In diesem Beispiel wird die Kalibrierung der Temperaturanzeige eines Bodenfeuchtigkeitssensors zwischen -2° und +2° in 0,1°-Schritten definiert und soll auch in 0,1°-Schritten angezeigt werden. Hierzu dient das abschließende '',1'':
attr Feuchtigkeitssensor setList :slider,-2,0.1,2,1

Hier wird für den ''state'' eine Uhrzeit angegeben. Die kann mit zwei Schiebebalken (einer für die Stunden, einer für die Minuten) gesetzt werden.
define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList :time

Möchte man Farbwerte einstellen, kann man ''colorpicker'' verwenden. Damit kann dann auf einer Palette eine Farbe gewählt werden.
define Farbe dummy
attr Farbe setList :colorpicker

define Wecker_Uhrzeit dummy
attr Wecker_Uhrzeit setList state:AUS,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:35,06:40,06:45,06:50,06:55,07:00,07:05,07:10,07:15,07:20,07:25,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45
attr Wecker_Uhrzeit readingList state
attr Wecker_Uhrzeit webCmd state

define Beschattung_auto dummy
attr Beschattung_auto setList state:aktiv,passiv
attr Beschattung_auto readingList state
attr Beschattung_auto webCmd state

define Heizungsmodus dummy
attr Heizungsmodus setList state:auto,FHEM,Frostschutz,AUS
attr Heizungsmodus readingList state
attr Heizungsmodus webCmd state

define TV_ProgrammKanal dummy
attr TV_ProgrammKanal setList ARD_Ch ZDF_Ch HR_Ch RTL_Ch Sat1_Ch VOX_Ch Pro7_Ch Kabel1_Ch COMEDYCENTRAL_Ch DREISAT_Ch ARTE_Ch EINSPLUS_Ch EINSFESTIVAL_Ch ZDFNEO_Ch NDR_Ch MDR_Ch BR_Ch RBB_Ch SWR_Ch WDR_Ch RTL2_Ch SUPERRTL_Ch SPORT1_Ch EUROSPORT_Ch DMAX_Ch N24_Ch NTV_Ch RTLNITRO_Ch SAT1GOLD_Ch SIXX_Ch TELE5_Ch
attr TV_ProgrammKanal readingList state

define benzinpreis dummy
attr benzinpreis readingList SuperE5_2 SuperPlus_2
attr benzinpreis setList SuperE5_2:slider,140,1,200 SuperPlus_2:slider,140,1,200
attr benzinpreis stateFormat SuperE5, SuperPlus
attr benzinpreis userReadings SuperE5 {(ReadingsVal("benzinpreis","SuperE5_2",0) / 100 )}, SuperPlus {(ReadingsVal("benzinpreis","SuperPlus_2",0) / 100 )}
attr benzinpreis webCmd SuperE5_2:SuperPlus_2

== Links ==
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], [[devStateIcon]], setList und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}}

[[Kategorie:Attribut (allgemeingültig)]]

DOIF/uiTable Schnelleinstieg

2022-02-19T22:36:23Z

Maista: An der Klammer lang es nicht ?!

[[Datei:UiTable state screen.png|700px|rechts|Webansicht bestehend aus mehreren DOIF/uiTable-Definitionen]]
An dieser Stelle wird das DOIF-Web-Interface erklärt, welches über das DOIF-Attribut '''uiTable''' realisiert wurde.

Abhängig von der Art der Funktion können in einer tabellarischen Darstellung FHEM-Geräte visualisiert und über die Web-Oberfläche bedient werden. Eventbasierte Änderungen visualisierter Readings werden unmittelbar in der Web-Ansicht aktualisiert. Eine erstellte Tabelle erscheint unterhalb der Statuszeile eines DOIF-Devices. Das uiTable-Attribut kann in bereits bestehenden DOIFs oder in funktionslosen DOIFs, wie in den unteren Beispielen, als reines WEB-Interface erstellt werden. In der Abbildung rechts ist ein Statusbildschirm aus vier Spalten mit mehreren DOIF/uiTable-Definitionen aufgebaut worden. 

Die Darstellungsmöglichkeiten werden anhand von Beispielen insb. mit Hilfe bereits im DOIF-Modul vordefinierter uiTable-Funktionen aufgezeigt. Diese Perlfunktionen sind in einem eigenen Package namens 'ui_Table' definiert worden. Mit Hilfe dieser Funktionen lassen sich recht einfach, ohne tiefere HTML/CSS-Kenntnisse, eigene Übersichten definieren. Im Anschluss werden typische '''[[DOIF/uiTable Schnelleinstieg#Anwendungsbeispiele|Anwendungsbeispiele]]''' aufgezeigt.

Die folgenden Beispieldefinitionen arbeiten mit konkreten Geräten und Readings, sie können als RAW-Definition ins eigene System übernommen werden, dazu müssen die Gerätenamen, Readings, ggf. auch Icons den existierenden Namen des eigenen Systems angepasst werden. Zum Ausprobieren der Beispiele können statt echter Geräte auch Dummys benutzt werden.

Es gibt im Perl-Modus des DOIF-Moduls ebenfalls das Attribut '''uiState''', welches die gleiche Syntax wie uiTable nutzt. Die definierte Tabelle erscheint im Gegensatz zu uiTable jedoch im Status des DOIF-Devices. uiState und uiTable können gleichzeitig in einem DOIF-Device definiert werden.

== Aufbau des uiTable-Attributs ==
Im uiTable-Attribut wird in erster Linie die zu visualisierende Tabelle definiert. Optional können zuvor ein Perlblock sowie Templates definiert werden.
{{Randnotiz|RNText='''Aufbau des Attributs'''
* das uiTable-Attribut besteht aus drei Bereichen:
* [[DOIF/uiTable Schnelleinstieg#Der Perlblock|Perlblock]]
* [[DOIF/uiTable Schnelleinstieg#uiTable-Templates|Templates-Definitionen]]
* [[DOIF/uiTable Schnelleinstieg#Die Tabellendefinition|Tabellendefinition]]
}}
'''Aufbaustruktur'''
<syntaxhighlight lang="perl">
{
<Perlblock, optional>
}

<Templates-Definitionen, optional>

<Tabellendefinition>
</syntaxhighlight>
=== Der Perlblock ===
Der Perlblock dient dazu, das Layout der Tabelle zu beeinflussen sowie eigene uiTable-Funktionen zu definieren. Hier wird insb. das Package definiert, welches für die Tabellendefinition gilt. Ebenfalls können CSS-Variablen sowie Steuerungsattribute gesetzt werden. Der Perlblock beginnt und endet mit einer geschweiften Klammer.

==== CSS-Variablen und Steuerungsattribute ====
Mit Hilfe von CSS-Variablen kann das Layout der Tabelle beeinflusst werden. Die Steuerungsattribute beeinflussen die Statuszeile sowie die Detailansicht des DOIF-Moduls.
{{Randnotiz|RNText='''CSS-Variablen und Steuerungsattribute'''
*Das Layout der gesamten Tabelle wird beeinflusst über die Variablendefinition: '''$TABLE="<CSS-Attribute der Tabelle>"'''
*Spaltenformatierungen werden beeinflusst mit Hilfe der Variablendefinition: '''$TC{<Zellenbereich für Spalten>}="<CSS-Attribute der Spalten>"'''
*Zeilenformatierungen werden beeinflusst mit Hilfe der Variablendefinition: '''$TR{Zeilenbereich}="<CSS-Attribute der Zeilen>"'''
*einzelne Zellen werden beeinflusst mit Hilfe der Variablen: '''$TD{<Zellenbereich für Zeilen>}{<Zellenbereich für Spalten>}="<CSS-Attribute der Zellen>"'''
*für Zellen-, Spalten- und Zeilen-Bereich gilt: '''<Zahl><nowiki>|</nowiki><kommagetrennte Aufzählung><nowiki>|</nowiki><Bereich von..bis>'''
*Der Status in der Statuszeile des DOIFs wird ausgeblendet mit '''$SHOWNOSTATE=1'''
*Die Gerätezeile des DOIFs wird ausgeblendet mit '''$SHOWNODEVICELINE = "<regex room>"'''
*Die Tabelle des DOIFs wird ausgeblendet mit '''$SHOWNOUITABLE = "<regex room>"'''
*Die Detailansicht wird umorganisiert mit '''$ATTRIBUTESFIRST=1'''
}}
'''Bespieldefinition'''
<syntaxhighlight lang="perl">
defmod di_bsp_layout DOIF ##
attr di_bsp_layout uiTable { ## Beginn des Perlblocks\
## CSS-Variablen\
\
## Die Tabelle soll ein Hintergrundbild der Größe 300x300 Pixel haben\
$TABLE = "width:300px;; height:300px;; background-image:url(/fhem/www/pgm2/images/Grundriss.png);; background-size: 300px 300px;;";;\
\
## die Zelle der ersten Zeile und der ersten Spalte soll rechts eine Rahmenlinie haben\
$TD{0}{0} = "style='border-right-style:solid;; border-right-width:10px'";;\
\
## Die erste Zeile soll aus der Klasse 'odd' sein und fett-Schrift haben\
$TR{0} = "class='odd' style='font-weight:bold'";;\
\
## die Spalten 2 bis 6 sollen zentriert sein\
$TC{1..5} = "align='center'";;\
\
## die Spalten 2, 4 und 5 sollen zentriert sein\
$TC{1,3,5} = "align='center'";;\
\
## die letzte Spalte der Tabelle soll fett sein\
$TC{last} = "style='font-weight:bold'";;\
\
\## Steuerungsattribute\
\
\## Ausblenden des Status in der Statuszeile\
$SHOWNOSTATE=1;;\
\
## Die Gerätezeile wird ausgeblendet in allen Räumen\
$SHOWNODEVICELINE = ".*";;\
\
## Die Tabelle wird im Raum info ausgeblendet\
$SHOWNOUITABLE = "^info$";;\
\
## Die Detailansicht wird umorganisiert, hilfreich beim Editieren längerer uiTable-Definitionen\
$ATTRIBUTESFIRST = 1;;\
} ## Ende des Perlblocks
</syntaxhighlight>

=== Die Tabellendefinition ===
==== Einfache Tabellendefinition ohne Funktionen ====
{{Randnotiz|RNText='''Tabellendefinition'''
* eine Tabelle wird aus Zellen zusammengebaut
* mehrere Zellen werden mit <nowiki>|</nowiki> von einander getrennt, sie bilden eine Tabellenzeile
* eine neue Tabellenzeile beginnt mit einer neuen Zeile in der Tabellendefinition
* eine Tabellenzeile kann auch in mehreren Zeilen definiert werden, diese müssen dann mit <nowiki>|</nowiki> enden
* Texte werden in Anführungszeichen angegeben
* Readings werden in der Form [<device>:<reading>] angegeben
* Kommentare beginnen mit ## und enden mit Zeilenende
* Events eines definierten Readings, führen sofort zu Aktualisierung seines Inhalts in der visualisierten Tabelle
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_definition DOIF ##
attr ui_Table_definition uiTable { ## Perlblock für globale Tabellendefinitionen\
\
$TC{1..2}="align='center'" ## zentrierte Ausrichtung der zweiten und dritten Spalte\
\
}\
\
## Tabellendefinition\
\
"Warmwasser"|"Vorlauf"|"Rücklauf" ## erste Tabellenzeile\
## zweite Tabellenzeile\
[T_Warmwasserspeicher:temperature]| ## Zeile wird fortgesetzt, da sie mit | endet\
[T_Vorlauf:temperature]| ## Zeile wird fortgesetzt, da sie mit | endet\
[T_Ruecklauf:temperature]
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable Definition.png|mini|ohne]]

==== Tabellendefinition mit Berechnungen ====
{{Randnotiz|RNText='''Zellenauswertung'''
* jede Zelle der Tabelle wird über Perl ausgewertet
* Readingangaben der Form [<device>:<reading>] werden in eine Perlfunktion übersetzt
* das Ergebnis des ausgewerteten Perlausdrucks wird ausgegeben
* in einer Zelle können beliebige Perlfunktionen genutzt werden
* Texte oder Funktionen können mit Punkt aneinander gehängt werden
* mit Komma werden Texte oder Werte untereinander dargestellt
* wird eine Zeile mit < abgeschlossen, so wird die aktuelle Tabelle abgeschlossen, die nächste Zeile beginnt in einer neuen Tabelle
* in einer Berechnung sollte ein Trigger in Form einer Readingangabe [<device>:<reading>] vorkommen, sonst wäre das Ergebnis statisch und würde sich nicht ändern
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_calc DOIF ##
attr di_uiTable_calc uiTable ## Tabellendefinition\
"Differenz"|[T_Ruecklauf:temperature]-[T_Vorlauf:temperature]\
"Minimum"|minNum([TH_WZ_HM:measured-temp],[TH_Keller_HM:measured-temp])\
"Durchschnitt"|([T_Ruecklauf:temperature]+[T_Vorlauf:temperature])/2
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable calc.png|mini|ohne]]

== Vordefinierte uiTable-Funktionen ==
Typische Widgets bzw. Styles wurden als Perl-Funktionen im package ui_Table für eine einfache Tabellendefinition programmiert. Im folgenden wird näher auf die einzelnen uiTable-Funktionen eingegangen.

=== FHEM-Widgets mit der Funktion '''widget''' ===
Alle in FHEM vorhanden Widgets können mit Hilfe der Perlfunktion '''widget''' genutzt werden. Bei häufiger Nutzung eines bestimmten Widgets bietet sich alternativ die Definition einer uiTable-Funktion (Typ 3) mit dem jeweiligen Widget an, siehe: [[DOIF/uiTable Schnelleinstieg#Eigene uiTable-Funktionen programmieren|uiTable-Funktion]]
{{Randnotiz|RNText=Funktion '''widget'''
<syntaxhighlight lang="perl">
widget(<Reading>,$fhem_widget,$set)

Reading # [<device>:<reading>]
$fhem_widget # Angabe des FHEM-Widgets
$set # optional, undef zum Setzen beliebiger Readings (entspricht setreading), "set" wenn das Reading per set-Befehl gesetzt wird (siehe Attribut ReadingList), "set <Befehl>", wenn sich der Befehl vom Reading unterscheidet, default undef
</syntaxhighlight>

'''nützliche Links'''
* [[FHEMWEB/Widgets|Fhem-Widgets]]
* Fhem-Widgets als [[DOIF/uiTable Schnelleinstieg#Eigene uiTable-Funktionen programmieren|uiTable-Funktion]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_widget DOIF ##
attr di_uiTable_widget uiTable ## FHEM-Widgets mit Hilfe der WID-Funktion\
{package ui_Table}\
"Widget"\
"Select"| widget([uhr:wochentag],"select,Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag")\
"Selectnumbers"| widget([motor:spannung],"selectnumbers,0,0.5,12,1,lin")\
"Slider"| widget([bla:wert],"slider,0,5,100,1")\
"Colorpicker RGB"| widget([Lampe:farbe],"colorpicker,RGB")\
"Colorpicker HSV"| widget([Lampe:farbe],"colorpicker,HSV")\
"Colorpicker CT"| widget([Lampe:waerme],"colorpicker,CT,2000,10,6500")\
"Colorpicker HUE"| widget([Lampe:farbe],"colorpicker,HUE,0,1,359")\
"Colorpicker BRI"| widget([Lampe:helligkeit],"colorpicker,BRI,0,1,100")\
"Time"| widget([start:zeit],"time")\
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable WID.png|mini|ohne]]

=== SVG-uiTable-Funktionen ===
SVG-uiTable-Funktionen sind skalierbare Widgets, die auf SVG-Elementen basieren. Bei allen SVG-Funktionen für Temperatur bzw. Feuchtigkeit wird die Einfärbung abhängig vom Temperatur- bzw. Feuchtigkeitswert mit Hilfe einer Zuordnungsfunktion bestimmt.

==== '''ring'''-Funktionen ====
===== Farbskalierte Temperaturanzeige mit Hilfe der SVG-Funktionen '''temp_ring/temp_mring''' =====
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''temp_mring'''-SVG-Funktion wird der Ring einfarbig dargestellt.

Farbskalierung der '''temp_ring'''-SVG-Funktion:
[[Datei:Farbskalierung temp_ring_scaling.png|600px|ohne]]

Farbskalierung der '''temp_mring'''-SVG-Funktion:
[[Datei:Farbskalierung temp_mring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_ring/temp_mring'''
<syntaxhighlight lang="perl">
temp_ring/temp_mring ($temp_value,$temp_min,$temp_max,$sizeHalf, $lightring,$lightnumber,$decFont)

$temp_value # Temperatur
$temp_min, # minimale Temperatur, optional, default=-20
$temp_max, # maximale Temperatur, optional, default=60
$sizeHalf # "<size>,<half ring>" size: Größe der Grafik, optional, default = 80, half ring: 1 für Halbring
$lightring, # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_ring DOIF ##
attr di_temp_ring uiTable {package ui_Table}\
"außen (standard)"|temp_ring([Aussensensor:temperature])\
"Warmwasser (größer,aufgehellt,Normalschrift)" |temp_mring([vaillant:WWSpeicher],15,70,110,90,100,"1,font-weight:normal")\
"Vorlauf (größer)"| temp_mring([ESPEasy_ESP_Temp_Vorlauf:Temperature],15,45,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_ring_bsp.png|ohne|mini]]

===== Farbskalierte Feuchtigkeitsanzeige mit Hilfe der SVG-Funktionen '''hum_ring/hum_mring''' =====
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''hum_mring'''-SVG-Funktion wird der Ring einfarbig dargestellt.

Farbskalierung der '''hum_ring'''-SVG-Funktion:
[[Datei:Farbskalierung hum_ring_scaling.png|600px|ohne]]

Farbskalierung der '''hum_mring'''-SVG-Funktion:
[[Datei:Farbskalierung hum_mring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''hum_ring/hum_mring'''
<syntaxhighlight lang="perl">
hum_ring/hum_mring ($hum_value,$sizeHalf,$lightring,$lightnumber,$decFont)
$hum_value # Feuchtigkeit
$sizeHalf # "<size>,<half ring>" size: Größe der Grafik, optional, default = 80, half ring: 1 für Halbring
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_hum_ring DOIF ##
attr di_hum_ring room test2
attr di_hum_ring uiTable {package ui_Table}\
"klein ohne Farbverlauf"|hum_mring([Aussensensor:humidity],60)\
"normal groß mit Farbverlauf"|hum_ring([Aussensensor:humidity])\
"groß ohne Farbverlauf aufgehellt"|hum_mring([Aussensensor:humidity],100,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:hum_ring_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Zahlenwertes mit Hilfe der universellen SVG-Funktion '''ring''' =====
Die Farbe des dargestellten Wertes kann abhängig vom Wert bestimmt werden. Dabei wird die Farbe mit Anleihen aus dem [https://de.wikipedia.org/wiki/HSV-Farbraum HSV-Farbraum] bestimmt. Dieser Farbraum benötigt eigentlich drei Werte, wobei die erste den Farbton (hue) bestimmt; hier wird nur dieser Wert verwendet (Sättigung und Hellwert sind nicht einstellbar). Der Farbton geht von rot (hue-Wert = 0) über gelb (hue-Wert = 60), dann grün (hue-Wert = 120) und blau (hue-Wert = 240) zurück zu rot (hue-Wert = 360), siehe dazu auch die [https://de.wikipedia.org/wiki/HSV-Farbraum#/media/Datei:HueScale.svg Farbtontafel] auf der Wikipedia-Seite.
Die unten $colorRef genannte Funktion kann zum Beispiel in der Tabelle selbst definiert werden, beispielsweise kann man in dem device &onoff_hue verwenden, wenn man es vorab definiert (siehe [https://forum.fhem.de/index.php/topic,120088.msg1204341.html#msg1204341 Link zum Forum]):<blockquote><syntaxhighlight lang="perl">
attr <ui device Name> {
package ui_Table;
sub onoff_hue {
my($irgendeinVariablenname)=@_;
return ($irgendeinVariablenname == 0 ? 240 : 0);
}
## Tabellendefinition
...
}
</syntaxhighlight></blockquote>{{Randnotiz|RNText=SVG-uiTable-Funktion '''ring'''
<syntaxhighlight lang="perl">
ring ($value,$min,$max,$minColor,$maxColor,$unit, $sizeHalf,$colorRef,$decFont,$model,$lightness)

$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$sizeHalf # "<size>,<half ring>" size: Größe der Grafik, optional, default = 100, half ring: 1 für Halbring
$colorRef # Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$model # '<Farbverlauf>,<Min/Max>,<Innenring>,<Zeigerstärke>,<Modus>',
# Farbverlauf: 1 für monochrom,
# Min/Max: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte,
# Innenring: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes, Zeigerstärke: in Pixel,
# Zeigerstärke: Breite des Zeigers,
# Modus: 0 Standard Min-Max, 1 Min-Null-Max, 2 Null-Min/Max,
# alle Parameter sind optional, default keine Angaben: ',,,,,'
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>", optional, default: "50,50,50,40,50"
</syntaxhighlight>
Wird '''$colorFunc''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_ring DOIF (1)
attr di_ring room test20,test5
attr di_ring uiTable {package ui_Table;; \
$SHOWNOSTATE=1}\
## von 0 bis 20 in Farben von grün (hue:120) bis rot (hue:0)\
"Umlaufmenge"|ring([heating:pump],0,20,120,0,"l/min",100)\
\
## von 0 bis 3 in Farben von rot (hue:0) bis türkis (hue:180), eine Nachkommastelle, Schriftgröße 170%\
## Innenring mit Min-, Max-Beschriftung\
"Wasserdruck"|ring([heating:pressure],0,3,0,180,"bar",100,undef,"1,font-size:170%,fill:silver;;font-size:50%","0,1,1")\
\
## Temperaturdarstellung, entspricht dem Funktionsaufruf:\
## temp_ring ([outdoor:temperature],-20,60,100,"1,font-weight:normal;;font-size:140%")\
## Eine Nachkommastelle, Normalschrift, Schriftgröße 140%\
"Temperatur"|ring([outdoor:temperature,-20,60,undef,undef,"°C",100,\&temp_hue,"1,font-weight:normal;;font-size:140%")\
\
## Lufdruck als Halbring\
"Luftdruck"|ring([weather:barometer],970,1045,30,90,"hPa","100,1",undef,0)\
\
## Co2 als Halbring, Farbgebung als Array mit drei Bereichen, Innenring mit Zeiger\
"Co2"|ring([livingroom:co2],400,1200,undef,undef,'ppm',"100,1",[(600,120,1000,60,1200,0)],0,'0,0,1,5')
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:ring_bsp.png|ohne|mini]]

===== Farbskalierte Temperatur- und Feuchtigkeitsanzeige mit Hilfe der SVG-Funktion '''temp_hum_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperatur- bzw. Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar:
[[Datei:Farbskalierung temp_hum_ring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_hum_ring'''
<syntaxhighlight lang="perl">
temp_hum_ring ($temp_value,$hum_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp,$decFontHum)

$temp_value # Temperatur
$hum_value # Feuchtigkeit
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp # Temperatur: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontHum # Feuchtigkeit: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_hum_ring DOIF ##
attr di_temp_hum_ring uiTable {package ui_Table}\
\
"klein"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity],undef,undef,60)\
"normal"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity])\
"größer, aufgehellt"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity],undef,undef,100,undef,80)\
"größer, Ring aufgehellt, Normalschrift"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity],undef,undef,100,80,50,"1,font-weight:normal","0,font-weight:normal")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_hum_ring_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Temperaturwerten mit Hilfe der SVG-Funktion '''temp_temp_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar:
[[Datei:Farbskalierung temp_temp_ring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_temp_ring'''
<syntaxhighlight lang="perl">
temp_temp_ring ($temp1_value,$temp2_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp1,$decFontTemp2)

$temp1_value # erster Temperaturwert
$temp2_value # zweiter Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp1 # Temperatur1: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontTemp2 # Temperatur2: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_temp_ring DOIF ##
attr di_temp_temp_ring uiTable {package ui_Table}\
"klein, Ring augehellt"|temp_temp_ring([Vorlauf:Temperature],[Ruecklauf:Temperature],15,60,60,80,50)\
"normal"|temp_temp_ring([Vorlauf:Temperature],[Ruecklauf:Temperature],15,60)\
"groß, Zahlen aufgehellt"|temp_temp_ring([Vorlauf:Temperature],[Ruecklauf:Temperature],15,60,100,undef,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_hum_temp_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Zahlenwerten mit Hilfe der universellen SVG-Funktion '''ring2''' =====
Die Farbe der dargestellten Werte kann abhängig vom Wert bestimmt werden.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''ring2'''
<syntaxhighlight lang="perl">
ring2 ($value1,$min1,$max1,$minColor1,$maxColor1,$unit1,$size,$colorFunc1,$decFont1,
$value2,$min2,$max2,$minColor2,$maxColor2,$unit2,$colorFunc2,$decFont2,
$lightness,$icon,$model)

$value1 # darzustellender Wert1
$min1 # minimaler Wert, optional, default=0
$max1 # maximaler Wert, optional, default=100
$minColor1 # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor1 # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit1 # Einheit des Wertes, optional, default = undef
$size # Größe der Grafik, optional, default = 100
$colorFunc1 # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont1 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$value2 # darzustellender Wert2
...
$decFont2 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"
$model # '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>',
# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'

Argumente für den zweiten Wert entsprechend den Argumenten des ersten Wertes
</syntaxhighlight>
Wird '''$colorFunc...''' nicht angegeben, so wird der Farbwert zwischen '''$minColor...''' und '''$maxColor...''' linear interpoliert
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_ring2 DOIF ##
attr di_ring2 uiTable {package ui_Table;;}\
## Leistungsaufnahme von 0 kW bis 3,6 kW in Farben von grün (hue:120) bis rot (hue:0)\
## Kapazität von 0 % bis 100 % V in Farben von rot (hue:0) bis grün (hue:120)\
"Wallbox"| ring2([tesla:Leistung],0,3.6,120,0,"kW",undef,undef,"1,font-weight:normal",[tesla:Kapazitaet],0,100,0,120,"%",undef,"0,font-weight:normal")\
\
## Stromstärke von 0 A bis 2 A in Farben von grün (hue:120) bis rot (hue:0)\
## Spannung von 1 V bis 1.5 V in Farben von rot (hue:0) bis grün (hue:120)\
## 3 Nachkommastellen, Normalschrift, Schriftgröße 80% \
"Akku"| ring2([akku:Strom],0,2,120,0,"A",undef,undef,"3,font-weight:normal;;font-size:80%",[akku:Spannung],1,1.5,0,120,"V",undef,"3,font-weight:normal;;font-size:80%")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:ring2_bsp.png|ohne|mini]]

'''<big>Beispieldefinition Innenring, Farb-Array, Ringmodi</big>'''
<syntaxhighlight lang="perl">
defmod di_solar DOIF {}
attr di_solar uiTable {package ui_Table}\
"Farb-Array, ringMode 1"|\
ring2([zaehler:Produktion],-20,30,undef,undef,"PV kWh",130,[(-10,0,-0.001,30,10,60,30,90)],"2",[test:Bezug],-20,30,undef,undef,"Bezug",[(-10,0,-0.001,30,10,60,30,90)],"2",undef,undef,"0,1,1,0,1")\
"Farbe linear, ringMode 1"|\
ring2([zeahler:Produktion],-20,30,0,120,"PV kWh",130,undef,"2",[test:Bezug],-20,30,0,120,"Bezug",undef,"2",undef,undef,"0,1,1,0,1")\
"Farbe linear, ringMode 2"|\
ring2([zaehler:Produktion],0,30,60,120,"PV kWh",130,undef,"2",[test:Bezug],-20,0,0,120,"Bezug",undef,"2",undef,undef,"0,,,0,2")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:ring2_ringMode.png|ohne|mini]]

 

==== '''icon_ring'''-Funktionen ====
===== Farbskalierte Temperaturanzeige mit einem Icon mit Hilfe der SVG-Funktionen '''icon_temp_ring/icon_temp_mring''' =====
Diese Funktionen basieren auf den obigen temp_ring-Funktionen, zusätzlich wird ein SVG-Icon dargestellt. Die Farbe des Icons kann mit @ an den Iconnamen angehängt werden, ansonsten wird die Farbe der Temperatur für das Icon verwendet. Die Größe des Icons kann skaliert werden, ebenso kann die Positionen des Icons verschoben werden.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_ring/icon_temp_mring'''
<syntaxhighlight lang="perl">
icon_temp_ring/icon_temp_mring ($icon,$temp_value,$temp_min,$temp_max,$size,$lightring,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation (0-360) sind optional
$temp_value # Temperatur
$temp_min, # minimale Temperatur, optional, default=-20
$temp_max, # maximale Temperatur, optional, default=60
$size, # Größe der Grafik, optional, default=80
$lightring, # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_Heizung_temp DOIF ##
attr di_Heizung_temp uiTable {\
package ui_Table;;\
}\
\
icon_temp_ring("temp_outside",[vaillant:Aussentemp],-15,40)|\
icon_temp_mring(([vaillant:Flame] eq "off"?"sani_boiler_temp\@white":"sani_boiler_temp\@Darkorange"),[vaillant:Vorlauf],15,70)|\
icon_temp_mring(([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),[vaillant:WWSpeicher],15,70)|\
icon_temp_mring(([Zirk] eq "off"?"sani_pump\@white":"sani_pump\@Darkorange"),[ESPEasy_ESP_Temp_Zirkulation:Temperature],15,70)|\
icon_temp_mring(([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),[ESPEasy_ESP_Temp_Vorlauf:Temperature],15,70)|\
icon_temp_mring("sani_floor_heating_neutral\@white",[ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature],15,70)|""

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_ring_bsp.png|ohne|mini]]

===== Farbskalierte Feuchtigkeitsanzeige mit einem Icon mit Hilfe der SVG-Funktionen '''icon_hum_ring/icon_hum_mring''' =====
Diese Funktionen basieren auf den obigen hum_ring-Funktionen, zusätzlich wird ein SVG-Icon dargestellt. Die Farbe des Icons kann mit @ an den Iconnamen angehängt werden, ansonsten wird die Farbe der Feuchtigkeit für das Icon verwendet. Die Größe des Icons kann skaliert werden, ebenso kann die Positionen des Icons verschoben werden.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_hum_ring/icon_hum_mring'''
<syntaxhighlight lang="perl">
icon_hum_ring/icon_hum_mring ($icon,$hum_value,$size,$lightring,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$hum_value # Feuchtigkeit
$size # Größe der Grafik, optional, default=80
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_hum_ring DOIF ##
attr di_icon_hum_ring room test5
attr di_icon_hum_ring uiTable {package ui_Table}\
"klein ohne Farbverlauf"|icon_hum_mring("weather_humidity",[Aussensensor:humidity],60)\
"normal groß mit Farbverlauf"|icon_hum_ring("weather_humidity",[Aussensensor:humidity])\
"groß ohne Farbverlauf aufgehellt"|icon_hum_mring("weather_humidity",[Aussensensor:humidity],100,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_hum_ring_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Icons mit einem Zahlenwert mit Hilfe der universellen SVG-Funktion '''icon_ring/icon_mring/icon_uring''' =====
Diese Funktionen basieren auf der universellen ring-Funktion. Die Farbe des dargestellten Icons und des Wertes kann abhängig vom Wert bestimmt werden. Die Funktion '''icon_ring''' stellt den Farbring mit Farbverlauf dar, die Funktion '''icon_mring''' stellt den Farbring einfarbig dar. Die universelle Funktion '''icon_uring''' kann über den Parameter '''$model''' das Erscheinungsbild der Grafik verändern.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_ring/icon_mring/icon_uring'''
<syntaxhighlight lang="perl">
icon_ring ($icon,$value,$min,$max,$minColor,$maxColor, $unit,$decFont,$size,$colorRef,$lightness,$model)

icon_mring ($icon,$value,$min,$max,$minColor,$maxColor, $unit,$decFont,$size,$colorRef,$lightness)

icon_uring ($model,$icon,$value,$min,$max,$minColor,$maxColor, $unit,$decFont,$size,$colorRef,$lightness)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Style-SVG-Attribute Wert>,<Style-SVG-Attribute Einheit>", optional
$size # Größe der Grafik, optional, default = 100
$colorRef # Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"
$model # '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>',
# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'
</syntaxhighlight>
Wird '''$colorRef''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_ring DOIF ##
attr di_icon_ring uiTable {package ui_Table}\
\
icon_ring ('sani_floor_heating_neutral',[Heizenergie:Vortag_hc],0,150,120,0,'kWh')|\
icon_mring ('fuel',[Tankstelle:Diesel],1.10,1.30,120,0,'€',2)|\
icon_uring ('0,1,1',"air",[ESPEasy_Eingang_CO2:PPM],400,1200,undef,undef,'ppm',0,100,[(600,120,1000,60,1200,0)])|\
icon_uring ('0,1','Zisterne',([Wasserzisterne]/3.4),0,100,0,120,'%',0)##/\
\
icon_uring ('1,1,0,8',"measure_water_meter",[Wasserverbrauch:heute],0,600,120,0,'l',0)|\
icon_uring ('0,fill:white,opacity:0.4',([vaillant:Pumpenstatus] eq '4' ? 'sani_buffer_temp_down@Darkorange' : 'sani_buffer_temp_down@white'),[vaillant:Umlaufmenge],0,20,120,0,'l/min')|\
icon_uring('0,1,1,4','weather_barometric_pressure',[vaillant:Wasserdruck],0,3,undef,undef,'bar',1,100,[(0.8,0,1,60,1.5,120,1.7,60,3,0)])|\
icon_uring('0,opacity:0.8,1,6','sani_water_tap',[vaillant:HwcHours_hoursum2_value],0,2000,120,0,'h',0)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_ring_bsp.png|ohne|mini]]
 

===== Farbskalierte Temperatur- und Feuchtigkeitsanzeige mit einem Icon mit Hilfe der SVG-Funktion '''icon_temp_hum_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperatur- bzw. Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar:

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_hum_ring'''
<syntaxhighlight lang="perl">
icon_temp_hum_ring ($icon,$temp_value,$hum_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp,$decFontHum)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$temp_value # Temperatur
$hum_value # Feuchtigkeit
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp # Temperatur: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontHum # Feuchtigkeit: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_temp_hum_ring DOIF ##
attr di_icon_temp_hum_ring uiTable {package ui_Table}\
\
"normal"|icon_temp_hum_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:humidity])\
"mit Normalschrift"|icon_temp_hum_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:humidity], undef,undef,undef,undef,undef,"1,font-weight:normal","0,font-weight:normal")\
"größer aufgehellt"|icon_temp_hum_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:humidity], undef,undef,120,undef,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_hum_ring.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Temperaturwerten mit einem Icon mit Hilfe der SVG-Funktion '''icon_temp_temp_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar:

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_temp_ring'''
<syntaxhighlight lang="perl">
icon_temp_temp_ring ($icon,$temp1_value,$temp2_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp1,$decFontTemp2)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$temp1_value # erster Temperaturwert
$temp2_value # zweiter Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp1 # Temperatur1: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontTemp2 # Temperatur2: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_temp_temp_ring DOIF ##
attr di_icon_temp_temp_ring uiTable {package ui_Table}\
## Größe 120%\
"FB-Heizung"|icon_temp_temp_ring(([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),[ESPEasy_ESP_Temp_Vorlauf:Temperature],[ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature],15,70,120)\
\
## Größe 120%, Normalschrift\
"Temperatur","Taupunkt"|icon_temp_temp_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:dewpoint],undef,undef,120,undef,undef,"1,font-weight:normal","1,font-weight:normal")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_temp_ring.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Zahlenwerten mit einem Icon mit Hilfe der universellen SVG-Funktion '''icon_ring2''' =====
Die Farbe der dargestellten Werte kann abhängig vom Wert bestimmt werden.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_ring2'''
<syntaxhighlight lang="perl">
icon_ring2 ($icon,$value1,$min1,$max1,$minColor1,$maxColor1,$unit1,$size,$colorFunc1,$decFont1, $value2,$min2,$max2,$minColor2,$maxColor2,$unit2,$colorFunc2,$decFont2,$lightnesss,$model)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$value1 # darzustellender Wert1
$min1 # minimaler Wert, optional, default=0
$max1 # maximaler Wert, optional, default=100
$minColor1 # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor1 # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit1 # Einheit des Wertes, optional, default = undef
$size # Größe der Grafik, optional, default = 100
$colorFunc1 # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont1 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$value2 ## darzustellender Wert2
...
$unit2 # Einheit des Wertes, optional, default = undef
$colorFunc2 # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont2 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"
$model # '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>',
# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'

Argumente für den zweiten Wert entsprechend den Argumenten des ersten Wertes
</syntaxhighlight>
Wird '''$colorFunc...''' nicht angegeben, so wird der Farbwert zwischen '''$minColor...''' und '''$maxColor...''' linear interpoliert.

Bei der Farbangabe des Icons beim Übergabeparameter $icon wird mit '''\@colorVal2''' das Icon mit der Farbe des zweiten Wertes eingefärbt. Bei keiner Farbangabe oder '''\@colorVal1''' wird das Icon mit der Farbe des ersten Wertes eingefärbt. Ansonsten gilt die allgemeine FHEM-Syntax für Farbgebung von Icons angehängt mit '''\@'''.
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_ring2 DOIF ##
attr di_icon_ring2 uiTable {package ui_Table;;\
\
sub himmelsrichtung {\
my ($richtung)=@_;;\
my $element=int($richtung/22.5);;\##/
my @h=(qw"N NNO NO ONO O OSO SO SSO S SSW SW WSW W WNW NW NNW");;\
return($h[$element]);;\
}\
}\
"Wallbox"| icon_ring2("car,1.5,0,-3",[tesla:Leistung],0,3.6,120,0,"kW",120,undef,"1,font-weight:normal",[tesla:Kapazitaet],0,100,0,120,"%",undef,"0,font-weight:normal")\
\
"Wind"|icon_ring2(([Wind:Geschwindigkeit]>0 ? "wind":"no_wind").",1,0,0,".[Wind:Richtung],[Wind:Geschwindigkeit],0,50,120,0,"km/h",120,undef,1,[Wind:Richtung],361,361,220,220,([Wind:Geschwindigkeit]>0?himmelsrichtung([Wind:Richtung]):"--"),undef,0)\
\
"Strom"|icon_ring2([zaehler:l-Produktion] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",[zaehler:l-Produktion],0,3.6,20,120,"PV kW",150,undef,"1,,font-size:50%;fill:white",[zaehler:l-Bezug,0],0,2,120,0,"Netz kW",undef,"1,,font-size:50%;fill:white")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_ring2.png|ohne|mini]]

==== '''bar'''-Funktionen ====
===== Farbskalierte Anzeige der Temperatur in Balkenform mit Hilfe der SVG-Funktionen '''temp_bar/temp_mbar''' =====
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''temp_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

Farbskalierung der '''temp_bar'''-SVG-Funktion:
[[Datei:Farbskalierung temp_bar_scaling.png|600px|ohne]]

Farbskalierung der '''temp_mbar'''-SVG-Funktion:
[[Datei:Farbskalierung temp_mbar_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_bar/temp_mbar'''
<syntaxhighlight lang="perl">
temp_bar/temp_mbar ($temp_value,$temp_min,$temp_max, $header,$width,$height,$size, $light,$lightnumber,$decFont)

$temp_value # Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$header # Überschrift, optional, default= undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=60
$size # Größe der Grafik, optional, default=100
$light # Helligkeit der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_bar DOIF ##
attr di_temp_bar uiTable {package ui_Table}\
"standard"|temp_bar([Aussensensor:temperature])\
"heller"|temp_bar([Aussensensor:temperature],undef,undef,undef,undef,undef,undef,80)\
"monochrom"|temp_mbar([Aussensensor:temperature])\
"kleiner"|temp_bar([Aussensensor:temperature],undef,undef,undef,undef,undef,80)\
"mit Überschrift"|temp_bar([Aussensensor:temperature],undef,undef,"Außen")\
"hoch"|temp_bar([Aussensensor:temperature],undef,undef,undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige der Feuchtigkeit in Balkenform mit Hilfe der SVG-Funktionen '''hum_bar/hum_mbar''' =====
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''hum_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

Farbskalierung der '''hum_bar'''-SVG-Funktion:
[[Datei:Farbskalierung hum_bar_scaling.png|600px|ohne]]

Farbskalierung der '''hum_mbar'''-SVG-Funktion:
[[Datei:Farbskalierung hum_mbar_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''hum_bar/hum_mbar'''
<syntaxhighlight lang="perl">
hum_bar/hum_mbar ($hum_value,$header,$width,$height,$size, $light,$lightnumber,$decFont)

$hum_value # Feuchtigkeitswert
$header # Überschrift, optional, default = undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=80
$size # Größe der Grafik, optional, default=100
$light # Helligkeit des der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 0
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_hum_bar DOIF ##
attr di_hum_bar uiTable {package ui_Table}\
"standard"|hum_bar([Aussensensor:humidity])\
"heller"|hum_bar([Aussensensor:humidity],undef,undef,undef,undef,80)\
"monochrom"|hum_mbar([Aussensensor:humidity])\
"kleiner"|hum_bar([Aussensensor:humidity],undef,undef,undef,80)\
"mit Überschrift"|hum_bar([Aussensensor:humidity],"Außen")\
"hoch"|hum_bar([Aussensensor:humidity],undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:hum_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Zahlenwertes mit Hilfe der universellen SVG-Funktion '''bar''' =====
Die Farbe des dargestellten Wertes kann abhängig vom Wert bestimmt werden.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''bar'''
<syntaxhighlight lang="perl">
bar ($value,$min,$max,$header,$minColor,$maxColor,$unit,$width, $height,$size,$colorFunc,$decFont,$gradient,$light,$lightnumber)

$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$header # Überschrift, optional, default = undef (keine)
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$width # Breite der Grafik, optional, default = 63
$height # Höhe der Grafik, optional, default = 60
$size # Größe der Grafik, optional, default = 100
$colorFunc # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
$gradient # Farbverlauf, optional, undef mit Farbverlauf, 1 ohne Farbverlauf, default = undef
$light # Helligkeit der Grafik (light:0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (light:0-100), optional, default=50
</syntaxhighlight>
Wird '''$colorFunc''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
{package ui_Table}
defmod di_bar DOIF ##
attr di_bar uiTable {package ui_Table}\
## von 0 bis 20 in Farben von grün (hue:120) bis rot (hue:0)\
"Umlaufmenge"|bar([heizung:Umlaufmenge],0,20,"Umlauf",120,0,"l/min")\
\
## von 0 bis 3 in Farben von rot (hue:0) bis türkis (hue:180)\
"Wasserdruck"|bar([heizung:Wasserdruck],0,3,undef,0,180,"bar"undef,70,undef,undef,"1,font-size:130%;;font-weight:normal")\
\
## Temperaturdarstellung, entspricht dem Funktionsaufruf:\
## temp_bar ([Aussensensor:temperature],-20,60)\
"Temperatur"|bar([Aussensensor:temperature],-20,60,undef,undef,undef,"°C",undef,undef,undef,\&temp_hue)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:bar_bsp.png|ohne|mini]]

==== '''icon_bar'''-Funktionen ====
===== Farbskalierte Anzeige der Temperatur in Balkenform mit Hilfe der SVG-Funktion '''icon_temp_bar/icon_temp_mbar''' =====
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''icon_temp_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_bar/icon_temp_mbar'''
<syntaxhighlight lang="perl">
icon_temp_bar/icon_temp_mbar ($icon,$temp_value,$temp_min,$temp_max, $header,$width,$height,$size,$light,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position", \@Farbe, Skalierungsfaktor, x-Position, y-Position sind optional
$temp_value # Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$header # Überschrift, optional, default= undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=75
$size # Größe der Grafik, optional, default=100
$light # Helligkeit der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_temp_bar DOIF ##
attr di_icon_temp_bar room test10
attr di_icon_temp_bar uiTable {package ui_Table}\
"standard"|icon_temp_bar("temp_outside",[Aussensensor:temperature])\
"heller"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,undef,undef,undef,undef,80)\
"monochrom"|icon_temp_mbar("temp_outside",[Aussensensor:temperature])\
"kleiner"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,undef,undef,undef,80)\
"mit Überschrift"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,"Außen")\
"hoch"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige der Feuchtigkeit in Balkenform mit Hilfe der SVG-Funktionen '''icon_hum_bar/icon_hum_mbar''' =====
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''icon_hum_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_hum_bar/icon_hum_mbar'''
<syntaxhighlight lang="perl">
icon_hum_bar/icon_hum_mbar ($icon,$hum_value,$header,$width,$height,$size, $light,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position", \@Farbe, Skalierungsfaktor, x-Position, y-Position sind optional
$hum_value # Temperaturwert
$header # Überschrift, optional, default = undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=75
$size # Größe der Grafik, optional, default=100
$light # Helligkeit des der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_hum_bar DOIF ##
attr di_icon_hum_bar uiTable {package ui_Table}\
"standard"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity])\
"heller"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],undef,undef,undef,undef,80)\
"monochrom"|icon_hum_mbar("temperature_humidity",[Aussensensor:humidity])\
"kleiner"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],undef,undef,undef,80)\
"mit Überschrift"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],"Außen")\
"hoch"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_hum_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Zahlenwertes mit Hilfe der universellen SVG-Funktionen '''icon_bar/icon_mbar''' =====
Die Farbe des dargestellten Wertes und des Icons kann abhängig vom Wert bestimmt werden. Bei der '''icon_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_bar/icon_mbar'''
<syntaxhighlight lang="perl">
icon_bar ($icon,$value,$min,$max,$minColor,$maxColor,$unit,$decfont,$header,$width,$height,$size, $colorFunc,$light,$lightnumber)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation (0-360) sind optional
$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$header # Überschrift, optional, default = undef (keine)
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
$width # Breite der Grafik, optional, default = 63
$height # Höhe der Grafik, optional, default = 75
$size # Größe der Grafik, optional, default = 100
$colorFunc # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$light # Helligkeit der Grafik (light:0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (light:0-100), optional, default=50
</syntaxhighlight>
Wird '''$colorFunc''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_bar_bsp DOIF ##
attr di_icon_bar_bsp uiTable {package ui_Table;;\
}\
icon_bar ("fuel",[Tankstelle:Diesel],1.10,1.30,120,0,"€",2)|\
icon_bar ("air",[ESPEasy_Eingang_CO2:PPM],400,1200,120,0,"ppm",0)|\
icon_bar ("Zisterne",([Wasserzisterne]/3.4),0,100,0,120,"%",0)|\
icon_bar (([vaillant:Pumpenstatus] eq "off" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),[vaillant:Umlaufmenge],0,20,120,0,"l/min")\
icon_bar ("measure_water_meter",[Wasserverbrauch:heute],0,600,120,0,"l",0)|\
icon_bar ("weather_barometric_pressure",[vaillant:Wasserdruck],0,3,0,180,"bar")|\
icon_bar ("sani_water_tap",[vaillant:HwcHours_hoursum2_value],0,2000,120,0,"h",0)|\
icon_bar ("sani_floor_heating_neutral",[Heizenergie:Vortag_hc],0,150,120,0,"kWh")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_bar_bsp.png|ohne|mini]]

==== Anzeige eines Werteverlaufs und des aktuellen Wertes mit Hilfe der SVG-Funktion '''card''' ====
Es wird der aktuelle Wert eines Readings, sein zeitlicher Verlauf sowie der maximale und minimale Wert in Form einer Informationskarte visualisiert. Das Erscheinungsbild kann über zahlreiche Parameter individualisiert werden. Die Besonderheit ist das Argument '''col<Anzahl><Zeitformat>''' bei der Angabe des Readings der Form '''[<Device>:<Reading>:col<Anzahl><Zeitformat>]'''. Dadurch werden Daten des Readings temporär im DOIF-Modul gesammelt und für die Erzeugung eines Graphen zur Verfügung gestellt - es sind keine weiteren Definitionen erforderlich. Dabei wird besonders sparsam mit der Datensammlung umgegangen, es werden maximal 72 Werte (in Timeslots) gespeichert, unabhängig davon wie lange die Zeitspanne ist und wie oft die Daten ankommen. Die Auflösung des Graphen nimmt mit der Zeitspanne ab - es werden immer maximal 72 Werte dargestellt. Daraus ergibt sich bei einer Stunde eine Auflösung von 3600/72 = 50 Sekunden/Eintrag, bei 6 Stunden sind es 6*60/72 = 5 Minuten/Eintrag, für eine Woche 7*24*60/72 = 140 Minuten/Eintrag usw. Die gesammelten Daten werden über den FHEM-Befehl '''save''' in versteckten Readings des jeweiligen DOIF-Moduls gespeichert.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''card'''
<syntaxhighlight lang="perl">
card ($collect,$header,$icon,$min,$max,$minColor,$maxColor, $unit,$colorRef,$decfont,$prop,$ringModel,$lightness, $collect2,$min2,$max2,$minColor2,$maxColor2,$unit2,$func2,$decfont2)

$collect
# Angabe eines Readings oder eines Arrays mit mehreren Readings der Form [<Device>:<Reading>:col<Anzahl><Zeitformat>], mit Hilfe des Argumentes col (von collect) wird das Modul angewiesen Daten des Readings über einen bestimmten Zeitraum zu sammeln

col<number><timeformat>
# <timeformat>: d Tage, w Wochen, ohne Angabe des Zeitformates wird <Anzahl> in Stunden interpretiert.
# Beispiele: col (entspricht col24), col1, col12, col1d, col3d, col1w, col4w, col52w usw.

$header # "<Überschrifttext,<Style-SVG-Text-Attribute>", optional
$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = 0 (rot)
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = 120 (grün)
$unit
# Einheit des Wertes, optional, default = undef, falls unter $collect ein Array für mehrere Readings angegeben wurde, so werden hier als Array die entsprechenden Einheiten angegeben, zusätzlich kann kommagetrennt pro Einheit Farbe des Graphen angegeben werden

$colorRef
# Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef

$decFont
# "<Anzahl der Nachkommastellen>,<Style-SVG-Attribute Wert>,<Style-SVG-Attribute Einheit>", optional

$prop
# Eigenschaft von card: "<size>,<y-scaling>,<steps>,<noFooter>,<noColor>,<hring>,<width>", optional

# <size>: Größe der der Karte, default = 130,
# <y-scaling>: feste Y-Skalierung: 1, sonst automatische Skalierung,
# <steps>: 1 für Stufen,
# <noFooter>: 1 für keine Fußzeile,
# <noColor>: 1 für graue y-Achsenbeschriftung,
# <hring>: 1 für Halbringdarstellung,
# <width>: Breite der Karte, default: 160

$ringModel
# '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>'

# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'

$lightness
# Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"

$collect2 # optionale Angaben für ein zweites Reading (es ist hier nur eine Readingangabe erlaubt)
$min # restliche Parameter
$max # entsprechen der Syntax
... # des ersten Sensors
$decfonts2 #
</syntaxhighlight>
Wird '''$colorRef''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
Werden mehrere Readings angegeben, so müssen sie alle die gleiche Zeitspanne besitzen (Zeitangabe bei col)

'''nützliche Links'''
* Anwendungsbeispiel [[DOIF/uiTable_Schnelleinstieg#Visualisierung:_Wetterstation|Wetterstation]]
* Anwendungsbeispiel [[DOIF/uiTable_Schnelleinstieg#Visualisierung:_aktueller_Spritpreis|Spritpreise]]
* Anwendungsbeispiel [[DOIF/uiTable_Schnelleinstieg#Visualisierung_und_Steuerung:_Heiztherme|Heiztherme]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Farbskalierte_Anzeige_eines_Icons_mit_einem_Zahlenwert_mit_Hilfe_der_universellen_SVG-Funktion_icon_ring.2Ficon_mring.2Ficon_uring|icon_ring]]
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_collect DOIF ##
attr di_collect uiTable {package ui_Table;;}\
card([Aussensensor:temperature:col12],"Außen","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef)|\
card([Tankstelle:Diesel:col12],"Sprit,fill:darkorange","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,1")\
card([zaehler:l-Produktion:col12],undef,[zaehler:l-Produktion] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,3.6,30,60,"PV kW",undef,"1,,font-size:50%")|\
card([ESPEasy_Eingang_CO2:PPM:col12],undef,"air",400,1200,120,0,"ppm",[600,120,1000,60,1200,0],0,undef,'0,1,1',"50,35,45,35,50,35")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:svgcard.png|ohne|mini]]

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">

defmod di_cards DOIF {}
attr di_cards uiTable {package ui_Table;;}\
"Standard"|\
card([Aussensensor:temperature:col],undef,"temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130")\
"mit Halbring"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130,,,,,1")\
"mit Halbring","ohne Fußzeile","Breite 110"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130,,,1,,1,110")\
"Standard","Breite 200"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130,,,,,,200")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_variations.png|ohne|mini]]

'''<big>Beispieldefinition mit zwei Readings mit unterschiedlichen Einheiten</big>'''
<syntaxhighlight lang="perl">
defmod di_cards DOIF {}
attr di_cards uiTable {package ui_Table;;}\
"Standard"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Header"|\
card([Aussensensor:temperature:col],undef,"temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Header","ohne Fußzeile"|card([Aussensensor:temperature:col],undef,"temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,1,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"Als Halbring"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,,1",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Fußzeile"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,1,,1",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_collect2.png|ohne|mini]]

'''<big>Beispieldefinitionen mit mehreren Readings mit gleicher Einheit</big>'''

<syntaxhighlight lang="perl">
defmod Sprit DOIF ##
attr Sprit uiTable {package ui_Table;;}\
card([[Tankstelle:SuperE5:col24],[Tankstelle:Diesel:col24]],"Sprit","fuel","1.20","1.60",120,0,["E5","Diesel"],undef,"2",",,1")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_Sprit2.png|ohne|mini]]

<syntaxhighlight lang="perl">
defmod PV DOIF {}
attr PV DOIF_Readings l_Eigenv: [zaehler:l-Produktion]-[zaehler:l-Lieferung],\
Eigenv:[zaehler:Produktion]-[zaehler:Lieferung],\
l_Verbrauch: [zaehler:l-Bezug,0]+[$SELF:l_Eigenv,0],\
Verbrauch:[zaehler:Bezug]+[$SELF:Eigenv],\
l_Bezug:-[zaehler:l-Bezug]
attr PV uiTable {\
package ui_Table;;\
$SHOWNOSTATE=1;;\
}\
card([[zaehler:l-Produktion:col],[$SELF:l_Eigenv:col],[$SELF:l_Bezug:col]],"kW","fa_bolt\@silver",-3.6,3.6,0,90,["Solar","Eigen.","Bezug"],[(-1,0,0,30,1,60,3.6,90)],"2","167,,1,,,1",",,1,6")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_energie.png|ohne|mini]]

'''<big>Beispieldefinition mit mehreren Readings mit einfarbigen Graphen</big>'''

<syntaxhighlight lang="perl">
defmod di_heating DOIF {}
attr di_heating uiTable {\
package ui_Table;;\
}\
card([[ESPEasy_ESP_Temp_Vorlauf:Temperature:col],[ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature:col]],"Umwälzpumpe",([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),15,70,undef,undef,["Vor. °C,red","Rück. °C,#287afc"],\&temp_hue,undef,",,1,,1")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_pump.png|ohne|mini]]

==== 3d-Balkendarstellung mehrerer Zahlenwerten mit Hilfe der universellen SVG-Funktion '''cylinder''' ====
Es können mehrere Zahlenwerte mit Legende farbig in Balkenform visualisiert werden. Negative Werte werden als Balken nach unten dargestellt, positive nach oben, der Nullpunkt wird automatisch berechnet.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''cylinder'''
<syntaxhighlight lang="perl">
cylinder ($header,$min,$max,$unit,$width,$height,$size,$dec,($value1,$color1,$text1),($value2,$color2,$text2),...

$header # Überschrift
$min # minimaler Wert, optional, default = 0
$max # maximaler Wert, optional, default = 100
$unit # Einheit des Wertes, optional, default = undef
$width # Breite der Grafik, optional, default = wird bei Beschriftungen automatisch angepasst
$height # Höhe der Grafik, optional, default = wird automatisch berechnet
$size # Größe der Grafik, optional, default = 100
$dec # Anzahl der Nachkommastellen, optional, default=1
$value1 # erster Zahlenwert
$color1 # HSL-Farbe des ersten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text1 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
$value2 # zweiter Zahlenwert, optional
$color2 # HSL-Farbe des zweiten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text2 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
...
Es können weitere Zahlenwerte jeweils mit Farbe und Beschriftung optional angegeben werden
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_cylinder DOIF ##
attr di_cylinder room Test,wiki
attr di_cylinder uiTable {package ui_Table}\
"normal"|cylinder("",0,100,"%",80,undef,undef,0,[Wasserzisterne:state],200,undef)\
\
"mit Überschrift"|cylinder("Zisterne",0,100,"%",80,undef,undef,0,[Wasserzisterne:state],200,undef)\
\
"kleiner"|cylinder("Zisterne",0,100,"%",80,undef,80,0,[Wasserzisterne:state],200,undef)\
\
"hoch"|cylinder("Zisterne",0,100,"%",undef,100,undef,0,[Wasserzisterne:state],200,undef)\
\
"mit Beschriftung"|cylinder("Zisterne",0,100,"%",undef,100,undef,0,[Wasserzisterne:state],200,"Wasserstand")\
\
"mit mehreren Informationen"|cylinder("Energie",-20,30,"kWh",undef,undef,undef,1,[zaehler:Bezug],0,"Bezug",[zaehler:Produktion],60,"Produktion",[zaehler:Eigenverbrauch],30,"Eigenverbrauch")\
\
"mit hellen Farben"| cylinder("Tag",0,100,"kWh",undef,undef,undef,1,[Heizenergie:Tagesverbrauch_hc]/100000,"30.100.70","letzter",[Heizenergie:heute_hc]/100000,"60.100.70","aktuell")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:cylinder_bsp.png|ohne|mini]]

==== Balkendarstellung mehrerer Zahlenwerte mit Hilfe der universellen SVG-Funktion '''cylinder_bars''' ====
Es können mehrere Zahlenwerte mit Legende farbig in Balkenform visualisiert werden. Negative Werte werden als Balken nach unten dargestellt, positive nach oben, der Nullpunkt wird automatisch berechnet. Die '''cylinder_bars'''-SVG-Funkton besitzt die gleichen Argumente, wie die obige '''cylinder'''-SVG-Funktion, mehrerer Balken werden jedoch nicht übereinander, sondern nebeneinander dargestellt.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''cylinder_bars'''
<syntaxhighlight lang="perl">
cylinder_bars ($header,$min,$max,$unit,$width,$height,$size,$dec,($value1,$color1,$text1),($value2,$color2,$text2),...

$header # Überschrift
$min # minimaler Wert, optional, default = 0
$max # maximaler Wert, optional, default = 100
$unit # Einheit des Wertes, optional, default = undef
$width # Breite der Grafik, optional, default = wird bei Beschriftungen automatisch angepasst
$height # Höhe der Grafik, optional, default = wird automatisch berechnet
$size # Größe der Grafik, optional, default = 100
$dec # Anzahl der Nachkommastellen, optional, default=1
$value1 # erster Zahlenwert
$color1 # HSL-Farbe des ersten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text1 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
$value2 # zweiter Zahlenwert, optional
$color2 # HSL-Farbe des zweiten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text2 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
...
Es können weitere Zahlenwerte jeweils mit Farbe und Beschriftung optional angegeben werden
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_wasserverbrauch DOIF ##
attr di_wasserverbrauch uiTable {package ui_Table;;}\
cylinder_bars("Monat",0,15,"m³",undef,undef,undef,1,[Wasserverbrauch:monatsdurchschnitt],30,"Durchschnitt",[Wasserverbrauch:monatsverbrauch]/1000,220,"letzter",[Wasserverbrauch:monat]/1000,180,"aktuell")\
\
cylinder_bars("Monat",0,15,"m³",undef,undef,undef,1,[Wasserverbrauch:jan],30,"Januar",[Wasserverbrauch:feb],220,"Februar",[Wasserverbrauch:mrz],180,"März",[Wasserverbrauch:apr],30,"April",[Wasserverbrauch:mai],220,"Mai",[Wasserverbrauch:jun],180,"Juni",[Wasserverbrauch:jul],30,"Juli",[Wasserverbrauch:aug],220,"August",[Wasserverbrauch:sep],180,"September",[Wasserverbrauch:okt],30,"Oktober",[Wasserverbrauch:nov],220,"November",[Wasserverbrauch:dez],180,"Dezember")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:cylinder_bars_bsp.png|ohne|mini]]

=== Farbskalierte Temperaturanzeige mit Hilfe der Funktion '''temp''' ===
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert:
[[Datei:Farbskalierung temp.png|600px|ohne]]
{{Randnotiz|RNText=uiTable-Funktion '''temp'''
<syntaxhighlight lang="perl">
temp ($temp,$size,$icon)

$temp # Temperatur
$size # Schriftgröße in Pixel (pt), optional
$icon # Icon, welches vorangestellt wird, optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_temp DOIF ##
attr di_uiTable_temp uiTable {\
package ui_Table;; ## Package für uiTable-Funktionen\
$TC{0..2}="align='center'";; ## zentrierte Darstellung aller Tabellenspalten\
}\
## Tabellendefinition\
\
"Aussen"|"Bad"|"Warmwasser" ## mit | werden Tabellenzellen voneinander getrennt \
temp([Aussensensor:temperature])| ## Anzeige des Readings 'temperature' des Gerätes 'Aussensensor' \
temp([TH_Bad_HM:measured-temp],24,"temp_temperature")| ## Schriftgröße 24pt, mit Icon namens temp_temperature\
temp([T_Warmwasserspeicher:temperature:d1],20) ## Schriftgröße 20pt
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Temp.png|ohne|mini]]

=== Farbskalierte Feuchtigkeitsanzeige mit Hilfe der Funktion '''hum''' ===
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert:
[[Datei:Farbskalierung hum.png|350px|ohne]]
{{Randnotiz|RNText=uiTable-Funktion '''hum'''
<syntaxhighlight lang="perl">
hum ($hum,$size,$icon)

$hum # Feuchtigkeit
$size # Schriftgröße in Pixel (pt), optional
$icon # Icon, welches vorangestellt wird, optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_hum DOIF ##
attr di_uiTable_hum uiTable {\
package ui_Table;;\
$TC{1}="align='center'";; ## zweite Spalte der Tabelle zentriert\
}\
## Tabellendefinition \
\
## Anzeige des Readings 'humidity' des Thermostats 'TH_Bad_HM' \
"Bad"|hum ([TH_Bad_HM:humidity])\
\
## Feuchtigkeit in Größe 10pt mit Temperatur in einer Tabellenzelle\
"Aussen"|temp ([Aussensensor:temperature]),hum ([Aussensensor:humidity],10)\
\
## Feuchtigkeit in Größe 26pt mit Icon namens 'temperature_humidity'\
"Keller"|hum ([TH_Keller_HM:humidity],26,"temperature_humidity")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable Funktion hum.png|ohne|mini]]

=== Textformatierungen mit Hilfe der Funktion '''style''' ===
Texte werden in Farbe, Größe und Schriftart statisch oder dynamisch formatiert.
{{Randnotiz|RNText=uiTable-Funktion '''style'''
<syntaxhighlight lang="perl">
style ($text,$color,$font_size,$font_weight)

$text # anzuzeigender Text
$color # CSS color, optional
$font_size # Schriftgröße in Pixel (pt), optional
$font_weight # CSS Schriftart, optional
</syntaxhighlight>
Mögliche Werte für '''''color''''' und '''''font_weight''''' können in einschlägiger Dokumentation zu CSS nachgeschlagen werden
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_style DOIF ##
attr di_uiTable_style uiTable {\
package ui_Table;;\
}\
## Tabellendefinition\
\
## statische Farbgebung, Größe, Schriftart \
style("Montag","orange")\
style("Dienstag","red",14)\
style("Mittwoch","#00FFFF",20)\
style("Donnerstag","blue",23,"bold")\
\
## dynamische Farbgebung abhängig vom Zustand des Gerätes 'Alarm'\
style("Alarm",([Alarm:state] eq "on" ? "red":"green"))\
\
## dynamische Farbgebung des Zustands des Gerätes 'Alarm'\
style([Alarm:state],([Alarm:state] eq "on" ? "red":"green"))\
\
## variabler Text abhängig vom Zustand des Gerätes 'Alarm'\
style(([Alarm:state] eq "on" ? "Alarm aktiv":"Alarm deaktiviert"),"red")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Style.png|ohne|mini]]

=== Icon-Darstellung mit Hilfe der Funktion '''ICON''' ===
Mit Hilfe der Funktion '''ICON''' kann ein FHEM-Icon dargestellt werden
{{Randnotiz|RNText=uiTable-Funktion '''ICON'''
<syntaxhighlight lang="perl">
ICON ($icon)

$icon # Icon mit Farbgebung
</syntaxhighlight>

'''ICON''' benutzt die Funktion [[DevelopmentFHEMWEB-API#FW_makeImage|FW_makeImage]]

'''nützliche Links'''
* [[DOIF/uiTable Schnelleinstieg#hsv-Funktion für Farbskalierungen|hsv-Funktion]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_Table_ICON DOIF ##
attr di_Table_ICON uiTable {\
package ui_Table;;\
}\
## Tabellendefinition\
ICON("temp_frost") | ## Icon ohne Einfärbung\
ICON("temp_frost\@blue") | ## Icon in CSS-Farbe blau\
ICON("temp_frost\@#8A2BE2") | ## Icon in CSS-Farbe #8A2BE2\
ICON("temp_frost\@".([Aussensensor:temperature] > 0 ? "orange":"blue"))| ## Icon in CSS-Farbe orange über Null Grad, sonst in CSS-Farbe blau\
ICON("temp_frost\@".hsv ([Aussensensor:temperature],-20,40,320,0)) ## Icon in Farbskalierung von violett (-20 °C) bis rot (40 °C) mit Hilfe der Funktion hsv
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable_IC.png|mini|ohne]]

=== Icon-Darstellung mit Text mit Hilfe der Funktion '''icon_label''' ===
Mit Hilfe der Funktion '''icon_label''' kann ein FHEM-Icon mit einem angehängten Text/Wert dargestellt werden.
{{Randnotiz|RNText=uiTable-Funktion '''icon_label'''
<syntaxhighlight lang="perl">
icon_label ($icon,$text,$color,$color_bg,$pos_left,$pos_top)
$icon # FHEM-Icon mit Farboption
$text # dargestellter Text
$color # Farbe des Textes, optional
$color # Hintergrundfarbe des Textes, optional
$pos_left # horizontale Position des Textes in px, default -5, optional
$pos_top # vertikale Position des Textes in px, default -8, optional
</syntaxhighlight>

'''Anwendungsbeispiele'''
* [[DOIF/uiTable Schnelleinstieg#Anzahl der Tage bis zur Abfall-Entsorgung|Abfall]]
* [[DOIF/uiTable Schnelleinstieg#Visualisierung: aktueller Spritpreis|Sprit]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_icon_label DOIF ##
attr di_uiTable_icon_label uiTable { package ui_Table;;\
}\
\
icon_label("fuel",[Tankstelle:Diesel])|\
icon_label("fuel",[Tankstelle:Diesel],"red")|\
icon_label("fuel\@blue",[Tankstelle:Diesel],"blue","#999999")|\
icon_label("fuel\@red",[Tankstelle:Diesel],"red","white",-10)|\
icon_label("fuel",[Tankstelle:Diesel],"white","red",-5,8)\

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable_icon_label.png|mini|ohne]]

=== Visualisierung eines Gerätes mit Hilfe der Funktion '''icon''' ===
Der Zustand eines Gerätes/Readings wird mit Hilfe eines Icons dargestellt.
{{Randnotiz|RNText=uiTable-Funktion '''icon'''
<syntaxhighlight lang="perl">
icon ($value,$icon_off,$icon_on,$state_off,$state_on)

$value # Wert
$icon_off # Icon für den Wert off, default "off"
$icon_on # Icon für den Wert on, default Icon für Wert 'off' in Farbe 'DarkOrange', sonst Icon 'on', wenn $icon_off nicht definiert ist
$state_off # Wert zugehörig zum Icon off, default "off"
$state_on # Wert zugehörig zum Icon on, default "on"
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_icon DOIF ##
attr di_uiTable_icon uiTable {\
package ui_Table;;\
}\
## Tabellendefinition\
\
## Standard-Icon off/on für Standardwert off/on \
"Lampe"|icon([Lampe:state]) ## entspricht icon([Lampe:state],"off","on","off","on")\
\
## Icon für Zustand 'off' ist 'hue_room_hallway', für Zustand 'on' 'hue_room_hallway\@DarkOrange'\
"Flur"|icon([Lampeflur:state],"hue_room_hallway") ## entspricht icon([Lampeflur:state],"hue_room_hallway","hue_room_hallway\DarkOrange","off","on")\
\
## Icon für Zustand 'off' ist 'status_away_2', für Zustand 'on' 'status_available\@DarkOrange'\
"Anwesenheit"|icon([Anwesenheit:state],"status_away_2","status_available\@DarkOrange") \
\
## Icon für Zustand 'closed' ist "status_locked", für Zustand 'open' 'status_open\@DarkOrange'\
"Haus"|icon([Schloss:state],"status_locked","status_open\@DarkOrange","closed","open")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable icon.png|mini|ohne]]

=== Schaltbares Icon mit Hilfe der Funktion '''switch''' ===
Der Zustand eines Gerätes/Readings wird mit Hilfe eines Icons dargestellt, er kann über die WEB-Oberfläche durch Anklicken geschaltet werden. Damit der Zustand des Gerätes geschaltet werden kann, muss das Gerät den set-Befehl unterstützen.

{{Randnotiz|RNText=uiTable-Funktion '''switch'''
<syntaxhighlight lang="perl">
switch ($value,$icon_off,$icon_on,$state_off,$state_on)

$value # [<device>:<reading>]
$icon_off # Icon für den Wert off, default "off"
$icon_on # Icon für den Wert on, default Icon für Wert 'off' in Farbe 'DarkOrange', sonst Icon 'on', wenn $icon_off nicht definiert ist
$state_off # Wert zugehörig zum Icon off, default "off"
$state_on # Wert zugehörig zum Icon on, default "on"
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_switch DOIF ##
attr di_uiTable_switch uiTable {\
package ui_Table;;\
}\
## schaltbares Icons in der Webansicht \
switch([Lampe:state]) | \
switch([Lampeflur:state],"hue_room_hallway") |\
switch([Anwesenheit:state],"status_away_2","status_available\@DarkOrange")|\
switch([Haus:state],"status_locked","status_open\@DarkOrange","closed","open")\
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable switch.png|mini|ohne]]

=== Rollladen: Visualisierung und Steuerung mit Hilfe der Funktion '''shutter''' ===
Die aktuelle Position des Rollladens (0 % - 100 %) wird über Icons visualisiert. Das Anklicken eines Symbols steuert den Rollladen auf die entsprechende Position. Prozentwerte zwischen zwei Icon-Werten werden dem nächsthöheren Icon-Wert zugeordnet.
{{Randnotiz|RNText=uiTable-Funktion '''shutter'''
<syntaxhighlight lang="perl">
shutter ($value,$color,$type)

$value # [<device>:<reading>]
$color # Farbe der aktuellen Rollladenposition, vorangestelltes @ verändert die Farbe des Icons, ohne @ wird der Hintergrund des Icons eingefärbt, default ist @DarkOrange
$type # optional, Anzahl der Symbole 2 bis 6, 3 ist default
</syntaxhighlight>

* [[DOIF/uiTable Schnelleinstieg#Visualisierung und Steuerung von Rollläden|Anwendungsbeispiel]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_shutter DOIF ##
attr ui_Table_shutter uiTable {\
package ui_Table;;\
}\
shutter([R_Keller:pct],"\@yellow",2) ## zwei Symbole für 0 % und 100 %\
shutter([R_Wohnzimmer_S:pct]) ## entspricht shutter ([R_Wohnzimmer_S:pct],"\@DarkOrange",3) \
shutter([R_Wohnzimmer_W1:pct],"blue",4) ## vier Symbole \
shutter([R_Wohnzimmer_W2:pct],"\@red",5) ## fünf Symbole\
shutter([R_Wohnzimmer_W3:pct],"red",6 ## sechs Symbole)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable shutter.png|mini|ohne]]

=== Helligkeit: Visualisierung und Steuerung mit Hilfe der Funktion '''dimmer''' ===
Die aktuelle Helligkeit (0 % - 100 %) wird über Icons visualisiert. Das Anklicken eines Icons bestimmt die Helligkeit der Leuchte. Prozentwerte zwischen zwei Icon-Werten werden dem nächsthöheren Icon-Wert zugeordnet.
{{Randnotiz|RNText=uiTable-Funktion '''dimmer'''
<syntaxhighlight lang="perl">
dimmer ($value,$color,$type)

$value # [<device>:<reading>]
$color # Farbe der aktuellen Helligkeit, vorangestelltes @ verändert die Farbe des Icons, ohne @ wird der Hintergrund des Icons eingefärbt, default ist @DarkOrange
$type # Anzahl der Symbole 2 bis 7, 3 ist default
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_dimmer DOIF ##
attr di_uiTable_dimmer uiTable {\
package ui_Table;;\
}\
dimmer([Strauch3:pct],"\@yellow",2)\
dimmer([Strauch3:pct]) ## entspricht dimmer([Strauch3:pct],"\@DarkOrange",3) \
dimmer([Strauch3:pct],"blue",4)\
dimmer([Strauch3:pct],"\@red",5)\
dimmer([Strauch3:pct],"red",6)\
dimmer([Strauch3:pct],"DarkOrange",7)

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable dimmer.png|mini|ohne]]

=== Vorgabetemperatur eines Thermostats mit Hilfe der Funktion '''temp_knob''' ===
Die aktuelle Vorgabetemperatur eines Thermostats wird über ein Icons visualisiert. Durch Anklicken des Ringes wird die Vorgabetemperatur verändert.
{{Randnotiz|RNText=uiTable-Funktion '''temp_knob'''
<syntaxhighlight lang="perl">
temp_knob ($value,$color,$set)

$value # [<device>:<reading>]
$color # Farbe der voreingestellten Temperatur, default "Darkorange"
$set # set-Befehl, default "set", sonst muss "set <Readingname>" angegeben werden, falls sich das Reading vom set-Befehl vom angezeigten Reading unterscheidet, wie beim THRESHOLD-Modul
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_temp_knob DOIF ##
attr ui_Table_temp_knob uiTable {\
package ui_Table;;\
}\
\
## HM-EU-Thermostat, angezeigt wird das Reading "desired-temp", geschaltet wird über "set desired-temp" \
"Dachgeschoss"|temp_knob([TH_DG_HM:desired-temp]) ## entspricht temp_knob([TH_DG_HM:desired-temp],"Darkorange","set") \
\
## HM-EU-Thermostat Temperaturanzeige in gelb \
"Wohnzimmer"|temp_knob([TH_WZ_HM:desired-temp],"yellow") \
\
## Beim THRESHOLD-Modul wird das Reading "desired_value" angezeigt, geändert wird die Temperatur per "set desired" \
"Küche"|temp_knob([TH_Kueche:desired_value],"red","set desired")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable temp knob.png|mini|ohne]]

== uiTable-'''Templates''' ==
Die Definition einer oder mehrere Zellen kann zu einem Template zusammengefasst werden. Durch die Nutzung von Templates kann die Definition einer Tabelle erheblich vereinfacht werden. Insb. bei gleichartigen Zellen/Zeilen für verschiedene Geräte/Readings braucht eine aufwendige Definition nicht immer wieder wiederholt werden, sondern kann jeweils mit dem Aufruf eines zuvor definierten Templates realisiert werden.
{{Randnotiz|RNText='''Templates'''
* Die Definition von Templates muss vor der Tabellendefinition vorgenommen werden
* Eine Template-Definition beginnt mit dem Schlüsselwort '''DEF'''
* Der Template-Name muss mit '''TPL_''' beginnen
* '''Template-Definition'''-Syntax
<syntaxhighlight lang="perl">
DEF TPL_<Template-Name>(<Zellendefinition mit Platzhaltern: $1,$2,...>)
</syntaxhighlight>
* Templates-Definitionen können in externe Dateien ausgelagert werden
* Templates-Definitionen können per IMPORT-Befehl aus externen Dateien importiert werden
* '''Template-Import'''-Syntax
<syntaxhighlight lang="perl">
IMPORT <Pfad mit Dateinamen>
</syntaxhighlight>
* Innerhalb einer Tabellendefinition können zuvor definierte oder importierte Templates mehrfach genutzt werden
* '''Template-Aufruf'''-Syntax
<syntaxhighlight lang="perl">
TPL_<Template-Name>(<Übergabeparameter für $1>,<Übergabeparameter für $2>,...)
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_Template DOIF ##
attr ui_Table_Template uiTable {\
package ui_Table;;\
$TC{1..3}="align='center'";; ## Spalten 1 bis 3 werden zentriert\
}\
\
## Template-Definitionen beginnen vor der Tabellendefinition\
\
## Das Template TPL_raum stellt eine Tabellenzeile dar, die mit Hilfe von uiTable-Funktionen mehrere Tabellenzellen definiert\
DEF TPL_raum ("$1" | temp([TH_$2_HM:measured-temp]),hum([TH_$2_HM:humidity]) | switch([H_$2:state],"fa_off") | temp_knob([TH_$2_HM:desired-temp]))\
\
## Tabellendefinition\
\
## pro Tabellenzeile wird ein Raum mit Hilfe des oben definierten Templates "TPL_raum" dargestellt\
"Raum"|"Temp./Feuchte"|"Ventil"|"Vorgabetemp."\
TPL_raum (Dachgeschoss,DG) ## der Übergabeparameter "Dachgeschoss" wird im Template "TPL_raum" anstelle von $1 eingesetzt, "DG" wird anstelle von $2 eingesetzt\
TPL_raum (Bad,Bad)\
TPL_raum (Kinderzimmer ost,Kz_o)\
TPL_raum (Kinderzimmer west,Kz_w)\
TPL_raum (Wohnzimmer,WZ)\
TPL_raum (Keller,Keller)

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable Templates.png|mini|ohne]]

== Eigene uiTable-Funktionen programmieren ==
Für die eigenen Bedürfnisse können eigene uiTable-Funktionen programmiert werden. In der Datei [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DOIF/uiTable.tpl contrib/DOIF/uiTable.tpl] befinden sich alle intern definierten uiTable-Funktion aus dem package ui_Table als Kopie. Diese Funktionen können als Inspiration für eigene Entwicklung dienen.
{{Randnotiz|RNText='''uiTable-Funktionen'''
* Es gibt drei Arten von uiTable-Funktionen, sie werden intern anhand der Rückgabewerte unterschieden
* uiTable-Funktionen vom Typ 1: '''HTML''', ein Rückgabewert
<syntaxhighlight lang="perl">
return(<HTML-code>)
</syntaxhighlight>
* uiTable-Funktionen vom Typ 2: '''Style''' (entspricht der '''STY'''-Funktion), zwei Rückgabewerte
<syntaxhighlight lang="perl">
return(<value>,<CSS-style>)
</syntaxhighlight>
* uiTable-Funktionen vom Typ 3: '''Widget''' (entspricht der '''WID'''-Funktion), vier Rückgabewerte
<syntaxhighlight lang="perl">
return (<value>,<>,<FHEM-widget>,<set-command: "" or "set" or "set <Readingname>">)
</syntaxhighlight>
* uiTable-Funktionen sind reine Perlfunktionen
* uiTable-Funktionen sollten im eigenen Package definiert werden, sonst könnten bestehende Perlfunktionen im System überschrieben werden
* uiTable-Funktionen können in Template-Dateien ausgelagert werden und über IMPORT-Befehl importiert werden, siehe Templates
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_function DOIF ##
attr di_uiTable_function uiTable {\
package my_uiTable;; ## eigenes Package mit selbstdefinierten Funktionen\
\
## uiTable-Funktion vom Typ "HTML", Rückgabewert: (HTML-code)\
\
sub clock { ## Anzeige aktueller Uhrzeit mit Datum\
## Voraussetzung: contrib/DOIF/doifclock.js muss ins www/pgm2-Verzeichnis kopiert werden\
## Attribut setzen in der Webinstanz: attr <WEB-Instanz> JavaScripts pgm2/doifclock.js \
my ($color,$size)=@_;;\
$color="darkorange" if (!defined ($color));; ## $color ist optional, default Darkorange\
$size="20" if (!defined ($size));; ## $size ist optional, default 20pt\
return("<div class='doifclock'style='font-weight:bold;;font-size:".$size."pt;;color:".$color.";;'>error</div>")\
}\
\
## uiTable-Funktion vom Typ Style, Rückgabewerte (Wert,CSS-style)\
\
sub red_green { ## Farbige Skalierung von Zahlen mit Hilfe der DOIF_hsv-Funktion: von 0 - rot bis 10 - grün\
my ($value)=@_;;\
return ($value." KW", ## Wert/Text\
"font-weight:bold;;color:".::DOIF_hsv ($value,0,10,0,120,70,100) ## CSS-Style\
);;\
} \
\
## uiTable-Funktion vom Typ Widget, Rückgabewerte (Wert,Leer,FHEM-Widget,set-Befehl)\
\
sub slider { ## FHEM-Widget Slider, weitere FHEM-Widgets siehe: https://wiki.fhem.de/wiki/FHEMWEB/Widgets\
my ($value,$set)=@_;;\
$set="" if (!defined $set);;\
return ($value, ## Zahlenwert\
"", ## leer\
"slider,0,0.5,100,1", ## FHEM-Widget\
$set ## set-Befehl des FHEM-Widgets\
) \
}\
\
}\
\
## Tabellendefinition\
\
"Uhrzeit/Datum"\
clock("yellow",30) ## obige Funktion clock\
"Dimmer"\
slider([Wohnzimmer:pct]) ## obige Funktion slider\
"Leistung"\
red_green([Leistung:state]) ## obige Funktion red_green
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-functions.png|mini|ohne]]

== Package-Konzept, Auslagerung eigener Funktionen, der '''IMPORT'''-Befehl==
uiTable arbeitet mit Packages. In einem Package sind definierte Funktionen gekapselt, sie kollidieren nicht mit bereits definierten Funktionen in FHEM.
{{Randnotiz|RNText='''Package'''
* das für die Definition der Tabelle gültige Package wird im Perlblock des uiTable-Attributes angegeben
* interne uiTable-Funktionen befinden sich im Package '''ui_Table'''
* ohne eine Angabe eines Package befindet man sich im Package '''main'''
* Funktionen außerhalb des gültigen Package müssen mit <package-Name>::<Funktion> angegeben werden
* externe uiTable-Funktionen können per IMPORT-Befehl importiert werden
}}
=== Tabellendefinition im Package main ===
<syntaxhighlight lang="perl">
defmod beispiel1 DOIF ##
attr beispiel1 uiTable ## keine Package-Definition im Perlblock\
\
## Tabellendefinition befindet sich im Package main\
\
## Funktionen aus dem main-Package können unmittelbar angegeben werden\
FW_makeImage("scene_day")\
\
## Funktionen aus dem ui_Table-Package müssen mit vorangestelltem Package angegeben werden\
ui_Table::temp ([Aussensensor:tempaerature])
</syntaxhighlight>

=== Tabellendefinition im Package ui_Table ===
<syntaxhighlight lang="perl">
defmod beispiel2 DOIF ##
attr beispiel2 uiTable {\
package ui_Table; ## Package-Angabe im Perlblock\
}\
\
## Tabellendefinition befindet sich im Package ui_Table\
\
## Funktionen aus dem main-Package müssen mit vorangestelltem package angegeben werden, der Name main kann weggelassen werden\
::FW_makeImage("scene_day")\
\
## Funktionen aus dem ui_Table-Package können direkt angegeben werden\
temp ([Aussensensor:temperature])
</syntaxhighlight>

=== Eigene uiTable-Funktionen im eigenen Package ===
Diese Art der Definition bietet sich dann an, wenn man eine eigene uiTable-Funktion nur in einem DOIF nutzen möchte.
<syntaxhighlight lang="perl">
defmod beispiel3 DOIF ##
attr beispiel3 uiTable {\
package $SELF;; ## Package-Name ist der Name des DOIF-Moduls, dadurch ist der Package-Name eindeutig\
sub scene_day { ## eigene Funktion befindet sich im eigenen Package beispiel3\
return (::FW_makeImage("scene_day"));;\
}\
}\
## Tabellendefinition befindet sich im Package beispiel3\
\
## Funktionen aus dem main-Package müssen mit vorangestelltem Package angegeben werden (der Name main kann weggelassen werden)\
::FW_makeImage("scene_day")\
\
## interne Funktionen aus dem ui_Table-Package müssen mit vorangestelltem Package ui_Table angegeben werden\
ui_Table::temp ([Aussensensor:temperature])\
\
## eigene Funktionen können direkt angegeben werden\
scene_day()
</syntaxhighlight>

=== Eigene ausgelagerte uiTable-Funktionen ===
Möchte man das ui_Table-Package um eigene Funktionen erweitern, die man in verschiedenen DOIFs nutzen möchte, so sollte man diese in eine eigene Datei auslagern, die man mit dem IMPORT-Befehl vor der Definition der Tabelle importieren kann.

Ausgelagerte Funktion in einer eigenen Datei z. B. my_uiTable.tpl:

<syntaxhighlight lang="perl">
{ ## Inhalt der Datei my_uiTable.tpl
package ui_Table; ## das aktuelle Package ist ui_Table
sub scene_day { ## eigene Funktion wird zum Package ui_Table hinzugefügt
return (::FW_makeImage("scene_day"));
}
## die Datei kann alle Funktionen beinhalten, die man in diversen DOIFs nutzen möchte
}
</syntaxhighlight>

<syntaxhighlight lang="perl">
defmod beispiel4 DOIF ##
attr beispiel4 uiTable ##\
\
IMPORT ./contrib/DOIF/my_uiTable.tpl ## nach dem Import befindet man sich in Package ui_Table erweitert um eigene Funktionen\
\
## Tabellendefinition befindet sich im Package ui_Table\
\
## Funktionen aus dem main-Package müssen mit vorangestelltem Package angegeben werden (der Name main kann weggelassen werden)\
::FW_makeImage("scene_day")\
\
## interne uiTable-Funktionen aus dem ui_Table-Package können direkt angegeben werden\
temp ([Aussensensor:temperature])\
\
## eigene Funktionen können direkt angegeben werden, da man sich bereits im Package uiTable befinden\
scene_day()\
</syntaxhighlight>

== '''hsv'''-Funktion für Farbskalierungen==
Mit Hilfe der hsv-Funktion können Texte, Werte oder Icons abhängig vom Wert eingefärbt werden. Es wird durch Vorgabe von Farbsättigung (saturation) und Helligkeit (lightness), linear ein Farbton für einen bestimmten Wert errechnet. Den Farbwert HUE (0 - 360) für den kleinsten sowie größten Wert kann man mit Hilfe eines Color-Pickers bestimmen. Der Rückgabewert ist ein Farbwert in der CSS-Notation.
{{Randnotiz|RNText='''hsv-Funktion für Farbskalierungen'''
<syntaxhighlight lang="perl">
hsv ($value,$min_value,$max_value,$min_hue,$max_hue,$saturation,$lightness)
$value # Wert, Reading
$min_value # der kleinste Wert, dieser entspricht dem Farbwert $min_hue
$max_value # der größte Wert, dieser entspricht dem Farbwert $max_hue
$min_hue # Farbwert für den kleinsten Wert $min_value
$max_hue # Farbwert für den größten Wert $max_value
$saturation # Farbsättigung, default 100, optional
$lightness # Farbhelligkeit, default 100, optional
</syntaxhighlight>
Die Funktion befindet sich im ui_Table-Package
}}

'''<big>Beispieldefinition</big>'''

<syntaxhighlight lang="perl">
defmod di_uiTable_hsv DOIF ##
attr di_uiTable_hsv uiTable {\
package ui_Table;;\
## eigene uiTable-Funktionen vom Typ 1 mit einem Rückgabewert als HTML-Code\
\
sub bat_icon { ## färbt das Icon 'measure_battery_100' abhängig vom Wert mit Hilfe der Funktion hsv \
my ($value)=@_;;\
return(ICON("measure_battery_100\@".hsv($value,0,100,0,120,100,100)))\
}\
\
sub bat_icon2 {## zusätzlich zum Farbwert wird ein entsprechendes Icon bestimmt\
my($val)=@_;;\
my $icon;;\
if ($val==0) {\
$icon="measure_battery_0";;\
} elsif ($val<=25) {\
$icon="measure_battery_25";;\
} elsif ($val<=50) {\
$icon="measure_battery_50";;\
} elsif ($val<=75) {\
$icon="measure_battery_75";;\
} else {\
$icon="measure_battery_100";;\
}\
\
my $output=ICON("$icon\@".hsv ($val,0,100,0,120,90,100));;\
return($output);;\
}\
}\
\
## Tabellendefinition\
\
## eingefärbtes Icon 0 % entspricht rot (HSV-Wert 0), 100 % entspricht grün (HSV-Wert 120) mit Direktangabe\
1|ICON("measure_battery_100\@".hsv([bat:level],0,100,0,120,100,100))\
\
## gleiche Funktionalität mit Hilfe der oben definierten Funktion bat_icon \
2|bat_icon([bat:level])\
\
## Icon mit Hilfe der oben definierten Funktion bat_icon2\
3|bat_icon2([bat:level])\
\
## Beispiel für die Farbskaliereung von 0 bis 100 % mit der obigen Funktion bat_icon\
4|bat_icon(0)|bat_icon(10)|bat_icon(20)|bat_icon(30)|bat_icon(40)|bat_icon(50)|bat_icon(60)|bat_icon(70)|bat_icon(80)|bat_icon(90)|bat_icon(100)\
\
## Beispiel für die Farbskaliereung von 0 bis 100 % mit der obigen Funktion bat_icon2\
5|bat_icon2(0)|bat_icon2(10)|bat_icon2(20)|bat_icon2(30)|bat_icon2(40)|bat_icon2(50)|bat_icon2(60)|bat_icon2(70)|bat_icon2(80)|bat_icon2(90)|bat_icon2(100)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable DOIF hsv.png|mini|ohne]]

== Eine for-Schleife mit Hilfe des '''FOR'''-Befehls ==
Mit Hilfe des '''FOR'''-Befehls können über eine Schleife aus einer Liste mit Elementen mehrere Tabellenzellen definiert werden. Die Elementenliste (Array) kann über eine Funktion bestimmt werden. Auf diese Weise kann z. B. eine Tabelle für mehrere Geräte einfach definiert werden.
{{Randnotiz|RNText='''FOR-Befehl'''
* Der FOR-Befehl entspricht einer foreach-Schleife in Perl
* Syntax: '''FOR (<Array>,<Zellendefinitionen>)''' '''<Array>''' eine gültige Angabe eines Arrays oder eine Perlfunktion, die ein Array liefert '''<Zellendefinitionen>''' Definition einer oder mehrerer Zellen, die Angabe $_ wird durch das jeweilige Element des Arrays ersetzt
*'''nützliche Links'''
**{{Link2CmdRef|Anker=DOIF_aggregation|Lang=de|Label=DOIF Aggregationsfunktionen mit Perlfunktion AggrDoIf}}
**[[DevelopmentModuleAPI#devspec2array|devspec2array]]
}}
'''<big>Beispieldefinitionen</big>'''
<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Temperaturen aller Geräte, die mit 'T' beginnen und ein Reading 'temperature' haben, sollen in einer Tabelle visualisiert werden\
FOR(::AggrDoIf('@','^T_','temperature'),"$_"|temp([$_:temperature:d2]))
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-temperature.png|200px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Anzeige des Batteriestatus aller Geräte, bei denen das Wort 'Fenster' vorkommt, die das Readings 'battery' haben\
FOR(::AggrDoIf('@','Fenster','battery'),"$_"|bat([$_:battery]))
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-battery.png|200px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Anzeige des Status aller Geräte im System vom Typ 'HMS'\
FOR(::devspec2array("TYPE=HMS"),"$_"|[$_])
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-HMS.png|300px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Elemente einer kommagetrennten Liste sollen jeweils in einer Tabellenzelle in einer Tabellenzeile angezeigt werden\
FOR(split(",","Mo,Di,Mi,Do,Fr,Sa,So"),ui_Table::style("$_","Darkorange")|)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-split.png|300px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Durch Leerzeichen getrennte Zeichenketten sollen jeweils in einer Tabellenzelle in einer Tabellenzeile angezeigt werden\
FOR(qw/Montag Dienstag Mittwoch Donnerstag Freitag/,"$_"|)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-qw.png|300px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## das Templates TPL_raum, soll vier mal aufgerufen werden: TPL_raum(1), TPL_raum(2)...\
## das Templates TPL_raum muss vorher definiert worden sein\
FOR(1..4,TPL_raum($_))
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR TPL raum.png|600px|ohne]]

== '''Anwendungsbeispiele''' ==
=== '' Visualisierung und Steuerung von '''Rollläden''''' ===
Im folgenden Beispiel werden Rollläden morgens hochgefahren, ebenso wird die Position aller Rollläden visualisiert. Durch Anklicken eines Icons wird der Rollladen auf die entsprechende Position bewegt.
{{Randnotiz|RNText='''nützliche Links'''
* {{Link2CmdRef|Anker=DOIF_Zeitsteuerung_mit_Zeitintervallen|Lang=de|Label=Zeitsteuerung}}
* uiTable-Funktion [[DOIF/uiTable Schnelleinstieg#Rollladen: Visualisierung und Steuerung mit Hilfe der Funktion shutter|shutter]]
* uiTable-Funktion [[DOIF/uiTable Schnelleinstieg#Textformatierungen mit Hilfe der Funktion style|style]]
* [[DOIF/uiTable Schnelleinstieg#uiTable-Templates|Templates]]
}}
<syntaxhighlight lang="perl">
defmod DI_Rollladen DOIF (([Dunkelheit] eq "off" and [06:25-09:00|8]) or [09:00|7]) \
((set R_W_S,R_W_W[1-3] on)) ## Hochfahren der Rollläden im Erdgeschoss morgens\
DOELSEIF ([Dunkelheit] eq "on")
attr DI_Rollladen cmdState oben|unten
attr DI_Rollladen devStateIcon unten:status_night oben:scene_day
attr DI_Rollladen icon fts_shutter_automatic
attr DI_Rollladen uiTable {\
package ui_Table;;\
}\
\
## Template für ein Fenster\
DEF TPL_shutter("$1"|shutter([$1:pct]))\
\
## Tabellendefinition\
\
style("Dachgeschoss","Darkorange")|""\
TPL_shutter(R_Dachboden)\
style("erstes Geschoss","Darkorange")|""\
TPL_shutter(R_Bad)\
TPL_shutter(R_Kinderzimmer1_O)\
TPL_shutter(R_Kinderzimmer1_S)\
TPL_shutter(R_Kinderzimmer2_S)\
TPL_shutter(R_Kinderzimmer2_W1)\
TPL_shutter(R_Kinderzimmer2_W2)\
style("Erdgeschoss","Darkorange")|""\
TPL_shutter(R_Kueche)\
TPL_shutter(R_W_S)\
TPL_shutter(R_W_W1)\
TPL_shutter(R_W_W2)\
TPL_shutter(R_W_W3)\
style("Keller","Darkorange")|""\
TPL_shutter(R_Keller)\
</syntaxhighlight>
''Ergebnis des Anwendungsbeispiels in der Webansicht:''
[[Datei:UiTable Rollladen.png|mini|ohne]]

=== ''Anzahl der Tage bis zur '''Abfall-Entsorgung''''' ===
Mit Hilfe des Kalender-Moduls werden die verbleibenden Tage bis zur Abfall-Entsorgung der jeweiligen Tonne berechnet und mit Hilfe von uiTable visualisiert. Wenn der Tag der Entsorgung bevorsteht, wird er farbig gekennzeichnet. Vorausgesetzt wird die Definition des Kalenders namens 'cal' mit Hilfe des Moduls [[Calendar]]. Dieser muss die Termine der Abfallentsorgung der Tonnen beinhalten. Im Beispiel wird nach Stichwörtern: "Altpapier", "Restmüll", "Bio", "Gelber" und "Grünschnitt" im Kalender gesucht.
{{Randnotiz|RNText='''nützliche Links'''
* FHEM-Modul [[Calendar]]
* ui_Table Funktion [[DOIF/uiTable Schnelleinstieg#Icon-Darstellung mit Text mit Hilfe der Funktion icon_label|icon_label]]
}}
<syntaxhighlight lang="perl">
defmod Abfall DOIF subs {\
## Die Funktion 'days' sucht nach dem Ereignis $event im Kalender und berechnet die Anzahl der verbleibenden Tage und legt sie im entsprechendem Reading $reading des DOIF-Moduls ab\
sub days \
{\
my ($event,$reading)=@_;;\
set_Reading($reading,fhem('get cal events timeFormat:"%j" filter:field(summary)=~"'.$event.'" limit:count=1,from=0 format:custom="$T1"')-::strftime ('%j', localtime()),1)\
}\
## Die Funktion 'update' bestimmt die verbleibenden Tage mit Hilfe der obigen Funktion 'days' für die jeweiligen Tonnen\
sub update\
{\
days("Altpapier","altpapier");;days("Restmüll","restmuell");;days("Bio","bio");;days("Gelber","gelbe_tonne");;days("Grünschnitt","gruenschnitt");;\
}\
}\
## Beim Start, um 02:00 Uhr und 08:00 Uhr wird zeitverzögert die obige Funktion 'update' aufgerufen\
init {[02:00];;[08:00];;set_Exec("Timer",60,'update()');;\
}
attr Abfall uiTable {\
package ui_Table;;\
$TC{0..4}="align='center'";;\
$SHOWNOSTATE=1;;\
\
## die Funktion 'ic' benutzt die Funktion 'icon_label' für die Darstellung des Icons, abhängig von der Anzahl der Tage wird die Anzahl in grün bzw. rot eingefärbt \
sub ic\
{\
my ($icon,$days)=@_;;\
icon_label($icon,$days,"white",$days > 1 ? "green":"red")\
}\
}\
## Tabellendefinition, die einzelnen Tonnen werden mit Hilfe der obigen Funkton 'ic' dargestellt\
\
ic ("Abfalltonne-Recycling-Logo\@yellow",[$SELF:gelbe_tonne])|\
ic ("Abfalltonne-Recycling-Logo\@blue",[$SELF:altpapier])|\
ic ("Abfalltonne\@gray",[$SELF:restmuell])|\
ic ("Abfalltonne-Recycling-Logo\@green",[$SELF:bio])|\
ic ("Gartenabfall\@green",[$SELF:gruenschnitt])
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Anwendungsbeispiel Abfall.png|mini|ohne]]

=== ''Visualisierung: '''offene Fenster''''' ===
Alle offenen Fenster werden aufgelistet und mit entsprechendem Icon visualisiert.
{{Randnotiz|RNText='''nützliche Links'''
* Attribut {{Link2CmdRef|Anker=DOIF_DOIF_Readings|Lang=de|Label=DOIF_Readings}}
* DOIF-{{Link2CmdRef|Anker=DOIF_aggregation|Lang=de|Label=Aggregationsfunktionen}}
* uiTable-Funktion [[DOIF/uiTable Schnelleinstieg#Icon-Darstellung mit Hilfe der Funktion icon|icon]]
}}
<syntaxhighlight lang="perl">
defmod di_uiTable_windows DOIF ## Visualisierung offener Fenster, Fenster-Devices enden mit "Fenster" im Namen
attr di_uiTable_windows DOIF_Readings windows:[@as( )"Fenster$":state:"open","keine"]
attr di_uiTable_windows uiTable {package ui_Table;;}\
icon([$SELF:windows],"fts_window_1w_open\@DarkOrange","fts_window_1w",".*","keine")|[$SELF:windows]
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable windows closed.png|mini|ohne]]
[[Datei:UiTable windows open.png|mini|ohne]]

=== ''Visualisierung: '''aktuelle Wetterlage''''' ===
Regenrader animiert, aktuelle Temperatur und Feuchte vom Sensor, aktuelle Wetterlage sowie Wettervorhersage der nächsten Tage. Über entsprechende Weblinks werden Bilder aus dem WWW in der Tabelle visualisiert. Im Gegensatz zu lokalen Sensoren, muss für die Aktualisierung der WWW-Elemente in der jeweiligen Webinstanz (FHEMWEB) das refresh-Attribut gesetzt werden.
{{Randnotiz|RNText='''nützliche Links'''
* DWD [https://www.dwd.de/DE/Home/home_node.html Homepage]
* Regenradar [https://www.dwd.de/DE/wetter/wetterundklima_vorort/_node.html Radarfilm BRD]
* aktuelles Wetter [https://www.dwd.de/DE/wetter/wetterundklima_vorort/nordrhein-westfalen/nrw_node.html NRW]
* Wetteronline [https://www.wetteronline.de/wetter-widget eignes Widget]
*
}}

<syntaxhighlight lang="perl">
defmod di_uiTable_wetter DOIF ##
attr di_uiTable_wetter uiTable {\
package ui_Table;;\
$TC{1}="align='center'";;\
}\
## das Attribut 'refresh' der Webinstanz für ein Wandtablet wurde auf 900 gesetzt, damit die Bilder alle 15 Minuten aktualisiert werden \
## Tabellendefinition\
\
## Regenradar BRD\
'<img src="https://www.dwd.de/DWD/wetter/radar/radfilm_brd_akt.gif" height="365px" width="365px">'|\
\
## Aktuelle Temperatur und Feuchtigkeit vom lokalen sensor\
temp([Aussensensor:temperature],40),hum ([Aussensensor:humidity],30),\
\
## aktuelle Wetterlage NRW\
"<img src ='https://www.dwd.de/DE/wetter/wetterundklima_vorort/nordrhein-westfalen/_functions/bildgalerie/wetter_aktuell.jpg?view=nasImage&nn=561200' height='255px' width='255px'>"|\
\
## Wettervorhersage\
"<iframe marginheight='0' marginwidth='0' scrolling='no' width='300' height='365' name='FC3' style='border:1px solid;;border-color:#00537f;;' src='https://api.wetteronline.de/wetterwidget?gid=x0677&modeid=FC3&seourl=juelich&locationname=Jülich&lang=de'></iframe>"\
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable wetter.png|600px|links]]
 

=== ''Visualisierung: '''Wetterstation''''' ===
Die vorgestellte Lösung funktioniert ohne Anmeldung beim Wetterdienst und ohne Nutzung von API.
Über den Wetterdienst: https://www.wunderground.com/ werden sehr viele private Wifi-Wetterstationen eingebunden. Das kann man sich zunutze machen, indem man zunächst in seiner Umgebung nach Wetterstationen des Dienstes sucht - oft findet man im Umkreis von wenigen Kilometern schon einige Stationen, die rege Wetterdaten liefern. Danach definiert man über HTTPMOD seine Station und visualisiert diese anschließend.

{{Randnotiz|RNText='''nützliche Links'''
* Wunderground [https://wunderground.com/ Homepage]
* svg-Funktion [https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card card]
* svg-Funktionen [https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#icon_ring-Funktionen icon_ring]
}}
Definition einer Station in der Nachbarschaft. <StationsID> muss gegen die korrekte Stationsnummer ersetzt werden.
<syntaxhighlight lang="perl">
defmod Wetter HTTPMOD https://www.wunderground.com/dashboard/pws/<StationsID>
attr Wetter enableControlSet 1
attr Wetter reading01Name Wind
attr Wetter reading01Regex wu-unit .{109}>(\d+\.\d)
attr Wetter reading02Name Windboeen
attr Wetter reading02Regex wu-unit-speed .{109}>(\d+\.\d)
attr Wetter reading03Name Windrichtung
attr Wetter reading03Regex (\d+)deg\).{84}Wind-Marker
attr Wetter reading04Name Regen
attr Wetter reading04Regex wu-unit-rainRate .{109}>(\d+\.\d\d)
attr Wetter reading05Name RegenGesamt
attr Wetter reading05Regex wu-unit-rain .{109}>(\d+\.\d\d)
attr Wetter reading06Name Temperatur
attr Wetter reading06Regex wu-unit-temperature .{127}>(\d+.\d)
attr Wetter reading07Name Feuchtigkeit
attr Wetter reading07Regex wu-unit-humidity .{109}>(\d\d)
attr Wetter reading08Name UV
attr Wetter reading08Regex UV<.{268}>(\d)
attr Wetter reading09Name Luftdruck
attr Wetter reading09Regex PRESSURE<.{285}>(\d+.\d+)
attr Wetter reading10Name TemperaturGefuehlt
attr Wetter reading10Regex wu-unit is-degree-visible .{109}>(\d+.\d)
attr Wetter reading11Name TaupunktTemp
attr Wetter reading11Regex DEWPOINT.{306}>(\d+.\d)
attr Wetter reading12Name Sonnenstrahlung
attr Wetter reading12Regex Solar radiation<.{549}>(\d+.\d+)
attr Wetter timeout 10
attr Wetter userReadings WindKm {sprintf("%1.1f",ReadingsVal($name,"Wind",0)*1.60934)},\
WindboeenKm {sprintf("%1.1f",ReadingsVal($name,"Windboeen",0)*1.60934)},\
WindrichtungGrad {ReadingsVal($name,"Windrichtung",0)-180},\
RegenMm {ReadingsVal($name,"Regen",0)*25.4},\
RegenGesamtMm {ReadingsVal($name,"RegenGesamt",0)*25.4},\
TemperaturC {sprintf("%1.1f",(ReadingsVal($name,"Temperatur",0)-32)*5/9)},\
TaupunktTempC {sprintf("%1.1f",(ReadingsVal($name,"TaupunktTemp",0)-32)*5/9)},\
LuftdruckHpa {sprintf("%d",ReadingsVal($name,"Luftdruck",0)*33.8639)},\
TemperaturGefuehltC {sprintf("%1.1f",(ReadingsVal($name,"TemperaturGefuehlt",0)-32)*5/9)}
</syntaxhighlight>

Nun erfolgt die Visualisierung der Daten.

<syntaxhighlight lang="perl">
defmod di_Wetter_ring DOIF ##
attr di_Wetter_ring uiTable {package ui_Table;;}\
\
icon_temp_hum_ring("temp_outside",[Wetter:TemperaturC],[Wetter:Feuchtigkeit],undef,undef,150)|\
icon_temp_ring ("temp_windchill",[Wetter:TemperaturGefuehltC],undef,undef,150) |\
icon_temp_ring ("temperature_humidity",[Wetter:TaupunktTempC],undef,undef,150) |\
icon_ring2([Wetter:WindKm] > 0 ? "wind".",1,0,0,".[Wetter:WindrichtungGrad]:"no_wind",[Wetter:WindKm],0,50,120,0,"km/h",150,undef,1,[Wetter:WindboeenKm],0,50,120,0,"km/h",undef,1) |\
icon_ring2("weather_rain_gauge",[Wetter:RegenMm],0,10,180,270,"mm/h",150,undef,1,[Wetter:RegenGesamtMm],0,50,180,270,"mm",undef,1)|\
icon_ring2("sani_solar",[Wetter:UV],0,10,100,30,"UV",150,undef,0,[Wetter:Sonnenstrahlung],0,1000,100,30,"Watt/m²",undef,0)|\
icon_ring ("weather_barometric_pressure",[Wetter:LuftdruckHpa],980,1047,0,120,"hPa",0,150)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable ringwetter.png|600px|links]]
 

Hier ein Beispiel der Visualisierung mit Verlauf der letzten drei Tage mit Hilfe der svg-Funktion '''card''':

<syntaxhighlight lang="perl">
defmod di_Wetter DOIF ##
attr di_Wetter icon weather_wind
attr di_Wetter uiTable {package ui_Table;;}\
## card ($collect,$header,$icon,$min,$max,$minColor,$maxColor,$unit,$func,$decfont,$size,$model,$lightness)\
\
card([Wetter:TemperaturC:col3d],"Außentemperatur","temp_outside",-10,60,undef,undef,"°C",\&temp_hue)|\
card([Wetter:TemperaturGefuehltC:col3d],"gefühlte Temperatur","temp_windchill",-10,60,undef,undef,"°C",\&temp_hue)|\
card([Wetter:TaupunktTempC:col3d],"Taupunkttemperatur","temperature_humidity",-10,60,undef,undef,"°C",\&temp_hue)|\
card([Wetter:Feuchtigkeit:col3d],"Außenfeuchtigkeit","temperature_humidity",0,100,undef,undef,"%",\&hum_hue)|\
card([Wetter:WindKm:col3d],"Wind",[Wetter:WindKm] > 0 ? "wind".",1,0,0,".[Wetter:WindrichtungGrad]:"no_wind",0,30,90,30,"km/h",undef,1)\
card([Wetter:WindboeenKm:col3d],"Windböen","weather_wind",0,30,90,30,"km/h",undef,1)|\
card([Wetter:RegenMm:col3d],"Regen","weather_rain_gauge",0,10,180,270,"mm/h")|\
card([Wetter:RegenGesamtMm:col3d],"Regengesamt","weather_rain_gauge",0,50,180,270,"mm")|\
##card([Wetter:UV:col3d],"UV-Strahlung","sani_solar",0,7,100,30,"UV",undef,0)|\
card([Wetter:Sonnenstrahlung:col3d],"Sonnenstrahlung","sani_solar",0,1000,30,90,"Watt/m²",undef,0)|\
card([Wetter:LuftdruckHpa:col3d],"Luftdruck","weather_barometric_pressure",980,1047,30,90,"hPa",undef,0)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable svgwetter.png|600px|links]]
 

Ohne Angabe der Überschrift (undef für $header setzen) lässt sich eine kompaktere Darstellung erzielen:

[[Datei:UiTable svgwetteroh.png|600px|links]]

 

=== ''Visualisierung: '''aktueller Spritpreis''''' ===
Der aktuelle Spritpreis einer Tankstelle wird ermittelt und mit seinem zeitlichen Verlauf visualisiert.
{{Randnotiz|RNText='''nützliche Links'''
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#ring-Funktionen|ring]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card|card]]
* Tankstelle bestimmen [https://www.clever-tanken.de/ Clever tanken]
* Modul [[HTTPMOD]]
}}

Zunächst wird ein HTTPMOD-Modul für den aktuellen Spritpreis definiert, dabei ist <Stations-ID> durch die ID der Tankstelle zu ersetzen.

<syntaxhighlight lang="perl">
defmod Tankstelle HTTPMOD http://www.clever-tanken.de/tankstelle_details/<Stations-ID> 300
attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)." ".ui_Table::ring(ReadingsVal("$name","SuperE5",0),1.10,1.60,120,0,"E5",90,undef,2)}
attr Tankstelle enableControlSet 1
attr Tankstelle event-on-change-reading .*
attr Tankstelle group Spritpreise
attr Tankstelle reading01Name Diesel
attr Tankstelle reading01Regex "current-price-1">(\d.\d{2})
attr Tankstelle reading02Name SuperE5
attr Tankstelle reading02Regex "current-price-2">(\d.\d{2})
attr Tankstelle room Spritpreise
attr Tankstelle timeout 10
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Di uiTable Tankstelle.png|ohne|mini]]

Visualisierung der Preisentwicklung der letzten 24 Stunden:

<syntaxhighlight lang="perl">
defmod sprit DOIF ##
attr sprit uiTable {package ui_Table;;}\
card([Tankstelle:Diesel:col24],"Diesel","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,1")\
card([Tankstelle:SuperE5:col24],"Super E5","fuel","1.10","1.60",120,0,"Super €",undef,"2",",,1")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Di uiTable sprit.png|ohne|mini]]

=== ''Visualisierung: '''aktuelle Corona-7-Tage-Inzidenz''''' ===
Die aktuellen Inzidenzwerte werden vom RKI ausgelesen und deren Verlauf visualisiert.

{{Randnotiz|RNText='''nützliche Links'''
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#ring-Funktionen|ring]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card|card]]
* Modul [[JsonMod]]
}}

Zunächst wird ein JsonMod Device für das Auslesen der Inzidenzzahlen definiert. Die gewünschten Regionen müssen für eigene Bedürfnisse angepasst werden.

<syntaxhighlight lang="perl">
defmod RKI7 JsonMod https://services7.arcgis.com/mOBPykOjAyBO2ZKk/arcgis/rest/services/RKI_Landkreisdaten/FeatureServer/0/query?where=1%3D1&outFields=last_update,cases7_per_100k,BEZ,BEM,GEN,BL,county&returnGeometry=false&outSR=4326&f=json
attr RKI7 readingList multi(jsonPath("\$.features[?(\@.attributes.GEN in ['Städteregion Aachen', 'Düren', 'Heinsberg'])]"), property('attributes.GEN'), sprintf('%.1f', property('attributes.cases7_per_100k')));;
</syntaxhighlight>

Visualisierung der Inzidenzzahlen der letzten sieben Tage:

<syntaxhighlight lang="perl">
defmod di_corona DOIF ##
attr di_corona uiTable {package ui_Table}\
card([RKI7:Duren:col1w],"Düren","coronavirus",0,200,120,0,"Fälle")|\
card([RKI7:Heinsberg:col1w],"Heinsberg","coronavirus",0,200,120,0,"Fälle")|\
card([RKI7:Stadteregion_Aachen:col1w],"Aachen","coronavirus",0,200,120,0,"Fälle")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:uiTable_Inzidenz.png|600px|links]]

 

=== '' Visualisierung und Steuerung: '''Heiztherme''''' ===
Im folgenden Beispiel wurde eine Heiztherme über einen ebus-Adapter in FHEM eingebunden. Die Heizungsdaten werden über MQTT ausgelesen und anschließend visualisiert. Die vorgestellten Visualisierungsbeispiele können ebenso im funktionslosen DOIF mit Hilfe des uiTable-Attriutes auf bereits existierende Readings des eigenen Systems angewendet werden.

{{Randnotiz|RNText='''nützliche Links'''
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#icon_ring-Funktionen|icon_ring]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card|card]]
* Commandref [https://fhem.de/commandref_DE.html#DOIF_Perl_Modus DOIF Perl-Modus]
* ebus-Adapter [https://ebusd.de/ ebusd]
* ebus-Wiki [[EBUS|ebus]]
}}

Definition eines MQTT2-Devices für die Kommunikation mit der Therme über einen ebus-Adapter.

Im diesem Fall wurde eine Vaillanttherme eingebunden, die meisten Readings wurden automatisch vom MQTT2-Server angelegt. Die Anbindung ist gerätespezifisch und unterscheidet sich je nach Gerättyp.

<syntaxhighlight lang="perl">
defmod vaillant MQTT2_DEVICE ebusd_bai
attr vaillant IODev MQTT2_FHEM_Server
attr vaillant devStateStyle style="text-align:left"
attr vaillant event-on-change-reading .*
attr vaillant group Ebus
attr vaillant icon sani_boiler_temp
attr vaillant jsonMap Status01_0_value:Vorlauf Status01_0_name:0\
Status01_1_value:Ruecklauf Status01_1_name:0\
Status01_2_value:Aussentemp Status01_2_name:0\
Status01_3_value:Warmwasser Status01_3_name:0\
Status01_4_value:WWSpeicher Status01_4_name:0\
Status01_5_value:Pumpenstatus Status01_5_name:0\
Flame_0_value:Flame Flame_0_name:0\
Storageloadpump_percent0_value:Storageloadpump\
FlowTempDesired_temp_value:VorlaufSoll\
Hc1HeatCurve_0_value:HeizKennlinie Hc1HeatCurve_0_name:0\
HolidayEndPeriod_hto_value:FerienEnde\
HolidayStartPeriod_hfrom_value:FerienBeginn\
PumpPower_0_value:PumpenLeistung PumpPower_0_name:0\
PrimaryCircuitFlowrate_uin100_value:Umlaufmenge\
z1DayTemp_tempv_value:TagSolltemp\
z1NightTemp_tempv_value:NachtSolltemp\
FanSpeed_0_value:LuefterDrehzahl FanSpeed_0_name:0\
WaterPressure_pressv_value:Wasserdruck\
z1OpMode_opmode_value:Heizmodus
attr vaillant model eBus_bai_jsonmap
attr vaillant readingList ebusd/bai/PumpHours:.* { json2nameValue($EVENT, 'PumpHours_', $JSONMAP) }\
ebusd/bai/WPPostrunTime:.* { json2nameValue($EVENT, 'WPPostrunTime_', $JSONMAP) }\
ebusd/bai/PowerValue:.* { json2nameValue($EVENT, 'PowerValue_', $JSONMAP) }\
ebusd/bai/StorageExitTemp:.* { json2nameValue($EVENT, 'StorageExitTemp_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/scan\x5c\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }\
ebusd/scan\x5c\x2e08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/global/uptime:.* uptime\
ebusd/global/signal:.* signal\
ebusd/scan\x5c\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\x5c\x2e15/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT, 'FanSpeed_', $JSONMAP) }\
ebusd/bai/PumpPower:.* { json2nameValue($EVENT, 'PumpPower_', $JSONMAP) }\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }\
ebusd/global/updatecheck:.* updatecheck\
ebusd/bai/DCFTimeDate:.* { json2nameValue($EVENT, 'DCFTimeDate_', $JSONMAP) }\
ebusd/bai/PumpPowerDesired:.* { json2nameValue($EVENT, 'PumpPowerDesired_', $JSONMAP) }\
ebusd/bai/HwcImpellorSwitch:.* { json2nameValue($EVENT, 'HwcImpellorSwitch_', $JSONMAP) }\
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT, 'ReturnTemp_', $JSONMAP) }\
ebusd/700/HwcStorageTempBottom:.* { json2nameValue($EVENT, 'HwcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/bai/FanPWMSum:.* { json2nameValue($EVENT, 'FanPWMSum_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HoursTillService:.* { json2nameValue($EVENT, 'HoursTillService_', $JSONMAP) }\
ebusd/bai/PumpHwcFlowNumber:.* { json2nameValue($EVENT, 'PumpHwcFlowNumber_', $JSONMAP) }\
ebusd/bai/WP:.* { json2nameValue($EVENT, 'WP_', $JSONMAP) }\
ebusd/700/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/bai/PrimaryCircuitFlowrate:.* { json2nameValue($EVENT, 'PrimaryCircuitFlowrate_', $JSONMAP) }\
ebusd/bai/Flame:.* { json2nameValue($EVENT, 'Flame_', $JSONMAP) }\
ebusd/bai/Storageloadpump:.* { json2nameValue($EVENT, 'Storageloadpump_', $JSONMAP) }\
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT, 'FlowTempDesired_', $JSONMAP) }\
ebusd/700/FrostOverRideTime:.* { json2nameValue($EVENT, 'FrostOverRideTime_', $JSONMAP) }\
ebusd/700/Hc1ActualFlowTempDesired:.* { json2nameValue($EVENT, 'Hc1ActualFlowTempDesired_', $JSONMAP) }\
ebusd/700/Hc1AutoOffMode:.* { json2nameValue($EVENT, 'Hc1AutoOffMode_', $JSONMAP) }\
ebusd/700/Hc1CircuitType:.* { json2nameValue($EVENT, 'Hc1CircuitType_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/HcStorageTempBottom:.* { json2nameValue($EVENT, 'HcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HcStorageTempTop:.* { json2nameValue($EVENT, 'HcStorageTempTop_', $JSONMAP) }\
ebusd/700/HolidayTemp:.* { json2nameValue($EVENT, 'HolidayTemp_', $JSONMAP) }\
ebusd/700/OpMode:.* { json2nameValue($EVENT, 'OpMode_', $JSONMAP) }\
ebusd/700/z1RoomTemp:.* { json2nameValue($EVENT, 'z1RoomTemp_', $JSONMAP) }\
ebusd/700/z1SFMode:.* { json2nameValue($EVENT, 'z1SFMode_', $JSONMAP) }\
ebusd/700/z1OpMode:.* { json2nameValue($EVENT, 'z1OpMode_', $JSONMAP) }\
ebusd/700/Time:.* { json2nameValue($EVENT, 'Time_', $JSONMAP) }\
ebusd/bai/EbusVoltage:.* { json2nameValue($EVENT, 'EbusVoltage_', $JSONMAP) }\
ebusd/bai/extWP:.* { json2nameValue($EVENT, 'extWP_', $JSONMAP) }\
ebusd/bai/FanStarts:.* { json2nameValue($EVENT, 'FanStarts_', $JSONMAP) }\
ebusd/700/z1NightTemp:.* { json2nameValue($EVENT, 'z1NightTemp_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/700/HolidayStartPeriod:.* { json2nameValue($EVENT, 'HolidayStartPeriod_', $JSONMAP) }\
ebusd/700/HolidayEndPeriod:.* { json2nameValue($EVENT, 'HolidayEndPeriod_', $JSONMAP) }\
ebusd/700/z1Timer.Monday:.* { json2nameValue($EVENT, 'z1Timer.Monday_', $JSONMAP) }\
ebusd/700/z1Timer.Tuesday:.* { json2nameValue($EVENT, 'z1Timer.Tuesday_', $JSONMAP) }\
ebusd/700/z1Timer.Wednesday:.* { json2nameValue($EVENT, 'z1Timer.Wednesday_', $JSONMAP) }\
ebusd/700/z1Timer.Thursday:.* { json2nameValue($EVENT, 'z1Timer.Thursday_', $JSONMAP) }\
ebusd/700/z1Timer.Friday:.* { json2nameValue($EVENT, 'z1Timer.Friday_', $JSONMAP) }\
ebusd/700/z1Timer.Sunday:.* { json2nameValue($EVENT, 'z1Timer.Sunday_', $JSONMAP) }\
ebusd/700/z1Timer.Saturday:.* { json2nameValue($EVENT, 'z1Timer.Saturday_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHc1:.* { json2nameValue($EVENT, 'PrEnergyCountHc1_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHwc1:.* { json2nameValue($EVENT, 'PrEnergyCountHwc1_', $JSONMAP) }\
ebusd/bai/PrEnergySumHc1:.* { json2nameValue($EVENT, 'PrEnergySumHc1_', $JSONMAP) }\
ebusd/bai/PrEnergySumHwc1:.* { json2nameValue($EVENT, 'PrEnergySumHwc1_', $JSONMAP) }\
ebusd/bai/FanHours:.* { json2nameValue($EVENT, 'FanHours_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HwcHours:.* { json2nameValue($EVENT, 'HwcHours_', $JSONMAP) }\
ebusd/bai/HcStarts:.* { json2nameValue($EVENT, 'HcStarts_', $JSONMAP) }\
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT, 'HwcStarts_', $JSONMAP) }
attr vaillant setList HeizKennlinie:selectnumbers,0,.1,2,1,lin ebusd/700/Hc1HeatCurve/set $EVTPART1\
TagSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1DayTemp/set $EVTPART1\
NachtSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1NightTemp/set $EVTPART1
</syntaxhighlight>

Definition eines DOIF-Devices zur Steuerung der Therme und Visualisierung der Daten. Es werden Readings und Befehle genutzt, die durch den MQTT2-Server der obigen Definition zur Verfügung gestellt werden. Einzelne Heizungswerte werden in bestimmten Intervallen über den publish-Befehl ausgelesen. Die Temperaturen der Zirkulation, des Vorlaufs und des Rücklaufs werden außerhalb der Therme mit 1-wire-Temperatursensoren über WLAN-ESP-Easy ausgelesen. Die Definition des Layouts über das Attribut uiTable ist unabhängig vom Auslesen der Werte, sie bezieht sich lediglich auf vorhandene Readings, die visualisiert werden sollen. Das Layout kann ebenso auf Readings aus anderen Devices der eigenen FHEM-Umgebung anpasst werden.

<syntaxhighlight lang="perl">
defmod di_vaillant DOIF ##{[+00:01];;foreach (qw(FanSpeed Flame PumpPower Storageloadpump PrimaryCircuitFlowrate FlowTempDesired PumpHours HcHours HcPumpStarts)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
\
{[+[1]:01];;foreach (qw(PrEnergySumHc1 PrEnergySumHwc1 HcHours HwcHours z1OpMode WaterPressure z1NightTemp z1DayTemp Hc1HeatCurve HwcLockTime HolidayStartPeriod HolidayEndPeriod)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}\
}\
\
{[+00:00:30];;foreach (qw(Flame PrimaryCircuitFlowrate)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
\
{[00:01];;foreach (qw(FanHours HcStarts HwcStarts )) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}\
set_Reading("gesamt_hc",int([?vaillant:PrEnergySumHc1_0_value]/10000)/10,0);;\
set_Reading("gesamt_hwc",int([?vaillant:PrEnergySumHwc1_0_value]/10000)/10,0);;\
set_Reading("diff_hc",0,1);;\
set_Reading("diff_hwc",0,1);;\
set_Reading("diff_h",0,1)\
}\
\
{if ([00:05|WE]) {fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayStartPeriod/set $mday.$month.$year");;fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayEndPeriod/set $mday.$month.$year")}}\
\
Timer {\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Monday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Tuesday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Wednesday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Thursday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Friday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Sunday/set 05:00;;10:00;;12:00;;22:30;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Saturday/set 05:00;;10:00;;12:00;;22:30;;-:-;;-:-"\
}\
\
diff {\
set_Reading("diff_hc",int(([vaillant:PrEnergySumHc1_0_value]/100000-get_Reading("gesamt_hc",0))*10)/10,1);;\
set_Reading("diff_hwc",int(([vaillant:PrEnergySumHwc1_0_value]/100000-get_Reading("gesamt_hwc",0))*10)/10,1);;\
set_Reading("diff_h",get_Reading("diff_hc")+get_Reading("diff_hwc"),1);;\
}\
\

attr di_vaillant event-on-change-reading .*
attr di_vaillant room Ebus
attr di_vaillant uiTable {\
package ui_Table;;\
$TABLE='text-align:center;;';;\
$SHOWNODEVICELINE = "test9|Damian";;\
}\
icon_temp_ring("temp_outside",[vaillant:Aussentemp],-15,40,130)|\
icon_temp_mring(([vaillant:Flame] eq "off"?"sani_boiler_temp\@white":"sani_boiler_temp\@Darkorange"),[vaillant:Vorlauf],15,70,130)|\
icon_temp_mring(([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),[vaillant:WWSpeicher],15,70,130)|\
icon_uring("0,0,1","weather_barometric_pressure",[vaillant:Wasserdruck],0,3,undef,undef,"bar",1,130,[(0.8,0,1,60,1.5,120,1.7,60,3,0)],"50,35")|\
icon_ring("sani_floor_heating_neutral",[vaillant:HcHours_hoursum2_value],0,10000,120,0,"h",0,130)|\
icon_ring("sani_water_tap",[vaillant:HwcHours_hoursum2_value],0,2000,120,0,"h",0,130)|\
\
icon_ring("time_graph",[vaillant:HeizKennlinie],0.4,1,120,0,"HK",1,130)|\
icon_temp_mring("scene_day\@yellow",[vaillant:TagSolltemp],undef,undef,130)|\
icon_temp_mring("scene_night\@#3464eb",[vaillant:NachtSolltemp],undef,undef,130)\
""|""|""|""|""|""|widget([vaillant:HeizKennlinie],"selectnumbers,0.4,.1,1,1,lin","set")|widget([vaillant:TagSolltemp],"selectnumbers,15,1,25,1,lin","set")|widget([vaillant:NachtSolltemp],"selectnumbers,15,1,25,1,lin","set")<\
\
card([vaillant:Aussentemp:col],"Außentemperatur","temp_outside",-15,35,undef,undef,"°C",\&temp_hue)|\
card([vaillant:WWSpeicher:col],"WW-Speicher",([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),15,70,undef,undef,"°C",\&temp_hue)|\
card([ESPEasy_ESP_Temp_Vorlauf:Temperature:col],"Vorlauf",([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),15,70,undef,undef,"°C",\&temp_hue)|\
card([$SELF:diff_hc:col],"Energie Heizung","sani_floor_heating_neutral",0,100,120,0,"kWh",undef,1)\
card([vaillant:Umlaufmenge:col],"Umlaufmenge","sani_pump",0,20,120,0,"l/min")|\
card([ESPEasy_ESP_Temp_Zirkulation:Temperature:col],"Zirkulation",([Zirk] eq "off"?"sani_pump\@white":"sani_pump\@Darkorange"),15,70,undef,undef,"°C",\&temp_hue)|\
card([ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature:col],"Rücklauf","sani_floor_heating_neutral\@wite",15,70,undef,undef,"°C",\&temp_hue)|\
card([$SELF:diff_hwc:col],"Energie Warmwasser","sani_water_tap",0,15,120,0,"kWh",undef,1)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Di uiTable Heizung.png|600px|links]]

 

=== ''Visualisierung: '''Anwesenheitsstatus''''' ===
Die aktuelle Anwesenheit von Heimbewohnern wird visualisiert. 
Zunächst wird mit Hilfe des Moduls [[FRITZBOX]] ein Device namens ''FritzBox'' erstellt. Dort werden die eingebuchten Smartphones der Bewohner mit Ihren MAC-Adressen in Readings abgelegt. Die folgende Definition wertet aus, ob die angegebenen MAC-Adressen als Readings vorhanden sind und erstellt für jeden Bewohner ein Reading mit den Zuständen on/off. Diese Readings werden dann über das Attribut uiTable visualisiert. Die anwesenden Personen werden farblich markiert. Die Namen der Personen sowie die MAC-Adressen sind fiktiv und müssen den eigenen Angaben entsprechend angepasst werden.
{{Randnotiz|RNText='''nützliche Links'''
* [[FRITZBOX|FritzBox-Modul]]
* ui_Table Funktion [[DOIF/uiTable Schnelleinstieg#Icon-Darstellung mit Text mit Hilfe der Funktion icon_label|icon_label]]
*[[DOIF/uiTable Schnelleinstieg#uiTable-Templates|uiTable-Templates]]
}}

<syntaxhighlight lang="perl">
defmod myHome DOIF {\
set_Reading_Begin;;\
set_Reading_Update("Ernie",[FritzBox:mac_12_34_E0_00_CD_E4] ? "on":"off");;\
set_Reading_Update("Bert", [FritzBox:mac_02_08_02_07_30_E3] ? "on":"off");;\
set_Reading_Update("Grobi", [FritzBox:mac_00_08_01_0B_00_E7] ? "on":"off");; \
set_Reading_Update("Kermit", [FritzBox:mac_01_30_A9_72_02_E3] ? "on":"off");; \
set_Reading_End(1);;\
}
attr myHome checkReadingEvent 0
attr myHome uiTable {\
package ui_Table;;\
$SHOWNOSTATE=1;;\
$TC{0..4}="align='center'";;\
}\
## Template-Definition für die Visualisierung eines Bewohners mit Hilfe des Icons fa__508\
DEF TPL_person (icon_label([$SELF:$1] eq "on" ? "fa__508\@DarkOrange":"fa__508","$1","#e67e00","white",-10))\
\
## Darstellung der Bewohner mit Hilfe des obigen Templates\
TPL_person(Ernie)|TPL_person(Bert)|TPL_person(Grobi)|TPL_person(Kermit)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable myHome.png|ohne|mini]]

=== Weitere Anwendungsbeispiele zur Automatisierung ===
* siehe [[DOIF/Automatisierung]]

== Weiterführende Links ==
* Weitere Beispiele für Fortgeschrittene, siehe "[[DOIF/uiTable|uiTable mit FHEM-Widgets und Styles]]"

[[Kategorie:HOWTOS]]
[[Kategorie:Code Snippets]]

DOIF/uiTable Schnelleinstieg

2022-02-19T22:30:08Z

Maista: Eine Klammer fehlte

[[Datei:UiTable state screen.png|700px|rechts|Webansicht bestehend aus mehreren DOIF/uiTable-Definitionen]]
An dieser Stelle wird das DOIF-Web-Interface erklärt, welches über das DOIF-Attribut '''uiTable''' realisiert wurde.

Abhängig von der Art der Funktion können in einer tabellarischen Darstellung FHEM-Geräte visualisiert und über die Web-Oberfläche bedient werden. Eventbasierte Änderungen visualisierter Readings werden unmittelbar in der Web-Ansicht aktualisiert. Eine erstellte Tabelle erscheint unterhalb der Statuszeile eines DOIF-Devices. Das uiTable-Attribut kann in bereits bestehenden DOIFs oder in funktionslosen DOIFs, wie in den unteren Beispielen, als reines WEB-Interface erstellt werden. In der Abbildung rechts ist ein Statusbildschirm aus vier Spalten mit mehreren DOIF/uiTable-Definitionen aufgebaut worden. 

Die Darstellungsmöglichkeiten werden anhand von Beispielen insb. mit Hilfe bereits im DOIF-Modul vordefinierter uiTable-Funktionen aufgezeigt. Diese Perlfunktionen sind in einem eigenen Package namens 'ui_Table' definiert worden. Mit Hilfe dieser Funktionen lassen sich recht einfach, ohne tiefere HTML/CSS-Kenntnisse, eigene Übersichten definieren. Im Anschluss werden typische '''[[DOIF/uiTable Schnelleinstieg#Anwendungsbeispiele|Anwendungsbeispiele]]''' aufgezeigt.

Die folgenden Beispieldefinitionen arbeiten mit konkreten Geräten und Readings, sie können als RAW-Definition ins eigene System übernommen werden, dazu müssen die Gerätenamen, Readings, ggf. auch Icons den existierenden Namen des eigenen Systems angepasst werden. Zum Ausprobieren der Beispiele können statt echter Geräte auch Dummys benutzt werden.

Es gibt im Perl-Modus des DOIF-Moduls ebenfalls das Attribut '''uiState''', welches die gleiche Syntax wie uiTable nutzt. Die definierte Tabelle erscheint im Gegensatz zu uiTable jedoch im Status des DOIF-Devices. uiState und uiTable können gleichzeitig in einem DOIF-Device definiert werden.

== Aufbau des uiTable-Attributs ==
Im uiTable-Attribut wird in erster Linie die zu visualisierende Tabelle definiert. Optional können zuvor ein Perlblock sowie Templates definiert werden.
{{Randnotiz|RNText='''Aufbau des Attributs'''
* das uiTable-Attribut besteht aus drei Bereichen:
* [[DOIF/uiTable Schnelleinstieg#Der Perlblock|Perlblock]]
* [[DOIF/uiTable Schnelleinstieg#uiTable-Templates|Templates-Definitionen]]
* [[DOIF/uiTable Schnelleinstieg#Die Tabellendefinition|Tabellendefinition]]
}}
'''Aufbaustruktur'''
<syntaxhighlight lang="perl">
{
<Perlblock, optional>
}

<Templates-Definitionen, optional>

<Tabellendefinition>
</syntaxhighlight>
=== Der Perlblock ===
Der Perlblock dient dazu, das Layout der Tabelle zu beeinflussen sowie eigene uiTable-Funktionen zu definieren. Hier wird insb. das Package definiert, welches für die Tabellendefinition gilt. Ebenfalls können CSS-Variablen sowie Steuerungsattribute gesetzt werden. Der Perlblock beginnt und endet mit einer geschweiften Klammer.

==== CSS-Variablen und Steuerungsattribute ====
Mit Hilfe von CSS-Variablen kann das Layout der Tabelle beeinflusst werden. Die Steuerungsattribute beeinflussen die Statuszeile sowie die Detailansicht des DOIF-Moduls.
{{Randnotiz|RNText='''CSS-Variablen und Steuerungsattribute'''
*Das Layout der gesamten Tabelle wird beeinflusst über die Variablendefinition: '''$TABLE="<CSS-Attribute der Tabelle>"'''
*Spaltenformatierungen werden beeinflusst mit Hilfe der Variablendefinition: '''$TC{<Zellenbereich für Spalten>}="<CSS-Attribute der Spalten>"'''
*Zeilenformatierungen werden beeinflusst mit Hilfe der Variablendefinition: '''$TR{Zeilenbereich}="<CSS-Attribute der Zeilen>"'''
*einzelne Zellen werden beeinflusst mit Hilfe der Variablen: '''$TD{<Zellenbereich für Zeilen>}{<Zellenbereich für Spalten>}="<CSS-Attribute der Zellen>"'''
*für Zellen-, Spalten- und Zeilen-Bereich gilt: '''<Zahl><nowiki>|</nowiki><kommagetrennte Aufzählung><nowiki>|</nowiki><Bereich von..bis>'''
*Der Status in der Statuszeile des DOIFs wird ausgeblendet mit '''$SHOWNOSTATE=1'''
*Die Gerätezeile des DOIFs wird ausgeblendet mit '''$SHOWNODEVICELINE = "<regex room>"'''
*Die Tabelle des DOIFs wird ausgeblendet mit '''$SHOWNOUITABLE = "<regex room>"'''
*Die Detailansicht wird umorganisiert mit '''$ATTRIBUTESFIRST=1'''
}}
'''Bespieldefinition'''
<syntaxhighlight lang="perl">
defmod di_bsp_layout DOIF ##
attr di_bsp_layout uiTable { ## Beginn des Perlblocks\
## CSS-Variablen\
\
## Die Tabelle soll ein Hintergrundbild der Größe 300x300 Pixel haben\
$TABLE = "width:300px;; height:300px;; background-image:url(/fhem/www/pgm2/images/Grundriss.png);; background-size: 300px 300px;;";;\
\
## die Zelle der ersten Zeile und der ersten Spalte soll rechts eine Rahmenlinie haben\
$TD{0}{0} = "style='border-right-style:solid;; border-right-width:10px'";;\
\
## Die erste Zeile soll aus der Klasse 'odd' sein und fett-Schrift haben\
$TR{0} = "class='odd' style='font-weight:bold'";;\
\
## die Spalten 2 bis 6 sollen zentriert sein\
$TC{1..5} = "align='center'";;\
\
## die Spalten 2, 4 und 5 sollen zentriert sein\
$TC{1,3,5} = "align='center'";;\
\
## die letzte Spalte der Tabelle soll fett sein\
$TC{last} = "style='font-weight:bold'";;\
\
\## Steuerungsattribute\
\
\## Ausblenden des Status in der Statuszeile\
$SHOWNOSTATE=1;;\
\
## Die Gerätezeile wird ausgeblendet in allen Räumen\
$SHOWNODEVICELINE = ".*";;\
\
## Die Tabelle wird im Raum info ausgeblendet\
$SHOWNOUITABLE = "^info$";;\
\
## Die Detailansicht wird umorganisiert, hilfreich beim Editieren längerer uiTable-Definitionen\
$ATTRIBUTESFIRST = 1;;\
} ## Ende des Perlblocks
</syntaxhighlight>

=== Die Tabellendefinition ===
==== Einfache Tabellendefinition ohne Funktionen ====
{{Randnotiz|RNText='''Tabellendefinition'''
* eine Tabelle wird aus Zellen zusammengebaut
* mehrere Zellen werden mit <nowiki>|</nowiki> von einander getrennt, sie bilden eine Tabellenzeile
* eine neue Tabellenzeile beginnt mit einer neuen Zeile in der Tabellendefinition
* eine Tabellenzeile kann auch in mehreren Zeilen definiert werden, diese müssen dann mit <nowiki>|</nowiki> enden
* Texte werden in Anführungszeichen angegeben
* Readings werden in der Form [<device>:<reading>] angegeben
* Kommentare beginnen mit ## und enden mit Zeilenende
* Events eines definierten Readings, führen sofort zu Aktualisierung seines Inhalts in der visualisierten Tabelle
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_definition DOIF ##
attr ui_Table_definition uiTable { ## Perlblock für globale Tabellendefinitionen\
\
$TC{1..2}="align='center'" ## zentrierte Ausrichtung der zweiten und dritten Spalte\
\
}\
\
## Tabellendefinition\
\
"Warmwasser"|"Vorlauf"|"Rücklauf" ## erste Tabellenzeile\
## zweite Tabellenzeile\
[T_Warmwasserspeicher:temperature]| ## Zeile wird fortgesetzt, da sie mit | endet\
[T_Vorlauf:temperature]| ## Zeile wird fortgesetzt, da sie mit | endet\
[T_Ruecklauf:temperature]
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable Definition.png|mini|ohne]]

==== Tabellendefinition mit Berechnungen ====
{{Randnotiz|RNText='''Zellenauswertung'''
* jede Zelle der Tabelle wird über Perl ausgewertet
* Readingangaben der Form [<device>:<reading>] werden in eine Perlfunktion übersetzt
* das Ergebnis des ausgewerteten Perlausdrucks wird ausgegeben
* in einer Zelle können beliebige Perlfunktionen genutzt werden
* Texte oder Funktionen können mit Punkt aneinander gehängt werden
* mit Komma werden Texte oder Werte untereinander dargestellt
* wird eine Zeile mit < abgeschlossen, so wird die aktuelle Tabelle abgeschlossen, die nächste Zeile beginnt in einer neuen Tabelle
* in einer Berechnung sollte ein Trigger in Form einer Readingangabe [<device>:<reading>] vorkommen, sonst wäre das Ergebnis statisch und würde sich nicht ändern
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_calc DOIF ##
attr di_uiTable_calc uiTable ## Tabellendefinition\
"Differenz"|[T_Ruecklauf:temperature]-[T_Vorlauf:temperature]\
"Minimum"|minNum([TH_WZ_HM:measured-temp],[TH_Keller_HM:measured-temp])\
"Durchschnitt"|([T_Ruecklauf:temperature]+[T_Vorlauf:temperature])/2
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable calc.png|mini|ohne]]

== Vordefinierte uiTable-Funktionen ==
Typische Widgets bzw. Styles wurden als Perl-Funktionen im package ui_Table für eine einfache Tabellendefinition programmiert. Im folgenden wird näher auf die einzelnen uiTable-Funktionen eingegangen.

=== FHEM-Widgets mit der Funktion '''widget''' ===
Alle in FHEM vorhanden Widgets können mit Hilfe der Perlfunktion '''widget''' genutzt werden. Bei häufiger Nutzung eines bestimmten Widgets bietet sich alternativ die Definition einer uiTable-Funktion (Typ 3) mit dem jeweiligen Widget an, siehe: [[DOIF/uiTable Schnelleinstieg#Eigene uiTable-Funktionen programmieren|uiTable-Funktion]]
{{Randnotiz|RNText=Funktion '''widget'''
<syntaxhighlight lang="perl">
widget(<Reading>,$fhem_widget,$set)

Reading # [<device>:<reading>]
$fhem_widget # Angabe des FHEM-Widgets
$set # optional, undef zum Setzen beliebiger Readings (entspricht setreading), "set" wenn das Reading per set-Befehl gesetzt wird (siehe Attribut ReadingList), "set <Befehl>", wenn sich der Befehl vom Reading unterscheidet, default undef
</syntaxhighlight>

'''nützliche Links'''
* [[FHEMWEB/Widgets|Fhem-Widgets]]
* Fhem-Widgets als [[DOIF/uiTable Schnelleinstieg#Eigene uiTable-Funktionen programmieren|uiTable-Funktion]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_widget DOIF ##
attr di_uiTable_widget uiTable ## FHEM-Widgets mit Hilfe der WID-Funktion\
{package ui_Table}\
"Widget"\
"Select"| widget([uhr:wochentag],"select,Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag")\
"Selectnumbers"| widget([motor:spannung],"selectnumbers,0,0.5,12,1,lin")\
"Slider"| widget([bla:wert],"slider,0,5,100,1")\
"Colorpicker RGB"| widget([Lampe:farbe],"colorpicker,RGB")\
"Colorpicker HSV"| widget([Lampe:farbe],"colorpicker,HSV")\
"Colorpicker CT"| widget([Lampe:waerme],"colorpicker,CT,2000,10,6500")\
"Colorpicker HUE"| widget([Lampe:farbe],"colorpicker,HUE,0,1,359")\
"Colorpicker BRI"| widget([Lampe:helligkeit],"colorpicker,BRI,0,1,100")\
"Time"| widget([start:zeit],"time")\
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable WID.png|mini|ohne]]

=== SVG-uiTable-Funktionen ===
SVG-uiTable-Funktionen sind skalierbare Widgets, die auf SVG-Elementen basieren. Bei allen SVG-Funktionen für Temperatur bzw. Feuchtigkeit wird die Einfärbung abhängig vom Temperatur- bzw. Feuchtigkeitswert mit Hilfe einer Zuordnungsfunktion bestimmt.

==== '''ring'''-Funktionen ====
===== Farbskalierte Temperaturanzeige mit Hilfe der SVG-Funktionen '''temp_ring/temp_mring''' =====
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''temp_mring'''-SVG-Funktion wird der Ring einfarbig dargestellt.

Farbskalierung der '''temp_ring'''-SVG-Funktion:
[[Datei:Farbskalierung temp_ring_scaling.png|600px|ohne]]

Farbskalierung der '''temp_mring'''-SVG-Funktion:
[[Datei:Farbskalierung temp_mring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_ring/temp_mring'''
<syntaxhighlight lang="perl">
temp_ring/temp_mring ($temp_value,$temp_min,$temp_max,$sizeHalf, $lightring,$lightnumber,$decFont)

$temp_value # Temperatur
$temp_min, # minimale Temperatur, optional, default=-20
$temp_max, # maximale Temperatur, optional, default=60
$sizeHalf # "<size>,<half ring>" size: Größe der Grafik, optional, default = 80, half ring: 1 für Halbring
$lightring, # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_ring DOIF ##
attr di_temp_ring uiTable {package ui_Table}\
"außen (standard)"|temp_ring([Aussensensor:temperature])\
"Warmwasser (größer,aufgehellt,Normalschrift)" |temp_mring([vaillant:WWSpeicher],15,70,110,90,100,"1,font-weight:normal")\
"Vorlauf (größer)"| temp_mring([ESPEasy_ESP_Temp_Vorlauf:Temperature],15,45,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_ring_bsp.png|ohne|mini]]

===== Farbskalierte Feuchtigkeitsanzeige mit Hilfe der SVG-Funktionen '''hum_ring/hum_mring''' =====
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''hum_mring'''-SVG-Funktion wird der Ring einfarbig dargestellt.

Farbskalierung der '''hum_ring'''-SVG-Funktion:
[[Datei:Farbskalierung hum_ring_scaling.png|600px|ohne]]

Farbskalierung der '''hum_mring'''-SVG-Funktion:
[[Datei:Farbskalierung hum_mring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''hum_ring/hum_mring'''
<syntaxhighlight lang="perl">
hum_ring/hum_mring ($hum_value,$sizeHalf,$lightring,$lightnumber,$decFont)
$hum_value # Feuchtigkeit
$sizeHalf # "<size>,<half ring>" size: Größe der Grafik, optional, default = 80, half ring: 1 für Halbring
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_hum_ring DOIF ##
attr di_hum_ring room test2
attr di_hum_ring uiTable {package ui_Table}\
"klein ohne Farbverlauf"|hum_mring([Aussensensor:humidity],60)\
"normal groß mit Farbverlauf"|hum_ring([Aussensensor:humidity])\
"groß ohne Farbverlauf aufgehellt"|hum_mring([Aussensensor:humidity],100,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:hum_ring_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Zahlenwertes mit Hilfe der universellen SVG-Funktion '''ring''' =====
Die Farbe des dargestellten Wertes kann abhängig vom Wert bestimmt werden. Dabei wird die Farbe mit Anleihen aus dem [https://de.wikipedia.org/wiki/HSV-Farbraum HSV-Farbraum] bestimmt. Dieser Farbraum benötigt eigentlich drei Werte, wobei die erste den Farbton (hue) bestimmt; hier wird nur dieser Wert verwendet (Sättigung und Hellwert sind nicht einstellbar). Der Farbton geht von rot (hue-Wert = 0) über gelb (hue-Wert = 60), dann grün (hue-Wert = 120) und blau (hue-Wert = 240) zurück zu rot (hue-Wert = 360), siehe dazu auch die [https://de.wikipedia.org/wiki/HSV-Farbraum#/media/Datei:HueScale.svg Farbtontafel] auf der Wikipedia-Seite.
Die unten $colorRef genannte Funktion kann zum Beispiel in der Tabelle selbst definiert werden, beispielsweise kann man in dem device &onoff_hue verwenden, wenn man es vorab definiert (siehe [https://forum.fhem.de/index.php/topic,120088.msg1204341.html#msg1204341 Link zum Forum]):<blockquote><syntaxhighlight lang="perl">
attr <ui device Name> {
package ui_Table;
sub onoff_hue {
my($irgendeinVariablenname)=@_;
return ($irgendeinVariablenname == 0 ? 240 : 0);
}
## Tabellendefinition
...
}
</syntaxhighlight></blockquote>{{Randnotiz|RNText=SVG-uiTable-Funktion '''ring'''
<syntaxhighlight lang="perl">
ring ($value,$min,$max,$minColor,$maxColor,$unit, $sizeHalf,$colorRef,$decFont,$model,$lightness)

$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$sizeHalf # "<size>,<half ring>" size: Größe der Grafik, optional, default = 100, half ring: 1 für Halbring
$colorRef # Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$model # '<Farbverlauf>,<Min/Max>,<Innenring>,<Zeigerstärke>,<Modus>',
# Farbverlauf: 1 für monochrom,
# Min/Max: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte,
# Innenring: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes, Zeigerstärke: in Pixel,
# Zeigerstärke: Breite des Zeigers,
# Modus: 0 Standard Min-Max, 1 Min-Null-Max, 2 Null-Min/Max,
# alle Parameter sind optional, default keine Angaben: ',,,,,'
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>", optional, default: "50,50,50,40,50"
</syntaxhighlight>
Wird '''$colorFunc''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_ring DOIF (1)
attr di_ring room test20,test5
attr di_ring uiTable {package ui_Table;; \
$SHOWNOSTATE=1}\
## von 0 bis 20 in Farben von grün (hue:120) bis rot (hue:0)\
"Umlaufmenge"|ring([heating:pump],0,20,120,0,"l/min",100)\
\
## von 0 bis 3 in Farben von rot (hue:0) bis türkis (hue:180), eine Nachkommastelle, Schriftgröße 170%\
## Innenring mit Min-, Max-Beschriftung\
"Wasserdruck"|ring([heating:pressure],0,3,0,180,"bar",100,undef,"1,font-size:170%,fill:silver;;font-size:50%","0,1,1")\
\
## Temperaturdarstellung, entspricht dem Funktionsaufruf:\
## temp_ring ([outdoor:temperature],-20,60,100,"1,font-weight:normal;;font-size:140%")\
## Eine Nachkommastelle, Normalschrift, Schriftgröße 140%\
"Temperatur"|ring([outdoor:temperature,-20,60,undef,undef,"°C",100,\&temp_hue,"1,font-weight:normal;;font-size:140%")\
\
## Lufdruck als Halbring\
"Luftdruck"|ring([weather:barometer],970,1045,30,90,"hPa","100,1",undef,0)\
\
## Co2 als Halbring, Farbgebung als Array mit drei Bereichen, Innenring mit Zeiger\
"Co2"|ring([livingroom:co2],400,1200,undef,undef,'ppm',"100,1",[(600,120,1000,60,1200,0)],0,'0,0,1,5')
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:ring_bsp.png|ohne|mini]]

===== Farbskalierte Temperatur- und Feuchtigkeitsanzeige mit Hilfe der SVG-Funktion '''temp_hum_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperatur- bzw. Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar:
[[Datei:Farbskalierung temp_hum_ring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_hum_ring'''
<syntaxhighlight lang="perl">
temp_hum_ring ($temp_value,$hum_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp,$decFontHum)

$temp_value # Temperatur
$hum_value # Feuchtigkeit
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp # Temperatur: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontHum # Feuchtigkeit: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_hum_ring DOIF ##
attr di_temp_hum_ring uiTable {package ui_Table}\
\
"klein"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity],undef,undef,60)\
"normal"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity])\
"größer, aufgehellt"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity],undef,undef,100,undef,80)\
"größer, Ring aufgehellt, Normalschrift"|temp_hum_ring([Aussensensor:temperature],[Aussensensor:humidity],undef,undef,100,80,50,"1,font-weight:normal","0,font-weight:normal")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_hum_ring_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Temperaturwerten mit Hilfe der SVG-Funktion '''temp_temp_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar:
[[Datei:Farbskalierung temp_temp_ring_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_temp_ring'''
<syntaxhighlight lang="perl">
temp_temp_ring ($temp1_value,$temp2_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp1,$decFontTemp2)

$temp1_value # erster Temperaturwert
$temp2_value # zweiter Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp1 # Temperatur1: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontTemp2 # Temperatur2: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_temp_ring DOIF ##
attr di_temp_temp_ring uiTable {package ui_Table}\
"klein, Ring augehellt"|temp_temp_ring([Vorlauf:Temperature],[Ruecklauf:Temperature],15,60,60,80,50)\
"normal"|temp_temp_ring([Vorlauf:Temperature],[Ruecklauf:Temperature],15,60)\
"groß, Zahlen aufgehellt"|temp_temp_ring([Vorlauf:Temperature],[Ruecklauf:Temperature],15,60,100,undef,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_hum_temp_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Zahlenwerten mit Hilfe der universellen SVG-Funktion '''ring2''' =====
Die Farbe der dargestellten Werte kann abhängig vom Wert bestimmt werden.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''ring2'''
<syntaxhighlight lang="perl">
ring2 ($value1,$min1,$max1,$minColor1,$maxColor1,$unit1,$size,$colorFunc1,$decFont1,
$value2,$min2,$max2,$minColor2,$maxColor2,$unit2,$colorFunc2,$decFont2,
$lightness,$icon,$model)

$value1 # darzustellender Wert1
$min1 # minimaler Wert, optional, default=0
$max1 # maximaler Wert, optional, default=100
$minColor1 # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor1 # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit1 # Einheit des Wertes, optional, default = undef
$size # Größe der Grafik, optional, default = 100
$colorFunc1 # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont1 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$value2 # darzustellender Wert2
...
$decFont2 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"
$model # '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>',
# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'

Argumente für den zweiten Wert entsprechend den Argumenten des ersten Wertes
</syntaxhighlight>
Wird '''$colorFunc...''' nicht angegeben, so wird der Farbwert zwischen '''$minColor...''' und '''$maxColor...''' linear interpoliert
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_ring2 DOIF ##
attr di_ring2 uiTable {package ui_Table;;}\
## Leistungsaufnahme von 0 kW bis 3,6 kW in Farben von grün (hue:120) bis rot (hue:0)\
## Kapazität von 0 % bis 100 % V in Farben von rot (hue:0) bis grün (hue:120)\
"Wallbox"| ring2([tesla:Leistung],0,3.6,120,0,"kW",undef,undef,"1,font-weight:normal",[tesla:Kapazitaet],0,100,0,120,"%",undef,"0,font-weight:normal")\
\
## Stromstärke von 0 A bis 2 A in Farben von grün (hue:120) bis rot (hue:0)\
## Spannung von 1 V bis 1.5 V in Farben von rot (hue:0) bis grün (hue:120)\
## 3 Nachkommastellen, Normalschrift, Schriftgröße 80% \
"Akku"| ring2([akku:Strom],0,2,120,0,"A",undef,undef,"3,font-weight:normal;;font-size:80%",[akku:Spannung],1,1.5,0,120,"V",undef,"3,font-weight:normal;;font-size:80%")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:ring2_bsp.png|ohne|mini]]

'''<big>Beispieldefinition Innenring, Farb-Array, Ringmodi</big>'''
<syntaxhighlight lang="perl">
defmod di_solar DOIF {}
attr di_solar uiTable {package ui_Table}\
"Farb-Array, ringMode 1"|\
ring2([zaehler:Produktion],-20,30,undef,undef,"PV kWh",130,[(-10,0,-0.001,30,10,60,30,90)],"2",[test:Bezug],-20,30,undef,undef,"Bezug",[(-10,0,-0.001,30,10,60,30,90)],"2",undef,undef,"0,1,1,0,1")\
"Farbe linear, ringMode 1"|\
ring2([zeahler:Produktion],-20,30,0,120,"PV kWh",130,undef,"2",[test:Bezug],-20,30,0,120,"Bezug",undef,"2",undef,undef,"0,1,1,0,1")\
"Farbe linear, ringMode 2"|\
ring2([zaehler:Produktion],0,30,60,120,"PV kWh",130,undef,"2",[test:Bezug],-20,0,0,120,"Bezug",undef,"2",undef,undef,"0,,,0,2")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:ring2_ringMode.png|ohne|mini]]

 

==== '''icon_ring'''-Funktionen ====
===== Farbskalierte Temperaturanzeige mit einem Icon mit Hilfe der SVG-Funktionen '''icon_temp_ring/icon_temp_mring''' =====
Diese Funktionen basieren auf den obigen temp_ring-Funktionen, zusätzlich wird ein SVG-Icon dargestellt. Die Farbe des Icons kann mit @ an den Iconnamen angehängt werden, ansonsten wird die Farbe der Temperatur für das Icon verwendet. Die Größe des Icons kann skaliert werden, ebenso kann die Positionen des Icons verschoben werden.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_ring/icon_temp_mring'''
<syntaxhighlight lang="perl">
icon_temp_ring/icon_temp_mring ($icon,$temp_value,$temp_min,$temp_max,$size,$lightring,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation (0-360) sind optional
$temp_value # Temperatur
$temp_min, # minimale Temperatur, optional, default=-20
$temp_max, # maximale Temperatur, optional, default=60
$size, # Größe der Grafik, optional, default=80
$lightring, # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_Heizung_temp DOIF ##
attr di_Heizung_temp uiTable {\
package ui_Table;;\
}\
\
icon_temp_ring("temp_outside",[vaillant:Aussentemp],-15,40)|\
icon_temp_mring(([vaillant:Flame] eq "off"?"sani_boiler_temp\@white":"sani_boiler_temp\@Darkorange"),[vaillant:Vorlauf],15,70)|\
icon_temp_mring(([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),[vaillant:WWSpeicher],15,70)|\
icon_temp_mring(([Zirk] eq "off"?"sani_pump\@white":"sani_pump\@Darkorange"),[ESPEasy_ESP_Temp_Zirkulation:Temperature],15,70)|\
icon_temp_mring(([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),[ESPEasy_ESP_Temp_Vorlauf:Temperature],15,70)|\
icon_temp_mring("sani_floor_heating_neutral\@white",[ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature],15,70)|""

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_ring_bsp.png|ohne|mini]]

===== Farbskalierte Feuchtigkeitsanzeige mit einem Icon mit Hilfe der SVG-Funktionen '''icon_hum_ring/icon_hum_mring''' =====
Diese Funktionen basieren auf den obigen hum_ring-Funktionen, zusätzlich wird ein SVG-Icon dargestellt. Die Farbe des Icons kann mit @ an den Iconnamen angehängt werden, ansonsten wird die Farbe der Feuchtigkeit für das Icon verwendet. Die Größe des Icons kann skaliert werden, ebenso kann die Positionen des Icons verschoben werden.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_hum_ring/icon_hum_mring'''
<syntaxhighlight lang="perl">
icon_hum_ring/icon_hum_mring ($icon,$hum_value,$size,$lightring,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$hum_value # Feuchtigkeit
$size # Größe der Grafik, optional, default=80
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_hum_ring DOIF ##
attr di_icon_hum_ring room test5
attr di_icon_hum_ring uiTable {package ui_Table}\
"klein ohne Farbverlauf"|icon_hum_mring("weather_humidity",[Aussensensor:humidity],60)\
"normal groß mit Farbverlauf"|icon_hum_ring("weather_humidity",[Aussensensor:humidity])\
"groß ohne Farbverlauf aufgehellt"|icon_hum_mring("weather_humidity",[Aussensensor:humidity],100,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_hum_ring_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Icons mit einem Zahlenwert mit Hilfe der universellen SVG-Funktion '''icon_ring/icon_mring/icon_uring''' =====
Diese Funktionen basieren auf der universellen ring-Funktion. Die Farbe des dargestellten Icons und des Wertes kann abhängig vom Wert bestimmt werden. Die Funktion '''icon_ring''' stellt den Farbring mit Farbverlauf dar, die Funktion '''icon_mring''' stellt den Farbring einfarbig dar. Die universelle Funktion '''icon_uring''' kann über den Parameter '''$model''' das Erscheinungsbild der Grafik verändern.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_ring/icon_mring/icon_uring'''
<syntaxhighlight lang="perl">
icon_ring ($icon,$value,$min,$max,$minColor,$maxColor, $unit,$decFont,$size,$colorRef,$lightness,$model)

icon_mring ($icon,$value,$min,$max,$minColor,$maxColor, $unit,$decFont,$size,$colorRef,$lightness)

icon_uring ($model,$icon,$value,$min,$max,$minColor,$maxColor, $unit,$decFont,$size,$colorRef,$lightness)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Style-SVG-Attribute Wert>,<Style-SVG-Attribute Einheit>", optional
$size # Größe der Grafik, optional, default = 100
$colorRef # Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"
$model # '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>',
# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'
</syntaxhighlight>
Wird '''$colorRef''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_ring DOIF ##
attr di_icon_ring uiTable {package ui_Table}\
\
icon_ring ('sani_floor_heating_neutral',[Heizenergie:Vortag_hc],0,150,120,0,'kWh')|\
icon_mring ('fuel',[Tankstelle:Diesel],1.10,1.30,120,0,'€',2)|\
icon_uring ('0,1,1',"air",[ESPEasy_Eingang_CO2:PPM],400,1200,undef,undef,'ppm',0,100,[(600,120,1000,60,1200,0)])|\
icon_uring ('0,1','Zisterne',([Wasserzisterne]/3.4),0,100,0,120,'%',0)##/\
\
icon_uring ('1,1,0,8',"measure_water_meter",[Wasserverbrauch:heute],0,600,120,0,'l',0)|\
icon_uring ('0,fill:white,opacity:0.4',([vaillant:Pumpenstatus] eq '4' ? 'sani_buffer_temp_down@Darkorange' : 'sani_buffer_temp_down@white'),[vaillant:Umlaufmenge],0,20,120,0,'l/min')|\
icon_uring('0,1,1,4','weather_barometric_pressure',[vaillant:Wasserdruck],0,3,undef,undef,'bar',1,100,[(0.8,0,1,60,1.5,120,1.7,60,3,0)])|\
icon_uring('0,opacity:0.8,1,6','sani_water_tap',[vaillant:HwcHours_hoursum2_value],0,2000,120,0,'h',0)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_ring_bsp.png|ohne|mini]]
 

===== Farbskalierte Temperatur- und Feuchtigkeitsanzeige mit einem Icon mit Hilfe der SVG-Funktion '''icon_temp_hum_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperatur- bzw. Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar:

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_hum_ring'''
<syntaxhighlight lang="perl">
icon_temp_hum_ring ($icon,$temp_value,$hum_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp,$decFontHum)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$temp_value # Temperatur
$hum_value # Feuchtigkeit
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp # Temperatur: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontHum # Feuchtigkeit: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_temp_hum_ring DOIF ##
attr di_icon_temp_hum_ring uiTable {package ui_Table}\
\
"normal"|icon_temp_hum_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:humidity])\
"mit Normalschrift"|icon_temp_hum_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:humidity], undef,undef,undef,undef,undef,"1,font-weight:normal","0,font-weight:normal")\
"größer aufgehellt"|icon_temp_hum_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:humidity], undef,undef,120,undef,80)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_hum_ring.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Temperaturwerten mit einem Icon mit Hilfe der SVG-Funktion '''icon_temp_temp_ring''' =====
Die Farbe ist jeweils abhängig vom dargestellten Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar:

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_temp_ring'''
<syntaxhighlight lang="perl">
icon_temp_temp_ring ($icon,$temp1_value,$temp2_value,$temp_min,$temp_max,$size, $lightring,$lightnumber,$decFontTemp1,$decFontTemp2)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$temp1_value # erster Temperaturwert
$temp2_value # zweiter Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$size # Größe der Grafik, optional, default=90
$lightring # Helligkeit des Ringes (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFontTemp1 # Temperatur1: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$decFontTemp2 # Temperatur2: "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_temp_temp_ring DOIF ##
attr di_icon_temp_temp_ring uiTable {package ui_Table}\
## Größe 120%\
"FB-Heizung"|icon_temp_temp_ring(([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),[ESPEasy_ESP_Temp_Vorlauf:Temperature],[ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature],15,70,120)\
\
## Größe 120%, Normalschrift\
"Temperatur","Taupunkt"|icon_temp_temp_ring("temp_outside",[Aussensensor:temperature],[Aussensensor:dewpoint],undef,undef,120,undef,undef,"1,font-weight:normal","1,font-weight:normal")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_temp_ring.png|ohne|mini]]

===== Farbskalierte Anzeige von zwei Zahlenwerten mit einem Icon mit Hilfe der universellen SVG-Funktion '''icon_ring2''' =====
Die Farbe der dargestellten Werte kann abhängig vom Wert bestimmt werden.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_ring2'''
<syntaxhighlight lang="perl">
icon_ring2 ($icon,$value1,$min1,$max1,$minColor1,$maxColor1,$unit1,$size,$colorFunc1,$decFont1, $value2,$min2,$max2,$minColor2,$maxColor2,$unit2,$colorFunc2,$decFont2,$lightnesss,$model)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$value1 # darzustellender Wert1
$min1 # minimaler Wert, optional, default=0
$max1 # maximaler Wert, optional, default=100
$minColor1 # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor1 # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit1 # Einheit des Wertes, optional, default = undef
$size # Größe der Grafik, optional, default = 100
$colorFunc1 # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont1 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$value2 ## darzustellender Wert2
...
$unit2 # Einheit des Wertes, optional, default = undef
$colorFunc2 # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont2 # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$lightness # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"
$model # '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>',
# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'

Argumente für den zweiten Wert entsprechend den Argumenten des ersten Wertes
</syntaxhighlight>
Wird '''$colorFunc...''' nicht angegeben, so wird der Farbwert zwischen '''$minColor...''' und '''$maxColor...''' linear interpoliert.

Bei der Farbangabe des Icons beim Übergabeparameter $icon wird mit '''\@colorVal2''' das Icon mit der Farbe des zweiten Wertes eingefärbt. Bei keiner Farbangabe oder '''\@colorVal1''' wird das Icon mit der Farbe des ersten Wertes eingefärbt. Ansonsten gilt die allgemeine FHEM-Syntax für Farbgebung von Icons angehängt mit '''\@'''.
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_ring2 DOIF ##
attr di_icon_ring2 uiTable {package ui_Table};;\
\
sub himmelsrichtung {\
my ($richtung)=@_;;\
my $element=int($richtung/22.5);;\##/
my @h=(qw"N NNO NO ONO O OSO SO SSO S SSW SW WSW W WNW NW NNW");;\
return($h[$element]);;\
}\
}\
"Wallbox"| icon_ring2("car,1.5,0,-3",[tesla:Leistung],0,3.6,120,0,"kW",120,undef,"1,font-weight:normal",[tesla:Kapazitaet],0,100,0,120,"%",undef,"0,font-weight:normal")\
\
"Wind"|icon_ring2(([Wind:Geschwindigkeit]>0 ? "wind":"no_wind").",1,0,0,".[Wind:Richtung],[Wind:Geschwindigkeit],0,50,120,0,"km/h",120,undef,1,[Wind:Richtung],361,361,220,220,([Wind:Geschwindigkeit]>0?himmelsrichtung([Wind:Richtung]):"--"),undef,0)\
\
"Strom"|icon_ring2([zaehler:l-Produktion] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",[zaehler:l-Produktion],0,3.6,20,120,"PV kW",150,undef,"1,,font-size:50%;fill:white",[zaehler:l-Bezug,0],0,2,120,0,"Netz kW",undef,"1,,font-size:50%;fill:white")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_ring2.png|ohne|mini]]

==== '''bar'''-Funktionen ====
===== Farbskalierte Anzeige der Temperatur in Balkenform mit Hilfe der SVG-Funktionen '''temp_bar/temp_mbar''' =====
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''temp_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

Farbskalierung der '''temp_bar'''-SVG-Funktion:
[[Datei:Farbskalierung temp_bar_scaling.png|600px|ohne]]

Farbskalierung der '''temp_mbar'''-SVG-Funktion:
[[Datei:Farbskalierung temp_mbar_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''temp_bar/temp_mbar'''
<syntaxhighlight lang="perl">
temp_bar/temp_mbar ($temp_value,$temp_min,$temp_max, $header,$width,$height,$size, $light,$lightnumber,$decFont)

$temp_value # Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$header # Überschrift, optional, default= undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=60
$size # Größe der Grafik, optional, default=100
$light # Helligkeit der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_temp_bar DOIF ##
attr di_temp_bar uiTable {package ui_Table}\
"standard"|temp_bar([Aussensensor:temperature])\
"heller"|temp_bar([Aussensensor:temperature],undef,undef,undef,undef,undef,undef,80)\
"monochrom"|temp_mbar([Aussensensor:temperature])\
"kleiner"|temp_bar([Aussensensor:temperature],undef,undef,undef,undef,undef,80)\
"mit Überschrift"|temp_bar([Aussensensor:temperature],undef,undef,"Außen")\
"hoch"|temp_bar([Aussensensor:temperature],undef,undef,undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:temp_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige der Feuchtigkeit in Balkenform mit Hilfe der SVG-Funktionen '''hum_bar/hum_mbar''' =====
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''hum_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

Farbskalierung der '''hum_bar'''-SVG-Funktion:
[[Datei:Farbskalierung hum_bar_scaling.png|600px|ohne]]

Farbskalierung der '''hum_mbar'''-SVG-Funktion:
[[Datei:Farbskalierung hum_mbar_scaling.png|600px|ohne]]

{{Randnotiz|RNText=SVG-uiTable-Funktion '''hum_bar/hum_mbar'''
<syntaxhighlight lang="perl">
hum_bar/hum_mbar ($hum_value,$header,$width,$height,$size, $light,$lightnumber,$decFont)

$hum_value # Feuchtigkeitswert
$header # Überschrift, optional, default = undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=80
$size # Größe der Grafik, optional, default=100
$light # Helligkeit des der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 0
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_hum_bar DOIF ##
attr di_hum_bar uiTable {package ui_Table}\
"standard"|hum_bar([Aussensensor:humidity])\
"heller"|hum_bar([Aussensensor:humidity],undef,undef,undef,undef,80)\
"monochrom"|hum_mbar([Aussensensor:humidity])\
"kleiner"|hum_bar([Aussensensor:humidity],undef,undef,undef,80)\
"mit Überschrift"|hum_bar([Aussensensor:humidity],"Außen")\
"hoch"|hum_bar([Aussensensor:humidity],undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:hum_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Zahlenwertes mit Hilfe der universellen SVG-Funktion '''bar''' =====
Die Farbe des dargestellten Wertes kann abhängig vom Wert bestimmt werden.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''bar'''
<syntaxhighlight lang="perl">
bar ($value,$min,$max,$header,$minColor,$maxColor,$unit,$width, $height,$size,$colorFunc,$decFont,$gradient,$light,$lightnumber)

$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$header # Überschrift, optional, default = undef (keine)
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$width # Breite der Grafik, optional, default = 63
$height # Höhe der Grafik, optional, default = 60
$size # Größe der Grafik, optional, default = 100
$colorFunc # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
$gradient # Farbverlauf, optional, undef mit Farbverlauf, 1 ohne Farbverlauf, default = undef
$light # Helligkeit der Grafik (light:0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (light:0-100), optional, default=50
</syntaxhighlight>
Wird '''$colorFunc''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
{package ui_Table}
defmod di_bar DOIF ##
attr di_bar uiTable {package ui_Table}\
## von 0 bis 20 in Farben von grün (hue:120) bis rot (hue:0)\
"Umlaufmenge"|bar([heizung:Umlaufmenge],0,20,"Umlauf",120,0,"l/min")\
\
## von 0 bis 3 in Farben von rot (hue:0) bis türkis (hue:180)\
"Wasserdruck"|bar([heizung:Wasserdruck],0,3,undef,0,180,"bar"undef,70,undef,undef,"1,font-size:130%;;font-weight:normal")\
\
## Temperaturdarstellung, entspricht dem Funktionsaufruf:\
## temp_bar ([Aussensensor:temperature],-20,60)\
"Temperatur"|bar([Aussensensor:temperature],-20,60,undef,undef,undef,"°C",undef,undef,undef,\&temp_hue)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:bar_bsp.png|ohne|mini]]

==== '''icon_bar'''-Funktionen ====
===== Farbskalierte Anzeige der Temperatur in Balkenform mit Hilfe der SVG-Funktion '''icon_temp_bar/icon_temp_mbar''' =====
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''icon_temp_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_temp_bar/icon_temp_mbar'''
<syntaxhighlight lang="perl">
icon_temp_bar/icon_temp_mbar ($icon,$temp_value,$temp_min,$temp_max, $header,$width,$height,$size,$light,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position", \@Farbe, Skalierungsfaktor, x-Position, y-Position sind optional
$temp_value # Temperaturwert
$temp_min # minimale Temperatur, optional, default=-20
$temp_max # maximale Temperatur, optional, default=60
$header # Überschrift, optional, default= undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=75
$size # Größe der Grafik, optional, default=100
$light # Helligkeit der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_temp_bar DOIF ##
attr di_icon_temp_bar room test10
attr di_icon_temp_bar uiTable {package ui_Table}\
"standard"|icon_temp_bar("temp_outside",[Aussensensor:temperature])\
"heller"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,undef,undef,undef,undef,80)\
"monochrom"|icon_temp_mbar("temp_outside",[Aussensensor:temperature])\
"kleiner"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,undef,undef,undef,80)\
"mit Überschrift"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,"Außen")\
"hoch"|icon_temp_bar("temp_outside",[Aussensensor:temperature],undef,undef,undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_temp_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige der Feuchtigkeit in Balkenform mit Hilfe der SVG-Funktionen '''icon_hum_bar/icon_hum_mbar''' =====
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert. Die Helligkeit der Farbgebung ist einstellbar. Bei der '''icon_hum_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_hum_bar/icon_hum_mbar'''
<syntaxhighlight lang="perl">
icon_hum_bar/icon_hum_mbar ($icon,$hum_value,$header,$width,$height,$size, $light,$lightnumber,$decFont)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position", \@Farbe, Skalierungsfaktor, x-Position, y-Position sind optional
$hum_value # Temperaturwert
$header # Überschrift, optional, default = undef (keine)
$width # Breite der Grafik, optional, default=63
$height # Höhe der Grafik, optional, default=75
$size # Größe der Grafik, optional, default=100
$light # Helligkeit des der Grafik (0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (0-100), optional, default=50
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_hum_bar DOIF ##
attr di_icon_hum_bar uiTable {package ui_Table}\
"standard"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity])\
"heller"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],undef,undef,undef,undef,80)\
"monochrom"|icon_hum_mbar("temperature_humidity",[Aussensensor:humidity])\
"kleiner"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],undef,undef,undef,80)\
"mit Überschrift"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],"Außen")\
"hoch"|icon_hum_bar("temperature_humidity",[Aussensensor:humidity],undef,undef,100)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_hum_bar_bsp.png|ohne|mini]]

===== Farbskalierte Anzeige eines Zahlenwertes mit Hilfe der universellen SVG-Funktionen '''icon_bar/icon_mbar''' =====
Die Farbe des dargestellten Wertes und des Icons kann abhängig vom Wert bestimmt werden. Bei der '''icon_mbar'''-SVG-Funktion wird der Balken einfarbig dargestellt.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''icon_bar/icon_mbar'''
<syntaxhighlight lang="perl">
icon_bar ($icon,$value,$min,$max,$minColor,$maxColor,$unit,$decfont,$header,$width,$height,$size, $colorFunc,$light,$lightnumber)

$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation (0-360) sind optional
$value # darzustellender Wert
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$header # Überschrift, optional, default = undef (keine)
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit # Einheit des Wertes, optional, default = undef
$decFont # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional, default = 1
$width # Breite der Grafik, optional, default = 63
$height # Höhe der Grafik, optional, default = 75
$size # Größe der Grafik, optional, default = 100
$colorFunc # Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, optional, default = undef
$light # Helligkeit der Grafik (light:0-100), optional, default=50
$lightnumber # Helligkeit der Zahl (light:0-100), optional, default=50
</syntaxhighlight>
Wird '''$colorFunc''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_icon_bar_bsp DOIF ##
attr di_icon_bar_bsp uiTable {package ui_Table;;\
}\
icon_bar ("fuel",[Tankstelle:Diesel],1.10,1.30,120,0,"€",2)|\
icon_bar ("air",[ESPEasy_Eingang_CO2:PPM],400,1200,120,0,"ppm",0)|\
icon_bar ("Zisterne",([Wasserzisterne]/3.4),0,100,0,120,"%",0)|\
icon_bar (([vaillant:Pumpenstatus] eq "off" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),[vaillant:Umlaufmenge],0,20,120,0,"l/min")\
icon_bar ("measure_water_meter",[Wasserverbrauch:heute],0,600,120,0,"l",0)|\
icon_bar ("weather_barometric_pressure",[vaillant:Wasserdruck],0,3,0,180,"bar")|\
icon_bar ("sani_water_tap",[vaillant:HwcHours_hoursum2_value],0,2000,120,0,"h",0)|\
icon_bar ("sani_floor_heating_neutral",[Heizenergie:Vortag_hc],0,150,120,0,"kWh")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:icon_bar_bsp.png|ohne|mini]]

==== Anzeige eines Werteverlaufs und des aktuellen Wertes mit Hilfe der SVG-Funktion '''card''' ====
Es wird der aktuelle Wert eines Readings, sein zeitlicher Verlauf sowie der maximale und minimale Wert in Form einer Informationskarte visualisiert. Das Erscheinungsbild kann über zahlreiche Parameter individualisiert werden. Die Besonderheit ist das Argument '''col<Anzahl><Zeitformat>''' bei der Angabe des Readings der Form '''[<Device>:<Reading>:col<Anzahl><Zeitformat>]'''. Dadurch werden Daten des Readings temporär im DOIF-Modul gesammelt und für die Erzeugung eines Graphen zur Verfügung gestellt - es sind keine weiteren Definitionen erforderlich. Dabei wird besonders sparsam mit der Datensammlung umgegangen, es werden maximal 72 Werte (in Timeslots) gespeichert, unabhängig davon wie lange die Zeitspanne ist und wie oft die Daten ankommen. Die Auflösung des Graphen nimmt mit der Zeitspanne ab - es werden immer maximal 72 Werte dargestellt. Daraus ergibt sich bei einer Stunde eine Auflösung von 3600/72 = 50 Sekunden/Eintrag, bei 6 Stunden sind es 6*60/72 = 5 Minuten/Eintrag, für eine Woche 7*24*60/72 = 140 Minuten/Eintrag usw. Die gesammelten Daten werden über den FHEM-Befehl '''save''' in versteckten Readings des jeweiligen DOIF-Moduls gespeichert.

{{Randnotiz|RNText=SVG-uiTable-Funktion '''card'''
<syntaxhighlight lang="perl">
card ($collect,$header,$icon,$min,$max,$minColor,$maxColor, $unit,$colorRef,$decfont,$prop,$ringModel,$lightness, $collect2,$min2,$max2,$minColor2,$maxColor2,$unit2,$func2,$decfont2)

$collect
# Angabe eines Readings oder eines Arrays mit mehreren Readings der Form [<Device>:<Reading>:col<Anzahl><Zeitformat>], mit Hilfe des Argumentes col (von collect) wird das Modul angewiesen Daten des Readings über einen bestimmten Zeitraum zu sammeln

col<number><timeformat>
# <timeformat>: d Tage, w Wochen, ohne Angabe des Zeitformates wird <Anzahl> in Stunden interpretiert.
# Beispiele: col (entspricht col24), col1, col12, col1d, col3d, col1w, col4w, col52w usw.

$header # "<Überschrifttext,<Style-SVG-Text-Attribute>", optional
$icon # "Iconname\@Farbe,Skalierungsfaktor,x-Position,y-Position,Rotation", \@Farbe, Skalierungsfaktor, x-Position, y-Position, Rotation sind optional
$min # minimaler Wert, optional, default=0
$max # maximaler Wert, optional, default=100
$minColor # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = 0 (rot)
$maxColor # Farbe (hue: 0-360) des maximalen Wertes, optional, default = 120 (grün)
$unit
# Einheit des Wertes, optional, default = undef, falls unter $collect ein Array für mehrere Readings angegeben wurde, so werden hier als Array die entsprechenden Einheiten angegeben, zusätzlich kann kommagetrennt pro Einheit Farbe des Graphen angegeben werden

$colorRef
# Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef

$decFont
# "<Anzahl der Nachkommastellen>,<Style-SVG-Attribute Wert>,<Style-SVG-Attribute Einheit>", optional

$prop
# Eigenschaft von card: "<size>,<y-scaling>,<steps>,<noFooter>,<noColor>,<hring>,<width>", optional

# <size>: Größe der der Karte, default = 130,
# <y-scaling>: feste Y-Skalierung: 1, sonst automatische Skalierung,
# <steps>: 1 für Stufen,
# <noFooter>: 1 für keine Fußzeile,
# <noColor>: 1 für graue y-Achsenbeschriftung,
# <hring>: 1 für Halbringdarstellung,
# <width>: Breite der Karte, default: 160

$ringModel
# '<color gradient>,<min/max>,<inner ring>,<pointer>,<mode>'

# <color gradient>: 1 für monochrom
# <min/max>: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte
# <inner ring>: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes
# <pointer>: Breite des Zeigers in Pixel
# <mode>: 0 Standard Min. - Max., 1 negativ - Null - positiv, 2 Null - negativ/positiv
# alle Parameter sind optional, default keine Angaben: ',,,,,,'

$lightness
# Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>,<icon>", optional, default: "50,50,50,40,50,40"

$collect2 # optionale Angaben für ein zweites Reading (es ist hier nur eine Readingangabe erlaubt)
$min # restliche Parameter
$max # entsprechen der Syntax
... # des ersten Sensors
$decfonts2 #
</syntaxhighlight>
Wird '''$colorRef''' nicht angegeben, so wird der Farbwert zwischen '''$minColor''' und '''$maxColor''' linear interpoliert
Werden mehrere Readings angegeben, so müssen sie alle die gleiche Zeitspanne besitzen (Zeitangabe bei col)

'''nützliche Links'''
* Anwendungsbeispiel [[DOIF/uiTable_Schnelleinstieg#Visualisierung:_Wetterstation|Wetterstation]]
* Anwendungsbeispiel [[DOIF/uiTable_Schnelleinstieg#Visualisierung:_aktueller_Spritpreis|Spritpreise]]
* Anwendungsbeispiel [[DOIF/uiTable_Schnelleinstieg#Visualisierung_und_Steuerung:_Heiztherme|Heiztherme]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Farbskalierte_Anzeige_eines_Icons_mit_einem_Zahlenwert_mit_Hilfe_der_universellen_SVG-Funktion_icon_ring.2Ficon_mring.2Ficon_uring|icon_ring]]
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_collect DOIF ##
attr di_collect uiTable {package ui_Table;;}\
card([Aussensensor:temperature:col12],"Außen","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef)|\
card([Tankstelle:Diesel:col12],"Sprit,fill:darkorange","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,1")\
card([zaehler:l-Produktion:col12],undef,[zaehler:l-Produktion] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,3.6,30,60,"PV kW",undef,"1,,font-size:50%")|\
card([ESPEasy_Eingang_CO2:PPM:col12],undef,"air",400,1200,120,0,"ppm",[600,120,1000,60,1200,0],0,undef,'0,1,1',"50,35,45,35,50,35")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:svgcard.png|ohne|mini]]

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">

defmod di_cards DOIF {}
attr di_cards uiTable {package ui_Table;;}\
"Standard"|\
card([Aussensensor:temperature:col],undef,"temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130")\
"mit Halbring"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130,,,,,1")\
"mit Halbring","ohne Fußzeile","Breite 110"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130,,,1,,1,110")\
"Standard","Breite 200"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,50,undef,undef,"°C",\&temp_hue,"1","130,,,,,,200")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_variations.png|ohne|mini]]

'''<big>Beispieldefinition mit zwei Readings mit unterschiedlichen Einheiten</big>'''
<syntaxhighlight lang="perl">
defmod di_cards DOIF {}
attr di_cards uiTable {package ui_Table;;}\
"Standard"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Header"|\
card([Aussensensor:temperature:col],undef,"temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Header","ohne Fußzeile"|card([Aussensensor:temperature:col],undef,"temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,1,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"Als Halbring"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,,1",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Fußzeile"|\
card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,1,,1",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_collect2.png|ohne|mini]]

'''<big>Beispieldefinitionen mit mehreren Readings mit gleicher Einheit</big>'''

<syntaxhighlight lang="perl">
defmod Sprit DOIF ##
attr Sprit uiTable {package ui_Table;;}\
card([[Tankstelle:SuperE5:col24],[Tankstelle:Diesel:col24]],"Sprit","fuel","1.20","1.60",120,0,["E5","Diesel"],undef,"2",",,1")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_Sprit2.png|ohne|mini]]

<syntaxhighlight lang="perl">
defmod PV DOIF {}
attr PV DOIF_Readings l_Eigenv: [zaehler:l-Produktion]-[zaehler:l-Lieferung],\
Eigenv:[zaehler:Produktion]-[zaehler:Lieferung],\
l_Verbrauch: [zaehler:l-Bezug,0]+[$SELF:l_Eigenv,0],\
Verbrauch:[zaehler:Bezug]+[$SELF:Eigenv],\
l_Bezug:-[zaehler:l-Bezug]
attr PV uiTable {\
package ui_Table;;\
$SHOWNOSTATE=1;;\
}\
card([[zaehler:l-Produktion:col],[$SELF:l_Eigenv:col],[$SELF:l_Bezug:col]],"kW","fa_bolt\@silver",-3.6,3.6,0,90,["Solar","Eigen.","Bezug"],[(-1,0,0,30,1,60,3.6,90)],"2","167,,1,,,1",",,1,6")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_energie.png|ohne|mini]]

'''<big>Beispieldefinition mit mehreren Readings mit einfarbigen Graphen</big>'''

<syntaxhighlight lang="perl">
defmod di_heating DOIF {}
attr di_heating uiTable {\
package ui_Table;;\
}\
card([[ESPEasy_ESP_Temp_Vorlauf:Temperature:col],[ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature:col]],"Umwälzpumpe",([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),15,70,undef,undef,["Vor. °C,red","Rück. °C,#287afc"],\&temp_hue,undef,",,1,,1")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:di_card_pump.png|ohne|mini]]

==== 3d-Balkendarstellung mehrerer Zahlenwerten mit Hilfe der universellen SVG-Funktion '''cylinder''' ====
Es können mehrere Zahlenwerte mit Legende farbig in Balkenform visualisiert werden. Negative Werte werden als Balken nach unten dargestellt, positive nach oben, der Nullpunkt wird automatisch berechnet.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''cylinder'''
<syntaxhighlight lang="perl">
cylinder ($header,$min,$max,$unit,$width,$height,$size,$dec,($value1,$color1,$text1),($value2,$color2,$text2),...

$header # Überschrift
$min # minimaler Wert, optional, default = 0
$max # maximaler Wert, optional, default = 100
$unit # Einheit des Wertes, optional, default = undef
$width # Breite der Grafik, optional, default = wird bei Beschriftungen automatisch angepasst
$height # Höhe der Grafik, optional, default = wird automatisch berechnet
$size # Größe der Grafik, optional, default = 100
$dec # Anzahl der Nachkommastellen, optional, default=1
$value1 # erster Zahlenwert
$color1 # HSL-Farbe des ersten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text1 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
$value2 # zweiter Zahlenwert, optional
$color2 # HSL-Farbe des zweiten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text2 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
...
Es können weitere Zahlenwerte jeweils mit Farbe und Beschriftung optional angegeben werden
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_cylinder DOIF ##
attr di_cylinder room Test,wiki
attr di_cylinder uiTable {package ui_Table}\
"normal"|cylinder("",0,100,"%",80,undef,undef,0,[Wasserzisterne:state],200,undef)\
\
"mit Überschrift"|cylinder("Zisterne",0,100,"%",80,undef,undef,0,[Wasserzisterne:state],200,undef)\
\
"kleiner"|cylinder("Zisterne",0,100,"%",80,undef,80,0,[Wasserzisterne:state],200,undef)\
\
"hoch"|cylinder("Zisterne",0,100,"%",undef,100,undef,0,[Wasserzisterne:state],200,undef)\
\
"mit Beschriftung"|cylinder("Zisterne",0,100,"%",undef,100,undef,0,[Wasserzisterne:state],200,"Wasserstand")\
\
"mit mehreren Informationen"|cylinder("Energie",-20,30,"kWh",undef,undef,undef,1,[zaehler:Bezug],0,"Bezug",[zaehler:Produktion],60,"Produktion",[zaehler:Eigenverbrauch],30,"Eigenverbrauch")\
\
"mit hellen Farben"| cylinder("Tag",0,100,"kWh",undef,undef,undef,1,[Heizenergie:Tagesverbrauch_hc]/100000,"30.100.70","letzter",[Heizenergie:heute_hc]/100000,"60.100.70","aktuell")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:cylinder_bsp.png|ohne|mini]]

==== Balkendarstellung mehrerer Zahlenwerte mit Hilfe der universellen SVG-Funktion '''cylinder_bars''' ====
Es können mehrere Zahlenwerte mit Legende farbig in Balkenform visualisiert werden. Negative Werte werden als Balken nach unten dargestellt, positive nach oben, der Nullpunkt wird automatisch berechnet. Die '''cylinder_bars'''-SVG-Funkton besitzt die gleichen Argumente, wie die obige '''cylinder'''-SVG-Funktion, mehrerer Balken werden jedoch nicht übereinander, sondern nebeneinander dargestellt.
{{Randnotiz|RNText=SVG-uiTable-Funktion '''cylinder_bars'''
<syntaxhighlight lang="perl">
cylinder_bars ($header,$min,$max,$unit,$width,$height,$size,$dec,($value1,$color1,$text1),($value2,$color2,$text2),...

$header # Überschrift
$min # minimaler Wert, optional, default = 0
$max # maximaler Wert, optional, default = 100
$unit # Einheit des Wertes, optional, default = undef
$width # Breite der Grafik, optional, default = wird bei Beschriftungen automatisch angepasst
$height # Höhe der Grafik, optional, default = wird automatisch berechnet
$size # Größe der Grafik, optional, default = 100
$dec # Anzahl der Nachkommastellen, optional, default=1
$value1 # erster Zahlenwert
$color1 # HSL-Farbe des ersten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text1 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
$value2 # zweiter Zahlenwert, optional
$color2 # HSL-Farbe des zweiten Balkens: "<hue>.<saturation>.<lightness>" (hue:0-360,saturation:0-100,lightness:0-100), saturation (default:100) und lightness (default:50) sind optional
$text2 # Beschriftung des Zahlenwertes in der Legende, optional, default = undef
...
Es können weitere Zahlenwerte jeweils mit Farbe und Beschriftung optional angegeben werden
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_wasserverbrauch DOIF ##
attr di_wasserverbrauch uiTable {package ui_Table;;}\
cylinder_bars("Monat",0,15,"m³",undef,undef,undef,1,[Wasserverbrauch:monatsdurchschnitt],30,"Durchschnitt",[Wasserverbrauch:monatsverbrauch]/1000,220,"letzter",[Wasserverbrauch:monat]/1000,180,"aktuell")\
\
cylinder_bars("Monat",0,15,"m³",undef,undef,undef,1,[Wasserverbrauch:jan],30,"Januar",[Wasserverbrauch:feb],220,"Februar",[Wasserverbrauch:mrz],180,"März",[Wasserverbrauch:apr],30,"April",[Wasserverbrauch:mai],220,"Mai",[Wasserverbrauch:jun],180,"Juni",[Wasserverbrauch:jul],30,"Juli",[Wasserverbrauch:aug],220,"August",[Wasserverbrauch:sep],180,"September",[Wasserverbrauch:okt],30,"Oktober",[Wasserverbrauch:nov],220,"November",[Wasserverbrauch:dez],180,"Dezember")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:cylinder_bars_bsp.png|ohne|mini]]

=== Farbskalierte Temperaturanzeige mit Hilfe der Funktion '''temp''' ===
Die Farbe der dargestellten Temperatur ist abhängig vom Temperaturwert:
[[Datei:Farbskalierung temp.png|600px|ohne]]
{{Randnotiz|RNText=uiTable-Funktion '''temp'''
<syntaxhighlight lang="perl">
temp ($temp,$size,$icon)

$temp # Temperatur
$size # Schriftgröße in Pixel (pt), optional
$icon # Icon, welches vorangestellt wird, optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_temp DOIF ##
attr di_uiTable_temp uiTable {\
package ui_Table;; ## Package für uiTable-Funktionen\
$TC{0..2}="align='center'";; ## zentrierte Darstellung aller Tabellenspalten\
}\
## Tabellendefinition\
\
"Aussen"|"Bad"|"Warmwasser" ## mit | werden Tabellenzellen voneinander getrennt \
temp([Aussensensor:temperature])| ## Anzeige des Readings 'temperature' des Gerätes 'Aussensensor' \
temp([TH_Bad_HM:measured-temp],24,"temp_temperature")| ## Schriftgröße 24pt, mit Icon namens temp_temperature\
temp([T_Warmwasserspeicher:temperature:d1],20) ## Schriftgröße 20pt
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Temp.png|ohne|mini]]

=== Farbskalierte Feuchtigkeitsanzeige mit Hilfe der Funktion '''hum''' ===
Die Farbe der dargestellten Feuchtigkeit ist abhängig vom Feuchtigkeitswert:
[[Datei:Farbskalierung hum.png|350px|ohne]]
{{Randnotiz|RNText=uiTable-Funktion '''hum'''
<syntaxhighlight lang="perl">
hum ($hum,$size,$icon)

$hum # Feuchtigkeit
$size # Schriftgröße in Pixel (pt), optional
$icon # Icon, welches vorangestellt wird, optional
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_hum DOIF ##
attr di_uiTable_hum uiTable {\
package ui_Table;;\
$TC{1}="align='center'";; ## zweite Spalte der Tabelle zentriert\
}\
## Tabellendefinition \
\
## Anzeige des Readings 'humidity' des Thermostats 'TH_Bad_HM' \
"Bad"|hum ([TH_Bad_HM:humidity])\
\
## Feuchtigkeit in Größe 10pt mit Temperatur in einer Tabellenzelle\
"Aussen"|temp ([Aussensensor:temperature]),hum ([Aussensensor:humidity],10)\
\
## Feuchtigkeit in Größe 26pt mit Icon namens 'temperature_humidity'\
"Keller"|hum ([TH_Keller_HM:humidity],26,"temperature_humidity")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable Funktion hum.png|ohne|mini]]

=== Textformatierungen mit Hilfe der Funktion '''style''' ===
Texte werden in Farbe, Größe und Schriftart statisch oder dynamisch formatiert.
{{Randnotiz|RNText=uiTable-Funktion '''style'''
<syntaxhighlight lang="perl">
style ($text,$color,$font_size,$font_weight)

$text # anzuzeigender Text
$color # CSS color, optional
$font_size # Schriftgröße in Pixel (pt), optional
$font_weight # CSS Schriftart, optional
</syntaxhighlight>
Mögliche Werte für '''''color''''' und '''''font_weight''''' können in einschlägiger Dokumentation zu CSS nachgeschlagen werden
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_style DOIF ##
attr di_uiTable_style uiTable {\
package ui_Table;;\
}\
## Tabellendefinition\
\
## statische Farbgebung, Größe, Schriftart \
style("Montag","orange")\
style("Dienstag","red",14)\
style("Mittwoch","#00FFFF",20)\
style("Donnerstag","blue",23,"bold")\
\
## dynamische Farbgebung abhängig vom Zustand des Gerätes 'Alarm'\
style("Alarm",([Alarm:state] eq "on" ? "red":"green"))\
\
## dynamische Farbgebung des Zustands des Gerätes 'Alarm'\
style([Alarm:state],([Alarm:state] eq "on" ? "red":"green"))\
\
## variabler Text abhängig vom Zustand des Gerätes 'Alarm'\
style(([Alarm:state] eq "on" ? "Alarm aktiv":"Alarm deaktiviert"),"red")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Style.png|ohne|mini]]

=== Icon-Darstellung mit Hilfe der Funktion '''ICON''' ===
Mit Hilfe der Funktion '''ICON''' kann ein FHEM-Icon dargestellt werden
{{Randnotiz|RNText=uiTable-Funktion '''ICON'''
<syntaxhighlight lang="perl">
ICON ($icon)

$icon # Icon mit Farbgebung
</syntaxhighlight>

'''ICON''' benutzt die Funktion [[DevelopmentFHEMWEB-API#FW_makeImage|FW_makeImage]]

'''nützliche Links'''
* [[DOIF/uiTable Schnelleinstieg#hsv-Funktion für Farbskalierungen|hsv-Funktion]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_Table_ICON DOIF ##
attr di_Table_ICON uiTable {\
package ui_Table;;\
}\
## Tabellendefinition\
ICON("temp_frost") | ## Icon ohne Einfärbung\
ICON("temp_frost\@blue") | ## Icon in CSS-Farbe blau\
ICON("temp_frost\@#8A2BE2") | ## Icon in CSS-Farbe #8A2BE2\
ICON("temp_frost\@".([Aussensensor:temperature] > 0 ? "orange":"blue"))| ## Icon in CSS-Farbe orange über Null Grad, sonst in CSS-Farbe blau\
ICON("temp_frost\@".hsv ([Aussensensor:temperature],-20,40,320,0)) ## Icon in Farbskalierung von violett (-20 °C) bis rot (40 °C) mit Hilfe der Funktion hsv
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable_IC.png|mini|ohne]]

=== Icon-Darstellung mit Text mit Hilfe der Funktion '''icon_label''' ===
Mit Hilfe der Funktion '''icon_label''' kann ein FHEM-Icon mit einem angehängten Text/Wert dargestellt werden.
{{Randnotiz|RNText=uiTable-Funktion '''icon_label'''
<syntaxhighlight lang="perl">
icon_label ($icon,$text,$color,$color_bg,$pos_left,$pos_top)
$icon # FHEM-Icon mit Farboption
$text # dargestellter Text
$color # Farbe des Textes, optional
$color # Hintergrundfarbe des Textes, optional
$pos_left # horizontale Position des Textes in px, default -5, optional
$pos_top # vertikale Position des Textes in px, default -8, optional
</syntaxhighlight>

'''Anwendungsbeispiele'''
* [[DOIF/uiTable Schnelleinstieg#Anzahl der Tage bis zur Abfall-Entsorgung|Abfall]]
* [[DOIF/uiTable Schnelleinstieg#Visualisierung: aktueller Spritpreis|Sprit]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_icon_label DOIF ##
attr di_uiTable_icon_label uiTable { package ui_Table;;\
}\
\
icon_label("fuel",[Tankstelle:Diesel])|\
icon_label("fuel",[Tankstelle:Diesel],"red")|\
icon_label("fuel\@blue",[Tankstelle:Diesel],"blue","#999999")|\
icon_label("fuel\@red",[Tankstelle:Diesel],"red","white",-10)|\
icon_label("fuel",[Tankstelle:Diesel],"white","red",-5,8)\

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable_icon_label.png|mini|ohne]]

=== Visualisierung eines Gerätes mit Hilfe der Funktion '''icon''' ===
Der Zustand eines Gerätes/Readings wird mit Hilfe eines Icons dargestellt.
{{Randnotiz|RNText=uiTable-Funktion '''icon'''
<syntaxhighlight lang="perl">
icon ($value,$icon_off,$icon_on,$state_off,$state_on)

$value # Wert
$icon_off # Icon für den Wert off, default "off"
$icon_on # Icon für den Wert on, default Icon für Wert 'off' in Farbe 'DarkOrange', sonst Icon 'on', wenn $icon_off nicht definiert ist
$state_off # Wert zugehörig zum Icon off, default "off"
$state_on # Wert zugehörig zum Icon on, default "on"
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_icon DOIF ##
attr di_uiTable_icon uiTable {\
package ui_Table;;\
}\
## Tabellendefinition\
\
## Standard-Icon off/on für Standardwert off/on \
"Lampe"|icon([Lampe:state]) ## entspricht icon([Lampe:state],"off","on","off","on")\
\
## Icon für Zustand 'off' ist 'hue_room_hallway', für Zustand 'on' 'hue_room_hallway\@DarkOrange'\
"Flur"|icon([Lampeflur:state],"hue_room_hallway") ## entspricht icon([Lampeflur:state],"hue_room_hallway","hue_room_hallway\DarkOrange","off","on")\
\
## Icon für Zustand 'off' ist 'status_away_2', für Zustand 'on' 'status_available\@DarkOrange'\
"Anwesenheit"|icon([Anwesenheit:state],"status_away_2","status_available\@DarkOrange") \
\
## Icon für Zustand 'closed' ist "status_locked", für Zustand 'open' 'status_open\@DarkOrange'\
"Haus"|icon([Schloss:state],"status_locked","status_open\@DarkOrange","closed","open")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable icon.png|mini|ohne]]

=== Schaltbares Icon mit Hilfe der Funktion '''switch''' ===
Der Zustand eines Gerätes/Readings wird mit Hilfe eines Icons dargestellt, er kann über die WEB-Oberfläche durch Anklicken geschaltet werden. Damit der Zustand des Gerätes geschaltet werden kann, muss das Gerät den set-Befehl unterstützen.

{{Randnotiz|RNText=uiTable-Funktion '''switch'''
<syntaxhighlight lang="perl">
switch ($value,$icon_off,$icon_on,$state_off,$state_on)

$value # [<device>:<reading>]
$icon_off # Icon für den Wert off, default "off"
$icon_on # Icon für den Wert on, default Icon für Wert 'off' in Farbe 'DarkOrange', sonst Icon 'on', wenn $icon_off nicht definiert ist
$state_off # Wert zugehörig zum Icon off, default "off"
$state_on # Wert zugehörig zum Icon on, default "on"
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_switch DOIF ##
attr di_uiTable_switch uiTable {\
package ui_Table;;\
}\
## schaltbares Icons in der Webansicht \
switch([Lampe:state]) | \
switch([Lampeflur:state],"hue_room_hallway") |\
switch([Anwesenheit:state],"status_away_2","status_available\@DarkOrange")|\
switch([Haus:state],"status_locked","status_open\@DarkOrange","closed","open")\
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable switch.png|mini|ohne]]

=== Rollladen: Visualisierung und Steuerung mit Hilfe der Funktion '''shutter''' ===
Die aktuelle Position des Rollladens (0 % - 100 %) wird über Icons visualisiert. Das Anklicken eines Symbols steuert den Rollladen auf die entsprechende Position. Prozentwerte zwischen zwei Icon-Werten werden dem nächsthöheren Icon-Wert zugeordnet.
{{Randnotiz|RNText=uiTable-Funktion '''shutter'''
<syntaxhighlight lang="perl">
shutter ($value,$color,$type)

$value # [<device>:<reading>]
$color # Farbe der aktuellen Rollladenposition, vorangestelltes @ verändert die Farbe des Icons, ohne @ wird der Hintergrund des Icons eingefärbt, default ist @DarkOrange
$type # optional, Anzahl der Symbole 2 bis 6, 3 ist default
</syntaxhighlight>

* [[DOIF/uiTable Schnelleinstieg#Visualisierung und Steuerung von Rollläden|Anwendungsbeispiel]]
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_shutter DOIF ##
attr ui_Table_shutter uiTable {\
package ui_Table;;\
}\
shutter([R_Keller:pct],"\@yellow",2) ## zwei Symbole für 0 % und 100 %\
shutter([R_Wohnzimmer_S:pct]) ## entspricht shutter ([R_Wohnzimmer_S:pct],"\@DarkOrange",3) \
shutter([R_Wohnzimmer_W1:pct],"blue",4) ## vier Symbole \
shutter([R_Wohnzimmer_W2:pct],"\@red",5) ## fünf Symbole\
shutter([R_Wohnzimmer_W3:pct],"red",6 ## sechs Symbole)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable shutter.png|mini|ohne]]

=== Helligkeit: Visualisierung und Steuerung mit Hilfe der Funktion '''dimmer''' ===
Die aktuelle Helligkeit (0 % - 100 %) wird über Icons visualisiert. Das Anklicken eines Icons bestimmt die Helligkeit der Leuchte. Prozentwerte zwischen zwei Icon-Werten werden dem nächsthöheren Icon-Wert zugeordnet.
{{Randnotiz|RNText=uiTable-Funktion '''dimmer'''
<syntaxhighlight lang="perl">
dimmer ($value,$color,$type)

$value # [<device>:<reading>]
$color # Farbe der aktuellen Helligkeit, vorangestelltes @ verändert die Farbe des Icons, ohne @ wird der Hintergrund des Icons eingefärbt, default ist @DarkOrange
$type # Anzahl der Symbole 2 bis 7, 3 ist default
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_dimmer DOIF ##
attr di_uiTable_dimmer uiTable {\
package ui_Table;;\
}\
dimmer([Strauch3:pct],"\@yellow",2)\
dimmer([Strauch3:pct]) ## entspricht dimmer([Strauch3:pct],"\@DarkOrange",3) \
dimmer([Strauch3:pct],"blue",4)\
dimmer([Strauch3:pct],"\@red",5)\
dimmer([Strauch3:pct],"red",6)\
dimmer([Strauch3:pct],"DarkOrange",7)

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable dimmer.png|mini|ohne]]

=== Vorgabetemperatur eines Thermostats mit Hilfe der Funktion '''temp_knob''' ===
Die aktuelle Vorgabetemperatur eines Thermostats wird über ein Icons visualisiert. Durch Anklicken des Ringes wird die Vorgabetemperatur verändert.
{{Randnotiz|RNText=uiTable-Funktion '''temp_knob'''
<syntaxhighlight lang="perl">
temp_knob ($value,$color,$set)

$value # [<device>:<reading>]
$color # Farbe der voreingestellten Temperatur, default "Darkorange"
$set # set-Befehl, default "set", sonst muss "set <Readingname>" angegeben werden, falls sich das Reading vom set-Befehl vom angezeigten Reading unterscheidet, wie beim THRESHOLD-Modul
</syntaxhighlight>
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_temp_knob DOIF ##
attr ui_Table_temp_knob uiTable {\
package ui_Table;;\
}\
\
## HM-EU-Thermostat, angezeigt wird das Reading "desired-temp", geschaltet wird über "set desired-temp" \
"Dachgeschoss"|temp_knob([TH_DG_HM:desired-temp]) ## entspricht temp_knob([TH_DG_HM:desired-temp],"Darkorange","set") \
\
## HM-EU-Thermostat Temperaturanzeige in gelb \
"Wohnzimmer"|temp_knob([TH_WZ_HM:desired-temp],"yellow") \
\
## Beim THRESHOLD-Modul wird das Reading "desired_value" angezeigt, geändert wird die Temperatur per "set desired" \
"Küche"|temp_knob([TH_Kueche:desired_value],"red","set desired")
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable temp knob.png|mini|ohne]]

== uiTable-'''Templates''' ==
Die Definition einer oder mehrere Zellen kann zu einem Template zusammengefasst werden. Durch die Nutzung von Templates kann die Definition einer Tabelle erheblich vereinfacht werden. Insb. bei gleichartigen Zellen/Zeilen für verschiedene Geräte/Readings braucht eine aufwendige Definition nicht immer wieder wiederholt werden, sondern kann jeweils mit dem Aufruf eines zuvor definierten Templates realisiert werden.
{{Randnotiz|RNText='''Templates'''
* Die Definition von Templates muss vor der Tabellendefinition vorgenommen werden
* Eine Template-Definition beginnt mit dem Schlüsselwort '''DEF'''
* Der Template-Name muss mit '''TPL_''' beginnen
* '''Template-Definition'''-Syntax
<syntaxhighlight lang="perl">
DEF TPL_<Template-Name>(<Zellendefinition mit Platzhaltern: $1,$2,...>)
</syntaxhighlight>
* Templates-Definitionen können in externe Dateien ausgelagert werden
* Templates-Definitionen können per IMPORT-Befehl aus externen Dateien importiert werden
* '''Template-Import'''-Syntax
<syntaxhighlight lang="perl">
IMPORT <Pfad mit Dateinamen>
</syntaxhighlight>
* Innerhalb einer Tabellendefinition können zuvor definierte oder importierte Templates mehrfach genutzt werden
* '''Template-Aufruf'''-Syntax
<syntaxhighlight lang="perl">
TPL_<Template-Name>(<Übergabeparameter für $1>,<Übergabeparameter für $2>,...)
</syntaxhighlight>
}}
'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod ui_Table_Template DOIF ##
attr ui_Table_Template uiTable {\
package ui_Table;;\
$TC{1..3}="align='center'";; ## Spalten 1 bis 3 werden zentriert\
}\
\
## Template-Definitionen beginnen vor der Tabellendefinition\
\
## Das Template TPL_raum stellt eine Tabellenzeile dar, die mit Hilfe von uiTable-Funktionen mehrere Tabellenzellen definiert\
DEF TPL_raum ("$1" | temp([TH_$2_HM:measured-temp]),hum([TH_$2_HM:humidity]) | switch([H_$2:state],"fa_off") | temp_knob([TH_$2_HM:desired-temp]))\
\
## Tabellendefinition\
\
## pro Tabellenzeile wird ein Raum mit Hilfe des oben definierten Templates "TPL_raum" dargestellt\
"Raum"|"Temp./Feuchte"|"Ventil"|"Vorgabetemp."\
TPL_raum (Dachgeschoss,DG) ## der Übergabeparameter "Dachgeschoss" wird im Template "TPL_raum" anstelle von $1 eingesetzt, "DG" wird anstelle von $2 eingesetzt\
TPL_raum (Bad,Bad)\
TPL_raum (Kinderzimmer ost,Kz_o)\
TPL_raum (Kinderzimmer west,Kz_w)\
TPL_raum (Wohnzimmer,WZ)\
TPL_raum (Keller,Keller)

</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable Templates.png|mini|ohne]]

== Eigene uiTable-Funktionen programmieren ==
Für die eigenen Bedürfnisse können eigene uiTable-Funktionen programmiert werden. In der Datei [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DOIF/uiTable.tpl contrib/DOIF/uiTable.tpl] befinden sich alle intern definierten uiTable-Funktion aus dem package ui_Table als Kopie. Diese Funktionen können als Inspiration für eigene Entwicklung dienen.
{{Randnotiz|RNText='''uiTable-Funktionen'''
* Es gibt drei Arten von uiTable-Funktionen, sie werden intern anhand der Rückgabewerte unterschieden
* uiTable-Funktionen vom Typ 1: '''HTML''', ein Rückgabewert
<syntaxhighlight lang="perl">
return(<HTML-code>)
</syntaxhighlight>
* uiTable-Funktionen vom Typ 2: '''Style''' (entspricht der '''STY'''-Funktion), zwei Rückgabewerte
<syntaxhighlight lang="perl">
return(<value>,<CSS-style>)
</syntaxhighlight>
* uiTable-Funktionen vom Typ 3: '''Widget''' (entspricht der '''WID'''-Funktion), vier Rückgabewerte
<syntaxhighlight lang="perl">
return (<value>,<>,<FHEM-widget>,<set-command: "" or "set" or "set <Readingname>">)
</syntaxhighlight>
* uiTable-Funktionen sind reine Perlfunktionen
* uiTable-Funktionen sollten im eigenen Package definiert werden, sonst könnten bestehende Perlfunktionen im System überschrieben werden
* uiTable-Funktionen können in Template-Dateien ausgelagert werden und über IMPORT-Befehl importiert werden, siehe Templates
}}

'''<big>Beispieldefinition</big>'''
<syntaxhighlight lang="perl">
defmod di_uiTable_function DOIF ##
attr di_uiTable_function uiTable {\
package my_uiTable;; ## eigenes Package mit selbstdefinierten Funktionen\
\
## uiTable-Funktion vom Typ "HTML", Rückgabewert: (HTML-code)\
\
sub clock { ## Anzeige aktueller Uhrzeit mit Datum\
## Voraussetzung: contrib/DOIF/doifclock.js muss ins www/pgm2-Verzeichnis kopiert werden\
## Attribut setzen in der Webinstanz: attr <WEB-Instanz> JavaScripts pgm2/doifclock.js \
my ($color,$size)=@_;;\
$color="darkorange" if (!defined ($color));; ## $color ist optional, default Darkorange\
$size="20" if (!defined ($size));; ## $size ist optional, default 20pt\
return("<div class='doifclock'style='font-weight:bold;;font-size:".$size."pt;;color:".$color.";;'>error</div>")\
}\
\
## uiTable-Funktion vom Typ Style, Rückgabewerte (Wert,CSS-style)\
\
sub red_green { ## Farbige Skalierung von Zahlen mit Hilfe der DOIF_hsv-Funktion: von 0 - rot bis 10 - grün\
my ($value)=@_;;\
return ($value." KW", ## Wert/Text\
"font-weight:bold;;color:".::DOIF_hsv ($value,0,10,0,120,70,100) ## CSS-Style\
);;\
} \
\
## uiTable-Funktion vom Typ Widget, Rückgabewerte (Wert,Leer,FHEM-Widget,set-Befehl)\
\
sub slider { ## FHEM-Widget Slider, weitere FHEM-Widgets siehe: https://wiki.fhem.de/wiki/FHEMWEB/Widgets\
my ($value,$set)=@_;;\
$set="" if (!defined $set);;\
return ($value, ## Zahlenwert\
"", ## leer\
"slider,0,0.5,100,1", ## FHEM-Widget\
$set ## set-Befehl des FHEM-Widgets\
) \
}\
\
}\
\
## Tabellendefinition\
\
"Uhrzeit/Datum"\
clock("yellow",30) ## obige Funktion clock\
"Dimmer"\
slider([Wohnzimmer:pct]) ## obige Funktion slider\
"Leistung"\
red_green([Leistung:state]) ## obige Funktion red_green
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-functions.png|mini|ohne]]

== Package-Konzept, Auslagerung eigener Funktionen, der '''IMPORT'''-Befehl==
uiTable arbeitet mit Packages. In einem Package sind definierte Funktionen gekapselt, sie kollidieren nicht mit bereits definierten Funktionen in FHEM.
{{Randnotiz|RNText='''Package'''
* das für die Definition der Tabelle gültige Package wird im Perlblock des uiTable-Attributes angegeben
* interne uiTable-Funktionen befinden sich im Package '''ui_Table'''
* ohne eine Angabe eines Package befindet man sich im Package '''main'''
* Funktionen außerhalb des gültigen Package müssen mit <package-Name>::<Funktion> angegeben werden
* externe uiTable-Funktionen können per IMPORT-Befehl importiert werden
}}
=== Tabellendefinition im Package main ===
<syntaxhighlight lang="perl">
defmod beispiel1 DOIF ##
attr beispiel1 uiTable ## keine Package-Definition im Perlblock\
\
## Tabellendefinition befindet sich im Package main\
\
## Funktionen aus dem main-Package können unmittelbar angegeben werden\
FW_makeImage("scene_day")\
\
## Funktionen aus dem ui_Table-Package müssen mit vorangestelltem Package angegeben werden\
ui_Table::temp ([Aussensensor:tempaerature])
</syntaxhighlight>

=== Tabellendefinition im Package ui_Table ===
<syntaxhighlight lang="perl">
defmod beispiel2 DOIF ##
attr beispiel2 uiTable {\
package ui_Table; ## Package-Angabe im Perlblock\
}\
\
## Tabellendefinition befindet sich im Package ui_Table\
\
## Funktionen aus dem main-Package müssen mit vorangestelltem package angegeben werden, der Name main kann weggelassen werden\
::FW_makeImage("scene_day")\
\
## Funktionen aus dem ui_Table-Package können direkt angegeben werden\
temp ([Aussensensor:temperature])
</syntaxhighlight>

=== Eigene uiTable-Funktionen im eigenen Package ===
Diese Art der Definition bietet sich dann an, wenn man eine eigene uiTable-Funktion nur in einem DOIF nutzen möchte.
<syntaxhighlight lang="perl">
defmod beispiel3 DOIF ##
attr beispiel3 uiTable {\
package $SELF;; ## Package-Name ist der Name des DOIF-Moduls, dadurch ist der Package-Name eindeutig\
sub scene_day { ## eigene Funktion befindet sich im eigenen Package beispiel3\
return (::FW_makeImage("scene_day"));;\
}\
}\
## Tabellendefinition befindet sich im Package beispiel3\
\
## Funktionen aus dem main-Package müssen mit vorangestelltem Package angegeben werden (der Name main kann weggelassen werden)\
::FW_makeImage("scene_day")\
\
## interne Funktionen aus dem ui_Table-Package müssen mit vorangestelltem Package ui_Table angegeben werden\
ui_Table::temp ([Aussensensor:temperature])\
\
## eigene Funktionen können direkt angegeben werden\
scene_day()
</syntaxhighlight>

=== Eigene ausgelagerte uiTable-Funktionen ===
Möchte man das ui_Table-Package um eigene Funktionen erweitern, die man in verschiedenen DOIFs nutzen möchte, so sollte man diese in eine eigene Datei auslagern, die man mit dem IMPORT-Befehl vor der Definition der Tabelle importieren kann.

Ausgelagerte Funktion in einer eigenen Datei z. B. my_uiTable.tpl:

<syntaxhighlight lang="perl">
{ ## Inhalt der Datei my_uiTable.tpl
package ui_Table; ## das aktuelle Package ist ui_Table
sub scene_day { ## eigene Funktion wird zum Package ui_Table hinzugefügt
return (::FW_makeImage("scene_day"));
}
## die Datei kann alle Funktionen beinhalten, die man in diversen DOIFs nutzen möchte
}
</syntaxhighlight>

<syntaxhighlight lang="perl">
defmod beispiel4 DOIF ##
attr beispiel4 uiTable ##\
\
IMPORT ./contrib/DOIF/my_uiTable.tpl ## nach dem Import befindet man sich in Package ui_Table erweitert um eigene Funktionen\
\
## Tabellendefinition befindet sich im Package ui_Table\
\
## Funktionen aus dem main-Package müssen mit vorangestelltem Package angegeben werden (der Name main kann weggelassen werden)\
::FW_makeImage("scene_day")\
\
## interne uiTable-Funktionen aus dem ui_Table-Package können direkt angegeben werden\
temp ([Aussensensor:temperature])\
\
## eigene Funktionen können direkt angegeben werden, da man sich bereits im Package uiTable befinden\
scene_day()\
</syntaxhighlight>

== '''hsv'''-Funktion für Farbskalierungen==
Mit Hilfe der hsv-Funktion können Texte, Werte oder Icons abhängig vom Wert eingefärbt werden. Es wird durch Vorgabe von Farbsättigung (saturation) und Helligkeit (lightness), linear ein Farbton für einen bestimmten Wert errechnet. Den Farbwert HUE (0 - 360) für den kleinsten sowie größten Wert kann man mit Hilfe eines Color-Pickers bestimmen. Der Rückgabewert ist ein Farbwert in der CSS-Notation.
{{Randnotiz|RNText='''hsv-Funktion für Farbskalierungen'''
<syntaxhighlight lang="perl">
hsv ($value,$min_value,$max_value,$min_hue,$max_hue,$saturation,$lightness)
$value # Wert, Reading
$min_value # der kleinste Wert, dieser entspricht dem Farbwert $min_hue
$max_value # der größte Wert, dieser entspricht dem Farbwert $max_hue
$min_hue # Farbwert für den kleinsten Wert $min_value
$max_hue # Farbwert für den größten Wert $max_value
$saturation # Farbsättigung, default 100, optional
$lightness # Farbhelligkeit, default 100, optional
</syntaxhighlight>
Die Funktion befindet sich im ui_Table-Package
}}

'''<big>Beispieldefinition</big>'''

<syntaxhighlight lang="perl">
defmod di_uiTable_hsv DOIF ##
attr di_uiTable_hsv uiTable {\
package ui_Table;;\
## eigene uiTable-Funktionen vom Typ 1 mit einem Rückgabewert als HTML-Code\
\
sub bat_icon { ## färbt das Icon 'measure_battery_100' abhängig vom Wert mit Hilfe der Funktion hsv \
my ($value)=@_;;\
return(ICON("measure_battery_100\@".hsv($value,0,100,0,120,100,100)))\
}\
\
sub bat_icon2 {## zusätzlich zum Farbwert wird ein entsprechendes Icon bestimmt\
my($val)=@_;;\
my $icon;;\
if ($val==0) {\
$icon="measure_battery_0";;\
} elsif ($val<=25) {\
$icon="measure_battery_25";;\
} elsif ($val<=50) {\
$icon="measure_battery_50";;\
} elsif ($val<=75) {\
$icon="measure_battery_75";;\
} else {\
$icon="measure_battery_100";;\
}\
\
my $output=ICON("$icon\@".hsv ($val,0,100,0,120,90,100));;\
return($output);;\
}\
}\
\
## Tabellendefinition\
\
## eingefärbtes Icon 0 % entspricht rot (HSV-Wert 0), 100 % entspricht grün (HSV-Wert 120) mit Direktangabe\
1|ICON("measure_battery_100\@".hsv([bat:level],0,100,0,120,100,100))\
\
## gleiche Funktionalität mit Hilfe der oben definierten Funktion bat_icon \
2|bat_icon([bat:level])\
\
## Icon mit Hilfe der oben definierten Funktion bat_icon2\
3|bat_icon2([bat:level])\
\
## Beispiel für die Farbskaliereung von 0 bis 100 % mit der obigen Funktion bat_icon\
4|bat_icon(0)|bat_icon(10)|bat_icon(20)|bat_icon(30)|bat_icon(40)|bat_icon(50)|bat_icon(60)|bat_icon(70)|bat_icon(80)|bat_icon(90)|bat_icon(100)\
\
## Beispiel für die Farbskaliereung von 0 bis 100 % mit der obigen Funktion bat_icon2\
5|bat_icon2(0)|bat_icon2(10)|bat_icon2(20)|bat_icon2(30)|bat_icon2(40)|bat_icon2(50)|bat_icon2(60)|bat_icon2(70)|bat_icon2(80)|bat_icon2(90)|bat_icon2(100)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable DOIF hsv.png|mini|ohne]]

== Eine for-Schleife mit Hilfe des '''FOR'''-Befehls ==
Mit Hilfe des '''FOR'''-Befehls können über eine Schleife aus einer Liste mit Elementen mehrere Tabellenzellen definiert werden. Die Elementenliste (Array) kann über eine Funktion bestimmt werden. Auf diese Weise kann z. B. eine Tabelle für mehrere Geräte einfach definiert werden.
{{Randnotiz|RNText='''FOR-Befehl'''
* Der FOR-Befehl entspricht einer foreach-Schleife in Perl
* Syntax: '''FOR (<Array>,<Zellendefinitionen>)''' '''<Array>''' eine gültige Angabe eines Arrays oder eine Perlfunktion, die ein Array liefert '''<Zellendefinitionen>''' Definition einer oder mehrerer Zellen, die Angabe $_ wird durch das jeweilige Element des Arrays ersetzt
*'''nützliche Links'''
**{{Link2CmdRef|Anker=DOIF_aggregation|Lang=de|Label=DOIF Aggregationsfunktionen mit Perlfunktion AggrDoIf}}
**[[DevelopmentModuleAPI#devspec2array|devspec2array]]
}}
'''<big>Beispieldefinitionen</big>'''
<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Temperaturen aller Geräte, die mit 'T' beginnen und ein Reading 'temperature' haben, sollen in einer Tabelle visualisiert werden\
FOR(::AggrDoIf('@','^T_','temperature'),"$_"|temp([$_:temperature:d2]))
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-temperature.png|200px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Anzeige des Batteriestatus aller Geräte, bei denen das Wort 'Fenster' vorkommt, die das Readings 'battery' haben\
FOR(::AggrDoIf('@','Fenster','battery'),"$_"|bat([$_:battery]))
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-battery.png|200px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Anzeige des Status aller Geräte im System vom Typ 'HMS'\
FOR(::devspec2array("TYPE=HMS"),"$_"|[$_])
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-HMS.png|300px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Elemente einer kommagetrennten Liste sollen jeweils in einer Tabellenzelle in einer Tabellenzeile angezeigt werden\
FOR(split(",","Mo,Di,Mi,Do,Fr,Sa,So"),ui_Table::style("$_","Darkorange")|)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-split.png|300px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## Durch Leerzeichen getrennte Zeichenketten sollen jeweils in einer Tabellenzelle in einer Tabellenzeile angezeigt werden\
FOR(qw/Montag Dienstag Mittwoch Donnerstag Freitag/,"$_"|)
</syntaxhighlight>
''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR-qw.png|300px|ohne]]

<syntaxhighlight lang="perl">
defmod di_for DOIF ##
attr di_for uiTable \
## das Templates TPL_raum, soll vier mal aufgerufen werden: TPL_raum(1), TPL_raum(2)...\
## das Templates TPL_raum muss vorher definiert worden sein\
FOR(1..4,TPL_raum($_))
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable-FOR TPL raum.png|600px|ohne]]

== '''Anwendungsbeispiele''' ==
=== '' Visualisierung und Steuerung von '''Rollläden''''' ===
Im folgenden Beispiel werden Rollläden morgens hochgefahren, ebenso wird die Position aller Rollläden visualisiert. Durch Anklicken eines Icons wird der Rollladen auf die entsprechende Position bewegt.
{{Randnotiz|RNText='''nützliche Links'''
* {{Link2CmdRef|Anker=DOIF_Zeitsteuerung_mit_Zeitintervallen|Lang=de|Label=Zeitsteuerung}}
* uiTable-Funktion [[DOIF/uiTable Schnelleinstieg#Rollladen: Visualisierung und Steuerung mit Hilfe der Funktion shutter|shutter]]
* uiTable-Funktion [[DOIF/uiTable Schnelleinstieg#Textformatierungen mit Hilfe der Funktion style|style]]
* [[DOIF/uiTable Schnelleinstieg#uiTable-Templates|Templates]]
}}
<syntaxhighlight lang="perl">
defmod DI_Rollladen DOIF (([Dunkelheit] eq "off" and [06:25-09:00|8]) or [09:00|7]) \
((set R_W_S,R_W_W[1-3] on)) ## Hochfahren der Rollläden im Erdgeschoss morgens\
DOELSEIF ([Dunkelheit] eq "on")
attr DI_Rollladen cmdState oben|unten
attr DI_Rollladen devStateIcon unten:status_night oben:scene_day
attr DI_Rollladen icon fts_shutter_automatic
attr DI_Rollladen uiTable {\
package ui_Table;;\
}\
\
## Template für ein Fenster\
DEF TPL_shutter("$1"|shutter([$1:pct]))\
\
## Tabellendefinition\
\
style("Dachgeschoss","Darkorange")|""\
TPL_shutter(R_Dachboden)\
style("erstes Geschoss","Darkorange")|""\
TPL_shutter(R_Bad)\
TPL_shutter(R_Kinderzimmer1_O)\
TPL_shutter(R_Kinderzimmer1_S)\
TPL_shutter(R_Kinderzimmer2_S)\
TPL_shutter(R_Kinderzimmer2_W1)\
TPL_shutter(R_Kinderzimmer2_W2)\
style("Erdgeschoss","Darkorange")|""\
TPL_shutter(R_Kueche)\
TPL_shutter(R_W_S)\
TPL_shutter(R_W_W1)\
TPL_shutter(R_W_W2)\
TPL_shutter(R_W_W3)\
style("Keller","Darkorange")|""\
TPL_shutter(R_Keller)\
</syntaxhighlight>
''Ergebnis des Anwendungsbeispiels in der Webansicht:''
[[Datei:UiTable Rollladen.png|mini|ohne]]

=== ''Anzahl der Tage bis zur '''Abfall-Entsorgung''''' ===
Mit Hilfe des Kalender-Moduls werden die verbleibenden Tage bis zur Abfall-Entsorgung der jeweiligen Tonne berechnet und mit Hilfe von uiTable visualisiert. Wenn der Tag der Entsorgung bevorsteht, wird er farbig gekennzeichnet. Vorausgesetzt wird die Definition des Kalenders namens 'cal' mit Hilfe des Moduls [[Calendar]]. Dieser muss die Termine der Abfallentsorgung der Tonnen beinhalten. Im Beispiel wird nach Stichwörtern: "Altpapier", "Restmüll", "Bio", "Gelber" und "Grünschnitt" im Kalender gesucht.
{{Randnotiz|RNText='''nützliche Links'''
* FHEM-Modul [[Calendar]]
* ui_Table Funktion [[DOIF/uiTable Schnelleinstieg#Icon-Darstellung mit Text mit Hilfe der Funktion icon_label|icon_label]]
}}
<syntaxhighlight lang="perl">
defmod Abfall DOIF subs {\
## Die Funktion 'days' sucht nach dem Ereignis $event im Kalender und berechnet die Anzahl der verbleibenden Tage und legt sie im entsprechendem Reading $reading des DOIF-Moduls ab\
sub days \
{\
my ($event,$reading)=@_;;\
set_Reading($reading,fhem('get cal events timeFormat:"%j" filter:field(summary)=~"'.$event.'" limit:count=1,from=0 format:custom="$T1"')-::strftime ('%j', localtime()),1)\
}\
## Die Funktion 'update' bestimmt die verbleibenden Tage mit Hilfe der obigen Funktion 'days' für die jeweiligen Tonnen\
sub update\
{\
days("Altpapier","altpapier");;days("Restmüll","restmuell");;days("Bio","bio");;days("Gelber","gelbe_tonne");;days("Grünschnitt","gruenschnitt");;\
}\
}\
## Beim Start, um 02:00 Uhr und 08:00 Uhr wird zeitverzögert die obige Funktion 'update' aufgerufen\
init {[02:00];;[08:00];;set_Exec("Timer",60,'update()');;\
}
attr Abfall uiTable {\
package ui_Table;;\
$TC{0..4}="align='center'";;\
$SHOWNOSTATE=1;;\
\
## die Funktion 'ic' benutzt die Funktion 'icon_label' für die Darstellung des Icons, abhängig von der Anzahl der Tage wird die Anzahl in grün bzw. rot eingefärbt \
sub ic\
{\
my ($icon,$days)=@_;;\
icon_label($icon,$days,"white",$days > 1 ? "green":"red")\
}\
}\
## Tabellendefinition, die einzelnen Tonnen werden mit Hilfe der obigen Funkton 'ic' dargestellt\
\
ic ("Abfalltonne-Recycling-Logo\@yellow",[$SELF:gelbe_tonne])|\
ic ("Abfalltonne-Recycling-Logo\@blue",[$SELF:altpapier])|\
ic ("Abfalltonne\@gray",[$SELF:restmuell])|\
ic ("Abfalltonne-Recycling-Logo\@green",[$SELF:bio])|\
ic ("Gartenabfall\@green",[$SELF:gruenschnitt])
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Anwendungsbeispiel Abfall.png|mini|ohne]]

=== ''Visualisierung: '''offene Fenster''''' ===
Alle offenen Fenster werden aufgelistet und mit entsprechendem Icon visualisiert.
{{Randnotiz|RNText='''nützliche Links'''
* Attribut {{Link2CmdRef|Anker=DOIF_DOIF_Readings|Lang=de|Label=DOIF_Readings}}
* DOIF-{{Link2CmdRef|Anker=DOIF_aggregation|Lang=de|Label=Aggregationsfunktionen}}
* uiTable-Funktion [[DOIF/uiTable Schnelleinstieg#Icon-Darstellung mit Hilfe der Funktion icon|icon]]
}}
<syntaxhighlight lang="perl">
defmod di_uiTable_windows DOIF ## Visualisierung offener Fenster, Fenster-Devices enden mit "Fenster" im Namen
attr di_uiTable_windows DOIF_Readings windows:[@as( )"Fenster$":state:"open","keine"]
attr di_uiTable_windows uiTable {package ui_Table;;}\
icon([$SELF:windows],"fts_window_1w_open\@DarkOrange","fts_window_1w",".*","keine")|[$SELF:windows]
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable windows closed.png|mini|ohne]]
[[Datei:UiTable windows open.png|mini|ohne]]

=== ''Visualisierung: '''aktuelle Wetterlage''''' ===
Regenrader animiert, aktuelle Temperatur und Feuchte vom Sensor, aktuelle Wetterlage sowie Wettervorhersage der nächsten Tage. Über entsprechende Weblinks werden Bilder aus dem WWW in der Tabelle visualisiert. Im Gegensatz zu lokalen Sensoren, muss für die Aktualisierung der WWW-Elemente in der jeweiligen Webinstanz (FHEMWEB) das refresh-Attribut gesetzt werden.
{{Randnotiz|RNText='''nützliche Links'''
* DWD [https://www.dwd.de/DE/Home/home_node.html Homepage]
* Regenradar [https://www.dwd.de/DE/wetter/wetterundklima_vorort/_node.html Radarfilm BRD]
* aktuelles Wetter [https://www.dwd.de/DE/wetter/wetterundklima_vorort/nordrhein-westfalen/nrw_node.html NRW]
* Wetteronline [https://www.wetteronline.de/wetter-widget eignes Widget]
*
}}

<syntaxhighlight lang="perl">
defmod di_uiTable_wetter DOIF ##
attr di_uiTable_wetter uiTable {\
package ui_Table;;\
$TC{1}="align='center'";;\
}\
## das Attribut 'refresh' der Webinstanz für ein Wandtablet wurde auf 900 gesetzt, damit die Bilder alle 15 Minuten aktualisiert werden \
## Tabellendefinition\
\
## Regenradar BRD\
'<img src="https://www.dwd.de/DWD/wetter/radar/radfilm_brd_akt.gif" height="365px" width="365px">'|\
\
## Aktuelle Temperatur und Feuchtigkeit vom lokalen sensor\
temp([Aussensensor:temperature],40),hum ([Aussensensor:humidity],30),\
\
## aktuelle Wetterlage NRW\
"<img src ='https://www.dwd.de/DE/wetter/wetterundklima_vorort/nordrhein-westfalen/_functions/bildgalerie/wetter_aktuell.jpg?view=nasImage&nn=561200' height='255px' width='255px'>"|\
\
## Wettervorhersage\
"<iframe marginheight='0' marginwidth='0' scrolling='no' width='300' height='365' name='FC3' style='border:1px solid;;border-color:#00537f;;' src='https://api.wetteronline.de/wetterwidget?gid=x0677&modeid=FC3&seourl=juelich&locationname=Jülich&lang=de'></iframe>"\
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable wetter.png|600px|links]]
 

=== ''Visualisierung: '''Wetterstation''''' ===
Die vorgestellte Lösung funktioniert ohne Anmeldung beim Wetterdienst und ohne Nutzung von API.
Über den Wetterdienst: https://www.wunderground.com/ werden sehr viele private Wifi-Wetterstationen eingebunden. Das kann man sich zunutze machen, indem man zunächst in seiner Umgebung nach Wetterstationen des Dienstes sucht - oft findet man im Umkreis von wenigen Kilometern schon einige Stationen, die rege Wetterdaten liefern. Danach definiert man über HTTPMOD seine Station und visualisiert diese anschließend.

{{Randnotiz|RNText='''nützliche Links'''
* Wunderground [https://wunderground.com/ Homepage]
* svg-Funktion [https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card card]
* svg-Funktionen [https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#icon_ring-Funktionen icon_ring]
}}
Definition einer Station in der Nachbarschaft. <StationsID> muss gegen die korrekte Stationsnummer ersetzt werden.
<syntaxhighlight lang="perl">
defmod Wetter HTTPMOD https://www.wunderground.com/dashboard/pws/<StationsID>
attr Wetter enableControlSet 1
attr Wetter reading01Name Wind
attr Wetter reading01Regex wu-unit .{109}>(\d+\.\d)
attr Wetter reading02Name Windboeen
attr Wetter reading02Regex wu-unit-speed .{109}>(\d+\.\d)
attr Wetter reading03Name Windrichtung
attr Wetter reading03Regex (\d+)deg\).{84}Wind-Marker
attr Wetter reading04Name Regen
attr Wetter reading04Regex wu-unit-rainRate .{109}>(\d+\.\d\d)
attr Wetter reading05Name RegenGesamt
attr Wetter reading05Regex wu-unit-rain .{109}>(\d+\.\d\d)
attr Wetter reading06Name Temperatur
attr Wetter reading06Regex wu-unit-temperature .{127}>(\d+.\d)
attr Wetter reading07Name Feuchtigkeit
attr Wetter reading07Regex wu-unit-humidity .{109}>(\d\d)
attr Wetter reading08Name UV
attr Wetter reading08Regex UV<.{268}>(\d)
attr Wetter reading09Name Luftdruck
attr Wetter reading09Regex PRESSURE<.{285}>(\d+.\d+)
attr Wetter reading10Name TemperaturGefuehlt
attr Wetter reading10Regex wu-unit is-degree-visible .{109}>(\d+.\d)
attr Wetter reading11Name TaupunktTemp
attr Wetter reading11Regex DEWPOINT.{306}>(\d+.\d)
attr Wetter reading12Name Sonnenstrahlung
attr Wetter reading12Regex Solar radiation<.{549}>(\d+.\d+)
attr Wetter timeout 10
attr Wetter userReadings WindKm {sprintf("%1.1f",ReadingsVal($name,"Wind",0)*1.60934)},\
WindboeenKm {sprintf("%1.1f",ReadingsVal($name,"Windboeen",0)*1.60934)},\
WindrichtungGrad {ReadingsVal($name,"Windrichtung",0)-180},\
RegenMm {ReadingsVal($name,"Regen",0)*25.4},\
RegenGesamtMm {ReadingsVal($name,"RegenGesamt",0)*25.4},\
TemperaturC {sprintf("%1.1f",(ReadingsVal($name,"Temperatur",0)-32)*5/9)},\
TaupunktTempC {sprintf("%1.1f",(ReadingsVal($name,"TaupunktTemp",0)-32)*5/9)},\
LuftdruckHpa {sprintf("%d",ReadingsVal($name,"Luftdruck",0)*33.8639)},\
TemperaturGefuehltC {sprintf("%1.1f",(ReadingsVal($name,"TemperaturGefuehlt",0)-32)*5/9)}
</syntaxhighlight>

Nun erfolgt die Visualisierung der Daten.

<syntaxhighlight lang="perl">
defmod di_Wetter_ring DOIF ##
attr di_Wetter_ring uiTable {package ui_Table;;}\
\
icon_temp_hum_ring("temp_outside",[Wetter:TemperaturC],[Wetter:Feuchtigkeit],undef,undef,150)|\
icon_temp_ring ("temp_windchill",[Wetter:TemperaturGefuehltC],undef,undef,150) |\
icon_temp_ring ("temperature_humidity",[Wetter:TaupunktTempC],undef,undef,150) |\
icon_ring2([Wetter:WindKm] > 0 ? "wind".",1,0,0,".[Wetter:WindrichtungGrad]:"no_wind",[Wetter:WindKm],0,50,120,0,"km/h",150,undef,1,[Wetter:WindboeenKm],0,50,120,0,"km/h",undef,1) |\
icon_ring2("weather_rain_gauge",[Wetter:RegenMm],0,10,180,270,"mm/h",150,undef,1,[Wetter:RegenGesamtMm],0,50,180,270,"mm",undef,1)|\
icon_ring2("sani_solar",[Wetter:UV],0,10,100,30,"UV",150,undef,0,[Wetter:Sonnenstrahlung],0,1000,100,30,"Watt/m²",undef,0)|\
icon_ring ("weather_barometric_pressure",[Wetter:LuftdruckHpa],980,1047,0,120,"hPa",0,150)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable ringwetter.png|600px|links]]
 

Hier ein Beispiel der Visualisierung mit Verlauf der letzten drei Tage mit Hilfe der svg-Funktion '''card''':

<syntaxhighlight lang="perl">
defmod di_Wetter DOIF ##
attr di_Wetter icon weather_wind
attr di_Wetter uiTable {package ui_Table;;}\
## card ($collect,$header,$icon,$min,$max,$minColor,$maxColor,$unit,$func,$decfont,$size,$model,$lightness)\
\
card([Wetter:TemperaturC:col3d],"Außentemperatur","temp_outside",-10,60,undef,undef,"°C",\&temp_hue)|\
card([Wetter:TemperaturGefuehltC:col3d],"gefühlte Temperatur","temp_windchill",-10,60,undef,undef,"°C",\&temp_hue)|\
card([Wetter:TaupunktTempC:col3d],"Taupunkttemperatur","temperature_humidity",-10,60,undef,undef,"°C",\&temp_hue)|\
card([Wetter:Feuchtigkeit:col3d],"Außenfeuchtigkeit","temperature_humidity",0,100,undef,undef,"%",\&hum_hue)|\
card([Wetter:WindKm:col3d],"Wind",[Wetter:WindKm] > 0 ? "wind".",1,0,0,".[Wetter:WindrichtungGrad]:"no_wind",0,30,90,30,"km/h",undef,1)\
card([Wetter:WindboeenKm:col3d],"Windböen","weather_wind",0,30,90,30,"km/h",undef,1)|\
card([Wetter:RegenMm:col3d],"Regen","weather_rain_gauge",0,10,180,270,"mm/h")|\
card([Wetter:RegenGesamtMm:col3d],"Regengesamt","weather_rain_gauge",0,50,180,270,"mm")|\
##card([Wetter:UV:col3d],"UV-Strahlung","sani_solar",0,7,100,30,"UV",undef,0)|\
card([Wetter:Sonnenstrahlung:col3d],"Sonnenstrahlung","sani_solar",0,1000,30,90,"Watt/m²",undef,0)|\
card([Wetter:LuftdruckHpa:col3d],"Luftdruck","weather_barometric_pressure",980,1047,30,90,"hPa",undef,0)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable svgwetter.png|600px|links]]
 

Ohne Angabe der Überschrift (undef für $header setzen) lässt sich eine kompaktere Darstellung erzielen:

[[Datei:UiTable svgwetteroh.png|600px|links]]

 

=== ''Visualisierung: '''aktueller Spritpreis''''' ===
Der aktuelle Spritpreis einer Tankstelle wird ermittelt und mit seinem zeitlichen Verlauf visualisiert.
{{Randnotiz|RNText='''nützliche Links'''
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#ring-Funktionen|ring]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card|card]]
* Tankstelle bestimmen [https://www.clever-tanken.de/ Clever tanken]
* Modul [[HTTPMOD]]
}}

Zunächst wird ein HTTPMOD-Modul für den aktuellen Spritpreis definiert, dabei ist <Stations-ID> durch die ID der Tankstelle zu ersetzen.

<syntaxhighlight lang="perl">
defmod Tankstelle HTTPMOD http://www.clever-tanken.de/tankstelle_details/<Stations-ID> 300
attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)." ".ui_Table::ring(ReadingsVal("$name","SuperE5",0),1.10,1.60,120,0,"E5",90,undef,2)}
attr Tankstelle enableControlSet 1
attr Tankstelle event-on-change-reading .*
attr Tankstelle group Spritpreise
attr Tankstelle reading01Name Diesel
attr Tankstelle reading01Regex "current-price-1">(\d.\d{2})
attr Tankstelle reading02Name SuperE5
attr Tankstelle reading02Regex "current-price-2">(\d.\d{2})
attr Tankstelle room Spritpreise
attr Tankstelle timeout 10
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Di uiTable Tankstelle.png|ohne|mini]]

Visualisierung der Preisentwicklung der letzten 24 Stunden:

<syntaxhighlight lang="perl">
defmod sprit DOIF ##
attr sprit uiTable {package ui_Table;;}\
card([Tankstelle:Diesel:col24],"Diesel","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,1")\
card([Tankstelle:SuperE5:col24],"Super E5","fuel","1.10","1.60",120,0,"Super €",undef,"2",",,1")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Di uiTable sprit.png|ohne|mini]]

=== ''Visualisierung: '''aktuelle Corona-7-Tage-Inzidenz''''' ===
Die aktuellen Inzidenzwerte werden vom RKI ausgelesen und deren Verlauf visualisiert.

{{Randnotiz|RNText='''nützliche Links'''
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#ring-Funktionen|ring]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card|card]]
* Modul [[JsonMod]]
}}

Zunächst wird ein JsonMod Device für das Auslesen der Inzidenzzahlen definiert. Die gewünschten Regionen müssen für eigene Bedürfnisse angepasst werden.

<syntaxhighlight lang="perl">
defmod RKI7 JsonMod https://services7.arcgis.com/mOBPykOjAyBO2ZKk/arcgis/rest/services/RKI_Landkreisdaten/FeatureServer/0/query?where=1%3D1&outFields=last_update,cases7_per_100k,BEZ,BEM,GEN,BL,county&returnGeometry=false&outSR=4326&f=json
attr RKI7 readingList multi(jsonPath("\$.features[?(\@.attributes.GEN in ['Städteregion Aachen', 'Düren', 'Heinsberg'])]"), property('attributes.GEN'), sprintf('%.1f', property('attributes.cases7_per_100k')));;
</syntaxhighlight>

Visualisierung der Inzidenzzahlen der letzten sieben Tage:

<syntaxhighlight lang="perl">
defmod di_corona DOIF ##
attr di_corona uiTable {package ui_Table}\
card([RKI7:Duren:col1w],"Düren","coronavirus",0,200,120,0,"Fälle")|\
card([RKI7:Heinsberg:col1w],"Heinsberg","coronavirus",0,200,120,0,"Fälle")|\
card([RKI7:Stadteregion_Aachen:col1w],"Aachen","coronavirus",0,200,120,0,"Fälle")
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:uiTable_Inzidenz.png|600px|links]]

 

=== '' Visualisierung und Steuerung: '''Heiztherme''''' ===
Im folgenden Beispiel wurde eine Heiztherme über einen ebus-Adapter in FHEM eingebunden. Die Heizungsdaten werden über MQTT ausgelesen und anschließend visualisiert. Die vorgestellten Visualisierungsbeispiele können ebenso im funktionslosen DOIF mit Hilfe des uiTable-Attriutes auf bereits existierende Readings des eigenen Systems angewendet werden.

{{Randnotiz|RNText='''nützliche Links'''
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#icon_ring-Funktionen|icon_ring]]
* svg-Funktion [[DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card|card]]
* Commandref [https://fhem.de/commandref_DE.html#DOIF_Perl_Modus DOIF Perl-Modus]
* ebus-Adapter [https://ebusd.de/ ebusd]
* ebus-Wiki [[EBUS|ebus]]
}}

Definition eines MQTT2-Devices für die Kommunikation mit der Therme über einen ebus-Adapter.

Im diesem Fall wurde eine Vaillanttherme eingebunden, die meisten Readings wurden automatisch vom MQTT2-Server angelegt. Die Anbindung ist gerätespezifisch und unterscheidet sich je nach Gerättyp.

<syntaxhighlight lang="perl">
defmod vaillant MQTT2_DEVICE ebusd_bai
attr vaillant IODev MQTT2_FHEM_Server
attr vaillant devStateStyle style="text-align:left"
attr vaillant event-on-change-reading .*
attr vaillant group Ebus
attr vaillant icon sani_boiler_temp
attr vaillant jsonMap Status01_0_value:Vorlauf Status01_0_name:0\
Status01_1_value:Ruecklauf Status01_1_name:0\
Status01_2_value:Aussentemp Status01_2_name:0\
Status01_3_value:Warmwasser Status01_3_name:0\
Status01_4_value:WWSpeicher Status01_4_name:0\
Status01_5_value:Pumpenstatus Status01_5_name:0\
Flame_0_value:Flame Flame_0_name:0\
Storageloadpump_percent0_value:Storageloadpump\
FlowTempDesired_temp_value:VorlaufSoll\
Hc1HeatCurve_0_value:HeizKennlinie Hc1HeatCurve_0_name:0\
HolidayEndPeriod_hto_value:FerienEnde\
HolidayStartPeriod_hfrom_value:FerienBeginn\
PumpPower_0_value:PumpenLeistung PumpPower_0_name:0\
PrimaryCircuitFlowrate_uin100_value:Umlaufmenge\
z1DayTemp_tempv_value:TagSolltemp\
z1NightTemp_tempv_value:NachtSolltemp\
FanSpeed_0_value:LuefterDrehzahl FanSpeed_0_name:0\
WaterPressure_pressv_value:Wasserdruck\
z1OpMode_opmode_value:Heizmodus
attr vaillant model eBus_bai_jsonmap
attr vaillant readingList ebusd/bai/PumpHours:.* { json2nameValue($EVENT, 'PumpHours_', $JSONMAP) }\
ebusd/bai/WPPostrunTime:.* { json2nameValue($EVENT, 'WPPostrunTime_', $JSONMAP) }\
ebusd/bai/PowerValue:.* { json2nameValue($EVENT, 'PowerValue_', $JSONMAP) }\
ebusd/bai/StorageExitTemp:.* { json2nameValue($EVENT, 'StorageExitTemp_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/scan\x5c\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }\
ebusd/scan\x5c\x2e08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/global/uptime:.* uptime\
ebusd/global/signal:.* signal\
ebusd/scan\x5c\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\x5c\x2e15/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT, 'FanSpeed_', $JSONMAP) }\
ebusd/bai/PumpPower:.* { json2nameValue($EVENT, 'PumpPower_', $JSONMAP) }\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }\
ebusd/global/updatecheck:.* updatecheck\
ebusd/bai/DCFTimeDate:.* { json2nameValue($EVENT, 'DCFTimeDate_', $JSONMAP) }\
ebusd/bai/PumpPowerDesired:.* { json2nameValue($EVENT, 'PumpPowerDesired_', $JSONMAP) }\
ebusd/bai/HwcImpellorSwitch:.* { json2nameValue($EVENT, 'HwcImpellorSwitch_', $JSONMAP) }\
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT, 'ReturnTemp_', $JSONMAP) }\
ebusd/700/HwcStorageTempBottom:.* { json2nameValue($EVENT, 'HwcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/bai/FanPWMSum:.* { json2nameValue($EVENT, 'FanPWMSum_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HoursTillService:.* { json2nameValue($EVENT, 'HoursTillService_', $JSONMAP) }\
ebusd/bai/PumpHwcFlowNumber:.* { json2nameValue($EVENT, 'PumpHwcFlowNumber_', $JSONMAP) }\
ebusd/bai/WP:.* { json2nameValue($EVENT, 'WP_', $JSONMAP) }\
ebusd/700/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/bai/PrimaryCircuitFlowrate:.* { json2nameValue($EVENT, 'PrimaryCircuitFlowrate_', $JSONMAP) }\
ebusd/bai/Flame:.* { json2nameValue($EVENT, 'Flame_', $JSONMAP) }\
ebusd/bai/Storageloadpump:.* { json2nameValue($EVENT, 'Storageloadpump_', $JSONMAP) }\
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT, 'FlowTempDesired_', $JSONMAP) }\
ebusd/700/FrostOverRideTime:.* { json2nameValue($EVENT, 'FrostOverRideTime_', $JSONMAP) }\
ebusd/700/Hc1ActualFlowTempDesired:.* { json2nameValue($EVENT, 'Hc1ActualFlowTempDesired_', $JSONMAP) }\
ebusd/700/Hc1AutoOffMode:.* { json2nameValue($EVENT, 'Hc1AutoOffMode_', $JSONMAP) }\
ebusd/700/Hc1CircuitType:.* { json2nameValue($EVENT, 'Hc1CircuitType_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/HcStorageTempBottom:.* { json2nameValue($EVENT, 'HcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HcStorageTempTop:.* { json2nameValue($EVENT, 'HcStorageTempTop_', $JSONMAP) }\
ebusd/700/HolidayTemp:.* { json2nameValue($EVENT, 'HolidayTemp_', $JSONMAP) }\
ebusd/700/OpMode:.* { json2nameValue($EVENT, 'OpMode_', $JSONMAP) }\
ebusd/700/z1RoomTemp:.* { json2nameValue($EVENT, 'z1RoomTemp_', $JSONMAP) }\
ebusd/700/z1SFMode:.* { json2nameValue($EVENT, 'z1SFMode_', $JSONMAP) }\
ebusd/700/z1OpMode:.* { json2nameValue($EVENT, 'z1OpMode_', $JSONMAP) }\
ebusd/700/Time:.* { json2nameValue($EVENT, 'Time_', $JSONMAP) }\
ebusd/bai/EbusVoltage:.* { json2nameValue($EVENT, 'EbusVoltage_', $JSONMAP) }\
ebusd/bai/extWP:.* { json2nameValue($EVENT, 'extWP_', $JSONMAP) }\
ebusd/bai/FanStarts:.* { json2nameValue($EVENT, 'FanStarts_', $JSONMAP) }\
ebusd/700/z1NightTemp:.* { json2nameValue($EVENT, 'z1NightTemp_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/700/HolidayStartPeriod:.* { json2nameValue($EVENT, 'HolidayStartPeriod_', $JSONMAP) }\
ebusd/700/HolidayEndPeriod:.* { json2nameValue($EVENT, 'HolidayEndPeriod_', $JSONMAP) }\
ebusd/700/z1Timer.Monday:.* { json2nameValue($EVENT, 'z1Timer.Monday_', $JSONMAP) }\
ebusd/700/z1Timer.Tuesday:.* { json2nameValue($EVENT, 'z1Timer.Tuesday_', $JSONMAP) }\
ebusd/700/z1Timer.Wednesday:.* { json2nameValue($EVENT, 'z1Timer.Wednesday_', $JSONMAP) }\
ebusd/700/z1Timer.Thursday:.* { json2nameValue($EVENT, 'z1Timer.Thursday_', $JSONMAP) }\
ebusd/700/z1Timer.Friday:.* { json2nameValue($EVENT, 'z1Timer.Friday_', $JSONMAP) }\
ebusd/700/z1Timer.Sunday:.* { json2nameValue($EVENT, 'z1Timer.Sunday_', $JSONMAP) }\
ebusd/700/z1Timer.Saturday:.* { json2nameValue($EVENT, 'z1Timer.Saturday_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHc1:.* { json2nameValue($EVENT, 'PrEnergyCountHc1_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHwc1:.* { json2nameValue($EVENT, 'PrEnergyCountHwc1_', $JSONMAP) }\
ebusd/bai/PrEnergySumHc1:.* { json2nameValue($EVENT, 'PrEnergySumHc1_', $JSONMAP) }\
ebusd/bai/PrEnergySumHwc1:.* { json2nameValue($EVENT, 'PrEnergySumHwc1_', $JSONMAP) }\
ebusd/bai/FanHours:.* { json2nameValue($EVENT, 'FanHours_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HwcHours:.* { json2nameValue($EVENT, 'HwcHours_', $JSONMAP) }\
ebusd/bai/HcStarts:.* { json2nameValue($EVENT, 'HcStarts_', $JSONMAP) }\
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT, 'HwcStarts_', $JSONMAP) }
attr vaillant setList HeizKennlinie:selectnumbers,0,.1,2,1,lin ebusd/700/Hc1HeatCurve/set $EVTPART1\
TagSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1DayTemp/set $EVTPART1\
NachtSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1NightTemp/set $EVTPART1
</syntaxhighlight>

Definition eines DOIF-Devices zur Steuerung der Therme und Visualisierung der Daten. Es werden Readings und Befehle genutzt, die durch den MQTT2-Server der obigen Definition zur Verfügung gestellt werden. Einzelne Heizungswerte werden in bestimmten Intervallen über den publish-Befehl ausgelesen. Die Temperaturen der Zirkulation, des Vorlaufs und des Rücklaufs werden außerhalb der Therme mit 1-wire-Temperatursensoren über WLAN-ESP-Easy ausgelesen. Die Definition des Layouts über das Attribut uiTable ist unabhängig vom Auslesen der Werte, sie bezieht sich lediglich auf vorhandene Readings, die visualisiert werden sollen. Das Layout kann ebenso auf Readings aus anderen Devices der eigenen FHEM-Umgebung anpasst werden.

<syntaxhighlight lang="perl">
defmod di_vaillant DOIF ##{[+00:01];;foreach (qw(FanSpeed Flame PumpPower Storageloadpump PrimaryCircuitFlowrate FlowTempDesired PumpHours HcHours HcPumpStarts)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
\
{[+[1]:01];;foreach (qw(PrEnergySumHc1 PrEnergySumHwc1 HcHours HwcHours z1OpMode WaterPressure z1NightTemp z1DayTemp Hc1HeatCurve HwcLockTime HolidayStartPeriod HolidayEndPeriod)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}\
}\
\
{[+00:00:30];;foreach (qw(Flame PrimaryCircuitFlowrate)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
\
{[00:01];;foreach (qw(FanHours HcStarts HwcStarts )) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}\
set_Reading("gesamt_hc",int([?vaillant:PrEnergySumHc1_0_value]/10000)/10,0);;\
set_Reading("gesamt_hwc",int([?vaillant:PrEnergySumHwc1_0_value]/10000)/10,0);;\
set_Reading("diff_hc",0,1);;\
set_Reading("diff_hwc",0,1);;\
set_Reading("diff_h",0,1)\
}\
\
{if ([00:05|WE]) {fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayStartPeriod/set $mday.$month.$year");;fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayEndPeriod/set $mday.$month.$year")}}\
\
Timer {\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Monday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Tuesday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Wednesday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Thursday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Friday/set 04:00;;09:00;;13:00;;22:00;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Sunday/set 05:00;;10:00;;12:00;;22:30;;-:-;;-:-"\
fhem_set "MQTT2_FHEM_Server publish ebusd/700/z1Timer.Saturday/set 05:00;;10:00;;12:00;;22:30;;-:-;;-:-"\
}\
\
diff {\
set_Reading("diff_hc",int(([vaillant:PrEnergySumHc1_0_value]/100000-get_Reading("gesamt_hc",0))*10)/10,1);;\
set_Reading("diff_hwc",int(([vaillant:PrEnergySumHwc1_0_value]/100000-get_Reading("gesamt_hwc",0))*10)/10,1);;\
set_Reading("diff_h",get_Reading("diff_hc")+get_Reading("diff_hwc"),1);;\
}\
\

attr di_vaillant event-on-change-reading .*
attr di_vaillant room Ebus
attr di_vaillant uiTable {\
package ui_Table;;\
$TABLE='text-align:center;;';;\
$SHOWNODEVICELINE = "test9|Damian";;\
}\
icon_temp_ring("temp_outside",[vaillant:Aussentemp],-15,40,130)|\
icon_temp_mring(([vaillant:Flame] eq "off"?"sani_boiler_temp\@white":"sani_boiler_temp\@Darkorange"),[vaillant:Vorlauf],15,70,130)|\
icon_temp_mring(([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),[vaillant:WWSpeicher],15,70,130)|\
icon_uring("0,0,1","weather_barometric_pressure",[vaillant:Wasserdruck],0,3,undef,undef,"bar",1,130,[(0.8,0,1,60,1.5,120,1.7,60,3,0)],"50,35")|\
icon_ring("sani_floor_heating_neutral",[vaillant:HcHours_hoursum2_value],0,10000,120,0,"h",0,130)|\
icon_ring("sani_water_tap",[vaillant:HwcHours_hoursum2_value],0,2000,120,0,"h",0,130)|\
\
icon_ring("time_graph",[vaillant:HeizKennlinie],0.4,1,120,0,"HK",1,130)|\
icon_temp_mring("scene_day\@yellow",[vaillant:TagSolltemp],undef,undef,130)|\
icon_temp_mring("scene_night\@#3464eb",[vaillant:NachtSolltemp],undef,undef,130)\
""|""|""|""|""|""|widget([vaillant:HeizKennlinie],"selectnumbers,0.4,.1,1,1,lin","set")|widget([vaillant:TagSolltemp],"selectnumbers,15,1,25,1,lin","set")|widget([vaillant:NachtSolltemp],"selectnumbers,15,1,25,1,lin","set")<\
\
card([vaillant:Aussentemp:col],"Außentemperatur","temp_outside",-15,35,undef,undef,"°C",\&temp_hue)|\
card([vaillant:WWSpeicher:col],"WW-Speicher",([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down\@white"),15,70,undef,undef,"°C",\&temp_hue)|\
card([ESPEasy_ESP_Temp_Vorlauf:Temperature:col],"Vorlauf",([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating\@Darkorange" : "sani_floor_heating_neutral\@white"),15,70,undef,undef,"°C",\&temp_hue)|\
card([$SELF:diff_hc:col],"Energie Heizung","sani_floor_heating_neutral",0,100,120,0,"kWh",undef,1)\
card([vaillant:Umlaufmenge:col],"Umlaufmenge","sani_pump",0,20,120,0,"l/min")|\
card([ESPEasy_ESP_Temp_Zirkulation:Temperature:col],"Zirkulation",([Zirk] eq "off"?"sani_pump\@white":"sani_pump\@Darkorange"),15,70,undef,undef,"°C",\&temp_hue)|\
card([ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature:col],"Rücklauf","sani_floor_heating_neutral\@wite",15,70,undef,undef,"°C",\&temp_hue)|\
card([$SELF:diff_hwc:col],"Energie Warmwasser","sani_water_tap",0,15,120,0,"kWh",undef,1)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:Di uiTable Heizung.png|600px|links]]

 

=== ''Visualisierung: '''Anwesenheitsstatus''''' ===
Die aktuelle Anwesenheit von Heimbewohnern wird visualisiert. 
Zunächst wird mit Hilfe des Moduls [[FRITZBOX]] ein Device namens ''FritzBox'' erstellt. Dort werden die eingebuchten Smartphones der Bewohner mit Ihren MAC-Adressen in Readings abgelegt. Die folgende Definition wertet aus, ob die angegebenen MAC-Adressen als Readings vorhanden sind und erstellt für jeden Bewohner ein Reading mit den Zuständen on/off. Diese Readings werden dann über das Attribut uiTable visualisiert. Die anwesenden Personen werden farblich markiert. Die Namen der Personen sowie die MAC-Adressen sind fiktiv und müssen den eigenen Angaben entsprechend angepasst werden.
{{Randnotiz|RNText='''nützliche Links'''
* [[FRITZBOX|FritzBox-Modul]]
* ui_Table Funktion [[DOIF/uiTable Schnelleinstieg#Icon-Darstellung mit Text mit Hilfe der Funktion icon_label|icon_label]]
*[[DOIF/uiTable Schnelleinstieg#uiTable-Templates|uiTable-Templates]]
}}

<syntaxhighlight lang="perl">
defmod myHome DOIF {\
set_Reading_Begin;;\
set_Reading_Update("Ernie",[FritzBox:mac_12_34_E0_00_CD_E4] ? "on":"off");;\
set_Reading_Update("Bert", [FritzBox:mac_02_08_02_07_30_E3] ? "on":"off");;\
set_Reading_Update("Grobi", [FritzBox:mac_00_08_01_0B_00_E7] ? "on":"off");; \
set_Reading_Update("Kermit", [FritzBox:mac_01_30_A9_72_02_E3] ? "on":"off");; \
set_Reading_End(1);;\
}
attr myHome checkReadingEvent 0
attr myHome uiTable {\
package ui_Table;;\
$SHOWNOSTATE=1;;\
$TC{0..4}="align='center'";;\
}\
## Template-Definition für die Visualisierung eines Bewohners mit Hilfe des Icons fa__508\
DEF TPL_person (icon_label([$SELF:$1] eq "on" ? "fa__508\@DarkOrange":"fa__508","$1","#e67e00","white",-10))\
\
## Darstellung der Bewohner mit Hilfe des obigen Templates\
TPL_person(Ernie)|TPL_person(Bert)|TPL_person(Grobi)|TPL_person(Kermit)
</syntaxhighlight>

''Ergebnis der Beispieldefinition in der Webansicht:''
[[Datei:UiTable myHome.png|ohne|mini]]

=== Weitere Anwendungsbeispiele zur Automatisierung ===
* siehe [[DOIF/Automatisierung]]

== Weiterführende Links ==
* Weitere Beispiele für Fortgeschrittene, siehe "[[DOIF/uiTable|uiTable mit FHEM-Widgets und Styles]]"

[[Kategorie:HOWTOS]]
[[Kategorie:Code Snippets]]

HourCounter

2022-01-28T19:31:15Z

Maista: URL nicht mehr erreichbar

{{Infobox Modul
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten
|ModType=h

|ModForumArea=MAX
|ModTechName=98_HourCounter.pm
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}

[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.

== Features ==
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten

== Zielsetzung des WIKI-Artikels ==
Erläuterung der Funktionalität zur weiterführenden Diskussion im {{Link2Forum|Topic=12216|Message=72596|LinkText=Forum}}.

== Aktuelle Version ==
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.

== Definition ==
=== Abstrakt ===
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre>

<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.

Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen
EIN- sowie einen AUS-Zustand aufweist.

<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.

===Konkret===
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre>
Hier wird der HourCounter CN.TEST definiert.
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:
<pre>
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1
....
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0
</pre>

Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre>

Die neue Instanz weist folgende Struktur auf:

<pre>
Internals:
CFGFN
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0
NAME CN.Test
NR 738
NTFY_ORDER 50-CN.Test
STATE 1
TYPE HourCounter
Readings:
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22
2014-02-04 20:59:57 countsOverall 1
2014-02-04 20:59:57 countsPerDay 1
2014-02-04 20:59:57 pauseTimeIncrement 35
2014-02-04 20:59:57 pauseTimeOverall 35
2014-02-04 20:59:57 pauseTimePerDay 35
2014-02-04 21:00:01 pulseTimeIncrement 4
2014-02-04 21:00:01 pulseTimeOverall 4
2014-02-04 21:00:01 pulseTimePerDay 4
2014-02-04 20:59:57 state 1
2014-02-04 21:00:00 tickHour 1
2014-02-04 21:00:01 value 0
Helper:
OFF_Regexp SHUTTER.JOHN:onoff:.0
ON_Regexp SHUTTER.JOHN:onoff:.1
calledByEvent
changedTimestamp 2014-02-04 21:00:01
forceClear
forceDayChange
forceHourChange
forceMonthChange
forceWeekChange
isFirstRun
sdRoundHourLast 1391544000
value 0
cmdQueue:
</pre>

Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß
nur Änderungen das Feuern von Events auslösen
<pre>
attr CN.BRENNER event-on-change-reading .*
</pre>
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden,
wenn sie aktualisiert werden.
<pre>
attr CN.BRENNER event-min-interval tick.*:0,.*:3600
</pre>

== Readings ==
{| class="wikitable sortable"
|-
! Reading !! class="unsortable" | Beschreibung
|-
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden
|-
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses
|-
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses
|-
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert
|-
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase
|-
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen
|-
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages
|-
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert
|-
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase
|-
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen
|-
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages
|-
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis, 
mit 1=letztes Ereignis war ON-Ereignis 
und 0=letztes Ereignis war OFF-Ereignis
|-
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)
|-
| tickChanged || Event wird nach Änderung von value gefeuert
|-
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden
|-
| tickHour || Event wird nach Stundenwechsel gefeuert
|-
| tickWeek || Event wird nach Wochenwechsel gefeuert
|-
| tickMonth || Event wird nach Monatswechsel gefeuert
|-
| tickYear || Event wird nach Jahreswechsel gefeuert
|-
| forceHourChange || simuliert einen Stundenwechsel
|-
| forceDayChange || simuliert einen Tageswechsel
|-
| forceWeekChange || simuliert einen Wochenwechsel
|-
| forceMonthChange || simuliert einen Monatswechsel
|-
| forceYearChange || simuliert einen Jahreswechsel
|}

== Web-Oberfläche ==
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]

== Anwendung ==
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den
abgeleiteten Werten.

[[Datei:13_11_15_HourCounter_Chart.png]]

* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.

=== Chart der Aktualwerte ===
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre>
Man erhält nach den ersten Ereignissen Einträge in folgender Form:
<pre>
2013-11-16_12:45:40 CN.Test value: 1
2013-11-16_12:45:40 CN.Test 1
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41
2013-11-16_12:46:21 CN.Test value: 0
2013-11-16_12:50:38 CN.Test countsPerDay: 2
2013-11-16_12:50:38 CN.Test countsOverall: 2
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756
2013-11-16_12:50:38 CN.Test value: 1
2013-11-16_12:50:38 CN.Test 2
</pre>

Nun kann man den Chart definieren:
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]

Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:
<pre>$fld[3]=~"1"?-2:-19</pre>
Die "Brenner Starts" können wir direkt von countsPerDay ableiten. 
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.
<pre>$fld[3]/=3600</pre>
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.
<pre>$fld[3]/=60</pre>

Somit sind die Basis-Kurven angelegt.

=== Erweiterungen ===
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.

* Aggregation über bestimmte oder ganz freie Zeiträume
* komplexe Berechnungen, die zum Verbrauch führen
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen

Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle
Erweiterung bei der Verbrauchserfassung.

HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.

Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.

==== Installation ====
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen
[https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/99_UtilsHourCounter.pm Link] bezogen werden.
 
Die Datei ist in da Unterverzeichnis FHEM vom FHEM-Homverzeichnis zu kopieren.
 
z.B. bei Raspberry Pi: /opt/fhem/FHEM
 
Nach dem Kopieren und einen Neustart von FHEM kann man überprüfen, ob FHEM diese Datei findet.
Wenn man das Menü "Edit Files " anwählt, wird auch 99_UtilsHourCounter angezeigt.

==== Readings ====
99_UtilsHourCounter aus dem contrib-Verzeichnis der FHEM-Installation erweitert den HourCounter um folgende Funktionen:
{| class="wikitable sortable"
|-
! Reading !! class="unsortable" | Beschreibung
|-
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert
|-
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour
|-
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)
|-
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert
|-
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek
|-
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert
|-
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth
|-
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert
|-
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear
|-
| appOpHoursPerDay || Betriebsstunden des Tages
|-
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay
|-
| appOpHoursPerWeek || Betriebsstunden der Woche
|-
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek
|-
| appOpHoursPerMonth || Betriebsstunden des Monats
|-
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth
|-
| appOpHoursPerYear || Betriebsstunden des Jahres
|-
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear
|-
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100
|-
| appUtilizationTemp || Arbeitsvariable zu appUtilization
|}
Beginn der Woche ist jeweils der Sonntag. 

Mit folgender Anweisung aktivieren wir die Erweiterungen:
:<code>define CN.EVENT notify CN\..*:tick.* { appHCNotify("$NAME","$EVTPART0","$EVTPART1");;}</code>

Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}

Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.

Somit können die neuen Readings beliebig manipuliert werden.

===== Für Anfänger die noch keine Erfahrungen mit Regular Expressions haben:=====
Benennt eure Hourcounter nach dem Muster CN.<euer Wunschname>. Dann wird der notify immer funktionieren. 

Beispiel: statt "PelletsCounter" wählt den Namen "CN.PelletsCounter"

==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w*(Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code>

Im Klartext:
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten
* und die danach nicht dem Term "Temp" beinhalten

== Fragen und Antworten ==
==== Betriebsstundenzähler über Leistungsmessung ableiten ====
'''Frage:'''
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?

Beispiel für die Events
<pre>
013-11-18_19:40:32 XXX power: 1.9
2013-11-18_19:40:32 XXX consumption: 2
2013-11-18_19:40:32 XXX consumptionTotal: 2
2013-11-18_19:40:36 XXX power: 27
2013-11-18_19:40:36 XXX consumption: 2
2013-11-18_19:40:36 XXX consumptionTotal: 2
2013-11-18_19:40:42 XXX power: 34.6
2013-11-18_19:40:42 XXX consumption: 2
</pre>

'''Antwort'''
Die hier vorgestellte Lösung überprüft ob der Wert des Events power eine oder zwei Ziffern vor dem Komma hat.
Deshalb wir hier erst gezählt, wenn die Schwelle von 10Watt überschritten wird.
<pre>
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$
</pre>
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis
* "power:" das Ereignis muss mit diesem Term beginnen
* "\s" es muss ein Leerzeichen folgen
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen
* "$" danach darf kein weiteres Zeichen mehr folgen

'''Antwort Möglichkeit 2'''
In dieser Lösung bekommt das entsprechende Device was mit HourCounter überwacht werden soll ein userReadings "onoff". Dieses Reading wird dann zum Schalten von Hour Counter verwendet:
<pre>
define GPIO4_DS18B20_Waermepumpe_Vorlauf GPIO4 28-000005956079
attr GPIO4_DS18B20_Waermepumpe_Vorlauf alias Wärmepumpe Vorlauf
attr GPIO4_DS18B20_Waermepumpe_Vorlauf model DS18B20
attr GPIO4_DS18B20_Waermepumpe_Vorlauf room GPIO4
attr GPIO4_DS18B20_Waermepumpe_Vorlauf userReadings onoff {(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}

define Waermepumpe_HourCounter HourCounter GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1 GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0
attr Waermepumpe_HourCounter room 2_Fussbodenheizung
</pre>
Erläuterungen zu dem Code: "{(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}"
* "(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)" Diese Bedingung für das userReadings onoff prüft bei jedem Event, ob der Wert von temperature größer als 28 ist.
* "?1:0" Ist dies der Fall wird das userReading onoff auf 1 gesetzt andernfalls auf 0.
Auf Basis deses UserReadings wird dann der HourCounter definiert:
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1" Einschaltbedingung für HourCounter
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0" Abschaltbedingung für Hour Counter

==== Welche Anwendungsfälle sind denkbar ? ====
{{Link2Forum|Topic=12216|Message=175163|LinkText=Aus dem Forum}}
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)

{{Link2Forum|Topic=12216|Message=195358|LinkText=Brenner Starts/Verbrauch + akkumulierte Werte}}

{{Link2Forum|Topic=12216|Message=196358|LinkText=Ölverbrauch+Solar-Ladung}}

[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren] (URL tot)

==== Seltene Schaltvorgänge ====
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?

'''Antwort'''

Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.

==== Korrekte Darstellung der akkumulierten Daten im Chart ====
'''Frage'''

"appCountsPerDay: 4" bezieht sich auf die Counts des Tages 2014-06-16, trägt aber selbst den Zeitstempel 2014-06-17 und wird demnach in einem Chart auch über den Tag " 2014-06-17" dargestellt.
Das Problem betrifft alle akkumulierten Daten des HourCounters.
Wie erreicht man im Chart die korrekte Darstellung ?

'''Antwort'''

Das Thema wurde {{Link2Forum|Topic=12216|Message=239929|LinkText=hier}} disktuiert.
Eine Lösung findet man mit [[LogProxy]].
Damit läßt sich ein negativer Offset für die X-Achse definieren, so daß die Daten wieder korrekt dargestellt werden.

[[Kategorie:MAX]]
[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]

Synology Diskstation

2021-11-01T14:58:40Z

Maista: Fhem > FHEM

== FHEM Installation auf der Synology Diskstation (ab DSM 5)==

FHEM auf einer Synology Diskstation (DS) zu installieren ist grundsätzlich nicht schwierig. Wichtig ist zunächst eine aktuelle DSM - also Systemupdates auf der DS installieren.

* Zunächst installiert ihr Euch über das Paket-Zentrum der DS das Programm "Perl".
* Dann besorgt ihr Euch von Martin Fischer ein kompiliertes FHEM [https://www.fischer-net.de/hausautomation/downloads/category/11-fhem.html SPK]. Mehr Infos s. {{Link2Forum|Topic=51265}}
* Dann wieder den Paket-Zentrum der DS aufrufen und "Manuelle Installation" -> entsprechende Datei auswählen -> weiter. Wenn es Mecker gibt wegen Signierung o.ä., dann Paket-Zentrum -> Einstellungen -> Vertrauensebene auf "Jeder Herausgeber".

Danach ist FHEM installiert und ihr könnt es über das Paket-Zentrum starten. Dann einfach FHEM aufrufen und als erstes mal ein Update durchführen.
Nach dem Update die Datei 99_update.pm löschen, siehe {{Link2Forum|Topic=36249|Message=285521|LinkText=hier}}

Um einen CUL damit zu betreiben oder HUEs anzusteuern müssen noch weitere Schritte unternommen werden. (siehe weiter unten)

Hinweis: Falls man eine neuere Version von Perl benötigt bzw. Probleme auftreten, dann kann auf x86_64-Architekturen (s. [http://www.synology-wiki.de/index.php/Welchen_Prozessortyp_besitzt_mein_System%3F]) auch ActivePerl eingesetzt werden. Dazu muss man nur das Startskript von FHEM anpassen. Dann kann man beide Versionen auch parallel betreiben. Nur bei CPAN/PPM darauf achten, in welchem Verzeichnis man das aufruft.

Hier noch Links zu Wiki-Einträgen für ältere DSM-Versionen / Modelle:
[[FHEM auf dem Synology DS408]]

== CUL zum laufen bringen | IPKG installieren ==
A.) Zunächst braucht ihr die USB-Treiber: http://forum.synology.com/enu/viewtopic.php?f=155&t=82843&hilit=usbserial - diese einfach über das Paket-Zentrum installieren. Die Zusatzkonfigurationen, die vom Wizard nach der Installation gefragt werden, müssen nicht ausgewählt werden.

B.) Dann braucht ihr das IPKG, damit ihr verschiedene Programme nachladen könnt, die ihr für den Betrieb des CUL benötigt:
1. Prozessor (CPU) Architektur heraussuchen - http://forum.synology.com/wiki/index.php/What_kind_of_CPU_does_my_NAS_have
2. Der Prozessor (CPU) Architektur entsprechendes Shell-Script herunterladen und in einem beliebigen Ordner auf der DiskStation speichern - http://forum.synology.com/wiki/index.php/Overview_on_modifying_the_Synology_Server,_bootstrap,_ipkg_etc#Bootstrap
Wenn ihr den Prozessor Marvel Armada XP oder Marvel Armada 370 habt (z.B. DS 214+), dann schaut hier: https://gist.github.com/marlun78/9349792
3. Dieses How-to durch arbeiten - http://forum.synology.com/wiki/index.php/How_to_Install_Bootstrap (für den Armada nicht - da steht alles im o.g. Link)
4. DiskStation neustarten

C) Jetzt braucht ihr die SerialPort Modul.
Das kann funktionieren mit:

<code>"ipkg install gcc"

"/usr/local/perl/bin/perl -MCPAN -e shell") / je nachdem wo Eure perl Installation liegt - bei mir war es "/usr/bin/perl -MCPAN -e shell"

"cpan install Device::SerialPort"</code>

Hat es bei mir nicht - ich habe es so geschafft:

<code>"ipkg install perl-device-serialport"

"cp /opt/lib/perl5/site_perl/5.10.0/arm-linux/Device/SerialPort.pm /volume1/@appstore/Perl/lib/perl5/site_perl/Device/"

"cp /opt/lib/perl5/site_perl/5.10.0/arm-linux/auto/Device/SerialPort/SerialPort.bs /volume1/@appstore/Perl/lib/perl5/site_perl/auto/Device/SerialPort/"

"cp /opt/lib/perl5/site_perl/5.10.0/arm-linux/auto/Device/SerialPort/SerialPort.so /volume1/@appstore/Perl/lib/perl5/site_perl/auto/Device/SerialPort/"</code>

Keine der beiden Varianten funktioniert für DS213+ (Stand: Juni 2015). Alternative für DS213+ siehe [[Synology Diskstation DS213+|hier]].

D) ganz wichtig - sonst schmiert Euch der CUL immer wieder ab - synousbmdemd deaktivieren - das habe ich wie folgt gemacht:

<code>mv /usr/syno/sbin/synousbmodemd /usr/syno/sbin/synousbmodemd_bkp</code>

Bei einem DSM update wird dieser Dienst vermutlich wieder installiert - daher nach einem Update same procedure as every year.

Der "Security Advisor" erkennt diese Änderung und glaubt, dass sich eine Malware auf dem NAS breitgemacht hätte. Man erhält deswegen eine entsprechende Warnung.

== Wichtig: Logfile auf USB auslagern ==
Damit die DS auch ab und zu mal die Platten zum schlafen schicken kann, solltet ihr die Logfiles auf ein USB-Laufwerk auslagern. Dazu einfach eines an die DS anschließen und im File-Explorer nachschauen, wie das Laufwerk benannt wurde (z.B. volumeUSB1). Dann FHEM runterfahren ("shutdown"), anschließend als root über z.B. putty mit der DS verbinden, das Log-Verzeichnis auf den Stick verschieben und einen Link anlegen - z.B. so:

<code>mv /usr/local/FHEM/var/log /volumeUSB1/usbshare/fhem/log

ln -s /volumeUSB1/usbshare/fhem/log /usr/local/FHEM/var/log</code>

Dann Fhem wieder starten und es sollte klappen.

== Inhalt von Fhem-Verzeichnissen aus Windows direkt bearbeiten ==
Hier gibt es mehrere Möglichkeiten. Entweder ihr verbindet Euch über WinSCP mit der DS. Oder aber ihr verschiebt und verknüpft noch weitere Teile der FHEM Installation auf den Stick (siehe Logfile auf USB auslagern). Hier wäre ich allerdings vorsichtig, da kann FHEM zickig werden. Ich persönlich habe mir die fhem.cfg auf diese Weise noch auf den Stick geschoben - also das /usr/local/FHEM/etc Verzeichnis analog obiger Beschreibung zum Logfile. Darüber hinaus könnt ihr auch einfach Dateien auf Eurem Stick ablegen und im entsprechenden FHEM-Verzeichnis einen Link dazu erstellen - so habe ich das z.B. mit meinen pm-Files gemacht - z.B.

<code>ln -s /volumeUSB1/usbshare/fhem/99_myUtils.pm /usr/local/FHEM/share/fhem/FHEM/99_myUtils.pm</code>

== HUE auf der Synology Diskstation ==
Da auf der DS standardmäßig kein JSON installiert ist, muss dies nachinstalliert werden (Danke an Patlinger für die Anleitung). Wichtig - ihr braucht IPKG (siehe CUL zum Laufen bringen):

1. Per SSH verbinden (Befehl "ssh <ip-adresse> -l root")

2. Superuser aktivieren (Befehl "su")

3. "make" installieren (Befehl "ipkg install make")

4. PERL und CPAN starten (Befehl "/usr/local/perl/bin/perl -MCPAN -e shell") / je nachdem wo Eure perl Installation liegt - bei mir war es "/usr/bin/perl -MCPAN -e shell"

5. CPAN updaten (Befehl "install CPAN")

6. JSON installieren (Befehl "install JSON")

7. Per telnet verbinden (Befehl "telnet <ip-adresse> <port (7072)>")

8. FHEM Update durchführen (Befehl "update")

9. FHEM Neustart (Befehl "shutdown restart")

10. Hue Bridge hinzufügen (Befehl "define <Name-für-die-Bridge> HUEBridge <ip-adresse-der-Hue-Bridge>")

11. Taste an der Hue Bridge drücken um das "Pairing" zu bestätigen.

12. GANZ WICHTIG - Wenn's jetzt einmal läuft, dann nicht vergessen die Konfiguration zu speichern! (Befehl "save")

== Net::Telnet installieren ==
Net::Telnet benötigt ihr beispielsweises für das geniale Modul FRITZBOX, dass Euch viele Möglichkeiten eröffnet, wenn ihr einen solchen Router besitzt.

Los gehts wie üblich mit
<code>"/usr/bin/perl -MCPAN -e shell"</code>
Der Pfad zu perl kann bei Euch auch anders lauten, siehe oben. Dann seid ihr fast fertig, nur noch folgendes eingeben - und fertig:
<code>install Net::Telnet</code>

== JeeLink ==

Für den JeeLink werden zwei Kernelmodule gebraucht, die seit DSM 5.2 dabei sind und nicht mehr separat installiert werden müssen. Jedoch müssen sie nach jedem Update wieder neu aktiviert werden (kann auch bei laufendem Betrieb von FHEM passieren):

* <code>cd /lib/modules</code>
* <code>insmod usbserial.ko</code>
* <code>insmod ftdi_sio.ko</code>

Ansonsten wird wie oben beschrieben das <code>Device::SerialPort</code>-Modul benötigt.

Getestet auf DSM415+

== Automatischer Neustart ==

Script anlegen:

<syntaxhighlight lang="bash">
#!/bin/sh
cnt=$(ps -A -f | grep "fhem\.pl" | grep -v grep | wc -l)
if [ "$cnt" -eq "0" ] ; then
/var/packages/FHEM/scripts/start-stop-status restart
else
echo "FHEM still running.";
return 1;
fi
</syntaxhighlight>

Dann kann man entweder über cron das Skript regelmäßíg (z.B. alle 15min) oder man nutzt hierfür die in DSM eingebaute Aufgabenverwaltung (einfach vollständigen Pfad zum Skript eingeben). Letzteres ist für den Überblick auf praktischer.

[[Kategorie:HOWTOS]]
[[Kategorie:Synology]]

At

2021-08-24T17:03:31Z

Maista:

{{SEITENTITEL:at}}
{{Infobox Modul
|ModPurpose=Setzt einen Fhem-Befehl zu einem späteren Zeitpunkt ab.
|ModType=h

|ModCmdRef=at
|ModTechName=90_at.pm
|ModOwner=rudolfkoenig / [http://forum.fhem.de/index.php?action=profile;u=8 rudolfkoenig]
}}

[[at]] ist ein Erweiterungsmodul, mit dessen Hilfe FHEM-Befehle/-Aktionen zu einem späteren Zeitpunkt ausgeführt werden können. Es läßt sich sowohl einmalige Ausführung, als auch regelmäßige Wiederholung erzielen, Zeitangaben können relativ oder absolut erfolgen.

== Voraussetzungen ==

Keine.

== Anwendung ==
=== Define ===
<code>define <name> at <timespec|datespec> <command></code>
=== Besonderheit ===
*timespec - '''nur Zeit''' im Format HH:MM:SS '''kann eine''' Perlfunktion sein.
*datespec - '''Datum und Zeit''' ISO 8601 oder "number of sec since 1970" '''darf keine''' Perlfunktion sein.
Siehe {{Link2Forum|Topic=91625|Message=168475}}

=== Beispiele ===
*<code>define MeineAktion at 02:02:00 set lamp on</code> → das nächste Mal um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at *02:02:00 set lamp on</code> → jeden Tag um zwei Minuten nach 2 Uhr "lamp" einschalten
*<code>define MeineAktion at {ReadingsVal("Dummy","Zeit","")} set lamp on</code> → das nächste Mal um (Perlfunktion liest Zeit aus dem Dummy) "lamp" einschalten
*<code>define MeineAktion at 2016-01-25T02:02:00 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (ISO 8601)
*<code>define MeineAktion at 1453683720 set lamp on</code> → das nächste Mal am 25.01.2016 um zwei Minuten nach 2 Uhr "lamp" einschalten (number of sec since 1970)
*<code>define MeineAktion at +02:02:00 set lamp on</code> → in zwei Stunden und 2 Minuten "lamp" einschalten
*<code>define MeineAktion at +*02:02:00 set lamp on</code> → alle zwei Stunden und 2 Minuten "lamp" einschalten
Um datespec auch variabel mit setzen zu können gibt es einen Workaround: Perlebene, Perlfunktion und Übergabe in Variable.

Beispiele für "number of seconds since 1970"
<syntaxhighlight lang="perl">
{my $time=time_str2num("2019-09-14 23:00:00");;fhem("define MeineAktion at $time set lamp on")}
{my $time=1568494800;;fhem("define MeineAktion at $time set lamp on")}
</syntaxhighlight>
Beispiel im ISO 8601 Format
<syntaxhighlight lang="perl">{my $time="2019-09-14T23:00:00";;fhem("define MeineAktion at $time set lamp on")}</syntaxhighlight>

=== Mehrere Aktionen ausführen ===
Die Verwendung der Semikolon erfordert immer besondere Aufmerksamkeit!
*<code>set lampe1 on ; set lampe2 on </code> → Schaltet sofort beide Lampen ein ( ein bisschen OT, weil kein at)
*<code>define morgens at *7:00:00 set lampe1 on ; set lampe2 on</code> → schaltet lampe 1 immer um 7 an, aber lampe2 sofort. Der erste Befehl landet in der config (im at) der zweite Befehl wird genau wie der define Befehl einfach sofort ausgeführt.
*<code>define morgens at *7:00:00 set lampe1 on ;; set lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Beide Befehle landen in der config (im at), nur der define Befehl wird ausgeführt
*<code>define morgens at *7:00:00 set lampe1,lampe2 on</code> → schaltet BEIDE Lampen immer um 7 an. Geht nur wenn der gleiche Befehl an 2 oder mehr Geräte gesendet werden soll

=== Attribute ===
...

=== Testen ===
{{Randnotiz|RNText='''Versionsspezifisch:''' Der Befehl ''execNow'' ist in FHEM 5.7/90_at.pm ab 30.4.2016 verfügbar.}}
Mit dem Befehl
:<code>set <devspec> execNow</code>
lässt sich eine ''at''-Definition (einmalig, beispielsweise zu Testzwecken) unabhängig vom Erreichen der angegebenen Zeitspezifikation ausführen.

== Anwendungsbeispiele ==
* [[AT an einem bestimmten Wochentag ausführen|at an einem bestimmten Wochentag ausführen]]
* [[AT um eine Temperaturabhängige Nachtabsenkung zu realisieren|at um eine Temperaturabhängige Nachtabsenkung zu realisieren]]
* [[AT zu einem absoluten Datum ausführen|at zu einem absoluten Datum ausführen]]
* [[SUNRISE_EL|at in Verbindung mit SUNRISE_EL]]

== Links ==
* Abfrage, ob at definiert ist: {{Link2Forum|Topic=23584|Message=841269}}

Qnap NAS

2021-06-06T20:27:46Z

Maista: /* FHEM Installieren */

{{Randnotiz|RNTyp=Info|RNText=Ergänzungen und Aktualisierungen in {{Link2Forum|Topic=60300}} bitte beachten!}}
= Installation von FHEM auf einem QNAP NAS =
Diese Anleitung beschreibt detailiert, wie FHEM auf einer
QNAP Turbo Station TS-109 II pro installiert werden kann.
Im wesentlichen wird die Vorgehensweise auch für weitere QNAP NAS
gelten.

== Überblick ==
Die aktuelle QNAP Firmware 3.1.0 Build 0708 unterstützt die
Installation von IPKG Paketen. Sämtliche für FHEM benötigte
Software ist auf diese Weise verfügbar, so dass die Installation
eigentlich sehr einfach vonstatten gehen könnte. Leider hat QNAP
an einigen Stellen geschlampt und man muss von Hand etwas nachhelfen.
Desweiteren ist Handarbeit gefragt für folgende Zusatzfunktionen

* Auslagerung der FHEM Logfiles auf einen Speicherstick. Somit kann die interne Festplatte weiterhin in den Spin Down gehen.
* Autostart von FHEM bein Booten des NAS
* Geordnetes Runterfahren von FHEM beim Herunterfahren des NAS
= Installation des QPKG Paketes Optware IPKG =
Über die NAS Web-Administration kann das Optware IPKG Paket
Optware_0.99.163_arm-x09.qpkg Installiert werden.
In dem Paket für die TS-109 sind leider einige Fehler enthalten, die
im folgenden korrigiert werden. Diese und alle weiteren Eingaben
sind auf der [[Kommandozeilentools|Kommandozeile]] durchzuführen.

== Anpassen der ipkg Konfiguration ==
=== Namen der Konfigurationsfiles korrigieren ===
<nowiki># cd /share/HDA_DATA/.qpkg/Optware/etc/ipkg
# mv tsx19-kmod.conf tsx09-kmod.conf
# mv tsx19.conf tsx09.conf</nowiki>
=== Repository für ipkg Pakete korrigieren ===
<nowiki># vi tsx09-kmod.conf
Ändern von
src tsx19 http://ipkg.nslu2-linux.org/feeds/optware/tsx19/cross/unstable
in
src tsx09 http://ipkg.nslu2-linux.org/feeds/optware/tsx09/cross/stable</nowiki>
=== Repository für die ipkg Kernel Module korrigieren ===
<nowiki># vi tsx09.conf
Ändern von
src cs08q1armel http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable
in
src cs05q3armel http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/unstable</nowiki>
=== Zusätzliches Installationsziel für ipkg in die Config aufnehmen ===
Die Kernel Module werden sonst nach /lib/modules installiert, und das wird bei jedem reboot überschrieben. Also müssen sie explizit nach /opt/lib/modules installiert werden.

<nowiki># cd /share/HDA_DATA/.qpkg/Optware/etc
# vi ipkg.conf
Hinzufügen von
dest opt /opt</nowiki>
=== Anpassen des Paketnamens ===
Es muss überall Optware-ipkg heissen.

<nowiki># cd /share/HDA_DATA/.qpkg/Optware
# mv Optware.sh Optware-ipkg.sh
# vi Optware-ipkg.sh
Ändern von
QPKG_NAME=“Optware“
in
QPKG_NAME=“Optware-ipkg“</nowiki>
=== Optware „mounten“ ===
<nowiki># /share/HDA_DATA/.qpkg/Optware/Optware-ipkg.sh restart</nowiki>

= Zusätzliche Software installieren =
Nun können die für FHEM benötigten Pakete per ipkg installiert werden.

== Paketliste aktualisieren ==
<nowiki># ipkg update</nowiki>
== Kernel Module für USB-Serial Hardware ==
Das usbserial Modul unterstützt diverse USB nach seriell Wandler.
Für ein CUL sind keine weiteren Kernel Module nötig.
Ein FHT-1000 benötigt zusätzlich des ftdi-sio Modul.
Eine Reihe von günstigen USB nach seriell Adapterkabel benutzen den
Proliftic PL-2303 Chip. Hierfür ist ebenfalls ein weiteres Modul nötig.
Über ein solches Kabel ist dann Beispielsweise ein ELV M232 Modul anzuschliessen.
Neben den Kernel Modulen habe ich noch die libusb installiert.
Die benötige ich später einmal um einen IOWarrior anzusprechen.

'''Bei den Kernel Modulen beachten, dass diese nach /opt installiert werden.'''Sonst sind sie nach dem nächsten Reboot weg.

<nowiki># ipkg -d opt install ts209-kernel-module-usbserial
# ipkg install -d opt ts209-kernel-module-ftdi-sio
# ipkg install -d opt ts209-kernel-module-pl2303
# ipkg install libusb</nowiki>
=== Kernel Module linken ===
<nowiki># ln -s /opt/lib/modules/2.6.12.6-arm1/kernel /lib/modules</nowiki>
=== Module laden mit Vendor und Product ID für CUL ===
<nowiki># insmod /lib/modules/kernel/drivers/usb/serial/usbserial.ko vendor=0x03eb product=0x204b
# insmod /lib/modules/kernel/drivers/usb/serial/ftdi_sio.ko
# insmod /lib/modules/kernel/drivers/usb/serial/pl2303.ko</nowiki>
Nun kann man den CUL anstöpseln und prüfen, ob er erkannt wurde

<nowiki># cd /usr/local/share # hier liegt usb.ids
# lsusb
Sollte u.A. folgendes ausgeben ...
ID 03eb:204b Atmel Corp.
# dmesg
Sollte folgendes ausgeben ...
usbserial_generic 2-1.4:1.1 Generic converter detected
usb 2-1.4: Generic converter now attached to ttyUSB0</nowiki>
== Benötigte Pakete für FHEM installieren ==
<nowiki># ipkg install perl perl-device-serialport
# ipkg install make # für die fhem Installation
# ipkg install gcc # richtige libgcc für perl
# ipkg install gnuplot # optional, falls lediglich plotmode SVG verwendet</nowiki>
= FHEM installieren =
FHEM am PC downloaden und in ein QNAP Public Verzeichnis auspacken z.B.

<nowiki>/share/HDA_DATA/Public/TS109/fhem-4.8</nowiki>
== Ins Download Verzeichnis wechseln ==
<nowiki># cd /share/HDA_DATA/Public/TS109/fhem-4.8</nowiki>
== Pfade im Makefile auf /opt/ .... ändern ==
<nowiki># vi Makefile
BINDIR=/opt/bin
MODDIR=/opt/lib
VARDIR=/opt/var/log/fhem</nowiki>
== Logverzeichnis anlegen ==
Dieses Verzeichnis wird später auf einen Speicherstick ausgelagert.

<nowiki># mkdir -p /opt/var/log/fhem</nowiki>
== Installieren ==
<nowiki># make install-pgm2</nowiki>
== Pfad von Perl in fhem.pl anpassen ==
<nowiki># vi /opt/bin/fhem.pl
#!/opt/bin/perl</nowiki>
== Configfile nach /opt/etc kopieren und editieren ==
<nowiki># cp /opt/var/log/fhem/fhem.cfg /opt/etc/fhem.cfg
#vi /opt/etc/fhem.cfg
attr global logfile /opt/var/log/fhem/fhem-%Y-%V.log
attr global statefile /opt/var/log/fhem/fhem.savestate
define CUL CUL /dev/usb/ttyUSB0 <Hauscode></nowiki>
== Probeweise starten ==
<nowiki># /opt/bin/fhem.pl /opt/etc/fhem.cfg</nowiki>
== Stoppen ==
<nowiki># killall fhem.pl</nowiki>
= Logfiles auf USB-Stick auslagern =
== Stick einstecken und prüfen, wo er gemounted wurde ==
<nowiki># mount|grep vfat
/dev/sdu on /share/external/sdu type vfat</nowiki>
== Lokale Logfiles verschieben und verlinken ==
<nowiki># cd /opt/var/log
# cp -r fhem /share/external/sdu
# mv fhem fhem.local
# ln -s /share/external/sdu/fhem</nowiki>
= Autostart und Stop einrichten =
== Startskript anlegen ==
# vi /share/HDA_DATA/.qpkg/Optware/optstart.sh

<pre>#!/bin/sh
# wait for optware init
while ( test -z "$(grep /opt/bin /etc/profile)" ); do sleep 10; done
# get new PATH
source /etc/profile
# Execute all start scripts in /opt/etc/init.d
# executing them in numerical order.
#
for i in /opt/etc/init.d/S??* ;do
# Ignore dangling symlinks (if any).
#[ ! -f "$i" ] && continue
case "$i" in
*.sh)
# Source shell script for speed.
(
trap - INT QUIT TSTP
set start
. $i
)
 ;;
*)
# No sh extension, so fork subprocess.
$i start
 ;;
esac
done</pre>
=== Startskript ausführbar machen ===
# chmod a+x optstart.sh

== Und noch einmal als Stop-Skript mit kleinen Änderungen ==
# cp optstart.sh optstop.sh
# chmod a+x optstop.sh

<pre>#!/bin/sh
# Execute all kill scripts in /opt/etc/init.d
# executing them in numerical order.
#
for i in /opt/etc/init.d/K??* ;do
# Ignore dangling symlinks (if any).
#[ ! -f "$i" ] && continue
case "$i" in
*.sh)
# Source shell script for speed.
(
trap - INT QUIT TSTP
set stop
. $i
)
 ;;
*)
# No sh extension, so fork subprocess.
$i stop
 ;;
esac
done</pre>

== Start- und Stop-Skript aus Optware-ipkg.sh heraus aufrufen ==
<nowiki># cd /etc/init.d
# vi Optware-ipkg.sh
Die Sektion in start/stop folgendermassen anpassen

case "$1" in
start)
/bin/echo "Enable Optware/ipkg"
# sym-link $QPKG_DIR to /opt
/bin/rm -rf /opt
/bin/ln -sf $QPKG_DIR /opt
# adding Ipkg apps into system path ...
/bin/cat /etc/profile | /bin/grep "PATH" | /bin/grep "/opt/bin" \
1>>/dev/null 2>>/dev/null
[ $? -ne 0 ] && /bin/echo "export PATH=$PATH":/opt/bin:/opt/sbin \
>> /etc/profile
if [ -x /opt/optstart.sh ]; then
/opt/optstart.sh
fi
 ;;
stop)
/bin/echo "Disable Optware/ipkg"
if [ -x /opt/optstop.sh ]; then
/opt/optstop.sh
fi
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/bin/sync
/bin/sleep 1
 ;;</nowiki>
== FHEM Init-Skript anlegen ==
<nowiki># cp /share/HDA_DATA/Public/TS109/fhem-4.8/contrib/init-skripts/fhem.2 \
/opt/etc/init.s/init_fhem
# vi /opt/etc/init.d/init_fhem
#!/bin/sh
# by Matthias Bauer
case "$1" in
start)
echo "Starting $0"
/opt/bin/fhem.pl /opt/etc/fhem.cfg
 ;;
stop)
echo "Stopping $0"
/opt/bin/fhem.pl 7072 shutdown
 ;;
status)
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "$0 is not running"
else
echo "$0 is running"
fi
 ;;
*)
echo "Usage: $0 {start|stop|status}"
exit 1
esac
exit 0</nowiki>
=== Ausführbar machen und Links anlegen ===
<nowiki># chmod u+x init_fhem
# ln -s init_fhem S30fhem
# ln -s init_fhem K10fhem</nowiki>
== Startskript zum Laden der USB-Serial Kernel Module anlegen ==
<nowiki># vi S01kernel-modules
#!/bin/sh
ln -s /opt/lib/modules/2.6.12.6-arm1/kernel /lib/modules
insmod /lib/modules/kernel/drivers/usb/serial/usbserial.ko vendor=0x03eb product=0x204b
insmod /lib/modules/kernel/drivers/usb/serial/ftdi_sio.ko
insmod /lib/modules/kernel/drivers/usb/serial/pl2303.ko</nowiki>
=== Ausführbar machen ===
<nowiki># chmod u+x S01kernel-modules</nowiki>
= Reboot und Test =
Viel Spass

TorstenS 06.03.2010

[[Kategorie:HOWTOS]]
[[Kategorie:Server Hardware]]

Qnap NAS

2021-06-06T20:25:12Z

Maista: /* Benötigte Pakete für fhem insatllieren */

{{Randnotiz|RNTyp=Info|RNText=Ergänzungen und Aktualisierungen in {{Link2Forum|Topic=60300}} bitte beachten!}}
= Installation von FHEM auf einem QNAP NAS =
Diese Anleitung beschreibt detailiert, wie FHEM auf einer
QNAP Turbo Station TS-109 II pro installiert werden kann.
Im wesentlichen wird die Vorgehensweise auch für weitere QNAP NAS
gelten.

== Überblick ==
Die aktuelle QNAP Firmware 3.1.0 Build 0708 unterstützt die
Installation von IPKG Paketen. Sämtliche für FHEM benötigte
Software ist auf diese Weise verfügbar, so dass die Installation
eigentlich sehr einfach vonstatten gehen könnte. Leider hat QNAP
an einigen Stellen geschlampt und man muss von Hand etwas nachhelfen.
Desweiteren ist Handarbeit gefragt für folgende Zusatzfunktionen

* Auslagerung der FHEM Logfiles auf einen Speicherstick. Somit kann die interne Festplatte weiterhin in den Spin Down gehen.
* Autostart von FHEM bein Booten des NAS
* Geordnetes Runterfahren von FHEM beim Herunterfahren des NAS
= Installation des QPKG Paketes Optware IPKG =
Über die NAS Web-Administration kann das Optware IPKG Paket
Optware_0.99.163_arm-x09.qpkg Installiert werden.
In dem Paket für die TS-109 sind leider einige Fehler enthalten, die
im folgenden korrigiert werden. Diese und alle weiteren Eingaben
sind auf der [[Kommandozeilentools|Kommandozeile]] durchzuführen.

== Anpassen der ipkg Konfiguration ==
=== Namen der Konfigurationsfiles korrigieren ===
<nowiki># cd /share/HDA_DATA/.qpkg/Optware/etc/ipkg
# mv tsx19-kmod.conf tsx09-kmod.conf
# mv tsx19.conf tsx09.conf</nowiki>
=== Repository für ipkg Pakete korrigieren ===
<nowiki># vi tsx09-kmod.conf
Ändern von
src tsx19 http://ipkg.nslu2-linux.org/feeds/optware/tsx19/cross/unstable
in
src tsx09 http://ipkg.nslu2-linux.org/feeds/optware/tsx09/cross/stable</nowiki>
=== Repository für die ipkg Kernel Module korrigieren ===
<nowiki># vi tsx09.conf
Ändern von
src cs08q1armel http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable
in
src cs05q3armel http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/unstable</nowiki>
=== Zusätzliches Installationsziel für ipkg in die Config aufnehmen ===
Die Kernel Module werden sonst nach /lib/modules installiert, und das wird bei jedem reboot überschrieben. Also müssen sie explizit nach /opt/lib/modules installiert werden.

<nowiki># cd /share/HDA_DATA/.qpkg/Optware/etc
# vi ipkg.conf
Hinzufügen von
dest opt /opt</nowiki>
=== Anpassen des Paketnamens ===
Es muss überall Optware-ipkg heissen.

<nowiki># cd /share/HDA_DATA/.qpkg/Optware
# mv Optware.sh Optware-ipkg.sh
# vi Optware-ipkg.sh
Ändern von
QPKG_NAME=“Optware“
in
QPKG_NAME=“Optware-ipkg“</nowiki>
=== Optware „mounten“ ===
<nowiki># /share/HDA_DATA/.qpkg/Optware/Optware-ipkg.sh restart</nowiki>

= Zusätzliche Software installieren =
Nun können die für FHEM benötigten Pakete per ipkg installiert werden.

== Paketliste aktualisieren ==
<nowiki># ipkg update</nowiki>
== Kernel Module für USB-Serial Hardware ==
Das usbserial Modul unterstützt diverse USB nach seriell Wandler.
Für ein CUL sind keine weiteren Kernel Module nötig.
Ein FHT-1000 benötigt zusätzlich des ftdi-sio Modul.
Eine Reihe von günstigen USB nach seriell Adapterkabel benutzen den
Proliftic PL-2303 Chip. Hierfür ist ebenfalls ein weiteres Modul nötig.
Über ein solches Kabel ist dann Beispielsweise ein ELV M232 Modul anzuschliessen.
Neben den Kernel Modulen habe ich noch die libusb installiert.
Die benötige ich später einmal um einen IOWarrior anzusprechen.

'''Bei den Kernel Modulen beachten, dass diese nach /opt installiert werden.'''Sonst sind sie nach dem nächsten Reboot weg.

<nowiki># ipkg -d opt install ts209-kernel-module-usbserial
# ipkg install -d opt ts209-kernel-module-ftdi-sio
# ipkg install -d opt ts209-kernel-module-pl2303
# ipkg install libusb</nowiki>
=== Kernel Module linken ===
<nowiki># ln -s /opt/lib/modules/2.6.12.6-arm1/kernel /lib/modules</nowiki>
=== Module laden mit Vendor und Product ID für CUL ===
<nowiki># insmod /lib/modules/kernel/drivers/usb/serial/usbserial.ko vendor=0x03eb product=0x204b
# insmod /lib/modules/kernel/drivers/usb/serial/ftdi_sio.ko
# insmod /lib/modules/kernel/drivers/usb/serial/pl2303.ko</nowiki>
Nun kann man den CUL anstöpseln und prüfen, ob er erkannt wurde

<nowiki># cd /usr/local/share # hier liegt usb.ids
# lsusb
Sollte u.A. folgendes ausgeben ...
ID 03eb:204b Atmel Corp.
# dmesg
Sollte folgendes ausgeben ...
usbserial_generic 2-1.4:1.1 Generic converter detected
usb 2-1.4: Generic converter now attached to ttyUSB0</nowiki>
== Benötigte Pakete für FHEM installieren ==
<nowiki># ipkg install perl perl-device-serialport
# ipkg install make # für die fhem Installation
# ipkg install gcc # richtige libgcc für perl
# ipkg install gnuplot # optional, falls lediglich plotmode SVG verwendet</nowiki>
= FHEM Installieren =
FHEM am PC downloaden und in ein QNAP Public Verzeichniss auspacken z.B.

<nowiki>/share/HDA_DATA/Public/TS109/fhem-4.8</nowiki>
== Ins Download Verzeichniss wechseln ==
<nowiki># cd /share/HDA_DATA/Public/TS109/fhem-4.8</nowiki>
== Pfade im Makefile auf /opt/ .... ändern ==
<nowiki># vi Makefile
BINDIR=/opt/bin
MODDIR=/opt/lib
VARDIR=/opt/var/log/fhem</nowiki>
== Logverzeichniss anlegen ==
Dieses Verzeichniss wird später auf einen Speicherstick ausgelagert.

<nowiki># mkdir -p /opt/var/log/fhem</nowiki>
== Installieren ==
<nowiki># make install-pgm2</nowiki>
== Pfad von perl in fhem.pl anpassen ==
<nowiki># vi /opt/bin/fhem.pl
#!/opt/bin/perl</nowiki>
== Konfigfile nach /opt/etc kopieren und editieren ==
<nowiki># cp /opt/var/log/fhem/fhem.cfg /opt/etc/fhem.cfg
#vi /opt/etc/fhem.cfg
attr global logfile /opt/var/log/fhem/fhem-%Y-%V.log
attr global statefile /opt/var/log/fhem/fhem.savestate
define CUL CUL /dev/usb/ttyUSB0 <Hauscode></nowiki>
== Probeweise starten ==
<nowiki># /opt/bin/fhem.pl /opt/etc/fhem.cfg</nowiki>
== Stoppen ==
<nowiki># killall fhem.pl</nowiki>
= Logfiles auf USB-Stick auslagern =
== Stick anstöpseln und prüfen, wo er gemounted wurde ==
<nowiki># mount|grep vfat
/dev/sdu on /share/external/sdu type vfat</nowiki>
== Lokale Logfiles verschieben und verlinken ==
<nowiki># cd /opt/var/log
# cp -r fhem /share/external/sdu
# mv fhem fhem.local
# ln -s /share/external/sdu/fhem</nowiki>
= Autostart und Stop einrichten =
== Startskript anlegen ==
# vi /share/HDA_DATA/.qpkg/Optware/optstart.sh

<pre>#!/bin/sh
# wait for optware init
while ( test -z "$(grep /opt/bin /etc/profile)" ); do sleep 10; done
# get new PATH
source /etc/profile
# Execute all start scripts in /opt/etc/init.d
# executing them in numerical order.
#
for i in /opt/etc/init.d/S??* ;do
# Ignore dangling symlinks (if any).
#[ ! -f "$i" ] && continue
case "$i" in
*.sh)
# Source shell script for speed.
(
trap - INT QUIT TSTP
set start
. $i
)
 ;;
*)
# No sh extension, so fork subprocess.
$i start
 ;;
esac
done</pre>
=== Startskript ausführbar machen ===
# chmod a+x optstart.sh

== Und noch einmal als Stopskript mit kleinen Änderungen ==
# cp optstart.sh optstop.sh
# chmod a+x optstop.sh

<pre>#!/bin/sh
# Execute all kill scripts in /opt/etc/init.d
# executing them in numerical order.
#
for i in /opt/etc/init.d/K??* ;do
# Ignore dangling symlinks (if any).
#[ ! -f "$i" ] && continue
case "$i" in
*.sh)
# Source shell script for speed.
(
trap - INT QUIT TSTP
set stop
. $i
)
 ;;
*)
# No sh extension, so fork subprocess.
$i stop
 ;;
esac
done</pre>

== Start- und Stopskript aus Optware-ipkg.sh heraus aufrufen ==
<nowiki># cd /etc/init.d
# vi Optware-ipkg.sh
Die Sektion in start/stop folgendermassen anpassen

case "$1" in
start)
/bin/echo "Enable Optware/ipkg"
# sym-link $QPKG_DIR to /opt
/bin/rm -rf /opt
/bin/ln -sf $QPKG_DIR /opt
# adding Ipkg apps into system path ...
/bin/cat /etc/profile | /bin/grep "PATH" | /bin/grep "/opt/bin" \
1>>/dev/null 2>>/dev/null
[ $? -ne 0 ] && /bin/echo "export PATH=$PATH":/opt/bin:/opt/sbin \
>> /etc/profile
if [ -x /opt/optstart.sh ]; then
/opt/optstart.sh
fi
 ;;
stop)
/bin/echo "Disable Optware/ipkg"
if [ -x /opt/optstop.sh ]; then
/opt/optstop.sh
fi
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/bin/sync
/bin/sleep 1
 ;;</nowiki>
== FHEM Initskript anlegen ==
<nowiki># cp /share/HDA_DATA/Public/TS109/fhem-4.8/contrib/init-skripts/fhem.2 \
/opt/etc/init.s/init_fhem
# vi /opt/etc/init.d/init_fhem
#!/bin/sh
# by Matthias Bauer
case "$1" in
start)
echo "Starting $0"
/opt/bin/fhem.pl /opt/etc/fhem.cfg
 ;;
stop)
echo "Stopping $0"
/opt/bin/fhem.pl 7072 shutdown
 ;;
status)
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "$0 is not running"
else
echo "$0 is running"
fi
 ;;
*)
echo "Usage: $0 {start|stop|status}"
exit 1
esac
exit 0</nowiki>
=== Ausführbar machen und Links anlegen ===
<nowiki># chmod u+x init_fhem
# ln -s init_fhem S30fhem
# ln -s init_fhem K10fhem</nowiki>
== Startskript zum Laden der Usb-serial Kernel Module anlegen ==
<nowiki># vi S01kernel-modules
#!/bin/sh
ln -s /opt/lib/modules/2.6.12.6-arm1/kernel /lib/modules
insmod /lib/modules/kernel/drivers/usb/serial/usbserial.ko vendor=0x03eb product=0x204b
insmod /lib/modules/kernel/drivers/usb/serial/ftdi_sio.ko
insmod /lib/modules/kernel/drivers/usb/serial/pl2303.ko</nowiki>
=== Ausführbar machen ===
<nowiki># chmod u+x S01kernel-modules</nowiki>
= Reboot und Test =
Viel Spass

TorstenS 06.03.2010

[[Kategorie:HOWTOS]]
[[Kategorie:Server Hardware]]

VALVES

2021-05-10T18:13:22Z

Maista: /* Auch hier nur Schreibfehler bereinigt */

{{Infobox Modul
|ModPurpose=Durchschnitt mit individueller Gewichtung und Ignore

|ModType=x

|ModForumArea=Codeschnipsel
|ModTechName=39_VALVES.pm
|ModOwner=epsrw1,cwagner}}
[[VALVES]] bietet eine einfache Möglichkeit, den nach flexibel konfigurierbaren Regeln gewichteten Durchschnittswert einer Gruppe von Werten zu berechnen.

== Features ==
Diese Wiki-Seite beschreibt den Versionsstand 1.0 des VALVES-Moduls.

Die Namensgebung beruht auf der primären Anwendung des Moduls auf Valve-Position-Readings von Heizungsthermostaten.

Thread im Forum:{{Link2Forum|Topic=24658|Message=177528}}

== Beschreibung ==
[[Datei:dok39_VALVES.jpg|mini|Funktionsweise]]

VALVES bietet als kleines Helferlein die Möglichkeit, einen halbwegs sinnvollen und individuell gewichteten Durchschnittswert der Readings mehrerer verschiedener Devices zu berechnen.

Für jeden Wert einzeln kann ein Offset definiert werden. Es können dynamisch jeweils die höchsten/niedrigsten 0 bis 3 Werte ignoriert werden. Eine weitere Einstellung ermöglicht, bestimmte Werte doppelt zu zählen.

''Im Anwendungsbeispiel [[Raumbedarfsabhängige Heizungssteuerung]] wird das Modul zum Beispiel verwendet, um den Durchschnittswert der Ventilöffnungen aller Heizkörper zu berechnen. Die individuelle Gewichtung über Attr ermöglicht hierbei einen virtuellen hydraulischen Abgleich.''

Die Liste aller auszulesenden Devices wird in einem ATTR eingestellt, der Name des Readings in einem weiteren. Das Modul prüft dann regelmäßig (attr: poll interval) die Daten der FHEM-Devices und berechnet neu, wenn ein Änderung festgestellt wird.

Für die Beeinflussung des Durchschnittes hat man folgende Attribute:

* ignoriere niedrigste 0...3 Positionen

* ignoriere höchste 0...3 Positionen

* ignoriere namentlich genannte Devices

* priority-device Liste (zählen doppelt)

* valves<Devicename>Gewichtung optionale Einzeleinstellung für jedes Reading, multipliziere mit Attr-Wert (zB:0,95 um 5% abzuziehen). Damit können Unterschiede bekannte gleichbleibende Meßungenauigkeiten kompensiert werden, oder verschieden große Geräte in vergleichbare Rechengrößen konvertiert werden.

== Define ==
:<code>define <name> VALVES </code>

== Attribute ==
Alle Attribute sind auch in FHEM durch das Kommando get attrHelp <varname> erklärt, fürs "schnelle Nachschauen zwischendurch".

valvesInitialDelay -> Startverzögerung

valvesPollInterval -> Berechnungsfrequenz

valvesDeviceList -> '''Pflicht-Attr''', Liste Thermostate mit valve-pos Readings

valvesDeviceReading -> '''Pflicht-Attr''', Bezeichnung valve-pos Reading

valvesIgnoreLowest -> Niedrigste N Werte ignorieren

valvesIgnoreHighest -> Höchste N Werte ignorieren

valvesIgnoreDeviceList -> Device(s) die komplett ignoriert werden, z.B. temporärer Eintrag für Gästezimmer

valvesPriorityDeviceList -> Devices, die doppelt gezählt werden

valves<Devicename> Gewichtung -> Faktor für einzelnes Device für individuelle Gewichtung

== Settings ==
reset -> Alle Readings zurücksetzen

== Readings ==
state -> Fehlermeldung oder Mittelwert nach oben beschriebener Berechnung

valve_<Devicename> -> Berechnete virtuelle Ventilstellung pro Gerät

valveDetail_<Devicename> -> Debug-Info mit Details

raw_average -> Simpler Mittelwert ohne Berücksichtigung der Gewichtungen (ignores werden auch hier ignoriert)

valve_average -> Mittelwert nach oben beschriebener Berechnung

valve_max -> Größte aktuelle Ventilöffnung seit letztem Reset

valve_min -> Kleinste aktuelle Ventilöffnung seit letztem Reset

== Weblinks ==
* {{Link2Forum|Topic=24658|Message=177528}} Thread im Forum, in dem dieses Modul vorgestellt wurde
* ...

[[Kategorie:Regelungstechnik]]
[[Kategorie:Heizungssteuerung]]

Raumbedarfsabhängige Heizungssteuerung

2021-05-10T18:07:46Z

Maista: /* Schreibfehler bereinigt */

{{Infobox Modul
|ModPurpose=Dieses Modul ist noch Entwicklung
|ModType=x


|ModForumArea=Codeschnipsel
|ModTechName=39_VALVES.pm
|ModOwner=epsrw1,cwagner}}

Das FHEM-[[:Kategorie:Hilfsmodul|Hilfsmodul]] [[VALVES]] bietet eine einfache Möglichkeit, eine raumbedarfsabhängige Steuerung des Vorlaufes (Brenner oder Mischer, dazu siehe auch [[Mischersteuerung]]) einer Zentralheizung umzusetzen. Diese berücksichtigt besser als eine Außentemperatursteuerung interne und externe Wärmequellen.

== Features ==

Diese Wiki-Seite beschreibt den derzeitigen Stand des VALVES-Moduls.

----

Thread im Forum:{{Link2Forum|Topic=24658|Message=177528}}

== Beschreibung ==

[[Datei:dok39_VALVES.jpg|mini|Funktionsweise]]
VALVES bietet als kleines Helferlein die Möglichkeit, einen halbwegs sinnvollen und individuell gewichteten Durchschnittswert der Ventilpositionen mehrerer Heizungsthermostate zu berechnen.

Dieser (gewichtete) Durchschnittswert der Ventilöffnungen ist ein Ausdruck der Wärmeanforderung im Haus. Da die Raumthermostate aus der FS20-, der Homematic und der Max-Reihe ihrerseits immer bessere Strategien verfolgen, um die Entwicklung der Temperatur in jeweils "ihrem" Raum zu erkennen, hat die Ventilposition eine große Aussagekraft.

Zugleich wird auch Vorlaufsteuerung des Heizkessels oder der Heiztherme automatisch durch Nachtabsenkungen, Abwesentheitsschaltungen einerseits und durch zusätzliche Wärmequellen, die das Haus aufheizen, beeinflusst.

Idealerweise ist der Vorlauf dann gerade so groß, dass der Wärmebedarf im Haus überall gestillt wird.

Die Liste aller Thermostate wird in einem ATTR eingestellt, der Name des Readings mit der Ventilposition in einem weiteren. Das Modul prüft dann regelmäßig (attr: poll interval) die Daten des FHEM-Devices und berechnet neu, wenn ein Änderung festgestellt wird.

Für die Beeinflussung des Durchschnittes hat man folgende Attribute:

* ignoriere niedrigste 0...3 Positionen

* ignoriere höchste 0...3 Positionen

* ignoriere namentlich genannte Devices

* priority-device Liste (zählen doppelt)

* valves<Devicename>Gewichtung optionale Einzeleinstellung für jeden Thermostat, multipliziere mit attr-wert (zB:0,95 um 5% der Position abzuziehen). Damit können Unterschiede im hydraulischen Abgleich kompensiert werden, oder individuelles Nutzungsverhalten feinjustiert.

== Define ==
<code>
define <name> VALVES
</code>

----

== Attribute ==

Alle Attributes sind auch in FHEM durch das Kommando get attrHelp <varname> erklärt, fürs "schnelle Nachschauen zwischendurch".

valvesInitialDelay -> Startverzögerung

valvesPollInterval -> Berechnungsfrequenz

valvesDeviceList -> '''Pflicht-Attr''', Liste >Thermostate mit valve-pos Readings

valvesDeviceReading -> '''Pflicht-Attr''', Bezeichnung valve-pos Reading

valvesIgnoreLowest -> Niedrigste N Werte ignorieren

valvesIgnoreHighest -> Höchste N Werte ignorieren

valvesIgnoreDeviceList -> Device(s) die komplett ignoriert werden, z.B. temporärer Eintrag für Gästezimmer

valvesPriorityDeviceList -> Devices, die doppelt gezählt werden

valves<Devicename>Gewichtung -> Faktor für einzelnes Device für individuelle Gewichtung

== Settings ==
reset -> Alle Readings zurücksetzen

== Readings ==

state -> Fehlermeldung oder Mittelwert nach oben beschriebener Berechnung

valve_<Devicename> -> Berechnete virtuelle Ventilstellung pro Gerät

valveDetail_<Devicename> -> Debug-Info mit Details

raw_average -> Simpler Mittelwert ohne Berücksichtigung der Gewichtungen (ignores werden auch hier ignoriert)

valve_average -> Mittelwert nach oben beschriebener Berechnung

valve_max -> Größte aktuelle Ventilöffnung seit letztem Reset

valve_min -> Kleinste aktuelle Ventilöffnung seit letztem Reset

== Weblinks ==
* {{Link2Forum|Topic=24658|Message=177528}} Thread im Forum, in dem dieses Modul vorgestellt wurde
* to be continued

[[Kategorie:Regelungstechnik]]
[[Kategorie:Examples]]
[[Kategorie:Heizungssteuerung]]

TelegramBot

2020-12-28T20:24:37Z

Maista: /* Fehlermeldungen bei veralteter SSL-Version */

{{Infobox Modul
|ModPurpose=Senden und Empfangen von Nachrichten (Text und Fotos) mit dem freien Messagingdienst Telegram
|ModType=d
|ModForumArea=Unterstützende Dienste
|ModFTopic=38328
|ModTechName=[https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm 50_TelegramBot.pm]
|ModOwner=[[Benutzer:Viegener|Viegener]] ({{Link2FU|12772|Forum}} / [[Benutzer Diskussion:Viegener|Wiki]])}}

Das [[TelegramBot]]-Modul ermöglicht das Senden und Empfangen von Nachrichten über den Telegram-instant messaging Dienst (https://telegram.org/).
Es entsteht eine Möglichkeit Benachrichtungen aus FHEM zu versenden, zum Beispiel Alarmmeldungen.
Ausserdem können auch Kommandos über Telegram an FHEM gesendet werden um Steuerungsbefehle in FHEM auszulösen.

Das TelegramBot-Modul benötigt keine Zusatzsoftware auf dem FHEM-Server<ref>anders als die Vorläufer-Variante über das [[Telegram - old API method|Telegram-API]]</ref>, sondern verwendet das [https://core.telegram.org/bots/api TelegramBot-API] über https-Aufrufe. Es muss jedoch das [http://www.fhemwiki.de/wiki/Raspberry_Pi#N.C3.BCtzliche_Zusatzpakete perl JSON modul] installiert sein.

== Über Telegram Instant Messaging ==
Telegram-IDs und Versand/Empfang von Nachrichten sind kostenfrei.
Clients sind für gängige Smartphonesysteme erhältlich (iOS iPhone und Tablet, Android, Windows Phone) und
können auch aus dem WebBrowser verwendet werden.
Es gibt auch einen Kommandozeilen-Client für Linux, der die Grundlage dieses Moduls darstellt.
Mehrfachanmeldungen, auch parallel mit verschiedenen Geräten (z.B. Tablet und Smartphone), sind möglich.
Gruppenchats und Chats mit End-2-End-Verschlüsselung werden ebenfalls unterstützt.

Für die Unterstützung von ''WhatsApp'' siehe Modul [[yowsup]].

Unterstützt werden:

* Versand von Textnachrichten
* Versand und Empfang von Bildern/Audio/etc
* Empfang von Textnachrichten von beliebigen Kontakten
* Kommandos in FHEM über Telegram-Nachrichten von aussen auslösen
* Ergebnisse der Kommandos zusenden lassen

Eine detaillierte Beschreibung des Moduls ist im FHEM Forum und in der (englischen) Dokumentation zum Modul in der {{Link2CmdRef|Anker=TelegramBot}} und in diesem {{Link2Forum|Topic=38328|LinkText=Diskussionsthread}} zu finden. Seit Oktober 2015 wird das Modul offiziell über FHEM-Update verteilt.

Die jeweils aktuellste Entwicklungs-Version des Moduls ist in Github [https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm 50_TelegramBot.pm] verfügbar.

== TelegramBot Devices in FHEM ==
=== Define ===
{{Randnotiz|RNTyp=Info|RNText=Achtung: Dieses Authtoken ist die einzige Authentifizierung für den Bot und sollte deshalb nicht aus der Hand gegeben werden. Die verwendeten Urls sind deshalb auch in den Log-Files nicht enthalten, da diese das Authtoken in Klartext enthalten. Auch im Forum sollte dieses Token nicht aufgenommen werden.
}}

Für die Anlage eines TelegramBot Devices in FHEM ist ein Authtoken erforderlich. Dieses Token wird über Anlegen eines neuen Bots im [https://core.telegram.org/bots#6-botfather BotFather] erzeugt (siehe dazu unten). Dafür muss der BotFather mit einem Telegram-Client kontaktiert werden. Dort mit dem Telegram-Befehl <code>/newbot</code> einen neuen Bot anlegen und mit einem Namen versehen. Hinweis: Die Namen für Bots müssen auf "Bot" enden. 

Das Anlegen eines TelegramBot devices erfolgt durch die Angabe dieses Tokens:

<code>define <name> TelegramBot <token> </code>

Beispiel: <code>define myTelegramBot TelegramBot 110201543:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw</code>

'''Das Empfangen von Nachrichten (polling) erfordert die Einstellung des Attributes'''
<code>pollingTimeout</code> '''auf einen Wert der grösser als Null ist. Beim Wert 0 oder ohne Setzen des Attributes findet kein Polling und damit auch kein Empfang statt.'''

Beispiel: <code>attr myTelegramBot pollingTimeout 120</code>

'''Der TelegramBot kann erst dann Nachrichten an einen telegram user schicken, wenn dieser zuerst an den telegram bot eine Nachricht gesendet hat.'''
Dafür muss man in seinem Telegram-Client den Kontakt @botName suchen und dann eine Nachricht daran versenden.

'''Der TelegramBot kann keine Nachrichten an andere Bots senden. Ein anderer Bot erhält die Nachrichten auch nicht wenn er in einer Gruppe enthalten ist.''' Dies ist eine Beschränkung in der Bot-Funktion bei Telegram. Das Versenden an einen anderen Bot (wenn man den Kontakt manuell hinzugefügt hat) führt zur Fehlermeldung
<code>sentMsgResult - Callback returned error :Bad Request: chat not found:</code>

{{Randnotiz|RNTyp=Info|RNText=TelegramBot setzt eine aktuelle Version von FHEM voraus, insbesondere Versionen weit vor der Umstellung auf 5.7 (also vor Herbst 2015) können mit einem TelegramBot-Modul nicht funktionieren, da insbesondere das HTTPSRV-Modul dann veraltet ist. Am besten auch den TelegramBot über den offiziellen Update mit dem Rest von FHEM installieren/aktualisieren.
}}

=== Registrierung eines neuen Bot ===
Zur Registrierung wird ein funktionierender Telegram-Client (egal ob Web, App oder Programm)benötigt. Hier wird ein Chat zum BotFather gestartet und der Befehl /newbot gesendet. Nun fragt der BotFather die benötigten Angaben ab und liefert am Ende des Dialogs die Informationen für den neuen Bot.
Hier ein Beispiel, wie so ein Chat aussehen könnte:
<pre>Client:
/newbot
----------------
BotFather:
Alright, a new bot. How are we going to call it? Please choose a name for your bot.
----------------
Client:
Mein Name
----------------
BotFather:
Good. Now let's choose a username for your bot. It must end in `bot`. Like this, for example: TetrisBot or tetris_bot.
----------------
Client:
fhem_bot
----------------
BotFather:
Sorry, this username is already taken. Think of something different.
----------------
Client:
fhem1234_bot
----------------
BotFather:
Done! Congratulations on your new bot.
You will find it at telegram.me/fhem1234_bot.
You can now add a description, about section and profile picture for your bot, see /help for a list of commands.
----------------
Use this token to access the HTTP API:
1234567890:AbCdefgHIJklmnOPQRst-uvwxyz

For a description of the Bot API, see this page: https://core.telegram.org/bots/api
</pre>
{{Randnotiz|RNTyp=Info|RNText=Achtung: Da Bots generell für alle Benutzer sichtbar sind und es gelegentlich Problem mit spammern gibt, die fremde bots auch in Gruppen hinzufügen, ist es empfehlenswert die Einstellung /setjoingroups auf false zu setzen, wenn die Zugehörigkeit zu Gruppen (und der Empfang von Meldungen aus gruppen) nicht notwendig ist
}}

Um einen Chat an einen "Contact" versenden zu können, muss zuerst in Contacts (bei Readings) ein Kontakt auftauchen. Wenn man sich zum allerersten Mal bei Telegram angemeldet hat, gibt es noch keinen Chat mit irgendjemanden. Man muss sich zuerstmal selbst eine Nachricht im Smartphone zusenden, dann taucht unter Readings der Eintrag Contacts auf. Erst dann kann man eine Nachricht mit @msgPeerId (das ist Ziffernfolge des Contacts ) oder mit @msgPeer (das ist der Name nach dem Doppelpunkt) vom TelegramBot auf sein Smartphone senden.

== Tipps ==

=== Privacyeinstellungen ===

Damit der TelegramBot auch Meldungen in Gruppen sieht, müssen über den BotFather die Privacy-Einstellungen geändert werden. Beispielchat:<pre>Client:
/setprivacy
----------------
BotFather:
Choose a bot to change group messages settings.
----------------
Client:
@fhem1234_bot
----------------
BotFather:
'Enable' - your bot will only receive messages that either start with the '/' symbol or mention the bot by username.
'Disable' - your bot will receive all messages that people send to groups.
Current status is: ENABLED
----------------
Client:
Disable
----------------
BotFather:
Success! The new status is: DISABLED. /help</pre>

Siehe auch Info zu /setjoingroups oben.

=== Kontakte ===

Der Bot merkt sich die bereits bekannten Kontakte im Reading <code>Contacts</code>. Dabei werden die einzelnen Kontakte jeweils als 3-teilige Einträge gespeichert - bestehend aus UserID, Vor- und Nachname des Benutzers (mit _ verbunden) und dem Username (mit vorangestelltem @).

Beispiel: <code>123456:Ralf_Mustermann:@ralf</code>

Verschiedene Einträge werden durch Leerzeichen getrennt.

Man kann die Kontakte auch manuell überschreiben (z.B. wenn das Reading fehlerhaft oder verloren sein sollte). Dazu gibt es den Set-Befehl <code>replaceContacts</code>. Dieser nimmt die Kontakte ebenfalls in der gleichen Form wie oben beschrieben entgegen.

Die Kontaktliste wird ansonsten nur durch den Empfang von Nachrichten erweitert, da es im TelegramBot-API keine Möglichkeit gibt Kontaktdaten von Telegram abzufragen (siehe auch pollingTimeout)

=== Reset ===

Es ist möglich den Bot im laufenden Betrieb zurückzusetzen (Set-Befehl <code>reset</code>). Dabei werden noch nicht abgeschlossene Übetragungen entfernt und die internen Zustände des Devices zurückgesetzt.

=== Gruppen ===

Um eine Nachricht von FHEM an eine Gruppe zu senden, muss der BOT in die Gruppe aufgenommen werden. Nach dem Senden einer Nachricht an die Gruppe kann im Modul die Gruppen-ID ermittelt werden und zum Senden von Nachrichten verwendet werden. Die Gruppen-ID ist eine negative Zahl. Wenn die Privacy-Einstellungen nicht auf 'Disabled' gesetzt wurden, muss die Nachricht mit einem Slash (/) beginnen.

==== Supergroups / Supergruppen ====

Auch die neuen Supergruppen werden mit dem Bot unterstützt, es ist allerdings zu beachten, dass bei der Umwandlung einer Gruppe in eine Supergruppe eine neue ID in den Kontakten von Telegram vergeben wird. Wenn man also wie empfohlen IDs zur Identifikation von Benutzern einsetzt, muss entsprechend angepasst werden.

==== Fehlermeldungen bei veralteter SSL-Version ====
Telegram nutzt seit Februar 2020 eine neue Verschlüsselung und dies ruft bei veralteter Installation eine Fehlermeldung hervor:

NonBlockingGet: returned <hidden>: Can't connect(2) to <nowiki>https://api.telegram.org:443</nowiki>

Dies deutet auf eine veraltete SSL-Version hin, siehe dazu die Forumsdiskussion ab {{Link2Forum|Topic=38328|Message=1021642|LinkText=diesem Beitrag}}. Hilfreich hat sich ein upgrade der SSL-Module erwiesen. Zuerst muss u.U. ein Modul installiert werden
:<code>sudo apt-get install libssl-dev</code>
und danach in zwei Schritten
sudo cpan <enter>
upgrade net::SSLeay<enter>
Es ist bei Jessie zwingend ein Upgrade von
IO::Socket::SSL 2.002 -> 2.066
notwendig. Es wird darauf hingewiesen, dass idealerweise nicht einzelne Module, sondern das gesamte OS sowie alle Perlmodule auf den neuesten Stand gebracht werden sollten.

=== Befehle von Telegram an FHEM senden ===
Es handelt sich hier um ein Tool, das {{Link2Forum|Topic=51425|Message=464928|LinkText=hier im Forum}} vorgestellt wurde. Dabei wird ein notify in FHEM angelegt, das den TelegramBot überwacht. Wird eine Befehlsfolge an den Bot gesendet, liest das Telegram-Device die gesendete Information aus und führt den Befehl aus. Weitere Details, wie hier vorzugehen ist, unter dem oben angegebenen Link im Forum.

Wenn man an FHEM Befehle senden will, muss der TelegramBot bereit sein, diese Nachrichten zu empfangen. Wenn man allerdings aus Sicherheitsgründen das Attribut
:<code>allowUnknownContacts = 0</code>
gesetzt hat, dann ist ein solcher Empfang nicht möglich. Daher muss (zumindest einmalig) erlaubt werden, von unbekannten Kontakten eine Nachricht zu bekommen. Nach dem ersten Empfang ist dann der Kontakt bekannt und man kann erneut den Empfang auf bekannte Kontakte beschränken.

== Beispielszenarien ==
=== Benachrichtigungen über Ereignisse ===
Das einfachste Szenario für die Integration von Messaging-Diensten mit FHEM ist zur Benachrichtigung über Ereignisse. Diese Funktion kann zum Beispiel verwendet werden, um über einen erfolgten Neustart von FHEM zu informieren:

<code>define notify_fhem_reload notify global:INITIALIZED set myTelegramBot message fhem newly started - just now !</code>

In diesem Beispiel wird der Nachrichtentext "fhem newly started - just now !" an den als default eingestellten Kontakt (Attribut: defaultPeer) gesendet, sobald FHEM neu gestartet wurde. Natürlich kann man auch beliebige andere Benachrichtigungen einführen.

Nebenbemerkung: hier ist eine erweiterte Strukturierung evt. empfehlenswert: statt jede Notify-Syntax o.ä. direkt auf TelegramBot-Spezifika gehen zu lassen, kann man sich eine Helper-Funktion (zur Vermittlung all solcher "Alarmtexte") bauen ([[99_myUtils_anlegen]]), die entsprechende Alarm-Meldungen dann nur intern auf (u.a.) einen Messaging-Service wie (momentan!) Telegram schickt.

=== Versand von Bildern ===

Es ist auch möglich Bilder auf dem FHEM-Server, die zum Beispiel von einer Kamera oder einem Wettermodul stammen über Telegram zu versenden. So wäre es z.B. möglich jeweils morgens die aktuelle Wetterkarte zu erhalten.

ACHTUNG: TelegramBot verwendet das HTTPUtils-Modul zur Kommunikation mit dem TelegramBot-API. Erst mit der Version, die seit 22.10.2015
([r9576] HttpUtils.pm: Async write for POST Requests {{Link2Forum|Topic=41583|LinkText=FHEM-Forum}}) verteilt wird, erlaubt auch den Transfer grösserer Bilder. Die Grenze liegt ansonsten bei ca. 14kb auf Raspberries (Plattformspezifische Grenze).

<code>define notify_fhem_reload notify wetter:report set myTelegramBot sendImage /opt/fhem/wetter.jpg</code>

Bei Erreichen des entsprechenden Status am Wetter-Modul wird ein Image über Telegram versendet. Hier sind lokale Pfade (relativ zu fhem) oder absolute Pfade wie oben möglich.

=== Versand von SVG-Plots ===

SVG-Plots können mit dem Befehl
<code>cmdSend [ @<peer1> ... @<peerN> ] <fhem command></code>
verschickt werden.

Das angegebene FHEM-Kommando wird ausgeführt und das Ergebnis an die angegebenen Peers bzw. den Standard-Peer verschickt.

Mit dem folgenden Befehl wird der SVG-Plot SVG_FileLog_Aussen an den Standard-Peer geschickt:
<code>set myTelegramBot cmdSend { plotAsPng('SVG_FileLog_Aussen') }</code>

Nach <code>define cmd_sendTelegramSVG cmdalias TGSVG .* AS set myTelegramBot cmdSend { plotAsPng("$EVENT") }</code>
kann man mit einem kurzen
<code>TGSVG SVG_Garten</code>
ein beliebiges SVG über die Kommandozeile per Telegram versenden.

Um das SVG nun noch mit einem Text zu versehen, muss eine Textnachricht dazu gesendet werden, was sich am einfachsten durch das Ausführen eines FHEM-Befehls auf Perl-Ebene realisieren lässt:

<code>{fhem "set myTelegramBot message Bildbeschreibung;; set myTelegramBot cmdSend { plotAsPng('mein_SVG') }" }</code>

'''Hinweis:''' früher wurde zum Verschicken von Plots auch die interne Funktion TelegramBot_ExecuteCommand verwendet; mit dem Update Ende Februar 2017 hat diese Funktion einen zusätzlichen Parameter erhalten und lautet nun
<code>TelegramBot_ExecuteCommand($defs{"myTelegramBot"}, meine_ZielID, undef, '{plotAsPng("mein_SVG")}');</code>

==== Voraussetzungen für den Versand von SVG-Plots ====
Es muss das Modul libimage-librsvg-perl installiert sein:

<code>sudo apt-get install libimage-librsvg-perl</code>

Evtl. sind weitere Module erforderlich:

<code>sudo apt-get install libgd-graph-perl

sudo apt-get install libgd-text-perl</code>

=== Empfang von Bildern oder ähnlichem ===

Beim Empfang von Bildern wird zuerst nur eine ID vom Telegram-Server empfangen, diese befindet sich im Reading <code>msgFileId</code> angelegt (<code>123456:xxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxx</code>) und im Reading <code>msgText</code> steht dann so etwas wie
<code>received photo # Size: 107701</code>

Über das Get-Kommando <code>urlForFile</code> mit der ID aus dem msgFileId Reading lässt sich dann daraus ein URL ableiten, der dann zur eigentlichen Datei führt:

<code>https://api.telegram.org/file/bot123456:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/photo/file_25.jpg</code>

=== Versand von Emojis (Smileys) ===

Es ist auch möglich Emojis mit den (Text-)Nachrichten zu versenden. Die entsprechenden (Unicode-)Zeichen werden einfach direkt mit in den Text der Nachricht aufgenommen. Um das zu vereinfachen kann man das einfach per Copy und Paste von dieser Seite

http://apps.timwhitlock.info/emoji/tables/unicode (Spalte "Native")

übernehmen und mit der Nachricht verschicken.

Die Emojis können auch empfangen werden und werden so auch in FHEM / FHEMWeb angezeigt. Plattformspezifische (z.B. von iOS oder Android) Emojis werden dabei nicht unterstützt (gerade mit iOS sind viele neue farbige Emojis hinzugekommen, die wohl leider nur auf Apple-devices funktionieren).

=== Kommandos auslösen ===

Ein wichtiges Szenario ist die Möglichkeit Kommandos in FHEM ausführen zu können, ohne einen Zugang durch die Firewall einrichten zu müssen. Dazu ist die Definition eines Schlüsselwortes (Attribut: "cmdKeyword") erforderlich, mit dem man die Nachrichten beginnen muss, damit der TelegramBot die Kommandos erkennt.

<code>attr myTelegramBot cmdKeyword doit</code>

Somit kann man dann durch Nachrichten die mit "doit" beginnen Kommandos an FHEM senden, die ähnlich wie im Kommandoeingabefeld von FHEMweb dann von FHEM ausgeführt werden. Das Ergebnis der Ausführung wird zurück an den Sender (und an den definierten defaultPeer) geschickt.

Somit können nicht nur Aktionen angestossen werden, sondern auch Infos abgefragt werden.

Beispiele

<code>doit set schalter on</code>

<code>doit list telegrambot</code>

==== TelegramBot-Aktionen auslösen ====
Der Bot sendet Nachrichten standardmäßig an den defaultPeer (falls definiert). So kann mit folgendem Befehl etwa der Versand eines Videos ausgelöst werden:

<code>doit set telegrambot sendMedia cam.mp4</code>

Soll eine Nachricht an einen anderen (bekannten) User geschickt werden, so ist die Angabe der ID des Users erforderlich. Dies kann dynamisch mit set-Logik und Abfrage der Readings erfolgen. Der folgende Befehl sendet das Video an den User, der das Kommando an den Bot geschickt hat:

<code>doit set telegrambot sendMedia @[TB:msgChatId] cam.mp4</code>

Bei der Definition von Favoriten (siehe unten) kann genau so vorgegangen werden.{{Randnotiz|RNTyp=Warn|RNText=Achtung: Bei den Kommandos sollten man unbedingt das Attribut "cmdRestrictedPeer" setzen, damit nicht jeder Kommandos auf dem FHEM-Server ausführen kann. Dazu sollten die BenutzerIDs der erlaubten Benutzer (durch Leerzeichen getrennt angeben). Da Benutzernamen selber vergeben werden und nicht unbedingt eindeutig sind, sollten hier auch NUR BenutzerIDs verwendet werden.
}}

==== Favoriten für Kommandos anlegen ====
Grundidee bei den Favoriten ist, dass man lange Befehle, die man häufig braucht auf "Kurzwahl" legt.

Beispiel-Kommandos wie z.B. <code>set TYPE=ROLLLADEN pos 100</code> und <code>set TYPE=ROLLLADEN pos 0</code>, die man immer wieder braucht. Um nicht jedes mal dieses Kommando eintippen zu müssen auf dem Smartphone, kann man auch dafür Favoriten anlegen.

Dazu gibt man erst mal die beiden Kommandos getrennt durch Semikolon im Attribut favorites an:

<code>attr myTelegramBot favorites set TYPE=ROLLLADEN pos 100;set TYPE=ROLLLADEN pos 0</code>

Um die Favorites jetzt ausführen zu können braucht man noch ein Schlüsselwort dafür.
Nehmen wir mal an man möchte die Favoriten mit <code>/short</code> ausführen können. Dazu muss dann das Attribut "cmdFavorites" setzen

<code>attr myTelegramBot cmdFavorites /short</code>

Wenn man nun im Telegram Client
<code>/short 1</code> an den Bot schickt führt der Bot den ersten Favoriten aus und das Ergebnis der Ausführung wird zurückgeschickt.

Ausserdem kann man im Telegram Client
<code>/short</code> an den Bot schicken, dann antwortet der Bot mit

<pre>
Favorites

/short1 = set TYPE=ROLLLADEN pos 100

/short2 = set TYPE=ROLLLADEN pos 0

</pre>

Die Antworten werden als Schaltflächen dargestellt (Telegram inline Keyboard) und können am Mobile-Client direkt angeklickt werden um sie auszuführen.
Um die Beschriftung der Schaltflächen zu optimieren, können die Befehle im Attribut favorites mit Beschreibungen versehen werden:

<code>/[Rolllaeden zu ]=set TYPE=ROLLLADEN pos 100;/[Rolllaeden auf]=set TYPE=ROLLLADEN pos 0</code>

Nun antwortet der Bot auf das Schlüsselwort für die Favoriten mit:

<pre>
Favorites

/short1 = Rolllaeden zu

/short2 = Rolllaeden auf

</pre>

=== Nützliche Kombinationen mit weiteren Modulen ===

==== msgConfig ====
{{Link2CmdRef|Anker=msgConfig|Lang=de|Label=msgConfig}}

{{Link2CmdRef|Anker=msgDialog|Lang=de|Label=msgDialog}}

==== msgDialog ====
[[MsgDialog]]

==== MSG ====
[[Msg]]

{{Link2CmdRef|Anker=MSG|Lang=en|Label=MSG}}

{{Link2Forum|Topic=39983|LinkText=Forum-Beitrag}}

==== PostMe ====
[[Modul PostMe#Steuerung per Telegram|PostMe]]

{{Link2CmdRef|Anker=PostMe|Lang=de|Label=PostMe}}

{{Link2CmdRef|Anker=TBot_List|Lang=en|Label=TBot_List}}

==== ROOMATE ====
{{Link2CmdRef|Anker=ROOMMATE|Lang=de|Label=ROOMMATE}}

==== MAX ====
[[MAX#Telegram-Benachrichtigung bei dauergeöffnetem Fenster|Dauer-offenes Fenster melden]]

==== SSCAM - Steuerung von Kameras in Synology Surveillance Station - Schnappschüsse mit TelegramBot versenden ====
[[SSCAM - Steuerung von Kameras in Synology Surveillance Station#Schnappschüsse mit TelegramBot versenden|Schnappschüsse mit TelegramBot versenden]]

==== PRESENCE ====
[[PRESENCE#Hinweis zur Benutzung / Fehlerhandling|Hinweis zur Benutzung / Fehlerhandling]]

==== AMAD ====
[[AMAD]]

==== TALKTOME & TALKTOUSER ====
[[TALKTOME & TALKTOUSER - Sprachverarbeitung für Nutzerinteraktionen#Beleuchtungssteuerung mit Telegram|Beleuchtungssteuerung mit Telegram]]

==== Staumelder ====
[[Staumelder#telegram|Staumelder]]

==== Grafana ====
[[Grafana#Speichern und Senden von Grafiken (zB_mit_Telegram)|Grafana-Plots versenden]]

==== Talk2Fhem ====
[[Talk2Fhem#Messenger Telegram|Talk2Fhem]]

==== Hausüberwachung ====
[[Hausüberwachung#Nachrichten aus dem Haus|Nachrichten aus dem Haus]]

==== Gäste-WLAN der Fritzbox auswerten und Login per Telegram senden ====

{{Link2Forum|Topic=100119|Message=936495|LinkText=Forum-Beitrag}}

==== Batterieüberwachung nur einmal täglich ====
{{Link2Forum|Topic=99219|Message=926652|LinkText=Forum-Beitrag}}

==== BOTVAC ====
[[BOTVAC#MAPS|Saugroboter-Karten]]

==== Unifi Voucher bereistellen über msgDialog ====
[[Unifi#über Telegram|Unifi Voucher]]

[[Unifi#Erkennung neuer clients|Erkennung unbekannter Clients]]

== Links ==
* Github Repository für die Telegram-FHEM Entwicklung: https://github.com/viegener/Telegram-fhem
* Infos zum Telegram BotFather: https://core.telegram.org/bots#6-botfather

* Source code für das 50_TelegramBot.pm-Modul: https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm

* Forum-Thread in dem das Modul vorgestellt wurde {{Link2Forum|Topic=38328|LinkText=FHEM-Forum}}
* Telegram messaging system https://telegram.org/
* TelegramBot API https://core.telegram.org/bots/api

<references />
[[Kategorie:Telegram]]

MSwitch

2020-10-04T18:40:35Z

Maista: Aktuelle Modulversion 4.1

{{Hinweis|Das Modul wurde vom Modulautor aus dem FHEM-SVN entfernt. Download des Moduls unter https://github.com/Byte009/Fhem-MSwitch. Support erfolgt laut github-Seite derzeit über Whatsapp.}}

Achtung: Das Wiki entspricht nicht mehr der aktuellen Modulversion ( V4.1 )

Hilfe zu allen Befehlen , Einstellungen etc. ist direkt über das Frontend eines MSwitch-Devices verfügbar.

Eine Aktualisierung des Wikis erfolgt in den kommenden Tagen.

[[MSwitch]] ist ein Hilfsmodul, welches das Event- und/oder zeitgesteuerte Schalten von mehreren Devices oder das Ausführen von benutzerdefinierten Befehlssequenzen erlaubt. Hauptmerkmale sind die fast vollständige und die sehr umfangreiche Konfigurierbarkeit über das Webinterface.

{{Infobox Modul
|ModPurpose=MSwitch
|ModType=x
|ModForumArea=Automatisierung
|ModTechName=98_MSwitch.pm
|ModOwner=Byte09 (aus dem Forum abgemeldet)}}

{{Randnotiz | RNTyp=y | RNText=Byte09: ''Die Grundidee zu MSwitch kam mir, weil ich bei der Arbeit mit FHEM für meinen Geschmack zu viele Module für die verschiedenen Aufgaben brauchte - zu allem Überfluss alle mit unterschiedlicher Syntax. Zwar ist DOIF hiervon ausgenommen (da hiermit wohl auch fast jede Aufgabe lösbar ist), aber ich konnte mich leider nicht daran gewöhnen und somit wurde jedes DOIF für mich zu einem echten Projekt. Was ich wollte war ein Modul, mit dem ich alles erledigen kann. Daher entschloss ich mich schon nach fast einem knappen Jahr FHEM-Nutzung mein eigenes Modul zu schreiben, welches diese Anforderung erfüllt. MSwitch beinhaltet die Funktionalität aller bisherigen Hilfsmodule wie z.B. Notify, Doif, Watchdog, Dummy,( ab Modulversion 2.2 auch Sequenz ) es lassen sich all deren Funktionen umsetzen.''

''MSwitch wird permanent - vorrangig nach meinen Bedürfnissen - weiterentwickelt, gerne nehme ich aber auch Anregungen von anderen Nutzern auf.''

[[Datei:1-2-3-4.png|rahmenlos]]
}}

== Grundsätzliche Überlegungen ==
{{Randnotiz | RNTyp=y | RNText=Will man mehrere Geräte als gleichzeitige Auslöser betreiben, so muss das Device GLOBAL gewählt und die entsprechenden Geräte angegeben werden (dies erzeugt höhere Systemlast und ist nur im Expert-Modus verfügbar).}}

1. Welches Gerät soll auslösen oder zu welcher Zeit soll eine Auslösung erfolgen?
[[Datei:MSwitch basic.svg|mini|240px|Stark vereinfachtes Struktogramm]]
Im Rahmen 1 des Webinterfaces lässt sich der Trigger (Auslöser) bzw. eine Zeitabhängigkeit konfigurieren:

** jedes Event aus dem Eventmonitor,
** triggerunabhängige Zeiten,
** triggerunabhängige Zufallszeiten,
** triggerunabhängige Intervalle,
** Kombinationen aus Triggern und Zeiten.

2. Welche Bedingungen sollen bei Auslösung erfüllt sein?
: Ersten Rahmen: Wenn diese Bedingungen erfüllt sind, werden Kommandos ausgelöst. Die Bedingungen werden im zweiten Teil des Webinterfaces eingegeben. Dabei unterscheidet das Modul zwischen zwei Kommando-Kanälen (cmd1 und cmd2) und den dazugehörigen Geräten.

3. Welche Kommandos sollen ausgelöst werden?
: Im vierten Rahmen des Webinterfaces werden dann die konkreten Kommandos eingegeben. Man wählt dabei aus einer Liste wie auf der Geräteseite Kommandos aus. FreeCmd erlaubt geräteunabhängige Kommandos, beispielsweise reinen Perl-Code.

4. Welche weiteren Bedingungen sollen noch gelten?
: Zusätzlich pro Gerät eine oder mehrere Instanzen des vierten Rahmens:
** ereignisgesteuerte Bedingungen,
** zeitgesteuerte Bedingungen,
** Verzögerungen,
** Wiederholungen etc.

==Definition und Einrichtung =={{Randnotiz | RNTyp=y | RNText=Alle relevante Einstellungen werden in Readings und/oder Hashes gespeichert. Daher stehen relevanten Daten ''nicht'' in der fhem.cfg! Vielmehr finden sich diese Daten in der Datei fhem.save. Die Speicherung erfolgt durch den Befehl Fhemsave.
}}
Das MSwitch-Modul ist ohne weitere Voraussetzungen nutzbar und wird in der aktuellen Version über FHEM Update verteilt. MSwitch kann mehrere Devices gleichzeitig schalten. Diese Schaltungen befinden sich in den zwei möglichen Zweigen entsprechend der Kommandos cmd1 und cmd2. Die einzelnen Devices jedes Zweiges können mit weiteren Schaltbedingungen versehen werden (zeit- oder ereignisgesteuert). Das define eines MSwitch Devices generiert lediglich eine 'leere Hülle':
:<code>define <name> MSwitch</code>
Es wird ein leeres Device angelegt, das dann komplett über das Webinterface konfigurierbar ist.

== Webinterface ==
MSwitch wird über das Webinterface eingerichtet. Es besteht aus vier Teilen. Änderungen in einem Abschnitt müssen auch dort gespeichert werden, bevor ein weiterer Teil bearbeitet wird, sonst gehen Änderungen verloren.{{Randnotiz | RNTyp=y | RNText=<code>attr <name> MSwitch_Help 1</code> führt dazu, dass im Modul selber eine sehr umfangreiche kontextsensitive Hilfe in Form von Fragezeichensymbolen angezeigt wird.}}

[[Datei:1-2-3-4.png|rahmenlos|Webinterface]]
=== Rahmen 1: Trigger Device und Trigger Time ===
==== Trigger Device ====
{{Randnotiz | RNTyp=y | RNText=Wenn das Attribut 'MSwitch_Expert' gesetzt ist kann man 'GLOBAL' auswählen. Dann werden '''alle''' von FHEM generierten Events durch das MSwitch Device weiterverarbeitet, eine weitere Begrenzung kann (und sollte) dann in einem folgenden Eingabefeld erfolgen, um die Systemlast zu reduzieren.
==== Trigger Device Global Whitelist ====
Damit kann die Liste eingehender Events weiter eingeschränkt werden. Sobald mindestens ein Eintrag vorhanden sind, werden nur noch Events der hier benannten Devices verarbeitet. Zulässig ind Devicenamen und DeviceTypen (z.B. TYPE=FS20). Mehrere Angaben sind durch Komma zu trennen.

Im unten gezeigten Beispiel wurde GLOBAL gewählt, weil nicht ein einzelnes Device, sondern eine Kombination aus zwei Geräten auslösen soll. Es werden alle Ereignisse betrachtet, wobei die Whitelist dann auf die Devices Schlafzimmer (ein Temperaturmessgerät) und Schlafzimmerfenster (ein [[HM-Sec-SCo Tür-Fensterkontakt, optisch|optischer Kontakt]]) einschränkt.}}In diesem Feld wird das Device per Dropdownfeld gewählt, dessen Events eine Aktion auslösen sollen.

[[Datei:MSwitchWebinterface1.png|400px|thumb|right|Webinterface, oben]]

==== Trigger Time ====
Trigger time bietet die Möglichkeit einer zeitabhängigen Steuerung. Dazu wird in die "at"-Zeile ein Termin in der Form [STUNDEN:MINUTEN|TAGE] eingetragen. Die Tage werden ab Montag von 1-7 gezählt. Mehrere Zeitvorgaben können direkt hintereinander geschrieben werden. Beispiele:
* <code>[17:00|1][18:30|23]</code> löst montags um 17 Uhr und dienstags sowie mittwochs um 18:30 Uhr aus.
* <code>[00:10*20:00-21:00]</code> führt den Schaltbefehl von 20 Uhr bis 21 Uhr alle 10 Minuten aus.
* <code>[?20:00-21:00]</code> schaltet zu einem zufälligen Zeitpunkt zwischen 20 und 21 Uhr einmalig.
* <code>[20:00|$we]</code> nur am Wochenende um 20:00 wird geschaltet.

==== Trigger Conditions ====

Optionale zusätzliche Bedingungen in diesem Feld gelten nur für auslösende Device Trigger. Trigger Times haben keinen Einfluss, es sei denn, das Attribut MSwitch_Condition_Time ist gesetzt. Man kann mit AND / OR verknüpfte Bedingungen für die Auslösung in an DOIF angelehnter Syntax angeben. Leere Felder werden ignoriert. Werden Readings mit Strings wie 'on' oder 'off' abgefragt, ist statt des Gleichheitszeichens "=" der Operator "eq" zu nutzen, der String muss in Anführungszeichen "" gesetzt werden. Beispiele:{{Randnotiz | RNTyp=y | RNText=Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (beispielsweise würde dann am Mittwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde).}}
* <code>[19:10-23:00] AND [Devicename:Reading] = 10</code> beide Bedingungen müssen erfüllt sein.
* <code>[19:10-23:00] OR [Devicename:Reading] eq "on"</code> eine der Bedingungen muss erfüllt sein.
* <code>[10:00-11:00|13]</code> schaltet Montag und Mittwoch zwischen 10 Uhr und 11 Uhr.
* <code>[{ sunset() }-23:00]</code> von Sonnenuntergang bis 23:00 Uhr.
* <code>{ !$we }</code> löst den Schaltvorgang nur Werktagen an aus.
* <code>{ $we }</code> löst den Schaltvorgang nur an Wochenenden, Feiertagen aus.
Es ist auf korrekte Eingabe der Leerzeichen zu achten.

=== Rahmen 2: Trigger Details ===
[[Datei:MSwitchWebinterface2.png|600px|thumb|right|Webinterface, Mitte]]
Der Inhalt des zweiten Rahmens wird mit dem gewählten Trigger aus dem ersten Rahmen initialisiert. Events können zugeordnet werden. Im Beispiel wird cmd1 ausgelöst, wenn das Fenster offen ist. Cmd2 wird bei Temperaturunterschreitung ausgelöst.

==== execute ====
Diese vier Zeilen legen fest, welches ankommende Event welchen Befehlszweig auslösen soll. Die Event-Drop-Down-Liste enthält alle empfangenen Events dieses Devices. Fehlende Events können manuell hinzugefügt werden.

* switch <MSwitch> on + execute 'cmd1' - MSwitch Statusänderung auf 'on'; cmd1 soll ausgeführt werden
* switch <MSwitch> off + execute 'cmd2' - MSwitch Statusänderung auf 'off'; cmd2 soll ausgeführt werden;
* execute 'cmd1' only - keine Statusänderung; cmd1 soll ausgeführt werden
* execute 'cmd2' only - keine Statusänderung; cmd2 soll ausgeführt werden

==== Save incomming events ====
Alle ankommenden Events der konfigurierten Geräte werden für die Dropdownlisten gespeichert. Nach erfolgreicher Konfiguration sollte diese Option entfernt werden, um die Datenmenge zu reduzieren. Falls das Device Events während der Konfiguration nicht liefert, können sie manuell als kommagetrennte Liste hinzugefügt werden.

==== add event ====
{{Randnotiz | RNTyp=y | RNText=Falls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden:
- * - alle auftretende Events des entsprechenden Device
- device:reading:wert (z.B. device:state:on ) - nur für das Event "device:state:on"
- device:reading:* (z.B. device:state:* ) - Events "device:state:(on,off,etc.)
- device:reading:(wert1/wert2/wert3) (z.b. device:state:(left/right) - Events "device:state:left" oder "devicestate:right" etc.

Das Device kann auch hier gegen "*" ersetzt werden (*:state:on). In diesem Fall erfolgt eine Aktion auf alle Events die z.B. "state:on" enthalten, egal welches Device triggert.
}}
* * - alle auftretende Events des entsprechenden Device
* reading:wert (z.B. state:on ) - nur auf das Event "state:on"
* reading:* (z.B. state:* ) - Events "state:(on,off,etc.)
* reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Events "state:left" oder "state:right" etc.
==== test event ====
Stehen Events zur Auswahl, kann die Konfiguration getestet werden. Durch Klick wird das Event simuliert und die dafür definierte Aktion ausgelöst.

==== apply filter to saved events ====
Beschreibung folgt???

==== clear saved event ====
Es werden die nicht als Trigger wirkenden Events aus der Liste gelöscht.

=== Rahmen 3: Affected devices ===
{{Randnotiz | RNTyp=y | RNText=In dem Auswahlfeld werden alle Devices angeboten, die eines der folgenden Kriterien erfüllen:
# Die Abfrage "set Device ?" liefert einen Befehlssatz
# Das Attribut 'webcmd' des Devices enthält Einträge
# Das Attribut 'MSwitch_Activate_MSwitchcmds' ist aktiviert und das Attribut 'MSwitchcmds' des betreffenden Devices enthält einen Befehlssatz

Einzige Ausnahme ist der erste Listeneintrag 'FreeCMD'. Die Auswahl dieses Eintrages bietet später die Möglichkeit Befehle auszuführen, die nicht an ein Device gebunden sind. Der Code in einem FreeCmd kann entweder reiner FHEM-Code sein ( set device on ) oder reiner Perl-Code. Wenn es sich um reinen Perl-Code handelt, ist dieser in geschweifte Klammen zu setzen { Perl-Code }.

}}
[[Datei:MSwitch_Screen_5.png|mini|rechts|affected devices]]
Auswahl der Devices, die auf die oben konfigurierten Events reagieren sollen. Um unbeabsichtigte Änderungen zu vermeiden ist die direkte Mehrfachauswahl gesperrt.

=== Rahmen 4: Device Actions ===

[[Datei:Webinterface3.png|mini|rechts|device_actions]]
Die auszuführenden Aktionen der im dritten Rahmen gewählten Geräte. Leere Felder werden ignoriert.

==== MSwitch cmd1/cmd2: ====
{{Randnotiz | RNTyp=y | RNText=Im Beispiel befindet sich ein FreeCmd, mit dem beliebige Kommandos eingetragen werden können. Im abgebildeten Beispiel ist dies sogar selbst definierter Perl-Code (die Funktion DebianMail sendet eine Mail).
}}
Man wählt den gewünschten Befehl aus den gespeicherten verfügbaren Möglichkeiten des betreffenden Device aus.

* Im Sonderfall FreeCmd wird der Befehl als String eingegeben.
* Das Attribut MSwitch_Extensions ergänzt die Schaltoption 'MSwitchToggle' in der Liste, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.

{{Randnotiz | RNTyp=y | RNText=Je nach Attribut-Einstellungen werden Einträge aus entsprechenden 'webcmds" oder 'MSwitchcmds' einbezogen. In Abhängigkeit des Befehls stehen unter Umständen weitere Felder oder Widgets zur Verfügung.
).
}}

==== cmd1/cmd2 condition ====

{{Randnotiz | RNTyp=y | RNText=Bei der Abfrage von Readings nach Strings (on, off, etc.) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden. Es ist auf korrekte Eingabe der Leerzeichen zu achten.
'''Achtung:''' Bei Anwendung der geschweiften Klammern zur Einleitung eines Perl Ausdrucks ist unbedingt auf die Leerzeichen hinter und vor der Klammer zu achten.

Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (zum Beispiel würde auch am Mittwoch noch der Schaltvorgang erfolgen, wenn als Tagesvorgabe Dienstag gesetzt wurde).
}}
Die Ausführung der Befehle kann '''pro gewählten Gerät''' analog Rahmen 1 von weiteren Bedingungen abhängig gemacht werden. Es gelten die gleichen Regeln und Beispiele wie im 'Rahmen 1 Trigger Conditions'. Sie können sinngemäß übernommen werden.

Die Variable <code>$EVENT</code> enthält den auslösenden Trigger. Wenn unter 'Rahmen 1 Trigger Conditions' ein Wildcard verwendet wurde, kann nun feingefiltert werden, indem das konkrete Ereignis angegeben wird.

Beispiel: <code>[$EVENT] eq "state:on"</code> würde den Kommandozweig nur dann ausführen, wenn der auslösende Trigger "state:on" war.

==== cmd1/cmd2 delay ====
Ein Eintrag in diesem Feld führt zur verzögerten Ausführung des Befehls nach Eintreffen des Events. Dabei kann der Befehl ohne weitere Prüfung der Bedingung ausgelöst werden. Es ist aber auch möglich, dass die Bedingung bei Ausführung erneut geprüft wird. Die Zeitangabe muss im Format hh:mm:ss vorliegen. Einzelheiten enthält auch das Funktions-Struktogramm.

Statt einer direkten Zeitangabe kann hier auch auf eine verwiesen werden, indem in der Form [NAME.reading] ein Reading eines Devices wie z.B. [dummy.state] angegeben wird.

==== add action ====
Mit diesem Button kann ein weiterer Rahmen 4 als Rahmen 4.1 für das gleiche Device angelegt werden, um z.B. einen weiteren Befehl gegebenenfalls zeitverzögert auszuführen.

==== delete this action ====
Mit diesem Button wird der gewählte Rahmen 4 für das Device gelöscht.

==== check condition ====
[[Datei:MSwitch_Screen_7.png|mini|rechts|check]]
Die angegebenen 'conditions' werden in Zusammenhang mit ggf. ausgewählten Devices auf Syntax und Ergebnis geprüft. Es erfolgt eine Ausgabe des Prüfungsergebnisses.

==== Repeat und Repeatdelay ====

Die Felder 'Repeats', 'Repeatdelay in s' und 'priority' stehen zur Verfügung, wenn das Attribut MSwitch_Expert gesetzt wurde. Diese bewirken eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung. Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.

== Erweiterte Konfiguration ==

=== Set-Befehle ===

{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|set active||Setzt das MSwitch-Device in den Status 'active'.
|-
|set inactive||Setzt das Device in den Status 'inactive'. Es werden keine Befehle mehr ausgeführt. Dieser Status entspricht dem Attribut 'disable', ist aber nicht mit dem roten Fragezeichen (fhem save) verbunden.
|-
|set on<nowiki>|</nowiki>off [<parameter>]||Setzt das Device in den Status 'on' oder 'off'. Alle Befehle der 'on/off-Zweige' werden ausgeführt. Optional kann den Befehlen 'on' und 'off' ein weiterer Parameter mit übergeben werden. Dieser wird im Reading 'Parameter' hinterlegt und es kann sofort in 'Freecmds' oder 'Conditions' darauf zugegriffen werden.
|-
|set reload_timer||Alle gesetzten Timer werden gelöscht und neu berechnet.
|-
|set change_renamed <oldname> <newname>||Sollten sich Devicenammen im ausführenden Teil geändert habe (affected Devices, Conditions, etc.) so kann das MSwitch mit diesem Befehl angepasst werden, ohne alle Einstellungen neu einstellen zu müssen.
|-
|set exec_cmd1 <nowiki>|</nowiki> set exec_cmd1 ID [<ID>]||Bewirkt das sofortige Ausführen des entsprechenden Befehlszweiges. Bei Angabe einer ID werden nur die Befehle mit der entsprechenden ID ausgeführt.
|-
|set MSwitch_backup||Erstellt eine Backup-Datei aller MSwitch Devices unter ./fhem/MSwitch_backup.cfg. Daten dieser Datei können im Bedarfsfall für einzelne oder gleichzeitig alle MSwitch Devices wieder zurückgespielt (hergestellt) werden.
|-
|set del_delays <nowiki>|</nowiki> set exec_cmd1 ID [<ID>]||Löscht alle anstehenden, verzögerten Befehle (delays).
|-
|set reset_cmd_count: 1<nowiki>|</nowiki>2||Löscht das entsprechende EVT_CMD_COUNT - Reading; entspricht damit einer Rückstellung auf '0'.
|-
|set fakeevent [<device>]:<reading>:<arg>||Beispiel: <device> fakeevent state:on 
Das MSwitch Device reagiert so, als wäre statt des internen "fakes-Befehls" ohne FHEM-Systembeeinflussung dieses Event tatsächlich vom triggernden Gerät generiert worden.

Der Name (<device>) muss bei GLOBALEN Triggern mit angegeben werden, sonst wird das Device automatisch gesetzt.
Um z.B. einen Watchdog zu realisieren ist es eventuell nötig, dass sich das MSwitch Device mit einem bestimmten Event selber neu triggert - ggf. mit einem entsprechenden Delay Affected Device. Bei dem Einsatz dieser Möglichkeit sollte das Attribut 'MSwitch_Safemode' UNBEDINGT aktiviert sein, da 'Experimente' hier schnell in einer Endlosschleife enden können, die nur durch ein Reboot unterbrochen werden kann. Möglicherweise steht dieser Befehl zukünftig nur noch zur Verfügung, wenn Safemode aktiviert ist.
|}

=== Get-Befehle ===

{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|get show_timer [<show><delete>]||
;Show
:Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
;Delete
:Löscht alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren. Schaltbefehle basierend auf rein zeitabhängigen Angaben werden neu berechnet und gesetzt.
|-
|get restore_MSwitch_data [<this_device><nowiki>|</nowiki><all_devices>]||
;this_device
:Stellt die Daten des Devices aus der Backupdatei wieder her, sofern diese in der Backupdatei gefunden werden (gesucht wird hier nach dem Namen des Devices).
;all_devices
:Stellt die Daten aller MSwitch Devices wieder her, sofern diese in der Backupdatei vorhanden sind. Diese Aktion kann einige Zeit in Anspruch nehmen und wird daher im Hintergrund (nonblocking) ausgeführt. Nach Beendigung erfolgt eine Benachrichtigung.
Die Devices sind nach einem Restore funktionsfähig. Empfohlen wird ein Neustart von FHEM..
|-
|get_config||Zeigt die Konfigurationsdatei des MSwitchdevices an; diese kann in dem Fenster editiert werden. Das sollte nur von erfahrenen Usern getan werden! Im Normalfall sollte das Device nur über die Weboberfläche konfiguriert werden und eine falsche Konfiguration kann hier zu einem FHEM Absturz führen.
|-
|get_support_info||Öffnet ein Fenster mit einer formatierten Ansicht aller Einstellungen des Devices. Bei Supportanfragen sollte dieses immer mit geposted werden.
|-
|get_MSwitch_preconf||Lädt vorkonfigurierte MSwitch-Devices. Diese Option ist nur dann vorhanden, wenn das Aktualisieren dieser vorkonfigurierten Devices im FHEM Update aktiviert ist.
Diese kann durch ein einmaliges Update erfolgen mit:
:<code>update all https://raw.githubusercontent.com/Byte009/MSwitch_Addons/master/controls_mswitchaddons.txt</code>
|}

=== Attribute ===
{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|MSwitch_Debug <0<nowiki>|</nowiki>1<nowiki>|</nowiki>2<nowiki>|</nowiki>3<nowiki>|</nowiki>4>||
0 - Abgeschaltet 
1 - Schaltet Felder zum testen der Conditionstrings an 
2 - Alle ausgehenden Befehle werden nur simuliert und nicht ausgeführt. Der Inhalt der Protokolldatei wird direkt im Device angezeigt 
3 - Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt. 
4 - erweitertes Debugfür Entwickler mit wechselnden Funktionen 
|-
|MSwitch_Expert <0<nowiki>|</nowiki>1>||
* In der Liste der möglichen Trigger erscheint das Selectfeld 'GLOBAL'. Dieses ermöglicht das Setzen eines Triggers auf alle Events und damit nicht nur auf einzelne Devices. In einem weiteren Feld kann eine weitere Selektion der triggernden Events erfolgen.

* Die Felder 'Repeats' und 'Repeatdelay in s' stehen zur Verfügung. Dies bewirkt eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung.

* Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.
|-
|MSwitch_Sequenz <Suchmuster> ??? ||
Eine Schaltsequenz kann durch ein oder mehrere durch '/' getrennte Suchmuster angegeben werden. Die Angabe muss folgende Syntax haben:
:<code>Device1:reading1:event1 Device1:reading1:event1-2 Device1:reading1:event1-3/..../....</code>

Beispiel: <code>Dummy:state:on Dummy:state:off Dummy:state:on</code>

Erkennt das Device dieses Suchmuster in den Schaltvorgängen des Devices (Dummy), wird das Reading "SEQUENCE" auf "match" gesetzt, das Reading "SEQUENCE_NUMBER" auf die Nummer der gefundenen Sequenz, wenn es mehrere Suchmuster gibt. Beide Readings können in den "Conditions" eines Schaltbefehles abgefragt werden. Eine Angabe muss in folgendem Format gemacht werden:
:<code>on/off/state/suchmuster1/suchmuster2</code>, wobei die letzten drei Angaben optional sind.

Funktion: Bei Ausführung des Befehls wird das Gerät 'on' oder 'off' geschaltet (on/off), Voraussetzung ist, dass der 'state' dieses Gerätes auch den 'state on' oder 'off' annimmt. Sollte dieses nicht der Fall sein, so kann mit dem Feld 'state' angegeben werden, in welchem Reading der aktuelle Status vorkommt und wie dieser lautet (suchmuster1/suchmuster2). Dieses 'state' kann mehrere Angaben enthalten, das Vorkommen der Suchmuster ist aber Voraussetzung.
|-
|MSwitch_Sequence_time <Zeit in Sekunden>||Maximalzeit in Sekunden, um eine Sequenz vollständig auszuführen. (Was wenn diese Zeit überschritten wird???)
|-
|MSwitch_Extensions <0<nowiki>|</nowiki>1>||Es wird zusätzlich zu 'on' und 'off' die Schaltoption 'MSwitchToggle' in der Liste angeboten, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.
|-
|MSwitch_Delete_Delays <0<nowiki>|</nowiki>1>||Eins bewirkt das Löschen aller anstehende Delays bei dem Auftreten eines erneuten passenden Events. Bei der Option '0' bleiben bereits gesetzte Delays aus einem vorher getriggerten Event erhalten und werden ausgeführt. Empfohlene Einstellung: 1
|-
|MSwitch_Include_Devicecmds <0<nowiki>|</nowiki>1>||Bewirkt die Aufnahme aller Devices die bei Abfrage mit 'set DEVICE ?' einen eigenen Befehlssatz liefern in die Auswahlliste 'Affected Devices'. Bei Option '0' werden diese Devices in der Liste nicht mehr angeboten. Empfohlene Einstellung: 1
|-
|MSwitch_Include_Webcmds <0<nowiki>|</nowiki>1>||Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut Webcmd hinterlegt haben. Die in Webcmd hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, es sei denn, sie liefern mit 'set DEVICE ?' einen eigenen Befehlssatz. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
|-
|MSwitch_Activate_MSwitchcmds <0<nowiki>|</nowiki>1>||Fügt jedem vorhandenen Device das Attribut 'MSwitchcmd' hinzu.
|-
|MSwitch_Include_MSwitchcmds <0<nowiki>|</nowiki>1> ||Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut MSwitchcmds hinterlegt haben. Die in MSwitchcmds hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz mit 'set DEVICE ?' liefern. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
|-
|MSwitch_Lock_Quickedit <0<nowiki>|</nowiki>1>||Voreinstellung für die Auswahlliste 'Affected Devices'. Bei der Option '1' ist diese voreingestellt gesperrt und kann nur über einen zusätzlichen Button geändert werden, um versehentliche Änderungen zu vermeiden. Die Auswahl einer Option ohne betätigte <Strg>-Taste bewirkt das Löschen aller bereits gesetzten Optionen. Empfohlene Einstellung: 1
|-
|MSwitch_Startdelay <0<nowiki>|</nowiki>10<nowiki>|</nowiki>20<nowiki>|</nowiki>30<nowiki>|</nowiki>60> ||MSwitch ignoriert nach einem FHEM-Neustart für die angegebene Zeit in Sekunden alle eingehenden Events um u.a. Startverzögerungen zu vermeiden. Bei nicht gesetztem Attribut gilt hier eine Zeit von 30 Sekunden. Diese sollte auch nur in Ausnahmefällen geändert werden. Empfohlene Einstellung: 30
|-
|MSwitch_Ignore_Types||Beinhaltet eine durch Leerzeichen getrennte Liste von Device-''Typen'' welche nicht geschaltet werden oder nicht geschaltet werden können. Sie werden dann in den Auswahllisten ''nicht'' dargestellt, um die Auswahllisten übersichtlich zu halten.Voreinstellung: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul.

???Wenn statt des Devicetyps ein devspec z.B. "TYPE=watchdog" angegeben wird, ist zu beachten, dass alle Geräte in die Ignoreliste einbezogen werden, die NICHT der devspec entsprechen. Weiterhin muss die devspec in Anführungszeichen gesetzt werden!???

|-
|MSwitch_Trigger_Filter ||Beinhaltet eine kommagetrennte Liste von Events, die im Falle ihres Eingangs unberücksichtigt und ungespeichert bleiben. Wildcards wie '*' können angegeben werden. Empfohlene Einstellung: -
|-
|MSwitch_Wait <n in Sekunden>||Bei gesetztem Attribut nimmt das MSwitch Device für den eingestellten Zeitraum keine Befehle mehr entgegen und ignoriert eingehende Events.

|-
|MSwitch_Event_Id_Distributor|| ??? Voraussetzung ist, dass das Attribut 'MSwitchExpert' auf '1' gesetzt ist. Es können auslösende Events ID-Aktionen umgeleitet werden. Sollte bei den 'trigger details :' in einem Zweig ( cmd1 ) z.B. mehrere getriggert werden (regex state:(on |off)) so werden für beide Events jeweils der Zweig 'cmd1' - alle Aktionen ohne ID - ausgeführt. Durch entsprechende Einträge kann für entsprechende Events auf eine Aktion umgeleitet werden, für die eine ID definiert ist. Die Syntax lautet: <code>state:on=>cmd1 ID 1,2</code> Entsprechend werden bei auslösendem Event 'state:on' nur die Aktionen aus cmd1 mit den IDs 1 und 2 ausgeführt. Mehrere Angaben sind durch new Line zu trennen. ???

|-
|MSwitch_Selftrigger_always <0<nowiki>|</nowiki>1> ||(dieses Attribut steht ab Modulversion 2.5 zur Verfügung)

Die Aktivierung dieses Attributes '1' bewirkt, dass alle SET Aktionen des Devices einen internen Event ohne Auswirkungen auf das FHEM-System auslösen, auf die das Device selber reagiert. Diese Option kann zusätzlich zu einem vorhandenen Trigger aktiviert werden. Auftretende auswertbare interne Events haben immer folgendes Format:
MSwitch_Self:aktion:wert
MSwitch_Self:pct:100
Es werden nur interne Events für set-Aktionen ausgelöst, die im Attribut setlist hinterlegt sind. Der 'wait' Befehl/Attribut hat keine wirkung.
|-
|MSwitch_Mode <Notify<nowiki>|</nowiki>Full<nowiki>|</nowiki>Toggle<nowiki>|</nowiki>Dummy> ||Schaltet das Modul zwischen angepassten Weboberflächen-Modi um.

Notify
Das Device kann nicht manuell umgeschaltet werden. Es gibt nur die zwei ausführbaren Zweige "execute 'cmd1' commands" und "execute 'cmd2' commands". Der Status des Devices wird nicht als 'on' oder 'off' angezeigt, sondern lediglich als 'active' Dieser Mode ist ähnlich zu einem FHEM-Notify.

Full
Es stehen alle Funktionen zur Verfügung.
Toggle
Sehr vereinfachter Mode. Es stehen keine verschiedenen Zweige zur Verfügung. Hier ist das Device manuell schaltbar und wird bei jedem definierten Event 'umgeschaltet', ??? entsprechend definierte Befehle für 'cmd1' oder 'cmd2' werden ausgeführt. ???
Dummy
ACHTUNG: Funktionsänderung mit V2.61 Der Mode 'Dummy' ist ein eingeschränkter Modus. Dieser bietet die Funktionalität eines Dummys kombiniert mit der Funktionalität eines Notifys und kann somit die gerne genutzte Kombination Dummy-Notify gegen ein Device ersetzen. Der Dummy-Mode kann nur in einem neu angelegten leeren MSwitch aktiviert und auch nicht wieder verlassen werden! Sobald ein angelegtes MSwitch einmal verändert wurde (modify trigger etc.) sind Umschalt-Optionen nicht mehr verfügbar.

|-
|MSwitch_Condition_Time <0<nowiki>|</nowiki>1> ||In der Grundeinstellung '0' werden für das zeitgesteuerte Schalten keine definierten Conditionen im Feld 'Trigger condition' überprüft, sondern die Schaltbefehle werden in jedem Fall ausgeführt. Mit der Einstellung '1' wird diese Überprüfung wie für Events zugeschaltet.

|-
|MSwitch_Random_Time <HH:MM:SS-HH:MM:SS> || Bei Aktivierung wird vor jedem Ausführen eines verzögerten Befehls (Delay) eine Zufallszeit generiert, die im Rahmen der hier angegebenen Zeitspanne liegt. Auf diese Zufallszahl kann in den Delays zugegriffen werden, durch die Angabe '[random]' statt einer direkten Zeitangabe. Bei nicht gesetztem Attribut ergibt die Angabe von '[random]' immer '00:00:00'

|-
|MMSwitch_Random_Number <n> ||Bei Aktivierung dieses Attributes mit einer beliebigen ganzen Zahl, werden vom Device die zwei Readings 'RandomNr' und 'RandomNr1' und mit Werten zwischen null und n angelegt. RandomNr wird vor jedem Ausführen eines Befehls, auch für unterschiedliche Geräte in einem Durchgang, neu generiert. RandomNr1 bleibt nach der Initialisierung konstant. Wenn auf dieses Readings in einer Condition mit z.B. '[$NAME:ReadingNr1] = 1' zugegriffen wird, wird der Befehl nur ausgeführt, wenn ReadingNr1 gerade = 1 ist. Der Befehl wird somit nur mit einer Wahrscheinlichkeit von eins zu n ausgeführt.

|-
|MSwitch_Reset_EVT_CMD1(2)_COUNT ||Bei Aktivierung dieses Attributes steht in den Readings das Reading 'EVT_CMD1_COUNT' bzw. 'EVT_CMD2_COUNT' zur Verfügung. Dieses kann in den Conditions genutzt werden, um z.B. nur bei jedem x-ten Eintreffen eines auslösenden Events einen Befehl auszuführen. Bei jedem Eintreffen eines gültigen Events werden die Zähler um 1 erhöht (für den jeweiligen Zweig). Ist hier der Wert '0' eingetragen, wird der Zähler fortlaufend (endlos) erhöht. Wird ein Wert größer 0 eingetragen, wird der Zähler mit Erreichen dieses Wertes automatisch wieder auf Null gesetzt. Mit Löschen dieses Attributes werden die entsprechenden Readings ebenfalls gelöscht.

|-
|MSwitch_Safemode <0<nowiki>|</nowiki>1> ||Bietet einen gewissen Schutz vor falschen Konfigurationen und dadurch entstehenden Endlosschleifen. Bei aktiviertem Attribut '1' beendet das Modul Endlosschleifen eines Devices. In diesem Fall erfolgt ein Logeintrag und das Device wird per Attribut auf 'Disabled' gesetzt. Es wird ein letztes Event generiert, auf das reagiert werden kann <code>2018-05-31 09:39:21 MSwitch <NAME> Safemode: on</code> Im Webinterface erfolgt bei betroffenem Device ein entsprechender Hinweis. In der Grundkonfiguration ist dieses Attribut nicht gesetzt. Es empfiehlt sich aber, bei neuen bzw. komplizierten Devices, dieses zumindest anfänglich zu aktivieren.
|-
|MSwitch_Read_Log<0<nowiki>|</nowiki>1> ||Ermöglicht den Zugriff auf das Logfile als Trigger.

* Bei aktiviertem Attribut enthält die Auswahl des Triggerdevices die Option 'LOGFILE'. Bei dieser Auswahl werde alle Logeinträge erkannt und in ein internes Event umgewandelt, auf das regiert werden kann.
* bei aktiviertem Attribut und der Auswahl 'GLOBAL' im 'Trigger_Device' wird auf ALLE Events und alle Logeinträge reagiert.
* bei aktiviertem Attribut und der Auswahl eines bestimmten Devices im 'Trigger_Device' wird auf alle Events und auf alle Logeinträge des gewählten Devices reagiert. Der im Logeintrag vorhandene Devicename ist Bedingung für die Funktion.
|-
|MSwitch_Help<0<nowiki>|</nowiki>1> ||Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.

|-
|MSwitch_Comments<0<nowiki>|</nowiki>1> ||Schaltet Kommentarfelder zu den einzelnen 'affected_devices an.

|-
|MSwitch_generate_Events<0<nowiki>|</nowiki>1> ||Reduziert bei Einstellung '1' die vom MSwitch-Devices erzeugten Events auf ein Minimum. Insbesondere bei Verwendung von 'MSwitch_Read_Log' zu empfehlen.

|-
|MSwitch_Startdelay||???Bestimmt die Verzögerungszeit des MSwitches nach FHEM-Start in Sekunden. In diesem Zeitraum reagiert das Device nicht auf Events. Die Vorgabe ist hier zehn Sekunden. Diese wird auch dann angenommen, wenn das Attribut nicht gesetzt ist.??? (Hatten wir das nicht schon?)

|-
|MSwitch_Inforoom ||Mit diesem Attribut wird die Raumansicht eines mit dem Attribut bestimmten Raumes verändert. Dadurch sollen die wichtigsten Informationen aller MSwitch-Devices auf eine Seite dargestellt werden. Zur Nutzung sollten alle MSwitch-Devices (zusätzlich) in einen Raum sortiert werden und dieser Raum im Attribut eingestellt werden.

Wichtig: Eine Änderung dieses Attributes bewirkt immer eine Änderung dieses Attributes in ''allen'' MSwitch devices: Es muss nur in einem Device gesetzt oder gelöscht werden um alle Devices zu erfassen.

<gallery>
MSwitch_Screen_1.png|Raumansicht des Raumes MSwitch mit gesetztem Attribut 'MSwitch'
MSwitch_Screen_2.png|Raumansicht des Raumes MSwitch ohne gesetztes Attribut
</gallery>

Es werden folgende Informationen bereitgestellt:
* Infobutton zeigt den im Device gespeicherten Textes des Attributes 'comment'
* Device und Events, die das Device triggern
* Zeiten, zu denen verschiedene Zweige des Devices ausgeführt werden
* Devices, die durch das MSwitch Device geschaltet werden
* State des Devices

|}

== Integrierte Funktionen ==

{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|Average||???
|-

|Difference||
* Syntax: [DIFF<wert>:<reading>] > <differenz>
* Beispiel: [DIFF2:countdown] > 0
* Reading: entspricht dem getriggerten Reading.
* Wert: gespeicherter Wert (in diesem Fall der vorletzte).
* Differenz: geforderte Differenz zwischen aktuellem und vorletztem Wert.
* Schaltung erfolg wenn diese Bedingung 'wahr' ist.
Folgende Readings werden zur Verfügung gestellt:
* DIFFERENCE (true/false) - Schaltbedingung erkannt ja/nein
* DIFFDIRECTION (up/down) - Richtung der erkannten Bedingung (steigend/fallend)
|-
|Increase||???
|-
|Tendency||
*Syntax: [TEND<wert>:<reading>] > <Mindestwert>
*Beispiel: [TEND2:countdown] > 2
*Reading: entspricht dem getriggerten Reading.
*Wert: Es wird jeweils der Durchschnitt von 2 Wertepaaren gebildet. In diesem Fall werden die letzten 4 Werte herangezogen. Paar 1 = Aktueller und letzter Wert, Paar 2 = Die 2 vorherigen Werte. Bei TEND3 werden die letzten 6 Werte zur Paarbildung genutzt.
*Mindestwert: Der Wertunterschied zwischen den Wertepaaren, der minimal erreicht sein muss, um eine Tendenz zu erkennen.

Rechenzeichen (><):
Dieses ist hier nicht als Rechenzeichen zu werten, sonder als Tendenz-Anzeige. ( < es wird nach fallender Tendenz gesucht / > sucht nach steigender Tendenz).

Schaltung erfolgt einmalig bei Erkennung der gesuchten Tendenz.
Danach erfolgt keine Schaltung mehr, solange bis eine Tendenz-Umkehr erfolgt ist.
Erst dann erfolgt wieder eine Schaltung bei erneuter Tendenz-Umkehr in gesuchte Richtung.
|}

== Funktions-Struktogramm ==
[[Datei:MSwitch full.svg|Struktogramm des Funktionsprinzips]]

== Anwendungs-Beispiele ==

=== [[Blinken - Rechteckgenerator]] ===
=== [[Blinken - Impulsgenerator mit variablem Tastgrad]] ===
=== [[Schmitt-Trigger - Temperaturabhängiges Schalten]] ===
=== [[Linearschalter]] ===

== Links ==
* Thread über das Modul im {{Link2Forum|Topic=86199|LinkText=FHEM Forum}}
* {{Link2Forum|Topic=100119|Message=936495|LinkText=Gäste-WLAN der Fritzbox auswerten und Login per Telegram senden}}
* {{Link2Forum|Topic=86199|Message=930133|LinkText=Schalten von vier Kanälen mit einem MSwitch-Device}}
* {{Link2Forum|Topic=99219|Message=926652|LinkText=Batterie-Überwachung. 1xTäglich per Telegram senden}}
* {{Link2Forum|Topic=101091|Message=945389|LinkText=Licht (Alarm) in einem bestimmten Zeitraum schalten}}
* {{Link2Forum|Topic=100949|Message=944284|LinkText=Über Dummy-Schalter ein Timer (EIN/AUS) aktivieren}}
* {{Link2Forum|Topic=103083|Message=967710|LinkText=Ladezeit von Akku ermitteln u. Steckdose entsprechend schalten}}
* {{Link2Forum|Topic=86199|Message=990265|LinkText=Bewegungsmelder}}
* {{Link2Forum|Topic=86199|Message=974592|LinkText=Rauch und Hitzemelder steuern}}

AT um eine Temperaturabhängige Nachtabsenkung zu realisieren

2020-06-07T19:45:45Z

Maista: drei "war" in einem Satz

'''Für die Grundlegende Funktion von [[at]] bitte einen Blick in die {{Link2CmdRef|Anker=at}} werfen.'''

<ins>Zielvorgabe:</ins>

Jeden Tag um 22:30 soll die Temperatur auf 17° abgesenkt werden (hier das FHEM-Gerät "wz_Heizung") wenn die Temperatur vorher über 17° eingestellt war - war die Temperatur vorher niedriger eingestellt, soll nichts passieren.

Der Befehl für die [[Konfiguration]] lautet dazu wie folgt:

Einzeiler:

:<code>define wz_HeizungNachtabsenkung at 22:30:00 {if(ReadingsVal('wz_Heizung', 'desired-temp', 0) > 17.0) {fhem("set wz_Heizung desired-temp 17.0")} }</code>

Mehrzeiler:

<nowiki>define wz_HeizungNachtabsenkung at 22:30:00 {\
if(ReadingsVal('wz_Heizung', 'desired-temp', 0) > 17.0) {\
fhem("set wz_Heizung desired-temp 17.0")\
}\
}</nowiki>
Im Detail:

* ''define wz_HeizungNachtabsenkung'' => lege ein neues Objekt ''wz_HeizungNachtabsenkung'' und ...
* ''at *22:30:00'' => ... prüfe täglich um 22:30 Uhr ...
* ''if(ReadingsVal('wz_Heizung', 'desired-temp', 0) > 17.0'' => ... ob ''(ReadingsVal -> lese Werte)'' ... ''('wz_Heizung', 'desired-temp', 0)''=> ... ob am Gerät ''wz_Heizung''der Wert ''desired-temp''... ''> 17.0''=> ... größer als 17.0 ist, wenn ja dann ...
* ''fhem("set wz_Heizung desired-temp 17.0")'' => ... soll FHEM am Gerät ''wz_Heizung'' den Wert ''desired-temp'' auf 17.0° setzen.

'''Anmerkung zu ReadingsVal:'''
<nowiki>ReadingsVal(<DeviceName>, <ReadingsName>, <Defaultwert>)</nowiki>
Damit wird das entsprechende Reading am entsprechenden Device ausgelesen. Gibt es das Reading nicht, wird Defaultwert zurückgegeben.

Man kann Prozedurergebnisse (wie dieses von ReadingsVal) und Variablen bei Vergleichen natürlich mischen, und muss diese Ergebnisse nicht unbedingt in Variablen zwischenspeichern. Das tut man meistens nur, wenn das Ermitteln viel Zeit in Anspruch nimmt und man diesen mehrfach benötigt, oder der Wert durch Überschreiben verloren geht.

Perl hat als Besonderheit, dass man einer Variablen nicht ansieht, ob sie eine Zahl oder einen String enthält. Das sind alles sogenannte Skalare (im Gegensatz zu Arrays oder Hashlisten). Um bei einem Vergleich aber die durchaus unterschiedlichen Ergebnisse erzwingen zu können, gibt es eben unterschiedliche Operatoren dafür:

<nowiki><, >, <=, >=, ==, != sind numerische Operatoren
lt, gt, le, ge, eq, ne sind die entsprechenden Stringvergleichsoperatoren</nowiki>
Beispiel:

<nowiki>my $var1 = '10';
my $var2 = '2';
# Ergibt true:
if ($var1 > $var2)...
# Ergibt false:
if ($var1 gt $var2)...</nowiki>
Für weitere Beispiele bietet es sich an auch mal einen Blick in die ''fhem.pl ''zu werfen.

[[Kategorie:Code Snippets]]

List

2020-05-23T20:46:20Z

Maista: /* list -r */

{{SEITENTITEL:list}}
{{Infobox Modul
|ModPurpose=Befehl zur Auflistung von Gerätedefinitionen
|ModType=cmd
|ModCmdRef=list
|ModForumArea=Sonstiges
|ModTechName=fhem.pl ("Built-in")
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
Der Befehl [[list]] dient dazu, Informationen über Geräte (Devices) anzuzeigen. Dabei können entweder Details zu einem einzelnen Gerät ausgegeben werden, oder eine Liste von Geräten (Gerätenamen) mit bestimmten gemeinsamen Attributen. Wenn mehrere Geräte aufgelistet werden, lässt sich zu jedem zusätzlich der Wert eines oder mehrerer Internals, Readings oder Attribute mit ausgeben.

Der Befehl kann direkt über das Eingabefeld des [[FHEMWEB|Webfrontends]] oder über die telnet Schnittstelle eingegeben werden.

== Beispiele ==
{{Randnotiz|RNText=Für alle Beispiele gilt: im Webfrontend lassen sich die Namen der ausgegebenen Geräte direkt anklicken, um in die zugehörige Detail-Ansicht zu gelangen. Dies ist besonders für [[weblink]], [[SVG]] oder [[readingsGroup]] Geräte nützlich, die in der Raum-Ansicht eventuell keinen solchen Link auf die Detail-Ansicht zeigen.}}
=== Alle Geräte mit bestimmten Namen mit ihrer Definition ===
Auflistung der Definitionen aller Geräte von FHEM:
:<code><nowiki>list .* DEF</nowiki></code>

Auflistung der Definitionen der Geräte, die mit wz beginnen.
:<code><nowiki>list wz.* DEF</nowiki></code>

=== Alle Geräte eines bestimmten Typs ===
Mit dem Befehl
:<code><nowiki>list TYPE=FS20</nowiki></code>
wird eine Liste (die Namen) aller Geräte des Typs [[FS20]] ausgegeben.

=== Alle Geräte ohne TYPE ===
Manche Fehlersituationen in FHEM werden verursacht durch Geräte, bei denen kein ''Internal'' mit dem Namen ''TYPE'' festgelegt ist (was eigentlich eine ungültige Definition ist). Diese Geräte-Definitionen lassen sich mit dem Befehl
:<code><nowiki>{ join("\n", grep { !defined($defs{$_}{TYPE}) } keys %defs) }</nowiki></code>
identifizieren. Mithilfe dieser Information lässt sich dann z.B. ein solches Gerät [[delete|löschen]].

Ein derartiges Szenario ist unter anderem in diesem {{Link2Forum|Topic=41137|LinkText=Forenthema}} beschrieben.

=== Alle Geräte mit einem bestimmten Attribut ===
Im Zusammenhang mit Verhaltensänderungen eines Attributs (wie z.B. bei [[userReadings]] geschehen), kann es sinnvoll sein, alle Devices aufzulisten, bei denen dieses Attribut verwendet wurde.
;alle Devices, bei denen das Attribut ''userReadings'' (auf einen beliebigen Wert gesetzt) ist:
:<code>list userReadings=[a-zA-Z].*</code> oder <code>list userReadings=.+</code> oder <code>list userReadings=\w.*</code> oder <code>list userReadings=..*</code>

=== Alle Geräte in einem Raum ===
[[Datei:ListRoom.png|mini|right|Ausgabebeispiel eines ''list'' Befehls]]
Mit dem Befehl
:<code><nowiki>list room=TV</nowiki></code>
werden die Namen aller Geräte aufgeführt, die ein Attribut ''room'' mit dem Wert ''TV'' haben. Durch einen Klick auf den Gerätenamen wird die Detailansicht des Gerätes aufgerufen.

=== Attributwert zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM serialNr</code>
werden die Seriennummern aller Homematic Geräte aufgelistet.

=== Mehrere Werte zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM:FILTER=serialNr=..* serialNr model</code>
werden die Seriennummer und die Modellbezeichnung aller Homematic Geräte aufgelistet, die auch eine Seriennummer haben.

=== Gezieltes Auflisten von Internal, Reading oder Attribut ===
Bei manchen Geräten gibt es Internals, Readings oder Attribute mit gleichem Namen. Da ''list'' jeweils nur das erste Vorkommen zeigt und nicht sichtbar macht, was genau gefunden wurde, ist die Ausgabe manchmal nicht eindeutig. Um das zu vermeiden, lässt sich mit dem Präfix i:, r: oder a: vor dem Namen des anzuzeigenden Wertes angeben, welcher der drei möglichen Typen ausgegeben werden soll.

== Erweiterte Optionen ==
Mit den Optionen -r und -R kann eine erweiterte Ausgabe erzielt werden. Diese sollte bei der Erstellung eines Threads im Forum zu allen beteiligten Geräten mit angegeben werden. Die Optionen können auch hilfreich sein, um Teile der [[Konfiguration]] schnell zwischen unterschiedlichen Installationen zu kopieren, z.B. von einem oder in ein Testsystem (siehe auch [[Import von Code Snippets]]).
=== list -r ===
Dabei werden auch die derzeitigen Stände der Readings mit ausgegeben. Für die Angabe des Gerätenamens ist dabei die Verwendung jeder {{Link2CmdRef|Anker=devspec|Label=devspec}} zulässig.

Beispiele:
:<code><nowiki>list -r TV</nowiki></code>
:<code><nowiki>list -r</nowiki></code>

=== list -R ===
Mit dieser Option werden auch die Geräte samt aktueller Zustände mit ausgegeben, die als '''probably associated with'' erkannt worden sind.

Beispiel:
:<code><nowiki>list -R TV</nowiki></code>

== Links ==
* [[Import von Code Snippets|RAW Definition]]

[[Kategorie:FHEM-Verwendung]]

List

2020-05-23T20:43:58Z

Maista: /* list -r */

{{SEITENTITEL:list}}
{{Infobox Modul
|ModPurpose=Befehl zur Auflistung von Gerätedefinitionen
|ModType=cmd
|ModCmdRef=list
|ModForumArea=Sonstiges
|ModTechName=fhem.pl ("Built-in")
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
Der Befehl [[list]] dient dazu, Informationen über Geräte (Devices) anzuzeigen. Dabei können entweder Details zu einem einzelnen Gerät ausgegeben werden, oder eine Liste von Geräten (Gerätenamen) mit bestimmten gemeinsamen Attributen. Wenn mehrere Geräte aufgelistet werden, lässt sich zu jedem zusätzlich der Wert eines oder mehrerer Internals, Readings oder Attribute mit ausgeben.

Der Befehl kann direkt über das Eingabefeld des [[FHEMWEB|Webfrontends]] oder über die telnet Schnittstelle eingegeben werden.

== Beispiele ==
{{Randnotiz|RNText=Für alle Beispiele gilt: im Webfrontend lassen sich die Namen der ausgegebenen Geräte direkt anklicken, um in die zugehörige Detail-Ansicht zu gelangen. Dies ist besonders für [[weblink]], [[SVG]] oder [[readingsGroup]] Geräte nützlich, die in der Raum-Ansicht eventuell keinen solchen Link auf die Detail-Ansicht zeigen.}}
=== Alle Geräte mit bestimmten Namen mit ihrer Definition ===
Auflistung der Definitionen aller Geräte von FHEM:
:<code><nowiki>list .* DEF</nowiki></code>

Auflistung der Definitionen der Geräte, die mit wz beginnen.
:<code><nowiki>list wz.* DEF</nowiki></code>

=== Alle Geräte eines bestimmten Typs ===
Mit dem Befehl
:<code><nowiki>list TYPE=FS20</nowiki></code>
wird eine Liste (die Namen) aller Geräte des Typs [[FS20]] ausgegeben.

=== Alle Geräte ohne TYPE ===
Manche Fehlersituationen in FHEM werden verursacht durch Geräte, bei denen kein ''Internal'' mit dem Namen ''TYPE'' festgelegt ist (was eigentlich eine ungültige Definition ist). Diese Geräte-Definitionen lassen sich mit dem Befehl
:<code><nowiki>{ join("\n", grep { !defined($defs{$_}{TYPE}) } keys %defs) }</nowiki></code>
identifizieren. Mithilfe dieser Information lässt sich dann z.B. ein solches Gerät [[delete|löschen]].

Ein derartiges Szenario ist unter anderem in diesem {{Link2Forum|Topic=41137|LinkText=Forenthema}} beschrieben.

=== Alle Geräte mit einem bestimmten Attribut ===
Im Zusammenhang mit Verhaltensänderungen eines Attributs (wie z.B. bei [[userReadings]] geschehen), kann es sinnvoll sein, alle Devices aufzulisten, bei denen dieses Attribut verwendet wurde.
;alle Devices, bei denen das Attribut ''userReadings'' (auf einen beliebigen Wert gesetzt) ist:
:<code>list userReadings=[a-zA-Z].*</code> oder <code>list userReadings=.+</code> oder <code>list userReadings=\w.*</code> oder <code>list userReadings=..*</code>

=== Alle Geräte in einem Raum ===
[[Datei:ListRoom.png|mini|right|Ausgabebeispiel eines ''list'' Befehls]]
Mit dem Befehl
:<code><nowiki>list room=TV</nowiki></code>
werden die Namen aller Geräte aufgeführt, die ein Attribut ''room'' mit dem Wert ''TV'' haben. Durch einen Klick auf den Gerätenamen wird die Detailansicht des Gerätes aufgerufen.

=== Attributwert zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM serialNr</code>
werden die Seriennummern aller Homematic Geräte aufgelistet.

=== Mehrere Werte zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM:FILTER=serialNr=..* serialNr model</code>
werden die Seriennummer und die Modellbezeichnung aller Homematic Geräte aufgelistet, die auch eine Seriennummer haben.

=== Gezieltes Auflisten von Internal, Reading oder Attribut ===
Bei manchen Geräten gibt es Internals, Readings oder Attribute mit gleichem Namen. Da ''list'' jeweils nur das erste Vorkommen zeigt und nicht sichtbar macht, was genau gefunden wurde, ist die Ausgabe manchmal nicht eindeutig. Um das zu vermeiden, lässt sich mit dem Präfix i:, r: oder a: vor dem Namen des anzuzeigenden Wertes angeben, welcher der drei möglichen Typen ausgegeben werden soll.

== Erweiterte Optionen ==
Mit den Optionen -r und -R kann eine erweiterte Ausgabe erzielt werden. Diese sollte bei der Erstellung eines Threads im Forum zu allen beteiligten Geräten mit angegeben werden. Die Optionen können auch hilfreich sein, um Teile der [[Konfiguration]] schnell zwischen unterschiedlichen Installationen zu kopieren, z.B. von einem oder in ein Testsystem (siehe auch [[Import von Code Snippets]]).
=== list -r ===
Dabei werden auch die derzeitigen Stände der Readings mit ausgegeben. Für die Angabe des Gerätenamens ist dabei die Verwendung jeder {{Link2CmdRef|Anker=devspec|Label=devspec}} zulässig.

Beispiel:
:<code><nowiki>list -r TV</nowiki></code>
:<code><nowiki>list -r</nowiki></code>

=== list -R ===
Mit dieser Option werden auch die Geräte samt aktueller Zustände mit ausgegeben, die als '''probably associated with'' erkannt worden sind.

Beispiel:
:<code><nowiki>list -R TV</nowiki></code>

== Links ==
* [[Import von Code Snippets|RAW Definition]]

[[Kategorie:FHEM-Verwendung]]

List

2020-05-23T20:43:13Z

Maista: /* list -r */

{{SEITENTITEL:list}}
{{Infobox Modul
|ModPurpose=Befehl zur Auflistung von Gerätedefinitionen
|ModType=cmd
|ModCmdRef=list
|ModForumArea=Sonstiges
|ModTechName=fhem.pl ("Built-in")
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
Der Befehl [[list]] dient dazu, Informationen über Geräte (Devices) anzuzeigen. Dabei können entweder Details zu einem einzelnen Gerät ausgegeben werden, oder eine Liste von Geräten (Gerätenamen) mit bestimmten gemeinsamen Attributen. Wenn mehrere Geräte aufgelistet werden, lässt sich zu jedem zusätzlich der Wert eines oder mehrerer Internals, Readings oder Attribute mit ausgeben.

Der Befehl kann direkt über das Eingabefeld des [[FHEMWEB|Webfrontends]] oder über die telnet Schnittstelle eingegeben werden.

== Beispiele ==
{{Randnotiz|RNText=Für alle Beispiele gilt: im Webfrontend lassen sich die Namen der ausgegebenen Geräte direkt anklicken, um in die zugehörige Detail-Ansicht zu gelangen. Dies ist besonders für [[weblink]], [[SVG]] oder [[readingsGroup]] Geräte nützlich, die in der Raum-Ansicht eventuell keinen solchen Link auf die Detail-Ansicht zeigen.}}
=== Alle Geräte mit bestimmten Namen mit ihrer Definition ===
Auflistung der Definitionen aller Geräte von FHEM:
:<code><nowiki>list .* DEF</nowiki></code>

Auflistung der Definitionen der Geräte, die mit wz beginnen.
:<code><nowiki>list wz.* DEF</nowiki></code>

=== Alle Geräte eines bestimmten Typs ===
Mit dem Befehl
:<code><nowiki>list TYPE=FS20</nowiki></code>
wird eine Liste (die Namen) aller Geräte des Typs [[FS20]] ausgegeben.

=== Alle Geräte ohne TYPE ===
Manche Fehlersituationen in FHEM werden verursacht durch Geräte, bei denen kein ''Internal'' mit dem Namen ''TYPE'' festgelegt ist (was eigentlich eine ungültige Definition ist). Diese Geräte-Definitionen lassen sich mit dem Befehl
:<code><nowiki>{ join("\n", grep { !defined($defs{$_}{TYPE}) } keys %defs) }</nowiki></code>
identifizieren. Mithilfe dieser Information lässt sich dann z.B. ein solches Gerät [[delete|löschen]].

Ein derartiges Szenario ist unter anderem in diesem {{Link2Forum|Topic=41137|LinkText=Forenthema}} beschrieben.

=== Alle Geräte mit einem bestimmten Attribut ===
Im Zusammenhang mit Verhaltensänderungen eines Attributs (wie z.B. bei [[userReadings]] geschehen), kann es sinnvoll sein, alle Devices aufzulisten, bei denen dieses Attribut verwendet wurde.
;alle Devices, bei denen das Attribut ''userReadings'' (auf einen beliebigen Wert gesetzt) ist:
:<code>list userReadings=[a-zA-Z].*</code> oder <code>list userReadings=.+</code> oder <code>list userReadings=\w.*</code> oder <code>list userReadings=..*</code>

=== Alle Geräte in einem Raum ===
[[Datei:ListRoom.png|mini|right|Ausgabebeispiel eines ''list'' Befehls]]
Mit dem Befehl
:<code><nowiki>list room=TV</nowiki></code>
werden die Namen aller Geräte aufgeführt, die ein Attribut ''room'' mit dem Wert ''TV'' haben. Durch einen Klick auf den Gerätenamen wird die Detailansicht des Gerätes aufgerufen.

=== Attributwert zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM serialNr</code>
werden die Seriennummern aller Homematic Geräte aufgelistet.

=== Mehrere Werte zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM:FILTER=serialNr=..* serialNr model</code>
werden die Seriennummer und die Modellbezeichnung aller Homematic Geräte aufgelistet, die auch eine Seriennummer haben.

=== Gezieltes Auflisten von Internal, Reading oder Attribut ===
Bei manchen Geräten gibt es Internals, Readings oder Attribute mit gleichem Namen. Da ''list'' jeweils nur das erste Vorkommen zeigt und nicht sichtbar macht, was genau gefunden wurde, ist die Ausgabe manchmal nicht eindeutig. Um das zu vermeiden, lässt sich mit dem Präfix i:, r: oder a: vor dem Namen des anzuzeigenden Wertes angeben, welcher der drei möglichen Typen ausgegeben werden soll.

== Erweiterte Optionen ==
Mit den Optionen -r und -R kann eine erweiterte Ausgabe erzielt werden. Diese sollte bei der Erstellung eines Threads im Forum zu allen beteiligten Geräten mit angegeben werden. Die Optionen können auch hilfreich sein, um Teile der [[Konfiguration]] schnell zwischen unterschiedlichen Installationen zu kopieren, z.B. von einem oder in ein Testsystem (siehe auch [[Import von Code Snippets]]).
=== list -r ===
Dabei werden auch die derzeitigen Stände der Readings mit ausgegeben. Für die Angabe des Gerätenamens ist dabei die Verwendung jeder {{Link2CmdRef|Anker=devspec|Label=devspec}} zulässig.

Beispiel:
:<code><nowiki>list -r TV</nowiki></code>
:<code><nowiki>list -r .*</nowiki></code>

=== list -R ===
Mit dieser Option werden auch die Geräte samt aktueller Zustände mit ausgegeben, die als '''probably associated with'' erkannt worden sind.

Beispiel:
:<code><nowiki>list -R TV</nowiki></code>

== Links ==
* [[Import von Code Snippets|RAW Definition]]

[[Kategorie:FHEM-Verwendung]]

List

2020-05-23T20:40:03Z

Maista: /* list -R */

{{SEITENTITEL:list}}
{{Infobox Modul
|ModPurpose=Befehl zur Auflistung von Gerätedefinitionen
|ModType=cmd
|ModCmdRef=list
|ModForumArea=Sonstiges
|ModTechName=fhem.pl ("Built-in")
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
Der Befehl [[list]] dient dazu, Informationen über Geräte (Devices) anzuzeigen. Dabei können entweder Details zu einem einzelnen Gerät ausgegeben werden, oder eine Liste von Geräten (Gerätenamen) mit bestimmten gemeinsamen Attributen. Wenn mehrere Geräte aufgelistet werden, lässt sich zu jedem zusätzlich der Wert eines oder mehrerer Internals, Readings oder Attribute mit ausgeben.

Der Befehl kann direkt über das Eingabefeld des [[FHEMWEB|Webfrontends]] oder über die telnet Schnittstelle eingegeben werden.

== Beispiele ==
{{Randnotiz|RNText=Für alle Beispiele gilt: im Webfrontend lassen sich die Namen der ausgegebenen Geräte direkt anklicken, um in die zugehörige Detail-Ansicht zu gelangen. Dies ist besonders für [[weblink]], [[SVG]] oder [[readingsGroup]] Geräte nützlich, die in der Raum-Ansicht eventuell keinen solchen Link auf die Detail-Ansicht zeigen.}}
=== Alle Geräte mit bestimmten Namen mit ihrer Definition ===
Auflistung der Definitionen aller Geräte von FHEM:
:<code><nowiki>list .* DEF</nowiki></code>

Auflistung der Definitionen der Geräte, die mit wz beginnen.
:<code><nowiki>list wz.* DEF</nowiki></code>

=== Alle Geräte eines bestimmten Typs ===
Mit dem Befehl
:<code><nowiki>list TYPE=FS20</nowiki></code>
wird eine Liste (die Namen) aller Geräte des Typs [[FS20]] ausgegeben.

=== Alle Geräte ohne TYPE ===
Manche Fehlersituationen in FHEM werden verursacht durch Geräte, bei denen kein ''Internal'' mit dem Namen ''TYPE'' festgelegt ist (was eigentlich eine ungültige Definition ist). Diese Geräte-Definitionen lassen sich mit dem Befehl
:<code><nowiki>{ join("\n", grep { !defined($defs{$_}{TYPE}) } keys %defs) }</nowiki></code>
identifizieren. Mithilfe dieser Information lässt sich dann z.B. ein solches Gerät [[delete|löschen]].

Ein derartiges Szenario ist unter anderem in diesem {{Link2Forum|Topic=41137|LinkText=Forenthema}} beschrieben.

=== Alle Geräte mit einem bestimmten Attribut ===
Im Zusammenhang mit Verhaltensänderungen eines Attributs (wie z.B. bei [[userReadings]] geschehen), kann es sinnvoll sein, alle Devices aufzulisten, bei denen dieses Attribut verwendet wurde.
;alle Devices, bei denen das Attribut ''userReadings'' (auf einen beliebigen Wert gesetzt) ist:
:<code>list userReadings=[a-zA-Z].*</code> oder <code>list userReadings=.+</code> oder <code>list userReadings=\w.*</code> oder <code>list userReadings=..*</code>

=== Alle Geräte in einem Raum ===
[[Datei:ListRoom.png|mini|right|Ausgabebeispiel eines ''list'' Befehls]]
Mit dem Befehl
:<code><nowiki>list room=TV</nowiki></code>
werden die Namen aller Geräte aufgeführt, die ein Attribut ''room'' mit dem Wert ''TV'' haben. Durch einen Klick auf den Gerätenamen wird die Detailansicht des Gerätes aufgerufen.

=== Attributwert zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM serialNr</code>
werden die Seriennummern aller Homematic Geräte aufgelistet.

=== Mehrere Werte zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM:FILTER=serialNr=..* serialNr model</code>
werden die Seriennummer und die Modellbezeichnung aller Homematic Geräte aufgelistet, die auch eine Seriennummer haben.

=== Gezieltes Auflisten von Internal, Reading oder Attribut ===
Bei manchen Geräten gibt es Internals, Readings oder Attribute mit gleichem Namen. Da ''list'' jeweils nur das erste Vorkommen zeigt und nicht sichtbar macht, was genau gefunden wurde, ist die Ausgabe manchmal nicht eindeutig. Um das zu vermeiden, lässt sich mit dem Präfix i:, r: oder a: vor dem Namen des anzuzeigenden Wertes angeben, welcher der drei möglichen Typen ausgegeben werden soll.

== Erweiterte Optionen ==
Mit den Optionen -r und -R kann eine erweiterte Ausgabe erzielt werden. Diese sollte bei der Erstellung eines Threads im Forum zu allen beteiligten Geräten mit angegeben werden. Die Optionen können auch hilfreich sein, um Teile der [[Konfiguration]] schnell zwischen unterschiedlichen Installationen zu kopieren, z.B. von einem oder in ein Testsystem (siehe auch [[Import von Code Snippets]]).
=== list -r ===
Dabei werden auch die derzeitigen Stände der Readings mit ausgegeben. Für die Angabe des Gerätenamens ist dabei die Verwendung jeder {{Link2CmdRef|Anker=devspec|Label=devspec}} zulässig.
=== list -R ===
Mit dieser Option werden auch die Geräte samt aktueller Zustände mit ausgegeben, die als '''probably associated with'' erkannt worden sind.

Beispiel:
:<code><nowiki>list -R TV</nowiki></code>

== Links ==
* [[Import von Code Snippets|RAW Definition]]

[[Kategorie:FHEM-Verwendung]]

List

2020-05-23T20:14:03Z

Maista: n entfernt

{{SEITENTITEL:list}}
{{Infobox Modul
|ModPurpose=Befehl zur Auflistung von Gerätedefinitionen
|ModType=cmd
|ModCmdRef=list
|ModForumArea=Sonstiges
|ModTechName=fhem.pl ("Built-in")
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
Der Befehl [[list]] dient dazu, Informationen über Geräte (Devices) anzuzeigen. Dabei können entweder Details zu einem einzelnen Gerät ausgegeben werden, oder eine Liste von Geräten (Gerätenamen) mit bestimmten gemeinsamen Attributen. Wenn mehrere Geräte aufgelistet werden, lässt sich zu jedem zusätzlich der Wert eines oder mehrerer Internals, Readings oder Attribute mit ausgeben.

Der Befehl kann direkt über das Eingabefeld des [[FHEMWEB|Webfrontends]] oder über die telnet Schnittstelle eingegeben werden.

== Beispiele ==
{{Randnotiz|RNText=Für alle Beispiele gilt: im Webfrontend lassen sich die Namen der ausgegebenen Geräte direkt anklicken, um in die zugehörige Detail-Ansicht zu gelangen. Dies ist besonders für [[weblink]], [[SVG]] oder [[readingsGroup]] Geräte nützlich, die in der Raum-Ansicht eventuell keinen solchen Link auf die Detail-Ansicht zeigen.}}
=== Alle Geräte mit bestimmten Namen mit ihrer Definition ===
Auflistung der Definitionen aller Geräte von FHEM:
:<code><nowiki>list .* DEF</nowiki></code>

Auflistung der Definitionen der Geräte, die mit wz beginnen.
:<code><nowiki>list wz.* DEF</nowiki></code>

=== Alle Geräte eines bestimmten Typs ===
Mit dem Befehl
:<code><nowiki>list TYPE=FS20</nowiki></code>
wird eine Liste (die Namen) aller Geräte des Typs [[FS20]] ausgegeben.

=== Alle Geräte ohne TYPE ===
Manche Fehlersituationen in FHEM werden verursacht durch Geräte, bei denen kein ''Internal'' mit dem Namen ''TYPE'' festgelegt ist (was eigentlich eine ungültige Definition ist). Diese Geräte-Definitionen lassen sich mit dem Befehl
:<code><nowiki>{ join("\n", grep { !defined($defs{$_}{TYPE}) } keys %defs) }</nowiki></code>
identifizieren. Mithilfe dieser Information lässt sich dann z.B. ein solches Gerät [[delete|löschen]].

Ein derartiges Szenario ist unter anderem in diesem {{Link2Forum|Topic=41137|LinkText=Forenthema}} beschrieben.

=== Alle Geräte mit einem bestimmten Attribut ===
Im Zusammenhang mit Verhaltensänderungen eines Attributs (wie z.B. bei [[userReadings]] geschehen), kann es sinnvoll sein, alle Devices aufzulisten, bei denen dieses Attribut verwendet wurde.
;alle Devices, bei denen das Attribut ''userReadings'' (auf einen beliebigen Wert gesetzt) ist:
:<code>list userReadings=[a-zA-Z].*</code> oder <code>list userReadings=.+</code> oder <code>list userReadings=\w.*</code> oder <code>list userReadings=..*</code>

=== Alle Geräte in einem Raum ===
[[Datei:ListRoom.png|mini|right|Ausgabebeispiel eines ''list'' Befehls]]
Mit dem Befehl
:<code><nowiki>list room=TV</nowiki></code>
werden die Namen aller Geräte aufgeführt, die ein Attribut ''room'' mit dem Wert ''TV'' haben. Durch einen Klick auf den Gerätenamen wird die Detailansicht des Gerätes aufgerufen.

=== Attributwert zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM serialNr</code>
werden die Seriennummern aller Homematic Geräte aufgelistet.

=== Mehrere Werte zu mehreren Geräten ===
Mit dem Befehl
:<code>list TYPE=CUL_HM:FILTER=serialNr=..* serialNr model</code>
werden die Seriennummer und die Modellbezeichnung aller Homematic Geräte aufgelistet, die auch eine Seriennummer haben.

=== Gezieltes Auflisten von Internal, Reading oder Attribut ===
Bei manchen Geräten gibt es Internals, Readings oder Attribute mit gleichem Namen. Da ''list'' jeweils nur das erste Vorkommen zeigt und nicht sichtbar macht, was genau gefunden wurde, ist die Ausgabe manchmal nicht eindeutig. Um das zu vermeiden, lässt sich mit dem Präfix i:, r: oder a: vor dem Namen des anzuzeigenden Wertes angeben, welcher der drei möglichen Typen ausgegeben werden soll.

== Erweiterte Optionen ==
Mit den Optionen -r und -R kann eine erweiterte Ausgabe erzielt werden. Diese sollte bei der Erstellung eines Threads im Forum zu allen beteiligten Geräten mit angegeben werden. Die Optionen können auch hilfreich sein, um Teile der [[Konfiguration]] schnell zwischen unterschiedlichen Installationen zu kopieren, z.B. von einem oder in ein Testsystem (siehe auch [[Import von Code Snippets]]).
=== list -r ===
Dabei werden auch die derzeitigen Stände der Readings mit ausgegeben. Für die Angabe des Gerätenamens ist dabei die Verwendung jeder {{Link2CmdRef|Anker=devspec|Label=devspec}} zulässig.
=== list -R ===
Mit dieser Option werden auch die Geräte samt aktueller Zustände mit ausgegeben, die als '''probably associated with'' erkannt worden sind.

== Links ==
* [[Import von Code Snippets|RAW Definition]]

[[Kategorie:FHEM-Verwendung]]

EventTypes

2020-05-23T16:33:48Z

Maista: Fhem > FHEM

{{SEITENTITEL:eventTypes}}
{{Infobox Modul
|ModPurpose=Sammeln der Ereignistypen für alle definerten Geräte
|ModType=h
|ModForumArea=Frontends
|ModCmdRef=eventTypes
|ModTechName=91_eventTypes.pm
|ModOwner={{Link2FU|8|rudolfkoenig}}
}}

Das Hilfsmodul [[eventTypes]] sammelt die Ereignistypen für alle definierten Geräte (Devices) und speichert sie in der spezifizierten Datei. Die gesammelten Daten werden benutzt um auf der Benutzeroberfläche (z.B. bei der Bearbeitung eines [[notify]]) bei der Erstellung von regulären Ausrücken die möglichen Werte in Auswahllisten anzuzeigen.

== Voraussetzungen ==
[[Datei:Hinweis_eventTypes.png|mini|rechts|Hinweis (Link) auf Informationen zu eventTypes]]
Für die Benutzung von eventTypes sind keine besonderen Voraussetzungen zu erfüllen, evenTypes ist jedoch im Gegenzug erforderlich, um Unterstützung bei der Erstellung von regulären Ausdrücken (Regexp wizard) bieten zu können.

== Anwendung ==
=== Define ===
Siehe {{Link2CmdRef|Anker=eventTypesdefine}}.

=== Attribute ===
Siehe {{Link2CmdRef|Anker=eventTypesattr}}.

== Hinweise ==
Die Datei für die Sammlung der eventTypes kann nach einiger Zeit sehr groß werden. Auf leistungsschwächeren FHEM-Servern führt dies unter Umständen zu einer erheblichen Verzögerung beim Objektdetails-Aufruf der Objekte, die den Regex Wizard nutzen (bspw. [[notify]], [[at]]).

Abhilfe: Löschen der eventTypes-Datei
set <eventTypes-device> clear
set <eventTypes-device> flush

siehe auch: {{Link2Forum|Topic=33905}}

== Anwendungsbeispiele ==

== Links ==

FileLog

2020-05-23T16:30:38Z

Maista: Fhem > FHEM

{{Infobox Modul
|ModPurpose=Protokollierung von Fhem-Ereignissen
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=92_FileLog.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])}}

Das Modul [[FileLog]] dient zur Protokollierung von Ereignissen in FHEM. Die Einträge werden in eine einfache Textdatei geschrieben. Zur Protokollierung in eine Datenbank kann alternativ oder auch parallel das Modul [[DbLog]] verwendet werden.

Logdateien sind die Basis für die Erstellung von Diagrammen ([[SVG]]).

== Definition ==
Details in der {{Link2CmdRef|Anker=FileLogdefine}}.

== Attribute ==
Über {{Link2CmdRef|Anker=FileLogattr|Label=Attribute}} lässt sich unter anderem auch festlegen, wie die Archivierung von Logdateien durchgeführt werden soll (Archivierungsbefehl, -pfad sowie Anzahl von Archivgenerationen).

Wenn bestimmte Zeilen '''nicht''' in die Logdatei geschrieben werden sollen, ist das Attribut ''ignoreRegexp'' hilfreich. Wenn beispielsweise alle Zeilen, die die Zeichenfolge "AbCd" oder "CdEf" enthalten '''nicht''' geloggt werden sollen, dann wäre
:<code>attr <log-name> ignoreRegexp .*AbCd.*|.*CdEf.*</code>
eine Attributdefinition, die das ermöglicht.

Dies bezieht sich aber nur auf normale FileLog-Instanzen. Falls Events aus dem globalen FHEM-Logfile ausgeschlossen werden sollen, muss man das Attribut in '''global''' angeben. (Zusammenhang siehe [[#Globale Logdatei und "fakelog"|Globale Logdatei und "fakelog"]])
:<code>attr global ignoreRegexp .*AbCd.*|.*CdEf.*</code>

== Funktionen ==
''FileLog'' bietet Funktionen wie ''reopen'', ''absorb'' und ''get''. Details dazu sind in der {{Link2CmdRef|Anker=FileLogset}} zu finden.

Sofern eine Instanz vom Objekt [[eventTypes]] angelegt ist, bietet die Detailansicht eines FileLog eine komfortable Möglichkeit, die regulären Ausdrücke für den/die Filter zu bearbeiten. Siehe hierzu auch diesen {{Link2Forum|Topic=12557|Message=75436}}.

== Globale Logdatei und "fakelog" ==
Die globale Logdatei (üblicherweise als fhem.log bezeichnet) für FHEM wird mit dem Attribut
:<code>attr global logfile XXX</code>
für das ''global''-Objekt definiert, wobei für ''XXX'' normalerweise <code>./log/fhem-%Y-%m.log</code> verwendet wird.

Um das ''fhem.log'' über das [[FHEMWEB|Web Interface]] anzeigen zu können, ist ein weiterer Eintrag in der [[Konfiguration]] erforderlich, nämlich:
:<code>define Logfile FileLog XXX fakelog</code>
Das ''XXX'' muss '''zwingend''' durch den gleichen Wert ersetzt werden, wie in der Definition des globalen ''logfile'' Attributs, weil anderenfalls unterschiedliche Dateien verwendet werden - mit dem Effekt, dass die über das Web Interface angezeigte Datei nicht die erwarteten Einträge enthält (Details dazu auch in diesem {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}}).

== Werte auslesen ==
Manchmal möchte man Daten aus den Logs abrufen ohne händisch in den Logfiles herumzuwühlen. Dies ist insb. auch dann hilfreich, wenn man eigenen Funktionen, Notifys oder spezielle Plots entwirft, bei denen man auf Logdaten zugreifen möchte.

Grundsätzlich beschrieben ist dies in der {{Link2CmdRef|Lang=de|Anker=FileLog}} und unterscheidet sich minimal (aber entscheidend) von der Struktur bei [[DbLog#Werte_auslesen|DbLogs]].

Hier ein paar Beispiele, was man damit anstellen kann:

* <code>get FileLog_FHT_3a32 - - 2016-10-01 2016-10-03</code> alle Einträge des FileLog_FHT_3a32 vom 01.10.-03.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00</code> alle Einträge des FileLog_FHT_3a32 von 8-16 Uhr am 01.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00 4:measured:0:</code> nur die Temperatur-Werte
* <code>{ ReadingsTimestamp("FHT_3a32","state","0") }</code> Timestamp des aktuellen state des FHT_3a32
* <code>{ OldTimestamp("FHT_3a32") }</code> Timestamp des letzten state des FHT_3a32
* <code>{ time_str2num(OldTimestamp("FHT_3a32")) }</code> Timestamp in Sekunden des letzten state des FHT_3a32
* ...
Weitere Beispiele kann man sich gut aus den SVG-Dateien ziehen.

== Links ==
* {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}} zum Thema fhem.log / fakelog

[[Kategorie:Logging]]

ArduCounter

2020-01-01T22:57:13Z

Maista: /* Set-Commands */

{{Infobox Modul
|ModPurpose=Count pulses, calculate time between pulses and convert this to readings for e.g. power consumption of Energy meters
|ModType=contrib
|ModCmdRef=ArduCounter
|ModForumArea=Sonstiges
|ModFTopic=19285
|ModTechName=98_ArduCounter.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
This module implements an Interface to an Arduino or ESP8266 based counter for pulses on any input pin of an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device. The device connects to FHEM either through USB / serial or via tcp if an ESP board is used.

The typical use case is an S0-Interface on an energy meter or water meter, but also reflection light barriers to monitor old ferraris counters are supported

Counters are configured with attributes that define which Arduino pins should count pulses and in which intervals the Arduino board should report the current counts.

The Arduino sketch that works with this module uses pin change interrupts so it can efficiently count pulses on all available input pins.
The module creates readings for pulse counts, consumption and optionally also a pin history with pulse lengths and gaps of the last pulses.

== Availability ==
The module has been checked in to the FHEM svn.
The corresponding Arduino sketch can also be found under contrib in the subdirectory arduino/.

== Prerequisites ==
This module requires an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device based on an Atmel 328p or ESP8266 running the ArduCounter sketch provided with this module

In order to flash an Arduino board with the corresponding ArduCounter firmware from within Fhem, avrdude needs to be installed.

For old ferraris counters an Arduino Uno or Nano or ESP8266 board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line.

This module also requires Device::SerialPort or Win32::SerialPort for communication via serial lines

== Define ==

<pre>define <name> ArduCounter <device></pre>
or
<pre>define <name> ArduCounter <ip:port></pre>

<device> specifies the serial port to communicate with the Arduino.

<ip:port> specifies the ip address and tcp port to communicate with an esp8266 where port is typically 80.

The name of the serial-device depends on your distribution. You can also specify a baudrate for serial connections if the device name contains the @ character, e.g.: /dev/ttyUSB0@38400. The default baudrate of the ArduCounter firmware is 38400 since Version 1.4

Examples:
<pre>
define AC ArduCounter /dev/ttyUSB2@38400
define AC ArduCounter 192.168.1.134:80
</pre>

== Configuration of ArduCounter digital counters ==

Specify the pins where impulses should be counted e.g. as attr AC pinX falling pullup 30

The X in pinX can be an Arduino / ESP pin number with or without the letter D e.g. pin4, pinD5, pin6, pinD7 ...

After the pin you can use the keywords falling or rising to define if a logical one / 5V (rising) or a logical zero / 0V (falling) should be treated as pulse.

The optional keyword pullup activates the pullup resistor for the given Pin.

The last argument is also optional but recommended and specifies a minimal pulse length in milliseconds.

An energy meter with S0 interface is typically connected to GND and an input pin like D4.
The S0 pulse then pulls the input to 0V.
Since the minimal pulse lenght of the s0 interface is specified to be 30ms, the typical configuration for an s0 interface is
attr AC pinX falling pullup 30

Specifying a minimal pulse length is recommended since it filters bouncing of reed contacts or other noise.

Example:
<pre>
define AC ArduCounter /dev/ttyUSB2
attr AC pulsesPerKWh 1000
attr AC interval 60 300
attr AC pinD4 falling pullup 5
attr AC pinD5 falling pullup 30
attr AC verboseReadingsD5
attr AC pinD6 rising
</pre>

This defines three counters connected to the pins D4, D5 and D5.
D4 and D5 have their pullup resistors activated and the impulse draws the pins to zero.
For D4 and D5 the arduino measures the time in milliseconds between the falling edge and the rising edge. If this time is longer than the specified 5 or 30 milliseconds then the impulse is counted.
If the time is shorter then this impulse is regarded as noise and added to a separate reject counter.

verboseReadings5 causes the module to create additional readings like the pin history which shows length and gaps between the last pulses.

For pin D6 the arduino does not check pulse lengths and counts every time when the signal changes from 0 to 1.

The ArduCounter sketch which must be loaded on the Arduino or ESP implements this using pin change interrupts, so all avilable input pins can be used, not only the ones that support normal interrupts.
The module has been tested with 14 inputs of an Arduino Uno counting in parallel and pulses as short as 3 milliseconds.

== Configuration of ArduCounter analog counters ==

This module and the corresponding sketch can be used to read out old analog ferraris energy counters. Therefore an ESP, Arduino Uno or Nano board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line. The idea comes from Martin Kompf (https://www.kompf.de/tech/emeir.html) and has been adopted for ArduCounter to support old ferraris energy counters.

To support this mode, the sketch has to be compiled with analogIR defined.

The configuration is then similar to the one for digital counters:

<pre>
define ACF ArduCounter /dev/ttyUSB4
attr ACF analogThresholds 100 110
attr ACF flashCommand avrdude -p atmega328P -b57600 -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr ACF interval 60 300 2 2
attr ACF pinA7 rising 20
attr ACF pulsesPerKWh 75
attr ACF stateFormat {sprintf("%.3f kW", ReadingsVal($name,"powerA7",0))}
</pre>

To find out the right analog thresholds you can set devVerbose to 20 which will ask the firmware of your conting board to report every analog measurement. The ArduCounter module will count how often each value is reported and you can then query these analog level counts with get levels. After a few turns of the ferraris disc the result of get levels might look like this:

<pre>
observed levels from analog input:
94: 21
95: 79
96: 6
97: 2
98: 3
99: 2
100: 2
101: 1
102: 3
105: 2
106: 1
108: 2
109: 1
110: 1
112: 1
113: 3
115: 4
116: 9
117: 14
118: 71
119: 103
120: 118
121: 155
122: 159
123: 143
124: 147
125: 158
126: 198
127: 249
128: 220
129: 230
130: 201
131: 140
132: 147
133: 153
134: 141
135: 119
136: 105
137: 109
138: 114
139: 83
140: 33
141: 14
142: 1
</pre>

This shows the measured values together with the frequency how often the individual value has been measured. It is obvious that most measurements result in values between 120 and 135, very few values are betweem 96 and 115 and another peak is around the value 95.
It means that the when the red mark of the ferraris disc is under the sensor, the value is around 95 and while the blank disc is under the sensor, the value is typically between 120 and 135. So a good upper threshold would be 120 and a good lower threshold would be for example 96.

== Get-Commands ==
;info
:send a command to the Arduino board to get current counts.
:This is not needed for normal operation but might be useful sometimes for debugging.

;levels
:show the count for the measured levels if an analog pin is used to measure e.g. the red mark of a ferraris counter disc.
:This is useful for setting the thresholds for analog measurements.

;history
:shows details regarding all the level changes that the counter device (Arduino or ESP) has detected
:and how they were used (counted or rejected)
:If get history is issued with a pin name (e.g. get history D5) then only the history entries concerning D5 will be shown.
:This information is sent from the device to Fhem when it reports the current count but only if devVerbose is equal or greater than 5.
:The maximum number of lines that the Arducounter module stores in a ring buffer is defined by the attribute maxHist and defaults to 1000.

== Set-Commands ==

;raw
:send the value to the board so you can directly talk to the sketch using its commands.
:This is not needed for normal operation but might be useful sometimes for debugging

;flash
:flashes the ArduCounter firmware ArduCounter.hex from the fhem subdirectory FHEM/firmware onto the device.
:This command needs avrdude to be installed. The attribute flashCommand specidies how avrdude is called.
:If it is not modifed then the module sets it to avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
:This setting should work for a standard installation and the placeholders are automatically replaced when the command is used.
:So normally there is no need to modify this attribute.
:Depending on your specific Arduino board however, you might need to insert -b 57600 in the flash Command.
:(e.g. for an Arduino Nano) ESP boards so far have to be flashed from the Arduino IDE. In a future version flashing over the air sould be supported.

;reset
:reopens the arduino device and sends a command to it which causes a reinitialize and reset of the counters. Then the module resends the attribute configuration / definition of the pins to the device.

;saveConfig
:stores the current interval, analog threshold and pin configuration to be stored in the EEPROM of the counter device
:so it can be retrieved after a reset.

;enable
:sets the attribute disable to 0

;disable
:sets the attribute disable to 1

;reconnect
:closes the tcp connection to an ESP based counter board that is conected via TCP/IP and reopen the connection

== Supported readings ==
The module creates at least the following readings and events for each defined pin:

;pin.* e.g. pinD4
:the current internal count at this pin (internal to the Arduino / ESP device, starts at 0 when the device restarts).
:The name of this reading can be changed with the attribute readingNameCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;long.* e.g. longD5
:long count which keeps on counting up after fhem restarts whereas the pin.* count is only a temporary internal count that starts at 0 when the arduino board starts.
:The name of this reading can be changed with the attribute readingNameLongCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;interpolatedLong.*
:like long.* but when the Arduino restarts the potentially missed pulses are interpolated based on the pulse rate before the restart and after the restart.
:The name of this reading can be changed with the attribute readingNameInterpolatedCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;calcCounter.*
:similar to long count which keeps on counting up after fhem restarts but this counter will take the pulses per kWh setting into the :calculation und thus not count pulses but real kWh (or some other unit that is applicable)
:The name of this reading can be changed with the attribute readingNameCalcCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;reject.*
:counts rejected pulses that are shorter than the specified minimal pulse length.

;power.*
:the current calculated power at this pin.
:The name of this reading can be changed with the attribute readingNamePower[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;pinHistory.*
:shows detailed information of the last pulses. This is only available when a minimal pulse length is specified for this pin. Also the total number of impulses recorded here is limited to 20 for all pins together. The output looks like -36/7:0C, -29/7:1G, -22/8:0C, -14/7:1G, -7/7:0C, 0/7:1G
:The first number is the relative time in milliseconds when the input level changed, followed by the length in milliseconds, the level and the internal action. -36/7:0C for example means that 36 milliseconds before the reporting started, the input changed to 0V, stayed there for 7 milliseconds and this was counted.

;countDiff.*
:delta of the current count to the last reported one. This is used together with timeDiff.* to calculate the power consumption.

;timeDiff.*
:time difference between the first pulse in the current observation interval and the last one. Used togehter with countDiff to calculate the power consumption.

;seq.*
:internal sequence number of the last report from the board to Fhem.

== Attributes ==

;do_not_notify
: ...

;pin.*
:Define a pin of the Arduino board as input. This attribute expects either <code>rising</code>, <code>falling</code> or <code>change</code>, followed by an optional <code>pullup</code> and an optional number as value.
:If a number is specified, the arduino will track rising and falling edges of each impulse and measure the length of a pulse in milliseconds.
:The number specified here is the minimal length of a pulse and a pause before a pulse. If one is too small, the pulse is not counted but added to a separate reject counter.

;interval normal max min mincout
:Defines the parameters that affect the way counting and reporting works.
:This Attribute expects at least two and a maximum of four numbers as value.
: The first is the normal interval, the second the maximal interval, the third is a minimal interval and the fourth is a minimal pulse count.

:In the usual operation mode (when the normal interval is smaller than the maximum interval), the Arduino board just counts and remembers the time between the first impulse and the last impulse for each pin.
:After the normal interval is elapsed the Arduino board reports the count and time for those pins where impulses were encountered.
:This means that even though the normal interval might be 10 seconds, the reported time difference can be something different because it observed impulses as starting and ending point.
:The Power (e.g. for energy meters) is the calculated based of the counted impulses and the time between the first and the last impulse.
:For the next interval, the starting time will be the time of the last impulse in the previous reporting period and the time difference will be taken up to the last impulse before the reporting interval has elapsed.

:The second, third and fourth numbers (maximum, minimal interval and minimal count) exist for the special case when the pulse frequency is very low and the reporting time is comparatively short.
:For example if the normal interval (first number) is 60 seconds and the device counts only one impulse in 90 seconds, the the calculated power reading will jump up and down and will give ugly numbers.
:By adjusting the other numbers of this attribute this can be avoided.
:In case in the normal interval the observed impulses are encountered in a time difference that is smaller than the third number (minimal interval) or if the number of impulses counted is smaller than the fourth number (minimal count) then the reporting is delayed until the maximum interval has elapsed or the above conditions have changed after another normal interval.
:This way the counter will report a higher number of pulses counted and a larger time difference back to fhem.

:If this is seems too complicated and you prefer a simple and constant reporting interval, then you can set the normal interval and the mximum interval to the same number. This changes the operation mode of the counter to just count during this normal and maximum interval and report the count. In this case the reported time difference is always the reporting interval and not the measured time between the real impulses.

;factor
:Define a multiplicator for calculating the power from the impulse count and the time between the first and the last impulse.
:This attribute is outdated and unintuitive so you should avoid it.
:Instead you should specify the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;readingFactor[0-9]+
:Override the factor attribute for this individual pin.
:Just like the attribute factor, this is a rather cumbersome way to specify the pulses per kWh.
:Instaed it is advised to use the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;pulsesPerKWh
:specify the number of pulses that the meter is giving out per unit that sould be displayed (e.g. per kWh energy consumed). For many S0 counters this is 1000, for old ferraris counters this is 75 (rounds per kWh).
:Example: attr myCounter pulsesPerKWh 75

;readingPulsesPerKWh[0-9]+
:is the same as pulsesPerKWh but specified per pin individually in case you have multiple counters with different settings at the same time
:Example:
:attr myCounter readingPulsesPerKWhA7 75
:attr myCounter readingPulsesPerKWhD4 1000

;readingNameCount[0-9]+
:Change the name of the counter reading pinX to something more meaningful.

;readingNameLongCount[0-9]+
:Change the name of the counter reading longX to something more meaningful.

;readingNameInterpolatedCount[0-9]+
:Change the name of the counter reading InterpolatedLongX to something more meaningful.

;readingNameCalcCount[AD]?[0-9]+
:Change the name of the real unit counter reading CalcCounterX to something more meaningful.
:Example: attr myCounter readingNameCalcCountD4 CounterHaus_kWh

;readingNamePower[0-9]+
:Change the name of the power reading powerX to something more meaningful.

;readingStartTime[0-9]+
:Allow the reading time stamp to be set to the beginning of measuring intervals

;verboseReadings[0-9]+
:create additional readings: timeDiff, countDiff and lastMsg for each pin

;devVerbose
:set the verbose level in the counting board. This defaults to 0.
:If the value is >0, then the firmware will echo all commands sent to it by the Fhem module.
:If the value is >=5, then the firmware will report the pin history (assuming that the firmware has been compiled with this feature enabled)
:If the value is >=10, then the firmware will report every level change of a pin
:If the value is >=20, then the firmware will report every analog measurement (assuming that the firmware has been compiled with analog measurements for old ferraris counters or similar).

;maxHist
:specifies how many pin history lines hould be buffered for "get history".
:This attribute defaults to 1000.

;analogThresholds
:this Attribute is necessary when you use an arduino nano with connected reflection light barrier (photo transistor and led) to detect the red mark of an old ferraris energy counter. In this case the firmware uses an upper and lower threshold which can be set here.
:Example: attr myCounter analogThresholds 90 110
:In order to find out the right threshold values you can set devVerbose to 20, wait for several turns of the ferraris disc and then use get levels to see the typical measurements for the red mark and the blank disc.

;flashCommand
:sets the command to call avrdude and flash the onnected arduino with an updated hex file (by default it looks for ArduCounter.hex in the FHEM/firmware subdirectory.
:This attribute contains avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] by default.
:For an Arduino Nano based counter you should add -b 57600 e.g. between the -P and -D options.
:Example: attr myCounter flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]

;keepAliveDelay
:defines an interval in which the module sends keepalive messages to a counter device that is conected via tcp.
:This attribute is ignored if the device is connected via serial port.
:If the device doesn't reply within a defined timeout then the module closes and tries to reopen the connection.
:The module tells the device when to expect the next keepalive message and the device will also close the tcp connection if it doesn't see a :keepalive message within the delay multiplied by 3
:The delay defaults to 10 seconds.
:Example: attr myCounter keepAliveDelay 30

;keepAliveTimeout
:defines the timeout when wainting for a keealive reply (see keepAliveDelay) The timeout defaults to 2 seconds.
:Example: attr myCounter keepAliveTimeout 3

;keepAliveRetries
:defines how often sending a keepalive is retried before the connection is closed and reopened.
:It defaults to 2.
:Example: attr myCounter keepAliveRetries 3

;nextOpenDelay
:defines the time that the module waits before retrying to open a disconnected tcp connection.
:This defaults to 60 seconds.
:Example: attr myCounter nextOpenDelay 20

;openTimeout
:defines the timeout after which tcp open gives up trying to establish a connection to the counter device. This timeout defaults to 3 seconds.
:Example: attr myCounter openTimeout 5

;silentReconnect
:if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3
:Example: attr myCounter silentReconnect 1

;disable
:if set to 1 then the module closes the connection to a counter device.

[[Kategorie:Other Components]]
[[Kategorie:Energieverbrauchsmessung]]

ArduCounter

2020-01-01T22:54:47Z

Maista: /* Prerequisites */

{{Infobox Modul
|ModPurpose=Count pulses, calculate time between pulses and convert this to readings for e.g. power consumption of Energy meters
|ModType=contrib
|ModCmdRef=ArduCounter
|ModForumArea=Sonstiges
|ModFTopic=19285
|ModTechName=98_ArduCounter.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
This module implements an Interface to an Arduino or ESP8266 based counter for pulses on any input pin of an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device. The device connects to FHEM either through USB / serial or via tcp if an ESP board is used.

The typical use case is an S0-Interface on an energy meter or water meter, but also reflection light barriers to monitor old ferraris counters are supported

Counters are configured with attributes that define which Arduino pins should count pulses and in which intervals the Arduino board should report the current counts.

The Arduino sketch that works with this module uses pin change interrupts so it can efficiently count pulses on all available input pins.
The module creates readings for pulse counts, consumption and optionally also a pin history with pulse lengths and gaps of the last pulses.

== Availability ==
The module has been checked in to the FHEM svn.
The corresponding Arduino sketch can also be found under contrib in the subdirectory arduino/.

== Prerequisites ==
This module requires an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device based on an Atmel 328p or ESP8266 running the ArduCounter sketch provided with this module

In order to flash an Arduino board with the corresponding ArduCounter firmware from within Fhem, avrdude needs to be installed.

For old ferraris counters an Arduino Uno or Nano or ESP8266 board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line.

This module also requires Device::SerialPort or Win32::SerialPort for communication via serial lines

== Define ==

<pre>define <name> ArduCounter <device></pre>
or
<pre>define <name> ArduCounter <ip:port></pre>

<device> specifies the serial port to communicate with the Arduino.

<ip:port> specifies the ip address and tcp port to communicate with an esp8266 where port is typically 80.

The name of the serial-device depends on your distribution. You can also specify a baudrate for serial connections if the device name contains the @ character, e.g.: /dev/ttyUSB0@38400. The default baudrate of the ArduCounter firmware is 38400 since Version 1.4

Examples:
<pre>
define AC ArduCounter /dev/ttyUSB2@38400
define AC ArduCounter 192.168.1.134:80
</pre>

== Configuration of ArduCounter digital counters ==

Specify the pins where impulses should be counted e.g. as attr AC pinX falling pullup 30

The X in pinX can be an Arduino / ESP pin number with or without the letter D e.g. pin4, pinD5, pin6, pinD7 ...

After the pin you can use the keywords falling or rising to define if a logical one / 5V (rising) or a logical zero / 0V (falling) should be treated as pulse.

The optional keyword pullup activates the pullup resistor for the given Pin.

The last argument is also optional but recommended and specifies a minimal pulse length in milliseconds.

An energy meter with S0 interface is typically connected to GND and an input pin like D4.
The S0 pulse then pulls the input to 0V.
Since the minimal pulse lenght of the s0 interface is specified to be 30ms, the typical configuration for an s0 interface is
attr AC pinX falling pullup 30

Specifying a minimal pulse length is recommended since it filters bouncing of reed contacts or other noise.

Example:
<pre>
define AC ArduCounter /dev/ttyUSB2
attr AC pulsesPerKWh 1000
attr AC interval 60 300
attr AC pinD4 falling pullup 5
attr AC pinD5 falling pullup 30
attr AC verboseReadingsD5
attr AC pinD6 rising
</pre>

This defines three counters connected to the pins D4, D5 and D5.
D4 and D5 have their pullup resistors activated and the impulse draws the pins to zero.
For D4 and D5 the arduino measures the time in milliseconds between the falling edge and the rising edge. If this time is longer than the specified 5 or 30 milliseconds then the impulse is counted.
If the time is shorter then this impulse is regarded as noise and added to a separate reject counter.

verboseReadings5 causes the module to create additional readings like the pin history which shows length and gaps between the last pulses.

For pin D6 the arduino does not check pulse lengths and counts every time when the signal changes from 0 to 1.

The ArduCounter sketch which must be loaded on the Arduino or ESP implements this using pin change interrupts, so all avilable input pins can be used, not only the ones that support normal interrupts.
The module has been tested with 14 inputs of an Arduino Uno counting in parallel and pulses as short as 3 milliseconds.

== Configuration of ArduCounter analog counters ==

This module and the corresponding sketch can be used to read out old analog ferraris energy counters. Therefore an ESP, Arduino Uno or Nano board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line. The idea comes from Martin Kompf (https://www.kompf.de/tech/emeir.html) and has been adopted for ArduCounter to support old ferraris energy counters.

To support this mode, the sketch has to be compiled with analogIR defined.

The configuration is then similar to the one for digital counters:

<pre>
define ACF ArduCounter /dev/ttyUSB4
attr ACF analogThresholds 100 110
attr ACF flashCommand avrdude -p atmega328P -b57600 -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr ACF interval 60 300 2 2
attr ACF pinA7 rising 20
attr ACF pulsesPerKWh 75
attr ACF stateFormat {sprintf("%.3f kW", ReadingsVal($name,"powerA7",0))}
</pre>

To find out the right analog thresholds you can set devVerbose to 20 which will ask the firmware of your conting board to report every analog measurement. The ArduCounter module will count how often each value is reported and you can then query these analog level counts with get levels. After a few turns of the ferraris disc the result of get levels might look like this:

<pre>
observed levels from analog input:
94: 21
95: 79
96: 6
97: 2
98: 3
99: 2
100: 2
101: 1
102: 3
105: 2
106: 1
108: 2
109: 1
110: 1
112: 1
113: 3
115: 4
116: 9
117: 14
118: 71
119: 103
120: 118
121: 155
122: 159
123: 143
124: 147
125: 158
126: 198
127: 249
128: 220
129: 230
130: 201
131: 140
132: 147
133: 153
134: 141
135: 119
136: 105
137: 109
138: 114
139: 83
140: 33
141: 14
142: 1
</pre>

This shows the measured values together with the frequency how often the individual value has been measured. It is obvious that most measurements result in values between 120 and 135, very few values are betweem 96 and 115 and another peak is around the value 95.
It means that the when the red mark of the ferraris disc is under the sensor, the value is around 95 and while the blank disc is under the sensor, the value is typically between 120 and 135. So a good upper threshold would be 120 and a good lower threshold would be for example 96.

== Get-Commands ==
;info
:send a command to the Arduino board to get current counts.
:This is not needed for normal operation but might be useful sometimes for debugging.

;levels
:show the count for the measured levels if an analog pin is used to measure e.g. the red mark of a ferraris counter disc.
:This is useful for setting the thresholds for analog measurements.

;history
:shows details regarding all the level changes that the counter device (Arduino or ESP) has detected
:and how they were used (counted or rejected)
:If get history is issued with a pin name (e.g. get history D5) then only the history entries concerning D5 will be shown.
:This information is sent from the device to Fhem when it reports the current count but only if devVerbose is equal or greater than 5.
:The maximum number of lines that the Arducounter module stores in a ring buffer is defined by the attribute maxHist and defaults to 1000.

== Set-Commands ==

;raw
:send the value to the board so you can directly talk to the sketch using its commands.
:This is not needed for normal operation but might be useful sometimes for debugging

;flash
:flashes the ArduCounter firmware ArduCounter.hex from the fhem subdirectory FHEM/firmware onto the device.
:This command needs avrdude to be installed. The attribute flashCommand specidies how avrdude is called.
:If it is not modifed then the module sets it to avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
:This setting should work for a standard installation and the placeholders are automatically replaced when the command is used.
:So normally there is no need to modify this attribute.
:Depending on your specific Arduino board however, you might need to insert -b 57600 in the flash Command.
:(e.g. for an Arduino Nano) ESP boards so far have to be fashed from the Arduino IDE. In a future version flashing over the air sould be supported.

;reset
:reopens the arduino device and sends a command to it which causes a reinitialize and reset of the counters. Then the module resends the attribute configuration / definition of the pins to the device.

;saveConfig
:stores the current interval, analog threshold and pin configuration to be stored in the EEPROM of the counter device
:so it can be retrieved after a reset.

;enable
:sets the attribute disable to 0

;disable
:sets the attribute disable to 1

;reconnect
:closes the tcp connection to an ESP based counter board that is conected via TCP/IP and reopen the connection

== Supported readings ==
The module creates at least the following readings and events for each defined pin:

;pin.* e.g. pinD4
:the current internal count at this pin (internal to the Arduino / ESP device, starts at 0 when the device restarts).
:The name of this reading can be changed with the attribute readingNameCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;long.* e.g. longD5
:long count which keeps on counting up after fhem restarts whereas the pin.* count is only a temporary internal count that starts at 0 when the arduino board starts.
:The name of this reading can be changed with the attribute readingNameLongCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;interpolatedLong.*
:like long.* but when the Arduino restarts the potentially missed pulses are interpolated based on the pulse rate before the restart and after the restart.
:The name of this reading can be changed with the attribute readingNameInterpolatedCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;calcCounter.*
:similar to long count which keeps on counting up after fhem restarts but this counter will take the pulses per kWh setting into the :calculation und thus not count pulses but real kWh (or some other unit that is applicable)
:The name of this reading can be changed with the attribute readingNameCalcCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;reject.*
:counts rejected pulses that are shorter than the specified minimal pulse length.

;power.*
:the current calculated power at this pin.
:The name of this reading can be changed with the attribute readingNamePower[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;pinHistory.*
:shows detailed information of the last pulses. This is only available when a minimal pulse length is specified for this pin. Also the total number of impulses recorded here is limited to 20 for all pins together. The output looks like -36/7:0C, -29/7:1G, -22/8:0C, -14/7:1G, -7/7:0C, 0/7:1G
:The first number is the relative time in milliseconds when the input level changed, followed by the length in milliseconds, the level and the internal action. -36/7:0C for example means that 36 milliseconds before the reporting started, the input changed to 0V, stayed there for 7 milliseconds and this was counted.

;countDiff.*
:delta of the current count to the last reported one. This is used together with timeDiff.* to calculate the power consumption.

;timeDiff.*
:time difference between the first pulse in the current observation interval and the last one. Used togehter with countDiff to calculate the power consumption.

;seq.*
:internal sequence number of the last report from the board to Fhem.

== Attributes ==

;do_not_notify
: ...

;pin.*
:Define a pin of the Arduino board as input. This attribute expects either <code>rising</code>, <code>falling</code> or <code>change</code>, followed by an optional <code>pullup</code> and an optional number as value.
:If a number is specified, the arduino will track rising and falling edges of each impulse and measure the length of a pulse in milliseconds.
:The number specified here is the minimal length of a pulse and a pause before a pulse. If one is too small, the pulse is not counted but added to a separate reject counter.

;interval normal max min mincout
:Defines the parameters that affect the way counting and reporting works.
:This Attribute expects at least two and a maximum of four numbers as value.
: The first is the normal interval, the second the maximal interval, the third is a minimal interval and the fourth is a minimal pulse count.

:In the usual operation mode (when the normal interval is smaller than the maximum interval), the Arduino board just counts and remembers the time between the first impulse and the last impulse for each pin.
:After the normal interval is elapsed the Arduino board reports the count and time for those pins where impulses were encountered.
:This means that even though the normal interval might be 10 seconds, the reported time difference can be something different because it observed impulses as starting and ending point.
:The Power (e.g. for energy meters) is the calculated based of the counted impulses and the time between the first and the last impulse.
:For the next interval, the starting time will be the time of the last impulse in the previous reporting period and the time difference will be taken up to the last impulse before the reporting interval has elapsed.

:The second, third and fourth numbers (maximum, minimal interval and minimal count) exist for the special case when the pulse frequency is very low and the reporting time is comparatively short.
:For example if the normal interval (first number) is 60 seconds and the device counts only one impulse in 90 seconds, the the calculated power reading will jump up and down and will give ugly numbers.
:By adjusting the other numbers of this attribute this can be avoided.
:In case in the normal interval the observed impulses are encountered in a time difference that is smaller than the third number (minimal interval) or if the number of impulses counted is smaller than the fourth number (minimal count) then the reporting is delayed until the maximum interval has elapsed or the above conditions have changed after another normal interval.
:This way the counter will report a higher number of pulses counted and a larger time difference back to fhem.

:If this is seems too complicated and you prefer a simple and constant reporting interval, then you can set the normal interval and the mximum interval to the same number. This changes the operation mode of the counter to just count during this normal and maximum interval and report the count. In this case the reported time difference is always the reporting interval and not the measured time between the real impulses.

;factor
:Define a multiplicator for calculating the power from the impulse count and the time between the first and the last impulse.
:This attribute is outdated and unintuitive so you should avoid it.
:Instead you should specify the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;readingFactor[0-9]+
:Override the factor attribute for this individual pin.
:Just like the attribute factor, this is a rather cumbersome way to specify the pulses per kWh.
:Instaed it is advised to use the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;pulsesPerKWh
:specify the number of pulses that the meter is giving out per unit that sould be displayed (e.g. per kWh energy consumed). For many S0 counters this is 1000, for old ferraris counters this is 75 (rounds per kWh).
:Example: attr myCounter pulsesPerKWh 75

;readingPulsesPerKWh[0-9]+
:is the same as pulsesPerKWh but specified per pin individually in case you have multiple counters with different settings at the same time
:Example:
:attr myCounter readingPulsesPerKWhA7 75
:attr myCounter readingPulsesPerKWhD4 1000

;readingNameCount[0-9]+
:Change the name of the counter reading pinX to something more meaningful.

;readingNameLongCount[0-9]+
:Change the name of the counter reading longX to something more meaningful.

;readingNameInterpolatedCount[0-9]+
:Change the name of the counter reading InterpolatedLongX to something more meaningful.

;readingNameCalcCount[AD]?[0-9]+
:Change the name of the real unit counter reading CalcCounterX to something more meaningful.
:Example: attr myCounter readingNameCalcCountD4 CounterHaus_kWh

;readingNamePower[0-9]+
:Change the name of the power reading powerX to something more meaningful.

;readingStartTime[0-9]+
:Allow the reading time stamp to be set to the beginning of measuring intervals

;verboseReadings[0-9]+
:create additional readings: timeDiff, countDiff and lastMsg for each pin

;devVerbose
:set the verbose level in the counting board. This defaults to 0.
:If the value is >0, then the firmware will echo all commands sent to it by the Fhem module.
:If the value is >=5, then the firmware will report the pin history (assuming that the firmware has been compiled with this feature enabled)
:If the value is >=10, then the firmware will report every level change of a pin
:If the value is >=20, then the firmware will report every analog measurement (assuming that the firmware has been compiled with analog measurements for old ferraris counters or similar).

;maxHist
:specifies how many pin history lines hould be buffered for "get history".
:This attribute defaults to 1000.

;analogThresholds
:this Attribute is necessary when you use an arduino nano with connected reflection light barrier (photo transistor and led) to detect the red mark of an old ferraris energy counter. In this case the firmware uses an upper and lower threshold which can be set here.
:Example: attr myCounter analogThresholds 90 110
:In order to find out the right threshold values you can set devVerbose to 20, wait for several turns of the ferraris disc and then use get levels to see the typical measurements for the red mark and the blank disc.

;flashCommand
:sets the command to call avrdude and flash the onnected arduino with an updated hex file (by default it looks for ArduCounter.hex in the FHEM/firmware subdirectory.
:This attribute contains avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] by default.
:For an Arduino Nano based counter you should add -b 57600 e.g. between the -P and -D options.
:Example: attr myCounter flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]

;keepAliveDelay
:defines an interval in which the module sends keepalive messages to a counter device that is conected via tcp.
:This attribute is ignored if the device is connected via serial port.
:If the device doesn't reply within a defined timeout then the module closes and tries to reopen the connection.
:The module tells the device when to expect the next keepalive message and the device will also close the tcp connection if it doesn't see a :keepalive message within the delay multiplied by 3
:The delay defaults to 10 seconds.
:Example: attr myCounter keepAliveDelay 30

;keepAliveTimeout
:defines the timeout when wainting for a keealive reply (see keepAliveDelay) The timeout defaults to 2 seconds.
:Example: attr myCounter keepAliveTimeout 3

;keepAliveRetries
:defines how often sending a keepalive is retried before the connection is closed and reopened.
:It defaults to 2.
:Example: attr myCounter keepAliveRetries 3

;nextOpenDelay
:defines the time that the module waits before retrying to open a disconnected tcp connection.
:This defaults to 60 seconds.
:Example: attr myCounter nextOpenDelay 20

;openTimeout
:defines the timeout after which tcp open gives up trying to establish a connection to the counter device. This timeout defaults to 3 seconds.
:Example: attr myCounter openTimeout 5

;silentReconnect
:if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3
:Example: attr myCounter silentReconnect 1

;disable
:if set to 1 then the module closes the connection to a counter device.

[[Kategorie:Other Components]]
[[Kategorie:Energieverbrauchsmessung]]

ArduCounter

2020-01-01T22:54:15Z

Maista: /* Availability */

{{Infobox Modul
|ModPurpose=Count pulses, calculate time between pulses and convert this to readings for e.g. power consumption of Energy meters
|ModType=contrib
|ModCmdRef=ArduCounter
|ModForumArea=Sonstiges
|ModFTopic=19285
|ModTechName=98_ArduCounter.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
This module implements an Interface to an Arduino or ESP8266 based counter for pulses on any input pin of an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device. The device connects to FHEM either through USB / serial or via tcp if an ESP board is used.

The typical use case is an S0-Interface on an energy meter or water meter, but also reflection light barriers to monitor old ferraris counters are supported

Counters are configured with attributes that define which Arduino pins should count pulses and in which intervals the Arduino board should report the current counts.

The Arduino sketch that works with this module uses pin change interrupts so it can efficiently count pulses on all available input pins.
The module creates readings for pulse counts, consumption and optionally also a pin history with pulse lengths and gaps of the last pulses.

== Availability ==
The module has been checked in to the FHEM svn.
The corresponding Arduino sketch can also be found under contrib in the subdirectory arduino/.

== Prerequisites ==
This module requires an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device based on an Atmel 328p or ESP8266 running the ArduCounter sketch provided with this module

In order to flash an arduino board with the corresponding ArduCounter firmware from within Fhem, avrdude needs to be installed.

For old ferraris counters an Arduino Uno or Nano or ESP8266 board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line.

This module also requires Device::SerialPort or Win32::SerialPort for communication via serial lines

== Define ==

<pre>define <name> ArduCounter <device></pre>
or
<pre>define <name> ArduCounter <ip:port></pre>

<device> specifies the serial port to communicate with the Arduino.

<ip:port> specifies the ip address and tcp port to communicate with an esp8266 where port is typically 80.

The name of the serial-device depends on your distribution. You can also specify a baudrate for serial connections if the device name contains the @ character, e.g.: /dev/ttyUSB0@38400. The default baudrate of the ArduCounter firmware is 38400 since Version 1.4

Examples:
<pre>
define AC ArduCounter /dev/ttyUSB2@38400
define AC ArduCounter 192.168.1.134:80
</pre>

== Configuration of ArduCounter digital counters ==

Specify the pins where impulses should be counted e.g. as attr AC pinX falling pullup 30

The X in pinX can be an Arduino / ESP pin number with or without the letter D e.g. pin4, pinD5, pin6, pinD7 ...

After the pin you can use the keywords falling or rising to define if a logical one / 5V (rising) or a logical zero / 0V (falling) should be treated as pulse.

The optional keyword pullup activates the pullup resistor for the given Pin.

The last argument is also optional but recommended and specifies a minimal pulse length in milliseconds.

An energy meter with S0 interface is typically connected to GND and an input pin like D4.
The S0 pulse then pulls the input to 0V.
Since the minimal pulse lenght of the s0 interface is specified to be 30ms, the typical configuration for an s0 interface is
attr AC pinX falling pullup 30

Specifying a minimal pulse length is recommended since it filters bouncing of reed contacts or other noise.

Example:
<pre>
define AC ArduCounter /dev/ttyUSB2
attr AC pulsesPerKWh 1000
attr AC interval 60 300
attr AC pinD4 falling pullup 5
attr AC pinD5 falling pullup 30
attr AC verboseReadingsD5
attr AC pinD6 rising
</pre>

This defines three counters connected to the pins D4, D5 and D5.
D4 and D5 have their pullup resistors activated and the impulse draws the pins to zero.
For D4 and D5 the arduino measures the time in milliseconds between the falling edge and the rising edge. If this time is longer than the specified 5 or 30 milliseconds then the impulse is counted.
If the time is shorter then this impulse is regarded as noise and added to a separate reject counter.

verboseReadings5 causes the module to create additional readings like the pin history which shows length and gaps between the last pulses.

For pin D6 the arduino does not check pulse lengths and counts every time when the signal changes from 0 to 1.

The ArduCounter sketch which must be loaded on the Arduino or ESP implements this using pin change interrupts, so all avilable input pins can be used, not only the ones that support normal interrupts.
The module has been tested with 14 inputs of an Arduino Uno counting in parallel and pulses as short as 3 milliseconds.

== Configuration of ArduCounter analog counters ==

This module and the corresponding sketch can be used to read out old analog ferraris energy counters. Therefore an ESP, Arduino Uno or Nano board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line. The idea comes from Martin Kompf (https://www.kompf.de/tech/emeir.html) and has been adopted for ArduCounter to support old ferraris energy counters.

To support this mode, the sketch has to be compiled with analogIR defined.

The configuration is then similar to the one for digital counters:

<pre>
define ACF ArduCounter /dev/ttyUSB4
attr ACF analogThresholds 100 110
attr ACF flashCommand avrdude -p atmega328P -b57600 -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr ACF interval 60 300 2 2
attr ACF pinA7 rising 20
attr ACF pulsesPerKWh 75
attr ACF stateFormat {sprintf("%.3f kW", ReadingsVal($name,"powerA7",0))}
</pre>

To find out the right analog thresholds you can set devVerbose to 20 which will ask the firmware of your conting board to report every analog measurement. The ArduCounter module will count how often each value is reported and you can then query these analog level counts with get levels. After a few turns of the ferraris disc the result of get levels might look like this:

<pre>
observed levels from analog input:
94: 21
95: 79
96: 6
97: 2
98: 3
99: 2
100: 2
101: 1
102: 3
105: 2
106: 1
108: 2
109: 1
110: 1
112: 1
113: 3
115: 4
116: 9
117: 14
118: 71
119: 103
120: 118
121: 155
122: 159
123: 143
124: 147
125: 158
126: 198
127: 249
128: 220
129: 230
130: 201
131: 140
132: 147
133: 153
134: 141
135: 119
136: 105
137: 109
138: 114
139: 83
140: 33
141: 14
142: 1
</pre>

This shows the measured values together with the frequency how often the individual value has been measured. It is obvious that most measurements result in values between 120 and 135, very few values are betweem 96 and 115 and another peak is around the value 95.
It means that the when the red mark of the ferraris disc is under the sensor, the value is around 95 and while the blank disc is under the sensor, the value is typically between 120 and 135. So a good upper threshold would be 120 and a good lower threshold would be for example 96.

== Get-Commands ==
;info
:send a command to the Arduino board to get current counts.
:This is not needed for normal operation but might be useful sometimes for debugging.

;levels
:show the count for the measured levels if an analog pin is used to measure e.g. the red mark of a ferraris counter disc.
:This is useful for setting the thresholds for analog measurements.

;history
:shows details regarding all the level changes that the counter device (Arduino or ESP) has detected
:and how they were used (counted or rejected)
:If get history is issued with a pin name (e.g. get history D5) then only the history entries concerning D5 will be shown.
:This information is sent from the device to Fhem when it reports the current count but only if devVerbose is equal or greater than 5.
:The maximum number of lines that the Arducounter module stores in a ring buffer is defined by the attribute maxHist and defaults to 1000.

== Set-Commands ==

;raw
:send the value to the board so you can directly talk to the sketch using its commands.
:This is not needed for normal operation but might be useful sometimes for debugging

;flash
:flashes the ArduCounter firmware ArduCounter.hex from the fhem subdirectory FHEM/firmware onto the device.
:This command needs avrdude to be installed. The attribute flashCommand specidies how avrdude is called.
:If it is not modifed then the module sets it to avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
:This setting should work for a standard installation and the placeholders are automatically replaced when the command is used.
:So normally there is no need to modify this attribute.
:Depending on your specific Arduino board however, you might need to insert -b 57600 in the flash Command.
:(e.g. for an Arduino Nano) ESP boards so far have to be fashed from the Arduino IDE. In a future version flashing over the air sould be supported.

;reset
:reopens the arduino device and sends a command to it which causes a reinitialize and reset of the counters. Then the module resends the attribute configuration / definition of the pins to the device.

;saveConfig
:stores the current interval, analog threshold and pin configuration to be stored in the EEPROM of the counter device
:so it can be retrieved after a reset.

;enable
:sets the attribute disable to 0

;disable
:sets the attribute disable to 1

;reconnect
:closes the tcp connection to an ESP based counter board that is conected via TCP/IP and reopen the connection

== Supported readings ==
The module creates at least the following readings and events for each defined pin:

;pin.* e.g. pinD4
:the current internal count at this pin (internal to the Arduino / ESP device, starts at 0 when the device restarts).
:The name of this reading can be changed with the attribute readingNameCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;long.* e.g. longD5
:long count which keeps on counting up after fhem restarts whereas the pin.* count is only a temporary internal count that starts at 0 when the arduino board starts.
:The name of this reading can be changed with the attribute readingNameLongCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;interpolatedLong.*
:like long.* but when the Arduino restarts the potentially missed pulses are interpolated based on the pulse rate before the restart and after the restart.
:The name of this reading can be changed with the attribute readingNameInterpolatedCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;calcCounter.*
:similar to long count which keeps on counting up after fhem restarts but this counter will take the pulses per kWh setting into the :calculation und thus not count pulses but real kWh (or some other unit that is applicable)
:The name of this reading can be changed with the attribute readingNameCalcCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;reject.*
:counts rejected pulses that are shorter than the specified minimal pulse length.

;power.*
:the current calculated power at this pin.
:The name of this reading can be changed with the attribute readingNamePower[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;pinHistory.*
:shows detailed information of the last pulses. This is only available when a minimal pulse length is specified for this pin. Also the total number of impulses recorded here is limited to 20 for all pins together. The output looks like -36/7:0C, -29/7:1G, -22/8:0C, -14/7:1G, -7/7:0C, 0/7:1G
:The first number is the relative time in milliseconds when the input level changed, followed by the length in milliseconds, the level and the internal action. -36/7:0C for example means that 36 milliseconds before the reporting started, the input changed to 0V, stayed there for 7 milliseconds and this was counted.

;countDiff.*
:delta of the current count to the last reported one. This is used together with timeDiff.* to calculate the power consumption.

;timeDiff.*
:time difference between the first pulse in the current observation interval and the last one. Used togehter with countDiff to calculate the power consumption.

;seq.*
:internal sequence number of the last report from the board to Fhem.

== Attributes ==

;do_not_notify
: ...

;pin.*
:Define a pin of the Arduino board as input. This attribute expects either <code>rising</code>, <code>falling</code> or <code>change</code>, followed by an optional <code>pullup</code> and an optional number as value.
:If a number is specified, the arduino will track rising and falling edges of each impulse and measure the length of a pulse in milliseconds.
:The number specified here is the minimal length of a pulse and a pause before a pulse. If one is too small, the pulse is not counted but added to a separate reject counter.

;interval normal max min mincout
:Defines the parameters that affect the way counting and reporting works.
:This Attribute expects at least two and a maximum of four numbers as value.
: The first is the normal interval, the second the maximal interval, the third is a minimal interval and the fourth is a minimal pulse count.

:In the usual operation mode (when the normal interval is smaller than the maximum interval), the Arduino board just counts and remembers the time between the first impulse and the last impulse for each pin.
:After the normal interval is elapsed the Arduino board reports the count and time for those pins where impulses were encountered.
:This means that even though the normal interval might be 10 seconds, the reported time difference can be something different because it observed impulses as starting and ending point.
:The Power (e.g. for energy meters) is the calculated based of the counted impulses and the time between the first and the last impulse.
:For the next interval, the starting time will be the time of the last impulse in the previous reporting period and the time difference will be taken up to the last impulse before the reporting interval has elapsed.

:The second, third and fourth numbers (maximum, minimal interval and minimal count) exist for the special case when the pulse frequency is very low and the reporting time is comparatively short.
:For example if the normal interval (first number) is 60 seconds and the device counts only one impulse in 90 seconds, the the calculated power reading will jump up and down and will give ugly numbers.
:By adjusting the other numbers of this attribute this can be avoided.
:In case in the normal interval the observed impulses are encountered in a time difference that is smaller than the third number (minimal interval) or if the number of impulses counted is smaller than the fourth number (minimal count) then the reporting is delayed until the maximum interval has elapsed or the above conditions have changed after another normal interval.
:This way the counter will report a higher number of pulses counted and a larger time difference back to fhem.

:If this is seems too complicated and you prefer a simple and constant reporting interval, then you can set the normal interval and the mximum interval to the same number. This changes the operation mode of the counter to just count during this normal and maximum interval and report the count. In this case the reported time difference is always the reporting interval and not the measured time between the real impulses.

;factor
:Define a multiplicator for calculating the power from the impulse count and the time between the first and the last impulse.
:This attribute is outdated and unintuitive so you should avoid it.
:Instead you should specify the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;readingFactor[0-9]+
:Override the factor attribute for this individual pin.
:Just like the attribute factor, this is a rather cumbersome way to specify the pulses per kWh.
:Instaed it is advised to use the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;pulsesPerKWh
:specify the number of pulses that the meter is giving out per unit that sould be displayed (e.g. per kWh energy consumed). For many S0 counters this is 1000, for old ferraris counters this is 75 (rounds per kWh).
:Example: attr myCounter pulsesPerKWh 75

;readingPulsesPerKWh[0-9]+
:is the same as pulsesPerKWh but specified per pin individually in case you have multiple counters with different settings at the same time
:Example:
:attr myCounter readingPulsesPerKWhA7 75
:attr myCounter readingPulsesPerKWhD4 1000

;readingNameCount[0-9]+
:Change the name of the counter reading pinX to something more meaningful.

;readingNameLongCount[0-9]+
:Change the name of the counter reading longX to something more meaningful.

;readingNameInterpolatedCount[0-9]+
:Change the name of the counter reading InterpolatedLongX to something more meaningful.

;readingNameCalcCount[AD]?[0-9]+
:Change the name of the real unit counter reading CalcCounterX to something more meaningful.
:Example: attr myCounter readingNameCalcCountD4 CounterHaus_kWh

;readingNamePower[0-9]+
:Change the name of the power reading powerX to something more meaningful.

;readingStartTime[0-9]+
:Allow the reading time stamp to be set to the beginning of measuring intervals

;verboseReadings[0-9]+
:create additional readings: timeDiff, countDiff and lastMsg for each pin

;devVerbose
:set the verbose level in the counting board. This defaults to 0.
:If the value is >0, then the firmware will echo all commands sent to it by the Fhem module.
:If the value is >=5, then the firmware will report the pin history (assuming that the firmware has been compiled with this feature enabled)
:If the value is >=10, then the firmware will report every level change of a pin
:If the value is >=20, then the firmware will report every analog measurement (assuming that the firmware has been compiled with analog measurements for old ferraris counters or similar).

;maxHist
:specifies how many pin history lines hould be buffered for "get history".
:This attribute defaults to 1000.

;analogThresholds
:this Attribute is necessary when you use an arduino nano with connected reflection light barrier (photo transistor and led) to detect the red mark of an old ferraris energy counter. In this case the firmware uses an upper and lower threshold which can be set here.
:Example: attr myCounter analogThresholds 90 110
:In order to find out the right threshold values you can set devVerbose to 20, wait for several turns of the ferraris disc and then use get levels to see the typical measurements for the red mark and the blank disc.

;flashCommand
:sets the command to call avrdude and flash the onnected arduino with an updated hex file (by default it looks for ArduCounter.hex in the FHEM/firmware subdirectory.
:This attribute contains avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] by default.
:For an Arduino Nano based counter you should add -b 57600 e.g. between the -P and -D options.
:Example: attr myCounter flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]

;keepAliveDelay
:defines an interval in which the module sends keepalive messages to a counter device that is conected via tcp.
:This attribute is ignored if the device is connected via serial port.
:If the device doesn't reply within a defined timeout then the module closes and tries to reopen the connection.
:The module tells the device when to expect the next keepalive message and the device will also close the tcp connection if it doesn't see a :keepalive message within the delay multiplied by 3
:The delay defaults to 10 seconds.
:Example: attr myCounter keepAliveDelay 30

;keepAliveTimeout
:defines the timeout when wainting for a keealive reply (see keepAliveDelay) The timeout defaults to 2 seconds.
:Example: attr myCounter keepAliveTimeout 3

;keepAliveRetries
:defines how often sending a keepalive is retried before the connection is closed and reopened.
:It defaults to 2.
:Example: attr myCounter keepAliveRetries 3

;nextOpenDelay
:defines the time that the module waits before retrying to open a disconnected tcp connection.
:This defaults to 60 seconds.
:Example: attr myCounter nextOpenDelay 20

;openTimeout
:defines the timeout after which tcp open gives up trying to establish a connection to the counter device. This timeout defaults to 3 seconds.
:Example: attr myCounter openTimeout 5

;silentReconnect
:if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3
:Example: attr myCounter silentReconnect 1

;disable
:if set to 1 then the module closes the connection to a counter device.

[[Kategorie:Other Components]]
[[Kategorie:Energieverbrauchsmessung]]

ArduCounter

2020-01-01T22:53:40Z

Maista:

{{Infobox Modul
|ModPurpose=Count pulses, calculate time between pulses and convert this to readings for e.g. power consumption of Energy meters
|ModType=contrib
|ModCmdRef=ArduCounter
|ModForumArea=Sonstiges
|ModFTopic=19285
|ModTechName=98_ArduCounter.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
This module implements an Interface to an Arduino or ESP8266 based counter for pulses on any input pin of an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device. The device connects to FHEM either through USB / serial or via tcp if an ESP board is used.

The typical use case is an S0-Interface on an energy meter or water meter, but also reflection light barriers to monitor old ferraris counters are supported

Counters are configured with attributes that define which Arduino pins should count pulses and in which intervals the Arduino board should report the current counts.

The Arduino sketch that works with this module uses pin change interrupts so it can efficiently count pulses on all available input pins.
The module creates readings for pulse counts, consumption and optionally also a pin history with pulse lengths and gaps of the last pulses.

== Availability ==
The module has been checked in to the FHEM svn.
The corresponding arduino sketch can also be found under contrib in the subdirectory arduino/.

== Prerequisites ==
This module requires an Arduino Uno, Nano, Jeenode, NodeMCU, Wemos D1 or similar device based on an Atmel 328p or ESP8266 running the ArduCounter sketch provided with this module

In order to flash an arduino board with the corresponding ArduCounter firmware from within Fhem, avrdude needs to be installed.

For old ferraris counters an Arduino Uno or Nano or ESP8266 board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line.

This module also requires Device::SerialPort or Win32::SerialPort for communication via serial lines

== Define ==

<pre>define <name> ArduCounter <device></pre>
or
<pre>define <name> ArduCounter <ip:port></pre>

<device> specifies the serial port to communicate with the Arduino.

<ip:port> specifies the ip address and tcp port to communicate with an esp8266 where port is typically 80.

The name of the serial-device depends on your distribution. You can also specify a baudrate for serial connections if the device name contains the @ character, e.g.: /dev/ttyUSB0@38400. The default baudrate of the ArduCounter firmware is 38400 since Version 1.4

Examples:
<pre>
define AC ArduCounter /dev/ttyUSB2@38400
define AC ArduCounter 192.168.1.134:80
</pre>

== Configuration of ArduCounter digital counters ==

Specify the pins where impulses should be counted e.g. as attr AC pinX falling pullup 30

The X in pinX can be an Arduino / ESP pin number with or without the letter D e.g. pin4, pinD5, pin6, pinD7 ...

After the pin you can use the keywords falling or rising to define if a logical one / 5V (rising) or a logical zero / 0V (falling) should be treated as pulse.

The optional keyword pullup activates the pullup resistor for the given Pin.

The last argument is also optional but recommended and specifies a minimal pulse length in milliseconds.

An energy meter with S0 interface is typically connected to GND and an input pin like D4.
The S0 pulse then pulls the input to 0V.
Since the minimal pulse lenght of the s0 interface is specified to be 30ms, the typical configuration for an s0 interface is
attr AC pinX falling pullup 30

Specifying a minimal pulse length is recommended since it filters bouncing of reed contacts or other noise.

Example:
<pre>
define AC ArduCounter /dev/ttyUSB2
attr AC pulsesPerKWh 1000
attr AC interval 60 300
attr AC pinD4 falling pullup 5
attr AC pinD5 falling pullup 30
attr AC verboseReadingsD5
attr AC pinD6 rising
</pre>

This defines three counters connected to the pins D4, D5 and D5.
D4 and D5 have their pullup resistors activated and the impulse draws the pins to zero.
For D4 and D5 the arduino measures the time in milliseconds between the falling edge and the rising edge. If this time is longer than the specified 5 or 30 milliseconds then the impulse is counted.
If the time is shorter then this impulse is regarded as noise and added to a separate reject counter.

verboseReadings5 causes the module to create additional readings like the pin history which shows length and gaps between the last pulses.

For pin D6 the arduino does not check pulse lengths and counts every time when the signal changes from 0 to 1.

The ArduCounter sketch which must be loaded on the Arduino or ESP implements this using pin change interrupts, so all avilable input pins can be used, not only the ones that support normal interrupts.
The module has been tested with 14 inputs of an Arduino Uno counting in parallel and pulses as short as 3 milliseconds.

== Configuration of ArduCounter analog counters ==

This module and the corresponding sketch can be used to read out old analog ferraris energy counters. Therefore an ESP, Arduino Uno or Nano board needs to be connected to a reflection light barrier which consists simply of an infra red photo transistor (connected to A7 on Arduinos and A0 on ESP8266) and an infra red led (connected to D2 on Arduinos and to D6 on ESP8266), both with a resistor in line. The idea comes from Martin Kompf (https://www.kompf.de/tech/emeir.html) and has been adopted for ArduCounter to support old ferraris energy counters.

To support this mode, the sketch has to be compiled with analogIR defined.

The configuration is then similar to the one for digital counters:

<pre>
define ACF ArduCounter /dev/ttyUSB4
attr ACF analogThresholds 100 110
attr ACF flashCommand avrdude -p atmega328P -b57600 -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr ACF interval 60 300 2 2
attr ACF pinA7 rising 20
attr ACF pulsesPerKWh 75
attr ACF stateFormat {sprintf("%.3f kW", ReadingsVal($name,"powerA7",0))}
</pre>

To find out the right analog thresholds you can set devVerbose to 20 which will ask the firmware of your conting board to report every analog measurement. The ArduCounter module will count how often each value is reported and you can then query these analog level counts with get levels. After a few turns of the ferraris disc the result of get levels might look like this:

<pre>
observed levels from analog input:
94: 21
95: 79
96: 6
97: 2
98: 3
99: 2
100: 2
101: 1
102: 3
105: 2
106: 1
108: 2
109: 1
110: 1
112: 1
113: 3
115: 4
116: 9
117: 14
118: 71
119: 103
120: 118
121: 155
122: 159
123: 143
124: 147
125: 158
126: 198
127: 249
128: 220
129: 230
130: 201
131: 140
132: 147
133: 153
134: 141
135: 119
136: 105
137: 109
138: 114
139: 83
140: 33
141: 14
142: 1
</pre>

This shows the measured values together with the frequency how often the individual value has been measured. It is obvious that most measurements result in values between 120 and 135, very few values are betweem 96 and 115 and another peak is around the value 95.
It means that the when the red mark of the ferraris disc is under the sensor, the value is around 95 and while the blank disc is under the sensor, the value is typically between 120 and 135. So a good upper threshold would be 120 and a good lower threshold would be for example 96.

== Get-Commands ==
;info
:send a command to the Arduino board to get current counts.
:This is not needed for normal operation but might be useful sometimes for debugging.

;levels
:show the count for the measured levels if an analog pin is used to measure e.g. the red mark of a ferraris counter disc.
:This is useful for setting the thresholds for analog measurements.

;history
:shows details regarding all the level changes that the counter device (Arduino or ESP) has detected
:and how they were used (counted or rejected)
:If get history is issued with a pin name (e.g. get history D5) then only the history entries concerning D5 will be shown.
:This information is sent from the device to Fhem when it reports the current count but only if devVerbose is equal or greater than 5.
:The maximum number of lines that the Arducounter module stores in a ring buffer is defined by the attribute maxHist and defaults to 1000.

== Set-Commands ==

;raw
:send the value to the board so you can directly talk to the sketch using its commands.
:This is not needed for normal operation but might be useful sometimes for debugging

;flash
:flashes the ArduCounter firmware ArduCounter.hex from the fhem subdirectory FHEM/firmware onto the device.
:This command needs avrdude to be installed. The attribute flashCommand specidies how avrdude is called.
:If it is not modifed then the module sets it to avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
:This setting should work for a standard installation and the placeholders are automatically replaced when the command is used.
:So normally there is no need to modify this attribute.
:Depending on your specific Arduino board however, you might need to insert -b 57600 in the flash Command.
:(e.g. for an Arduino Nano) ESP boards so far have to be fashed from the Arduino IDE. In a future version flashing over the air sould be supported.

;reset
:reopens the arduino device and sends a command to it which causes a reinitialize and reset of the counters. Then the module resends the attribute configuration / definition of the pins to the device.

;saveConfig
:stores the current interval, analog threshold and pin configuration to be stored in the EEPROM of the counter device
:so it can be retrieved after a reset.

;enable
:sets the attribute disable to 0

;disable
:sets the attribute disable to 1

;reconnect
:closes the tcp connection to an ESP based counter board that is conected via TCP/IP and reopen the connection

== Supported readings ==
The module creates at least the following readings and events for each defined pin:

;pin.* e.g. pinD4
:the current internal count at this pin (internal to the Arduino / ESP device, starts at 0 when the device restarts).
:The name of this reading can be changed with the attribute readingNameCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;long.* e.g. longD5
:long count which keeps on counting up after fhem restarts whereas the pin.* count is only a temporary internal count that starts at 0 when the arduino board starts.
:The name of this reading can be changed with the attribute readingNameLongCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;interpolatedLong.*
:like long.* but when the Arduino restarts the potentially missed pulses are interpolated based on the pulse rate before the restart and after the restart.
:The name of this reading can be changed with the attribute readingNameInterpolatedCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;calcCounter.*
:similar to long count which keeps on counting up after fhem restarts but this counter will take the pulses per kWh setting into the :calculation und thus not count pulses but real kWh (or some other unit that is applicable)
:The name of this reading can be changed with the attribute readingNameCalcCount[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;reject.*
:counts rejected pulses that are shorter than the specified minimal pulse length.

;power.*
:the current calculated power at this pin.
:The name of this reading can be changed with the attribute readingNamePower[AD]?[0-9]+ where [AD]?[0-9]+ stands for the pin description e.g. D4

;pinHistory.*
:shows detailed information of the last pulses. This is only available when a minimal pulse length is specified for this pin. Also the total number of impulses recorded here is limited to 20 for all pins together. The output looks like -36/7:0C, -29/7:1G, -22/8:0C, -14/7:1G, -7/7:0C, 0/7:1G
:The first number is the relative time in milliseconds when the input level changed, followed by the length in milliseconds, the level and the internal action. -36/7:0C for example means that 36 milliseconds before the reporting started, the input changed to 0V, stayed there for 7 milliseconds and this was counted.

;countDiff.*
:delta of the current count to the last reported one. This is used together with timeDiff.* to calculate the power consumption.

;timeDiff.*
:time difference between the first pulse in the current observation interval and the last one. Used togehter with countDiff to calculate the power consumption.

;seq.*
:internal sequence number of the last report from the board to Fhem.

== Attributes ==

;do_not_notify
: ...

;pin.*
:Define a pin of the Arduino board as input. This attribute expects either <code>rising</code>, <code>falling</code> or <code>change</code>, followed by an optional <code>pullup</code> and an optional number as value.
:If a number is specified, the arduino will track rising and falling edges of each impulse and measure the length of a pulse in milliseconds.
:The number specified here is the minimal length of a pulse and a pause before a pulse. If one is too small, the pulse is not counted but added to a separate reject counter.

;interval normal max min mincout
:Defines the parameters that affect the way counting and reporting works.
:This Attribute expects at least two and a maximum of four numbers as value.
: The first is the normal interval, the second the maximal interval, the third is a minimal interval and the fourth is a minimal pulse count.

:In the usual operation mode (when the normal interval is smaller than the maximum interval), the Arduino board just counts and remembers the time between the first impulse and the last impulse for each pin.
:After the normal interval is elapsed the Arduino board reports the count and time for those pins where impulses were encountered.
:This means that even though the normal interval might be 10 seconds, the reported time difference can be something different because it observed impulses as starting and ending point.
:The Power (e.g. for energy meters) is the calculated based of the counted impulses and the time between the first and the last impulse.
:For the next interval, the starting time will be the time of the last impulse in the previous reporting period and the time difference will be taken up to the last impulse before the reporting interval has elapsed.

:The second, third and fourth numbers (maximum, minimal interval and minimal count) exist for the special case when the pulse frequency is very low and the reporting time is comparatively short.
:For example if the normal interval (first number) is 60 seconds and the device counts only one impulse in 90 seconds, the the calculated power reading will jump up and down and will give ugly numbers.
:By adjusting the other numbers of this attribute this can be avoided.
:In case in the normal interval the observed impulses are encountered in a time difference that is smaller than the third number (minimal interval) or if the number of impulses counted is smaller than the fourth number (minimal count) then the reporting is delayed until the maximum interval has elapsed or the above conditions have changed after another normal interval.
:This way the counter will report a higher number of pulses counted and a larger time difference back to fhem.

:If this is seems too complicated and you prefer a simple and constant reporting interval, then you can set the normal interval and the mximum interval to the same number. This changes the operation mode of the counter to just count during this normal and maximum interval and report the count. In this case the reported time difference is always the reporting interval and not the measured time between the real impulses.

;factor
:Define a multiplicator for calculating the power from the impulse count and the time between the first and the last impulse.
:This attribute is outdated and unintuitive so you should avoid it.
:Instead you should specify the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;readingFactor[0-9]+
:Override the factor attribute for this individual pin.
:Just like the attribute factor, this is a rather cumbersome way to specify the pulses per kWh.
:Instaed it is advised to use the attribute pulsesPerKWh or readingPulsesPerKWh[0-9]+ (where [0-9]+ stands for the pin number).

;pulsesPerKWh
:specify the number of pulses that the meter is giving out per unit that sould be displayed (e.g. per kWh energy consumed). For many S0 counters this is 1000, for old ferraris counters this is 75 (rounds per kWh).
:Example: attr myCounter pulsesPerKWh 75

;readingPulsesPerKWh[0-9]+
:is the same as pulsesPerKWh but specified per pin individually in case you have multiple counters with different settings at the same time
:Example:
:attr myCounter readingPulsesPerKWhA7 75
:attr myCounter readingPulsesPerKWhD4 1000

;readingNameCount[0-9]+
:Change the name of the counter reading pinX to something more meaningful.

;readingNameLongCount[0-9]+
:Change the name of the counter reading longX to something more meaningful.

;readingNameInterpolatedCount[0-9]+
:Change the name of the counter reading InterpolatedLongX to something more meaningful.

;readingNameCalcCount[AD]?[0-9]+
:Change the name of the real unit counter reading CalcCounterX to something more meaningful.
:Example: attr myCounter readingNameCalcCountD4 CounterHaus_kWh

;readingNamePower[0-9]+
:Change the name of the power reading powerX to something more meaningful.

;readingStartTime[0-9]+
:Allow the reading time stamp to be set to the beginning of measuring intervals

;verboseReadings[0-9]+
:create additional readings: timeDiff, countDiff and lastMsg for each pin

;devVerbose
:set the verbose level in the counting board. This defaults to 0.
:If the value is >0, then the firmware will echo all commands sent to it by the Fhem module.
:If the value is >=5, then the firmware will report the pin history (assuming that the firmware has been compiled with this feature enabled)
:If the value is >=10, then the firmware will report every level change of a pin
:If the value is >=20, then the firmware will report every analog measurement (assuming that the firmware has been compiled with analog measurements for old ferraris counters or similar).

;maxHist
:specifies how many pin history lines hould be buffered for "get history".
:This attribute defaults to 1000.

;analogThresholds
:this Attribute is necessary when you use an arduino nano with connected reflection light barrier (photo transistor and led) to detect the red mark of an old ferraris energy counter. In this case the firmware uses an upper and lower threshold which can be set here.
:Example: attr myCounter analogThresholds 90 110
:In order to find out the right threshold values you can set devVerbose to 20, wait for several turns of the ferraris disc and then use get levels to see the typical measurements for the red mark and the blank disc.

;flashCommand
:sets the command to call avrdude and flash the onnected arduino with an updated hex file (by default it looks for ArduCounter.hex in the FHEM/firmware subdirectory.
:This attribute contains avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] by default.
:For an Arduino Nano based counter you should add -b 57600 e.g. between the -P and -D options.
:Example: attr myCounter flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]

;keepAliveDelay
:defines an interval in which the module sends keepalive messages to a counter device that is conected via tcp.
:This attribute is ignored if the device is connected via serial port.
:If the device doesn't reply within a defined timeout then the module closes and tries to reopen the connection.
:The module tells the device when to expect the next keepalive message and the device will also close the tcp connection if it doesn't see a :keepalive message within the delay multiplied by 3
:The delay defaults to 10 seconds.
:Example: attr myCounter keepAliveDelay 30

;keepAliveTimeout
:defines the timeout when wainting for a keealive reply (see keepAliveDelay) The timeout defaults to 2 seconds.
:Example: attr myCounter keepAliveTimeout 3

;keepAliveRetries
:defines how often sending a keepalive is retried before the connection is closed and reopened.
:It defaults to 2.
:Example: attr myCounter keepAliveRetries 3

;nextOpenDelay
:defines the time that the module waits before retrying to open a disconnected tcp connection.
:This defaults to 60 seconds.
:Example: attr myCounter nextOpenDelay 20

;openTimeout
:defines the timeout after which tcp open gives up trying to establish a connection to the counter device. This timeout defaults to 3 seconds.
:Example: attr myCounter openTimeout 5

;silentReconnect
:if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3
:Example: attr myCounter silentReconnect 1

;disable
:if set to 1 then the module closes the connection to a counter device.

[[Kategorie:Other Components]]
[[Kategorie:Energieverbrauchsmessung]]

Template

2019-12-01T18:41:26Z

Maista:

{{SEITENTITEL:template}}
{{Infobox Modul
|ModPurpose=Einfaches Erstellen gleichartiger Devices
|ModType=cmd
|ModCmdRef=template
|ModForumArea=Sonstiges
|ModTechName=98_template.pm
|ModOwner=Dr. Boris Neubert ({{Link2FU|10| Forum}})
}}
Der [[template]]-Befehl vereinfacht das Erstellen gleichartiger Devices in FHEM. Ein Template-File besteht im Grunde aus FHEM Befehlen, in die Platzhalter eingefügt werden. Beim Aufruf des Template-Befehles werden die Platzhalter durch konkrete Werte ersetzt. Damit lassen sich sehr schnell ähnliche Devices (oder Kombinationen von Devices) erstellen oder ändern. Ein Template-File könnte z.B. die Definition eines Dummies inkl. mehrerer sich auf den Dummy beziehenden [[notify]] und [[at]] enthalten. Durch wiederholte Ausführung des Templates lassen sich so schnell Devices und ihre Verarbeitungslogik erstellen.

== Template-File erstellen ==
Template-Files werden außerhalb FHEM erstellt und dann auf dem FHEM Server (in einem Unterverzeichnis von FHEM) abgelegt. Nutzer von [[configdb]] müssen das File zunächst importieren.

Derzeit (März 2017) können Template-Files noch nicht über "Edit Files" in FHEM direkt bearbeitet werden. Über einen Workaround ist dies jedoch möglich. Dateien, die in /FHEM abgelegt sind und Endungen wie z.B. .holiday oder .layout haben, werden unter "Edit Files" angezeigt und können in FHEM bearbeitet werden.
Das Template File kann mittels
:<code>template show <templateFile></code>
angezeigt werden

== Template-File mit Inhalt füllen ==
Das Template besteht aus FHEM Befehlen mit Platzhaltern, die bei der Ausführung des Template-Befehls durch konkrete Werte ersetzt werden. Ein Template könnte beispielsweise folgendermaßen definiert werden.
<pre>
# my Template File ./FHEM/tmpl_example.layout
define %name% dummy

define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always
</pre>

Im Gegensatz zur Kopie eines Devices mit [[copy]] ermöglicht der Template-Befehl die Definition mehrerer - von einander abhängiger - Geräte "in einem Rutsch". Oben stehendes Beispiel ist bewusst einfach gehalten um diesen Aspekt zu verdeutlichen.

Für komplexere Templates bietet sich die [[Import_von_Code_Snippets|raw definition]] eines existierenden Gerätes als Ausgangspunkt an.

== Template ausführen ==
Bei Ausführung des Templates werden die FHEM Befehle des Template-Files abgearbeitet. In oben definiertem Beispiel würde also ein
:<code>template ./FHEM/tmpl_example.layout name=myDummy device=myDevice</code>
dazu führen, dass ein Dummy inkl. zugehörigem [[DOIF]] angelegt würde.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

Template

2019-12-01T18:41:11Z

Maista: /* Template File mit Inhalt füllen */

{{SEITENTITEL:template}}
{{Infobox Modul
|ModPurpose=Einfaches Erstellen gleichartiger Devices
|ModType=cmd
|ModCmdRef=template
|ModForumArea=Sonstiges
|ModTechName=98_template.pm
|ModOwner=Dr. Boris Neubert ({{Link2FU|10| Forum}})
}}
Der [[template]] Befehl vereinfacht das Erstellen gleichartiger Devices in FHEM. Ein Template-File besteht im Grunde aus FHEM Befehlen, in die Platzhalter eingefügt werden. Beim Aufruf des Template-Befehles werden die Platzhalter durch konkrete Werte ersetzt. Damit lassen sich sehr schnell ähnliche Devices (oder Kombinationen von Devices) erstellen oder ändern. Ein Template-File könnte z.B. die Definition eines Dummies inkl. mehrerer sich auf den Dummy beziehenden [[notify]] und [[at]] enthalten. Durch wiederholte Ausführung des Templates lassen sich so schnell Devices und ihre Verarbeitungslogik erstellen.

== Template-File erstellen ==
Template-Files werden außerhalb FHEM erstellt und dann auf dem FHEM Server (in einem Unterverzeichnis von FHEM) abgelegt. Nutzer von [[configdb]] müssen das File zunächst importieren.

Derzeit (März 2017) können Template-Files noch nicht über "Edit Files" in FHEM direkt bearbeitet werden. Über einen Workaround ist dies jedoch möglich. Dateien, die in /FHEM abgelegt sind und Endungen wie z.B. .holiday oder .layout haben, werden unter "Edit Files" angezeigt und können in FHEM bearbeitet werden.
Das Template File kann mittels
:<code>template show <templateFile></code>
angezeigt werden

== Template-File mit Inhalt füllen ==
Das Template besteht aus FHEM Befehlen mit Platzhaltern, die bei der Ausführung des Template-Befehls durch konkrete Werte ersetzt werden. Ein Template könnte beispielsweise folgendermaßen definiert werden.
<pre>
# my Template File ./FHEM/tmpl_example.layout
define %name% dummy

define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always
</pre>

Im Gegensatz zur Kopie eines Devices mit [[copy]] ermöglicht der Template-Befehl die Definition mehrerer - von einander abhängiger - Geräte "in einem Rutsch". Oben stehendes Beispiel ist bewusst einfach gehalten um diesen Aspekt zu verdeutlichen.

Für komplexere Templates bietet sich die [[Import_von_Code_Snippets|raw definition]] eines existierenden Gerätes als Ausgangspunkt an.

== Template ausführen ==
Bei Ausführung des Templates werden die FHEM Befehle des Template-Files abgearbeitet. In oben definiertem Beispiel würde also ein
:<code>template ./FHEM/tmpl_example.layout name=myDummy device=myDevice</code>
dazu führen, dass ein Dummy inkl. zugehörigem [[DOIF]] angelegt würde.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

Template

2019-12-01T18:38:25Z

Maista:

{{SEITENTITEL:template}}
{{Infobox Modul
|ModPurpose=Einfaches Erstellen gleichartiger Devices
|ModType=cmd
|ModCmdRef=template
|ModForumArea=Sonstiges
|ModTechName=98_template.pm
|ModOwner=Dr. Boris Neubert ({{Link2FU|10| Forum}})
}}
Der [[template]] Befehl vereinfacht das Erstellen gleichartiger Devices in FHEM. Ein Template-File besteht im Grunde aus FHEM Befehlen, in die Platzhalter eingefügt werden. Beim Aufruf des Template-Befehles werden die Platzhalter durch konkrete Werte ersetzt. Damit lassen sich sehr schnell ähnliche Devices (oder Kombinationen von Devices) erstellen oder ändern. Ein Template-File könnte z.B. die Definition eines Dummies inkl. mehrerer sich auf den Dummy beziehenden [[notify]] und [[at]] enthalten. Durch wiederholte Ausführung des Templates lassen sich so schnell Devices und ihre Verarbeitungslogik erstellen.

== Template-File erstellen ==
Template-Files werden außerhalb FHEM erstellt und dann auf dem FHEM Server (in einem Unterverzeichnis von FHEM) abgelegt. Nutzer von [[configdb]] müssen das File zunächst importieren.

Derzeit (März 2017) können Template-Files noch nicht über "Edit Files" in FHEM direkt bearbeitet werden. Über einen Workaround ist dies jedoch möglich. Dateien, die in /FHEM abgelegt sind und Endungen wie z.B. .holiday oder .layout haben, werden unter "Edit Files" angezeigt und können in FHEM bearbeitet werden.
Das Template File kann mittels
:<code>template show <templateFile></code>
angezeigt werden

== Template File mit Inhalt füllen ==
Das Template besteht aus FHEM Befehlen mit Platzhaltern, die bei der Ausführung des Template-Befehls durch konkrete Werte ersetzt werden. Ein Template könnte beispielsweise folgendermaßen definiert werden.
<pre>
# my Template File ./FHEM/tmpl_example.layout
define %name% dummy

define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always
</pre>

Im Gegensatz zur Kopie eines Devices mit [[copy]] ermöglicht der Template-Befehl die Definition mehrerer - von einander abhängiger - Geräte "in einem Rutsch". Oben stehendes Beispiel ist bewusst einfach gehalten um diesen Aspekt zu verdeutlichen.

Für komplexere Templates bietet sich die [[Import_von_Code_Snippets|raw definition]] eines existierenden Gerätes als Ausgangspunkt an.

== Template ausführen ==
Bei Ausführung des Templates werden die FHEM Befehle des Template-Files abgearbeitet. In oben definiertem Beispiel würde also ein
:<code>template ./FHEM/tmpl_example.layout name=myDummy device=myDevice</code>
dazu führen, dass ein Dummy inkl. zugehörigem [[DOIF]] angelegt würde.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

Template

2019-12-01T18:37:34Z

Maista: /* Template File erstellen */

{{SEITENTITEL:template}}
{{Infobox Modul
|ModPurpose=Einfaches Erstellen gleichartiger Devices
|ModType=cmd
|ModCmdRef=template
|ModForumArea=Sonstiges
|ModTechName=98_template.pm
|ModOwner=Dr. Boris Neubert ({{Link2FU|10| Forum}})
}}
Der [[template]] Befehl vereinfacht das Erstellen gleichartiger Devices in FHEM. Ein Template File besteht im Grunde aus FHEM Befehlen, in die Platzhalter eingefügt werden. Beim Aufruf des Template-Befehles werden die Platzhalter durch konkrete Werte ersetzt. Damit lassen sich sehr schnell ähnliche Devices (oder Kombinationen von Devices) erstellen oder ändern. Ein Template File könnte z.B. die Definition eines Dummies inkl. mehrerer sich auf den Dummy beziehenden [[notify]] und [[at]] enthalten. Durch wiederholte Ausführung des Templates lassen sich so schnell Devices und ihre Verarbeitungslogik erstellen.

== Template-File erstellen ==
Template-Files werden außerhalb FHEM erstellt und dann auf dem FHEM Server (in einem Unterverzeichnis von FHEM) abgelegt. Nutzer von [[configdb]] müssen das File zunächst importieren.

Derzeit (März 2017) können Template-Files noch nicht über "Edit Files" in FHEM direkt bearbeitet werden. Über einen Workaround ist dies jedoch möglich. Dateien, die in /FHEM abgelegt sind und Endungen wie z.B. .holiday oder .layout haben, werden unter "Edit Files" angezeigt und können in FHEM bearbeitet werden.
Das Template File kann mittels
:<code>template show <templateFile></code>
angezeigt werden

== Template File mit Inhalt füllen ==
Das Template besteht aus FHEM Befehlen mit Platzhaltern, die bei der Ausführung des Template-Befehls durch konkrete Werte ersetzt werden. Ein Template könnte beispielsweise folgendermaßen definiert werden.
<pre>
# my Template File ./FHEM/tmpl_example.layout
define %name% dummy

define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always
</pre>

Im Gegensatz zur Kopie eines Devices mit [[copy]] ermöglicht der Template-Befehl die Definition mehrerer - von einander abhängiger - Geräte "in einem Rutsch". Oben stehendes Beispiel ist bewusst einfach gehalten um diesen Aspekt zu verdeutlichen.

Für komplexere Templates bietet sich die [[Import_von_Code_Snippets|raw definition]] eines existierenden Gerätes als Ausgangspunkt an.

== Template ausführen ==
Bei Ausführung des Templates werden die FHEM Befehle des Template-Files abgearbeitet. In oben definiertem Beispiel würde also ein
:<code>template ./FHEM/tmpl_example.layout name=myDummy device=myDevice</code>
dazu führen, dass ein Dummy inkl. zugehörigem [[DOIF]] angelegt würde.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

Template

2019-12-01T18:37:12Z

Maista:

{{SEITENTITEL:template}}
{{Infobox Modul
|ModPurpose=Einfaches Erstellen gleichartiger Devices
|ModType=cmd
|ModCmdRef=template
|ModForumArea=Sonstiges
|ModTechName=98_template.pm
|ModOwner=Dr. Boris Neubert ({{Link2FU|10| Forum}})
}}
Der [[template]] Befehl vereinfacht das Erstellen gleichartiger Devices in FHEM. Ein Template File besteht im Grunde aus FHEM Befehlen, in die Platzhalter eingefügt werden. Beim Aufruf des Template-Befehles werden die Platzhalter durch konkrete Werte ersetzt. Damit lassen sich sehr schnell ähnliche Devices (oder Kombinationen von Devices) erstellen oder ändern. Ein Template File könnte z.B. die Definition eines Dummies inkl. mehrerer sich auf den Dummy beziehenden [[notify]] und [[at]] enthalten. Durch wiederholte Ausführung des Templates lassen sich so schnell Devices und ihre Verarbeitungslogik erstellen.

== Template File erstellen ==
Template Files werden außerhalb FHEM erstellt und dann auf dem FHEM Server (in einem Unterverzeichnis von FHEM) abgelegt. Nutzer von [[configdb]] müssen das File zunächst importieren.

Derzeit (März 2017) können Template-Files noch nicht über "Edit Files" in FHEM direkt bearbeitet werden. Über einen Workaround ist dies jedoch möglich. Dateien, die in /FHEM abgelegt sind und Endungen wie z.B. .holiday oder .layout haben, werden unter "Edit Files" angezeigt und können in FHEM bearbeitet werden.
Das Template File kann mittels
:<code>template show <templateFile></code>
angezeigt werden

== Template File mit Inhalt füllen ==
Das Template besteht aus FHEM Befehlen mit Platzhaltern, die bei der Ausführung des Template-Befehls durch konkrete Werte ersetzt werden. Ein Template könnte beispielsweise folgendermaßen definiert werden.
<pre>
# my Template File ./FHEM/tmpl_example.layout
define %name% dummy

define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always
</pre>

Im Gegensatz zur Kopie eines Devices mit [[copy]] ermöglicht der Template-Befehl die Definition mehrerer - von einander abhängiger - Geräte "in einem Rutsch". Oben stehendes Beispiel ist bewusst einfach gehalten um diesen Aspekt zu verdeutlichen.

Für komplexere Templates bietet sich die [[Import_von_Code_Snippets|raw definition]] eines existierenden Gerätes als Ausgangspunkt an.

== Template ausführen ==
Bei Ausführung des Templates werden die FHEM Befehle des Template-Files abgearbeitet. In oben definiertem Beispiel würde also ein
:<code>template ./FHEM/tmpl_example.layout name=myDummy device=myDevice</code>
dazu führen, dass ein Dummy inkl. zugehörigem [[DOIF]] angelegt würde.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

ESPEasy

2019-11-08T22:59:43Z

Maista: /* userSetCmds */

{{Infobox Modul
|ModPurpose=Steuerung eines Espressif ESP8266 WLAN-SoC
|ModType=d
|ModCmdRef=
|ModForumArea=Bastelecke/ESP8266
|ModFTopic=55728
|ModTechName=34_ESPEasy.pm
|ModOwner={{Link2FU|7465|dev0}}
}}
Dieser Wiki-Artikel soll und kann die {{Link2CmdRef|Anker=ESPEasy|Lang=en|Label=ESPEasy Modul-Dokumentation}}(aka FHEM Command Reference) nicht ersetzen, sondern ergänzt die Dokumentation nur um ein paar Informationen.

== Grundlegende ESP Easy Einstellungen ==

Diese Einstellungen sind in der Weboberfläche des ESP vorzunehmen und bewirken u.a., dass für jedes ESPEasy-Device ein FHEM Device angelegt wird. Das kann bspw. für einen ESP sinnvoll sein, der Relays über GPIOs schalten soll (ESPEasy Device-Type ''Switch Input'').

*Es muss ein einmaliger ESP Devicename vergeben werden (''Config'' -> ''Main Settings'' ->''Name'')
*Die verwendeten ESP Easy Devices sollten einen ESP-weit einmaligen Namen erhalten (''Device'' -> ''Edit'' -> ''Task Settings'' -> ''Name''). Ist dieser Name nicht eindeutig oder wird nicht vergeben, dann gibt es u.a. Probleme mit ESP Easy Rules [link].
*Jeder Wert, der gesendet werden soll, benötigt ebenfalls einen Namen, der in diesem ESP Device einmalig sein muss (''Device'' -> ''Edit'' -> ''Optional Settings'' -> ''Value Name'')
*Soll dieser Wert nun automatisch in einem Interval von x Sekunden (an FHEM) gesendet werden, dann muss noch das ''Delay'' (''Device'' -> ''Edit'' -> ''Task Settings'' -> ''Delay'') angegeben und die Option ''Send Data'' (''Device'' -> ''Edit'' -> ''Task Settings'' -> ''Send Data'') aktiviert werden. Die Option ''Send Boot State'' ist an dieser Stelle ebenfalls sinnvoll.

=== Attribut combineDevices ===

Wenn das oben genannte Verhalten (ein FHEM Device pro ESP Easy Device) nicht gewünscht ist, dann kann man mittels des Attributes ''combineDevices'' der {{Link2CmdRef|Anker=ESPEasy_bridge_define|Lang=en|Label=ESPEasy Bridge}} einstellen, ob die ESP Easy Devices eines einzelnen ESPs in ein FHEM Device zusammengeführt werden sollen.
Diese Funktionalität kann man global einschalten, indem man dem Attribut ''combineDevices'' den Wert ''1'' gibt.

Will man nur von bestimmten ESPs die Devices zusammen fassen, dann kann man eine komma-getrennte Liste der ESPs angeben. Die Liste kann aus ESP Namen, IP Adressen und/oder Netzwerkbereichen bestehen. Netzwerkbereiche können mit einer Netzmaske in dotted decimal (/255.255.255.0) oder in bitmask (/24) Schreibweise angegeben werden. Hostnamen und FQDNs werden nicht unterstützt.

Beispiele:
attr <esp> combineDevices ESP1,ESP2
attr <esp> combineDevices 10.0.0.148,10.0.0.149
attr <esp> combineDevices 192.168.124.0/24
attr <esp> combineDevices 192.168.124.0/255.255.255.0
attr <esp> combineDevices ESP1,ESP2,10.0.0.0/8,192.168.0.0/255.255.0.0

IPv6 Adressen/Bereiche werden zwar von FHEM, allerdings zur Zeit noch nicht von der öffentlichen ESP Easy Distribution unterstützt.

Beispiel:
attr <esp> combineDevices 2001:1a50:50a8::148,2001:abcd:efff::/48

== Presence Erkennung ==
Die "Presence Detection", also die Erkennung, ob ein ESP noch Daten sendet, wurde anhand des Alters der empfangenen (Sensor-)Werte realisiert. Vereinfacht gesagt: Werden keine Readings mehr innerhalb von x Sekunden empfangen (siehe Device-Attribut ''Interval''), wird das FHEM Device als "absent" gekennzeichnet. Das hat den Vorteil, dass auch ESP Easy Devices, die zwischen dem Senden von Daten in den so genannten Deep Sleep Modus gehen, erkannt werden können.

Das Attribut ''Interval'' gibt unter anderem vor, in welchem zeitlichen Abstand Werte vom ESP erwartet werden, damit der ESP als "present" (und nicht absent) markiert wird.

Wenn ein ESP Easy Device Werte alle 60 Sekunden sendet (Option ''Delay'' in der ESP Easy Device GUI) und das FHEM Device Interval auf 60 gesetzt ist, dann würde das Device-Reading "presence" auf "absent" wechseln, wenn innerhalb von 60-120 Sekunden keine Werte empfangen werden.

Also wäre zum Beispiel die ESP Easy Firmware so zu konfigurieren, dass mindestens ein Wert alle 60 Sekunden gesendet wird. Das Interval-Attribut des entsprechenden FHEM ESPEasy Device müsste ebenfalls auf 60 (default) gesetzt werden. Ein paar Sekunden Toleranz sind im ESPEasy Modul eingebaut.

Wenn man kein ESP Easy Device hat, das Daten an FHEM sendet, dann kann man zusätzlich einen der "System Info" Werte senden lassen und ''combineDevices'' für diesen ESP aktivieren. Es reicht nämlich, wenn ein Reading regelmäßig aktualisiert wird.

Wenn die Presence Erkennung nicht genutzt werden soll, dann muss das Attribut ''presenceCheck'' auf 0 gesetzt werden.

== Sicherheit ==

Wenn eine ESPEasy Bridge in FHEM eingerichtet wurde, dann werden Verbindungen nur von IP Adressen aus [https://tools.ietf.org/html/rfc1918 privaten Bereichen] zugelassen.

Wenn ESP Easy Geräte außerhalb dieser Bereiche Daten an FHEM senden (z.B. über das Internet), dann muss das in der ESPEasy Bridge konfiguriert werden, andernfalls wird die Verbindung abgewiesen.

Einerseits muss die IP Adresse bzw. der IP Bereich erlaubt (Attribute ''allowedIPs'', ''deniedIPs''), andererseits die Authentifizierung über "Basic Auth" in der ESPEasy Bridge eingerichtet werden.
Die Authentifizierung wird über das Attribut ''authentication'' eingeschaltet. Die Benutzerdaten für die Authentifizierung werden über die Set-Befehle ''user'' und ''pass'' der Bridge eingegeben
{{Hinweis|Hinweis: Username und Passwort werden unverschlüsselt in ./FHEM/FhemUtils/uniqueID gespeichert.}}

=== Attribut authentication ===
Beispiel:
set <espbridge> user MeinUserName
set <espbridge> pass sehrgeheim
attr <espbridge> authentication 1

=== Attribute allowedIPs / deniedIPs ===
Beispiel:
attr <espbridge> allowedIPs 192.0.2.0/24 # erlaubt ist 192.0.2.0 bis 192.0.2.255
attr <espbridge> deniedIPs 192.0.2.0/29 # ausgeschlossen werden aber die IPs von 192.0.2.0 bis 192.0.2.7

Das Attribut ''deniedIPs'' hat Vorrang vor ''allowedIPs''. Das bedeutet, dass verbotene IPs niemals eine Verbindung aufbauen können, auch wenn sie vorher erlaubt wurden.

Regular Expressions sind können ebenfalls verwendet werden:
attr <espbridge> allowedIPs 192.0.2.1([0-4][0-9]|50) # erlaubt IP von 192.168.30.100 bis 192.168.30.150

Alle Details dazu sind in der {{Link2CmdRef|Anker=ESPEasy_bridge_attr_allowedips|Lang=en|Label=Command Reference}} beschrieben.

== Erweiterte Beispiele==
Hier ein paar Beispiele für unterschiedlichste Anwendungsfälle

=== Schalter in FHEMWEB mit devStateIcons ===
Beispiel für GPIO 12:
attr <ESP> stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIO12","")}
attr <ESP> devStateIcon on:ios-on-green:off off:ios-off:on absent:10px-kreis-rot:statusRequest
attr <ESP> eventMap /gpio 12 on:on/gpio 12 off:off/
attr <ESP> webCmd :

=== on-for-timer und off-for-timer ===
Beispiel für GPIO 15:
attr <ESP> /longpulse 15 on:on-for-time:slider,0,1,60/longpulse 15 off:off-for-time:slider,0,1,60/

=== (on|off)-for-timer und devStateIcons ===
Beispiel für GPIO 15:
attr <ESP> eventMap /longpulse 15 on:on-for-time:slider,0,1,60/longpulse 15 off:off-for-time:slider,0,1,60/gpio 15 on:on/gpio 15 off:off/

=== userSetCmds ===
Mithilfe des Attributes userSetCmds kann man:
*Einzelne ESP Easy Befehle nachrüsten
*Eigene oder nicht unterstützte Plugins integrieren
*Bereits integrierte Befehle verändern
*Befehle einzelner Plugins mappen: Statt 'set <dev> plugin_a on' kann man so 'set <dev> on' verwenden. Das wird z.B. benötigt, um FHEMs setExtentions oder auch um FHEMWEB Widgets nutzen zu können.

Die generelle Syntax des Attributes ist ein Perl Hash, der die Eigenschaften des ESP Easy Befehls/Plugins beschreibt.
Folgende Eigenschaften (Keys) gibt es:
*args: Anzahl der benötigten Parameter. Default: 0
*url: Die aufzurufende URL. Default: /control?cmd=
*widget: Das FHEMWEB Widget, dass beim FHEMWEB Setter des Befehls verwendet werden soll. Default: keines
*usage: Diese Zeichenkette wird zum einen angezeigt, wenn ein falscher oder zu wenige Parameter beim Befehlsaufruf angeben wurden. Zum anderen haben folgende Zeichenketten eine besondere Bedeutung:
**<0|1|off|on>: Innerhalb des FHEM Befehl kann on/off statt 0/1 angegeben werden. An die ESP Easy Firmware wird 0/1 gesendet.
**<pin>: Bei dem Paramater handelt es sin um einen GPIO Port. Aliasnamen können verwendet werden. Siehe: get <dev> pinMap
**<text>: Dieser Paramter wird url encoded an die ESP Easy Firmware gesendet. Wird für die Ausgabe auf (O)led Displays benötigt.
*cmds: Diese Eigenschaft (key) muss ebenfalls ein Perl Hash sein. Dieser Key definiert die Unterbefehle des Plugins. Alle oben genannten Eigenschaften (Keys) können benutzt werden. Nur der Key 'url' kann nicht angegeben werden, da in diesem Fall die URL des Plugins verwendet wird.

Ein einzelner neuer Befehl 'myCmd1':
attr <dev> userSetCmds ( myCmd1 => {} )

Ein einzelner neuer Befehl 'myCmd1'. Der erste Paramater enthält einen GPIO Port, der durch Aliasnamen ersetzt werden kann. Der zweite Paramater kann als on/off geschrieben werden, gesendet wird aber 1/0:
attr <dev> userSetCmds ( myCmd1 => { usage => "<pin> <0|1|off|on>" } )

Zwei neue Befehle, mit allen default Werten:
attr <dev> userSetCmds ( myCmd1 => {}, myCmd2 => {} )

Zwei neue Befehle, der zweite Befehl verwendet eine abweichende URL:
attr <dev> userSetCmds ( myCmd1 => {}, myCmd2 => { url => "/?cmd=" } )

Beispiel für das fiktive Plugin 'LED' mit den Unterbefehlen 'rgb' und 'ct'. Die Unterbefehle 'rgb' und 'ct' können ohne Angabe des Pluginnamens 'LED' verwendet werden. Zusätzlich werden in der FHEMWEB-Ansicht die Slider Widgets hsv/ct verwendet:
<source lang="text">
attr <dev> userSetCmds (
LED => {
args => 2,
url => "/control?cmd=",
usage => "<rgb|ct> <rrggbb|colortemp>",
cmds => {
rgb => { args => 1, usage => "<rrggbb>", widget => "colorpicker,HSV" },
ct => { args => 1, usage => "<colortemp>", widget => "colorpicker,CT,2000,10,4000" }
}
}
)
</source>

=== useSetExtensions ===
Mithilfe der FHEM setExtentions kann man die Befehle on-for-timer, off-for-timer, on-till, off-till, blink, intervals, toggle, etc nutzen. Im Gegensatz zu den ESP Easy Firmware Befehlen 'pulse', 'longpulse' und 'longpulse_ms' laufen die Timer nicht innerhalb der ESP Easy Firmware, sondern in FHEM. Mit allen Vor- und Nachteilen.
Um die setExtensions nutzen zu können muss das Attribut 'useExtensions' auf 1 gesetzt sein. Weiterhin müssen die Befehle 'on' und 'off', für das entsprechende Device, verfügbar sein. Das kann man auf verschiedene Weisen realisieren:
==== setExtensions mit eventMap ====
In diesem Beispiel wird der Befehl 'set <dev> GPIO 15 on' mithilfe des globalen Attributs 'eventMap' auf den Befehl 'set <dev> on' gemappt. Gleiches gilt für 'off'.
<source lang="text">
attr <dev> useSetExtensions 1
attr <dev> eventMap /gpio 15 on:^on$/gpio 15 off:^off$/
</source>
==== setExtentions mit userSetCmds ====
In diesem Beispiel wird nicht das globale Attribut 'eventMap' benutzt, sondern das ESPEasy Attribut 'userSetCmds', um die 'on' und 'off' Befehle bereitzustellen.
<source lang="text">
attr <dev> useSetExtensions 1
attr <dev> userSetCmds ( on => {url=>"/control?cmd=gpio,15,1", args => -1}, off => {url=>"/control?cmd=gpio,15,0", args => -1}
)
</source>

==Logging==
===ESPEasy Bridge===
<source lang="text">
2018.02.10 08:48:06.197 4: Connection accepted from eb_10.0.0.148_25654
2018.02.10 08:48:06.199 4: ESPEasy eb_10.0.0.148_25654: Peer address accepted
2018.02.10 08:48:06.199 5: ESPEasy eb_10.0.0.148_25654: Received header: {'Content-Length' => '298','Authorization' => 'Basic ***** ','Host' => '10.0.0.53','Connection' => 'close'}
2018.02.10 08:48:06.199 5: ESPEasy eb_10.0.0.148_25654: Received content: {"module":"ESPEasy","version":"1.02","data":{"ESP":{"name":"BA_SEN1","unit":4,"version":9,"build":137,"sleep":0,"ip":"10.0.0.148"},"SENSOR":{"0":{"deviceName":"DHT22","valueName":"temperature","type":2,"value":"21.5"},"1":{"deviceName":"DHT22","valueName":"humidity","type":2,"value":"12.2"}}}}
2018.02.10 08:48:06.200 4: ESPEasy eb_10.0.0.148_25654: Basic authentication accepted
2018.02.10 08:48:06.200 4: ESPEasy eb_10.0.0.148_25654: Send http close '200 OK'
2018.02.10 08:48:06.202 4: ESPEasy eb_10.0.0.148_25654: Src:'BA_SEN1'/'DHT22' => ident:BA_SEN1 dev:ESPEasy_BA_SEN1 combinedDevice:1
2018.02.10 08:48:06.202 5: eb: dispatch BA_SEN1::10.0.0.148::1::0::1::i||unit||4||0|||i||sleep||0||0|||i||build||137||0|||i||version||9||0|||r||temperature||21.5||2|||r||humidity||12.2||2
2018.02.10 08:48:06.209 4: ESPEasy eb_10.0.0.148_25654: Closing tcp session.
</source>

Im Detail bedeuten die Logeinträge:

;Connection accepted from eb_10.0.0.148_25654
:Eine TCP Verbindung wurde vom ESP (IP: 10.0.0.148, source port: 25654) zur Bridge "eb" aufgebaut.

;ESPEasy eb_10.0.0.148_25654
:Es wurde ein temporäres ESPEasy Bridge Devices angelegt, das Daten von der IP 10.0.0.148 und Quellport 25654 empfängt.

;Peer address accepted
:Die IP Adresse des ESP wurde akzeptiert und die empfangenen Daten werden nun verarbeitet. Wenn die IP Adresse nicht akzeptiert wird, dann wird '''Peer address rejected''' gelogged.

;<nowiki>Received header: {'Content-Length' => '298','Authorization' => 'Basic ***** ','Host' => '10.0.0.53','Connection' => 'close'}</nowiki>
:Diese ''received header'' Zeile enthält die Daten des Headers, die via HTTP vom ESP empfangen werden. Ein eventuell vorhandenes Passwort wird maskiert.

;<nowiki>Received content: {"module":"ESPEasy","version":"1.02","data":"ESP":"name":"BA_SEN1","unit":4,"version":9,"build":137,"sleep":0,"ip":"10.0.0.148"},"SENSOR":"0":{"deviceName":"DHT22","valueName":"temperature","type":2,"value":"21.5"},"1":"deviceName":"DHT22","valueName":"humidity","type":2,"value":"12.2"}}}}</nowiki>
:Diese ''received content'' Zeile enthält die Daten, die vom ESP via HTTP empfangenen werden. Mehr oder weniger Klartext im JSON Format.

;Basic authentication accepted
:In diesem Schritt wird geprüft ob eine Authentifizierung erforderlich und im besten Fall auch korrekt ist.
:Folgende Meldungen wären an dieser Stelle auch möglich:
:*No basic authentication required (auf beiden Seiten ist keine basic auth eingerichtet)
:*No basic authentication active but credentials received (auf FHEM Seite ist keine basic auth eingerichtet, der ESP sendet aber basic auth)
:*Basic authentication rejected (Username oder Passwort passen nicht zusammen)

;Send http close '200 OK'
:"Quittung" an den ESP senden. Daraufhin wird der ESP die Verbindung beenden.

;<nowiki>Src:'BA_SEN1'/'DHT22' => ident:BA_SEN1 dev:ESPEasy_BA_SEN1 combinedDevice:1</nowiki>
:Die Daten wurden vom ESP mit dem Namen BA_SEN1 und dem ESP Device DHT22 gesendet. Auf FHEM Seite werden die Daten dem Device mit dem Ident "BA_SEN1" zugewiesen. Dieses Ident wird vom FHEM Device ESPEasy_BA_SEN1 verwendet. Für diesen ESP ist das Attribut ''combineDevices'' wirksam. Wäre ''combineDevices'' nicht aktiv, dann würde das Ident "BA_SEN1_DHT22" lauten.

;<nowiki>dispatch BA_SEN1::10.0.0.148::1::0::1::i||unit||4||0|||i||sleep||0||0|||i||build||137||0|||i||version||9||0|||r||temperature||21.5||2|||r||humidity||12.2||2</nowiki>
:Die Daten werden nun von der Bridge an das logische ESPEasy Device weitergegeben.
:Im Details bedeuten die einzelnen Elemente dieser Zeichenkette:
:*'''BA_SEN1::''': Daten an das FHEM Device mit dem Ident BA_SEN1 schicken.
:*'''10.0.0.148::''': IP Adresse des ESPs
:*'''1::''': autocreate enabled? ja
:*'''0::''': autosave enabled? nein
:*'''1::''': wird nicht mehr benutzt
:*'''i||unit||4||0|||''': Der ESP hat die Unit Nummer 4
:*'''i||sleep||1||0|||''': Ist der ESP für den deep sleep mode konfiguriert? ja
:*'''i||build||137||0|||''': ESPEasy build version 137
:*'''i||version||9||0|||''': ESPEasy Release 9
:*'''r||temperature||21.5||2|||''': Readingname: temperature, Wert: 21.5, Sensortyp: 2
:*'''r||humidity||12.2||2''': Readingname: humidity, Wert 12.2, Sensortyp: 2
:Je nach ESPEasy Firmware Version können die Internals (Zeilen mit i am Anfang) auch
zusätzliche/andere Informationen aufweisen.

;Closing tcp session.
:Die tcp Verbindung wird geschlossen, das temporäre ESPEasy Bridge Device wird gelöscht.

===ESPEasy Device===
<source lang="text">
2018.02.10 10:08:41.235 5: ESPEasy ESPEasy_BA_SEN1: Received: BA_SEN1::10.0.0.148::1::0::1::i||unit||4||0|||i||sleep||0||0|||i||build||137||0|||i||version||9||0|||r||temperature||21.2||2|||r||humidity||10.3||2
2018.02.10 10:08:41.236 4: ESPEasy ESPEasy_BA_SEN1: temperature: 21.2
2018.02.10 10:08:41.237 4: ESPEasy ESPEasy_BA_SEN1: humidity: 10.3
2018.02.10 10:08:41.237 5: ESPEasy ESPEasy_BA_SEN1: Internals: unit:4 sleep:0 build:137 version:9
</source>
Im Detail:

;<nowiki>Received: BA_SEN1::10.0.0.148::1::0::1::i||unit||4||0|||i||sleep||0||0|||i||build||137||0|||i||version||9||0|||r||temperature||21.2||2|||r||humidity||10.3||2</nowiki>
:Das ist wieder die, bereits oben beschriebene, ''dispatch'' Zeichenkette, die jetzt vom logischen Device empfangen wurde.

;<nowiki>ESPEasy ESPEasy_BA_SEN1: temperature: 21.2</nowiki>
;<nowiki>ESPEasy ESPEasy_BA_SEN1: humidity: 10.3</nowiki>
:Die Readings ''temperature'' und ''humidity'' wurden aktualisiert.

;<nowiki>ESPEasy ESPEasy_BA_SEN1: Internals: unit:4 sleep:1 build:137 version:9</nowiki>
:Die Internals ''unit'', ''sleep'', ''build'' und ''version'' wurden aktualisiert.

===Zusätzliche Logeinträge===
Wird ein Device via Autocreate angelegt, gibt es zusätzliche Einträge im Logfile
<source lang="text">
2018.02.10 10:23:52.243 4: ESPEasy eb_10.0.0.148_3446: Src:'BA_SEN1'/'DHT22' => ident:BA_SEN1 dev:undef combinedDevice:1
2018.02.10 10:23:52.243 2: ESPEasy eb: Autocreate ESPEasy_BA_SEN1 ESPEasy 10.0.0.148 80 eb BA_SEN1
2018.02.10 10:23:52.244 4: ESPEasy ESPEasy_BA_SEN1: Opened for BA_SEN1 10.0.0.148:80 using bridge eb
2018.02.10 10:23:52.258 5: ESPEasy ESPEasy_BA_SEN1: received event: ATTR ESPEasy_BA_SEN1 setState 3
2018.02.10 10:23:52.262 5: ESPEasy ESPEasy_BA_SEN1: received event: ATTR ESPEasy_BA_SEN1 Interval 300
2018.02.10 10:23:52.262 5: ESPEasy ESPEasy_BA_SEN1: Start internalTimer +304 => 2018-02-10 10:28:57
2018.02.10 10:23:52.266 5: ESPEasy ESPEasy_BA_SEN1: received event: ATTR ESPEasy_BA_SEN1 presenceCheck 1
2018.02.10 10:23:52.269 5: ESPEasy ESPEasy_BA_SEN1: received event: ATTR ESPEasy_BA_SEN1 readingSwitchText 1
2018.02.10 10:23:52.271 2: ESPEasy eb: Autosave is disabled: Do not forget to save changes.
</source>

==Weblinks==
*{{Link2CmdRef|Anker=ESPEasy|Lang=en|Label=FHEM ESPEasy Modul-Dokumentation}}
*[https://www.letscontrolit.com/wiki/index.php/ESPEasy ESP Easy Firmware Wiki]
*[https://www.letscontrolit.com/wiki/index.php/ESPEasy_Command_Reference ESP Easy Command Reference]
*[https://www.letscontrolit.com/wiki/index.php/Tutorial_Rules ESP Easy Rules]

==Credits==
Vielen Dank an:

*'''ESP Easy Team''', für die kontinuierliche Pflege und Erweiterungen der Software

*'''Drhrin''', für die initiale Umsetzung dieses Wiki-Eintags

AttrTemplate

2019-11-08T22:56:12Z

Maista: /* Eigene templates entwickeln */

{{SEITENTITEL:AttrTemplate}}
{{Infobox Modul
|ModPurpose=Hilfsmodul bzw. Befehl, das/der die Einrichtung von Geräten erleichtern kann
|ModType=cmd
|ModCmdRef=
|ModForumArea=Automatisierung
|ModTechName=AttrTemplate.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

AttrTemplate ist ein Hilfsmodul, mit dessen Hilfe Geräte auf einfache Weise mit einer passenden Konfiguration versehen lassen.

Das Modul ''AttrTemplate'' ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden. Über diesen Mechanismus ist der Befehl ''attrTemplate'' in einer Vielzahl von Modulen verfügbar.

==Einführung==
Ziel von ''attrTemplate'' ist es, den Nutzer bei der Konfiguration von Geräten zu unterstützen, indem vorrangig entsprechende [[Attribute]] gesetzt werden. Grundsätzlich ist es jedoch auch möglich, beliebige FHEM-Befehle oder Perl-Code im Rahmen von attrTemplate auszulösen.
Teilt man entsprechende ''templates'', sollte jedoch deutlich darauf hingewiesen werden, wenn ein Template etwas anderes tut als nur Attribute zu setzen, also insbesondere dauerhafte Konfigurationsänderungen in der Hardware selbst vorzunehmen.

Um Ihnen die Auswahl zu erleichtern, kann
* mit <code>set <Device-Name> attrTemplate ?</code> eine Liste der vorhandenen Templates samt kurzer Beschreibung aufgerufen werden.
* in der Detailansicht der Geräte über das Dropdownfeld ein ''template'' ausgewählt werden. Nun erhält man unmittelbar unter dem ''set''-Befehl ebenfalls entsprechende weitere Informationen sowie den Code des ''template'' angezeigt, der bei Drücken auf ''set'' ausgeführt wird.
Hat man ein passendes ''template'' gefunden, wird mit <code>set <Device-Name> attrTemplate <template_name></code> angewendet, wodurch die entsprechenden, in dem ''template'' hinterlegten Kommandos ausgeführt werden.

== Syntax ==

{{Link2Forum|Topic=104804|Message=988100|LinkText=Hier}} hat Rudolf König die Syntax erläutert, die in den attrTemplate-Dateien verwendet werden können:
* leere Zeilen werden ignoriert
* Zeilen die mit # anfangen sind Kommentare (s.u. ''desc:'')
* Zeilen, die mit einem der folgenden Schlüsselwörter beginnen, werden speziell interpretiert: ''name: filter: prereq: par: desc: farewell: order:''
** '''name:''' Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
** '''filter:''' devspec2array Ausdruck, der beschreibt, für welche Geräte dieses Template anwendbar ist. Wird erst beim "set ?" ausgeführt.
** '''prereq:''' ist entweder ein Perl-Ausdruck {}, oder ein ''devspec2array'', was genau ein Gerät spezifiziert. Wird beim Einlesen des template Files ausgeführt. Falls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt. Ist für sowas wie "setze zusätzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
** '''par:''' kann mehrfach vorkommen, Syntax: <code>par:<ParamaterName>:<Kommentar>:<Perl-Code></code>. ''Perl-Code'' versucht den Wert zu finden, falls nicht möglich (''return undef''), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ''ParameterName'' wird in jeder Befehlzeile ersetzt mit dem Wert. Zusätzlich: ''DEVICE'' wird mit dem Namen des Gerätes ersetzt, wird ''DEVICE'' (z.B. für Modulnamen) als Text benötigt, muß es ''escaped'' werden (z.B. MQTT2_\DEVICE).
** '''desc:''' Kommentar fuer <code>set attrTemplate help ?</code>. Die letzte Zeile mit # vor ''name:'' wird als ''desc:'' interpretiert, falls kein ''desc:'' vorhanden ist.
** '''farewell:''' wird zum Schluss als Dialog (oder Text in telnet) angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist.
** '''order:''' bestimmt die Reihenfolge, in der die Templates im [[FHEMWEB|Webfrontend]] angezeigt werden; falls nicht vorhanden, wird ''name:'' genommen.
* alle anderen Zeilen werden als auszuführende Befehle interpretiert, wenn man <code>set <Device-Name> attrTemplate TemplateName</code> ausführt.

==Eigene Templates entwickeln==
Wer plant, mehrere gleichartige Geräte anzulegen, aber andere Einstellungen zu wählen, als sie in den vorhandenen Templates enthalten sind, kann hierfür ebenfalls die attrTemplate-Funktion mit eigenen Templates nutzen. Hierfür können die vorhandenen Templates der im Unterverzeichnis ''fhem/FHEM/lib/AttrTemplate'' zu findenden Dateien als Basis dienen. Ihre Templates speichern Sie einfach als neue Datei mit der Endung ''.template'' im selben Verzeichnis und lesen diese mit <code>{ AttrTemplate_Initialize() }</code> neu ein. Danach können Sie diese direkt verwenden.

Haben Sie ein Template erstellt und möchten dieses teilen, erstellen Sie einfach einen Beitrag im entsprechenden Forenbereichen, für manche Module existieren auch spezielle Threads (siehe Linkliste unten)

==Links==
* {{Link2Forum|Topic=93370|LinkText=Ankündigung des Moduls im Forum}}
* [[MQTT2_DEVICE#attrTemplate|Wiki zu attrTemplate und MQTT2_DEVICE]] - enthält auch Links zu speziellen Threads für bestimmte Device-Typen
* {{Link2Forum|Topic=94495|LinkText=Thread für getestete Vorschläge (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=94494|LinkText=Thread für Fragen und Anregungen (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=97694|LinkText=Thread für HTTPMOD}}.
<references />
[[Kategorie:FHEM-Verwendung]]
[[Kategorie:HOWTOS]]

AttrTemplate

2019-11-08T22:55:58Z

Maista: /* Eigene templates entwickeln */

{{SEITENTITEL:AttrTemplate}}
{{Infobox Modul
|ModPurpose=Hilfsmodul bzw. Befehl, das/der die Einrichtung von Geräten erleichtern kann
|ModType=cmd
|ModCmdRef=
|ModForumArea=Automatisierung
|ModTechName=AttrTemplate.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

AttrTemplate ist ein Hilfsmodul, mit dessen Hilfe Geräte auf einfache Weise mit einer passenden Konfiguration versehen lassen.

Das Modul ''AttrTemplate'' ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden. Über diesen Mechanismus ist der Befehl ''attrTemplate'' in einer Vielzahl von Modulen verfügbar.

==Einführung==
Ziel von ''attrTemplate'' ist es, den Nutzer bei der Konfiguration von Geräten zu unterstützen, indem vorrangig entsprechende [[Attribute]] gesetzt werden. Grundsätzlich ist es jedoch auch möglich, beliebige FHEM-Befehle oder Perl-Code im Rahmen von attrTemplate auszulösen.
Teilt man entsprechende ''templates'', sollte jedoch deutlich darauf hingewiesen werden, wenn ein Template etwas anderes tut als nur Attribute zu setzen, also insbesondere dauerhafte Konfigurationsänderungen in der Hardware selbst vorzunehmen.

Um Ihnen die Auswahl zu erleichtern, kann
* mit <code>set <Device-Name> attrTemplate ?</code> eine Liste der vorhandenen Templates samt kurzer Beschreibung aufgerufen werden.
* in der Detailansicht der Geräte über das Dropdownfeld ein ''template'' ausgewählt werden. Nun erhält man unmittelbar unter dem ''set''-Befehl ebenfalls entsprechende weitere Informationen sowie den Code des ''template'' angezeigt, der bei Drücken auf ''set'' ausgeführt wird.
Hat man ein passendes ''template'' gefunden, wird mit <code>set <Device-Name> attrTemplate <template_name></code> angewendet, wodurch die entsprechenden, in dem ''template'' hinterlegten Kommandos ausgeführt werden.

== Syntax ==

{{Link2Forum|Topic=104804|Message=988100|LinkText=Hier}} hat Rudolf König die Syntax erläutert, die in den attrTemplate-Dateien verwendet werden können:
* leere Zeilen werden ignoriert
* Zeilen die mit # anfangen sind Kommentare (s.u. ''desc:'')
* Zeilen, die mit einem der folgenden Schlüsselwörter beginnen, werden speziell interpretiert: ''name: filter: prereq: par: desc: farewell: order:''
** '''name:''' Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
** '''filter:''' devspec2array Ausdruck, der beschreibt, für welche Geräte dieses Template anwendbar ist. Wird erst beim "set ?" ausgeführt.
** '''prereq:''' ist entweder ein Perl-Ausdruck {}, oder ein ''devspec2array'', was genau ein Gerät spezifiziert. Wird beim Einlesen des template Files ausgeführt. Falls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt. Ist für sowas wie "setze zusätzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
** '''par:''' kann mehrfach vorkommen, Syntax: <code>par:<ParamaterName>:<Kommentar>:<Perl-Code></code>. ''Perl-Code'' versucht den Wert zu finden, falls nicht möglich (''return undef''), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ''ParameterName'' wird in jeder Befehlzeile ersetzt mit dem Wert. Zusätzlich: ''DEVICE'' wird mit dem Namen des Gerätes ersetzt, wird ''DEVICE'' (z.B. für Modulnamen) als Text benötigt, muß es ''escaped'' werden (z.B. MQTT2_\DEVICE).
** '''desc:''' Kommentar fuer <code>set attrTemplate help ?</code>. Die letzte Zeile mit # vor ''name:'' wird als ''desc:'' interpretiert, falls kein ''desc:'' vorhanden ist.
** '''farewell:''' wird zum Schluss als Dialog (oder Text in telnet) angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist.
** '''order:''' bestimmt die Reihenfolge, in der die Templates im [[FHEMWEB|Webfrontend]] angezeigt werden; falls nicht vorhanden, wird ''name:'' genommen.
* alle anderen Zeilen werden als auszuführende Befehle interpretiert, wenn man <code>set <Device-Name> attrTemplate TemplateName</code> ausführt.

==Eigene templates entwickeln==
Wer plant, mehrere gleichartige Geräte anzulegen, aber andere Einstellungen zu wählen, als sie in den vorhandenen Templates enthalten sind, kann hierfür ebenfalls die attrTemplate-Funktion mit eigenen Templates nutzen. Hierfür können die vorhandenen Templates der im Unterverzeichnis ''fhem/FHEM/lib/AttrTemplate'' zu findenden Dateien als Basis dienen. Ihre Templates speichern Sie einfach als neue Datei mit der Endung ''.template'' im selben Verzeichnis und lesen diese mit <code>{ AttrTemplate_Initialize() }</code> neu ein. Danach können Sie diese direkt verwenden.

Haben Sie ein Template erstellt und möchten dieses teilen, erstellen Sie einfach einen Beitrag im entsprechenden Forenbereichen, für manche Module existieren auch spezielle Threads (siehe Linkliste unten)

==Links==
* {{Link2Forum|Topic=93370|LinkText=Ankündigung des Moduls im Forum}}
* [[MQTT2_DEVICE#attrTemplate|Wiki zu attrTemplate und MQTT2_DEVICE]] - enthält auch Links zu speziellen Threads für bestimmte Device-Typen
* {{Link2Forum|Topic=94495|LinkText=Thread für getestete Vorschläge (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=94494|LinkText=Thread für Fragen und Anregungen (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=97694|LinkText=Thread für HTTPMOD}}.
<references />
[[Kategorie:FHEM-Verwendung]]
[[Kategorie:HOWTOS]]

AttrTemplate

2019-11-08T22:54:42Z

Maista: /* Einführung */

{{SEITENTITEL:AttrTemplate}}
{{Infobox Modul
|ModPurpose=Hilfsmodul bzw. Befehl, das/der die Einrichtung von Geräten erleichtern kann
|ModType=cmd
|ModCmdRef=
|ModForumArea=Automatisierung
|ModTechName=AttrTemplate.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

AttrTemplate ist ein Hilfsmodul, mit dessen Hilfe Geräte auf einfache Weise mit einer passenden Konfiguration versehen lassen.

Das Modul ''AttrTemplate'' ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden. Über diesen Mechanismus ist der Befehl ''attrTemplate'' in einer Vielzahl von Modulen verfügbar.

==Einführung==
Ziel von ''attrTemplate'' ist es, den Nutzer bei der Konfiguration von Geräten zu unterstützen, indem vorrangig entsprechende [[Attribute]] gesetzt werden. Grundsätzlich ist es jedoch auch möglich, beliebige FHEM-Befehle oder Perl-Code im Rahmen von attrTemplate auszulösen.
Teilt man entsprechende ''templates'', sollte jedoch deutlich darauf hingewiesen werden, wenn ein Template etwas anderes tut als nur Attribute zu setzen, also insbesondere dauerhafte Konfigurationsänderungen in der Hardware selbst vorzunehmen.

Um Ihnen die Auswahl zu erleichtern, kann
* mit <code>set <Device-Name> attrTemplate ?</code> eine Liste der vorhandenen Templates samt kurzer Beschreibung aufgerufen werden.
* in der Detailansicht der Geräte über das Dropdownfeld ein ''template'' ausgewählt werden. Nun erhält man unmittelbar unter dem ''set''-Befehl ebenfalls entsprechende weitere Informationen sowie den Code des ''template'' angezeigt, der bei Drücken auf ''set'' ausgeführt wird.
Hat man ein passendes ''template'' gefunden, wird mit <code>set <Device-Name> attrTemplate <template_name></code> angewendet, wodurch die entsprechenden, in dem ''template'' hinterlegten Kommandos ausgeführt werden.

== Syntax ==

{{Link2Forum|Topic=104804|Message=988100|LinkText=Hier}} hat Rudolf König die Syntax erläutert, die in den attrTemplate-Dateien verwendet werden können:
* leere Zeilen werden ignoriert
* Zeilen die mit # anfangen sind Kommentare (s.u. ''desc:'')
* Zeilen, die mit einem der folgenden Schlüsselwörter beginnen, werden speziell interpretiert: ''name: filter: prereq: par: desc: farewell: order:''
** '''name:''' Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
** '''filter:''' devspec2array Ausdruck, der beschreibt, für welche Geräte dieses Template anwendbar ist. Wird erst beim "set ?" ausgeführt.
** '''prereq:''' ist entweder ein Perl-Ausdruck {}, oder ein ''devspec2array'', was genau ein Gerät spezifiziert. Wird beim Einlesen des template Files ausgeführt. Falls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt. Ist für sowas wie "setze zusätzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
** '''par:''' kann mehrfach vorkommen, Syntax: <code>par:<ParamaterName>:<Kommentar>:<Perl-Code></code>. ''Perl-Code'' versucht den Wert zu finden, falls nicht möglich (''return undef''), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ''ParameterName'' wird in jeder Befehlzeile ersetzt mit dem Wert. Zusätzlich: ''DEVICE'' wird mit dem Namen des Gerätes ersetzt, wird ''DEVICE'' (z.B. für Modulnamen) als Text benötigt, muß es ''escaped'' werden (z.B. MQTT2_\DEVICE).
** '''desc:''' Kommentar fuer <code>set attrTemplate help ?</code>. Die letzte Zeile mit # vor ''name:'' wird als ''desc:'' interpretiert, falls kein ''desc:'' vorhanden ist.
** '''farewell:''' wird zum Schluss als Dialog (oder Text in telnet) angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist.
** '''order:''' bestimmt die Reihenfolge, in der die Templates im [[FHEMWEB|Webfrontend]] angezeigt werden; falls nicht vorhanden, wird ''name:'' genommen.
* alle anderen Zeilen werden als auszuführende Befehle interpretiert, wenn man <code>set <Device-Name> attrTemplate TemplateName</code> ausführt.

==Eigene templates entwickeln==
Wer plant, mehrere gleichartige Geräte anzulegen, aber andere Einstellungen zu wählen, als sie in den vorhandenen templates enthalten sind, kann hierfür ebenfalls die attrTemplate-Funktion mit eigenen templates nutzen. Hierfür können die vorhandenen templates der im Unterverzeichnis ''fhem/FHEM/lib/AttrTemplate'' zu findenden Dateien als Basis dienen. Ihre Templates speichern Sie einfach als neue Datei mit der Endung ''.template'' im selben Verzeichnis und lesen diese mit <code>{ AttrTemplate_Initialize() }</code> neu ein. Danach können Sie diese direkt verwenden.

Haben Sie ein Template erstellt und möchten dieses teilen, erstellen Sie einfach einen Beitrag im entsprechenden Forenbereichen, für manche Module existieren auch spezielle Threads (siehe Linkliste unten)

==Links==
* {{Link2Forum|Topic=93370|LinkText=Ankündigung des Moduls im Forum}}
* [[MQTT2_DEVICE#attrTemplate|Wiki zu attrTemplate und MQTT2_DEVICE]] - enthält auch Links zu speziellen Threads für bestimmte Device-Typen
* {{Link2Forum|Topic=94495|LinkText=Thread für getestete Vorschläge (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=94494|LinkText=Thread für Fragen und Anregungen (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=97694|LinkText=Thread für HTTPMOD}}.
<references />
[[Kategorie:FHEM-Verwendung]]
[[Kategorie:HOWTOS]]

AttrTemplate

2019-11-08T22:53:37Z

Maista: /* Eigene templates entwickeln */

{{SEITENTITEL:AttrTemplate}}
{{Infobox Modul
|ModPurpose=Hilfsmodul bzw. Befehl, das/der die Einrichtung von Geräten erleichtern kann
|ModType=cmd
|ModCmdRef=
|ModForumArea=Automatisierung
|ModTechName=AttrTemplate.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

AttrTemplate ist ein Hilfsmodul, mit dessen Hilfe Geräte auf einfache Weise mit einer passenden Konfiguration versehen lassen.

Das Modul ''AttrTemplate'' ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden. Über diesen Mechanismus ist der Befehl ''attrTemplate'' in einer Vielzahl von Modulen verfügbar.

==Einführung==
Ziel von ''attrTemplate'' ist es, den Nutzer bei der Konfiguration von Geräten zu unterstützen, indem vorrangig entsprechende [[Attribute]] gesetzt werden. Grundsätzlich ist es jedoch auch möglich, beliebige FHEM-Befehle oder Perl-Code im Rahmen von attrTemplate auszulösen.
Teilt man entsprechende ''templates'', sollte jedoch deutlich darauf hingewiesen werden, wenn ein template etwas anderes tut als nur Attribute zu setzen, also insbesondere dauerhafte Konfigurationsänderungen in der Hardware selbst vorzunehmen.

Um Ihnen die Auswahl zu erleichtern, kann
* mit <code>set <Device-Name> attrTemplate ?</code> eine Liste der vorhandenen Templates samt kurzer Beschreibung aufgerufen werden.
* in der Detailansicht der Geräte über das Dropdownfeld ein ''template'' ausgewählt werden. Nun erhält man unmittelbar unter dem ''set''-Befehl ebenfalls entsprechende weitere Informationen sowie den Code des ''template'' angezeigt, der bei Drücken auf ''set'' ausgeführt wird.
Hat man ein passendes ''template'' gefunden, wird mit <code>set <Device-Name> attrTemplate <template_name></code> angewendet, wodurch die entsprechenden, in dem ''template'' hinterlegten Kommandos ausgeführt werden.

== Syntax ==

{{Link2Forum|Topic=104804|Message=988100|LinkText=Hier}} hat Rudolf König die Syntax erläutert, die in den attrTemplate-Dateien verwendet werden können:
* leere Zeilen werden ignoriert
* Zeilen die mit # anfangen sind Kommentare (s.u. ''desc:'')
* Zeilen, die mit einem der folgenden Schlüsselwörter beginnen, werden speziell interpretiert: ''name: filter: prereq: par: desc: farewell: order:''
** '''name:''' Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
** '''filter:''' devspec2array Ausdruck, der beschreibt, für welche Geräte dieses Template anwendbar ist. Wird erst beim "set ?" ausgeführt.
** '''prereq:''' ist entweder ein Perl-Ausdruck {}, oder ein ''devspec2array'', was genau ein Gerät spezifiziert. Wird beim Einlesen des template Files ausgeführt. Falls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt. Ist für sowas wie "setze zusätzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
** '''par:''' kann mehrfach vorkommen, Syntax: <code>par:<ParamaterName>:<Kommentar>:<Perl-Code></code>. ''Perl-Code'' versucht den Wert zu finden, falls nicht möglich (''return undef''), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ''ParameterName'' wird in jeder Befehlzeile ersetzt mit dem Wert. Zusätzlich: ''DEVICE'' wird mit dem Namen des Gerätes ersetzt, wird ''DEVICE'' (z.B. für Modulnamen) als Text benötigt, muß es ''escaped'' werden (z.B. MQTT2_\DEVICE).
** '''desc:''' Kommentar fuer <code>set attrTemplate help ?</code>. Die letzte Zeile mit # vor ''name:'' wird als ''desc:'' interpretiert, falls kein ''desc:'' vorhanden ist.
** '''farewell:''' wird zum Schluss als Dialog (oder Text in telnet) angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist.
** '''order:''' bestimmt die Reihenfolge, in der die Templates im [[FHEMWEB|Webfrontend]] angezeigt werden; falls nicht vorhanden, wird ''name:'' genommen.
* alle anderen Zeilen werden als auszuführende Befehle interpretiert, wenn man <code>set <Device-Name> attrTemplate TemplateName</code> ausführt.

==Eigene templates entwickeln==
Wer plant, mehrere gleichartige Geräte anzulegen, aber andere Einstellungen zu wählen, als sie in den vorhandenen templates enthalten sind, kann hierfür ebenfalls die attrTemplate-Funktion mit eigenen templates nutzen. Hierfür können die vorhandenen templates der im Unterverzeichnis ''fhem/FHEM/lib/AttrTemplate'' zu findenden Dateien als Basis dienen. Ihre Templates speichern Sie einfach als neue Datei mit der Endung ''.template'' im selben Verzeichnis und lesen diese mit <code>{ AttrTemplate_Initialize() }</code> neu ein. Danach können Sie diese direkt verwenden.

Haben Sie ein Template erstellt und möchten dieses teilen, erstellen Sie einfach einen Beitrag im entsprechenden Forenbereichen, für manche Module existieren auch spezielle Threads (siehe Linkliste unten)

==Links==
* {{Link2Forum|Topic=93370|LinkText=Ankündigung des Moduls im Forum}}
* [[MQTT2_DEVICE#attrTemplate|Wiki zu attrTemplate und MQTT2_DEVICE]] - enthält auch Links zu speziellen Threads für bestimmte Device-Typen
* {{Link2Forum|Topic=94495|LinkText=Thread für getestete Vorschläge (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=94494|LinkText=Thread für Fragen und Anregungen (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=97694|LinkText=Thread für HTTPMOD}}.
<references />
[[Kategorie:FHEM-Verwendung]]
[[Kategorie:HOWTOS]]

AttrTemplate

2019-11-08T22:52:13Z

Maista: /* Syntax */

{{SEITENTITEL:AttrTemplate}}
{{Infobox Modul
|ModPurpose=Hilfsmodul bzw. Befehl, das/der die Einrichtung von Geräten erleichtern kann
|ModType=cmd
|ModCmdRef=
|ModForumArea=Automatisierung
|ModTechName=AttrTemplate.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

AttrTemplate ist ein Hilfsmodul, mit dessen Hilfe Geräte auf einfache Weise mit einer passenden Konfiguration versehen lassen.

Das Modul ''AttrTemplate'' ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden. Über diesen Mechanismus ist der Befehl ''attrTemplate'' in einer Vielzahl von Modulen verfügbar.

==Einführung==
Ziel von ''attrTemplate'' ist es, den Nutzer bei der Konfiguration von Geräten zu unterstützen, indem vorrangig entsprechende [[Attribute]] gesetzt werden. Grundsätzlich ist es jedoch auch möglich, beliebige FHEM-Befehle oder Perl-Code im Rahmen von attrTemplate auszulösen.
Teilt man entsprechende ''templates'', sollte jedoch deutlich darauf hingewiesen werden, wenn ein template etwas anderes tut als nur Attribute zu setzen, also insbesondere dauerhafte Konfigurationsänderungen in der Hardware selbst vorzunehmen.

Um Ihnen die Auswahl zu erleichtern, kann
* mit <code>set <Device-Name> attrTemplate ?</code> eine Liste der vorhandenen Templates samt kurzer Beschreibung aufgerufen werden.
* in der Detailansicht der Geräte über das Dropdownfeld ein ''template'' ausgewählt werden. Nun erhält man unmittelbar unter dem ''set''-Befehl ebenfalls entsprechende weitere Informationen sowie den Code des ''template'' angezeigt, der bei Drücken auf ''set'' ausgeführt wird.
Hat man ein passendes ''template'' gefunden, wird mit <code>set <Device-Name> attrTemplate <template_name></code> angewendet, wodurch die entsprechenden, in dem ''template'' hinterlegten Kommandos ausgeführt werden.

== Syntax ==

{{Link2Forum|Topic=104804|Message=988100|LinkText=Hier}} hat Rudolf König die Syntax erläutert, die in den attrTemplate-Dateien verwendet werden können:
* leere Zeilen werden ignoriert
* Zeilen die mit # anfangen sind Kommentare (s.u. ''desc:'')
* Zeilen, die mit einem der folgenden Schlüsselwörter beginnen, werden speziell interpretiert: ''name: filter: prereq: par: desc: farewell: order:''
** '''name:''' Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
** '''filter:''' devspec2array Ausdruck, der beschreibt, für welche Geräte dieses Template anwendbar ist. Wird erst beim "set ?" ausgeführt.
** '''prereq:''' ist entweder ein Perl-Ausdruck {}, oder ein ''devspec2array'', was genau ein Gerät spezifiziert. Wird beim Einlesen des template Files ausgeführt. Falls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt. Ist für sowas wie "setze zusätzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
** '''par:''' kann mehrfach vorkommen, Syntax: <code>par:<ParamaterName>:<Kommentar>:<Perl-Code></code>. ''Perl-Code'' versucht den Wert zu finden, falls nicht möglich (''return undef''), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ''ParameterName'' wird in jeder Befehlzeile ersetzt mit dem Wert. Zusätzlich: ''DEVICE'' wird mit dem Namen des Gerätes ersetzt, wird ''DEVICE'' (z.B. für Modulnamen) als Text benötigt, muß es ''escaped'' werden (z.B. MQTT2_\DEVICE).
** '''desc:''' Kommentar fuer <code>set attrTemplate help ?</code>. Die letzte Zeile mit # vor ''name:'' wird als ''desc:'' interpretiert, falls kein ''desc:'' vorhanden ist.
** '''farewell:''' wird zum Schluss als Dialog (oder Text in telnet) angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist.
** '''order:''' bestimmt die Reihenfolge, in der die Templates im [[FHEMWEB|Webfrontend]] angezeigt werden; falls nicht vorhanden, wird ''name:'' genommen.
* alle anderen Zeilen werden als auszuführende Befehle interpretiert, wenn man <code>set <Device-Name> attrTemplate TemplateName</code> ausführt.

==Eigene templates entwickeln==
Wer plant, mehrere gleichartige Geräte anzulegen, aber andere Einstellungen zu wählen, als sie in den vorhandenen templates enthalten sind, kann hierfür ebenfalls die attrTemplate-Funktion mit eigenen templates nutzen. Hierfür können die vorhandenen templates der im Unterverzeichnis ''fhem/FHEM/lib/AttrTemplate'' zu findenden Dateien als Basis dienen, Ihre templates speichern Sie einfach als neue Datei mit der Endung ''.template'' im selben Verzeichnis und lesen diese mit <code>{ AttrTemplate_Initialize() }</code> neu ein. Danach können Sie diese direkt verwenden.

Haben Sie ein template erstellt und möchten dieses teilen, erstellen Sie einfach einen Beitrag im entsprechenden Forenbereichen, für manche Module existieren auch spezielle Threads (siehe Linkliste unten)

==Links==
* {{Link2Forum|Topic=93370|LinkText=Ankündigung des Moduls im Forum}}
* [[MQTT2_DEVICE#attrTemplate|Wiki zu attrTemplate und MQTT2_DEVICE]] - enthält auch Links zu speziellen Threads für bestimmte Device-Typen
* {{Link2Forum|Topic=94495|LinkText=Thread für getestete Vorschläge (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=94494|LinkText=Thread für Fragen und Anregungen (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=97694|LinkText=Thread für HTTPMOD}}.
<references />
[[Kategorie:FHEM-Verwendung]]
[[Kategorie:HOWTOS]]

AttrTemplate

2019-11-08T22:51:35Z

Maista: /* Einführung */

{{SEITENTITEL:AttrTemplate}}
{{Infobox Modul
|ModPurpose=Hilfsmodul bzw. Befehl, das/der die Einrichtung von Geräten erleichtern kann
|ModType=cmd
|ModCmdRef=
|ModForumArea=Automatisierung
|ModTechName=AttrTemplate.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

AttrTemplate ist ein Hilfsmodul, mit dessen Hilfe Geräte auf einfache Weise mit einer passenden Konfiguration versehen lassen.

Das Modul ''AttrTemplate'' ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden. Über diesen Mechanismus ist der Befehl ''attrTemplate'' in einer Vielzahl von Modulen verfügbar.

==Einführung==
Ziel von ''attrTemplate'' ist es, den Nutzer bei der Konfiguration von Geräten zu unterstützen, indem vorrangig entsprechende [[Attribute]] gesetzt werden. Grundsätzlich ist es jedoch auch möglich, beliebige FHEM-Befehle oder Perl-Code im Rahmen von attrTemplate auszulösen.
Teilt man entsprechende ''templates'', sollte jedoch deutlich darauf hingewiesen werden, wenn ein template etwas anderes tut als nur Attribute zu setzen, also insbesondere dauerhafte Konfigurationsänderungen in der Hardware selbst vorzunehmen.

Um Ihnen die Auswahl zu erleichtern, kann
* mit <code>set <Device-Name> attrTemplate ?</code> eine Liste der vorhandenen Templates samt kurzer Beschreibung aufgerufen werden.
* in der Detailansicht der Geräte über das Dropdownfeld ein ''template'' ausgewählt werden. Nun erhält man unmittelbar unter dem ''set''-Befehl ebenfalls entsprechende weitere Informationen sowie den Code des ''template'' angezeigt, der bei Drücken auf ''set'' ausgeführt wird.
Hat man ein passendes ''template'' gefunden, wird mit <code>set <Device-Name> attrTemplate <template_name></code> angewendet, wodurch die entsprechenden, in dem ''template'' hinterlegten Kommandos ausgeführt werden.

== Syntax ==

{{Link2Forum|Topic=104804|Message=988100|LinkText=Hier}} hat Rudolf König die Syntax erläutert, die in den attrTemplate-Dateien verwendet werden kann:
* leere Zeilen werden ignoriert
* Zeilen die mit # anfangen sind Kommentare (s.u. ''desc:'')
* Zeilen, die mit einem der folgenden Schlüsselwörter beginnen, werden speziell interpretiert: ''name: filter: prereq: par: desc: farewell: order:''
** '''name:''' Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
** '''filter:''' devspec2array Ausdruck, der beschreibt, für welche Geräte dieses Template anwendbar ist. Wird erst beim "set ?" ausgeführt.
** '''prereq:''' ist entweder ein Perl-Ausdruck {}, oder ein ''devspec2array'', was genau ein Gerät spezifiziert. Wird beim Einlesen des template Files ausgeführt. Falls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt. Ist für sowas wie "setze zusätzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
** '''par:''' kann mehrfach vorkommen, Syntax: <code>par:<ParamaterName>:<Kommentar>:<Perl-Code></code>. ''Perl-Code'' versucht den Wert zu finden, falls nicht möglich (''return undef''), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ''ParameterName'' wird in jeder Befehlzeile ersetzt mit dem Wert. Zusätzlich: ''DEVICE'' wird mit dem Namen des Gerätes ersetzt, wird ''DEVICE'' (z.B. für Modulnamen) als Text benötigt, muß es ''escaped'' werden (z.B. MQTT2_\DEVICE).
** '''desc:''' Kommentar fuer <code>set attrTemplate help ?</code>. Die letzte Zeile mit # vor ''name:'' wird als ''desc:'' interpretiert, falls kein ''desc:'' vorhanden ist.
** '''farewell:''' wird zum Schluss als Dialog (oder Text in telnet) angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist.
** '''order:''' bestimmt die Reihenfolge, in der die Templates im [[FHEMWEB|Webfrontend]] angezeigt werden; falls nicht vorhanden, wird ''name:'' genommen.
* alle anderen Zeilen werden als auszuführende Befehle interpretiert, wenn man <code>set <Device-Name> attrTemplate TemplateName</code> ausführt.

==Eigene templates entwickeln==
Wer plant, mehrere gleichartige Geräte anzulegen, aber andere Einstellungen zu wählen, als sie in den vorhandenen templates enthalten sind, kann hierfür ebenfalls die attrTemplate-Funktion mit eigenen templates nutzen. Hierfür können die vorhandenen templates der im Unterverzeichnis ''fhem/FHEM/lib/AttrTemplate'' zu findenden Dateien als Basis dienen, Ihre templates speichern Sie einfach als neue Datei mit der Endung ''.template'' im selben Verzeichnis und lesen diese mit <code>{ AttrTemplate_Initialize() }</code> neu ein. Danach können Sie diese direkt verwenden.

Haben Sie ein template erstellt und möchten dieses teilen, erstellen Sie einfach einen Beitrag im entsprechenden Forenbereichen, für manche Module existieren auch spezielle Threads (siehe Linkliste unten)

==Links==
* {{Link2Forum|Topic=93370|LinkText=Ankündigung des Moduls im Forum}}
* [[MQTT2_DEVICE#attrTemplate|Wiki zu attrTemplate und MQTT2_DEVICE]] - enthält auch Links zu speziellen Threads für bestimmte Device-Typen
* {{Link2Forum|Topic=94495|LinkText=Thread für getestete Vorschläge (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=94494|LinkText=Thread für Fragen und Anregungen (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=97694|LinkText=Thread für HTTPMOD}}.
<references />
[[Kategorie:FHEM-Verwendung]]
[[Kategorie:HOWTOS]]

AttrTemplate

2019-11-08T22:49:00Z

Maista: Tippfehler

{{SEITENTITEL:AttrTemplate}}
{{Infobox Modul
|ModPurpose=Hilfsmodul bzw. Befehl, das/der die Einrichtung von Geräten erleichtern kann
|ModType=cmd
|ModCmdRef=
|ModForumArea=Automatisierung
|ModTechName=AttrTemplate.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

AttrTemplate ist ein Hilfsmodul, mit dessen Hilfe Geräte auf einfache Weise mit einer passenden Konfiguration versehen lassen.

Das Modul ''AttrTemplate'' ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden. Über diesen Mechanismus ist der Befehl ''attrTemplate'' in einer Vielzahl von Modulen verfügbar.

==Einführung==
Ziel von ''attrTemplate'' ist es, den Nutzer bei der Konfiguration von Geräten zu unterstützen, indem vorrangig entsprechende [[Attribute]] gesetzt werden. Grundsätzlich ist es jedoch auch möglich, beliebige FHEM-Befehle oder Perl-Code im Rahmen von attrTemplate auszulösen.
Teilt man entsprechende ''templates'', sollte jedoch deutlich darauf hingewiesen werden, wenn ein template etwas anderes tut als nur Attribute zu setzen, also insbesondere dauerhafte Konfigurationsänderungen in der Hardware selbst vorzunehmen.

Um Ihnen die Auswahl zu erleichtern, kann
* mit <code>set <Device-Name> attrTemplate ?</code> eine Liste der vorhandenen Templates samt kurzer Beschreibung aufgerufen werden.
* in der Detailansicht der Geräte über das Dropdownfeld ein ''template'' ausgewählt werden; dann erhält man unmittelbar unter dem ''set''-Befehl ebenfalls entsprechende weitere Informationen sowie den Code des ''template'' angezeigt, der bei Drücken auf ''set'' ausgeführt wird.
Hat man ein passendes ''template'' gefunden, wird mit <code>set <Device-Name> attrTemplate <template_name></code> angewendet, wodurch die entsprechenden, in dem ''template'' hinterlegten Kommandos ausgeführt werden.

== Syntax ==

{{Link2Forum|Topic=104804|Message=988100|LinkText=Hier}} hat Rudolf König die Syntax erläutert, die in den attrTemplate-Dateien verwendet werden kann:
* leere Zeilen werden ignoriert
* Zeilen die mit # anfangen sind Kommentare (s.u. ''desc:'')
* Zeilen, die mit einem der folgenden Schlüsselwörter beginnen, werden speziell interpretiert: ''name: filter: prereq: par: desc: farewell: order:''
** '''name:''' Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
** '''filter:''' devspec2array Ausdruck, der beschreibt, für welche Geräte dieses Template anwendbar ist. Wird erst beim "set ?" ausgeführt.
** '''prereq:''' ist entweder ein Perl-Ausdruck {}, oder ein ''devspec2array'', was genau ein Gerät spezifiziert. Wird beim Einlesen des template Files ausgeführt. Falls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt. Ist für sowas wie "setze zusätzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
** '''par:''' kann mehrfach vorkommen, Syntax: <code>par:<ParamaterName>:<Kommentar>:<Perl-Code></code>. ''Perl-Code'' versucht den Wert zu finden, falls nicht möglich (''return undef''), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ''ParameterName'' wird in jeder Befehlzeile ersetzt mit dem Wert. Zusätzlich: ''DEVICE'' wird mit dem Namen des Gerätes ersetzt, wird ''DEVICE'' (z.B. für Modulnamen) als Text benötigt, muß es ''escaped'' werden (z.B. MQTT2_\DEVICE).
** '''desc:''' Kommentar fuer <code>set attrTemplate help ?</code>. Die letzte Zeile mit # vor ''name:'' wird als ''desc:'' interpretiert, falls kein ''desc:'' vorhanden ist.
** '''farewell:''' wird zum Schluss als Dialog (oder Text in telnet) angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist.
** '''order:''' bestimmt die Reihenfolge, in der die Templates im [[FHEMWEB|Webfrontend]] angezeigt werden; falls nicht vorhanden, wird ''name:'' genommen.
* alle anderen Zeilen werden als auszuführende Befehle interpretiert, wenn man <code>set <Device-Name> attrTemplate TemplateName</code> ausführt.

==Eigene templates entwickeln==
Wer plant, mehrere gleichartige Geräte anzulegen, aber andere Einstellungen zu wählen, als sie in den vorhandenen templates enthalten sind, kann hierfür ebenfalls die attrTemplate-Funktion mit eigenen templates nutzen. Hierfür können die vorhandenen templates der im Unterverzeichnis ''fhem/FHEM/lib/AttrTemplate'' zu findenden Dateien als Basis dienen, Ihre templates speichern Sie einfach als neue Datei mit der Endung ''.template'' im selben Verzeichnis und lesen diese mit <code>{ AttrTemplate_Initialize() }</code> neu ein. Danach können Sie diese direkt verwenden.

Haben Sie ein template erstellt und möchten dieses teilen, erstellen Sie einfach einen Beitrag im entsprechenden Forenbereichen, für manche Module existieren auch spezielle Threads (siehe Linkliste unten)

==Links==
* {{Link2Forum|Topic=93370|LinkText=Ankündigung des Moduls im Forum}}
* [[MQTT2_DEVICE#attrTemplate|Wiki zu attrTemplate und MQTT2_DEVICE]] - enthält auch Links zu speziellen Threads für bestimmte Device-Typen
* {{Link2Forum|Topic=94495|LinkText=Thread für getestete Vorschläge (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=94494|LinkText=Thread für Fragen und Anregungen (MQTT2_DEVICE)}}.
* {{Link2Forum|Topic=97694|LinkText=Thread für HTTPMOD}}.
<references />
[[Kategorie:FHEM-Verwendung]]
[[Kategorie:HOWTOS]]

Blinken - Impulsgenerator mit variablem Tastgrad

2019-11-08T22:44:28Z

Maista: Code in <pre>

= Blinken - Impulsgenerator mit variablem Tastgrad =
== Import ==
Die folgende Definition kann als Testraum in die eigene FHEM-Installation ohne Seiteneffekte importiert werden, indem man auf das Pluszeichen oben links im Webinterface klickt. Falls dieses unsichtbar sein sollte, kann es z.B über den Style f18 sichtbar gemacht werden.
[[Datei:Import nach FHEM1.png|mini|Import nach FHEM Schritt 1]]
[[Datei:Importfenster.png|mini|Import nach FHEM Schritt 2]]

<pre>defmod Pulse MSwitch # MSwitch_Self pulsedevice 
attr Pulse MSwitch_Debug 0 
attr Pulse MSwitch_Delete_Delays 1 
attr Pulse MSwitch_Eventhistory 0 
attr Pulse MSwitch_Expert 1 
attr Pulse MSwitch_Extensions 1 
attr Pulse MSwitch_Help 1 
attr Pulse MSwitch_Ignore_Types "TYPE=MSwitch" 
attr Pulse MSwitch_Include_Devicecmds 1 
attr Pulse MSwitch_Include_MSwitchcmds 0 
attr Pulse MSwitch_Include_Webcmds 0 
attr Pulse MSwitch_Inforoom MSwitch 
attr Pulse MSwitch_Lock_Quickedit 1 
attr Pulse MSwitch_Mode Full 
attr Pulse MSwitch_Safemode 1 
attr Pulse readingList onpulse offpulse 
attr Pulse room 07_Pulse 
attr Pulse setList onpulse:00:00:01,00:00:02,00:00:03,00:00:04,00:00:05 offpulse:00:00:01,00:00:02,00:00:03,00:00:04,00:00:05 
attr Pulse webCmd on:off:onpulse:offpulse 
attr Pulse webCmdLabel ::ontime:offtime 
</pre>
<pre>defmod pulsedevice MSwitch # no_device 
attr pulsedevice MSwitch_Debug 0 
attr pulsedevice MSwitch_Eventhistory 0 
attr pulsedevice MSwitch_Help 0 
attr pulsedevice MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul 
attr pulsedevice MSwitch_Inforoom MSwitch 
attr pulsedevice MSwitch_Mode Dummy 
attr pulsedevice room 07_Pulse 
attr pulsedevice setList on off 
</pre>
<pre>setstate Pulse off 
setstate Pulse 2019-11-03 14:17:18 .Device_Affected MSwitch_Self-AbsCmd1,MSwitch_Self-AbsCmd2,pulsedevice-AbsCmd1,pulsedevice-AbsCmd2 
setstate Pulse 2019-11-03 14:21:52 .Device_Affected_Details MSwitch_Self-AbsCmd1#[NF]exec_cmd_1#[NF]no_action#[NF]ID#[sp]1#[NF]#[NF]delay1#[NF]delay1#[NF][Pulse#[dp]onpulse]#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]3#[ND]MSwitch_Self-AbsCmd2#[NF]exec_cmd_1#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF][Pulse#[dp]offpulse]#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]1#[NF]#[NF]0#[NF]0#[NF]4#[ND]pulsedevice-AbsCmd1#[NF]on#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[ND]pulsedevice-AbsCmd2#[NF]off#[NF]no_action#[NF]#[NF]#[NF]delay2#[NF]delay1#[NF][Pulse#[dp]onpulse]#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]2 
setstate Pulse 2019-11-03 12:31:25 .Device_Events no_trigger 
setstate Pulse 2019-11-03 12:31:25 .First_init done 
setstate Pulse 2019-11-03 12:31:25 .Trigger_cmd_off no_trigger 
setstate Pulse 2019-11-03 12:31:25 .Trigger_cmd_on no_trigger 
setstate Pulse 2019-11-03 12:31:25 .Trigger_off no_trigger 
setstate Pulse 2019-11-03 12:31:25 .Trigger_on no_trigger 
setstate Pulse 2019-11-03 12:31:25 .V_Check V2.00 
setstate Pulse 2019-11-03 14:18:43 .sortby show 
setstate Pulse 2019-11-03 12:31:25 Trigger_log off 
setstate Pulse 2019-11-03 14:21:24 last_activation_by manual 
setstate Pulse 2019-11-03 14:21:23 last_cmd 1 
setstate Pulse 2019-11-03 14:21:23 last_exec_cmd set Pulse exec_cmd_1 
setstate Pulse 2019-11-03 14:21:05 offpulse 00:00:05 
setstate Pulse 2019-11-03 14:19:18 onpulse 00:00:02 
setstate Pulse 2019-11-03 14:21:24 state off 
</pre>
<pre>setstate pulsedevice on 
setstate pulsedevice 2019-11-03 12:32:30 .Device_Affected no_device 
setstate pulsedevice 2019-11-03 12:32:30 .Device_Events no_trigger 
setstate pulsedevice 2019-11-03 12:32:30 .First_init done 
setstate pulsedevice 2019-11-03 12:32:30 .Trigger_cmd_off no_trigger 
setstate pulsedevice 2019-11-03 12:32:30 .Trigger_cmd_on no_trigger 
setstate pulsedevice 2019-11-03 12:32:30 .Trigger_off no_trigger 
setstate pulsedevice 2019-11-03 12:32:30 .Trigger_on no_trigger 
setstate pulsedevice 2019-11-03 12:32:30 .V_Check V2.00 
setstate pulsedevice 2019-11-03 12:32:30 Trigger_log off 
</pre>

== Inbetriebnahme ==
Der Testraum 07_Puls enthält zwei konfigurierte MSwitch-Geräte, die die beabsichtigte Funktion zusammen bewirken. Pulse enthält die Logik, Pulsedevice dient der Statusausgabe des Generators. Als einziges muss in Pulse eine Auslösezeit in die obere Zeile (switch MSwitch on + execute 'cmd1' at :) im Format hh:mm:ss geschrieben werden, um die Impulsfolge zu starten.

[[Datei:Pulse-Fenster-oben.png|mini|Pulse-Konfiguration 1. Teil]]
[[Datei:Pulse-Fenster2.png|mini|Pulse-Konfiguration 2. Teil]]
[[Datei:Pulsdevice.png|mini|Pulsdevice-Konfiguration]]

Nach der Auslösung liefert das Pulsdevice eine endlose konfigurierbare Folge von Rechtecksignalen. Pulsdevice im Testraum in Aktion:

[[Datei:Pulsdevice .png||Pulsdevice im Testraum in Aktion]]

== Funktionsbeschreibung ==
[[Datei:Kausakkette1.png|Trigger]] 
1. Auslösung des MSwitch-Gerätes 'Pulse' beim Erreichen der angegebenen Triggertime, 
2. Aktivieren des 1. Befehlszweiges 'cmd1' des MSwitch-Gerätes 'Pulse',

[[Datei:Kausakkette2.png|Geräteauswahl]] 
3. Auswahl betroffener Geräte: 'MSwitch_Self -> pulse' und 'pulsedevice', Erzeugung je eines 'device action'-Rahmens

[[Datei:Kausalkette3.png|Setzen der positiven Flanke des Rechtecksignals ]] 
4. unverzögertes Setzen des Status von 'pulsedevice' auf 'on', positive Flanke des Rechtecksignals

[[Datei:Kausalkette4.png|Negative Flanke des Ausgangssignals]] 
5. um die Länge von 'onpulse' verzögertes Rücksetzen des Status von 'pulsdevice', negative Flanke des Rechtecksignals

[[Datei:Kausalkette5.png|Pausenzeit]] 
6. um die Länge von 'offpulse' verzögertes Ausführen von 'Set exec_cmd_1', Verweis auf ID1, Pausenzeit vor nächstem Impuls

[[Datei:Kausalkette6.png|x]] 
5.???,

== Anpassung an eigene Anforderungen ==

Um eigene Geräte für die Ausgabe benutzen zu können, muss:

<code>Attribut Switch_Ignore_Types = TYPE=MSwitch</code> auf

<code>Attribut Switch_Ignore_Types = notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul</code>

geändert werden.

[[Datei:MSwitch Ignore Types geaendert.png|MSwitch_Ignore_Types geändert|938px]]

Um den Verlust von Konfigurationsdaten zu vermeiden, lässt man das quickedit verriegelt und fügt eigene Zielgeräte per 'edit list' hinzu.
[[Datei:Eigenes device.png|938px|Eigenes Device]]

Die Bestätigung mit 'modify Devices' erzeugt pro neuem Gerät einen 'device action'-Rahmen, in den die Konfiguration von 'pulsedevice' übernommen werden kann. 'Modify action' übernimmt.

[[Datei:Deviceaction uebernehmen.png|938px|Deviceaction übernehmen]]

Der zweite notwendige Action-Rahmen für das eigene Device wird per 'add action ..' erzeugt.

Das Attribut 'setlist' erlaubt die leichte Anpassung der auswählbaren Impuls- bzw. Pausenzeiten. Hier können auch Dezimalbrüche wie 0,5 angegeben werden.

[[Datei:Bei der Arbeit.png|bei der Arbeit]]

MSwitch

2019-11-08T22:36:47Z

Maista: Neuer Link

[[MSwitch]] ist ein Hilfsmodul, welches das Event- und/oder zeitgesteuerte Schalten von mehreren Devices oder das Ausführen von benutzerdefinierten Befehlssequenzen erlaubt. Hauptmerkmale sind die fast vollständige und die sehr umfangreiche Konfigurierbarkeit über das Webinterface.

{{Infobox Modul
|ModPurpose=MSwitch
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=98_MSwitch.pm
|ModOwner=Byte09}}

{{Randnotiz | RNTyp=y | RNText=Byte09: ''Die Grundidee zu MSwitch kam mir, weil ich bei der Arbeit mit FHEM für meinen Geschmack zu viele Module für die verschiedenen Aufgaben brauchte - zu allem Überfluss alle mit unterschiedlicher Syntax. Zwar ist DOIF hiervon ausgenommen (da hiermit wohl auch fast jede Aufgabe lösbar ist), aber ich konnte mich leider nicht daran gewöhnen und somit wurde jedes DOIF für mich zu einem echten Projekt. Was ich wollte war ein Modul, mit dem ich alles erledigen kann. Daher entschloss ich mich schon nach fast einem knappen Jahr FHEM-Nutzung mein eigenes Modul zu schreiben, welches diese Anforderung erfüllt. MSwitch beinhaltet die Funktionalität aller bisherigen Hilfsmodule wie z.B. Notify, Doif, Watchdog, Dummy,( ab Modulversion 2.2 auch Sequenz ) es lassen sich all deren Funktionen umsetzen.''

''MSwitch wird permanent - vorrangig nach meinen Bedürfnissen - weiterentwickelt, gerne nehme ich aber auch Anregungen von anderen Nutzern auf.''

[[Datei:1-2-3-4.png|rahmenlos]]
}}

== Grundsätzliche Überlegungen ==
{{Randnotiz | RNTyp=y | RNText=Will man mehrere Geräte als gleichzeitige Auslöser betreiben, so muss das Device GLOBAL gewählt und die entsprechenden Geräte angegeben werden (dies erzeugt höhere Systemlast und ist nur im Expert-Modus verfügbar).}}

1. Welches Gerät soll auslösen oder zu welcher Zeit soll eine Auslösung erfolgen?
[[Datei:MSwitch basic.svg|mini|240px|Stark vereinfachtes Struktogramm]]
Im Rahmen 1 des Webinterfaces lässt sich der Trigger (Auslöser) bzw. eine Zeitabhängigkeit konfigurieren:

** jedes Event aus dem Eventmonitor,
** triggerunabhängige Zeiten,
** triggerunabhängige Zufallszeiten,
** triggerunabhängige Intervalle,
** Kombinationen aus Triggern und Zeiten.

2. Welche Bedingungen sollen bei Auslösung erfüllt sein?
: Ersten Rahmen: Wenn diese Bedingungen erfüllt sind, werden Kommandos ausgelöst. Die Bedingungen werden im zweiten Teil des Webinterfaces eingegeben. Dabei unterscheidet das Modul zwischen zwei Kommando-Kanälen (cmd1 und cmd2) und den dazugehörigen Geräten.

3. Welche Kommandos sollen ausgelöst werden?
: Im vierten Rahmen des Webinterfaces werden dann die konkreten Kommandos eingegeben. Man wählt dabei aus einer Liste wie auf der Geräteseite Kommandos aus. FreeCmd erlaubt geräteunabhängige Kommandos, beispielsweise reinen Perl-Code.

4. Welche weiteren Bedingungen sollen noch gelten?
: Zusätzlich pro Gerät eine oder mehrere Instanzen des vierten Rahmens:
** ereignisgesteuerte Bedingungen,
** zeitgesteuerte Bedingungen,
** Verzögerungen,
** Wiederholungen etc.

==Definition und Einrichtung =={{Randnotiz | RNTyp=y | RNText=Alle relevante Einstellungen werden in Readings und/oder Hashes gespeichert. Daher stehen relevanten Daten ''nicht'' in der fhem.cfg! Vielmehr finden sich diese Daten in der Datei fhem.save. Die Speicherung erfolgt durch den Befehl Fhemsave.
}}
Das MSwitch-Modul ist ohne weitere Voraussetzungen nutzbar und wird in der aktuellen Version über FHEM Update verteilt. MSwitch kann mehrere Devices gleichzeitig schalten. Diese Schaltungen befinden sich in den zwei möglichen Zweigen entsprechend der Kommandos cmd1 und cmd2. Die einzelnen Devices jedes Zweiges können mit weiteren Schaltbedingungen versehen werden (zeit- oder ereignisgesteuert). Das define eines MSwitch Devices generiert lediglich eine 'leere Hülle':
:<code>define <name> MSwitch</code>
Es wird ein leeres Device angelegt, das dann komplett über das Webinterface konfigurierbar ist.

== Webinterface ==
MSwitch wird über das Webinterface eingerichtet. Es besteht aus vier Teilen. Änderungen in einem Abschnitt müssen auch dort gespeichert werden, bevor ein weiterer Teil bearbeitet wird, sonst gehen Änderungen verloren.{{Randnotiz | RNTyp=y | RNText=<code>attr <name> MSwitch_Help 1</code> führt dazu, dass im Modul selber eine sehr umfangreiche kontextsensitive Hilfe in Form von Fragezeichensymbolen angezeigt wird.}}

[[Datei:1-2-3-4.png|rahmenlos|Webinterface]]
=== Rahmen 1: Trigger Device und Trigger Time ===
==== Trigger Device ====
{{Randnotiz | RNTyp=y | RNText=Wenn das Attribut 'MSwitch_Expert' gesetzt ist kann man 'GLOBAL' auswählen. Dann werden '''alle''' von FHEM generierten Events durch das MSwitch Device weiterverarbeitet, eine weitere Begrenzung kann (und sollte) dann in einem folgenden Eingabefeld erfolgen, um die Systemlast zu reduzieren.
==== Trigger Device Global Whitelist ====
Damit kann die Liste eingehender Events weiter eingeschränkt werden. Sobald mindestens ein Eintrag vorhanden sind, werden nur noch Events der hier benannten Devices verarbeitet. Zulässig ind Devicenamen und DeviceTypen (z.B. TYPE=FS20). Mehrere Angaben sind durch Komma zu trennen.

Im unten gezeigten Beispiel wurde GLOBAL gewählt, weil nicht ein einzelnes Device, sondern eine Kombination aus zwei Geräten auslösen soll. Es werden alle Ereignisse betrachtet, wobei die Whitelist dann auf die Devices Schlafzimmer (ein Temperaturmessgerät) und Schlafzimmerfenster (ein [[HM-Sec-SCo Tür-Fensterkontakt, optisch|optischer Kontakt]]) einschränkt.}}In diesem Feld wird das Device per Dropdownfeld gewählt, dessen Events eine Aktion auslösen sollen.

[[Datei:MSwitchWebinterface1.png|400px|thumb|right|Webinterface, oben]]

==== Trigger Time ====
Trigger time bietet die Möglichkeit einer zeitabhängigen Steuerung. Dazu wird in die "at"-Zeile ein Termin in der Form [STUNDEN:MINUTEN|TAGE] eingetragen. Die Tage werden ab Montag von 1-7 gezählt. Mehrere Zeitvorgaben können direkt hintereinander geschrieben werden. Beispiele:
* <code>[17:00|1][18:30|23]</code> löst montags um 17 Uhr und dienstags sowie mittwochs um 18:30 Uhr aus.
* <code>[00:10*20:00-21:00]</code> führt den Schaltbefehl von 20 Uhr bis 21 Uhr alle 10 Minuten aus.
* <code>[?20:00-21:00]</code> schaltet zu einem zufälligen Zeitpunkt zwischen 20 und 21 Uhr einmalig.
* <code>[20:00|$we]</code> nur am Wochenende um 20:00 wird geschaltet.

==== Trigger Conditions ====

Optionale zusätzliche Bedingungen in diesem Feld gelten nur für auslösende Device Trigger. Trigger Times haben keinen Einfluss, es sei denn, das Attribut MSwitch_Condition_Time ist gesetzt. Man kann mit AND / OR verknüpfte Bedingungen für die Auslösung in an DOIF angelehnter Syntax angeben. Leere Felder werden ignoriert. Werden Readings mit Strings wie 'on' oder 'off' abgefragt, ist statt des Gleichheitszeichens "=" der Operator "eq" zu nutzen, der String muss in Anführungszeichen "" gesetzt werden. Beispiele:{{Randnotiz | RNTyp=y | RNText=Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (beispielsweise würde dann am Mittwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde).}}
* <code>[19:10-23:00] AND [Devicename:Reading] = 10</code> beide Bedingungen müssen erfüllt sein.
* <code>[19:10-23:00] OR [Devicename:Reading] eq "on"</code> eine der Bedingungen muss erfüllt sein.
* <code>[10:00-11:00|13]</code> schaltet Montag und Mittwoch zwischen 10 Uhr und 11 Uhr.
* <code>[{ sunset() }-23:00]</code> von Sonnenuntergang bis 23:00 Uhr.
* <code>{ !$we }</code> löst den Schaltvorgang nur Werktagen an aus.
* <code>{ $we }</code> löst den Schaltvorgang nur an Wochenenden, Feiertagen aus.
Es ist auf korrekte Eingabe der Leerzeichen zu achten.

=== Rahmen 2: Trigger Details ===
[[Datei:MSwitchWebinterface2.png|600px|thumb|right|Webinterface, Mitte]]
Der Inhalt des zweiten Rahmens wird mit dem gewählten Trigger aus dem ersten Rahmen initialisiert. Events können zugeordnet werden. Im Beispiel wird cmd1 ausgelöst, wenn das Fenster offen ist. Cmd2 wird bei Temperaturunterschreitung ausgelöst.

==== execute ====
Diese vier Zeilen legen fest, welches ankommende Event welchen Befehlszweig auslösen soll. Die Event-Drop-Down-Liste enthält alle empfangenen Events dieses Devices. Fehlende Events können manuell hinzugefügt werden.

* switch <MSwitch> on + execute 'cmd1' - MSwitch Statusänderung auf 'on'; cmd1 soll ausgeführt werden
* switch <MSwitch> off + execute 'cmd2' - MSwitch Statusänderung auf 'off'; cmd2 soll ausgeführt werden;
* execute 'cmd1' only - keine Statusänderung; cmd1 soll ausgeführt werden
* execute 'cmd2' only - keine Statusänderung; cmd2 soll ausgeführt werden

==== Save incomming events ====
Alle ankommenden Events der konfigurierten Geräte werden für die Dropdownlisten gespeichert. Nach erfolgreicher Konfiguration sollte diese Option entfernt werden, um die Datenmenge zu reduzieren. Falls das Device Events während der Konfiguration nicht liefert, können sie manuell als kommagetrennte Liste hinzugefügt werden.

==== add event ====
{{Randnotiz | RNTyp=y | RNText=Falls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden:
- * - alle auftretende Events des entsprechenden Device
- device:reading:wert (z.B. device:state:on ) - nur für das Event "device:state:on"
- device:reading:* (z.B. device:state:* ) - Events "device:state:(on,off,etc.)
- device:reading:(wert1/wert2/wert3) (z.b. device:state:(left/right) - Events "device:state:left" oder "devicestate:right" etc.

Das Device kann auch hier gegen "*" ersetzt werden (*:state:on). In diesem Fall erfolgt eine Aktion auf alle Events die z.B. "state:on" enthalten, egal welches Device triggert.
}}
* * - alle auftretende Events des entsprechenden Device
* reading:wert (z.B. state:on ) - nur auf das Event "state:on"
* reading:* (z.B. state:* ) - Events "state:(on,off,etc.)
* reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Events "state:left" oder "state:right" etc.
==== test event ====
Stehen Events zur Auswahl, kann die Konfiguration getestet werden. Durch Klick wird das Event simuliert und die dafür definierte Aktion ausgelöst.

==== apply filter to saved events ====
Beschreibung folgt???

==== clear saved event ====
Es werden die nicht als Trigger wirkenden Events aus der Liste gelöscht.

=== Rahmen 3: Affected devices ===
{{Randnotiz | RNTyp=y | RNText=In dem Auswahlfeld werden alle Devices angeboten, die eines der folgenden Kriterien erfüllen:
# Die Abfrage "set Device ?" liefert einen Befehlssatz
# Das Attribut 'webcmd' des Devices enthält Einträge
# Das Attribut 'MSwitch_Activate_MSwitchcmds' ist aktiviert und das Attribut 'MSwitchcmds' des betreffenden Devices enthält einen Befehlssatz

Einzige Ausnahme ist der erste Listeneintrag 'FreeCMD'. Die Auswahl dieses Eintrages bietet später die Möglichkeit Befehle auszuführen, die nicht an ein Device gebunden sind. Der Code in einem FreeCmd kann entweder reiner FHEM-Code sein ( set device on ) oder reiner Perl-Code. Wenn es sich um reinen Perl-Code handelt, ist dieser in geschweifte Klammen zu setzen { Perl-Code }.

}}
[[Datei:MSwitch_Screen_5.png|mini|rechts|affected devices]]
Auswahl der Devices, die auf die oben konfigurierten Events reagieren sollen. Um unbeabsichtigte Änderungen zu vermeiden ist die direkte Mehrfachauswahl gesperrt.

=== Rahmen 4: Device Actions ===

[[Datei:Webinterface3.png|mini|rechts|device_actions]]
Die auszuführenden Aktionen der im dritten Rahmen gewählten Geräte. Leere Felder werden ignoriert.

==== MSwitch cmd1/cmd2: ====
{{Randnotiz | RNTyp=y | RNText=Im Beispiel befindet sich ein FreeCmd, mit dem beliebige Kommandos eingetragen werden können. Im abgebildeten Beispiel ist dies sogar selbst definierter Perl-Code (die Funktion DebianMail sendet eine Mail).
}}
Man wählt den gewünschten Befehl aus den gespeicherten verfügbaren Möglichkeiten des betreffenden Device aus.

* Im Sonderfall FreeCmd wird der Befehl als String eingegeben.
* Das Attribut MSwitch_Extensions ergänzt die Schaltoption 'MSwitchToggle' in der Liste, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.

{{Randnotiz | RNTyp=y | RNText=Je nach Attribut-Einstellungen werden Einträge aus entsprechenden 'webcmds" oder 'MSwitchcmds' einbezogen. In Abhängigkeit des Befehls stehen unter Umständen weitere Felder oder Widgets zur Verfügung.
).
}}

==== cmd1/cmd2 condition ====

{{Randnotiz | RNTyp=y | RNText=Bei der Abfrage von Readings nach Strings (on, off, etc.) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden. Es ist auf korrekte Eingabe der Leerzeichen zu achten.
'''Achtung:''' Bei Anwendung der geschweiften Klammern zur Einleitung eines Perl Ausdrucks ist unbedingt auf die Leerzeichen hinter und vor der Klammer zu achten.

Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (zum Beispiel würde auch am Mittwoch noch der Schaltvorgang erfolgen, wenn als Tagesvorgabe Dienstag gesetzt wurde).
}}
Die Ausführung der Befehle kann '''pro gewählten Gerät''' analog Rahmen 1 von weiteren Bedingungen abhängig gemacht werden. Es gelten die gleichen Regeln und Beispiele wie im 'Rahmen 1 Trigger Conditions'. Sie können sinngemäß übernommen werden.

Die Variable <code>$EVENT</code> enthält den auslösenden Trigger. Wenn unter 'Rahmen 1 Trigger Conditions' ein Wildcard verwendet wurde, kann nun feingefiltert werden, indem das konkrete Ereignis angegeben wird.

Beispiel: <code>[$EVENT] eq "state:on"</code> würde den Kommandozweig nur dann ausführen, wenn der auslösende Trigger "state:on" war.

==== cmd1/cmd2 delay ====
Ein Eintrag in diesem Feld führt zur verzögerten Ausführung des Befehls nach Eintreffen des Events. Dabei kann der Befehl ohne weitere Prüfung der Bedingung ausgelöst werden. Es ist aber auch möglich, dass die Bedingung bei Ausführung erneut geprüft wird. Die Zeitangabe muss im Format hh:mm:ss vorliegen. Einzelheiten enthält auch das Funktions-Struktogramm.

Statt einer direkten Zeitangabe kann hier auch auf eine verwiesen werden, indem in der Form [NAME.reading] ein Reading eines Devices wie z.B. [dummy.state] angegeben wird.

==== add action ====
Mit diesem Button kann ein weiterer Rahmen 4 als Rahmen 4.1 für das gleiche Device angelegt werden, um z.B. einen weiteren Befehl gegebenenfalls zeitverzögert auszuführen.

==== delete this action ====
Mit diesem Button wird der gewählte Rahmen 4 für das Device gelöscht.

==== check condition ====
[[Datei:MSwitch_Screen_7.png|mini|rechts|check]]
Die angegebenen 'conditions' werden in Zusammenhang mit ggf. ausgewählten Devices auf Syntax und Ergebnis geprüft. Es erfolgt eine Ausgabe des Prüfungsergebnisses.

==== Repeat und Repeatdelay ====

Die Felder 'Repeats', 'Repeatdelay in s' und 'priority' stehen zur Verfügung, wenn das Attribut MSwitch_Expert gesetzt wurde. Diese bewirken eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung. Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.

== Erweiterte Konfiguration ==

=== Set-Befehle ===

{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|set active||Setzt das MSwitch-Device in den Status 'active'.
|-
|set inactive||Setzt das Device in den Status 'inactive'. Es werden keine Befehle mehr ausgeführt. Dieser Status entspricht dem Attribut 'disable', ist aber nicht mit dem roten Fragezeichen (fhem save) verbunden.
|-
|set on<nowiki>|</nowiki>off [<parameter>]||Setzt das Device in den Status 'on' oder 'off'. Alle Befehle der 'on/off-Zweige' werden ausgeführt. Optional kann den Befehlen 'on' und 'off' ein weiterer Parameter mit übergeben werden. Dieser wird im Reading 'Parameter' hinterlegt und es kann sofort in 'Freecmds' oder 'Conditions' darauf zugegriffen werden.
|-
|set reload_timer||Alle gesetzten Timer werden gelöscht und neu berechnet.
|-
|set change_renamed <oldname> <newname>||Sollten sich Devicenammen im ausführenden Teil geändert habe (affected Devices, Conditions, etc.) so kann das MSwitch mit diesem Befehl angepasst werden, ohne alle Einstellungen neu einstellen zu müssen.
|-
|set exec_cmd1 <nowiki>|</nowiki> set exec_cmd1 ID [<ID>]||Bewirkt das sofortige Ausführen des entsprechenden Befehlszweiges. Bei Angabe einer ID werden nur die Befehle mit der entsprechenden ID ausgeführt.
|-
|set MSwitch_backup||Erstellt eine Backup-Datei aller MSwitch Devices unter ./fhem/MSwitch_backup.cfg. Daten dieser Datei können im Bedarfsfall für einzelne oder gleichzeitig alle MSwitch Devices wieder zurückgespielt (hergestellt) werden.
|-
|set del_delays <nowiki>|</nowiki> set exec_cmd1 ID [<ID>]||Löscht alle anstehenden, verzögerten Befehle (delays).
|-
|set reset_cmd_count: 1<nowiki>|</nowiki>2||Löscht das entsprechende EVT_CMD_COUNT - Reading; entspricht damit einer Rückstellung auf '0'.
|-
|set fakeevent [<device>]:<reading>:<arg>||Beispiel: <device> fakeevent state:on 
Das MSwitch Device reagiert so, als wäre statt des internen "fakes-Befehls" ohne FHEM-Systembeeinflussung dieses Event tatsächlich vom triggernden Gerät generiert worden.

Der Name (<device>) muss bei GLOBALEN Triggern mit angegeben werden, sonst wird das Device automatisch gesetzt.
Um z.B. einen Watchdog zu realisieren ist es eventuell nötig, dass sich das MSwitch Device mit einem bestimmten Event selber neu triggert - ggf. mit einem entsprechenden Delay Affected Device. Bei dem Einsatz dieser Möglichkeit sollte das Attribut 'MSwitch_Safemode' UNBEDINGT aktiviert sein, da 'Experimente' hier schnell in einer Endlosschleife enden können, die nur durch ein Reboot unterbrochen werden kann. Möglicherweise steht dieser Befehl zukünftig nur noch zur Verfügung, wenn Safemode aktiviert ist.
|}

=== Get-Befehle ===

{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|get show_timer [<show><delete>]||
;Show
:Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
;Delete
:Löscht alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren. Schaltbefehle basierend auf rein zeitabhängigen Angaben werden neu berechnet und gesetzt.
|-
|get restore_MSwitch_data [<this_device><nowiki>|</nowiki><all_devices>]||
;this_device
:Stellt die Daten des Devices aus der Backupdatei wieder her, sofern diese in der Backupdatei gefunden werden (gesucht wird hier nach dem Namen des Devices).
;all_devices
:Stellt die Daten aller MSwitch Devices wieder her, sofern diese in der Backupdatei vorhanden sind. Diese Aktion kann einige Zeit in Anspruch nehmen und wird daher im Hintergrund (nonblocking) ausgeführt. Nach Beendigung erfolgt eine Benachrichtigung.
Die Devices sind nach einem Restore funktionsfähig. Empfohlen wird ein Neustart von FHEM..
|-
|get_config||Zeigt die Konfigurationsdatei des MSwitchdevices an; diese kann in dem Fenster editiert werden. Das sollte nur von erfahrenen Usern getan werden! Im Normalfall sollte das Device nur über die Weboberfläche konfiguriert werden und eine falsche Konfiguration kann hier zu einem FHEM Absturz führen.
|-
|get_support_info||Öffnet ein Fenster mit einer formatierten Ansicht aller Einstellungen des Devices. Bei Supportanfragen sollte dieses immer mit geposted werden.
|-
|get_MSwitch_preconf||Lädt vorkonfigurierte MSwitch-Devices. Diese Option ist nur dann vorhanden, wenn das Aktualisieren dieser vorkonfigurierten Devices im FHEM Update aktiviert ist.
Diese kann durch ein einmaliges Update erfolgen mit:
:<code>update all https://raw.githubusercontent.com/Byte009/MSwitch_Addons/master/controls_mswitchaddons.txt</code>
|}

=== Attribute ===
{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|MSwitch_Debug <0<nowiki>|</nowiki>1<nowiki>|</nowiki>2<nowiki>|</nowiki>3<nowiki>|</nowiki>4>||
0 - Abgeschaltet 
1 - Schaltet Felder zum testen der Conditionstrings an 
2 - Alle ausgehenden Befehle werden nur simuliert und nicht ausgeführt. Der Inhalt der Protokolldatei wird direkt im Device angezeigt 
3 - Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt. 
4 - erweitertes Debugfür Entwickler mit wechselnden Funktionen 
|-
|MSwitch_Expert <0<nowiki>|</nowiki>1>||
* In der Liste der möglichen Trigger erscheint das Selectfeld 'GLOBAL'. Dieses ermöglicht das Setzen eines Triggers auf alle Events und damit nicht nur auf einzelne Devices. In einem weiteren Feld kann eine weitere Selektion der triggernden Events erfolgen.

* Die Felder 'Repeats' und 'Repeatdelay in s' stehen zur Verfügung. Dies bewirkt eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung.

* Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.
|-
|MSwitch_Sequenz <Suchmuster> ??? ||
Eine Schaltsequenz kann durch ein oder mehrere durch '/' getrennte Suchmuster angegeben werden. Die Angabe muss folgende Syntax haben:
:<code>Device1:reading1:event1 Device1:reading1:event1-2 Device1:reading1:event1-3/..../....</code>

Beispiel: <code>Dummy:state:on Dummy:state:off Dummy:state:on</code>

Erkennt das Device dieses Suchmuster in den Schaltvorgängen des Devices (Dummy), wird das Reading "SEQUENCE" auf "match" gesetzt, das Reading "SEQUENCE_NUMBER" auf die Nummer der gefundenen Sequenz, wenn es mehrere Suchmuster gibt. Beide Readings können in den "Conditions" eines Schaltbefehles abgefragt werden. Eine Angabe muss in folgendem Format gemacht werden:
:<code>on/off/state/suchmuster1/suchmuster2</code>, wobei die letzten drei Angaben optional sind.

Funktion: Bei Ausführung des Befehls wird das Gerät 'on' oder 'off' geschaltet (on/off), Voraussetzung ist, dass der 'state' dieses Gerätes auch den 'state on' oder 'off' annimmt. Sollte dieses nicht der Fall sein, so kann mit dem Feld 'state' angegeben werden, in welchem Reading der aktuelle Status vorkommt und wie dieser lautet (suchmuster1/suchmuster2). Dieses 'state' kann mehrere Angaben enthalten, das Vorkommen der Suchmuster ist aber Voraussetzung.
|-
|MSwitch_Sequence_time <Zeit in Sekunden>||Maximalzeit in Sekunden, um eine Sequenz vollständig auszuführen. (Was wenn diese Zeit überschritten wird???)
|-
|MSwitch_Extensions <0<nowiki>|</nowiki>1>||Es wird zusätzlich zu 'on' und 'off' die Schaltoption 'MSwitchToggle' in der Liste angeboten, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.
|-
|MSwitch_Delete_Delays <0<nowiki>|</nowiki>1>||Eins bewirkt das Löschen aller anstehende Delays bei dem Auftreten eines erneuten passenden Events. Bei der Option '0' bleiben bereits gesetzte Delays aus einem vorher getriggerten Event erhalten und werden ausgeführt. Empfohlene Einstellung: 1
|-
|MSwitch_Include_Devicecmds <0<nowiki>|</nowiki>1>||Bewirkt die Aufnahme aller Devices die bei Abfrage mit 'set DEVICE ?' einen eigenen Befehlssatz liefern in die Auswahlliste 'Affected Devices'. Bei Option '0' werden diese Devices in der Liste nicht mehr angeboten. Empfohlene Einstellung: 1
|-
|MSwitch_Include_Webcmds <0<nowiki>|</nowiki>1>||Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut Webcmd hinterlegt haben. Die in Webcmd hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, es sei denn, sie liefern mit 'set DEVICE ?' einen eigenen Befehlssatz. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
|-
|MSwitch_Activate_MSwitchcmds <0<nowiki>|</nowiki>1>||Fügt jedem vorhandenen Device das Attribut 'MSwitchcmd' hinzu.
|-
|MSwitch_Include_MSwitchcmds <0<nowiki>|</nowiki>1> ||Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut MSwitchcmds hinterlegt haben. Die in MSwitchcmds hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz mit 'set DEVICE ?' liefern. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
|-
|MSwitch_Lock_Quickedit <0<nowiki>|</nowiki>1>||Voreinstellung für die Auswahlliste 'Affected Devices'. Bei der Option '1' ist diese voreingestellt gesperrt und kann nur über einen zusätzlichen Button geändert werden, um versehentliche Änderungen zu vermeiden. Die Auswahl einer Option ohne betätigte <Strg>-Taste bewirkt das Löschen aller bereits gesetzten Optionen. Empfohlene Einstellung: 1
|-
|MSwitch_Startdelay <0<nowiki>|</nowiki>10<nowiki>|</nowiki>20<nowiki>|</nowiki>30<nowiki>|</nowiki>60> ||MSwitch ignoriert nach einem FHEM-Neustart für die angegebene Zeit in Sekunden alle eingehenden Events um u.a. Startverzögerungen zu vermeiden. Bei nicht gesetztem Attribut gilt hier eine Zeit von 30 Sekunden. Diese sollte auch nur in Ausnahmefällen geändert werden. Empfohlene Einstellung: 30
|-
|MSwitch_Ignore_Types||Beinhaltet eine durch Leerzeichen getrennte Liste von Device-''Typen'' welche nicht geschaltet werden oder nicht geschaltet werden können. Sie werden dann in den Auswahllisten ''nicht'' dargestellt, um die Auswahllisten übersichtlich zu halten.Voreinstellung: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul.

???Wenn statt des Devicetyps ein devspec z.B. "TYPE=watchdog" angegeben wird, ist zu beachten, dass alle Geräte in die Ignoreliste einbezogen werden, die NICHT der devspec entsprechen. Weiterhin muss die devspec in Anführungszeichen gesetzt werden!???

|-
|MSwitch_Trigger_Filter ||Beinhaltet eine kommagetrennte Liste von Events, die im Falle ihres Eingangs unberücksichtigt und ungespeichert bleiben. Wildcards wie '*' können angegeben werden. Empfohlene Einstellung: -
|-
|MSwitch_Wait <n in Sekunden>||Bei gesetztem Attribut nimmt das MSwitch Device für den eingestellten Zeitraum keine Befehle mehr entgegen und ignoriert eingehende Events.

|-
|MSwitch_Event_Id_Distributor||??? Voraussetzung ist, dass das Attribut 'MSwitchExpert' auf '1' gesetzt ist. Es können auslösende Events auf ID-Aktionen umgeleitet werden. Sollte bei den 'trigger details :' in einem Zweig ( cmd1 ) z.B. auf mehrere Events getriggert werden (regex z.B. state:(on|off)) so werden für beide Events jeweils der Zweig 'cmd1' - alle Aktionen ohne ID - ausgeführt. Durch entsprechende Einträge kann für entsprechende Events auf eine Aktion umgeleitet werden, für die eine ID definiert ist. Die Syntax lautet: <code>state:on=>cmd1 ID 1,2</code> Entsprechend werden bei auslösendem Event 'state:on' nur die Aktionen aus cmd1 mit den IDs 1 und 2 ausgeführt. Mehrere Angaben sind durch new Line zu trennen. ???

|-
|MSwitch_Selftrigger_always <0<nowiki>|</nowiki>1> ||(dieses Attribut steht ab Modulversion 2.5 zur Verfügung)

Die Aktivierung dieses Attributes '1' bewirkt, dass alle SET Aktionen des Devices einen internen Event ohne Auswirkungen auf das FHEM-System auslösen, auf die das Device selber reagiert. Diese Option kann zusätzlich zu einem vorhandenen Trigger aktiviert werden. Auftretende auswertbare interne Events haben immer folgendes Format:
MSwitch_Self:aktion:wert
MSwitch_Self:pct:100
Es werden nur interne Events für set-Aktionen ausgelöst, die im Attribut setlist hinterlegt sind. Der 'wait' Befehl/Attribut hat keine wirkung.
|-
|MSwitch_Mode <Notify<nowiki>|</nowiki>Full<nowiki>|</nowiki>Toggle<nowiki>|</nowiki>Dummy> ||Schaltet das Modul zwischen angepassten Weboberflächen-Modi um.

Notify
Das Device kann nicht manuell umgeschaltet werden. Es gibt nur die zwei ausführbaren Zweige "execute 'cmd1' commands" und "execute 'cmd2' commands". Der Status des Devices wird nicht als 'on' oder 'off' angezeigt, sondern lediglich als 'active' Dieser Mode ist ähnlich zu einem FHEM-Notify.

Full
Es stehen alle Funktionen zur Verfügung.
Toggle
Sehr vereinfachter Mode. Es stehen keine verschiedenen Zweige zur Verfügung. Hier ist das Device manuell schaltbar und wird bei jedem definierten Event 'umgeschaltet', ??? entsprechend definierte Befehle für 'cmd1' oder 'cmd2' werden ausgeführt. ???
Dummy
ACHTUNG: Funktionsänderung mit V2.61 Der Mode 'Dummy' ist ein eingeschränkter Modus. Dieser bietet die Funktionalität eines Dummys kombiniert mit der Funktionalität eines Notifys und kann somit die gerne genutzte Kombination Dummy-Notify gegen ein Device ersetzen. Der Dummy-Mode kann nur in einem neu angelegten leeren MSwitch aktiviert und auch nicht wieder verlassen werden! Sobald ein angelegtes MSwitch einmal verändert wurde (modify trigger etc.) sind Umschalt-Optionen nicht mehr verfügbar.

|-
|MSwitch_Condition_Time <0<nowiki>|</nowiki>1> ||In der Grundeinstellung '0' werden für das zeitgesteuerte Schalten keine definierten Conditionen im Feld 'Trigger condition' überprüft, sondern die Schaltbefehle werden in jedem Fall ausgeführt. Mit der Einstellung '1' wird diese Überprüfung wie für Events zugeschaltet.

|-
|MSwitch_Random_Time <HH:MM:SS-HH:MM:SS> || Bei Aktivierung wird vor jedem Ausführen eines verzögerten Befehls (Delay) eine Zufallszeit generiert, die im Rahmen der hier angegebenen Zeitspanne liegt. Auf diese Zufallszahl kann in den Delays zugegriffen werden, durch die Angabe '[random]' statt einer direkten Zeitangabe. Bei nicht gesetztem Attribut ergibt die Angabe von '[random]' immer '00:00:00'

|-
|MMSwitch_Random_Number <n> ||Bei Aktivierung dieses Attributes mit einer beliebigen ganzen Zahl, werden vom Device die zwei Readings 'RandomNr' und 'RandomNr1' und mit Werten zwischen null und n angelegt. RandomNr wird vor jedem Ausführen eines Befehls, auch für unterschiedliche Geräte in einem Durchgang, neu generiert. RandomNr1 bleibt nach der Initialisierung konstant. Wenn auf dieses Readings in einer Condition mit z.B. '[$NAME:ReadingNr1] = 1' zugegriffen wird, wird der Befehl nur ausgeführt, wenn ReadingNr1 gerade = 1 ist. Der Befehl wird somit nur mit einer Wahrscheinlichkeit von eins zu n ausgeführt.

|-
|MSwitch_Reset_EVT_CMD1(2)_COUNT ||Bei Aktivierung dieses Attributes steht in den Readings das Reading 'EVT_CMD1_COUNT' bzw. 'EVT_CMD2_COUNT' zur Verfügung. Dieses kann in den Conditions genutzt werden, um z.B. nur bei jedem x-ten Eintreffen eines auslösenden Events einen Befehl auszuführen. Bei jedem Eintreffen eines gültigen Events werden die Zähler um 1 erhöht (für den jeweiligen Zweig). Ist hier der Wert '0' eingetragen, wird der Zähler fortlaufend (endlos) erhöht. Wird ein Wert größer 0 eingetragen, wird der Zähler mit Erreichen dieses Wertes automatisch wieder auf Null gesetzt. Mit Löschen dieses Attributes werden die entsprechenden Readings ebenfalls gelöscht.

|-
|MSwitch_Safemode <0<nowiki>|</nowiki>1> ||Bietet einen gewissen Schutz vor falschen Konfigurationen und dadurch entstehenden Endlosschleifen. Bei aktiviertem Attribut '1' beendet das Modul Endlosschleifen eines Devices. In diesem Fall erfolgt ein Logeintrag und das Device wird per Attribut auf 'Disabled' gesetzt. Es wird ein letztes Event generiert, auf das reagiert werden kann <code>2018-05-31 09:39:21 MSwitch <NAME> Safemode: on</code> Im Webinterface erfolgt bei betroffenem Device ein entsprechender Hinweis. In der Grundkonfiguration ist dieses Attribut nicht gesetzt. Es empfiehlt sich aber, bei neuen bzw. komplizierten Devices, dieses zumindest anfänglich zu aktivieren.
|-
|MSwitch_Read_Log<0<nowiki>|</nowiki>1> ||Ermöglicht den Zugriff auf das Logfile als Trigger.

* Bei aktiviertem Attribut enthält die Auswahl des Triggerdevices die Option 'LOGFILE'. Bei dieser Auswahl werde alle Logeinträge erkannt und in ein internes Event umgewandelt, auf das regiert werden kann.
* bei aktiviertem Attribut und der Auswahl 'GLOBAL' im 'Trigger_Device' wird auf ALLE Events und alle Logeinträge reagiert.
* bei aktiviertem Attribut und der Auswahl eines bestimmten Devices im 'Trigger_Device' wird auf alle Events und auf alle Logeinträge des gewählten Devices reagiert. Der im Logeintrag vorhandene Devicename ist Bedingung für die Funktion.
|-
|MSwitch_Help<0<nowiki>|</nowiki>1> ||Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.

|-
|MSwitch_Comments<0<nowiki>|</nowiki>1> ||Schaltet Kommentarfelder zu den einzelnen 'affected_devices an.

|-
|MSwitch_generate_Events<0<nowiki>|</nowiki>1> ||Reduziert bei Einstellung '1' die vom MSwitch-Devices erzeugten Events auf ein Minimum. Insbesondere bei Verwendung von 'MSwitch_Read_Log' zu empfehlen.

|-
|MSwitch_Startdelay||???Bestimmt die Verzögerungszeit des MSwitches nach FHEM-Start in Sekunden. In diesem Zeitraum reagiert das Device nicht auf Events. Die Vorgabe ist hier zehn Sekunden. Diese wird auch dann angenommen, wenn das Attribut nicht gesetzt ist.??? (Hatten wir das nicht schon?)

|-
|MSwitch_Inforoom ||Mit diesem Attribut wird die Raumansicht eines mit dem Attribut bestimmten Raumes verändert. Dadurch sollen die wichtigsten Informationen aller MSwitch-Devices auf eine Seite dargestellt werden. Zur Nutzung sollten alle MSwitch-Devices (zusätzlich) in einen Raum sortiert werden und dieser Raum im Attribut eingestellt werden.

Wichtig: Eine Änderung dieses Attributes bewirkt immer eine Änderung dieses Attributes in ''allen'' MSwitch devices: Es muss nur in einem Device gesetzt oder gelöscht werden um alle Devices zu erfassen.

<gallery>
MSwitch_Screen_1.png|Raumansicht des Raumes MSwitch mit gesetztem Attribut 'MSwitch'
MSwitch_Screen_2.png|Raumansicht des Raumes MSwitch ohne gesetztes Attribut
</gallery>

Es werden folgende Informationen bereitgestellt:
* Infobutton zeigt den im Device gespeicherten Textes des Attributes 'comment'
* Device und Events, die das Device triggern
* Zeiten, zu denen verschiedene Zweige des Devices ausgeführt werden
* Devices, die durch das MSwitch Device geschaltet werden
* State des Devices

|}

== Integrierte Funktionen ==

{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|Average||???
|-

|Difference||
* Syntax: [DIFF<wert>:<reading>] > <differenz>
* Beispiel: [DIFF2:countdown] > 0
* Reading: entspricht dem getriggerten Reading.
* Wert: gespeicherter Wert (in diesem Fall der vorletzte).
* Differenz: geforderte Differenz zwischen aktuellem und vorletztem Wert.
* Schaltung erfolg wenn diese Bedingung 'wahr' ist.
Folgende Readings werden zur Verfügung gestellt:
* DIFFERENCE (true/false) - Schaltbedingung erkannt ja/nein
* DIFFDIRECTION (up/down) - Richtung der erkannten Bedingung (steigend/fallend)
|-
|Increase||???
|-
|Tendency||
*Syntax: [TEND<wert>:<reading>] > <Mindestwert>
*Beispiel: [TEND2:countdown] > 2
*Reading: entspricht dem getriggerten Reading.
*Wert: Es wird jeweils der Durchschnitt von 2 Wertepaaren gebildet. In diesem Fall werden die letzten 4 Werte herangezogen. Paar 1 = Aktueller und letzter Wert, Paar 2 = Die 2 vorherigen Werte. Bei TEND3 werden die letzten 6 Werte zur Paarbildung genutzt.
*Mindestwert: Der Wertunterschied zwischen den Wertepaaren, der minimal erreicht sein muss, um eine Tendenz zu erkennen.

Rechenzeichen (><):
Dieses ist hier nicht als Rechenzeichen zu werten, sonder als Tendenz-Anzeige. ( < es wird nach fallender Tendenz gesucht / > sucht nach steigender Tendenz).

Schaltung erfolgt einmalig bei Erkennung der gesuchten Tendenz.
Danach erfolgt keine Schaltung mehr, solange bis eine Tendenz-Umkehr erfolgt ist.
Erst dann erfolgt wieder eine Schaltung bei erneuter Tendenz-Umkehr in gesuchte Richtung.
|}

== Funktions-Struktogramm ==
[[Datei:MSwitch full.svg|Struktogramm des Funktionsprinzips]]

== Anwendungs-Beispiele ==

=== [[Blinken - Rechteckgenerator]] ===
=== [[Blinken - Impulsgenerator mit variablem Tastgrad]] ===
=== [[Linearschalter]] ===

== Links ==
* Thread über das Modul im {{Link2Forum|Topic=86199|LinkText=FHEM Forum}}
* {{Link2Forum|Topic=100119|Message=936495|LinkText=Gäste-WLAN der Fritzbox auswerten und Login per Telegram senden}}
* {{Link2Forum|Topic=86199|Message=930133|LinkText=Schalten von vier Kanälen mit einem MSwitch-Device}}
* {{Link2Forum|Topic=99219|Message=926652|LinkText=Batterie-Überwachung. 1xTäglich per Telegram senden}}
* {{Link2Forum|Topic=101091|Message=945389|LinkText=Licht (Alarm) in einem bestimmten Zeitraum schalten}}
* {{Link2Forum|Topic=100949|Message=944284|LinkText=Über Dummy-Schalter ein Timer (EIN/AUS) aktivieren}}
* {{Link2Forum|Topic=103083|Message=967710|LinkText=Ladezeit von Akku ermitteln u. Steckdose entsprechend schalten}}
* {{Link2Forum|Topic=86199|Message=990265|LinkText=Bewegungsmelder}}

MSwitch

2019-11-01T20:15:46Z

Maista: /* MSwitch_Startdelay */

[[MSwitch]] ist ein Hilfsmodul, welches das Event- und/oder zeitgesteuerte Schalten von mehreren Devices oder das Ausführen von benutzerdefinierten Befehlssequenzen erlaubt.

Die Stärke bzw. das Unterscheidungsmerkmal dieses Moduls liegt in der Konfigurierbarkeit über ein Webinterface. Diese Konfiguration kann jederzeit geändert oder erweitert werden.

Byte09: ''Die Grundidee zu MSwitch kam mir, weil ich bei der Arbeit mit FHEM für meinen Geschmack zu viele Module für die verschiedenen Aufgaben brauchte - zu allem Überfluss alle mit unterschiedlicher Syntax. Zwar ist DOIF hiervon ausgenommen (da hiermit wohl auch fast jede Aufgabe lösbar ist), aber ich konnte mich leider nicht daran gewöhnen und somit wurde jedes DOIF für mich zu einem echten Projekt. Was ich wollte war ein Modul, mit dem ich alles erledigen kann. Daher entschloss ich mich schon nach fast einem knappen Jahr FHEM-Nutzung mein eigenes Modul zu schreiben, welches diese Anforderung erfüllt. MSwitch beinhaltet die Funktionalität aller bisherigen Hilfsmodule wie z.B. Notify, Doif, Watchdog, Dummy,( ab Modulversion 2.2 auch Sequenz ) es lassen sich all deren Funktionen umsetzen.''

''MSwitch wird permanent - vorrangig nach meinen Bedürfnissen - weiterentwickelt, gerne nehme ich aber auch Anregungen von anderen Nutzern auf.''

{{Infobox Modul
|ModPurpose=MSwitch
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=98_MSwitch.pm
|ModOwner=Byte09}}

== Grundsätzliche Überlegungen ==
Um das Modul zu nutzen, muss man zuerst folgende Fragen beantworten:

* Welches Gerät soll auslösen oder zu welcher Zeit soll eine Auslösung erfolgen.
: Dies ist der Trigger. Jedes Event aus dem Eventmonitor kann als Trigger dienen. Will man mehrere Geräte als gleichzeitige Auslöser betreiben, so muss das Device GLOBAL gewählt und die entsprechenden Geräte angegeben werden (dies erzeugt höhere Systemlast und ist nur im Expert-Modus verfügbar). Weiterhin kann auch zu fest definierten Zeiten, Zufallszeiten oder Intervallen, unabhängig von einem Trigger, geschaltet werden; auch eine Kombination beider Varianten ist möglich. Diese Einstellungen erfolgen im ersten Teil des Webinterfaces.

* Welche Bedingungen sollen bei Auslösung erfüllt sein?
: Wenn diese Bedingungen erfüllt sind, werden Kommandos ausgelöst. Die Bedingungen werden im zweiten Teil des Webinterfaces eingegeben. Dabei unterscheidet das Modul zwischen zwei Kommando-Kanälen (cmd1 und cmd2) und den dazugehörigen Geräten.

* Welche Kommandos sollen ausgelöst werden?
: Im dritten Teil des Webinterfaces werden dann die konkreten Kommandos eingegeben. Typischerweise wählt man dabei aus einer Liste der Kommandos aus, die die zugehörigen Geräte insgesamt aufweisen (also so, wie man auf den Geräteseiten selber Kommandos auswählt). Es gibt zudem ein so genanntes FreeCmd, das ein Geräteunabhängiges Kommando zulässt, beispielsweise reinen Perl-Code.

* Welche weiteren Bedingungen sollen noch gelten?
: Hier sind Ereignisgesteuerte wie auch Zeitgesteuerte Bedingungen möglich. Diese Bedingungen werden auch in dem dritten Teil des Webinterfaces eingetragen. So sind Verzögerungen und Wiederholungen und weitere Bedingungen möglich.

== Voraussetzungen, Installation und Grundbefehle ==
Das MSwitch-Modul ist ohne weitere Voraussetzungen nutzbar und wird derzeit in der Version 2.08 über FHEM Update verteilt.

=== Definition und Einrichtung ===
Mit Hilfe von MSwitch kann man mehrere Devices gleichzeitig schalten. Diese Schaltungen befinden sich in zwei möglichen Zweigen bei MSwitch. Dabei unterscheidet man im Modul zwischen den beiden Kommandos cmd1 und cmd2. Die zu einem Kommando gehörenden Geräte werden wir auch Zweig nennen. Die einzelnen Devices jedes Zweiges können mit weiteren Schaltbedingungen versehen werden (zeit- oder ereignisgesteuert).

Folgende Möglichkeiten zum definieren des MSwitch Devices stehen zur Verfügung:
:<code>define <name> MSwitch</code>
Es wird ein leeres Device angelegt, das dann komplett über das Webinterface konfigurierbar ist.

Das define eines MSwitch Devices generiert lediglich eine 'leere Hülle'. Alle relevante Einstellungen werden in Readings und/oder Hashes gespeichert. Daher stehen relevanten Daten ''nicht'' in der fhem.cfg! Vielmehr finden sich diese Daten in der Datei fhem.save (die Speicherung erfolgt durch den Befehl Fhemsave).

=== set-Befehle ===
Es sind derzeit die folgenden set-Befehle implementiert.

==== set active ====
Setzt das Device in den Status 'active'.

==== set inactive ====
Setzt das Device in den Status 'inactive', es werden keine Befehle mehr ausgeführt. Dieser Status entspricht dem Attribut 'disable', ist aber nicht mit dem roten Fragezeichen (fhem save) verbunden.

==== set on/off [<parameter>]====
Setzt das Device in den Status 'on' oder 'off'. Alle Befehle der 'on/off-Zweige' werden ausgeführt.
Optional kann den Befehlen 'on' und 'off' ein weiterer Parameter mit übergeben werden. Dieser wird im Reading 'Parameter' hinterlegt und es kann sofort in 'Freecmds' oder 'Conditions' darauf zugegriffen werden.

==== set reload_timer ====
Alle gesetzten Timer werden gelöscht und neu berechnet.

==== set change_renamed <oldname> <newname> ====
Sollten sich Devicenammen im ausführenden Teil geändert habe (affected Devices, Conditions, etc.) so kann das MSwitch mit diesem Befehl angepasst werden, ohne alle Einstellungen neu einstellen zu müssen.

==== set exec_cmd1 / set exec_cmd1 ID [<ID>] ====
Bewirkt das sofortige Ausführen des entsprechenden Befehlszweiges. Bei Angabe einer ID werden nur die Befehle mit der entsprechenden ID ausgeführt.

==== set MSwitch_backup ====
Erstellt eine Backup-Datei aller MSwitch Devices unter ./fhem/MSwitch_backup.cfg.

Daten dieser Datei können im Bedarfsfall für einzelne oder gleichzeitig alle MSwitch Devices wieder zurückgespielt (hergestellt) werden.

==== set del_delays ====
Löscht alle anstehenden, verzögerten Befehle (delays).

==== set reset_cmd_count:1,2 ====
Löscht das entsprechende EVT_CMD_COUNT - Reading (entspricht Rückstellung auf '0').

==== set fakeevent [<device>]:<reading>:<arg> ====
Beispiel: <device> fakeevent state:on 

Ob der Name (<device>) angegeben werden muss, oder nicht, ist abhängig davon, ob auf ein einzelnes Device, oder GLOBAL getriggert wird. Bei GLOBALEN Triggern muss das Device mit angegeben werden. Wird auf ein Device getriggert, so wird das Device automatisch gesetzt.

Mit diesem Befehl kann das MSwitch Device neu getriggert werden, indem hier ein Event 'gefaked' wird. Das MSwitch Device reagiert dann so, als wäre dieses Event vom getriggerten Gerät generiert worden.

Dieses kann nötig sein, um z.B. einen Watchdog zu realisieren, in dem es nötig ist, dass sich das MSwitch Device mit einem bestimmten Event selber neu triggert - ggf. mit einem entsprechenden Delay (affected Device muss dafür u.A. des MSwitch Device selber sein).

Es wird hierbei KEIN echtes Event generiert welches das System beeinflusst, sondern ausschließlich ein MSwitch-Interner Befehl umgesetzt!

Bei dem Einsatz dieser Möglichkeit sollte das Attribut 'MSwitch_Safemode' UNBEDINGT aktiviert sein, da 'Experimente' hier schnell in einer Endlosschleife enden können, die nur durch ein Reboot unterbrochen werden kann.

Ggf. werde ich hier sogar eine entsprechende Änderung vornehmen, dass dieser Befehl nur zur Verfügung steht, wenn Safemode aktiviert ist.

=== get-Befehle ===
==== get show_timer [<show><delete>] ====
;Show
:Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
;Delete
:Löscht alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren. Schaltbefehle basierend auf rein zeitabhängigen Angaben werden neu berechnet und gesetzt.

==== get restore_MSwitch_data [<this_device><all_devices>] ====
;this_device
:Stellt die Daten des Devices aus der Backupdatei wieder her, sofern diese in der Backupdatei gefunden werden (gesucht wird hier nach dem Namen des Devices).
;all_devices
:Stellt die Daten aller MSwitch Devices wieder her, sofern diese in der Backupdatei vorhanden sind. Diese Aktion kann einige Zeit in Anspruch nehmen und wird daher im Hintergrund (nonblocking) ausgeführt. Nach Beendigung erfolgt eine Benachrichtigung.

Die Devices sind nach einem Restore funktionsfähig. Empfohlen wird ein Neustart von FHEM.

==== get_config ====
Zeigt die Konfigurationsdatei des MSwitchdevices an; diese kann in dem Fenster editiert werden. Das sollte nur von erfahrenen Usern getan werden! Im Normalfall sollte das Device nur über die Weboberfläche konfiguriert werden und eine falsche Konfiguration kann hier zu einem FHEM Absturz führen.

==== get_support_info ====
Öffnet ein Fenster mit einer formatierten Ansicht aller Einstellungen des Devices. Bei Supportanfragen sollte dieses immer mit geposted werden.

==== get_MSwitch_preconf ====
Lädt vorkonfigurierte MSwitch-Devices. Diese Option ist nur dann vorhanden, wenn das Aktualisieren dieser vorkonfigurierten Devices im FHEM Update aktiviert ist.

Diese kann durch ein einmaliges Update erfolgen mit:
:<code>update all https://raw.githubusercontent.com/Byte009/MSwitch_Addons/master/controls_mswitchaddons.txt</code>

== Webinterface ==
MSwitch wird im Wesentlichen über das Webinterface eingerichtet. Wählt man das folgende Attribut
:<code>attr <name> MSwitch_Help 1</code>
so wird im Modul selber eine sehr umfangreiche Hilfe angezeigt. Über das gesamte Webinterface hinweg erscheinen kleine Fragezeichen, die man anklicken kann und die beschreiben, was in dem jeweiligen Textfeld sinnvollerweise einzugeben ist bzw. was das Modul an dieser Stelle erwartet.

Das Webinterface besteht aus vier Teilen. Änderungen in jedem Abschnitt müssen in dem jeweiligen Teil bestätigt werden und auch nur diese werden gespeichert. Bevor ein weiterer Teil bearbeitet wird, sollten Änderungen gespeichert werden, sie gehen sonst verloren.

=== Trigger device/time ===
==== Trigger Device ====
In diesem Feld wird das Device ausgewählt, dessen Events eine Aktion auslösen sollen. Dazu werden alle verfügbaren Devices in einem Dropdownfeld angeboten.

Zusätzlich gibt es eine Auswahl 'GLOBAL', wenn das Attribut 'MSwitch_Expert' gesetzt ist. Bei Auswahl dieser Option werden '''alle''' von FHEM generierten Events durch das MSwitch Device weiterverarbeitet, eine weitere Begrenzung der aktivierenden Events kann (und sollte) dann in einem folgenden Eingabefeld erfolgen, um die Systemlast zu reduzieren.

==== Trigger Device Global Whitelist ====
Dieses Feld ist nur verfügbar, wenn als Trigger 'GLOBAL' gewählt wurde.

Hier kann die Liste eingehender Events weiter eingeschränkt werden. Es handelt sich um eine Whitelist, d.h., wenn es keine Einträge gibt, werden Events aller Devices verarbeitet. Sobald ein oder mehrere Einträge gemacht werden, werden nur noch Events der hier benannten Devices verarbeitet. Als Angabe können hier Devices benannt werden oder ganze DeviceTypen (z.B. TYPE=FS20). Mehrere Angaben sind durch Komma zu trennen.

[[Datei:MSwitchWebinterface1.png|400px|thumb|right|Webinterface, oben]]
Im gezeigten Beispiel wurde GLOBAL gewählt, weil nicht ein einzelnes Device, sondern eine Kombination aus zwei Geräten auslösen soll. Es werden also alle Ereignisse betrachtet, wobei die Whitelist dann auf die Devices Schlafzimmer (ein Temperaturmessgerät) und Schlafzimmerfenster (ein [[HM-Sec-SCo Tür-Fensterkontakt, optisch|optischer Kontakt]]) einschränkt.

==== Trigger time ====
Es besteht die Möglichkeit, das Modul (neben den Events) zu festen Zeiten auszulösen. Dann wären in die leer stehenden Zeilen bei "at" entsprechende Termine einzutragen. Zeitangaben erfolgen durch [STUNDEN:MINUTEN|TAGE], wobei die Tage von 1-7 gezählt werden (1 steht für Montag, 7 für Sonntag usw.).
Mehrere Zeitvorgaben können direkt aneinandergereiht werden.

Beispielsweise würde [17:00|1][18:30|23] den Trigger montags um 17 Uhr auslösen und dienstags sowie mittwochs um 18:30 Uhr.
Bei [00:10*20:00-21:00] würde der Schaltbefehl von 21 Uhr bis 21 Uhr alle 10 Minuten ausgeführt. Bei [?20:00-21:00] würde der Schaltbefehl zu einem zufälligen Zeitpunkt zwischen 20 und 21 Uhr ausgeführt. [20:00|$we] bedeutet, dass nur am Wochenende um 20:00 geschaltet wird.

==== Trigger conditions ====
Hier kann die Angabe von Bedingungen erfolgen, die zusätzlich zu dem triggernden Device erfüllt sein müssen.
Diese Bedingungen sind eng an DOIF-Syntax angelehnt. Die Kombination mehrerer Bedingungen und Zeiten ist durch AND oder OR möglich.

Wird in diesem Feld keine Angabe gemacht, so erfolgt der Schaltvorgang nur durch das triggernde Device ohne weitere Bedingungen.

;Zeitabhängigkeit
:[19:10-23:00] - Trigger des Devices erfolgt nur in angegebenem Zeitraum
;Readingabhängige Trigger
:[Devicename:Reading] =/>/< X oder [Devicename:Reading] eq "x" - Trigger des Device erfolgt nur bei erfüllter Bedingung.
:Werden Readings mit Strings abgefragt (on,off,etc.), ist statt des Gleichheitszeichens "=" der Operator "eq" zu nutzen, der String muss in Anführungszeichen "" gesetzt werden.
;mehrere Beispiele
:[19:10-23:00] AND [Devicename:Reading] = 10 - beide Bedingungen müssen erfüllt sein.
:[19:10-23:00] OR [Devicename:Reading] = 10 - eine der Bedingungen muss erfüllt sein.
:[10:00-11:00|13] - schaltet Montag und Mittwoch zwischen 10 Uhr und 11 Uhr.
:[{ sunset() }-23:00] - von Sonnenuntergang bis 23:00 Uhr.
:{ !$we } löst den Schaltvorgang nur Werktagen an aus.
:{ $we } löst den Schaltvorgang nur an Wochenenden, Feiertagen aus.

Es ist auf korrekte Eingabe der Leerzeichen zu achten.

Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (beispielsweise würde dann am Mittwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde).

Bedingungen in diesem Feld gelten nur für auslösende Trigger eines Devices und haben keinen Einfluss auf zeitgesteuerte Auslöser.

=== Trigger details ===
[[Datei:MSwitchWebinterface2.png|600px|thumb|right|Webinterface, Mitte]]
Während im obigen Feld das Device ausgewählt werden konnte, wird hier das Ereignis festgelegt. Das Eingabefeld besteht aus mehreren Einzelfeldern.

Im abgebildeten Fall wird cmd1 ausgelöst, wenn der Zustand des Schlafzimmerfenster-Sensors meldet, dass das Fenster offen ist. Cmd2 wird ausgelöst, wenn die Temperatur des Schlafzimmersensors unter einen bestimmten Wert fallen wird.

==== execute 'cmd1/cmd2' ====
Hier kann aus einer vorbelegten Dropdownliste ausgewählt werden, welches ankommende Event den entsprechenden Befehlszweig auslösen soll. In dieser Liste werden bei entsprechender Einstellung alle ankommenden Events eines vorher definierten Devices gespeichert. In einem weiteren Feld (siehe unten) können Events manuell zugefügt werden.

==== Save incomming events ====
Bei Aktivierung dieser Option werden alle ankommenden Events des oben definierten Devices (oder Global) gespeichert und in entsprechenden Dropdownlisten angeboten.

Da hier doch erhebliche Datenmengen anfallen können (je nach Device) wird empfohlen, diese Option nach der Konfiguration des Devices zu deaktivieren.

==== add event ====
Hier besteht die Möglichkeit, unabhängig von der Option, ankommende Events automatisch zu speichern. Manuell Events anzulegen, die in den Dropdownliste zur Auswahl angeboten werden, ohne das entsprechendes Event erst vom Device geliefert werden muss.

Es können mehrere Events gleichzeitig eingegeben werden, eine Trennung erfolgt durch " , ".

Hier ist zu unterscheiden, ob das gewählte triggernde Device ein einfaches Device ist oder ob der Trigger 'GLOBAL' ist.
Bei triggernden Devices können Events in folgendem Formaten zugefügt werden:

- * - Aktion erfolgt auf alle auftretende Events des entsprechenden Device 
- reading:wert (z.b. state:on ) - Aktion erfolgt nur auf das Event "state:on" 
- reading:* (z.b. state:* ) - Aktion erfolgt auf die Events "state:(on,off,etc.) 
- reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Aktion erfolgt nur auf Events "state:left" oder "state:right" etc. 
 
Falls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden: 
 
- * - Aktion erfolgt auf alle auftretende Events des entsprechenden Device 
- device:reading:wert (z.b. device:state:on ) - Aktion erfolgt nur auf das Event "device:state:on" 
- device:reading:* (z.b. device:state:* ) - Aktion erfolgt auf die Events "device:state:(on,off,etc.) 
- device:reading:(wert1/wert2/wert3) (z.b. device:state:(left/right) - Aktion erfolgt nur auf Events "device:state:left" oder "devicestate:right" etc. 

Das Device kann auch hier gegen "*" ersetzt werden (*:state:on). In diesem Fall erfolgt eine Aktion auf alle Events die z.B. "state:on" enthalten, egal welches Device triggert.

==== test event ====
Dieses Feld wird angeboten, wenn entsprechende vom Triggerdevice gelieferte Events gespeichert wurden.

Durch Auslösen dieser Funktion wird das Event simuliert und entsprechende definierte Aktionen ausgelöst. Diese Funktion dient ausschließlich zum Testen der eingestellten Konfiguration. Alle entsprechenden Befehle werden ausgeführt, als würde das Event real eintreffen.

==== apply filter to saved events ====
Beschreibung folgt

==== clear saved event ====
Es werden alle gespeicherten Events gelöscht.

Ausnahme: Events, die als Trigger eingestellt sind, bleiben erhalten.

=== Affected devices ===
[[Datei:MSwitch_Screen_5.png|mini|rechts|affected devices]]
Dieser Abschnitt beinhaltet die Auswahl der Devices, die auf ein Event reagieren sollen.

In dem Auswahlfeld werden alle Devices angeboten, die eines der folgenden Kriterien erfüllen:
# Die Abfrage "set Device ?" liefert einen Befehlssatz
# Das Attribut 'webcmd' des Devices enthält Einträge
# Das Attribut 'MSwitch_Activate_MSwitchcmds' ist aktiviert und das Attribut 'MSwitchcmds' des betreffenden Devices enthält einen Befehlssatz

Einzige Ausnahme ist der erste Listeneintrag 'FreeCMD'. Die Auswahl dieses Eintrages bietet später die Möglichkeit Befehle auszuführen, die nicht an ein Device gebunden sind. Der Code in einem FreeCmd kann entweder reiner FHEM-Code sein ( set device on ) oder reiner Perl-Code. Wenn es sich um reinen Perl-Code handelt, ist dieser in geschweifte Klammen zu setzen { Perl-Code }.

=== Device actions ===
[[Datei:Webinterface3.png|mini|rechts|device_actions]]
Hier stellt man die auszuführenden Aktionen der eingestellten Devices ein. Im ersten Abschnitt oben befindet sich ein FreeCmd, mit dem beliebige Kommandos eingetragen werden können. Im abgebildeten Beispiel ist dies sogar selbst definierter Perl-Code (die Funktion DebianMail sendet eine Mail).

==== MSwitch cmd1/cmd2: ====
Man wählt den Befehl aus dem betreffenden Device aus. Bei freien Textfeldern (wie im Fall des FreeCmd) wird der Befehl eingegeben.

Es werden alle verfügbaren Befehle des Devices zur Auswahl angeboten. Je nach Attribut-Einstellungen werden Einträge aus entsprechenden 'webcmds" oder 'MSwitchcmds' einbezogen. In Abhängigkeit des Befehls stehen unter Umständen weitere Felder oder Widgets zur Verfügung.

05.04.2018 NEU: Auswahlfeld 'MSwitchtoggle' -> Beschreibung wird noch ergänzt !

==== cmd1/cmd2 condition ====
Mit diesem Feld kann die Ausführung des Befehls von weiteren Bedingungen abhängig gemacht werden. Bei der Abfrage von Readings nach Strings (on, off, etc.) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden. Es ist auf korrekte Eingabe der Leerzeichen zu achten.

#Zeitabhängiges schalten: [19:10-23:00] - Schaltbefehl erfolgt nur in angegebenem Zeitraum
#Readingabhängiges schalten [Devicename:Reading] =/>/< X oder [Devicename:Reading] eq "x" - Schaltbefehl erfolgt nur bei erfüllter Bedingung.

Soll nur an bestimmten Wochentagen geschaltet werden, muss eine Zeitangabe gemacht werden.

Beispielsweise würde [10:00-11:00|13] den Schaltvorgang nur Montag und Mittwoch zwischen 10 Uhr und 11 Uhr auslösen. Hierbei zählen die Wochentage von 1-7 für Montag-Sonntag.

Die Kombination mehrerer Bedingungen und Zeiten ist durch AND oder OR möglich:
* [19:10-23:00] AND [Devicename:Reading] = 10 - beide Bedingungen müssen erfüllt sein.
* [19:10-23:00] OR [Devicename:Reading] = 10 - eine der Bedingungen muss erfüllt sein.
* [{sunset()}-23:00] - von Sonnenuntergang bis 23:00 Uhr.
* { !$we } löst den Schaltvorgang nur Werktagen aus
* { $we } löst den Schaltvorgang nur Wochenenden, Feiertagen aus

'''Achtung:''' Bei Anwendung der geschweiften Klammern zur Einleitung eines Perl Ausdrucks ist unbedingt auf die Leerzeichen hinter und vor der Klammer zu achten.

Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (zum Beispiel würde auch am Mittwoch noch der Schaltvorgang erfolgen, wenn als Tagesvorgabe Dienstag gesetzt wurde).

; $EVENT:
: Die Variable EVENT enthält den auslösenden Trigger, d.h. es kann eine Reaktion in direkter Abhängigkeit zum auslösenden Trigger erfolgen.

[$EVENT] eq "state:on" würde den Kommandozweig nur dann ausführen, wenn der auslösende Trigger "state:on" war. Wichtig ist dieses, wenn bei den Triggerdetails nicht schon auf ein bestimmtes Event getriggert wird, sondern hier durch die Nutzung eines Wildcards (*) auf alle Events getriggert wird, oder auf alle Events eines Readings z.B. (state:*).

==== cmd1/cmd2 delay ====
Ein Eintrag in diesem Feld führt zur verzögerten Ausführung des Befehls nach Eintreffen des Events. Dabei kann der Befehl ohne weitere Prüfung der Bedingung ausgelöst werden. Es ist aber auch möglich, dass die Bedingung bei Ausführung erneut geprüft wird. Die Zeitangabe muss im Format hh:mm:ss vorliegen.

Statt einer unmittelbaren Zeitangabe kann hier auch ein Verweis auf ein Reading eines Devices erfolgen : 
[NAME.reading] des Devices ->z.B. [dummy.state]

==== add action ====
Mit diesem Button kann ein weiteres Eingabefeld für das entsprechende Device angelegt werden, um z.B. einen weiteren Befehl (ggf.) zeitverzögert auszuführen.

==== delete this action ====
Mit diesem Button wird der entsprechende Befehl für das Device gelöscht.

==== check condition ====
[[Datei:MSwitch_Screen_7.png|mini|rechts|check]]
Die angegebenen 'conditions' werden in Zusammenhang mit ggf. ausgewählten Devices auf Syntax und Ergebnis geprüft. Es erfolgt eine Ausgabe des Prüfungsergebnisses.

==== Repeat und Repeatdelay ====
Man kann mehrfache Wiederholungen erzwingen. Repeat gibt dabei an, wie oft das Kommando wiederholt wird (Anzahl). Repeatdelay gibt an, wie viel Sekunden zwischen einzelnen Wiederholungen liegen sollen.

== Attribute ==
Folgende Attribute stehen zur Verfügung:

=== MSwitch_Debug (0:1:2:3:4) ===
0 - Abgeschaltet 
1 - Schaltet Felder zum testen der Conditionstrings etc. an 
2 - Alle ausgehenden Befehle werden nur simuliert und nicht ausgeführt. Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt 
2 - Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt 
4 - erweiterte Debug-Funktion (nur für Entwicklung - wechselnde Funktion ) 

=== MSwitch_Expert (0:1) ===
In der Liste der möglichen Trigger erscheint das Selectfeld 'GLOBAL'. Dieses ermöglicht das Setzen eines Triggers auf alle Events und damit nicht nur auf einzelne Devices. In einem weiteren Feld kann eine weitere Selektion der triggernden Events erfolgen.

Es stehen weitere Felder 'Repeats' und 'Repeatdelay in sec' zur Verfügung. Eine hier getätigte Einstellung bewirkt X-fache Wiederholung von gesetzten Befehlen im Abstand der gesetzten Sekunden.

Weiterhin kann über das Auswahlfeld 'priotity' bei jedem 'affectes device' die Reihenfolge beim abarbeiten der Befehle beeinflusst werden.

=== MSwitch_Sequenz <Suchmuster> ===
In diesem Attribut können ein oder mehrere Suchmuster angegeben werden ,die eine Schaltsequenz darstellen und vom Device erkannt werden.

Die Angabe muss folgende Syntax haben:
:<code>Device1:reading1:event1 Device1:reading1:event1-2 Device1:reading1:event1-3/..../....</code>

mehrere Suchmuster müssen durch "/" getrennt werden.

Beispiel:
:<code>Dummy:state:on Dummy:state:off Dummy:state:on</code>

Erkennt das Device dieses Suchmuster in den Schaltvorgängen des Devices (Dummy), wird das Reading "SEQUENCE" auf "match" gesetzt, das Reading "SEQUENCE_NUMBER" auf die Nummer der gefundenen Sequenz, wenn es mehrere Suchmuster gibt. Beide Readings können in den "Conditions" eines Schaltbefehles abgefragt werden.

=== MSwitch_Sequence_time <Zeit in Sekunden> ===
Beinhaltet die Zeit in Sekunden, die es dauern darf, um eine Sequenz vollständig auszuführen.

=== MSwitch_Extensions (0:1) ===
Es wird eine zusätzliche Schaltoption 'MSwitchToggle' in den Geräten angeboten. Diese kann genutzt werden, wenn zuschaltende Geräte eine Togglefunktion nicht von Haus aus anbieten.

Eine Angabe muss in folgendem Format gemacht werden:
:<code>on/off/state/suchmuster1/suchmuster2</code>, wobei die letzten drei Angaben optional sind.

Funktion: Bei Ausführung des Befehls wird das Gerät 'on' oder 'off' geschaltet (on/off), Voraussetzung ist, dass der 'state' dieses Gerätes auch den 'state on' oder 'off' annimmt. Sollte dieses nicht der Fall sein, so kann mit dem Feld 'state' angegeben werden, in welchem Reading der aktuelle Status vorkommt und wie dieser lautet (suchmuster1/suchmuster2). Dieses 'state' kann mehrere Angaben enthalten, das Vorkommen der Suchmuster ist aber Voraussetzung.

=== MSwitch_Delete_Delays (0:1) ===
Bewirkt das Löschen aller anstehende Timer (Delays) bei dem Auftreten eines erneuten, passenden Events. Bei der Option '0' bleiben bereits gesetzte Delays aus einem vorherigen, getriggertem Event erhalten und werden ausgeführt.

Empfohlene Einstellung (1)

=== MSwitch_Include_Devicecmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz liefern (bei Abfrage set DEVICE ?).

Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr angeboten.

Empfohlene Einstellung (1).

=== MSwitch_Include_Webcmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut Webcmd hinterlegt haben. Die in Webcmd hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten.

Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz (set DEVICE ?) liefern.

Empfohlene Einstellung (0), Einsatz nach Bedarf.

=== MSwitch_Activate_MSwitchcmds (0:1) ===
Fügt jedem vorhandenen Device as Attribut 'MSwitchcmd' hinzu.

=== MSwitch_Include_MSwitchcmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut MSwitchcmds hinterlegt haben. Die in MSwitchcmds hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr Angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz (set DEVICE ?) liefern.

Empfohlene Einstellung (0), Einsatz nach Bedarf.

=== MSwitch_Lock_Quickedit (0:1) ===
Voreinstellung für die Auswahlliste 'Affected Devices'. Bei der Option (1) ist diese voreingestellt gesperrt und kann nur über einen zusätzlichen Button geändert werden. Da es sich hier um ein Feld mit der Möglichkeit einer Mehrfacheingabe handelt handelt ist die Voreinstellung 1, um versehentliche nicht gewünschte Änderungen zu vermeiden (Auswahl einer Option ohne 'Strg' bewirkt das löschen aller bereits gesetzten Optionen).

Empfohlene Einstellung (1).

=== MSwitch_Startdelay (0:10:20:30:60) ===
Diese Einstellung beeinflusst den Start von MSwitch nach einem FHEM Start. MSwitch ignoriert für die angegebene Zeit in Sekunden alle eingehenden Events um u.a. Startverzögerungen zu vermeiden. Bei nicht gesetztem Attribut gilt hier eine Zeit von 30 Sekunden. Diese sollte auch nur in Ausnahmefällen bzw. bei besonderem Bedarf geändert werden.

Empfohlene Einstellung (30).

=== MSwitch_Ignore_Types ===
Beinhaltet eine Liste von Device''typen'', die in den Auswahllisten ''nicht'' dargestellt werden. Hier ist es sinnvoll, Devicetypen einzutragen, die in aller Regel nicht geschaltet werden oder nicht geschaltet werden können, um die Auswahllisten übersichtlicher zu halten. Einzelne Devicetypen sind durch Leerzeichen zu trennen.

Voreinstellung: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul.

Eine Angabe kann hier in 2 Arten getätigt werden:
# eine Liste von devicetypen.
# Angabe einer devspec z.B. "TYPE=watchdog". Hier ist zu beachten, dass in diesem Fall alle Geräte in die Ignoreliste einbezogen werden, die NICHT der devspec entsprechen. Weiterhin muss die devspec in Anführungszeichen gesetzt werden!

=== MSwitch_Trigger_Filter ===
Beinhaltet eine Liste von Events, die bei eingehenden Events unberücksichtigt bleiben. Diese werde dann auch nicht gespeichert.

Hier kann mit Wildcards (*) gearbeitet werden. Einzelne Events sind durch Komma ',' zu trennen.

Empfohlene Einstellung (keine).

=== MSwitch_Wait (sec)===
Bei gesetztem Attribut (Zeit in Sekunden) nimmt Das MSwitch Device für den eingestellten Zeitraum keine Befehle mehr entgegen und ignoriert eingehende Events

=== MSwitch_Event_Id_Distributor ===
Dieses Attribut hat nur dann eine Funktion, wenn auch das Attribut 'MSwitchExpert' auf '1' gesetzt ist.
Hier können verschiedene auslösende Events auf Aktionen mit angegebenen IDs umgeleitet werden.

Sollte bei den 'trigger details :' in einem Zweig ( cmd1 ) z.B. auf mehrere Events getriggert werden ( regex z.B. state:(on|off) ) so werden für beide Events jeweils der Zweig 'cmd1' - alle Aktionen ohneID - ausgeführt. Durch entsprechende Einträge kann für entsprechende Events auf eine Aktion umgeleitet werden, für die eine ID definiert ist. Die Syntax lautet:
:<code>state:on=>cmd1 ID 1,2</code>

Hier werden bei auslösendem Event 'state:on' nur die Aktionen aus cmd1 mit den IDs 1 und 2 ausgeführt. Mehrere Angaben sind durch new Line zu trennen.

=== MSwitch_Selftrigger_always (0,1)===
(dieses Attribut steht ab Modulversion 2.5 zur Verfügung)

Die Aktivierung dieses Attributes (1) bewirkt, dass alle SET Aktionen des Devices einen (internen) Event auslösen, auf die das Device selber reagiert. Diese Option kann zusätzlich zu einem vorhandenen Trigger aktiviert werden.

Diese Events sind lediglich Device intern, d.h es werden keine Modulübergreifenden Events ausgelöst.

Auftretende und auswertbare interne Events haben immer folgendes Format und können darüber ausgewertet werden.

MSwitch_Self:aktion:wert
MSwitch_Self:pct:100

Es werden nur interne Events für set-Aktionen ausgelöst, die im Attribut setlist hinterlegt sind.

Als weitere Besonderheit unterliegen diese internen Events nicht dem 'wait' Befehl/Attribut.

=== MSwitch_Mode (Notify,Full,Toggle,Dummy)===
Schaltet das Modul zwischen verschiedenen Modi um, mit entsprechend angepasster Weboberfläche.

==== Notify ====
Das Device kann nicht manuell umgeschaltet werden. Es gibt nur zwei ausführbare Zweige (execute 'cmd1' commands und execute 'cmd2' commands). Der Status des Devices wird nicht als 'on' oder 'off' angezeigt, sondern lediglich als 'active'

Dieser Mode ist am ehesten mit einem Notify zu Vergleichen.

==== Full ====
Es stehen alle Funktionen zur Verfügung.
==== Toggle ====
Sehr vereinfachter Mode. Es stehen keine verschiedenen Zweige zur Verfügung. Hier ist das Device manuell schaltbar und wird bei jedem definierten Event 'Umgeschaltet', entsprechend definierte Befehle für 'cmd1' oder 'cmd2' werden ausgeführt.
==== Dummy====
ACHTUNG: Funktionsänderung mit V2.61

Der Mode 'Dummy' ist ein eingeschränkter Modus.
Dieser bietet die Funktionalität eines Dummys kombiniert mit der Funktionalität eines Notifys und kann somit die gerne genutzte Kombination Dummy-Notify gegen ein Device ersetzen.

Achtung: Devices die einmal in dem Modus 'Dummy' gesetzt wurden können nicht wieder in einen anderen Mode geschaltet werden !

Der Dummy-Mode kann nur in einem neu angelegtem, leeren MSwitch aktiviert werden. Sobald ein angelegtes MSwitch einmal verändert wurde (modify trigger etc.) ist ein Umschalten nicht mehr möglich und die Option nicht mehr verfügbar.

=== MSwitch_Condition_Time (0,1)===
In der Grundeinstellung (0) werden für das zeitgesteuerte Schalten keine definierten Conditionen im Feld 'Trigger condition' überprüft, sondern die Schaltbefehle werden in jedem Fall ausgeführt. Mit der Einstellung (1) wird diese Überprüfung auch für zeitgesteuerte Befehle zugeschaltet.

=== MSwitch_Random_Time (HH:MM:SS-HH:MM:SS)===
Bei Aktivierung wird vor jedem Ausführen eines verzögerten Befehls ( Delay ) eine Zufallszeit generiert, die im Rahme der hier angegebenen Zeitspanne liegt. Auf diese Zufallszahl kann in den Delays zugegriffen werden, durch die Angabe '[random]' statt einer direkten Zeitangabe. Bei nicht gesetztem Attribut ergibt die Angabe von ' [random] ' hier immer '00:00:00'

=== MSwitch_Random_Number ===
Bei Aktivierung dieses Attributes (der Inhalt kann einen beliebige Zahl sein) werden vom Device 2 Readings angelegt (Device:RandomNr) und (Device:RandomNr1). RandomNr wird vor jedem Ausführen eines Befehls aktualisiert und neu generiert, d.h wenn ein MSwitch Device mehrere Geräte schaltet, wird (auch in einem Durchgang) vor jedem Befehl dieses Reading neu gesetzt. RandomNr1 wird lediglich bei Ausführung des MSwitch Devices einmal neu gesetzt, d.h. nicht vor jedem Befehl der ausgeführt wird.
Die Readings werden mit einer Zufallszahl zwischen 0 und dem hier eingestellten Wert gesetzt.

Auf diese Readings kann in jeder Condition mit z.B. '[$NAME:ReadingNr1] = 1' zugegriffen werden.

D.h., das in der Condition angegebene Reading ( [$NAME:ReadingNr1] ) muss in diesem Fall den Wert 1 angenommen haben, ansonsten wird der Befehl nicht ausgeführt.
Der Befehl wird somit nur mit einer Wahrscheinlichkeit von 1 zu ( gesetzter Wert im Attr. ) ausgeführt.

=== MSwitch_Reset_EVT_CMD1(2)_COUNT ===
Bei Aktivierung dieses Attributes steht in den Readings das Reading 'EVT_CMD1_COUNT' bzw. 'EVT_CMD2_COUNT' zur Verfügung. Dieses kann in den Conditions genutzt werden, um z.B. nur bei jedem x-ten Eintreffen eines auslösenden Events einen Befehl auszuführen. Bei jedem Eintreffen eines gültigen Events werden die Zähler um 1 erhöht (für den jeweiligen Zweig).
Ist hier der Wert '0' eingetragen, wird der Zähler fortlaufend (endlos) erhöht. Wird ein Wert größer 0 eingetragen, wird der Zähler mit Erreichen dieses Wertes automatisch wieder auf Null gesetzt.

Mit Löschen dieses Attributes werden die entsprechenden Readings ebenfalls gelöscht.

=== MSwitch_Safemode (0:1)===
Bietet einen (gewissen) Schutz vor falschen Konfigurationen und somit entstehenden Endlosschleifen.
Bei aktiviertem Attribut (1) erkennt das Modul Endlosschleifen eines Devices und beendet diese.

In diesem Fall erfolgt ein Logeintrag und das Device wird per Attribut auf 'Disabled' gesetzt.
Es wird ein letztes Event generiert, auf das reagiert werden kann:
:<code>2018-05-31 09:39:21 MSwitch <NAME> Safemode: on</code>
Im Webinterface erfolgt bei betroffenem Device ein entsprechender Hinweis.

In der Grundkonfiguration ist dieses Attribut nicht gesetzt, es empfiehlt sich aber, bei neuen (komplizierten) Devices, dieses - zumindest anfänglich - zu aktivieren.

=== MSwitch_Read_Log(0:1)===
Ermöglicht den Zugriff auf das Logfile als Trigger.

Hier gibt es mehrere Konfigurationsmöglichkeiten:
* Bei aktiviertem Attribut enthält die Auswahl des Triggerdevices die Option 'LOGFILE'. Bei dieser Auswahl werde alle Logeinträge erkannt und in ein internes Event umgewandelt, auf das regiert werden kann.
* bei aktiviertem Attribut und der Auswahl 'GLOBAL' im 'Trigger_Device' wird auf ALLE Events und alle Logeinträge reagiert.
* bei aktiviertem Attribut und der Auswahl eines bestimmten Devices im 'Trigger_Device' wird auf alle Events und auf alle Logeinträge des gewählten Devices reagiert. Hier ist zu beachten, dass FHEM mir keine Möglichkeit bietet, wirklich herauszufinden, welches Device denn nun einen Logeintrag generiert hat. D.h., dieses wird vom Vorhandensein des Namens im Logeintrag abhängig gemacht und MSwitch reagiert nur dann auf einen Logeintrag, wenn der Name des Devices in diesem Eintrag vorhanden ist.

=== MSwitch_Help(0:1)===
Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.

=== MSwitch_Comments(0:1)===
Schaltet Kommentarfelder zu den einzelnen 'affected_devices an.

=== MSwitch_generate_Events(0:1)===
Reduziert bei Einstellung '1' die vom MSwitch-Devices erzeugten Events auf ein absolutes Minimum. Insbesondere bei Verwendung von 'MSwitch_Read_Log' zu empfehlen.

=== MSwitch_Startdelay ===
Bestimmt die Verzögerungszeit des MSwitches nach FHEM-Start in Sekunden. In diesem Zeitraum reagiert das Device nicht auf Events. Die Vorgabe ist hier zehn Sekunden. Diese wird auch dann angenommen, wenn das Attribut nicht gesetzt ist.

=== MSwitch_Inforoom ===
Mit diesem Attribut wird die Raumansicht eines mit dem Attribut bestimmten Raumes verändert. Dadurch sollen die wichtigsten Informationen aller MSwitch-Devices auf eine Seite dargestellt werden. Zur Nutzung sollten alle MSwitch-Devices (zusätzlich) in einen Raum sortiert werden und dieser Raum im Attribut eingestellt werden.

Wichtig: Eine Änderung dieses Attributes bewirkt immer eine Änderung dieses Attributes in ''allen'' MSwitch devices: Es muss nur in einem Device gesetzt oder gelöscht werden um alle Devices zu erfassen.

<gallery>
MSwitch_Screen_1.png|Raumansicht des Raumes MSwitch mit gesetztem Attribut 'MSwitch'
MSwitch_Screen_2.png|Raumansicht des Raumes MSwitch ohne gesetztes Attribut
</gallery>

Es werden folgende Informationen bereitgestellt:
* Infobutton zeigt den im Device gespeicherten Textes des Attributes 'comment'
* Device und Events, die das Device triggern
* Zeiten, zu denen verschiedene Zweige des Devices ausgeführt werden
* Devices, die durch das MSwitch Device geschaltet werden
* State des Devices

== Integrierte Funktionen ==

=== Average ===
Folgt

=== Tendency ===

Syntax:
[TEND<wert>:<reading>] > <Mindestwert>

Beispiel:
[TEND2:countdown] > 2

Reading:
Entspricht dem getriggerten Reading.

Wert:
Es wird jeweils der Durchschnitt von 2 Wertepaaren gebildet. In diesem Fall werden die letzten 4 Werte herangezogen. 
Paar 1 = Aktueller und letzter Wert, Paar 2 = Die 2 vorherigen Werte. 
Bei TEND3 werden die letzten 6 Werte zur Paarbildung genutzt.

Mindestwert:
Der Wertunterschied zwischen den Wertepaaren, der minimal erreicht sein muss, um eine Tendenz zu erkennen.

Rechenzeichen (><):
Dieses ist hier nicht als Rechenzeichen zu werten, sonder als Tendenz-Anzeige. ( < es wird nach fallender Tendenz gesucht / > sucht nach steigender Tendenz).

Schaltung erfolgt einmalig bei Erkennung der gesuchten Tendenz.
Danach erfolgt keine Schaltung mehr, solange bis eine Tendenz-Umkehr erfolgt ist.
Erst dann erfolgt wieder eine Schaltung bei erneuter Tendenz-Umkehr in gesuchte Richtung.

=== Difference ===

Syntax:
[DIFF<wert>:<reading>] > <differenz>

Beispiel:
[DIFF2:countdown] > 0

Reading:
Entspricht dem getriggerten Reading.

Wert:
Gespeicherter Wert (in diesem Fall der vorletzte).

Differenz:
Geforderter Differenz zwischen aktuellem und vorletztem Wert.

Schaltung erfolg wenn diese Bedingung 'wahr' ist.

Folgende Readings werden zur Verfügung gestellt:

DIFFERENCE (true/false) - Schaltbedingung erkannt ja/nein

DIFFDIRECTION (up/down) - Richtung der erkannten Bedingung (steigend/fallend)

=== Increase ===
Folgt

== Tipps, Tricks, Kurzbeispiele ==
Wird stetig ergänzt.

=== Blinken - Falls nicht im Device vorhanden ===
[[Datei:MSwitch MSwitchblink.png|center|704px]]
 
Lässt ein beliebiges Device 5 mal togglen, mit einem Intervall von 0.5 Sekunden (Blinkzeit somit 2,5 Sekunden) 
Die MSwitchtoggle-Funktion muss per ATTR aktiviert werden. 
Die Repeatfunktion ist nur im Expertmode verfügbar, auch per ATTR einstellbar.

=== Linearschalter ===
Umsetzung eines Linearschalters mit MSwitch.

Eingang: Beliebiges Reading als numerischer Wert.

Ausgang: Wird entsprechend Linear / oder umgekehrt Linear zum Eingang geschaltet.

Folgend die Rawdefinition des MSwitchdevices und zweier Dummys (selbsterklärend)

Alle Devices werden im Raum Lineartest angelegt, die Dummy müssen zuerst angelegt werden.

<pre>defmod linearausgang dummy
attr linearausgang room Lineartest
attr linearausgang setList state:slider,0,1,100
attr linearausgang webCmd state
setstate linearausgang state 57
setstate linearausgang 2018-06-06 18:06:12 state state 57</pre>

<pre>defmod lineareingang dummy
attr lineareingang room Lineartest
attr lineareingang setList state:slider,0,1,15000
attr lineareingang webCmd state
setstate lineareingang 6422
setstate lineareingang 2018-06-06 18:06:12 state 6422</pre>

<pre>defmod Linearschalter MSwitch lineareingang # linearausgang FreeCmd
attr Linearschalter MSwitch_Debug 0
attr Linearschalter MSwitch_Delete_Delays 1
attr Linearschalter MSwitch_Expert 0
attr Linearschalter MSwitch_Extensions 0
attr Linearschalter MSwitch_Help 0
attr Linearschalter MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr Linearschalter MSwitch_Include_Devicecmds 1
attr Linearschalter MSwitch_Include_MSwitchcmds 0
attr Linearschalter MSwitch_Include_Webcmds 0
attr Linearschalter MSwitch_Inforoom MSwitch
attr Linearschalter MSwitch_Lock_Quickedit 1
attr Linearschalter MSwitch_Mode Notify
attr Linearschalter room Lineartest

setstate Linearschalter active
setstate Linearschalter 2018-06-06 18:03:50 .Device_Affected FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,linearausgang-AbsCmd1
setstate Linearschalter 2018-06-06 18:04:35 .Device_Affected_Details FreeCmd-AbsCmd1,cmd,cmd,{my $eingang =ReadingsVal( "lineareingang"## "state"## 0 );;my $emin=0;;my $emax=15000;;my $amin=100;;my $amax=0;;$eingang = $emin if $eingang < $emin;;$eingang = $emax if $eingang > $emax;;my $y= (($amax-$amin)/($emax-$emin)*($eingang-$emin))+$amin;;readingsSingleUpdate( $hash## "to_set"## int ($y)## 1 );;},,delay1,delay1,000000,000000,,,0,0|FreeCmd-AbsCmd2,cmd,cmd,,,delay1,delay1,000000,000000,,,0,0|linearausgang-AbsCmd1,state,no_action,[Linearschalter:to_set],,delay1,delay1,000000,000000,,,0,0
setstate Linearschalter 2018-06-06 18:06:12 .Device_Events no_trigger
setstate Linearschalter 2018-06-04 18:24:21 .First_init done
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_cmd_off no_trigger
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_cmd_on *
setstate Linearschalter 2018-06-06 17:58:56 .Trigger_condition
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_off no_trigger
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_on no_trigger
setstate Linearschalter 2018-06-06 17:58:56 .Trigger_time
setstate Linearschalter 2018-06-04 18:24:21 .V_Check V 0.3
setstate Linearschalter 2018-06-06 18:06:12 EVENT state: 6422
setstate Linearschalter 2018-06-06 18:06:12 EVTFULL lineareingang:state: 6422
setstate Linearschalter 2018-06-06 18:06:12 EVTPART1 lineareingang
setstate Linearschalter 2018-06-06 18:06:12 EVTPART2 state
setstate Linearschalter 2018-06-06 18:06:12 EVTPART3 6422
setstate Linearschalter 2018-06-06 18:06:12 Exec_cmd set linearausgang state [Linearschalter:to_set]
setstate Linearschalter 2018-06-06 17:58:56 Trigger_device lineareingang
setstate Linearschalter 2018-06-06 18:00:47 Trigger_log off
setstate Linearschalter 2018-06-06 18:06:12 last_event state: 6422
setstate Linearschalter 2018-06-04 18:39:56 state active
setstate Linearschalter 2018-06-06 18:06:12 to_set 57</pre>

MSwitch -Configfile (bei Bedarf)
<pre>#V V1.54
#S .Device_Affected -> FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,linearausgang-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{my $eingang =ReadingsVal( "lineareingang"## "state"## 0 )[S]my $emin=0[S]my $emax=15000[S]my $amin=100[S]my $amax=0[S]$eingang = $emin if $eingang < $emin[S]$eingang = $emax if $eingang > $emax[S]my $y= (($amax-$amin)/($emax-$emin)*($eingang-$emin))+$amin[S]readingsSingleUpdate( $hash## "to_set"## int ($y)## 1 )[S]},,delay1,delay1,000000,000000,,,0,0|FreeCmd-AbsCmd2,cmd,cmd,,,delay1,delay1,000000,000000,,,0,0|linearausgang-AbsCmd1,state,no_action,[Linearschalter.to_set],,delay1,delay1,000000,000000,,,0,0
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> *
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> lineareingang
#S Trigger_log -> off
#S last_event -> state: 6422
#S state -> active
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Help -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Include_Webcmds -> 0
#A room -> Lineartest
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 0
#A MSwitch_Lock_Quickedit -
</pre>

== Links ==
* Thread über das Modul im {{Link2Forum|Topic=86199|LinkText=FHEM Forum}}
* {{Link2Forum|Topic=100119|Message=936495|LinkText=Gäste-WLAN der Fritzbox auswerten und Login per Telegram senden}}
* {{Link2Forum|Topic=86199|Message=930133|LinkText=Schalten von vier Kanälen mit einem MSwitch-Device}}
* {{Link2Forum|Topic=99219|Message=926652|LinkText=Batterie-Überwachung. 1xTäglich per Telegram senden}}
* {{Link2Forum|Topic=101091|Message=945389|LinkText=Licht (Alarm) in einem bestimmten Zeitraum schalten}}
* {{Link2Forum|Topic=100949|Message=944284|LinkText=Über Dummy-Schalter ein Timer (EIN/AUS) aktivieren}}
* {{Link2Forum|Topic=103083|Message=967710|LinkText=Ladezeit von Akku ermitteln u. Steckdose entsprechend schalten}}

MSwitch

2019-11-01T20:02:25Z

Maista: /* Tipps, Tricks, Kurzbeispiele */

[[MSwitch]] ist ein Hilfsmodul, welches das Event- und/oder zeitgesteuerte Schalten von mehreren Devices oder das Ausführen von benutzerdefinierten Befehlssequenzen erlaubt.

Die Stärke bzw. das Unterscheidungsmerkmal dieses Moduls liegt in der Konfigurierbarkeit über ein Webinterface. Diese Konfiguration kann jederzeit geändert oder erweitert werden.

Byte09: ''Die Grundidee zu MSwitch kam mir, weil ich bei der Arbeit mit FHEM für meinen Geschmack zu viele Module für die verschiedenen Aufgaben brauchte - zu allem Überfluss alle mit unterschiedlicher Syntax. Zwar ist DOIF hiervon ausgenommen (da hiermit wohl auch fast jede Aufgabe lösbar ist), aber ich konnte mich leider nicht daran gewöhnen und somit wurde jedes DOIF für mich zu einem echten Projekt. Was ich wollte war ein Modul, mit dem ich alles erledigen kann. Daher entschloss ich mich schon nach fast einem knappen Jahr FHEM-Nutzung mein eigenes Modul zu schreiben, welches diese Anforderung erfüllt. MSwitch beinhaltet die Funktionalität aller bisherigen Hilfsmodule wie z.B. Notify, Doif, Watchdog, Dummy,( ab Modulversion 2.2 auch Sequenz ) es lassen sich all deren Funktionen umsetzen.''

''MSwitch wird permanent - vorrangig nach meinen Bedürfnissen - weiterentwickelt, gerne nehme ich aber auch Anregungen von anderen Nutzern auf.''

{{Infobox Modul
|ModPurpose=MSwitch
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=98_MSwitch.pm
|ModOwner=Byte09}}

== Grundsätzliche Überlegungen ==
Um das Modul zu nutzen, muss man zuerst folgende Fragen beantworten:

* Welches Gerät soll auslösen oder zu welcher Zeit soll eine Auslösung erfolgen.
: Dies ist der Trigger. Jedes Event aus dem Eventmonitor kann als Trigger dienen. Will man mehrere Geräte als gleichzeitige Auslöser betreiben, so muss das Device GLOBAL gewählt und die entsprechenden Geräte angegeben werden (dies erzeugt höhere Systemlast und ist nur im Expert-Modus verfügbar). Weiterhin kann auch zu fest definierten Zeiten, Zufallszeiten oder Intervallen, unabhängig von einem Trigger, geschaltet werden; auch eine Kombination beider Varianten ist möglich. Diese Einstellungen erfolgen im ersten Teil des Webinterfaces.

* Welche Bedingungen sollen bei Auslösung erfüllt sein?
: Wenn diese Bedingungen erfüllt sind, werden Kommandos ausgelöst. Die Bedingungen werden im zweiten Teil des Webinterfaces eingegeben. Dabei unterscheidet das Modul zwischen zwei Kommando-Kanälen (cmd1 und cmd2) und den dazugehörigen Geräten.

* Welche Kommandos sollen ausgelöst werden?
: Im dritten Teil des Webinterfaces werden dann die konkreten Kommandos eingegeben. Typischerweise wählt man dabei aus einer Liste der Kommandos aus, die die zugehörigen Geräte insgesamt aufweisen (also so, wie man auf den Geräteseiten selber Kommandos auswählt). Es gibt zudem ein so genanntes FreeCmd, das ein Geräteunabhängiges Kommando zulässt, beispielsweise reinen Perl-Code.

* Welche weiteren Bedingungen sollen noch gelten?
: Hier sind Ereignisgesteuerte wie auch Zeitgesteuerte Bedingungen möglich. Diese Bedingungen werden auch in dem dritten Teil des Webinterfaces eingetragen. So sind Verzögerungen und Wiederholungen und weitere Bedingungen möglich.

== Voraussetzungen, Installation und Grundbefehle ==
Das MSwitch-Modul ist ohne weitere Voraussetzungen nutzbar und wird derzeit in der Version 2.08 über FHEM Update verteilt.

=== Definition und Einrichtung ===
Mit Hilfe von MSwitch kann man mehrere Devices gleichzeitig schalten. Diese Schaltungen befinden sich in zwei möglichen Zweigen bei MSwitch. Dabei unterscheidet man im Modul zwischen den beiden Kommandos cmd1 und cmd2. Die zu einem Kommando gehörenden Geräte werden wir auch Zweig nennen. Die einzelnen Devices jedes Zweiges können mit weiteren Schaltbedingungen versehen werden (zeit- oder ereignisgesteuert).

Folgende Möglichkeiten zum definieren des MSwitch Devices stehen zur Verfügung:
:<code>define <name> MSwitch</code>
Es wird ein leeres Device angelegt, das dann komplett über das Webinterface konfigurierbar ist.

Das define eines MSwitch Devices generiert lediglich eine 'leere Hülle'. Alle relevante Einstellungen werden in Readings und/oder Hashes gespeichert. Daher stehen relevanten Daten ''nicht'' in der fhem.cfg! Vielmehr finden sich diese Daten in der Datei fhem.save (die Speicherung erfolgt durch den Befehl Fhemsave).

=== set-Befehle ===
Es sind derzeit die folgenden set-Befehle implementiert.

==== set active ====
Setzt das Device in den Status 'active'.

==== set inactive ====
Setzt das Device in den Status 'inactive', es werden keine Befehle mehr ausgeführt. Dieser Status entspricht dem Attribut 'disable', ist aber nicht mit dem roten Fragezeichen (fhem save) verbunden.

==== set on/off [<parameter>]====
Setzt das Device in den Status 'on' oder 'off'. Alle Befehle der 'on/off-Zweige' werden ausgeführt.
Optional kann den Befehlen 'on' und 'off' ein weiterer Parameter mit übergeben werden. Dieser wird im Reading 'Parameter' hinterlegt und es kann sofort in 'Freecmds' oder 'Conditions' darauf zugegriffen werden.

==== set reload_timer ====
Alle gesetzten Timer werden gelöscht und neu berechnet.

==== set change_renamed <oldname> <newname> ====
Sollten sich Devicenammen im ausführenden Teil geändert habe (affected Devices, Conditions, etc.) so kann das MSwitch mit diesem Befehl angepasst werden, ohne alle Einstellungen neu einstellen zu müssen.

==== set exec_cmd1 / set exec_cmd1 ID [<ID>] ====
Bewirkt das sofortige Ausführen des entsprechenden Befehlszweiges. Bei Angabe einer ID werden nur die Befehle mit der entsprechenden ID ausgeführt.

==== set MSwitch_backup ====
Erstellt eine Backup-Datei aller MSwitch Devices unter ./fhem/MSwitch_backup.cfg.

Daten dieser Datei können im Bedarfsfall für einzelne oder gleichzeitig alle MSwitch Devices wieder zurückgespielt (hergestellt) werden.

==== set del_delays ====
Löscht alle anstehenden, verzögerten Befehle (delays).

==== set reset_cmd_count:1,2 ====
Löscht das entsprechende EVT_CMD_COUNT - Reading (entspricht Rückstellung auf '0').

==== set fakeevent [<device>]:<reading>:<arg> ====
Beispiel: <device> fakeevent state:on 

Ob der Name (<device>) angegeben werden muss, oder nicht, ist abhängig davon, ob auf ein einzelnes Device, oder GLOBAL getriggert wird. Bei GLOBALEN Triggern muss das Device mit angegeben werden. Wird auf ein Device getriggert, so wird das Device automatisch gesetzt.

Mit diesem Befehl kann das MSwitch Device neu getriggert werden, indem hier ein Event 'gefaked' wird. Das MSwitch Device reagiert dann so, als wäre dieses Event vom getriggerten Gerät generiert worden.

Dieses kann nötig sein, um z.B. einen Watchdog zu realisieren, in dem es nötig ist, dass sich das MSwitch Device mit einem bestimmten Event selber neu triggert - ggf. mit einem entsprechenden Delay (affected Device muss dafür u.A. des MSwitch Device selber sein).

Es wird hierbei KEIN echtes Event generiert welches das System beeinflusst, sondern ausschließlich ein MSwitch-Interner Befehl umgesetzt!

Bei dem Einsatz dieser Möglichkeit sollte das Attribut 'MSwitch_Safemode' UNBEDINGT aktiviert sein, da 'Experimente' hier schnell in einer Endlosschleife enden können, die nur durch ein Reboot unterbrochen werden kann.

Ggf. werde ich hier sogar eine entsprechende Änderung vornehmen, dass dieser Befehl nur zur Verfügung steht, wenn Safemode aktiviert ist.

=== get-Befehle ===
==== get show_timer [<show><delete>] ====
;Show
:Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
;Delete
:Löscht alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren. Schaltbefehle basierend auf rein zeitabhängigen Angaben werden neu berechnet und gesetzt.

==== get restore_MSwitch_data [<this_device><all_devices>] ====
;this_device
:Stellt die Daten des Devices aus der Backupdatei wieder her, sofern diese in der Backupdatei gefunden werden (gesucht wird hier nach dem Namen des Devices).
;all_devices
:Stellt die Daten aller MSwitch Devices wieder her, sofern diese in der Backupdatei vorhanden sind. Diese Aktion kann einige Zeit in Anspruch nehmen und wird daher im Hintergrund (nonblocking) ausgeführt. Nach Beendigung erfolgt eine Benachrichtigung.

Die Devices sind nach einem Restore funktionsfähig. Empfohlen wird ein Neustart von FHEM.

==== get_config ====
Zeigt die Konfigurationsdatei des MSwitchdevices an; diese kann in dem Fenster editiert werden. Das sollte nur von erfahrenen Usern getan werden! Im Normalfall sollte das Device nur über die Weboberfläche konfiguriert werden und eine falsche Konfiguration kann hier zu einem FHEM Absturz führen.

==== get_support_info ====
Öffnet ein Fenster mit einer formatierten Ansicht aller Einstellungen des Devices. Bei Supportanfragen sollte dieses immer mit geposted werden.

==== get_MSwitch_preconf ====
Lädt vorkonfigurierte MSwitch-Devices. Diese Option ist nur dann vorhanden, wenn das Aktualisieren dieser vorkonfigurierten Devices im FHEM Update aktiviert ist.

Diese kann durch ein einmaliges Update erfolgen mit:
:<code>update all https://raw.githubusercontent.com/Byte009/MSwitch_Addons/master/controls_mswitchaddons.txt</code>

== Webinterface ==
MSwitch wird im Wesentlichen über das Webinterface eingerichtet. Wählt man das folgende Attribut
:<code>attr <name> MSwitch_Help 1</code>
so wird im Modul selber eine sehr umfangreiche Hilfe angezeigt. Über das gesamte Webinterface hinweg erscheinen kleine Fragezeichen, die man anklicken kann und die beschreiben, was in dem jeweiligen Textfeld sinnvollerweise einzugeben ist bzw. was das Modul an dieser Stelle erwartet.

Das Webinterface besteht aus vier Teilen. Änderungen in jedem Abschnitt müssen in dem jeweiligen Teil bestätigt werden und auch nur diese werden gespeichert. Bevor ein weiterer Teil bearbeitet wird, sollten Änderungen gespeichert werden, sie gehen sonst verloren.

=== Trigger device/time ===
==== Trigger Device ====
In diesem Feld wird das Device ausgewählt, dessen Events eine Aktion auslösen sollen. Dazu werden alle verfügbaren Devices in einem Dropdownfeld angeboten.

Zusätzlich gibt es eine Auswahl 'GLOBAL', wenn das Attribut 'MSwitch_Expert' gesetzt ist. Bei Auswahl dieser Option werden '''alle''' von FHEM generierten Events durch das MSwitch Device weiterverarbeitet, eine weitere Begrenzung der aktivierenden Events kann (und sollte) dann in einem folgenden Eingabefeld erfolgen, um die Systemlast zu reduzieren.

==== Trigger Device Global Whitelist ====
Dieses Feld ist nur verfügbar, wenn als Trigger 'GLOBAL' gewählt wurde.

Hier kann die Liste eingehender Events weiter eingeschränkt werden. Es handelt sich um eine Whitelist, d.h., wenn es keine Einträge gibt, werden Events aller Devices verarbeitet. Sobald ein oder mehrere Einträge gemacht werden, werden nur noch Events der hier benannten Devices verarbeitet. Als Angabe können hier Devices benannt werden oder ganze DeviceTypen (z.B. TYPE=FS20). Mehrere Angaben sind durch Komma zu trennen.

[[Datei:MSwitchWebinterface1.png|400px|thumb|right|Webinterface, oben]]
Im gezeigten Beispiel wurde GLOBAL gewählt, weil nicht ein einzelnes Device, sondern eine Kombination aus zwei Geräten auslösen soll. Es werden also alle Ereignisse betrachtet, wobei die Whitelist dann auf die Devices Schlafzimmer (ein Temperaturmessgerät) und Schlafzimmerfenster (ein [[HM-Sec-SCo Tür-Fensterkontakt, optisch|optischer Kontakt]]) einschränkt.

==== Trigger time ====
Es besteht die Möglichkeit, das Modul (neben den Events) zu festen Zeiten auszulösen. Dann wären in die leer stehenden Zeilen bei "at" entsprechende Termine einzutragen. Zeitangaben erfolgen durch [STUNDEN:MINUTEN|TAGE], wobei die Tage von 1-7 gezählt werden (1 steht für Montag, 7 für Sonntag usw.).
Mehrere Zeitvorgaben können direkt aneinandergereiht werden.

Beispielsweise würde [17:00|1][18:30|23] den Trigger montags um 17 Uhr auslösen und dienstags sowie mittwochs um 18:30 Uhr.
Bei [00:10*20:00-21:00] würde der Schaltbefehl von 21 Uhr bis 21 Uhr alle 10 Minuten ausgeführt. Bei [?20:00-21:00] würde der Schaltbefehl zu einem zufälligen Zeitpunkt zwischen 20 und 21 Uhr ausgeführt. [20:00|$we] bedeutet, dass nur am Wochenende um 20:00 geschaltet wird.

==== Trigger conditions ====
Hier kann die Angabe von Bedingungen erfolgen, die zusätzlich zu dem triggernden Device erfüllt sein müssen.
Diese Bedingungen sind eng an DOIF-Syntax angelehnt. Die Kombination mehrerer Bedingungen und Zeiten ist durch AND oder OR möglich.

Wird in diesem Feld keine Angabe gemacht, so erfolgt der Schaltvorgang nur durch das triggernde Device ohne weitere Bedingungen.

;Zeitabhängigkeit
:[19:10-23:00] - Trigger des Devices erfolgt nur in angegebenem Zeitraum
;Readingabhängige Trigger
:[Devicename:Reading] =/>/< X oder [Devicename:Reading] eq "x" - Trigger des Device erfolgt nur bei erfüllter Bedingung.
:Werden Readings mit Strings abgefragt (on,off,etc.), ist statt des Gleichheitszeichens "=" der Operator "eq" zu nutzen, der String muss in Anführungszeichen "" gesetzt werden.
;mehrere Beispiele
:[19:10-23:00] AND [Devicename:Reading] = 10 - beide Bedingungen müssen erfüllt sein.
:[19:10-23:00] OR [Devicename:Reading] = 10 - eine der Bedingungen muss erfüllt sein.
:[10:00-11:00|13] - schaltet Montag und Mittwoch zwischen 10 Uhr und 11 Uhr.
:[{ sunset() }-23:00] - von Sonnenuntergang bis 23:00 Uhr.
:{ !$we } löst den Schaltvorgang nur Werktagen an aus.
:{ $we } löst den Schaltvorgang nur an Wochenenden, Feiertagen aus.

Es ist auf korrekte Eingabe der Leerzeichen zu achten.

Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (beispielsweise würde dann am Mittwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde).

Bedingungen in diesem Feld gelten nur für auslösende Trigger eines Devices und haben keinen Einfluss auf zeitgesteuerte Auslöser.

=== Trigger details ===
[[Datei:MSwitchWebinterface2.png|600px|thumb|right|Webinterface, Mitte]]
Während im obigen Feld das Device ausgewählt werden konnte, wird hier das Ereignis festgelegt. Das Eingabefeld besteht aus mehreren Einzelfeldern.

Im abgebildeten Fall wird cmd1 ausgelöst, wenn der Zustand des Schlafzimmerfenster-Sensors meldet, dass das Fenster offen ist. Cmd2 wird ausgelöst, wenn die Temperatur des Schlafzimmersensors unter einen bestimmten Wert fallen wird.

==== execute 'cmd1/cmd2' ====
Hier kann aus einer vorbelegten Dropdownliste ausgewählt werden, welches ankommende Event den entsprechenden Befehlszweig auslösen soll. In dieser Liste werden bei entsprechender Einstellung alle ankommenden Events eines vorher definierten Devices gespeichert. In einem weiteren Feld (siehe unten) können Events manuell zugefügt werden.

==== Save incomming events ====
Bei Aktivierung dieser Option werden alle ankommenden Events des oben definierten Devices (oder Global) gespeichert und in entsprechenden Dropdownlisten angeboten.

Da hier doch erhebliche Datenmengen anfallen können (je nach Device) wird empfohlen, diese Option nach der Konfiguration des Devices zu deaktivieren.

==== add event ====
Hier besteht die Möglichkeit, unabhängig von der Option, ankommende Events automatisch zu speichern. Manuell Events anzulegen, die in den Dropdownliste zur Auswahl angeboten werden, ohne das entsprechendes Event erst vom Device geliefert werden muss.

Es können mehrere Events gleichzeitig eingegeben werden, eine Trennung erfolgt durch " , ".

Hier ist zu unterscheiden, ob das gewählte triggernde Device ein einfaches Device ist oder ob der Trigger 'GLOBAL' ist.
Bei triggernden Devices können Events in folgendem Formaten zugefügt werden:

- * - Aktion erfolgt auf alle auftretende Events des entsprechenden Device 
- reading:wert (z.b. state:on ) - Aktion erfolgt nur auf das Event "state:on" 
- reading:* (z.b. state:* ) - Aktion erfolgt auf die Events "state:(on,off,etc.) 
- reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Aktion erfolgt nur auf Events "state:left" oder "state:right" etc. 
 
Falls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden: 
 
- * - Aktion erfolgt auf alle auftretende Events des entsprechenden Device 
- device:reading:wert (z.b. device:state:on ) - Aktion erfolgt nur auf das Event "device:state:on" 
- device:reading:* (z.b. device:state:* ) - Aktion erfolgt auf die Events "device:state:(on,off,etc.) 
- device:reading:(wert1/wert2/wert3) (z.b. device:state:(left/right) - Aktion erfolgt nur auf Events "device:state:left" oder "devicestate:right" etc. 

Das Device kann auch hier gegen "*" ersetzt werden (*:state:on). In diesem Fall erfolgt eine Aktion auf alle Events die z.B. "state:on" enthalten, egal welches Device triggert.

==== test event ====
Dieses Feld wird angeboten, wenn entsprechende vom Triggerdevice gelieferte Events gespeichert wurden.

Durch Auslösen dieser Funktion wird das Event simuliert und entsprechende definierte Aktionen ausgelöst. Diese Funktion dient ausschließlich zum Testen der eingestellten Konfiguration. Alle entsprechenden Befehle werden ausgeführt, als würde das Event real eintreffen.

==== apply filter to saved events ====
Beschreibung folgt

==== clear saved event ====
Es werden alle gespeicherten Events gelöscht.

Ausnahme: Events, die als Trigger eingestellt sind, bleiben erhalten.

=== Affected devices ===
[[Datei:MSwitch_Screen_5.png|mini|rechts|affected devices]]
Dieser Abschnitt beinhaltet die Auswahl der Devices, die auf ein Event reagieren sollen.

In dem Auswahlfeld werden alle Devices angeboten, die eines der folgenden Kriterien erfüllen:
# Die Abfrage "set Device ?" liefert einen Befehlssatz
# Das Attribut 'webcmd' des Devices enthält Einträge
# Das Attribut 'MSwitch_Activate_MSwitchcmds' ist aktiviert und das Attribut 'MSwitchcmds' des betreffenden Devices enthält einen Befehlssatz

Einzige Ausnahme ist der erste Listeneintrag 'FreeCMD'. Die Auswahl dieses Eintrages bietet später die Möglichkeit Befehle auszuführen, die nicht an ein Device gebunden sind. Der Code in einem FreeCmd kann entweder reiner FHEM-Code sein ( set device on ) oder reiner Perl-Code. Wenn es sich um reinen Perl-Code handelt, ist dieser in geschweifte Klammen zu setzen { Perl-Code }.

=== Device actions ===
[[Datei:Webinterface3.png|mini|rechts|device_actions]]
Hier stellt man die auszuführenden Aktionen der eingestellten Devices ein. Im ersten Abschnitt oben befindet sich ein FreeCmd, mit dem beliebige Kommandos eingetragen werden können. Im abgebildeten Beispiel ist dies sogar selbst definierter Perl-Code (die Funktion DebianMail sendet eine Mail).

==== MSwitch cmd1/cmd2: ====
Man wählt den Befehl aus dem betreffenden Device aus. Bei freien Textfeldern (wie im Fall des FreeCmd) wird der Befehl eingegeben.

Es werden alle verfügbaren Befehle des Devices zur Auswahl angeboten. Je nach Attribut-Einstellungen werden Einträge aus entsprechenden 'webcmds" oder 'MSwitchcmds' einbezogen. In Abhängigkeit des Befehls stehen unter Umständen weitere Felder oder Widgets zur Verfügung.

05.04.2018 NEU: Auswahlfeld 'MSwitchtoggle' -> Beschreibung wird noch ergänzt !

==== cmd1/cmd2 condition ====
Mit diesem Feld kann die Ausführung des Befehls von weiteren Bedingungen abhängig gemacht werden. Bei der Abfrage von Readings nach Strings (on, off, etc.) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden. Es ist auf korrekte Eingabe der Leerzeichen zu achten.

#Zeitabhängiges schalten: [19:10-23:00] - Schaltbefehl erfolgt nur in angegebenem Zeitraum
#Readingabhängiges schalten [Devicename:Reading] =/>/< X oder [Devicename:Reading] eq "x" - Schaltbefehl erfolgt nur bei erfüllter Bedingung.

Soll nur an bestimmten Wochentagen geschaltet werden, muss eine Zeitangabe gemacht werden.

Beispielsweise würde [10:00-11:00|13] den Schaltvorgang nur Montag und Mittwoch zwischen 10 Uhr und 11 Uhr auslösen. Hierbei zählen die Wochentage von 1-7 für Montag-Sonntag.

Die Kombination mehrerer Bedingungen und Zeiten ist durch AND oder OR möglich:
* [19:10-23:00] AND [Devicename:Reading] = 10 - beide Bedingungen müssen erfüllt sein.
* [19:10-23:00] OR [Devicename:Reading] = 10 - eine der Bedingungen muss erfüllt sein.
* [{sunset()}-23:00] - von Sonnenuntergang bis 23:00 Uhr.
* { !$we } löst den Schaltvorgang nur Werktagen aus
* { $we } löst den Schaltvorgang nur Wochenenden, Feiertagen aus

'''Achtung:''' Bei Anwendung der geschweiften Klammern zur Einleitung eines Perl Ausdrucks ist unbedingt auf die Leerzeichen hinter und vor der Klammer zu achten.

Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (zum Beispiel würde auch am Mittwoch noch der Schaltvorgang erfolgen, wenn als Tagesvorgabe Dienstag gesetzt wurde).

; $EVENT:
: Die Variable EVENT enthält den auslösenden Trigger, d.h. es kann eine Reaktion in direkter Abhängigkeit zum auslösenden Trigger erfolgen.

[$EVENT] eq "state:on" würde den Kommandozweig nur dann ausführen, wenn der auslösende Trigger "state:on" war. Wichtig ist dieses, wenn bei den Triggerdetails nicht schon auf ein bestimmtes Event getriggert wird, sondern hier durch die Nutzung eines Wildcards (*) auf alle Events getriggert wird, oder auf alle Events eines Readings z.B. (state:*).

==== cmd1/cmd2 delay ====
Ein Eintrag in diesem Feld führt zur verzögerten Ausführung des Befehls nach Eintreffen des Events. Dabei kann der Befehl ohne weitere Prüfung der Bedingung ausgelöst werden. Es ist aber auch möglich, dass die Bedingung bei Ausführung erneut geprüft wird. Die Zeitangabe muss im Format hh:mm:ss vorliegen.

Statt einer unmittelbaren Zeitangabe kann hier auch ein Verweis auf ein Reading eines Devices erfolgen : 
[NAME.reading] des Devices ->z.B. [dummy.state]

==== add action ====
Mit diesem Button kann ein weiteres Eingabefeld für das entsprechende Device angelegt werden, um z.B. einen weiteren Befehl (ggf.) zeitverzögert auszuführen.

==== delete this action ====
Mit diesem Button wird der entsprechende Befehl für das Device gelöscht.

==== check condition ====
[[Datei:MSwitch_Screen_7.png|mini|rechts|check]]
Die angegebenen 'conditions' werden in Zusammenhang mit ggf. ausgewählten Devices auf Syntax und Ergebnis geprüft. Es erfolgt eine Ausgabe des Prüfungsergebnisses.

==== Repeat und Repeatdelay ====
Man kann mehrfache Wiederholungen erzwingen. Repeat gibt dabei an, wie oft das Kommando wiederholt wird (Anzahl). Repeatdelay gibt an, wie viel Sekunden zwischen einzelnen Wiederholungen liegen sollen.

== Attribute ==
Folgende Attribute stehen zur Verfügung:

=== MSwitch_Debug (0:1:2:3:4) ===
0 - Abgeschaltet 
1 - Schaltet Felder zum testen der Conditionstrings etc. an 
2 - Alle ausgehenden Befehle werden nur simuliert und nicht ausgeführt. Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt 
2 - Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt 
4 - erweiterte Debug-Funktion (nur für Entwicklung - wechselnde Funktion ) 

=== MSwitch_Expert (0:1) ===
In der Liste der möglichen Trigger erscheint das Selectfeld 'GLOBAL'. Dieses ermöglicht das Setzen eines Triggers auf alle Events und damit nicht nur auf einzelne Devices. In einem weiteren Feld kann eine weitere Selektion der triggernden Events erfolgen.

Es stehen weitere Felder 'Repeats' und 'Repeatdelay in sec' zur Verfügung. Eine hier getätigte Einstellung bewirkt X-fache Wiederholung von gesetzten Befehlen im Abstand der gesetzten Sekunden.

Weiterhin kann über das Auswahlfeld 'priotity' bei jedem 'affectes device' die Reihenfolge beim abarbeiten der Befehle beeinflusst werden.

=== MSwitch_Sequenz <Suchmuster> ===
In diesem Attribut können ein oder mehrere Suchmuster angegeben werden ,die eine Schaltsequenz darstellen und vom Device erkannt werden.

Die Angabe muss folgende Syntax haben:
:<code>Device1:reading1:event1 Device1:reading1:event1-2 Device1:reading1:event1-3/..../....</code>

mehrere Suchmuster müssen durch "/" getrennt werden.

Beispiel:
:<code>Dummy:state:on Dummy:state:off Dummy:state:on</code>

Erkennt das Device dieses Suchmuster in den Schaltvorgängen des Devices (Dummy), wird das Reading "SEQUENCE" auf "match" gesetzt, das Reading "SEQUENCE_NUMBER" auf die Nummer der gefundenen Sequenz, wenn es mehrere Suchmuster gibt. Beide Readings können in den "Conditions" eines Schaltbefehles abgefragt werden.

=== MSwitch_Sequence_time <Zeit in Sekunden> ===
Beinhaltet die Zeit in Sekunden, die es dauern darf, um eine Sequenz vollständig auszuführen.

=== MSwitch_Extensions (0:1) ===
Es wird eine zusätzliche Schaltoption 'MSwitchToggle' in den Geräten angeboten. Diese kann genutzt werden, wenn zuschaltende Geräte eine Togglefunktion nicht von Haus aus anbieten.

Eine Angabe muss in folgendem Format gemacht werden:
:<code>on/off/state/suchmuster1/suchmuster2</code>, wobei die letzten drei Angaben optional sind.

Funktion: Bei Ausführung des Befehls wird das Gerät 'on' oder 'off' geschaltet (on/off), Voraussetzung ist, dass der 'state' dieses Gerätes auch den 'state on' oder 'off' annimmt. Sollte dieses nicht der Fall sein, so kann mit dem Feld 'state' angegeben werden, in welchem Reading der aktuelle Status vorkommt und wie dieser lautet (suchmuster1/suchmuster2). Dieses 'state' kann mehrere Angaben enthalten, das Vorkommen der Suchmuster ist aber Voraussetzung.

=== MSwitch_Delete_Delays (0:1) ===
Bewirkt das Löschen aller anstehende Timer (Delays) bei dem Auftreten eines erneuten, passenden Events. Bei der Option '0' bleiben bereits gesetzte Delays aus einem vorherigen, getriggertem Event erhalten und werden ausgeführt.

Empfohlene Einstellung (1)

=== MSwitch_Include_Devicecmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz liefern (bei Abfrage set DEVICE ?).

Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr angeboten.

Empfohlene Einstellung (1).

=== MSwitch_Include_Webcmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut Webcmd hinterlegt haben. Die in Webcmd hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten.

Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz (set DEVICE ?) liefern.

Empfohlene Einstellung (0), Einsatz nach Bedarf.

=== MSwitch_Activate_MSwitchcmds (0:1) ===
Fügt jedem vorhandenen Device as Attribut 'MSwitchcmd' hinzu.

=== MSwitch_Include_MSwitchcmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut MSwitchcmds hinterlegt haben. Die in MSwitchcmds hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr Angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz (set DEVICE ?) liefern.

Empfohlene Einstellung (0), Einsatz nach Bedarf.

=== MSwitch_Lock_Quickedit (0:1) ===
Voreinstellung für die Auswahlliste 'Affected Devices'. Bei der Option (1) ist diese voreingestellt gesperrt und kann nur über einen zusätzlichen Button geändert werden. Da es sich hier um ein Feld mit der Möglichkeit einer Mehrfacheingabe handelt handelt ist die Voreinstellung 1, um versehentliche nicht gewünschte Änderungen zu vermeiden (Auswahl einer Option ohne 'Strg' bewirkt das löschen aller bereits gesetzten Optionen).

Empfohlene Einstellung (1).

=== MSwitch_Startdelay (0:10:20:30:60) ===
Diese Einstellung beeinflusst den Start von MSwitch nach einem FHEM Start. MSwitch ignoriert für die angegebene Zeit in Sekunden alle eingehenden Events um u.a. Startverzögerungen zu vermeiden. Bei nicht gesetztem Attribut gilt hier eine Zeit von 30 Sekunden. Diese sollte auch nur in Ausnahmefällen bzw. bei besonderem Bedarf geändert werden.

Empfohlene Einstellung (30).

=== MSwitch_Ignore_Types ===
Beinhaltet eine Liste von Device''typen'', die in den Auswahllisten ''nicht'' dargestellt werden. Hier ist es sinnvoll, Devicetypen einzutragen, die in aller Regel nicht geschaltet werden oder nicht geschaltet werden können, um die Auswahllisten übersichtlicher zu halten. Einzelne Devicetypen sind durch Leerzeichen zu trennen.

Voreinstellung: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul.

Eine Angabe kann hier in 2 Arten getätigt werden:
# eine Liste von devicetypen.
# Angabe einer devspec z.B. "TYPE=watchdog". Hier ist zu beachten, dass in diesem Fall alle Geräte in die Ignoreliste einbezogen werden, die NICHT der devspec entsprechen. Weiterhin muss die devspec in Anführungszeichen gesetzt werden!

=== MSwitch_Trigger_Filter ===
Beinhaltet eine Liste von Events, die bei eingehenden Events unberücksichtigt bleiben. Diese werde dann auch nicht gespeichert.

Hier kann mit Wildcards (*) gearbeitet werden. Einzelne Events sind durch Komma ',' zu trennen.

Empfohlene Einstellung (keine).

=== MSwitch_Wait (sec)===
Bei gesetztem Attribut (Zeit in Sekunden) nimmt Das MSwitch Device für den eingestellten Zeitraum keine Befehle mehr entgegen und ignoriert eingehende Events

=== MSwitch_Event_Id_Distributor ===
Dieses Attribut hat nur dann eine Funktion, wenn auch das Attribut 'MSwitchExpert' auf '1' gesetzt ist.
Hier können verschiedene auslösende Events auf Aktionen mit angegebenen IDs umgeleitet werden.

Sollte bei den 'trigger details :' in einem Zweig ( cmd1 ) z.B. auf mehrere Events getriggert werden ( regex z.B. state:(on|off) ) so werden für beide Events jeweils der Zweig 'cmd1' - alle Aktionen ohneID - ausgeführt. Durch entsprechende Einträge kann für entsprechende Events auf eine Aktion umgeleitet werden, für die eine ID definiert ist. Die Syntax lautet:
:<code>state:on=>cmd1 ID 1,2</code>

Hier werden bei auslösendem Event 'state:on' nur die Aktionen aus cmd1 mit den IDs 1 und 2 ausgeführt. Mehrere Angaben sind durch new Line zu trennen.

=== MSwitch_Selftrigger_always (0,1)===
(dieses Attribut steht ab Modulversion 2.5 zur Verfügung)

Die Aktivierung dieses Attributes (1) bewirkt, dass alle SET Aktionen des Devices einen (internen) Event auslösen, auf die das Device selber reagiert. Diese Option kann zusätzlich zu einem vorhandenen Trigger aktiviert werden.

Diese Events sind lediglich Device intern, d.h es werden keine Modulübergreifenden Events ausgelöst.

Auftretende und auswertbare interne Events haben immer folgendes Format und können darüber ausgewertet werden.

MSwitch_Self:aktion:wert
MSwitch_Self:pct:100

Es werden nur interne Events für set-Aktionen ausgelöst, die im Attribut setlist hinterlegt sind.

Als weitere Besonderheit unterliegen diese internen Events nicht dem 'wait' Befehl/Attribut.

=== MSwitch_Mode (Notify,Full,Toggle,Dummy)===
Schaltet das Modul zwischen verschiedenen Modi um, mit entsprechend angepasster Weboberfläche.

==== Notify ====
Das Device kann nicht manuell umgeschaltet werden. Es gibt nur zwei ausführbare Zweige (execute 'cmd1' commands und execute 'cmd2' commands). Der Status des Devices wird nicht als 'on' oder 'off' angezeigt, sondern lediglich als 'active'

Dieser Mode ist am ehesten mit einem Notify zu Vergleichen.

==== Full ====
Es stehen alle Funktionen zur Verfügung.
==== Toggle ====
Sehr vereinfachter Mode. Es stehen keine verschiedenen Zweige zur Verfügung. Hier ist das Device manuell schaltbar und wird bei jedem definierten Event 'Umgeschaltet', entsprechend definierte Befehle für 'cmd1' oder 'cmd2' werden ausgeführt.
==== Dummy====
ACHTUNG: Funktionsänderung mit V2.61

Der Mode 'Dummy' ist ein eingeschränkter Modus.
Dieser bietet die Funktionalität eines Dummys kombiniert mit der Funktionalität eines Notifys und kann somit die gerne genutzte Kombination Dummy-Notify gegen ein Device ersetzen.

Achtung: Devices die einmal in dem Modus 'Dummy' gesetzt wurden können nicht wieder in einen anderen Mode geschaltet werden !

Der Dummy-Mode kann nur in einem neu angelegtem, leeren MSwitch aktiviert werden. Sobald ein angelegtes MSwitch einmal verändert wurde (modify trigger etc.) ist ein Umschalten nicht mehr möglich und die Option nicht mehr verfügbar.

=== MSwitch_Condition_Time (0,1)===
In der Grundeinstellung (0) werden für das zeitgesteuerte Schalten keine definierten Conditionen im Feld 'Trigger condition' überprüft, sondern die Schaltbefehle werden in jedem Fall ausgeführt. Mit der Einstellung (1) wird diese Überprüfung auch für zeitgesteuerte Befehle zugeschaltet.

=== MSwitch_Random_Time (HH:MM:SS-HH:MM:SS)===
Bei Aktivierung wird vor jedem Ausführen eines verzögerten Befehls ( Delay ) eine Zufallszeit generiert, die im Rahme der hier angegebenen Zeitspanne liegt. Auf diese Zufallszahl kann in den Delays zugegriffen werden, durch die Angabe '[random]' statt einer direkten Zeitangabe. Bei nicht gesetztem Attribut ergibt die Angabe von ' [random] ' hier immer '00:00:00'

=== MSwitch_Random_Number ===
Bei Aktivierung dieses Attributes (der Inhalt kann einen beliebige Zahl sein) werden vom Device 2 Readings angelegt (Device:RandomNr) und (Device:RandomNr1). RandomNr wird vor jedem Ausführen eines Befehls aktualisiert und neu generiert, d.h wenn ein MSwitch Device mehrere Geräte schaltet, wird (auch in einem Durchgang) vor jedem Befehl dieses Reading neu gesetzt. RandomNr1 wird lediglich bei Ausführung des MSwitch Devices einmal neu gesetzt, d.h. nicht vor jedem Befehl der ausgeführt wird.
Die Readings werden mit einer Zufallszahl zwischen 0 und dem hier eingestellten Wert gesetzt.

Auf diese Readings kann in jeder Condition mit z.B. '[$NAME:ReadingNr1] = 1' zugegriffen werden.

D.h., das in der Condition angegebene Reading ( [$NAME:ReadingNr1] ) muss in diesem Fall den Wert 1 angenommen haben, ansonsten wird der Befehl nicht ausgeführt.
Der Befehl wird somit nur mit einer Wahrscheinlichkeit von 1 zu ( gesetzter Wert im Attr. ) ausgeführt.

=== MSwitch_Reset_EVT_CMD1(2)_COUNT ===
Bei Aktivierung dieses Attributes steht in den Readings das Reading 'EVT_CMD1_COUNT' bzw. 'EVT_CMD2_COUNT' zur Verfügung. Dieses kann in den Conditions genutzt werden, um z.B. nur bei jedem x-ten Eintreffen eines auslösenden Events einen Befehl auszuführen. Bei jedem Eintreffen eines gültigen Events werden die Zähler um 1 erhöht (für den jeweiligen Zweig).
Ist hier der Wert '0' eingetragen, wird der Zähler fortlaufend (endlos) erhöht. Wird ein Wert größer 0 eingetragen, wird der Zähler mit Erreichen dieses Wertes automatisch wieder auf Null gesetzt.

Mit Löschen dieses Attributes werden die entsprechenden Readings ebenfalls gelöscht.

=== MSwitch_Safemode (0:1)===
Bietet einen (gewissen) Schutz vor falschen Konfigurationen und somit entstehenden Endlosschleifen.
Bei aktiviertem Attribut (1) erkennt das Modul Endlosschleifen eines Devices und beendet diese.

In diesem Fall erfolgt ein Logeintrag und das Device wird per Attribut auf 'Disabled' gesetzt.
Es wird ein letztes Event generiert, auf das reagiert werden kann:
:<code>2018-05-31 09:39:21 MSwitch <NAME> Safemode: on</code>
Im Webinterface erfolgt bei betroffenem Device ein entsprechender Hinweis.

In der Grundkonfiguration ist dieses Attribut nicht gesetzt, es empfiehlt sich aber, bei neuen (komplizierten) Devices, dieses - zumindest anfänglich - zu aktivieren.

=== MSwitch_Read_Log(0:1)===
Ermöglicht den Zugriff auf das Logfile als Trigger.

Hier gibt es mehrere Konfigurationsmöglichkeiten:
* Bei aktiviertem Attribut enthält die Auswahl des Triggerdevices die Option 'LOGFILE'. Bei dieser Auswahl werde alle Logeinträge erkannt und in ein internes Event umgewandelt, auf das regiert werden kann.
* bei aktiviertem Attribut und der Auswahl 'GLOBAL' im 'Trigger_Device' wird auf ALLE Events und alle Logeinträge reagiert.
* bei aktiviertem Attribut und der Auswahl eines bestimmten Devices im 'Trigger_Device' wird auf alle Events und auf alle Logeinträge des gewählten Devices reagiert. Hier ist zu beachten, dass FHEM mir keine Möglichkeit bietet, wirklich herauszufinden, welches Device denn nun einen Logeintrag generiert hat. D.h., dieses wird vom Vorhandensein des Namens im Logeintrag abhängig gemacht und MSwitch reagiert nur dann auf einen Logeintrag, wenn der Name des Devices in diesem Eintrag vorhanden ist.

=== MSwitch_Help(0:1)===
Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.

=== MSwitch_Comments(0:1)===
Schaltet Kommentarfelder zu den einzelnen 'affected_devices an.

=== MSwitch_generate_Events(0:1)===
Reduziert bei Einstellung '1' die vom MSwitch-Devices erzeugten Events auf ein absolutes Minimum. Insbesondere bei Verwendung von 'MSwitch_Read_Log' zu empfehlen.

=== MSwitch_Startdelay ===
Bestimmt die Verzögerungszeit des MSwitches nach FHEM-Start in Sekunden. In diesem Zeitraum reagiert das ??Event??(Red: ist hier "Device" gemeint?) nicht auf Events. Die Vorgabe ist hier zehn Sekunden. Diese wird auch dann angenommen, wenn das Attribut nicht gesetzt ist.

=== MSwitch_Inforoom ===
Mit diesem Attribut wird die Raumansicht eines mit dem Attribut bestimmten Raumes verändert. Dadurch sollen die wichtigsten Informationen aller MSwitch-Devices auf eine Seite dargestellt werden. Zur Nutzung sollten alle MSwitch-Devices (zusätzlich) in einen Raum sortiert werden und dieser Raum im Attribut eingestellt werden.

Wichtig: Eine Änderung dieses Attributes bewirkt immer eine Änderung dieses Attributes in ''allen'' MSwitch devices: Es muss nur in einem Device gesetzt oder gelöscht werden um alle Devices zu erfassen.

<gallery>
MSwitch_Screen_1.png|Raumansicht des Raumes MSwitch mit gesetztem Attribut 'MSwitch'
MSwitch_Screen_2.png|Raumansicht des Raumes MSwitch ohne gesetztes Attribut
</gallery>

Es werden folgende Informationen bereitgestellt:
* Infobutton zeigt den im Device gespeicherten Textes des Attributes 'comment'
* Device und Events, die das Device triggern
* Zeiten, zu denen verschiedene Zweige des Devices ausgeführt werden
* Devices, die durch das MSwitch Device geschaltet werden
* State des Devices

== Integrierte Funktionen ==

=== Average ===
Folgt

=== Tendency ===

Syntax:
[TEND<wert>:<reading>] > <Mindestwert>

Beispiel:
[TEND2:countdown] > 2

Reading:
Entspricht dem getriggerten Reading.

Wert:
Es wird jeweils der Durchschnitt von 2 Wertepaaren gebildet. In diesem Fall werden die letzten 4 Werte herangezogen. 
Paar 1 = Aktueller und letzter Wert, Paar 2 = Die 2 vorherigen Werte. 
Bei TEND3 werden die letzten 6 Werte zur Paarbildung genutzt.

Mindestwert:
Der Wertunterschied zwischen den Wertepaaren, der minimal erreicht sein muss, um eine Tendenz zu erkennen.

Rechenzeichen (><):
Dieses ist hier nicht als Rechenzeichen zu werten, sonder als Tendenz-Anzeige. ( < es wird nach fallender Tendenz gesucht / > sucht nach steigender Tendenz).

Schaltung erfolgt einmalig bei Erkennung der gesuchten Tendenz.
Danach erfolgt keine Schaltung mehr, solange bis eine Tendenz-Umkehr erfolgt ist.
Erst dann erfolgt wieder eine Schaltung bei erneuter Tendenz-Umkehr in gesuchte Richtung.

=== Difference ===

Syntax:
[DIFF<wert>:<reading>] > <differenz>

Beispiel:
[DIFF2:countdown] > 0

Reading:
Entspricht dem getriggerten Reading.

Wert:
Gespeicherter Wert (in diesem Fall der vorletzte).

Differenz:
Geforderter Differenz zwischen aktuellem und vorletztem Wert.

Schaltung erfolg wenn diese Bedingung 'wahr' ist.

Folgende Readings werden zur Verfügung gestellt:

DIFFERENCE (true/false) - Schaltbedingung erkannt ja/nein

DIFFDIRECTION (up/down) - Richtung der erkannten Bedingung (steigend/fallend)

=== Increase ===
Folgt

== Tipps, Tricks, Kurzbeispiele ==
Wird stetig ergänzt.

=== Blinken - Falls nicht im Device vorhanden ===
[[Datei:MSwitch MSwitchblink.png|center|704px]]
 
Lässt ein beliebiges Device 5 mal togglen, mit einem Intervall von 0.5 Sekunden (Blinkzeit somit 2,5 Sekunden) 
Die MSwitchtoggle-Funktion muss per ATTR aktiviert werden. 
Die Repeatfunktion ist nur im Expertmode verfügbar, auch per ATTR einstellbar.

=== Linearschalter ===
Umsetzung eines Linearschalters mit MSwitch.

Eingang: Beliebiges Reading als numerischer Wert.

Ausgang: Wird entsprechend Linear / oder umgekehrt Linear zum Eingang geschaltet.

Folgend die Rawdefinition des MSwitchdevices und zweier Dummys (selbsterklärend)

Alle Devices werden im Raum Lineartest angelegt, die Dummy müssen zuerst angelegt werden.

<pre>defmod linearausgang dummy
attr linearausgang room Lineartest
attr linearausgang setList state:slider,0,1,100
attr linearausgang webCmd state
setstate linearausgang state 57
setstate linearausgang 2018-06-06 18:06:12 state state 57</pre>

<pre>defmod lineareingang dummy
attr lineareingang room Lineartest
attr lineareingang setList state:slider,0,1,15000
attr lineareingang webCmd state
setstate lineareingang 6422
setstate lineareingang 2018-06-06 18:06:12 state 6422</pre>

<pre>defmod Linearschalter MSwitch lineareingang # linearausgang FreeCmd
attr Linearschalter MSwitch_Debug 0
attr Linearschalter MSwitch_Delete_Delays 1
attr Linearschalter MSwitch_Expert 0
attr Linearschalter MSwitch_Extensions 0
attr Linearschalter MSwitch_Help 0
attr Linearschalter MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr Linearschalter MSwitch_Include_Devicecmds 1
attr Linearschalter MSwitch_Include_MSwitchcmds 0
attr Linearschalter MSwitch_Include_Webcmds 0
attr Linearschalter MSwitch_Inforoom MSwitch
attr Linearschalter MSwitch_Lock_Quickedit 1
attr Linearschalter MSwitch_Mode Notify
attr Linearschalter room Lineartest

setstate Linearschalter active
setstate Linearschalter 2018-06-06 18:03:50 .Device_Affected FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,linearausgang-AbsCmd1
setstate Linearschalter 2018-06-06 18:04:35 .Device_Affected_Details FreeCmd-AbsCmd1,cmd,cmd,{my $eingang =ReadingsVal( "lineareingang"## "state"## 0 );;my $emin=0;;my $emax=15000;;my $amin=100;;my $amax=0;;$eingang = $emin if $eingang < $emin;;$eingang = $emax if $eingang > $emax;;my $y= (($amax-$amin)/($emax-$emin)*($eingang-$emin))+$amin;;readingsSingleUpdate( $hash## "to_set"## int ($y)## 1 );;},,delay1,delay1,000000,000000,,,0,0|FreeCmd-AbsCmd2,cmd,cmd,,,delay1,delay1,000000,000000,,,0,0|linearausgang-AbsCmd1,state,no_action,[Linearschalter:to_set],,delay1,delay1,000000,000000,,,0,0
setstate Linearschalter 2018-06-06 18:06:12 .Device_Events no_trigger
setstate Linearschalter 2018-06-04 18:24:21 .First_init done
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_cmd_off no_trigger
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_cmd_on *
setstate Linearschalter 2018-06-06 17:58:56 .Trigger_condition
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_off no_trigger
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_on no_trigger
setstate Linearschalter 2018-06-06 17:58:56 .Trigger_time
setstate Linearschalter 2018-06-04 18:24:21 .V_Check V 0.3
setstate Linearschalter 2018-06-06 18:06:12 EVENT state: 6422
setstate Linearschalter 2018-06-06 18:06:12 EVTFULL lineareingang:state: 6422
setstate Linearschalter 2018-06-06 18:06:12 EVTPART1 lineareingang
setstate Linearschalter 2018-06-06 18:06:12 EVTPART2 state
setstate Linearschalter 2018-06-06 18:06:12 EVTPART3 6422
setstate Linearschalter 2018-06-06 18:06:12 Exec_cmd set linearausgang state [Linearschalter:to_set]
setstate Linearschalter 2018-06-06 17:58:56 Trigger_device lineareingang
setstate Linearschalter 2018-06-06 18:00:47 Trigger_log off
setstate Linearschalter 2018-06-06 18:06:12 last_event state: 6422
setstate Linearschalter 2018-06-04 18:39:56 state active
setstate Linearschalter 2018-06-06 18:06:12 to_set 57</pre>

MSwitch -Configfile (bei Bedarf)
<pre>#V V1.54
#S .Device_Affected -> FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,linearausgang-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{my $eingang =ReadingsVal( "lineareingang"## "state"## 0 )[S]my $emin=0[S]my $emax=15000[S]my $amin=100[S]my $amax=0[S]$eingang = $emin if $eingang < $emin[S]$eingang = $emax if $eingang > $emax[S]my $y= (($amax-$amin)/($emax-$emin)*($eingang-$emin))+$amin[S]readingsSingleUpdate( $hash## "to_set"## int ($y)## 1 )[S]},,delay1,delay1,000000,000000,,,0,0|FreeCmd-AbsCmd2,cmd,cmd,,,delay1,delay1,000000,000000,,,0,0|linearausgang-AbsCmd1,state,no_action,[Linearschalter.to_set],,delay1,delay1,000000,000000,,,0,0
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> *
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> lineareingang
#S Trigger_log -> off
#S last_event -> state: 6422
#S state -> active
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Help -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Include_Webcmds -> 0
#A room -> Lineartest
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 0
#A MSwitch_Lock_Quickedit -
</pre>

== Links ==
* Thread über das Modul im {{Link2Forum|Topic=86199|LinkText=FHEM Forum}}
* {{Link2Forum|Topic=100119|Message=936495|LinkText=Gäste-WLAN der Fritzbox auswerten und Login per Telegram senden}}
* {{Link2Forum|Topic=86199|Message=930133|LinkText=Schalten von vier Kanälen mit einem MSwitch-Device}}
* {{Link2Forum|Topic=99219|Message=926652|LinkText=Batterie-Überwachung. 1xTäglich per Telegram senden}}
* {{Link2Forum|Topic=101091|Message=945389|LinkText=Licht (Alarm) in einem bestimmten Zeitraum schalten}}
* {{Link2Forum|Topic=100949|Message=944284|LinkText=Über Dummy-Schalter ein Timer (EIN/AUS) aktivieren}}
* {{Link2Forum|Topic=103083|Message=967710|LinkText=Ladezeit von Akku ermitteln u. Steckdose entsprechend schalten}}