4d5402946d
Generic settings architecture (data-driven, no per-setting UI code):
- SettingDefinition (id/name/description/category/type/default/min/max/
choices/editable/sensitive/requiresRestart/visibleIf) x 8 types:
boolean/string/number/select/multi-select/color/url/secret
- SettingsManager: validation, reset, custom CRUD, export/import
(all-or-nothing with per-key rejection reasons; custom definitions
travel in the export), secrets routed to EncryptedSharedPreferences
(AndroidKeyStore master key) and excluded from export by default
- Settings screen renders controls from the type; search; add/edit/delete
dialogs for custom settings; import/export dialogs
- Built-ins: General / Home Assistant / Appearance / Network / Advanced
Home Assistant integration (official REST + WebSocket APIs only):
- HomeAssistantClient: GET /api/, /api/states, /api/states/{id},
POST /api/services/{domain}/{service}, WS /api/websocket
(auth -> subscribe_events state_changed) with exponential-backoff
reconnect; safe HaError types that never contain the token
- HaRepository: single service layer between UI and client; optimistic
toggles reconciled by WS; poll fallback from refresh-interval setting
- Devices screen: discovery list, search, live states, toggles
(light/switch/fan/input_boolean/humidifier)
- Cleartext permitted for LAN http:// URLs (same stance as the official
HA companion app; TLS verification untouched); consent dialog on first
launch; Record button present but inert until M4 (honest label)
- Tests: 29 unit tests (19 settings incl. secret routing, import
validation, persistence; 10 HA via MockWebServer incl. 401 handling,
unreachable, WS handshake + event + auth_invalid). All green.
Docs: docs/home-assistant.md (install, token creation, storage,
troubleshooting, endpoint table); README + ROADMAP updated honestly
(live e2e against a real HA server still in progress).
43 KiB
43 KiB