Vergleich Solarprognosen Solarwetter und brightsky

[klassisch]

@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

ich hab keinen Fronius

Bei meinem Fronius ist dieser Mechanismus, die ja noch aus den 70% Zeiten stammt, hinter einem technician PWD, welches ich leider nicht habe.
Aber falls die Einspeisebegrenzung tatsächlich erforderlich sein sollte, wird es Lösungen geben.

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

0.3.0 (2025-09-15)

• (ticaki) Added experimental datapoint for solar energy estimation (daily and hourly)
• (ticaki) Wind bearing text is now translated into ioBroker system language
• (ticaki) Added new datapoint for MDI icons support
• (ticaki) Add day and night objects in addition to daily objects fixes #11
• (ticaki) Enhanced day and night support with dedicated day/night icons

Habe die neueste Beta mal gezogen.
Verstehe den Wirkungsgrad nicht. Ist das der Modulwirkungsgrad aus dem Datenblatt, also irgendwas um 20%? Wenn ich das eingebe, dann ist
brightsky.0.hourly.01.solar_estimate
etwa um Faktor 10 zu klein. Gebe ich die vorgeschlagenen 85% ein, dann sind die Ergebnisse ca. um Faktor 4 zu groß.

[Homoran]

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Verstehe den Wirkungsgrad nicht

zeigen, zeigen, zeigen!
meinst du hier?

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Ist das der Modulwirkungsgrad aus dem Datenblatt, also irgendwas um 20%?

ja!
im Prinzip kWp/m² eines Panels

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

nicht. Ist das der Modulwirkungsgrad aus dem Datenblatt, also irgendwas um 20%? Wenn ich das eingebe, dann ist
brightsky.0.hourly.01.solar_estimate
etwa um Faktor 10 zu klein.

bitte auch zeigen.

dann muss beim scaledown auf hourly was schiefgegangen sein.
ich hab seit paar Tagen eine Vorabversion ohne estimate bei hourly.
bei daily passt es bei mir

[klassisch]

@homoran Dann fange ich mal ganz selbstbewusst mit dem Ergebnis meines Frickelscripts an. Ergebnis für die Leistung liegt um 6kW, was im Stundentakt zur gleichen Zahl in kWh führt und scheint plausibel:

Im daily Datensatz 00, auf heute 14:00 datiert (Mon Sep 15 2025 14:00:00 GMT+0200 (Mitteleuropäische Sommerzeit))

sehe ich unter
brightsky.0.hourly.00.solar_estimate
:

also einen Wert von 0.684
Die zugehörige Adaptereinstellung 20%, was in etwa dem Modulwirkungsgrad entspricht :

Jetzt setze ich den Wirkungsgrad auf 80%

und das Ergebnis ist unplausibel hoch 33.526

[ticaki]

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Jetzt setze ich den Wirkungsgrad auf 80%

1. Kanns nicht testen - hab da nur null werte aktuell.
2. 0.561 * 65 = 36,465 36,465 * 80% = 29,172 das sieht plausibel aus

EDIT - das dürfte aber nicht so hoch sein, deine panels zeigen ja nach norden.

mist ich hab das daily total mit kopiert

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

EDIT - das dürfte aber nicht so hoch sein, deine panels zeigen ja nach norden.

nono, weitgehen Süden mit 10° gegen Osten. In PVGIS setze ich -10° ein. Das müßte ja den 350° entsprechen, wenn 0° gen Süden zeigt.

[ticaki]

@klassisch
Ich verbessere die Admin bezeichnung weil:

Das hängt davon ab, wer den Azimut definiert – es gibt zwei gängige Konventionen:
1. Astronomische Definition (wie bei SunCalc):
• 0 rad = Süden
• Werte laufen im Bogen: Ost = −90°, West = +90°
• Bereich = −180° … +180°
2. Geodätisch / Kompass-Definition (üblich in Navigation, GIS, Meteorologie):
• 0° = Norden
• 90° = Osten, 180° = Süden, 270° = Westen
• Bereich = 0° … 360°

Kurzantwort:
• Bei SunCalc: Azimuth ist relativ zu Süden.
• „In der Regel“ (Kompass, GIS, Technik): Azimuth ist relativ zu Norden.

Daher hab ich:

 // SunCalc-Azimut: 0 = Süd, +West; auf 0=N, 90=E normieren:

[Homoran]

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

nono, weitgehen Süden mit 10° gegen Osten.

dann ist der eingegebene Wert falsch!
0/360 is Nord

[ticaki]

Ich ändere das in:

