Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

[andi11]

Hab jetzt das SVG zum laufen bekommen.
async im DBLog device aktiviert. In meiner SVG Config hatte ich scheinbar einen Fehler bei der Defintion. Egal welchen Wert ich benutzt hatte (auch wenn es was ganz anders war, dass sicher ging wurde nix angezeigt) Habs jetzt nochmal neu zusammengesetzt jetzt geht das.
Vielen Dank

2te Frage: Die Autokorrektur generiert aus dem Reading SW_Total_DC_P_sumOfAllPVInputs  die Korrekturwerte. Ich kann leider nur mit AC Werten dienen (die ja an sich auch die wichtigeren sind)
Ich habe ein Dummy Device in dem ich momentan eigenverbrauch usw berechne. Desweiteren einen Dummy der die Momentanleistung und Absolutwerte aller Wechselrichter summiert. Soll ich den Forecast lieber in den Zähler rein packen? Bin unsicher da ich momentan einen Batteriewechselrichter und 2 getrennte PV Wechselrichter habe. Demnächst wird der Batteriewechselrichter und 1 PV Wechselrichter durch einen Solis RHI Hybridwechselrichter getauscht. Ob ich dann eine brauchbare Momentanerzeugungsleistung habe weiß ich noch nicht.
Habe noch Direktzugang zu allen Wechselrichters über HTTPMOD und gehe davon aus dass ich das beim neuen auch haben werde. Dieser Weg gibt aber nicht soviele Infos her

[ch.eick]

Hab jetzt das SVG zum laufen bekommen.
async im DBLog device aktiviert. In meiner SVG Config hatte ich scheinbar einen Fehler bei der Defintion. Egal welchen Wert ich benutzt hatte (auch wenn es was ganz anders war, dass sicher ging wurde nix angezeigt) Habs jetzt nochmal neu zusammengesetzt jetzt geht das.
Vielen Dank

2te Frage: Die Autokorrektur generiert aus dem Reading SW_Total_DC_P_sumOfAllPVInputs  die Korrekturwerte. Ich kann leider nur mit AC Werten dienen (die ja an sich auch die wichtigeren sind)
Ich habe ein Dummy Device in dem ich momentan eigenverbrauch usw berechne. Desweiteren einen Dummy der die Momentanleistung und Absolutwerte aller Wechselrichter summiert. Soll ich den Forecast lieber in den Zähler rein packen? Bin unsicher da ich momentan einen Batteriewechselrichter und 2 getrennte PV Wechselrichter habe. Demnächst wird der Batteriewechselrichter und 1 PV Wechselrichter durch einen Solis RHI Hybridwechselrichter getauscht. Ob ich dann eine brauchbare Momentanerzeugungsleistung habe weiß ich noch nicht.
Habe noch Direktzugang zu allen Wechselrichters über HTTPMOD und gehe davon aus dass ich das beim neuen auch haben werde. Dieser Weg gibt aber nicht soviele Infos her

Hallo Andi,
meine Empfehlung wäre, einen Master Wechselrichter WR_1 zu definieren, was bei mir der WR mit dem Speicher ist.
Dort sind bei mir per Definition alle zentralen Werte abgelegt, die die gesamt Anlage betreffen.
Eine PV-Anlage besteht somit aus ein 1-n Wechselrichtern und eventuellem Zubehör, also auch einem Speicher.
Deshalb lege ich im WR_1 auch die Prognose ab.
Im WR_1 habe ich auch die die String Informationen der anderen WR abgelegt, WR_1 hat string 1 und 2, an String 3 ist der Speicher und alle weiteren Strings, also 3 und 5
habe ich einfach über userreadings rein gemapped.
Auch der Hausverbrauch und andere zentrale Werte sind dort zu finden. In den userreadings werden somit alle zusammengehörigen Werte behandelt, da diese ja auch in einem Schwarm teilweise korrigiert werden müssen.

Am Anfang ist es erstmal wichtig alle Daten, die im Zugriff sind zu sammeln und per Namensstandard zu gruppieren. Es ist dabei egal, über welchen Weg Du daran kommst, also HTTPMOD oder ModBus oder was auch immer.

Für die Struktur schau Dir eventuell nochmal mein Wiki an, da erkennst Du in der Namensgebung was zusammen gehört und die Struktur dahinter.

Die Autokorrektur solltest Du jetzt besser noch weg lassen, da Du zuerst die Prognose generell auf Deine Wechselrichter und die Strings anpassen musst.
Erst wenn das passt, kann man dann noch etwas nach justieren. Ob Du die AC oder DC Werte dann korrigierst ist eigentlich egal, das optische Ergebnis ist das wichtige dabei.

Gruß
    Christian

[ch.eick]

Von Andi

Andere Frage: Ich wohne direkt am Fuß eines Hügels, der östlich von mir liegt. Dementsprechend verschattet der in der früh  durch die höher gelegenen Häuser. Gibt es eine Möglichkeit z.b. solar_plain so zu erweitern dass es das etwas kompensiert? Es müsste eine Kombination von Azimuth und Elevation sein, aber wie ich das verrechnen kann weiß ich nicht. Schlimmstenfalls pro Modulgruppe einzeln. Sowas wie "Mindestsonnenstand dass die Anlage arbeitet"

Solar_plain()
Die Funktion reagiert auf das Attribut verbose >=3 vom Device mit dem Namen Astro

Dann gibt es zwei Grenzbereiche, die man sehr fein granular justieren könnte.

- Durch optische Kontrolle sollte man beobachten, zu welcher Uhrzeit die Sonne morgens und abends zu den kritischen
  Zeiten das erste mal richtig auf den Modulen steht. Hier ist natürlich auch das Datum wichtig und auch Schatten von Bergen oder dem Nachbarn.
- Aus den Wechselrichter Werten erkennt man zusätzlich ab wann die Produktion beginnt und wann sie endet.
- Dann aktiviert man das Logging
- und verwendet die Testaufrufe aus dem Wiki, man muss also nicht warten, bis eine Astro Konstellation in der Natur auftritt
- Bei den Testaufrufen geht man nun auf 06:00, 07:00, 08:00, 09:00 Uhr und schaut sich den Faktor an
- In meinem Bild kommt von 6-8 Uhr eine 0.001 zurück, wodurch die Prognose auf 0 gezogen wird.
- ab 9 Uhr geht es dann erst richtig los.
- Dann kann man im Log die Elevation ablesen und an der Stelle "if ($elevation <= 0.1798)" ganz vorsichtig etwas nach justieren

Code Auswählen Erweitern


    # avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
    if ($elevation <= 0.1798) {
      if ($verbose >= 3) { Log 3, "Solar_plain factor           : ".$factor };
      return($factor);
    };

und

    # avoid too big values
    if ($factor > - 0.05 && $factor < 0.05) {
      $factor = 0.05
    };
    if ($verbose >= 3) { Log 3, "Solar_plain factor           : ".$factor };
    return ($factor);



Wichtig sind natürlich auch die korrekten Astro Werte in fhem.cfg, insbesondere die altitude, also die Höhedes Standortes + die Haushöhe

Code Auswählen Erweitern


attr global altitude 93
attr global latitude 49.85345
attr global longitude 8.46780


- Zum Schluss sollte man das auch noch mal mit Sommer und Winter Daten testen und dort einen goldenen Mittelweg finden.

Bitte denkt immer daran, das ist nur eine Näherung an die Natur. An manchen Tagen passt es bei mir auf 1-2 kWh und an anderen Tagenliegt es halt rund 10 % daneben.
Für meine Optimierungsentscheidungen ist es jedoch gut genug und dazu noch unabhängig von ständig wechselnden Diesten im WEB.
Der Deutsche Wetterdienst (DWD) ist in seinem Angebot ziemlich stabiel und hält sich dazu noch an normierte Wetter Größen.

VG
   Christian

[andi11]

super Ansatz. Wie kann ich passende Grenzwerte finden die Sommer und Winter passt?
Muss die Sonne einfach eine gewisse Höhe überschreiten? Die Werte kann ich dank Vergleich Prognose und aktueller Produktion ja fast aus einem Chart lesen. Aber passt dieser Wert automatisch für das ganze Jahr?

Ich würde die Funktion tendenziell so erweitern dass Grenzen als Parameter aus dem _config device übergeben werden können, da sich der Effekt bei meinen Panelgruppen unterschiedlich auswirkt.

[ch.eick]

super Ansatz. Wie kann ich passende Grenzwerte finden die Sommer und Winter passt?
Muss die Sonne einfach eine gewisse Höhe überschreiten? Die Werte kann ich dank Vergleich Prognose und aktueller Produktion ja fast aus einem Chart lesen. Aber passt dieser Wert automatisch für das ganze Jahr?

Ich würde die Funktion tendenziell so erweitern dass Grenzen als Parameter aus dem _config device übergeben werden können, da sich der Effekt bei meinen Panelgruppen unterschiedlich auswirkt.

Oh, ich hatte das Bild noch vergessen.
Das es durch die DWD Daten nur im ein Stunden Rythmus berechnet wird wandert die WR Kurve, wie im Bild zu sehen gerade langsam in die früheren Stunden.
Ab einem gewissen Datum kommt dann aus Solar_plain() für 7:00 Uhr keine 0.001 mehr und schon klappt die Prognose auf der Zeitachse auseinander.
Es bleibt halt immer nur eine Näherung. Wenn Du mal einen kompletten Jahreszyklus durchlaufen hast wirst Du eine Elevation finden, die näherungsweise passt.

- Wolken und Regen lässt sich noch anpassen, wenn man z.B. in seiner Region Effekte hat, die besonders berücksichtigt werden müssen.
- Danach kommt dann ein eventueller forecast_faktor, mit dem man die komplette Prognose heben oder senken kann.
- auch die Modul Ausrichtung kann gradweise eingetragen werden, also nicht nur -90 , 0 , 90
- Und ganz zum Schluss kommt dann die Autokorrektur, für die man aber erstmal Daten in der Datenbank haben muss

Das mit dem Parameter wollte ich auch schon gemacht haben, der reagiert aber so stark auf Veränderung, dass sich eh jeder bei mir meldet

[andi11]

- auch die Modul Ausrichtung kann gradweise eingetragen werden, also nicht nur -90 , 0 , 90

ich benutze auch 180 da ich aus optischen Gründen auf meinem Gartenhaus auch Module auf der Nordseite habe (und auch wissen will was das so in der Realität bringt)

Durch den Ansatz mit solar_plain von dir kann ich jetzt schon einen korrekten Wert ermitteln denke ich.
Ich habe schon länger Wechselrichter Daten, d.h. ich kann für Sommer und Wintersonnwende schauen ab wann der WR Leistung produziert und entsprechend mit dem Mindestsonnenstand abgleichen

[ch.eick]

ich benutze auch 180 da ich aus optischen Gründen auf meinem Gartenhaus auch Module auf der Nordseite habe (und auch wissen will was das so in der Realität bringt)

Ich meinte eher -73 , +47 , ... Es gibt ja doch mehr gedrehte Häuser, als die die eine echte Süd Ausrichtung haben.

[ch.eick]

Von Andi

hast du mal überlegt noch folgendes in die Config zu packen?
module_x_factor (Könnte Alterung, Wandlungsverluste, unterschiedliche Wirkungsgrade Modulgruppenspezifisch abfangen) Ich habe jetzt die Modulleistung entsprechend runtergerechnet. Schöner wäre halt ein extra Faktor

Das macht es aber auch beliebig komplex und es wird jetzt schon nur von den wenigsten verstanden.
Da es ja auch nur eine Näherung auf Stunden Basis ist und auch die rad1h Werte des DWD nicht so dolle sind wäre das schon ziemlich über dimensioniert.
Je nach Wohnort gibt es ja oft gar keine Wetterstation, die die rad1h Werte liefert und dann liegt man schon sehr daneben mit seiner Berechnung.

Viel schwieriger wird es da bei Wolken und Regen, was ich über eine "Heizungskurve" umgesetzt habe und das dann eher eine gefühlte Implementierung ist.

module_x_SunStartAltitude Sonnenhöhe zu der die Beschattung der Reihe endet (Morgensonne kommt verspätet auf die Module)
module_x_SunEndAltitude Sonnenhöhe zu der die Beschattung der Reihe anfängt (Abendsonne kommt nicht mehr auf die Module)

Die beiden letzten Parameter in Grad, denn dann kann man mit Astro sehr schön den Sonnenstand zu einer bestimmten Uhrzeit berechnen lassen.

Wenn dann sind beide Winkel zu berücksichtigen , also Altitude und Latitude um Sommer und Winter zu berücksichtigen.
Ich hatte mich einfach auf das Abfangen der Grenzwerte beschränkt, da ich schon etwas länger aus der Schule bin

ganz optional: module_x_ tempk  (Ich habe unterschiedliche Modultechnologien)

Liegen die denn wirklich soooo weit auseinander?
Wichtiger wäre ein temperatursensor an den Modulen, was bisher keiner hat.
Ich nehme da den Sensor aus meiner Wärmepumpe, die im Süden voll in der Sonne steht und addiere da noch einige Grad drauf.
Das mit der Temperatur hatten wir ja schon geändert, es ist jetzt die Prognose vom DWD +10° , aber dieser Stelle könnte man besser einen Sensor an den Modulen verwenden.

[andi11]

Komplex macht es im ersten Moment die Vermischung von Kostal, Vorhersage und Eigenverbrauchsoptimierung (zumindest gefühlt) ohne grobe graphische Skizze.

Die Verschmischung macht großteils Sinn. Der WIKI Artikel ist sehr gut nachvollziehbar, aber sehr lang. Evl könnte eine Auftrennung in Basis (Vorhersage mit SVG) + bessere Charts mit Grafana helfen, und Eigenverbrauchsoptimierung helfen?
Beim ersten anschauen des Artikels hab ich als es mit Kostal anfing nicht mehr weitergelesen und den Goldschatz übersehen.... Mit der Schwarmaufteilung hast du es super aufgezogen, irritierend ist aber dass der Chef im Ring der Kostal WR ist (ich weiß Kostal nennt den auch Master). Ich hab keinen solchen Master, daher scheint mir ein virtueller Master hier einfacher verständlich. "Wir definieren ein Device dass folgende Readings bereitstellen muss... Das kann innerhalb eines WRs sein oder in einem Dummy. Achtung wenn es in einem WR ist, wird es komplexer falls z.b. nach einem defekt der Kostal WR durch SMA ersetzt wird"

Ein Faktor auf Modulebene kann es hier vereinfachen. "Mein Modulstring Hans liefert immer zuviel Leistung, den rechne ich einfach runter z.b. weil da Tagsüber die Satschüssel mal im Weg ist) Modulstring Herbert betrifft das aber nicht." Selbst meine China Wechselrichter liefern Stringmomentan und Tageswerte über die Cloud App, damit kann man vergleichsweise gut skalieren.

Ich könnte den Temperatursensor von meinem Windmesser bieten. Der steht neben den Modulen auf dem Dach. Wie ich das verknüpfe habe ich aber noch nicht verstanden (und auch noch nicht genauer angeschaut)
Nein der Temperaturkoeffizient ist ähnlich, daher wäre der Wert auch optional.

Muss für die Früh/Abendverschattung der Sonnenstand groß mitverwendet werden? Vormittag gilt dieser Grenzwert, Nachmittag gilt der andere Grenzwert?

[ch.eick]

Komplex macht es im ersten Moment die Vermischung von Kostal, Vorhersage und Eigenverbrauchsoptimierung (zumindest gefühlt) ohne grobe graphische Skizze.

Tja, wie immer ist es mit den Ideen gewachsen.

Die Verschmischung macht großteils Sinn. Der WIKI Artikel ist sehr gut nachvollziehbar, aber sehr lang. Evl könnte eine Auftrennung in Basis (Vorhersage mit SVG) + bessere Charts mit Grafana helfen, und Eigenverbrauchsoptimierung helfen?

Das Wiki war meine Dokumentation und ich wollte nicht aufteilen, damit der Zusammenhang nicht verloren geht.

Beim ersten anschauen des Artikels hab ich als es mit Kostal anfing nicht mehr weitergelesen und den Goldschatz übersehen.... Mit der Schwarmaufteilung hast du es super aufgezogen, irritierend ist aber dass der Chef im Ring der Kostal WR ist (ich weiß Kostal nennt den auch Master). Ich hab keinen solchen Master, daher scheint mir ein virtueller Master hier einfacher verständlich. "Wir definieren ein Device dass folgende Readings bereitstellen muss... Das kann innerhalb eines WRs sein oder in einem Dummy.

Die Probleme hatte ich auch bemerkt und da schon begonnen die Device Namen in einen Namensstandard zu überführen.
WR_1 ist somit der Chef im Ring, egal was es für ein Wechselrichter ist. In einem anderen Thread wurde schon mal begonnen eine Standard bei den readings zwischen SMA und Kostal zu definieren, was aber letzt endlich nicht zu einem Ergebnis geführt hat. Kostal liefert viel mehr Informationen, die bei SMA namuell erst noch berechnet werden müssen

Umsetzbar wäre das dann wie Du geschrieben hast mit einem Dummy Device, was jedoch wieder eine menge an umkopieren von Daten bedeuten würde. Da selbst der RPI 4 bei mir bereits ziemlich gut gefüllt ist muss ich auf die zusätzlichen Events verzichten es stockt so auch schon mal, wenn zuviel HTTPMOD im Hintergrund läuft.

Achtung wenn es in einem WR ist, wird es komplexer falls z.b. nach einem defekt der Kostal WR durch SMA ersetzt wird"

Den Austauschfall am Master hatte ich erst gerade. Das habe ich bei den Zählern gemerkt, die ich gerne fortlaufend haben wollte Das hat dank Vorbereitung aber soweit geklappt.
Nur die Statistiken von Monat und Jahr muss man dann leider mit einem Offset um den vorherigen Zeitraum anheben, was mich jetzt bis anfang April und dann bis zum Jahreswechsel begleitet

Wenn es ein komplett anderer WR ist, dann muss man eh einiges neu aufsetzen.

Ein Faktor auf Modulebene kann es hier vereinfachen. "Mein Modulstring Hans liefert immer zuviel Leistung, den rechne ich einfach runter z.b. weil da Tagsüber die Satschüssel mal im Weg ist) Modulstring Herbert betrifft das aber nicht." Selbst meine China Wechselrichter liefern Stringmomentan und Tageswerte über die Cloud App, damit kann man vergleichsweise gut skalieren.

Hier fällt mir nur Schattenmanagement oder Leistungsoptimierer ein, das ist so speziel, das kann nicht in die Prognose rein.
Mein Schattenmanagement habe ich im PV_Schedule eingebaut und aktiviere es nur zu bestimmten Zeiten. Der Plenticoe kann das über die API.
Experimentell habe ich mal versucht eine Verdeckung von Schnee zu erkennen, da ist aber noch nichts gescheites bei raus gekommen und bisher war kein Schnee da

Ich könnte den Temperatursensor von meinem Windmesser bieten. Der steht neben den Modulen auf dem Dach. Wie ich das verknüpfe habe ich aber noch nicht verstanden (und auch noch nicht genauer angeschaut)

Das müsste man noch einbauen. Im Moment wird die Temperatur vom DWD +10 genommen, was ja auch mehr Sinn macht, da ich ja stundenweise Werte in der zukunft brauche.
Ob es jetzt 10° oder mehr sind, könnte man mal messen, aber auch das wird zwischen morgens, mittags und abends schwanken. Das wären dann wieder drei Offsets in der Konfig

Nein der Temperaturkoeffizient ist ähnlich, daher wäre der Wert auch optional.

Deshalb ist es auch nur einer

Muss für die Früh/Abendverschattung der Sonnenstand groß mitverwendet werden? Vormittag gilt dieser Grenzwert, Nachmittag gilt der andere Grenzwert?

