2026-08-04 15:06:52 +02:00
|
|
|
---
|
|
|
|
|
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`)
|
fix(kb): przepiecie wszystkich odwolan wewnetrznych po migracji
126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.
15 markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
rozwiazywala sie z katalogu, w ktorym lezala)
200 odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
-> nowa sciezka repo-root-relative, zgodnie z konwencja repo
5 linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
tylko w starym katalogu; przeliczone recznie
Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.
Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.
Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.
Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 15:12:24 +02:00
|
|
|
→ one week of observation → decide on `docker rm`. See `kb/phases/backlog.md`
|
2026-08-04 15:06:52 +02:00
|
|
|
for the ha-diag-agent re-pointing and wind-down follow-ups this incident
|
|
|
|
|
generated.
|
|
|
|
|
|