Что такое MQTT?

MQTT или Message Queue Telemetry Transport – это легкий открытый протокол обмена данными, работающий поверх TCP/IP, созданный для унификации обмена данных между устройствами M2M (Машинно-Машинное взаимодействие) и IIoT (Промышленный Интернет вещей).

Идеален для использования в контроллерах и датчиках  где требуется небольшой размер кода и есть ограничения по пропускной способности канала. 

Особенности протокола MQTT

Основные особенности протокола MQTT:

  • Асинхронный протокол
  • Компактные сообщения
  • Работа в условиях нестабильной связи на линии передачи данных
  • Поддержка нескольких уровней качества обслуживания (QoS) 
  • Легкая интеграция новых устройств

 

Протокол MQTT работает на прикладном уровне поверх TCP/IP и использует по умолчанию 1883 порт (8883 при подключении через SSL). Также, возможна работа через Winsocket

Обмен сообщениями в протоколе MQTT осуществляется между клиентом (client), который может быть издателем или подписчиком (publisher/subscriber) сообщений, и брокером (broker) сообщений (например, открытое ПО  Mosquitto MQTT).

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

Устройства MQTT используют определенные типы сообщений для взаимодействия с брокером, ниже представлены основные:

  • Connect – установить соединение с брокером
  • Disconnect – разорвать соединение с брокером
  • Publish – опубликовать данные в топик на брокере
  • Subscribe – подписаться на топик на брокере
  • Unsubscribe – отписаться от топика

Топики представляют собой иерархическую структуру, похожую на путь в файловой системе. Например:

myhome/kitchen/temperature

myhome/kitchen/light

Все устройства, которые заинтересованы в получении обновлений информации по всему, например, что происходит на кухне, могут подписаться на топик myhome/kitchen/#  (#-специальный символ, аналогичный "*" в файловых системах) 

Датчик температуры публикует свои измерения в топик /myhome/kitchen/temperature

Выключатель - в топик /myhome/kitchen/light

Преимущества использования MQTT для устройств  

  • Является стандартом де-факто для современных облачных систем IoT (см обзор). Данный протокол поддерживается абсолютно всеми современными облачными и On Premises системами IoT
  • Развитая экосистема opensource решений автоматизации и диспетчеризации, в том числе: HomeAssistant, OpenHab, Wiren Board, Node Red - (см. Обзор) - это позволяет оконечным устройствам легко использовать уже имеющееся ПО без необходимости разрабатывать Web- интерфейсы, мобильные приложения, Rule-engines и пр.
  • ПО MQTT брокера, также, доступно в открытом исходном коде и портировано под основные ОС (https://mosquitto.org/)
  • Поддержка данного протокола устройством позволяет использовать его совместно с большим кол-вом уже существующего ПО и легко интегрировать новые устройства  
  • Библиотеки для реализации клиентской части данного протокола, также, доступны в исходном коде и могут быть легко интегрированы в ваш проект

Недостатки и особенности реализации MQTT

Протокол хорошо специфицирует такие операции как подписка на информацию (топик)  и публикацию информации в топик, но сам формат данных оставляет на усмотрение приложений IoT

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

Например, популярные OpenSource системы управления УД: OpenHab, HomeAssistant и IOBroker  поддерживают MQTT. Но при этом напрямую, не совместимы.

На мой взгляд, самая обширная и продуманная реализация MQTT из этих трех систем, у HomeAssistant. По крайней мере, она подразумевает разумную иерархию топиков. И поддерживает аж три формата взаимодействия, включая JSon. Также, описывает формат управления для типовых устройств Умного дома, таких как освещение, термостат и пр.

Отдельно стоит упомянуть MQTT Autodiscovery - механизм, при помощи которого HomeAssistant может одним кликом добавлять новые устройства, которые особым образом анонсируют себя на шине MQTT

Начиная с версии 2.4, OpenHab, также, анонсировал новый драйвер MQTT, в том числе, с поддержкой конвенции homie и AutoDiscovery

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

Старый драйвер стабилен, но достаточно примитивен. Подразумевает использование в качестве  MQTT Payload простых команд: "ON", "OFF", цифровые значения датчиков, разделенные запятыми. Можно прикрутить JSon, но настройка этого крайне неудобна. Также, плоская как блин структура Item-ов OpenHab все еще крайне натянуто ложится на иерархическую структуру мира. Дальнейшие эксперименты я не проводил, так как постепенно перешел на HomeAssistant

IOBroker имеет более-менее продуманную структуру топиков, но вот беда, его авторам понадобилось зачем-то доработать сам брокер, отступив от стандарта.

Доработка заключается в том, что MQTT брокер, входящий в состав IOBroker-а не отправляет информацию обратно тому клиенту, который ее направил, даже если он в явном виде подписался на данный топик.

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

Можно спорить о том, полезная доработка или нет, но она уже привела к тому, что те устройства, которые делаются под IOBroker в принципе, не работают со стандарным Mosquitto, так как не заботятся о правильной архитектуре топиков, уповая на "костыль", внедренный в IOBroker. Любое отступление от стандартов - это всегда плохо. 

 

MQTT в контроллере LightHub 

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

Сейчас частично поддерживается конвенция homie, которая определяет рациональную и унифицированную иерархию MQTT топиков устройства, а также, публикует служебную информацию, при помощи которой, системы управления смогут автоматически настраиваться на те устройства, которыми управляет контроллер.

Также, контроллер может работать одновременно с системами  OpenHab, HomeAssistant и IOBroker.  Также, участники сообщества адаптировали контроллер под Domotics.

Данные особенности, тем не менее, не мешают использовать MQTT для межмашинного взаимодействия уже сегодня. 

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

В статье использованы материалы из  Wikipedia и IPC2u 

 

Комментарии   

0 #1 Netwizard 23.11.2017 23:05
Здравствуйте,

на сколько я помню, на железках уровня atmega2560 SSL нет... как с безопасностью комуникаций? В контроллируемой среде (по кабелю) это плохо, но не кошмар, а вот wifi для таких железок автоматически закрывается от слова совсем.

mosquitto это легко и просто, но ненадежно. Не задумывались о варианте RabbitMQ в кластере с адаптером в mqtt протокол? Там вроде все "искаропки" поддерживается + без диких плясок с бубном можно подцепить авторизацию.
+1 #2 Super User 25.11.2017 16:15
Цитирую Netwizard:
Здравствуйте,

на сколько я помню, на железках уровня atmega2560 SSL нет... как с безопасностью комуникаций? В контроллируемой среде (по кабелю) это плохо, но не кошмар, а вот wifi для таких железок автоматически закрывается от слова совсем.

mosquitto это легко и просто, но ненадежно. Не задумывались о варианте RabbitMQ в кластере с адаптером в mqtt протокол? Там вроде все "искаропки" поддерживается + без диких плясок с бубном можно подцепить авторизацию.

Да, на AVR затруднительно поднять SSL, но для локальной связи с брокером пока проблемы не вижу. Со временем, смигрирую все же код на AVR и ESP - там мощность позволяет. После этого можно будет смело и без паранойи подключаться к внешним облачным брокерам. Не очень, правда, понимаю какая проблема с WiFi? WiFi сам по себе закрыт шифрованием и прослушивая его не перехватишь взаимодействие контроллера с брокером. Контроллер во всех смыслах лучше подключать проводом. Но даже пачка WiFi сенсоров, которые у меня подключаются по WiFi к брокеру без SSL, по моему, дополнительно не компрометируют безопасность.

Относительно надежности mosquitto, также, не уловил мысль. За два года после его установки (2 минуты из репозитория Ubuntu), я о нем более не вспоминал. Ни в каких глюках я данный брокер не заметил просто ни разу. Rabbit хорошая штука, но какие преимущества принесет связка RabbitMQ+MQTT адаптер?
0 #3 Алексей 25.11.2017 16:47
Цитирую Super User:

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


Ну вариант подлючения к внешним системам я даже не рассматриваю - мой внутренний параноик говорит, что мои данние являются моими только пока они у меня. А насчет "бесплатных" облаков товарищ Бобук сказал оценна правильно: вы или покупатель или товар - другого не дано.
+1 #4 Алексей 25.11.2017 16:49
Цитирую Super User:

Не очень, правда, понимаю какая проблема с WiFi? WiFi сам по себе закрыт шифрованием и прослушивая его не перехватишь взаимодействие контроллера с брокером.


Не давече чем месяц тому назад, wpa/2-psk "продемонстрировал" свою защишенность во всей красе. И никто не может гарантировать, что похожий facepalm не вылезет позже - так что защита коммуникации должна быть на каждом уровне - в случае какой-либо дыры велика вероятность что следующий слой не позволит нагадить в системе управления.
OFFTOP: мой личный опыт утверждает, что люди экономящие на безопастности на начальных стадиях разработки, на последних этапах платят со сторицей, на на проде - иногда и сворачиваются после первого-же инцидента безопасности.
0 #5 Алексей 25.11.2017 16:50
Цитирую Super User:

Контроллер во всех смыслах лучше подключать проводом. Но даже пачка WiFi сенсоров, которые у меня подключаются по WiFi к брокеру без SSL, по моему, дополнительно не компрометируют безопасность.


тот-же провод, выходящий за пределы контролируемой среды (напр. за физ. пределами дома, квартиры) автоматически перестает быть доверенной средой. WiFi по определению не может быть доверенной средой передачи: его можно снифить, делать инжекцию пакетов (MitM, принидительный разрыв соединения https://xakep.ru/2017/10/16/wpa2-krack/ ), да даже простое зашумление эфира с целью блокировки связи
0 #6 Алексей 25.11.2017 16:52
Цитирую Super User:

Относительно надежности mosquitto, также, не уловил мысль. За два года после его установки (2 минуты из репозитория Ubuntu), я о нем более не вспоминал. Ни в каких глюках я данный брокер не заметил просто ни разу. Rabbit хорошая штука, но какие преимущества принесет связка RabbitMQ+MQTT адаптер?

например, message persistance на случай рестарт брокера, гарантия доставки всем подписчикам. в отношении глюков такое я встречал: например, он не хотел пускать клиента с тем-же именем, если он уже был зареган в брокере (напр., timeout 120s для экономии батарейки при работе от акума по wifi)
С точки зрения HA - падение одного из брокеров не положит коммуникацию IoT, т.к. очереди кластерные, а VIP перекидывается на живую ноду тем-же heartbeat'ом
0 #7 Super User 25.11.2017 18:24
Цитирую Алексей:

например, message persistance на случай рестарт брокера, гарантия доставки всем подписчикам. в отношении глюков такое я встречал: например, он не хотел пускать клиента с тем-же именем, если он уже был зареган в брокере (напр., timeout 120s для экономии батарейки при работе от акума по wifi)
С точки зрения HA - падение одного из брокеров не положит коммуникацию IoT, т.к. очереди кластерные, а VIP перекидывается на живую ноду тем-же heartbeat'ом

Client-ID должен быть уникальный, это не бага а фича. В Вашем случае, перед засыпанием устройства, вероятно, помогло бы делать Disconnect от брокера. Персистентность mosquitto поддерживает.
По поводу кластеризации тут соглашусь. Хотя, это, скорее, для "ответственных" или промышленных применений. Кластер MQTT брокера для дома ИМХО перебор.
0 #8 Super User 25.11.2017 18:27
Цитирую Алексей:

Не давече чем месяц тому назад, wpa/2-psk "продемонстрировал" свою защишенность во всей красе. И никто не может гарантировать, что похожий facepalm не вылезет позже - так что защита коммуникации должна быть на каждом уровне - в случае какой-либо дыры велика вероятность что следующий слой не позволит нагадить в системе управления.

Ну если покопаться поглубже в этой уязвимости, то становится понятно, что ZeroKey позволяет перекинуть непропатченного WiFi клиента Android или Linux на фальшивую точку доступа, а далее, при помощи SSLStrip, например, сниффить пароли. В нашем случае, эта уязвимость ничего не добавляет и не прибавляет. Мобильные приложения на Андроид - становятся более уязвимы, до установки обновлений. WiFi датчик CO2 внутри с ESP8266, про ее уязвимость тут ничего не говорится. Конечно, при возможности, надо использовать SSL или TLS шифрование при подключению к брокеру. В принципе, можно аксеслистами ограничить незашифрованное соединение с брокером только контроллеру, подключенному по проводной сети. Всех прочих - пускать только на порт с шифрованием.
Провод внутренней докальной сети за периметр, конечно, тоже не дело выпускать.
0 #9 Алексей 25.11.2017 18:34
Цитирую Super User:
Ну если покопаться поглубже в этой уязвимости, то становится понятно, что ZeroKey позволяет перекинуть непропатченного WiFi клиента Android или Linux на фальшивую точку доступа, а далее, при помощи SSLStrip, например, сниффить пароли. В нашем случае, эта уязвимость ничего не добавляет и не прибавляет.


Zerokey + heartbleed - 2 наиболее яркие и наглядные демострация того, что то, что все считают незыблемым - таковым не является и может показать средний палец в самый неподходящий момент. Именно исходя из этого системы автоматизации и телеметрии должны проектироваться с требованями максимальной безопасности. Утрируя: Вам же не хочется, чтобы ваш уютный дом в час Х превратился в неуютную запертую халупу из-за того, что школьнику из соседней квартиры не понравились ваши комментарии по поводу его громко демонстрируемых всему дому, музыкальных вкусов :)
+1 #10 Super User 25.11.2017 18:48
Цитирую Алексей:

Zerokey + heartbleed - 2 наиболее яркие и наглядные демострация того, что то, что все считают незыблемым - таковым не является и может показать средний палец в самый неподходящий момент. Именно исходя из этого системы автоматизации и телеметрии должны проектироваться с требованями максимальной безопасности. Утрируя: Вам же не хочется, чтобы ваш уютный дом в час Х превратился в неуютную запертую халупу из-за того, что школьнику из соседней квартиры не понравились ваши комментарии по поводу его громко демонстрируемых всему дому, музыкальных вкусов :)

Ну для большинства домашних применений, даже гипотетический взлом WiFi и несанкционированое подключение к шине пока не могут привести к чему-то кроме мелкого неудобства. Но для более ответственных применений, там где есть угроза здоровью/жизни, конечно, решения должны быть другими. Доверить открывание дверей этой технологии, также рановато.
Все ПО тут опенсорсное, и будет очень хорошо, если в сообщество разработчиков добавится конструктивный параноик. Так, глядишь, оно станет пригодно и для другого класса применения. :-)

You have no rights to post comments

0
0
0
s2sdefault