Plugin: PV Solcast (Forecast für PV Anlagen)

[hismastersvoice]

Die stündlichen Werte sind UTC, richtig?
Die "afteroon" bzw. "morning" Werte summieren einfach die hourly-Werte von 0-11 bzw. 13-23 auf, richtig?
Damit entspricht das dem Vormittag/Nachmittag nach UTC und nicht nach MEZ bzw. MESZ.

Sehe ich das so richtig?

Die Werte die von Solcast kommen, sind UTC.
Wenn der Loxberry die richtige Zeitzone eingestellt hat, wird die Zeitverschiebung mit einbezogen.
Morning ist bis Wert 0-12 Uhr , afternoon ist dann ab 13-23 Uhr.

Und noch eine blöde Frage:
Der hourly Wert zB "hourly_10" ist die Stunde ab 10 bis 11, richtig?

Ja, da wie oben beschrieben der Versatz einbezogen ist, ist es die Leitung die ab 10 Uhr bis 11 Uhr erzeuget wird

Beispiel von mir heute...

s_sum_hourly_td_w_7=0
s_sum_hourly_td_w_8=10.9
s_sum_hourly_td_w_9=491.5
s_sum_hourly_td_w_10=1105.4
s_sum_hourly_td_w_11=1803.4
s_sum_hourly_td_w_12=2064.1
s_sum_hourly_td_w_13=2106.9
s_sum_hourly_td_w_14=2063.5
s_sum_hourly_td_w_15=1487.3
s_sum_hourly_td_w_16=686.7
s_sum_hourly_td_w_17=48.2
s_sum_hourly_td_w_18=0

Um 7 Uhr ist es noch nicht hell genug, also 0Wh
Um 18 Uhr ist es schon wieder dunkel also auch 0Wh

Wenn es UTC wäre, dann würde es aktuell eine Stunde Verschiebung geben.
Wir haben es jetzt 9:35 Uhr und es wurden 340Wh erzeugt, errechnet wären es 326Wh. Also gar nicht so daneben

[flump]

Vielen Dank für die schnelle Antwort!
Dann werd ich mich mal daran machen die Werte sinnvoll in Loxone zu verwenden.
Wärmepumpe und Waschmaschine :-)

[Noschvie]

Habe einen LoxBerry 2.2.2.2 mit Plugin Version 0.6.1 in Verwendung, weiß nicht seit wann (autom. Update)

Die Abfragen klappen seit geraumer Zeit einfach nicht mehr, API Key erneuert, bringt keine Verbesserung.

