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

[Diginix]

@haus-automatisierung Bekommst du:
https://github.com/iobroker-community-adapters/ioBroker.pvforecast/issues/82

[JB_Sullivan]

Habe die 2.5.0 auf dem System und heute Morgen diese Fehlermeldung im Log gefunden. Instanz läuft aber einwandfrei und auch die Grafiken wurden erzeugt.

pvforecast.0
2023-01-13 09:47:12.064	error	Axios Error TypeError: Cannot read property 'ratelimit' of undefined

pvforecast.0
2023-01-13 09:47:04.648	error	Axios Error TypeError: Cannot read property 'ratelimit' of undefined

[haus-automatisierung]

@jb_sullivan Mh, die Meldung müsste aber schon "immer" da sein. Gucke ich mir an, danke.

[Latzi]

@haus-automatisierung
mit der 2.5.1 bleibt bei mir bei solcast die pvforecast.0.summary.JSONTable leer ([]). Die JSONTable der einzelnen Anlagen sind jedoch befüllt.
Brauchst du noch weitere Infos?

Edit: github issue ist erstellt: https://github.com/iobroker-community-adapters/ioBroker.pvforecast/issues/83

Edit vom edit (14.01.23 09:09): Nach Löschen der DP´s und kompletter Neuinstallation (Instanz und Adapter vorher gelöscht) läuft´s nun perfekt - issue geschlossen

[haus-automatisierung]

@latzi sagte in Test PV Forecast Adapter:

Nach Löschen der DP´s und kompletter Neuinstallation

Da sich bei den Datenpunkten nichts geändert hat, wäre das nicht notwendig gewesen. Einfach die Daten neu vom Service abholen (oder einen Tag warten) hätte auch gereicht.

[Diginix]

@haus-automatisierung 2.5.1 aktualisiert bei mir alle JSONTable ohne manuelle Eingriffe.

[haus-automatisierung]

@diginix Sollte auch so sein, wenn nach dem Upgrade einmal frische Daten vom Server geholt wurden.

[Diginix]

@haus-automatisierung Das macht er ja zwangsläufig durch Instanz Neustart nach Update.

[haus-automatisierung]

@diginix sagte in Test PV Forecast Adapter:

@haus-automatisierung Das macht er ja zwangsläufig durch Instanz Neustart nach Update.

Nein

[Diginix]

@haus-automatisierung Hm, bei mir mit solcast definitiv. Deswegen fliegen ja sofort alle Prognosewerte der Vergangenheit weg wofür es ja ein Feature request gibt. Aber ist ja auch egal. 2.5.1 läuft und das zählt.

[haus-automatisierung]

@diginix sagte in Test PV Forecast Adapter:

Hm, bei mir mit solcast definitiv.

Die Daten werden nur neu geholt, wenn sie mindestens eine Stunde alt sind. Wenn Solcast nachts die Daten geholt hat und Du tagsüber die Instanz neustartest, dann natürlich schon. Wenn Du aber 10x neustartest, dann trotzdem nur einmalig.

https://github.com/iobroker-community-adapters/ioBroker.pvforecast/blob/9149f96a37e2d352d1eeffec0c7d6c70df4ef572/main.js#L652

[WaldWieselchen]

@patrickwalther

@sputnik24 said in Test PV Forecast Adapter:

Heute mal eine perfekte Prognose, sowohl im Leistungsverlauf als auch im Ertrag (prognostiziert wurden 27,7 kWh, was in der Summe aber Zufall ist, weil für die Südseite wurden 22,7 kWh und die Nordseite 5,0 kWh prognostiziert, sprich für die Nordseite liegt die Prognose um 50% daneben, kompensiert damit zufällig den Fehler auf der Südseite.).

Hi @Sputnik24 ,
ich versuch mich auch gerade an so einer Darstellung von forecast + Produktion in Grafana.
Könntest Du mir bitte die queries etc. von dem dashboard geben?

Danke und Gruß
Michael

[Christoph1337]

@patrickwalther Moin moin,
ich hätte ein paar Ideen für deinen tollen Adapter.

