# Audyt spójności automatyzacji instancji `ken` — 2026-07-23

Zakres: wyłącznie analiza; żadnych zmian w automatyzacjach/skryptach/scenach.

Materiał: `config/ken/` (119 automatyzacji, 6 skryptów, 3 sceny),
`storage-export/ken/` (rejestry z 2026-07-22), `fixtures/ken-states-2026-07-22.yaml`
(stany + `last_triggered`), `config/ken-legacy/` (60 automatyzacji, archiwum),
DESIGN.md (Incident log).

Zastrzeżenia metodyczne:

- Rejestry i fixtures pochodzą z 2026-07-22, sprzed wdrożenia automatyki klimy
  (commity z 2026-07-23). Encje klimy „brakujące" w exportach nie muszą być
  martwe — patrz 1.1.
- HA po restarcie 2026-07-17 15:07 (update Supervisora) zresetował `last_changed`
  — encje pokazujące `unavailable od 2026-07-17 15:07` są martwe *co najmniej*
  od restartu; `last_triggered` automatyzacji wskazuje, że część padła dużo
  wcześniej (marzec–maj).
- Deploy helpers (`input_*`) nie istnieje (faza 1 obejmuje tylko
  automations/scripts/scenes), więc obecności helperów klimy nie da się
  potwierdzić z repo.

## Streszczenie

Liczby:

- 119 automatyzacji (112 włączonych, 7 wyłączonych), 6 skryptów, 3 sceny.
- 305 encji `unavailable` w fixtures; 6 czujników ruchu/obecności martwych
  lub gasnących (mdwejscie, mdsypialnia, mdtymka, mdheli, mdubikacja, occusalon).
- ~15 automatyzacji martwych lub zdegradowanych przez martwe czujniki — po cichu:
  triggery nie strzelają albo warunki `is_not_occupied` na encji `unavailable`
  nigdy nie przechodzą.
- 8 referencji do encji nieistniejących w registry (poza klimą).
- 13 automatyzacji na `time_pattern`, z tego 7 co ≤1 min (w tym 6 kalibracji TRV
  co 40–50 s i `Set current_player` co 15 s).
- Legacy: 54/60 automatyzacji ma odpowiednik 1:1 na ken, 6 bez odpowiednika
  (sekcja 5).

Top 5 znalezisk wg wagi:

1. **[krytyczne] Kalibracja TRV sypialnia i Tymek liczy średnią z martwego
   czujnika** — `unavailable → float(0)` zaniża temperaturę o połowę, kalibracje
   przypięte do −5.0 (potwierdzone w fixtures). W sezonie grzewczym oznacza to
   trwałe przegrzewanie obu pokoi. Pętle piszą po Zigbee co 40–45 s (baterie TRV
   20–38%). (1.4)
2. **[krytyczne] Martwy klaster czujników ruchu wyłączył alerty i nocne
   gaszenie** — m.in. `email on move in hall/sypialnia when on leave` (funkcja
   antywłamaniowa) nigdy nie wystrzeli; oba nocne „turn off lights if clear"
   martwe od marca; `sleep_mode` nie włącza się już automatycznie. (1.2, 2.4)
3. **[krytyczne] Łańcuch alertów wodnych dziurawy** — czujnik WC `unavailable`
   (brak alertu przy zalaniu), „dry in Kuchnia" triggeruje na `moist`
   (kopiuj-wklej), „dry in Lazienka" ma literówkę `mesaage:` (akcja bez
   `message` → skrypt się wywala). (1.3, 2.6)
4. **[istotne] `Poranek start` codziennie wisi 1 h na martwym czujniku** —
   `wait_for_trigger` na mdwejscie (unavailable) zawsze dobija do timeoutu 1 h;
   radio i powitanie startują o godzinę za późno. (1.2c)
5. **[istotne] Klima salon: helperów nie ma w żadnym exporcie, a gałąź OFF nie
   sprawdza `klima_salon_auto`** — jeśli helpery nie istnieją na instancji, obie
   automatyzacje są martwe (cicho); niezależnie od tego zachód słońca ubija też
   ręcznie włączone chłodzenie. (1.1, 3.1)

## 1. Martwe referencje

### 1.1 [istotne — do weryfikacji] Helpery klimy salonowej niepotwierdzone

Pliki: `1784804667795` „Klima salon: włącz…", `1784804668795` „Klima salon:
wyłącz…", `scripts/klima_salon_dry_off.yaml`.

Referencje: `input_boolean.klima_salon_auto`, `input_number.klima_salon_temp_docelowa`,
`input_number.klima_salon_tolerancja` — nie występują w
`storage-export/ken/input_*.yaml` ani w fixtures (snapshoty z 2026-07-22, sprzed
deployu klimy). Repo nie ma toru deployu helperów, więc musiały powstać ręcznie
w UI — albo nie powstały. Jeśli ich nie ma, warunek `state: 'on'` na
nieistniejącej encji nigdy nie przechodzi i cała automatyka klimy jest martwa
bez żadnego błędu.

