Read-only import of the pre-migration homeassistant5 container (piha), per DESIGN.md phase-0 scope: 60 automations (split one-file-per-id), 5 scenes, 1 script, plus curated .storage/* export (area/entity registries, input_boolean/input_text, lovelace dashboards). No token at ~/.config/ha-deploy/ken-legacy.token — fixtures step fail-softed as designed, no repo import.sh changes needed. Verified: gitignore-excluded paths (secrets.yaml, *.db*, logs, .storage/auth*, core.restore_state, tts/, deps/, backups/, .cloud/) correctly stripped from the pull; three consecutive import.sh runs produced byte-identical output under config/ken-legacy/ and storage-export/ken-legacy/ (idempotent); automation count matches the 2026-07-22 recon estimate (~60) exactly. README.md only touched to note the import date. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| automations | ||
| blueprints | ||
| scenes | ||
| scripts | ||
| configuration.yaml | ||
| groups.yaml | ||
| known_devices.yaml | ||
| README.md | ||
ken-legacy — historical archive, do not deploy
This directory holds the /config import of the pre-migration Home
Assistant instance: the homeassistant5 container on piha, wound down
2026-07. It is kept for historical reference only — e.g. recovering the
logic of an old automation — not as a live or deployable instance.
See services/home-assistant/DESIGN.md, "Incident log" (2026-07-22) for
why this instance exists separately from the canonical ken (now the
Home Assistant OS instance on the RPi4 at 192.168.31.7): this container
kept running after the real migration and was firing automations in
parallel with the real home instance until the cutover was caught and
fixed.
Rules for humans and agents:
- Never run
import.sh ken-legacyexpecting a deploy target — it isn't one.services/home-assistant/instances.yamlmarks itstatus: archivedfor this reason. - Never write back to
homeassistant5from this directory. - Treat everything here as read-only history.
Archival import performed: 2026-07-22.