O ile mi wiadomo, istnieją 2 ogólne metody umożliwiające zdalny (Internet, a nie LAN) dostęp do urządzeń IoT:
Zakładam, że druga metoda nie jest prosta, ponieważ zazwyczaj urządzenia konsumenckie siedzą za routerem domowym.
Moje pytanie brzmi: z grubsza, jaki procent obecnie sprzedawanych urządzeń IoT korzysta z poniższych metod zdalnego łączenia się z nimi :
- Za pośrednictwem serwera (urządzenie odpytuje serwer)
- Bezpośredni dostęp zdalny, który wymaga ręcznej konfiguracji routera domowego w celu umożliwienia przekierowania portów (lub w inny sposób narażający urządzenie)
- Bezpośredni dostęp zdalny, w którym urządzenie automatycznie konfiguruje router za pośrednictwem UPnP lub innego protokołu
- Bezpośredni dostęp zdalny przy użyciu statycznego adresu IPv6 urządzenia, który nie wymaga konfiguracji routera
- Inne metody
Moje pytanie dotyczy urządzeń IoT dla konsumentów, takich jak żarówki, przełączniki światła, zamki, termometry itp. Od zaufanych producentów, które są dziś sprzedawane i są instalowane w domach.
Aktualizacja:
Które oceniły tę odpowiedź przez @ Aurora0001 innej odpowiedzi na tej stronie o dziurkowanie umożliwienie bezpośredniej komunikacji pomiędzy 2 urządzeniami przebywających w różnych sieciach wewnętrznych (np za routerem domowym). To rozwiązanie wymaga serwera, ale tylko do początkowego uzgadniania.
Myślę, że to dodałoby kolejną opcję ...
źródło
Odpowiedzi:
Myślę, że znajdziesz dość wysoki odsetek „# 5, Inne”, ponieważ na liście brakuje jednej z najczęstszych architektur IoT dla konsumentów: pośrednia komunikacja za pośrednictwem wewnętrznej bramki.
Wszystkie inne metody, które opisujesz, mają swoje wady: są trudne do skonfigurowania, nie są bezpieczne lub wymagają dużo kosztownych zasobów serwerowych. Wewnętrzna brama pozwala uniknąć tych problemów dla poszczególnych urządzeń, udostępniając tylko jedno urządzenie w Internecie.
Typowa brama służy kilku celom. Po pierwsze, jest to most protokołu. Urządzenia bezprzewodowe wykorzystują wszelkiego rodzaju otwarte i zastrzeżone protokoły komunikacyjne, w tym Z-Wave, Zigbee, dedykowane częstotliwości radiowe 900 MHz, dedykowane częstotliwości radiowe 433 MHz, światło podczerwone, Bluetooth, BLE, ANT +, Crestron itp. Rozwiązują one wszelkie problemy niszowe, takich jak koszt na urządzenie, żywotność baterii, samokonfigurujące się sieci kratowe, szybki czas reakcji, niepewna komunikacja, proste konfiguracje z minimalną pamięcią itp. W ten sposób większość urządzeń IoT dla konsumentów nie używa pakietów IP, ale zamiast tego dostarcza swoje dane mniejsze ramki w celu zachowania żywotności baterii. Brama przekształci własny protokół w coś łatwiejszego w transporcie i interoperacyjności z siecią opartą na protokole IP.
Ponadto brama wewnętrzna jest dobrym miejscem do przechowywania reguł systemu. Jeśli zamierzasz włączyć takie reguły, jak: „jeśli włączysz światło u szczytu schodów, włącz także światło w przedpokoju, chyba że światło w kuchni jest włączone”, możesz umieścić reguły w przełącznikach światła, scentralizowanym serwer WWW lub brama. Umieszczenie reguł w każdym włączniku światła tworzy kruchą konfigurację, którą trudno jest skonfigurować, zmienić lub zarządzać. Uruchamianie reguł w scentralizowanym serwerze wprowadza opóźnienia, ponieważ wiadomość musi zostać przetłumaczona na TCP, zaszyfrowana, wysłana przez Internet, działanie musi zostać odebrane, odszyfrowane i przetłumaczone z powrotem do Zigbee. Brama umożliwia dostawcy rozwiązanie tych problemów, zapewniając pojedynczy punkt zarządzania do tworzenia kopii zapasowych i przywracania, a procesor lokalny do szybkiego uruchamiania reguł.
Bezpieczeństwo to duży problem: urządzenia IoT muszą być tanie, a tanie procesory nie mają dużych procesorów i pamięci do bezpiecznego szyfrowania. Nie wspominając już o chęci uniknięcia ogromnego kosztu opracowania bezpiecznie zaszyfrowanych protokołów. W ten sposób wdrażają bardzo słabe (tanie) zabezpieczenia w urządzeniach konsumenckich lub w ogóle ich nie mają. Nadrabiają to komunikując się tylko w bardzo ograniczonym zasięgu - muszą dotrzeć tylko do bramki domowej. W ten sposób brama obsługuje lokalną niezabezpieczoną komunikację i tylko jedno urządzenie potrzebuje mocy obliczeniowej i pamięci potrzebnej do komunikacji z chmurą za pośrednictwem TLS.
Wreszcie, brama może zapewnić wygodny pojedynczy punkt ludzkiego interfejsu dla urządzeń. Większość bram udostępnia interfejs WWW, umożliwiający konfigurację opartą na GUI. Wyobraź sobie próbę skonfigurowania 12-znakowego hasła Wi-Fi do urządzenia za pomocą tylko jednego przycisku i jednej diody LED. Co gorsza, wyobraź sobie, że pracownicy działu wsparcia telefonicznego Twojej firmy rozmawiają z każdym klientem przez ten proces.
Niestety nadal nie odpowiada to bezpośrednio na twoje pytanie. Ale spodziewam się, że architektura bramy będzie najczęstszym sposobem, w jaki urządzenia konsumenckie łączą się z Internetem.
EDYCJA: W odpowiedzi na Twój komentarz na temat wewnętrznych bram używanych do urządzeń IoT, istnieje kilka podstawowych rodzajów: dedykowany jeden cel, dedykowany uniwersalny i ogólny cel. Oprócz poniższych interfejsów wszystkie mają interfejs Ethernet lub WiFi do mostkowania wiadomości do i z sieci IP.
Dedykowana bramka jednofunkcyjna obsługuje tylko urządzenia określonego producenta. Najprostszym przykładem może być klucz USB, który odbiera dane z jednego urządzenia, takiego jak klucz Fitbit. Inne przykłady obejmują most Philips Hue (który komunikuje się tylko z żarówkami Philips Hue); Brama Liftmaster MyQ Gateway (która komunikuje się tylko z otwieraczami drzwi garażowych Liftmaster, Chamberlain lub Craftsman); lub Harmony Hub (który komunikuje się z pilotami Logitech Harmony i miga IR do różnych komponentów kina domowego).
Przykładem dedykowanego wielofunkcyjnego koncentratora może być hub SmartThings firmy Samsung. SmartThings sprzedaje szeroką gamę urządzeń automatyki domowej, ale mówią one tylko protokołem SmartThings. Hub SmartThings może również komunikować się z wieloma innymi kontrolerami urządzeń za pośrednictwem protokołu IP i ma natywną integrację IFTTT.
Bramki ogólnego przeznaczenia mogą zawierać niektóre zastrzeżone elementy, ale często obsługują wiele interfejsów i mogą służyć jako podstawowy interfejs inteligentnego domu. Przykłady obejmują Wink Hub (który komunikuje się z urządzeniami RF Zigbee, Z-Wave, Lutron i Kidde); Vera Edge (która komunikuje się z urządzeniami Z-Wave i Insteon, a także komunikuje się z urządzeniami zewnętrznymi).
Wreszcie istnieją również bardzo aktywne działania open source w dziedzinie automatyki domowej ogólnego przeznaczenia, w tym Domoticz i OpenHAB. Są to programy obsługujące komunikację z urządzeniami IoT za pośrednictwem dedykowanych urządzeń mostkowych (takich jak klucz USB Z-Wave lub radio Zigbee), wdrażają reguły i oferują szerokie możliwości integracji, takie jak IFTTT, MQTT i inne.
źródło
Praktycznie wszystkie produkty konsumenckie działające w ten sposób będą wymagały zewnętrznego serwera do pośredniczenia w wysyłaniu wiadomości z urządzenia zewnętrznego do określonego urządzenia w domu. Nawet w najbardziej oczywistym przypadku ujawnienia portu 22 na Raspberry Pi nadal (generalnie) potrzebujesz dynamicznej usługi DNS.
W przypadku wszystkich pozostałych metod zdalne urządzenie musi być w stanie znaleźć urządzenie domowe. Protokoły peer to peer czasami używają przekierowania portów, ponieważ chcą uniknąć architektury klient-serwer.
Możliwe jest, że system otworzy ponadto port przychodzący za pomocą UPnP, ale nie powinno to być konieczne w przypadku aplikacji IoT. Może to dotyczyć starszych aplikacji do gier, ale rozpada się, gdy więcej niż jeden węzeł jest obecny na jednym publicznym adresie IP.
Chociaż protokół IPv6 umożliwia skojarzenie pary urządzeń, wiele sieci nie obsługuje dziś protokołu IPv6 od końca do końca. Serwer jest konieczny niezależnie od tego, czy ma być dostępne aktualizacje oprogramowania układowego (chyba że urządzenie jest przestarzałe przed sprzedażą).
źródło