PROPOZYCJA: jednorazowa weryfikacja na żywej instancji (`/api/states`), potem
re-import `input_*` do storage-export, żeby snapshot dogonił stan.

### 1.2 [krytyczne] Martwe czujniki ruchu/obecności — ~15 automatyzacji cicho nie działa

Stan w fixtures: `binary_sensor.0x00124b00251472ef_occupancy` (mdwejscie/hall),
`mdsypialnia_occupancy`, `mdheli_occupancy` — unavailable co najmniej od
restartu 2026-07-17; `occusalon_occupancy` od 2026-07-20, `mdtymka_occupancy` od
2026-07-21, `mdubikacja_occupancy` od 2026-07-22 (te trzy gasną/flapują —
typowy obraz siadających baterii). `last_triggered` wskazuje, że occusalon i
mdwejscie realnie przestały działać w okolicach marca–maja.

Skutki, w kolejności wagi:

a) **Alerty on-leave martwe**: `1753431022365` „email on move in hall when on
   leave" i `1753883109847` „email on move in sypialnia when on leave" —
   triggery na martwych czujnikach; nigdy nie wystrzelą. Przy `on_leave = on`
   dom NIE zgłosi ruchu. (Ostatnie odpalenia: 2026-01-29 / 2025-09-15 — jeszcze
   z czasów życia czujników.)

b) **Nocne gaszenie świateł martwe**: `1702844937214` „Turn off Lights after
   23:30 if clear" (ostatni raz 2026-03-27) i `1763384250145` „Turn off Swiatlo
   na Kuchnia after 23:30 if clear" (2025-11-27) mają w warunkach
   `is_not_occupied` na occusalon/mdwejscie/mdubikacja — `unavailable` ≠ `off`,
   warunek zawsze fałszywy. Konsekwencja wtórna: `1702844937214` było jedynym
   automatycznym włącznikiem `input_boolean.sleep_mode` — sleep mode działa już
   tylko z przycisku w sypialni. Realnie nocą domyka światła tylko
   `1700832676138` „Turn off lights unconditionally at 3am".

c) **`Poranek start` (`1763386155895`) wisi godzinę**: główna sekwencja czeka
   `wait_for_trigger` na mdwejscie occupied z timeoutem 1 h — czyli codziennie
   pełny timeout; radio/speak startują o ~7:42 zamiast po wykryciu ruchu.
   Dodatkowo `1764595573287` „Poranek pause media player…" (warunki na
   occusalon+mdwejscie) — martwe od 2026-03-26.

d) **`1763637049783`** („Turn off swiatlo nad kuchnia when no motion, no
   trigger", entity `automation.new_automation_3`, wywoływane codziennie przez
   `Poranek stop`): pętla `repeat–until` z warunkami na mdwejscie i occusalon —
   `until` nigdy nie przejdzie, pętla kręci się w nieskończoność (delay 1 min),
   aż ubije ją restart HA lub `stop_actions`. Zombie.

e) **`1752607597518` „Turn off led zasilanie w Kuchni"**: warunek AND na
   3 czujnikach, z których 2 martwe → nigdy nie przechodzi. Potwierdzone:
   `switch.tasmota_14` świeci się non stop (state `on`). LED zasilania w kuchni
   nie gaśnie od marca.

f) Mniejsze: `1666891422388`/`1666891723803` (Magic Mirror Display On/Off —
   trigger mdwejscie, lustro nie reaguje na obecność), `1667065238690` „Swiatlo
   na wejscie do domu" (trigger mdwejscie, ostatnio 2026-03-24), `1703104763868`
   „Turn OFF Heli sufit" (warunek mdheli, ostatnio 2026-04-08), `1763637857513`
   „…no motion in all home for 1h" (warunki na 5 martwych czujnikach; częściowo
   uratowane przez odnogę OR akceptującą `unavailable` mdkorytarz — ale AND na
   mdheli/mdtymka/mdsypialnia i tak blokuje), `1734943824257` „Turn ON Choinka
   na wejscie" (trigger mdwejscie — podwójnie martwe, patrz 4.2).

PROPOZYCJA: wymiana baterii / re-pairing 6 czujników to jedna fizyczna akcja,
która reanimuje większość powyższego. Po niej: przegląd, czy `1763637049783`
(zombie-pętla) nie powinno zostać przepisane na zwykłe warunki `for:`. Docelowo
rozważyć alerty ha-diag-agent na `unavailable > 24 h` dla czujników użytych w
automatyzacjach (routing `ha_entity_unavailable_long` już istnieje w
supervisorze).

