mqtt что это такое
Проще, чем MQTT? MQTT/UDP
Хотел написать на эту тему подробную статью, но, очевидно, руки не доходят. Посему краткое сообщение. Я разработал и реализовал на нескольких языках в виде прототипного кода версию протокола MQTT под рабочим названием MQTT/UDP. Для нетерпеливых и тех, кому уже всё понятно и очевидно, код на Гитхабе
Я живу в квартире, которая почти полностью управляется собственной системой умного дома несколько лет. Управление светом, климатом, датчики, лёгкая автоматизация, вот это всё.
За это время я выяснил (да, впрочем, и до того понимал), что главное свойство систем УД — надёжность.
Все системы с центральным узлом по определению ненадёжны. Отсюда — желание получить интерконнект компонент системы (а их в реальном умном доме много) без использования какого-либо центрального хаба.
При этом исходим из того, что в целом трафик систем УД невелик — датчики редко нуждаются в апдейте чаще раза в минуту, остальные данные имеют событийный характер (включили свет), и по трафику совершенно несущественны. Даже ежесекундное обновление всех данных в системе не является не только катастрофой, но и даже существенной проблемой.
Логичный вывод — UDP бродкаст является идеальным инструментом.
(Да, я предполагаю, что внутренняя сеть квартиры закрыта файрволлом.)
Невероятно простая реализация. Минимальный микроконтроллер с крошечной памятью сумеет послать UDP-пакет. Для датчика даже приём UDP не нужен.
Нет центральной точки отказа в хабе/брокере. Рассмотрим простую схему: два датчика температуры, контроллер тёплого пола, контроллер батарей отопления. С применением MQTT/UDP отказ любой части такой системы не приводит к отказу системы в целом.
Низкий трафик в сети. Ниже некуда. TCP и подтверждения только добавляют трафика, но не добавляют надёжности. Отказавший датчик не заработает от получения TCP ACK. А отказ мы и так выявляем по отсутствию обновлений.
Ненадёжность самого протокола UDP несущественна — датчики всё равно обновляют данные регулярно, и пропадание отсчёта совершенно незаметно, а пропадание команды с, например, выключателя визуально подтверждается несработкой целевой системы. Что делает человек? Щёлкает ещё раз. Тем не менее, это — главный ограничитель применимости протокола. Идеален для повторяющихся опросов.
Не нужна конфигурация системы. Никому не нужно прописывать адрес брокера, хаба и т.п. Впрочем, всё равно нужна конфигурация датчика — требуется прописать идентификатор датчика. Но при переносе других частей системы на другие сервера переконфигурация ответных компонент не потребуется.
Отдельно интересно, что эта модель обмена данными хорошо ложится на натурально бродкастные среды, такие как радиоканал или RS/485. Я с этим не экспериментировал, и протокол в таких средах нуждается в контроле. Логично здесь применить CRC16 от modbus, кстати.
Минусы также очевидны: надежность доставки определяется только хардвером и трафиком в сети, ну и если в сеть пробрался враг, то протокол повержен сразу. Правда, будем откровенны, взлом иных типичных протоколов умного дома — дело секунд, так что это — спорный недостаток MQTT/UDP. Ещё один неочевидный минус — максимум один приёмник на IP-адрес.
Что сделано и лежит в репозитории в исходниках:
Что такое MQTT
После того как я стал стал строить умный дом я очень быстро столкнулся с вещью под названием MQTT. Оказывается, некоторые устройства могут «разговаривать с MQTT», а система умного дома может «забирать из MQTT» данные. Происходит «отправка сообщений в топики». Изначально мне было совершенно непонятно что как это все работает и зачем это. Как оказалось, это все не очень сложно.
Я написал этот текст специально для людей кто никогда раньше не сталкивались с MQTT.
История возникновения MQTT
MQTT — это такой специальный протокол по которому умеют общаться программы и устройства. Есть русский язык и люди которые умеют разговаривать на этом языке могут понять друг друга. Точно так же есть «язык» MQTT — программы и устройства которые умеют разговаривать на этом языке могут общаться друг с другом.
Для передачи данных использовалась спутниковые телефоны, которые и сейчас очень дорогие, а 20 лет назад были очень-очень дорогие. Поэтому технология передачи должна была быть как можно более экономной — передавать как можно меньше данных.
Протокол MQTT смог успешно решить эта задачу и стал применяться и в других отраслях. Постепенно компьютеры и микропроцессоры становились все дешевле и это привело к тому что стала появляться куча разных устройств в которые добавили «ума» (для этого придумали красивый термин IoT — Internet of Things — Интернет Вещей). Умный чайник, умный обогреватель — эти устройства могут отправлять данные про себя (какая сейчас температура, сколько устройство работает), а так же удаленно получать команды на управление.
Есть множество устройств разных производителей — как им общаться друг с другом и с серверами умного дома? Можно взять и придумать новый язык (протокол) и многие производители так и делают. Но есть протокол MQTT которые отлично подходит для общения разных устройств и программ. Некоторые производители используют MQTT в своих устройствах. MQTT популярен в мире бесплатных и открытых программ (Open Source).
Программа MQTT Explorer
Если вы работаете с MQTT, то вам нужно обязательно скачать и поставить программу MQTT Explorer.
Программа бесплатная. Программа работает на Windows, на macOS и на Linux.
С помощью этой программы можно подключиться к MQTT серверу и увидеть все то что там происходит.
MQTT брокер
MQTT — это протокол который работает по модели клиент-сервер.
Центральная часть — это MQTT сервер. Обычно сервер MQTT называют MQTT брокер.
Есть очень популярная программа Mosquitto — если запустить эту программу, то у вас появится работающий MQTT сервер.
Далеко не всегда нужно самому запускать MQTT сервер. Многие системы сами поднимают MQTT сервер с которыми работают.
Клиенты
К серверу MQTT подключаются клиенты. Клиенты могут отправлять сообщения и читать сообщения. Некоторые клиенты только отправляют, некоторые только читают, но достаточно часто клиент делает и то и другое: и отправляет сообщения и слушает другие сообщения.
Чтобы клиент мог подключиться к MQTT серверу нужно указать:
Топики и отправка сообщений
Итак, есть MQTT брокер — центр системы. Есть клиенты которые подключаются к этому центру.
Давайте разберем задачу. Есть датчик температуры и есть система умного дома. Как с помощью MQTT датчик может передать температуру в систему умного дома?
Датчик температуры подключается к серверу MQTT. Раз в 5 минут датчик производит замер температуры и отправляет результат замера в сервер MQTT. Например, температура 23.8 °C
Для того чтобы отправить температуру в MQTT датчик должен знать две вещи. Во-первых, саму температуру, она есть — 23.8. А во-вторых датчик должен указать адрес топика в который будет отправлено это значение. Что же такое топик? Чуть-чуть отойдем в сторону. Представим что нужно сохранить число 23.8 на компьютер. Можно сохранить в файл. Для этого нужно знать полный путь к файлу. Например, c:\temperature\sensor.txt — в этом файл мы можем записать число 23.8
Топик очень похож на файл — это расположение какого-то кусочка информации в MQTT сервере. Датчик температуру может отправить сообщение 23.8 в топик temperature/sensor — теперь MQTT сервер знает про это число.
Половину задачи решели — датчик температуру отправил значение температуру в MQTT сервер.
Как же система умного дома узнает о том что датчик прислал новую температуру? При подключении к серверу MQTT система умного дома говорит — я хочу получить все данные которые приходят в топик temperature/sensor MQTT сервер запоминает это желание клиента и как только в топик temperature/sensor приходит какое-то значение сервер пересылает это сообщение всем клиентам кто выразил желание получать сообщение из этого топика (это называется кто «подписался» на эти топики»)
Символ решетка
Клиент при подключении к MQTT серверу может указать список топиков которые он хочет «слушать» (т.е. получать все сообщения которые поступают в эти топики)
При подписке можно указать символ решетка. Например, если клиент говорит что он хочет подписать на temperature/# то этот клиент получит все сообщения которые будут отправлены вот в такие топики:
Так же клиент может подписать на топик # — это ознчает что он будет получать вообще все сообщения которые прилетают в MQTT сервер.
Retain Флаг
MQTT сервер — это всего лишь посредник между разными клиентами. Клиент отправил сообщение в MQTT сервер, сервер переслал это сообщение всем клиентам, которым интересно это сообщение и сервер тут же забыл про это сообщение. Новые клиенты которые подключаются к MQTT серверу уже не получат это сообщение.
Пример. Есть датчик температуры и есть система умного дома. Штатный режим работы. Система умного дома подключилась к MQTT серверу и слушает все сообщения. Датчик температуры подключился к MQTT серверу и каждые 5 минут отправляет данные про температуру. Все работает прекрасно — датчик отправл температуру, MQTT сервер переслал эту температуру в систему умного дома и умный дом отобразил эту температуру в интерфейсе.
Но тут происходит ситуация что нужно перезагрузить систему умного дома. Умный дом перезапустился, и заново подключился к MQTT серверу, но никакой информации о температуре в MQTT сервере нет (те сообщения которые были раньше уже переданы всем клиентам и никуда на MQTT сервере не сохранились). Пока датчик не отправит новое значение система умного дома не получит температуру из MQTT сервера.
Решение такой ситуации — это флаг retain. При отправке сообщения клиент может сказать что это сообщение нужно отправить с флагом retain, т.е. сервер должен сохранить сообщение. В этом случае сервер получит сообщение, переправит его всем клиентам, но не забывает про это сообщение, а оставляет его у себя и будет отправлять это же сообщением всем новым клиентам которые подключились к MQTT серверу.
Last will
Одна из интересных фишек протокола MQTT — это штука под названием Last will — завещание. Еще используют аббревиатуру «LWT» — Last Will and Testament.
Стандартная работа — клиент подключается к MQTT серверу и все время остается подключенным к серверу (сервер «видит» момент подключения и может понять когда клиент отключился).
Задача. Есть клиент — компьютер — он должен быть всегда подключен к MQTT серверу. Если этот компьютер не подключен к MQTT серверу — это авария, что-то случилось либо с этим компьютером, либо с каналом связи. Как об этой аварии могут узнать другие клиенты?
Решение следующее: клиент при подключении говорит серверу: «слушай, когда я отключусь, ты, пожалуйста, вот в этот топик положи вот такое сообщение». Сервер принимает такое «завещание» от клиента и когда этот клиент отключается, MQTT сервер выполняет «последнюю волю» клиента.
Например, клиент может попросить сервер отправить сообщение «offline» в топик «computers/my-desktop/status». И когда этот клиент отвалится MQTT сервер отправит сообщение «offline» в нужный топик. Клиент подключился, сказал MQTT серверу что при отключении нужно отправить в топик значение «offline» и тут же отправляет в этот же топик значение «online». Тогда все другие клиенты которым интересен статус этого клиента могут следить за этим топиком — если там «online» значит с компьютером все нормально, если «offline», то есть проблема.
Платформа ARM и брокер MQTT, как современная основа решений для Интернета вещей
Протокол MQTT, на текущее время, завоевал свою популярность и стал стандартом де факто в проектах, направленных на создание решений для Интернета вещей (IoT). Конечно, Интернет вещей – это определенная абстракция или, правильнее, концепция построения распределенных сетей устройств или машин. При этом, частные задачи взаимодействия машин Machine-to-Machine (M2M), уже сегодня эффективно решаются, включая и уровень подключения этих систем к Интернет, как для создания промышленных систем автоматики, так, например, и для построения систем «умного дома». Очевидно, что для критически важных систем требуется наличие локального арбитра или брокера и устройств, позволяющих отработать решение ситуации не зависимо от качества Интернет-подключения, а также в случае полного разрыва связи.
При этом, в качестве аппаратной платформы для запуска такого брокера MQTT, отлично себя зарекомендовали энергоэффективные, но от этого не менее производительные, микропроцессоры на базе архитектуры ARM. Такая взаимосвязь аппаратной платформы, протоколов обмена сообщениями и их программной реализации стала отправной точкой в стремительном прогрессе развития современных систем автоматизации. Далее рассмотрим подробнее аппаратные решения и программные компоненты для реализации одного из наиболее успешных протоколов обмена сообщениями в технических системах.
ClusterHAT review: Raspberry Pi cluster computer kit. Photo: MagPi magazine
Архитектура микропроцессоров ARM (Advanced RISC Machine) прочно вошла в нашу жизнь. Практически каждый смартфон уже сейчас работает на базе этой архитектуры. Стоит отметить, что понятие RISC-машина на сегодня достаточно размыто, ведь и ее противоположность – современная платформа x86-64, позаимствовала многое из мира RISC-систем. Но речь не об этом, а о том, что она на сегодня стала синонимом или отличительной особенностью производительной и, при этом, энергоэффективной мобильной платформы, а также основой для различных недорогих DIY или «сделай сам» устройств. В этом контексте, конечно, нельзя не упомянуть различные варианты Raspberry Pi, вплоть до решения кластера на базе платы ClusterHAT и т.п. В качестве основной операционной системы для этой платформы отлично себя зарекомендовала Linux. Но и тут, как не вспомнить, например, о такой системе, как Microsoft Windows 10 IoT Core?
Хорошо, когда есть выбор, но не все так просто, как хотелось бы. Microsoft Windows 10 IoT Core – это замечательная операционная система, но она, в первую очередь, предназначена для разработки и запуска программ, например, написанных на языке С# в среде Microsoft Visual Studio. Такой подход универсальным не назовешь. Поэтому, пока классическим выбором для большинства задач остается ARM и Linux, а также Android, как же без него. Отметим, что для быстрого прототипирования кроме плат Raspberry Pi есть и более дешевые Orange Pi компании Xunlong Software или, наоборот, более дорогие ODROID компании Hardkernel, но при этом вполне оправдывающие свою цену. Все зависит от решаемой задачи. А таковой, для текущего проекта, стал запуск сервера/брокера MQTT. При этом, не следует акцентировать внимание на то, что проект посвящен «умному дому» или решениям для робототехники. Это не принципиально, поскольку протокол MQTT – сам по себе является очень универсальным решением.
CPU-351-13. Low Power, Rugged i.MX6 SBC. Photo: Eurotech
Кроме промышленных решений архитектура ARM проникает на рынок серверных решений. Здесь интересен опыт компании Scaleway, которая развертывает и дает в аренду не обычные виртуальные машины, а физические сервера на базе ARMv8. Это решение интересно своей энергоэффективностью, с позиции провайдера, и отсутствием гипервизора или среды виртуализации, как таковой, для пользователя сервиса. Таким образом, становится реальностью отличная среда для запуска Docker-контейнеров. Это напоминает что-то вроде ClusterHAT в промышленных масштабах, а по производительности – отличный выбор для контейнерной виртуализации в облаке. В целом нельзя не согласиться, что это смелое, новаторское бизнес-решение в направлении хостинг услуг, которое уже достаточно продолжительное время существует на рынке. Получается, что если не покупать свой Raspberry Pi или аналог, то всегда можно поэкспериментировать с сервером на базе ARM, взяв его в аренду.
CloudMQTT is a perfect solution for «Internet of Things» messaging
Завершая выбор аппаратной платформы и хвалу архитектуры ARM, можно на этом поставить точку, но следует не забывать, что всегда можно найти альтернативное решение, а это только и подталкивает энтузиастов, гиков, этических хакеров к новым исследованиям и экспериментам с открытыми аппаратными платформами. Итак, у нас стоит задача на базе Linux установить брокер MQTT и немного с ним поэкспериментировать.
Можно было вообще не рассматривать аппаратную платформу, а сразу перейти к работе в облачном сервисе CloudMQTT. Но рассматривается задача на базе трехуровневой структуры Интернета вещей, где на нижнем уровне находятся интеллектуальные датчики и управляющие системы. Середина – это место брокера MQTT, причем он должен быть расположен локально, чтобы проблемы с доступом к Интернет можно было частично решить внутренним оборудованием. А верхний уровень – облако с интерфейсом Node-Red или AWS IoT, Azure IoT Hub и т.п. В такой концепции сложно представить лучшего кандидата на место энергоэффективного и очень бюджетного микро-сервера, что-то отличное от ARM.
Но так устроен мир, нельзя сказать, что все отлично или, наоборот, все плохо. Везде есть свои нюансы. Дело в том, что рассматриваемая трехуровневая система – это не совсем Интернет вещей, скорее, это некий промежуточный вариант пути к такой концепции. Просто IoT без Интернет-соединения не должен существовать, т.е. не зря мы ожидаем появления беспроводных сетей пятого поколения, усовершенствование существующих коммуникаций и т.п. В концепции Интернета вещей нет места для уровня промежуточного слоя, датчики и исполнительные системы должны выходить напрямую в облако, где и будет происходить их взаимодействие.
A Brief, but Practical Introduction to the MQTT Protocol and its Application to IoT. Picture: Zoetrope labs
Протокол MQTT (Message Queuing Telemetry Transport) – это асинхронный протокол передачи телеметрических сообщений по принципу издатель/подписчик с использованием брокера. Этот протокол был разработан IBM и переведен в разряд открытых проектов организации Eclipse Foundation. Особенностью протокола является его компактность, т.к. величина заголовка пакета данных составляет всего лишь несколько байт. Он работает поверх стандартного протокола TCP и, для обеспечения безопасности, предполагает использование механизмов аутентификации на уровне «username/password» и использование шифрования транспортного протокола TLS/SSL. На текущее время, протокол MQTT стал стандартом де-факто для построения решений Интернета вещей.
Поскольку MQTT разработан для использования в среде Интернет-соединения, которое по определению стоит считать не надежным, протокол предусматривает три уровня обеспечения качества сервиса доставки. QoS 0: At most once – «не более одного». Издатель публикует сообщение на брокере, затем брокер публикует его для подписчика. На этом уровне не гарантируется обязательная передача данных подписчику. QoS 1: At least once – «хотя бы один». Подписчик должен получить данное сообщение как минимум один раз. Однако, сообщения могут дублироваться и это должен предусматривать в логике своей работы подписчик. QoS 2: Exactly one – «гарантированно один». Обеспечивает высшую гарантию доставки и отсутствие дублирования сообщений.
Для масштабирования своих решений можно воспользоваться конфигурацией типа «мост» между брокерами, и тем самым снизить нагрузку на каждый брокер в отдельности. Так же протокол MQTT позволяет подписчикам получать данные сразу по нескольким каналам. Для этого применяют wildcard-символы «+» и «#», чтобы отметить либо все записи в определенной подписке, либо только блок сообщений. Например, подписка на несколько разных датчиков температуры: «sensors/+/temperature/+» или сразу подписка на все каналы: «#». Можно еще долго обсуждать особенности протокола, но проще попробовать на реальном примере. В качестве брокера можно выбрать множество решений, но одним из самых популярных и легковесных брокеров является Mosquitto.
Для разворачивания брокера Mosquitto выберем простой вариант одноплатного компьютера, например, одну из первых версий Raspberry Pi Model B 512MB RAM. Данный выбор продиктован буквально тем, что находилось под рукой. Конечно, для реального проекта, следует отдельно изучить вопрос о надежности и производительности платы и, кроме выбора оптимальных аппаратных решений, также следует проработать вопросы: надежности корпуса, качества блока питания, безопасности системы в целом и т.п. Плату Raspberry Pi еще было интересно взять, чтобы окончательно развеять миф о трудностях старта проекта на базе открытых аппаратных решений и операционной системы Linux. Конечно, от разработчика требуются базовые знания, но современные платформы стали исключительно дружественными с точки зрения программного интерфейса и при этом хорошо документированы.
Photo: Raspberry Pi Model B 512MB RAM
В качестве операционной системы можно сделать выбор в сторону официальной прошивки Raspbian Stretch with desktop или Raspbian Stretch Lite. Это две одинаковые операционные системы на базе известного дистрибутива Debian Stretch, который модифицировали для работы с Raspberry Pi. Отличия, только в наличие графического рабочего стола, что для начала ознакомления вполне оправдано, но для сервера, конечно, графическая оболочка не к чему. Для установки выберем все-таки вариант с графическим рабочим столом и все это установим на недорогую флешку 8GB SD card. Фактически, остается загрузить образ операционной системы и при помощи очень удобной кроссплатформенной утилиты Etcher перенести образ на физический накопитель.
Screenshot: Etcher in Windows 10
Теперь остается поместить прошитую флешку в плату Raspberry Pi и подать питание. Есть ода особенность, если потребуется получить удаленный доступ к командной строке Raspbian Stretch по протоколу ssh, при этом нет клавиатуры, физически подключенной к плате, то можно записать пустой файл с именем ssh в загрузочный раздел флешки, что позволит активировать соответствующий доступ. После включения и Raspberry Pi доступ к операционной системе разрешен пользователю «pi» по паролю «raspberry». Пользователь по умолчанию «pi» может получить права root, выполнив команду sudo. Поскольку в Raspbian все подготовлено для комфортной работы неподготовленного пользователя, то первой командой в новой системе может стать вызов меню конфигурирования системы:
Screenshot: Remote connection to Raspberry Pi by SSH and run raspi-config
Утилита raspi-config позволяет задать новый пароль пользователю и, например, в меню «Interfacing Options» можно настроить поведение интерфейсов системы, разрешить удаленный рабочий стол по протоколу VNC и т.п. Так же в меню: «Boot Options» можно установить параметры по умолчанию для загрузки системы, например выбрать только режим командной строки, а в под-меню «Resolution» из меню «Advanced Options» установить нужное разрешение графического экрана, например, выбрав требуемый размер «DMT» – для цифрового интерфейса монитора или «CEA» – аналогового входа и т.п.
Теперь можно обновить пакеты системы:
$ sudo apt-get update
$ sudo apt-get upgrade
И установить брокер Mosquitto и клиента MQTT, например, для тестирования системы:
$ sudo apt-get install mosquitto
$ sudo apt-get sudo mosquitto-clients
Screenshot: Raspberry Pi terminal sessions
Просматривать подписки и делать публикации по протоколу MQTT, а также выполнить тестирование нагрузочной способности брокера, можно в среде браузера Chrome и операционных систем: Linux, Mac, Windows благодаря кроссплатформенному приложению MQTTBox.
Действительно, протокол MQTT сейчас стал настолько распространен, что не найти удобное решение для своих задач просто невозможно. Так же в рамках проекта Eclipse Paho активно развивается разработка открытых программных решений и библиотек, практически на всех языках программирования, для реализации протокола обмена сообщениями MQTT и, тем самым, совершенствования решений для Интернета вещей.
Построение решений на базе брокера MQTT становится уже тривиальной задачей. Стоит лишь развернуть систему, подключиться к облаку, например, используя Node-RED или специализированное решение и остается дело за «малым» — подключить интеллектуальные датчики и исполнительные механизмы. Для рассмотрения нижнего уровня систем IoT следует написать отдельную статью, но для данного примера вполне можно обойтись рассмотрением примера на базе фактического стандарта для Интернета вещей – платы NodeMCU на базе SoC ESP8266 компании Espressif.
Screenshot: MQTTBox in Windows 10
Плата NodeMCU изначально ориентирована на разработку на языке eLua. Для сборки прошивки можно использовать облачный сервис, а сама плата проекта существует виде открытого аппаратного решения NodeMCU DEVKIT V1.0, для которого уже выпущено множество аналогов. При этом следует отметить хорошую документацию проекта. Однако, очень субъективно, но при разработке интеллектуального датчика с протоколом MQTT на базе прошивки с eLua для NodeMCU DEVKIT все же придется встретиться с рядом трудностей с реализацией протокола MQTT. При этом вся инфраструктура проекта выглядит как-то недостаточно подготовленной к использованию в качестве среды для быстрой и качественной разработки микропроцессорных систем. Всегда всплывают какие-то мелочи и нюансы, но еще раз стоит повториться – это очень субъективная оценка. Интересно, а у читателей блога есть успешный опыт с eLua и MQTT?
Совершенно другое дело – выбор среды разработки Arduino IDE для работы с NodeMCU DEVKIT, впрочем, как и с другими платами на базе ESP8266. Все делается практически моментально на базе готовых библиотек и примеров кода. Для начала разработки следует с официального сайта проекта Arduino скачать открытую кроссплатформенную среду разработки Arduino IDE. Затем в параметрах «File» — «Preferences» — «Addition Boards Manager URLs:» указать ссылку на проект Arduino core for ESP8266 WiFi chip: arduino.esp8266.com/stable/package_esp8266com_index.json После этого в «Tools» — «Boards Manager» остается загрузить и установить поддержку для плат ESP8266 Community. Кстати, не следует забывать о том, что для работы с платой NodeMCU потребуется установить драйвер интерфейсного преобразователя CP210x или, его еще называют мост UART к USB.
Photo: Работа с платой NodeMCU
Для работы с протоколом MQTT можно установить библиотеку PubNub Arduino Library. Для этого в меню «Sketch» — «Include Library» — «Manage Libraries» выбрать соответствующую библиотеку и установить. Ознакомиться с возможностями программной платформы можно на базе примера кода, например, Basic ESP8266 MQTT example, где на брокере публикуется канал «outTopic», а также устанавливается подписка на «inTopic», и когда приходит на «inTopic» значение «1», то на плате включается встроенный светодиод. Все просто, быстро и отлично работает из коробки.
Screenshot: Arduino IDE with ESP8266 support
В завершении хочется отметить, что эта публикация не призывает использовать исключительно архитектуру ARM-процессоров для построения систем Интернета вещей и она лишь затронула особенности внедрения MQTT-брокера, как связующего звена для решений в области автоматизации. Но при этом у читателя может сформироваться мнение, что на сегодня решения для IoT – это удел гиков, экспериментаторов и фанатов, например, плат Raspberry Pi. Это верно, на этом и держится прогресс, но будущее уже с нами.
Пример, очевиден: коммерческое решение платформы беспроводных датчиков Wzzard для IoT и шлюза Spectre Network Gateway компании Advantech B+B SmartWorx. Здесь, как и во многих на сегодняшний день внедрений в производственные циклы, предложена архитектура защищенных от внешней среды промышленных датчиков, которые объединяются беспроводной сетью, основанной на стандартах 6LoWPAN и IEEE 802.15.4e. Для обработки данных на уровне облака предлагается шлюз с поддержкой протокола MQTT и передачей данных по коммуникациям беспроводной 3G-сети или проводного 10/100 Ethernet.