Danke für die ausführliche Antwort. Ist andere Liga 
1 „Gefällt mir“
Sehr gern! Wie gesagt je nach dem wie Simon und / oder die Admins das sehen werde ich entscheiden ob ich diesen sehr spezillen Teil hier weiterführen werden. - hat eben nicht wirklich was mit SFML, STATS, GPM, TFS-HA, ESC, .. zu tun.
DU nun wieder… aber ja richtige Konfiguration und ein wenig Geduld zaheln sich am Ende immer aus. Danke das Du solange dabei bist!
Ich warne Dich schon mal vor auf Grund des FIndings von @Johnny_1993 wird es auch heute Nacht noch ein Update geben
1 „Gefällt mir“
@Johnny_1993 .. und ich werde dich in dem Update-Release-Text erwähnen, deine Adresse, Telefonnummer, .. mit veröffentlichen damit jeder weiß vor welchem Haus er mit brennenden Fackeln auftauchen muss - wer schuld ist das es schon wieder ein Update gibt.. 
4 „Gefällt mir“
Passt, ich halt die Würstchen schon bereit zum grillen 
2 „Gefällt mir“
Vielleicht schaffe ich das heute auch noch, es kommt ja noch ein bisschen.
Gestern hat SFML es “nur” auf 99,7% geschafft und das auf einem Grundstück, welches rundherum und mittendrin mit hohen Bäumen bewachsen ist, deren Schatten ständig über die Module wandern…
Allerding verstehe ich nicht, was der Akku immer in der Auswertung soll. Ich hätte gerne einen Akku, aber warum der mir jetzt schon angezeigt wird, ist mir schleierhaft.
Edit: Na jetzt habe ich mich aber mit den Tagen vertan. Gestern war ja schon vorgestern und heute kommt erst noch. 
Kann ja mal passieren. 
Der Fehler ist behoben, bzw wieder zurückgedreht auf die ursprüngliche Version - der Code kümmert sich wieder um die Zeitzone.
ABER das bedeutet auch, dass nach dem Update die DB einmal korrigiert wird. - Nur zur Info!
Gruß Zara
1 „Gefällt mir“
Kannst du bitte, wenn es zeitlich passt, den selben Screen-Shot noch einmal um 20:10 (machen / posten) → wichtig mind 5 Min nach der Vollenstunde.
Danke
Mission accomplished!
Ach so, V. 28.0.4 - Update gegen 16:30 Uhr.
Zum Vergleich mit den anderen Ansagern:
Vielen Dank @Joachim-xo und @seebaer1976 .. ich prüfe mal ob das auch mit den “Time-Zone” Thema zu tun hat.. dann fixe ich das direkt mit.
Gefunden..
Sobald Überschuss eingespeist wird, weicht der Wert massiv vom IST-VERGLEICH ab, welcher sich aus der echten, unverfälschten PV-Erzeugung berechnet. Da hier ebenfalls der UTC-Fehler vorliegt, passt das vorne und hinten nicht zusammen und Hubble verwirft die “Einspeisung” so entsteht an der Stelle eine Differenz..
Ich fixe das direkt mit! MIST MIST MIST.. ich verspreche es nicht wieder ausserhalb meiens Codes berechnen zu lassen
HINWEIS: Hubble wird nach dem Update die DB korrigieren, da es sich ebenso auf Preisberechnungen, Aut. und alles andere auswirkt.. MIST MIST MIST
Kein Stress bitte! 
Ich würde mich freuen, wenn Du die Zusammenhänge erklären könntest und ob meine Auffassung korrekt ist. Denke, da wird in Zukunft noch der ein- oder andere drüber stolpern. Aktuell hat der Strompreissensor bei Smart Charging jedenfalls bei mir keine Auswirkung. Er zieht sich immer den von “Pricing”.
Ich habe daran schon einiges geändert, es gab ein Problem innerhalb von Home Assistant selber. Ich würde dich bitten, nachdem das Update heute Nacht veröffentlicht wird morgen mal zu schauen, ob das Thema behoben ist. Grundsätzlich ist es aber so, dass Smart Charge ausschließlich mit G PM zusammenarbeitet. Das hat ganz wichtige Gründe da auf Stundenbasis gerechnet wird. Das bedeutet es wird in der Statistik auch immer die Differenz zu dem Zeitpunkt, wann die im Akku gespeicherte Energie abgegeben wird zum aktuellen Strompreis berechnet das ganze passiert mit einer Mischkalkulation, um auseinanderhalten zu können, was es eingekaufteter Strom und was ist Solarenergie. Es wäre sonst rechnerisch falsc den gesamten Akku beziehungsweise die Entladung gegen den aktuellen Strompreis zum Zeitpunkt der Entladung zu rechnen.
Hallo @Tom-HA, Es hat etwas gedauert, aber einen kleinen Schritt bin weiter. Der build im entpackten Release-Archiv lief zunächst auf einen Fehler.
ERROR: failed to build: failed to solve: base name ($BUILD_FROM) should not be blank
Nach etwas Sucherei und intelligentem Raten habe ich die erste Zeile des Dockerfiles auf
ARG BUILD_FROM=ubuntu
geändert. Im HA-Kontext scheint das ARG schon “irgendwie” gesetzt zu sein. Danch lief der build über ~200 sec. und “docker image ls liefert das hier:
toorox_foresight_ha:latest 117c821bfb40 1.68GB 0B
Da ich ein zentrales docker-compose.yaml habe, ergänzte ich dort diesen Eintrag:
toorox-foresight:
#build: /home/tz/tsf/TFS-HA-SFML-Transformer-AI-28.0.0/toorox_foresight_ha
image: toorox_foresight_ha:latest
container_name: toorox-foresight
restart: unless-stopped
ports:
- "8780:8780"
volumes:
- /opt/toorox-foresight/data:/data
- ~/.ssh:/host_ssh:ro
environment:
- TFS_TIMEZONE_STR=Europe/Berlin
- TFS_LATITUDE=52,...
- TFS_LONGITUDE=9,...
- TFS_STATE_DIR=/config/toorox_foresight_ha
Mit
docker compose up -d toorox-foresight
kann ich auch einen container erzeugen:
tz@smart-nuc:/opt/homeassistant/config/solar_forecast_ml/logs$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d08c7adef07a toorox_foresight_ha:latest "/usr/bin/tini -- /a…" 2 seconds ago Up Less than a second 0.0.0.0:8780->8780/tcp, [::]:8780->8780/tcp
Der ist jedoch gewissermaßen “leer”. Er verbraucht keinen Speicher, keine CPU und macht kein I/O . Kein Wunder, denn portainer meldet, dass darin kein Prozess läuft. An dieser Stelle werde ich dann morgen mal weiter experimentieren. Mir scheint, dass im image irgendwie kein default ron-Kommando OSLT hinterlegt ist. Na, schaun mer mal ..
Das gewünschte solar_forcast_ml.log habe ich per PN hochgeladen.
Einstweilen Danke nochmal!
Weiß nicht; macht doch dafür einen eigenen thread auf.
1 „Gefällt mir“
Sehr guter Punkt @Joachim-xo → ist kein Problem zum Release sondern eine reine Support-Anfrage!
@thomasz kannst du bitte einen neuen Thread zu dem Thema aufmachen, dann verschwindet das Thema auch nicht
1 „Gefällt mir“
sollte nun erledigt sein, was wir heute besprochen haben
1 „Gefällt mir“
Guten Morgen,
hast du das Thema
”7 h Nullexport/Basislast, 1 h Akku-Curtailment”
noch auf dem Zettel?
Leider wird es nicht weniger. → bei mir aber nur auf dem Pi!
Gutes Ergebnis, aber Lernbasis liegt außerhalb der wichtigen Stunden.
hier von Gestern. → Stunde 09,10,11,12,13,14,15,16 sind nicht verrechnet.
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H09: actual=0.227 kWh, theoretical=0.408 kWh, reason=demand_limited_zero_export
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H10: actual=0.260 kWh, theoretical=0.540 kWh, reason=demand_limited_zero_export
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H11: actual=0.298 kWh, theoretical=0.634 kWh, reason=suspected_battery_curtailment
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H12: actual=0.479 kWh, theoretical=0.679 kWh, reason=demand_limited_zero_export
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H13: actual=0.306 kWh, theoretical=0.671 kWh, reason=demand_limited_zero_export
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H14: actual=0.283 kWh, theoretical=0.611 kWh, reason=demand_limited_zero_export
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H15: actual=0.225 kWh, theoretical=0.505 kWh, reason=demand_limited_zero_export
2026-06-16 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-06-16 H16: actual=0.190 kWh, theoretical=0.364 kWh, reason=demand_limited_zero_export
Vielen Dank für das Update. Bzgl. dem Problem mit Smart Charging hat sich bisher leider nichts verändert. Der Strompreissensor, den man bei den Einstellungen von Smart Charging auswählen kann, wird aktuell nirgends berücksichtigt. Im Smart Charging holt er sich bei mir immer den Marktpreis, so wie ich das sehe. Sollte er sich nicht den Strompreissensor ziehen oder für was ist der da? Das wäre meiner Meinung nach eine geniale Möglichkeit, für alle Tarife (also auch HT/NT, Börse usw.) ein smartes Laden zu ermöglichen.
Ich habe jetzt mal testweise in der Config von “Pricing” einen festen Tarif eingetragen (27 Cent, keine Gebühren und Steuern, nur noch Grundgebühr). Auch das wird nicht bei Smart Charging berücksichtigt.
Vielen Dank für die Aufklärung
PS: Noch eine kleine Frage: Wie und wann berechnet sich denn der Ziel-Soc? Der steht bei mir IMMER auf 6% - egal zu welcher Tageszeit und egal, wie viel im Akku ist…Ich benötige aber über Nacht eher ca. 70% des Akkus… Stromverbrauch / Tag ist korrekt in SFML