Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[haus-automatisierung]

@ostseeskipper sagte in Test PV Forecast Adapter:

Das Ausrechnen könnte man mit Max(WR Leistung machen).

Leistung ist leicht. Aber was ist mit der errechneten Energie? Wenn für 13 Uhr z.B. 3kWh zurückgeliefert wird, dann kann ich das ja nicht einfach prozentual kürzen. Ich weiß ja nicht, ob und wie lange die Leistung über 10kWp war.

[duejo]

Guten Morgen, zunächst vielen Dank für die Arbeit an diesem gelungenen Adapter...Ich teste gerade V2.2.0, Instanz 0 mit Prognose von Forecast.solar, Instanz 1 mit Prognose von Solcast, beides die kostenfreie Version, identische PV-Anlagendaten.
Kannst Du bitte den Datenpunkt "pvforecast.x.plants.pv.energy.now" mal anschauen? In der Instanz 0 erhalte ich nachvollziehbare, zur Anlage passende Werte, ich erkenne das "aufaddieren" über den Tag. Ist für mich ok.
In der Instanz 1 (mit solcast-Prognose) passen die Werte nicht zur Anlage, ich erkenne kein aufaddieren. Stattdessen kann ich eine Glockenkurve erkennen, die aber von ihrer überdeckten Fläche, die m.E. die Tagesprognose darstellen sollte, nicht zur Anlage passt. Hier ist m.E. etwas faul. Könntest Du das bitte checken?
Die Datenpunkte "pvforecast.x.plants.pv.energy.today" liefern nachvollziehbare Prognosen, wobei Solcast in meinem Test näher an der Realität ist.
Danke.

[BananaJoe]

@haus-automatisierung sagte in Test PV Forecast Adapter:

@ostseeskipper sagte in Test PV Forecast Adapter:

Und noch eine Frage an die Entwickler zum Schluss: Ist geplant auch eine SQL Instanz als Alternative zu Influx einzubinden?

Wäre eigentlich fix implementiert. Die Frage ist nur, ob SQL die Datensätze auch aktualisiert, wenn man den gleichen Timestamp für einen Schlüssel nochmal sendet. Würde mich wundern wenn dem so wäre - deswegen gibt es das momentan nicht.

Damit habe ich mich schon beschäftigt, ich nutze den PV-Forecast-Adapter ja mit SQL:

https://forum.iobroker.net/topic/55463/sql-sendto-problem-storestate-vs-update

Der Ziel-Datenpunkt muss aktiviert sein. Also bei einem Datenpunkt die SQL-Aufzeichnung aktivieren und dann auch mindestens einmal einen Wert im Datenpunkt schreiben, erst dann gibt es die notwendigen Datenpunkteinträge mit denen dann auch sendTo etc. arbeiten ... daran habe ich damals lange gesucht ...

[ostseeskipper]

@bananajoe
Ich habe das mit SQL mehr als 2x gelesen ... und bin verwirrt bzw. klingt kompliziert .... muss es wohl erst mal sacken lassen.
Auch funktioniert bei mir das JSON Diargramm von Materialdesign nur mit Balken, egal ob ich auf Line umstelle.
Dachte es geht einfacher.

[BananaJoe]

@ostseeskipper am einfachsten wäre es wenn @haus-automatisierung das wieder in seinen Adapter aktiviert.
Nachtrag: Weiter oben beschreiben ich eine Blockly-Lösung wo ich das gemacht habe.

Ich hab auch eine Weile für die Lösung gebraucht, und ja, die ist überhaupt nicht einfach. Mein jetziger Stand ist sogar noch um einiges komplexer da ich nicht mehr alles Lösche wenn neue Daten reinkommen.

Man könnte das vereinfachen und automatisieren - was aber alles hinfällig wäre wenn es der Adapter direkt macht, deshalb habe ich das bisher keine weitere Mühe reingesteckt.

[ostseeskipper]

@bananajoe
Stelle mir immer die Frage was soll eigentlich rauskommen.

Ne Prognose, ja ok und dann.
Klar, was damit steuern, wie z.B. "prognosebasiert laden" aber dann kommt schon die Frage wie zuverlässig ist die Prognose, also ist es zum
Vergleich und zur Abweichung nicht weit.
Mir würde da einfallen in den Adaptereinstellungen zu jedem WR einen Datenpunkt zu benennen in den die IST Werte drin sind dann über die History Instanz(SQL) in das JSON mit reingeplottet und die Differenzen errechnet werden.

[haus-automatisierung]

@bananajoe sagte in Test PV Forecast Adapter:

Der Ziel-Datenpunkt muss aktiviert sein. Also bei einem Datenpunkt die SQL-Aufzeichnung aktivieren und dann auch mindestens einmal einen Wert im Datenpunkt schreiben

Das war im InfluxDB-Adapter in den neuen Versionen auch mal so. Aber mit den aktuellsten Versionen kann man wieder Daten schreiben, zu denen kein Datenpunkt mit konfiguriertem Logging existiert. Hoffe das wurde bei SQL auch schon angepasst. Von welcher Version des Adapters reden wir?

[BananaJoe]

@haus-automatisierung sagte in Test PV Forecast Adapter:

@bananajoe sagte in Test PV Forecast Adapter:

Der Ziel-Datenpunkt muss aktiviert sein. Also bei einem Datenpunkt die SQL-Aufzeichnung aktivieren und dann auch mindestens einmal einen Wert im Datenpunkt schreiben

Das war im InfluxDB-Adapter in den neuen Versionen auch mal so. Aber mit den aktuellsten Versionen kann man wieder Daten schreiben, zu denen kein Datenpunkt mit konfiguriertem Logging existiert. Hoffe das wurde bei SQL auch schon angepasst. Von welcher Version des Adapters reden wir?

Na im Moment setze ich die v2.1.3 ein ... ob das Problem inzwischen nicht mehr existiert habe ich ehrlicherweise nicht getestet - und mit welcher Version ich das Problem hatte weis ich auch nicht mehr.

[BananaJoe]

@ostseeskipper sagte in Test PV Forecast Adapter:

@bananajoe
Stelle mir immer die Frage was soll eigentlich rauskommen.

Pfft was man den Daten anfangen will sei mal dahin gestellt. ich hab halt eine Info-Anzeige was die Anlage heute schon gebracht hat und wieviel es vermutlich werden wird, immer bezogen auf den aktuellen Tag.

Forecast Solar hat am Anfang sich quasi gedeckt (Vorhersage <=> Real), inzwischen schwankt es doch ziemlich.
Das SQL Thema hatte ich deshalb wieder angefasst weil ich parallel auch mal Solcast ausprobieren wollte.

Der ganze Aufwand ist bei mir doch nur für diese eine Grafik:

In der Grafik vergleiche ich immer noch Äpfel (W) mit Birnen (Wh), aber optisch passt es an sich.
Wenn ich jetzt noch den Sonnenstand mit Einbeziehen würde sowie eigene Faktoren (Wann die Sonne dann über das Dach des Nachbarn erscheint) könnte man es genauer machen ... aber wozu Wenn ich mal Langeweile habe.

Forecast bringt ja immer die Werte des heutigen Tages - von Tagesanfang an. Solcast seit dem Zeitpunkt der Abfrage weshalb man sich die alten Werte merken muss.

[haus-automatisierung]

@bananajoe sagte in Test PV Forecast Adapter:

Na im Moment setze ich die v2.1.3 ein

Laut Changelog geht es seit 2.1.0 auch ohne Datenpunkt. Muss ich wie gesagt mal testen, aber dann kann ich das gerne als Option mit aufnehmen

- (Apollon77) Allow storeState and GetHistory also to be called for "unknown ids"

[Dillio]

@haus-automatisierung nun habe ich mich breitschlagen lassen und mir doch die influxdb installiert. Soweit so gut:

Ich würde es noch super finden, wenn die Summary Werte ebenfalls in die influxdb übertragen werden. Wäre das möglich?

[moppel2810]

Guten Morgen,
ich bin gerade am Aufbau meiner PV-Anlage und bastel mir gerade eine grafanaübersicht hab mir den pvforecast adapter installiert und komme jetzt nicht weiter. Ich weiß nicht wie ich die Daten in grafana bekomme, hab mein Hausverbrauch, PV Ertrag und Sonnenstand drin aber wie bekomm ich diese Prognose in den graph?

danke schonmal

[haus-automatisierung]

@moppel2810 sagte in Test PV Forecast Adapter:

aber wie bekomm ich diese Prognose in den graph?

Was erwartest Du denn jetzt? Ein bisschen mehr Infos, was Du schon hast, wäre hilfreich. Hier tippt niemand die Installation von InfluxDB + ioBroker Adapter, Grafana und alle Grundlagen runter.

[Sputnik24]

Ich hätte eine Anmerkung zum Adapter:
Ich werte in einem eigenen Script die Energy und Power aus, für Power die JSONTable, da man hier mit ner for-Schleife schön durch alle json-Knoten iterieren kann. Dabei ist mir aufgefallen:

• In der JSONTable werden die Zahlen als string statt number angezeigt und müssen von meinem Script erst in ein Float oder Int umgewandelt werden.
• Die JSONTable verwendet einen Punkt (.) als Tausendertrennzeichen (bei Watt statt kW), obwohl in der Programmierung der Punkt als Dezimaltrennzeichen verwendet wird. Mein Script muss dieses entfernen, bevor in ein Int umgewandelt wird. In den power-Datenpunkten wird auf das 1000er Trennzeichen verzichtet.
• Bei kW statt W wird ein Komma (,) als Dezimaltrennzeichen verwendet statt wie üblich einem Punkt.

Vorschlag wäre, dass JSONTable und die einzelnen Datenpunkte einheitlich sind in ihrem Format. Idealerweise nummerisch mit Punkt als Dezimaltrennezeichen und ohne Tausendertrennzeichen oder so wie in den Systemeinstellungen von iobroker festgelegt.

[BananaJoe]

@sputnik24 sagte in Test PV Forecast Adapter:

Ich hätte eine Anmerkung zum Adapter:
Ich werte in einem eigenen Script die Energy und Power aus, für Power die JSONTable, da man hier mit ner for-Schleife schön durch alle json-Knoten iterieren kann. Dabei ist mir aufgefallen:

• In der JSONTable werden die Zahlen als string statt number angezeigt und müssen von meinem Script erst in ein Float oder Int umgewandelt werden.
• Die JSONTable verwendet einen Punkt (.) als Tausendertrennzeichen (bei Watt statt kW), obwohl in der Programmierung der Punkt als Dezimaltrennzeichen verwendet wird. Mein Script muss dieses entfernen, bevor in ein Int umgewandelt wird. In den power-Datenpunkten wird auf das 1000er Trennzeichen verzichtet.
• Bei kW statt W wird ein Komma (,) als Dezimaltrennzeichen verwendet statt wie üblich einem Punkt.

Vorschlag wäre, dass JSONTable und die einzelnen Datenpunkte einheitlich sind in ihrem Format. Idealerweise nummerisch mit Punkt als Dezimaltrennezeichen und ohne Tausendertrennzeichen oder so wie in den Systemeinstellungen von iobroker festgelegt.

Ich mache es genauso wie du und bin über genau die gleichen Probleme gestolpert. ABER ... Der Datenpunkt ist nie für die von uns beiden genutzten Zwecke gebaut worden sondern um die Daten eben in einer Tabelle darstellen zu können. Mit einem JSON-Table Widget kann man dann schön alles umformatieren (Reihenfolge, welche Spalten zu sehen sein sollen), aber da braucht man z.B. den 1000er Punkt (ich finde es damit auch lesbarer), den bekommt man da nicht extra wieder ein.

Ja, du hast Recht, aber nein, dafür war der Datenpunkt nicht gedacht.
Du könntest statt dessen z.B. die Datenpunkte pvforecast.0.plants.NameDerAnlage.JSONData nutzen, da hättest du die Daten im Rohformat.
Aber ich mache es ja auch wie du. Weiter oben hatte ich mal eine ähnliche Frage in die Richtung gestellt und eine ähnliche Antwort erhalten

[moppel2810]

@haus-automatisierung Ich habe den pvforecast adapter installiert und grafana läuft bei mir schon einiges.
In den iobroker objekten stehen die Daten von pvforecast ja drin also für jede Stunde nur weiß ich nicht wie ich diese in mein graph bekomme. Muß ich da für jede stunde ein eigenes Query erstellen? Ich hab in dem graph bis jetzt den Sonnenverlauf meinen Pv Ertrag und meinen Hausverbrauch und möchte nur noch die Prognose Grafisch darstellen.

[moppel2810]

@haus-automatisierung So sieht es bei mir im Moment aus.

[moppel2810]

Kann oder will mir niemand helfen die Werte aus dem Adapter in einen grafana graph zubekommen?
Ich kenne mich mit grafana etwas aus und habe auch schon einige Dashboards angelegt aber mit dem pvforecast verzweifel ich gerade

[haus-automatisierung]

@moppel2810 sagte in Test PV Forecast Adapter:

Kann oder will mir niemand helfen die Werte aus dem Adapter in einen grafana graph zubekommen?

Du hakst die InfluxDB-Integration an und dann wird das übermittelt. Und das stellst Du einfach dar - wie jeden anderen Wert auch. Nur, dass es dafür eben keinen Datenpunkt im ioBroker gibt.

[moppel2810]

@haus-automatisierung
Ja das habe ich gemacht in den Objekten aber muss ich jeden Datenpunkt von 5:00-21:00 Uhr einzeln in ein Query importieren?