Wirkungsgrad von Kollektoren bzgl. Einfallswinkel berechnen

Begonnen von Elektrolurch, 30 Mai 2015, 09:49:17

Vorheriges Thema - Nächstes Thema

Elektrolurch

Hallo,

der Wirkungsgrad von Kollektoren hängt ja von vier Werten ab (Wetter mal außen vor):

a) Neigungswinkel (elevation) der Sonne zum Horizont
b) Position der Sonne bzgl. Himmelsrichtung (azimuth)
c) Ausrichtung des Kollektors (Himmelsrichtung (azimuth)
d) Neigungswinkel des Kollektors (elevation)

a) und b) bekommt man z.B. über das twiligth - Modul
c) und d) sind ja fix und müssen ja nur einmal gemessen werden.
Scheint die Sonne genau senkrecht auf die Kollektorfläche, so ist der Wirkungsfaktor 1. Für alle anderen Positionen kleiner als 1.

Jetzt wollte ich mir das mal berechnen und habe mit einigen sin und cos was herausbekommen, bin mir aber nicht sicher, ob das so stimmt.

Hat das schon mal jemand berechnet?

Blamabel, ist ja eigentlich Abi-Stuff und sollte man noch können. Hier mal mein Code:

my $tw = 'Daemmerung';
my $hz = 'HzAnlage';
my $el = ReadingsVal($tw,'elevation',0);
my $az = ReadingsVal($tw,'azimuth',0);
my $kel = AttrVal($hz,'Kollektor-Neigung',0);
my $kaz = AttrVal($hz,'Kollektor-Richtung',0);

# Nacht?
return undef if ($el < 0);

# horizontal drehen
$az = $az - $kaz + 90;
my $ss = 0;
# vertikale Neigung
$ss = cos(($el - $kel) * pi / 180);
# verringerung durch azimut
my $hs = sin($kel * pi / 180) * abs(cos($az * pi / 180));
$ss = $ss * (1 - $hs); 
# auf 100 normieren
$ss = sprintf("%d",$ss * 100);
Log(1,"Proj 2: ss $ss el $el az $az kel $kel kaz $kaz");
readingsSingleUpdate($defs{$hz},'Solar-Projection',$ss,1);

Elektrolurch
configDB und Windows befreite Zone!

Prof. Dr. Peter Henning

#1
Dies bezeichnet man aber nicht als Wirkungsgrad, der Wirkungsgrad ist das Verhältnis aus abgeführter und zugeführter Leistung und liegt für thermische Kollektoren bei ca. 50%

Für den solaren Ertrag ist maßgeblich, wie die Absorption des Kollektors vom Winkel abhängt - dafür gilt keineswegs das Lambertsche Gesetz.

Schließlich: Ich traue den von (Edit:) Twilight gelieferten Werten für Elevation und Azimut nicht, meine eigenen Simulationen für meine PV-Anlage ergeben andere Daten.

LG

pah

smurfix

Zitat von: Prof. Dr. Peter Henning am 30 Mai 2015, 21:01:18
Für den solaren Ertrag ist maßgeblich, wie die Absorption des Kollektors vom Winkel abhängt - dafür gilt keineswegs das Lambertsche Gesetz.
Dürfte außerdem von der genauen Ausgestaltung der Kollektoren abhängen, oder?
Zitat
Ich traue den Yahoo-Werten für Elevation und Azimut nicht

Dumm gefragt: wie, Yahoo? Brauchbare Formeln zum Berechnen des Sonnenstands finden sich im Netz, oder (evtl. noch besser) im Sourcecode des Astronomieprogramms deiner Wahl.

Prof. Dr. Peter Henning

Das genannte Modul twilight holt nach meinen Informationen den Wert von Yahoo.

LG

pah

Dietmar63

Zitat
Schließlich: Ich traue den Yahoo-Werten für Elevation und Azimut nicht, meine eigenen Simulationen für meine PV-Anlage ergeben andere Daten.

Die Werte azimuth und Elevation werden in Twilight mit Formeln von Loredo berechnet.

Sie stammen nicht von Yahoo.

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Prof. Dr. Peter Henning

Hm, danke für die Korrektur - dann traue ich diesen Werten nicht.

