Протокол налаштування параметрів пристроїв IoT


9

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

Однак, якщо мова йде про центральний сервер, який хоче налаштувати налаштування на кінцевому пристрої, я не впевнений, що модель дуже підходить. Сервер захоче надіслати команду на пристрій і чекати відповіді назад (наприклад, прочитати певний параметр, чекати відповіді), що не дуже відповідає моделі MQTT для публікації та підписки.

Мені було цікаво, чи існують протоколи, які спрямовані на надсилання та отримання команд та налаштування віддалених пристроїв?


1
Ви впевнені, що MQTT не дозволяє клієнту підписатися на канал управління? Я думаю, що це місце, щоб почати шукати відповіді, але я недостатньо швидкий, щоб підвести підсумки у відповіді en.wikipedia.org/wiki/Representational_state_transfer
Шон Холіхане

1
Не забувайте, кінцевою точкою повинен бути ініціатор каналу, тому він контролює споживання енергії.
Шон Хуліхане

1
@SeanHoulihane Безумовно, можна використовувати MQTT для надсилання та отримання команд / налаштувань так, як ви описуєте, але так, як я це бачу, в ідеалі вам потрібно мати протокол, який базується на "сеансі", тобто ви створюєте сеанс, відправляєте команду і отримують відповідь у тому ж сеансі, таким чином легко пов'язуючи відповідь з початковою командою. MQTT базується на повідомленнях, тому взагалі немає нічого, щоби зв’язувати повідомлення один з одним - ви вирішуєте цю частину. Мені було цікаво, чи є легко доступний протокол, який я міг би використовувати для цієї мети.
Амр Бехіт

1
en.wikipedia.org/wiki/OMA_LWM2M Я не впевнений, як саме, але хмара, здається, може робити дзвінки PUT або POST, щоб викликати зворотний виклик у клієнта.
Шон Хуліхане

MQTTv5 має поля заголовка для позначення повідомлення як відповіді на попереднє повідомлення.
hardillb

Відповіді:


6

Здається, це робота для 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.


0

Мені було цікаво, чи існують протоколи, які спрямовані на надсилання та отримання команд та налаштування віддалених пристроїв?

Так, є кращий протокол управління пристроями в IoT. Це LwM2M - це набагато ефективніше, ніж MQTT і вище COAP, MQTT та HTTP.

LwM2M постачається з чітко визначеною моделлю управління даними та пристроями, що пропонує різноманітні готові до використання стандартні об'єкти (IPSO Smart Objects), моніторинг підключення, віддалені дії пристрою та структуровані оновлення FOTA та SOTA, тоді як у MQTT ці функції повністю постачальника та платформи. Далі випливає, що з MQTT оновлення програмного забезпечення або будь-які інші функції управління повинні створюватися з нуля. На противагу цьому, LwM2M пропонує оновлення прошивки як одну з основних функціональних можливостей, тому немає необхідності винаходити будь-які нові будівельні блоки для спілкування.

Тут ви порівняли MQTT проти LwM2M і весь курс аварій.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.