Beberapa waktu lalu, kami memperkenalkan Anda pada
termostat pintar . Artikel ini awalnya disusun sebagai demonstrasi dari firmware dan sistem kontrolnya. Tetapi untuk menjelaskan logika termostat dan apa yang telah kami terapkan, perlu untuk menguraikan seluruh konsep.
Tentang otomatisasi
Secara konvensional, semua otomatisasi dapat dibagi menjadi tiga kategori:
Kategori 1 - pisahkan perangkat "pintar". Anda mendapatkan bola lampu, teko, dll. Dari berbagai produsen. Plus: setiap perangkat memperluas peluang dan meningkatkan kenyamanan. Cons: setiap pabrikan baru membutuhkan aplikasinya sendiri. Protokol perangkat dari berbagai produsen seringkali tidak kompatibel satu sama lain.
Kategori 2 - pemasangan PC papan tunggal atau kompatibel x86. Ini menghilangkan keterbatasan daya komputasi, dan MajorDoMo atau distribusi server lainnya untuk mengelola rumah pintar dipasang di mesin ini. Dengan demikian, sebagian besar perangkat produsen terhubung dalam satu ruang informasi. Yaitu muncul server Anda untuk rumah pintar. Kelebihan: kompatibilitas di bawah satu pusat, yang menyediakan kemampuan manajemen tingkat lanjut. Cons: dalam kasus server rusak / gagal, seluruh sistem kembali ke tahap 1, mis. menjadi terfragmentasi, atau dianggap tidak berguna.
Kategori 3 adalah versi yang paling hardcore. Pada tahap perbaikan, semua komunikasi diletakkan dan semua sistem digandakan. Pro: semuanya dibawa ke ideal dan kemudian rumah menjadi sangat pintar. Cons: biaya sangat tinggi dibandingkan dengan kategori 1 dan 2, kebutuhan untuk berpikir di depan segalanya dan memperhitungkan setiap hal kecil.
Sebagian besar pengguna memilih opsi satu, dan kemudian beralih dengan mulus ke opsi dua. Dan di masa depan, opsi jangkauan yang paling gigih 3.
Tetapi ada opsi yang bisa disebut sistem terdistribusi: setiap perangkat individu akan menjadi server dan klien. Sebenarnya, ini adalah upaya untuk mengambil dan menggabungkan opsi 1 dan opsi 2. Ambil semua plus dan hilangkan minusnya, tangkap jalan tengah.
Mungkin seseorang akan mengatakan bahwa opsi semacam itu telah dikembangkan. Tetapi keputusan seperti itu ditargetkan secara sempit; untuk orang yang mengerti pemrograman. Tujuan kami adalah untuk menurunkan ambang batas untuk masuk ke sistem terdistribusi seperti itu dalam bentuk perangkat akhir dan dalam bentuk integrasi perangkat yang ada ke dalam sistem kami. Dalam kasus termostat, pengguna cukup melepas termostat lamanya, memasang termostat yang cerdas, dan menghubungkan sensornya ke termostat tersebut. Tanpa tindakan tambahan.
Mari pertimbangkan integrasi ke dalam sistem kami menggunakan contoh.
Bayangkan kita memiliki 8 modul Sonoff di jaringan kita. Beberapa pengguna mungkin memiliki kontrol yang cukup atas cloud Sonoff (kategori 1). Beberapa akan menggunakan firmware pihak ketiga dan dengan lancar pindah ke kategori 2. Sebagian besar firmware pihak ketiga bekerja dengan prinsip yang sama: transfer data ke server MQTT. OpenHub, Majordomo atau lainnya melayani tujuan yang sama - untuk menggabungkan perangkat yang berbeda menjadi ruang informasi tunggal yang terletak di Internet atau di jaringan lokal. Oleh karena itu, keberadaan Server adalah wajib. Dari sini masalah utama muncul - ketika Server gagal, seluruh sistem berhenti bekerja secara mandiri. Untuk mencegah ini, sistem menjadi lebih rumit, metode kontrol manual ditambahkan yang menduplikasi otomatisasi jika terjadi kegagalan Server.
Kami mengambil jalur yang berbeda, di mana setiap perangkat mandiri. Dengan demikian, Server tidak memainkan peran yang menentukan, tetapi hanya memperluas fungsionalitasnya.
Kembali ke eksperimen pemikiran. Sekali lagi, ambil 8 modul Sonoff yang sama dan instal firmware Lytko di dalamnya. Di semua firmware Lytko, fungsi
SSDP diimplementasikan. SSDP adalah protokol jaringan yang didasarkan pada seperangkat protokol Internet yang digunakan untuk mengiklankan dan menemukan layanan jaringan. Respons terhadap permintaan dapat berupa standar atau lanjutan. Selain fungsi standar, kami menyertakan jawaban ini untuk membuat daftar perangkat di jaringan. Dengan demikian, perangkat itu sendiri menemukan satu sama lain, dan masing-masing dari mereka akan memiliki daftar seperti itu. Contoh lembar SSDP:
"ssdpList": { "id": 94967291, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967282, "ip": "192.168.xx", "type": "thermostat" }
Seperti yang Anda lihat dari contoh, daftar termasuk id perangkat, alamat IP jaringan, jenis blok (dalam kasus kami, termostat berbasis Sonoff). Daftar ini diperbarui setiap dua menit sekali (interval ini cukup untuk menanggapi perubahan dinamis dalam jumlah perangkat di jaringan). Dengan demikian, kami melacak penambahan, modifikasi, dan pemutusan perangkat tanpa tindakan apa pun oleh pengguna. Daftar ini dikirim ke browser atau aplikasi seluler, dan skrip itu sendiri membentuk halaman dengan jumlah blok tertentu. Setiap blok sesuai dengan satu perangkat / sensor / pengontrol. Secara visual, daftar ini terlihat seperti ini:
Tetapi jika sensor radio lainnya terhubung ke esp8266 / esp32 melalui cc2530 (ZigBee) atau nrf24 (MySensors)?
Tentang proyek
Ada berbagai sistem terdistribusi di pasar. Sistem kami memungkinkan Anda untuk berintegrasi dengan yang paling populer.
Di bawah ini adalah proyek yang entah bagaimana mencoba mengubah situasi dengan ketidakcocokan berbagai produsen di antara mereka sendiri. Ini, misalnya,
SLS Gateway ,
MySensors atau
ZESP32 .
ZigBee2MQTT diikat ke server MQTT, jadi tidak cocok misalnya.
Salah satu opsi implementasi untuk MySensors adalah gateway berbasis ESP8266. Contoh lain ada di ESP32. Dan di dalamnya Anda dapat menerapkan prinsip deteksi dan pembuatan daftar perangkat kami.
Mari kita lakukan eksperimen pemikiran lain. Kami memiliki gateway ZESP32 atau SLS Gateway, atau MySensors. Bagaimana mereka dapat digabungkan dalam ruang informasi tunggal? Kami akan menambahkan pustaka protokol SSDP ke fungsi standar gateway ini. Saat mengakses pengontrol ini melalui SSDP, itu akan menambah ke jawaban standar daftar perangkat yang terhubung dengannya. Berdasarkan informasi ini, browser akan membentuk halaman. Secara umum, akan terlihat seperti ini:
Antarmuka web
Aplikasi PWA "ssdpList": { "id": 94967291, // "ip": "192.168.xx", // ip "type": "thermostat" // }, { "id": 94967292, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967293, "ip": "192.168.xx", "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 bahwa perangkat ditambahkan satu sama lain secara terpisah. 3 termostat dengan alamat ip mereka sendiri dan 5 sensor berbeda dengan id unik terhubung. Jika sensor terhubung ke jaringan Wi-Fi, maka ia akan memiliki ip sendiri, jika terhubung ke gateway, maka alamat IP perangkat akan menjadi alamat IP gateway.
Untuk berkomunikasi dengan perangkat, kami menggunakan WebSocket. Ini memungkinkan Anda untuk meminimalkan biaya sumber daya dibandingkan dengan mendapatkan-permintaan dan menerima informasi secara dinamis saat menghubungkan atau mengubah.
Data diambil langsung dari perangkat tempat unit tersebut berada, melewati server. Dengan demikian, jika ada perangkat yang gagal, sistem akan terus berfungsi. Antarmuka web tidak hanya menampilkan perangkat yang hilang dari daftar. Tetapi sinyal kerugian, jika perlu, akan datang dalam bentuk pemberitahuan di aplikasi pengguna.
Upaya pertama untuk menerapkan pendekatan ini adalah aplikasi PWA. Ini memungkinkan Anda untuk menyimpan pangkalan blok pada perangkat pengguna dan hanya meminta data yang diperlukan. Tetapi karena kekhasan struktur, opsi semacam itu lebih rendah. Dan hanya ada satu jalan keluar - aplikasi asli untuk Android dan iOS, yang saat ini sedang dalam pengembangan aktif. Secara default, aplikasi hanya akan berfungsi di jaringan internal. Jika perlu, Anda dapat mentransfer semuanya ke kontrol eksternal. Jadi, ketika pengguna meninggalkan jaringan lokal, aplikasi secara otomatis beralih ke cloud.
Manajemen eksternal - duplikasi penuh halaman. Ketika halaman diaktifkan, pengguna dapat masuk ke server dan mengelola perangkat melalui akun pribadi. Dengan demikian, Server memperluas fungsionalitasnya, memungkinkan Anda untuk mengelola perangkat saat berada di luar rumah, dan tidak terikat dengan penerusan port atau ip khusus.
Dengan demikian, opsi di atas bebas dari kelemahan pendekatan server, dan juga memiliki beberapa keuntungan dalam bentuk fleksibilitas menghubungkan perangkat baru.
Tentang termostat
Pertimbangkan sistem kontrol menggunakan termostat kami sebagai contoh.
Disediakan oleh:
- Kontrol suhu setiap termostat (ditampilkan sebagai unit terpisah);
- Mengatur jadwal termostat (pagi, siang, malam, malam);
- Memilih jaringan Wi-Fi dan menghubungkan perangkat ke dalamnya;
- Memperbarui perangkat "over the air";
- Konfigurasikan MQTT;
- Konfigurasikan jaringan tempat perangkat terhubung.
Selain mengelola melalui antarmuka web, mereka menyediakan antarmuka klasik - dengan mengetuk layar. Onboard adalah monitor 2,4 inci Nextion NX3224T024. Pilihannya jatuh pada dia karena kesederhanaan bekerja dengan perangkat. Namun dalam perkembangannya adalah monitornya sendiri berbasis STM32. Fungsinya tidak lebih buruk daripada Nextion, tetapi biayanya lebih murah, yang secara positif akan mempengaruhi harga akhir perangkat.
Seperti layar thermostat lainnya, Nextion kami dapat:
- atur suhu yang diperlukan untuk pengguna (menggunakan tombol di sebelah kanan);
- nyalakan dan matikan mode operasi yang dijadwalkan (tombol H);
- operasi tampilan relai (panah di sebelah kiri);
- memiliki perlindungan dari anak-anak (klik fisik diblokir hingga kunci dilepas);
- menampilkan kekuatan sinyal WiFi.
Selain itu, menggunakan monitor Anda dapat:
- pilih jenis sensor yang dipasang oleh pengguna;
- mengelola fungsi perlindungan anak;
- perbarui firmware.
Dengan mengklik pada bilah WiFi, pengguna akan mengetahui informasi tentang jaringan yang terhubung. Kode QR digunakan untuk memasangkan perangkat dalam firmware HomeKit.
Demo pekerjaan dengan layar:
Kami mengembangkan
halaman demo dengan tiga termostat yang terhubung.
Anda bertanya: "Apa kekhasan termostat Anda?" Sekarang ada banyak termostat di pasaran dengan fungsi Wi-Fi, pekerjaan terjadwal, kontrol sentuh. Dan penggemar memiliki modul tertulis untuk berinteraksi dengan sistem rumah pintar paling populer (Majordomo, HomeAssistant, dll).
Thermostat kami kompatibel dengan sistem seperti itu dan memiliki semua hal di atas. Tetapi fitur yang khas adalah bahwa termostat terus ditingkatkan, berkat fleksibilitas sistem. Dengan setiap pembaruan, fungsionalitas akan berkembang. Untuk cara standar mengelola sistem (sesuai jadwal), kami akan menambahkan yang adaptif. Aplikasi ini memungkinkan Anda untuk mendapatkan geolokasi pengguna. Karena ini, sistem akan secara dinamis mengubah mode operasi tergantung pada lokasinya. Dan modul cuaca akan memungkinkan Anda untuk menyesuaikan dengan kondisi cuaca.
Dan diperpanjang. Siapa pun dapat mengganti termostat yang biasa dipasang dengannya dengan kami. Dengan sedikit usaha. Kami memilih 5 sensor paling populer di pasar dan menambahkan dukungan mereka. Tetapi bahkan dalam kasus karakteristik sensor eksklusif, pengguna akan dapat menghubungkannya ke termostat kami. Untuk melakukan ini, Anda perlu mengkalibrasi termostat agar bekerja dengan sensor tertentu. Kami akan memberikan instruksi.
Saat menghubungkan termostat atau perangkat lain, itu muncul secara bersamaan di mana-mana: baik di antarmuka web dan di aplikasi PWA. Menambahkan perangkat otomatis: cukup sambungkan ke jaringan Wi-Fi.
Sistem kami tidak membutuhkan Server, dan jika terjadi kegagalan, ia tidak berubah menjadi labu. Bahkan jika salah satu komponen gagal, sistem tidak memulai sesuai dengan skenario darurat. Pengontrol, sensor, perangkat - setiap elemen adalah Server dan klien, sehingga sepenuhnya otonom.
Bagi yang berminat, jejaring sosial kami:
Telegram ,
Instagram ,
Berita Telegram ,
VK ,
Facebook .
Email: shop@lytko.com
PS kami tidak mendesak untuk meninggalkan Server. Kami juga memiliki dukungan untuk server MQTT dan memiliki cloud kami sendiri. Tujuan kami adalah untuk membawa stabilitas dan keandalan sistem ke tingkat yang sama sekali baru. Sehingga Server bukanlah titik lemah, tetapi menambah fungsionalitas dan membuat sistem lebih nyaman.