Protokół do konfigurowania ustawień urządzenia IoT


9

MQTT jest szeroko stosowany w IoT, jeśli chodzi o wymianę danych aplikacji między urządzeniem końcowym a usługą hosta. Model publikuj-subskrybuj ułatwia korzystanie: bez uzgadniania, negocjacji itp. (Przynajmniej powyżej warstwy protokołu MQTT). Jest to przede wszystkim ukierunkowane na to, aby producenci danych mogli łatwo dystrybuować swoje dane wśród konsumentów.

Jednak jeśli chodzi o serwer centralny, który chce skonfigurować ustawienia na urządzeniu końcowym, nie jestem pewien, czy model jest bardzo odpowiedni. Serwer będzie chciał wysłać polecenie do urządzenia i poczekać na odpowiedź zwrotną (np. Odczytać określone ustawienie, poczekać na odpowiedź), co tak naprawdę nie pasuje do modelu publikowania i subskrybowania MQTT.

Zastanawiałem się, czy istnieją jakieś protokoły ukierunkowane na wysyłanie i odbieranie poleceń oraz konfigurowanie urządzeń zdalnych?


1
Czy na pewno MQTT nie zezwala klientowi na subskrybowanie kanału kontrolnego? Myślę, że to miejsce, w którym można zacząć szukać odpowiedzi, ale nie jestem wystarczająco szybki, aby podsumować w odpowiedzi en.wikipedia.org/wiki/Representational_state_transfer
Sean Houlihane

1
Nie zapominaj, że punkt końcowy musi być tym, który inicjuje kanał, więc kontroluje zużycie energii.
Sean Houlihane

1
@SeanHoulihane Z pewnością można używać MQTT do wysyłania i odbierania poleceń / ustawień zgodnie z opisem, ale z mojego punktu widzenia najlepiej jest mieć protokół oparty na „sesji”, tzn. Tworzysz sesję, wysyłasz polecenie i odbierać odpowiedź w tej samej sesji, w ten sposób łatwo łącząc odpowiedź z pierwotnym poleceniem. MQTT jest oparty na wiadomościach, więc nie ma nic do łączenia wiadomości ze sobą - to od Ciebie zależy, czy poradzisz sobie z tą częścią. Zastanawiałem się, czy istnieje łatwo dostępny protokół, którego mogę użyć do tego celu.
Amr Bekhit

1
en.wikipedia.org/wiki/OMA_LWM2M Nie jestem pewien, jak dokładnie, ale wydaje się, że chmura jest w stanie wykonywać wywołania PUT lub POST w celu wywołania wywołania zwrotnego w kliencie.
Sean Houlihane

MQTTv5 ma pola nagłówka do oznaczenia wiadomości jako odpowiedzi na wcześniejszą wiadomość.
hardillb

Odpowiedzi:


6

Brzmi jak praca dla CoAP :

Podobnie jak HTTP, CoAP opiera się na niezwykle udanym modelu REST: serwery udostępniają zasoby pod adresem URL, a klienci uzyskują dostęp do tych zasobów za pomocą metod takich jak GET, PUT, POST i DELETE.

Z punktu widzenia dewelopera CoAP przypomina HTTP. Uzyskiwanie wartości z czujnika niewiele różni się od uzyskiwania wartości z interfejsu API sieci Web.

Najwyraźniej można go wdrożyć przy bardzo niskim obciążeniu:

CoAP został zaprojektowany do pracy na mikrokontrolerach z zaledwie 10 KiB pamięci RAM i 100 KiB przestrzeni kodu

CoAP jest określony w RFC 7252 i istnieją różne implementacje (np. W C ).

Jest bardzo mocno zainspirowany przez REST używany z HTTP dla internetowych interfejsów API, więc jeśli znasz je, szybko wybierzesz CoAP. Jeśli nie, ta prezentacja może być przydatna w kontekście. Chodzi o to, że każda metoda HTTP ma znaczenie semantyczne, np GETżąda informacji z urządzenia bez zmieniania czegokolwiek i POST, PUTi DELETEmutować dane.

Jak mówisz, modele publikowania / subskrypcji nie działałyby w sytuacji, gdy Twoje urządzenie działa jak „serwer” koordynujący system centralny (który działa jako klient dla każdego urządzenia). Zamiast tego idealny jest model podobny do HTTP, z tym wyjątkiem, że HTTP ma o wiele za dużo narzutu, i tam właśnie przychodzi CoAP.


0

Zastanawiałem się, czy istnieją jakieś protokoły ukierunkowane na wysyłanie i odbieranie poleceń oraz konfigurowanie urządzeń zdalnych?

Tak, istnieje lepszy protokół do zarządzania urządzeniami w IoT. Jest to LwM2M - jest znacznie bardziej wydajny niż MQTT i wyższy niż COAP, MQTT i HTTP.

LwM2M ma dobrze zdefiniowany model zarządzania danymi i urządzeniami, oferujący różnorodne gotowe do użycia standardowe obiekty (IPSO Smart Objects), monitorowanie łączności, zdalne akcje urządzeń oraz ustrukturyzowane aktualizacje FOTA i SOTA, podczas gdy w MQTT funkcje te są całkowicie specyficzne dla dostawcy i platformy. Poniżej jest to, że dzięki MQTT aktualizacje oprogramowania układowego lub inne funkcje zarządzania muszą być tworzone od zera. Natomiast LwM2M oferuje aktualizacje oprogramowania układowego jako jedną ze swoich podstawowych funkcji, więc nie trzeba wymyślać żadnych nowych elementów składowych do komunikacji.

Tutaj masz porównanie MQTT vs LwM2M i przebieg całego wypadku.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.