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

[klassisch]

@ticaki sagte in Betatest Bright Sky v0.6.x:

.... was ich alles breaking mache :)

breaking?

• (ticaki) Customisable update interval for Daily (expert)

Was ist der Default Value für "update interval for Daily (expert)". Was passiert wenn ich nirgendwo etwas eingebe?

[ticaki]

@klassisch sagte in Betatest Bright Sky v0.6.x:

@ticaki sagte in Betatest Bright Sky v0.6.x:

.... was ich alles breaking mache :)

breaking?

Breaking bedeutet inkompatibel zur Vorversion. Das entfernen der forHomoran states ist ein break - wenn ich die role von sunset/sunrise ändere ist das ein anderer break. Bei letzterem findet der nspanel Adapter die states nicht mehr, bis ich es anpasse

• (ticaki) Customisable update interval for Daily (expert)

Was ist der Default Value für "update interval for Daily (expert)". Was passiert wenn ich nirgendwo etwas eingebe?

Damit kannst du den 5/18/0 Uhr interval in einen ändern der alle X Stunden aktualisiert - Option erscheint nur wenn expert an ist, Verwendung ist nicht empfohlen. Ah, da fällt mir ein das ich im Beschreibungstext 0=off noch in 0=default interval ändern wollte. :)

Dieses Release ist nicht im latest

[Bushveld]

Hallo
(1) bisher war brightsky.0.daily.00.solar_estimateForHomoran immer genauer an meinen echten Werten als brightsky.0.daily.00.solar_estimate
Wird hier für solar_estimateForHomoran anders gerechnet als für solar_estimate? Wenn ja dann wäre ein mehr sprechender Name und umbenennen besser.
Könntest du bitte, wenn anders gerechnet wird, den Unterschied beschreiben? Derzeit nutze ich in der Tat solar_estimateForHomoran da dieses die für mich passendsten Werte liefert.

(2) Übrigens, die "ForHomoran" Objekte im ioBroker wurden nicht gelöscht mit dem Update auf die 1.0.0-beta-0.

(3) Bei den Einstellungen schreibst du:
Verwende benutzerdefiniertes Intervall für Tagesübersichten (0 aus) - nicht empfohlen

Wie wäre es mit:
Verwende ein benutzerdefiniertes Aktualisierunsintervall für Tagesübersichten.
Empfehlung: (0 aus) die Daten werden dann um 0:00,5:00 und 18:00 Uhr aktualisiert.

(4) Frage: warum ist die das Nachführen der Tagesübersichten z.b. in einem stündlichen Intervall nicht empfohlen?

(5) In brightsky.0.daily.00.solar_estimate (Solar Estimate daily total) sah ich um 23:04 Uhr einen Wert von 0 kWh um 21:43 Uhr stand hier noch: 20,741 kWh
Da es ein daily total ist hätte ich erwartet den Summenwert des Ertrags zu sehen (bis 24:00 Uhr) was hier ~22 kWh sein sollte. Das Updateinterval habe ich auf 1h gesetzt.

[ticaki]

1. wird entfernt daher wieso noch drüber sprechen.
2. Ja, die werden zu früh im Code entfernt - da weiß der Adapter noch nicht das es sie gibt :D
3. ist nicht empfohlen - drüber steht wie die Intervalle sind - das hat keiner einzustellen, sonst hätte ich es nicht versteckt.
4. Weil es in meinen Augen quark ist eine tägliche Übersicht stündlich zu aktualisieren und unnötige Last auf den Servern erzeugt für 99% der Anwendungen. Ausnahme deine Anwendung
5. Deshalb 5,18,0 damit ich keine Probleme mit Zeitzonen bekomme. Denke mal das es ein Zeitzonen problem ist

[Bushveld]

Hallo @ticaki
zu 1) brightsky.0.daily.00.solar_estimateForHomoran liefert bessere Werte als brightsky.0.daily.00.solar_estimate wird hier anders gerechnet?
Wenn ja würde ich gerne wissen was anders gemacht wird und ggf. vorschlagen den Wert als eine weitere Option für solar_estimate unter einem besseren Namen zu erhalten.

zu 4) halte ich im Auge und liefere dann mal eine Übersicht der Effekte, wenn das für dich und andere ok ist kannst du die beta ja mal zwei, drei Wochen so stehen lassen dann kann der Effekt auch mit Zahlen belegt oder entkräftet werden. ich bin der letzte der sinnlose Ressourcenvernichtung gut findet

zu 5) ist mir noch nicht erklärbar, ich beobachte mal

[ticaki]

@Bushveld

1. Da wurde AFAIK nichts anders gemacht, war der selbe Code nur halt um ausschließlich 5 Uhr.
2. KA wieviele irgendwann den Adapter benutze - wenn 1 Person stündlich das wetter abfragt ist das wurscht - wenns tausende machen sieht man dass dann schon in der Lastauswertung. :)

const dataDay = Math.floor(new Date(item.timestamp).getTime() / (24 * 60 * 60 * 1000));

Da wird berechnet obs in 00, 01 usw solll - wird die Zeitzone nicht berücksichtig. Mal gucken wie ich das am besten mache.

[ticaki]

1.0.0-beta.1 (2025-11-16)

• (ticaki) fixed: states/timezone/translation

Jetzt gibts erstmal nur "falsche" Ergebnisse am Tag der Zeitumstellung.

[Bushveld]

Hallo @ticaki irgendwas stimmt da nicht in brightsky.0.daily.00.solar_estimate (Solar estimate daily total) steht aktuell 0 kWh. Beim daily total würde ich damit rechnen dass die Werte bis 24:00 Uhr aufsummiert dort stehen.
Das scheint aber nicht der Fall zu sein. könntest du bei Gelegenheit den Wert bitte mal prüfen?
Diesen Wert suche ich die prognostiziert Summe des Solarertrags.
Mit einen stündlichen Updateintervall müsste sich die Prognose zusammensetzen aus den realen historischen Werten und den zukünftigen Reststunden des Tages als reine Prognose.

[ticaki]

so sieht es bei mir aus

[Bushveld]

@ticaki

Die Wert WAREN über den Tag gefüllt und sind dann runter auf 0 ???

Wir sprechen hier über brightsky.0.daily.00.solar_estimate also 00 hast du das angeschaut?
Alle Werte > 00 sind bei mir noch gefüllt.

[ticaki]

Natürlich sind das oben die Werte von brightsky.0.daily.00

Bitte beachte das die Daten je nach Wetterstation unvollständig sein können.

[Bushveld]

Hallo @ticaki, ich bin mir recht sicher dass es nicht an unvollständigen Daten liegt.
Ich habe zum Testen das Update-Intervall auf 1h gesetzt.
Der Wert von solar_estimate ist relativ realistisch gestartet war um die Mittagszeit passend und seither sinkt der Wert wieder. Das kann so nicht stimmen, laut der Beschreibung ist das ein daily total. Durch die stündlichen update kann es immer zu Anpassungen kommen, aber nicht zu einem Sinken bis auf 0 so wie es gestern der Fall war und sich heute abzeichnet.

[ticaki]

@Bushveld
Könnte es wenn die verwendete Station keine historisierten Daten ausliefert. Gib mir mal die stationid von der die Daten kommen.

Btw mein Screenshot da oben war zeitnah erstellt zu dem geschrieben Beitrag, also kann’s nicht an der Rechnung liegen.

Ich gucke es mir nochmal an

EDIT: Hab jetzt nochmal rein geguckt und bei mir stimmts - du kannst gerne mal debug an machen und den Adapter starten und dann in dem log das mit Processing daily data for day 0: gucken was bei solar steht sieht bei mir so aus:

"solar":[0,0,0,0,0,0,0,0,0,0.007,0.041,0.055,0.087,0.155,0.123,0.103,0.079,0.037,0,0,null,null,null,null]

[Bushveld]

Hallo vielen Dank für den Hinweis, evtl. sind da in der Tat null werte gekommen. Das kann ich nicht ganz sicher sagen da es verschiedene source_id s gitb über den Tag.
Ich habe nur die den Umkreis vergrößert in der Hoffnung dass bessere Stationen gefunden werden. Das habe ich mir im Code noch nicht angesehen wir du das zauberst.

Bei meinem aktuellen Lauf bekomme ich dann das folgende Array zurück:
"solar": [ 0, 0, 0, 0, 0, 0, 0, 0.001, 0.014, 0.042, 0.09, 0.131, 0.107, 0.196,
0.119, 0.037, 0.01, 0, 0, 0, 0, 0, 0, 0 ],

