Hai
Seperti yang saya tulis baru-baru ini (
Artikel pendek pertama tentang MQTT / UDP ), MQTT / UDP adalah protokol yang didasarkan pada MQTT, tetapi:
- Mengikuti siaran UDP (tidak perlu perantara, hampir tidak membutuhkan konfigurasi)
- Sangat tidak mudah untuk diimplementasikan (10 baris pada C + UDP / IP stack - dan Anda mengirim data dari sensor)
- Semua orang mendengar semua orang
Di satu sisi, ini BISA, tetapi di atas Ethernet.
Mengapa
Apartemen saya sebenarnya telah hidup selama beberapa tahun di bawah kendali sistem seperti "rumah itu tidak benar-benar oligofrenik." Akan berlebihan untuk menyebutnya intelijen, tetapi cahaya dan iklim otomatis. Untuk membayangkan skala bencana - sistem ini menempati rak penuh berdebar sekitar 19 inci dan tinggi dua meter. Dua dinding rak ditempati hampir ke lantai.
Ketika saya merancang semua ini, masalah toleransi kesalahan menjadi prioritas utama. Beberapa tahun operasi telah menunjukkan: itu benar. Bantah semuanya. Cepat atau lambat. Tetapi relay elektromekanis belum gagal, dan itu adalah pada mereka eselon terakhir perlindungan terhadap kegagalan.
Masalah selanjutnya setelah toleransi kesalahan adalah kebun binatang. Karena perjalanan hidup yang alami, keingintahuan saya dan kebutuhan mendesak, Unix yang biasa pada PC biasa, Aries PLC, Raspberr + Orange PI, modul Atmega, modul berbasis NodeMCU (ESP8266) hidup dalam sistem, dan semua ini berjalan satu sama lain melalui modbus 485, modbus TCP, http, dan di sampingnya menggantung broker MQTT yang gelisah, sebagai warisan dari upaya gagal untuk beralih ke itu dengan seluruh kamp.
Mengapa upaya untuk beralih ke MQTT tidak berhasil. Pertama, untuk sebagian besinya berat atau rumit. Pada fragmen Pascal yang bersembunyi di CodeSys PLC, hanya seorang masokis yang dapat menulis MQTT. Tapi kemudian Anda perlu men-debug. Demikian pula pada atmega: Anda bisa menjejalkan, tetapi erat. Tapi ini bukan masalah keseluruhan.
MQTT sebagaimana adanya (dan dapat diterima di mana saja 3.1.1) bersikeras mengirim paket PUBLISH (yaitu, pesan kami ke broker) ke semua penerima, termasuk pengirim. Efek dari kegilaan ini mempesona - OpenHAB yang sama tidak dapat mengirim dan menerima data dalam MQTT dengan nama yang sama. Ini berarti bahwa tidak mungkin untuk mengatur bus berdasarkan MQTT (beberapa modul yang memperbarui nilai objek yang sama dan menggunakannya). Dan itulah tepatnya bagaimana komunikasi PLC harus diatur, di mana kontrol lampu utama hidup, OpenHAB, yang mengontrol cahaya dari antarmuka web dan aplikasi seluler, dan sakelar cerdas, yang ingin saya tambahkan di sini dan di sini. Itu, tentu saja, masalah ini dapat diatasi, tetapi sebenarnya itu berarti membangun protokol Anda sendiri SURFACE MQTT, dan ini sepertinya sudah terlalu banyak.
Pada saat yang sama, apa yang saya butuhkan? Kirim pembaruan nilai parameter dan dapatkan di semua titik yang tertarik. Untuk apa, sebenarnya, kakek melakukan UDP ke alamat siaran.
Setelah posting terakhir tentang Habré, salah satu pembaca untuk waktu yang lama mencela saya dengan tidak dapat diandalkannya protokol UDP. Secara spekulatif saya menjawabnya bahwa untuk IoT, UDP LEBIH dapat diandalkan daripada TCP: dengan hilangnya paket 50% pada jaringan, TCP tidak hanya berbaring, tetapi secara umum, dan sensor suhu yang mengirimkan pengukuran melalui UDP hanya akan kehilangan setengah jumlah, yang akan mempengaruhi pengoperasian sistem dengan cara apa pun. Umumnya.
Tapi itu spekulatif. Namun, liburan Tahun Baru juga diberikan kepada seseorang untuk menyelesaikan minum sampanye untuk bertanya pada dirinya sendiri: akankah kita menempatkan LAN rumah kita di sekop hari ini? Dan apa pun yang terjadi.
Saya mengambil MQTT / UDP dan menulis tes primitif. Satu sisi mengirimkan paket berturut-turut tanpa jeda di antara paket sebanyak mungkin. Yang kedua mempertimbangkan kecepatan dan kehilangan paket. Eksperimennya sederhana: kami meluncurkan ejekan ini, dan secara paralel dua TV HD menampilkan film dari Internet, dan komputer desktop menulis file besar ke NAS.
Nilai hasilnya. Saya menunggu semuanya, tapi ... kerugian maksimal untuk UDP mencapai setengah persen, dan kedua TV berhenti tampil. Jadi saya masih pesimis. Dalam jaringan rumah nyata, keandalan pengiriman UDP mendekati absolut. Namun demikian, saya mungkin akan membuat versi dengan konfirmasi dan mengirim ulang paket. Ada beberapa kesulitan, tetapi pertanyaannya dihapus sepenuhnya.
Pertanyaan kedua adalah keamanan, tetapi benar, jika mereka membobol jaringan rumah saya, hilangnya data dari sensor suhu adalah hal terakhir yang saya akan berduka. Namun, sekali lagi, tugas untuk menandatangani paket secara digital di pelacak masalah sudah ada, dan saya sudah mengerti bagaimana memperluas paket MQTT untuk implementasinya.
Secara umum, saya merencanakan pasangan perangkat pertama di jaringan rumah untuk beralih ke MQTT / UDP beberapa hari yang lalu.
Dan saya sarankan Anda mencobanya di program dan perangkat Anda:
Repositori dan
dokumentasi dalam bahasa Inggris .
Apa yang tersedia:
Implementasi yang cukup lengkap di Java, Python, dan C. Implementasi dasar pada Lua. Sejauh ini, hanya mengirim untuk Arduino dan CodeSys PLC (diuji dan bekerja pada Aries, tetapi harus melakukan apa saja).
Alat GUI untuk melihat apa yang terjadi dan mengintervensi:
Program untuk mengirim dan menerima data dalam Python, Lua dan Java.
Konektor Python untuk integrasi dengan MQTT biasa dan langsung dengan OpenHAB. Mereka bekerja perlindungan terhadap siklus, melarang siaran balik pesan selama 5 detik setelah melewati arah maju. Selain itu, ada perpustakaan untuk membatasi aliran data yang diulang. Dia memeriksa apakah sudah ada pembaruan dari topik ini untuk waktu yang ditentukan, dan jika dia lakukan, dia melewatkan pembaruan baru hanya jika data telah berubah.
Saya berencana untuk secara bertahap pindah ke protokol ini sepenuhnya, dan ini adalah salah satu contoh dari apa yang ingin saya dapatkan dengan sensor:
Ada tiga sensor dalam satu ruangan (baik, atau di jalan, itu tidak masalah). Mereka mengirim sampel melalui MQTT / UDP. Bacaan ini diterima secara bersamaan oleh sistem rumah pintar utama (OpenHAB), database historis dan monitor dinding yang menampilkan suhu untuk penduduk.
Seluruh pesona MQTT / UDP adalah bahwa dalam skema seperti itu, kegagalan setiap blok tidak menimbulkan masalah bagi orang lain. Dan ini dengan kesederhanaan mempesona protokol.
Selain itu, skema kontrol yang berlebihan dengan duplikasi mudah diimplementasikan dalam skema yang sama. Server database dapat diduplikasi tanpa masalah sama sekali. Akan lebih sulit untuk menduplikasi modul yang berhubungan dengan manajemen. Misalnya, mendengarkan suhu memberikan aksi kontrol pada radiator. Tapi mungkin ini cerita selanjutnya. Hari ini saya berencana untuk fokus mengumpulkan sinyal dari sensor dan bertukar antar modul rumah pintar.