Cloud Smart Home. Bagian 2: Layanan Cloud

Saya melanjutkan serangkaian tiga artikel tentang cloud smart home.

Dalam artikel sebelumnya , peralatan untuk merasakan rumah pintar dipertimbangkan, serta algoritma untuk mengubah data sensorik menjadi perintah kontrol untuk perangkat eksekutif. Komponen utama dari rumah pintar adalah pengontrol, yang sebagian besar waktu bekerja secara mandiri sesuai dengan logika yang ditetapkan pada tahap pengaturan. Berbagai perangkat (kamera IP, sensor, aktuator) terhubung ke pengontrol, yang mengirimkan data yang diterima dari perangkat ini ke cloud.

Sekarang mari kita bicara tentang arsitektur layanan cloud untuk menyimpan dan memproses informasi dari sensor dan kamera.

Manfaat Layanan Cloud

Layanan cloud rumah pintar menawarkan cara sederhana, fleksibel, dan murah untuk menyimpan dan mengakses data yang diterima dari perangkat rumah pintar. Pengguna layanan cloud tidak perlu khawatir tentang keamanan data mereka. Kemampuan server media multiprosesor, dilengkapi dengan keranjang disk dengan array RAID dari beberapa drive 10 - 12 TB, jauh melebihi kapasitas kartu SD atau Flash di dalam pengontrol rumah pintar. Selain itu, kartu memori tidak dapat diandalkan karena memiliki siklus penulisan ulang yang terbatas dan sering gagal. Kedalaman penyimpanan data di cloud ditentukan oleh tarif pengguna dan mudah dikonfigurasi di akun pribadinya.

Selain itu, untuk mengakses data tidak perlu "port forwarding" pada router pengguna ketika perangkat rumah pintar disembunyikan dari jaringan eksternal oleh NAT. Di akun pribadi Anda, dapat diakses dari perangkat seluler, Anda dapat dengan mudah mengonfigurasi konfigurasi dan logika rumah pintar.

Nyaman tidak hanya untuk menyimpan data di cloud, tetapi juga untuk memprosesnya, memberikan pengguna statistik untuk berbagai periode waktu. Di bawah ini kami akan mempertimbangkan contoh penghitungan suhu kamar rata-rata per minggu berdasarkan pengukuran multisensor.

Arsitektur Layanan Cloud

Dalam artikel sebelumnya, kami berbicara tentang pengontrol rumah pintar yang diinstal di sisi pengguna dan berinteraksi dengan layanan cloud menggunakan beberapa protokol:

• MQTT digunakan untuk bertukar pesan JSON antara pengontrol dan server logika bisnis;
• HTTP untuk mendapatkan alamat IP dari server media yang paling tidak dimuat dari load balancer dari cluster server media;
• RTMP untuk mentransfer aliran H.264 + AAC ke server media.

Sekarang kita akan mempertimbangkan layanan cloud rumah pintar - komponen utama yang terdiri darinya, dan bagaimana interaksi dengan pengendali rumah pintar.


(klik pada gambar untuk membuka dalam resolusi yang lebih tinggi)

Server logika bisnis adalah elemen kunci dalam seluruh skema pertukaran informasi dalam layanan cloud. Tujuan utamanya adalah untuk mengelola berbagai subsistem server melalui antarmuka API RESTful. Ini mengimplementasikan logika layanan cloud berdasarkan pada model pengguna : merekam arsip video dan pengukuran sensor tergantung pada tarif yang dipilih, interaksi antara pengguna dan pengontrol rumah pintar, dll.

Broker MQTT diperlukan untuk bertukar pesan JSON antara pengontrol rumah pintar yang diinstal pada sisi klien dan server logika bisnis. Klien berlangganan topik dalam broker yang berfungsi sebagai saluran pesan. Sebagai broker MQTT, Eclipse Mosquitto digunakan .

Cluster server media adalah sistem terdistribusi untuk menyimpan, memproses, mencari, dan memutar informasi video untuk kamera IP rumah pintar yang keruh. Penyeimbang beban khusus mengumpulkan informasi tentang kinerja saat ini dari setiap server dalam gugus, menghitung yang paling sedikit dimuat dan melaporkan alamat IP-nya ke pengontrol rumah pintar, yang mentransfer video dari kamera ke sana.