Wenn ich es richtig verstehe dann werden in https://github.com/ticaki/ioBroker.brightsky/blob/main/src/main.ts#L409-L427 die Werte summiert dann komme ich 0,747 kWh/m² bei 30m² mit 20% wirkungsgrad komme ich auf ~4, kWh was ungefähr passt.

Nun steht aber in solar_estimate 14,2 kWh wie kommt das dann zustande? Ich muss zu geben dass ich nicht mehr im Code gesucht habe, muss morgen früh raus :-(

[ticaki]

Da müssten wir schauen ob du vielleicht was im Admin falsch eingegeben hast.

Die Rechnung findest du ganz unten im Code Zeile 2128 - 2 Funktionen

[Bushveld]

Hallo @ticaki
nun habe ich mich durch die gesamte Berechnung gewühlt und 4 Pannel, mit korrektem Ort, Ausrichtung, Fläche, Wirkungsgrad und 2 Wechselrichtern nachgerechnet mit mehreren Array. Die Werte sind die gleichen wie gestern.
Zuerst einmal: jemehr ich vom Code verstanden habe desto mehr hast Spaß gemacht. Ich mag nicht so superlativisch daherkommen, aber sagen will ich doch dass ich bright-sky nun richtig gut finde! Danke Dir!

Nun zu den Ergebnissen: ich bin beim Rechnen mit einem Korridor von +/- 5% an die realen Werte rangekommen.

Hier mal ein paar Arrays:
09:00 "solar": [0,0,0,0,0,0,0,0.005,0.036,0.131,0.219,0.278,0.3,0.269,0.192,0.097,0.017,0,0,0,0,0,0,0]
14:00 "solar": [0,0,0,0,0,0,0,0.005,0.101,0.324,0.361,0.387,0.381,0.264,0.189,0.097,0.017,0,0,0,0,0,0,0]
17:00 "solar": [0,0,0,0,0,0,0,0.005,0.101,0.324,0.361,0.387,0.381,0.33,0.265,0.159,0.019,0,0,0,0,0,0,0]
21:00 "solar": [0,0,0,0,0,0,0,0.005,0.101,0.324,0.361,0.387,0.381,0.33,0.265,0.159,0.027,0,0,0,0,0,0,0]

Man sieht schön wie die historischen Werte konstant bleiben und zwangsläufig die verbleibende Prognose immer genauer wurde. Die +/- 5% Abweichungen stammen aus Differenzen der vom DWD gelieferten Werte. Das ist zum Teil der Tatsache geschuldet dass ich weiter entfernte Stationen zum Testen nehmen musste um vollständige Arrays mit Werten zu erhalten.

Diese unvollständigen Arrays waren dann scheinbar auch die Ursache für die zuvor von mir beobachteten abfallenden Werte.

Die Logik um die Backupstation habe ich mir noch nicht angesehen. Wäre es evtl. einen Überlegung wert noch einen Fehlerprüfung einzubauen wenn eine Station unvollständige Daten liefert und damit unbemerkt die Prognosewerte falsch ausweist??

Im Code habe ich ein paar Kleinigkeiten gesehen (nur formaler Kram, Kommentare, Variabelnnamen, Sprachmix... ) wenn du magst kann ich im Dez ein PR schicken. Ich bin die nächsten Tage leider unterwegs und kann vermutlich nicht viel machen.

Noch mal vielen Dank!
Michael

[ticaki]

Wenn man den Umkreis benutzt, sollten bei unvollständige Daten andere Station einspringen, hab das aber auch noch nicht so ganz verstanden.

[Homoran]

@ticaki sagte in Betatest Bright Sky v0.6.x:

sollten bei unvollständige Daten andere Station einspringen,

ich fürchte das klappt nicht.

[Bushveld]

@Homoran sagte in Betatest Bright Sky v0.6.x:

@ticaki sagte in Betatest Bright Sky v0.6.x:

sollten bei unvollständige Daten andere Station einspringen,

ich fürchte das klappt nicht.

Habe noch nicht den ganzen relevanten code Teile durch, befürchte aber das @Homoran Recht hat.
Ich bin noch eine Woche unterwegs dann kann ich noch mal eintauchen

Anm. Die neue 1.x alpha arbeitet genial gut !

[ticaki]

Das ersetzt erfolgt vom api-server - aber wie gesagt ich hab keine ahnung wie das funktioniert