Soweit ich weiß, gibt es zwei allgemeine Methoden, um den Fernzugriff (Internet, nicht LAN) auf IoT-Geräte zu ermöglichen:
Ich gehe davon aus, dass die zweite Methode nicht einfach ist, da in der Regel Consumer-Geräte hinter einem Heimrouter sitzen.
Meine Frage lautet: Ungefähr wie viel Prozent der derzeit verkauften IoT-Geräte verwenden welche der folgenden Methoden, um eine Remoteverbindung herzustellen :
- Über einen Server (Gerät fragt den Server ab)
- Direkter Remotezugriff, bei dem ein Heimrouter manuell konfiguriert werden muss , um die Portweiterleitung zu aktivieren (oder auf eine andere Weise, die das Gerät verfügbar macht)
- Direkter Fernzugriff, bei dem das Gerät den Router automatisch über UPnP oder ein anderes Protokoll konfiguriert
- Direkter Remotezugriff über die statische IPv6-Adresse eines Geräts , für das kein Router-Setup erforderlich ist
- Andere Methoden
Meine Frage bezieht sich auf Consumer-IoT-Geräte wie Glühbirnen, Lichtschalter, Schlösser, Thermometer usw. von vertrauenswürdigen Herstellern, die heute verkauft und in Privathaushalten installiert werden.
Aktualisieren:
Diese Antwort wurde von @ Aurora0001 auf eine andere Antwort auf dieser Website zum Thema Lochen gefunden , um die direkte Kommunikation zwischen zwei Geräten zu ermöglichen, die sich in verschiedenen internen Netzwerken befinden (z. B. hinter einem Heimrouter). Diese Lösung erfordert einen Server, jedoch nur für den ersten Handshake.
Ich denke, das würde eine weitere Option hinzufügen ...
quelle
Antworten:
Ich denke, Sie werden einen relativ hohen Prozentsatz von "# 5, Other" finden, da in der Liste eine der häufigsten IoT-Architekturen für Verbraucher fehlt: indirekte Kommunikation über ein In-Home-Gateway.
Alle anderen von Ihnen beschriebenen Methoden weisen Nachteile auf: Sie sind schwer zu konfigurieren, nicht sicher oder beanspruchen eine Menge teurer Serverressourcen. Ein In-Home-Gateway vermeidet diese Probleme für die einzelnen Geräte, indem nur ein Gerät dem Internet ausgesetzt wird.
Das typische Gateway dient mehreren Zwecken. Erstens ist es eine Protokollbrücke. Drahtlose Geräte verwenden alle Arten von offenen und proprietären Kommunikationsprotokollen, einschließlich Z-Wave, ZigBee, dediziertem 900-MHz-Funk, dediziertem 433-MHz-Funk, Infrarotlicht, Bluetooth, BLE, ANT +, Crestron usw. Diese Protokolle lösen alle Arten von Nischenproblemen. B. Kosten pro Gerät, Akkulaufzeit, selbstkonfigurierende Mesh-Netzwerke, schnelle Reaktionszeiten, unsichere Kommunikation, einfache Konfigurationen bei minimalem Speicherbedarf usw. Auf diese Weise verwenden die meisten Consumer-IoT-Geräte keine IP-Pakete, sondern liefern ihre Daten in großen Mengen kleinere Rahmen, um die Batterielebensdauer zu erhalten. Das Gateway konvertiert das proprietäre Protokoll in etwas, das mit einem IP-basierten Netzwerk transportabler und interoperabler ist.
Das In-Home-Gateway ist auch ein guter Ort, um die Regeln des Systems zu speichern. Wenn Sie Regeln wie "Wenn Sie das Licht oben auf der Treppe einschalten, schalten Sie auch die Eingangsbeleuchtung ein, es sei denn, die Küchenbeleuchtung ist an" aktivieren möchten, können Sie die Regeln in die zentralisierten Lichtschalter einfügen Webserver oder das Gateway. Das Einfügen der Regeln in jeden Lichtschalter führt zu einer spröden Konfiguration, die schwer einzurichten, zu ändern oder zu verwalten ist. Das Ausführen der Regeln auf einem zentralen Server führt zu einer Wartezeit, da die Nachricht in TCP übersetzt, verschlüsselt, über das Internet gesendet, die Aktion empfangen, entschlüsselt und zurück in Zigbee übersetzt werden muss. Mit dem Gateway kann der Anbieter diese Probleme lösen, indem er einen einzigen Verwaltungspunkt zum Sichern und Wiederherstellen und einen lokalen Prozessor zum schnellen Ausführen der Regeln bereitstellt.
Sicherheit ist ein großes Problem: IoT-Geräte müssen billig sein, und billige Prozessoren verfügen nicht über große CPUs und Speicher für sichere Verschlüsselungsfunktionen. Ganz zu schweigen von dem Wunsch, die enormen Kosten für die Entwicklung sicher verschlüsselter Protokolle zu vermeiden. Sie implementieren also eine sehr schwache (billige) oder gar keine Sicherheit auf den Endgeräten. Sie machen das wieder wett, indem sie nur in einem sehr begrenzten Bereich kommunizieren - sie müssen nur das In-Home-Gateway erreichen. Auf diese Weise verarbeitet das Gateway die lokale ungesicherte Kommunikation, und nur ein Gerät benötigt die erforderliche Verarbeitungsleistung und den Speicher, um über TLS mit der Cloud zu kommunizieren.
Schließlich kann das Gateway eine bequeme zentrale Benutzerschnittstelle für die Geräte bereitstellen. Die meisten Gateways verfügen über eine Webschnittstelle, die eine GUI-basierte Konfiguration ermöglicht. Stellen Sie sich vor, Sie möchten ein 12-stelliges WLAN-Passwort mit nur einer Taste und einer LED in ein Gerät mischen und konfigurieren. Schlimmer noch, stellen Sie sich vor, die Telefonsupportmitarbeiter Ihres Unternehmens sprechen jeden Kunden durch diesen Prozess.
Leider beantwortet dies Ihre Frage immer noch nicht direkt. Ich gehe jedoch davon aus, dass die Gateway-Architektur die am häufigsten verwendete Methode ist, um verbraucherorientierte Geräte mit dem Internet zu verbinden.
BEARBEITEN: Als Antwort auf Ihren Kommentar zu In-Home-Gateways, die für IoT-Geräte verwendet werden, gibt es einige grundlegende Arten: dedizierte Einzelfunktionen, dedizierte Mehrzweckfunktionen und allgemeine Funktionen. Zusätzlich zu den folgenden Schnittstellen verfügen alle über eine Ethernet- oder WiFi-Schnittstelle zum Überbrücken von Nachrichten zu und von einem IP-Netzwerk.
Ein dediziertes Single-Purpose-Gateway spricht nur die Geräte eines bestimmten Herstellers an. Das einfachste Beispiel ist ein USB-Dongle, der Daten von einem einzelnen Gerät empfängt, beispielsweise einem Fitbit-Dongle. Weitere Beispiele sind die Philips Hue Bridge (die nur mit Philips Hue-Glühlampen kommuniziert); das Liftmaster MyQ Gateway (das nur mit Liftmaster-, Chamberlain- oder Craftsman-Garagentoröffnern kommuniziert); oder der Harmony Hub (der mit Logitech Harmony-Fernbedienungen kommuniziert und IR-Signale an verschiedene Heimkino-Komponenten sendet).
Ein Beispiel für den dedizierten Mehrzweck-Hub ist der SmartThings-Hub von Samsung. SmartThings verkauft eine Vielzahl von Geräten für die Hausautomation, spricht jedoch nur das SmartThings-Protokoll. Der SmartThings-Hub kann auch über IP mit vielen anderen Gerätesteuerungen kommunizieren und verfügt über eine native IFTTT-Integration.
Die Universal-Gateways enthalten möglicherweise einige proprietäre Komponenten, unterstützen jedoch häufig mehrere Schnittstellen und können als primäre Smart-Home-Schnittstelle dienen. Beispiele sind der Wink Hub (der mit Zigbee-, Z-Wave-, Lutron- und Kidde-HF-Geräten kommuniziert); Vera Edge (zur Kommunikation mit Z-Wave- und Insteon-Geräten und zur Kommunikation mit externen Geräten).
Schließlich gibt es auch einige sehr aktive Open-Source-Bemühungen im Bereich der allgemeinen Hausautomation, einschließlich Domoticz und OpenHAB. Hierbei handelt es sich um Softwareprogramme, die die Kommunikation mit IoT-Geräten über dedizierte Bridge-Geräte (z. B. einen Z-Wave-USB-Dongle oder ein ZigBee-Radio) unterstützen, Regeln implementieren und umfassende Integrationsfunktionen wie IFTTT, MQTT und andere bieten.
quelle
Praktisch alle Verbraucherprodukte, die auf diese Weise betrieben werden, erfordern einen externen Server, um das Senden von Nachrichten von einem externen Gerät an ein bestimmtes Gerät zu Hause zu vermitteln. Selbst im offensichtlichsten Fall, dass Sie Port 22 auf Ihrem Raspberry Pi verfügbar machen, benötigen Sie (im Allgemeinen) noch einen dynamischen DNS-Dienst.
Bei allen anderen Methoden muss das entfernte Mobilteil in der Lage sein, das Heimgerät zu finden. Peer-to-Peer-Protokolle verwenden manchmal die Portweiterleitung, da sie eine Client-Server-Architektur vermeiden möchten.
Es ist möglich, dass ein System zusätzlich einen eingehenden Port mit UPnP öffnet, dies sollte jedoch für IoT-Anwendungen nicht erforderlich sein. Dies gilt möglicherweise für ältere Spieleanwendungen, fällt jedoch auseinander, sobald mehr als ein Knoten auf einer öffentlichen IP vorhanden ist.
Obwohl IPv6 die Zuordnung von zwei Geräten ermöglicht, unterstützen viele Netzwerke IPv6 heute nicht durchgehend. Ein Server ist erforderlich, um Firmware-Updates bereitzustellen (es sei denn, das Gerät ist vor dem Verkauf veraltet).
quelle