NEWS
Test PV Forecast Adapter
-
@bananajoe sagte in Test PV Forecast Adapter:
Sollte so passen:
...und im PVForecastadpater habe ich die Leistung auf W statt kw gestellt. Im alten Blockly war da glaube ich die Umrechnung drin. Weil bei W statt KW kommt dann der Punkt in den Werten zum tragen. Oder, bin mir nicht ganz so sicher. Aber mit dem Summery scheint das ganze ja zu funktionieren.
-
@sonnenschein ob kW oder W kannst du ja im Skript ergänzen - bei meiner kleine Anlage reichen halt W
Wenn es gut aussieht passt es -
@bananajoe
ja in die SQL DB werden keine Kommawerte geschrieben, deshalb KW Darstellung ungenügend.
Mit den Watt paßt das schon. -
@sonnenschein sagte in Test PV Forecast Adapter:
@bananajoe
ja in die SQL DB werden keine Kommawerte geschrieben, deshalb KW Darstellung ungenügend.
Mit den Watt paßt das schon.Habe im Blockly mal Debug Bausteine eingebaut.
Demnach steht eine Kommazahl in json Tabelle aber die Variable Leistungswert holen tempLeistungSonnenschein ist ohne Kommastelle!
Hast da jemand deine Erklärung?
Warum die json Tabelle meiner Einzelanlage nicht funktioniert, scheint daran zu liegen das in der Tabelle kein Anlagenname steht! Also in Summery steht der "Sonnenschein" als Anlagenname , in der Tabelle unter plants aber nicht! da steht nur Power! Habe das im Blockly angepaßt und dann kommt auch kein REPLACE Fehler wie oben beschrieben.
-
@sonnenschein weil SQL das mit Punkt statt Komma haben will?
Man müsste noch einen Replace machen, sind ja 2 Beispiele dafür drin (Ich hatte eine extra JavaScript Funktion genommen weil ich die nativen Blockly Wege sehr umständlich fand, in JavaScript ist es ein Einzeiler)Ich hab es nicht richtig gelesen.
-
@bananajoe
Hallo BananaJoe!
Ich habe meinen Adapter noch mal auf KW statt W umgestellt.Die Werte werden dann als Kommazahl im json dargestellt
[{"Time":"2022-11-01 07:11:00","Power":"0,000"},{"Time":"2022-11-01 08:00:00","Power":"0,010"},{"Time":"2022-11-01 09:00:00","Power":"0,065"},{"Time":"2022-11-01 10:00:00","Power":"0,130"},{"Time":"2022-11-01 11:00:00","Power":"2,004"},{"Time":"2022-11-01 12:00:00","Power":"3,986"},{"Time":"2022-11-01 13:00:00","Power":"4,769"},{"Time":"2022-11-01 14:00:00","Power":"4,433"},{"Time":"2022-11-01 15:00:00","Power":"3,079"},{"Time":"2022-11-01 16:00:00","Power":"1,663"},{"Time":"2022-11-01 16:51:00","Power":"0,000"},{"Time":"2022-11-02 07:13:00","Power":"0,000"},{"Time":"2022-11-02 08:00:00","Power":"1,179"},{"Time":"2022-11-02 09:00:00","Power":"3,049"},{"Time":"2022-11-02 10:00:00","Power":"4,314"},{"Time":"2022-11-02 11:00:00","Power":"5,254"},{"Time":"2022-11-02 12:00:00","Power":"5,109"},{"Time":"2022-11-02 13:00:00","Power":"4,829"},{"Time":"2022-11-02 14:00:00","Power":"4,644"},{"Time":"2022-11-02 15:00:00","Power":"3,027"},{"Time":"2022-11-02 16:00:00","Power":"1,493"},{"Time":"2022-11-02 16:49:00","Power":"0,000"}]
Ich verstehe aber Deine Blockly Zeile evtl. noch nicht richtig.
Die Funktion "Replace Dot" wirkt nicht, da es keinen Punkt gibt. OK
Wenn ich zwischen "Replace DOT" und "nach Zahl" einen addierer mit 0.001 einbaue, bekomme ich auch eine Kommazahl in meiner Variablen angezeigt. Also scheint doch die Kommastelle oder das Komma aus dem json nicht gelesen zu werden. Oder bin ich auf dem Holzweg?
Evtl hast Du hier noch eine Idee?
Erst mal lasse ich den Adapter auf Watt stehen damit es erst mal läuft. -
@sonnenschein ReplaceDot macht ja aus dem Punkt ein "", also nichts .... ich meine das wegen 1.000 Zeichen notwendig.
Kann bei dir also raus, schadet aber auch nicht.
Wenn du aus dem , einen Punkt brauchts so schau dir die Funktion an:return x.replace(",",".");
würde aus Kommas dann Punkte machen.
-
@sonnenschein sagte in Test PV Forecast Adapter:
Die Werte werden dann als Kommazahl im json dargestellt
Das von Dir verwendete JSON (wahrscheinlich
pvforecast.0.summary.JSONTable
?) ist gar nicht für die weitere Verarbeitung gedacht! Das ist zur Darstellung in einer (wie der Name vermuten lässt) VIS-Tabelle gedacht.Daher liegen in diesem JSON die Daten formatiert (als String) vor. Und zwar in dem Format, wie es in den Systemeinstellungen hinterlegt ist. So wird aus dem Punkt ein Komma usw. Es wäre totaler Quatsch, das jetzt wieder zurück zu formatieren um es in eine Datenbank zu schreiben!
Bitte nutze den Datenpunkt
pvforecast.0.summary.JSONData
um damit weiter zu rechnen oder die Daten in eine Datenbank zu übertragen.@bananajoe sagte in Test PV Forecast Adapter:
ReplaceDot macht ja aus dem Punkt ein "", also nichts .... ich meine das wegen 1.000 Zeichen notwendig.
Wenn man mit den Daten aus JSONData arbeitet, dann muss man gar nix ersetzen. Kein Komma, keine Tausender-Trennzeichen.
-
@haus-automatisierung sagte in Test PV Forecast Adapter:
Das von Dir verwendete JSON (wahrscheinlich
pvforecast.0.summary.JSONTable
?) ist gar nicht für die weitere Verarbeitung gedacht! Das ist zur Darstellung in einer (wie der Name vermuten lässt) VIS-Tabelle gedacht.Daher liegen in diesem JSON die Daten formatiert (als String) vor. Und zwar in dem Format, wie es in den Systemeinstellungen hinterlegt ist. So wird aus dem Punkt ein Komma usw. Es wäre totaler Quatsch, das jetzt wieder zurück zu formatieren um es in eine Datenbank zu schreiben!
Bitte nutze den Datenpunkt
pvforecast.0.summary.JSONData
um damit weiter zu rechnen oder die Daten in eine Datenbank zu übertragen.Da hast du recht, das der Datenpunkt dafür nicht gedacht ist, ist mir bewusst und aus der Historie gewachsen.
Ich schau mir den anderen Datenpunkt einmal an und baue mein Skript dann mal um. -
@bananajoe sagte in Test PV Forecast Adapter:
ist mir bewusst und aus der Historie gewachsen.
Dann wäre es schon schön, wenn diese Historie nicht auf einer grünen Wiese bei anderen auch wächst Hattest Du Dir nicht sogar den anderen Datenpunkt mit den "RAW-Daten" gewünscht?
-
@haus-automatisierung jepp, aber weil es ja gerade lief noch nicht umgesetzt.
-
@haus-automatisierung öhm, ich weis jetzt wieder warum ich die
pvforecast.0.summary.JSONData
Datenpunkte nicht nutze - weil da nicht genug drin steht ... da steht nur Total drin?
pvforecast.0.summary.JSONData:
[ { "t": 1667456580000, "y": 0 }, { "t": 1667458800000, "y": 1 }, { "t": 1667462400000, "y": 5 }, { "t": 1667466000000, "y": 9 },
Und in
pvforecast.0.summary.JSONTable:
[ { "Time": "2022-11-03 07:23:00", "Total": "0", "600W": "0", "1500W": "0" }, { "Time": "2022-11-03 08:00:00", "Total": "1", "600W": "0", "1500W": "1" }, { "Time": "2022-11-03 09:00:00", "Total": "5", "600W": "2", "1500W": "3" }, { "Time": "2022-11-03 10:00:00", "Total": "9", "600W": "3", "1500W": "6" },
Da kann ich mir halt sämtliche Anlagen aus einem Datenpunkt holen ...
Soll ich einen Request auf GitHub aufmachen? -
Hi Leute,
Ich habe den Adapter schon einige Zeit am Laufen und bin nur zufällig auf diesen Thread gestoßen.
Erst Mal vielen Dank für Euere Arbeit. Jetzt habe ich ein, zwei Fragen zu dem Adapter. Kann aber auch sein, dass ich mich zu doof anstelle.Ich habe bei den Koordinaten die Werte von den Systemeinstellungen genommen. Leider wird ein Ort in den DP geschrieben, der 6km Luftlinie entfernt ist.
Weiter ist die Vorhersage noch weniger als Circa. Es weicht manchmal um etliche KW/h ab.
Die Version von dem Adapter ist
Sonnst ist mein System auf dem aktuellen Stand.
Grüße -
@bananajoe Du hast ja pro Plant auch nochmal JSONData. Daher wäre es ja doppelt, das da auch nochmal zu pflegen.
-
@haus-automatisierung ja .... wäre es ..... gilt aber ja auch für JSONTable ...
-
@maxtor62 sagte in Test PV Forecast Adapter:
Weiter ist die Vorhersage noch weniger als Circa. Es weicht manchmal um etliche KW/h ab.
Tja, dann macht deine Anlage nicht was sie machen soll
Im Sommer passt es eher ... Oder die Anlagendaten "faken", also weniger angeben als wirklich da ist und dann passt es besser.
-
@bananajoe
Super, Danke für die HilfeMeine Anlage ist seit 06.2019 am Start und macht genau das was sie soll.
-
@bananajoe sagte in Test PV Forecast Adapter:
@haus-automatisierung ja .... wäre es ..... gilt aber ja auch für JSONTable ...
Hallo Zusammen!
Ich habe Eure Diskussion verfolgt und mein Problem mit den Datenpunkt und Darstellungen der Prognose noch mal auf den Kopf gestellt.
Erstes Problem welches ich mir eingebaut hatte: Beim Anlegen des Datenpunkt unter Userdata für die SQL Datenbank, hatte ich noch auf archivieren stehen, UND delta Speicherung mit trotzdem alle 3600 Sekunden spichern. Da im Datenpunkt eine 0 stand hat er mir zusätzlich zum Script noch vom SQL Adapter rein geschrieben.
Trotzdem hatte ich dann mit dem Start des Blockly korrekte Daten in der SQL DB in VIS aber nur bis die Zeit der Prognose am nächsten Tag zu Ende war. Das Script hat nicht aktualisiert.
Nach dem ich Stunden mit dem Trigger im Blockly gekämpt habe, habe ich am Ende das Script weggeschmissen und neu angelegt. Anpassungen an meine Anlage bzw. die JSON Tabelle Summery des Adapter.
Seit dem läuft es wieder so wie es soll. Bei Änderung wird in die DB geschrieben. Und die Verbesserung von BananaJoe historische Daten durch das geänderte Schreiben ohne Delete all.Danke für Eure Diskussion das hat geholfen!
-
@patrickwalther Hallo, möchte mich hier mal einklinken. Einen Forecast für meine PV-Produktion wäre sehr hilfreich, damit könnte ich ev. erkennen, wann ich Netzstrom für die E-Auto Ladung benötige.
Frage, reicht der Public Api Key von Forecast?
https://doc.forecast.solar/doku.php?id=api:estimate -
@humidor Hier ist alles erklärt https://www.youtube.com/watch?v=rV_uKHI90eY