Эта статья – логическое продолжение поднятой ранее темы мониторинга систем загородного дома. Тому, кто не читал предыдущую статью, некоторые мысли в данной статье могут показаться странными. Напомню: уже в процессе проектирования и выбора базовых компонентов стало понятно, что мониторингом работы систем загородного дома дело не закончится и что нужно делать не просто мониторинг, а фундамент умного дома. Теперь посмотрим, как развивались события. Как и прежде, я не буду приводить полные листинги программ или детальные схемы. Моя задача – показать ход мысли и, возможно, инициировать дискуссию.



Что вы хотите от умного дома?


Для начала нужно понять, а что собственно умного должно быть в умном доме. Речь идет не о каких-либо канонических определениях, а о том, что приходит в голову, когда в руках такой мощный набор инструментов, как описан в предыдущей статье: openHAB+Arduino/nFR24L01+. У меня получился вот такой список первичных «хотелок»:

  1. Научиться управлять мощностью электрического котла в зависимости от температуры в доме и на улице, а еще лучше с учетом прогноза погоды. До этого мощность котла задавалась только механическими выключателями на самом котле и работа котла была неоптимальной как с точки зрения нагрузки на сеть, так и с точки зрения экономии электроэнергии за счет Солнца (см. здесь).
  2. Исключить ручные манипуляции включения/выключения насосов (подача воды, рециркуляция ГВС), полотенцесушителя, термостатов радиаторов и т.д. при приезде/отъезде. Ну и, конечно, видеть статус этих устройств.
  3. Научиться включать и выключать свет, фонтан и другие устройства в зависимости от времени суток и года, присутствия в доме хозяев и еще каких-либо факторов. В более общей формулировке – алгоритмизировать и автоматизировать управление теми устройствами, управление которыми рутинно, исключить однообразное щелканье традиционными выключателями, особенно в темноте. Все должно включаться и выключаться автоматически.
  4. Использовать алгоритмы, позволяющие экономить электроэнергию. Например, долго включенная первая ступень котла позволит получить от Солнца энергии больше, чем периодически включающиеся/выключающиеся по температуре обратной магистрали 2-3 ступени. Т.е. можно получить экономию электроэнергии за счет более продуманной нагрузки.
  5. Родившейся к этому моменту системы мониторинга и управления было достаточно для реализации только части этих требований. Например, управлять котлом по ступеням уже можно, но пока не понятно по каким алгоритмам, с учетом ограничений на потребление электроэнергии и с учетом баланса приоритетов на отопление дома и на приготовление горячей воды. Кроме того, первая версия системы включила не все необходимые исполнительные устройства, например, не было устройств управления насосами, не весь свет в доме был автоматизирован. Появились дополнительные конкретные запросы, например, «сделать подсветку картины». Причём, этот запрос сам собой трансформировался в «сделать автоматическое включение и выключение подсветки картины в зависимости от времени суток, освещенности и других факторов».

Итого: есть расширяемый фундамент, есть цели. Анализируем, каких данных не хватает. Во-первых, не хватает электрических параметров, как минимум следующих: текущее потребление дома, мощность, получаемая от Солнца. Во-вторых, не хватает прогноза погоды. Кроме этого, не хватает компактных исполнительных устройств. Замечу, что оконечные контроллеры с исполнительными устройствами (реле), описанные в предыдущей статье, все были многофункциональными и не очень компактными. И к тому же самодельными. Некоторые устройства, например, управляемые термостатические головки на радиаторы отопления делать самому нет вообще никакого смысла, их надо покупать.

Получать параметры электричества