Basis data cloud diperlukan untuk menyimpan model pengguna layanan cloud, konfigurasi dan status peralatan saat ini, serta meta-informasi tentang entri arsip video. Sebagai implementasi dari basis data cloud, DBMS MySQL digunakan.

Touch Database adalah database NoSQL non-relasional. Ini menyimpan acara dan pengukuran sensor rumah pintar, dipesan oleh waktu. Penggunaan InfluxDB DBMS, yang dioptimalkan untuk bekerja dengan tipe data ini, secara signifikan meningkatkan kinerja layanan cloud.

Backend aplikasi klien adalah aplikasi server yang fungsi utamanya adalah untuk menyediakan data yang diterima dari cloud dan menyentuh basis data dalam format yang nyaman untuk tampilan selanjutnya oleh aplikasi klien pada perangkat pengguna. Backend juga menghasilkan perintah kontrol dalam format JSON untuk pengontrol rumah pintar. Backend didasarkan pada kerangka PHP Laravel . Ini akan dibahas secara lebih rinci di artikel selanjutnya tentang aplikasi klien untuk berinteraksi dengan cloud smart home.

Penyedia pemberitahuan push mengirimkan pesan tentang peristiwa rumah pintar ke perangkat seluler pengguna sehingga ia dapat dengan cepat melakukan intervensi dalam situasi (misalnya, ketika kebocoran air atau asap muncul, hubungi layanan respons yang sesuai). Layanan OneSignal dipilih sebagai penyedia pemberitahuan Push, yang memiliki antarmuka API yang nyaman dan fungsi identifikasi perangkat seluler, yang diperlukan untuk pengoperasian notifikasi yang benar di dalam akun pribadi pengguna.

Server logika bisnis

Seperti yang disebutkan sebelumnya, server logika bisnis adalah komponen kunci dari cloud smart home. Berdasarkan model pengguna (deskripsi informasi tentang pengguna sistem, yang mencakup fitur sistem, personal, keuangan dan logis), ia mengelola berbagai layanan di dalam cloud yang memiliki implementasi dan fungsi yang berbeda dan berkomunikasi satu sama lain melalui antarmuka API yang tenang.



Modul logika bisnis di dalam server bertanggung jawab untuk operasi berikut:

1. mengelola penyimpanan pengukuran sensor dan peristiwa detektor gerakan dari kamera IP rumah pintar di dalam basis data sentuh;
2. mengelola perekaman aliran media dari siaran kamera IP oleh pengontrol rumah pintar dalam arsip server media (konstanta / dengan detektor gerakan);
3. terjemahan perintah dari aplikasi klien ke pengontrol rumah pintar;
4. menyiarkan konfigurasi pengontrol rumah pintar (perangkat yang terhubung, aturan logika produksi yang ditentukan oleh pengguna);
5. mengirimkan pemberitahuan push tentang status pengontrol rumah pintar dan perangkat yang terhubung ke aplikasi klien.

Fitur server logika bisnis adalah komunikasi antar proses dengan aplikasi jarak jauh yang berjalan pada beberapa server di Internet. Sebagian besar waktu, aplikasi server logika bisnis tidak dapat digunakan pada kunci I / O, sehingga dirancang berdasarkan arsitektur multi-utas dan terdiri dari serangkaian subtugas terbatas.

Untuk memastikan efisiensi maksimum, implementasi internal server logika bisnis harus menjadi yang paling sederhana ( prinsip KISS ). Karena model pengguna sepenuhnya deterministik dan tidak mengandung perubahan hubungan antar fitur, tidak perlu mekanisme inferensi yang fleksibel (seperti pada pengontrol rumah pintar, di mana logika pengguna dikonfigurasikan oleh pengguna). Oleh karena itu, operasi modul logika bisnis di dalam server dapat dijelaskan oleh diagram blok algoritmik konvensional dengan transisi bersyarat.


(klik pada gambar untuk membuka dalam resolusi yang lebih tinggi)

Segera setelah memulai, server logika bisnis masuk ke status menunggu untuk pesan menggunakan protokol MQTT (dari pengontrol rumah pintar) dan HTTP (dari backend aplikasi klien). Jika pesan tiba melalui HTTP, ini berarti bahwa pengguna berinteraksi dengan aplikasi klien dan mengirimkan perintah ke pengontrol rumah pintar atau memperbarui konfigurasinya. Agar pesan dari klien jatuh ke dalam pengontrol rumah pintar, itu dikirim oleh server logika bisnis ke topik yang sesuai dari broker MQTT, di mana controller berlangganan (sub- tugas SendGatewayMessage ).

Pada tahap inisialisasi, pengontrol rumah pintar menunggu pengguna untuk mendaftarkannya di akun pribadi mereka. Oleh karena itu, subtugas CheckGatewayExistance dilakukan , yang memeriksa status terkait di database cloud MySQL. Untuk mendaftar di akun pribadi Anda, controller mengirim konfigurasi penuhnya ke server business logic, dan pada gilirannya, menyiarkan backend-nya ke aplikasi klien ( SendBackend subtask), yang membuat dan memperbarui catatan konfigurasi di database cloud dan touch.

Ketika pengontrol rumah pintar berhasil terdaftar di akun pribadi pengguna, server logika bisnis memuat model pengguna dari basis data cloud ke dalam RAM-nya dan mulai memproses pesan dari kamera IP dan sensor Z-Wave sesuai dengan algoritma logika bisnis berikut ini.

Pesan JSON dari sensor Z-Wave dengan bidang informasi:

{ "vendor": "*****", "version": "3.0.0", "timestampMs": "1571754749561", "clientType": "gateway", "deviceId": "c8e8de37-d301-45f4-ba01-************", "deviceType": "sensor", "protocol": "zwave", "messageType": "sensorData", "homeId": "0xefa0cfa7", "nodeId": "19", "sensorType": "SENSOR MULTILEVEL", "label": "Temperature", "sensorData": "26.1", "units": "C", "gatewayId": "6774f85a-0a5b-4059-9b68-************" } 

Ketika pesan dari sensor Z-Wave tiba melalui protokol MQTT, subtugas berikut dilakukan:

• StoreSensorDataMySQL memperbarui (UPDATE) catatan yang ada di database cloud MySQL, di mana informasi tentang keadaan saat ini dan pengukuran dari sensor disimpan. Ini diperlukan untuk aplikasi klien yang menampilkan keadaan rumah pintar saat ini untuk pengguna;
• StoreSensorDataInfluxDB menambahkan (INSERT) catatan baru ke basis data sentuh InfluxDB, di mana sejarah pengukuran dari sensor disimpan. Informasi ini digunakan dalam perhitungan data statistik untuk berbagai periode waktu (misalnya, konsumsi energi per hari, bulan atau tahun) dan ditampilkan dalam aplikasi klien dalam bentuk grafik dan tabel;
• SendPushNotification menghasilkan pesan JSON yang berisi cap waktu, nama sensor, deskripsi teks acara, pengenal ponsel cerdas pengguna yang dengannya ia masuk ke akun pribadinya, pengenal internal aplikasi dalam sistem penyedia OneSignal. Selanjutnya, pesan ini dikirim ke penyedia pemberitahuan push melalui RESTful API https://onesignal.com/api/v1/notifications , yang mengirimkannya ke ponsel cerdas pengguna.

Contoh pesan JSON dari kamera IP dengan bidang informasi:

 { "vendor": "*****", "version": "3.0.0", "timestampMs": "1571753150317", "clientType": "gateway", "deviceId": "1616453d-30cd-44b7-9bf0-************", "deviceType": "camera", "protocol": "onvif", "messageType": "deviceState", "deviceState": "streamingOn", "mediaserverIp": "***.***.***.***", "applicationName": "rtp-live-iot", "gatewayId": "6774f85a-0a5b-4059-9b68-************" } 

Ketika pesan datang dari kamera IP menggunakan protokol MQTT, server logika bisnis mengekstrak tipenya dari bidang messageType . Bergantung pada nilai bidang ini, tindakan berikut dilakukan:

• "MessageType": "deviceState" - pesan berisi informasi tentang perubahan status kamera IP. Subtugas UpdateCameraState dilakukan , memperbarui informasi dalam basis data cloud. Jika bidang deviceState adalah streamingOn atau streamingOff (kamera IP mengirim / menghentikan aliran data ke server media), sub-tugas RecordMediaStream dijalankan , yang menghasilkan perintah untuk mengaktifkan / menonaktifkan mode perekaman arsip dan mengirimkannya ke server media, dengan mempertimbangkan model pengguna;
• "MessageType": "sensorData" - informasi tentang pengoperasian detektor gerakan pada kamera IP. Jika dalam model pengguna mode perekaman arsip diatur ke "oleh detektor gerakan", maka subtugas RecordMediaStream dijalankan . Selanjutnya, subtasks StoreSensorDataInfluxDB (menyimpan riwayat detektor dalam database sentuh) dan SendPushNotification (mengirim pemberitahuan push melalui penyedia) dilakukan;
• "MessageType": "preview" - pesan berisi bingkai gambar mini dari kamera IP, yang secara berkala dikirim ke cloud. Subtitel StorePreview menyimpannya dalam basis data cloud. Kemudian digunakan dalam aplikasi klien saat menampilkan daftar kamera;
• "MessageType": "command" - perintah yang dikirim oleh pengontrol rumah pintar ketika pengguna mengubah pengaturannya melalui antarmuka Web. Sub-tugas RecordMediaStream dilakukan , yang, tergantung pada model pengguna, menghidupkan / mematikan mode perekaman pada server media.

(klik pada gambar untuk membuka dalam resolusi yang lebih tinggi)

Sebagai hasil dari pekerjaan modul logika bisnis, antrian tugas dibentuk - urutan bagian minimal dari kode yang dieksekusi secara independen satu sama lain. Antrian tugas ditransfer ke kumpulan utas , yang mendistribusikan tugas di antara inti bebas prosesor pusat. Ketika kunci I / O terjadi selama eksekusi, utas berhenti dan memasuki status siaga dan membebaskan inti dari prosesor pusat, yang memungkinkan kumpulan utas untuk memulai eksekusi segera tugas berikutnya dari antrian. Pada saat kunci I / O dilepaskan, utas yang diblokir mengubah statusnya menjadi berfungsi dan melanjutkan eksekusi segera setelah salah satu inti dari prosesor pusat dibebaskan.

Dengan demikian, dengan menguraikan tugas logika bisnis menjadi banyak sub tugas terpisah yang dijalankan secara bersamaan, kinerja server logika bisnis meningkat. Penskalaan sistem dicapai dengan meningkatkan jumlah inti dari prosesor pusat dan meningkatkan jumlah server logika bisnis dalam sistem.

Aplikasi server logika bisnis dikembangkan dalam C ++ dan berjalan sebagai layanan systemd dari sistem operasi Linux Debian Sarge. Untuk pemantauan kinerja tambahan, sistem pemantauan sumber daya monit digunakan, yang memulai kembali layanan jika terjadi masalah kinerja.

Saat ini, layanan cloud menjalankan satu server logika bisnis yang berjalan di mesin virtual Yandex. Cloud. Parameter mesin virtual - 4 inti vCPU dengan pangsa dijamin 20%, 2 GB RAM, 100 GB HDD. Menurut perhitungan, kinerja ini cukup untuk memproses pesan dari ~ 1000 pengontrol rumah pintar dengan 3 kamera IP dan 5 sensor Z-Wave masing-masing (perhitungan akan diklarifikasi selama pengoperasian sistem).

Server media

Server media adalah server khusus tempat perangkat lunak khusus diinstal untuk:

• menerima aliran data video dan audio dari perangkat encoder menggunakan protokol jaringan khusus;
• menyimpan data dalam bentuk file arsip dalam sistem file-nya;
• Menyiarkan informasi dari file arsip dalam format streaming standar untuk pemutaran pada perangkat klien.

Wowza Streaming Engine 4.7.2 dengan modul tambahan yang dikembangkan dalam bahasa Jawa digunakan sebagai server media dalam sistem cloud smart home untuk merekam data streaming ke arsip file dan untuk bekerja dengan basis data cloud.


(klik pada gambar untuk membuka dalam resolusi yang lebih tinggi)

Aliran media dari pengontrol rumah pintar dalam format RTMP memasuki server media dan disejajarkan dengan stempel waktu dalam buffer jitter . Ini diperlukan untuk mengkompensasi efek dari keterlambatan paket jaringan saat mentransmisikan aliran data melalui Internet.

Untuk merekam streaming video ke sistem file server media sebagai file MP4, server logika bisnis mengirim perintah berikut ke server media melalui RESTful HTTP API:

 http://<mediaserverIp>:<port>/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/rtp-live-iot/instances/_definst_/streamrecorders/1616453d-30cd-44b7-9bf0-************ { "instanceName": "_definst_", "fileVersionDelegateName": "CustomFileVersionDelegate", "serverName": "", "recorderName": "1616453d-30cd-44b7-9bf0-************", "segmentSchedule": "", "outputPath": "", "currentFile": "", "applicationName": "rtp-live-iot", "fileTemplate": "", "segmentationType": "SegmentByDuration", "fileFormat": "MP4", "recorderState": "", "option": "", "currentSize": "0", "segmentSize": "0", "segmentDuration": "1800000", "backBufferTime": "0", "currentDuration": "0", "startOnKeyFrame": "true", "recordData": "false", "moveFirstVideoFrameToZero": "true", "defaultRecorder": "false", "splitOnTcDiscontinuity": "false" } 

Di bidang recorderName , nama aliran video (pengidentifikasi kamera IP pada pengontrol rumah pintar) ditunjukkan , dalam bidang fileVersionDelegateName , nama kelas yang diwarisi untuk menentukan jalur folder dan nama file. Kode kelas Java ditunjukkan dalam daftar berikut:

 import java.io.File; import java.util.Calendar; import java.util.TimeZone; import com.wowza.wms.livestreamrecord.manager.IStreamRecorder; import com.wowza.wms.livestreamrecord.manager.IStreamRecorderFileVersionDelegate; import com.wowza.wms.logging.WMSLoggerFactory; public class CustomFileVersionDelegate implements IStreamRecorderFileVersionDelegate { @Override public String getFilename(IStreamRecorder recorder) { String sDisk = GetDisk(); if(sDisk == null) { WMSLoggerFactory.getLogger(null).error("CustomFileVersionDelegate::getFilename(): No drive chosen"); return null; } String sStreamName = recorder.getStreamName(); int nCameraId = Integer.parseUnsignedInt(ServiceQueries.GetCameraId(sStreamName)); TimeZone tz = TimeZone.getTimeZone("Europe/Moscow"); Calendar now = Calendar.getInstance(tz); String sDirPath = ServerParams.m_sServerContentPath + "/" + sDisk + "/" + Integer.toString(nCameraId / 200) + "/" + sStreamName + "/" + String.format("%1$tY/%1$tm/%1$td", now); String sFullFilePath = sDirPath + "/" + sStreamName + "_" + String.format("%1$tH_%1$tM_%1$tS", now) + ".mp4"; File dirs = new File(sDirPath); dirs.setExecutable(true); dirs.setWritable(true); dirs.mkdirs(); WMSLoggerFactory.getLogger(null).info( "CustomFileVersionDelegate::getFilename(): Filename created: " + sFullFilePath); return sFullFilePath; } } 

Di kelas CustomFileVersionDelegate , fungsi getFilename virtual dari kelas dasar IStreamRecorderFileVersionDelegate kelebihan beban , yang dipanggil oleh server media sebelum aliran mulai menulis ke file. Fungsi membuat folder pada disk dengan path sDirPath dan mengembalikan path lengkap ke file sFullFilePath .

Karena volume data media sangat besar, sistem file menyertakan beberapa disk fisik volume besar (8 - 12 TB) yang dipasang sebagai subdirektori. Disk dengan jumlah ruang kosong terbesar dipilih sebagai disk tujuan selama perekaman. Untuk operasi optimal dari sistem file ketika mengakses file, jalur ke folder target dibentuk sebagai berikut:

 /content/<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/ 

di mana diskId adalah pengidentifikasi disk (folder yang dipasang),
cameraIdDivideBy200 - hasil pembagian integer dari pengidentifikasi kamera sebesar 200,
streamUuid - pengidentifikasi aliran media,
tahun, bulan, hari - tahun, bulan dan hari pencatatan, masing-masing.

Ini menghindari sejumlah besar subfolder dalam satu folder dan, karenanya, penurunan dramatis dalam kinerja seluruh sistem file dengan peningkatan jumlah kamera IP di rumah pintar yang keruh.

Informasi tentang alamat IP server media, jalur ke file dengan data media, waktu mulai dan akhir penulisan ke file disimpan dalam basis data cloud dan kemudian digunakan oleh aplikasi klien untuk menampilkan garis waktu arsip tempat video dapat dipilih dan diputar.

Untuk mendapatkan streaming video, ujung depan aplikasi klien mengakses server media, mengirimkan perintah berikut melalui protokol HTTP. Untuk aliran video "langsung":

 https://<mediaserverIp>:<port>/rtp-live-iot/<streamUuid>/playlist.m3u8 

