Über PV-Anlage Einstrahlung auf Gebäudeteile ermitteln

Begonnen von KölnSolar, 27 Juni 2019, 12:42:50

Vorheriges Thema - Nächstes Thema

KölnSolar

Hallo zusammen,
ich hab nun endlich (scheinbar) eine Lösung gefunden, wie ich über meine PV-Anlage die Einstrahlung für die unterschiedlichen Gebäudeteile ermitteln kann, um dann daraus die Notwendigkeit von Verschattung zu steuern.

Ausgangssituation:
- Objekt bzw. PV-Anlagen: +27° Westausrichtung
- aufgeteilt in 2 PV-Teilanlagen mit jeweils 4,32 kWp.
  - Dach mit 30° Neigung u. ohne Verschattung(Grundvoraussetzung !) durch umliegende Gebäude, Bäume.....
  - Garage/Carport: 25° Neigung u. Teilverschattung durch das eigene Gebäude (hier irrelevant und nicht genutzt, taucht aber dann in den Grafiken auf)

Lösungskomponenten:
- Aufzeichnung von (Leistung, Spannung,) Tagesertrag der Fronius-Wechselrichter über RS422, RS422-USB, Rpi, eigenes FHEM-Modul
- Temperaturmessung Innenraum
- Temperaturmessung Solarmodul(unverschattet !)
- Temperaturkoeffizient des Solarmoduls Tmpp(bei mir -0,45%/°K; Basis 25°C)
- statistics-Modul für statistische Werte(alternativ eigene statistische Daten)
- customReadings-Modul mit berechneten Readings für die unterschiedlichen Gebäudeorientierungen(alternativ UserReadings im Basis-device)
- twilight-Modul zur Ermittlung von elevation(Höhenwinkel Sonne) u. azimuth(Richtungswinkel der Sonne in der Ebene)
- Funktion in 99_myUtils zur Berechnung von Einstrahlung auf die Ebene u. Einstrahlung auf die geneigte(ggfs. 90° für Fassade) Fläche

Für die Umrechnung der Einstrahlung für einen beliebige Ausrichtung u. Neigung habe ich mich einer Formel aus dem WWW bedient. Leider finde ich nach der langen Zeit nicht mehr den Link.  :'( :-[ Das ist insofern etwas blöd, da ich meine Ergebnisse nicht mehr prüfen kann und auch nicht mehr die Wertebereiche kenne, für die die Formel "ungültig" ist.

Nun zu den Details und ggfs. Beschreibung, was Ihr für Euch anpassen müsst:

Wechselrichter-device:
define Fronius .....
Durch das statistics-Modul werden die Readings statWert_WR1_18Hour und statWert_WR1_18HourLast(für die spätere Berechnung) zusätzlich angelegt.
Habt Ihr kein device für einen Wechselrichter, so sollte auch ein Zählerdevice funktionieren.

statistics:
define stat_wr statistics Fronius
attr stat_wr deltaReadings Wert_WR1_18
attr stat_wr singularReadings Fronius:Wert_WR1_18:Delta:Hour

(Wert_WR1_18=lfd. Tagesertrag[vom device in Wh], täglich bei 0 beginnend; ein Gesamtertragszähler sollte genauso funktionieren;

CustomReadings
define myReadings CustomReadings
attr myReadings interval 300
attr myReadings readingDefinitions Solar_PV:{Solar_power()},\
Solar_Eb:{ Solar_power() / Solar_plain(30,27)},\
Solar_Sl:{ Solar_power() / Solar_plain(30,27) * Solar_plain(90,27) },\
Solar_East:{ Solar_power() / Solar_plain(30,27) * Solar_plain(90,-63) },\
Solar_West:{ Solar_power() / Solar_plain(30,27) * Solar_plain(90,117) },\
Elevation:{ ReadingsVal('myTwilight','elevation','0')}

Obwohl ich (leider) ja nur den statistischen Ertragswert von jeweils der vollen vorhergehenden Stunde(anstatt gewünscht Viertelstunde;alternativ eigene Durchschnittsermittlung und Periode ohne statistics-Modul) habe, ermittle ich neue Werte mit einem Intervall von 5 Min., weil durch den aktualisierten Sonnenstand trotzdem interessante Werte errechnet werden.
Solar_Eb ist die Ermittlung der Einstrahlung auf die Ebene, ermittelt aus der über die PV-Anlage errechneten Einstrahlung und meinen Objektdaten: Neigung=30°, Azimuth=+27°West)
Solar_Sl die vergleichbare Berechnung für MEINE "Südfassade"(also nicht wirklich Süd, sondern Süd+27°)
Solar_East(Ost+27°=-63°), -West(West+27°=117°) für MEINE Ost-,Westfassade
Elevation: für einen späteren Vergleich von Werten in Grafiken logge ich den Höhenwinkel der Sonne mit

Nun die Funktionen in 99_myUtils:
sub Solar_power() {

   my $tempk     =-0.45;
   my $temp      = ReadingsVal('RPi_OW_TC1','temperature','0');
#  radiation: correction by modul temperature, minus 10% indirect radiation
   my $power = ReadingsVal('Fronius','statWert_WR1_18HourLast','0') / 4.32 / 4.17 / 1.6533 / 0.147 / (1 + ($temp - 25) * $tempk / 100);

return ($power);

};
(alternativ $power mit eigener Durchschnittsermittlung ersetzen und ggfs. den Faktor(hier 6) ergänzen, z.B. Wert_WR1_18_int für 10min-Werte;das statistics-device wird dann natürlich nicht benötigt)   my $power = ReadingsVal('Fronius','Wert_WR1_18_int','0') * 6 / 4.32 / 4.17 / 1.6533 / 0.147 /  (1 + ($temp - 25) * $tempk / 100) ;
Es wird die normierte Leistung Wp mit Korrektur über die Solarmodultemperatur berechnet.
Den Temperaturkoeffizienten $tempk müsst Ihr Eurem Moduldatenblatt entnehmen, $temp mit Eurem Reading der Modultemperatur ersetzen  und die 4.32 durch Eure nominelle Anlagenleistung. 4,17 ist meine Modulanzahl je kWp, 1,6533 die Fläche je Modul und 0,147 mein Modulwirkungsgrad.

###########################################################
# Subroutine to calculate radiation
###########################################################
sub Solar_plain($$) {

        my $angle     = $_[0];
        my $orienta   = $_[1];
my $azimuth   = ReadingsVal('myTwilight','azimuth','0');

# angles in radiant
my $rad       = 57.296;
my $elevation = ReadingsVal('myTwilight','elevation','0') / $rad;
$angle        = $angle / $rad;
my $orientation = ($azimuth - 180 - $orienta) / $rad;

#  avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
        return (0.001) if ($elevation <= 0); 

        if(cos($orientation) < 0.05 && cos($orientation) > -0.2) {$orientation =$orientation - 0.2}

#    Log3 "", 1, "Solar radiation, azimuth = $azimuth, orientation=$orientation, elevation=$elevation, angle=$angle";
     my $factor = sin($angle) /
         (sin( $elevation) / 
          cos( $elevation)) * 
cos($orientation) +
cos($angle);

# otherwise too big values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
    if ($factor > - 0.05 && $factor < 0.05) {$factor = 0.05}

    return ($factor);
};

Diese Funktion könnt Ihr 1:1 übernehmen. Es gibt keine individuellen Parameter außer denen, die mit dem Funktionsaufruf mitgegeben werden:
Neigung, Ausrichtung von PV-Anlage oder Gebäudeteil
Über das twilight-Modul werden jeweils azimuth und elevation des eigenen Standorts(latitude,longitude) ermittelt.
Für den Formelinteressierten: Stellenweise sind Korrekturen enthalten, um auch außerhalb der eigentlich gültigen Wertebereiche Daten zu berechnen, aber die falschen Peaks zu eliminieren.

Das Ganze sieht dann in Grafiken so aus: Grafik1 zeigt den Ertrag meiner beiden Wechselrichter und deren Gleichspannung.
(Schön zu sehen, dass die Garagenteilanlage morgens durch das eigene Gebäude verschattet ist und bei deren Verwendung unrealistische Werte liefern würde)
Grafik2 zeigt für den selben Tag die für die Anlage normierte und korrigierte(Temperatur) Leistung und die Einstrahlung auf die verschiedenen Gebäudeteile(Fassaden). Die Elevation ist (neben der Uhrzeit) geeignet, um die Daten über den Tag zu interpretieren bzw. evtl. Abhängigkeiten für smarte Steuerungen zu erkennen und definieren.

Schließlich nutze ich die Daten dann beispielsweise für eine einfache Verschattungsfunktion(Rolläden mit ROLLO-Modul) in Abhängigkeit der Innentemperatur(>22°):
define act_on_SonneOston notify myReadings.Solar_East.* { if ("$EVTPART1" > 200 && ReadingsVal("myReadings","Elevation",0) > 18 && ReadingsVal("Rolladenfenster","pct",0) == 0 && ReadingsVal("KlimaWohnen","temperature",0) > 22) { fhem('set Rolladenfenster half')} }
Der set-Befehl kann natürlich je nach Aktor bei jedem anders aussehen. Bei mir funktioniert z.B. kein on-for-timer.
Und das Gegenstück, wenn die Sonne am frühen Nachmittag nicht mehr auf MEINE Ostfassade scheint.
define act_on_SonneOstoff notify myReadings.Solar_East.* { if ("$EVTPART1" < 100 && "$EVTPART1" > 0 && ReadingsVal("myReadings","Elevation",0) > 18 && ReadingsVal("Rolladenfenster","pct",50) >= 50 && ReadingsVal("KlimaWohnen","temperature",0) > 22) { fhem('set Rolladenfenster open')} }
Die Werte 100 bzw. 200[W/m²] bzw 18[°]sind Erfahrungswerte, die ich über die Grafiken ermittelt habe. Bisher passt das ganz gut, ist aber sicherlich über die Zeit(Jahreszeitabhängiger Sonnenstand) noch zu optimieren.

Ich hoffe, jemand kanns gebrauchen (und es funktioniert  :D).

Kommentare/Verbesserungsvorschläge sind willkommen, aber bitte hier keine Diskussion über direkte/indirekte Strahlung ..... führen. Wesentlich ist, dass man näherungsweise halbwegs realistische Einstrahlungswerte ermittelt, wobei sie um den wesentlichsten Einflussfaktor Modultemperatur korrigiert sind.

Grüße Markus

Edit: Grafiken hinzugefügt; Solarluft entspricht MEINER Südfassade

Edit2: Gute Website, um sich den Sonnverlauf zu unterschiedlichsten Uhr- und Jahreszeiten zum individuellen Standort anzusehen.

Edit3: Nun die Variante mit einem selbsterzeugten Durchschnitt des Ertrags über eine Periode von 10'
         Dazu bediene ich mich des laufenden Ertragszählers define at_Froniusint at +*00:10:00 {my $kum = ReadingsVal("Fronius","Wert_WR1_18",0);; \
my $int = $kum - ReadingsVal("Fronius","Wert_WR1_18_intLast",0);; \
$int = 0 if ($int < 0);;\
fhem("setreading Fronius Wert_WR1_18_intLast $kum;;\
setreading Fronius Wert_WR1_18_int $int");; }

         Wie Ihr seht, werden die Grafiken dadurch "eindeutiger" und die Verschattungsfunktion funktioniert sinnvoller.
         Man erkennt die markanten Punkte nun viel deutlicher. Und am Nachmittag kamen Wolken auf, was ein guter Test für Rolladen runter, Rolladen hoch, Ralladen runter  war.
         Die notifys habe ich den neuen Erfahrungen angepasst.
         Wie bereits erwähnt, ist die Formel nur in einem Wertebereich gültig(bei mir funktioniert es von -90°Ost/90°West und leicht eingeschränkt bis Sonnenuntergang)
         Derzeit geht die Sonne aber viel nördlicher auf(ca. -130°Ost). Um nun trotzdem die Rolläden in Nichtaufenthaltsräumen vom nächtlichen Lüften rechtzeitig zu schließen, nutze ich dafür die elevation:define act_on_SonneOstonSz notify myReadings.Elevation.* { if ("$EVTPART1" > 7 && ReadingsVal("RolladenTuerSz","state","off") ne "off" && ReadingsVal("KlimaSchlafzimmer","temperature",0) > 22) { fhem('set RolladenfensterSz,RolladentuerSz closed')} }         