Итак, начинаем с электрических параметров. Первое что приходит в голову – поставить датчики тока на основе эффекта Холла, датчик 220В уже есть, остается ещё измерить напряжение на панелях и аккумуляторах. Всё можно сделать на отдельных датчиках. Однако, все эти измерения уже делаются энергетической установкой на основе инвертора и MPPT-контроллера Xantrex. Как мы помним, эти устройства объединены в проприетарную шину Xanbus, которая является транспортом для взаимодействия устройств по Modbus-протоколу. И для нее есть специальный TCP-Modbus шлюз Conext ComBox, который позволяет считывать и устанавливать параметры системы по локальной сети. Это как раз то, что нужно! В свою очередь для openHAB есть специальный binding TCP- Modbus, который остается подключить и настроить. Итак, шлюз куплен, документация изучена, binding к openHAB подключен и настроен, items определены, базовые правила написаны. В итоге в умный дом стали поступать следующие параметры: напряжения на входах сети и генератора, напряжение на выходе инвертора, ток нагрузки, мощность нагрузки в Вт и ВА, напряжения на солнечных панелях и аккумуляторах, токи на входе и выходе из MPPT-контроллера, ток заряда батареи, мощность получаемой солнечной энергии, отдаваемой, количество собранной солнечной энергии, отданной в систему, отданной обратно в сеть. Считывается даже температура аккумуляторов, однажды это помогло избежать их перегрева.

Участие в развитии openHAB
В процессе отладки были выявлены ошибки в функционировании TCP-Modbus шлюза. Через форум openHAB вышел на разработчика в числе других тестировщиков. В итоге binding был доработан в несколько итераций и работает уже более двух лет.


TCP-Modbus шлюз для чтения параметров устройств Shneider Electric (Xantrex), объединенных в сеть Xanbus.

Получать прогноз погоды


Далее. Получить прогноз погоды можно разными способами, например, подписаться на услуги провайдера. Однако, есть и более очевидный путь: забирать данные прогноза прямо с погодного сайта, например, yandex.ru/pogoda. Для этого написал на C утилиту, которая с помощью библиотеки curl сохраняет HTML-страницу в файл. В HTTP-запросе утилита передаёт сайту координаты дома. Полученный файл разбирается и из него извлекается с десяток параметров: температура, время восхода и заката, прогноз ночной температуры, направление и сила ветра. В алгоритмах умного дома используются прогноз ночной температуры, время заката. Остальные данные просто информативно показываются в интерфейсе. В openHAB данные передаются этой же утилитой через поддерживаемый openHAB удобный REST API. В свою очередь сама утилита на С запускается штатными средствами openHAB каждые 4 часа. Таким образом, всё довольно просто, а основную сложность представляет разработка алгоритма разбора сохраненной HTML-страницы. Но моя статья не об этом.

На рисунке — экран умного дома с данными погоды, полученными по координатам дома с yandex.ru/pogoda

Автоматизировать рутинное управление устройствами


Как раз во время работы над получением прогноза погоды друг подарил мне управляемые по WiFi реле и целый электрический удлинитель с тремя реле и тремя парами розеток фирмы USR IOT. К этому моменту я уже немного освоился в openHAB и с некоторым азартом приступил к освоению новых устройств и включению их в состав умного дома. Реле было определено для управления скважинным насосом, а удлинитель разместился в сарае и использован для управления подсветкой пруда, фонтаном, светом в сарае. К устройствам USR IOT нашел в сети документацию с описанием протокола управления, однако сетевой трафик все равно пришлось слушать с помощью Wireshark. В итоге научился генерировать управляющие команды и разбирать ответы от устройств. Для управления реле написал на С программу, которая вызывается правилом из openHAB, а удлинитель подключил напрямую, используя TCP binding openHAB. На фото справа удлинитель фирмы USRIOT с управляемыми по WiFi розетками.

Осталось написать правила:

  1. Включение скважинного насоса. При снятии дома с охраны включить насос, при постановке на охрану – выключить. Всё просто, ведь состояние охраны система научилась считывать с сигнализации на этапе «мониторинг». И этот параметр в дальнейшем используется во множестве правил. Для этой цели часто используют детектирование присутствия в доме, например, по Bluetooth-меткам, по регистрации мобильного устройства в локальной сети и т.д. Однако эти методы не очень стабильны, и для использования в серьёзных правилах нежелательны.
  2. Включение фонтана в пруду. Раньше использовал электронные реле времени, но они регулярно сгорали и не знали о присутствии хозяина в доме. Теперь же открылась «новая эра» автоматизации. Фонтан включается, если дом снят с охраны, если температура на улице (научились измерять на этапе «мониторинг») не менее 5 градусов (зимой фонтан не нужен) и время 08:00. Выключается фонтан в 23:00, всегда. Т.е. правило немного «несимметричное» и это очень удобно.
  3. Включение подсветки пруда. Надо сказать, что сама подсветка появилась из-за желания включать ее автоматически. Подсветка включается, когда дом снят с охраны, когда освещенность на улице ниже заданного в настройках параметра, и по факту движения на крыльце основного или гостевого дома. Т.е. не загорится раньше, чем хозяин захочет ее увидеть. Все параметры для управления появились на этапе «мониторинг». Выключается в 01:00, всегда.
  4. Включение света в сарае. Это самое забавное правило. Свет включается, если дом снят с охраны, если уровень освещенности ниже заданного порога, если температура воздуха ниже 15 градусов и если засечено движение на крыльце. Выключается через 5 минут, при повторном движении на крыльце время горения продляется на 5 минут. Всё реализовано только штатными средствами openHAB. Спрашивается: зачем используется температура в правиле? Очень просто: в сарае хранятся дрова для камина. Если вечером в прохладную погоду я вышел на крыльцо, то, вероятно, за дровами :) и лучше, если в сарае будет гореть свет.

