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

[Homoran]

@warp735 sagte in Test PV Forecast Adapter:

Warum wird man in diesem Forum mit nem Docker immer behandelt, als hätte man ne Warze am Arsch?!

Warum behauptest du das?

Hier kann eben nur eine begrenzte Anzahl User mit dem entsprechenden Wissen helfen, deswegen muss diese Info über Docker initial gegeben werden

es funktioniert im Docker eben nicht wie in einer nativen Umgebung

[Thomas Braun]

@warp735

Weil ein Docker prinzipbedingt ein Sonderweg ist und sich komplett von nativen oder LXC-Installationen unterscheidet.
Und deswegen muss beim 'iob fix' dieser Hinweis kommen. Und auch 'iob nodejs-update' muss den Docker-Sonderweg ausschließen. Und im 'iob diag' müssen auch einige Dinge anders gemacht werden als in anderen Installationen.

[anbima]

Ich verwende den Solcast-Adapter mit passendem API-Schlüssel.
Beim Diagramm werden falsche Werte angezeigt.
Erst dachte ich mir, dass es an den fehlenden Daten liegt, da ich es gestern eingerichtet habe. Aber heute war es auch wieder falsch. Es fehlt auch der zweite Tag.

Den Adapter habe ich auch schon gelöscht und neu installiert, aber es ist immer der selbe Fehler. Nachfolgend Screenshots davon.

Was kann ich machen?

[BananaJoe]

@anbima und was daran ist falsch? Die Werte sehen doch Plausibel aus

[anbima]

@bananajoe said in Test PV Forecast Adapter:

@anbima und was daran ist falsch? Die Werte sehen doch Plausibel aus

Die Werte passen nicht überein.
z.B.
Daten 13:00 Uhr: 6,267
Diagramm 13:00 Uhr: 6,349

Und es fehlen auch einige Stunden beim 2. Tag.

Es schaut so aus, als wenn die Daten im 1/2-Stunden-Takt ausgegeben werden. Wird diese Einstellung wo gespeichert, was bei der Deinstallation des Adapters nicht gelöscht wird?

Hier noch die Daten vom JSONGraph:

Spoiler

{
"graphs": [
{
"data": [
6.027,
6.349,
6.267,
5.921,
5.444,
4.998,
4.64,
4.252,
3.797,
3.242,
2.59,
1.916,
1.307,
0.728,
0.221,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0.196,
0.643,
1.179,
1.855,
2.702,
3.467,
4.164,
4.688,
4.982,
5.339,
5.784,
6.139,
6.399,
6.324,
5.899,
5.314,
4.638,
4.023,
3.527,
2.698,
1.559,
0.785,
0.278,
0.007,
0,
0,
0,
0,
0,
0,
0,
0,
0.085,
0.488,
1.08,
1.766,
2.51,
3.22,
3.857,
4.383,
4.785
],
"type": "bar",
"legendText": "Total",
"displayOrder": 1,
"color": "#e6d41a",
"tooltip_AppendText": "kW",
"datalabel_show": true,
"datalabel_rotation": 300,
"datalabel_color": "#0b0b0b",
"datalabel_fontSize": 14,
"yAxis_id": 0,
"yAxis_position": "left",
"yAxis_show": true,
"yAxis_appendix": "kW",
"yAxis_step": 1,
"yAxis_max": 11.55,
"yAxis_maximumDigits": 3
}
],
"axisLabels": [
"12",
"13",
"14",
"15",
"16",
"17",
"18",
"19",
"20",
"21",
"06",
"07",
"08",
"09",
"10",
"11"
]
}

[BananaJoe]

@anbima keine Ahnung, könnte was mit dem Adapter sein beim Schreiben der Werte in Datenpunkte. Sieht um 1h verschoben aus.
Ich nutze ein eigenes Skript um die Werte in meine SQL-Datenbank zu schreiben und bei mir passt es

[anbima]

@bananajoe
Schaut eher so aus, als wenn er die Daten im 1/2-Stunden-Takt liefert, aber das Script nur die Achse für den Stunden-Takt angibt.

