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!