Главная » Хабрахабр » Мониторинг работы систем загородного дома: первые шаги к умному дому

Мониторинг работы систем загородного дома: первые шаги к умному дому

Итак, мы остановились на том, что после появления в доме альтернативных источников энергии, в первую очередь солнечного коллектора, захотелось измерять параметры, сопровождающие их работу. Предыдущая заметка вызвала довольно бурную дискуссию и это обстоятельство убедило меня в необходимости продолжения того, что мы называем «делиться опытом». Понятно, что само по себе измерение чего-либо и даже передача этой информации к месту потребления (телеметрия) не увеличивают комфорт или безопасность, поэтому сразу же в «ТЗ» внесен пункт об удаленном управлении различными исполнительными устройствами. Например, для того, чтобы видеть, как меняется температура солнечного теплоносителя, не перегревается ли вода в бойлере и т.д. Моя цель – показать ход мысли и принятые технические решения, а также их результат. В этой статье я не буду приводить листинги кода, детализировать до мелочей все технические решения. Тому, кто захочет пойти похожим путем всё равно придется самостоятельно решать множество задач.

Небольшое лирическое отступление.

Это замечательное универсальное устройство использовалось помимо функций сигнализации с оповещением по GSM, еще и для управления светом в гостиной, и, главное, для управления электрическим котлом. В 2010г вместе с инвертором/аккумуляторами в доме появился универсальный GSM контроллер-сигнализация российской фирмы RADS Electronics. Удобство подобных систем совершенно очевидно. Так что контролировать температуру, поддерживать температуру, а также прогревать дом заранее, до приезда, я научился уже давно. Однако, возможности контроллера ограничены, поэтому в новом «ТЗ» изначально закладывалось создание параллельной системы, пусть даже с частично повторяющимися функциями и, естественно, с доступом к информации с датчиков и управлению через Интернет.

Так вырисовались начальные требования:

  1. Измерять температуру на всех 8 патрубках бойлера и 2 патрубках котла.
  2. Измерять температуру и влажность воздуха в котельной, где смонтировано оборудование.
  3. Измерять температуру и влажность воздуха на улице. Чтобы когда-нибудь в будущем реализовать погодозависимое управление отоплением.
  4. Управлять электрическим котлом, сохранив старую систему. Котел трехступенчатый, с регулировкой температуры нагрева и обратной связью по температуре теплоносителя. Однако, для целей удаленного управления достаточно включать/выключать ступени отопления.
  5. Управлять ТЭНом бойлера.
  6. Прокладывать минимум проводов. Не столько потому, чтобы не возиться, сколько потому что отделка в доме уже сделана.
  7. Иметь удобный интерфейс для управления и работы с показаниями датчиков. Интерфейс должен быть доступен на мобильных устройствах. 

И еще одно небольшое отступление.

Для зимнего пуска пришлось поставить автомобильный аккумулятор и зарядное устройство. На фото — генератор с электростартером. И использовать синтетическое масло.

И к нему в скором времени добавился контроллер автоматического запуска, сделанный самостоятельно на базе микроконтроллера Arduino. Всё в том же 2010г в гараже поселился бензиновый генератор. Всё вместе позволило реализовать достаточно интеллектуальный алгоритм управления генератором. Контроллер смотрит не только на наличие сети 220В, но и на сигнал с инвертора о разряде аккумуляторов, а сам инвертор обеспечивает автоматический ввод генератора. В прошлом я много программировал на С/С++. В общем, страха перед использованием микроконтроллеров не было никакого, как в смысле подключения периферии, так и в смысле программирования.

Существуют тысячи разных способов их реализации. Требования, в общем-то, простые, если не сказать тривиальные. Здесь как раз важен системный подход, понимание того, что отдельные технические решения должны быть увязаны друг с другом, понимание того, что система, безусловно, будет расширяться дальше, как уже случилось с системой энергоснабжения дома. И именно поэтому краеугольным камнем является выбор архитектуры и технологического стека, на котором будет строиться новая система. Поэтому пришлось гуглить, брать «помощь зала» и «звонок другу». И еще важно понимание собственных возможностей.

