Cihaz sözleşmesinin bir kez tanımlandığı bir bina otomasyon platformu

Bağlam

Müşteri KNX tabanlı bina otomasyon donanımı üretiyor. Firma, önce kendi cihazlarını, ardından KNX protokolünü konuşan herhangi bir üçüncü taraf cihazı kontrol edip izleyecek bir yazılım platformuna ihtiyaç duyuyordu.

Kapsam olarak Home Assistant’a benzer, ama KNX cihazlarını kutudan çıktığı gibi desteklemesiyle ayrışıyor: kurulumcudan hiçbir entegrasyon işi beklenmiyor. Ürün tablet öncelikli; mobil ve web sonraki yüzeyler olarak planlandı.

Üç kişilik çekirdek ekip: mimariyi ve uygulamayı sahiplenen iki kıdemli mühendis ve bir tasarımcı. Bu iki koltuktan birini ve genel mimariyi biz üstlendik.

Problem

Böyle bir platformun yapısal bir tuzağı var. Bir cihaz düğümünün tanımına (metadata’sı, bağlantı tutamakları, doğrulama kuralları) üç taraf birden ihtiyaç duyuyor: onu çalıştıran backend motoru, kurulumcunun onu kurguladığı yönetim paneli ve onu gösteren mobil istemci. Üç kez tanımlarsanız üç tanım birbirinden ayrılır. Sonra bir kurulumcu, motorun çalıştırmayı reddettiği bir otomasyon kurgular ve üçünden hangisinin yanlış olduğunu kimse söyleyemez.

İkinci kısıt: kurulumcular programcı değil. Otomasyon mantığının elle kural yazmadan kurgulanabilmesi gerekiyordu.

Yaklaşım

Her yerde aynı biçimde tüketilen tek tipli sözleşme

Platformun paylaşımlı sözleşme kütüphanesini tasarladık: her düğüm bileşenini, metadata şemasını, bağlantı tutamağı modelini ve TypeBox ile çalışma zamanı doğrulamasını tanımlayan, sıkı tipli paylaşılan bir TypeScript kütüphanesi. Backend motoru, yönetim paneli ve mobil istemci tarafından aynı biçimde tüketiliyor; böylece bir düğümün sözleşmesi tüm platformda tam olarak bir kez tanımlanıyor ve ona yapılan bir değişiklik üçüne birden ulaşıyor.

Mantık yürütme motoru

Mantık yürütme motoru platformun çekirdeğidir: bir NATS mesaj veri yolunu Socket.IO istemcilerine bağlayan, cihaz olaylarını birleştirilebilir mantık düğümlerinden oluşan bir grafik üzerinden yönlendiren bir TypeScript/Fastify servisi. Grafikteki düğümler arasında boolean operatörler, gecikme, saat, anahtar, toggle, dimmer, termostat, KNX cihaz düğümleri ve VoIP/SIP düğümleri yer alıyor.

Motor soyut bir düğüm sözleşmesi üzerine kurulu; yani yeni düğüm tipleri motoru değiştirmeden eklenebiliyor. Platform ile ürün arasındaki fark buradadır: motorun termostatın ne olduğunu bilmesi gerekmiyor.

Elle kural yazmak yerine görsel editör

Otomasyon editörünü Next.js yönetim panelinde React Flow üzerine kurduk; kurulumcular kural yazmak yerine mantığı bir düğüm grafiği olarak kurguluyor. Durum yönetimi Redux Toolkit ve redux-saga ile yapılıyor, arayüz ise tam olarak uluslararasılaştırıldı.

Tablet istemcisi

Tablet öncelikli kontrol uygulaması React Native / Expo ile kurulu; aynı tipli sözleşmeleri paylaşıyor ve mantık motoruyla Socket.IO üzerinden gerçek zamanlı konuşuyor; tek kod tabanından Android, iOS ve web’i hedefliyor.

SIP/VoIP interkom

İnterkom alt sistemini kavram kanıtı olarak uçtan uca tasarlayıp kurduk: TypeScript/Node backend’i ve gösterim amaçlı Android ve iOS istemci uygulamaları. Entegrasyon noktaları mantık motorunda SipNode ve VoipNode olarak hâlihazırda mevcut; tam platform entegrasyonu beklemede.

Geliştirme standartları

semantic-release ile ekip için yayınlanan özel paylaşımlı bir ESLint kural paketi yazıldı; buna Jest test takımları, sıkı TypeScript yapılandırması, Prettier, Husky pre-commit hook’ları ve Bitbucket Pipelines CI eklendi.

Sonuç

• Platformdaki her katman, her dil ve her mimari kararda teslim yapıldı: TypeScript mantık motoru ve paylaşımlı kütüphaneler, Next.js yönetim paneli, dotnet core API ve React Native istemci.
• Bir düğümün tanımı tam olarak tek bir yerde yaşıyor. Düğüm tipi eklemek, üç kod tabanında koordine bir düzenleme değil; paylaşımlı sözleşmelerde bir değişiklik ve yeni bir düğüm implementasyonu.
• Kurulumcular otomasyonu görsel olarak kurguluyor; doğrulama, motorun karşısında çalıştırdığı şemanın aynısından türüyor.
• Çalışma, kesintisiz 12 aylık bir inşadan talep bazlı sürekli işe devam etti.