В данной статье я хочу сделать попытку обоснования выбора реализуемой мною системы «Умный дом». Это уже третий вариант разработанного мной «Умного дома» (вообще эта тема меня заинтересовала с середины 90-х годов):
Первый проект был создан на базе ПК с подключением периферийных устройств через COM‑порт.
Второй проект был разработан лет 8 назад, основывался на сотовом телефоне в качестве главного узла и подчиненных устройств подключаемых к нему с помощью интерфейса RS485. Ссылка на источник [1].
Оба проекта были основаны на проводных интерфейсах обмена внутри дома и обменом данными с внешними устройствами через сотовую связь (SMS, а затем и TELEGRAM).
На этом краткое вступление заканчиваю и перехожу к сути вопроса.
1. Выбор функциональной схемы системы
На данный момент уже сложилась типовая базовая модель системы «Умный дом», это:
Локальный интерфейс, проводной или беспроводный, объединяющий периферийные устройства системы «Умный дом».
Сервер, расположенный как на объекте так и удаленно в «облаке», на котором хранится текущая информация.
Устройство соединяющее локальную сеть и интернет.
Устройства получающие информацию из системы и управляющие ей. Желательно чтобы обмен информацией был доступен как через интернет, так и локально.
На рис. 1 представлена функциональная схема такой модели.
Теперь надо выбрать каждый элемент системы.
2. Выбор локального интерфейса
2.1 В настоящее время широко распространены системы «умный дом» с беспроводным интерфейсом и управлением через облачный сервер. Минусы таких систем:
При отсутствии или сбоях работы интернета их работа парализуется.
Даже если пользователь находится на объекте, при обмене через облачный сервер исполнение команд занимает довольно значительное время.
Улучшением работы таких сис��ем может послужить управление устройствами через локальные беспроводные интерфейсы (типа WiFi, Bluetooth и так далее) при нахождении пользователя на объекте, однако при этом возможно нарушение работы от помех и целенаправленного блокирования с помощью широкополосного источника помех.
Более надежным вариантом является использование проводных интерфейсов. Это исключит сбои в работе от внешних радиопомех и повысит надежность обмена информацией в локальной системе, особенно это ценно при использовании функций охраны объекта.
Решено, выбираем для локальной сети проводной интерфейс.
2.2 Существует огромное множество протоколов проводных интерфейсов обмена данными используемых в системе умный дом, основные:
KNX: Международный стандарт для комплексной автоматизации зданий. Отличается высокой надежностью и стабильностью, но требует профессиональной установки.
Modbus: Промышленный протокол, используемый в умных домах для управления инженерными системами (например, отоплением и вентиляцией). Работает по схеме: «мастер — подчиненные».
Ethernet: Обеспечивает быстрое и надежное проводное соединение с низкой восприимчивостью к помехам. Идеален для устройств, требующих высокой скорости передачи данных, таких как IP‑камеры.
LonWorks: Протокол, созданный для промышленной автоматизации, что обуславливает его высокую надежность и безопасность. Устройства на базе LonWorks могут работать как самостоятельные интеллектуальные гаджеты. Довольно сложен в реализации, требует специализированный микроконтроллер Neuron Chip.
-
1-Wire: Простой протокол, который использует один кабель для передачи данных и питания устройств. Часто применяется для датчиков температуры и влажности на небольших расстояниях. Обладает низкой помехоустойчивостью.
Кроме того существует протокол CAN (Controller Area Network), который изначально разрабатывался компанией Bosch в 1980-х годах и в первую очередь получил широкое распространение в автомобильной промышленности. Особенностью этого протокола является работа всех узлов сети на равных условиях, обмен данными производится на основе событий. Из‑за своей надежности CAN может использоваться для критически важных подсистем внутри дома, где требуется высокая отказоустойчивость, например, в системах безопасности или управления отоплением. Однако он не является типичным или широко используемым стандартом для бытовых систем умного дома. Также в отличие от большинства, данный протокол широко описан в разных источниках, например [2].
Из всех проводных протоколов мне больше понравился CAN из‑за его возможности обеспечивать работоспособность узлов сети в автономном режиме при пропадании связи с сервером, а также возможностью обеспечить соединение с п��льзователями любым узлом сети при неисправности основного.
2.3 Обзор видов протоколов основанных на CAN (Controller Area Network)
Сам по себе протокол CAN определяет только физический и канальный уровни (согласно модели OSI), то есть правила передачи отдельных сообщений по шине. Для обеспечения полноценной связи, управления устройствами и обмена сложными данными поверх CAN были разработаны различные протоколы верхнего уровня (прикладного), адаптированные под конкретные задачи и отрасли. Ниже представлен обзор основных протоколов, основанных на CAN‑шине:
CANopen — один из самых распространенных и функционально полных протоколов верхнего уровня для CAN. Он широко используется в промышленной автоматизации, медицинском оборудовании и встраиваемых системах. Обеспечивает стандартизированный способ настройки, управления и обмена данными между устройствами разных производителей.
Особенности: довольно сложная реализация обмена данными через четыре подуровня (слой данных (DLL), интерфейс обмена (CI), словарь объекта (OBD), приложение (USR) ); наличие служб: синхронизации, аварийных сообщений, управление сетью, мониторинга сети. Ссылка на описание [3].
При этом открытым программное обеспечение протокола можно назвать только условно, требуется платная лицензия.
-
DeviceNet — ориентирован на простые промышленные сети ввода/вывода, соединяя датчики, исполнительные механизмы и контроллеры. Эффективная схема обмена данными, где одно устройство «производит» данные, а несколько других могут их «потреблять». DeviceNet — это протокол ориентированный на соединения. Узел сети DeviceNet может быть клиентом или сервером. Сервер и клиент могут или отправлять сообщения (producer), или принимать сообщения (consumer), или одновременно и отправлять и принимать. Следует отметить, что с точки зрения схемы Master/Slave, Master является клиентом, а Slave — сервером.
Особенности: хотя протокол поддерживает одноранговый (peer‑to‑peer) режим связи, хотя чаще всего он используется в конфигурации «ведущий‑ведомый», к тому же прежде чем между двумя узлами сети могли быть переданы какие‑либо данные, должно быть установлено сетевое соединение.
-
CAN Kingdom — представляет собой набор «примитивов протокола» (protocol primitives) — инструментарий, позволяющий системному разработчику создать оптимизированный, специализированный протокол для конкретной системы.
Особенности: централизованная настройка, децентрализованная работа. Он не содержит готового программного обеспечения и требует значительных усилий при проектировании на системном уровне.
Протоколы J1939, ISO 11 783 (ISOBUS), UDS предназначены для транспортного использования на автомобилях.
Проанализировав информацию по данным протоколам, где меня не устраивает: то сложность исполнения, то ограниченный функционал при работе в одноранговом режиме, мне стало понятно что придется изобретать свой вариант пользовательского (прикладного) протокола на основе CAN 2.0. В этом решении меня поддержал ИИ DeepSeek, за 8 секунд набросав проект: «Отличная задача! Создание упрощённого пользовательского протокола поверх CAN для умного дома — это прекрасный подход, который позволяет получить все преимущества CAN (надёжность, детерминизм, помехозащищённость) без избыточности больших стандартов». Кстати получился проект довольно неплохой и вполне реализуемый, но примитивный, поэтому мы пойдем другим путем.
3. Проект пользовательского протокола на основе CAN
3.1 Концепция протокола:
Создать простой протокол использующий основную идею CAN: любое устройство, подключенное к интерфейсу может выставить событие, которое видят все но обрабатывают только устройства подписанные на него.
Каждое устройство сети имеет функции, выбираемые из таблицы функциональности (набор заданных функций).
Связь сети с внешним миром происходит через один из узлов сети, однако любое из устройств сети может выполнять эту функцию.
Все устройства входящие в сеть должны иметь одинаковое программное обеспечение, разница только в области памяти где хранятся индивидуальные настройки устройства (она программируется до включения в сеть). Такой подход позволит в дальнейшем производить OTA (Over‑The‑Air) обновление программы.
Протокол должен позволять запись команд на устройства сети из вне (сценарии), для обработки событий происходящих в сети в автономном режиме.
Протокол должен обеспечивать выполнение широковещательных команд.
Предусмотреть надежность передачи данных по сети с помощью сообщений подтверждения или повторов.
3.2 На основании изложенной выше концепции был создан протокол. Описание его приведено в источнике [4]. За основу при разработке данного протокола взята идея аналогичная формированию таблиц GATT в BLE. Также есть профиль устройства, сервисы, характеристики.
4. Выбор элементной базы
4.1 Список всех основных производителей на данный момент, исключая микроконтроллеры специализированные для автомобилей, и выпускаемых ими серий микросхем, имеющих в своем составе программной поддержки реализации протокола CAN:
STMicroelectronics (STM32)
ESPRESSIF (ESP32)
NXP(LPC series)
Microchip/Atmel (SAM series; AT90CAN, ATmega16/32/64/M1)
Texas Instruments (series: C2000, Sitara ARM, MSP430)
Infineon (XMC4000 series)
Renesas (RX Family; RL78)
Производители: Microchip/Atmel, Texas Instruments отпадают из‑за малой доступности в связи с введенными ограничениями.
Микроконтроллеры производителя Renesas имеют маленький размер флэш памяти, к тому же они 16 разрядные.
Микроконтроллеры с большим объемом памяти производителей NXP, Infineon имеют значительно большую стоимость чем STM32 и ESP32.
Микроконтроллеры с большим объемом памяти STM32 сложно достать и они имеют большую стоимость по сравнению с ESP32.
Значит остановим выбор на серии ESP32 китайского производителя ESPRESSIF.
4.2 Выбираем микроконтроллер из выше указанной серии на основе следующих критерий:
объем памяти для программ (flash) не менее 4 Мб, чтобы поместились все: программы, профили устройств сети и можно было произвести OTA обновление программы;
наличие аппаратного ускорителя для кодирования/декодирования отсылаемых сообщений на внешние устройства;
наличие встроенной антенны для протоколов беспроводной связи;
программная и аппаратная поддержка протокола CAN 2.0;
-
поддержка максимально возможного числа протоколов беспроводной связи, для развития системы в будущем.
Всему вышесказанному соответствует модуль ESP32-C6-WROOM-1-N8: это модуль на базе микросхемы ESP32-C6 со встроенной антенной и флэш памятью на 8Мб, поддерживающий Wi‑Fi 6 в диапазоне 2,4 ГГц, Bluetooth 5, ZigBee 3.0 и Thread. Благодаря низкому энергопотреблению он идеально подходит для различных устройств Интернета вещей.
5. Выбор устройства соединения (шлюз)
Теперь необходимо выбрать устройство соединяющее интернет и локальную сеть — сетевой шлюз.
5.1 Логичнее взять недорогое покупное устройство — роутер с модемом. Так как наша локальная сеть является проводной, то и роутер (маршрутизатор) должен иметь выходы для подключения проводного интерфейса, обычно ETHERNET. Кроме того желательно чтобы он имел каналы WiFi, для подключения беспроводных устройств и локального управления пользователями. К тому же он должен быть недорогим. Я выбрал роутер фирмы Eltex: RG-1440G‑WAC.
5.2 Порывшись в интернете на предмет соединения интерфейса CAN и ETHERNET, а также учитывая готовые программы драйверов для микросхем ESP32, мой выбор пал на Module Ethernet WIZ820io, основанный на микроконтроллере W5500 и подключаемый к микросхеме ESP32 через интерфейс SPI.
6. Выбор типа сервера и протокола обмена с ним
6.1 На данный момент существует два основных транспортных протокола в интернете:
TCP (Transmission Control Protocol) TCP/IP. Он устанавливает соединение между клиентом и сервером. Гарантирует доставку данных, проверяет целостность, упорядочивает пакеты. Если пакет потерялся, он запрашивается повторно.
UDP (User Datagram Protocol). Он работает без установки соединения. Отправляет данные «в слепую», без гарантий доставки и порядка. Зато работает очень быстро.
Для нашей системы где потеря информации должна быть исключена или сведена к минимуму, протокол UDP не подходит.
Рассмотрим протоколы прикладного уровня поверх TCP:
HTTP (HyperText Transfer Protocol). Это основа всемирной паутины. Использует модель «запрос‑ответ». Клиент отправляет запрос, сервер возвращает ответ (HTML‑страницу, картинку, данные). Задержки по времени при этом довольно значительны.
HTTPS (HTTP Secure). Это HTTP + шифрование (SSL/TLS). Данные шифруются, что защищает их от перехвата.
WebSocket. Создает постоянное двустороннее соединение между клиентом и сервером. После рукопожатия (часто через HTTP) данные могут передаваться в обе стороны одновременно и без задержек на новые запросы.
WebSocketSecure (WSS). Используется протокол WebSocket через шифрование TLS. При этом производится проверка сертификатов.
Поверх вышеуказанных протоколов можно установить протокол MQTT (Message Queuing Telemetry Transport) — это облегченный протокол для обмена сообщениями по принципу «издатель‑подписчик» (publish‑subscribe). Он идеально подходит для устройств с ограниченными ресурсами (малая мощность процессора, низкое энергопотребление, нестабильный канал связи).
6.2 Ключевые особенности и концепции MQTT.
а) Архитектура «Издатель‑Подписчик» (Pub/Sub):
В отличие от HTTP с его моделью «запрос‑ответ», в MQTT нет прямого общения между устройствами.
Клиенты могут быть:
Издателями (Publishers): Отправляют сообщения.
Подписчиками (Subscribers): Получают сообщения.
Все общение происходит через центральный узел — MQTT‑брокер.
б) Брокер (Broker):
Это сервер, который принимает все сообщения от издателей и перенаправляет их всем подписчикам, которые интересуются данной темой.
Он отвечает за управление подключениями, подписками и маршрутизацию сообщений.
в) Темы (Topics):
Это виртуальные каналы, на которые издатели отправляют сообщения. Подписчики слушают конкретные темы.
-
Темы имеют иерархическую структуру, разделенную слешем
/, например:home/living_room/temperaturehome/kitchen/light/switch
Подписчик может подписаться на конкретную тему (
home/living_room/temperature) или использовать специальные символы (#для многоуровневого шаблона,+для одноуровневого), чтобы слушать группу тем (например,home/+/temperature).
Преимущества MQTT
Очень малый накладной расход. Заголовки сообщений очень маленькие, что экономит трафик и батарею.
Эффективная доставка данных. Одно сообщение от одного издателя может быть доставлено тысячам подписчиков через брокер.
Поддержка нестабильных сетей. Протокол разработан для работы с частыми разрывами соединения. Клиент может настроить «последнюю волю» (Last Will), чтобы уведомить других, если он неожиданно отключился.
-
Гибкость качества обслуживания (QoS):
QoS 0: «Отправил и забыл» — доставка не гарантируется (как UDP).
QoS 1: «Доставлен хотя бы раз» — подтверждение доставки обязательно, возможны дубликаты.
QoS 2: «Доставлен ровно один раз» — максимальная надежность (как TCP, но с дополнительными проверками).
6.3 Вывод. Оптимальным будет использование протокола MQTT с использованием канала связи согласно протоколу WSS. Оба эти протокола широко освещены в различных источниках, одним из которых является [5].
Заключение
Получилось так, что я вначале создал выше изложенную систему «Умный дом на основе CAN», а затем написал эту статью. Поэтому программное обеспечение в основном разработано и отлажено (правда остались некоторые нюансы которые требуют доработки).
Печатная плата типового узла сети тоже разработана и спаяно несколько экземпляров.
Отработано взаимодействие в сети CAN (TWAI).Проверена работа под управлением через MQTT — брокера, а также в автономном режиме — по сценариям.
Возможно продолжение публикаций по этому проекту с детальным объяснением работы программы и нюансов реализации системы, если будет проявлен интерес читателей.
Список используемых источников
2. Описание протокола CAN: ГОСТ Р ИСО 11898–1 -2015.