NEWS
Vergleich Solarprognosen Solarwetter und brightsky
-
@klassisch
noch immer der gleiche Fehler? Ok der Link geht gleich nicht mehr - ich mache ne Verison -
@ticaki Ich habe jetzt den iob Befehl direkt in CMD eingegeben. Dann hat er was installiert
Version im Admin immer noch
0.3.1 (1~)Diese Version zeigt momentan mit den schwachen 19:00 Werten
ghi (solar) 0.117
und solar_estimate 0.088
bei meinem 0°, 1, 1 Testvektor - also Modul horizontal 1m², 100% Wirkungsgrad. -
ok dass sollte ... hm ich weiß nicht ob das ne gute idee war - kenne mich mit windows nicht aus - die Version ändert sich nur wenn ich eine Version mache - die Entwicklungsversion hat i.d.R. keine geänderte Versionsnummer.
Aber in 10 Minuten sollte es per npm gehen - also das Fenster mit der benutzerdefinierten Installation aber da npm auswählen und dann ticaki/ioBroker.brightsky glaube ich.
EDIT:
so sieht das aus - aber ist noch nicht da
EDIT2
Jetzt ist es angekommen - obs schon installierbar ist oder er noch die alte nimmt weiß ich aber netEDIT3 - er nimmt die 0.3.2
-
@ticaki Vielen Dank! 0.3.2 auch hier. Und verhält sich anders
solar (ghi) 0.133
solar_estimate 1
könnte grundete 0.133 sein, was ein plausibles Ergebnis wäre.
Mehr sehe ich erst später. morgen um 07:00 ist ghi immer noch 0Edit: Achso, ich habe über github benutzerdefiniert und nicht über npm installiert. lief aber durch und Version passt ja.
Edit2: Habe jetzt nach @Armilar s Hinwei mal 24h eingestellt. Und morgen Thu Sep 18 2025 14:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
haben solar und solar_estimate gleiche Zahlenwerte - wie es sein soll. -
@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:
Der Rest ist bei mir
gestern gut 20% über Forecast und heute wird's noch mehr.Es sei Dir gegönnt! War gestern eh den ganzen Tag mit Auto weg. Und heute ist es wieder voll geladen
Octo(
pus)CatAh, ja. vielen Dank!
-
@armilar sagte in Vergleich Solarprognosen Solarwetter und brightsky:
ja - der Adapter lässt 48 Stunden zu
Vielen Dank! Hatte den Post glatt überlesen - sorry! Dann werde ich mal 24h einstellen.
-
@klassisch
In der rechnung ist noch folgendes mit drin - kann man wohl aus den Variablen ableiten was es ist:const poaWhPerM2 = valueWhPerM2 * (beamFraction * dirGain + diffuseFraction * skyDiffuseGain + groundRefGain);
-
@ticaki Ja, habe jetzt die 24 Forcast Stunden (+ die aktuelle Stunde = 25 h) eingestellt und den "Streiflichttest" gemacht.
Mein Skript bricht auf 0 ein, weil es nur direkte Strahlung berechnet.
Adapter geht von 0,692 auf ca. 0,2 zurück.
Die Python Lib verhält sich ähnlich.Sieht also auf den ersten Blick gut aus.
-
Auf den zweiten Blick sieht das auch noch gut aus. Die Werte der sonnenstarken Phasen passen zu meinem Skript.
Und da könnte ich gleich einen Feature Request antizipieren:
- Modulüberbelegung bzw. Begrenzung durch Wechselrichter.
Das ist bei mir der Fall. Für die Entscheidung netzdienliches Laden wohl ohne große Bedeutung. Aber wenn man schon Albedo, Diffuslicht etc berücksichtigt .. (icon für Duck und weg)
Bei mir wurde einfach ausconst energy_kWh = poa_kwh_m2 * AREA_M2 * EFFICIENCY
const energy_kWh = Math.min(poa_kwh_m2 * AREA_M2 * EFFICIENCY, inverterLimit);
-
@klassisch und du schreibst was von homoran'schem Perfektionismus!
-
@homoran Nunja, ich schrieb ja, daß es für meinen einfachen Anwendungsfall nicht sooo wichtig ist.
Irgendwann später wird aber jemand danach fragen.
Und wenn wir schon mal dabei sind und es doch soo einfach zu implementieren ist .....Edit: Ja und wenn wir gerade darüber sprechen: Man könnte die geklippten Daten und die ungeklippten Daten parallel halten. Dann kann man berechnen, was man durch das Clipping verliert. Bei mir war es letztes Jahr < 20 EUR Einspeisevergütung.
-
@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:
den ganzen Tag mit Auto weg. Und heute ist es wieder voll geladen
du fährst jetzt auch elektrisch?
Da sieht man mal, wie die Zeit vergeht und wie lange ich dich nicht mehr gesehen hab!@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:
für meinen einfachen Anwendungsfall nicht sooo wichtig
ach ja!
mein Schlechtwetterprogramm hat heute sein bestes getan!
nicht gerade wirklich netzdienlich, zwar nur 1.5 kWh eingespeist, allerdings nicht früh morgens*.
aber die Batterie war planmäßig voll.EDIT:
- doch, tatsächlich einiges früh morgens
aber eher zufällig.
- doch, tatsächlich einiges früh morgens
-
@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:
Bei mir wurde einfach aus
const energy_kWh = poa_kwh_m2 * AREA_M2 * EFFICIENCY
const energy_kWh = Math.min(poa_kwh_m2 * AREA_M2 * EFFICIENCY, inverterLimit);
Ich hab 2 Gruppen an einem Wechselrichter - das ist dann schon etwas komplexer
-
@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:
du fährst jetzt auch elektrisch?
Ja schon ein paar Jahre. Passt gut zur PV-Anlage und fährt angenehm. Davor Plug-In Hybrid. Ging auch gut 100km elektrisch.
Da sieht man mal, wie die Zeit vergeht und wie lange ich dich nicht mehr gesehen hab!
Da hast Du recht! Corona hat leider die Kasseler HM-Tradition gebrochen und das ioBroker Meeting war mir zu weit weg und ich hatte anderes zu tun.
mein Schlechtwetterprogramm hat heute sein bestes getan!
nicht gerade wirklich netzdienlich, zwar nur 1.5 kWh eingespeist, allerdings nicht früh morgens.
aber die Batterie war planmäßig voll.Respekt!
Ich mache das noch manuell. Und nicht so perfektionistisch -
@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:
Ich hab 2 Gruppen an einem Wechselrichter - das ist dann schon etwas komplexer
Die Komplexität hast Du ja schon bei der Definition der Strings und deren Orientierung. Solange es nur einen WR gibt, kann man dessen summarische PV Leistung entsprechend mit Math.max clippen. Kompliziert wird es wenn es mehrere Strings an mehreren WR gibt. Beispielsweise zwei Strings an einem und drei Strings am anderen. Das würde die Konfiguration aufwendiger gestalten. Könnte man aber umgehen, indem man für jeden WR eine eigene Instanz anlegt. Jetzt nicht so hyperelegant. Aber ich würde es als user so machen. Einfach und robust. Und wer mit den Ergebnissen mehr rechnen oder regeln will, kann es ja mittels Skript selber rechnen.
-
@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:
Und nicht so perfektionistisch
Das Schönwetterprogramm rechnet auch nur den Energiebedarf zum laden und verteilt das auf die Stunden bis der max Est unter die 60% PV Leistung fällt. ab da dann laden mit voller Leistung
Das war bei wechselnder Bewölkung viel zu wenig, da die Leistungsspitzen während Wolkenlücken nicht genutzt wurden.
Jetzt rechne ich zusätzlich noch einen Faktor aus, der sich aus der fehlenden Energie der letzten Stunden ergibt, die wegen Wolken nicht produziert wurde.so was ganz einfaches
EDIT:
Für dich in js
und nicht lachen!
ich kann besser frickeln als wie du! -
@klassisch
Wenn man sowas einbaut dann richtig oder garnicht -
@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:
@klassisch
Wenn man sowas einbaut dann richtig oder garnichtJa genau, für einen WR richtig einbauen. Wer sich mehrere WR leistet kann sich auch mehrere Instanzen leisten. Keep it simple duckundweg
-
Sind 4 möglich und unendliche anzahl an Panels - bedenke die Leute die sich 8 Balkonkraftwerke halten - offiziell haben sie natürlich nur 1
-
Da zum Probieren
https://github.com/ticaki/ioBroker.brightsky/tree/fix/limit-inverter-max-power
Übersetzungen hab ich nicht überprüft
EDIT: LOL: Wechselrichter 1 max. Macht (KW)
EDIT2: wie man sieht hab ichs dann doch überprüft.