---
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 `kb/phases/backlog.md`
for the ha-diag-agent re-pointing and wind-down follow-ups this incident
generated.