Яким чином споживчі пристрої IoT зазвичай дозволяють підключитися до Інтернету?


15

Наскільки мені відомо, є два загальних способи ввімкнути віддалений (Інтернет, а не локальну мережу) доступ до пристроїв IoT:

  1. Через сервер, який пристрій періодично опитує (наприклад, MQTT )
  2. Прямий віддалений доступ

Я припускаю, що другий метод не є прямим вперед, оскільки зазвичай побутові пристрої сидять за домашнім маршрутизатором.

Моє запитання таке: орієнтовно, який відсоток проданих на даний момент пристроїв IoT використовує який із наведених нижче способів для віддаленого підключення до них :

  1. Через сервер (пристрій опитує сервер)
  2. Прямий віддалений доступ, який вимагає вручну настроїти домашній маршрутизатор, щоб увімкнути переадресацію портів (або інший спосіб, що відкриває пристрій)
  3. Прямий віддалений доступ, де пристрій автоматично налаштовує роутер через UPnP або інший протокол
  4. Прямий віддалений доступ за допомогою статичної адреси IPv6 пристрою, яка не потребує налаштування маршрутизатора
  5. Інші методи

Моє запитання стосується споживчих пристроїв IoT, таких як лампочки, вимикачі світла, замки, термометри тощо від надійних виробників, які продаються сьогодні та встановлюються в будинках.

Оновлення:

Знайшов цю відповідь від @ Aurora0001 на іншу відповідь на цьому веб-сайті про пробивання отворів, щоб увімкнути прямий зв'язок між двома пристроями, що перебувають у різних внутрішніх мережах (наприклад, за домашнім маршрутизатором). Для цього рішення потрібен сервер, але лише для початкового рукостискання.

Я думаю, це додало б ще один варіант ...


Цікаве запитання. Я не впевнений, чи буде легко отримати статистику, щоб дізнатись відсотки - вам це конкретно потрібно, чи ви просто намагаєтесь зрозуміти, які методи є більш поширеними?
Aurora0001

5
Також MQTT не опитується, він відкриває стійке з'єднання з брокером, а брокер потім надсилає повідомлення назад по цьому посиланню
hardillb

1
Я б припустив, що 99% встановлень цього року використовуватимуть (1), але нічого не виправдовують.
Шон Хуліхане

2
@Mawg Зворотний пошук адреси. Доступ до пристрою в моєму будинку з роботи.
Шон Хуліхане

1
@Perspectivus чому, у відкритого сокета практично немає накладних витрат, він надсилає дуже маленький пакет збереження в живих (щоб повідомити брокеру, що він все ще є) з налаштованою швидкістю, яка, поки коротше 15 хвилин TCP вийде з розетки має залишатися відкритим нескінченно.
hardillb

Відповіді:


12

Я думаю, ви знайдете досить високий відсоток "№5, інше", оскільки в списку відсутня одна з найпоширеніших архітектурних IoT-архітектур: непрямі комунікації через внутрішній шлюз.

Усі інші описані вами методи мають недоліки в домашніх умовах: їх важко налаштувати, вони не захищені або вони вимагають багато дорогих серверних ресурсів. Внутрішній шлюз дозволяє уникнути цих проблем для окремих пристроїв, відкривши лише один пристрій в Інтернеті.

Типовий шлюз виконує кілька цілей. По-перше, це протокольний міст. Бездротові пристрої використовують усі види протоколів відкритого та захищеного зв’язку, включаючи Z-Wave, Zigbee, виділений радіочастот 900 МГц, виділений радіочастот 433 МГц, інфрачервоне світло, Bluetooth, BLE, ANT +, Crestron тощо. Вони вирішують всі види нішевих проблем, як-от вартість пристрою, час автономної роботи, мережеві мережі, що самоконфігуруються, швидкий час реагування, незахищена комунікація, прості конфігурації з мінімальним обсягом пам’яті тощо. Таким чином, більшість споживчих пристроїв IoT не використовують IP-пакети, а натомість доставляють свої дані всередині менші кадри, щоб зберегти ресурс акумулятора. Шлюз перетворить фірмовий протокол у щось більш транспортабельне та сумісне з мережею на основі IP.

Також внутрішній шлюз - хороше місце для зберігання правил системи. Якщо ви збираєтеся ввімкнути правила типу "якщо ви увімкніть світло у верхній частині сходів, також увімкніть світло на вході, якщо не увімкнене світло на кухні", ви можете розмістити правила у вимикачах, централізованих веб-сервер або шлюз. Якщо встановити правила в кожен вимикач світла, це створить крихку конфігурацію, яку важко налаштувати, змінити чи керувати. Запуск правил на централізованому сервері вводить затримку, оскільки повідомлення має бути переведене на TCP, зашифроване, надіслане через Інтернет, дію потрібно отримати, розшифрувати та перекласти назад у Zigbee. Шлюз дозволяє постачальнику вирішувати ці проблеми, надаючи єдину точку управління для резервного копіювання та відновлення, а локальний процесор швидко виконує правила.

Безпека - велика проблема: пристрої IoT повинні бути дешевими, а дешеві процесори не мають великих процесорів та сховища для безпечних функцій шифрування. Не кажучи вже про бажання уникнути масових витрат на розробку надійно зашифрованих протоколів. Таким чином, вони реалізують дуже слабку (дешеву) безпеку на споживчих пристроях або взагалі відсутність безпеки. Вони компенсують це лише спілкуванням у дуже обмеженому діапазоні - вони повинні дістатися лише до внутрішнього шлюзу. Таким чином, шлюз обробляє локальну незахищену комунікацію, і лише одному пристрою потрібна потужність обробки та сховище, необхідні для передачі інформації в хмару через TLS.

Нарешті, шлюз може забезпечити зручну єдину точку людського інтерфейсу для пристроїв. Більшість шлюзів відкривають веб-інтерфейс, що забезпечує конфігурацію на основі GUI. Уявіть, що ви намагаєтеся за допомогою Морзе-коду налаштувати 12-символьний пароль WiFi на пристрій, використовуючи лише одну кнопку та один світлодіод. Гірше, уявіть, що персонал служби підтримки вашої компанії розмовляє з кожним клієнтом через цей процес.

На жаль, це все ще не відповідає безпосередньо на ваше запитання. Але я очікую, що архітектура шлюзу є найпоширенішим способом підключення споживачів до Інтернету.

EDIT: У відповідь на ваш коментар про внутрішні шлюзи, які використовуються для пристроїв IoT, є кілька основних типів: спеціальна цільова цільова цільова ціль, багатоцільове призначення та загальне призначення. Окрім наведених нижче інтерфейсів, усі вони мають інтерфейс Ethernet або WiFi для перенесення повідомлень до мережі IP та з неї.

Виділений єдиний цільовий шлюз розмовляє лише з пристроями конкретного виробника. Найпростішими прикладами може бути USB-ключ, який отримує дані з одного пристрою, як, наприклад, Fitbit dongle. Інші приклади включають міст Philips Hue Bridge (який спілкується лише з лампочками Philips Hue); шлюз Liftmaster MyQ (який спілкується лише з відкриттями гаражних дверей Liftmaster, Chamberlain або Craftsman); або Центр Harmony (який спілкується з Logitech Harmony, віддалено та блимає ІК до різних компонентів домашнього кінотеатру.)

Прикладом виділеного багатоцільового концентратора може бути концентратор SmartThings Samsung. SmartThings продає найрізноманітніші пристрої домашньої автоматизації, але вони говорять лише за протоколом SmartThings. Центр SmartThings також може спілкуватися з багатьма іншими контролерами пристроїв через IP та має вбудовану інтеграцію IFTTT.

Шлюзи загального призначення можуть мати деякі фірмові компоненти, але часто підтримують декілька інтерфейсів і можуть слугувати основним інтерфейсом розумного дому. Приклади включають концентратор Wink (який повідомляє пристрої Zigbee, Z-Wave, Lutron та Kidde RF); Vera Edge (яка зв’язується з пристроями Z-Wave та Insteon і поширюється на спілкування із зовнішніми пристроями).

Нарешті, також є кілька дуже активних зусиль з відкритим кодом у сфері домашньої автоматизації загального призначення, включаючи Domoticz та OpenHAB. Це програмні програми, які підтримують зв’язок із пристроями IoT через спеціальні мостові пристрої (наприклад, USB-догва Z-Wave або радіо Zigbee), реалізують правила та пропонують широкі можливості інтеграції, такі як IFTTT, MQTT та інші.


Дякую, Джон. Чи можете ви надати посилання на загальні статті про або конкретні приклади таких внутрішніх шлюзів?
Perspectivus

8

Практично всі продукти споживання, які працюють таким чином, потребують зовнішнього сервера для посередництва надсилання повідомлень із зовнішнього пристрою на певний пристрій вдома. Навіть у найбільш очевидному випадку експонування порту 22 на вашому Raspberry Pi, вам все-таки (як правило) потрібен динамічний сервіс DNS.

  1. Пристрій ініціює та підтримує постійне з'єднання з сервером. Для цього не потрібна конфігурація маршрутизатора за умови, що маршрутизатор надає доступ https до Інтернету ...

Для всіх інших методів пристрої віддаленої слухавки повинні мати можливість знайти домашній пристрій. Протоколи однорангових програм іноді використовуватимуть переадресацію портів, оскільки вони мають бажання уникати архітектури клієнт-сервер.

Можливо, що система також відкриє вхідний порт за допомогою UPnP, але це не повинно бути необхідним для програм IoT. Це може стосуватися застарілих ігрових програм, але вони розпадаються, як тільки на одному загальнодоступному IP-адресі присутній більше одного вузла.

Хоча IPv6 дозволяє асоціювати пару пристроїв, багато мереж сьогодні не підтримують IPv6. Сервер необхідний незалежно, щоб забезпечити оновлення мікропрограмного забезпечення (якщо пристрій застаріло до його продажу).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.