76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[tomcat.x]

Den Parameter hatte ich dann wohl nicht richtig verstanden, als ich ihn vor längerer Zeit beim Hinzufügen des Speichers gesetzt hatte. Sonsts wären mir auch die 90 % klar gewesen. Mit 50 sieht es besser aus. Aber eigentlich macht das auch keinen Sinn, wenn ich das gar nicht regeln will. Hatte dann erst stepSoC=0 gesetzt, aber schließlich das Attribut komplett enfernt. Macht das einen Unterschied?

Aber ich glaube, bei mir steht noch was schief. Vor Deiner Antwort hatte ich die Balkengrafik erweitert, um die Verbrauchsvorhersage besser sehen zu können. Die Balken für consumptionForcast sehen gut aus, aber consumption ist tagsüber zu niedrig, in der Zeit wenn Strom erzeugt wird.

Nur zum Verständnis, consumptionForcast soll den Verbrauch aller Verbraucher vorhersagen, nicht nur der registrierten? Und consumption entsprechend den realen Verbrauch aller Verbraucher in Sunne anzeigen, egal wo der Strom herkomnt? Die Balken bei gridConsumption sollten dann in Zeiten ohne PV-Erzeugung und ohne Strom aus der Batterie mit denen von consumption übereinstimmen?

[300P]

Nur zum Verständnis, consumptionForcast soll den Verbrauch aller Verbraucher vorhersagen, nicht nur der registrierten?

Ja

Und consumption entsprechend den realen Verbrauch aller Verbraucher in Sunne anzeigen, egal wo der Strom herkomnt?

Ja

Die Balken bei gridConsumption sollten dann in Zeiten ohne PV-Erzeugung und ohne Strom aus der Batterie mit denen von consumption übereinstimmen?

Ja

Einschränkung : Es kann möglicherweise "Überlappungen" geben - es wird in SF alles auf eine volle Stunde dargestellt / bezogen !!

[DS_Starter]

Moin,

Aber eigentlich macht das auch keinen Sinn, wenn ich das gar nicht regeln will. Hatte dann erst stepSoC=0 gesetzt, aber schließlich das Attribut komplett enfernt. Macht das einen Unterschied?

Wenn du das Attribut entfernst und die Batterie nicht aktiv durch SF steuerst bekommst du auch keine schlüssige Batterie SoC Vorhersage da SF Grenzwerte und die Steuerung durch dein BMS bzw. deine Batterieanlage nicht kennt.

Wenn du das nicht brauchst/möchtest kannst du das Attr löschen, darfst dann natürlich keine sinnvolle SoC-Prognose erwarten.

Einschränkung : Es kann möglicherweise "Überlappungen" geben - es wird in SF alles auf eine volle Stunde dargestellt / bezogen !!

Und nicht nur das.
Die Wertelieferanten (Zählerdevices etc.) in FHEM laufen nicht synchron. D.h. die diversen Summierungen sind zum Zeitpunkt X in den seltensten Fällen exakt stimmig oder heben sich exakt zu "0" auf.

[tomcat.x]

Ist schon klar, dass die Werte nicht hundertprozentig übereinstimmen, aber die Richtung sollte passen. Das ist auch für letzte Nacht so (kein PV, Batterie auf 10 % runter). Auch jetzt in den Morgenstunden ergibt PV + Grid zusammen ungefähr das, was der Balken bei consumption anzeigt. Gestern tagsüber war der Balken aber teilweise unter 10 Wh. Das dürften die Stunden gewesen sein, als die Batterie ins Spiel kam. Ich werde das mal heute beobachten. Wobei es schon seltsam ist, denn wenn der Verbrauch nicht richtig ermittelt würde, dürfte auch die Verbrauchsvorhersage nicht passen. Das tut sie aber. Wie gesagt, habe ich consumption + consuptionForecast erst seit gestern in der Balkengrafik und vorher nie drauf geschaut (auf die stündlichen Verbrauchswerte in SF).

Wenn du das nicht brauchst/möchtest kannst du das Attr löschen, darfst dann natürlich keine sinnvolle SoC-Prognose erwarten.

Ja, ich habe schon gesehen, dass der SoC dann teilweise mit unter 10 % vorhergesagt wird, was die Batterie aber gar nicht macht. Also dann Werte eintragen, aber stepSoC=0? Denn nur so kann ich erreichen, dass lowSoc=upSoC ist und SF nicht davon ausgeht, die Batterie steuern zu können. Denn das kann es nicht. Weder kann es der Batterie sagen, ob sie laden soll oder nicht, noch gibt es relevante Verbraucher, über die das beeinflusst werden könnte.