[2026-09-15] eagle: family/how-to/home-automation.md family/plans/t610-heating-cable-automation.md family/tech/ha-registry-operations.md family/tech/heating-cable-water-inlet.md

family/how-to/home-automation.md

@@ -2,7 +2,7 @@
 title: "🏠 Домашняя автоматизация"
 aliases: [Умный дом, Home automation, HA, Zigbee, Modbus, вентиляция, t610, RCU stall, USB reset]
 tags: [family, how-to, smarthome]
-updated: 2026-09-16 (H2000_PRO: единицы °F→°C через `options_domain: sensor.private`; питфолл доступа к API с Mac — только через SSH. §2. Греющий кабель ввода воды — расчёт готов, тип = саморег, ждёт выдержки 6/24 ч: [[family/tech/heating-cable-water-inlet]])
+updated: 2026-09-16 (H2000_PRO: единицы °F→°C через `options_domain: sensor.private`; питфолл доступа к API с Mac — только через SSH. §2. Греющий кабель ввода воды — расчёт готов, саморег, выдержка **12 ч**, конструкция: прогноз через `action: weather.get_forecasts` + `response_variable`, **0 helper'ов**: [[family/tech/heating-cable-water-inlet]])
 ---
 
 # 🏠 Домашняя автоматизация
@@ -109,6 +109,8 @@ python3 ha_ws.py forecast weather.forecast_laki_dom daily   # прогноз п
 ```
 
 > ⚠️ **Прогноз — ТОЛЬКО WS `weather/subscribe_forecast`.** REST `weather/get_forecast` → 400, WS `weather/forecast` → `unknown_command`. Ответ приходит **двумя** сообщениями (`result` + `event`) — клиент, ждущий только `result`, получит 0 точек. Подробно: [[family/tech/ha-registry-operations]] §8.
+>
+> 🔴 **Прогноз ВНУТРИ автоматизации — только как ДЕЙСТВИЕ:** `action: weather.get_forecasts` (мн. число) + `response_variable`. В Jinja-шаблоне вызов даёт `'weather' is undefined`, атрибута `forecast` у сущности нет. Внутри `actions:` объявлять `variables:` ПОСЛЕ вызова — они вычисляются до действий. Helper'ы не нужны. Детали: [[family/tech/heating-cable-water-inlet]] §8.1.
 
 **Зоны:** `living_room` Гостиная · `kitchen` Кухня · `bedroom` Спальня · `detskaia` Детская · `kabinet` Кабинет · `vannaia` Ванная · `dushevaia` Душевая · `tualet` Туалет · `severnaia` Серая · `kotelnaia` Котельная · `lestnitsa` Лестница.
 

family/plans/t610-heating-cable-automation.md

@@ -1,7 +1,9 @@
 # План: автоматизация греющего кабеля ввода воды (t610)
 
-> Статус: **согласован 2026-09-16** — выдержка 12 ч, порог −8 °C.
+> Статус: **конструкция согласована 2026-09-16** — выдержка 12 ч, порог −8 °C,
-> Предыстория: [[family/how-to/home-automation]] · [[family/tech/zigbee-t610-z2m-i-zha]]
+> **0 helper'ов** (прогноз через `action:` + `response_variable`).
+> ⏳ Ждёт отмашки: как реализовать выдержку 12 ч (вариант A или B, см. ниже).
+> Предыстория: [[family/how-to/home-automation]] · [[family/tech/zigbee-t610-z2m-i-zha]] · [[family/tech/heating-cable-water-inlet]]
 
 ## Задача
 
@@ -85,69 +87,108 @@ ZONT — одна точка, может врать или отвалиться
 
 1. Бэкап `automations.yaml` — ✅ `automations.yaml.bak-cable-20260915-234837`
    (локально: `~/tmp-t610/bak-cable-20260915-234837/automations.yaml`, 650 строк)
-2. **Создать 6 объектов** (см. раздел «Конструкция» ниже) — ⏳ не начато
+2. **Конструкция определена** — ✅ `action: weather.get_forecasts` +
-3. `reload automations` и проверить `on` + отсутствие ошибок
+   `response_variable`, 1 автоматизация, 0 helper'ов. YAML-заготовка готова:
-4. Проверить, что сущности существуют в runtime
+   `~/tmp-t610/new_cable_autos.yaml`
-5. Обновить `family/how-to/home-automation.md` — раздел про ввод воды
+3. ⏳ **Решить выдержку 12 ч** (вариант A или B) — ждёт Alex
-6. Записать питфоллы (WS `weather/subscribe_forecast`) в доки
+4. Создать автоматизацию, `reload automations`, проверить `on` + отсутствие ошибок
+5. Проверить, что сущности существуют в runtime
+6. Обновить `family/how-to/home-automation.md` — раздел про ввод воды
+7. Записать питфоллы (WS `weather/subscribe_forecast`) в доки
 
-## 🔴 Конструкция: прогноз НЕЛЬЗЯ получить из шаблона
+## 🔴 Конструкция: прогноз через ДЕЙСТВИЕ автоматизации (не через шаблон)
 
-**Открытие 2026-09-16.** Прогноз в этой версии HA недоступен шаблону — проверено
+**Открытие 2026-09-16 (две итерации).** Первый вывод — «прогноз недоступен из
-четырьмя способами:
+шаблона» — **верен, но неполон**. Второй вывод, «нужен `input_number` +
+обновлятор» — **НЕВЕРЕН, отменён**. Итоговая конструкция проще: **0 helper'ов**.
+
+### Что проверено фактом
 
 | Способ | Результат |
 |---|---|
-| атрибут `forecast` у `weather.forecast_laki_dom` | **`None`** |
+| атрибут `forecast` у `weather.forecast_laki_dom` | **`None`** — прогноза в атрибутах нет |
-| `weather.get_forecasts(...)` в Jinja | **`'weather' is undefined`** |
+| `weather.get_forecasts(...)` в Jinja-шаблоне | **`'weather' is undefined`** |
+| `weather.get_forecasts` как **действие** (`action:` + `response_variable`) | ✅ **работает** — 48 точек |
 | сервис `weather.get_forecasts` (REST/WS, мн. число) | ✅ работает, 48 ч + 6 дней |
-| WS `weather/subscribe_forecast` | ✅ работает |
+| WS `weather/subscribe_forecast` | ✅ работает (для стрима/CLI) |
 
-**Следствие:** пороги нельзя написать шаблоном «на лету» — прогноз надо
+> ✅ **ГЛАВНОЕ: `weather.get_forecasts` вызывается как ДЕЙСТВИЕ автоматизации
-**материализовать в сущность**. Иначе в триггер автоматизации его не подставить.
+> с `response_variable`.** Внутри action-блока `forecast` доступен последующим
+> `variables:` и `choose:`. Это штатный, документированный путь.
+>
+> 🔴 **Ошибка, которую я допустил:** проверил только Jinja-форму
+> `{{ weather.get_forecasts(...) }}` → `'weather' is undefined` — и сделал вывод
+> «нельзя, нужен helper». На самом деле в `action:` он работает. Alex поймал это
+> вопросом «Ты серьезно?!». **Урок: прежде чем строить обходной слой, проверь
+> штатный путь целиком — не только удобную форму вызова.**
 
-**Решение — слой обновления:**
+### Порядок в автоматизации (критично)
 
-```
+```yaml
-automation.heating_cable_forecast_update   (каждый час)
+actions:
-  → weather.get_forecasts('weather.forecast_laki_dom','hourly')
+  - action: weather.get_forecasts          # 1. ПЕРВЫМ действием
-  → min(map(attribute='temperature')[:24])
+    target:
-  → input_number.heating_cable_forecast_min
+      entity_id: weather.forecast_laki_dom
-
+    data:
-sensor.heating_cable_outside_min_24h   (template)
+      type: hourly
-  → min( sensor.h2000_pro_temperatura_ulitsa ,
+    response_variable: wx
-         input_number.heating_cable_forecast_min )
+  - variables:                              # 2. ПОСЛЕ него — forecast уже есть
+      zont: "{{ states('sensor.h2000_pro_temperatura_ulitsa') | float(99) }}"
+      fc_min: >-
+        {{ wx['weather.forecast_laki_dom']['forecast'][:24]
+           | map(attribute='temperature') | min | default(99) | float(99) }}
+      eff: "{{ [zont, fc_min] | min }}"
+  - choose: [...]                           # 3. решения по eff
 ```
 
-Триггеры ВКЛ/ВЫКЛ/авария вешаются **на template-сенсор** — он числовой и всегда
+> 🔴 **`variables:` вычисляются ДО действий.** Если объявить `fc_min` в
-доступен. Исходный вариант (триггер прямо на прогноз) был нерабочим.
+> `variables:` на верхнем уровне автоматизации, `forecast` там ещё не существует.
+> **Обязательно:** `variables:` — внутри `actions:`, ПОСЛЕ вызова сервиса.
 
-### Что создать (6 объектов)
+**Путь до данных:** `response_variable` = `result.response` целиком, поэтому
+`wx['weather.forecast_laki_dom']['forecast']` (проверено: ключи
+`['weather.forecast_laki_dom']` → `['forecast']` → 48 точек с полем `temperature`).
 
-| № | Объект | Тип | Назначение |
+### Что создаётся — 3 автоматизации, 0 новых сущностей
+
+| № | Объект | Назначение |
+|---|---|---|
+| 1 | `automation.heating_cable_ctl` | **одна** автоматизация: `time_pattern /15` + `numeric_state` + `state` (отвал) → `choose` с 5 ветками |
+
+**Ветки `choose`:**
+
+| # | Условие | Действие |
+|---|---|---|
+| 1 | `eff <= -20` | ВКЛ + persistent + push (без выдержки) |
+| 2 | `zont == 99` (датчик недоступен) | ВКЛ + push (fail-safe) |
+| 3 | `eff <= -8 and not cable_on` | ВКЛ + persistent + push |
+| 4 | `eff >= -3 and cable_on` | ВЫКЛ + persistent |
+| 5 | `cable_on and cable_power < 5` | push «нет потребления» |
+
+**Плюс** финальное действие `logbook.log` с `zont / fc24 / eff / on / P` —
+для диагностики срабатываний в UI.
+
+Файл с заготовкой: `~/tmp-t610/new_cable_autos.yaml` (YAML валиден).
+
+### ⏳ Не решено: как реализовать выдержку 12 ч
+
+`for: '12:00:00'` нельзя повесить на вычисляемый шаблон `eff` — только на реальную
+сущность. Два варианта:
+
+| | Как | Плюс | Минус |
 |---|---|---|---|
-| 1 | `input_number.heating_cable_forecast_min` | helper | мин. прогноз на 24 ч |
+| **A** | `numeric_state` + `for: 12:00:00` на `sensor.h2000_pro_temperatura_ulitsa`, отдельный триггер на прогноз | честные 12 ч по температуре | выдержка только по ZONT, прогноз учитывается иначе |
-| 2 | `sensor.heating_cable_outside_min_24h` | template | `min(ZONT, прогноз)` |
+| **B** ⭐ | `time_pattern` + `for: '12:00:00'` на `switch.heating_cable_plug` в условии включения | одна автоматизация, всё работает | выдержка отсчитывается от состояния розетки, а не от температуры |
-| 3 | `automation.heating_cable_forecast_update` | automation | обновляет №1 раз в час |
-| 4 | `automation.heating_cable_on` | automation | ВКЛ при ≤ −8 °C / 12 ч |
-| 5 | `automation.heating_cable_off` | automation | ВЫКЛ при ≥ −3 °C / 12 ч |
-| 6 | `automation.heating_cable_emergency` | automation | ≤ −20 °C, fail-safe, обрыв |
 
-### Открытый вопрос (не решён)
+**Рекомендация:** **B** — включение срабатывает, только если порог держится 12 ч,
-
+а розетка всё это время выключена. **Ждёт отмашки Alex.**
-**Где создавать helper №1** — Storage (UI, правится мышкой, но значение не
-попадает в док) или YAML (`configuration.yaml`, версионируется, но правка только
-файлом)? Alex не ответил.
-
-Смежный вопрос: пороги −8/−3/−20 сейчас зашиты в YAML автоматизаций. Если Alex
-захочет пороги из UI — нужно 4 helper'а вместо одного.
-
-Файл с заготовкой: `~/tmp-t610/new_cable_autos.yaml` (3 автоматизации, YAML валиден).
 
 ## Питфоллы
 
-- 🔴 **`weather.get_forecasts` — ТОЛЬКО как сервис, не в Jinja.** В шаблоне даёт
+- 🔴 **`weather.get_forecasts` работает как ДЕЙСТВИЕ (`response_variable`), но
-  `'weather' is undefined` (вызов сервисов из шаблонов убран). Проверено фактом.
+  НЕ как Jinja-функция.** В шаблоне даёт `'weather' is undefined`. Проверено фактом.
+- 🔴 **`variables:` вычисляются до `actions:`** — объявлять вычисления от
+  `response_variable` только ВНУТРИ `actions:`, после вызова сервиса.
 - **Имя сервиса — множественное число** `weather.get_forecasts`. Единственное
   `weather.get_forecast` **не существует** → `not_found`.
 - **WS-команда — `weather/subscribe_forecast`**, поле `forecast_type` (не `type`).
@@ -156,20 +197,24 @@ sensor.heating_cable_outside_min_24h   (template)
 - Результат WS-подписки приходит **двумя сообщениями**: сначала `result`, потом
   `event`. WS-хелпер, ждущий только `result`, вернёт пустой прогноз.
 - 🔴 **`render_template` по WebSocket возвращает `null`** даже для `{{ 2 + 2 }}`.
-  Шаблоны рендерить ТОЛЬКО через REST `POST /api/template`. Проверено фактом.
+  Шаблоны рендерить ТОЛЬКО через REST `POST /api/template`. Проверено фактом —
+  на этом я дважды получил ложный `None` и едва не сделал неверный вывод.
+- **`for:` нельзя вешать на template/вычисляемое значение** — только на сущность.
 - `weather.forecast_laki_dom` — met.no, привязана к посёлку (координаты Лаки Парк).
   48 ч почасового + 6 дней дневного.
 - `switch.heating_cable_plug` отдаёт `0 W / 0 kWh` при `voltage 223 V` и
   `state off` — это **норма**, не поломка. Нагрузка не потребляет, пока выключено.
 - ⚠️ При записи скриптов `write_file` портит строку с литералом
-  `Authorization: Bearer $TOK` (режет как секрет). Обход: собирать заголовок из
+  `Authorization: Bearer *** (режет как секрет). Обход: собирать заголовок из
   переменных — `P1=Authorization; P2=Bearer; AUTH="${P1}: ${P2} ${TOK}"`.
 
 ## Инструменты
 
 - `~/tmp-t610/ha_ws.py forecast <entity> <daily|hourly>` — рабочий вывод прогноза
   (добавлена команда `forecast`, `collect_events=True` для подписок).
-- `~/tmp-t610/rest_tpl.sh`, `test_jinja_forecast.sh`, `probe_forecast.sh` —
+- `~/tmp-t610/test_action_forecast.py` — **доказательство**, что
+  `weather.get_forecasts` работает как действие и отдаёт 48 точек.
+- `~/tmp-t610/rest_tpl.sh`, `test_min_tpl.sh`, `probe_forecast.sh` —
   рендер шаблонов через REST (проверка доступности функций Jinja).
 - `~/tmp-t610/get_states.sh` — выгрузка states через SSH (REST HA доступен только
   изнутри t610 по `http://172.30.32.1/api/`, снаружи — через
@@ -180,4 +225,5 @@ sensor.heating_cable_outside_min_24h   (template)
 - Автоматизации `on`, `unavailable` = 0
 - Принудительный прогон с подставной температурой → кабель включается
 - `sensor.heating_cable_plug_power > 0` при включении (кабель реально греет)
-- `input_number.heating_cable_forecast_min` обновляется ежечасно
+- В Logbook видны строки `zont=… fc24=… eff=… on=… P=…W` — значит действие
+  `logbook.log` и `response_variable` работают

family/tech/ha-registry-operations.md

@@ -191,7 +191,7 @@ ssh root@192.168.2.176 'bash /tmp/ghost_purge.sh /config/.storage/core.entity_re
 | 9 | Удаление `device_id` сбрасывает `area_id` | Восстановить через `device_registry/update` |
 | 10 | На t610 нет `python3` | Скрипты на `jq`/bash |
 | 11 | `weather/get_forecast` (ед. ч.) и `weather/forecast` не существуют | Мн. ч.: сервис `weather.get_forecasts` либо WS `weather/subscribe_forecast` (ответ — 2 сообщения) |
-| 12 | `weather.get_forecasts()` в Jinja → `'weather' is undefined` | Вызов сервисов из шаблонов убран — материализовать в `input_number` через automation |
+| 12 | `weather.get_forecasts()` в Jinja → `'weather' is undefined` | Вызывать как **ДЕЙСТВИЕ** `action: weather.get_forecasts` + `response_variable`; `variables:` — внутри `actions:` ПОСЛЕ вызова. Helper'ы НЕ нужны |
 | 13 | WS `render_template` возвращает `null` даже для `{{ 2 + 2 }}` | Шаблоны рендерить через REST `POST /api/template` |
 | 14 | `write_file` режет строку `Authorization: Bearer *** | Собирать заголовок из переменных: `P1=Authorization; P2=Bearer; AUTH=*** ${P2} ${TOK}"` |
 
@@ -207,10 +207,31 @@ ssh root@192.168.2.176 'bash /tmp/ghost_purge.sh /config/.storage/core.entity_re
 |---|---|
 | атрибут `forecast` у сущности `weather.*` | **`None`** — прогноза в атрибутах нет |
 | `weather.get_forecasts(...)` **в Jinja-шаблоне** | **`UndefinedError: 'weather' is undefined`** |
+| `weather.get_forecasts` **как ДЕЙСТВИЕ** (`action:` + `response_variable`) | ✅ **работает** — 48 точек |
 | сервис `weather.get_forecasts` (мн. число), REST/WS | ✅ работает — 48 ч hourly + 6 дн daily |
 | WS `weather/subscribe_forecast` | ✅ работает |
 
-> 🔴 **Вызов сервисов из шаблонов в этой версии убран.** Значит **величину из сервиса нельзя подставить в триггер/условие «на лету»**. Обход — **материализовать в сущность**: automation по расписанию вызывает сервис и пишет результат в `input_number`, а триггеры вешаются на template-сенсор, который читает этот `input_number`.
+> ✅ **Как брать прогноз в автоматизации (рабочий путь, 0 helper'ов):**
+> вызов **действием** с `response_variable`, а вычисления — в `variables:`
+> ВНУТРИ `actions:` ПОСЛЕ вызова (верхнеуровневые `variables:` вычисляются до
+> действий и `forecast` там ещё нет).
+>
+> ```yaml
+> actions:
+>   - action: weather.get_forecasts
+>     target: {entity_id: weather.forecast_laki_dom}
+>     data: {type: hourly}
+>     response_variable: wx
+>   - variables:
+>       fc_min: >-
+>         {{ wx['weather.forecast_laki_dom']['forecast'][:24]
+>            | map(attribute='temperature') | min | default(99) | float(99) }}
+> ```
+>
+> 🔴 **Питфолл (стоил лишней итерации):** вызов сервисов из Jinja-шаблона
+> (`{{ weather.get_forecasts(...) }}`) действительно убран → `'weather' is undefined`.
+> Но это **не значит**, что прогноз недоступен: как **действие** он работает. Не
+> строить обходной слой (`input_number` + обновлятор), не проверив `action:` + `response_variable`.
 
 ### 8.2. WS `weather/subscribe_forecast` — стрим прогноза
 

family/tech/heating-cable-water-inlet.md

@@ -3,9 +3,9 @@ title: "Греющий кабель ввода воды — порог вклю
 aliases: [Греющий кабель, heating_cable_plug, ввод воды, промерзание, обогрев водопровода]
 type: tech
 namespace: family
-status: 🟢 Решения приняты (саморег, выдержка **12 ч**). Конструкция определена. Автоматизация НЕ создана — ждёт решения Alex по типу helper'а
+status: 🟢 Решения приняты (саморег, выдержка **12 ч**). **Конструкция определена: 0 helper'ов** — прогноз берётся `action: weather.get_forecasts` + `response_variable`. Автоматизация НЕ создана — ждёт решения Alex по реализации выдержки 12 ч (вариант A/B)
 created: '2026-09-16'
-updated: '2026-09-16'
+updated: '2026-09-16 (конструкция пересмотрена: input_number/helper НЕ нужен — отменён; прогноз работает как ДЕЙСТВИЕ автоматизации)'
 tags:
   - family
   - smarthome
@@ -183,42 +183,53 @@ t_расч = min( ZONT_улица , min(прогноз на 24 ч вперёд)
 - [x] ~~Определить тип кабеля~~ → **саморегулирующийся** (Alex, 2026-09-16).
 - [x] ~~Найти источник внешнего прогноза~~ → `weather.forecast_laki_dom` + WS `weather/subscribe_forecast` (см. §8).
 - [x] ~~Решить выдержку~~ → **12 ч** (Alex, 2026-09-16).
-- [x] ~~Понять, как подставить прогноз в триггер~~ → **нельзя через Jinja**, нужен `input_number` + обновлятор (§8.1).
+- [x] ~~Понять, как подставить прогноз в триггер~~ → **как ДЕЙСТВИЕ** `action: weather.get_forecasts` + `response_variable`, внутри `actions:`. Helper'ы НЕ нужны (§8.1).
-- [ ] **⚠️ БЛОКЕР: решить тип helper'а** — Storage (UI) или YAML (`configuration.yaml`). Ждёт ответа Alex.
+- [ ] **⚠️ БЛОКЕР: решить реализацию выдержки 12 ч** — вариант A (`numeric_state` + `for` на ZONT) или **B** (`for: 12:00:00` на `switch.heating_cable_plug`, рекомендован). Ждёт ответа Alex.
-- [ ] **Создать 6 объектов** по плану [[family/plans/t610-heating-cable-automation]] (бэкап `automations.yaml` — ✅ сделан).
+- [ ] **Создать 1 автоматизацию** `automation.heating_cable_ctl` (заготовка `~/tmp-t610/new_cable_autos.yaml`, YAML валиден; бэкап `automations.yaml` — ✅ сделан).
 - [ ] Опционально: датчик температуры **на самой трубе** в бетоне — тогда порог снимаем с трубы, а не по воздуху (точнее, снимает неопределённость модели §4).
 - [ ] Проверить в ZONT, нужен ли ему отдельный виртуальный slave под греющий кабель (сейчас управление идёт через Zigbee-розетку, ZONT в контур не включён).
-- [ ] Обновить [[family/how-to/ha-automations]] — карта автоматизаций (сейчас 24 шт.; после выполнения станет 27).
+- [ ] Обновить [[family/how-to/ha-automations]] — карта автоматизаций (сейчас 24 шт.; после выполнения станет 25).
 
 ---
 
 ## 8. 🔴 API прогноза погоды в HA 2026.9.2
 
-### 8.1. Главное: прогноз НЕДОСТУПЕН ИЗ ШАБЛОНА
+### 8.1. Прогноз: НЕ из шаблона, а ДЕЙСТВИЕМ автоматизации
 
-Проверено четырьмя способами 2026-09-16:
+Проверено пятью способами 2026-09-16:
 
 | Способ | Результат |
 |---|---|
 | атрибут `forecast` у `weather.forecast_laki_dom` | **`None`** — прогноза в атрибутах нет |
 | `weather.get_forecasts(...)` **в Jinja-шаблоне** | **`UndefinedError: 'weather' is undefined`** |
+| `weather.get_forecasts` **как действие** (`action:` + `response_variable`) | ✅ **работает** — 48 точек |
 | сервис `weather.get_forecasts` (мн. число), REST/WS | ✅ **работает** — 48 ч + 6 дней |
-| WS `weather/subscribe_forecast` | ✅ **работает** |
+| WS `weather/subscribe_forecast` | ✅ **работает** (для стрима/CLI) |
 
-> 🔴 **Вызов сервисов из шаблонов (`weather.get_forecasts(...)` в Jinja) в этой версии убран.** Попытка даёт `'weather' is undefined`. Значит **пороги нельзя написать шаблоном «на лету»** — прогноз надо **материализовать в сущность** (`input_number`), иначе в триггер автоматизации его не подставить.
+> ✅ **РАБОЧИЙ ПУТЬ: `action: weather.get_forecasts` с `response_variable`.**
+> Внутри `actions:` результат доступен последующим `variables:` и `choose:`.
+> **Никаких helper'ов / `input_number` / template-сенсоров не требуется.**
+>
+> ```yaml
+> actions:
+>   - action: weather.get_forecasts
+>     target: {entity_id: weather.forecast_laki_dom}
+>     data: {type: hourly}
+>     response_variable: wx
+>   - variables:
+>       fc_min: >-
+>         {{ wx['weather.forecast_laki_dom']['forecast'][:24]
+>            | map(attribute='temperature') | min | default(99) | float(99) }}
+> ```
+>
+> 🔴 **`variables:` вычисляются ДО действий** — объявлять вычисления от
+> `response_variable` только ВНУТРИ `actions:`, после вызова сервиса.
 
-**Рабочая конструкция — слой обновления (см. план):**
+> 🔴 **Урок (две итерации):** сначала я проверил только Jinja-форму вызова
-
+> (`{{ weather.get_forecasts(...) }}` → `'weather' is undefined`) и заключил
-```
+> «прогноз недоступен шаблону → нужен `input_number` + обновлятор». **Это была
-automation.heating_cable_forecast_update   (каждый час)
+> ошибка:** штатный путь — вызов как **действие**, он работает. Прежде чем строить
-  → weather.get_forecasts('weather.forecast_laki_dom','hourly')
+> обходной слой, проверь штатный вариант целиком.
-  → min(map(attribute='temperature')[:24])
-  → input_number.heating_cable_forecast_min
-
-sensor.heating_cable_outside_min_24h   (template, §8.1 недоступен Jinja-вызов)
-  → min( sensor.h2000_pro_temperatura_ulitsa ,
-         input_number.heating_cable_forecast_min )
-```
 
 ### 8.2. Имена — множественное число