Edit: Formel Solar_power korrigiert bzw. um Anz. Module je kWp, Fläche/Modul und Wirkungsgrad erweitert
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

Moin,
Und schon wieder warst Du schneller.
Den Gedanken habe ich auch, es fehlt nur die PV-Anlage. Die ist bestellt.

Gruß Christian

Gesendet von meinem SM-G930F mit Tapatalk

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

<OT u. Spaß on> Und wieso nicht bei uns bestellt ?  ;D <OT off>
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

Tja, muss man halt wissen.
Ich hab nen lokalen gewählt...

Gesendet von meinem SM-G930F mit Tapatalk

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

So, ich hab das Ganze nun verfeinert, indem ich mir statistische Werte über eine Periode von jeweils 10min ermittle. Formeln etc. habe ich im 1. Post ergänzt und die nun viel aufschlussreicheren Grafiken attached.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

Hallo Markus,

ich habe mich noch an diesen Thread erinnert :-)
Meine Assiziation ist nun, das man den Ertrag fuer den naechsten tag doch irgendwie ermitteln koennen muss. Zumindest stelle ich mir ein Signal vor, dass ein guter oder ein schlechter Tag kommt.
Auf den Wetter Seiten sind ja immer weiche Aussagen, die sich alle gegenseitig beeinflussen und da kann man nicht so gut mit schalten ;-)

Auf dieser Seite habe ich interessante Formeln gefunden. Fuer Inhalte des Links uebernehme ich natuerlich keine Gewaehrleistung und alles was man sonst noch Abstreiten muss...
https://desktop.arcgis.com/de/arcmap/10.3/tools/spatial-analyst-toolbox/how-solar-radiation-is-calculated.htm

Im iobroker Bereich habe ich auch java code gefunden, in dem obige Formeln wohl auch Anwendung finden, womit die Spur heiss ist. Leider ist das etwas zu komplex fuer mich, da ich aus dem Studium bereits etwas laenger raus bin.

Hier habe ich meinen Hilferuf fuer den PV Forcast abgesetzt
https://forum.fhem.de/index.php/topic,108191.msg1021853.html#msg1021853

Teile Deiner Berechnungen sind fuer den Forecast sicher auch von nutzen. Ich bringe nur leider die ganzen Winkel mit der Ausrichtung (bei mir drei Seiten) nicht in eine Formel zusammen, aus der die Leistung der Module herauskommt.
Wenn das dann mit dem zuerwartendem Wetter, zu einer bestimmten Zeit in Verbindung gebracht wird, dann koennte man die errechnete Maximalleistung durch Sonnenstunden und Bewoelkung entsprechend kleiner rechnen.

Ueber Deine Meinung und eventuelles Interesse wuerde ich mich freuen.

Viele Gruesse
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

#6
Hallo Markus,

mich läst die Prognose für den nächsten Tag noch nicht los und da habe ich mich Deiner Vorarbeit etwas bedient.

Mein Ansatz ist Deine Funktion für "Solar_plain()", womit ich die Winkel und den Sonnenstand isns Spiel bringe.
Zum Testen verwende ich dann noch eine Wetterstation in meiner Nähe, die die Solar Strahlung liefert.
Dann habe ich noch die Module pro Ausrichtung mit der Anzahl, dem Quadratmetern und der Nennleistung mit rein gerechnet.
Nun wird es natürlich ungenau, denn ich werfe die Werte, die negativ sind weg. Das ist jetzt am Abend der Osten.
Den rest summiere ich dann auf. Wenn ich das dann mit der momentanen Leistung vergleiche bekomme ich noch einen faktor von 0,5 rein.

Das ganze logge ich dann mal morgen und schau mir mal den Verlauf mit der aktuellen PV Gesamtleistung an :-)


Solar_East:Total_DC_Power.* { my $x = 13 * 1.5 * 0.310 * ReadingsVal("wetter_II","solarRadiation",0) * Solar_plain(40,-90);; ($x lt 0)?0:round($x,2) },
Solar_South:Total_DC_Power.* { my $x = 6 * 1.5 * 0.310 * ReadingsVal("wetter_II","solarRadiation",0) * Solar_plain(40,0);; ($x lt 0)?0:round($x,2) },
Solar_West:Total_DC_Power.* { my $x = 13 * 1.5 * 0.310 * ReadingsVal("wetter_II","solarRadiation",0) * Solar_plain(40,+90);; ($x lt 0)?0:round($x,2) },

Solar_Sum:Total_DC_Power.* { round( ( ReadingsVal($NAME,"Solar_East",0) + ReadingsVal($NAME,"Solar_South",0) + ReadingsVal($NAME,"Solar_West",0) ) * 0.5 ,2) }


Später möchte ich dann die Solarstrahlung auf dem Wetterbericht in Verbindung mit der Bewölkung einsetzen....na das wird was werden ;-)

Viele Grüße
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

Hallo Christian,

Du gibst nicht auf.  ;D

Zitatdem Quadratmetern und der Nennleistung

Das ist ja doppelt gemoppelt: Die Nennleistung ist ja nicht je m², sondern je Modul(also implizit die m² bereits berücksichtigt).

