76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Wolle02]

Moin Heiko,

ich will dir natürlich Dein Fhem-frei gönnen. Das hast du Dir auch wahrlich redlich verdient. Ist schon toll, was Du hier auf die Beine gestellt hast. Vielen Dank nochmal an der Stelle.

Ich hab aber noch ein kleines Wehweh bei mir mit dem ich etwas rumhadere. Ich glaube wir hatten das Thema auch schonmal kurz angeschnitten, aber ich habe es auch wieder etwas aus den Augen verloren. Ist also nichts systemkritisches.
Es geht um den Zeitpunkt wann der Battery_OptimumTargetSoC_01 bei mir immer aktualisiert wird. Es gab mal eine Zeit da hat das toll funktioniert, so wie ich das aus der Dokumentation und Deinen Erläuterungen im Hinterkopf hatte. Nämlich, dass der Battery_OptimumTargetSoC_01 zum Ende eines jeden Sonnentages aktualisiert wird, je nach Prognose des zu erwartenden Solarertrages, um Platz in der Batterie für die Aufnahme zu schaffen, und/oder je nach dem wie die Einstellungen für low, up und maxSOC gewählt sind und ob der BatterieSOC im Laufe des Tages maxSOC erreicht hat oder nicht (jeweils In- oder Decrementierung um 5%).
Das hatte alles gut funktioniert und am Ende des Sonnentages wurde bei mir Battery_OptimumTargetSoC_01 neu eingestellt.

Seit einer gewissen Zeit funktioniert das leider gar nicht mehr zuverlässig am Ende eines Sonnentages, sondern hin und wieder unregelmäßig, aber hauptsächlich findet die Aktualisierung nachts um 00:00 Uhr statt. Das ist blöd, weil die Batterie dann manchmal schon zu weit entladen wurde und es dadurch bei mir zu Zwangsladungen kommt.
Ich habe heute Nacht mal ein Debug laufen lassen. Hier ist das Ergebnis (ich habe das Log als Dokument hochgeladen, weil sonst das Forum streikt)


Kannst du da eventuell mal drüber schauen, ob Du hier einen Grund erkennst warum das so ist?

Ich habe auch mal die KI befragt und sie gab mir als Ergebnis folgendes mit auf den Weg:

Der entscheidende Auslöser liegt in der Art und Weise, wie das Modul den Referenztag ("Gestern") bestimmt, um die historischen Daten (z.B. batmaxsoc, also ob die Batterie voll wurde) abzurufen.

Im Code (innerhalb der Logik, die die "SoC Step1"-Ausgaben erzeugt, vermutlich _batSocTarget oder _batChargeMgmt) wird der Vergleichstag wie folgt definiert:

Perl
# Auszug aus der Logik (Snippet 22/23)
my $yday = strftime "%Y-%m-%d", localtime($t - 86400); # Datum gestern
my $batymaxsoc = HistoryVal ($name, $yday, 99, 'batmaxsoc'.$bn, 0); # gespeicherter max. SOC des Vortages
my $batysetsoc = HistoryVal ($name, $yday, 99, 'batsetsoc'.$bn, $lowSoc); # gespeicherter SOC Sollwert des Vortages
Das Datum $yday wird berechnet, indem von der aktuellen Zeit ($t) exakt 24 Stunden (86400 Sekunden) abgezogen werden.

Was passiert beim Tageswechsel?
Um 23:59:XX Uhr (Tag A):

$t - 24h verweist auf Tag A minus 1 (Vorgestern).

Das Modul prüft also die Performance von Vorgestern, um das Ziel für "Heute" (Tag A) zu bestätigen.

Ergebnis im Log: Target: 55 % (Dies ist das Ziel für den noch laufenden Tag A).

Um 00:00:00 Uhr (Tag B):

$t - 24h springt jetzt auf Tag A (Gestern, der gerade zu Ende ging).