Schau Dir bitte mal die Winkel und Faktoren von Solar_plain() im Log dazu an. Anhand des Rückgabe Wertes von 0.001 oder 0.5 kannst Du unterscheiden wann welcher Grenzwert gezogen hat.

[andi11]

Schau Dir bitte mal die Winkel und Faktoren von Solar_plain() im Log dazu an. Anhand des Rückgabe Wertes von 0.001 oder 0.5 kannst Du unterscheiden wann welcher Grenzwert gezogen hat.

Vielleicht war mein reading Name schlecht gewählt.
MindesthoeheMorgens und MindesthoeheAbends
Trennung Morgens <>Abends anhand "Vor oder nach 12Uhr" oder Winkel >180° im Astromodul, dann Abendswert.

den Wert ausschließlich anhand einer Mindesthoehe zu limiteren reicht denke ich z.b. in meinem Fall nicht aus. Früh hab ich Schatten, abends geht die Sonne einfach nur unter.

[ch.eick]

Von Andi

Du hast da echte Schätze in dem Artikel. Im Bereich der SVG Veränderung, webcmd Kennzeichnung und lauter kleine Details

Man gibt sich halt Mühe

steuerst du deine Wärmepumpe "nur" mit diesem DOIF und dem Shelly also ohne Sperrzeiten usw?

Achtung, ich habe eine Zyklische Wärmepumpe und noch keine oszilierende.
Nein, als erstes muss die Wärmepumpe bis zum letzten auf das Haus und die Bewohner optimiert werden!!!
Die WP läuft erstmal generell autark und macht was sie will
- Sperrzeiten habe ich für WW, damit es von sich aus immer in der PV Zeit liegt und nicht von 12:00 Uhr
- Eine Tagesanhebung um 4K  zwischen 10:00 und 16:00 Uhr bringt die WP ordentlich ans Heizen
- Die Nachtabsenkung von 8K in der Restzeit minimiert die Heizung und bedient sich aus dem Mehrfachpufferspeicher
Hier kommt jetzt FHEM
- von 18:30 bis 2:00 Uhr schalte ich mittlerweile die Heizung komplett über FHEM ab
- Zwischen 2:00 und ca 9:00 Uhr habe ich dann 2-3 Heizzyklen, wo die WP mal anspringt und den Puffer nachheizt

- Nach der Leistungsprognose wird dann auch mal der PV-Modus der WP aktiviert, was meist in der Überganszeit passiert.
  Das macht dann der Shelly, als potentialfreies Signal auf den SG-Ready Eingang der WP.

Den PV-Modus verwende ich zusätzlich, um bei Besuch und zum geplanten Putzen mal das WW auf 60° zu heizen.
Wir haben mittlerweile in der Küche eine Tradfri remote control, mit der wir die Zirkulationspumpe und den PV-Modus
aktivieren können, das ist end Geil

Mir gefällt das richtig gut dass die Vorhersage meldet wieviel die PV Anlage heute noch liefern wird.
Überlege in Richtung "Es ist Mittag, der COP der LWP ist hoch, hat der Speicher genug Platz für die Restenergie oder soll die Pumpe mal bissl mehr laufen"

Das macht ja mein DOIF, wobei der COP nicht so extrem wichtig ist. Um 14:00 Uhr wäre die höchste Außentemperatur, aber da kann es bei schlechtem Wetter
schon knapp mit der PV-Leistung werden. Deshalb bin ich auf 12:00 Uhr gegangen.

Beim Accu gilt immer, ein direkter Verbrauch ist besser als speichern.
Deshalb immer zuerst die WP aktivieren und den Hausspeicher (ACCU) nur die Reste einsammeln lassen.

[ch.eick]

Vielleicht war mein reading Name schlecht gewählt.
MindesthoeheMorgens und MindesthoeheAbends
Trennung Morgens <>Abends anhand "Vor oder nach 12Uhr" oder Winkel >180° im Astromodul, dann Abendswert.

den Wert ausschließlich anhand einer Mindesthoehe zu limiteren reicht denke ich z.b. in meinem Fall nicht aus. Früh hab ich Schatten, abends geht die Sonne einfach nur unter.

