Zitat von: frober am 12 Dezember 2025, 13:36:06Bei einem userReading gibt es standardmäßig kein Event, da die Gefahr zu groß ist, das es sich selbst triggert.?
Zitat von: erwin am 12 Dezember 2025, 13:50:20Um die Verwirrung noch zu ergänzen:![]()
Bei einem AT hat das doppelte semicolon noch eine zusätzliche Bedeutung, siehe: wiki , daher je nach dem auch 4 semicolons nötig....
l.g.erwin

Zitatkann man eigentlich den Zeitpunkt an dem der OTP-SoC neu berechnet und eingestellt wird irgendwo einstellen oder fixieren?Der opt. SoC wird ständig neu berechnet, aber erst nach der halben Strecke zwischen Sonnenauf- und Untergang aktiviert sofern der neue SoC höher als der alte Sollwert ist. Die care Zeit spielt auch noch eine Rolle.
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> today -> PV fc: 859 Wh, con till sunset: 1884 Wh, Surp: -1025 Wh
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> tomorrow -> PV fc: 4704 Wh, con till sunset: 13906 Wh, Surp: -5726 Wh (75% con)
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> selected energy for charging (the higher positive Surp value from above): 0 Wh
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> expected energy for charging after application Share factor: 0 Wh
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 45 %
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 0 Wh, need until maxsoc: 1421 Wh
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 10 %, remain days until care SoC: 19, Target: 45 %
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step3 Bat 01 - basics -> max SOC so that predicted PV can be stored: 100 %, newtarget: 45 %
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 0, Target: 45 % (no change)
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step4 Bat 01 - basics -> docare: 0, lowSoc: 10 %, upSoc: 50 %
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 45 %
2025.12.12 13:22:09.016 1: SolCast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 45 %
2025.12.12 13:22:09.016 1: SolCast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)
ZitatAm Anfang war er zum Ende des Sonnentages, so um den Sonnenuntergang herum, dann war er plötzlich um Mitternacht und aktuell ist er morgens um halb sechs. Das führt dazu, dass die Batterie dann Nachts plötzlich auf einen bestimmten SoC-Wert entladen wird, nur um dann ein paar Stunden später mittels Zwangsladung aus dem Netz wieder auf einen neuen SoC geladen zu werden.Wenn ich dich richtig verstehe, steht die Batterie morgens durch die Entladeprozesse auf dem gesenkten Soll-SoC. Das ist richtig, weil erwartet wurde, dass die Batterie über den kommenden Tag wieder aufgeladen wird.
Zitat von: passibe am 12 Dezember 2025, 13:33:30Das hier ist doch gar kein Gast?Ich habe es nur geschrieben, da das gleiche auch bei einem Gast sein könnte und es somit zusammenhängend ist.Zitat von: Marko1976 am 09 Dezember 2025, 19:16:34TYPE ROOMMATE