git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
82e5cb264090a906400866a60345953c18bb967f
obsidian-vault/family/tech/heating-cable-water-inlet.md
T

21 KiB
Raw Blame History

title: "Греющий кабель ввода воды — порог включения (расчёт)" aliases: [Греющий кабель, heating_cable_plug, ввод воды, промерзание, обогрев водопровода] type: tech namespace: family status: 🟢 Решения приняты (саморег, выдержка 12 ч). Конструкция определена: 0 helper'ов — прогноз берётся action: weather.get_forecasts + response_variable. Автоматизация НЕ создана — ждёт решения Alex по реализации выдержки 12 ч (вариант A/B) created: '2026-09-16' updated: '2026-09-16 (конструкция пересмотрена: input_number/helper НЕ нужен — отменён; прогноз работает как ДЕЙСТВИЕ автоматизации)' tags:

Греющий кабель ввода воды — порог включения

Задача: определить, при какой уличной температуре включать греющий кабель, обогревающий ввод воды в дом. Конструкция: труба (ПНД) уходит сквозь бетонную фундамент-подушку 30 см и далее в грунт (суглинок) на глубину ~4 м. Регион: Новосибирск, ДНП «Лаки Парк» (55.257328, 83.048234).

1. ИТОГ — пороги автоматизации

Тип кабеля: САМОРЕГУЛИРУЮЩИЙСЯ (подтверждено Alex 2026-09-16). Это меняет логику:

  • перегрев не грозит (сам сбрасывает мощность при нагреве) → нет смысла ждать, цель — успеть до промерзания бетона;
  • работа вхолостую стоит копейки → не экономим циклы, а защищаемся от замерзания;
  • размер окна выдержки задаёт тепловая инерция бетона (~сутки), а не риск для кабеля.
Параметр Значение Обоснование
ВКЛ t_расч ≤ −8 °C, выдержка 12 ч при −8 °C труба в бетоне достигает 0 °C (§4); 12 ч отсекают ночные заморозки
ВЫКЛ t_расч ≥ −3 °C, выдержка 12 ч гистерезис 5 °C — бетон оттаивает медленно
Безусловный ВКЛ t_расч ≤ −20 °C игнорирует выдержку и гистерезис
Fail-safe оба источника unavailable > 1 ч ВКЛ + push (замёрзшая труба дороже лишних кВт)
Алерт обрыва включили + 10 мин → power < 5 W кабель/нагрузка не подключены

🔴 t_расч — расчётная температура по двум источникам

t_расч = min( ZONT_улица , min(прогноз на 24 ч вперёд) )

Зачем второй источник: уличный датчик ZONT — одна точка и может врать/отвалиться (реальный случай 2026-09-16: отдавал °F из-за ручного override, см. family/tech/ha-registry-operations §4). Если он замолчит в −25 °C, автоматизация промолчит в самый опасный момент. Внешний прогноз — независимый канал.

Правило конфликта: берём более холодный из двух. Fail-safe смещён в сторону защиты от замерзания, а не экономии.

Источники:

  • Датчик: sensor.h2000_pro_temperatura_ulitsa (ZONT H2000_PRO, ZONT-шина).
  • Прогноз: weather.forecast_laki_dom (met.no, привязан к посёлку Лаки Парк; 48 ч почасового + 6 дней).
  • Исполнитель: switch.heating_cable_plug (розетка NEO NAS-WR01B, Zigbee a4c138eb6fbe9d19, зона kotelnaia).

🔴 API прогноза в HA 2026.9.2 — только WS-команда weather/subscribe_forecast. Подробности и точный вызов — §8.

✅ Выдержка — РЕШЕНО: 12 ч (Alex, 2026-09-16)

Обсуждались 6 ч / 12 ч / 24 ч. Alex выбрал 12 ч — «ни нашим ни нашим».

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

Бетон за сутки не промёрзнет в любом варианте.

2. Климатология (СП 131.13330.2020, табл. 5.1 — Новосибирск)

Месяц t, °C Месяц t, °C
янв −17,6 июл +19,4
фев −15,4 авг +16,4
мар −7,7 сен +9,9
апр +2,3 окт +1,5
май +11,0 ноя −7,9
июн +17,3 дек −15,3
  • Сумма среднемесячных отрицательных Mt = 17,6 + 15,4 + 7,7 + 7,9 + 15,3 = 63,9
  • Среднегодовая t воздуха = +1,2 °C
  • Минимальная температура (СП 20.13330, карта 4) = −45 °C

