Понедельник, 24.04.2017, 11:29
| RSS
Поиск
Главная |
Защита, контроль, управление
Форма входа
Логин:
Пароль:

Меню

Авторские проекты

Авторский блог

Raspberry Pi

Каталог схем

Полезная информация

Обратная связь

Каталог сайтов

Форум

Канал YouTube

Сузуки Клуб Россия


Календарь
«  Январь 2017  »
ПнВтСрЧтПтСбВс
      1
2345678
9101112131415
16171819202122
23242526272829
3031

Наш опрос
Как Вы узнали об этом сайте?
Всего ответов: 523

Ссылки




Яндекс.Метрика





.
Статистика

Онлайн всего: 3
Гостей: 3
Пользователей: 0

Домашняя автоматизация на Raspberry Pi

Домашняя автоматизация на Raspberry Pi


Домашняя автоматика

В результате проделанной работы по созданию системы домашней автоматизации с применением Raspberry Pi сложилась ее определенная структура с возможностью дальнейшего наращивания и конфигурирования. Обращаю ваше внимание - здесь не предлагается некая завершенная система, которую нужно пытаться реализовать «один в один». Наша система домашней автоматизации с применением Raspberry Pi – это своеобразный «конструктор», используя который с помощью отдельных «кубиков» вы сможете построить требуемую вам конфигурацию.

Итак, начнем со структурной схемы системы, показанной на рис.1:

 

Структурная схема домашней автоматизации Raspberry Pi

Рис.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;

- выходы GPIO, предназначенные для управления релейным модулем;

- входы GPIO для контроля состояния дискретных датчиков.

К распределенному сегменту системы относятся:

контроллер, имеющий четыре релейных выхода, четыре дискретных входа и один вход для подключения датчика температуры и влажности DHT22;

- контроллер температуры и влажности (метеостанция), имеющий один вход для датчика DHT22 и пять входов для датчиков DHT11;

- контроллер с двумя релейными выходами (применено готовое изделие);

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

В отличие от пилотной версии системы домашней автоматизации, все контроллеры с интерфейсом RS485 вместо нестандартного «ASCII-подобного» протокола сейчас работают по стандартному протоколу Modbus RTU.

Для обеспечения взаимодействия оператора с системой домашней автоматизации не требуется установки никакого дополнительного программного обеспечения на компьютер, планшет или смартфон – доступ к системе осуществляется через web-браузер с любого устройства. С целью обеспечения безопасности доступ авторизированный – т.е. через ввод логина и пароля пользователя.

Интерфейс пользователя – это отдельные web-страницы, которые хранятся на сервере. Причем, абсолютно не нужно придерживаться принципа «одна страница – одно устройство». На одной web-странице могут находиться элементы как разных устройств, так и разных сегментов. Например, на рис.2 показана интеграция в web-интерфейс контроллера температуры и влажности «Метеостанция», относящегося к распределенному сегменту, показаний датчика давления и температуры ВМР085, а так же датчиков температуры DS18B20, которые в свою очередь относится к централизованному сегменту системы:

 

Meteostation Raspberry Pi

Рис.2

 

Аналогично на рис.3 показан web-интерфейс «Управление» радиомодуля,  в который интегрировано управление контроллером с двумя релейными выходами. Оба устройства относятся к распределенному сегменту системы:

 

Radio Raspberry Pi

Рис.3

 

Web-интерфейс «Контроллер» является примером «индивидуального» интерфейса и предназначен только для управления контролером, имеющем четыре релейных выхода, четыре дискретных входа и один вход для подключения датчика температуры и влажности DHT22 (рис.4):

 

Controllers RS485 Raspberry Pi

Рис.4

 

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

Рассмотренные выше web-страницы представлены в так называемом "табличном" виде - все параметры и элементы управления сведены в обычную таблицу. Если кого-то не устраивает подобный "аскетичный" интерфейс, то такую страницу довольно легко можно сделать более наглядной и понятной для восприятия. В качестве примера на рис.5 приведен интерфейс метеостанции, где данные температуры/влажности указываются непосредственно на реальном плане контролируемого объекта. Впрочем, оформление интерфейса – это дело вкуса, каждый может выбрать или придумать свои варианты.

 

3D web interface Raspberry Pi

Рис.5

 

Отдельно рассмотрим пункт меню «Графики», в котором выводятся изменения во времени показаний от различных датчиков – давления, температуры, влажности. Здесь так же есть довольно широкие возможности по интеграции в одну страницу нескольких графиков. Но в данном случае нужно подходить к вопросу более продуманно. Неправильно совмещать в одной системе координат графики, например, атмосферного давления и температуры. Иначе, один график будет лежать в области значений 700…760 мм.рт.ст., а другой: -20°С…+30°С. И хотя графики довольно удобно масштабируются, тем не менее при группировке нескольких графиков в одну систему координат, желательно использовать параметры, имеющие абсолютные величины одного порядка.

Для примера на рис. 6 показан «индивидуальный» график температуры на улице:

 

График температуры Raspberry Pi

Рис.6

 

А на рис.7 приведен пример графиков температуры с пяти датчиков DHT11 в доме:

 

Контроль температуры Raspberry Pi

Рис.7

 

Теперь что касается установки на Raspberry Pi необходимого программного обеспечения для работы системы домашней автоматизации (операционная система, программные пакеты, настройка конфигурационных файлов). Процедуры установки программного обеспечения подробно описывались в цикле наших предыдущих публикаций по Raspberry Pi и вы можете самостоятельно пройти весь этот путь с начала установки операционной системы Raspbian. Однако, наиболее оптимальным решением является установка программного обеспечения из образа. Размер образа сформирован под SD карту 4 Гб, но, конечно, подойдут карты и большего объема.Для «быстрого старта» необходимо развернуть скачанный образ на SD карте и заменить папки html и script на последние версии. 

Внимание!  О всех последних доработках системы домашней автоматизации, а так же об установке программного обеспечения читайте здесь 


 

 

 




Категория: | Просмотров: 5242 | Добавил: Admin | Теги: Raspberry Pi, домашняя автоматизация | Рейтинг: 5.0/4 |
Всего комментариев: 3


1  
Выскажу своё мнение о несколько некорректном использовании понятия "СЕРВЕР" в Ваших статьях что бы читатели  задумались над его смыслом. Вот ссылка, что такое сервер: 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.

0
2  
Сергей, я же в переписке приводил конкретный пример, что в определенных протоколах обмена данными подчиненное устройство ("сервер") тоже может быть инициатором запросов. Все зависит от режима работы протокола. Странно в таком случае получается - "железо" осталось тем же, а изменение режима работы протокола привело к тому, что то что было "сервером" превращается в "не сервер"

Следовательно, считать конкретное устройство сервером только по одному отличительному признаку (отсутствие формирования запросов) несколько некорректно.

3  
По поводу клиент-серверных терминологических заморочек. Стараюсь понятия "клиент-сервер" применять исключительно к софтовому уровню. На
"железном" уровне -- "мастер-слейв"
Как пример: "OPC-сервер протокола modbus является мастером шины". Ну и как исключение на "обывательском"
уровне - типа "главный сервер" - комп как ядро некой системы smile





T2M © 2017
Сайт управляется системой uCoz