76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Achso, jetzt habe ich es verstanden.
Naja, der Ansatz zur Darstellung der Batterie-Icons ist eigentlich nicht deren Füllgrad und SoC-Prognose.
Der Case ist hier die Visualisierung ob die Aufladung der Batterie für die nächsten Stunden empfohlen wird oder nicht. Das hat etwas mit der Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einem Beitrag zur Netzstabilität zu tun (Wiki).
Deswegen hat die Vergangenheit keine Relevanz für diese Darstellung.
Aber du kannst die z.B. in 2. Ebene ein Balkendiagramm des SoC einblenden, welches auch die erreichten SoC der Vergangenheit anzeigt.

Die Abbildung der SoC-Prognose ist quasi ein, wenn auch attraktives, "Abfallprodukt".

[Parallix]

...
Der Case ist hier die Visualisierung ob die Aufladung der Batterie für die nächsten Stunden empfohlen wird oder nicht.

Um warum lässt Du die alten bzw. letzten Empfehlungen nicht in der Grafik?

[DS_Starter]

Wäre es möglich, derart unsinnige Fälle (House-Consumption < 0) im Modul zu erkennen und dann nicht weiter zu verarbeiten, sodass Sie dann weder in der Grafik angezeigt werden und auch gar nicht erst ins Forecast einfließen?

Das ist ein zweischneidiges Schwert. Technisch kann man alles mögliche unterdrücken und teilweise mache ich es auch in bestimmten Fällen.
ABER, und das möchte ich beibehalten, wird man dadurch auf Fehler im Setup und/oder fehlerhaft gelieferte  Daten der Datenlieferanten aufmerksam und kann bzw. sollte die Sache bereinigen.
Nichts geht über eine gute Inputdatenqualität!

[DS_Starter]

Um warum lässt Du die alten bzw. letzten Empfehlungen nicht in der Grafik?

Wozu soll das gut sein?
Achtung ... Ich entferne sie nicht, sondern müßte sie erst relativ aufwändig in die Grafik integrieren.

[DS_Starter]

Apropos unsinnige Daten:

Kannst du erläutern was genau unsinnig ist?

[Parallix]

Um warum lässt Du die alten bzw. letzten Empfehlungen nicht in der Grafik?

Wozu soll das gut sein?

Aus den gleichen Gründen, weshalb ein Blick auf die alten Wetterdaten sinnvoll sein kann.

Ich entferne sie nicht, sondern müßte sie erst relativ aufwändig in die Grafik integrieren.

Hierfür einen großen Aufwand zu treiben würde ich auch nicht wollen. Finde es halt nur inkonsistent, dass die alten (!) Wetter-Icons stehen bleiben. Konsistenz könnte ja auch dadurch hergestellt werden, dass die alten (!) Wetter-Icons entfernt werden

[Parallix]

Apropos unsinnige Daten:

Kannst du erläutern was genau unsinnig ist?

SOC=100% und Ladeempfehlung?

[DS_Starter]

Konsistenz könnte ja auch dadurch hergestellt werden, dass die alten Wetter-Icons entfernt werden

Nö, das wurde ja schon mit entsprechenden Aufwand integriert und muß auch nicht raus.
Es muß ja auch auch nicht alles gleich aussehen. 
Und vielleicht habe ich ja auch noch Lust diesen Aufwand zu treiben, kann ich jetzt noch nicht sagen ...
Kommt immer darauf an, ob es vielleicht noch mehr Interessenten gibt was den Aufwand dann rechtfertigen würde.

[DS_Starter]

SOC=100% und Ladeempfehlung?

Das habe ich mir fast gedacht. 
Der aktuelle SoC ist für sich genommen kein Kriterium für eine Ladeempfehlung. Man könnte auch besser Ladefreigabe dazu sagen.
'Ladeempfehlung' fand ich aber weniger drastisch.
Wann die Ladeempfehlung (bzw. Ladefreigabe) gesetzt wird, liest du im Wiki.

[Parallix]

SOC=100% und Ladeempfehlung?

Das habe ich mir fast gedacht. 
Der aktuelle SoC ist kein Kriterium für eine Ladeempfehlung. Man könnte auch besser Ladefreigabe dazu sagen.
'Ladeempfehlung' fand ich aber weniger drastisch.

Ja, in der Tat liegt's am Wording. Ladefreigabe wäre mir sofort klar gewesen

[DS_Starter]

Ja verstehe ich. Vielleicht gibt es noch ein deutlich besseres Wort für diesen Sachverhalt.
Gerne mal darüber sinnieren ...

[Parallix]

Ja verstehe ich. Vielleicht gibt es noch ein deutlich besseres Wort für diesen Sachverhalt.
Gerne mal darüber sinnieren ...

