Стандарти для пристроїв без підключення до Інтернету?


10

Я планую зробити багато домашньої автоматизації. Для цього я розміщую приватну ізольовану мережу WiFi, до якої будуть підключені всі мої пристрої. Пристроями будуть прості світильники, світлодіодні смуги RGB (smd5050 та ws2812b), термостати, вентилятори, відкривачі вікон, контролери відтінків вікон та звичайні розетки. Також ІЧ-передавачі для імітації пульта для запуску телевізорів тощо. І передавач 433 МГц для імітації пульта, який може перемикати стандартні дистанційні керовані розетки.

Тепер мені цікаво, чи існують якісь стандарти щодо того, який саме інтерфейс повинен піддавати цим пристроям до мережі WiFi.

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

Відповіді:


7

Про протоколи IoT найчастіше HTTP, CoAP і MQTT використовуються для зв'язку.

HTTP і CoAP підходять для типу REST клієнтів (ів) для зв'язку з сервером, а MQTT підтримує багатокористувацькі комунікації на основі публікації та підписки, де походження може бути легко від сервера до клієнта, клієнта до сервера і навіть клієнта до клієнта.

Відповідь на питання:

Використовуйте REST через HTTP або CoAP для зв’язку один на один або MQTT для багатоточкового трафіку.

Детальніше

Після коментаря нижче, я визнаю, що моя відповідь була досить частковою, тому я вивчив і знайшов трохи більше:

Навіть у комунікаціях такий безлад стандартів, якщо все обчислити:

http://www.slideshare.net/butler-iot/butler-project-overview-13603599

Джерело: Проект ЄС Батлер - питання комунікації

Також postscapes.com має наступний список, заснований на різних аспектах:

1  Infrastructure (ex: 6LowPAN, IPv4/IPv6, RPL)
2  Identification (ex: EPC, uCode, IPv6, URIs)
3  Comms / Transport (ex: Wifi, Bluetooth, LPWAN)
4  Discovery (ex: Physical Web, mDNS, DNS-SD)
5  Data Protocols (ex: MQTT, CoAP, AMQP, Websocket, Node)
6  Device Management (ex: TR-069, OMA-DM)
7  Semantic (ex: JSON-LD, Web Thing Model)
8  Multi-layer Frameworks (ex: Alljoyn, IoTivity, Weave, Homekit)

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

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

Зараз правильним питанням є пошук правильного набору продуктів або набору продуктів (групи наборів продуктів) з однаковими або майже збігаються стеками протоколів через Wi-Fi, коли ви ставите собі мету (маючи на увазі, інфрачервоне - це рішення з цієї області та там є безліч інших бездротових мережевих рішень, з якими ви все ще можете стикатися).

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


1
"REST over http" трохи розпливчастий. Навіть маючи це на увазі, я міг придумати сотні різних способів проектування інтерфейсу, особливо для пристроїв, які розуміють більше, ніж "увімкнено" та "вимкнено". В ідеалі я б просто вказав IP-адресу та тип пристрою, а решта було б стандартизовано. Чи існує щось подібне?
Форивін

7

Моя рекомендація - MQTT. Універсальний, легкий і модульний, він може працювати навіть на ESP8266 (концентратор і клієнт). Протокол MQTT доступний для багатьох платформ від вбудованих, мобільних пристроїв і до великих жирних ОС, таких як MAC, Windows та Linux.

У протоколі є модель видавця, абонента для зв'язку. І QoS, так що концентратор може запам’ятати, чи отримав підписник повідомлення від видавця. Таким чином, сплячий пристрій може набирати швидкість, коли він прокидається і шукає на ньому повідомлення.

Я запускаю свій сервер MQTT на маленькому Raspberry Pi Zero W, це як кредитна картка на стіні, і для логіки я використовую "Node Red", і я почав шукати OpenHAB для більш складного рішення.

Я також створив свої власні пристрої Arduino / MQTT для моїх 12 В постійного струму і використовує продукт на базі ESP8266 для моїх пристроїв змінного струму 230 В.

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