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

[haus-automatisierung]

@thomas-braun Gerade mal in das Dockerfile geschaut. Diese Zeile gehört da eigentlich nicht rein:

https://github.com/buanet/ioBroker.docker/blob/5247639a66ad0b648153c4da632795a99f45093c/debian12/Dockerfile#L49

Habe mal einen Issue geöffnet:

https://github.com/buanet/ioBroker.docker/issues/465

[Thomas Braun]

@haus-automatisierung

Geh mir weg mit eingedockertem Zeuch...
Ich sag ja: Docker-Sonderstrick...

[haus-automatisierung]

@thomas-braun Was stört dich? Dass jeder Schritt im Dockerfile klar dokumentiert ist, und man so auf einen Blick direkt sieht, was im Container eigentlich installiert wurde? Fehler in 10 Sekunden gefunden. Das wäre bei einer nativen Installation nicht so leicht nachvollziehbar

[Homoran]

@haus-automatisierung sagte in Test PV Forecast Adapter:

Was stört

Vielleicht dass da eine weitere Ebene existiert, die geprüft werden muss.
Und der User der Docker nimmt, weil es so einfach zu handeln ist, wird nicht sämtliche Codes durchforsten.

[Thomas Braun]

@haus-automatisierung sagte in Test PV Forecast Adapter:

Was stört dich?

Grundsätzlich nichts.
Nur halt die ganzen Verrenkungen, die in einem Docker veranstaltet werden.

[haus-automatisierung]

@thomas-braun Jedenfalls wird das Problem von @warp735 nicht mit der neueren npm Version zusammenhängen.

Da hilft also wirklich nur noch ein Debug-Log vom pvforecast Adapter + Screenshot der Configuration um zu schauen was genau passiert und welche Daten abgerufen werden.

[Thomas Braun]

@haus-automatisierung sagte in Test PV Forecast Adapter:

Jedenfalls wird das Problem von @warp735 nicht mit der neueren npm Version zusammenhängen.

Das habe ich aber auch nicht behauptet. Mir war nur die Inkonsistenz in den Versionen aufgefallen.
Ich hab auch nicht gesehen, das es was eingedockertes war.

[warp735]

Warum wird man in diesem Forum mit nem Docker immer behandelt, als hätte man ne Warze am Arsch?! Für mich als normaler User ist das Ding "offiziell" und trotzdem tut jeder, als würde man nen absoluten Sonderweg fahren...

Das Selbe mit dem Fixer... beim "offiziellen Docker image" popt einem dann erstmal diese Meldung entgegen:

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