Остается заметить, что во всех правилах устройства включаются и выключаются автоматически. Но при этом ими можно управлять и вручную через интерфейс openHAB. Описанные устройства USR IOT имеют также и физические кнопки управления на корпусе, поэтому важно научиться считывать состояние устройств. Одним из способов актуализации состояния всех исполнительных устройств, а также датчиков является их опрос из openHAB по таймеру, например, каждые 15 минут. Для самодельных устройств, кроме этого, обязательно делается отправка статуса при изменении состояния управляющих кнопок/выключателей.

Вернемся на шаг назад. Исходной задачей было научиться гибко управлять отоплением, чтобы в доме было тепло, всегда была горячая вода, и чтобы не приходилось регулярно ходить в котельную регулировать работу котла. И чтобы при этом минимизировать вероятность отключения котла в результате срабатывания реле ограничения нагрузки, которое установлено в щитке и ограничивает текущее потребление за счет отключения неприоритетных нагрузок, к которым относятся и котёл, и бойлер. При этом на первой ступени отключается ТЭН бойлера на 5 минут, а если это не помогает, то еще и котел на 10 минут (вторая ступень). Напомню, потребление на дом ограничено и в доме все электрическое, газа нет, поэтому приходится следить за потреблением. А еще хорошо бы по-максимуму использовать энергию Солнца. Вот некоторые получившиеся правила.

Первая группа. Дом снят с охраны:


  1. Каждые 20 минут проверять температуру в доме и, если она ниже заданной (22 градуса) добавлять одну ступень мощности котла. Но, делать это если не превышен порог тока нагрузки, например, в 25,6 А. Если же температура выше заданной, то каждые 20 минут отключать по одной ступени котла, оставляя только первую. В результате мы получаем плавный «разгон» системы отопления и защищаемся от ее полного отключения из-за превышения нагрузки. Общая логика такая: если в доме работают мощные потребители электроэнергии, например, плита, чайник, микроволновая печь или даже пылесос, то потребляемая ими энергия в конечном счете переходит в тепло, остающееся в доме и не зачем гнаться за включением котла на полную мощность. Лучше пусть котел работает на первой ступени, но не отключается на 10 минут в результате срабатывания реле ограничения нагрузки.
  2. Если температура горячей воды в бойлере ниже 35 градусов включить первую ступень котла и ТЭН бойлера. Если температура воды больше 35 градусов, а температура воздуха в доме выше заданной, (23 градуса), выключить первую ступень котла. Если температура воды выше 37 градусов – выключить ТЭН бойлера. При этом все включения делать только если ток нагрузки не более 25,6А. Иначе сработает реле ограничения нагрузки и 10 минут вообще ничего нельзя будет включить. Все проверки делать при обновлении показаний датчика температуры горячей воды. Это правило гарантирует наличие горячей воды, быстрый прогрев при минимальном потреблении энергии.
  3. Если температура теплоносителя в солнечном контуре больше температуры горячей воды, которая в свою очередь выше 35 градусов – отключить ТЭН бойлера. Таким образом можно сэкономить электроэнергию и при этом не остаться без горячей воды.
  4. Если температура в доме больше заданной (23 градуса), а температура горячей воды больше 35 градусов – отключить котел полностью. Иначе будет перерасход электроэнергии, а автоматика котла будет часто отключать его по температуре в обратной магистрали.
  5. Если на ТЭНе бойлера нет напряжения, хотя он включен из умного дома, значит сработала первая ступень реле нагрузки. Если ограничить мощность котла, можно избежать и его отключения. Выключаем вторую и третью ступени. Потом они сами включатся, другими правилами, если это будет необходимо. Аналогично проверяем напряжение питания котла. Если оно пропало – сработала вторая ступень реле нагрузки, оставляем только первую ступень котла, все остальное, включая ТЭН бойлера отключаем. Они включатся потом другими правилами. Делается это для того, чтобы уменьшить вероятность повторного срабатывания реле нагрузки и для обеспечения максимального и равномерного потока тепла в дом.

