My heat pro подключение к wi fi
Обновлено: 04.07.2024
Долгое и занудное рассуждение на заданную тему вы можете при желании прочитать здесь. Вы не найдёте там никакого рабочего решения - там только развёрнутая постановка задачи.
А задача, если кратко, состоит в том, чтобы заставить котел отопления, рассчитанный изначально на поддержание заданной температуры воздуха в одном помещении* (так называемый "одноконтурный" котёл), поддерживать разную температуру в нескольких разных помещениях* (то есть, обслуживать несколько контуров).
Исходный состав оборудования (на своём собственном примере, но возможны и другие варианты):
- Система отопления водяного типа (батареи, теплые полы), состоящая из нескольких контуров**.
- Электрокотёл Protherm Скат с управлением по шине EBUS.
- Локальная сеть с возможностью доступа по WiFi (оптимально - с выходом в Интернет).
- Контроллер котла My Heat Smart.
- Микроконтроллерное устройство (плата) на чипе ESP8266.
- Комплект дистанционно управляемых кранов для перекрытия подачи теплоносителя в контуры***.
- Home Assistant.
- MQTT- брокер.
* Помещение - это не обязательно одно физическое помещение (например, комната). Под помещением мы понимаем совокупность пространств, отапливаемых одним физическим контуром отопления, а температура в таком помещении со стороны системы отопления контролируется по одному термодатчику. Например, это может быть этаж небольшого дома.
** Контур отопления - это сопокупность трубопроводов, радиаторов и прочего оборудования, имеющих один общий трубопропод подачи теплоносителя и один общий трубопровод возврата теплоносителя.
*** Включая контроллер, который приводит в действие краны и управляется со стороны Home Assistant'а.
Суть решения
Контроллер My Heat (впрочем, как и любой другой) переключает режимы работы котла, исходя из необходимости поддержания заданной температуры в помещении. Так как котел одноконтурный, то и термодатчик, с которого считывается текущее значение температуры, всего один. Поэтому при разветвлении теплоподачи на несколько физических контуров (помещений, этажей и т.д.) заданная температура по факту будет поддерживаться только в том помещении, в котором установлен термодатчик. В остальных же помещениях с высокой долей вероятности будет иметь место либо недогрев, либо перегрев.
Этап 1. Создаём виртуальный термодатчик.
В качестве термодатчика, по показаниям которого будет поддерживаться заданная температура, контроллер My Heat позволяет использовать термодатчики, работающие по протоколу 1-Wire (One Wire). К таким относится, например, весьма популярный и недорогой датчик DS18B20. Датчик подключается к контроллеру по трем проводам - VCC ( 5 В), GND (масса) и DATA (передача данных). Вместо такого физического датчика мы подключим к контроллеру виртуальный датчик, который будет сообщать контроллеру не фактическую температуру, а ту температуру, которую мы захотим. Физическая основа виртуального датчика - плата на чипе ESP8266. Сгодятся варианты ESP01 (самый дешевый), NodeMCU, Wemos D1 Mini и прочие. Плата подключается к контроллеру по тем же самым трем проводам, что были описаны выше, и будет питаться прямо от контроллера. Единственная оговорка - платы ESP8266 питаются не от 5 вольт, а от 3,3, поэтому нужно позаботиться о наличии понижающего преобразователя. У таких плат как NodeMCU или Wemos D1 Mini такие "понижатели" встроены, поэтому можно смело подключать выход " 5 В" контроллера к пину "VIN", а если вы используете ESP01, то рекомендую воспользоваться копеечным переходником типа такого:
Для программирования ESP01 нам понадобится скетч, который использует библиотеки OneWireHub (для эмуляции датчика One Wire) и EspMQTTClient (для получения текущего значения температуры, которое нужно сообщить контроллеру).
Вот текст скетча:
Небольшое уточнение. Поскольку у адаптера ESP01, кроме выводов питания, только два логических вывода - TXD и RXD, то мне было удобнее в качестве пина передачи данных использовать именно один из них (я использую TXD). Если вы используете другую плату, то можете назначить для этого другой пин, который вам покажется более удобным.
И еще. В скетче имеется строчка :
Подведем промежуточный итог. Теперь мы можем "подставлять" контролеру My Heat в качестве текущей любую температуру, которую захотим. Для этого нам нужно записывать в заданный MQTT-топик нужное значение.
Этап 2. Записываем в MQTT-брокер нужное показание температуры
Сначала немного размышлений. Допустим, у нас трехэтажный дом, и для каждого этажа у нас на физическом уровне реализован отдельный контур отопления. При этом температуры на разных этажах нужно поддерживать разные, да еще и с учетом времени суток.
Например, на первом этаже у нас прихожая, кухня и гостиная. Здесь мы принимаем пищу и проводим вечерний семейный досуг. Но ночью на первом этаже никого нет (только коты бродят). Поэтому имеет смысл в дневное время поддерживать здесь, скажем, 21 градус, а ночью - не более 19. Ну, еще утром перед завтраком прогреть часовым "толчком" до 22 градусов.
Второй этаж. Здесь расположены спальни. Тут всё наоборот - днём сюда мало, кто заходит (поэтому будет достаточно днём здесь поддеживать 21 градус), а ночью во время сна хочется тепла - поэтому ночью здесь выставим 23 градуса.
Третий этаж - это мансардное помещение, используемое под кладовку. Тут никто не живёт, здесь хранится сезонная одежда на вешалках, лежат коробки с обувью, старые журналы и прочий хлам, "нажитый непосильным трудом". Поэтому для третьего этажа вполне хватит и круглосуточных 19 градусов.
Поэтому я решил реализовать это дело по-другому, а именно:
- Заданная температура будет постоянной. Желательно, чтобы она была заведомо выше всех температур для всех помещений - как текущих, так и задаваемых. Например, 25 градусов.
- В качестве текущей мы будем оправлять MQTT-брокеру (и в конечном итоге - контроллеру котла) не истинную текущую температуру в таком-то помещении (в нашем случае - на таком-то этаже), а приведённую (или фейковую - как хотите, так и называйте).
Что такое (в нашем случае) приведённая текущая температура? Поясню на примере. Допустим, в настоящее время для второго этажа требуется поддержание 22 градусов, а по факту там сейчас 20,5 градусов. Значит, требуется нагрев на (22 - 20,5) = 1,5 градуса. Вычитаем эту "дельту" из неизменной целевой температуры, заданной в настройках контроллера (т.е., 25 градусов) и получаем (25 - 1,5) = 23,5 градуса. Именно это показание мы отправляем на MQTT-брокер. При этом мы по сути полагаем, что для котла нагреть воздух что с 20,5 до 22 градусов, что с 23,5 до 25 градусов - это одна и та же работа. Ну, конечно, тонкие знатоки термодинамики могут сказать, что это не так. Конечно, не так, но в пересчете на энергию там получится разница в какие-то микроскопические доли джоуля, которыми можно пренебречь.
Кстати, такой подход позволяет в качестве "полезной побочки" решить одну небольшую проблему. Дело в том, что разработчики контроллера My Heat почему-то подумали, что целевую температуру нужно задавать с точностью в один градус. Тут сказывается отсутствие у этих разработчиков практики в предметной области (то есть, жизни в доме, отоплением которого управляешь сам). А практика показывает, что для реальных систем отопления градус Цельсия - это очень грубо. Желательно иметь возможность задавать температуру с точностью ну хотя бы до половины гнрадуса. А в идеале - до одной десятой. И наша "побочка" состоит как раз в том, что как бы сохраняя выставленную на контроллере заданную температуру в те же 25 градусов, по факту мы можем настраивать заданную температуру практически с любой точностью - но однако в реальности нам хватит, пожалуй, и одного знака после запятой.
Переходим к делу. В Home Assistant'е создаем вспомогательные элементы типа "число" по количеству наших контуров (этажей). Даем им интуитивно понятные имена.
. и в опциях указываем минимальное (например, 5) и максимальное (например, 30) значения, а также тип представления (мне понравился "слайдер"), шаг (допустим, 0.1) и единицу измерения ( °C).
Создадим в Lovelace карточку типа "Entities" и поместим туда наши свежесозданные объекты. В этой карточке мы сможем, двигая ползунками, выставлять для каждого этажа свою заданную температуру. Для начала вручную, а потом, может быть, и автоматизацию какую-нибудь напишем.
Карточка может выглядеть примерно так. Тут я конечно, немного поспешил и показал, что в ту же карточку можно поместить значения реальных температур на этажах, а также значения фейковых (приведённых) текущих температур, вычисленных по принципу, изложенному ранее в этом документе.
Предполагается, что сенсоры для отображения истинных текущих температур на каждом этаже, у нас уже есть (а как иначе?). Они могут у вас по-разному называться, но у меня называются так:
- sensor.temperature_floor_3
- sensor.temperature_floor_2
- sensor.temperature_floor_1
Следующее, что нам нужно сделать в Home Assistant'е - это создать переменные (в нотации HA - сенсоры) для приведённых (фейковых) значений текущей температуры по каждому этажу. Для этого воспользуемся механизмом создания шаблонных сенсоров (Template Sensors).
Отступление: чуть не забыл. Я же не рассказал, как получить значение текущей и заданной температур с контроллера My Heat. Долго писать здесь не буду - всё описано здесь. Отмечу только что сенсоры, получающие эти два значения температуры с контроллера, называются у меня так:
- sensor. mh_virt_temp_temperature
- sensor.mh_virt_temp_target_temperature
При этом мы договорились, что целевая температура для нашего виртуально-фейкового термодатчика будет постоянной и равной 25 градусам. Таковой мы ее зададим средствами веб-администрирования контроллера (ну, или через REST-запрос со стороны HA, но зачем городить этот запрос, если операцию нужно выполнить всего один раз?).
Итак, создаем шаблонные сенсоры для отображения приведённых (фейковых) текущих температур по каждому этажу (на примере 3-го этажа):
Далее нам (чисто для удобства) необходимо будет создать по числу контуров двоичные сенсоры (binary sensors), которые будут нам показывать, нуждается ли тот или иной контур (этаж) в настоящий момент в обогреве. Принцип тут простой - если разница между истинными значениями заданной и текущей температуры положительная, то значит данный контур нуждается в обогреве. Ну, или разница между значениями заданной температуры виртуального датчика и приведёнными (фейковыми) значениями текущей температуры на разных этажах - что по сути одно и то же:
Теперь начинается интересное. Допустим, в текущий момент времени в обогреве нуждается не один этаж, а сразу два (или даже все три). Какую из фейковых температур передавать в MQTT и далее на контроллер? Логически предположить, что надо выбрать меньшую (потому что чем больше разница между заданной и текущей температурами, тем бо́льшую мощность разовьет котёл отопления - в этом и состоит, в частности, логика "умного" управления котлом по цифровой шине) . А как её выбрать? Да вот так:
Теперь мы знаем, что контроллеру в качестве текущей температуры нужно передать значение вот этого сенсора:
sensor. min_fake_temp
Это можно сделать с помощью созданной специально для этого в Home Assistant'е автоматизации. Но здесь возникает вопрос - а что будет являться триггером для срабатывания этой автоматизации? Рассуждая логически, триггером должно быть изменение значения сенсора sensor.min_fake_temp. Но к великому сожалению, в автоматизациях Home Assistant'а нельзя назначить триггером "просто изменение" значения сенора. Нужно обязательно указывать (причём, жёстко - т.е., в виде определенного числа) пороговое значение. Например, если температура поднялась выше 19 градусов. И триггер сработает именно в момент перехода температуры через эти 19 градусов. Получается, что для того, чтобы отрабатывать любые колебания температуры в диапазоне, скажем, от 18 до 20 градусов с точностью до одной десятой градуса, нам потребуется создать 20 (двадцать, Карл!) триггеров. А если в диапазоне от 16 до 26 градусов? А если нужны триггеры не только на повышение температуры, а еще и на понижение? В-общем, "это не наш метод".
Поэтому "пойдем другим путём" и назначим триггер типа "шаблон времени". Такой тип триггера позволяет запускать автоматизацию, как говорится, без видимых причин, а просто через равные промежутки времени (в нашем примере - каждые 10 секунд):
Как видно выше, мы не стали усложнять себе жизнь, создавая payload в формате JSON (как нынче модно). Мы просто тупо забиваем в топик значение температуры (например, 20,38), оставляя его там храниться ( retain: 'yes'), чтобы наш виртуальный термодатчик всегда смог прочитать оттуда это значение и сообщить контроллеру котла, что, мол, контролируемая температура такая-то.
Но это еще не всё.
Этап 3. Управляем кранами
Текст стал настолько длинным, что некоторые, возможно, успели подзабыть, о каких кранах идёт речь. А речь идёт о том, что на выходе из котла отопления эта самая выходящая (или в терминологии профильных специалистов - подающая) линия разветвляется на несколько контуров (например, батареи 1-го этажа, 2-го этажа и 3-го этажа), и после разветвления на линии каждого контура стоит кран, который имеет два положения - открыт или закрыт. Если кран открыт, то теплоноситель (вода или что там у вас залито в систему - антифриз, тосол, рыбий жир, томатный сок, лимонад "Буратино") попадает в контур, прогревает его батареи и охлажденный возвращается в котёл для нового подогрева. Если кран закрыт, то в контур вода не поступает, и его батареи начинают потихоньку охлаждаться. Вместе с ними охлаждается и воздух в помещении, обслуживаемом контуром, термометр в помещении начинает выдавать все более низкое начение температуры и т.д., и т.п.
О "физике" кранов я говорить не буду. Краны бывают разные. Есть электроприводы, непосредственно крутящие шаровую заслонку, а есть приводы, крутящие ручку обычного крана. Есть приводы, работающие на постоянном токе напряжением 12 вольт (и направление их работы - на открытие или на закрытие - обеспечивается сменой полярности подаваемого питания), а есть и работающие от бытовой сети переменного тока 230 вольт (да-да, не 220, а 230 - читайте новые стандарты) - и они управляются попеременной подачей "фазы" то на один контакт, то на другой, при условии, что на третий контакт всё время подается "ноль".
Для управления такими кранами можно использовать как "полуготовый" контроллер (например, Sonoff 4CH), так и самодельное (и более дешёвое) решение - например, на плате NodeMCU с прошивкой Tasmota в совокупности с блоком реле. В "особо тяжёлых" случаях иногда приходится ставить еще и дополнительные (промежуточные) реле - например, типа РЭК77 или РЭК78. Эти реле коммутируют (в зависимости от конкретной модели) от двух до четырех наборов "сухих" перекидных контактов, что позволяет (на нашем примере) одновременно с переключением электроприводного крана задействовать еще какие-то функции. Ну, не знаю - может лампочку включать во время перекладки крана. Или сирену. Или насос прокачки, если он имеется во включаемом контуре. Если у вас краны со сменой полярности, то без такого промежуточного реле вы точно не обойдётесь.
В-общем, не буду здесь описывать реализацию контроллера управления кранами. Скажу только то, что в итоге мы должны создать в Home Assistant'е несколько (по числу контуров отопления - в нашем случае это 3) объектов типа switch (а с точки зрения Tasmota, если вы будете использовать эту прошивку, это будут объекты типа Relay). Назовем их, например, так:
Например, если мы хотим открыть кран контура 1-го этажа, то присваиваем переключателю switch.vcran_1 значение on. А если надо закрыть кран 3-го тажа, то переключателю switch.vcran_3 присваиваем значение off. И так далее.
Осталось решить довольно сложную задачу - создать логику открытия и закрытия трёх кранов в зависи мости от потребностей того или иного этажа в обогреве. Плюс еще учесть маленький, но очень важный момент - в любой произвольный момент времени должен быть открыт хотя бы один кран. Для чего? Да чисто из соображений безопасности - чтобы не "запирать" котел и его насос, оставляя ему выход для прокачивания воды.
Для удобства создадим в Home Assistant'е еще несколько (в нашем случае - снова три) бинарных сенсора, основанных на шаблонах. Каждый сенсор может принимать значение 1 (true) или 0 (false) в зависимости от того, нуждается ли закрепленный за ним контур (этаж) в отоплении в данный момент. Сама эта "нуждаемость" вычисляется простой разницей температур - заданной и текущей. Если текущая меньше заданной, то топить нужно, если равна или больше - то не нужно:
Ещё нам понадобится создать три группы , в каждую из которых мы включим по два вышеупомянутых бинарных сенсора:
Читайте также: