Wichtiger Hinweis: App vs. Integration (Sicherheitsanalyse)
Die technische Architektur: Flexibilität vs. Kontrolle
Ein entscheidender Unterschied zwischen einer App und einer nativen Integration liegt in der Abhängigkeitsverwaltung. Apps können eigenständig Bibliotheken nachziehen, die Home Assistant nativ weder unterstützt noch verifiziert hat.
Zudem können Apps keine direkten Sensor-Plattformen innerhalb des HA-Kerns registrieren; sie müssen stattdessen Umwege über Brücken (wie MQTT) nutzen. Aus Gründen der Systemstabilität und Sicherheit habe ich mich explizit gegen das aktive „Publishen“ von Entitäten entschieden.
Das SFML-Sicherheitsnetz
Stattdessen fungiert SFML als kontrollierte Schnittstelle, welche Werte übergibt, abholt und verarbeitet.
- Schutz vor Instabilität: Dieses Design verhindert Fehlkonfigurationen, Daten-Spam und unkontrollierte Zustandsänderungen.
- Native Validierung: SFML unterliegt zu 100 % der Kontrolle des Supervisors und basiert ausschließlich auf nativem, von Home Assistant freigegebenem Code.
Das Risiko der „Black-Box“
Apps agieren prinzipiell als Black-Box: Ohne tiefgehende Code-Analyse bleibt unklar, ob sie Fehler, versteckte Telemetrie, Trojaner oder Schadsoftware enthalten.
Meine Konsequenz: Totale Isolation.
Meine App ist strikt vom System getrennt. Sie kann weder in den Home Assistant Recorder schreiben noch daraus lesen. Alle benötigten Daten werden über das überwachte SFML-Modul bezogen. Damit ist ein direkter Zugriff auf eure historische Datenbank technisch ausgeschlossen.
Grundsatz: Safety First statt Bequemlichkeit
Integrationen sind hochkomplex und erfordern native, geprüfte Lösungen. Apps hingegen unterliegen keinerlei zentralen Kontrolle. Es gibt keinen technisch logischen Grund, Werkzeuge für Energiestatistiken (STATS), komplexe Energieberechnungen (GPM) oder Datenvergleiche nicht auf einer sauberen, offiziellen Repository-Basis zu bauen.
“Ich investiere lieber deutlich mehr Hirnschmalz in eine robuste Architektur, als eine unberechenbare Gefahr für das Gesamtsystem in Kauf zu nehmen.”
Wir hatten diese Diskussion bereits im Beta-Thread: Warum sind SFML, STATS und GPM keine Apps? Weil Sicherheit Vorrang vor dem vermeintlich einfacheren Weg hat.
Warnung vor KI-Code und unbekannten Quellen
Die Gefahr unerkannter oder gefährlicher Routinen in fremdem Code ist immens. Ich rate zur massiven Vorsicht bei Apps unbekannter Entwickler oder KI-generierten Lösungen – insbesondere wenn diese:
- Weitreichenden Zugriff auf den Recorder verlangen.
- Sensorik-Daten manipulieren, um Berechnungen oder Statistiken zu erstellen (wie es etwa bei TFS für Tagesprognosen und Erträge praktiziert wird).
Solche tiefgreifenden Zugriffe stellen ein unnötiges Sicherheitsrisiko dar, das durch mein Design konsequent ausgeschlossen wird.
Appell an alle (KI-)Entwickler
Wenn ihr via KI Apps baut: Lasst zwingend einen erfahrenen Entwickler über den Code schauen. Nur ein Mensch, der Code wirklich versteht, kann verifizieren, ob eine App „nach Hause telefoniert“ oder ein Risiko für das Smart Home darstellt.
Fazit & Side-Kick
Wer maximale Sicherheit für Prognosen sucht: Die TFS Docker-Version (Standalone Linux) bietet das höchste Sicherheitsniveau. Sie ist komplett isoliert, und dem Container können strenge Regeln auferlegt werden – ein Sicherheitslevel, das bei HA-Apps konstruktionsbedingt nicht möglich ist.
Kurzgefasst: Äußerste Vorsicht bei der Nutzung von Apps innerhalb von Home Assistant!
@Spatz: Du kannst dazu bestimmt noch einiges mehr sagen.