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

[PatrickWalther]

@sonnenschein

Hallo,

Die Werte siehst du nicht in Iobroker direkt nur in der Datenbank und in Grafana.

Meine Aufbau ist wie folgt:

Influxdb mit Grafana und der Graph bzw. Timewerkes geht auch.
Folgende Anleitung kannst du verwenden.

https://www.smarthome-tricks.de/software-iobroker/1-2-grafana-installation-von-influxdb-und-integration-in-iobroker/amp/

Der Adapter schreibt die Werte alle X Minuten (wie du es eingestellt hast) in die SQL / Influx Datenbank.

Kannst auch gerne per Discord oder Chat schreiben, dann geht es schneller.

[Sebastianb_80]

@patrickwalther

welche Widgets du benutzt?

• um die blaue Grafik zu erzeugen habe ich das Material Design json chart Widget benutzt

Woher kommt die andere Grafik?

• die andere Grafik kommt aus dem Modbusadapter --> History-->Flot Charts

Benutzt du Garafana?

• Nein

Welche Datenbank wir benutzt?

• Mit InfluxDB usw. hab ich noch keine Erfahrungen sammeln können...

Ist es möglich die Daten der beiden Kurven (blaues unschönes Widget) in einer Kurve zu "vereinigen?
z.B. mit Blockly? Sprich die einzelnen Daten von 05:00Uhr - 21:00Uhr (aus der summery) Zusammenzuführen und dann Grafisch darzustellen?

[PatrickWalther]

@sebastianb_80 hast du im Adapter - Settings SQL aktiviert (checkbox) und SQL.0 ausgewählt?

Ich wusste aus dem steh Greif keine andere Variante als die Daten in die Datenbank direkt zu schreiben.

Würde dir Grafana empfehlen, dort kann man viele Einstellungen machen.

[Sebastianb_80]

@patrickwalther

Danke für den Hinweis, dann werde ich mich wohl oder über mal mit Grafana beschäftigen müssen.

DANKE

[PatrickWalther]

@sebastianb_80 habe gerade mal den SQL Adapter installiert und die Funktion getestet. Diese funktioniert nicht richtig.

Werde den Fehler versuchen jetzt zu beheben.

[sonnenschein]

@patrickwalther Hallo!

Ich habe soeben noch mal in meine SQL DB geschaut. So wie du festgestellt hast, kommen die Daten in der DB nicht "an".
Im Logfile erscheinen aber keine Fehlermeldungen dazu.

[sonnenschein]

@sonnenschein sagte in Test PV Forecast Adapter:

@patrickwalther Hallo!

Ich habe soeben noch mal in meine SQL DB geschaut. So wie du festgestellt hast, kommen die Daten in der DB nicht "an".
Im Logfile erscheinen aber keine Fehlermeldungen dazu.

Inhalt wieder gelöscht da Fehlerhaft, Tschuldigung

[PatrickWalther]

@sonnenschein Kein Problem.

@sebastianb_80 und @sonnenschein
Habs hin bekommen das die Daten sowohl in Grafana, ECharts und Flot angezeigt werden. Auch die Daten werden unter Object Einstellungen angzeigt.

Einstellungen unter Objekte:

Grafana:

E-Charts:

Update ist online. Probiert es gerne aus. Habe allerdings keine längeren Tests damit gemacht.

Falls Fehler auftreten bitte melden.

[PatrickWalther]

@Sputnik24 wie verhinderst du doppelte Einträge mit deinem Script?

[BananaJoe]

@patrickwalther kannst du noch mal genau erklären was man machen muss um die Daten im SQL zu haben?
Was ich gemacht habe:

• auf aktuelle GitHub-Version 1.9.0 aktualisiert
• in den Adapter-Einstellungen activate SQL gesetzt und meine Instanz sql.0 ausgewählt.
  Im Log erhalte ich Fehlermeldungen dieser Art:

2022-02-12 05:22:31.650  - warn: sql.0 (1721) States system pmessage messagebox.system.adapter.sql.0 {"command":"storeState","message":{"id":"pvforecast.0.summary.prognose","state":{"ts":1644757200000,"val":71,"ack":true,"from":"pvforecast"}},"from":"system.adapter.pvforecast.0","_id":78689077} Cannot read property 'ignoreZero' of undefined
2022-02-12 05:22:31.650  - warn: sql.0 (1721) TypeError: Cannot read property 'ignoreZero' of undefined
    at pushValueIntoDB (/opt/iobroker/node_modules/iobroker.sql/main.js:1575:39)
    at storeState (/opt/iobroker/node_modules/iobroker.sql/main.js:2294:9)
    at processMessage (/opt/iobroker/node_modules/iobroker.sql/main.js:916:9)
    at Adapter.<anonymous> (/opt/iobroker/node_modules/iobroker.sql/main.js:219:34)
    at Adapter.emit (events.js:400:28)
    at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/lib/adapter/adapter.js:5294:34)
    at Immediate._onImmediate (/opt/iobroker/node_modules/@iobroker/db-states-redis/lib/states/statesInRedisClient.js:324:37)
    at processImmediate (internal/timers.js:464:21)