2025-02-12 23:00:01 - Hourly-Cron, Hour not set for Request - System 1
2025-02-13 00:00:01 - Hourly-Cron, Hour not set for Request - System 1
2025-02-13 01:00:01 - Hourly-Cron, Hour not set for Request - System 1
2025-02-13 02:00:01 - Hourly-Cron, Hour not set for Request - System 1
2025-02-13 03:00:02 - Hourly-Cron, Hour not set for Request - System 1
2025-02-13 04:00:02 - Hourly-Cron, Hour not set for Request - System 1
2025-02-13 05:00:02 - Hourly-Cron, Hour not set for Request - System 1
2025-02-13 06:00:02 - Request by cron - System 1
2025-02-13 06:00:03 - "Code: 404 \/ Client Error: Not Found"
2025-02-13 06:00:03 - {"url":"https:\/\/api.solcast.com.au\/rooftop_sites\/\/forecasts?​

[Noschvie]

@hismastersvoice eine Idee dazu?

[Noschvie]

Seit wann gibt es die Version 0.6.1 ? Im wiki steht leider kein Release Datum dabei

[pgo]

Ein herzliches Hallo an Alle,

ich habe ein Frage zur Installation vom Plugin bzw. grundsätzlich zu Loxberry:

Ist das Plugin auf DietPi angewiesen oder kann es auch auf einer anderen Linux distribution laufen?

Der Hintergrund meiner Frage: ich realisiere mit einer Phidget SBC4 eine Redoxmessung und habe somit bereits ein SBC zur Verfügung, und möchte mir zusätzliche Hardware für Loxberry sparen. Ich bin im Linuxbereich nicht sehr erfahren, wenn es grundsätzlich nicht möglich ist werde ich mich um Alternativen umschauen müssen.
Auf der SBC4 läuft Debian, könnte Loxberry dort auch in einer VM ausgeführt werden?
danke

[hismastersvoice]

Wie Plugin schon vermuten lässt, ist es auf Loxberry angewiesen und Loxberry wiederum wird auf DietPi installiert.
Also nein, das wird nicht ohne Anpassungen gehen.

[Joh S.]

fec
Joneass
SehlingS
läuft es bei euch halbwegs über die Umweg-Lösung mit http?

Ich hab das Problem, dass Solcast IMMER ab 7 Uhr stündlich Daten holt und zwar völlig egal wie ich die Schalter für "Automatische Timer" und "erster Abruf bei Mitternacht" einstelle. (7 Uhr ist gar nicht ausgewählt) (natürlich schon de- und neu installiert)
Dementsprechend ist bei 2 Anlagen dann schon vor Mittag das Limit erreicht.

Wenn ich jetzt per http abrufen würde bessert sich die Situation ja nicht -> dass das Tool zu oft die Daten holt bekomm ich nicht abgeschaltet und http Abrufe erzeugen ja nur zusätzliche Abfragen - oder wie genau habt ihr das über http gelöst?

[Joneass]

Guckst Du #384

[Joh S.]

Ach Mist ähnlich wie bei mir aber doch irgendwie anders. Wobei: ich glaube zu Anfang war es bei mir auch so! Mittlerweile kann ich aber tatsächlich nicht mal mehr manuell abrufen wenn "too many request" kommt. Es ist zum Mäuse melken. Wie kann ich rausfinden in welcher Datei bzw. in welchem Ordner die Abrufzeiten hinterlegt sind - dann würde ich versuchen das manuell mal im Code checken 🤔

[hismastersvoice]

Jede volle Stunde wird per Cronjob abgefragt ob die aktuelle Stunde gesetzt ist.
Wenn ja, dann Abfrage, wenn nein, dann weiter...

[Noschvie]

Spät aber doch bin ich nun dahintergekommen, dass:
.) Plugin v 0.5.1 lange Zeit gut funktioniert hat
.) Plugin v 0.5.1 wurde automatisch upgegraded auf v 0.6.1, obwohl es hierbei breaking changes gibt. Zeitpunkt des Updates unbekannt, Release Datum der 0.6.1 unbekannt
.) die Solcast API hat sich geändert, Zeitpunkt unbekannt
.) die Forecast Werte sehr ungenau / unbrauchbar geworden sind
.) bestimmte Parameter im GUI der v0.6.1 gegenüber der Vorversion nicht mehr enthalten sind
.) es im Plugin nur noch zu Fehlern gekommen ist

Nun habe ich mit einem Test LoxBerry die Zusammenhänge klären können. Eine mühsame G'schicht...

[hismastersvoice]

Autoupdate hast du schon selber eingeschaltet am Loxberry

Das Plugin wäre eh nicht mehr funktionell gewesen, da wie du selber erkannt hast die API geändert wurde.
Es wurden keine Werte mehr über die alte Abfrage geleifert.

Der Forecast ist so gut und schlecht wie er immer war. Winter eher ungenau, rest des Jahres bei mir recht genau.

Keine Ahnung worüber du dich hier beschweren willst.
Ich sehe keine Verpflichtung eines Plugin-Entwicklers sich mit jedem persönlich in Kontakt zu setzen

Bei meinen Systemen die ich in Betrieb habe / betreue, kommen keine Fehler, also auch hier für mich nicht nachvollziehbar.

[Joneass]

Hat jemand die Stündlichen ForeCast Werte in Loxone visualisert also als Diagramm?
In Grafana habe ich das zwar aber auf Grafana kann/will ich nicht von unterwegs zugreifen, da meine Syno nicht öffentlich im Netz hängt.

