SolarForecast - Solare Prognose (PV Erzeugung) und Verbrauchersteuerung: Unterschied zwischen den Versionen

Aus FHEMWiki
Zur Navigation springen Zur Suche springen
K (syntaxhighlight korrigiert, Formatierung leicht überarbeitet)
Zeile 198: Zeile 198:
[[Datei:Solarforecast Beispiel Screenshot.png|zentriert|mini|Ergebnis nach dieser Konfiguration]]
[[Datei:Solarforecast Beispiel Screenshot.png|zentriert|mini|Ergebnis nach dieser Konfiguration]]


== Verbraucherregistrierung und Verbrauchersteuerung ==
== Einbinden / Registrieren 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.
 
 
 
=== 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 angebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben.
Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern sich über die Einschaltdauer.
 
Die Angabe von '''power''' definiert die Nominalleistung (Watt) die für den Verbraucher laut Typenschild vom Hersteller angegeben wird. Diese Angabe wird vom Modul bei der Planung der Einschaltzeiten verwendet indem die Nominalleistung in das Verhältnis zur Solarprognose bzw. Verbrauchsprognose des Netzes gesetzt wird. Weiterhin ist dieser Wert auch wichtig um später den tatsächlichen Einschaltzeitpunkt auszuführen wenn ein realer PV Überschuß festgestellt wird.
 
Es ist möglich '''power=0''' zu setzen. Das führt dazu, dass die Planung und letzendlich auch der Schaltvorgang unabhängig von der Solarprognose bzw. einem realen PV Überschuß vorgenommen wird. 
 
Es werden weitere Schlüsseleingaben vorgenommen:
 
Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off
 
Mit dem Schlüssel '''icon''' legt man ein Icon fest welches in der Grafik für den Verbraucher verwendet wird. Der '''mode''' definiert die Art und Weise der Einplanung:
 
 
;can: Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuß. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuß.
 
;must: Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuß vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuß. 
 
 
Mit '''notbefore''' wird festgelegt, dass die Einplanung nicht vor neun Uhr morgens erfolgen soll auch falls schon genügend PV Überschuß vorhanden wäre. Der Schlüssel '''mintime''' definiert die Einplanungsdauer des Verbrauchers in Minuten im einfachsten Fall. Die hier verwendete Angabe '''SunPath''' ist ein Spezialfall. Der Verbraucher soll von Sonnenaufgang bis Sonnenuntergang eingeschaltet werden, wobei die Angabe von 60 bzw. -60 ein relative Verschiebung bewirken. Dadurch wird das Einschalten 60 Mintuen nach Sonnenaufgang bis 60 Minuten vor Sonnenuntergang geplant.
 
Die Schlüssel '''on''' und '''off''' teilen dem Modul die jeweiligen gültigen Ein- und Aus-Kommandos mit, mit dem das (Shelly)Device geschaltet werden kann. Werden diese Schlüssel nicht oder "leer" (on= off=) angegeben, erfolgt kein Schalten durch das Modul, nur die Planungsdaten werden erzeugt.
 
Die Verbraucherregistrierung wird mit weiteren Angaben ergänzt um das gewünschte Verhalten zu erreichen:
 
Shelly.shellyplug3 type=heater power=1700 icon=vent_ventilation mode=can notbefore=09 mintime=SunPath:60:-60 on=on off=off etotal=relay_0_energy_Wh:Wh 
                    pcurr=relay_0_power:W auto=automatic interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2
 
In '''etotal''' wird der Readingname des Shelly Devices angegeben welches die Summe der verbrauchten Energie (Wh/kWh) des Consumer Device liefert. D.h. es muß ein sich stetig erhöhender Wert sein. Durch die Auswertung dieses Readings ermittelt das Modul die in bestimmten Zeiteinheiten verbrauchte Energie zur weiteren Verwendung.
 
In dem Shelly Device ist per default ein solches Reading nicht vorhanden. Über userReadings kann in dem Device Shelly.shellyplug3 ein Reading für etotal erzeugt werden:
 