Azimuth (0-360°) 0=N

im Admin.

[klassisch]

Ich kann mit beiden Definitionen leben, muß nur wissen, welche gilt. Da wir im Solarumfeld arbeiten, hatte ich mal diese Definition aus PV GIS etc genommen.

[Homoran]

@klassisch ich kenne 0=Süd eigentlich nur aus den Satellitenpositionen.
Die Windrose ist immer 0=Nord

edit:

Quelle: Wikipedia

[MartyBr]

@homoran
Bei vielen Anbietern von Solarprognose entspricht 0 ° Süden.
Das ist z.B. auch bei Solarprognose.de so.
Aktuell kann man dort mehrere Panel Ausrichtungen noch kostenlos eintragen.

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Ich ändere das in:

Azimuth (0-360°) 0=N

im Admin.

Dann wären meine 10° Ost 190°
Damit errechnet der Adapter
brightsky.0.hourly.01.solar_estimate
zu
2.822
schon deutlich besser, aber immer noch unplausibel wenig . Mein Wert für 15:00 wäre 6035.

Wobei ich das um 08:10 mit den dortigen Prognosen gerechnet habe und die Werte seither nicht mehr verändert habe.
Wenn sich die DWD Prognosen mittlerweile verändert haben, dann hat der Adapter beim Neustart andere DWD Werte und damit auch solar_estimate Werte.

[Homoran]

@martybr dann ist es aber sicher auch wie bei Ausrichtung der Satellitenschüssel z.B. -27° Ost und nicht 333°, oder?

[ticaki]

@klassisch

Wenn wir über die stündlichen Werte sprechen - die sind nicht kumulativ - das daily total ist falsch - c&p fehler.

[Homoran]

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Wenn sich die DWD Prognosen mittlerweile verändert haben,

nur um 0:00, 05:00 und um 18:00

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

und damit auch solar_estimate Werte.

hmm, bei mir gibt's deswegen Spezial

War super lieb von @ticaki, aber ich schreib inzwischen schon um 5:15 die estimates in eigene DP und rechne damit weiter

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

@klassisch

Wenn wir über die stündlichen Werte sprechen - die sind nicht kumulativ - das daily total ist falsch - c&p fehler.

Ja, ich rede von den stündlichen Werten. Die blaue Kurve hat mein Skript heute morgen um 08:10 aus der damaligen Datenlage gerechnet und history mit gefüttert.

History hat das dann in das history json file geschrieben

Spoiler

[
  {
    "val": 237.04044165379764,
    "ack": 1,
    "ts": 1757916000000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 1192.062399664518,
    "ack": 1,
    "ts": 1757919600000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 2559.162652377875,
    "ack": 1,
    "ts": 1757923200000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 3930.7320407839475,
    "ack": 1,
    "ts": 1757926800000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 5258.085203958388,
    "ack": 1,
    "ts": 1757930400000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 6077.021134136788,
    "ack": 1,
    "ts": 1757934000000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 6435.295870959073,
    "ack": 1,
    "ts": 1757937600000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 6034.966080298795,
    "ack": 1,
    "ts": 1757941200000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 5282.569127553792,
    "ack": 1,
    "ts": 1757944800000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 3866.516851116459,
    "ack": 1,
    "ts": 1757948400000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 2275.8213268259638,
    "ack": 1,
    "ts": 1757952000000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 410.005448541669,
    "ack": 1,
    "ts": 1757955600000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  },
  {
    "val": 0,
    "ack": 1,
    "ts": 1757959200000,
    "q": 0,
    "c": "script.js.EnergyManagement.PvForecastBrightSkyBased",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin"
  }
]

[MartyBr]

@homoran
Richtig. Die Angaben erfolgen hier -180 bis 180 °. Nullpunkt ist Süden mit 0°
-90° ist Osten, +90° ist dann Westen.

Ist eben eine Definitionssache, Hauptsache, die 360° werden abgebildet.

[klassisch]

@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Wenn sich die DWD Prognosen mittlerweile verändert haben,

nur um 0:00, 05:00 und um 18:00

Ja, um 05:00 rechnet das Skript zum ersten Mal bis 17:00. In der Übergangszeit und im Winter reicht das zur Entscheidung. Aber meine Vorhersagekurve sieht halt unfertig aus. um 08:00 rechnet das Skript nochmals und modifiziert die Kurve. Spätestens danach entscheide ich über den Ladefahrplan. 18:00 interessiert mich dann für diesen Anwendungsfall nicht mehr.

[klassisch]

Die 05:00 Daten von heute:

Daten des Skripts, welches ich verwende am Beispiel 12:00:

 { "hour": 7, "time": "Tue Sep 16 2025 12:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.367, "poa_kwh_m2": 0.5061753569504339, "energy_kWh": 6.639081019221859 },

Vorschaukurve über 12h von 05:00 bis 17:00

Alle Stunden

Spoiler

Alle Stunden:
   script.js.EnergyManagement.PvForecastBrightSkyBased: Gesamte erwartete Energie heute: 52 kWh { "hour": 0, "time": "Tue Sep 16 2025 05:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0, "poa_kwh_m2": 0, "energy_kWh": 0 }, { "hour": 1, "time": "Tue Sep 16 2025 06:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0, "poa_kwh_m2": 0, "energy_kWh": 0 }, { "hour": 2, "time": "Tue Sep 16 2025 07:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0, "poa_kwh_m2": 0, "energy_kWh": 0 }, { "hour": 3, "time": "Tue Sep 16 2025 08:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.011, "poa_kwh_m2": 0.018478070228058044, "energy_kWh": 0.24236147342700762 }, { "hour": 4, "time": "Tue Sep 16 2025 09:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.083, "poa_kwh_m2": 0.12492129104230186, "energy_kWh": 1.638488640087726 }, { "hour": 5, "time": "Tue Sep 16 2025 10:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.189, "poa_kwh_m2": 0.2729957662185061, "energy_kWh": 3.58065833301065 }, { "hour": 6, "time": "Tue Sep 16 2025 11:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.286, "poa_kwh_m2": 0.40265006868547776, "energy_kWh": 5.281225946090266 }, { "hour": 7, "time": "Tue Sep 16 2025 12:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.367, "poa_kwh_m2": 0.5061753569504339, "energy_kWh": 6.639081019221859 }, { "hour": 8, "time": "Tue Sep 16 2025 13:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.436, "poa_kwh_m2": 0.5897519135173445, "energy_kWh": 7.735285176014961 }, { "hour": 9, "time": "Tue Sep 16 2025 14:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.458, "poa_kwh_m2": 0.6066293227145992, "energy_kWh": 7.9566521104509 }, { "hour": 10, "time": "Tue Sep 16 2025 15:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.442, "poa_kwh_m2": 0.5706131555544697, "energy_kWh": 7.484258011262558 }, { "hour": 11, "time": "Tue Sep 16 2025 16:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.397, "poa_kwh_m2": 0.49444124440015014, "energy_kWh": 6.485174427681428 }, { "hour": 12, "time": "Tue Sep 16 2025 17:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)", "ghi": 0.3, "poa_kwh_m2": 0.35165894800846154, "energy_kWh": 4.612417840782246 }] { "val": 0, "ts": 1757991600000 }, { "val": 0, "ts": 1757995200000 }, { "val": 0, "ts": 1757998800000 }, { "val": 242.3614734270076, "ts": 1758002400000 }, { "val": 1638.488640087726, "ts": 1758006000000 }, { "val": 3580.65833301065, "ts": 1758009600000 }, { "val": 5281.225946090266, "ts": 1758013200000 }, { "val": 6639.081019221859, "ts": 1758016800000 }, { "val": 7735.285176014961, "ts": 1758020400000 }, { "val": 7956.6521104509, "ts": 1758024000000 }, { "val": 7484.258011262557, "ts": 1758027600000 }, { "val": 6485.174427681428, "ts": 1758031200000 }, { "val": 4612.4178407822465, "ts": 1758034800000 }

12Uhr Daten vom Adapter:

brightsky.0.hourly.07.timestamp 
Tue Sep 16 2025 12:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)

Dieses Datum verwende ich auch im Skript als Input

brightsky.0.hourly.07.solar
0.367

Der Adapter kommt aber zu einem anderen Ergebnis

brightsky.0.hourly.07.solar_estimate
2.952

Adaptereinstellungen:

Spoiler

Modulbeschreibung im Skript:

Spoiler

const AREA_M2      = 36* 1.755 * 1.038;    // Fläche A in m²
const EFFICIENCY   = 0.20;  // Wirkungsgrad (z. B. 20% -> 0.20)
const ALPHA_DEG    = -10;     // Azimut der Fläche (0 = Süd, negativ Ost, positiv West)
const BETA_DEG     = 25;    // Neigung in Grad gegen Horizontal

Vielleicht sollte wir mal die Berechnungsmethode und Zwischenergebnisse vergleichen. Habe heute allerdings keinen Urlaub und bin geschäftlich ausser Haus. Sorry.