docs(ha): audyt automatyzacji ken 2026-07-23
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
oskar
parent
f3328d2c75
commit
f0e9533025
502
services/home-assistant/docs/audyt-automatyzacji-2026-07-23.md
Normal file
502
services/home-assistant/docs/audyt-automatyzacji-2026-07-23.md
Normal file
|
|
@ -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`).
|
||||||
Loading…
Reference in a new issue