Untuk aliran video yang diarsipkan:

 https://<mediaserverIp>:<port>/vod/_definst_/mp4:<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/<fileName>/playlist.m3u8?wowzaplaystart=<offsetMs>&wowzaplayduration=<durationMs> 

di mana fileName adalah nama file arsip pada disk,
offsetMs - pemutaran offset relatif terhadap awal file dalam milidetik,
durationMs - durasi pemutaran dalam milidetik.

Server media mengirimkan streaming dalam format HLS , yang memungkinkan Anda untuk menampilkan video H.264 + AAC di semua browser dan perangkat seluler modern dengan sistem operasi iOS dan Android. Packageizer HLS mengkodekan aliran dalam bentuk potongan-potongan terpisah dan mengirimkannya melalui HTTP sebagai tanggapan terhadap permintaan dari aplikasi seluler.

Untuk mengoptimalkan biaya penyimpanan dan akses ke file arsip, server cloud home cloud dikembangkan pada platform perangkat keras Supermicro CSE-825TQ, motherboard X8DT6, motherboard X8DT6, 2xCPU Intel Xeon E5645 2,4 GHz, RAM 32 GB, HDD 44 TB Adaptec AAC-RAID HDD. Server media diinstal sebagai server khusus di situs hosting dan terhubung ke saluran Internet dengan lebar 400 Mbps yang dijamin. Kinerja satu server media cukup untuk memproses stream media dari ~ 400 kamera IP dengan codec H.264, resolusi bingkai 720p dan bitrate 1 Mbps.



Oleh karena itu, untuk dapat memproses stream dari 1000 kamera IP, perlu menginstal 3 server media dan mendistribusikan beban secara merata di antara mereka. Untuk ini, load balancer digunakan, yang terhubung ke server media Wowza Streaming Engine sebagai plugin AddOn Load Balancing AddOn yang terpisah . Ini membedakan, pada kenyataannya, load balancer (atau server asal ), yang secara berkala menerima metrik kinerja dari server media akhir (atau server tepi ) dan, berdasarkan informasi ini, menemukan server yang paling tidak dimuat dalam gugus.

Pengontrol rumah pintar mengakses penyeimbang melalui HTTP dan sebagai tanggapan menerima alamat IP dari server ini, di mana pengontrol mentransmisikan aliran media dari kamera IP melalui RTMP. Metrik kinerja mencakup jumlah koneksi yang dibuat dengan sumber dan konsumen aliran media dan bandwidth saat ini dari saluran Internet di server. Dalam pengaturan penyeimbang, Anda juga dapat menentukan pilihan server tepi, dengan mempertimbangkan posisi geospasialnya, yang memungkinkan Anda untuk meng-host server di berbagai kota dan negara untuk membuat jaringan terdistribusi untuk mengirimkan konten CDN .

Sentuh basis data

Seperti disebutkan sebelumnya dalam artikel sebelumnya, pembacaan sensor Z-Wave, serta status dan kejadian terkini dari kamera IP dikirim dalam format JSON oleh pengontrol rumah pintar ke cloud menggunakan protokol MQTT. Server logika bisnis mendekode pesan-pesan ini dan menjalankan subtugas StoreSensorDataInfluxDB , yang mentransmisikan data ke database sentuh melalui HTTP.


(klik pada gambar untuk membuka dalam resolusi yang lebih tinggi)

Basis data cloud rumah pintar dikembangkan berdasarkan InfluxDB 1.7.x - sistem manajemen basis data sumber terbuka untuk bekerja dengan urutan waktu, yang digunakan di banyak proyek Internet of Things untuk menyimpan data dari sensor dan analitik. Permintaan ke database sentuh dihasilkan dalam bahasa InfluxQL yang mirip dengan SQL tradisional.

Waktu penyimpanan data di cloud smart home ditentukan oleh tarif yang dipilih sesuai dengan model pengguna. Karena perbedaan yang signifikan dalam jumlah data video dan data sensor, waktu penyimpanannya akan berbeda. Ukuran arsip video diukur dalam hari (7, 14, 30 hari dengan kecepatan berbeda), dan ukuran arsip sensor diukur dalam tahun (3, 5, 7 tahun, masing-masing). Oleh karena itu, untuk setiap pengontrol rumah pintar, ketika terdaftar di akun pribadi pengguna, 2 database terpisah dengan kebijakan penyimpanan berbeda dibuat di dalam basis data sentuh:

 CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras" WITH DURATION 720h SHARD DURATION 1h; CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors" WITH DURATION 61320h SHARD DURATION 24h; 