1. Da einige APIs nur eine bestimmte Anzahl von Anfragen am Tag erlauben währe es toll diese auf die Sonnezeit zu beschränken. Mir ist schön öfter aufgefallen, dass solcast im verlauf des Tages seine Kurven korrigiert. Wenn man nun die 10 Anfragen erst ab Sonnenaufgang verbraucht sind mit Glück genauere Daten zu erwarten.
2. rotierende API Keys. Es ist zwar nicht im Sinne des Erfinders, aber man könnte für Anbieter wie solcast einfach drei API-Keys hinterlegen. So hätte man nicht mehr das Limit von 10 Requests.
3. Es gibt ja eine neue API von SolarPredictionAPI. Leider habe ich die bei mir noch nicht zum laufen gebracht. Da hier Kosten entstehen, wenn 12 Requests überschritten sind wäre ab diesem Punkt ein automatischer STOP ganz gut. So wundert man sich nicht plötzlich über die Kosten von 0,15$ pro weiterem Request. Natürlich könnte man das ganze auch mit Punkt 1 und 2 vereinen.
4. Scheduler für Requests genauer einstellen. z.B. alle 2 Stunden. Vielleicht so wie in einem cron ein Feld hinzufügen.

Beste Grüße

[oxident]

@christoph1337 Also bei dem einstellbaren Abfrageinterval bin ich voll bei Dir. Mir ist auch oft aufgefallen, dass die Vorhersagen teilweise arg daneben liegen (und das Wetter in der Tat schlechter als erwartet war).

[BananaJoe]

@Christoph1337 sagte

rotierende API Keys. Es ist zwar nicht im Sinne des Erfinders, aber man könnte für Anbieter wie solcast einfach drei API-Keys hinterlegen. So hätte man nicht mehr das Limit von 10 Requests.

Das wäre ein ein Missbrauch der kostenlosen Bereitstellung durch den Anbieter. Wenn du unbedingt die Daten so oft brauchst und es der Anbieter sein soll muss man eben bezahlen.

[cash]

Welcher Wert muss denn bei Spitzenleistung rein bei einen Balkonkraftwerk? 600 0der 0.6. Ich habe 600 genommen aber die Werte die da rauskommen sind nur halb so groß wie die, die ich bekomme wenn ich einfach die URL von forecast.solar direkt eingebe und dort als Paramter 600 verwende. Die Werte aus der URL sind auch deutlich näher an dem dran was man mit so einer Anlage erreichen kann an meinen Standort

[cash]

ok ich muss 0.6 eingeben.

Hat jemand eine Idee wieso die Daten so unterschiedlich sind?

Wenn ich die URL https://api.forecast.solar/estimate/:51.xxxx/:8.xxxx/:45/:-10/:600

eingebe erhalte ich erstmal als Adresse genau meine Adresse. Passt also. Als watt hous day bekomme ich 3412 Wh

Der Adapter zeigt mir 2,048 kWh an. Also knapp 1400 Wh weniger? Die Realität ist näher an den Daten die ich per URL bekomme

Im Adapter habe ich nur die Neigung von 45 eingestellt, die -10 und 0.6. Die Koordinaten sind aus ioBroker. Genau die habe ich auch in meiner URL verwendet

[MarcoH]

Hallo zusammen,

ich versuche mich auch gerade an der visuellen Darstellung der "forecast Daten" in Grafana (zur späteren Darstellung in Lovelace), leider will mir das noch nicht gelingen. Vielleicht hab ich es auch überlesen, aber ich zu der Thematik keine wirklich Anleitung gefunden.

Mein derzeitiger Stand sieht so aus:
-> JSONTable wird in InfluxDB geloggt (ggf. liegt hier schon der Fehler?)
-> über Transformationen (siehe unten) kann ich mir diese Tabelle in Grafana anzeigen lassen:

So weit so gut...Aber wie komme ich von der Tabelle zu einem Graph?

Dies sind die genutzten Transformationen:

Ich hoffe, hier kann mir jemand weiterhelfen.

Gruß
Marco

[BananaJoe]

@marcoh du kannst im Adapter doch direkt die Influx-Datenbank angeben - dann schreibt er die Werte - soweit ich es verstanden habe - doch direkt in die Datenbank und du kannst diese nutzen wie jeden anderen aufgezeichneten Wert auch.

[MarcoH]

@bananajoe Die habe ich auch angegeben, finde aber in Grafana kein Measurement mit den Daten