В прошлой статье "Умный дом. Как соединить разные технологии? Реальный опыт" я осветил основные инженерные и технические решения, реализованные в моём проекте умного дома. В этой статье я хотел бы затронуть тему создания благоприятного температурного режима в доме и о решениях, которые можно для этого применить.
Так получилось, что это второе моё место проживания, в котором для отопления используется газовый котёл. Первый раз задача автоматического регулирования комнатной температуры была решена очень просто, котёл поддерживал подключение проводного датчика наружной температуры и позволял устанавливать температурную кривую для автоматического регулирования температуры теплоносителя. В этот раз пришлось действовать нестандартно. Дело в том, что котел выбирал не я, он достался мне от застройщика. Возможность подключения датчика отсутствует, но зато, поддерживается цифровая шина и это внушило мне определенную уверенность в успехе.
Достался мне котел марки Navien, модель Deluxe Plus Coaxial 24k, который имеет цифровую шину, реализующую протокол Navien. Начал я с поиска адаптера цифровой шины. Сначала наткнулся на ZONT, но в списке поддерживаемого оборудования моего котла не оказалось (на данный момент котёл есть в списке поддерживаемых). Смущало еще и то, что сам адаптер работает только в составе с другим оборудованием ZONT, т.е. не имеет открытого и документированного интерфейса для взаимодействия с адаптером. Далее, я наткнулся на адаптер ectoControl, который имеет открытый и документированный интерфейс, размещенный на сайте поставщика. В списке поддерживаемого оборудования моего котла тоже не оказалось :( Ответ техподдержки был примерно такой: "вероятнее всего заработает, но гарантию дать не можем так как сами не проверяли". Цена в 3.5к побудила меня проверить данный адаптер на совместимость.
Наиболее распространенные цифровые шины для управления отопительным оборудованием
OpenTherm - используется в системах центрального отопления для взаимодействия между отопительными котлами и термостатами. Является открытым стандартом, который не зависит от поставщика (в теории). На мой взгляд, наиболее предпочтительный вариант из-за открытости.
eBUS - изначально разработан для использования в системах автоматизации зданий, но чаще всего используется для управления отопительным оборудованием и солнечными панелями. Популярен у немецких производителей (Vaillant, Bosch, Viessmann). Протокол частично закрытый и не имеет общего стандарта.
Navien - используется исключительно для управления котлами и другим оборудованием Navien. Протокол закрытый, публичной документации нет. Котлы получили очень широкое распространение на территории РФ, прежде всего из-за доступной цены.
Это не исчерпывающий список, есть и другие, но конкретно данные варианты чаще всего применяются в бытовых котлах.
Постановка задачи
Изначально задача ставилась так: обеспечить возможность автоматического изменения температуры теплоносителя в зависимости от изменения наружной температуры. Т.е. именно так как это работает в котлах с возможностью подключения датчика наружной температуры. Выбор режима работы осуществляется путем выбор номера отопительной кривой:
Конечной же целью является функция термостатирования т.е. обеспечение постоянства температуры в помещении, заданной в виде целевого значения. Существует два основных подхода:
Гистерезисное управление (релейное) - на термостате задается целевая температура внутри помещения, при достижении которой (плюс гистерезис 0,5℃.) размыкается реле, что запрещает отопительному оборудованию включаться. При падении температуры ниже целевой (минус гистерезис 0,5℃) реле замыкается и разрешает работу отопителя. Например: целевая Т=21℃, при 21,5℃ работа отопителя запрещена, при 20,5℃ разрешена. Возможный перепад температуры - 1℃. Сама величина гистерезиса может варьироваться для термостатов разных производителей, а иногда, может регулироваться пользователем.
Плюсы:
Простота реализации
Поддержка оборудованием - может быть использовано практически для любого отопительного оборудования
Стоимость
Минусы:
Низкая точность (в пределах гистерезиса)
Не учитывает внешние факторы
Возможный дискомфорт - перепад в 1℃ уже ощущается человеком. На практике было замечено, что в момент отключения радиаторы могли остыть полностью и появлялся холодок от окон.
Иногда требует вмешательства и регулировки температуры теплоносителя. Например: ударили морозы и установленная температура теплоносителя в 50℃ уже не справляется с теплопотерями, вследствие чего, целевая температура по термостату никогда не будет достигнута.
Погодозависимая автоматика (ПЗА) - основана на изменении целевой температуры теплоносителя (или мощности электрического отопителя) в зависимости от внешних факторов. Основным внешним фактором является температура снаружи, но кроме этого может учитываться: скорость ветра, влажность, облачность, солнечная активность и т.д. Может учитываться и внутренняя температура в помещении, но не обязательно. Сам принцип термостатирования основан на том, что можно всегда подобрать такой номер отопительной кривой, при которой установится баланс между теплопотерями здания и работой отопительных приборов.
Плюсы:
Плавное регулирование
Комфорт
Адаптивность
Возможно, небольшая экономия на платежах за газ. Пока отношусь к этому скептически. Сложно проверить, т.к. погода каждый год разная. Но маркетологи заявляют )))
Минусы:
Сложность - требуется контроллер, датчики или информация о погодных условиях
Поддержка отопительным оборудованием
Я вначале попробовал первый вариант, но в итоге не смог смириться с минусами гистерезисного управления и оставил его только как резервное.
Мой состав оборудования для решения задачи
В статье "Умный дом. Как соединить разные технологии? Реальный опыт" я уже описывал полный перечень оборудования используемого для реализации умного дома. Здесь привожу только то, что используется для ПЗА. Часть оборудования используется и для других задач, например RPi.
Микрокомпьютер RPi 3 Model B — 1 шт. (был в наличии)
SD-карта на 64 Гб для микрокомпьютера — 1 шт.
Конвертер MODBUS RTU в MODBUS TCP (Full-isolation Serial Device Server ZLAN5143D) — 1 шт.
Адаптер цифровой шины Navien ectoControl, модель: ES-BRNV-01 — 1 шт.
Блок питания DC 12V MEAN WELL HDR-15-12 - 1 шт. (для питания адаптера цифровой шины)
Беспроводной (LoRaWAN) датчик температуры Вега ТД-11 — 1 шт. (опционально, может использоваться информация погодного сервиса).
Комнатный датчик температуры и влажности с двумя выходами 4-20 мА — 1шт. (может быть заменен на любой другой источник комнатной температуры, например ZigBee датчик)
Если у вас уже работает умный дом на базе HomeAssistant (дале HA), то обязательными пунктами являются только п.3 и п.4. Можно еще сэкономить, заменив п.3 на USB-стик RS485 для RPi, но в этом случае нужно будет проложить двухжильный кабель между п.3 и п.4.
Реализация
Предварительные условия:
НA уже установлен, настроен и подключен в локальную сеть
В HA установлена интеграция Modbus
ZLAN 5143D подключен в локальную сеть и настроен
ZLAN 5143D подключен по RS485 к ectoControl ES-BRNV-01 (клеммы A и B)
Питание DC 12V подключено к ZLAN 5143D (клеммы "V+" и "V-")
Питание DC 12V подключено к ectoControl ES-BRNV-01 (контакты "+" и "-")
ectoControl ES-BRNV-01 подключен к котлу (возможные схемы подключения есть в документации производителя)
HA имеет доступ по IP к ZLAN 5143D
Настройки RS485 в ZLAN 5143D для подключения к ectoControl ES-BRNV-01:
Общая схема получилась такой:
После того как я подключил всё по схеме, первое, что я сделал - проверил опрос адаптера ectoControl по Modbus TCP с помощью mbpoll. Попробовал получить время наработки (uptime), регистры 0x0012, 0x0013 по документации производителя.
Обратите внимание (опытные "промавтоматчики" это хорошо знают), что при опросе через mbpoll я указываю стартовый регистр 0x0013 и получаю регистры 19-20 (HEX 0x0013-0x0014), а в документации они обозначены как 0x0012-0x0013. Это не ошибка. Дело в том, что регистры могут адресоваться по-разному: включая первый регистр (mbpoll) и не включая первый регистр (документация). Всё зависит от клиента. При опросе через mbpoll нужно всегда добавить +1 к адресу регистра, указанному в документации. При настройке интеграции Modbus в HA, карту регистров нужно описывать в соответствии с документацией. Собственно, вот она:
Скрытый текст
modbus:
- name: "NAVIEN"
type: tcp
host: 192.168.1.65
port: 502
timeout: 2
delay: 1
sensors:
- name: "adapter_status"
slave: 1
unique_id: 0x0010
address: 0x0010
scan_interval: 10
input_type: holding
data_type: uint16
- name: "adapter_version"
slave: 1
unique_id: 0x0011
address: 0x0011
scan_interval: 10
input_type: holding
data_type: uint16
- name: "adapter_uptime"
unit_of_measurement: "s"
slave: 1
unique_id: 0x0012
address: 0x0012
scan_interval: 10
input_type: holding
data_type: uint32
- name: "coolant_temp"
unit_of_measurement: "°C"
slave: 1
unique_id: 0x0018
address: 0x0018
scan_interval: 15
input_type: holding
data_type: int16
device_class: temperature
scale: 0.1
- name: "dhw_temp"
unit_of_measurement: "°C"
slave: 1
unique_id: 0x0019
address: 0x0019
scan_interval: 15
input_type: holding
data_type: uint16
device_class: temperature
scale: 0.1
- name: "burner_status"
slave: 1
unique_id: 0x001D
address: 0x001D
scan_interval: 5
input_type: holding
data_type: uint16Считываю не все параметры, только те, что поддерживаются моим котлом.
Настройка HomeAssistant
После того как карта регистров настроена в YAML конфиге интеграции Modbus, а HA перезапущен, мы получаем наши значения в виде объектов:
Скрытый текст
Некоторые регистры кодируют сразу несколько параметров. Например: регистр 0x001D кодирует состояние горелки (включена или выключена) и режим работы (отопление или ГВС). Для того чтобы в HA получить нужные нам значения, нужно использовать раздел "Настройки - Устройства и службы - Вспомогательные", в котором нужно создать вспомогательные объекты типа "Template". Они позволят извлечь из значения исходного объекта нужную нам информацию с помощью Jinja2 шаблона. Давайте я разберу это на примере регистра 0x001D (объект Статус горелки (raw) - sensor.burner_status в моём HA).
Идём в раздел "Настройки - Устройства и службы - Вспомогательные", жмём "Создать вспомогательный объект", далее выбираем "Template -> Бинарный сенсор". Заполняем в соответствии со снимком и жмём "Подтвердить":
Что происходит в самом шаблоне:
Берем значение исходного объекта считанного по Modbus:
states('sensor.burner_status')Принудительно преобразуем его в целое число:
| intВыполняем операцию побитового "И" со значением 0x1 т.к состояние горелки у нас находится в первом бите:
| bitwise_and(0x1)Проверяем, что получившееся значение не равно нулю:
!= 0
Так поступаем со всеми значениями, которые хотим декодировать. Jinja2 и его встроенные функции позволяют строить довольно сложную логику. Подробнее в документации.
Похожим образом создаются и управляющие элементы: списки выбора, поля ввода и т.д.
На выходе я получил список всех значений, которые меня интересовали:
Следующим шагом я оформил это в блоки на панели управления:
Дело осталось за малым, создать автоматизацию в HA (далее я могу использовать термин сценарий), которая будут реализовывать логику ПЗА, а именно при изменении внешней температуры, изменять температуру теплоносителя в адаптере ectoControl. На самом деле список автоматизаций получился прилично больше:
Следующие два снимка объясняют как реализован сценарий ПЗА в моём случае.
Немного объяснений как это работает
У меня есть вспомогательный сенсор (типа Template), который на основе датчика внешней температуры (в данном случае используется Яндекс.Погода) рассчитывает целевую температуру теплоносителя.
Когда я понял, что этот сенсор превратился в приличный кусок кода Jinja2, я создал небольшую интеграцию для HA под названием WDA Sensor (про неё чуть ниже), которую можно использовать вместо Template сенсора.
Первый сценарий при изменении значения этого вспомогательного сенсора и если режим ПЗА активирован, записывает новое значение в объект "Целевая температура теплоносителя", который представляет собой вспомогательный элемент ввода и выведен на панель управления под названием "Целевая Т. теплоносителя" (см. снимок выше).
Второй сценарий при изменении вспомогательного объекта "Целевая температура теплоносителя" записывает новое значение этого объекта в регистр адаптера ectoControl (регистр 49, HEX: 0x0031). Значение предварительно умножается на 10, в соответствии с документацией.
Зачем так сложно, можно же было сразу записать в Modbus регистр адаптера? Дело в том, что это обеспечивает возможность как ручного, так и автоматического управления температурой теплоносителя. Я могу выключить "Режим ПЗА" на панели и управлять вручную температурой теплоносителя, в этом случае будет отрабатывать только второй сценарий.
Можно наблюдать как изменяется температура теплоносителя при перепадах дневной и ночной температуры снаружи:
Важное замечание! Некоторые регистры адаптера ectoControl записываются в ПЗУ (EEPROM). В частности регистр 0x0031. Как удалось выяснить у технической поддержки, количество циклов записи/перезаписи составляет 100 тыс. Поэтому, не стоит строить сценарии так, чтобы запись происходила слишком часто. Оптимально - не чаще чем 1 раз в час. Яндекс.Погода обновляет свои показания 1 раз в 2 часа, мой уличный датчик температуры Вега ТД-11 раз в час. Этого вполне достаточно.
Интеграция WDA Sensor (Сенсор погодозависимой автоматики)
Проект в GitHub: https://github.com/sokolovs/wda-sensor
Что умеет интеграция? Она позволяет собрать свой сенсор погодозависимой автоматики через WebUI HA, который будет рассчитывать целевую температуру теплоносителя на основе следующих данных:
Максимальная и минимальная температура теплоносителя, поддерживаемая вашим котлом
Целевая температура в помещении
Номер отопительной кривой от 1 до 200
Сенсор, предоставляющий наружную температуру
Сенсор, предоставляющий внутреннюю температуру (опционально)
Сенсор, предоставляющий скорость ветра (опционально)
Сенсор, предоставляющий влажность снаружи (опционально)
Коэффициенты коррекции: по комнатной температуре, по скорости ветра, по влажности снаружи
Сенсор подписывается на изменения показаний других сенсоров, от которых он зависит, и обновляет свое значение как только изменился любой их них.
Все это продемонстрировано на следующих четырёх снимках:
Установить интеграцию можно в HACS через добавление пользовательского репозитория. В какой-то перспективе интеграцию включат в HACS, заявка подана, но очередь на включение очень большая.
Отопительные кривые используемые в интеграции:
Подведение итогов
Цель достигнута, к котлу я теперь практически не подхожу. Раньше можно было проснуться утром в холодном доме из-за того, что резко похолодало на улице или наоборот, в перегретом доме, если на улице прилично потеплело. В этот момент нужно было подойти к котлу и скорректировать температуру теплоносителя.
Следующая цель - зональное отопление. В моей семье "комфортная температура" понятие ооочень растяжимое от 21 до 26,5℃ :-).
Побочный эффект: возможность удаленного управления и мониторинга показателей котла. Например, можно наблюдать такты котла:
P.S.: Планирую в обозримом будущем разработать полноценную интеграцию для адаптеров ectoControl, чтобы избавиться от вспомогательных сенсоров и получить в комбинации с WDA Sensor решение "из коробки" для HA.
P.P.S.: Котёл у меня двухконтурный, что не является лучшим вариантом, скорее - компромисс. Контур ГВС приходит в промежуточный электрический водонагреватель, в который уже поступает подогретая котлом вода. Водонагреватель используется как буферная емкость + термос и иногда подогревает воду, если никто долго не пользуется. Это решение хорошо себя зарекомендовало, но есть один нюанс. Котёл моментально переключается на нагрев ГВС, как только видит проток воды. Есть идея реализовать отложенное включение нагрева ГВС, скажем через 3 минуты после открытия крана. Это исключит переключение на ГВС при кратковременном открытии. Зачем переключаться, если уже есть запас горячей воды? Похожим образом работают газовые котлы со встроенным бойлером. Если получится, будет статься об этом. Если у кого-то есть идеи как это можно реализовать, напишите в комментариях. Датчик протока в котле - геркон. Пока смотрю в сторону реле времени (от 100р на Ali).
UPD1: добавлена информация о поддержке котла Navien Deluxe Plus 24k Coaxial адаптером ZONT. Спасибо @DarkTiger
UPD2: добавил формат времени в подпись к графику "Состояние отопления", иначе может показаться, что 2 такта в минуту. Спасибо @Forever73
