Czy protokół MQTT jest odpowiedni do przesyłania odczytów czujników przez BLE?

Załóżmy, że istnieje wiele słabych czujników (np. Urządzenia poziomu Arduino), które opierają się na BLE jako środkach komunikacji i że urządzenia te są podłączone do bardziej wydajnej bramy (np. Urządzenia Raspberry pi).

Chciałbym wiedzieć, czy MQTT jest uważany za odpowiedni protokół do przesyłania ich odczytów (krótkie, częste wiadomości z serii).

Wiele blogów / dokumentów uważa, że MQTT jest odpowiedni dla „aplikacji IoT”, ponieważ ma mniejszą (mniejszą) wagę w porównaniu z HTTP i oszczędza energię. Jednak, według mnie, wymaga to utrzymywania otwartego połączenia, co nie ma miejsca w przypadku BLE lub innych protokołów komunikacyjnych odpowiednich dla IoT. BLE nie utrzymuje otwartego połączenia przez dłuższy czas w celu rezerwowania energii. Najwyraźniej MQTT jest odpowiedni, gdy używany jest protokół warstwy MAC, taki jak WiFi. To prawie łamie uzasadnienie używania MQTT w pierwszej kolejności (tj. Jeśli urządzenie obliczalnie obsługuje protokół taki jak WiFi, może nie potrzebować protokołu takiego jak MQTT). Czy widzisz błąd w tej logice?

Czy istnieje w tym celu jakiś alternatywny protokół warstwy aplikacji? Jaka jest najczęściej spotykana struktura tego typu komunikatów (np. Surowe dane binarne, JSON, XML), kiedy komunikują się z bramą i kiedy komunikują się bezpośrednio z serwerem?

mqtt power-consumption bluetooth-low-energy

— dr.doom
źródło

Czy natywny mechanizm BLE jest nieodpowiedni z jakiegoś konkretnego powodu?

— Sean Houlihane,

Pytanie Seana można najlepiej podzielić na dwie części - A) czy natywne mechanizmy protokołu BLE działają w bezpośrednim połączeniu z urządzeniem, i B) gdzie ostatecznie dane muszą się udać? Jeśli odpowiedź na część B jest poza zakresem BLE, potrzebny jest mostek (przynajmniej między formatami radiowymi, ale prawdopodobnie również protokołami).

— Chris Stratton,

Czy brama pobiera nieprzetworzone odczyty, czy po prostu przekazuje je, i czy w tym kontekście może mieć sens tunelowanie MQTT od końca do końca zamiast mostkowania BLE natywnego dla MQTT w bramie?

— Sean Houlihane,

Odpowiedzi:

MQTT musi działać przez TCP / IP (nie pamiętam, czy faktycznie jest w specyfikacji, czy też wystarczają pewne założenia, aby to zrobić), ale jego siostrzany protokół MQTT-SN może być uruchomiony na prawie każdym protokole, który może przesyłać dane , Widziałem implementacje w UDP i serial.

Powiedziawszy, że nie jestem pewien, co zyskasz, biegając po BLE, wbudowane Charakterystyki BLE oferują wiele takich samych korzyści (choćby na zasadzie 1 do 1) z takimi rzeczami jak powiadomienie.

Myślę, że jedną z ważnych rzeczy do zapamiętania jest to, co oznacza „ja” w IoT, oznacza to w pewnym momencie dostęp do Internetu (nawet jeśli jest to bramka lub telefon). W tym momencie MQTT może być bardzo przydatny, ale niekoniecznie oznacza całą drogę do (krwawiącej) krawędzi.

— hardillb
źródło

Przede wszystkim dziękuję za poinformowanie mnie o istnieniu MQTT-SN. Ogromna większość literatury jest nieco myląca, ponieważ implikuje, że MQTT wzmacnia urządzenia brzegowe głównie ze względu na swoje właściwości oszczędzania energii. W takim przypadku zmniejszenie zużycia energii nie jest tak naprawdę prawdziwym argumentem, ponieważ w urządzeniach z tym profilem po prostu nie ma znaczenia. Urządzenia powinny implementować pełny stos IP, a ponieważ MQTT utrzymuje otwarte połączenie, energooszczędne protokoły warstwy MAC nie są opcją.

— dr.doom

MQTT oszczędza energię w porównaniu do czegoś takiego jak HTTP, ponieważ otwarte połączenie TCP tak naprawdę nie zużywa tyle energii, aby pozostać otwarte, gdy już uruchomisz stos TCP, a pakiety utrzymywania życia są małe. Również narzut protokołu jest znacznie niższy niż HTTP, ponieważ nagłówek HTTP jest ogromny w porównaniu z nagłówkiem pakietu MQTT. Duża część literatury obliczeniowej oparta jest na urządzeniu komórkowym, np. Telefonie

— hardillb

Przesunęła się również krawędź, kiedyś było tam, gdzie zatrzymał się TCP / IP, rzeczy takie jak ble i ZigBee (szczególnie z lpwan), a nawet procesory o niższej mocy przeniosły się na jeszcze cieńsze urządzenia

— hardillb

Jest to wyraźnie nie tylko TCP / IP; jedynym wymaganiem jest, aby protokół zapewniał „uporządkowane, bezstratne, dwukierunkowe połączenia”. To jak drugi akapit streszczenia dokumentu. SN istnieje, ponieważ wymóg ten jest uciążliwy w przypadku małych systemów, zwłaszcza radiowych. Być może to rozumiesz przez „poczyniono wystarczające założenia, aby tak się stało”, ale zdecydowanie nie zależy od TCP / IP.

— Dave Newton

Prawdopodobnie lepiej byłoby zrobić proste mapowanie danych z paradygmatów BLE na MQTT, niż dosłownie wysyłać MQTT przez BLE.

BLE zasadniczo wymienia dane w formie cech . Mają różne unikalne mechanizmy BLE do wykrywania zmian wartości, które mogą okazać się przydatne. Ale mają maksymalną długość danych 20 bajtów .

Jest to możliwe do strumienia danych szeregowych nad BLE, przenosząc 20 bajtów na raz. Czasami robi się to w celu zaimplementowania wirtualnego portu szeregowego i można przez to tunelować pełne MQTT.

Ale prawdopodobnie lepiej byłoby użyć zbioru cech BLE do przenoszenia danych z różnych tematów i mieć mostek, który odwzorowuje charakterystyczną tożsamość na temat MQTT i odwzorowuje wartość na ładunek MQTT.

BLE ma własne poczucie ciągłych połączonych sesji w porównaniu z sesjami niepowiązanymi. Prawdopodobnie powinieneś dowiedzieć się, jakie użycie BLE jest najlepsze dla twojej aplikacji, a następnie odwzorować to na sens utrzymywania połączenia przez MQTT.

Powinieneś być w stanie to zrobić w jednym lub obu kierunkach: BLE-> MQTT i MQTT-> BLE

— Chris Stratton
źródło

Jeśli chcesz mostu MQTT 2 BLE, możesz spojrzeć na mój github.com/hardillb/mqtt2ble

— hardillb

Dzięki za ten link. Właśnie na to patrzę.

— dr.doom