Habe mir die Frage gestellt ob das irgendwie über Zählerbausteine, Statistiken oder so funktioniert.
Absolute Spielerrei, dennoch Nice to have

[Hoga]

Hat sich bei dem Plugin in der letzten Zeit etwas verändert?
Nachdem mir jetztes Monat die Stromrechnung durch automatischen laden der Batterie explodiert ist, scheinen es die Werte zu sein die vom Plugin kommen.

Die Logik ist simple, wenn am nächsten Tag weniger als 30 kw/h runter kommen, dann bitte die Batterie aus dem Netz laden in der Nacht. Die Logik hatte ich nicht verändert. Jetzt ist mir allerdings aufgefallen, das die Werte für den nächsten Tag erst um 6 Uhr früh kommen. Davor sind sie null, das ist gerade die Zeit wo ich lade.

Ich verwende:
solcast_1_total_td_kw
solcast_2_total_td_kw

Version ist 0.6.1

[hismastersvoice]

Habe gerade in die Logs der letzten Tage geschaut, bei mir wird pünktlich 0 Uhr ein Abruf ausgeführt.

Es hat sich seit der API Umstellung von Solcast am Plugin auch nichts geändert.

[Noschvie]

Hast du die API Umstellung mitbekommen und entsprechend durchgeführt? Was steht in deinen Logs?

[Hoga]

Nein hab ich nicht, wa sist zu tun?

[Noschvie]

Willkommen im Club :-) siehe oben #396

Grob gesagt: Du musst dir im Solcast Web eine ResourceId anlegen und diese im Plugin (v 0.6.1) eintragen.

[Hoga]

Noschvie Gibt es dazu ein howto? Nur mit der Info ist mir jetzt nicht klar, was ich da machen muss. Ich bekomme ja Daten und sie scheinen soweit OK zu sein, ich bekomme sie zu spät

[Noschvie]

Wenn du Daten bekommst, ist das kein Problem der geänderten API. Dann hast du eh schon eine ResourceId erstellt und diese in Verwendung.
Bezüglich "zu spät" habe ich keine Idee.
Was steht in den Logs? Timezone korrekt?

[Hoga]

Wie ich gesagt habe, gibt es ein howto? Ich hab gar nichts gemacht, und finde keine Info dazu was ich genau machen soll. Das Log sieht OK aus, ausser diese Meldungen vom cron die immer wieder kommen

