From f0e9533025569c4419ff1d88e55de31a8a3f137c Mon Sep 17 00:00:00 2001 From: oskar Date: Thu, 23 Jul 2026 15:25:18 +0200 Subject: [PATCH] docs(ha): audyt automatyzacji ken 2026-07-23 Co-Authored-By: Claude Fable 5 --- .../docs/audyt-automatyzacji-2026-07-23.md | 502 ++++++++++++++++++ 1 file changed, 502 insertions(+) create mode 100644 services/home-assistant/docs/audyt-automatyzacji-2026-07-23.md diff --git a/services/home-assistant/docs/audyt-automatyzacji-2026-07-23.md b/services/home-assistant/docs/audyt-automatyzacji-2026-07-23.md new file mode 100644 index 0000000..ee64525 --- /dev/null +++ b/services/home-assistant/docs/audyt-automatyzacji-2026-07-23.md @@ -0,0 +1,502 @@ +# 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`).