oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

feat(kb): SPLIT home-assistant/DESIGN.md -> decision + incident

Browse source 
kb/decisions/ha-configs-as-code.md — decyzje projektowe HA configs-as-code
kb/incidents/2026-07-22-ha-dwie-instancje.md — sekcja "Incident log":
dwie instancje HA sterujace domem rownolegle po migracji

Incydent byl dotad wtopiony w dokument decyzyjny; teraz jest adresowalny
jako osobny wpis type: incident. Tresc nietknieta.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
oskar 2026-08-04 15:06:52 +02:00
parent 280ed48d9a
commit 5439c00def
2 changed files with 53 additions and 31 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
services/home-assistant/DESIGN.md → kb/decisions/ha-configs-as-code.md
View file

@ -1,3 +1,13 @@
---
okf: "0.1"
type: decision
visibility: private
status: active
updated: 2026-07-30
links:
- ../incidents/2026-07-22-ha-dwie-instancje.md
---
# Home Assistant configs-as-code — design decisions
Status: **phase 1 (partial)**. `scripts/ha/deploy.sh` implements the write
@ -134,37 +144,6 @@ copied into the repo.
the existing Telegram bot / approval-queue pattern from
`services/control-plane/`.
## Incident log
### 2026-07-22 — two HA instances controlling the house in parallel
**Symptom**: automations firing twice from a single physical trigger — e.g.
`turn_on_led_nad_blatem_1` firing the same day from the same button press,
`mirror_on` at 04:30 and `gniazdka_w_lazience_on` at 05:00 all firing on
both instances.
**How detected**: comparing `last_triggered` from `restore_state` across the
two instances showed identical automation IDs firing at the same times on
both — the container on piha (`homeassistant5`, HA 2026.4.3, location_name
`KEN`, mounted at `/home/pi/homeassistant/config`) never actually stopped
running after the migration to the RPi4/HAOS instance at 192.168.31.7; it
stayed alive and MQTT-connected, so both were independently reacting to the
same physical events.
**Root cause**: `instances.yaml` had `ken` pointed at the piha container —
that was the pre-migration instance, not the real one. The actual home
instance had already moved to Home Assistant OS on a dedicated RPi4
(192.168.31.7:8123, ingress `ha.kapala.org` via NPM, confirmed HAOS via
observer :4357, HACS installed, 118 automations), but the repo never
followed the move.
**Decision**: 192.168.31.7 (HAOS/RPi4) is canonical `ken`. The piha
container is renamed `ken-legacy` in `instances.yaml`, `status: archived`.
Plan: archival import for historical reference → `docker stop` (not `rm`)
→ one week of observation → decide on `docker rm`. See `docs/backlog.md`
for the ha-diag-agent re-pointing and wind-down follow-ups this incident
generated.
## Decyzje operatora po audycie 2026-07-23
Zobacz `docs/audyt-automatyzacji-2026-07-23.md` (sekcja "Do decyzji operatora",

43
kb/incidents/2026-07-22-ha-dwie-instancje.md Normal file
View file

@ -0,0 +1,43 @@
---
okf: "0.1"
type: incident
visibility: private
status: active
updated: 2026-07-30
links:
- ../decisions/ha-configs-as-code.md
---
# 2026-07-22 — dwie instancje HA sterujace domem rownolegle
## Incident log
### 2026-07-22 — two HA instances controlling the house in parallel
**Symptom**: automations firing twice from a single physical trigger — e.g.
`turn_on_led_nad_blatem_1` firing the same day from the same button press,
`mirror_on` at 04:30 and `gniazdka_w_lazience_on` at 05:00 all firing on
both instances.
**How detected**: comparing `last_triggered` from `restore_state` across the
two instances showed identical automation IDs firing at the same times on
both — the container on piha (`homeassistant5`, HA 2026.4.3, location_name
`KEN`, mounted at `/home/pi/homeassistant/config`) never actually stopped
running after the migration to the RPi4/HAOS instance at 192.168.31.7; it
stayed alive and MQTT-connected, so both were independently reacting to the
same physical events.
**Root cause**: `instances.yaml` had `ken` pointed at the piha container —
that was the pre-migration instance, not the real one. The actual home
instance had already moved to Home Assistant OS on a dedicated RPi4
(192.168.31.7:8123, ingress `ha.kapala.org` via NPM, confirmed HAOS via
observer :4357, HACS installed, 118 automations), but the repo never
followed the move.
**Decision**: 192.168.31.7 (HAOS/RPi4) is canonical `ken`. The piha
container is renamed `ken-legacy` in `instances.yaml`, `status: archived`.
Plan: archival import for historical reference → `docker stop` (not `rm`)
→ one week of observation → decide on `docker rm`. See `docs/backlog.md`
for the ha-diag-agent re-pointing and wind-down follow-ups this incident
generated.