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

[haus-automatisierung]

@jacke sagte in Test PV Forecast Adapter:

unter plants finde ich leider auch nichts in grafana

Du solltest die Daten unter pvforecast.0.plants.west.power finden. Der Namespace wurde noch voran gestellt, damit mehrere Instanzen unterstützt werden und unterschieden werden können. Also vom Konzept analog zu anderen Datenpunkten, welche für das InfluxDB Logging aktiviert.

[SBorg]

@jacke sagte in Test PV Forecast Adapter:

unter plants finde ich leider auch nichts in grafana

...siehe zwar @haus-automatisierung , aber in Grafana braucht man auch nicht wie wild in der Liste zu scrollen und zu suchen, sondern einfach mal plants eingeben --> dann kommt auch pvforecast.0.plants.XXX.power sofort als Ergebnis

[Dillio]

Hallo zusammen,

ich bin zufälligerweise über den Youtube-Kanal von @haus-automatisierung auf diesen Adapter gestoßen und habe mir diesen gleich mal installiert. Die Daten werden auch schon fleißig berechnet und ausgespuckt. Jetzt würde ich das gerne visualisieren und über die IST-Werte meiner PV-Anlage legen, ähnlich wie hier:

Nur halt nicht über Grafana, sondern über Flot. Ich habe weder SQL noch InfluxDB. Logge die Daten mittels History-Adapter. Daher meine Frage: ist es möglich die Prognosedaten über die Rohdaten JSONData oder über einen anderen Weg mittels History Adapter zu loggen und im Flot darzustellen?

Gruß
Dillio

[SBorg]

@dillio sagte in Test PV Forecast Adapter:

Daher meine Frage: ist es möglich die Prognosedaten über die Rohdaten JSONData oder über einen anderen Weg mittels History Adapter zu loggen und im Flot darzustellen?

Nein, Flot kann nichts mit dem Datensatz anfangen.
...und ja, aber ziemliche Datenflut (oder Anzahl an History-Files). Du bräuchtest bei der PV eine stündliche Summe des Ertrages als logbaren History-Datenpunkt. Gleichzeitig musst du jede gewünschte Stunde (also bspw. 5-23 Uhr) im PVForecast per History loggen. Die beiden Datenreihen kannst du dann in Flot übereinander legen.

---

...und nur damit ich es erwähne, Influx und Grafana sind da deutlich komfortabler und haben wesentlich mehr Möglichkeiten

[Diginix]

@sborg sagte in Test PV Forecast Adapter:

...und nur damit ich es erwähne, Influx und Grafana sind da deutlich komfortabler und haben wesentlich mehr Möglichkeiten

@Dillio Unabhängig von PV solltest du je nach Menge der erfassten Objekte und Änderungshäufigkeit darüber nachdenken von history weg zu gehen. Gerade nicht boolesche Daten (zB nummerische Sensorwerte o.ä.) können beim History Adapter echt viel Plattenbelegung und Platten I/O Erzeugen. Gerade bei Setups mit SD Karte sehr ungünstig für die Lebensdauer.
Aus meinen damals 4 GB history JSON sind keine 300 MB influxDB geworden.

[Dillio]

@SBorg danke für die schnelle Antwort!

Die einzelnen Datenpunkte (today & tomorrow) über History zu loggen bringt mir leider wenig, da mir nicht bekannt ist, dass History Datenpunkte in der Zukunft loggen kann. Somit hätte ich ja keine Prognose. Ich hätte jetzt gedacht, dass man, eventuell mittels eines Scripts, die Daten so aufbereiten kann, dass die über History logbar wären. Dafür müsste man die JSONData in einem neuen Datenpunkt speichern, aber in einem anderen Format. Beispielsweise so:

[
  {
    "val": "1282",
    "ack": 1,
    "ts": 1655312400000,
    "q": 0,
    "from": "system.adapter.pvforecast.0",
    "user": "system.user.admin"
  }
]

Ich bin jedoch kein Script-Experte.