Da bin ich dann morgen Abend mal gespannt.

Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#8
Und ich erst mal.
Zumindest erklärt sich mein Faktor, weil doppelt gemoppelt :-)

Muss ich Leistungsoptimierer berücksichtigen? Es sind je drei Module vom Süden im Loop von Ost und West.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

#9
ZitatMuss ich Leistungsoptimierer berücksichtigen? Es sind je drei Module vom Süden im Loop von Ost und West.
Nein. Die sind ja nicht "leistungssteigernd", sondern nur "Verluste verringernd", die durch die in Reihe Schaltung von Modulen verschiedener Ausrichtung ansonsten auftreten würden.

Edit: Berücksichtigen müsstest Du noch die Verluste in Abhängigkeit von Modultemperatur/Temperaturkoeffizient. Das steckt bei mir in der Funktion solar_power.my $power = ReadingsVal('Fronius','statWert_WR1_18HourLast','0') / 4.32 / (1 + ($temp - 25) * $tempk / 100);
Müsste in Deinem Fall also so lauten{ my $x = 13 * 0.310 * (1 + ($temp - 25) * $tempk / 100) * ReadingsVal("wetter_II","solarRadiation",0) * Solar_plain(40,-90);; ($x lt 0)?0:round($x,2) },
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#10
Das wollte ich morgen noch einbauen. Du rechnest ja in die andere Richtung um die Solarstrahlung abzuschätzen.
Leider habe ich nur die Außentemperatur in der LWP, dafür aber in der Südsonne. Die muss erst mal reichen :-)

Gesendet von meinem SM-G930F mit Tapatalk
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

Unterschätz den Faktor nicht. Im Augenblick genügt sowas wie Außentemperatur bis 200W/kWp u. über 200W/kWp Aussentemperatur + 10°. Im Sommer sind das aber gerne mal 30°-40° Unterschied.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

Das heißt ich müsste unter den Modulen im Süden die Temperatur messen. Da schau ich mal wie ich das hin bekomme.
Die Module haben ca 18 cm Luft bis zu den Pfannen damit sich die Hitze nicht so staut.

Gesendet von meinem SM-G930F mit Tapatalk

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

Du müsstest sogar alle 3 Flächen messen, denn morgens oder abends wird sicherlich die West- bzw. Ostfläche deutlich verschattet und daher viel kälter als die bestrahlten Flächen sein.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#14
Beim Forecast kann ich natürlich nicht für morgen messen. Da müsste ich dann Glaskugel lesen und Erfahrungswerte bestimmen.
Ich lass jetzt gerade meine Berechnung mit den ermittelten Werten mal über den Tag laufen und in einem Diagramm darstellen.

EDIT:
Das erste Diagramm sieht schon recht gut aus :-)

Hier ist meine Berechnung im userreading des Wechselrichters

Solar_SolarRadiation:Total_DC_Power.* { ReadingsVal("wetter_wolfskehlen_II","solarRadiation",0) },

Solar_Correction_Temp:Total_DC_Power.* { my $tempk = -0.39 ;; my $temp = ReadingsVal("Heizung","heatSourceIN",0)+10;; my $x =  round((1 + ( $temp - 25) * $tempk / 100),3) },

Solar_East:Total_DC_Power.* { my $x = 13 * 0.310 * ReadingsVal("$NAME","Solar_SolarRadiation",0) * ReadingsVal("$NAME","Solar_Correction_Temp",0) * ReadingsVal("$NAME","Solar_Correction_Factor",0) * Solar_plain(40,-90);; ($x lt 0)?0:round($x,2) },

Solar_South:Total_DC_Power.* { my $x = 6 * 0.310 * ReadingsVal("$NAME","Solar_SolarRadiation",0) * ReadingsVal("$NAME","Solar_Correction_Temp",0) * ReadingsVal("$NAME","Solar_Correction_Factor",0) * Solar_plain(40,0);; ($x lt 0)?0:round($x,2) },

Solar_West:Total_DC_Power.* { my $x = 13 * 0.310 * ReadingsVal("$NAME","Solar_SolarRadiation",0) * ReadingsVal("$NAME","Solar_Correction_Temp",0) * ReadingsVal("$NAME","Solar_Correction_Factor",0) * Solar_plain(40,+90);; ($x lt 0)?0:round($x,2) },

Solar_Calculation:Total_DC_Power.* { round( ( ReadingsVal($NAME,"Solar_East",0) + ReadingsVal($NAME,"Solar_South",0) + ReadingsVal($NAME,"Solar_West",0) ) ,2) }


Werte für die Berechnung (hier als Momentanwerte)

Solar_Correction_Factor 1.5     <<<< Dieser Faktor ist eine manuelle Korrektur
Solar_Correction_Temp 1.028    <<<< Das ist ein ergebnis aus der Temperatur Korrektur
Solar_SolarRadiation 290.20    <<<< Das ist ein Wert, der von einer benachbarten Wetterstation, gemessen wurde


@Markus: Soll ich mit meinem Kram besser Umziehen, oder denken wir zusammen darüber nach?

Viele Grüße
     Christian


Zur Orientierung:
grau - Sonnenhöhe
gelb - SolarRadiation

Berechnete Einzelwerte:
blau - Ost
rosa - Süd
braun - West

schwarz - Calculation ist die zu erwartende Leistung
grün     - DC_Sum ist die tatsächliche Leistung von Loop 1 und 2 am WR
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

Jo, die Tendenz sieht gut aus.

Zitat@Markus: Soll ich mit meinem Kram besser Umziehen, oder denken wir zusammen darüber nach?
Ist doch auf Grundlage derselben Formel. Können wir ruhig hier weitermachen.
ZitatBeim Forecast kann ich natürlich nicht für morgen messen. Da müsste ich dann Glaskugel lesen und Erfahrungswerte bestimmen.
Klar. Dann musst Du Dir Annahmen über die Temperatur über die Globalstrahlung UND die Ausrichtung bilden.
Ich bleib ja dabei, dass das in der Prognose zu ungenau für eine "schalttechnische" Verwertbarkeit sein wird. Interessieren tun mich Soll-Ist-Vergleiche als Grafik dann aber schon. ;)

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