### 1.3 [krytyczne] Czujnik wycieku WC martwy

`binary_sensor.waterleakwc_water_leak` unavailable (razem z baterią) →
`1752086527168` „email on water sensor moist in WC" i `1752086563805` „dry in
WC" nie wystrzelą przy zalaniu. Pozostałe czujniki wycieku żyją (bateria
łazienkowego: 35%).

PROPOZYCJA: bateria/re-pairing; rozważyć zbiorczy alert „czujnik bezpieczeństwa
unavailable" (jak w 1.2).

### 1.4 [krytyczne] Kalibracje TRV liczone z martwych czujników, pętle co 40–50 s

Pliki: `1764751049013` (Sypialnia), `1765817937658` (Tymek), `1766345640142`
(Łazienka), `1765817263673` (Heli), `1766348309347` (SalonLewy),
`1766348430579` (SalonPrawy).

- Sypialnia i Tymek: `room_temp = (thX + zhimi_Y)/2`, a oba czujniki zhimi są
  unavailable od 2026-07-17 → `float(0)` → średnia zaniżona o połowę → `diff`
  zawsze na dolnym ograniczniku → kalibracja dojechała do **−5.0** (potwierdzone
  w fixtures dla obu). TRV raportuje temperaturę o 5° za nisko; w sezonie
  grzewczym = trwałe przegrzewanie. Dziś (lato, TRV `off`) bug jest uzbrojony,
  ale nieszkodliwy — do naprawy przed sezonem.
- Łazienka: `climate.heaterlazienkatrv07` i jego `number.*_calibration` są
  unavailable (TRV zniknął z sieci) → `number.set_value` co 40 s w próżnię
  (błędy w logach). Powiązane: `1766408469485` „Boost heater temp in Lazienka
  when shower" — trigger na `sensor.thtuyalazienka_humidity_stats_5min`
  (state `unknown`; sensor statystyczny prawdopodobnie nie przeżył migracji na
  HAOS) + cel unavailable → martwe.
- Salon lewy/prawy: kalibracje przypięte do +5 (max). Częściowo tłumaczy to
  lato (TRV nie mierzy sensownie przy zaworze off), ale SalonPrawy ma clamp
  `diff` ±5, podczas gdy wszystkie pozostałe ±1.5 — wygląda na niedokończony
  eksperyment, nie świadomą różnicę.
- Wszystkie 6: `time_pattern` co 40/45/50 s pisze po Zigbee do TRV na baterii
  (poziomy 20–38%). To agresywny polling; `for:`/trigger na zmianę temperatury
  załatwiłby to samo przy ułamku ruchu.

PROPOZYCJA: (1) wywalić uśrednianie z czujników zhimi albo dodać guard
`is not unavailable`; (2) po naprawie ręcznie wyzerować kalibracje
sypialnia/Tymek; (3) zwolnić pętle do np. 5 min lub przejść na trigger
zmiany stanu; (4) ujednolicić clamp SalonPrawy; (5) reanimować TRV łazienki
albo wyłączyć jego automatyzacje.

### 1.5 [istotne] Encje usunięte z registry — automatyzacje trwale martwe

- `1751307777881` „Aktualizuj lokalizację Oskar": `sensor.owntracks_last_location`
  nie istnieje (integracja OwnTracks nie przeżyła migracji?). Ostatni trigger
  2025-12-20; `device_tracker.oskar` = `not_home` na stałe, mimo że
  `person.oskar` = `home` (inna ścieżka). PROPOZYCJA: przywrócić OwnTracks albo
  skasować automatyzację i sprzątnąć `device_tracker.oskar`.
- `1760432474594` „Notify on router sypialnia is away for too long":
  `sensor.routerheli_last_seen` nie istnieje; `last_triggered` NULL; pattern co
  1 min ocenia warunek na nieistniejącej encji. Uwaga: alias mówi „sypialnia",
  sensor „heli". PROPOZYCJA: skasować lub podpiąć istniejący sensor.
- `1763384250145` „Turn off Swiatlo na Kuchnia after 23:30 if clear": warunek na
  `binary_sensor.0x8c65a3fffeea673a_occupancy` — stary identyfikator occusalon
  sprzed zmiany nazwy. Nawet po reanimacji occusalon ta automatyzacja nie
  ożyje. PROPOZYCJA: podmienić na `binary_sensor.occusalon_occupancy`.
- `1640285211569`/`1640285276640` „Oczyszczacz i nawilżacz prze przycisk Tymka
  [ON]/[OFF]": `fan.mi_air_purifier_3_3h` i `switch.gniazdko_xiaomi_2` nie
  istnieją w registry; ostatnie triggery 2024. Martwe od ~2 lat. PROPOZYCJA:
  skasować (patrz też 4.5).
