Lebih mudah daripada MQTT? MQTT / UDP

Saya ingin menulis artikel terperinci tentang topik ini, tetapi, jelas, tangan saya tidak menjangkau. Karena itu, pesan singkat. Saya mengembangkan dan menerapkan dalam beberapa bahasa sebagai kode prototipe versi protokol MQTT dengan nama kerja MQTT / UDP. Untuk yang tidak sabar dan mereka yang sudah mengerti segalanya dan jelas, kode pada Github

Mengapa

Saya tinggal di sebuah apartemen yang hampir sepenuhnya dikendalikan oleh sistem rumah pintar saya sendiri selama beberapa tahun. Cahaya, kontrol iklim, sensor, otomatisasi mudah, itu saja.

Selama waktu ini, saya menemukan (ya, omong-omong, saya sudah mengerti bahwa) properti utama sistem UD adalah keandalan.

Semua sistem dengan simpul pusat, menurut definisi, tidak dapat diandalkan. Oleh karena itu keinginan untuk mendapatkan interkoneksi dari komponen sistem (dan ada banyak dari mereka di rumah yang benar-benar pintar) tanpa menggunakan hub pusat.

Pada saat yang sama, kami melanjutkan dari fakta bahwa, secara umum, lalu lintas sistem UD kecil - sensor jarang perlu diperbarui lebih sering dari sekali per menit, sisa data berdasarkan kejadian (menyalakan lampu), dan lalu lintas sama sekali tidak signifikan. Bahkan setiap detik memperbarui semua data dalam sistem tidak hanya bencana, tetapi bahkan masalah yang signifikan.

Kesimpulan logisnya adalah bahwa UDP Broadcast adalah alat yang ideal.

(Ya, saya berasumsi bahwa jaringan internal apartemen ditutup oleh firewall.)

Apa yang ada di pro:

Implementasi yang sangat sederhana. Mikrokontroler minimal dengan memori kecil dapat mengirim paket UDP. Untuk sensor, bahkan penerimaan UDP tidak diperlukan.

Latensi sangat rendah. Tidak ada maju di hub pusat, waktu pengiriman paket UDP praktis slot waktu minimum dalam sistem modern.

Tidak ada titik pusat kegagalan di hub / broker. Pertimbangkan skema sederhana: dua sensor suhu, pengontrol lantai yang dipanaskan, pengontrol baterai pemanas. Dengan penggunaan MQTT / UDP, kegagalan bagian mana pun dari sistem semacam itu tidak menyebabkan kegagalan sistem secara keseluruhan.

Lalu lintas jaringan rendah. Di bawah tempat. TCP dan ucapan terima kasih hanya menambah lalu lintas, tetapi tidak menambah keandalan. Sensor yang gagal tidak akan berfungsi saat menerima ACK TCP. Dan kami mengidentifikasi kegagalan dengan tidak adanya pembaruan.

Keandalan protokol UDP itu sendiri tidak signifikan - sensor masih memperbarui data secara teratur, dan hilangnya jumlah sama sekali tidak terlihat, dan hilangnya perintah dari, misalnya, saklar secara visual dikonfirmasi oleh kegagalan sistem target. Apa yang dilakukan seseorang? Klik lagi. Namun, ini adalah batasan utama pada penerapan protokol. Ideal untuk pemungutan suara berulang.

Tidak diperlukan konfigurasi sistem. Tidak ada yang perlu mendaftarkan alamat broker, hub, dll. Namun, konfigurasi sensor masih diperlukan - Anda harus mendaftarkan ID sensor. Tetapi ketika mentransfer bagian lain dari sistem ke server lain, konfigurasi ulang komponen respons tidak diperlukan.

Sangat menarik bahwa model pertukaran data ini cocok dengan media penyiaran alami seperti saluran radio atau RS / 485. Saya belum bereksperimen dengan ini, dan protokol di lingkungan seperti itu perlu dikontrol. Adalah logis di sini untuk menerapkan CRC16 dari modbus.

Minusnya juga jelas: keandalan pengiriman ditentukan hanya oleh perangkat keras dan lalu lintas di jaringan, yah, jika musuh masuk ke jaringan, maka protokolnya langsung dikalahkan. Benar, kita akan jujur, meretas protokol rumah pintar lainnya adalah hitungan detik, jadi ini adalah kelemahan kontroversial MQTT / UDP. Minus lain yang tidak jelas adalah maksimum satu penerima per alamat IP.

Apa yang telah dilakukan dan terletak di repositori kode sumber:

  • Implementasi klien / server dalam beberapa bahasa. Ada C, Python dan Java. Saya tidak menguasai Lua (tidak bisa meletakkan semua yang Anda butuhkan, bagaimana Anda hidup dalam hal ini?) Dan Codesys (tidak dapat mengkompilasi paket, yang menemukan bahasa ini?).
  • Gerbang Minimal ke MQTT Tradisional dengan Python
  • Alat primitif untuk menampilkan lalu lintas MQTT / UDP pada jaringan

Apa yang akan saya lakukan jika saya punya lebih banyak waktu:

  • Saya akan menulis modul untuk openHUB.
  • Akan membuat varian protokol pada JSON pada port lain dan konverter ke format utama dan port. Atau gerbang di kedua arah.
  • Saya akan membuat implementasi kosong untuk platform utama. Untuk Arduino, saya melakukan pendekatan terhadap bobot dan benar-benar menguji kodenya, tetapi tidak merancang semuanya dengan benar. Untuk Raspberry, uji kasus dengan Python cocok.
  • Akan menandatangani dan mengenkripsi secara digital, tetapi tidak jelas caranya.
  • Multicast.

Terima kasih untuk itu, selamat datang di repositori

PS: Pendekatan serupa, tetapi dengan multicast, dijelaskan dalam artikel ini.

Source: https://habr.com/ru/post/id429714/


All Articles