69 lines
2.1 KiB
Markdown
69 lines
2.1 KiB
Markdown
# SillyHome Next v1.3.0 Operating Guide
|
|
|
|
v1.3.0 ergänzt die v1.2-Lernfunktionen um Anomalie-Erkennung und
|
|
Performance-Überwachung. Das Dashboard bleibt Visualisierung und Einrichtung;
|
|
der direkte Schaltpfad bleibt kurz und führt vor dem Home-Assistant-Service-Call
|
|
keine Discovery, kein Training und keine Modellanalyse aus.
|
|
|
|
## Performance-Budget
|
|
|
|
- Dashboard-Start und `/v1/actuators/dashboard` haben ein Budget von 3000 ms.
|
|
- Das Dashboard zeigt die eigene Ladezeit, das aktive Budget, Job-p95 und die
|
|
Anzahl langsamer Jobs.
|
|
- Jobs ab 3000 ms werden in der Job-Queue als langsam markiert.
|
|
- Der automatisierte API-Test prüft den Root- und Dashboard-Startpfad gegen das
|
|
3-Sekunden-Budget.
|
|
|
|
## Anomalie-Erkennung
|
|
|
|
Anomalien werden pro Aktor gespeichert und im Aktor-Detail angezeigt. Erkannt
|
|
werden aktuell:
|
|
|
|
- fehlender Sensor-/Kontextbezug
|
|
- zu wenige Lernbeispiele
|
|
- unklare Quellen historischer Schaltungen
|
|
- veraltetes Training
|
|
- Vorhersagen unter der Sicherheitsgrenze
|
|
- aktive manuelle Sicherheitssperren
|
|
- Safety-Blocker
|
|
- parallele HA-Automationen bei aktivem SillyHome
|
|
- hohe negative Feedbackquote
|
|
|
|
Die Anomalien sind Hinweise für Setup und manuelles Gegensteuern. Sie lösen
|
|
keine automatische Eskalation und keine langsamere Schaltung aus.
|
|
|
|
## API
|
|
|
|
- `GET /v1/actuators/dashboard` liefert jetzt zusätzlich:
|
|
- `performance_budget_ms`
|
|
- `job_p95_duration_ms`
|
|
- `slow_job_count`
|
|
- `performance_status`
|
|
- `anomaly_count`
|
|
- `critical_anomaly_count`
|
|
- `GET /v1/actuators/anomalies` liefert offene Anomalien gruppiert nach Aktor.
|
|
|
|
## Betrieb
|
|
|
|
Bei Ladezeiten ab 3 Sekunden gilt die Seite als nicht performant. Dann zuerst
|
|
prüfen:
|
|
|
|
1. Dashboard-Statistik: Ladezeit, Job-p95, langsame Jobs.
|
|
2. Job-Queue: welche Aktion langsam war.
|
|
3. Aktor-Detail: Anomalien, Safety-Blocker und Automation-Konflikte.
|
|
4. Falls Discovery oder Training langsam war: nicht in den Startpfad ziehen,
|
|
sondern geplant, manuell oder über Queue laufen lassen.
|
|
|
|
## Qualität
|
|
|
|
Vor Release/Installation ausführen:
|
|
|
|
```bash
|
|
pytest -q
|
|
ruff check .
|
|
mypy app backend tests
|
|
git diff --check
|
|
```
|
|
|
|
Zusätzlich das eingebettete Dashboard-JavaScript mit `node --check` prüfen.
|