Поскольку Z-Wave – очевидный выбор под требования, близкие к моим, важно понимать, почему он был отброшен. На фото Arduino Nano и nRF24L01+ c антенной
Смотреть начал с систем на базе широко распространенного стандарта Z-Wave, это в значительной мере повлияло на дальнейшие решения, хотя Z-Wave и был на первых порах отброшен. А мне только на бойлере в 8 точках измерять температуру надо, каждая точка получается по 3000+ рублей. Во-первых, конечно стоимость одного датчика. В-третьих, ограниченность выбора систем управления и удаленного доступа, которые к тому же все проприетарные (следует читать: «ограниченные») и платные. Во-вторых, форм-фактор стандартных датчиков, не позволяющий применить их на патрубках бойлера. По совету друга вышел на интересный проект, который изначально выглядел как расширение функциональности Z-Wave систем на базе контроллеров Vera, но с использованием DIY-подхода. Однако, сама идея самоорганизующейся сети с возможностью, как одноранговых связей (ассоциаций) датчик-исполнительное устройство, так и централизованного, сервер-клиент, управления, очень привлекательна. 4ГГц трансиверы nRF24L01+ и соответствующая библиотека. В проекте использовались Arduino, беспроводные 2. Использование Arduino открывает практически безграничные возможности домашней автоматизации за деньги, на порядок (!) меньшие, чем в случае с Z-Wave. Всё вместе как раз то, что нужно под мои требования. Контроллер автоматического запуска генератора, собранный когда-то на Arduino, безукоризненно работает уже 7 лет. Немаловажно также, что Arduino – исключительно стабильная платформа. Учитывая наличие опыта разработки, пайки и программирования, остановился на этом проекте.

В коде вообще отказался от привязки к Vera. И даже пошел дальше. Им, после изучения форумов и сайтов производителей, стал open source проект openHAB. Вместо него выбрал один из рекомендованных автором библиотеки mysensors программных контроллеров. Это как раз то, что и нужно системно мыслящему IT-специалисту: возможность расширения системы в будущем, использование компонентов разных производителей и стандартов, при этом наиболее подходящих под конкретные цели. Решающим фактором, помимо открытости, кроссплатформенности, встроенного мощного языка правил, наличия мобильных клиентов, стало следующее заявленное свойство: «a vendor and technology agnostic». с самого начала было понимание, что не всё нужно делать на Arduino и не всё можно в границах Z-Wave. Т.е. Т.е. При этом я решил придерживаться централизованной логики управления, что для начала вполне естественно. Прямого взаимодействия узлов сети устройств пока не планирую. на оконечных устройствах, собираемых на Arduino, будет минимальная бизнес-логика: включение/выключение света от античныхобычных механических выключателей, которые становятся просто датчиками, чтение и преобразование информации с датчиков физических параметров, передача данных на сервер, прием и исполнение команд с сервера. Теперь остались сущие мелочи – выбрать аппаратную платформу и операционную систему под серверную часть, под openHAB. Вся реальная бизнес-логика управления – на правилах openHAB.