{"pv_estimate":0,"pv_estimate10":0,"pv_estimate 90" :0,"period_end":"2025-03-13T23:00:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-13T23:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T00:00:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T00:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T01:00:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T01:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T02:00:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T02:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T03:00:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T03:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T04:00:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T04:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0,"perio d _end":"2025-03-14T05:00:00.0000000Z","period":"PT30M"},{"pv_estim ate":0,"pv_estimate10":0,"pv_estimate90":0.0068," p eriod_end":"2025-03-14T05:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":0.0956,"pv_estimate10":0.0273,"pv_estimate90 " :0.1776,"period_end":"2025-03-14T06:00:00.0000000Z","period":"PT30M"}]}
2025-03-12 08:00:01 - Hourly-Cron, Hour not set for Request - System 1
2025-03-12 09:00:02 - Hourly-Cron, Hour not set for Request - System 1
2025-03-12 10:00:01 - Hourly-Cron, Hour not set for Request - System 1
2025-03-12 11:00:02 - Hourly-Cron, Hour not set for Request - System 1
2025-03-12 12:00:01 - Request by cron - System 1
2025-03-12 12:00:07 - "Code: 200 \/ Successful: OK"
2025-03-12 12:00:07 - {"url":"https:\/\/api.solcast.com.au\/rooftop_sites\/d92f-2624-ab3c-d07f\/forecasts?format=json&api_key=d2xxxxxxxoogWv-kWw7i3kentxfeII3","content_type":"application\/json; charset=utf-8","http_code":200,"header_size":883,"request_s ize ":151,"filetime":-1,"ssl_verify_result":0,"redirect_count":0,"tota l_ time":5.869522,"namelookup_time":0.055965,"connect _time":0.060065,"pretransfer_time":0.076714,"size_ upload":0,"size_download":11727,"speed_download":1 998,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":5.869061,"redirect_time": 0, "redirect_url":"","primary_ip":"xyxxx", "cer tinfo":[],"primary_port":443,"local_ip":"192.168.1.39"," loc al_port":57888,"http_version":3,"protocol":2,"ssl_ verifyresult":0,"scheme":"HTTPS","appconnect_time_ us":75985,"connect_time_us":60065,"namelookup_ti me _us":55965,"pretransfer_time_us":76714,"redirect_ t ime_us":0,"starttransfer_time_us":5869061,"total_t ime_us":5869522}
2025-03-12 12:00:07 - {"forecasts":[{"pv_estimate":2.1472,"pv_estimate10":1.3122,"p v_e stimate90":3.019,"period_end":"2025-03-12T11:30:00.0000000Z","period":"PT30M"},{"pv_estim ate":2.9977,"pv_estimate10":1.5621,"pv_estimate90 " :5.3073,"period_end":"2025-03-10000

[Hoga]

Noschvie Gibt es dazu ein howto? Nur mit der Info ist mir jetzt nicht klar, was ich da machen muss. Ich bekomme ja Daten und sie scheinen soweit OK zu sein, ich bekomme sie zu spät

Bei mir scheinen jetzt auch die Werte falsch zu sein, sie ändern sich nicht mehr.

Kann vielleicht irgendwer kurz erklären, was bei dieser API Änderung genau zu tun ist? Welche Ressource muss ich generieren und WO im Solcast Webbereich? Ich sehe keinen Punkt, und die Werte APIkey sind noch immer die selben die auch al Loxberry eingetragen sind

[Hoga]

Gibt es irgendjemand der helfen kann?
Anscheinend muss man nach der API Änderung was machen, wa sgenau will aber keiner sagen

[Karl Napp]

Servus, Hoga und @hismastersvoice,
das Wiki ist leider seit gestern nicht erreichbar wg. Serverumzug.
Ich habe PV Solcast ganz frisch installiert und kenne auch keine bisherige Version. Mir sind die Begrifflichkeiten noch etwas unklar.
Ist es richtig, dass ich in PV Solcast im Feld 'API Key' die komplette URL eintrage, die ich in Solcast unter 'API' finde?
Bsp.: https://api.solcast.com.au/rooftop_s...ts?format=json (statt xxxx steht hier natürlich mein echter Wert)
Und ist es weiter richtig, dass ich in PV Solcast im Feld 'Rooftop ID' die 'Resource ID' aus Solcast eintrage?
Bsp.: 7ee1-4c59-0561-xxxx (statt xxxx steht hier natürlich mein echter Wert)
So hab' ich's gemacht. Im Loxberry unter MQTT erhalte ich jede Menge 'solcast_*'-Felder. Aber nur die Felder 'solcast_sum_hourly_top4_td_hour_1', 'solcast_sum_hourly_top4_td_hour_2' und 'solcast_sum_hourly_top4_td_hour_3' enthalten Werte, und zwar immer 13, 22 und 21.
Was mache ich falsch?

[hismastersvoice]

Keine URL im API eintragen, nur den API Key selber den du von Solcast bekommst bzw. im Profil auch selber generieren kannst.
Rooftop ID stimmt so.

[Karl Napp]

Aah, die angezeigte API-URL wird überhaupt nicht benötigt.
1. in solcast.com unter Benuztername/Your API-Key wird der API-Key angezeigt.
2. die Resource ID ist die Rooftop ID
Jetzt kommen Werte. Danke dir.

[Hoga]

Ich habe die ID und API key drinnnen. Was ist genau der Unterschied zu vor der API Umstellung? Was mich verwirrt hat ist die Ausssage, ich muss eine neue Ressource generieren.

[hismastersvoice]

Der Uneterschied ist einfach das die Werte jetzt direkt in Solcast eingetragen werden müssen, und nicht mehr über die Abfrage URL mitgegeben werden.