Meine eigene Simulation ist ein mit Mathematica geschriebenes astronomisches Programm, enthält keinerlei Näherung und wird auch von Anderen verwendet. Soll heißen: Da bin ich recht sicher, dass es stimmt.

LG

pah

Dietmar63

Dann müsstet ihr nur noch einen Weg finden die Werte aus Mathematika fhem zur Verfügung zu stellen.
Vielleicht reichen ja die ungefähren Werte aus TW aus.

Die Mathematik zur Berechnung von azimuth und Elevation erscheint mir etwa so einfach wie die Berechnung von SonnenAufgang bzw. SonnenUntergang zu sein. Und auf +-
1°sollte es nicht ankommen.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Prof. Dr. Peter Henning

Nein, ist gar nicht einfach.

Erstens muss die Jahreszeit, zweitens die Tageszeit, drittens die geografische Breite, viertens die geografische Länge berücksichtigt werden. Letzte spielt deshalb eine Rolle, weil sie den Abstand vom Nullmeridian genauer festlegt, als die Tageszeit.

Bei 1440 Minuten pro Tag kommt man damit auf ca. 1 Grad Genauigkeit.

Die Tatsache, dass die Erdbahn kein Kreis, sondern eine Ellipse ist, muss bei noch genauerer Rechnung durch eine Korrektur (wahrer Sonnentag gegenüber mittlerem Sonnentag) berechnet werden.

LG

pah

Dietmar63

Meine Aussagen bezogen sich nur auf die Berechnung von azimuth und Elevation
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Prof. Dr. Peter Henning

Ja, genau die meine ich auch...

Ich habe das vor Jahren mal sehr genau unter die Lupe genommen, um eine genau gehende Sonnenuhr zu konstruieren. Das ist zwar alles elementare Mathematik, aber schon ein ziemliches Gefuddel.

Der einfachste Weg, diese Daten zur Verfügung zu stellen, wäre ein Posting des Mathematica-Codes. Den kann man bei Wolfram Alpha eingeben und hat seine lokale Kurve.Könnte aber eine Weile dauern, bis ich das ausgegraben habe.

LG

pah

Dietmar63

Aber handelt es sich bei einem solchen Ansatz um "Mit Kanonen auf Spatzen schiessen".
Azimuth und Elevation reichen für den Hausgebrauch wenn sie mit +/-1° zur Verfügung gestellt werden können. Die Genauigkeit dürfte aus TW etwas der Genauigkeit des sunrise_el Moduls entsprechen.

Nachkommastellen sind aus meiner Sicht irrelevant.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Prof. Dr. Peter Henning

Das ist nicht richtig.

Wenn man die Werte auf 1 Grad genau haben will, kann höchstens die Exzentrizität der Erdbahn vernachlässigt werden, alle anderen Aspekte müssen berücksichtigt werden.

LG

pah

erwin

@Elektrolurch,

unabhängig von der Diskussion über Genaugikeit und Vertrauen.....
ich hab das auch mal versucht und gepostet, war mir auch nicht sicher, ob es stimmt....
Evtl. für dich als Vergleich?
http://forum.fhem.de/index.php/topic,36430.msg287119.html#msg287119
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Elektrolurch

Hallo Erwin,

danke für Deinen Beitrag. Habe mir mal die Formel von Dir herauskopiert. Meine, und ich habe da am WE noch Mal herumprobiert, sieht so ähnlich aus, muss aber das mal so auflösen, dass ich den Unterschied sehe.

Im Beitrag 2 zu meiner Frage hat PA zwar viele "Richtigstellungen" gepostet und auch dargelegt, wie toll und genau er alles berechnet..
Leider aber nicht meine Frage beantwortet, obwohl er ja das wohl auch gelöst zu haben scheint. War also nicht sehr hilfreich, seine Beiträge und ff.

Vielen Dank an Dich Erwin.

Elektrolurch
configDB und Windows befreite Zone!

Prof. Dr. Peter Henning

Immer schön bei der Wahrheit bleiben.
Denn die einzige Frage war, ob das schon mal jemand berechnet hat - und die habe ich sehr wohl beantwortet.

pah