3. Глубина промерзания и что творится на 4 м

Формула СП 22.13330: d_fn = d0 · √Mt, где d0 зависит от грунта.

Грунт d0 d_fn
Суглинок / глина 0,23 1,84 м
Супесь, песок мелкий/пылеватый 0,28 2,24 м
Песок гравелистый/крупный 0,30 2,40 м
Крупнообломочный 0,34 2,72 м

Наш случай — суглинок: d_fn = 0,23 × √63,9 = 1,84 м (открытая поверхность, без снега). Под снегом 30–40 см реальное промерзание меньше: 1,3–1,6 м.

Грунт на глубине трубы (4 м)

Температуропроводность суглинка: a = λ / C = 1,4 / 2,5e6 ≈ 5,6e-7 м²/с.

Глубина затухания волны в e раз: z_зат = √(a·T/π)

Волна Период z_зат
Суточная 86 400 с 0,12 м
Годовая 365 сут 2,37 м

Амплитуда годового хода на 4 м: 19,0 × exp(−4,0/2,37) = ±3,5 °C от среднегодовой.

✅ ГЛАВНЫЙ ВЫВОД: труба на 4 м НЕ ЗАМЕРЗАЕТ ФИЗИЧЕСКИ. Там круглый год +2,5…+3,5 °C — грунт практически изотермичен. Зона промерзания (до 1,84 м) заканчивается задолго до трубы.

4. Критичная точка — бетонная подушка 30 см

Единственное место, где есть риск. Причина: бетон — теплопроводный мост.

  • λ_бетона ≈ 1,7 Вт/(м·К) против λ_суглинка ≈ 1,4 — на 21 % выше;
  • сверху нет снеговой шубы, как над грунтом;
  • на бетон приходится 72,6 % перепада температуры (расчёт через термические сопротивления: R_возд = 1/15 = 0,067, R_бет = 0,30/1,7 = 0,177).
Улица Труба в бетоне
−6 °C +0,5 °C
−8 °C −0,1 °C ⬅ ПОРОГ
−10 °C −0,6 °C
−12 °C −1,1 °C
−15 °C −1,9 °C
−20 °C −3,1 °C
−25 °C −4,4 °C
−30 °C −5,6 °C

5. Почему выдержка в часах, а не мгновенное включение

Бетон — тепловая масса. Промерзает за сутки, а не за минуту или час.

  • Кратковременные −10 °C ночью в сентябре не опасны — за ночь бетон не промёрзнет.
  • При затяжном похолодании выдержка уже прошла → кабель включён до того, как бетон успеет охладиться.
  • Инерция бетона ≈ сутки — это и есть верхняя граница окна. Нижняя — время, за которое бетон успевает остыть до 0 °C при −8 °C на улице.
  • После оттепели бетон оттаивает медленно → выключение с той же выдержкой.
  • Итог: 12 ч (выбор Alex). Отсекает одиночные ночные заморозки, но не пропускает резкое похолодание на весь день.

🔴 Исправление первой версии расчёта: изначально стояло «30 мин». Это была ошибка — при инерции бетона в сутки выдержка 30 мин пропускает ночные заморозки и даёт лишние включения. Далее обсуждались 6/12/24 ч; принято 12 ч.

Важно: выдержку задаёт инерция бетона, а не защита кабеля. Для саморег-кабеля перегрев невозможен, поэтому «греть подольше» не вредит — наоборот, выгоднее.

6. Состояние железа (проверено 2026-09-16)

Сущность Значение Комментарий
switch.heating_cable_plug off розетка живёт, выключена
sensor.heating_cable_plug_voltage 223 V напряжение в розетке есть
sensor.heating_cable_plug_power 0.0 W ожидаемо при off
sensor.heating_cable_plug_energy 0.0 kWh
sensor.h2000_pro_temperatura_ulitsa 12.8 °C после фикса °F→°C 2026-09-16

⚠️ 0 Вт — это норма, пока switch = off, а не поломка. Ранее (2026-09-15) в family/documents/home-automation-wishlist §7 это было записано как подозрение на мёртвый мониторинг. Уточнение: напряжение 223 V присутствует → розетка работает; нулевая мощность при выключенном реле ожидаема. Проверка живости нагрузки возможна только после первого включения. 💡 Отсюда — алерт обрыва в автоматизации: включили → через 5 мин ждём power > 5 W; если ноль — кабель не подключён либо перебит.

