Умный дом. Часть 2. Топология умного дома. Сервер и локальный хаб. Технологии разработки.

2020-05-05

Владислав Новицкий

Оглавление

• Вступление.
• Как это устроено. Взаимодействие клиент-сервер.
• Как это устроено. Взаимодействие сервер-хаб.
• Как это устроено. Сервер.
• Как это устроено. Локальный хаб.
• Выбор микроконтроллера и технологии для локального хаба.
• Выбор микроконтроллера и технологии для сервера.
• Доработка метеостанции.
• Что бы я изменил.
• Заключение.

Вступление

Как вы уже могли догадаться из названия, в этой статье расскажу о том, как я создаю умный дом, от концепции и схем до реализации самих модулей. Поведаю о том, что такое локальный хаб и сервер, какой функционал в них заложен и как они устроены.

В предыдущей статье, которая называется «Автономная метеостанция как начало умного дома», я описывал первый модуль умного дома. В нем произошли некоторые изменения для интеграции в умный дом, о которых я расскажу далее.

Как это устроено. Взаимодействие клиент-сервер.

Первым делом следовало определиться каким образом будет осуществляться управление системами умного дома. Пультом было бы не удобно, он может где-то затеряться, да и просто вставать за ним не особо приятно. Голосовое управление вообще шикарно, но пока что трудно реализуемо. Поэтому было принято решение написать веб-приложение, к которому будет доступ с любого устройства, будь то телефон, планшет или компьютер. Почему я выбрал именно такое решение:

• Независимость от платформы и размеров экрана устройства;
• Простота решения (легкий старт даже при отсутствии опыта).

Теперь, когда способ взаимодействия человека и умного дома ясен, кто-то ж должен предоставлять эту возможность. Нужен http-сервер для отправки клиенту веб-страницы. (Выбор микроконтроллера и технологии для сервера описано в одноименном разделе). Одного http-сервера оказалось мало, хотелось сделать все по-красивому. Вдруг к системе управления будут подсоединены несколько пользователей и один из них внесет какие-нибудь изменения. Как остальные пользователи узнают об этом, точнее, как система передаст им изменения. Делать запросы на сервер со стороны клиента с определенным интервалом плохое решение – мало того, что мы грузим сервер не нужными запросами, так еще и нагружаем нашу локальную сеть. Да и скорость реакции будет зависеть от частоты опроса. Согласитесь, что звучит не очень. Поэтому было принято решение запускать на сервере еще и WebSocket сервер, технология которого, позволяет отправлять всем подключенным клиентам сообщение о том, что произошло, в момент возникновения события, таким образом, не загружая себя и сеть. Этот алгоритм выглядит следующим образом (рис. 1).

Рис. 1. Алгоритм полного подключения клиента к серверу

В конечном итоге получается следующее: http-сервер отдает нам веб-страницу (а именно html, css, js файлы), после чего на стороне клиента происходит инициализация подключения к WebSocket серверу, после чего клиент находится в системе. Посмотреть реализацию этого процесса можно в файле:

“SmartHouseNV-Server\Website\UsualSite\usualSite.js”

Постоянно загружать код в ESP8266 и проверять результат (особенно проводить отладку) было не удобно. Поэтому на компьютер был установлен Node.js. Сообщения между клиентом и сервером передаются в формате JSON, на пример:

Эта команда означает что нужно в спальне включить устройство, которое подключено к первой ножке порта А. Другими словами, открыть реле, благодаря которому, зажжется свет, к примеру.

Внешний вид веб-приложения изображен на рисунке 2 и 3. Для упрощения и ускорения процесса разработки был использован набор инструментов Bootstrap.

Рис. 2. Внешний вид сайта на компьютере

Рис. 3. Внешний вид сайта на мобильном устройстве

Пункте меню «Остальное» содержит в себе дополнительный функционал (рис. 4).

Рис. 4. Дополнительный функционал

В «Режиме редактирования» пользователь может добавлять и удалять элементы управления в комнате. Вид сайта в этом режиме показан на рисунке 5.

Рис. 5. Вид сайта в режиме редактирования

Чтобы хранить комнаты и элементы в них потребовалось база данных. Я использовал MySQL Server. Схема базы данных умного дома изображена на рисунке 6.

Рис. 6. Схема базы данных

На данный момент доступны следующие элементы управления:

• Обычная кнопка

• Двойная кнопка

• Тройная кнопка

• Изменяющаяся кнопка

• Выбор цвета

• Ползунок

Как это устроено. Взаимодействие сервер-хаб.

Как клиент будет взаимодействовать с сервером мы уже разобрались. Но нам же нужны некие исполняющие устройства, которые и будут выполнять всю работу: переключать свет, управлять вентиляцией, кранами водоснабжения, климат контролем и т.д. Я назвал такие устройства хабами (локальными хабами). Такие устройства должны присутствовать в каждой комнате дома, быть вмонтированы или где-то спрятаны и подключаться ко всей периферии комнаты (свет, кондиционер, бра и т.д.). В качестве мозга хаба была выбрана плата разработчика STM32F103C8T6. По какой причине я выбрал именно ее, читайте в соответствующем разделе ниже.

Если сервер использует технологию Wi-Fi, то локальные хабы, для связи с сервером используют модули беспроводной связи NRF24L01+ 2.4 ГГц (рис. 7). Они есть в разных модификациях: с большим радиусом связи, с малым. Мне подошли самые дешевые с малым радиусом.

Рис. 7. NRF24L01+ 2.4 ГГц

Ссылка на библиотеку для работы с модулем:

https://github.com/VNovytskyi/STM32_NRF

У них реализована пакетная передача данных, аппаратный контроль ошибок, автоматическое подтверждение приема пакета и отправка пакета пока получатель не получит его и еще много чего интересного. Управляется этот модуль по интерфейсу SPI, библиотека для работы с этим модулем реализована на множестве платформ. Но вот как связать, с помощью NRF24L01+ несколько разных устройств (например, STM32 Hal, Arduino, Espruino) я информации не нашел, так что пробивал эту проблему свои лбом.

Так вот, сервер принимает некую команду от пользователя через Wi-Fi, преобразует эту команду в понятную для хаба и отправляет ее хабу, получая при этом подтверждение о приеме. В противном случае отправляет команду снова определенное количество раз, если и в таком случае команда не доставлена, то выдает пользователю сообщение о том, что хаб не принял команду (может он отключен или находится вне радиуса действия, в таком случае следует заменить NRF24L01+ на более мощный или изменить месторасположение устройства). Хаб принимает эту команду, выполняет ее и отправляет на сервер сообщение о том, что команды была успешно или не успешно выполнена. Сервер анализирует ответ и выдает пользователю соответствующее сообщение.

Как это устроено. Сервер

Модуль NRF24L01+ подключен к NodeMCU по интерфейсу SPI. В прошивке ESP8266 используется аппаратный SPI, что позволяет не загружать процессор. К выводам питания NRF24L01+ присоединен электролитический конденсатор на 1000 мкФ для сглаживания пульсаций как самого модуля NRF24L01+, так и ESP8266. Схема подключения изображена на рисунке 8.

Рис. 8. Схема сервера

Код сервера находится в файле:

«SmartHouseNV-Server\ServerFirmware\main.js»

Ссылка на проект сервера:

https://github.com/VNovytskyi/SmartHouseNV-Server

Как это устроено. Локальный хаб

Конфигурация микроконтроллера в STM32CubeMX проиллюстрирована на рисунке 9. Оставшиеся ножки будут использоваться для общего назначения. Например, подсоединить еще какой-то модуль к хабу по I2C, SPI, CAN или UART.

Рис. 9. Конфигурация ножек микроконтроллера

NRF24L01+ подключен к SPI1, со следующими параметрами (рис. 10), схема подключения изображена на рисунке 11.

Рис. 10. Настройка SPI1

Рис. 11. Схема подключения NRF24L01+ к STM32F103C8

Код главного цикла программы локального хаба изображен на рисунке 12. В нем мы опрашиваем состояние ножки IRQ NRF24L01+. Если напряжение на ней высокое – значит никакого прерывание не было у модуля, если напряжение равно нулю – значит произошло прерывание. После этого нам необходимо узнать почему это прерывание произошло, для этого читаем регистр Status. Также для удобства проверяем как там очередь приемника. Если она не пуста, значит к нам прилетел пакет. Читаем его и отправляем его содержимое в функцию InputMessageHandler. Эта функция и приведет в исполнение команды в сообщении.

Рис. 12. Главный цикл хаба

Для того, чтобы увеличить количество ножек микроконтроллера были использованы два последовательно соединенных сдвиговых регистров 74HC595, управляемых по SPI2 в режиме “Transmit only master” (рис. 13). В итоге получается - три вывода микроконтроллера дают нам 16 ножек на выходе, которые являют собой логический порт A. Данный порт будет управлять блоком реле.

Рис. 13. Схема подключения сдвиговых регистров

Рис. 14. Тест порта А

Также имеется порт B. Он включает в себя 6 выводов, которые способны генерировать ШИМ-сигнал. Такой порт будет использоваться для контроля уровня яркости подсветки, управление RGB-подсветкой, оборотами вентиляторов.

Порт C предназначен для общего назначения. Ножки этого выхода могу как принимать сигнал (логический, ADC), так и выполнять роль определенного интерфейса.

Целиком схема подключения изображена на рисунке 14.

Рис. 14. Полная схема локального хаба

В моем проекте в NRF24L01+ используется динамическая длинна пакета, поэтому структура пакета выглядит следующим образом: первый байт в пакете говорит о длине самого пакета, а последующие байты – сами инструкции. К примеру, чтобы подать высокий уровень на первую ножку порта A необходимо подать 0x03, а, чтобы подать низкий – 0x04. Таким образом, наш пакет будет иметь вид: [0x01, 0x03]. Чтобы понять, почему нужно отправлять именно такие числа, заглянем внутрь функции InputMessageHandler (рис. 15).

Рис. 15. Пример кода для порта А

Подать команду на включение ШИМ-сигнала немного сложнее. В ней мы должны указать номер ножки порта B, а потом передать само значение, разбитое на 2 байта. Потому что, разрядность ШИМ-сигнала у STM32F103C8 16 бит. На рисунке 16 представлен фрагмент кода для подачи ШИМ-сигнала.

Рис. 16. Фрагмент кода сервера для отправки команды на подачу ШИМ-сигнала

Для начала мы определяем номер ножки, они у нас начинаются с числа 0x23 (потому что до этого идут команды для порта A). А потом решаем какое значение мы будем отправлять. Если значение ШИМ равно нулю, значит мы выключаем его, а если не равно, то отправляем его.

Ссылка на проект локального хаба:

https://github.com/VNovytskyi/SmartHouseNV-LocalHub1

Ссылка на библиотеку для сдвигового регистра:

https://github.com/VNovytskyi/STM32_ShiftRegister

Выбор микроконтроллера и технологии для локального хаба

В отличие от микроконтроллера сервера, вычислительная возможность хаба может быть порядка ниже, так как его задачей является прочесть пакет с NRF24L01+, и выполнить команды в нем. Также важно учесть количество периферии и ножек, доступных для взаимодействия с окружающей средой и модулями. Отладочная плата STM32F103C8 (рис. 17) отлично для этого подошла. Она не дорогая, имеется много ножек и интерфейсов. Стоит отметить и сопутствующий софт для семейства микроконтроллеров серии STM. Это STM32CubeIDE, STM32Cube, STM32Programmer, STM32CubeMonitor. Пару слов о них:

• STM32CubeIDE – удобная среда разработки для STM32, авто дополнение кода, отладка;
• STM32Cube – настройка всего микроконтроллера, на данный момент вмонтирована в STM32CubeIDE;
• STM32Programmer – программатор для STM32 через ST-Link;
• STM32CubeMonitor – для отладки STM32 в реальном времени, отображение графиков и т.д.

Как вы уже могли догадаться, в качестве языка программирования хаба был выбран язык С и библиотека HAL.

Рис. 17. STM32F103C8

Выбор микроконтроллера и технологии для сервера

Центром умного дома является Wi-Fi модуль ESP8266, расположенной на плате разработчика NodeMCU V3 с программатором CH340 (Рис. 18). Так же был вариант взять Wi-Fi модуль LuaNode32 на базе микроконтроллера ESP32, но он был дороже, да и количество периферии показалось мне излишним. В идеале, хотелось организовать все на каком-нибудь мини-компьютере, к примеру, на Raspberry Pi или на Orange Pi. Но такие решения выходят за рамки моего бюджета.

Рис. 18. NodeMCU V3

В качестве программного обеспечения была выбрана технология Espruino, которая представляет собой JavaScript интерпретатор для микроконтроллеров. По факту, используя данную технологию, мы получаем Node.js сервер. Рассматривались и другие технологии для ESP8266: Arduino, Lua, MicroPython.

Идея писать на Arduino была отброшена практически сразу из-за отсутствия нормальной среды разработки и не стабильной работы прошивки (Arduino Pro IDE еще сырая и не поддерживает ESP8266, а в Platformio IDE хоть и красиво и удобно, но тот же фреймворк Arduino).

Скриптовый язык Lua, который изначально рассчитан для NodeMCU плат, выглядит интересно, выполняется быстро, но отсутствие соответствия между реальным интерпретатором и документаций заставило отказаться от этого варианта.

Технология Espruino сразу приглянулась мне, так как я уже был знаком з языком JavaScript и Node.js. Скорость выполнения и стабильность прошивки меня так же сильно порадовали, даже есть некая реализация режима отладки, но скорость загрузки кода в микроконтроллер при больших объемах кода немного проседает. Также стоит отметить, что Espruino имеет хорошо написанную документацию. В добавок ко всему этому мы получаем практически все возможности языка JavaScript, а именно: динамическая типизация переменных, возможность обновлять код по воздуху или непосредственно отправлять код на исполнение, хороший JSON и URL parser, не плохая реализация WebSocket сервера. Хоть JavaScript это язык высокого уровня, его реализация в Espruino дает возможность работать непосредственно с регистрами и делать вставки кода на язык С, что дает возможность сильно увеличивать производительность. Внешний вид Espruino IDE изображен на рисунке 19.

Рис. 19. Внешний вид Espruino IDE

До технологии MicroPython я так и не добрался по простой причине: Espruino меня полностью устроила.

Дополнительный софт

Хотелось бы сказать пару слов о созданной программе для отладки локального хаба. Она позволяет имитировать команды с сервера, передавая их сразу и обработчик команд хаба через UART-переходник (рис. 20).

Рис. 20. UART переходник

Программа изображена на рисунке 21.

Рис. 21. Программа для отладки локального хаба

Ссылка на репозиторий с программой:

https://github.com/VNovytskyi/DebugLocalHub/

Доработка метеостанции

В метеостанции пришлось сделать некоторые изменения для интеграции с умным домом. Wi-Fi модуль был заменен на NRF24l01+.

В проект была добавлена библиотека работы с модулем NRF24l01+ и немного изменен код. Изменения изображены на рисунке 22

Рис. 22. Измененный код метеостанции

Ссылка на проект метеостанции:

https://github.com/VNovytskyi/SmartHouseNV-WeatherStation

Что бы я изменил

1. Как выяснилось в ходе разработки, оперативной памяти ESP8266 не хватило для подключения нескольких WebSocket клиентов (Espruino интерпретатор занял слишком много места). Если б я работал с этой технологией ранее, то скорее всего этого не случилось бы. Нужно будет заменить его на ESP32;

2. Отказался б от базы данных MySQL, к которой я очень привязался в момент отладки. Лучше использовать файловую реализацию базы данных. Количество записей не большое, поэтому работать файловая база данных будет даже быстрее.

Заключение

По мере возможностей и наличии свободного времени провожу усовершенствование своего проекта «Умный дом». В дальнейшем планирую разработать еще парочку устройств, в частности для полива растений и охраны дома. Также при достижении определенной надежности и функционала устройств планирую разработать для них печатные платы в программе EasyEDA, заказать парочку таких и создать для них корпуса.

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

Оставляйте свое мнение и отзывы о моем проекте в комментариях!

Комментарий автора

Все файлы находятся на Github, в разделе Release находится актуальная версия. Желательно, чтобы версии всех устройств совпадали, то есть, если скачиваете сервер версии v0.1, то и хаб, и ПО для отладки должно быть версии v0.1.