Weihnachtsangebot 2025! 🎄

[icebear]

@homoran said in Vergleich Solarprognosen Solarwetter und brightsky:

und wo sind die Panels?
bzw. die Dachneigung?

Na das schwarze sind die Panels, Richtung NO = 8 Panels Dachneigung 40° und Richtung SW = 12 Panels 40°

Den First haste ja schon richtig eingezeichnet:relaxed: (hatte ich vergessen)

und was soll mir das > wobei 60 +180 = 240 sagen?

[Homoran]

@icebear sagte in Vergleich Solarprognosen Solarwetter und brightsky:

was soll mir das > wobei 60 +180 = 240 sagen?

wenn die Panels auf gegenüberliegenden Dachhälften liegen, sind die um 180 Grad gedreht.
Dann stimmen deine Werte so nicht ganz.

[icebear]

@homoran said in Vergleich Solarprognosen Solarwetter und brightsky:

wenn die Panels auf gegenüberliegenden Dachhälften liegen,

Ah, verstehe (hoffentlich) da die Panels ja genau gegenüber liegen müssten das ja 180° sein.

Heißt wenn die auf der einen Seite 60° Richtung NO zeigen, dann müßten die auf der anderen Seite bei 240° SW liegen, es sei denn das Haus ist schief :face_with_rolling_eyes:

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Hab ich ganz vergessen zu sagen - in der aktuellen beta wird für jede ¼ Stunde der Wert berechnet um dichter an ein gutes ergebnis zu kommen.

EDIT: Hab nicht mehr Messwerte - aber die Sonne wandert ja in einer Stunde doch ein Stückchen am Himmel.

Interpretiere ich das richtig?

• Es gibt noch immer 13 Datensätze pro Tag 00 bis +12
• Die stündlichen DWD Daten "solar", also ghi, bleiben über die Stunde konstant
• die Daten "solar_estimate". werden jetzt aus dem Sonnerverlauf innerhalb dieser Stunde berechnet und der Mittelwert der Einzelrechnungen wird in den Datenpunkt geschrieben

Edit: Und welche Nummer hat die latest beta? Ich habe derzeit 0.3.0

[ticaki]

@klassisch
v0.3.1

Die v0.3.0 hat nen Fehler wenn man keine Panels eingetragen hat.

Hm ich glaube da ist ein Fehler in der Rechnung - mir gehts die letzten Tage nicht so doll. Ok ich glaube es nicht nur, dass muß falsch sein:

4 Iterationen

const quarterHourValue = estimatePvEnergy(valueWhPerM2 / 4, quarterHourTime, coords, panels) / 4;
        if (i === 0) {
            valueWhPerM2 = quarterHourValue;
        } else {
            valueWhPerM2 += quarterHourValue;
        }

Da hab ich ein /4 zuviel oder?

EDIT: hab mal chatGPT gefragt und der meint folgendes:

Bei modernen Photovoltaik-Modulen liegt der Wirkungsgrad typischerweise bei 18–23 %.

Das heißt:
	•	Von 1000 W/m² Sonnenstrahlung (Standardtestbedingung) werden etwa 180–230 W/m² elektrische Leistung.
	•	Faktor von eingestrahlter Energie (Wh) zu abgegebener elektrischer Energie (Wh) ≈ 0,18–0,23.

High-End-Module (z. B. monokristalline TOPCon oder HJT) schaffen auch bis knapp 25 %.

[ticaki]

Bitte das hier mal testen

https://github.com/ticaki/ioBroker.brightsky/tree/fix/solar-panel-energy-yield-estimate (benutzerdefinierte Github installation expert -> adapter -> katze -> ganz rechts)

Da sollte jetzt die Rechnung stimmiger sein - Ich gehe davon aus, das die DWD Werte die Rohdaten sind und man bei effizenz den Wirkungsgrad der Panels eingeben muß.

Ist durchaus möglich das die Rechnung noch einen Fehler hat. Ich hab aber nicht genug erfahrung um das direkt zu sehen, hab das doch hauptsächlich für euch eingebaut, mit unzureichenden Hintergrund informationen :)

Edit: hab das jetzt so angepasst im Admin: Azimut (0-360°) 0=N (im Uhrzeigersinn) wird das jeder verstehen?

[klassisch]

@ticaki Ja, die 20% Wirkungsgrad sind eine gute Näherung. Bei meinen auch nahebei im Datenblatt.

Die Iteration habe ich nicht verstanden.
Ich wurde es halt in der Art rechnen:

quarterHourValue = (valueWhPerM2 [1] + valueWhPerM2 [2] +valueWhPerM2 [3] +valueWhPerM2 [4])/4

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Schnelle RM, den Rest habe ich nicht durch, weil ich noh an einer anderen Sache dran bin