И это отличное решение, экономичное, компактное и бесшумное. Многие DIY-щики под openHAB выбирают Raspberry Pi. Забегая вперед скажу, что в итоге Kodi интегрирован с умным домом, при запуске видео – гаснет свет, при остановке — зажигается. Однако, мне показалось неправильным ограничивать себя в вычислительной мощности, потому что сразу решил использовать будущий сервер как многофункциональное устройство, например, на нем же захотел развернуть медиацентр Kodi и, возможно в будущем, еще что-то, например, программный видеорегистратор. При этом особых требований к мультимедиа-компонентам у меня нет, достаточно чтобы на сервере были HDMI и S/PDIF. Да и видеорегистратор тоже появился и тоже интегрирован. на AliExpress): Intel Core i7, 8GB, 256GB SSD, 8 USB-портов, включая 4 3. В общем, осенью 2015 года выбор пал на безвентиляторный неттоп от Hystou (см. Стоил он тогда около 24 т.р. 0, 2 LAN, WiFi, 2 HDMI, S/PDIF, Card reader в общем всё, что нужно для счастья DIY-щика. Но, последовавший за всем этим опыт уверенно говорит: везде, где можно проложить провода – прокладывать провода. О выборе ни разу не пожалел, хотя должен сказать, что WiFi у него работает не очень стабильно. 4ГГц и т.д.) всегда хуже, чем провод. Радиоканал, независимо от стандарта и частоты (WiFi, Z-Wave, 433МГц, 869МГц, 2. И на нем поселилось еще несколько различных систем.
Что касается ОС для сервера, то я бы рекомендовал стабильность и предсказуемость. Поэтому неттоп в итоге подключен к домашней LAN проводом. Мне — привычнее Ubuntu. Этим свойством обладают дистрибутивы Linux с большими community. Хотя, благодаря кроссплатформенности, всё можно сделать и на Windows.

Действуем. Итак, архитектура и стек выбраны.

Температуру теплоносителей и воды будем замерять на патрубках бойлера и котла. Задача 1. Выбрать датчики и исполнительные устройства. А сами патрубки с датчиками сверху прикрываем поролоновой теплоизоляцией для труб. Для этого берем 1-wire датчики DS18B20 в металлическом герметичном корпусе, их удобно крепить непосредственно на патрубках, снаружи. Для измерения температуры воздуха и влажности в котельной и на улице выбираем DHT22, просто потому что это стандартный выбор DIY. Когда однотипных датчиков много, шина 1-wire очень удобна. Важно заметить, что эти реле подключаются параллельно выключателям ступеней на котле, а не реле ТЭНов, которые управляются автоматикой котла. Управлять котлом раздельно по ступеням – с помощью обычных пятивольтовых механических реле, также привычных DIY-щикам. Никаких сложностей. Вся выбранная периферия либо бесхитростно программируется напрямую, как реле, например, либо имеет соответствующие библиотеки для Arduino, как 1-wire/DS18B20/DHT22.

Видно, что к каждому патрубку подходит черный провод с датчиком на конце, в белой коробке они объединяются и общий белый провод 1-wire идет к контроллеру. На фото бойлер 300л.

Пришлось немного повозиться, поскольку с openHAB еще не был «на ты». Задача 2. Обмен данными и командами с openHAB. к openHAB. Архитектура mysensors подразумевает наличие gateway (шлюза) для подключения к центральному контроллеру/серверу, т.е. Поскольку я в начале пути – выбираю Serial и размещаю gateway рядом с сервером. Cам gateway – физически отдельный контроллер на Arduino/nRF24L01+ и может подключаться к серверу по LAN/WiFi или Serial. Сообщения mysensors имеют фиксированный формат и легко парсятся. Gateway служит для маршрутизации сообщений, передаваемых в сети mysensors через gateway и непосредственного обмена с центральным контроллером, openHAB. За основу правила openHAB, разбирающего сообщения, взят код, найденный на форуме mysensors. Добавляем в openHAB binding Serial для подключения gateway по USB и пишем правило для парсинга сообщений устройств в сети mysensors, получаемых по USB от gateway. Далее пишем правила для исполнительных устройств – реле управления котлом, ТЭНом бойлера, светом и т.д.

На фото – gateway, маленькая коричневая коробка с антенной на аудиоколонке.

Про openHAB

Например, для взаимодействия с устройствами по USB есть binding Serial. openHAB – решение открытое, расширяется с помощью комьюнити за счет разработки bindings к конкретным устройствам, с которыми openHAB будет взаимодействовать. Сам я поучаствовал в разработке в качестве активного тестировщика Modbus binding. Аналогично для других устройств или протоколов, например Modbus, NTP, HTTP, Squeezebox, Kodi/XBMC, Z-Wave, ZigBee, Nest и так далее.

Все эти измерения и предсказания передаем в openHAB.
На фото gateway изнутри. Пока возился с подключением gateway к серверу openHAB, решил доработать код gateway (и сам gateway), взятый с mysensors.org и добавить к нему датчик температуры и влажности DHT22 и датчик атмосферного давления BMP180, а заодно нашел исходный код для предсказания погоды по динамике атмосферного давления. На белом проводе — DHT22, плата со свободными pin'ами — Arduino, справа внизу — nRF24L01+ и BMP180.

openHAB – полностью настраиваемая система, включая разметку интерфейса. Задача 3. Интерфейс и удаленный доступ. Универсальная разметка, конечно, не может быть идеальной, но на смартфоне смотрится хорошо, а это главное. И эта разметка – единая, как для обычного доступа через браузер, так и через мобильное приложение. Во-первых, можно (и что важно, необязательно) использовать облако myopenhab.org. Остается решить, как вне локальной сети получить доступ к серверу openHAB. Это решение самое простое и обеспечивает полную функциональность управления системой, кроме разве что передачи видео с ip-камер. Сервер openHAB подключается к облаку напрямую с помощью специального binding. Раскрывать детали по понятным соображениям не буду, тем более что этот вопрос не относится напрямую к теме статьи. Во-вторых, для тех, кто не любит облака, а я отношусь к их числу, есть обычные средства удаленного доступа, например комбинация VPN+VNC и т.д. По первому идет, если видит по этому адресу сервер openHAB, по второму – если не видит. Замечу только, что мобильный клиент openHAB имеет настройку на два адреса. Например, в качестве второго адреса можно указать облачный и тогда openHAB доступен всегда без дополнительных манипуляций с подключением VPN. Это очень удобная особенность интерфейса. Или еще как-то. Или указать виртуальный адрес, полученный с помощью какого-либо VPN-решения.

Начальный экран интерфейса

Скроллинг вниз стартового экрана

Раскрытый пункт меню «Свет»

Некоторые пункты раскрываются при нажатии, например «Отопление», «Свет», «Сирена» и т.д. Разметка позволяет делать условное форматирование, например, выделять красным температуру при превышении ею заданного в разметке значения.

Берем в руки по очереди то паяльник, то клавиатуру. Вот вроде и всё. Как известно, аппетит приходит во время еды. И постепенно первая версия системы обретает очертания. В итоге на первом этапе внедрена система, которая: В результате уже в первую версию системы добавляются новые датчики и даже новые контроллеры, например для автоматизации гостевого дома.

  1. Измеряет температуру в 16 точках.
  2. Измеряет влажность в 4 точках.
  3. Измеряет напряжение сети 220В на входе в дом, до стабилизатора.
  4. Измеряет освещенность на улице. Освещенность используется для автоматического включения света.
  5. Измеряет атмосферное давление и делает предсказание погоды по динамике давления.
  6. Детектирует движение в нескольких точках.
  7. Управляет всем светом в гостевом доме. Выключатели превратились в датчики.
  8. Управляет сиренами.
  9. Управляет раздельно 3-мя ступенями электрокотла, сохранив функциональность старой системы. Управляет ТЭНом бойлера.
  10. Проверяет наличие напряжения на котле и ТЭНе бойлера, а также считывает факты включения ТЭНов бойлера. Это важно, так как, во-первых котел имеет обратную связь по температуре теплоносителя и умеет сам отключать ТЭНы, а во вторых в щитке смонтировано двухступенчатое реле ограничения нагрузки, отключающее последовательно бойлер и котел при превышении порога потребления в доме. Эти данные будут в дальнейшем использоваться в алгоритмах умного дома. Но на этом этапе я еще не знал как именно, только чувствовал, что понадобятся.
  11. Считывает факты включения и отключения насоса солнечного контура.
  12. Строит графики температур за неделю, день и час.
  13. Присылает Push-уведомления о разных событиях. События могут быть практически любыми, например, движение на крыльце, превышение температурой заданного порога, пропадание/появление электричества и т.д. Сделано также и оповещение по SMS.
  14. Старая система осталась физически и логически отделенной от новой, хотя в новой частично переиспользуются те же датчики. Старая система сохранила функции охраны и резервной системы мониторинга/управления.

Коробка с антенной — контроллер, круглая «шайба» — сирена, между ними — датчик DHT22, под щитком — датчик движения, слева — 12В блок бесперебойного питания. На фото электрооборудование гостевого дома.

Пример работы системы

В случае изменения показаний или по запросу от сервера, отправляет данные на gateway отдельно по каждому датчику. Каждые 30 секунд контроллер опрашивает датчики температуры. В openHAB’е срабатывает правило, сообщение разбирается, соответствующему item (базовое понятие openHAB) присваивается полученное значение температуры. Gateway принимает данные и отправляет их по USB в openHAB. Если предусмотрена логикой какая-либо реакция, например «если температура упала ниже такого-то уровня», выполняется действие, например «включить ТЭН бойлера». Срабатывает правило настроенное на изменение этого item. Gateway отправляет по радиоканалу команду контроллеру, контроллер получает команду и включает соответствующее реле. Эта команда отправляется по USB в gateway. Примерно так выглядит общая схема взаимодействия компонентов системы. Обратно отправляет подтверждение получения команды.

Температуры измеряются и визуализируются на графиках и в интерфейсе. Итог. Исходные цели достигнуты и даже больше. Видно, что температура воздуха в котельной порой превышает 30 градусов и нужно устанавливать кондиционер. По итогам наблюдений стало понятно, что температура горячей воды никогда не повышается более 55 градусов, а теплоносителя в солнечном контуре – 60, беспокоиться о перегреве не приходится. Далее. Стало удобно управлять отоплением, достаточно касаться виртуальных переключателей на экране смартфона. Но, только если зафиксировано движение, достаточно темно и дом снят с охраны. Свет на крыльце гостевого дома теперь зажигается автоматически. Аналогично внутри дома. А если не снят, то включается сирена и на почту присылается фотография нарушителя. Самым дорогим компонентом системы стал неттоп, около 24т.р. Появились и другие полезные «фишки», но об этом в следующей статье.
Пару слов о ценах. Arduino на AliExpress стоит около 200р, большинство периферийных компонентов (nRF24L01+, датчики) имеют такой же масштаб цены. Если ограничиться мониторингом и управлением, достаточно Raspberry Pi за 2500р. Хотя в дальнейшем и пришлось купить кое-какие лицензии, но об этом в следующей статье. Софт – бесплатен. в целом всё это очень доступно. Т.е.

То, ради чего всего все затевалось.

Дата — 11. График температур, измеряемых на патрубках бойлера. 2018. 05. Температура горячей воды до 38, температура теплоносителя контура отопления до 35 градусов. Видно, что температура в солнечном контуре доходила до 49 градусов. Факты включения насоса солнечного контура зафиксированы на нижнем графике желтым цветом. Все это только за счет Солнца. Другое отопительное оборудование не использовалось.

В том, что сделано, для инженера с широким кругозором нет ничего сложного или непостижимого. Заключение. Но это всё можно освоить, так же как необходимо освоить язык правил в openHAB. Хотя, некоторые специфические навыки, например программирования на C++, для Arduino, нужны. Я побеждаю время с помощью сезонности. Единственный ресурс, которого всегда не хватает для подобных затей – время. Придумываю или получаю «заказ». Летом-осенью думаю, чего еще не хватает в доме, ставшим умным. Весной физически устанавливаю и отлаживаю. Зимними вечерами собираю прототип, программирую, интегрирую с умным домом. Описанный цикл за несколько лет вошел в фазу стабильности. После этого – наслаждаюсь результатом.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[recovery mode] Статистика от владельца Tesla Model S

Автор youtube канала Like Tesla (владеет Tesla Model 3, Tesla Model X) поделилась интересной статистикой, связанной с автомобилей её мамы. Её мама решила продать свою Tesla Model S 85 2013 года, которой она владела 5 лет (просит за неё $39,900). ...

Как оценить качество продукта

Привет Хабр! В ней описывалось про то, какой же хороший у них продукт. Недавно мне попалась на глаза статья про Service Now. Даже показали менеджера среднего звена с микрофоном, которая без цифр что-то говорила (из статьи — "сократило время административного ...