API Automasi vs Babak Aqara: Cara Memodelkan Peraturan dengan Betul

Jawapan ringkas — Pada API automasi dan babak Aqara, babak dan automasi ialah objek berbeza dengan antara muka penciptaan yang berbeza. Babak ialah tindakan yang anda panggil; config.scene.create menerima nama, kedudukan pilihan dan senarai tindakan yang tersusun, setiap satu dengan kelewatan pilihan. Automasi ialah peraturan pencetus/syarat/tindakan yang bertindak sendiri; config.linkage.create menerima syarat, hubungan AND/OR, dan tindakan. Daripada sudut pandangan API, tiada objek yang secara automatik "setempat" atau "awan", tetapi dokumentasi platform memang mengiklankan automasi berbilang peranti setempat untuk kawalan babak yang stabil, dan keupayaan itulah yang patut memikul peraturan kritikal anda.

Jika anda telah membaca gambaran keseluruhan platform pembangun AqaraLink kami, anda tahu modul itu wujud. Catatan ini tentang keputusan pemodelan, iaitu tempat kebanyakan pepijat integrasi berada: pasukan membina babak di tempat mereka memerlukan automasi, atau menjana empat puluh automasi sedangkan empat babak sudah memadai.

Ia bukan objek yang sama, dan perbezaannya bukan kosmetik

Halaman lampiran tentang peraturan konfigurasi pautan mentakrifkan kedua-duanya, dan takrifannya sengaja dibezakan:

• Automasi (Automation): pengguna menyesuaikan syarat dan tindakan. Apabila syarat pencetus dipenuhi, tindakan yang ditetapkan dilaksanakan secara automatik.
• Babak (Scene): pengguna menyesuaikan tindakan yang hendak dilaksanakan. Apabila babak dicetuskan secara manual, tindakan yang ditetapkan dilaksanakan.
• Berbilang syarat (Multiple-conditions): objek ketiga yang membolehkan pengguna menyesuaikan syarat pencetus untuk menyokong pelbagai gabungan AND/OR.

API mencerminkan ini. config.scene.create mempunyai name, positionId pilihan, dan tatasusunan action. config.linkage.create mempunyai name, positionId pilihan, objek conditions dan objek actions. Tiada medan syarat pada penciptaan babak. Perbezaan itu bersifat struktur, bukan konvensyen UI.

Dua akibat terus timbul:

Babak bersifat tersusun dan disengajakan; automasi bersifat berstatus dan bersyarat. Tindakan babak membawa delayTime dengan delayTimeUnit bernilai 1 untuk saat atau 2 untuk minit, dan julat kelewatan 0 hingga 59 saat atau 0 hingga 59 minit. Primitif penjujukan itu milik model babak kerana babak ialah skrip. Automasi memodelkan predikat, jadi syaratnya membawa beginTime dan endTime, iaitu satu tetingkap, bukan selang-seli.

Pelayan anda perlu tahu bezanya, kerana peristiwa memberitahu perbezaannya. Format tolakan mesej mentakrifkan jenis peristiwa yang berbeza: linkage_created dan linkage_deleted untuk automasi, scene_created dan scene_deleted untuk babak, serta event_created / event_deleted untuk berbilang syarat. Jika integrasi anda menggabungkan ketiga-tiganya menjadi "satu peraturan", anda kehilangan keupayaan menjawab soalan pengguna tentang mengapa lampu koridor menyala.

Ketahui apa yang mungkin sebelum membina apa-apa

Kedua-dua panggilan cipta bukan tempat untuk meneka. Dokumentasi mengarahkan kedua-duanya kepada dua antara muka pertanyaan dahulu:

• query.ifttt.trigger: menanyakan konfigurasi syarat automatik yang disokong oleh model objek tertentu, termasuk nama syarat dan parameter. Anda hantar model yang anda minati.
• query.ifttt.action: yang setara untuk sebelah tindakan.

Model objek itu sendiri boleh ditanya dari konsol di bawah halaman Device Resources. Jadi tertib yang betul ialah: baca modelnya, tanya pencetus yang disokongnya, tanya tindakan yang disokongnya, kemudian gubah.

Terdapat juga laluan penciptaan kedua yang wajar diketahui, kerana ia yang membuka atribut yang tidak dilindungi pratetap sistem. Dokumen menerangkan penciptaan pautan sama ada melalui actionDefinition atau triggerDefinition yang ditakrifkan sistem yang ditemui melalui model objek, atau dengan menyesuaikan atribut peranti secara terus. Laluan atribut tersuai menggunakan nilai parameter tetap: triggerDefinitionId bernilai TD.custom_1 dan paramId bernilai PD.custom.trigger, dengan ujian sebenar dibawa sebagai rentetan tatasusunan JSON bagi id sumber, nilai dan pengendali.

Bagi set syarat, medan relation ialah integer: 0 untuk AND, 1 untuk OR, lalai 0. Itu butiran kecil dengan kesan yang besar: automasi yang sepatutnya memerlukan penderia pintu dan tetingkap masa sekali gus akan bertindak pada salah satu jika anda membiarkan nilai lalai di tempat yang salah, dan ia akan lulus setiap ujian yang anda tulis dengan tangan.

Babak atau automasi: peraturan keputusan

