Wie ihr sicher wisst, lege ich vor jedem Release größten Wert auf eine gründliche Qualitätssicherung. Dabei geht es nicht nur um ein einfaches „Installieren und Ausprobieren“, sondern um umfassende State-of-the-Art-Tests (u. a. Python-Interpreter-Validierung, Mocking, Security-, Syntax- und Penetrationstests).
Aktueller Status & Herausforderung
Diese Testläufe nehmen mehrere Stunden in Anspruch und haben aktuell eine Unstimmigkeit im Transformer Head aufgezeigt. Konkret gibt es einen Mismatch bei zwei Features: Aufgrund des Trainingsprozesses liegen diese in einer Form vor, die der Transformer Head so nicht verarbeiten kann.
Um dieses Problem zu lösen, habe ich folgende Optionen abgewogen:
Option A: Anpassung des Transformers (Extrem aufwendig; hohes Risiko für Regressionen an anderer Stelle).
Option B: Ignorieren der betroffenen Features (Qualitativ nicht empfehlenswert).
Option C: Erneutes Training des Modells (Dauer: mehrere Tage).
Option D: Implementierung eines Adapter-Layers (Zwischenschicht) zur Daten-Normalisierung.
Entscheidung & Zeitplan
Ich habe mich für Option D entschieden. Da die Implementierung und Validierung dieser Schicht Zeit in Anspruch nimmt, kann ich das ursprünglich geplante Release-Datum leider nicht ganz halten.
Sofern alles nach Plan läuft, verschiebt sich der Release voraussichtlich nur um einen Tag.
ich bin der meinung das es dir nicht schaden würde den nintendo-ansatz zu folgen. verschiebe den release so lange wie nötig um das bestmögliche ergebnis zu erzielen. am ende juckt es keinen ob es eine woche mehr oder weniger dauert wenn das ergebnis besser ist bzw. die entwicklung in zukunft einfacher zu realisieren ist weil ohne adapter-layer.
Ich glaube darauf gibt es keine eindeutige Antwort. Die Frage ist, wie sind deine Bewertungskriterien?
Wenn es das Ergebnis der Solarprognose ist:
TFS Docker: Die beste Solarprognose (nicht DAU geeignet)
SFML Integration + TFS App: Noch bessere Solarprognose - Auch eigentlich einfach zum Einrichten (aber zwei Steps)
SFML Integration: Gut für Solarprognose - Einfach zum Einrichten
Performance:
SFML Integration: Gut für Solarprognose - kaum Performance
SFML Integration + TFS App: braucht mehr Performance
TFS Docker: braucht viel Performance
Sicherheit:
TFS Docker
SFML Integration
SFML Integration + TFS App
So die Frage ist aber immer, was will ich?
Mir persönlich - sorry nochmal @Tom-HA für unseren Start - ist Sicherheit am Wichtigsten. Daher habe ich auch immer schon mit dem Verschlüsselten Code Mühe gehabt und bis dato die Lösung tatsächlich nicht genutzt.
Daher aus Security Sicht gibt es für mich nur eine ganz klare Antwort: TFS Docker: Wenn API / MQTT Input möglich ist, da SSH auf HA akutell auch undurchsichtig ist, da wir nicht sehen was TFS Docker damit macht Allerdings muss TFS Docker auch richtig konfiguriert sein
@Tom-HA selbst weisst ja immer auch auf die Gefahren selbst hin (KI etc.), es soll auch kein Angriff sein, sondern in dem Punkt sind @Tom-HA und ich glaub gleicher Meinung Sicherheit & Datenschutz sind das A und O. Verschlüsselter Code ist einfach schwierig zu analysieren Eine gute Zusammenfassung von Tom gibt es auch hier TFS HA Solar Forecat ML 8 Head Transformer KI (App-Version) - #49 von Tom-HA - nochmal wichtig ich unterstelle @Tom-HA nicht böses!
@Spatz
Das ist gut zusammengefasst. Eigentlich gehört eine Mischung aus meinem und deinen Post in die “Anleitung” eines jeden Home Assistant - oder als AGB wenn man ihn installiert.
Jeder der Home Assistant nutzt, aufsetzt sollte über ein paar Grundlegende Dinge vorab informiert werden - oder aufgeklärt werden.
a) Es ist egal wie performant / modern eine HW ist → HA nutzt nur einen Kern deines Prozessors für den Event-Loop
b) Unterschied zwischen App und Integration
c) Datenschutzgefahren bei unverschlüsselten Backups
d) Unterschied Supervisor Docker und Docker Installation
e) Informationspflicht im Haushalt lebender Personen / Gäste besonder beim Nutzen der Companion-App, Kameras, Alexas und Co das Daten abließen
f) Rieman-Sensoren und ihre mathematischen Grenzen
g) Mqtt, Modbus, Api
h) Token und SSH
i) Externe KI niemals auf den HA lassen → komplette DB und Netzwerk liegt offen
j) HA ist kein OS sondern eine Datenbank-Anwendung mit Schnittstellen
k) HA ist kein reines Open Source sondern bedient sich nur aus der Open Source Comunity → Firmensitzt ist in den USA im engen Schulterschluss mit einer Schweizer Stiftung.
Damit wäre schon mal sehr vielen geholfen ein paar Grundsätzliche Dinge und Basics zu verstehen.
Ich habe die Anleitung nun rauf und runtergelesen. Ich finde aber keinen Hinweis auf die Docker Datei bzw. die getippte Datei.
Mit dem Befehl
docker load < toorox-foresight-beta.tar.gz
wird ja auf eine lokal vorhandene Datei verwiesen. Wo kann ich mir diese herunterladen?
Das hier ist die Docker-Version Standalone.. diese Version benötigt eigene Hardware, oder einen eigenen Container und hat mit Home Assistant nichts zu tun. ..
Zu deiner Frage,
Update zum anstehenden Release