Die sollst Du haben[emoji39]

Ich spionier noch bei iobroker.pleticore, da sind sie bereits weiter. Ich brauch ja nur einen Triggerwert um zu wissen ab welcher  Leistung danach noch ein Hügel über 70% kommt.
Dann nutze ich ab da Leistung über der Einspeisegrenze und schalte den Pool zum Heizen und die LWP im PV-Modus für WW ein.
Das sind dann 1KW über 4h und 3 KW über 1-2h .
Vor den 70% wird dann alles eingespeist und darüber weniger abgeschnitten.
Mehr kann ich nicht tun.

Gesendet von meinem SM-G930F mit Tapatalk

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

ZitatIch brauch ja nur einen Triggerwert um zu wissen ab welcher  Leistung danach noch ein Hügel über 70% kommt.
Den gibt's ja nicht. Maximal ein Krümelchen und das per Forecast zu prognostizieren.....

Was hattest Du denn bisher an Max.Leistung(in %) ? Bei mir waren es heute 87%. ABER: Auch nur, weil die Sonne wechselnd war. Das lässt sich per Prognose nun mal gar nicht vorhersagen und bleibt die Sonne dauerhaft, steigt die Modultemperatur und die Verluste.
Bei Deiner Ost-West-Südanlage würde ich erwarten, dass Du so gut wie nie die 70% erreichst.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#18
Zitat von: KölnSolar am 03 März 2020, 18:17:21
Den gibt's ja nicht. Maximal ein Krümelchen und das per Forecast zu prognostizieren.....

Was hattest Du denn bisher an Max.Leistung(in %) ? Bei mir waren es heute 87%. ABER: Auch nur, weil die Sonne wechselnd war. Das lässt sich per Prognose nun mal gar nicht vorhersagen und bleibt die Sonne dauerhaft, steigt die Modultemperatur und die Verluste.
Bei Deiner Ost-West-Südanlage würde ich erwarten, dass Du so gut wie nie die 70% erreichst.
Ich habe ja noch keinen Sommer erlebt und bereite mich halt gerne etwas vor :-)
Heute war ich von 10:00-11:30 Uhr bei gut 5000 W , der absolute peak lag bei 6700 W .
Ich finde das ist schon recht nah an den 70% und das bei dieser proplanta Bewölkung:
  fc06 100
  fc09  37,5
  fc12  37,5

Ich habe gerade begonnen die Bewölkung mit in die Schätzung zu nehmen, das Ergebniss wollte ich dann morgen mit "set <name> addCacheLine YYYY-MM-DD HH:MM:SS"
für den nächsten Tag mit in die Datenbank schreiben. Dann habe ich am Folgetag meine Prognose mit im passenden Diagramm.
Oder ich ergänze das noch mit einer Prognose vom selben Tag bevor die Sonne aufgeht, dann sollte die Schätzung besser sein.
Wer nicht wagt, der nicht gewinnt, ansonsten habe ich wenigstens etwas gelernt.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

#19
ZitatIch habe ja noch keinen Sommer erlebt und bereite mich halt gerne etwas vor :-)
Du begehst immer noch den Fehler zu glauben, dass der peak im Sommer wegen besserem Einstrahlungswinkel höher wäre. Dem ist nicht so.  :'( Den peak erreichst Du eher jetzt als im Sommer, wenn die Module noch schön gekühlt werden, das Wetter wechselhaft ist. Im Sommer gibt es dann lediglich bessere Erträge, weil der Tag einfach länger ist, nicht aber, weil die Leistung steigen würde.

Ich hab Dir mal einen der "echten" Sonnentage herausgesucht. 29.7.: peak bei mir 78% bei 53° Modultemp. u. 24,5° Aussentemp. Du siehst an dem Bsp.: 9 Prozentpunkte schlechter im Peak als heute.

Und was Du auch noch unterschätzt: "Gefühlt" haben wir 50-100 Sonnentage im Jahr, also wolkenfreien Himmel. Tatsächlich sind es aber vielleicht nur 10 oder 20. Der Rest ist schönes Wetter, aber immer mal wieder mit Wolken. Dein Gefühl kannst Du mal mit den attachten Fakten vergleichen. Im vergangenen Monat gab es nur genau einen "echten" Sonnentag am 7.2. Du erkennst das an der dünnen gelben Kurve. Und was fällt auf ? Da war der peak im Verhältnis sehr niedrig.  :'(
(Edit: wobei ich glaube, dass der Tag zwar wolkenlos, aber diesig war, sonst hätte der peak nicht sooo niedrig ausfallen dürfen)

Edit2: Wesentlich ist daher nicht ein detaillierter Forecast bzgl. 70%. Du solltest Deine Energie vielleicht mehr in die Nutzung der tatsächlich anfallenden Energie im Hinblick auf den Mehrtagesforecast investieren, denn dann kannst Du Deine 3 Energiespeicher(Batterie, Pool, Pufferspeicher(?)), so über Solarstrom "befüllen", dass Du möglichst keine Energie zukaufen musst und trotzdem den wohltemperierten Pool und Dusche hast u. nachts nicht mit Strom geizen musst. Detailliert: wenn in absehbarer Zeit mit wenig Erträgen zu rechnen ist, darf der Pool auch mal auf 2-3° höher aufgeheizt werden, solange die Sonne scheint.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#20
Hmm, da habe ich noch viel zu lernen.
Mehrtages Forcast mach ich eh nicht, maximal der nächste Tag. Ob ich über 70% komme wird sich ja bald zeigen. Ich kenne ja meine Anlage noch nicht.
Und an der Leistungskurve entlang Tasten passt schon echt super bei mir.
Ich versuche halt immer einmal mehr wie Du[emoji1787][emoji39].
Ich hatte es ja eh so gedacht von morgens bis abends Leistung zu haben und nicht alles am Mittag.
Vielleicht kann ich ja noch nachjustieren.
Verändert sich die Loopspannung noch sehr stark nach oben im Sommer? Laut Papiere regelt der WR bei 700V ab, momentan habe ich so um 500V maximal. Da würde ja dann noch ein Modul pro Loop im Süden Luft sein.
Der Solarteur wollte sich da nicht rann rechnen. 

