Предыдущая заметка вызвала довольно бурную дискуссию и это обстоятельство убедило меня в необходимости продолжения того, что мы называем «делиться опытом». Итак, мы остановились на том, что после появления в доме альтернативных источников энергии, в первую очередь солнечного коллектора, захотелось измерять параметры, сопровождающие их работу. Например, для того, чтобы видеть, как меняется температура солнечного теплоносителя, не перегревается ли вода в бойлере и т.д. Понятно, что само по себе измерение чего-либо и даже передача этой информации к месту потребления (телеметрия) не увеличивают комфорт или безопасность, поэтому сразу же в «ТЗ» внесен пункт об удаленном управлении различными исполнительными устройствами. В этой статье я не буду приводить листинги кода, детализировать до мелочей все технические решения. Моя цель – показать ход мысли и принятые технические решения, а также их результат. Тому, кто захочет пойти похожим путем всё равно придется самостоятельно решать множество задач.
В 2010г вместе с инвертором/аккумуляторами в доме появился универсальный GSM контроллер-сигнализация российской фирмы RADS Electronics. Это замечательное универсальное устройство использовалось помимо функций сигнализации с оповещением по GSM, еще и для управления светом в гостиной, и, главное, для управления электрическим котлом. Так что контролировать температуру, поддерживать температуру, а также прогревать дом заранее, до приезда, я научился уже давно. Удобство подобных систем совершенно очевидно. Однако, возможности контроллера ограничены, поэтому в новом «ТЗ» изначально закладывалось создание параллельной системы, пусть даже с частично повторяющимися функциями и, естественно, с доступом к информации с датчиков и управлению через Интернет.
Так вырисовались начальные требования:
- Измерять температуру на всех 8 патрубках бойлера и 2 патрубках котла.
- Измерять температуру и влажность воздуха в котельной, где смонтировано оборудование.
- Измерять температуру и влажность воздуха на улице. Чтобы когда-нибудь в будущем реализовать погодозависимое управление отоплением.
- Управлять электрическим котлом, сохранив старую систему. Котел трехступенчатый, с регулировкой температуры нагрева и обратной связью по температуре теплоносителя. Однако, для целей удаленного управления достаточно включать/выключать ступени отопления.
- Управлять ТЭНом бойлера.
- Прокладывать минимум проводов. Не столько потому, чтобы не возиться, сколько потому что отделка в доме уже сделана.
- Иметь удобный интерфейс для управления и работы с показаниями датчиков. Интерфейс должен быть доступен на мобильных устройствах.
На фото — генератор с электростартером. Для зимнего пуска пришлось поставить автомобильный аккумулятор и зарядное устройство. И использовать синтетическое масло.
Всё в том же 2010г в гараже поселился бензиновый генератор. И к нему в скором времени добавился контроллер автоматического запуска, сделанный самостоятельно на базе микроконтроллера Arduino. Контроллер смотрит не только на наличие сети 220В, но и на сигнал с инвертора о разряде аккумуляторов, а сам инвертор обеспечивает автоматический ввод генератора. Всё вместе позволило реализовать достаточно интеллектуальный алгоритм управления генератором. В общем, страха перед использованием микроконтроллеров не было никакого, как в смысле подключения периферии, так и в смысле программирования. В прошлом я много программировал на С/С++.
Требования, в общем-то, простые, если не сказать тривиальные. Существуют тысячи разных способов их реализации. И именно поэтому краеугольным камнем является выбор архитектуры и технологического стека, на котором будет строиться новая система. Здесь как раз важен системный подход, понимание того, что отдельные технические решения должны быть увязаны друг с другом, понимание того, что система, безусловно, будет расширяться дальше, как уже случилось с системой энергоснабжения дома. И еще важно понимание собственных возможностей. Поэтому пришлось гуглить, брать «помощь зала» и «звонок другу».
На фото Arduino Nano и nRF24L01+ c антенной
Смотреть начал с систем на базе широко распространенного стандарта Z-Wave, это в значительной мере повлияло на дальнейшие решения, хотя Z-Wave и был на первых порах отброшен. Поскольку Z-Wave – очевидный выбор под требования, близкие к моим, важно понимать, почему он был отброшен. Во-первых, конечно стоимость одного датчика. А мне только на бойлере в 8 точках измерять температуру надо, каждая точка получается по 3000+ рублей. Во-вторых, форм-фактор стандартных датчиков, не позволяющий применить их на патрубках бойлера. В-третьих, ограниченность выбора систем управления и удаленного доступа, которые к тому же все проприетарные (следует читать: «ограниченные») и платные. Однако, сама идея самоорганизующейся сети с возможностью, как одноранговых связей (ассоциаций) датчик-исполнительное устройство, так и централизованного, сервер-клиент, управления, очень привлекательна. По совету друга вышел на интересный проект, который изначально выглядел как расширение функциональности Z-Wave систем на базе контроллеров Vera, но с использованием DIY-подхода. В проекте использовались Arduino, беспроводные 2.4ГГц трансиверы nRF24L01+ и соответствующая библиотека. Всё вместе как раз то, что нужно под мои требования. Использование Arduino открывает практически безграничные возможности домашней автоматизации за деньги, на порядок (!) меньшие, чем в случае с Z-Wave. Немаловажно также, что Arduino – исключительно стабильная платформа. Контроллер автоматического запуска генератора, собранный когда-то на Arduino, безукоризненно работает уже 7 лет. Учитывая наличие опыта разработки, пайки и программирования, остановился на этом проекте.
И даже пошел дальше. В коде вообще отказался от привязки к Vera. Вместо него выбрал один из рекомендованных автором библиотеки mysensors программных контроллеров. Им, после изучения форумов и сайтов производителей, стал open source проект openHAB. Решающим фактором, помимо открытости, кроссплатформенности, встроенного мощного языка правил, наличия мобильных клиентов, стало следующее заявленное свойство: «a vendor and technology agnostic». Это как раз то, что и нужно системно мыслящему IT-специалисту: возможность расширения системы в будущем, использование компонентов разных производителей и стандартов, при этом наиболее подходящих под конкретные цели. Т.е. с самого начала было понимание, что не всё нужно делать на Arduino и не всё можно в границах Z-Wave. При этом я решил придерживаться централизованной логики управления, что для начала вполне естественно. Т.е. на оконечных устройствах, собираемых на Arduino, будет минимальная бизнес-логика: включение/выключение света от античныхобычных механических выключателей, которые становятся просто датчиками, чтение и преобразование информации с датчиков физических параметров, передача данных на сервер, прием и исполнение команд с сервера. Прямого взаимодействия узлов сети устройств пока не планирую. Вся реальная бизнес-логика управления – на правилах openHAB. Теперь остались сущие мелочи – выбрать аппаратную платформу и операционную систему под серверную часть, под openHAB.
Многие DIY-щики под openHAB выбирают Raspberry Pi. И это отличное решение, экономичное, компактное и бесшумное. Однако, мне показалось неправильным ограничивать себя в вычислительной мощности, потому что сразу решил использовать будущий сервер как многофункциональное устройство, например, на нем же захотел развернуть медиацентр Kodi и, возможно в будущем, еще что-то, например, программный видеорегистратор. Забегая вперед скажу, что в итоге Kodi интегрирован с умным домом, при запуске видео – гаснет свет, при остановке — зажигается. Да и видеорегистратор тоже появился и тоже интегрирован. При этом особых требований к мультимедиа-компонентам у меня нет, достаточно чтобы на сервере были HDMI и S/PDIF. В общем, осенью 2015 года выбор пал на безвентиляторный неттоп от Hystou (см. на AliExpress): Intel Core i7, 8GB, 256GB SSD, 8 USB-портов, включая 4 3.0, 2 LAN, WiFi, 2 HDMI, S/PDIF, Card reader в общем всё, что нужно для счастья DIY-щика. Стоил он тогда около 24 т.р. О выборе ни разу не пожалел, хотя должен сказать, что WiFi у него работает не очень стабильно. Но, последовавший за всем этим опыт уверенно говорит: везде, где можно проложить провода – прокладывать провода. Радиоканал, независимо от стандарта и частоты (WiFi, Z-Wave, 433МГц, 869МГц, 2.4ГГц и т.д.) всегда хуже, чем провод. Поэтому неттоп в итоге подключен к домашней LAN проводом. И на нем поселилось еще несколько различных систем.
Что касается ОС для сервера, то я бы рекомендовал стабильность и предсказуемость. Этим свойством обладают дистрибутивы Linux с большими community. Мне — привычнее Ubuntu. Хотя, благодаря кроссплатформенности, всё можно сделать и на Windows.
Итак, архитектура и стек выбраны. Действуем.
Задача 1. Выбрать датчики и исполнительные устройства. Температуру теплоносителей и воды будем замерять на патрубках бойлера и котла. Для этого берем 1-wire датчики DS18B20 в металлическом герметичном корпусе, их удобно крепить непосредственно на патрубках, снаружи. А сами патрубки с датчиками сверху прикрываем поролоновой теплоизоляцией для труб. Когда однотипных датчиков много, шина 1-wire очень удобна. Для измерения температуры воздуха и влажности в котельной и на улице выбираем DHT22, просто потому что это стандартный выбор DIY. Управлять котлом раздельно по ступеням – с помощью обычных пятивольтовых механических реле, также привычных DIY-щикам. Важно заметить, что эти реле подключаются параллельно выключателям ступеней на котле, а не реле ТЭНов, которые управляются автоматикой котла. Вся выбранная периферия либо бесхитростно программируется напрямую, как реле, например, либо имеет соответствующие библиотеки для Arduino, как 1-wire/DS18B20/DHT22. Никаких сложностей.
На фото бойлер 300л. Видно, что к каждому патрубку подходит черный провод с датчиком на конце, в белой коробке они объединяются и общий белый провод 1-wire идет к контроллеру.
Задача 2. Обмен данными и командами с openHAB. Пришлось немного повозиться, поскольку с openHAB еще не был «на ты». Архитектура mysensors подразумевает наличие gateway (шлюза) для подключения к центральному контроллеру/серверу, т.е. к openHAB. 
Cам gateway – физически отдельный контроллер на Arduino/nRF24L01+ и может подключаться к серверу по LAN/WiFi или Serial. Поскольку я в начале пути – выбираю Serial и размещаю gateway рядом с сервером. Gateway служит для маршрутизации сообщений, передаваемых в сети mysensors через gateway и непосредственного обмена с центральным контроллером, openHAB. Сообщения mysensors имеют фиксированный формат и легко парсятся. Добавляем в openHAB binding Serial для подключения gateway по USB и пишем правило для парсинга сообщений устройств в сети mysensors, получаемых по USB от gateway. За основу правила openHAB, разбирающего сообщения, взят код, найденный на форуме mysensors. Далее пишем правила для исполнительных устройств – реле управления котлом, ТЭНом бойлера, светом и т.д.
На фото – gateway, маленькая коричневая коробка с антенной на аудиоколонке.
openHAB – решение открытое, расширяется с помощью комьюнити за счет разработки bindings к конкретным устройствам, с которыми openHAB будет взаимодействовать. Например, для взаимодействия с устройствами по USB есть binding Serial. Аналогично для других устройств или протоколов, например Modbus, NTP, HTTP, Squeezebox, Kodi/XBMC, Z-Wave, ZigBee, Nest и так далее. Сам я поучаствовал в разработке в качестве активного тестировщика Modbus binding.
Пока возился с подключением gateway к серверу openHAB, решил доработать код gateway (и сам gateway), взятый с mysensors.org и добавить к нему датчик температуры и влажности DHT22 и датчик атмосферного давления BMP180, а заодно нашел исходный код для предсказания погоды по динамике атмосферного давления. Все эти измерения и предсказания передаем в openHAB.
На фото gateway изнутри. На белом проводе — DHT22, плата со свободными pin'ами — Arduino, справа внизу — nRF24L01+ и BMP180.
Задача 3. Интерфейс и удаленный доступ. openHAB – полностью настраиваемая система, включая разметку интерфейса. И эта разметка – единая, как для обычного доступа через браузер, так и через мобильное приложение. Универсальная разметка, конечно, не может быть идеальной, но на смартфоне смотрится хорошо, а это главное. Остается решить, как вне локальной сети получить доступ к серверу openHAB. Во-первых, можно (и что важно, необязательно) использовать облако myopenhab.org. Сервер openHAB подключается к облаку напрямую с помощью специального binding. Это решение самое простое и обеспечивает полную функциональность управления системой, кроме разве что передачи видео с ip-камер. Во-вторых, для тех, кто не любит облака, а я отношусь к их числу, есть обычные средства удаленного доступа, например комбинация VPN+VNC и т.д. Раскрывать детали по понятным соображениям не буду, тем более что этот вопрос не относится напрямую к теме статьи. Замечу только, что мобильный клиент openHAB имеет настройку на два адреса. По первому идет, если видит по этому адресу сервер openHAB, по второму – если не видит. Это очень удобная особенность интерфейса. Например, в качестве второго адреса можно указать облачный и тогда openHAB доступен всегда без дополнительных манипуляций с подключением VPN. Или указать виртуальный адрес, полученный с помощью какого-либо VPN-решения. Или еще как-то.
| Начальный экран интерфейса | Скроллинг вниз стартового экрана | Раскрытый пункт меню «Свет» |
|---|---|---|
 |
 |
 |
Разметка позволяет делать условное форматирование, например, выделять красным температуру при превышении ею заданного в разметке значения. Некоторые пункты раскрываются при нажатии, например «Отопление», «Свет», «Сирена» и т.д.
Вот вроде и всё. Берем в руки по очереди то паяльник, то клавиатуру. И постепенно первая версия системы обретает очертания. Как известно, аппетит приходит во время еды. В результате уже в первую версию системы добавляются новые датчики и даже новые контроллеры, например для автоматизации гостевого дома. В итоге на первом этапе внедрена система, которая:
- Измеряет температуру в 16 точках.
- Измеряет влажность в 4 точках.
- Измеряет напряжение сети 220В на входе в дом, до стабилизатора.
- Измеряет освещенность на улице. Освещенность используется для автоматического включения света.
- Измеряет атмосферное давление и делает предсказание погоды по динамике давления.
- Детектирует движение в нескольких точках.
- Управляет всем светом в гостевом доме. Выключатели превратились в датчики.
- Управляет сиренами.
- Управляет раздельно 3-мя ступенями электрокотла, сохранив функциональность старой системы. Управляет ТЭНом бойлера.
- Проверяет наличие напряжения на котле и ТЭНе бойлера, а также считывает факты включения ТЭНов бойлера. Это важно, так как, во-первых котел имеет обратную связь по температуре теплоносителя и умеет сам отключать ТЭНы, а во вторых в щитке смонтировано двухступенчатое реле ограничения нагрузки, отключающее последовательно бойлер и котел при превышении порога потребления в доме. Эти данные будут в дальнейшем использоваться в алгоритмах умного дома. Но на этом этапе я еще не знал как именно, только чувствовал, что понадобятся.
- Считывает факты включения и отключения насоса солнечного контура.
- Строит графики температур за неделю, день и час.
- Присылает Push-уведомления о разных событиях. События могут быть практически любыми, например, движение на крыльце, превышение температурой заданного порога, пропадание/появление электричества и т.д. Сделано также и оповещение по SMS.
- Старая система осталась физически и логически отделенной от новой, хотя в новой частично переиспользуются те же датчики. Старая система сохранила функции охраны и резервной системы мониторинга/управления.
На фото электрооборудование гостевого дома. Коробка с антенной — контроллер, круглая «шайба» — сирена, между ними — датчик DHT22, под щитком — датчик движения, слева — 12В блок бесперебойного питания.
Каждые 30 секунд контроллер опрашивает датчики температуры. В случае изменения показаний или по запросу от сервера, отправляет данные на gateway отдельно по каждому датчику. Gateway принимает данные и отправляет их по USB в openHAB. В openHAB’е срабатывает правило, сообщение разбирается, соответствующему item (базовое понятие openHAB) присваивается полученное значение температуры. Срабатывает правило настроенное на изменение этого item. Если предусмотрена логикой какая-либо реакция, например «если температура упала ниже такого-то уровня», выполняется действие, например «включить ТЭН бойлера». Эта команда отправляется по USB в gateway. Gateway отправляет по радиоканалу команду контроллеру, контроллер получает команду и включает соответствующее реле. Обратно отправляет подтверждение получения команды. Примерно так выглядит общая схема взаимодействия компонентов системы.
Итог. Исходные цели достигнуты и даже больше. Температуры измеряются и визуализируются на графиках и в интерфейсе. По итогам наблюдений стало понятно, что температура горячей воды никогда не повышается более 55 градусов, а теплоносителя в солнечном контуре – 60, беспокоиться о перегреве не приходится. Видно, что температура воздуха в котельной порой превышает 30 градусов и нужно устанавливать кондиционер. Стало удобно управлять отоплением, достаточно касаться виртуальных переключателей на экране смартфона. Далее. Свет на крыльце гостевого дома теперь зажигается автоматически. Но, только если зафиксировано движение, достаточно темно и дом снят с охраны. А если не снят, то включается сирена и на почту присылается фотография нарушителя. Аналогично внутри дома. Появились и другие полезные «фишки», но об этом в следующей статье.
Пару слов о ценах. Самым дорогим компонентом системы стал неттоп, около 24т.р. Если ограничиться мониторингом и управлением, достаточно Raspberry Pi за 2500р. Arduino на AliExpress стоит около 200р, большинство периферийных компонентов (nRF24L01+, датчики) имеют такой же масштаб цены. Софт – бесплатен. Хотя в дальнейшем и пришлось купить кое-какие лицензии, но об этом в следующей статье. Т.е. в целом всё это очень доступно.
График температур, измеряемых на патрубках бойлера. Дата — 11.05.2018. Видно, что температура в солнечном контуре доходила до 49 градусов. Температура горячей воды до 38, температура теплоносителя контура отопления до 35 градусов. Все это только за счет Солнца. Факты включения насоса солнечного контура зафиксированы на нижнем графике желтым цветом. Другое отопительное оборудование не использовалось. 
Заключение. В том, что сделано, для инженера с широким кругозором нет ничего сложного или непостижимого. Хотя, некоторые специфические навыки, например программирования на C++, для Arduino, нужны. Но это всё можно освоить, так же как необходимо освоить язык правил в openHAB. Единственный ресурс, которого всегда не хватает для подобных затей – время. Я побеждаю время с помощью сезонности. Летом-осенью думаю, чего еще не хватает в доме, ставшим умным. Придумываю или получаю «заказ». Зимними вечерами собираю прототип, программирую, интегрирую с умным домом. Весной физически устанавливаю и отлаживаю. После этого – наслаждаюсь результатом. Описанный цикл за несколько лет вошел в фазу стабильности.
Автор: Medox