Daher auch die Frage, ob diese Angaben wo gespeichert werden, auch wenn der Adapter deinstalliert wird. Denn ich hatte vorher die Anzeige mi dem 1/2-Stunden-Takt eingestellt und das hat gepasst. Nun ändert sich aber auch nichts, wenn ich auf den 1/2-Stunden-Tank umschalte.

Gefunden: Beim Diagrammetikettenformat muss mind. DD.HH vorhanden sein.

[BananaJoe]

@anbima sagte in Test PV Forecast Adapter:

Schaut eher so aus, als wenn er die Daten im 1/2-Stunden-Takt liefert, aber das Script nur die Achse für den Stunden-Takt angibt.

das ist egal. Die Werte die geliefert werden haben ja auch einen Zeitstempel zum jeweiligen Wert, z.B. "um 13:00:00 Uhr sind es 5899kWh"

Und so schreibt man das dann auch in die Datenbank. Da ist es egal ob der Wert in der Zukunft oder Vergangenheit liegt, man gibt diesen Wert mit: "Schreibe für 13:00:00 Uhr den Wert 5899 in die Datenbank"

[anbima]

Das Problem ist wieder da.
Ich hatte gestern das Abfragelimit bei solcast erreicht und daher auf Forecast.solar umestellt. Da hat es funktioniert.

Mit solcast funktioniert es heute nicht mehr.

Trotz eingetelltem Stundentakt werden diese im 1/2-Stundentakt ausgegeben.
Das haut dann die Grafik durcheinander.

Kann ich das Problem selbst lösen oder muss da ein "Bugfixer" ran?

[anbima]

@PatrickWalther
Bist du hier noch aktiv und könntest eventuell Änderungen vornehmen?

[JLeg]

Pls.ignore.

[markus397]

Der Adapter liefert seit ein paar Tagen keine Daten mehr Issues auf Github dazu ist ja schon offen. Kann man das Problem fixen?

[Samson71]

@markus397 sagte in Test PV Forecast Adapter:

Der Adapter liefert seit ein paar Tagen keine Daten mehr

Ganz neue Erkenntnis ;)

https://forum.iobroker.net/topic/77375/pv-forecast-probleme-mit-solcast

[icebear]

Ich denke der einzigste der da jetzt noch was dran tun kann ist @haus-automatisierung Matthias.

Der hatte damals auch schon mal ein Problem gefixt. Ohne seine Hilfe wird das wohl nix mehr werden mit 'solcast' . Dann bleibt leider nur die Option 'forcast-solar'.

Ich bin momentan dran den 'solcast' Part über Node-Red zu realisieren, die grafische Darstellung in Grafana hab ich schon, leider gehen meine Kentnisse nicht soweit das ich das mal eben aus dem Ärmel schütteln kann wie ich in Node-Red jetzt ein json mit den Werten erzeugen kann und die Werte dann nach IOB bekomme.

[haus-automatisierung]

@icebear Ich nutze aktuell forecast.solar (die Bezahlversion). Muss mal gucken ob die API einfach anpassen kann oder ob das mehr Aufwand wird.

[icebear]

@haus-automatisierung

Also wie gesagt, ich mach das bei solcast im Moment über Node-Red mittels der (wie im Github zum Adapter beim Issue von einem Erwähnt wurde) Abfrage der Rooftop_id's

Dazu habe ich zwei Flow's, einen für NE und einen für SW und dann über die Abfrage URL

https://api.solcast.com.au/rooftop_sites/<rooftop-id>/estimated_actuals?format=json

und der Solcast-API Id bei 'Benutzerdaten'.