Danke, dass ich an Deinem Wissen teilhaben darf.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

ZitatIch hatte es ja eh so gedacht von morgens bis abends Leistung
Das wirst Du haben mit Ost-Süd-West-Anlage.
ZitatVerändert sich die Loopspannung noch sehr stark nach oben im Sommer?
Du meinst die Stringspannung. Ganz im Gegenteil. Die sinkt mit steigender Temperatur. deshalb werden die Spannungen der Stränge bzgl. der Leerlaufspannung bei -10°(in der Regel) ausgelegt.
ZitatDer Solarteur wollte sich da nicht rann rechnen. 
:o Dann hat der keine Ahnung wie sich die Spannungen/Ströme in Abhängigkeit der Temperatur verhalten. Eher Dachdecker als Solarteur.  ::) ;D Zu deren Glück gibt es ja die Auslegungsprogramme der Wechselrichterhersteller, die einem sagen, wie viele Module der Wechselrichter in einem Strang "verkraftet".
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#22
Zitat von: KölnSolar am 03 März 2020, 20:56:13
Die Stringspannung sinkt mit steigender Temperatur. deshalb werden die Spannungen der Stränge bzgl. der Leerlaufspannung bei -10°(in der Regel) ausgelegt. :o
Zum Glück gibt es ja die Auslegungsprogramme der Wechselrichterhersteller, die einem sagen, wie viele Module der Wechselrichter in einem Strang "verkraftet".

Ich habe dann mal die Spannung ausgewertet und erkenne, dass das Spannungslimit bereits erreicht worden ist.

MySQL [fhem]> select TIMESTAMP,DEVICE,READING,cast(VALUE AS DECIMAL) AS VOLTAGE from history where DEVICE = 'PV_Anlage_1' and READING like 'Voltage_DC%' order by VOLTAGE desc,TIMESTAMP limit 2;
+---------------------+-------------+-------------+---------+
| TIMESTAMP           | DEVICE      | READING     | VOLTAGE |
+---------------------+-------------+-------------+---------+
| 2020-02-28 08:23:55 | PV_Anlage_1 | Voltage_DC1 |     718 |
| 2020-02-06 09:17:19 | PV_Anlage_1 | Voltage_DC2 |     714 |
+---------------------+-------------+-------------+---------+

Unter Berücksichtigung des von Dir gelernten wird die Spannung im Sommer, durch die Temperatur der Module, noch sinken. Somit gehe ich jedoch jetzt schon davon aus,
dass die zwei Strings bereits voll bestückt sind.

Wie wäre denn die Sinnhaftigkeit einer Parallelschaltung? Die Spannung sinkt und der Strom steigt.
Mit dieser Variante könnte ich 4 Module mehr auf's Dach bekommen :-)
Ich habe 13 Module mit jeweils 3 Modulen im Süden mit Leistungsoptimierern verschaltet.
Wenn ich nun auf 14 mit 2x7 parallel im Osten und 4 mit 2x2 im Süden umbaue, dann würde ich pro String 2 Module mehr haben und die Spann unter 700 Volt halten.
Das ergibt dann 18x 310 Kwp = 5580 KWp in Ost/Süd und das gleiche nochmal in West/Süd Richtung.
Unter der Berücksichtigung der Wahrscheinlichkeit dürfte der Plenticore 10 Plus nicht überlastet werden.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Mit meinem Forecast komme ich leider nicht so gut weiter.
Bei proplanta habe ich nur eine Summer der Globalstrahlung für den ganzen Tag und ich habe noch keinen Weg das in zB 3 Stunden Blöcke entsprechend der Wolkenprognose aufzuteilen. Leider findet man nicht die zugrundeliegenden Modelle und Formeln. Ich beschränke mich dann lieber jetzt mit Auswertungen :-)
Zumindest bis die nächste Idee durch den kopf schießt...

Die Kalkulation mit der SolarRadiation, Deiner Temperaturkorrektur und der Dachausrichtung folgt schon recht gut der tatsächlichen Leistung. Bei sehr starken
Schwankungen durch Wolken kommt es jedoch auch zu starken Abweichungen, das ist halt die Diskrepanz von Natur und mathematischen Modellen. Meine
Kenntniss mit Formeln sind doch schon sehr stark eingerostet. Mir wäre eine formel mit nicht so starken Schwankungen und somit einem gleichmäßigerem Verlauf
für die Vorschau lieber.
Ich stelle später nochmal ein Diagramm rein, da sieht man es recht gut.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

ZitatUnter der Berücksichtigung der Wahrscheinlichkeit dürfte der Plenticore 10 Plus nicht überlastet werden.
Überlastung kennen die Dinger quasi nicht. Nur der max. erlaubte Strom darf nicht überschritten werden !
ZitatWenn ich nun auf 14 mit 2x7 parallel im Osten und 4 mit 2x2 im Süden umbaue, dann würde ich pro String 2 Module mehr haben und die Spann unter 700 Volt halten.
Du meinst anstatt 13+3, 2*(7+2) ?
Wo hast Du die 700V her ? Im Datenblatt steht, dass er 720V Mpp kann.
Aber wirf mal einen Blick auf die Wirkungsgradgrafiken. Ideal wären also 12-13 Module(570V). Verstehe gerade nicht, warum nicht 3 Strings gemacht wurden. Der Wr hat doch 3 MPP-Tracker.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#25
Am dritten String ist der Speicher.
Die Spannung ist der max Wert seit Beginn der Aufzeichnungen.
Genau 2x7 und 2x2 jeweils parallel und dann in Reihe. Das ganze dann pro String, also einmal Ost und einmal West.
Ups ich hab die Piraten vergessen. Es wären 2x8 mit 2x2 also 20 Module pro String.
Wie wird denn die parallel Schaltung gemacht? Einfach die Adern zusammen rödeln?
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