Peraturan asasnya: jika manusia akan menekannya, ia babak. Jika penderia atau jam yang menyebabkannya, ia automasi. Kebanyakan integrasi yang buruk menterbalikkan perkara ini dan berakhir dengan automasi yang saling menduplikasi dan babak dengan logik yang disemat dalam urutan tindakannya.

Pelaksanaan setempat, dan apa yang diubahnya pada awan anda

Senarai keupayaan platform sendiri mengiklankan automasi pintar setempat: "menyokong automasi berbilang peranti setempat untuk kawalan babak yang stabil", dengan Mod Keluar dan Mod Di Rumah sebagai contoh. Aqara mengutamakan Zigbee dan hab ialah pengawal setempat; keseluruhan tujuan mesh ialah peraturan dijalankan dalam unit, bukan dalam pusat data di negara lain.

Itu fakta seni bina, bukan hujah jualan, dan ia patut mengubah reka bentuk anda:

• Peraturan kritikal patut berada di tempat peraturan masih boleh berjalan apabila pelayan anda tumbang. Lampu gerakan koridor, penutupan air, pintu dibiarkan terbuka: ini wajar berada di hab walaupun awan anda turut menyimpan salinan.
• Awan anda tidak sepatutnya menjadi satu-satunya laluan kepada tindakan keselamatan. Jika nilai integrasi anda ialah "kami menambah logik pada automasi", anda telah membina sesuatu yang lebih buruk daripada peraturan setempat bagi kelas peranti itu.
• Awan anda masih tempat yang betul untuk apa-apa yang merentas rumah, merentas penyewa atau bersifat sejarah. Analitik penghunian, pelaporan tenaga, perubahan mod seluruh premis: itu tiada setara setempat dan tepat di situlah API berbaloi dengan kosnya.

Perangkapnya ialah menduplikasi peraturan yang sama di kedua-dua tempat. Jika peraturan wujud di hab dan di awan anda, anda akan mendapat tindakan berganda, dan sesi penyahpepijatan untuk mencarinya benar-benar menyakitkan. Pilih satu tempat pelaksanaan bagi setiap peraturan, dan rekodkan yang mana.

Tidak mencipta ledakan automasi

Ini corak kegagalan yang mematikan demo selepas bulan ketiga. Setiap kes tepi menjadi automasi baharu, dan senarai pengguna bertambah daripada lapan item kepada empat ratus, tiada satu pun yang dapat mereka fahami.

Jenis peristiwa menunjukkan skala risikonya: linkage_created, linkage_deleted, scene_created, scene_deleted, event_created, event_deleted semuanya ditolak ke pelayan anda. Jika pengguna mencipta peraturan dalam aplikasi Aqara Home, sistem anda mengetahuinya sama ada ia yang mencipta atau tidak. UI anda akan menjadi cermin kepada ruang yang sedang disunting dari dua arah.

Empat perkara yang mengekalkan bilangan rendah:

Gunakan templat, jangan jana. Sediakan katalog tetap automasi yang munasabah dan biarkan pengguna menghidupkannya, bukannya menggubah peraturan sewenang-wenangnya semasa larian. Katalog boleh disemak; empat ratus peraturan yang dijana pengguna tidak boleh.

Dedahkan syarat, bukan tatabahasa peraturan penuh. Sebelah pencetus ialah tempat letupan kombinatorik berlaku. Jika produk anda menawarkan "apabila gerakan dikesan di koridor" sebagai pilihan pada set kecil peranti, anda telah menghadkannya.

Utamakan babak ditambah pemboleh ubah keadaan berbanding N automasi. "Selamat malam" sebagai babak, ditambah satu automasi yang memerhati keadaan aplikasi anda sendiri, mengalahkan enam automasi berdasarkan enam gabungan peranti.

Selaraskan, jangan longgokkan. Oleh sebab peristiwa cipta dan padam ditolak, anda boleh memegang inventori yang tepat. Jalankan bacaan penuh berkala objek pautan dan babak, dan bandingkan perbezaannya. Peraturan yang wujud di hab tetapi tiada dalam katalog anda ialah peraturan yang dibuat seseorang secara manual: paparkannya, jangan ambil alih secara senyap.

Mod kegagalan yang wajar dijangka

Memadam peranti di bawah peraturan. Syarat dan tindakan kedua-duanya merujuk subjectId dan satu model. Peraturan yang merujuk peranti yang telah dinyahikat ialah peraturan yang tidak akan bertindak, dan dokumen tidak menerangkan keadaan batu nisan (tombstone). Semak peranti yang dirujuk sebelum anda melaksanakan babak.

Ralat penjujukan akibat unit kelewatan. delayTimeUnit bernilai 1 ialah saat, 2 ialah minit. Babak yang dibina dengan unit yang salah tidak menghasilkan ralat, ia cuma mengambil masa jauh lebih lama daripada yang dijangka sesiapa, dan itu dibaca sebagai "automasi rosak".

Nilai lalai kedudukan. Kedua-dua panggilan cipta menganggap positionId kosong sebagai kedudukan lalai. Jika produk anda menyokong berbilang hartanah atau berbilang tingkat, kedudukan yang tidak ditetapkan secara senyap memfailkan peraturan dalam ruang yang salah.

Nilai lalai hubungan syarat. Dibincangkan di atas, dan ia yang pertama patut diletakkan ujian unit.