Die Funktion Solar_plan() ist eine reine Winkel Korrektur und sollte nichts mit Schattenmanagenet zu tun haben.
Die Korrektur des elevation Wertes dient nur dazu bei bestimmten berechneten Winkel die ungültigen Werte zu eliminieren.
Die Winkelberechnungen sind nur in einem definierten Bereich gültig.

Ab wann zündet denn Deine Anlage morgens? Das wäre dann der Winkel Bereich, der den ersten Faktor > 0.001 liefern sollte.
Du hast natürlich recht, man könnte auch die eingangs Winkel für die Winkelberechnung limitieren, jedoch fand ich es besser einfach den Müll wieder weg zu schmeißen.
Die Grundfunktion ist übrigens auch nicht von mir, sondern nur addaptiert.

[andi11]

Die Funktion Solar_plan() ist eine reine Winkel Korrektur und sollte nichts mit Schattenmanagenet zu tun haben.
Die Korrektur des elevation Wertes dient nur dazu bei bestimmten berechneten Winkel die ungültigen Werte zu eliminieren.
Die Winkelberechnungen sind nur in einem definierten Bereich gültig.

Macht Sinn

Ab wann zündet denn Deine Anlage morgens? Das wäre dann der Winkel Bereich, der den ersten Faktor > 0.001 liefern sollte.

Aktuell ab 8.30 die entsprechende Sonnenstandhöhe habe ich als mindestwert in solar_plain eingetragen. Diese Sonnenstandshöhe hat aber nichts mit der (in diesem Fall unnötigen erhöhten) Begrenzung abends zu tun. Hab nur auf einer Seite einen Berg neben unserem Haus

Der bessere Platz wäre hier wohl eine Erweiterung von Solar_forcast. Alternativ denkbar wäre eine Begrenzung durch Aufruf einer weiteren Funktion z.b. Solar_shadow() Hier könnten eigene Perl Begrenzungen implementiert werden. da als Parameter azimuth,elevtion,modulname usw übergeben werden.
Das Schattenthema wird wohl immer so Anwendungsspezifisch sein dass es kaum mit ein paar generischen Readings abzudecken werden)

[ch.eick]

Macht Sinn
Aktuell ab 8.30 die entsprechende Sonnenstandhöhe habe ich als mindestwert in solar_plain eingetragen. Diese Sonnenstandshöhe hat aber nichts mit der (in diesem Fall unnötigen erhöhten) Begrenzung abends zu tun. Hab nur auf einer Seite einen Berg neben unserem Haus

Okay, bei mir geht es um 7:00 los und endet um 18:00 Uhr, bei einer Aufteilung könnte auch ich morgens und abends genauer korrigieren.

Der bessere Platz wäre hier wohl eine Erweiterung von Solar_forcast. Alternativ denkbar wäre eine Begrenzung durch Aufruf einer weiteren Funktion z.b. Solar_shadow() Hier könnten eigene Perl Begrenzungen implementiert werden. da als Parameter azimuth,elevtion,modulname usw übergeben werden.
Das Schattenthema wird wohl immer so Anwendungsspezifisch sein dass es kaum mit ein paar generischen Readings abzudecken werden)

Für meinen Standort wäre vormittags

Code Auswählen Erweitern


get Astro text SunAz  "2022-03-09 12:00:00"
==> 168.8


Hier mal zum Testen mit der Aufteilung für Vormittag und Nachmittag. Den Elevation Grenzwert könnte man dann in das WR_1_config Device legen.

Code Auswählen Erweitern



    # avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)

    if ($azimuth < 180) {
      if ($elevation <= 0.1798) {
        if ($verbose >= 3) { Log 3, "Solar_plain factor           : ".$factor };
        return($factor)
      }
    } else {
      if ($elevation <= 0.1798) {
        if ($verbose >= 3) { Log 3, "Solar_plain factor           : ".$factor };
        return($factor)
      }
    };


Achtung, alle korrekten Werte würden einfach ohne Änderung durch die Abfrage weiter laufen, also nicht einfach den Code optimieren