Beberapa waktu lalu kami memperkenalkan anda . Artikel ini pada asalnya bertujuan sebagai demonstrasi perisian tegar dan sistem kawalannya. Tetapi untuk menerangkan logik termostat dan perkara yang kami laksanakan, adalah perlu untuk menggariskan keseluruhan konsep secara keseluruhan.
Mengenai automasi
Secara konvensional, semua automasi boleh dibahagikan kepada tiga kategori:
Kategori 1 β peranti "pintar" berasingan. Anda membeli mentol lampu, teko, dsb. daripada pengeluar yang berbeza. Kelebihan: Setiap peranti mengembangkan keupayaan dan meningkatkan keselesaan. Keburukan: Setiap pengeluar baharu memerlukan aplikasinya sendiri. Protokol peranti daripada pengeluar yang berbeza selalunya tidak serasi antara satu sama lain.
Kategori 2 β pemasangan PC papan tunggal atau x86 yang serasi. Ini mengalih keluar sekatan ke atas kuasa pengkomputeran dan MajorDoMo atau mana-mana pengedaran pelayan lain untuk mengurus rumah pintar dipasang pada mesin ini. Oleh itu, peranti daripada kebanyakan pengeluar disambungkan dalam satu ruang maklumat. Itu. Pelayan anda sendiri untuk rumah pintar muncul. Kelebihan: keserasian di bawah satu pusat, yang menyediakan keupayaan pengurusan yang dipertingkatkan. Keburukan: jika pelayan gagal, keseluruhan sistem kembali ke peringkat 1, i.e. menjadi berpecah-belah atau menjadi tidak berguna.
Kategori 3 - pilihan yang paling tegar. Pada peringkat pembaikan, semua komunikasi diletakkan dan semua sistem diduplikasi. Kelebihan: segala-galanya dibawa ke kesempurnaan dan kemudian rumah menjadi benar-benar pintar. Kelemahan: sangat mahal berbanding dengan kategori 1 dan 2, keperluan untuk memikirkan segala-galanya terlebih dahulu dan mengambil kira setiap butiran kecil.
Kebanyakan pengguna memilih pilihan satu dan kemudian dengan lancar beralih ke pilihan dua. Dan kemudian yang paling gigih mencapai pilihan 3.
Tetapi terdapat pilihan yang boleh dipanggil sistem teragih: setiap peranti individu akan menjadi pelayan dan pelanggan. Pada asasnya, ini adalah percubaan untuk mengambil dan menggabungkan pilihan 1 dan pilihan 2. Ambil semua kebaikan mereka dan hapuskan keburukan, untuk menangkap min emas.
Mungkin seseorang akan mengatakan bahawa pilihan sedemikian telah dibangunkan. Tetapi keputusan sedemikian tertumpu secara sempit; untuk orang yang mahir dalam pengaturcaraan. Matlamat kami adalah untuk mengurangkan halangan untuk masuk ke dalam sistem teragih tersebut, baik dalam bentuk peranti akhir dan dalam bentuk menyepadukan peranti sedia ada ke dalam sistem kami. Dalam kes termostat, pengguna hanya mengalih keluar termostat lamanya, memasang termostat pintar dan menyambungkan penderia sedia ada kepadanya. Tanpa sebarang langkah tambahan.
Mari kita lihat penyepaduan ke dalam sistem kami menggunakan contoh.
Bayangkan kita mempunyai 8 modul Sonoff pada rangkaian kita. Bagi sesetengah pengguna, kawalan melalui awan Sonoff (kategori 1) sudah memadai. Sesetengah akan mula menggunakan perisian tegar pihak ketiga dan lancar akan beralih ke kategori 2. Sebahagian besar perisian tegar pihak ketiga berfungsi pada prinsip yang sama: memindahkan data ke pelayan MQTT. OpenHub, Majordomo atau mana-mana yang lain mempunyai satu tujuan - untuk menyatukan peranti yang berbeza ke dalam satu ruang maklumat yang terletak sama ada di Internet atau pada rangkaian tempatan. Oleh itu, kehadiran Pelayan adalah wajib. Di sinilah masalah utama timbul - jika Pelayan gagal, keseluruhan sistem berhenti berfungsi secara autonomi. Untuk mengelakkan ini, sistem menjadi lebih kompleks, kaedah kawalan manual ditambah yang automasi pendua sekiranya berlaku kegagalan Pelayan.
Kami mengambil jalan yang berbeza, di mana setiap peranti berdikari. Oleh itu, Pelayan tidak memainkan peranan yang menentukan, tetapi hanya mengembangkan fungsi.
Mari kita kembali kepada eksperimen pemikiran. Mari ambil 8 modul Sonoff yang sama sekali lagi dan pasang perisian tegar Lytko di dalamnya. Semua firmware Lytko mempunyai fungsi . SSDP ialah protokol rangkaian berdasarkan suite protokol Internet untuk pengiklanan dan penemuan perkhidmatan rangkaian. Respons kepada permintaan boleh sama ada standard atau dilanjutkan. Sebagai tambahan kepada fungsi standard, kami memasukkan dalam jawapan ini penciptaan senarai peranti pada rangkaian. Oleh itu, peranti itu sendiri mencari satu sama lain, dan setiap daripada mereka akan mempunyai senarai sedemikian. Contoh helaian SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Seperti yang anda boleh lihat daripada contoh, senarai termasuk id peranti, alamat IP pada rangkaian, jenis unit (dalam kes kami, termostat berasaskan Sonoff). Senarai ini dikemas kini sekali setiap dua minit (tempoh ini mencukupi untuk bertindak balas kepada perubahan dinamik dalam bilangan peranti pada rangkaian). Dengan cara ini, kami menjejaki peranti yang ditambahkan, diubah dan dilumpuhkan tanpa sebarang tindakan pengguna. Senarai ini dihantar ke penyemak imbas atau aplikasi mudah alih, dan skrip itu sendiri menghasilkan halaman dengan bilangan blok tertentu. Setiap blok sepadan dengan satu peranti/sensor/pengawal. Secara visual senarai kelihatan seperti ini:
Tetapi bagaimana jika penderia radio lain disambungkan ke esp8266/esp32 melalui cc2530 (ZigBee) atau nrf24 (MySensors)?
Mengenai projek
Terdapat pelbagai sistem yang diedarkan di pasaran. Sistem kami membolehkan anda berintegrasi dengan yang paling popular.
Di bawah adalah projek yang satu cara atau yang lain cuba mengubah keadaan dengan ketidakserasian pengeluar yang berbeza antara satu sama lain. Ini contohnya, , atau . terikat pada pelayan MQTT, jadi ia tidak sesuai untuk contoh.
Satu pilihan untuk melaksanakan MySensors ialah get laluan berdasarkan ESP8266. Contoh selebihnya adalah pada ESP32. Dan di dalamnya anda boleh melaksanakan prinsip operasi kami untuk mengesan dan mencipta senarai peranti.
Mari kita lakukan satu lagi eksperimen pemikiran. Kami mempunyai gerbang ZESP32 atau Gerbang SLS, atau MySensors. Bagaimanakah ia boleh digabungkan dalam satu ruang maklumat? Kami akan menambah perpustakaan protokol SSDP pada fungsi standard get laluan ini. Apabila mengakses pengawal ini melalui SSDP, ia akan menambah senarai peranti yang disambungkan kepadanya kepada respons standard. Berdasarkan maklumat ini, pelayar akan menjana halaman. Secara umum ia akan kelihatan seperti ini:
Antara muka web
permohonan PWA
"ssdpList":
{
"id": 94967291, // ΡΠ½ΠΈΠΊΠ°Π»ΡΠ½ΡΠΉ ΠΈΠ΄Π΅Π½ΡΠΈΡΠΈΠΊΠ°ΡΠΎΡ ΡΡΡΡΠΎΠΉΡΡΠ²Π°
"ip": "192.168.x.x", // ip Π°Π΄ΡΠ΅Ρ Π² ΡΠ΅ΡΠΈ
"type": "thermostat" // ΡΠΈΠΏ ΡΡΡΡΠΎΠΉΡΡΠ²Π°
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 13587532,
"type": "switch"
},
{
"id": 98412557,
"type": "smoke"
},
{
"id": 57995113,
"type": "contact_sensor"
},
{
"id": 74123668,
"type": "temperature_humidity_pressure_sensor"
},
{
"id": 74621883,
"type": "temperature_humidity_sensor"
}
Contoh menunjukkan bahawa peranti ditambah secara berasingan antara satu sama lain. 3 termostat dengan alamat IP mereka sendiri dan 5 sensor berbeza dengan ID unik disambungkan. Jika penderia disambungkan ke rangkaian Wi-Fi, ia akan mempunyai IP sendiri; jika ia disambungkan ke get laluan, maka alamat IP peranti akan menjadi alamat IP get laluan.
Kami menggunakan WebSocket untuk berkomunikasi dengan peranti. Ini membolehkan anda meminimumkan kos sumber berbanding untuk mendapatkan permintaan dan mendapatkan maklumat secara dinamik apabila menyambung atau menukar.
Data diambil terus dari peranti yang dimiliki oleh blok itu, memintas pelayan. Oleh itu, jika mana-mana peranti gagal, sistem akan terus beroperasi. Antara muka web tidak memaparkan peranti yang hilang daripada senarai. Tetapi isyarat tentang kehilangan, jika perlu, akan datang dalam bentuk pemberitahuan dalam aplikasi pengguna.
Percubaan pertama untuk melaksanakan pendekatan ini ialah aplikasi PWA. Ini membolehkan anda menyimpan pangkalan blok pada peranti pengguna dan hanya meminta data yang diperlukan. Tetapi disebabkan oleh keanehan struktur, pilihan ini tidak lengkap. Dan hanya ada satu jalan keluar - aplikasi asli untuk Android dan IOS, yang sedang dalam pembangunan aktif. Secara lalai, aplikasi hanya akan berfungsi pada rangkaian dalaman. Jika perlu, anda boleh memindahkan segala-galanya ke kawalan luaran. Jadi, apabila pengguna meninggalkan rangkaian tempatan, aplikasi secara automatik beralih ke awan.
Kawalan luaran - penduaan lengkap halaman. Apabila halaman diaktifkan, pengguna boleh log masuk ke pelayan dan mengurus peranti melalui akaun peribadi mereka. Oleh itu, Pelayan mengembangkan fungsinya, membolehkan anda mengurus peranti semasa berada di luar rumah, dan tidak terikat dengan pemajuan port atau IP khusus.
Oleh itu, pilihan di atas tidak mempunyai kelemahan pendekatan pelayan, dan juga mempunyai beberapa kelebihan dalam bentuk fleksibiliti dalam menyambungkan peranti baru.
Mengenai termostat
Mari lihat sistem kawalan menggunakan termostat kami sebagai contoh.
Disediakan:
- Kawalan suhu untuk setiap termostat (dipaparkan sebagai blok berasingan);
- Menetapkan jadual operasi termostat (pagi, tengah hari, petang, malam);
- Memilih rangkaian Wi-Fi dan menyambungkan peranti kepadanya;
- Mengemas kini peranti "melalui udara";
- Menyediakan MQTT;
- Konfigurasikan rangkaian yang peranti disambungkan.
Selain mengawal melalui antara muka web, kami menyediakan yang klasik - dengan mengklik pada paparan. Terdapat monitor Nextion NX3224T024 2.4-inci di atas kapal. Pilihan jatuh padanya kerana kemudahan bekerja dengan peranti itu. Tetapi kami sedang membangunkan monitor kami sendiri berdasarkan STM32. Fungsinya tidak lebih buruk daripada Nextion, tetapi kosnya akan lebih rendah, yang akan memberi kesan positif pada harga akhir peranti.
Seperti mana-mana skrin termostat yang menghormati diri sendiri, Nextion kami boleh:
- tetapkan suhu yang diperlukan oleh pengguna (menggunakan butang di sebelah kanan);
- hidupkan dan matikan mod operasi yang dijadualkan (butang H);
- paparan operasi geganti (anak panah di sebelah kiri);
- mempunyai perlindungan kanak-kanak (klik fizikal disekat sehingga kunci dikeluarkan);
- memaparkan kekuatan isyarat WiFi.
Di samping itu, menggunakan monitor anda boleh:
- pilih jenis sensor yang dipasang oleh pengguna;
- menguruskan ciri kunci kanak-kanak;
- kemas kini firmware.
Dengan mengklik pada bar WiFi, pengguna akan mengetahui maklumat mengenai rangkaian yang disambungkan. Kod QR digunakan untuk memasangkan peranti dalam perisian tegar HomeKit.
Demo bekerja dengan paparan:
Kami telah membangunkan dengan tiga termostat yang disambungkan.
Anda mungkin bertanya, "Apakah yang istimewa tentang termostat anda?" Kini di pasaran terdapat banyak termostat dengan fungsi Wi-Fi, operasi berjadual dan kawalan sentuh. Dan peminat telah menulis modul untuk berinteraksi dengan sistem rumah pintar yang paling popular (Majordomo, HomeAssistant, dsb.).
Termostat kami serasi dengan sistem sedemikian dan mempunyai semua perkara di atas. Tetapi ciri tersendiri ialah termostat sentiasa diperbaiki, terima kasih kepada fleksibiliti sistem. Dengan setiap kemas kini fungsi akan berkembang. Kepada kaedah standard pengurusan sistem (mengikut jadual), kami akan menambah satu penyesuaian. Aplikasi ini membolehkan anda mendapatkan geolokasi pengguna. Terima kasih kepada ini, sistem akan menukar mod operasi secara dinamik bergantung pada lokasinya. Dan modul cuaca akan membolehkan anda menyesuaikan diri dengan keadaan cuaca.
Dan kebolehkembangan. Sesiapa sahaja boleh menggantikan termostat konvensional mereka yang sedia ada dengan termostat kami. Dengan usaha yang minimum. Kami telah memilih 5 daripada penderia paling popular di pasaran dan menambah sokongan untuk mereka. Tetapi walaupun penderia mempunyai ciri eksklusif, pengguna akan dapat menyambungkannya ke termostat kami. Untuk melakukan ini, anda perlu menentukur termostat untuk berfungsi dengan penderia tertentu. Kami akan memberikan arahan.
Apabila menyambungkan termostat atau mana-mana peranti lain, ia muncul serentak di mana-mana: dalam antara muka web dan dalam aplikasi PWA. Penambahan peranti berlaku secara automatik: anda hanya perlu menyambungkannya ke rangkaian Wi-Fi.
Sistem kami tidak memerlukan Pelayan, dan jika gagal, ia tidak akan berubah menjadi labu. Walaupun salah satu komponen gagal, sistem tidak mula beroperasi dalam senario kecemasan. Pengawal, penderia, peranti - setiap elemen adalah Pelayan dan pelanggan, oleh itu autonomi sepenuhnya.
Bagi mereka yang berminat, rangkaian sosial kami: , , , , .
E-mel: [e-mel dilindungi]
PS Kami tidak menggalakkan anda untuk meninggalkan Pelayan. Kami juga menyokong pelayan MQTT dan mempunyai awan kami sendiri. Matlamat kami adalah untuk membawa kestabilan dan kebolehpercayaan sistem ke tahap yang baharu. Supaya Pelayan bukan titik lemah, tetapi melengkapkan fungsi dan menjadikan sistem lebih mudah.
Sumber: www.habr.com