Протокол для настройки параметров устройства IoT

MQTT широко используется в IoT, когда речь идет об обмене данными приложения между конечным устройством и хост-службой. Модель публикации-подписки делает ее простой в использовании: отсутствие рукопожатия, согласование и т. Д. (По крайней мере, выше уровня протокола MQTT). Он в первую очередь ориентирован на то, чтобы производители данных могли легко распространять свои данные среди потребителей.

Однако, когда речь идет о центральном сервере, который хочет настроить параметры на конечном устройстве, я не уверен, что модель очень подходит. Сервер захочет отправить команду устройству и дождаться ответа (например, прочитать определенный параметр, дождаться ответа), который на самом деле не подходит для модели MQTT «публикация-подписка».

Мне было интересно, существуют ли какие-либо существующие протоколы, предназначенные для отправки и получения команд и настройки удаленных устройств?

networking mqtt protocols

— Амр Бехит
источник

Вы уверены, что MQTT не позволяет клиенту подписаться на канал управления? Я думаю, что это то место, где можно начать искать ответы, но я недостаточно хорошо разбираюсь в ответах en.wikipedia.org/wiki/Representational_state_transfer

— Шон

Не забывайте, что конечная точка должна быть той, которая инициирует канал, поэтому она контролирует энергопотребление.

— Шон

@SeanHoulihane Конечно, можно использовать MQTT для отправки и получения команд / настроек, как вы описываете, но, как я понимаю, в идеале вам нужен протокол, основанный на сеансах, т.е. вы создаете сеанс, отправляете команду и получить ответ в том же сеансе, таким образом, легко связывая ответ с исходной командой. MQTT основан на сообщениях, поэтому связывать сообщения друг с другом совсем нечего - это ваша задача. Мне было интересно, есть ли доступный протокол, который я мог бы использовать для этой цели.

— Амр Бехит

en.wikipedia.org/wiki/OMA_LWM2M Я не совсем уверен, как именно, но облако, по-видимому, может выполнять вызовы PUT или POST для запуска обратного вызова в клиенте.

— Шон

MQTTv5 имеет поля заголовка, чтобы пометить сообщение как ответ на предыдущее сообщение.

— Hardillb

Ответы:

Похоже, работа для CoAP :

Как и HTTP, CoAP основан на чрезвычайно успешной модели REST: серверы делают ресурсы доступными по URL-адресу, а клиенты получают доступ к этим ресурсам с помощью таких методов, как GET, PUT, POST и DELETE.

С точки зрения разработчика, CoAP очень похож на HTTP. Получение значения от датчика мало чем отличается от получения значения из веб-API.

По-видимому, это может быть реализовано с очень низкими издержками:

CoAP был разработан для работы на микроконтроллерах с объемом оперативной памяти 10 КБ и объемом кода 100 КБ

CoAP определен в RFC 7252 , и существуют различные реализации (например, в C ).

Он очень вдохновлен REST, который используется с HTTP для веб-API, поэтому, если вы знакомы с ним, вы быстро выберете CoAP. Если нет, вы можете найти эту презентацию полезной для контекста. Идея заключается в том, что каждый метод HTTP имеет семантическое значение, например, GETзапрашивает информацию с устройства, ничего не меняя и POST, PUTи изменяет DELETEданные.

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

— Аврора0001
источник

Мне было интересно, существуют ли какие-либо существующие протоколы, предназначенные для отправки и получения команд и настройки удаленных устройств?

Да, в IoT есть лучший протокол для управления устройствами. Это LwM2M - он намного эффективнее, чем MQTT и выше COAP, MQTT и HTTP.

LwM2M поставляется с четко определенной моделью управления данными и устройствами, предлагая различные готовые к использованию стандартные объекты (интеллектуальные объекты IPSO), мониторинг подключений, действия удаленных устройств и структурированные обновления FOTA и SOTA, тогда как в MQTT эти функции полностью в зависимости от поставщика и платформы. Далее следует, что с помощью MQTT обновления микропрограммного обеспечения или любые другие функции управления должны создаваться с нуля. В отличие от этого, LwM2M предлагает обновления встроенного программного обеспечения в качестве одной из основных функций, поэтому нет необходимости изобретать какие-либо новые строительные блоки для связи.

Здесь у вас есть сравнение MQTT против LwM2M и весь ускоренный курс.

— Барбара Поттер
источник