userReadings relay_0_energy_Wh:relay_0_energy.* monotonic { sprintf "%.0f", ReadingsVal ($name, 'relay_0_energy', 0) / 60 }
 
Der Schlüssel '''pcurr''' enthält das Reading in Shelly.shellyplug3 welches den aktuellen Energieverbrauch liefert.
 
'''auto''' enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben.
Der User kann durch Setzen des Readings '''automatic=0''' das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch 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) ausschalten nachdem er bei Unterschreiten einer bestimmten Solltemperatur eingeschalten wurde.
Der Schlüssel '''interruptable''' übernimmt diese temporäre Schaktsequenzen.
 
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 angegbene 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 heißt wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0.
In diesem Fall matcht der angebene Regex in:
 
interruptable=og.bad.wandthermostat:diff-temp:'''[0-9]\.[0-9]''':0.2
 
und Shelly.shellyplug3 wird ausgeschaltet. Unterschreitet der Wert von diff-temp 0, matcht der Regex nicht mehr und der Verbraucher wird wieder eingeschaltet. Dabei wird die angegebene Hysterese berücksichtigt, d.h der Verbraucher wird erst ausgeschaltet wenn "diff-temp - 0.2 >= 0" wahr ist.
 
Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung dass ein entsprechender PV-Überschuß vorliegt. Diese Bedinung wirde durch die Angabe von '''power=1700''' bewirkt. Soll der zwangsweise PV Überschuß ignoriert werden, kann '''power=0''' angegeben werden.
 
<br>
 
=== Praxisbeispiele und Lösungsansätze für Verbrauchersteuerungen ===
=== Praxisbeispiele und Lösungsansätze für Verbrauchersteuerungen ===



Version vom 13. April 2023, 22:06 Uhr


Clock - Under Construction.svg An dieser Seite wird momentan noch gearbeitet.


Info blue.png
Das Modul 76_SolarForecast ist im Stadium "Testing" und ist zur Zeit noch nicht im offiziellen FHEM Repository verfügbar. Die vorliegende Wiki-Seite befindet sich im Aufbau.


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

SolarForecast ist ein integratives Modul zur Gewinnung solarer Vorhersagedaten, deren Verarbeitung und grafischen Darstellung. Desweiteren bietet es die Möglichkeit, in FHEM definierte Verbraucher in einem SolarForecast-Device zu registrieren und eine PV Prognose basierte Steuerung der Verbraucher vom Modul übernehmen zu lassen.

Das Modul ist insbesondere durch folgende Eigenschaften gekennzeichnet:

grafische Ansicht SolarForecast
  • zur Gewinnung solarer Strahlungswerte werden die SolCast API oder alternativ DWD Stahlungswerte-Stationen integriert
  • es wird sowohl die Erzeugungsprognose als auch eine Verbrauchsprognose erstellt
  • Wetterdaten werden über DWD Wetter-Stationen integriert
  • 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 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 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
  • trotz der hohen Komplexität wird dem Anwender durch eine "Guided Procedure" bei der Gerätedefinition der Einstieg erleichtert und damit ein optimales Benutzerlebnis 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

Definition

Die Hilfe zu dem Modul ist über "help SolarForecast de" aufrufbar.

Konfigurationsbeispiele

Beispiel 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

define DWD DWD_OpenData
attr DWD DbLogExclude .*
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastResolution 1
attr DWD forecastStation H568
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date at Blintrop
attr DWD verbose 2

InverterDummy

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

SMA_Energymeter

define 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 group Energy Meter
attr SMA_Energymeter icon measure_power@green
attr SMA_Energymeter interval 15
attr SMA_Energymeter room 020_PV,Energie
attr SMA_Energymeter serialNumber XXXXXXXXXX    
attr SMA_Energymeter stateFormat state W (IN -) P1: L1_Saldo_Wirkleistung P2: L2_Saldo_Wirkleistung P3:L3_Saldo_Wirkleistung
attr SMA_Energymeter verbose 2

BatteryDummy

define 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)." %"}

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

define N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
 # 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("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));;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2

SolarForecast

define Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast affect70percentRule 0
attr Forecast comment update per "wget -qO /opt/fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr Forecast ctrlInterval 10
attr Forecast disable 0
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicAnimate 1
attr Forecast flowGraphicShowConsumer 1
attr Forecast flowGraphicShowConsumerDummy 1
attr Forecast flowGraphicShowConsumerPower 1
attr Forecast flowGraphicShowConsumerRemainTime 1
attr Forecast flowGraphicSize 400
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvForecast
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvReal
attr Forecast graphicHeaderDetail all
attr Forecast graphicHistoryHour 4
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 0
attr Forecast group Energy Meter
attr Forecast room 020_PV,Energie
attr Forecast stateFormat Current_PV
attr Forecast verbose 2

setstate Forecast 2023-03-03 19:35:46 currentBatteryDev BatteryDummy pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus
setstate Forecast 2023-02-27 19:53:12 currentForecastDev DWD
setstate Forecast 2023-02-27 22:42:02 currentInverterDev InverterDummy pv=total_pac:kW etotal=etotal:kWh capacity=9500
setstate Forecast 2022-03-29 08:44:11 currentMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh
setstate Forecast 2022-03-06 20:12:10 currentRadiationDev DWD
setstate Forecast 2023-04-05 16:44:50 inverterStrings Garage_SE,Garage_NW,Haus_NW,Haus_SW
setstate Forecast 2023-04-05 16:44:32 moduleDirection Garage_SE=SE Garage_NW=NW Haus_NW=NW Haus_SW=SW
setstate Forecast 2023-04-05 16:45:13 modulePeakString Garage_SE=2.75 Garage_NW=3.2 Haus_NW=2.230 Haus_SW=2.230
setstate Forecast 2023-04-05 16:45:39 moduleTiltAngle Garage_SE=35 Garage_NW=35 Haus_NW=45 Haus_SW=45

So sollte es dann als Ergebnis aussehen:

Ergebnis nach dieser Konfiguration

Einbinden / Registrieren 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.


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 angebene Nominalleistung abgerufen und wird über die Zeit gleichbleiben. Eine Waschmaschine oder ein Trockner rufen über ihre Laufzeit die Leistung nicht gleichbleibend ab und ändern sich über die Einschaltdauer.

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

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

Es werden weitere Schlüsseleingaben vorgenommen:

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

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


can
Die Einplanung erfolgt zum Zeitpunkt mit wahrscheinlich genügend verfügbaren PV Überschuß. Der Start des Verbrauchers zum Planungszeitpunkt unterbleibt bei ungenügendem PV-Überschuß.
must
Der Verbaucher wird optimiert eingeplant auch wenn wahrscheinlich nicht genügend PV Überschuß vorhanden sein wird. Der Start des Verbrauchers erfolgt auch bei ungenügendem PV-Überschuß.


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

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

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

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

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

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

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

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

auto enthält das Reading in Shelly.shellyplug3 welches zur Freigabe/Sperrung der autmatischen Schaltung durch das Modul dienen soll. Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt. Dadurch ist per default das automatische Schalten von Shelly.shellyplug3 durch das Modul freigegeben. Der User kann durch Setzen des Readings automatic=0 das automatische Schalten durch das Modul sperren und mit "1" wieder freigeben. Dadurch 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) ausschalten nachdem er bei Unterschreiten einer bestimmten Solltemperatur eingeschalten wurde. Der Schlüssel interruptable übernimmt diese temporäre Schaktsequenzen.

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 angegbene 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 heißt wenn die Raumtemperatur die Solltemperatur erreicht oder höher ist, wird diff-temp >= 0. In diesem Fall matcht der angebene Regex in:

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

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

Für das Wiedereinschalten des Heizlüfters ist außerdem Voraussetzung dass ein entsprechender PV-Überschuß vorliegt. Diese Bedinung wirde durch die Angabe von power=1700 bewirkt. Soll der zwangsweise PV Überschuß ignoriert werden, kann power=0 angegeben werden.


Praxisbeispiele und Lösungsansätze für Verbrauchersteuerungen

weiterführende Links