From 09624e008e3ea306cd6ff247f3241488ae4863f1 Mon Sep 17 00:00:00 2001 From: oskar Date: Mon, 27 Jul 2026 16:59:52 +0200 Subject: [PATCH] =?UTF-8?q?feat(ha/ken):=20porzadki=20po=20audycie=20?= =?UTF-8?q?=E2=80=94=20pimirror=20z=20archiwum,=20konwencje,=20backlog?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Odtworzone graceful shutdown pimirror (audyt pkt 14, jedyna realna strata migracji): nowa automatyzacja "Pimirror: graceful shutdown przed odcieciem zasilania" (1785164185794.yaml) wciska przycisk shutdown przed twardym cieciem zasilania o 23:35, dajac istniejacemu ACK-flow ("Magic Mirror OFF on ACK") szanse zamknac Pi grzecznie zamiast zawsze odcinac prad na sile. Zaadaptowane wzgledem legacy: entity_id zamiast device automation, oryginalna encja button.rpi_pimirror_* jest dziś unavailable — uzyto aktualnej button.rpi_pimirror2_* (potwierdzone w storage-export/ken). Spisana konwencja na przyszlosc (audyt pkt 17) w DESIGN.md: entity_id zamiast device automations, alias PL z prefiksem funkcjonalnym, description z "managed-by: repo" — bez hurtowej migracji istniejacych automatyzacji. Backlog: deploy.sh --delete (kasacje wspolnym torem dry-run/LIVE zamiast recznych curl DELETE) i brakujacy trigger na zmiane input_number.klima_salon_tolerancja w automatyzacji ON klimy. Walidacja: normalizator round-trip (byte-identical), 4 pakiety testow offline (normalize/split/deploy_api/import_api) pass, dry-run deploy.sh na zywym ken (check_config valid, brak driftu) — bez LIVE deployu. --- docs/backlog.md | 40 +++++++++++++++++++ services/home-assistant/DESIGN.md | 21 ++++++++++ .../config/ken/automations/1785164185794.yaml | 15 +++++++ 3 files changed, 76 insertions(+) create mode 100644 services/home-assistant/config/ken/automations/1785164185794.yaml diff --git a/docs/backlog.md b/docs/backlog.md index e7f7876..a26cc44 100644 --- a/docs/backlog.md +++ b/docs/backlog.md @@ -102,6 +102,46 @@ historia incydentów, out-of-band watchdog. ## Aktywne +### `scripts/ha/deploy.sh --delete`: brak wspólnego toru kasacji automatyzacji + +**Data**: 2026-07-27 +**Źródło**: sesja porządków po audycie (`task/ha-porzadki`); kontekst bezpośredni: +kasacja pkt 10 (`36b43e5`, para Tymka/powitanie-test/notify-router/para-prototyp) +zrobiona pętlą ręcznych `curl DELETE` po API zamiast przez repo tooling. +**Problem**: `deploy.sh` ma tylko WRITE (`POST /api/config//config/`) — +zgodnie z DESIGN.md ("Deploy path") i istniejącym wpisem w tym backlogu (sekcja +"Cutover HA ken", krok 4) DELETE obiektów usuniętych z repo jest poza zakresem, +drift-check tylko ostrzega (`warnings`), nigdy nie kasuje. Efekt: jedyna droga +usunięcia automatyzacji z żywej instancji to ręczne wywołanie API, bez +drift-check/`check_config`/verify, czyli bez żadnej z gwarancji, które deploy.sh +daje dla write. +**Fix**: `deploy.sh --delete ` (albo `--delete` jako tryb pracy +na plikach usuniętych z repo, wykrytych przez `drift_warnings`) z tym samym rytmem +co write: dry-run domyślny, `--dry-run`/LIVE jak dziś, `DELETE +/api/config//config/` per obiekt, verify (GET → oczekiwane 404) zamiast +porównania treści. Scope jak przy write: automations/scripts/scenes. + +--- + +### HA ken: `input_number.klima_salon_tolerancja` nie ma triggera — zmiana nie przelicza progu + +**Data**: 2026-07-27 +**Źródło**: sesja porządków po audycie (`task/ha-porzadki`), przy okazji przeglądu +`1784804667795` dla konwencji automatyzacji (pkt 17) +**Problem**: `"Klima salon: włącz chłodzenie i synchronizuj cel"` (`1784804667795`) +ma trigger `id: sync` na `input_number.klima_salon_temp_docelowa` (zmiana celu od +razu przelicza próg), ale brak odpowiednika dla `input_number.klima_salon_tolerancja` +— to ta sama klasa buga co "trigger brzegowy bez lustrzanego warunku" z audytu +(sekcja 3, wzorzec `klima_salon` z fixu `faa2e2a`), tylko po stronie triggerów, nie +warunków: zmiana tolerancji na dashboardzie nic nie przelicza do najbliższej +naturalnej zmiany `sensor.thsalon_temperature`. +**Fix**: dodać trigger `state` na `input_number.klima_salon_tolerancja` do gałęzi +`sync` (albo do analogicznej gałęzi w automatyzacji OFF, jeśli tolerancja wpływa też +na próg wyłączenia) w `1784804667795`, tak samo jak istniejący trigger na +`_temp_docelowa`. + +--- + ### HA ken: guard TRV kalibracji przed sezonem grzewczym (~2026-09) **Data**: 2026-07-23 diff --git a/services/home-assistant/DESIGN.md b/services/home-assistant/DESIGN.md index 3cec4fd..907505f 100644 --- a/services/home-assistant/DESIGN.md +++ b/services/home-assistant/DESIGN.md @@ -210,6 +210,27 @@ poprawki oczywistych bugów, audyt 2.6 i 2.3): turn_off_lights_in_kuchania = on` (double-click wyłącza tę automatyzację; „anyway" teraz cofa się przed tym stanem zamiast go unieważniać po 15 min). +## Konwencje automatyzacji + +Ustalone po audycie 2026-07-23 (`docs/audyt-automatyzacji-2026-07-23.md`, sekcja 6 +"Spójność stylistyczna", pkt 17 checklisty operatora — decyzja: TAK). Obowiązuje dla +**nowych** automatyzacji od teraz; istniejące **nie są migrowane hurtowo** (patrz +sekcja 4.1 audytu — konsolidacja/rename `entity_id` wymaga osobnej mapy referencji +krzyżowych, to osobny task, nie efekt uboczny porządków). + +- **`entity_id`, nie device automations.** `device_id`/encja-UID (32-znakowy hex) są + nieczytelne w YAML-u i kruche przy wymianie sprzętu — nowe urządzenie generuje nowy + `device_id`, a automatyzacja umiera po cichu (dokładnie ten mechanizm ubił parę + Tymka i ukrył rename `occusalon`, patrz audyt 4.1). Nowe automatyzacje używają + `action:`/`trigger:`/`condition:` z `entity_id:` jawnym. +- **Alias po polsku, z prefiksem funkcjonalnym.** Format `": "`, np. + `"Klima salon: włącz chłodzenie i synchronizuj cel"`, `"Pimirror: graceful shutdown + przed odcięciem zasilania"`. Jeden język w aliasie (nie mieszanka PL/EN jak w + automatyzacjach z audytu 6). +- **`description:` zawiera `managed-by: repo`.** Odróżnia automatyzacje autorskie + repo od tych z UI/migracji; przy okazji miejsce na kontekst (skąd odtworzone, jakie + encje zaadaptowano — patrz przykład `1785164185794.yaml`). + ## Open questions - What actually drives the phase-3 operational agent (a new agent process diff --git a/services/home-assistant/config/ken/automations/1785164185794.yaml b/services/home-assistant/config/ken/automations/1785164185794.yaml new file mode 100644 index 0000000..a0ce0ff --- /dev/null +++ b/services/home-assistant/config/ken/automations/1785164185794.yaml @@ -0,0 +1,15 @@ +actions: +- action: button.press + target: + entity_id: button.rpi_pimirror2_rpi_shutdown_pimirror2_command +alias: 'Pimirror: graceful shutdown przed odcięciem zasilania' +conditions: +- condition: state + entity_id: switch.tasmota_2 + state: 'on' +description: 'Wciska przycisk graceful-shutdown pimirror2 przed twardym odcięciem zasilania o 23:35 ("Mirror OFF"), żeby Pi zdążył się bezpiecznie wyłączyć zanim zgaśnie prąd. Istniejący automat "Magic Mirror OFF on ACK" (MQTT dom/pimirror-ack "went-halt") odcina zasilanie switch.tasmota_2 ok. 2 min po ACK — "Mirror OFF" 23:35 zostaje jako pas bezpieczeństwa, gdyby ACK nie przyszedł (Pi zawieszony/offline). Odtworzone z ken-legacy (automations/1703105565821.yaml "Turn OFF pimirror"): legacy używał device automation (press przycisku + delay 1 min + turn_off switch bezpośrednio, bez zapisanego triggera — prawdopodobnie wywoływane ręcznie); tu: entity_id zamiast device_id, bez duplikowania wyłączenia zasilania (robi to już istniejący ACK-flow), trigger czasowy zamiast braku triggera. Adaptacja encji: legacy/oryginalny button.rpi_pimirror_dom_rpi_shutdown_pimirror_command jest unavailable na ken (fixtures/ken-states-2026-07-27.yaml) — użyto aktualnego button.rpi_pimirror2_rpi_shutdown_pimirror2_command (potwierdzone w storage-export/ken/core.entity_registry.yaml). managed-by: repo' +id: '1785164185794' +mode: single +triggers: +- at: '23:28:00' + trigger: time