Подходит ли протокол MQTT для передачи показаний датчика через BLE?

Предположим, что существуют многочисленные слабые датчики (например, устройства уровня Arduino), которые полагаются на BLE в качестве средства связи и что эти устройства подключены к более мощному шлюзу (например, устройства Raspberry pi уровня).

Я хотел бы знать, считается ли MQTT подходящим протоколом для передачи их показаний (короткие, частые пакетные сообщения).

Многие блоги / документы считают MQTT подходящим для «приложений IoT», поскольку он имеет меньший вес по сравнению с HTTP и экономит энергию. Однако, насколько я понимаю, требуется, чтобы соединение оставалось открытым, что не относится к BLE или другим протоколам связи, подходящим для IoT. BLE не поддерживает соединение открытым в течение длительных периодов времени для резервирования энергии. Очевидно, MQTT подходит, когда используется протокол уровня MAC, такой как WiFi. Это почти нарушает обоснование использования MQTT в первую очередь (т. Е. Если устройство вычислимо обрабатывает протокол, такой как WiFi, тогда ему может не понадобиться протокол, такой как MQTT). Видите ли вы недостаток в этой логике?

Есть ли альтернативный протокол прикладного уровня для этой цели? Какова наиболее часто встречающаяся структура сообщений такого типа (например, необработанные двоичные данные, JSON, XML), когда они взаимодействуют со шлюзом и когда они общаются с сервером напрямую?

mqtt power-consumption bluetooth-low-energy

— dr.doom
источник

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

— Шон

Вопрос Шона лучше всего разделить на две части: а) можно ли использовать собственные механизмы протокола BLE для непосредственной связи с устройством, и б) куда в конечном итоге нужно направлять данные? Если ответ на часть B выходит за пределы диапазона BLE, то необходим мост (по крайней мере, между радиоформатами, но, вероятно, и протоколами).

— Крис Страттон

Использует ли шлюз необработанные показания или просто передает их, и в этом контексте может иметь смысл туннелировать сквозной MQTT, а не соединять BLE, собственный для MQTT, на шлюзе?

— Шон

Ответы:

MQTT должен работать по протоколу TCP / IP (я не могу вспомнить, действительно ли он указан в спецификации или для этого достаточно предположений), но его родственный протокол MQTT-SN может работать практически по любому протоколу, который может передавать данные Я видел реализации в UDP и последовательном.

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

Я думаю, что одна из важных вещей, которую нужно помнить, это то, что означает «I» в IoT, оно подразумевает доступ к Интернету в какой-то момент (даже если это устройство шлюза или телефон). В этот момент MQTT может быть очень полезным, но это не обязательно означает весь путь до (истекающего кровью) края.

— hardillb
источник

Прежде всего, спасибо, что сообщили мне о существовании MQTT-SN. Подавляющее большинство литературы несколько вводит в заблуждение, поскольку подразумевает, что MQTT расширяет возможности периферийных устройств в основном благодаря своим характеристикам энергосбережения. В этом случае снижение энергопотребления не так уж и много, потому что в устройствах с таким профилем это просто не имеет значения. Устройства должны реализовывать полный стек IP, и, поскольку MQTT поддерживает открытое соединение, энергосберегающие протоколы уровня MAC не подходят.

— доктор Юрий

MQTT экономит электроэнергию по сравнению с чем-то вроде HTTP, потому что открытое TCP-соединение на самом деле не потребляет столько энергии, чтобы оставаться открытым после того, как вы уже используете стек TCP, а пакеты поддержки активности крошечные. Кроме того, издержки протокола намного ниже, чем HTTP, потому что заголовок HTTP огромен по сравнению с заголовком пакета MQTT. Большая часть компьютерной литературы основана на сотовом устройстве, например, на телефоне

— hardillb

Кроме того, преимущество переместилось, когда-то там, где остановились TCP / IP, такие вещи, как ble и ZigBee (особенно с lpwan) и даже процессоры с низким энергопотреблением, перешли на еще более тонкие устройства

— hardillb

Это явно не только TCP / IP; единственное требование заключается в том, что протокол должен обеспечивать «упорядоченные, двунаправленные соединения без потерь». Это как второй абзац аннотации документа. SN существует, потому что это требование является обременительным для небольших систем, особенно радиосистем. Может быть, это то, что вы подразумеваете под «достаточно предположений, чтобы сделать это», но это, безусловно, не зависит от TCP / IP.

— Дэйв Ньютон,

Возможно, было бы лучше сделать простое отображение данных из парадигм BLE в MQTT, а не пытаться буквально отправлять MQTT через BLE.

BLE обычно обменивается данными в форме характеристик . У них есть различные уникальные BLE-механизмы для обнаружения изменений значений, которые могут оказаться полезными. Но они имеют максимальную длину данных 20 байтов .

Это возможно , чтобы поток последовательных данных через BLE, перемещение 20 байт за один раз. Иногда это делается для реализации виртуального последовательного порта, и вы можете туннелировать полный MQTT через это.

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

BLE имеет свое собственное чувство продолжающихся подключенных сеансов против несвязанных. Вероятно, вам следует выяснить, какое использование BLE лучше всего подходит для вашего приложения, а затем сопоставить его с MQTT-смыслом поддержания соединения.

Вы должны быть в состоянии сделать это в одном или обоих направлениях: BLE-> MQTT и MQTT-> BLE

— Крис Страттон
источник

Если вам нужен мост MQTT 2 BLE, вы можете посмотреть на мой github.com/hardillb/mqtt2ble

— hardillb

Спасибо за эту ссылку, я смотрю на нее прямо сейчас.

— доктор Юрий