Доброго дня!
Мы с вами поговорили в предыдущих частях (1, 2, 3), чем же отличается умный дом от неумного, что он умеет и какие принципы принять во внимание перед началом его "проектирования и строительства".
В этой статье мы начнем проектировать наш умный дом. И, как обычный дом начинается с эскизного проекта, так же и мы начнем с эскиза нашего будущего дома умного.
Как и в случае с началом проектирования дома или выбора квартиры, мы должны себе ответить на основные вопросы, которые, собственно, во многом и определят как образ, так и базовые подходы к проектированию и последующему строительству.
Какие же это вопросы? Давайте попробую их поставить:
- Насколько Вам интересны и важны все те функции умных домов, что описаны ранее? Какие функции Вы хотели бы иметь обязательно (или очень стараться, чтобы они были), какие относите к опциональным, а какие не нужны вовсе?
- Сколько личного времени Вы готовы посветить реализации своего проекта? Здесь важно быть честным. Если Вы в деталях разбираетесь в технологиях и процессе строительства своего "каменного дома", проводите достаточно времени на стройплощадке и контролируете то, что там происходит - вероятно, Вы сможете "погрузиться" и в эту область. Если же Ваша реальность такова: заплатил деньги на старте и пришел доплачивать на финише - не нужно себя обманывать. С умным домом у Вас тоже не будет возможностей разбираться. Ответьте на первый вопрос и идите к профессиональным инсталляторам (или попросите найти таковых своего дизайнера/архитектора/прораба). Дальше Вам почитать тоже полезно, но лишь для целей систематизации собственного представления о предмете.
- Собираетесь ли Вы в будущем (гипотетически) рассматривать Ваш дом (квартиру) как объект продажи? Если да, больше ориентируйтесь на промышленные решения, меньше - на самосбор (либо применяйте DIY-решения так, чтобы их можно было выкинуть без ущерба для функционирования жилища). Потому как не факт, что следующий за Вами владелец захочет разбираться в Ваших сценариях и кучке железок, а Вам вряд ли интересно оказывать пожизненный постпродажный сервис.
- Ну и, на конец, насколько Вы готовы рассматривать стандартные сценарии (которые уже обкатаны на множестве проектов) с минимальной кастомизацией или же Вам интересно составить свой личный и неповторимый "умный дом", также же как Вы заказывали свой личный и неповторимый архитектурный проект основного дома. И если Вы серьезно хотите уникальность - будьте готовы оплатить эту работу не менее щедро, чем оплачивали индивидуальный архитектурный проект. Либо будьте готовы потратить свое время в самостоятельном проектировании. Второй путь я бы не рекомендовал настойчиво, но мои статьи Вам помогут, ежели что и в этом.
И так, предположим, Вы ответили на эти вопросы так, что Вам потребовались дальнейшие детали - как же спроектировать свой умный дом. Ниже я расскажу об основных принципах и подходах, которые Вам в этом помогут. Сразу оговорюсь, я не буду (по крайней мере в моменте не планирую) сравнивать досконально все виды решений и протоколов. Просто поверьте, что я сравнил уже многие из них и применил в своем опыте. Поэтому начну сразу, как говориться, с конца. Даже если мои выводы кому-то покажутся спорными. Хотя я и постараюсь приводить минимальные обоснования каждого своего выбора. Поехали..
Первое, с чего нужно начать, как уже отметил выше, это составить принципиальную архитектурную схему Вашего умного дома. Начать, как уже, наверняка догадались - с функций (вы их перечислили, когда отвечали на 1 вопрос).
Следующее, что необходимо, это для класса "основных функций" ("жизнеобеспечивающих") - подобрать решения (компоненты), на базе которых они будут реализованы. Давайте рассмотрим классы решений под типовые основные функции нашего "умного дома".
- Общее управление ("центральный мозг").
Как уже отмечал в предыдущей статье - нужно понять масштаб Вашего объекта. Для большого коттеджа или квартиры (более 150м2), где будет использоваться хотя бы пара из систем: централизованное управление отоплением, централизованная система вентиляции и/или кондиционирования, "умное освещение" - я бы рекомендовал надежное решение с развитыми функциями программирования и настроек. И тогда на подобном решении можно вполне реализовывать функции "жизнеобеспечения".
Лично я после длительного анализа остановил выбор на системе Tridium (на базе фреймворка Niagara), в настоящее время принадлежащая известному концерну Honeywell. В интернете можно прочитать достаточно статей на тему его возможностей (на английском). Здесь лишь отмечу множество инсталляций по всему миру, большой комьюнити профессионалов и энтузиастов, которое позволит Вам не остаться один-на один со своей проблемой. И, главное, развитый интерфейс программирования, освоить который интуитивно может любой человек, а не обязательно программист.
Система имеет драйверы сопряжения (совместимость) с большинством промышленных протоколов: KNX, Modbus (TCP/RTU), Lonworks, Z-wave, MQTT (далее будет понятно, почему это важно) и десятки других.
При всем этом система выполнена в виде готового "аплайнса" (фактически промышленное исполнение), не имеет в своем составе движущихся частей и потому крайне надежная.
В общем, на мой взгляд, система как нельзя лучше подходит на роль центральной, а также обеспечивающей алгоритмы реализации большинства основных функций. К минусам можно отнести стоимость. Это несколько единиц тысяч евро. Точнее, как к минусам, для большого дома Вы же за котел наверняка заплатили дороже. А сколько к нему стоит система управления, приценивались? То то.
Для небольших же объектов, вполне подойдут решения из DIY-сегментов. Но в этом случае задача "центрального контроллера" - это не выполнение основных функций, а лишь интеграция между отдельными компонентами, решающими "жизнеобеспечивающие" функции - в целях, например, сценарного управления (т.е. по факту это вспомогательная задача). Несмотря на то, что мы выше договорились рассмотреть решения для целей выполнения "основных функций" умного дома, все же отвлечемся, раз заговорили. Так вот, такой "центральный мозг" может быть реализован как на opensource (Home Assistant, Node Red), так и на "коммерческих" решениях типа Vera, Control4, Crestron, Iridium Server, Wirenboard и много других. Основной критерий подбора, как я писал ранее, это наличие нужных Вам протоколов совместимости (в opensource их больше как правило), а также дружелюбность и гибкость интерфейсов настройки (в коммерческих вариантах обычно этот параметр превалирует). В общем, у меня нет здесь универсального совета. Я лично использовал и Vera Edge, и Home Assistant в связке с Node Red, и OpenHAB, и Crestron, и Wirenboard, и iRidium. Каждому из Вас следует найти баланс между собственным потраченным временем на освоение и настройку и ценой решения включая работу инсталлятора (если применимо). В моем случае время - это время проведенное за хобби, а для кого-то лишь обременение. В общем, изучайте, сравнивайте, щупайте и решайте!
Единственная моя рекомендация: даже для opensource-решений старайтесь использовать embedded-аппаратные платформы (вроде Wirenboard, Raspberry PI и т.п.) - это существенно повысит надежность по сравнению с установкой на старом компьютере. - Управление отоплением (имеем ввиду газовое, электрическое или иное отопление с центральным теплогенератором - котлом). В случае использования электрических конвекторов в помещениях - подход будет отличаться.
Здесь я бы рекомендовал выбирать котел, имеющий поддержку управления со стороны внешней BMS-системы. Крайне желательно, чтобы это был промышленный стандартный и понятный протокол, при чем желательно - без необходимости закупки дорогостоящих шлюзов (ведь, например, розничная цена шлюза LON для котла Buderus составляет порядка 1k евро). Я для себя выбрал котлы Vaillaint с платой управления 0-10В стоимостью порядка 50 евро. Эта же плата позволяет отправлять аварийный сигнал от котла в сторону системы управления через реле замыкания контакта. Но это для случая с мощной "центральной" системой управления (Tridium). В случае, же небольших инсталляций, подойдет любой котел со своим штатным термостатом, но желательно, чтобы он тоже умел отправлять сигналы во "внешний мир". Для маленького дома я применил котел Buderus с управлением самым простым термостатом (однозонным) с поддержкой протокола Opentherm. К сожалению, opentherm нельзя назвать промышленным стандартом, но у нас есть российская железка Zont, которая умеет "подменять" стандартный термостат или вставать между стандартным термостатом и котлом, добавляя "ума" в нашу систему отопления.
В случае же, если отопление осуществляется децентрализовано путем электроконвекторов, я рекомендую использовать выделенные линии электропроводки для подключения батарей с заведением на силовые электронноуправляемые реле или пускатели. При этом можно ставить как отдельные термостаты в каждом помещении, так и пользоваться одним в самом большом помещении дома - для грубого задания температуры, а точную температуру выставлять "вручную" на самих конвекторах. Однако же последнее решение вряд ли можно отнести к шибко умному, скорее - к крайне бюджетному. - Система кондиционирования и вентиляции. Для больших объемов - все просто. И дорого ) За счет оборудования, конечно. Я использовал варианты как с одним канальным кондиционером в центральной системе вентиляции (такая система сравнительно недорогая, но не позволяет, что логично, точно управлять температурой в отдельных помещениях), так и полноценную VRF-систему. Для первого случая вполне подошло управление все теми же 0-10В и сухими контактами на Tridium (или на modbus-контроллер с такими входами, подключенному к Tridium). Для VRF-системы (Mitsubishi), имеющей свой собственный протокол "общения" между блоками (Mbus) пришлось заказать шлюз в промышленную сеть стандарта LON, которая, в свою очередь терминируется... правильно - на Tridium. Можно было вместо шлюза использовать "родные" пульты управления Mitsubishi в каждом помещении, но тогда бы нарушился принцип "централизации мозга" умного дома. И пришлось бы ставить две панели управления в комнатах - одну для отопления, а одну - для кондиционирования.. Что удивительно, я много где такое видел для VRF-инсталляций, хотя стоимость шлюза невелика по сравнению со стоимостью самих блоков. В моем же случае использована единая панелька для управления в каждом помещении, совмещающая в себе функции датчика температуры, уставки целевой температуры.. А заодно и активирующая разные сценарии.. Но об этом далее.
Бытовыми же кондиционерами можно управлять как через шлюзы в промышленные сети (например, в KNX, но стоить такое решение будет чуть ли не дороже самого кондиционера), так и подобрать очевидно менее надежный вариант с инфракрасным управлением (фактически это "подмена" стандартного пульта кондиционера). Такие есть, например, для бюджетной Z-Wave сети, стоят тоже недорого. Z-wave нельзя отнести к "промышленным" решениям, скажете Вы? И будете правы, +1 за внимательность. Но и управление бытовыми кондиционерами мы договорились не рассматривать среди основных функций умного дома. Извините, что опять "смешал" разделы. - Освещение. Если не включать варианты с экзотикой (типа lonworks) и DIY-варианты (типа IP-реле или Mega-D - помните мой совет не использовать DYI в основных функциях, чтобы не получить проблемы при продаже) - распространены и рекомендованы мною к использованию два варианта: (1) DALI в связке с KNX для больших объектов (2) "обычное" освещение, но "интеллектуально обогащенное" Z-wave выключателями - для небольших объектов. Z-wave как беспроводной протокол нельзя отнести к "промышленным" (хотя на небольших площадях вполне себе неплохо работает), за то у такого решения есть существенный плюс - такой объект можно вполне себе вернуть в привычное "неумное" состояние, просто убрав из подрозетников Z-wave контроллеры. Учтите только, что в подразетник должен заходить не только "фазовый" провод, но и "нейтраль" (хотя, по-другому уже лет 50 как никто и не делает).
- Контроль протечек. Здесь я предлагаю не изобретать велосипед, а выбрать одно из решений известных производителей, ориентированных на решение данной задачи. Благо стоят они недорого, а аварийный сигнал от них - завести через тот же "сухой контакт" на "центральный мозг". Можно, конечно, отдельно закупить датчики и электрокраны, но по деньгам выйдет не сильно дешевле (как бы не дороже), но придется самому писать логику работы, включая периодический поворот и тестирование кранов. Краны с обратной связью недешевы, в общем, на мой взгляд, оно того не стоит.
То же рассуждение касается вопросов выбора охранной сигнализации (при выборе производителя важно учитывать совместимость с охранным пультом вашего ЧОП), выбора системы автополива, видеорегистратора.. Когда "профильные" решения вполне доступны по цене, а их функционал настолько отлажен, что пытаться его "изобрести" заново в своей системе автоматизации - не имеет никакого экономического смысла. Единственно, на что стоит дополнительно обращать внимание при выборе, это то, каким образом можно интегрировать эти решения с Вашей центральной системой автоматизации. Ведь, например, удобно, чтобы датчики движения от сигнализации - также использовались системой умного дома для включения света по событию движения, или, наоборот, длительное отсутствие движения переводило дом в режим экономии освещения или "ночной режим", а постановка на сигнализацию активировала бы одну из программ энергосбережения здания. Про варианты интеграционных механизмов немного поговорим ниже. - IP-сеть. Здесь я рекомендую временно отказаться от "именитых" производителей домашних комбайнов "все в одном" типа Zyxel, а "разориться" на профессиональное сетевое оборудование (можно даже купленное на Авито). Это Cisco, Ubiquity и что-то подобное, что Вам посоветует знакомый айтишник. Не обязательно всю локальную сеть строить с его использованием, но коммутатор, который "соберет" на себе все оборудование управления - я рекомендую выбрать надежный. Так же стоит сеть управления отделить от сети, куда подключаются Ваши персональные компьютеры-ноутбуки-телефоны-телевизоры. Сделать это можно либо физическим разнесением на разные интерфейсы маршрутизатора с отдельным физическим сетевым коммутатором, либо разделить на уровне виртуальных сабинтерфейсов VLAN на маршрутизаторе и соответствующих портах коммутатора. В общем, кто понял - тот сделает, кто не понял - пригласит специалиста либо погуглит сам в интернете.
И так, я перечислил базовые "основные функции" умного дома и указал на принципы подбора конкретных решений для их реализации. Настало время поговорить про интеграцию различных "специальных" решений - в "центральный мозг" умного дома, а через него - и между собой, для целей сплошного контроля и реализации сложных сценариев управления.
Выше мы упомянули о таком способе "интеграции" как сухой контакт и сигнал 0-10В. Это самые древние и надежные способы, принцип работы которых подчинены только одному закону - закону Ома. Как правило любое промышленное оборудование или "в базе" или за небольшую доплату имеет возможность такого взаимодействия. Принцип его не нужно лишний раз объяснять: замыкание/размыкание контакта означает бинарный сигнал (это может быть передача понятного статуса чего-либо от одной стороны к другой либо, наоборот, задание сигнала на какой-либо сценарий, например, сигнал на включение). Сигнал 0-10В служит для кодирования цифрового значения через уровень напряжения и таблицу его соответствия значениям искомого показателя (например, % открытия трехходового крана). Аналогичным образом возможно как задание сигнала (через аналоговый выход на контроллере управления), так и считывание сигнала (через аналоговый вход). Аналогичные по классу задачи решают сигналы 0-1В, 1-10В, 4-20мА - все эти разновидности разбираются исключительно опираясь на знание законов Ома.
Логично рассудить, что "интеграция" 0-10В не является полноценной интеграцией с расширенным информационным обменом, а служит лишь для целей передачи заранее ожидаемых сигналов (хотя и этого во многих случаях достаточно для решения задачи). Следующим уровнем интеграции является информационный обмен с использованием заданного протокола информационного обмена. Этих протоколов великое множество, но широко распространены следующие:
- KNX (в основном применяется для автоматизации освещения и управления освещением/климатом в помешениях). Устройства с поддержкой данного протокола отличает высокая цена, хотя уже появились на рынке доступные китайские производители (HDL, GVS) делающие достойные и недорогие устройства. Причина высокой стоимости в необходимости сертификации каждого устройства производителем - в ассоциации KNX. Связь между устройствами осуществляется по отдельно проложенной шине (витая пара 0.8мм2)
- DALI (как правило используется в связке с KNX через шлюз и используется для управления исключительно осветительными приборами, т.к. в реализации на порядок дешевле инсталляций на чистом KNX). Совместимые устройства можно купить на aliexpress за "2 копейки". Протокол простой и понятный, не сильно продвинутый, но для управления светом больше и не надо (вкл/выкл, RGB+температура, да управление группами) - более сложное управление (типа сцен и сценариев) осуществляется через шлюз со стороны KNX. Удобно, что сигнал DALI может передаваться по жилам, идущим по соседству с силовыми жилами в одном кабеле (обычно используется 5-жильный силовой кабель вместо 3-жильного). Исполнительные устройства (реле, диммеры), как правило, размещаются под потолком в непосредственной близости от осветительного прибора (по аналогии с тем, как мы делаем с трансформаторами для галогенных 12В ламп) - в большинстве случаев это удобно, хотя есть и устройства для монтажа на DIN-рейку в щите. Таким образом, как и в случае с классическим освещением, на один силовой кабель вешается несколько групп светильников (например, все группы одного помещения или даже несколько смежных помещений) - в отличие от KNX, когда каждая группа светильников имеет свою линию питания, уходящую в электрический щиток на актуатор (исполнительное реле). С точки зрения выключателей - это также могут быть как DALI-выключатели, так и конвертеры из DALI в сухой контакт для подключения классического выключателя на его размыкание. Кроме того, можно использовать и KNX-выключатели или панели управления с сопряжением KNX-сети с сетью DALI через шлюз (в большинстве случаев такой шлюз присутствует в проектах).
- modbus (RTU - по медной паре или TCP - через IP-сеть). Достаточно старый промышленный протокол обмена, который отличает высокая надежность передачи сигналов, но невысокая скорость (для RTU). Контроллеры с поддержкой modbus широко распространены и достаточно дешевы по сравнению с иными промышленными стандартами. Этот протокол удобно использовать для завязки между собой аналоговых "входов" и "выходов" (беспотенциальные контакты, 0-10В), подключенных к системе управления. В домашних инсталляциях датчики и иное оборудование с таким протоколом встречается редко, т.к. комнатные датчики с modbus-интерфейсом хоть и дешевы, но обычно весьма "страшные" с точки зрения дизайна. А внутри котельной удобнее и дешевле использовать датчики 0-10В (2-20мА), заведенные на аналоговые выходы modbus-контроллера.
- Bacnet. Не сильно распространен, используется в основном для "общения" теплового оборудования в котельной. В частных проектах экзотика.
- Lonworks. Еще один промышленный протокол обмена между оборудованием. Претендует на звание универсального, но достаточно дорогой и слабо распространен. При автоматизации больших зданий встречаются даже системы управления освещением на базе этого протокола, но в частном секторе не рекомендую его применять без четкого понимания "зачем".
- 1-wire ранее распространенный, но давно устаревший протокол. Даже не рассматриваем. Несмотря на крайнюю дешевизну совместимых устройств, используют их уже лишь фанаты-электронщики в супер бюджетных "самоделках".
- есть еще много проприетарных стандартов обмена, совместимых исключительно внутри одного производителя (E-bus Vaillant, Mbus Mitsubishi, вендороспецифичные реализации Opentherm и многие другие), их рассматривать бессмысленно, реализовать на их базе целиком проект не получится ввиду ограниченности совместимых устройств
Все перечисленные "промышленные" стандарты отличает высокая надежность передачи информации, но, при этом - низкая скорость (хотя в большинстве случаев для частных инсталляций ее достаточно). И, конечно, это их "закрытость" от нас - современных пользователей яблочных устройств и прочих самсунгов! С телефона в такие сети не подключишься и через интернет не залезешь - нужен специальный шлюз. И несмотря на иронию - это их плюс. Действительно, пользователю лучше не пытаться через свой смартфон общаться напрямую с котлом и кондиционером. Взаимодействие между устройствами, подключенными к подобным сетям - не должно выходить за рамки контроллера управления "умным домом". И там уже все должно быть четко и аккуратно, чтобы не было такого, что "я нажала и все пропало".
Но что делать нам, привыкшим к глянцевым экранам и не расстающимся с ними даже ночью? Мы хотим приказать Сири или Алисе поставить фильм или поменять температуру в гостиной, хотим чтобы стиральная машина напоминала нам о завершении программы стирки, а закипевший чайник - звал к столу!
Для подобных целей и для множества появившихся внезапно поумневших устройств (от холодильников до вешалок) умные люди придумали новый протокол обмена, который в настоящее время стал стандартом де-факто. Это MQTT (Message Queuing Telemetry Transport). Данный протокол работает поверх IP-сети и как раз предназначен для информационного обмена между множеством умных устройств дома, так называемых сейчас IoT (internet of things).
Еще недавно, данного протокола чурались "промышленные" решения, что понятно, но, к счастью, в последнее время все больше и больше производителей видят в IoT будущее и включают поддержку этого протокола в свои решения. В частности Tridium начиная с версии 4 своего Niagara Framework имеет возможность принимать и отправлять данные по этому протоколу. Этот протокол абсолютно гибкий, что означает, что каждый производитель или даже пользователь может определить, какими данными и в каком формате он решит обмениваться.
Подчеркну, что этот протокол в качестве основного используют разные "оконечные" умные устройства типа лампочек и кофеварок, промышленное оборудование котельных, конечно не рассматривает (по крайней мере пока) его в качестве опорного. Но для целей построения пользовательских интерфейсов, а также сопряжения множества оборудования, выполняющего вспомогательные функции умного дома - данный протокол крайне удобно использовать в качестве базового. И все больше устройств и контроллеров заявляют о его поддержке. Именно поэтому поддержка данного протокола крайне желательна и даже важна - на выбранном нами "центральном мозге" умного дома.
Таким образом, использование протокола MQTT крайне рекомендовано для применения при интеграции вспомогательных систем умного дома.
Но об этом мы поговорим в другой статье. Ведь тема реализации вспомогательных функций умного дома настолько широка и дискуссионна, что охватить ее будет непросто! Но попробуем... что ж, поехали!
