Standar untuk perangkat WiFi yang tidak terhubung Internet?


10

Saya berencana untuk melakukan banyak otomatisasi rumah. Untuk itu saya akan meng-host jaringan WiFi pribadi yang terisolasi untuk semua perangkat saya akan terhubung. Perangkat akan berupa lampu sederhana, strip LED RGB (smd5050 dan ws2812b), termostat, kipas, pembuka jendela, pengontrol naungan jendela, dan outlet normal. Juga, IR-transmitter untuk mensimulasikan remote untuk memulai TV dll. Dan pemancar 433MHz untuk mensimulasikan remote yang dapat beralih outlet standar yang dikendalikan jarak jauh.

Sekarang saya bertanya-tanya apakah ada standar pada antarmuka seperti apa perangkat ini harus mengekspos ke jaringan WiFi.

Tentu saja saya bisa memberi setiap perangkat rute http sederhana dan kemudian menulis aplikasi yang memahami antarmuka saya, tetapi alangkah baiknya jika saya bisa menerapkan standar yang akan memungkinkan saya untuk menggunakan aplikasi dan program yang telah ditulis dan memahami standar. .

Jawaban:


7

Tentang protokol IoT, paling umum HTTP, CoAP dan MQTT digunakan pada komunikasi.

HTTP dan CoAP cocok untuk jenis REST klien ke komunikasi server dan MQTT mendukung penerbitan dan berlangganan komunikasi multi-pengguna berbasis, di mana asalnya dapat dengan mudah dari server ke klien, klien ke server dan bahkan klien ke klien.

Menjawab pertanyaan:

Gunakan REST melalui HTTP atau CoAP untuk komunikasi satu lawan satu atau MQTT untuk penggunaan lalu lintas multi titik.

Keterangan lebih lanjut

Setelah komentar di bawah saya akui jawaban saya cukup parsial, jadi saya memeriksa dan menemukan sedikit lebih banyak:

Bahkan komunikasi memiliki jenis standar berantakan, jika semua dihitung:

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

Sumber: Proyek Butler UE - Masalah Komunikasi

Juga postscapes.com memiliki daftar berikut berdasarkan berbagai aspek:

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)

Seperti terlihat dalam daftar masing-masing contoh, ada banyak dari mereka dan juga lebih banyak kebiasaan dan hak milik pasti ada.

Anda harus membuka tautan itu dan membacanya secara menyeluruh. Saya percaya Anda mungkin menemukan banyak dari ini dalam proyek Anda, setidaknya jika sensornya sangat padat, yaitu. tidak hanya komponen dalam format paling murni, tetapi bagian dari ekosistem yang sudah ada. Dalam kasus-kasus itu Anda mungkin tidak dapat menegosiasikan cara Anda menghubungkannya, Anda hanya perlu memilih antar ekosistem.

Masalah yang tepat sekarang tampaknya adalah untuk menemukan set produk yang benar atau set set (kelompok set produk) dengan tumpukan protokol yang identik atau hampir cocok melalui wifi, saat Anda menetapkan tujuannya (dengan mengingat inframerah adalah solusi dari area ini dan ada ada banyak solusi jaringan nirkabel non internet lainnya, yang mungkin masih Anda hadapi).

Kriteria adalah untuk mengidentifikasi apa semua hal yang mungkin ingin Anda lakukan, dan berapa banyak tumpukan yang ingin Anda pelajari dengan cara itu. Dengan belajar yang saya maksud Anda masih ingin bermain sedikit dengan gadget dan sadar bagaimana protokol tertentu bekerja di bawah tenda.


1
"REST over http" agak kabur. Bahkan dengan itu dalam pikiran saya bisa memikirkan seratus cara berbeda untuk merancang antarmuka terutama untuk perangkat yang mengerti lebih dari 'hidup' dan 'mati'. Idealnya saya hanya memberikan alamat IP dan jenis perangkat dan sisanya akan distandarisasi. Apakah ada yang seperti itu?
Forivin

7

Rekomendasi saya adalah MQTT. Serbaguna, ringan dan modular, bahkan dapat berjalan pada ESP8266 (Hub dan klien). Protokol MQTT tersedia untuk banyak platform dari embedded, perangkat seluler dan hingga OS besar seperti MAC, Windows dan Linux.

Protokol memiliki model Penerbit, Pelanggan untuk komunikasi. Dan QoS agar Hub dapat mengingat jika pelanggan telah menerima pesan dari penerbit. Jadi perangkat yang tidur dapat meningkat dengan cepat ketika bangun dan mencari pesan.

Saya menjalankan server MQTT saya pada Raspberry Pi Zero W kecil, seperti kartu kredit di dinding dan untuk logika saya menggunakan "Node Red" dan saya sudah mulai melihat OpenHAB untuk solusi yang lebih rumit.

Saya juga telah membangun perangkat Arduino / MQTT saya sendiri untuk perangkat 12v DC saya dan menggunakan produk berbasis ESP8266 untuk perangkat 230v AC saya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.