Der Datenpunkt pvforecast.0.summary.prognose wird als Typ JSON erstellt.

Ich wollte das auch nutzen um Prognose und Realität in einer Grafik übereinanderlegen zu können.

[PatrickWalther]

@bananajoe ich habe in den Objekt Einstellungen des Datenpunktes das Logging aktiviert und die Einstellungen in den Adapter Einstellungen wie du es gesagt hast.

[sonnenschein]

@patrickwalther Hallo zusammen !

Ich hab ebenfalls die Version auf 0.1.9 aktualisiert.
Einstellung wie BanaJoe geschrieben hat.
SQL mit Instanz sql.0
Das Objekt pvforecast.1.summary.prognose sql aktiviert.
Aber anscheinend wird hier nicht rein geschrieben. Im SQl Adpater Logging / bzw PVAdapter Logging sehe ich keine Fehlermeldungen.
Das Objekt pvforecast.1.summary.lastUpdated_data wird regelmäßig laut Zeit Stempel beschrieben.
Was mache ich falsch, muß ich abwarten oder wo kann ich noch hinschauen um hier evtl weitere Infos zur Fehlersuche zu liefern.
Mit Grafana brauche ich solange nicht testen, wenn im Objekt Prognose nichts reingeschrieben wird.
Ich habe auch direkt in die SQL DB geschaut.
Der Datenpunkt für summery prognose wurde nach dem Aktivieren des Logging angelegt, aber keine Daten geschrieben.
Im Objekt habe ich dann mal einen Wert 1 und 0 gespeichert. Der wird im SQL auch angezeigt. Aber aus dem Adapter PVForecast scheint anscheinend nichts in das Objekt pvforecast.1.summary.prognose geschrieben zu werden.

Mein Verständnis: Der Adapter holt alle 60 Minuten Daten von Forecats und werte diese aus. Schreibt sie in die Objekte die durch den Adapter angelegt wurden. Außer dem Objekt Prognose wurde kein SQL Logging der Objekte aktiviert. Da Adapter schreibt die relevanten Daten direkt in die SQL DB. Im Summery.Progonse soll es einen JSON String geben der dann in Grafanana mit Datenquelle JSON SIMPLE in einem Panel TIMESERIES angezeigt werden kann.
Gruß Sonnenschein

[sonnenschein]

@bananajoe sagte in Test PV Forecast Adapter:

Der Datenpunkt pvforecast.0.summary.prognose wird als Typ JSON erstellt.

Dieses Objekt wird doch automatisch durch den Adapter erstellt, oder? Hast Du den von Hand angelegt oder bearbeiten müssen?

[PatrickWalther]

@sonnenschein Influxdb ist anders als SQL. Das bedeutet das InfluxDb funktioniert, SQL arbeite ich noch dran.

Kenne mich leider damit auch nicht so gut aus. Muss mich auch erst rein Arbeiten. Wird noch einen Moment dauern.

[Sputnik24]

@patrickwalther said in Test PV Forecast Adapter:

@Sputnik24 wie verhinderst du doppelte Einträge mit deinem Script?

Für mein Verständnis gibt es das Problem bei influxdb nicht, da der Index der Zeitstempel ist. Heißt, das Schreiben eines neuen Wertes mit gleichem Zeitstempel überschreibt den alten Wert.

[PatrickWalther]

@sputnik24 danke für die Info, das habe ich auch rausgefunden.

Mal schauen wie ich das Thema bei SQL angehe. Hast du eine Idee?

[Sputnik24]

@patrickwalther said in Test PV Forecast Adapter:

Mal schauen wie ich das Thema bei SQL angehe. Hast du eine Idee?

Bin leider auch nicht mehr so tief in SQL drin, aber da man den Zeitraum ja kennt, für den man die Daten neu schreiben möchte, zuvor die Daten aus der Datenbank für diesen Zeitraum löschen? Könnte man ja auch für influx machen, dann wäre die Implementierung DB-unabhängig.

[sonnenschein]

@patrickwalther sagte in Test PV Forecast Adapter:

Influxdb ist anders als SQL. Das bedeutet das InfluxDb funktioniert, SQL arbeite ich noch dran.
Kenne mich leider damit auch nicht so gut aus. Muss mich auch erst rein Arbeiten. Wird noch einen Moment dauern.

Kein Problem

[PatrickWalther]

@sputnik24 so in etwa habe ich das auch gedacht. Mal schauen ob es klappt.

[Sputnik24]

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