UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[klassisch]

@ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

@klassisch

Nein, man hätte unter hourly jeweils den Wert für diese Stunde und müsste selbst kumulieren - könnte natürlich auch einen datenpunkt mit Kumulation anbieten.

Ich meine hier:

Ah, ich glaube jetzt habe ich es verstanden. Zusätzlich zu den DWD Werten kämen dann noch die für mein Dach customized Werte mit der ganzen Geometrie.
Ich fände es praktisch. Derzeit rechne ich das intern in meinem Frickelskript - ohne diese Datenpunkte anzulegen. Aber eine Lösung von einem professionellen Adapterprogrammierer wäre natürlich immer besser als mein Gefrickel.

EDIT - dazu müsste ich aber die schreiblogik verändern, das geht nicht mal gerade so - also das kumulieren.

Ja, in dieser Richtung klemmt es bei mir auch gerade. Ich habe ja noch keinen netzdienlichen Algo. Ich mache das noch manuell. Dazu schreibe ich mit die prognostizierten Stundenwerte meiner Anlage als Sequenz in einen Datenpunkt. Der erzeugt dann die blaue Linie. Dann kann ich als Mensch grob abschätzen, wie ich heute einspeise bzw. den Akku lade.
Wenn dann die 08:00 Berechnung kommt, oder das Skript untertägig neu gestartet wird, dann werden die neuen Daten an das History json File hinten angehängt, was doof ist. Wenn ich das file vorher löschen lasse, wird auch das Vortags-File gelöscht. Wie gesagt, ein Gefrickel bei mir.

[klassisch]

@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

Habe das bisher nicht selber angegangen, da du für jede Stunde den mittleren Azimut, Elevation und solar mit dem Timestamp mappen müsstest, dann die trigonometrischen Berechnungen ausführst und das dann kumulierst

Ich mache das ja - aber halt nicht professionell sondern Laiengefrickel.
Dann schreibe ich die Daten sequentiell in ein history json, welches die Blaue Forecast-Kurve macht.
Für heute sieht das dann so aus:

[Homoran]

@klassisch
:+1:
Dann bist du schon weiter als ich!

[klassisch]

@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

@klassisch
Dann bist du schon weiter als ich!

Ja, Deine abgeschattete Tageskurve hat mich angespornt.
Bin aber noch nicht zufrieden wegen Mehrfachschreiben, Tageswechsel etc.
Gehe ich noch an, aber derzeite beobachte ich soll und ist.

[Homoran]

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

derzeite beobachte ich soll und ist.

aber schon auf hourly Basis!
Da wäre es natürlich schön die Estimate-Werte von @ticaki unter hourly zu haben und dein Skript zu füttern.
Ich würde es erstmal zur manuellen Plausibilitätsprüfung nutzen.

Zu mehr komme ich im Moment nicht

[ticaki]

@homoran

### **WORK IN PROGRESS**
- (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  

:)

Oh da wollte noch einer etwas - ok dann dauerts noch

[Homoran]

[OT]!!

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

am Ende des Tages war der Minderertrag nur 5,4% gegenüber der 05:00 Berechnung

da hast du bessere Vorhersage

oben heutige Vorhersagen in kWh, Unten Prozente Vorhersage erreicht von geszern

oder schlechteres Wetter gehabt. Hier war Wahlwetter ;-)

aber

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

mit Temperaturabhängigkeit! Das sieht etwas nach @Homoran schen Perfektionismus aus.
So viel Aufwand, werde ich nicht spendieren.

solltest du dir überlegen.
sieh dir das Datenblatt deiner Panels an. bei mir ist es knapp 1/2 Prozent Leistungsverlust je Kelvin Temperaturerhöhung am Panel.
Sehr schön zu sehen in der rechten Hälfte meiner Kurve.
Als es wechselnd bewölkt war kühlen die Panrls ab, kommt die Sonne durch gibt es überschießend Leistung bis die Panels wieder aufgeheizt sind.
[/OT]

[klassisch]

[OT]
@homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

mit Temperaturabhängigkeit! Das sieht etwas nach @Homoran schen Perfektionismus aus.
So viel Aufwand, werde ich nicht spendieren.

solltest du dir überlegen.
sieh dir das Datenblatt deiner Panels an. bei mir ist es knapp 1/2 Prozent Leistungsverlust je Kelvin Temperaturerhöhung am Panel.
Sehr schön zu sehen in der rechten Hälfte meiner Kurve.
Als es wechselnd bewölkt war kühlen die Panrls ab, kommt die Sonne durch gibt es überschießend Leistung bis die Panels wieder aufgeheizt sind.

Ich sage mal ganz frech: Das habe ich mir bei der Auslegung meiner Anlage schon überlegt. Hoch- und runter gerechnet.
Meine Anlage ist mit 30% Überbelegung. Der Installateur hatte einen 2. Wechselrichter angeboten - damals für einen hohen Preis. Den habe ich gestrichen. Damit kann ich im Sommer eh nicht alles nutzen und der Temperaturgang is mir deshalb meist "Wurscht".

Aufgrund der Eigenheiten meiner Anlage, kann ich den Verlust näherungsweise mitrechenen. 2024 waren es < 20 EUR verlorene Einspeisevergütung und 2025 bis gestern um 18 EUR. Die Stringaufteilung würde eine Aufrüstung ermöglichen, lohnt sich aber nicht und wäre im Winter sogar kontraproduktiv.
Und der Winter ist und bleibt unser Problem.

[Homoran]

@klassisch Du missverstehst die Anwendungsoption!

Wenn du für die Netzdienlichkeit eine Obergrenze nutzen willst (Ich hab da die im Solarspitzengesetz genannten 60% der PV Leistung genommen, auch wenn mich das nicht betrifft) so rechne ich so, dass die Prognose diese 60% nicht überschreiten darf. Inklusive Temperaturkorrektur!
Was natürlich nicht klappt :joy: wenn die Solarleistung stark schwankt

[klassisch]

[OT]
@homoran Ja, so weit denke ich noch nicht. Ich bin noch einfacher gestrickt. Wenn die regulative oder ökonomischne Notwendigkeit einer Begrenzung der Einspeiseleistung kommt, werde ich mich auf den WR verlassen.
Derzeit geht es mir lediglich darum, zu entscheiden, ob ich morgens auf die Ladung des Akkus verzichten kann und den Akku zur Reduzierung der Mittagsspitze nutzen kann.
Mein Akku ist halt kleiner und Netzbezug möchte ich vermeiden.

[ticaki]

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

[Homoran]

@klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

werde ich mich auf den WR verlassen.

das kann ich eben nicht :cry:
ich hab keinen Fronius

[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! :grin:
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