Edit: hab das jetzt so angepasst im Admin: Azimut (0-360°) 0=N (im Uhrzeigersinn) wird das jeder verstehen?

Bietet leider noch immer Raum für Misverständnisse.
N=0 ; O=90
wäre das Mindesteste mM nach. Das würde mir zumindest mir reichen.

[ticaki]

@klassisch
Nur ist O in Franzözisch westen - das muß ich dann einzeln anpassen - oder ich lass es da weg - jo passe nur de und en an

EDIT

in 3.1 ist die REchnung mit 2 * /4 das ist falsch

also (valueWhPerM2 [1] /4/4+ valueWhPerM2 [2]/4/4 +valueWhPerM2 [3]/4/4 +valueWhPerM2 [4]/4/4)

aktuell onlijne ist

(valueWhPerM2 [1] /4+ valueWhPerM2 [2]/4 +valueWhPerM2 [3]/4 +valueWhPerM2 [4]/4)

Deine Version spart aber 3 Rechnungen - passe das an.

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

@klassisch
Nur ist O in Franzözisch westen - das muß ich dann einzeln anpassen - oder ich lass es da weg - jo passe nur de und en an

Das ist wahr, Ouest, . Der Osten wäre E=90
Est

[ticaki]

@klassisch

habs für DE und EN angepasst mit 90=O und 90=E - für den rest kann ich das mal von chatGPT machen sollen - vorallem 方位角（0-360°）

EDIT: bitte die branch oben testen - will nicht noch ne fehlerhafte Rechnung veröffentlichen.

[Homoran]

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Es gibt noch immer 13 Datensätze pro Tag 00 bis +12

die Anzahl kannst du konfigurieren

[ticaki]

@homoran

Für die Prognossen werden 7 * 24 Datensätze bezogen und dann nach Tag abgearbeitet - das hat nichts mit den eigenen hourly einstellungen zu tun. Diese Abfragen laufen in getrennten Zweigen.

[klassisch]

@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

die Anzahl kannst du konfigurieren

Ist das das?

[klassisch]

Nochmals zu den prinzipiellen Abweichungen der Schätzung.
Ich hatte ja dort https://forum.iobroker.net/post/1294675 meine heutigen Daten geschrieben und verglichen.
Habe jetzt nach einer langen Reise mit ChatGPT ein Python Skript, welches die Python Lib PVlib nutzt und dem man die Daten plausibilisieren kann.
Das bringt mit den 05:00 Werten ghi = 0.439 für 12:00 als Ergebnis 6220.
Das liegt nahe bei dem Wert, den mein einfaches JScript generiert hat. Jedenfalls näher als das Ergebnis des Adapters.

[Armilar]

@klassisch

ja - der Adapter lässt 48 Stunden zu

[ticaki]

Ich werde mal heute abend schauen was er mir rückwirken voraussagt, dann schreib ich den wirkungsfaktor aus soll und ist in die konfig und gucke mal wie es morgen ist.

[klassisch]

@ticaki Kein Stress, ist ja nicht dringend.

Ich kann anbieten, Dir das python Script und mein Frickelscript per PN zukommen zu lassen.

Edit: Ein einfacher (erster) Test: Neigung 0°; Fläche 1m²; Effizienz 100%, Dann muß ghi = poa = Leistung (bzw. Energie in 1 h) sein, also solar_estimate. Und das zu jeder Stunde.
Hier stimmt das python Skript mit meinen JSCript überein.
Der Adapter liefert andere, geringere Wert.

[ticaki]

@klassisch

Danke das hat den Fehler aufgedeckt. Hab beim summieren der vietelstunde werte einen Fehler gemacht so das er sich kumuliert hat.

https://github.com/ticaki/ioBroker.brightsky/tree/fix/solar-panel-energy-yield-estimate

Außerdem beim debuggen auch unnötige Wiederholungen mit 0 Werten entfernt - die werden auch durchs rumrechnen nicht besser :)

[klassisch]

@ticaki Ich habe jetzt noch einen Test gemacht:
Panel 90° aufstellen und in streifenden Lichteinfall drehen, also die Flächennormale seknrecht zum Azimut. Aber aufpassen, einige Algos arbeiten unsymmetrisch wie einseitige Module. Der Adapter scheint auch einen solchen zu verwenden. In einer Winkelposition bricht der Ertrag erwartungsgemäß zusammen. Ich muß das aber Morgen nochmals mit einem intensiven Mittagswert testen.
Bei meinem Skript bricht der Ertrag auch komplett ein.
Beim Python Skript ist mit der Python PVLIib geht der Ertrag zurück, aber nicht auf Null. Vielleicht wird dort noch Streulicht oder Albedo reingerechnet.
Bei diesen Experimenten ist die "1" hilfreich. Fläche 1, Wirkungsgrad 1.