Хотел написать на эту тему подробную статью, но, очевидно, руки не доходят. Посему краткое сообщение. Я разработал и реализовал на нескольких языках в виде прототипного кода версию протокола MQTT под рабочим названием MQTT/UDP. Для нетерпеливых и тех, кому уже всё понятно и очевидно, код на Гитхабе
Зачем
Я живу в квартире, которая почти полностью управляется собственной системой умного дома несколько лет. Управление светом, климатом, датчики, лёгкая автоматизация, вот это всё.
За это время я выяснил (да, впрочем, и до того понимал), что главное свойство систем УД — надёжность.
Все системы с центральным узлом по определению ненадёжны. Отсюда — желание получить интерконнект компонент системы (а их в реальном умном доме много) без использования какого-либо центрального хаба.
При этом исходим из того, что в целом трафик систем УД невелик — датчики редко нуждаются в апдейте чаще раза в минуту, остальные данные имеют событийный характер (включили свет), и по трафику совершенно несущественны. Даже ежесекундное обновление всех данных в системе не является не только катастрофой, но и даже существенной проблемой.
Логичный вывод — UDP бродкаст является идеальным инструментом.
(Да, я предполагаю, что внутренняя сеть квартиры закрыта файрволлом.)
Что в плюсах:
Невероятно простая реализация. Минимальный микроконтроллер с крошечной памятью сумеет послать UDP-пакет. Для датчика даже приём UDP не нужен.
Предельно низкая латентность. Нет форварда в центральном хабе, время доставки UDP пакета -практически минимальный квант времени в современной системе.
Нет центральной точки отказа в хабе/брокере. Рассмотрим простую схему: два датчика температуры, контроллер тёплого пола, контроллер батарей отопления. С применением MQTT/UDP отказ любой части такой системы не приводит к отказу системы в целом.
Низкий трафик в сети. Ниже некуда. TCP и подтверждения только добавляют трафика, но не добавляют надёжности. Отказавший датчик не заработает от получения TCP ACK. А отказ мы и так выявляем по отсутствию обновлений.
Ненадёжность самого протокола UDP несущественна — датчики всё равно обновляют данные регулярно, и пропадание отсчёта совершенно незаметно, а пропадание команды с, например, выключателя визуально подтверждается несработкой целевой системы. Что делает человек? Щёлкает ещё раз. Тем не менее, это — главный ограничитель применимости протокола. Идеален для повторяющихся опросов.
Не нужна конфигурация системы. Никому не нужно прописывать адрес брокера, хаба и т.п. Впрочем, всё равно нужна конфигурация датчика — требуется прописать идентификатор датчика. Но при переносе других частей системы на другие сервера переконфигурация ответных компонент не потребуется.
Отдельно интересно, что эта модель обмена данными хорошо ложится на натурально бродкастные среды, такие как радиоканал или RS/485. Я с этим не экспериментировал, и протокол в таких средах нуждается в контроле. Логично здесь применить CRC16 от modbus, кстати.
Минусы также очевидны: надежность доставки определяется только хардвером и трафиком в сети, ну и если в сеть пробрался враг, то протокол повержен сразу. Правда, будем откровенны, взлом иных типичных протоколов умного дома — дело секунд, так что это — спорный недостаток MQTT/UDP. Ещё один неочевидный минус — максимум один приёмник на IP-адрес.
Что сделано и лежит в репозитории в исходниках:
Что бы я сделал, будь у меня ещё время:
На сём благодарю, добро пожаловать в репозиторий
PS: Аналогичный подход, но уже с мультикастом, описан в этой статье.
Зачем
Я живу в квартире, которая почти полностью управляется собственной системой умного дома несколько лет. Управление светом, климатом, датчики, лёгкая автоматизация, вот это всё.
За это время я выяснил (да, впрочем, и до того понимал), что главное свойство систем УД — надёжность.
Все системы с центральным узлом по определению ненадёжны. Отсюда — желание получить интерконнект компонент системы (а их в реальном умном доме много) без использования какого-либо центрального хаба.
При этом исходим из того, что в целом трафик систем УД невелик — датчики редко нуждаются в апдейте чаще раза в минуту, остальные данные имеют событийный характер (включили свет), и по трафику совершенно несущественны. Даже ежесекундное обновление всех данных в системе не является не только катастрофой, но и даже существенной проблемой.
Логичный вывод — UDP бродкаст является идеальным инструментом.
(Да, я предполагаю, что внутренняя сеть квартиры закрыта файрволлом.)
Что в плюсах:
Невероятно простая реализация. Минимальный микроконтроллер с крошечной памятью сумеет послать UDP-пакет. Для датчика даже приём UDP не нужен.
Предельно низкая латентность. Нет форварда в центральном хабе, время доставки UDP пакета -практически минимальный квант времени в современной системе.
Нет центральной точки отказа в хабе/брокере. Рассмотрим простую схему: два датчика температуры, контроллер тёплого пола, контроллер батарей отопления. С применением MQTT/UDP отказ любой части такой системы не приводит к отказу системы в целом.
Низкий трафик в сети. Ниже некуда. TCP и подтверждения только добавляют трафика, но не добавляют надёжности. Отказавший датчик не заработает от получения TCP ACK. А отказ мы и так выявляем по отсутствию обновлений.
Ненадёжность самого протокола UDP несущественна — датчики всё равно обновляют данные регулярно, и пропадание отсчёта совершенно незаметно, а пропадание команды с, например, выключателя визуально подтверждается несработкой целевой системы. Что делает человек? Щёлкает ещё раз. Тем не менее, это — главный ограничитель применимости протокола. Идеален для повторяющихся опросов.
Не нужна конфигурация системы. Никому не нужно прописывать адрес брокера, хаба и т.п. Впрочем, всё равно нужна конфигурация датчика — требуется прописать идентификатор датчика. Но при переносе других частей системы на другие сервера переконфигурация ответных компонент не потребуется.
Отдельно интересно, что эта модель обмена данными хорошо ложится на натурально бродкастные среды, такие как радиоканал или RS/485. Я с этим не экспериментировал, и протокол в таких средах нуждается в контроле. Логично здесь применить CRC16 от modbus, кстати.
Минусы также очевидны: надежность доставки определяется только хардвером и трафиком в сети, ну и если в сеть пробрался враг, то протокол повержен сразу. Правда, будем откровенны, взлом иных типичных протоколов умного дома — дело секунд, так что это — спорный недостаток MQTT/UDP. Ещё один неочевидный минус — максимум один приёмник на IP-адрес.
Что сделано и лежит в репозитории в исходниках:
- Реализации клиента/сервера на нескольких языках. Есть Си, Питон и Ява. Я не осилил Lua (не смог поставить всё, что нужно, как вы в этом живёте?) и Codesys (не смог собрать пакет, кто придумал этот язык?).
- Минимальный гейт в традиционный MQTT на Питоне
- Примитивный инструмент для отображения трафика MQTT/UDP в сети
Что бы я сделал, будь у меня ещё время:
- Написал бы модуль для openHUB.
- Сделал бы вариант протокола на JSON на другом порту и конвертор в основной формат и порт. Или гейт в обе стороны.
- Сделал бы болванки реализации для основных платформ. Для Arduino я сделал подход к весу и реально протестировал код, но не оформил всё как следует. Для Малины годятся тестовые примеры на Питоне.
- Сделал бы цифровую подпись и шифрование, но неясно, как.
- Мультикаст.
На сём благодарю, добро пожаловать в репозиторий
PS: Аналогичный подход, но уже с мультикастом, описан в этой статье.