Backend dari aplikasi klien bertanggung jawab untuk membuat, mengedit, dan menghapus basis data di dalam basis data sentuh. Misalnya, jika pengguna cloud rumah pintar mengubah tarif, backend mengirim perintah berikut untuk membuat perubahan pada kebijakan penyimpanan:

 ALTER RETENTION POLICY "autogen" ON "gateway_6774f85a_0a5b_4059_9b68_************_cameras" DURATION 168h SHARD DURATION 1h; 

Saat menghapus pengontrol rumah pintar dari akun pribadi pengguna, backend menghapus database yang sesuai:

 DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras"; DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors"; 

Setelah menerima pesan informasi dari pengontrol rumah pintar, server logika bisnis melakukan permintaan untuk memasukkan data ke dalam database sentuh:

 INSERT device_20873eb0_dd5e_4213_a175_************,class=METER,label=Energy,units=kWh value_float=0.05 1572194550125; 

Contoh tabel dengan data dari sensor Z-Wave untuk satu pengontrol rumah pintar:



Salah satu fitur paling berguna dari cloud house adalah perhitungan statistik berdasarkan data yang diterima. Pengguna perlu mengetahui suhu rata-rata di dalam ruangan atau berapa banyak listrik yang ia habiskan per bulan.

Bahasa InfluxQL memungkinkan Anda untuk melakukan kueri menggunakan fungsi analitik . Misalnya, untuk menghitung suhu rata-rata selama seminggu, Anda harus menjalankan kueri berikut:

 SELECT MEAN("value_float") FROM device_63c660da_f0e8_4eca_8d5f_************ WHERE label = 'Temperature' AND time >= '2019-10-21T00:00:00.000Z' AND time <= '2019-10-27T23:59:59.999Z' GROUP BY time(1d) fill(null); 

Hasil kueri ini ditunjukkan pada tabel:



Artikel berikutnya, yang sepenuhnya dikhususkan untuk aplikasi klien, akan mempertimbangkan secara rinci perhitungan statistik untuk berbagai parameter dan pembangunan tabel dan grafik berdasarkan itu.

Dalam sistem cloud smart home, InfluxDB DBMS digunakan pada mesin virtual Yandex. Cloud dengan parameter berikut: 4 vCPU core dengan pangsa terjamin sebesar 20%, 2 GB RAM, 100 GB HDD. Menurut perhitungan konfigurasi ini, cukup untuk menyimpan data sensor dari 3.000 kamera IP dan 5.000 sensor Z-Wave selama 7 tahun.

Kesimpulan

Artikel tersebut meneliti arsitektur layanan cloud untuk rumah pintar, algoritma server logika bisnis, arsitektur server media untuk merekam, menyimpan, dan memutar aliran media dari kamera IP, serta arsitektur basis data sentuh untuk menyimpan dan menganalisis data dari sensor rumah pintar. Sistem layanan cloud berfungsi baik pada server khusus maupun virtual, untuk stabilitas lebih besar yang terletak di situs hosting yang berbeda. Sistem saat ini sedang menjalani operasi uji coba.

Semakin tua data yang disimpan di cloud, semakin jarang pengguna mengaksesnya. Dalam versi layanan cloud berikutnya, diusulkan untuk menggunakan mekanisme penipisan (atau oversampling) data menggunakan InfluxDB Continuous Queries untuk mengurangi jumlah data yang disimpan menggunakan fungsi agregasi dan, dengan demikian, meningkatkan kapasitas database sentuh.



Juga, dalam versi berikutnya dari layanan cloud, sekelompok server logika bisnis akan diimplementasikan sesuai dengan prinsip sekelompok server media, yang dibahas dalam artikel ini. Gambar tersebut menunjukkan arsitektur cluster seperti itu, di mana beberapa server tepi (masing-masing memiliki broker MQTT terpisah dan perangkat lunak server logika bisnis) mengirim metrik kinerja ke server asal, yang menghitung alamat IP dari server yang paling tidak dimuat. Ini akan memungkinkan Anda untuk skala sistem ke tingkat yang lebih besar dan mengatasi batas 1000 rumah pintar.