(Beitrag vom Verfasser gelöscht)
Verstehe ich jetzt nicht so ganz. In meinem Beispiel habe ich einen Octopus Tarif (Tag anders als Nachts). Habe einen Sensor mit aktueller Strom preis in Cent.
Den trage ich bei Smart Charging in SFML als Strompreissensor ein. Dann sollte der doch die Basis für die Berechnungen sein, oder nicht - also völlig unabhängig, was ich unter Pricing eingestellt habe.
Hallo @thomasz
Vorab: Ich unterstütze deinen Ansatz, Dienste wie TFS außerhalb von Home Assistant in separaten Container-Umgebungen laufen zu lassen, zu 100 %. Gerade heutzutage, wo viele Leute einfach Code von einer KI schreiben lassen, ohne wirklich zu verstehen, was dieser im Hintergrund eigentlich tut, ist das ein enormes Risiko. Ein externer Container minimiert dieses Risiko drastisch. Man kann ihn wesentlich besser überwachen, isolieren und monitoren – für mich ein echtes Sicherheits- und Datenschutzplus.
Ich halte das aus genau diesen Gründen schon von der ersten Stunde an so. Ich würde mir selbst niemals eine App oder ein Add-on von einem Entwickler, den ich nicht kenne, direkt auf mein Live-System holen. Das kann unter Umständen Selbstmord für die Datensicherheit sein und widerspricht der eigentlichen Grundidee von Home Assistant. Erst recht nicht, wenn diese App in der Lage ist, Daten nach außen zu senden oder wenn die Antworten auf Fragen leicht als AI-Slop zu erkennen sind - also der Entwickler nicht selber antwortet, sondern Fragen / Anmerkungen von einer KI beantworten lässt. Das ist immer ein sehr schlechtes Zeichen und legt die Vermutung nahe, dass er keine Ahnung davon hat was er eigentlich macht. Dadurch fehlt die menschliche Kontroll-Instanz über den Code komplett.
Weiterhin bitte ich sogar darum, Entwickler TFS HA in einem separaten Container laufen zu lassen und genau zu monitoren um sicherzustellen das da nichts “krummes” vor sich geht und nichts nach Hause telefoniert. Es gab hier mal einen User @Spatz dem dieser Punkt, genau wie mir sehr wichtig gewesen ist und der etwas davon verstanden hat. Leider war er schon lange nicht mehr aktiv! Also ich bitte Dich hiermit ausdrücklich, mir jede Auffälliglkeit direkt zu melden, gern auch öffentlich, das ist ein Qualitätscheck dem ich mich gerne stelle!
Deshalb ist TFS HA im Kern auch ein völlig eigenständiger FastAPI-Webservice (der standardmäßig auf Port 8780 läuft). Das HAOS-Add-on ist lediglich ein komfortabler Wrapper.
Für dein Standalone-Docker-Setup bedeutet das konkret:
- Datenbank-Volume teilen: TFS benötigt direkten Lesezugriff auf die SQLite-Datenbank von SFML. Du musst das
/config-Verzeichnis deines HA-Containers also zwingend als Volume in den TFS-Container mounten (standardmäßig wird der Pfad/config/solar_forecast_ml/solar_forecast.dbabgefragt). - Konfiguration über Umgebungsvariablen: Da im Standalone-Docker die
options.jsondes HA-Supervisors fehlt, konfigurierst du TFS einfach über Umgebungsvariablen mit dem PräfixTFS_(z. B.TFS_LATITUDE,TFS_LONGITUDE,TFS_TIMEZONE_STR="Europe/Berlin",TFS_STATE_DIR="/config/toorox_foresight_ha"). - Ganz wichtig (Netzwerk): Da die TFS-Verbindungsadresse in der SFML-Integration fest auf
http://127.0.0.1:8780verdrahtet ist und nicht im UI geändert werden kann, muss dein Home Assistant Container zwingend im Host-Netzwerkmodus (network_mode: host) laufen. Nur so kann der HA-Container den Port8780des TFS-Containers über Loopback erreichen.
Zu den Diagrammen für die Panelgruppen: Das STATS-Dashboard liest die stündlichen Modulgruppen-Prognosen stattdessen direkt aus der Tabelle prediction_panel_groups in der solar_forecast_ml.db aus.
Wenn deine HA-Docker-Umgebung Probleme mit den SQLite-Dateisperren hat (was die Database is closed-Fehler im Log erzeugt), kann auch STATS die Daten nicht auslesen. Sobald das Dateisystem-Locking auf deinem Docker-Host sauber funktioniert, fließen die Daten auch ins Dashboard. Am Code der Integration selbst werde ich hierzu nichts ändern, da die DB-Zugriffe sauber implementiert sind und das Problem auf Dateisystem-Ebene liegt.
PS: Soll ich Dir das noch einmal in Englisch auf GIT schreiben, oder reicht Dir das hier? Ich würde Issue dann closen!
1 „Gefällt mir“
Das war ja salmunia´s Thema mit den Sensor, ich hatte da nur meine Gedanken zu abgegeben.
Mein Thema findest du hier.
und ich habe überall brav GPM als Quelle eingetragen, daran sollte es eigentlich nicht liegen. 
2 „Gefällt mir“
Du hast recht.. SORRY!! Ich habe schnell in der Mittagspause geantwortet und mich vertan - es vermischt - ! Reicht es dir wenn wir das Thema nach Feirabend (heute Abend) noch einmal gründlich angehen?
Du solltest dir auch einmal das Thema von thomasz anschauen, sowie ich das verstehe hat er alles korrekt konfiguriert, aber er bekommt die einzelnen Panel-Graphs nicht angezeigt. Ich bin hier mit meinem Latein am Ende. Und auch andere scheinen hier nicht zu finden, was wir übersehen haben.
Gruß Ralf
1 „Gefällt mir“
Vielen Dank Ralf,
das mache ich heute Abend nach Feierabend. Ich vermute es ist ein Zugriffsproblem. Er hat HA als Docker-Version laufen. Das birgt einige Probleme, zum Beispiel kann er keine Apps installieren, muss Dinge selbst konfigurieren. Ich werde mir das mit @thomasz heute abend mal in ruhe anschauen. -ist keine standart installtion von HA wie bei 99% der Nutzer. Seine Gründe dafür hat er sehr klar auf Git und hier dargelegt.. ich muss da tiefere einsteigen.
Ich habe gesehen, dass du versucht hast zu helfen, vielen Dank dafür " Kaffee für Dich" .. ich bin aber aktuell auf der Arbeit und kann nur “rudimentär” / “nebenbei” antworten. Sein Problem braucht aber eine tiefere Analyse.
1 „Gefällt mir“
bitte schreibe mir mal im Detail deine Installtion, was Du unternommen hast und im idealfall schick mir mal dein SFML LOG (config/solar_forecast_ml/ logs. - bitte via PN. Ich schaue es mir dann heute Abend in Ruhe an und komme auf dich zurück. Das ist der Beste Ansatz.
Moin @Tom-HA , danke für Deine fixe und ausführliche Antwort!
Zusätzlich zur isolierten Ausführung des Containers und der dadurch erhöhten Sicherheit gibt es aus meiner Sicht auch ein viel bessere Resourcennutzung. Zuerst hatte ich HA in einer vbox laufen. Da ist immer gleich eine feste Portion CPU und RAM verbraucht. Außerdem war es nicht stabil. Wenn ein Dienst wie der systemd immer wieder mal ein SigSeg produziert, stimmt irgendwas mit dem Packaging des Linx nicht …
Da HA config Verzeichnis ist außerhalb von HA erreichbar und HA läuft im network-mode host, das passt also. Die Umgebungsvariablen werde ich auch irgendwie hinbekommen.
Da mein docker Wissen erst sehr rudimentär ist, weil ich mich erst seit wenigen Monaten damit befasse und auch nur auf Basis fertiger container aus dem docker repo, werde ich etwas Zeit benötigen, um aus dem tar.gz einen lauffähigen, lokalen container zu erzeugen. Ich bitte daher um Verständnis, wenn erste Ergebnisse länger auf sich warten lassen.
Ich habe mir gerade mal V28.0.0.tar.gz herunter geladen und nach Hinweis von googles Raumkapsel ein “docker import” ohne Fehlermeldung hinbekommen, aber starten tut es nicht. Da werde ich erstmal ein wenig RTFM praktizieren müssen. Aber auf jeden Fall werde ich da am Ball bleiben und berichten.
Das Github issue kannst du gerne so lassen, wie es ist. Ich habe den Eintrag nur gemacht, damit die Info nicht verloren geht.
Und da das issue zwischendurch bei neueren Versionen komplett verschwunden war, habe ich meine Zweifel, dass das OS mit dem file locking ein wirkliches Problem hat (Ubuntu 24.04.4 LTS auf Intel Core i5-7260U 7. Gen Kaby Lake). Ein generisches Problem sollte IMO auch “zufälliger” auftreten, und nicht nur genau jedes Mal beim Update der Wetterdaten. Da es aber eher ein Schönheitsfehler ist, würde ich da zunächst auch keinerlei Aufwand reinstecken.
Die Tabelle prediction_panel_groups werde ich mir mal anschauen, aber erst später, weil ich jetzt erst mal was anderes machen muss …
Gruß
Thomas
1 „Gefällt mir“
Moin @thomasz, (etwas OT NERD-TALK -aber für deinen Kontext wichtig)
Du triffst da bei mir genau den Nerv. Ich komme ebenfalls aus der Linux-Ecke. Eine komplette VM mit eigenem Gast-Kernel aufzusetzen, nur um eine Python-App wie Home Assistant laufen zu lassen, ist schließlich so, als würde man ein ganzes Containerschiff chartern, um ein einzelnes Paket zu liefern.
VirtualBox (oder generell eine voll emulierte VM auf Proxmox) für ein 24/7 Smart Home zu nutzen, ist wie ein Auto zu fahren, bei dem man alle 10 Kilometer den Motor aus- und wieder einbauen muss – das zwingt das System völlig unnötig in die Knie.
Ich werde es wohl nie verstehen, warum gefühlt 90 % der Nutzer Proxmox / VM für Home Assistant völlig falsch nutzen und eine schwere KVM-VM (mit HAOS) aufsetzen. Die Virtualisierung in einer klassischen VM schleppt immer enormen Overhead mit sich herum.
Der korrekte Weg (persönliche Meinung)
Home Assistant als Container (entweder als Docker in einem unprivilegierten LXC oder als direkter LXC-Systemcontainer) ist die absolute Königsklasse - gerade auf NAS oder Proxmox. Erst damit spielt man die eigentliche Stärke von Proxmox / NAS – die native Container-Virtualisierung – voll aus. Man teilt sich den Kernel mit dem Host und spart massiv RAM und CPU-Overhead ein. Die bequemen HAOS-Funktionen (wie Supervisor und Add-ons) verliert man zwar, gewinnt dafür aber die volle Kontrolle über das System. Proxmox-seitige Backups / VM Backups (Snapshots) funktionieren ja trotzdem perfekt. Natürlich erfordert dieser Weg ein grundlegendes technisches Verständnis, aber es lohnt sich und ist aus technischer Sicht der korrekte Weg.
Zu deinen ersten Docker-Schritten und dem TFS-Start: Dass der Container nach dem docker import nicht startet (da hat dich die „Raumkapsel“ leider auf den falschen Pfad geschickt 
), liegt an der Methode. docker import ist für bereits exportierte Container-Dateisysteme gedacht, importiert das Archiv aber ohne die im Dockerfile hinterlegten Metadaten (wie den Entrypoint run.sh und die Standard-Umgebungsvariablen).
Ich rate dringend von Claude, Codex (ChatGPT), Gemini für solche tiefen Fragen ab. Nimm lieber Grok, um zu lernen / verstehen, wie es geht.
Da TFS ein fertiges Dockerfile mitbringt, musst du das Image selbst bauen. Entpacke einfach das Release-Archiv (V28.0.0.tar.gz), wechsle im Terminal in den Ordner toorox_foresight_ha (wo das Dockerfile liegt) und baue das Image auf deinem Host mit:
docker build -t toorox_foresight_ha
Danach kannst du den Container ganz normal mit deinen Umgebungsvariablen und Volume-Mounts starten.
Das GitHub-Issue lasse ich offen, kein Stress.
Bezüglich des File-Lockings unter Ubuntu:
SQLite nutzt das standardmäßige POSIX-Locking des Betriebssystems. Wenn das HA-Config-Verzeichnis lokal liegt und die Rechte (UID/GID) stimmen, läuft das meist sauber.
Viel Spaß beim „Basteln“ und „Lernen“… Du wirst sehen, dass es Spaß macht und die coolste / richtige Art und Weise für Proxmox, VM, NAS, .. ist und einer nativen Installation überlegen ist. Besonders bei Performance, Sicherheit und Stabilität.
HA kommt ursprünglich aus dieser Ecke und hat seine Wurzeln niemals aufgegeben. Daher ist die Bare-Metal-Installation auch auf einem „kleinen Linux“ aufgebaut.
Vergiss den ganzen VM / Proxmox Virtualisierungskram in einer klassischen VM – das ist aus Entwickler- und technischer Sicht (persönliche Meinung) totaler Unfug.
PS: Das wird noch einmal ein spannendes Thema, wenn ich TFS Docker standalone Ende dieser oder nächhste Woche release. Das läuft aktuell im Testbetrieb perfekt auf VM, Proxmox, Linux, Mac.. ein mächtiger Transformer mit pytorch und neusten Technologien und einem großen von mir trainierten Modell.
Es wird vermutlich eine Menge Diskussionen geben, da er seine stärken auch unter Proxmox voll auspielt aber will man ihn an HA anbinden.. bedarf es eben HA als Docker. Da sind dann alle Proxmox-Nutzer die Ha als VM laufen haben raus, sofern sie nicht verstehen wie Virtualisierungen und Container im Kern funktioineren. Ich überlege daher bereits es lieber in einem Linux-Forum zu releasen.
Zara
Kein Ding, passiert jeden mal
Nach Feierabend ist vollkommen ausreichend 
1 „Gefällt mir“
Hallo @nightrunner
Kannst Du bitte mal das letzte Update von heute morgen 3 Uhr installieren? Das sollte das Problem beheben.
Ok, ich glaube, ich kann das Problem, dass geladen wird obwohl der Preis über der Preisschwelle liegt, eingrenzen.
Für 00:00 Uhr und 01:00 Uhr liefert GPM keinen Wert.
Und das war heut Nacht auch so, als der Geladen hatte, wenn ich mich recht entsinne.
Sozusagen müsste man Smart Charging dagegen absichern, das es nicht auslöst wenn kein Preis verfügbar ist.
Super FINDING!!! Respekt!!!
Also der Code ist dagegen abgesichert, das Problem liegt bei hass.config.time_zone also dem Zeitmanagement von Home Assistant. Er schreibt UTC und wandelt dann in local um (theoretisch). → da scheint was nicht zu stimmen.. ich hatte eine Anpassung vorgenommen und der Code verlässt sich seit 28.0 wieder auf hass.config.time_zone das war offensichtlich ein Fehler, so ist es nun “verschoben” so entsteht die Lücke in dem Diagram und auch fehlende Daten.
Ich werde das heute Abend in Ruhe zurückbauen und den Code die Zeitzone wieder selber berechnen lassen.. MIST MIST MIST.. ich dachte ich könnte es mir ein wenig einfacher machen und HA es überlassen → das war ein Fehler.. MIST MIST MIST..
Danke @Tom-HA ,
habe ich erledigt.
Inzwischen muss man ja 24/7 die updates überwachen 
1 „Gefällt mir“
Das ist die „Große KI“ – die läuft nicht unter Home Assistant und auch nicht auf „kleinen Systemen“! Es ist ein 8-Head-Transformer mit selbst trainiertem Modell (18 Jahre Wetterdaten in 5-Minuten-Schritten für 165 Standorte in DE / AT / CH und 15 Jahre Klimadaten).
Mit einer selbstlernenden Logik, die weit über SFML hinausgeht, und 18 separaten Wetter-Features, die ohne externe Sensoren nicht funktionieren… das ist also eine völlig andere Klasse als das, was mit Home Assistant möglich ist.
Auch ein lokales LLM ist mit von der Partie. Es wurde von mir angepasst, um mit meiner KI zusammenzuarbeiten und Fragen zu Wetter, Prognose, Ausblick oder Problemen im Chat zu beantworten. Es verbindet sich von allein mit der Anker-Cloud, ModBus, MQTT oder via SSH mit HA, um dort die Daten zu holen.
Zudem unterstützt es CUDA, was für das Training und den Chat auch dringend empfohlen ist (mindestens 4 GB VRAM sollten es schon sein). Kurzum: Das ist nicht Home Assistant, sondern eine komplett andere Liga. Aktuell läuft alles ausschließlich über Docker – wobei ich gerade ein eigenes Linux auf Basis von Ubuntu baue, wo es direkt inkludiert ist.
Ich denke, dass ich das Projekt auch nicht hier in Simons Forum weiter behandeln werde. Es ist zwar eine Anwendung die HA Daten auslesen und zurückübergeben kann.. aber keine reine HA oder Smart-Home Lösung.. eine Grauzone. Mal sehen was Simon dazu meint oder ode Admins hier.. -
das liegt daran, dass ich immer nur nach Feierabend daran arbeiten kann 
aber Home Assistant ist in dem Punkt SFML und STATS nun auch echt am Ende der Möglichkeiten für die breite Masse angekommen. Jedes weitere “freilassen” von Hubble würde Hardware-Mindestvoraussetzungen mit sich bringen. Daher habe ich Hubble wieder ein wenig eingebremst
1 „Gefällt mir“
Danke für die Blumen Ich find auf Arbeit schon immer die Bugs in der Software 
Naja, passiert, im besten falle hätte es so funktioniert, mach dir da mal keinen Kopf
1 „Gefällt mir“