Jetzt erst greift das Modul auf die Daten des soeben beendeten Zeittages zu (wurde maxSoC erreicht?).

Basierend auf diesem neuen Referenztag wird das Ziel für den neuen Tag B berechnet.

Ergebnis im Log: Target: 50 % (Das Modul hat vermutlich erkannt, dass die Batterie am Tag A voll wurde, und senkt das Ziel für Tag B).

Zusammenfassung
Das Verhalten ist im Code hardcodiert. Der Wechsel der Berechnungsgrundlage findet mathematisch zwingend um 00:00 Uhr statt, da sich erst zu diesem Zeitpunkt das Datum von heute - 24h ändert.

Das Reading Battery_OptimumTargetSoC repräsentiert das Ziel für den kalendarischen Tag. Würde es sich bereits zum Sonnenuntergang ändern, würde das für den Rest des Abends ein falsches Ziel (nämlich das für morgen) anwenden, was ungewollte Regelungen (z.B. Entladestopps) am späten Abend zur Folge haben könnte.

Fazit: Das Verhalten ist technisch korrekt ("Design Intent"), da das Ziel immer für den aktuellen Kalendertag gilt. Dass der Wert um 00:00 springt, ist die direkte Folge des Datumswechsels in der Variable $yday.

Vielen Dank für Deine Mühe.

Gruß
Wolle

[klaus.schauer]

Ich habe comforttemp nun so erweitert, dass in dem Schlüssel alternativ eine Device:Reading Kombi angegeben werden kann:

comforttemp   
Solltemperatur (Komforttemperatur) in den Innenräumen in °C (Pflichtangabe).
Der Wert kann fest gesetzt oder durch eine <Device>:<Reading>-Kombination geliefert werden:
<Device>:<Reading> - die Device/Reading Kombination liefert die Temperatur
Wertebereich: -40..40

Update liegt im contrib.

@Klaus,

Wäre dennoch irgendwie praktischer. Jetzt sehe ich zweimal täglich, dass die cfg geändert wurde. Ist aber ein Komfortproblem, zugegeben.

Die Änderung ist über das rote Fragezeichen nur sichtbar, wenn man im global Device explizit autosave=0 gesetzt hat. Sonst erfolgt die Änderung völlig transparent ohne diese Signalisierung.

Das ist hier wie im Wunderland. Kaum hat man einen Wunsch, geht er schon in Erfüllung.

Danke dafür

[300P]

@300P, wäre deine Info nicht etwas für das Wiki als Unterpunkt in diesem Bereich? Sonst gehen solche wertvollen Beiträge/Informationen leicht unter.

Hallo Heiko,

eine schöne Auszeit für Dich - ist auch angebracht bei deinem Arbeitsvolumen
->> Viel Spass und Ruhe in der Zeit !!!🛫🧳🏨🏖🧳🛬

Und -Ja- wenn es okay, ist mach ich das mit dem Wiki evtl. schon heute Abend - bin grad mit der WaMa fertig - neue Dämpfer und neu Federn eingebaut - Abendessen und dann rein damit.


PS:
Meine selber programmierte SF-ADDON - WP-Einzellösung war die letzte Woche bei einer Genauigkeit von ca. +/- 7 % (CON).
Da das ja nun nicht triumphmäßig besser von der "Standart"-Lösung liegt bin ich heute morgen wieder zurück auf den SF-Standart.       

..nochmals : Dir eine schöne Zeit......

[DS_Starter]

Hallo Wolle,

ich werde in der Version beim Checkin das Debuglog erweitern um weitere Antworten auf Fragen zu bekommen die mir im Kopf herumgehen.

Unter anderem dürfte der SollSoc m.M. nach nicht von 55% am 17. auf 50% am 18. zurückfallen, da ja bereits am 17. ein Soll von 55% bestand.
Ich würde dir raten stepSoC auf 2 oder sogar 1 zu setzen. careCycle muß dann entsprechend der Online-Hilfe auch angepasst werden.

LG,
Heiko