@Diginix
Ja, da gebe ich dir vollkommen recht. Mein History Ordner liegt derzeit bei 3.9 GB. Mich stört das nicht, da die Installation meines Master-ioBrokers über Synology (Docker) läuft und ich da massig Speicherplatz habe. Läuft es denn unter InfluxDB und Grafana flüssiger? Konntest du da eine Leistungssteigerung feststellen. Ich habe manchmal das Gefühl, wenn ich beispielsweise mir die Daten für den Zeitraum von einem Monat anschaue, dass Flot/History da zu kämpfen haben.

[haus-automatisierung]

@dillio sagte in Test PV Forecast Adapter:

da mir nicht bekannt ist, dass History Datenpunkte in der Zukunft loggen kann

Was spricht dagegen? Mit sendTo müsstest Du die Daten auch für die Zukunft schreiben können. Macht der InfluxDB-Adapter ja genauso mit.

[Diginix]

@dillio sagte in Test PV Forecast Adapter:

@Diginix
Läuft es denn unter InfluxDB und Grafana flüssiger? Konntest du da eine Leistungssteigerung feststellen. Ich habe manchmal das Gefühl, wenn ich beispielsweise mir die Daten für den Zeitraum von einem Monat anschaue, dass Flot/History da zu kämpfen haben.

Kann ich nicht mehr genau sagen, aber kann mMn nur so sein, da eine Datenbank dafür gemacht ist und bei History erst alle JSON eingelesen/geparst werden müssen, um an die Werte zu kommen. Bei einem schnellen Server wahrs. nur im Sekundenbereich. Ich bin froh die Migration "rechtzeitig" gemacht zu haben obwohl es bei mir auch kein Plattenplatz oder SD Card Problem gab.

[ostseeskipper]

@PatrickWalther
Der Adapter sieht wirklich vielversprechend aus. Super Arbeit und Danke.
Vor allem das man mehrere PV Anlagen mit der Ausrichtung anlegen kann, wirklich toll.

Leute wie habt Ihr das eingetragen: Habe OST und WEST jeweils 7,2 KWp also zusammen 14,4 KWp der WR hat aber "nur" eine AC Leistung von 10 KW.
Was muss bei Spitzenleistung rein?

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

[haus-automatisierung]

@ostseeskipper sagte in Test PV Forecast Adapter:

Was muss bei Spitzenleistung rein?

Du trägst genau das ein, was installiert ist. Warum 10kWp Spitzenleistung? Wegen Wirkleistungsbegrenzung? Da gibt es noch einen offenen Wunsch, dass man die auch konfigurieren kann. Ist aber viel Rechnerei und muss ich mir noch anschauen. Du würdest dann halt ggf. Werte über 10kW bekommen.

[haus-automatisierung]

@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.

[ostseeskipper]

@haus-automatisierung said in Test PV Forecast Adapter:

@ostseeskipper sagte in Test PV Forecast Adapter:

Was muss bei Spitzenleistung rein?

Du trägst genau das ein, was installiert ist. Warum 10kWp Spitzenleistung? Wegen Wirkleistungsbegrenzung? Da gibt es noch einen offenen Wunsch, dass man die auch konfigurieren kann. Ist aber viel Rechnerei und muss ich mir noch anschauen. Du würdest dann halt ggf. Werte über 10kW bekommen.

Mit Wirkleistungsbegrenzung hat das nichts zu tun. Der Adapter weiss ja ehh nicht wie hoch mein Eigenverbrauch im Haus ist.
Ist nur so das der WR maximal 10KW AC Leistung produziert. Je Ausrichtung aber 7,2 KWp hat. Erst kommt von der Ostseite bis zu 7,2 KW und weniger von West, dann wandert es bis 7,2 von West kommen und weniger von Ost.
Das Ausrechnen könnte man mit Max(WR Leistung machen). Eventuell die Einträge als Strings definieren und (wie in PVSOL) zu Wechselrichtern zusammenschalten der eine Maximale Leistung hat. Ich probier erst mal was da so rauskommt an Prognose, vor allem wenn Wetter ist

[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.