ZitatWie wird denn die parallel Schaltung gemacht? Einfach die Adern zusammen rödeln?
Nananana. Ein Y-Stecker sollte es schon sein.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#27
Was es nicht alles gibt [emoji6] Y-Stecker...
Kann mir der Solarteur das im Kostal Tool durchrechnen?
Oder ist das auch wieder Sinnfrei?
Im Winter kann ich schon noch mehr Leistung brauchen.

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

ZitatIm Winter kann ich schon noch mehr Leistung brauchen.
Leistung oder Arbeit ?  ;)
ZitatKann mir der Solarteur das im Kostal Tool durchrechnen?
Klar. Ich würd es mir aber selber besorgen u. durchrechnen.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

Ich hatte ja noch ein Bildchen versprochen, auch wenn es momentan nicht weiter geht.
Die Kalkulation sieht für den Winter recht nett aus, nur fehlen mir halt Vorhersagewerte, die ich in die Berechnung einsetzen kann.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Gisbert

Hallo Markus,

vom Prinzip her habe ich was vergleichbares vor, nur dass ich keine PV-Anlage einsetze, die ich nicht habe, sondern einen BH1750 - einen digitalen Lichtsensor, der an einem ESP8266 hängt.
Vielleicht hast Du das folgende Problem schon längst gelöst, aber für mich stellt es sich noch als solches heraus.

Mein Sensor ist fix ausgerichtet in etwa in die Richtung, die ich gerne verschatten möchte. Die Lichtintensität über den Tagesverlauf ist morgens klein, mittags am höchsten und abends wieder klein, sieht in etwa wie eine Gaussverteliung aus. Mit einem fixen Wert, bei dem verschattet werden soll, komme ich wohl kaum weiter. Er müsste zumindest von der Tageszeit abhängen, vermutlich aber auch noch noch vom Datum, also dem Tag im Jahresverlauf.

Hast du dafür eine Lösung?
Die Erklärung und die Lösung gerne ich kleinen Häppchen und schön vorgekaut ;D

Viele Grüße Gisbert

PS: Schreiben ist weniger anstrengend als machen, der Drucksensor für den Heizkreislauf steht noch auf der Warteliste.
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

ch.eick

Hallo Gisbert,
Schau Dir mal ASC an. Das kann denke ich alles was Du vor hast.
Brightness mit Schwellwerten,  Temperatur, Astro Position und Position des Rollos.

Gesendet von meinem SM-G930F mit Tapatalk

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Gisbert

#32
Zitat von: ch.eick am 05 März 2020, 21:51:54
Hallo Gisbert,
Schau Dir mal ASC an. Das kann denke ich alles was Du vor hast.
Brightness mit Schwellwerten,  Temperatur, Astro Position und Position des Rollos.

ASC = AutoShuttersControl, nehme ich an.
Das ist ja ein gewaltiges Modul, geht es irgendwie auch 3 Nummern kleiner?
Ich bin mir nicht sicher, ob ich mir dieses Modul nur wegen der Tageszeit-abhängigen Helligkeitskurve antun möchte.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

KölnSolar

#33
Hi Gisbert,
den Gauss gibt es aber nur bei Sonnenschein, oder ?  ;D

Das ist ja meine Funktion aus dem 1.Post(muss ich noch auf meine ROLLO-devices umstellen)
ZitatSchließlich nutze ich die Daten dann beispielsweise für eine einfache Verschattungsfunktion in Abhängigkeit der Innentemperatur(>22°):
Code: [Auswählen]
define act_on_SonneOston notify myReadings.Solar_East.* { if ("$EVTPART1" > 200 && ReadingsVal("myReadings","Elevation",0) > 18 && ReadingsVal("Rolladenfenster","pct",0) == 0 && ReadingsVal("KlimaWohnen","temperature",0) > 22) { fhem('set Rolladenfenster half')} }
Der set-Befehl kann natürlich je nach Aktor bei jedem anders aussehen. Bei mir funktioniert z.B. kein on-for-timer.
Und das Gegenstück, wenn die Sonne am frühen Nachmittag nicht mehr auf MEINE Ostfassade scheint.
Code: [Auswählen]
define act_on_SonneOstoff notify myReadings.Solar_East.* { if ("$EVTPART1" < 100 && "$EVTPART1" > 0 && ReadingsVal("myReadings","Elevation",0) > 18 && ReadingsVal("Rolladenfenster","pct",50) >= 50 && ReadingsVal("KlimaWohnen","temperature",0) > 22) { fhem('set Rolladenfenster open')} }
Die Werte 100 bzw. 200[W/m²] bzw 18[°]sind Erfahrungswerte, die ich über die Grafiken ermittelt habe. Bisher passt das ganz gut, ist aber sicherlich über die Zeit(Jahreszeitabhängiger Sonnenstand) noch zu optimieren.

Müsste doch bei Dir ähnlich mit dem Lichtsensor gehen. :-\ da
ZitatMein Sensor ist fix ausgerichtet in etwa in die Richtung, die ich gerne verschatten möchte.
Ein Schwellwert zum verschatten u. ein niedrigerer zum "entschatten".

Warum so kompliziert
ZitatMit einem fixen Wert, bei dem verschattet werden soll, komme ich wohl kaum weiter. Er müsste zumindest von der Tageszeit abhängen, vermutlich aber auch noch noch vom Datum, also dem Tag im Jahresverlauf.

