План: автоматизация греющего кабеля ввода воды

Расчёт и обоснование порогов — в family/tech/heating-cable-water-inlet. Здесь — что именно делать руками.

1. Задача

Обогрев ввода воды в дом. Труба ПНД сквозь бетонную подушку 30 см → в суглинок на 4 м. Регион — Новосибирск (Лаки Парк).

Ключевые выводы расчёта:

Грунт на 4 м не замерзает никогда (+2,5…+3,5 °C круглый год).
Опасна только бетонная подушка 30 см — труба в ней доходит до 0 °C при воздухе −8 °C.
Кабель саморегулирующийся → перегрев невозможен, окно выдержки задаёт инерция бетона (~сутки).

2. 🔴 Единственный блокер

Выдержка: 6 ч или 24 ч. Решение за Alex.

Вариант	Плюс	Минус
24 ч	отсекает ночные заморозки	при ударе −15 °C за ночь включится через сутки
6 ч	ловит резкое похолодание в тот же день	может дёрнуться на ночном заморозке

Рекомендация ассистента: 6 ч.

3. Спецификация автоматизации

Имя: heating_cable_water_inlet Файл: /config/automations.yaml на t610 (бэкап обязателен перед правкой)

3.1. Расчётная температура

t_расч = min( sensor.h2000_pro_temperatura_ulitsa ,
              min( прогноз weather.forecast_laki_dom на 24 ч вперёд ) )

Берём более холодный из двух источников — fail-safe в сторону защиты от замерзания.

3.2. Триггеры и действия

#	Триггер	Условие	Действие
1	`t_расч` ≤ −8 °C	`for: <6ч\|24ч>`	`switch.turn_on` `switch.heating_cable_plug`
2	`t_расч` ≥ −3 °C	`for: <6ч\|24ч>`	`switch.turn_off` `switch.heating_cable_plug`
3	`t_расч` ≤ −20 °C	без `for`	`switch.turn_on` (безусловно)
4	оба источника `unavailable`	`for: 01:00:00`	`switch.turn_on` + push
5	после ВКЛ + 10 мин	`sensor.heating_cable_plug_power < 5`	push «кабель не греет»

3.3. Сущности

Роль	Сущность
Датчик (ZONT)	`sensor.h2000_pro_temperatura_ulitsa`
Прогноз	`weather.forecast_laki_dom` (met.no)
Исполнитель	`switch.heating_cable_plug` (NEO NAS-WR01B, `a4c138eb6fbe9d19`, зона `kotelnaia`)
Контроль мощности	`sensor.heating_cable_plug_power`

4. Шаги выполнения

Бэкап /config/automations.yaml → automations.yaml.bak-heatcable-<ts>.
Забрать прогноз в шаблон-сенсор:
```
template:
  - sensor:
      - name: "t_rasch_heating_cable"
        unit_of_measurement: "°C"
        state: >
          {% set fc = state_attr('weather.forecast_laki_dom','forecast') %}
          ...
```
⚠️ Прогноз в этих шаблонах может быть недоступен — атрибут forecast в HA 2026.9.2 не отдаётся в state_attr, только через WS weather/subscribe_forecast (§8 family/tech/heating-cable-water-inlet). Проверить фактом ДО написания шаблона. Если недоступен — вариант: брать уличную температуру напрямую из met.no через RESTful-сенсор (отдельная интеграция), либо использовать weather.get_forecasts (проверить существование в 2026.9.2).
Добавить 5 триггеров из §3.2 в automations.yaml (через patch, не sed).
Перезагрузить автоматизации: POST /api/services/automation/reload.
Проверить: automation.heating_cable_water_inlet = on, 0 unavailable, ссылки на сущности живые.
Обновить family/how-to/ha-automations — карта автоматизаций (стало 25).
Обновить статус family/tech/heating-cable-water-inlet → 🟢.

5. Питфоллы (собрано из опыта сессии)

Питфолл	Обход
Прогноз недоступен через REST/`call_service`	Только WS `weather/subscribe_forecast` (§8)
WS-ответ прогноза — два сообщения	Второй `recv()` после `result`
`http://192.168.2.176:8123` с Mac → `000`	SSH-однострочник или `wss://mallexxx.duckdns.org`
Токен `/tmp/.hatok` лежит на Mac	Передавать в SSH-команду из Mac
Правка `automations.yaml` без reload не действует	`POST /api/services/automation/reload`
`sensor.heating_cable_plug_power = 0 Вт` при `off`	Норма, не поломка — проверить можно только после включения

6. Следующие шаги (не блокеры)

Датчик температуры на трубе в бетоне — точнее модели §4.
Решить, нужен ли ZONT отдельный виртуальный slave под греющий кабель.
После первого включения — снять реальную мощность (sensor.heating_cable_plug_power) и записать в доку: сколько потребляет кабель 6 м.

6.5 KiB Raw Blame History Unescape Escape