homelab-codex-ws/kb/audits/ha-automatyzacje-2026-07-23.md

okf	type	visibility	status	updated	as_of	links
0.1	audit	private	active	2026-07-23	2026-07-23

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).