Grüße Markus
Edit: Hab die Posts auf die Rolläden mit ROLLO-Modul angepasst. War bei mir natürlich längst produktiv.  ;D
ZitatPS: Schreiben ist weniger anstrengend als machen, der Drucksensor für den Heizkreislauf steht noch auf der Warteliste.
Und vielleicht müssen wir den auch wieder streichen, wenn ich die Haltbarkeit(anderer Thread) so sehe.  :'(
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#34
ASC = AutoShuttersControl, nehme ich an.
Das ist ja ein gewaltiges Modul, geht es irgenwie auch 3 Nummern kleiner?
Ich bin mir nicht sicher, ob ich mir dieses Modul nur wegen der Tageszeit-abhängigen Helligkeitskurve antun möchte.

Der Appetit kommt beim Essen[emoji39]

Rauf,runter, privacy, Beschatten, Aussperrschutz, Lüften, Fensterkontakte, Einbruchschutz ...

Ich wollte auch erst selber machen, aber Unterstützung finde ich besser.

Gesendet von meinem SM-G930F mit Tapatalk

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Gisbert

Hallo Markus,

bei mir zeichnet der Lichtsensor auch eine Art Gausskurve bei wolkenlosem Himmel, und der Sensor ist den ganzen unverschattet durch Bäume, Häuser etc.

Das, was ich erreichen möchte, sieht bei mir folgendermaßen aus:

  • Verschattung durch Senkrechtmarkise, wenn die Sonne scheint (und auf das Fenster fällt - gelöst per Azimuth)
  • Schutz der Senkrechtmarkise, wenn es plötzlich dunkel wird und Regen (oder gar Sturm) angesagt ist
Wenn ich mittags bspw. 50000 Lux habe, und Wolken ziehen auf, die den Wert auf 5000 Lux reduzieren, dann soll die Markise hoch. Wenn es aber abends 5000 Lux gibt, dann weiß ich, dass die Sonne immer noch voll auf dem Fenster steht und die Bude aufbrutzelt, dann möchte ich die Verschattung unten haben.
Ich bräuchte so was wie den stundenabhängigen Maximalwert, der dann zwischen Mai und September auch noch tagesabhängig sein dürfte, um darauf eine Schwelle von ca. 10% zu setzen, bei der die Markise hoch soll.

Gibt es so was, oder ist es zu kompliziert gedacht?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

KölnSolar

#36
Nur ein wenig.  ;)

Ich kann mir die von Dir angegebenen Werte(5000 Lux abends bei praller Sonne u. 5000 Lux mittags bei Wolken) so gar nicht vorstellen. Ich hatte früher einen Lichtsensor an einem "Automaten", der hat das perfekt gelöst: pralle Sonne = Verschattung; keine Sonne(egal ob Wolken oder Uhrzeit) = keine Verschattung.

Ansonsten würde noch der azimuth(anstatt Uhrzeit) helfen. Die sagt Dir ja genau wo die Sonne gerade steht. Guck Dir mal den Link in Edit2 im 1. Post an. Der gibt einem schon einmal ein besseres Verständnis der Einstrahlungssituation zu den unterschiedlichen Jahreszeiten.

Wenn Du z.B. einen Faktor aus azimuth(abends höher als mittags) u. Lux-wert bildest ?  :-\

Grüße
Markus
PS: Wie hast Du den Sensor positioniert ? Der Sollte meines Erachtens im Lot zur zu verschattenden Fläche "gucken". Hast Du ihn vielleicht in einem "Schattenspender"(Rohr, Hülse....) versteckt, so dass abends nicht mehr die volle Einstrahlung zum tragen kommt ?

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

#37
Könnte ein Temperaturwert von außen und im Innerbereich am Fenster direkt in der Sonne eventuell auch noch wertvolle Werte liefern?

Ich habe mit auch eine Brigthness Berechnung mit Werten von naheliegenden Wetterstationen und einer Verwurschtelung mit dem UV Index gemacht.
Das ganze habe ich über drei Stationen von wunderground gestreut, um Wolken und kurze Schwankungen zu eliminieren.
Guckst Du hier https://forum.fhem.de/index.php/topic,102199.msg967512.html#msg967512

Temperatur nehme ich aus der LWP im Süden in der Sonne und die Sonnenposition aus dem Astro Modul. Das wird dann im ASC zusammengebracht.
Wie man das nun zusammenrechnet ist ziemlich egal, man braucht halt Werte, die die Situation beschreiben.

Hier mal ein Bild zur Einrichtung...
Im Diagramm sieht man die Position der Rollos (/10) als Stufendarstellung. Um 16:45 gehen zwei Rollos in Privacy, zum Sonnenuntergang dann alle auf zu. Bei Beschattung sieht man den Zustand dann natürlich auch.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

Ich habe erst jetzt gemerkt, dass die Formel zur Ermittlung der Solarstrahlung nur annähernd richtig war und in meinem Fall fast genau passte.

Ich habe sie nun im 1. Post um die erforderlichen Werte Modulanzahl/kWp, Fläche/Modul und Modulwirkungsgrad erweitert.  ;)

Grüße  Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ch.eick

Zitat von: KölnSolar am 08 Oktober 2022, 11:30:38
Ich habe erst jetzt gemerkt, dass die Formel zur Ermittlung der Solarstrahlung nur annähernd richtig war und in meinem Fall fast genau passte.

Ich habe sie nun im 1. Post um die erforderlichen Werte Modulanzahl/kWp, Fläche/Modul und Modulwirkungsgrad erweitert.  ;)

Grüße  Markus
Hallo Markus,
das ist bereits alles in meinem Solar_forecast() für die Leistungsprognose enthalten ;-) Ich hatte darmals doch Deine Formel übernommen
und das dann weiter voran getrieben. Anschließend ist das dann auch bei DS_Starter mit eingeflossen.
Meine Leistungsprognose kann auch Herstellerunabhängig verwendet werden und in jedes andere Device die readings schreiben.
Temperatur, Wolken und Regen werden vom DWD ermittelt.

VG
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick