На данный момент существует много протоколов для Интернета вещей: CoAP, MQTT, AMQP… В этом руководстве познакомимся с протоколом MQTT – это один из хорошо известных протоколов Интернета вещей. Он предназначен для управления данными и их передачи между устройствами в сети Интернета вещей.
MQTT расшифровывается как Message Queuing Telemetry Transport (Передача телеметрии очередью сообщений).
Протокол имеет следующие основные особенности:
- используется механизм издатель/подписчик/топик;
- асинхронный протокол;
- компактные пакеты;
- работает поверх стека TCP/IP;
- требуется меньшая пропускная способность сети и может работать в условиях нестабильного канала передачи данных.
В основе работы протокола MQTT лежит традиционная модель клиент-сервер. Согласно этой модели, есть один сервер (также называемый брокером) и много клиентов. Клиенты всегда поддерживают связь с сервером. Задачами сервера (брокера) являются фильтрация и передача сообщений для клиентов-подписчиков.
Связь между клиентами основана на механизме издатель / подписчик / топик, в котором:
- сообщениям присваивают топик;
- издатель отправляет сообщения в сеть;
- подписчик ожидает сообщения, содержащие нужный ему топик;
- брокер координирует связь между издателями и подписчиками.
Топик представляет собой строку символов в кодировке UTF‑8 и состоит из одного или нескольких уровней, которые разделены между собой символом «/». Например: «этаж1 / комната1 / температура»: этот топик состоит из трёх уровней, лёгко понимаемых человеком (это этаж 1, комната 1 и температурный датчик).
Кроме этого существуют ещё некоторые термины, о которых необходимо знать:
QoS (Quality of Service – качество обслуживания): неформально, этот показатель обозначает вероятность прохождения пакета между двумя точками сети. Существуют следующие модели QoS:
- QoS 0 — на этом уровне издатель отправляет пакет брокеру без подтверждения доставки (этот уровень самый быстрый, но ненадёжный);
- QoS 1 — на этом уровне пакеты гарантированно доставляется брокеру, но существует вероятность дублирования сообщения от издателя. После получения дублированного сообщеня брокер заново делает рассылку подписчикам, издателю снова отправляет сообщение о получении. В случае если издатель не получает PUBACK сообщения от брокера, то осущуствляется повторная отправка пакета, а DUP присваивается значение “1”. Этот уровень используется по умолчанию.
- QoS 2 — гарантируется доставка сообщений подписчику и исключается вероятность дублирования отправленных пакетов. Здесь издатель отправляет пакет брокеру. Указывается уникальный PacketID, QoS=2 и DUP присваевается значение “0”. До тех пор, пока от брокера не получен ответ PUBREC издатель хранит сообщение неподтверждённым. Брокер должен ответить сообщением PUBREC, которое содержит тот же PacketID. ПРосле того, как пакет получен, издатель отправляет с тем же PacketID PUBREL. Пока брокер не получил PUBREL он хранит пакет у себя. После получения PUBREL копия сообщения удаляется, а издателю отправляется PUBCOMP об успешном завершении транзакции. Это самый надёжный уровень, но самый медленный.
Сохраняемые сообщения: брокер сохраняет такие сообщения после отправки, поэтому если появиться новый подписчик, интересующийся топиком этого сообщения, то оно будет отправлено ему.
Большинство библиотек, реализующих протокол MQTT, определяют несколько стандартных методов, таких как:
- Connect(): подключиться к серверу.
- Disconnect(): отключиться от сервера.
- Subscribe(): подписаться на топик сообщений, идущих от сервера.
- UnSubscribe(): отписаться от топика сообщений, идущих от сервера.
- Publish(): публикация клиентом топика в сеть.
Для демонстрационного примера мы создали простую сеть для Умного дома с тремя узлами-клиентами (смартфон, микропроцессорное управляющее устройство с интерфейсом Wi‑Fi и датчиком температуры, микропроцессорное управляющее устройство с интерфейсом Wi‑Fi и светодиодом (лампой)) и одним узлом-сервером, служащим в качестве брокера (ПК или плата Raspberry Pi).
В нашем случае мы хотим использовать смартфон для отслеживания температуры и управления (включение и выключение) светодиодом или лампой. Поэтому мы создали систему с реализацией протокола MQTT, описанную ниже.
10 комментариев. Оставить новый
Как рас занимаюсь тем же вопросом, на том же железе. Статья – огонь, спасибо )
“#define DHTPIN 14 ?
#define DHTTYPE DHT22” сомневаюсь в назначении пина,ранее было указано
[ESP32 IO15 — DHT22 DATA] на плате NodeMCU Lua ESP8266 это D8. Не ошибка, ли?
Верно указали. Распиновка, в зависимости от версии отладочной платы может различаться. Лучше ориентироваться на распиновку непосредственно той платы, которую используете в проекте.
Топик 1: smarthome/room1/bulb #value (смартфон/комната1/лампа #значение)
smarthome – это умный дом, не смартфон
Просто спасибо !)
Компилятор ругается на строку – WiFi.begin(ssid, password);
“exit status 1
invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]”
Здравствуйте! Ругается, потому что в данной строке надо ввести доступы к своей сети, к которой желаете подключить контроллер
Здравствуйте. Я вот не понимаю, зачем огород городить с MQTT? Если данные можно передать\получить используя, например, личный сайт? В скрипте потребуется написать всего лишь шесть строк кода для передачи\получения. У меня так управление с Алисой организовано.
Здравствуйте! Как-бы статья посвящена протоколу MQTT, поэтому речь и идет о нем.
почему то происходит reconnect to mqtt независимо от какого брокера, не знаю как решить проблему