Das müsste man ja dann beim Adapter so einbauen, das man das in der Konfiguration so eingibt (also Die jeweilige 'Rooftop-ID' und der wie jetzt auch schon zugehörige API-Key.

Dadurch würde die Abfrage nach der PV-Ausrichtung im Adapter entfallen, da die ja duch die Rooftop-ID festgelegt ist.

Ich hab mittlerweile auch schon ein JSON aus meinen Node-Red Flows, das wie folgt aussieht:

{
    "forecasts": [
        {
            "pv_estimate": 0.5877,
            "pv_estimate10": 0.4438,
            "pv_estimate90": 0.686,
            "period_end": "2024-10-12T09:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.593,
            "pv_estimate10": 0.4029,
            "pv_estimate90": 0.7882,
            "period_end": "2024-10-12T10:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.6933,
            "pv_estimate10": 0.4774,
            "pv_estimate90": 0.8427,
            "period_end": "2024-10-12T10:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.7427,
            "pv_estimate10": 0.5796,
            "pv_estimate90": 0.7877,
            "period_end": "2024-10-12T11:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.6969,
            "pv_estimate10": 0.5447,
            "pv_estimate90": 0.7216,
            "period_end": "2024-10-12T11:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.6204,
            "pv_estimate10": 0.4745,
            "pv_estimate90": 0.6686,
            "period_end": "2024-10-12T12:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.5564,
            "pv_estimate10": 0.4214,
            "pv_estimate90": 0.6139,
            "period_end": "2024-10-12T12:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.5214,
            "pv_estimate10": 0.374,
            "pv_estimate90": 0.5641,
            "period_end": "2024-10-12T13:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.4715,
            "pv_estimate10": 0.3144,
            "pv_estimate90": 0.5118,
            "period_end": "2024-10-12T13:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.4029,
            "pv_estimate10": 0.247,
            "pv_estimate90": 0.4556,
            "period_end": "2024-10-12T14:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.303,
            "pv_estimate10": 0.1602,
            "pv_estimate90": 0.3944,
            "period_end": "2024-10-12T14:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.1968,
            "pv_estimate10": 0.0853,
            "pv_estimate90": 0.3189,
            "period_end": "2024-10-12T15:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.1006,
            "pv_estimate10": 0.0467,
            "pv_estimate90": 0.2197,
            "period_end": "2024-10-12T15:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.0521,
            "pv_estimate10": 0.0198,
            "pv_estimate90": 0.1006,
            "period_end": "2024-10-12T16:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.0198,
            "pv_estimate10": 0.0072,
            "pv_estimate90": 0.0431,
            "period_end": "2024-10-12T16:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0.0018,
            "pv_estimate10": 0,
            "pv_estimate90": 0.0036,
            "period_end": "2024-10-12T17:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0,
            "pv_estimate10": 0,
            "pv_estimate90": 0,
            "period_end": "2024-10-12T17:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0,
            "pv_estimate10": 0,
            "pv_estimate90": 0,
            "period_end": "2024-10-12T18:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0,
            "pv_estimate10": 0,
            "pv_estimate90": 0,
            "period_end": "2024-10-12T18:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0,
            "pv_estimate10": 0,
            "pv_estimate90": 0,
            "period_end": "2024-10-12T19:00:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0,
            "pv_estimate10": 0,
            "pv_estimate90": 0,
            "period_end": "2024-10-12T19:30:00.0000000Z",
            "period": "PT30M"
        },
        {
            "pv_estimate": 0,
            "pv_estimate10": 0,
            "pv_estimate90": 0,
            "period_end": "2024-10-12T20:00:00.0000000Z",
            "period": "PT30M"
        }

Musste halt mal schaun ob es den Aufwand lohnt, schön wärs schon, da z.B. bei mir die Solcastwerte besser gepasst haben als die von Forcast-Solar.

[Krys]

Hi, ich benötige leider eure Hilfe.
Auch ich verstehe es noch nicht so ganz mit dem Azimut.

Meine Panele schauen dem Bild nach auf so auf 155 Grad Süd-Südost.

Was ist der richtige Azimutwert im Adapter? -40 pipapo?

[icebear]

@krys

Also wenn ich jetzt nicht ganz falsch liege, dann müßte das -25 sein.

Da der Adapter ja Süden bei =0° nimmt und du ja weiter nach Osten mußt also in den Minus-Bereich so wie es im Adapter auf der Einstellungsseite zusehen ist.

Und 155+25 sind 180(bzw 0). Also müßte -25 richtig sein.

Das brauchst du ja auch nur bei Forecast Solar. Wenn du den Adapter (in der neuesten Version 4.0.0) mit 'solcast' nutzt dann gibt es das ja nicht mehr.

[Krys]

@icebear

Vielen Dank für den Hinweis. Es läuft nun denke ich mal.

[markus397]

@haus-automatisierung Danke für deine Arbeit