Eine Empfehlung zum Laden des Akkus sollte dann nicht gegeben werden, wenn

• Netzbezug vorliegt (wg. ansonsten fehlendem netzdienlichen Verhalten)
• Zu wenig Überschuss vorliegt, da es dann schnell zum Netzbezug kommen kann (wg. nicht perfekter Regelung, vorgeschriebene max. Anstiegsraten)
• Der Akku zu lange auf einem unnötig hohem SOC-Level stehen bleiben würde (wg. drohende Zelldegeneration)

Vor diesem Hintergrund schlage ich vor, den "Ladeempfehlung" durch "Unbedenklichkeit einer Ladung" bzw. "Ladeunbedenklichkeit" zu ersetzen.

Warum (egal welches Wort verwendet wird) ein unnötig zu lange zu hoher SOC hier unberücksichtigt bleiben soll, erschließt sich mich derzeit noch nicht. Um den Aufwand gering zu halten, könnte man diese Größe zur Not auch durch ein optionales anzugebendes (vorläufig externes) binäres Reading berücksichtigen, das die rein durch den Akku bedingte Unbedenklichkeit einer Ladung angibt.

[DS_Starter]

Eine Empfehlung zum Laden des Akkus sollte dann nicht gegeben werden, wenn

Der Akku zu lange auf einem unnötig hohem SOC-Level stehen bleiben würde (wg. drohende Zelldegeneration)

Das wird durch die SoC-Optimierung gemacht sofern man sie aktiviert.

Netzbezug vorliegt (wg. ansonsten fehlendem netzdienlichen Verhalten)

Das macht üblicherweise schon die Steuerung des Herstellers. In manchen Fällen wird ein Zwangsladen aus dem Netz empfohlen/vollzogen wenn der SoC zu tief gefallen sein sollte.

Zu wenig Überschuss vorliegt, da es dann schnell zum Netzbezug kommen kann (wg. nicht perfekter Regelung, vorgeschriebene max. Anstiegsraten)

Wird im Prinzip berücksichtigt. Ein gewisses Überregeln kann und wird passieren. Es gibt sogar Vorgaben dass bei einer Nulleinspeisung der Hersteller eine Überregelung, ich glaube innerhalb 10 Min., wieder einregeln muß. Können auch weniger Min. sein, weiß ich jetzt nicht aus dem Kopf.

"Ladefreigabe" halte ich inzwischen für eine gute Variante weil es jeder gleich versteht wie du selbst geschrieben hast.

[Parallix]

Wäre es möglich, derart unsinnige Fälle (House-Consumption < 0) im Modul zu erkennen und dann nicht weiter zu verarbeiten, sodass Sie dann weder in der Grafik angezeigt werden und auch gar nicht erst ins Forecast einfließen?

Das ist ein zweischneidiges Schwert. Technisch kann man alles mögliche unterdrücken und teilweise mache ich es auch in bestimmten Fällen.
ABER, und das möchte ich beibehalten, wird man dadurch auf Fehler im Setup und/oder fehlerhaft gelieferte  Daten der Datenlieferanten aufmerksam und kann bzw. sollte die Sache bereinigen.
Nichts geht über eine gute Inputdatenqualität!

Dass nichts über eine gute Datenqualität geht, dass kann ich nur unterschreiben. Wie vorliegend, hat man das aber nicht immer in der Hand oder man muss schon einen extremen Aufwand treiben, um gesichert stets saubere Daten zu haben. Dass eine Fehler- bzw. Warnmeldung im Falle eines unsauberen Anlieferns von Daten geliefert wird, das finde ich nicht nur sehr in Ordnung, sondern sogar absolut wünschenswert. Dass offensichtlich fehlerbehaftete Daten aber einfach weiter prozessiert werden, halte ich für sehr problematisch.

[DS_Starter]

Dass offensichtlich fehlerbehaftete Daten aber einfach weiter prozessiert werden, halte ich für sehr problematisch.

Ja ist es. Nur kann das Modul nicht immer als regulierende Instanz aufteten und alle Input-Fehler ausbügeln. Das sehe ich nicht als dessen Aufgabe.
Allerdings werden fehlerhafte Input-Daten nicht für die weiteren Prognoseberechnungen gespeichert. Sichtbar als "aktuelle Daten" sind sie schon.

In deinem speziellen Fall sollte man sich das mal anschauen um zu erkennen woher das Problem kommt denn Vermutungen helfen nicht wirklich. Vllt. hat ein Datenlieferant (Device) ein Problem welches dort gerichtet werden muß.
Wahrscheinlich hilft hier ein "set ... ctrDebug collectData". Das können wir uns mal anschauen.
Ist halt etwas aufwändig wenn es nur sporadisch auftritt, Debug schreibt jede Menge Daten.