Вторая группа. Дом на охране.


  1. Если температура на улице ниже минус 8 градусов, включить вторую ступень котла. (первая включается автоматически со времен установки универсального GSM-контроллера, см. здеcь, под первым катом). Если температура на улице ниже -15 градусов – включить третью ступень котла. Тем самым обеспечивается оптимальная работа системы отопления при поддержании заданной экономичной температуры в доме. При повышении температуры на улице ступени последовательно отключаются. Это правило позволяет сделать работу котла более равномерной и эффективной.
  2. Если на улице высокая освещенность, включить котел превентивно, не дожидаясь срабатывания автоматики поддержания экономной температуры (8 градусов). Перевести котел обратно в автоматический режим, если температура достигла расчетного значения. Расчетное значение вычисляется по эмпирической формуле, в которой используется минимум из ночной температуры за минувшие сутки и прогноза ночной температуры. Кроме этого, котел возвращается в автоматический режим если, получаемая от Солнца электрическая мощность падает ниже 500 Вт. Этот показатель сглаживается на нескольких проходах выполняемого каждую минуту правила. В итоге правило позволяет экономить электроэнергию: за счет прогрева дома, котел в темное время суток будет меньше работать и меньше потребит энергии от сети.


Скриншот среды разработки openHAB Designer с двумя правилами управления отоплением и ГВС.

Предварительные итоги:


  1. Поставленные цели достигнуты совершенно непыльным путём. Львиная доля трудозатрат была связана не с оборудованием, а с программированием. И из этого программирования бОльшая часть пришлась на разработку и отладку правил в openHAB.
  2. Уже на ранних стадиях развития умного дома оправдалась ставка на «technology agnostic» решение. В описанных выше правилах используются данные, полученные с самодельных контроллеров на Arduino, с покупного TCP-Modbus шлюза, полученные из Интернета, т.е. из совершенно разнородных источников. Добавилось управление устройствами по TCP/IP. Всё это очень гармонично оркестрируется из openHAB. Но, конечно, при этом openHAB становится единой точкой отказа. Именно поэтому в качестве операционной системы под openHAB правильно использовать Linux. Поэтому же пришлось со временем перейти от подключения сервера к LAN по WiFi на обычный провод. Пришлось также поставить индивидуальный UPS, несмотря на резервированное питание всего дома. Ну и в завершение пришлось поставить на питание сервера управляемую по WiFi-розетку Xiaomi, подключив ее к отдельной WiFi-сети, она служит последним аргументом при зависании сервера.
  3. Пришло осознание того, что Интернет вещей и умный дом действительно открывают горизонты для нового качества жизни. Действительно повышается комфорт. Действительно, появляется экономия. И, наконец, появляется азарт, приводящий к подключению новых устройств и использованию новых технологий интеграции. Что снова приводит к дополнительному комфорту.

В следующем посте расскажу, к чему привел азарт и как эволюционировал умный дом.

Комментарии (32)


  1. dunkle
    02.08.2018 14:20

    Я бы хотел обсуждать тему умного дома подробнее и чаще, может быть есть какая-та группа в телеграме, где можно обмениваться идеями/наработками, спрашивать советы, а если нет, то быть может надо ее создать?


    1. Medox Автор
      02.08.2018 15:31

      Может быть, хотя мне кажется из-за разнообразия решений, интерфейсов, технологий может получиться каша.


    1. BigD
      02.08.2018 18:33


  1. Nick_mentat
    02.08.2018 16:25

    Нельзя ли предоставить информацию по логике обогрева воды и воздуха в виде блоксхемы? А то текстом сложнее воспринимать…


    1. Medox Автор
      02.08.2018 16:58

      Можно, но надо рисовать. Будет две-три отдельные и очень простые блок-схему. С ходу могу сказать только следующее — правила в основном асинхронные, в том смысле, что управление ТЭНом бойлера и ТЭНами котла — делаются разными правилами и события-триггеры для них могут быть разные. Поэтому единой блок-схемы в любом случае не получится.


      1. Nick_mentat
        02.08.2018 17:09

        Однако у них есть ограничение на общую потребляемую мощность. Т.е. из того что я прочитал, я понял что можно сделать единую систему приоритетов, завязанную так же на фиксацию факта использвания другого мощного прибора (типа чайничка). Это должна быть именно одна система.


        1. Medox Автор
          02.08.2018 17:56

          Все параметры в openHAB определяются либо как глобальные переменные внутри файла правил, либо как items. Обратиться к любому item можно из любого правила, вызванного любым событием.
          Как это работает. TCP-modbus binding каждые 4 секунды опрашивает modbus-шлюз и считывает параметры электричества. Таким образом они актуализируются. Уже на этапе обновления тока нагрузки можно вызывать правило, которое отключит лишние ступени котла. А можно сделать правило, которое следит за какой-либо температурой и вызывается при ее изменении, а в самом правиле прописать сравнение текущего тока нагрузки, который хранится в соответствующем item с предельно допустимым.


        1. Medox Автор
          02.08.2018 18:00

          На скриншоте среды разработки есть правило «Boiler rule».
          Там есть строка проверки тока нагрузки
          if((LoadCurrent.state as DecimalType) < MaxLoadCurrent — 9) { сделать что-то
          LoadCurrent — это как раз и есть item доступный всем правилам.
          MaxLoadCuurent — это глобальная переменная (константа), доступная только внутри конкретного файла с правилами. Она как раз равна 25.6 А.


        1. Medox Автор
          02.08.2018 18:02

          Т.е. асинхронные правила настолько просты, что нет нужды для них рисовать блок-схемы. Важнее думать об их корректной совместной работе, чтобы результат их действий не был противоположным, иначе в системе возникнут автоколебания.


  1. ACooper
    02.08.2018 19:52

    Попробуйте Microsoft Visual Studio Code с плагином openHAB VS Code Extension. Думаю, у Вас пропадёт желание дальше пользоваться стандартным дизайнером от openHAB.


    1. Medox Автор
      03.08.2018 09:16

      Спасибо, надо попробовать


  1. Igrek_L
    02.08.2018 20:37

    Вышел на крыльцо в холод за дровами это конечно хороший кейс. Но не хочется уже его решать прямым программированием. Для подобных задач сейчас пытаюсь простенькую нейронную сеть накинуть. Пусть самообучается выделяя некие паттерны и по ним работает. И когда это сможет без программирования самонастраиваться, в массы двинется потоком. Мне так думается.


    1. Medox Автор
      03.08.2018 09:09

      Будет интересно узнать о результатах.


  1. iig
    02.08.2018 22:52
    +1

    Прогноз погоды котлу не нужен совсем. Колебания температуры за бортом очень медленные, для их компенсации достаточно ПИД-регулятора, который все равно должен присутствовать.


    1. Medox Автор
      03.08.2018 09:07

      Согласен на 100%. Однако, в одном из правил, ориентированных на использование солнечной энергии у меня используется прогноз ночной температуры. Т.е. не столько для отопления, сколько для экономии.


      1. iig
        03.08.2018 09:42

        Хм. И как это позволяет экономить? Выработка энергии днём ведь никак не изменится от прогноза температуры на ночь?


        1. Medox Автор
          03.08.2018 09:59

          Так в статье выше я и описал. Зимой и особенно в межсезонье, в режиме охраны в доме поддерживается +8 автоматикой, отдельной от умного дома. Если есть Солнце, то можно прогреть дом превентивно, например до +10, тогда ночью котел дольше будет выключен. Прогноз ночной температуры использую для вычисления целевой температуры, до которой надо прогреть дом, чтобы котел не включался ночью.


          1. iig
            03.08.2018 12:02

            Да, невнимательно читал. У вас, наверное, очень хорошая теплоизоляция и очень много солнечной энергии. Иначе, проще было бы в режиме охраны просто всю неиспользованную солнечную энергию отдавать на отопление. Ну нагреется днем вместо +8 до +22 (больше, наверное, будет лишнее).


            1. Medox Автор
              03.08.2018 12:50

              Теплоизоляция хорошая. О Солнце я писал вот здесь habr.com/company/sberbank/blog/414219
              Больше телпа собирать тоже не получается в межсезонье, особенно ближе к зиме. Если солнечного электричества больше 500Вт — это уже удача. И этого недостаточно даже для 1-й ступени котла.
              А солнечное тепло, появляющееся в марте и так все полностью в дом идет.


              1. iig
                03.08.2018 14:57

                Тогда я опять не понял, в чем экономия, если в любом случае вся солнечная энергия и так уходит на отопление.


                1. Medox Автор
                  03.08.2018 15:36

                  Посмотрите здесь habr.com/company/sberbank/blog/414219.
                  Есть солнечное тепло. Собирается солнечными коллекторами. Полностью уходит в дом. Но, появляется не раньше марта.
                  Есть солнечное электричество, собирается солнечными панелями. Появляется в феврале. Так вот. Допустим мощность первой ступени котла 1.7кВт. Допустим, Солнце светит на 1кВт, тогда от сети 220В я возьму всего 700Вт. Т.е. за 1 час работы котла сэкономлю 1кВт.ч. За счет этой разницы и превентивного прогрева дома я и получаю экономию на поддержании температуры в доме. Прогрев дом до 11 градусов я даю ему 10-12 часов на остывание ночью с выключенным котлом, когда нет солнечного электричества, до 8 градусов, когда включится котел.


                  1. iig
                    03.08.2018 16:26

                    Это понятно. Тогда имеет смысл превентивный нагрев без учета прогноза температуры.


                    1. Medox Автор
                      03.08.2018 16:40

                      Можно и без прогноза, в некоторых случаях котел будет дольше работать, чем нужно. Собственно проблема не в том, что дольше, а в том, что он будет больше включаться-выключаться из-за неравномерности солнечного электричества, сокращая ресурс реле. В любом случае для расчета я беру минимальное из предыдущей ночной температуры и прогнозной.


                      1. iig
                        03.08.2018 17:35

                        Чем больше нагреем дом днем — тем дольше будет остывать ночью — тем меньше время работы котла, разве не так?
                        Чтобы минимизировать количество включений — либо вместо реле симистор с детектором нуля, либо гистерезис между температурой включения и выключения.
                        Чем логика проще — тем надежнее. ИМХО.


                        1. Medox Автор
                          04.08.2018 09:15

                          Это сложнее, а не проще. Нет ничего проще, чем написать правило в OH. А гистерезис у котла, естественно есть, штатный.


                          1. iig
                            04.08.2018 09:50

                            Проще, КМК, не писать правил, если они заявленную задачу не решают. Если экономия электричества заключается в простом наргеве по максимуму солнечной энергией, а экономией ресурса реле заниматься сам котел.
                            Но я не настаиваю ;)


                            1. Medox Автор
                              04.08.2018 20:46

                              Да, лучше не писать. Но это не мой случай. У меня происходит именно то, что я хотел добиться.


          1. Gryphon88
            03.08.2018 16:41

            Извините, немного оффтоп: насколько разумно держать температуру 8С? Допустим, растений и домашних животных нет, но вот за обои и штукатурку я бы волновался.


            1. Medox Автор
              03.08.2018 16:45

              да, 8 градусов на грани разумного. Штукатурка и приклеенные карнизы при падении ниже 5 градусов могут пострадать. Один раз карниз у меня отвалился в сильный мороз, когда котел не справился и температура опустилась ниже 5 градусов.

              Однако, на 8 градусах — все нормально.


  1. MDiMaI666
    03.08.2018 09:55

    Используйте node-red классная вещь, для построения подобных систем
    image


    1. Medox Автор
      03.08.2018 09:57

      Да, на Raspbian кажется даже предустановлен node-red. Но, пока не добрался, чтобы понять подходит мне или нет.
      В следующем посте у меня появятся Raspberry и MQTT.