В результате проделанной работы по созданию системы домашней автоматизации с применением Raspberry Pi сложилась ее определенная структура с возможностью дальнейшего наращивания и конфигурирования. Обращаю ваше внимание - здесь не предлагается некая завершенная система, которую нужно пытаться реализовать «один в один». Наша система домашней автоматизации с применением Raspberry Pi – это своеобразный «конструктор», используя который с помощью отдельных «кубиков» вы сможете построить требуемую вам конфигурацию.
Итак, начнем со структурной схемы системы, показанной на рис.1:
Рис.1
Система домашней автоматизации с применением в качестве центрального сервера Raspberry Pi строится по централизованно-распределенному принципу, в котором соответственно можно выделить два основных сегмента системы – централизованный и распределенный.
Централизованный сегмент системы – это различные датчики, контроллеры, исполнительные устройства, подключаемые непосредственно к портам GPIO Raspberry Pi по шинам 1-wire, I2C, SPI.
Распределенный сегмент – это сеть территориально распределенных контроллеров, подключаемых к серверу по последовательному интерфейсу RS485. Длина шины RS485 может составлять 1200 метров и выполняется «витой парой». Если для шины RS485 применяется стандартный сетевой кабель типа UTP-5e, то оставшиеся свободные пары можно использовать для подвода питания +12В к контроллерам.
В распределенном сегменте необходимо выделить отдельный «подсегмент», который представляет собой радиомодуль, управляющий радиоконтроллерами и принимающий информацию от радиодатчиков и радиопультов. В принципе, его можно было бы отнести и к централизованному сегменту. Но учитывая то, что он взаимодействует с Raspberry Pi через интерфейс RS485 и таких контроллеров на шине может быть несколько (для охвата большой зоны установленных в разных частях дома), более уместно будет считать радиомодули все же составляющими элементами распределенной части системы.
В зависимости от поставленных целей и задач, вы можете использовать только необходимые вам сегменты системы и их составляющие. Например, при автоматизации квартиры или небольшого дома возможно использование только централизованного сегмента. При таком построении все силовые и слаботочные коммуникации сводятся в один коммутационный шкаф, в котором установлен Raspberry Pi. А вот при автоматизации больших объемов имеет смысл использовать распределенный сегмент. В таком случае в каждом отдельном помещении устанавливается контроллер, на который подключаются датчики и исполнительные устройства данного помещения. Контроллер в свою очередь соединяется с центральным сервером Raspberry Pi через интерфейс RS485. Применение контроллеров позволяет сократить количество и длину силовых и слаботочных коммуникаций, т.к. они будут сгруппированы только в пределах одного помещения, а не протянуты по всему дому. Кроме того, в случае выхода из строя сервера, сохраняется локальное (местное) управление и мониторинг.
Перейдем к более детальному рассмотрению структурной схемы домашней автоматизации. К централизованному сегменту системы относятся:
- шина 1-wire с подключенными к ней датчиками DS18B20;
- шина I2C с подключенными к ней датчиком давления и температуры ВМР085 и часами реального времени DS1307;
- контроллер с двумя релейными выходами (применено готовое изделие);
- радиомодуль, принимающий сигналы от пультов, датчиков движения, протечки воды, пожара и т.д.и взаимодействующий с радиоконтроллерами (например, радиоконтроллер управления кондиционером или управления освещением).
В отличие от пилотной версии системы домашней автоматизации, все контроллеры с интерфейсом RS485 вместо нестандартного «ASCII-подобного» протокола сейчас работают по стандартному протоколу Modbus RTU.
Для обеспечения взаимодействия оператора с системой домашней автоматизации не требуется установки никакого дополнительного программного обеспечения на компьютер, планшет или смартфон – доступ к системе осуществляется через web-браузер с любого устройства. С целью обеспечения безопасности доступ авторизированный – т.е. через ввод логина и пароля пользователя.
Интерфейс пользователя – это отдельные web-страницы, которые хранятся на сервере. Причем, абсолютно не нужно придерживаться принципа «одна страница – одно устройство». На одной web-странице могут находиться элементы как разных устройств, так и разных сегментов. Например, на рис.2 показана интеграция в web-интерфейс контроллера температуры и влажности «Метеостанция», относящегося к распределенному сегменту, показаний датчика давления и температуры ВМР085, а так же датчиков температуры DS18B20, которые в свою очередь относится к централизованному сегменту системы:
Рис.2
Аналогично на рис.3 показан web-интерфейс «Управление» радиомодуля, в который интегрировано управление контроллером с двумя релейными выходами. Оба устройства относятся к распределенному сегменту системы:
Рис.3
Web-интерфейс «Контроллер» является примером «индивидуального» интерфейса и предназначен только для управления контролером, имеющем четыре релейных выхода, четыре дискретных входа и один вход для подключения датчика температуры и влажности DHT22 (рис.4):
Рис.4
При желании, можно вывести все элементы управления и мониторинга от различных устройств и сегментов даже на одну web-страницу, что бы в процессе работы не переключать страницы в меню. Но это будет рациональным только при небольшом количестве таких элементов. Если устройств много, то просмотр «единой» страницы будет не очень удобным, особенно на мобильных устройствах.
Рассмотренные выше web-страницы представлены в так называемом "табличном" виде - все параметры и элементы управления сведены в обычную таблицу. Если кого-то не устраивает подобный "аскетичный" интерфейс, то такую страницу довольно легко можно сделать более наглядной и понятной для восприятия. В качестве примера на рис.5 приведен интерфейс метеостанции, где данные температуры/влажности указываются непосредственно на реальном плане контролируемого объекта. Впрочем, оформление интерфейса – это дело вкуса, каждый может выбрать или придумать свои варианты.
Рис.5
Отдельно рассмотрим пункт меню «Графики», в котором выводятся изменения во времени показаний от различных датчиков – давления, температуры, влажности. Здесь так же есть довольно широкие возможности по интеграции в одну страницу нескольких графиков. Но в данном случае нужно подходить к вопросу более продуманно. Неправильно совмещать в одной системе координат графики, например, атмосферного давления и температуры. Иначе, один график будет лежать в области значений 700…760 мм.рт.ст., а другой: -20°С…+30°С. И хотя графики довольно удобно масштабируются, тем не менее при группировке нескольких графиков в одну систему координат, желательно использовать параметры, имеющие абсолютные величины одного порядка.
Для примера на рис. 6 показан «индивидуальный» график температуры на улице:
Рис.6
А на рис.7 приведен пример графиков температуры с пяти датчиков DHT11 в доме:
Рис.7
Теперь что касается установки на Raspberry Pi необходимого программного обеспечения для работы системы домашней автоматизации (операционная система, программные пакеты, настройка конфигурационных файлов). Процедуры установки программного обеспечения подробно описывались в цикле наших предыдущих публикаций по Raspberry Pi и вы можете самостоятельно пройти весь этот путь с начала установки операционной системы Raspbian. Однако, наиболее оптимальным решением является установка программного обеспечения из образа. Размер образа сформирован под SD карту 4 Гб, но, конечно, подойдут карты и большего объема.Для «быстрого старта» необходимо развернуть скачанный образ на SD карте и заменить папки html и script на последние версии.
Внимание! О всех последних доработках системы домашней автоматизации, а так же об установке программного обеспечения читайте здесь
Выскажу своё мнение о несколько некорректном использовании понятия "СЕРВЕР" в Ваших статьях что бы читатели задумались над его смыслом. Вот ссылка, что такое сервер: https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B2%D0%B5%D1%80 Как отличить сервер от "не сервера", какой критерий? Если железка, программа ТОЛЬКО отвечает на запросы - значит сервер. Если железка, программа сама является генератором запросов, то это уже НЕ СЕРВЕР. В рамках Ваших статей о Raspberry как о сервере можно говорить только когда речь идет о WEB-сервере. Но ведь Raspberry генерирует трафик к DS18b20, DS1307, реле и, если я не путаю, по интерфейсу RS485. Думаю, что Raspberry в Ваших статьях правильнее называть контроллером, а не сервером. Все IMHO.
Сергей, я же в переписке приводил конкретный пример, что в определенных протоколах обмена данными подчиненное устройство ("сервер") тоже может быть инициатором запросов. Все зависит от режима работы протокола. Странно в таком случае получается - "железо" осталось тем же, а изменение режима работы протокола привело к тому, что то что было "сервером" превращается в "не сервер"
Следовательно, считать конкретное устройство сервером только по одному отличительному признаку (отсутствие формирования запросов) несколько некорректно.
По поводу клиент-серверных терминологических заморочек. Стараюсь понятия "клиент-сервер" применять исключительно к софтовому уровню. На "железном" уровне -- "мастер-слейв" Как пример: "OPC-сервер протокола modbus является мастером шины". Ну и как исключение на "обывательском" уровне - типа "главный сервер" - комп как ядро некой системы