Наличие кабеля: в закупках зафиксировано «Греющий кабель в ПНД × 6 м» + «Ввод греющего кабеля» (family/documents/lerua-shopping).

7. Что НЕ сделано (следующие шаги)

  • Определить тип кабеля → саморегулирующийся (Alex, 2026-09-16).
  • Найти источник внешнего прогноза → weather.forecast_laki_dom + WS weather/subscribe_forecast (см. §8).
  • Решить выдержку → 12 ч (Alex, 2026-09-16).
  • Понять, как подставить прогноз в триггер → как ДЕЙСТВИЕ 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 шт.; после выполнения станет 25).

8. 🔴 API прогноза погоды в HA 2026.9.2

8.1. Прогноз: НЕ из шаблона, а ДЕЙСТВИЕМ автоматизации

Проверено пятью способами 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 ✅ работает (для стрима/CLI)

✅ РАБОЧИЙ ПУТЬ: action: weather.get_forecasts с response_variable. Внутри actions: результат доступен последующим variables: и choose:. Никаких helper'ов / input_number / template-сенсоров не требуется.

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 + обновлятор». Это была ошибка: штатный путь — вызов как действие, он работает. Прежде чем строить обходной слой, проверь штатный вариант целиком.

8.2. Имена — множественное число

🔴 Сервис называется weather.get_forecasts (МНОЖЕСТВЕННОЕ число). Единственное weather.get_forecast не существует → not_found: Service weather.get_forecast not found.

# ✅ работает (REST / WS call_service)
{"domain":"weather","service":"get_forecasts",
 "service_data":{"entity_id":"weather.forecast_laki_dom","type":"daily"},
 "return_response": True}

8.3. WS-подписка — единственный путь для стрима

{"type": "weather/subscribe_forecast",
 "entity_id": "weather.forecast_laki_dom",
 "forecast_type": "daily"}     # ⚠️ именно forecast_type, НЕ type; или "hourly"

Что НЕ работает (проверено фактом):

Способ Результат
WS weather/forecast unknown_command
WS call_service → weather.get_forecast (ед. ч.) not_found
POST /api/services/weather/get_forecast (ед. ч.) 400 Bad Request

🔴 Питфолл: ответ подписки приходит ДВУМЯ сообщениями. Сначала {"type":"result","success":true,"result":null}, затем отдельным сообщением {"type":"event","event":{"type":"daily","forecast":[...]}}. Наивный WS-клиент, ждущий только result, вернёт 0 точек — прогноз надо читать вторым recv().

8.4. 🔴 render_template по WebSocket НЕ работает

🔴 WS render_template возвращает null даже для {{ 2 + 2 }} — проверено фактом. Шаблоны рендерить ТОЛЬКО через REST POST /api/template с телом {"template": "..."}. Через REST работает и {{ 2 + 2 }} → 4, и {{ states('sensor...') }}.

Что отдаёт weather.forecast_laki_dom (met.no):

  • Атрибут temperature = текущая (11.8 °C на момент проверки);
  • hourly — 48 точек (достаточно для окна 24 ч);
  • daily — 6 точек, поле templow (минимум ночи) + temperature (максимум дня).

Инструмент: ~/tmp-t610/ha_ws.py forecast <entity> <hourly|daily> — добавлена команда forecast (реализация: collect_events=True — второй recv() после result).

cd ~/tmp-t610 && python3 ha_ws.py forecast weather.forecast_laki_dom daily

⚠️ ha_ws.py ходит через внешний wss://mallexxx.duckdns.org и работает с Mac. Локальный http://192.168.2.176 с Mac недоступен (000), а http://172.30.32.1 доступен только с t610 по SSH. Для REST-запросов — SSH-туннель (см. family/how-to/home-automation §2).

8.5. ⚠️ Питфолл окружения: write_file портит строку с Bearer

⚠️ При генерации скриптов write_file режет литерал Authorization: Bearer $TOK — строка приходит битой, скрипт не парсится (unexpected EOF while looking for matching quote). Обход: собирать заголовок из переменных:

TOK=$(cat /tmp/.hatok)
P1=Authorization
P2=Bearer
AUTH_HDR="${P1}: ${P2} ${TOK}"

Тот же эффект — на строках с suggested_unit_of_measurement из §4 реестровых операций.

Связанные заметки

Reference in New Issue View Git Blame Copy Permalink