oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
homelab-codex-ws/docs/sessions/2026-07-22-ha-dwa-mozgi-cutover.md
oskar 510fe0b600 feat(kb): frontmatter OKF dla 39 session logow 
Session logi zostaja w docs/sessions/ (decyzja z etapu 1). Dodany wylacznie
blok frontmattera: type: session-log, visibility: private, status: active,
updated = data ostatniego commita pliku.

Tresc nietknieta — kazdy plik to +9/-0 linii.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 16:58:04 +02:00

2.5 KiB
Raw Blame History

okf type visibility status updated links
0.1 session-log private active 2026-07-22

2026-07-22 — HA: incydent dwóch mózgów, cutover ken, archiwum legacy

Odkrycie

Recon pod projekt configs-as-code ujawnił, że repo wskazywało złą maszynę jako "ken": kontener homeassistant5 na piha to instancja sprzed migracji (HA 2026.4.3, location_name "KEN", konta całej rodziny), a prawdziwy dom to HAOS na dedykowanym RPi4, LAN 192.168.31.7 (potwierdzone: observer :4357, HACS, 118 automatyzacji, ingress ha.kapala.org).

Obie instancje działały RÓWNOLEGLE i obie były podpięte do MQTT na piha. Dowody dublowania triggerów (last_triggered z restore_state obu instancji): mirror_on 04:30 na obu, gniazdka_w_lazience_on 05:00 na obu, turn_on_led_nad_blatem_1 12:53 na obu z tego samego fizycznego przycisku. Wyjaśnia obserwowane od dawna anomalie ("samo się przełącza", kaprysy przycisków). Stan trwał prawdopodobnie od migracji domu na RPi4.

Fałszywa hipoteza po drodze (odrzucona przez weryfikację): "kontener to martwa pozostałość" — obalona przez świeże last_triggered i mtime automations.yaml. Verify-before-fix uratował przed ślepym stopem, który wyłączyłby m.in. automatyzacje przycisków i harmonogramy łazienki.

Wykonane

  1. task/ha-cutover-instances (77d55ca): instances.yaml — ken = 31.7/api, ken-legacy = kontener piha/docker-exec (status: archived); DESIGN.md sekcja "Incident log"; README archiwum; backlog: przepięcie ha-diag-agent, procedura wygaszenia, adapter api.
  2. task/ha-import-legacy (970b8cc, po rebase na master): pełny import archiwalny ken-legacy — 60 automatyzacji, 5 scen, 1 skrypt, blueprinty, dashboardy, rejestry (85 plików). Idempotencja potwierdzona, gitignore szczelny (grep pod sekrety czysty), round-trip tagów HA OK.
  3. docker stop homeassistant5 na piha (BEZ rm) — dom przeszedł na jeden mózg. Rollback: docker start homeassistant5.

Otwarte / obserwacja

  • Do 2026-07-29: obserwacja, czy nic w domu nie polega na legacy. Braki → logika w services/home-assistant/config/ken-legacy/automations/, odtwarzanie wyłącznie przez repo na 31.7.
  • ha-diag-agent na piha celuje w martwy localhost:8123 — spodziewany alert; przepięcie na 31.7 w backlogu (wymaga tokenu diag_agent na 31.7).
  • Adapter api w import.sh dla ken + user deploy_agent i token na 31.7 — pierwszy task następnej sesji.
  • Po 2026-07-29: decyzja o docker rm i sprzątnięciu configu na piha.