Initialisiere SillyHome Next Analyseprojekt
This commit is contained in:
17
docs/adr/ADR-001-data-flow.md
Normal file
17
docs/adr/ADR-001-data-flow.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# ADR-001: Datenfluss zwischen Home Assistant und Trainingsdaten
|
||||
|
||||
## Status
|
||||
Angenommen
|
||||
|
||||
## Kontext
|
||||
Das System muss Historie lesen und Live-Events verarbeiten. OAuth-HA-Zugriff ist aufwändiger, Long-Lived-Tokens sind in lokalen Netzen vertretbar.
|
||||
|
||||
## Entscheidung
|
||||
- Home Assistant Integration via Long-Lived Access Token oder Supervisor-Service-Account.
|
||||
- Historische Daten via SQL-Export/Backup, Lesezugriff auf die Recorder-Datenbank oder REST `/api/history/period`.
|
||||
- Live-Events via WebSocket und optional MQTT.
|
||||
|
||||
## Konsequenzen
|
||||
- Vereinfachung der Integration.
|
||||
- Kein permanentes MQTT-Bridge-Setup zwingend.
|
||||
- Backup-Granularität und lokale Datenschutzprüfung bleiben erforderlich.
|
||||
17
docs/adr/ADR-002-ml-stack.md
Normal file
17
docs/adr/ADR-002-ml-stack.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# ADR-002: ML-Stack und Modellwahl
|
||||
|
||||
## Status
|
||||
Angenommen
|
||||
|
||||
## Kontext
|
||||
Es soll lokal laufen, erklärbar bleiben und ohne zwingende Cloud auskommen.
|
||||
|
||||
## Entscheidung
|
||||
- Regel- und ML-Ebene mit PyTorch, scikit-learn und XGBoost.
|
||||
- LLM-Ebene über Ollama-kompatible Modelle oder OpenAI-kompatible LiteLLM-Proxy-Anbindung lokal.
|
||||
- Semantik über Sentence-Transformers oder lokale Embeddings.
|
||||
|
||||
## Konsequenzen
|
||||
- Lokal-first-Betrieb bleibt machbar.
|
||||
- Modellwechsel ist durch Schnittstellen-Abstraktion möglich.
|
||||
- GPU-Einsatz ist optional und bleibt trennbar.
|
||||
16
docs/adr/ADR-003-api-gateway.md
Normal file
16
docs/adr/ADR-003-api-gateway.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# ADR-003: API und Integration Gateway
|
||||
|
||||
## Status
|
||||
Angenommen
|
||||
|
||||
## Kontext
|
||||
HA, Addon, UI und externe Dienste müssen stabil integrierbar sein.
|
||||
|
||||
## Entscheidung
|
||||
- FastAPI als zentraler API-Layer.
|
||||
- Endpunkte für Geräte, Sensoren, Vorhersagen, Erklärungen, Automationen und Insights.
|
||||
- OpenAI-kompatible Endpunkte für LLM-gestützte Assistenz.
|
||||
|
||||
## Konsequenzen
|
||||
- Standardisierte Anbindung und klare Versionierung.
|
||||
- Einfache Erweiterung für zusätzliche Integrationen.
|
||||
16
docs/adr/ADR-004-deployment.md
Normal file
16
docs/adr/ADR-004-deployment.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# ADR-004: Deploymentmodell
|
||||
|
||||
## Status
|
||||
Angenommen
|
||||
|
||||
## Kontext
|
||||
Das System soll einfach installierbar sein, lokal laufen und wartbar bleiben.
|
||||
|
||||
## Entscheidung
|
||||
- Docker Compose für Core-Services.
|
||||
- HA Addon-Rezepte und Lua-Skripte als optionale Integrationshilfe.
|
||||
- Kubernetes-Support bleibt möglich, aber optional.
|
||||
|
||||
## Konsequenzen
|
||||
- Schneller Einstieg in bestehende HA-Umgebungen.
|
||||
- Flexibilität für künftige Betriebsgrößen.
|
||||
Reference in New Issue
Block a user