- `1752241986989` „test test Powitanie głosowe…": `sensor.temperature_salon`
  nie istnieje (jest `thsalon_temperature`); automatyzacja wyłączona, bez
  triggerów. PROPOZYCJA: skasować.

### 1.6 [istotne] Encje trwale unavailable w akcjach

- `1700837302203` „Speak" (4button 1_double): cel `media_player.salon_2`
  (soundbar Bose) unavailable — przycisk „powiedz" martwy. Jedyny konsument
  `tts.google_translate_say`; reszta domu mówi przez `tts.piper`+pimirror.
  PROPOZYCJA: przepiąć na pimirror/piper albo skasować.
- `1761038411219` „Oczyszcza w tryb nocny" (23:30): `xiaomi_miot.set_property`
  na `fan.zhimi_mc2_c369_air_purifier` — unavailable od 2026-07-17; co noc
  błąd. Szerszy obraz: **cała rodzina encji zhimi (mb3, mc2) padła równo z
  restartem/aktualizacją 2026-07-17** — wygląda na wysypaną integrację
  xiaomi_miot, nie na urządzenia. Dotyka też scen (4.2) i kalibracji TRV (1.4).
  PROPOZYCJA: zdiagnozować integrację miot po stronie HA zamiast naprawiać
  pojedyncze automatyzacje.
- Sceny `Oczyszczacze i Nawilzacze ON/OFF`: połowa encji żyje (tasmota_4/5,
  chuangmi), wentylatory zhimi unavailable → sceny wykonują się częściowo.

## 2. Sprzeczności i wyścigi

### 2.1 [istotne] „Disable AUTO off lights in Kuchnia" jest unieważniane po ≤15 min

`1762952673833` (double-click) wyłącza `automation.turn_off_lights_in_kuchania`
i zapala światła — intencja: „zostaw światła w spokoju". Ale `1764190493305`
„Turn off lights in Kuchnia after 15 minutes anyway" (zawsze włączone, pattern
/5 + własny trigger) gasi te same światła po 15 min bez ruchu i **z powrotem
włącza** auto-off. Przy bezruchu (oglądanie czegoś, gotowanie poza zasięgiem
czujników) decyzja użytkownika żyje kwadrans. Do tego `1763383792516` „Activate
AUTO… after 1h" i `1762954145724` „…at 23:30" też re-aktywują auto-off.
Nakładka intencji: „anyway" vs „disable".

PROPOZYCJA: „after 15 minutes anyway" powinno respektować stan wyłączenia
`turn_off_lights_in_kuchania` (warunek `state: automation... = on`) albo
double-click powinien ustawiać dedykowany `input_boolean.kuchnia_manual`
sprawdzany przez wszystkie gaszące automatyzacje.

### 2.2 [istotne] Cztery nakładające się nocne wyłączniki tych samych świateł

Na zestaw {switch.tasmota, sufit2/3, tasmota_12, tasmota_8, zblampkiregal}
działają równolegle: `1702844937214` (pattern /5, 23:30–6:30 — martwe, 1.2b),
`1763384250145` (pattern /3 — martwe, 1.5), `1768946230585` (sleep-mode
enforcer, pattern /5) i `1700832676138` (3:00). Trzy z nich to warianty tej
samej funkcji pisane w różnych epokach. Po reanimacji czujników wszystkie trzy
ożyją naraz i będą się ścigać (różne warunki, ten sam cel).

PROPOZYCJA: skonsolidować do jednej automatyzacji „nocne domknięcie" z jasnym
priorytetem trybów; pozostałe skasować.

### 2.3 [kosmetyczne] `1700832676138` „…at 3am": `time_pattern hours: '3'` bez minut

Odpala się co minutę przez całą godzinę 3:00–3:59 (60 prób, w tym 3 na
unavailable przełącznikach choinki). PROPOZYCJA: zwykły trigger `time: 03:00`.

### 2.4 [istotne] Enforcer sleep mode gasi światła co ~10 min przez całą noc

