Standardy dla urządzeń WiFi niepołączonych z Internetem?

Planuję dużo automatyzacji domu. W tym celu będę hostować prywatną izolowaną sieć WiFi, do której zostaną podłączone wszystkie moje urządzenia. Urządzeniami będą proste światła, paski LED RGB (smd5050 i ws2812b), termostaty, wentylatory, otwieracze okien, kontrolery zasłon okiennych i normalne gniazdka. Ponadto nadajniki IR do symulacji pilota w celu uruchomienia telewizorów itp. Oraz nadajnik 433 MHz do symulacji pilota, który może przełączać standardowe gniazda zdalnego sterowania.

Teraz zastanawiam się, czy istnieją jakieś standardy dotyczące rodzaju interfejsu, jaki te urządzenia powinny wystawiać na działanie sieci WiFi.

Mógłbym oczywiście podać każdemu urządzeniu prostą trasę http, a następnie napisać aplikacje, które rozumieją mój interfejs, ale byłoby miło, gdybym mógł wdrożyć standard, który pozwoliłby mi korzystać z aplikacji i programów, które zostały już napisane i rozumieją ten standard .

W przypadku protokołów IoT do komunikacji wykorzystywane są najczęściej HTTP, CoAP i MQTT.

Protokoły HTTP i CoAP są odpowiednie dla komunikacji typu klient REST z serwerem, a MQTT obsługuje komunikację opartą na publikowaniu i subskrybowaniu wielu użytkowników, przy czym źródłem może być z łatwością serwer do klienta, klient do serwera, a nawet klient do klienta.

Odpowiedź na pytanie:

Użyj REST przez HTTP lub CoAP dla komunikacji jeden do jednego lub MQTT dla ruchu wielopunktowego.

Więcej szczegółów

Po komentarzu poniżej przyznam, że moja odpowiedź była dość częściowa, więc zbadałem i znalazłem trochę więcej:

Nawet komunikacja ma tego rodzaju bałagan standardów, jeśli wszystkie obliczone:

Źródło: Projekt UE Butlera - problemy z komunikacją

Również postscapes.com ma następującą listę opartą na różnych aspektach:

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)

Jak widać na liście każdego z przykładów, jest ich wiele, a także z pewnością więcej niestandardowych i zastrzeżonych.

Powinieneś otworzyć ten link i przeczytać go, to oszałamiające. Wierzę, że możesz spotkać w swoich projektach wiele z nich, przynajmniej jeśli czujniki są mocno zapakowane, tj. nie tylko komponenty w najczystszym formacie, ale części niektórych już istniejących ekosystemów. W takich przypadkach być może nie można negocjować sposobu ich interfejsu, wystarczy wybrać między ekosystemami.

Właściwym problemem wydaje się teraz znalezienie odpowiedniego zestawu produktów lub zestawu zestawów (grupy zestawów produktów) z identycznymi lub prawie pasującymi stosami protokołów przez Wi-Fi, gdy ustalasz cel (pamiętając, że podczerwień jest rozwiązaniem poza tym obszarem i tam jest wiele innych nie-internetowych bezprzewodowych rozwiązań sieciowych, z którymi nadal możesz się spotkać).

Kryteria polegałyby na określeniu, co wszystkie rzeczy możesz zrobić i ile stosów możesz nauczyć się w ten sposób. Ucząc się, mam na myśli, że nadal nie chcesz grać z gadżetami i mieć świadomość, jak działa określony protokół pod maską.

Moje zalecenie to MQTT. Wszechstronny, lekki i modułowy, może nawet działać na ESP8266 (hub i klient). Protokół MQTT jest dostępny dla wielu platform, od urządzeń wbudowanych, urządzeń mobilnych i dużych systemów operacyjnych, takich jak MAC, Windows i Linux.

Protokół ma model wydawcy, model subskrybenta do komunikacji. I QoS, aby Hub mógł zapamiętać, czy subskrybent otrzymał wiadomość od wydawcy. Dzięki temu urządzenie do spania może przyspieszyć, gdy się obudzi i zacznie wyszukiwać wiadomości.

Korzystam z mojego serwera MQTT na małym Raspberry Pi Zero W, to jest jak karta kredytowa na ścianie, a dla logiki używam „Node Red” i zacząłem szukać w OpenHAB bardziej skomplikowanego rozwiązania.

Zbudowałem również własne urządzenia Arduino / MQTT dla moich urządzeń 12 V DC i korzystam z produktu opartego na ESP8266 dla moich urządzeń 230 V AC.