diff --git a/family/how-to/home-automation.md b/family/how-to/home-automation.md index 6c7a2793..e137b31d 100644 --- a/family/how-to/home-automation.md +++ b/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` Лестница. diff --git a/family/plans/t610-heating-cable-automation.md b/family/plans/t610-heating-cable-automation.md index 9b2dfd6e..a5815444 100644 --- a/family/plans/t610-heating-cable-automation.md +++ b/family/plans/t610-heating-cable-automation.md @@ -1,7 +1,9 @@ # План: автоматизация греющего кабеля ввода воды (t610) -> Статус: **согласован 2026-09-16** — выдержка 12 ч, порог −8 °C. -> Предыстория: [[family/how-to/home-automation]] · [[family/tech/zigbee-t610-z2m-i-zha]] +> Статус: **конструкция согласована 2026-09-16** — выдержка 12 ч, порог −8 °C, +> **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 объектов** (см. раздел «Конструкция» ниже) — ⏳ не начато -3. `reload automations` и проверить `on` + отсутствие ошибок -4. Проверить, что сущности существуют в runtime -5. Обновить `family/how-to/home-automation.md` — раздел про ввод воды -6. Записать питфоллы (WS `weather/subscribe_forecast`) в доки +2. **Конструкция определена** — ✅ `action: weather.get_forecasts` + + `response_variable`, 1 автоматизация, 0 helper'ов. YAML-заготовка готова: + `~/tmp-t610/new_cable_autos.yaml` +3. ⏳ **Решить выдержку 12 ч** (вариант A или B) — ждёт Alex +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`** | -| `weather.get_forecasts(...)` в Jinja | **`'weather' is undefined`** | +| атрибут `forecast` у `weather.forecast_laki_dom` | **`None`** — прогноза в атрибутах нет | +| `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 поймал это +> вопросом «Ты серьезно?!». **Урок: прежде чем строить обходной слой, проверь +> штатный путь целиком — не только удобную форму вызова.** -**Решение — слой обновления:** +### Порядок в автоматизации (критично) -``` -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) - → min( sensor.h2000_pro_temperatura_ulitsa , - input_number.heating_cable_forecast_min ) +```yaml +actions: + - action: weather.get_forecasts # 1. ПЕРВЫМ действием + target: + entity_id: weather.forecast_laki_dom + data: + type: hourly + response_variable: wx + - 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 ч | -| 2 | `sensor.heating_cable_outside_min_24h` | template | `min(ZONT, прогноз)` | -| 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, обрыв | +| **A** | `numeric_state` + `for: 12:00:00` на `sensor.h2000_pro_temperatura_ulitsa`, отдельный триггер на прогноз | честные 12 ч по температуре | выдержка только по ZONT, прогноз учитывается иначе | +| **B** ⭐ | `time_pattern` + `for: '12:00:00'` на `switch.heating_cable_plug` в условии включения | одна автоматизация, всё работает | выдержка отсчитывается от состояния розетки, а не от температуры | -### Открытый вопрос (не решён) - -**Где создавать helper №1** — Storage (UI, правится мышкой, но значение не -попадает в док) или YAML (`configuration.yaml`, версионируется, но правка только -файлом)? Alex не ответил. - -Смежный вопрос: пороги −8/−3/−20 сейчас зашиты в YAML автоматизаций. Если Alex -захочет пороги из UI — нужно 4 helper'а вместо одного. - -Файл с заготовкой: `~/tmp-t610/new_cable_autos.yaml` (3 автоматизации, YAML валиден). +**Рекомендация:** **B** — включение срабатывает, только если порог держится 12 ч, +а розетка всё это время выключена. **Ждёт отмашки Alex.** ## Питфоллы -- 🔴 **`weather.get_forecasts` — ТОЛЬКО как сервис, не в Jinja.** В шаблоне даёт - `'weather' is undefined` (вызов сервисов из шаблонов убран). Проверено фактом. +- 🔴 **`weather.get_forecasts` работает как ДЕЙСТВИЕ (`response_variable`), но + НЕ как 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 ` — рабочий вывод прогноза (добавлена команда `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` работают diff --git a/family/tech/ha-registry-operations.md b/family/tech/ha-registry-operations.md index 814568e0..983c83cb 100644 --- a/family/tech/ha-registry-operations.md +++ b/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` — стрим прогноза diff --git a/family/tech/heating-cable-water-inlet.md b/family/tech/heating-cable-water-inlet.md index 0481cada..93d8b10a 100644 --- a/family/tech/heating-cable-water-inlet.md +++ b/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). -- [ ] **⚠️ БЛОКЕР: решить тип helper'а** — Storage (UI) или YAML (`configuration.yaml`). Ждёт ответа Alex. -- [ ] **Создать 6 объектов** по плану [[family/plans/t610-heating-cable-automation]] (бэкап `automations.yaml` — ✅ сделан). +- [x] ~~Понять, как подставить прогноз в триггер~~ → **как ДЕЙСТВИЕ** `action: weather.get_forecasts` + `response_variable`, внутри `actions:`. Helper'ы НЕ нужны (§8.1). +- [ ] **⚠️ БЛОКЕР: решить реализацию выдержки 12 ч** — вариант A (`numeric_state` + `for` на ZONT) или **B** (`for: 12:00:00` на `switch.heating_cable_plug`, рекомендован). Ждёт ответа Alex. +- [ ] **Создать 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:`, после вызова сервиса. -**Рабочая конструкция — слой обновления (см. план):** - -``` -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 ) -``` +> 🔴 **Урок (две итерации):** сначала я проверил только Jinja-форму вызова +> (`{{ weather.get_forecasts(...) }}` → `'weather' is undefined`) и заключил +> «прогноз недоступен шаблону → нужен `input_number` + обновлятор». **Это была +> ошибка:** штатный путь — вызов как **действие**, он работает. Прежде чем строить +> обходной слой, проверь штатный вариант целиком. ### 8.2. Имена — множественное число