`1768946230585` „Turn OFF lights 5 minutes after sleep mode activated" ma dwa
triggery: krawędź `sleep_mode off→on` **i** `time_pattern /5», z warunkiem
`sleep_mode = on`. Efekt: to nie jest „5 minut po aktywacji", tylko cykliczny
dozorca — każde światło z listy zapalone ręcznie w trakcie sleep mode zgaśnie
w ciągu 5–10 min. Jeśli to celowe, alias kłamie; jeśli nie — pattern jest
zbędny. PROPOZYCJA: decyzja operatora (patrz checklista); przy „tylko raz"
usunąć trigger pattern.

### 2.5 [kosmetyczne] Blat w Pralni — double-click może zdesynchronizować parę automatyzacji

`1760992440280` toggluje **niezależnie** dwie automatyzacje (ON-ową i OFF-ową).
Dziś obie są `on`, więc działa; jeśli kiedykolwiek rozjadą się (restart,
ręczna zmiana), double-click będzie je wiecznie swapował zamiast włączać/
wyłączać parę. Dodatkowo w nocy `1768989504100` (night light 1%… w praktyce
turn_on/off) i para MD piszą w ten sam `switch.zbpralniablat` — kierunkowo
zgodne, ale night-light wyłącza po 5 min timeoutu nawet przy obecności (wait
`not_occupied` z `continue_on_timeout`). PROPOZYCJA: toggle zastąpić parą
`turn_on`/`turn_off` wg stanu jednej z nich.

### 2.6 [krytyczne → patrz Top 3] Para wodna Kuchnia: „dry" triggeruje na `moist`

`1752086407230` „email on water sensor dry in Kuchnia" ma trigger `type: moist`
(kopiuj-wklej z `1752086343222`). Efekt: przy zalaniu kuchni przychodzą DWA
maile („mokro" i „sucho") naraz, a informacja „wyschło" nie przyjdzie nigdy.
Ślad w fixtures: „dry" ma `last_triggered` 2026-01-20, „moist" — NULL (czyli
realne zdarzenie moist obsłużyła… automatyzacja „dry"; NULL na „moist"
prawdopodobnie przez późniejsze przeładowanie). Bonus: `1752085965483` „dry in
Lazienka" przekazuje parametr `mesaage:` (literówka) — skrypt
`notify_email_ntfy` dostaje niezdefiniowane `message` i akcja się wykłada.
PROPOZYCJA: trigger na `not_moist` w Kuchni; `mesaage → message` w Łazience.

### 2.7 [kosmetyczne] Redundantne harmonogramy Gniazdka w Łazience

ON: 7:00, 20:00 (warunek `on_leave off`); OFF: 1:00, 2:00, 9:30, 10:30, 12:30
(bez warunków). Okna 7:00–9:30 i 20:00–1:00 są spójne; trzy dodatkowe OFF-y to
pasy bezpieczeństwa. Sprzeczności brak. Odnotowane, bo pięć punktowych OFF-ów
w jednej automatyzacji utrudnia czytanie intencji.

### 2.8 [kosmetyczne] Dwa wyłączniki stereo

`1744976289447` (idle 15 min, po 23:30) i `1763662256621` (idle 1 h, zawsze) —
nakładka celowa (nocne zaostrzenie), kierunkowo zgodna. OK, odnotowane.

## 3. Trigger brzegowy bez lustrzanego warunku (klasa buga z klima_salon, fix `faa2e2a`)

Przejrzano wszystkie automatyzacje z >1 triggerem pod kątem: „warunek istnieje
tylko jako inny trigger, więc obcy trigger omija bramkę".

### 3.1 [istotne] `1784804668795` „Klima salon: wyłącz…" — OFF nie sprawdza `klima_salon_auto`

Gałąź ON wymaga `klima_salon_auto = on`; gałąź OFF (sunset / balkon ≤ salon
15 min / auto→off) ma tylko warunek `climate = cool`. Scenariusz: użytkownik
wyłącza tryb auto i chłodzi ręcznie — o zachodzie słońca (albo gdy balkon
zrówna się z salonem) automatyzacja i tak ubije chłodzenie i odpali suszenie
parownika. Jeśli intencja to „suszenie parownika zawsze, niezależnie od trybu"
— OK, ale wtedy warto to zapisać w `description`. PROPOZYCJA: decyzja
operatora; przy „auto-only" dodać warunek `klima_salon_auto = on`.

### 3.2 [istotne] `1768946230585` — pattern omija semantykę „po aktywacji" (opisane w 2.4)

Formalnie ta sama klasa: trigger krawędziowy (off→on) plus trigger czasowy,
który wchodzi tą samą bramką warunków co stan ciągły.

### 3.3 Przypadki sprawdzone i czyste

- `1751562415786` „Turn off lights in Kuchnia": triggery czujnikowe + pattern
  /5 + 23:30:02, ale warunki lustrzanie wymagają wszystkich czterech czujników
  `not_occupied` — pattern nie omija bramki. OK.
- `1764190493305` „after 15 minutes anyway": pattern /5 zlustrzany warunkami
  14:45. OK (problem tej automatyzacji to 2.1, nie klasa 3).
- `1744918189114`/`1744919280479`/`1744919746930` (pigry/piplayer): pattern co
  minutę, warunki z `for:` — lustrzane. OK.
- `1666471111199` „Zasilanie multimediów auto-off": pattern co minutę, warunki
  TV off 1 min + gniazdko on 10 min — okno rozruchu TV (2m35s w `1764610725230`)
  mieści się w 10-minutowej karencji. OK.
- Pary ON/OFF na wspólnym triggerze (`1640285211569/...276640` — 1_hold Tymka)
  bramkowane `is_off`/`is_on` — wzorzec poprawny (choć encje martwe, 1.5).

## 4. Higiena

### 4.1 [kosmetyczne] Aliasy-śmieci i rozjazdy alias ↔ entity_id

| entity_id (fixtures) | alias (repo) | problem |
|---|---|---|
| `automation.lampka_test_1_on` | „Mirror OFF" | entity z testu żarówki, robi lustro |
| `automation.xxxxxx` | „Turn on led nad blatem duzym prawym" | — |
| `automation.new_automation` | „4b: 1_sc: Swiatlo nad kuchnia" | — |
| `automation.new_automation_2` | „1b2: 1_ho: Choinka i lampki OFF" | — |
| `automation.new_automation_3` | „Turn off swiatlo nad kuchnia when no motion, no trigger" | — |
| `automation.choinka` | „4b:  2_dc: Activate Scene Film" | alias zmieniony (legacy: „Lampki na półce"), entity zostało po choince |
| `automation.swiatlo_za_telewizorem_z_przycisku` | „1b2: 1_dc: Choinka i lampki ON" | entity po starej funkcji |
| `automation.gniadka_w_lazience_off` | „Gniazdka w Łazience OFF" | alias naprawiony (57a5f66), entity z literówką zostało |
| `automation.turn_off_lights_in_kuchania` | „Turn off lights in  Kuchnia" | literówka „kuchania" — na tym entity wisi 8 referencji z innych automatyzacji! |
| `automation.email_on_water_sensor_dry_in_lazienka_2/3/4` | dry in **Kuchnia/Pralnia/WC** | kopie po Łazience |
| `automation.turn_off_blat_w_pralnia_on_md` | „Turn **ON** blat w Pralnia on MD" | entity mówi „off" |
| `automation.set_heaterhelitv07_…` / `set_heaterlazienkatrv10_…` / `set_heatersypialniatv02_…` / `set_heatertymktv10_…` | aliasy TRV10/TRV07 | numery TRV w entity nie zgadzają się z aliasami |

Duplikatów aliasów brak. PROPOZYCJA: nie zmieniać entity_id hurtowo (referencje
krzyżowe — zwłaszcza `turn_off_lights_in_kuchania` jest celem `automation.turn_on/off`
z 8 miejsc); jeśli porządkować, to najpierw mapa referencji, osobny task.
Aliasy typu „test"/„xxxxxx" można prostować bezpiecznie (alias nie jest
identyfikatorem).

### 4.2 [istotne] Sezonowe aktywne poza sezonem (choinka w lipcu)

- `1734943824257` „Turn ON Choinka na wejscie" — **włączona**, ostatni trigger
  2026-05-02 (sic!), cele: tasmota_12 („Lampki na półce"), tasmota_8
  („Choinka"), zblampkiregal — wszystkie trzy unavailable (fizycznie odpięte).
- `1689079279480`/`1689079321508` „1b2: 1_dc/1_ho: Choinka i lampki ON/OFF" —
  przyciskowe, włączone, cele unavailable.
- Scena `Film` (`1730724373818`) ma zapisany stan `switch.tasmota_8: unavailable`
  (scena robiona przy odpiętej choince) i `tasmota_12: on`.

PROPOZYCJA: wyłączać (nie kasować) sezonowe automatyzacje po sezonie — np.
konwencja aliasu `[sezon:zima]` + jedna automatyzacja/checklista sezonowa.
Scena Film do przegrania bez encji choinkowych.

### 4.3 [kosmetyczne] `last_triggered` NULL lub >12 miesięcy (kandydaci do przeglądu)

- 2024: `1640285211569`, `1640285276640` (Tymek ON/OFF — martwe encje, 1.5),
  `1703104933437` „Turn OFF TYmka sufit" (2024-09, wyłączona).
- NULL: `1752086343222` „moist in Kuchnia" (patrz 2.6 — zostawić, to alert),
  `1760432474594` (martwa, 1.5).
- Wyłączone od dawna: `1704492239040/288312` „prototyp w ubikacji" (2025-08,
  świadomie zarzucony — patrz 5), `1752241986989` „test test…" (2025-07),
  `1701370240657` „Przyjscie Tymka" (2025-11, wyłączona), `1744918520715`
  „Turn on pigry wo trigger" (2025-04; bez triggerów — de facto skrypt).
- `1714050591470` „Leave auto on: batch 02" — **wyłączona**, podczas gdy
  „Leave auto off: batch 02" włączona. Przy najbliższym urlopie symulacja
  obecności zapali tylko batch 01. Niespójność do decyzji.

### 4.4 [kosmetyczne] Automatyzacje-bez-triggerów używane jak skrypty

`speak_mirror`, `speak_mirror_alert`, `Poranek stop`, `new_automation_3`,
`Turn on pigry wo trigger`, `Test ntfy` — wywoływane przez `automation.trigger`
lub ręcznie. Działa, ale to semantycznie skrypty (byłyby widoczne w UI skryptów,
nie zaśmiecałyby listy automatyzacji i nie miałyby stanu on/off do przypadkowego
wyłączenia). PROPOZYCJA: przepisać na `script.*` przy okazji porządków.

### 4.5 [kosmetyczne] Inne

- `input_boolean.motion_front` — nieużywany w żadnej automatyzacji (kandydat do
  kasacji); `input_number.test` — jw.
- `input_datetime.koniec_urlopu` = 2026-01-31 (przeszłość) — trigger
  `End of On leave` nie odpali do czasu ustawienia nowej daty; spójne z
  `on_leave = off`, ale warto wiedzieć, że to ręczny krok przy każdym urlopie.
- `sensor.4button_battery` unavailable od 2026-07-17, a automatyzacje 4b:
  strzelały jeszcze 2026-07-12 — pilot prawdopodobnie na resztkach baterii
  (albo ofiara tej samej awarii co zhimi). Do sprawdzenia fizycznie — wisi na
  nim 8 automatyzacji salonu.

## 5. Porównanie z legacy (60 automatyzacji archiwum)

54/60 ma odpowiednik na ken po tym samym `id`. Bez odpowiednika:

| legacy id | alias | ocena |
|---|---|---|
| 1639950051409 | `--Test obecnosci telefonu` | test (prefiks `--`), strata zerowa |
| 1666696862316 | `---Zone Notification oka leave home` | blueprint, prefiks `---` (wyłączony konwencją), strata zerowa |
| 1667745509155 | `Notify move in Sypialnia` | na ken zastąpione wariantem **tylko on-leave** (`1753883109847`). Funkcja „zawsze powiadom o ruchu w sypialni" znikła — wygląda na świadomą redukcję szumu, do potwierdzenia |
| 1701086617456 | `Oczyszczacz i nawilżacz z przycisku` | przycisk sypialni (long) przemapowany na ken na Sleep mode OFF (`1768946838707`) — świadoma zmiana funkcji przycisku |
| 1701087364463 | `Wszystkie nawilżacze i oczyszczenie z przycisku` | jw. (double → Sleep mode ON) |
| 1703105565821 | `Turn OFF pimirror` | **jedyna realna strata**: graceful shutdown lustra (press przycisku shutdown → 1 min → odcięcie zasilania). Na ken zostało tylko twarde cięcie o 23:35 (`Mirror OFF`) i ścieżka ACK (`Magic Mirror OFF on ACK`), której nic już nie inicjuje — RPi lustra jest codziennie twardo odłączany od prądu |

Znany przypadek świadomej decyzji (wzorzec, jak to robić dobrze): „prototyp w
ubikacji" istnieje na ken, ale **wyłączony**, czujnik zdemontowany, a dimmer
`light.tsdimm01` przeznaczony ponownie do LED nad małym blatem w kuchni.
Uwaga praktyczna: przypadkowe włączenie tej pary automatyzacji miga światłem w
kuchni od (martwego dziś) czujnika ubikacji — bezpieczniej skasować niż trzymać
wyłączone.

PROPOZYCJA: odtworzyć graceful shutdown lustra (mqtt `halt` przed 23:35 +
istniejący ACK-flow zamiast gołego odcięcia zasilania); potwierdzić decyzję o
sypialni; resztę uznać za zamkniętą.

## 6. Spójność stylistyczna (informacyjnie, nie błędy)

- **Nazewnictwo**: trzy pokolenia konwencji naraz — prefiksy przyciskowe
  (`4b: 3_sc:`, `1b2: 1_ho:`), angielskie zdania („Turn off lights in Kuchnia
  after 15 minutes anyway"), polskie zdania („Oczyszczacz i nawilżacz prze
  przycisk Tymka"). Mieszanka PL/EN często w jednym aliasie. Literówki:
  „Toogle", „prze przycisk", „Lampiki", „wzmaczniacz", „Oczyszczecze",
  „Gniadka" (w entity), „kuchania" (w entity).
- **device_id vs entity_id**: ~60% akcji to `device automation` z surowymi
  `device_id`/UID-ami registry (32-znakowe hexy) — nieczytelne w YAML-u i
  kruche przy wymianie sprzętu (nowe urządzenie = nowy device_id = cicha
  śmierć automatyzacji; dokładnie ten mechanizm ubił parę Tymka z 1.5 i ukrył
  rename occusalon z 1.5). Nowsze automatyzacje (klima, ledy blatowe) używają
  już `action` + `entity_id` — ta konwencja powinna być docelowa dla wszystkich
  nowych/przepisywanych automatyzacji.
- **TTS**: dwa systemy równolegle — `tts.google_translate_say` na martwym
  Bose (Speak) vs `tts.piper` na pimirror (reszta). Docelowo jeden.
- **Polling vs zdarzenia**: 13 automatyzacji `time_pattern`, w tym co-minutowe
  („Send balkon temp to mm", multimedia, pigry/piplayer) i sub-minutowe
  (current_player 15 s, TRV 40–50 s). Część jest uzasadniona (ping-sensory),
  ale kierunek powinien być zdarzeniowy tam, gdzie HA ma trigger (np.
  `Send balkon temp` → trigger na zmianę stanu sensora zamiast REST co minutę).
- **Tryby**: cztery flagi trybów (`sleep_mode`, `night_mode`, `passive_mode`,
  `movie_mode`) o częściowo pokrywającej się semantyce; `night_mode` włącza się
  o 23:30 i gaśnie o wschodzie (latem 4:30), `sleep_mode` gaśnie o 6:30 —
  automatyzacje sprawdzają raz jedną, raz drugą, raz OR obu. Entity
  `automation.turn_off_sleep_mode_at_sunrise` steruje… `night_mode`. Do
  przemyślenia konsolidacja w jeden `input_select.tryb_domu`.

## Do decyzji operatora

Pytania tak/nie, do przejścia punkt po punkcie:

1. Wymieniamy baterie / re-parujemy 6 czujników ruchu (mdwejscie, mdsypialnia,
   mdtymka, mdheli, mdubikacja, occusalon) i czujnik wycieku WC? (1.2, 1.3)
2. Naprawiamy kalibracje TRV przed sezonem: guard na unavailable + reset −5.0
   w sypialni/Tymku + zwolnienie pętli do ≥5 min? (1.4)
3. Diagnozujemy integrację xiaomi_miot (padła 2026-07-17 razem z encjami zhimi)
   zamiast łatać pojedyncze automatyzacje? (1.6)
4. Poprawiamy parę wodną Kuchnia (`moist`→`not_moist`) i literówkę `mesaage`
   w „dry in Lazienka"? (2.6) — dwie zmiany one-linerowe.
5. Weryfikujemy na żywym ken istnienie helperów klimy
   (`klima_salon_auto`, `_temp_docelowa`, `_tolerancja`)? (1.1)
6. Czy „Klima salon: wyłącz" ma ubijać także ręczne chłodzenie o zachodzie
   (obecne zachowanie), czy respektować `klima_salon_auto = off`? (3.1)
7. Czy enforcer sleep mode ma gasić światła cyklicznie całą noc (obecne
   zachowanie), czy tylko raz po aktywacji? (2.4)
8. Czy „Turn off lights in Kuchnia after 15 minutes anyway" ma respektować
   ręczne „Disable AUTO off" (double-click)? (2.1)
9. Konsolidujemy cztery nocne wyłączniki świateł do jednego? (2.2)
10. Kasujemy martwe od lat: para Tymka [ON]/[OFF], „test test Powitanie…",
    „Notify on router sypialnia…", para „prototyp w ubikacji"? (1.5, 4.3, 5)
11. Przywracamy OwnTracks (lokalizacja Oskar) czy kasujemy automatyzację
    i `device_tracker.oskar`? (1.5)
12. Włączamy z powrotem „Leave auto on: batch 02" (symulacja obecności) —
    czy celowo została wyłączona? (4.3)
13. Wyłączamy na lato automatyzacje choinkowe i przegrywamy scenę Film bez
    encji choinki? (4.2)
14. Odtwarzamy graceful shutdown pimirror (jedyna realna strata z migracji)?
    (5)
15. Sprawdzamy baterię pilota 4button (8 automatyzacji salonu na jednym
    urządzeniu, encje unavailable od 2026-07-17)? (4.5)
16. Naprawiamy „Turn off lights unconditionally at 3am" na punktowy trigger
    03:00 (dziś strzela 60×/noc)? (2.3)
17. Ustalamy konwencję na przyszłość: nowe automatyzacje tylko `entity_id`
    (bez device automations) + aliasy w jednym języku? (6)

---
Wygenerowano w ramach audytu read-only; żadna automatyzacja, skrypt ani scena
nie zostały zmodyfikowane. Snapshot źródłowy: registry/fixtures 2026-07-22,
repo `task/ha-audyt-automatyzacji` (parent `faa2e2a`).