Bir süre önce sizi tanıştırmıştık . Bu makale başlangıçta ürün yazılımının ve kontrol sisteminin bir gösterimi olarak tasarlandı. Ama termostatın mantığını ve uyguladığımızı anlatabilmek için konseptin tamamını bir bütün olarak özetlemek gerekiyor.
Otomasyon hakkında
Geleneksel olarak tüm otomasyon üç kategoriye ayrılabilir:
Kategoriler 1 — ayrı “akıllı” cihazlar. Farklı üreticilerden ampul, çaydanlık vb. satın alıyorsunuz. Artıları: Her cihaz yetenekleri genişletir ve konforu artırır. Eksileri: Her yeni üretici kendi uygulamasını gerektirir. Farklı üreticilerin cihazlarının protokolleri çoğu zaman birbiriyle uyumlu değildir.
Kategoriler 2 — tek kartlı veya x86 uyumlu bir bilgisayarın kurulumu. Bu, bilgi işlem gücü üzerindeki kısıtlamaları ortadan kaldırır ve MajorDoMo veya akıllı bir evi yönetmek için başka herhangi bir sunucu dağıtımı bu makineye kurulur. Böylece çoğu üreticinin cihazları tek bir bilgi alanına bağlanır. Onlar. akıllı ev için kendi Sunucunuz görünür. Artıları: Gelişmiş yönetim yetenekleri sağlayan tek bir merkez altında uyumluluk. Eksileri: Sunucu arızalanırsa tüm sistem 1. aşamaya döner, yani. parçalanır veya işe yaramaz hale gelir.
Kategoriler 3 - en zorlu seçenek. Onarım aşamasında tüm iletişim kurulur ve tüm sistemler kopyalanır. Artıları: Her şey mükemmel hale getirildikten sonra ev gerçekten akıllı hale geliyor. Dezavantajları: Kategori 1 ve 2'ye kıyasla son derece pahalıdır, her şeyi önceden düşünme ve her küçük ayrıntıyı dikkate alma ihtiyacı.
Çoğu kullanıcı birinci seçeneği seçer ve ardından sorunsuz bir şekilde ikinci seçeneğe geçer. Ve sonra en ısrarcı olanlar 3. seçeneğe ulaşır.
Ancak dağıtılmış sistem olarak adlandırılabilecek bir seçenek var: her bir cihaz hem sunucu hem de istemci olacaktır. Temelde bu, seçenek 1 ile seçenek 2'yi alıp birleştirme girişimidir. Altın ortalamayı yakalamak için tüm artılarını alın ve eksilerini ortadan kaldırın.
Belki birileri böyle bir seçeneğin zaten geliştirildiğini söyleyecektir. Ancak bu tür kararlar dar bir alana odaklanmıştır; programlama konusunda bilgili insanlar için. Amacımız hem uç cihazlar hem de mevcut cihazların sistemimize entegre edilmesi yoluyla bu tür dağıtık sistemlere giriş engelini azaltmaktır. Termostat durumunda, kullanıcının eski termostatını çıkarması, akıllı olanı takması ve mevcut sensörlerini ona bağlaması yeterlidir. Herhangi bir ek adım olmadan.
Bir örnek kullanarak sistemimize entegrasyona bakalım.
Ağımızda 8 adet Sonoff modülümüz olduğunu düşünelim. Bazı kullanıcılar için Sonoff bulutu (kategori 1) üzerinden kontrol yeterli olacaktır. Bazıları üçüncü taraf ürün yazılımını kullanmaya başlayacak ve sorunsuz bir şekilde kategori 2'ye geçecektir. Üçüncü taraf ürün yazılımının büyük bir kısmı aynı prensipte çalışır: verileri bir MQTT sunucusuna aktarmak. OpenHub, Majordomo veya diğerleri tek bir amaca hizmet eder: farklı cihazları İnternet'te veya yerel ağda bulunan tek bir bilgi alanında birleştirmek. Bu nedenle bir Sunucunun varlığı zorunludur. Asıl sorun burada ortaya çıkıyor; Sunucu arızalanırsa tüm sistem bağımsız olarak çalışmayı durdurur. Bunu önlemek için sistemler daha karmaşık hale gelir, Sunucu arızası durumunda otomasyonu çoğaltan manuel kontrol yöntemleri eklenir.
Her cihazın kendi kendine yettiği farklı bir yol izledik. Böylece Sunucu belirleyici bir rol oynamaz, yalnızca işlevselliği genişletir.
Düşünce deneyine dönelim. Aynı 8 Sonoff modülünü tekrar alalım ve bunlara Lytko ürün yazılımını yükleyelim. Tüm Lytko yazılımları bu fonksiyona sahiptir . SSDP, ağ hizmetlerinin reklamı ve keşfi için İnternet protokol paketini temel alan bir ağ protokolüdür. Bir talebe verilen yanıt standart veya genişletilmiş olabilir. Standart işlevlere ek olarak, bu cevaba ağdaki cihazların bir listesinin oluşturulmasını da dahil ettik. Böylece cihazların kendisi birbirini bulur ve her birinin böyle bir listesi olacaktır. Örnek SSDP sayfası:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Örnekte görebileceğiniz gibi listede cihaz kimlikleri, ağdaki IP adresi, ünite türü (bizim durumumuzda Sonoff tabanlı bir termostat) yer almaktadır. Bu liste her iki dakikada bir güncellenir (bu süre, ağdaki cihaz sayısındaki dinamik değişikliklere yanıt vermek için yeterlidir). Bu şekilde eklenen, değiştirilen ve devre dışı bırakılan cihazları herhangi bir kullanıcı işlemine gerek kalmadan takip ediyoruz. Bu liste tarayıcıya veya mobil uygulamaya gönderilir ve betiğin kendisi belirli sayıda bloktan oluşan bir sayfa oluşturur. Her blok bir cihaza/sensöre/kontrolöre karşılık gelir. Liste görsel olarak şöyle görünür:
Peki ya esp8266/esp32'ye cc2530 (ZigBee) veya nrf24 (MySensors) aracılığıyla başka radyo sensörleri bağlanırsa?
Projeler hakkında
Piyasada çeşitli dağıtılmış sistemler bulunmaktadır. Sistemimiz en popüler olanlarla entegre olmanıza olanak sağlar.
Aşağıda, farklı üreticilerin birbirleriyle uyumsuzluğu ile durumu bir şekilde değiştirmeye çalışan projeler bulunmaktadır. Bu, örneğin, , veya . bir MQTT sunucusuna bağlı olduğundan örnek için uygun değildir.
MySensors'ı uygulamaya yönelik seçeneklerden biri ESP8266'yı temel alan bir ağ geçididir. Örneklerin geri kalanı ESP32'dedir. Ve bunların içinde, cihazların bir listesini tespit etme ve oluşturma çalışma prensibimizi uygulayabilirsiniz.
Başka bir düşünce deneyi yapalım. Bir ZESP32 ağ geçidimiz veya SLS Ağ Geçidimiz veya MySensors'ımız var. Tek bir bilgi alanında nasıl birleştirilebilirler? Bu ağ geçitlerinin standart işlevlerine SSDP protokol kütüphanesini ekleyeceğiz. Bu denetleyiciye SSDP aracılığıyla erişildiğinde, kendisine bağlı cihazların bir listesi standart yanıta eklenecektir. Bu bilgilere dayanarak tarayıcı bir sayfa oluşturacaktır. Genel olarak şöyle görünecek:
Web arayüzü
PWA uygulaması
"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"
}
Örnek, cihazların birbirinden bağımsız olarak eklendiğini göstermektedir. Kendi IP adreslerine sahip 3 termostat ve benzersiz ID'lere sahip 5 farklı sensör bağlanır. Sensör bir Wi-Fi ağına bağlıysa kendi IP'sine sahip olacaktır; bir ağ geçidine bağlıysa cihazın IP adresi, ağ geçidinin IP adresi olacaktır.
Cihazlarla iletişim kurmak için WebSocket kullanıyoruz. Bu, istek almayla karşılaştırıldığında kaynak maliyetlerini en aza indirmenize ve bağlanırken veya değişiklik yaparken dinamik olarak bilgi almanıza olanak tanır.
Veriler, sunucuyu atlayarak doğrudan bloğun ait olduğu cihazdan alınır. Böylece cihazlardan herhangi birinin arızalanması durumunda sistem çalışmaya devam eder. Web arayüzü eksik cihazı listeden görüntülemiyor. Ancak gerekirse kayıpla ilgili bir sinyal, kullanıcının uygulamasında bir bildirim şeklinde gelecektir.
Bu yaklaşımı uygulamaya yönelik ilk girişim bir PWA uygulamasıydı. Bu, kullanıcının cihazında bir blok tabanı saklamanıza ve yalnızca gerekli verileri talep etmenize olanak tanır. Ancak yapının özellikleri nedeniyle bu seçenek eksiktir. Ve tek bir çıkış yolu var - şu anda aktif olarak geliştirilmekte olan Android ve IOS için yerel bir uygulama. Varsayılan olarak uygulama yalnızca dahili ağda çalışacaktır. Gerekirse her şeyi harici kontrole aktarabilirsiniz. Yani kullanıcı yerel ağdan çıktığında uygulama otomatik olarak buluta geçiş yapıyor.
Harici kontrol - sayfanın tamamen çoğaltılması. Sayfa etkinleştirildiğinde kullanıcı sunucuya giriş yapabilir ve kişisel hesabı üzerinden cihazları yönetebilir. Böylece, Sunucu işlevselliğini genişleterek, cihazları ev dışındayken ve bağlantı noktası yönlendirmeye veya özel bir IP'ye bağlı kalmadan yönetmenize olanak tanır.
Dolayısıyla yukarıdaki seçenek, sunucu yaklaşımının dezavantajlarına sahip olmadığı gibi, yeni cihazların bağlanmasında esneklik şeklinde bir takım avantajlara da sahiptir.
Termostat hakkında
Örnek olarak termostatımızı kullanarak kontrol sistemine bakalım.
Tedarik edilen:
- Her termostat için sıcaklık kontrolü (ayrı bir blok olarak görüntülenir);
- Termostat çalışma programının ayarlanması (sabah, öğleden sonra, akşam, gece);
- Bir Wi-Fi ağı seçmek ve ona bir cihaz bağlamak;
- Cihazın "kablosuz" güncellenmesi;
- MQTT'nin kurulması;
- Cihazın bağlı olduğu ağı yapılandırın.
Web arayüzü üzerinden kontrole ek olarak, ekrana tıklayarak klasik olanı da sağladık. Gemide Nextion NX3224T024 2.4 inç monitör bulunmaktadır. Cihazla çalışmanın kolaylığı nedeniyle seçim ona düştü. Ama biz STM32 tabanlı kendi monitörümüzü geliştiriyoruz. İşlevselliği Nextion'unkinden daha kötü değil, ancak daha az maliyetli olacak ve bu da cihazın nihai fiyatı üzerinde olumlu bir etkiye sahip olacak.
Kendine saygılı herhangi bir termostat ekranı gibi Nextion'umuz da şunları yapabilir:
- kullanıcının ihtiyaç duyduğu sıcaklığı ayarlayın (sağdaki düğmeleri kullanarak);
- programlanmış çalışma modunu açın ve kapatın (H düğmesi);
- röle çalışmasının görüntülenmesi (soldaki ok);
- çocuk koruması vardır (kilit kaldırılana kadar fiziksel tıklamalar engellenir);
- WiFi sinyal gücünü görüntüler.
Ayrıca monitörü kullanarak şunları yapabilirsiniz:
- kullanıcı tarafından kurulan sensör tipini seçin;
- çocuk kilidi özelliğini yönetin;
- Firmware'i güncelleyin.
Kullanıcı WiFi çubuğuna tıklayarak bağlı ağ hakkında bilgi bulacaktır. QR kodu, cihazı HomeKit ürün yazılımında eşleştirmek için kullanılır.
Ekranla çalışmanın demosu:
Geliştirdik üç bağlı termostat ile.
"Termostatınızın özelliği nedir?" diye sorabilirsiniz. Artık piyasada Wi-Fi işlevine, programlı çalışmaya ve dokunmatik kontrole sahip birçok termostat var. Ve meraklılar, en popüler akıllı ev sistemleriyle (Majordomo, HomeAssistant, vb.) etkileşim kurmak için modüller yazdılar.
Termostatımız bu tür sistemlere uyumlu olup yukarıdaki özelliklerin hepsine sahiptir. Ancak ayırt edici özelliği, sistemin esnekliği sayesinde termostatın sürekli olarak iyileştirilmesidir. Her güncellemeyle işlevsellik genişleyecektir. Standart sistem yönetimi yöntemine (bir programa göre), uyarlanabilir bir yöntem ekleyeceğiz. Uygulama kullanıcının coğrafi konumunu elde etmenizi sağlar. Bu sayede sistem, konumuna bağlı olarak çalışma modlarını dinamik olarak değiştirecektir. Ve hava durumu modülü, hava koşullarına uyum sağlamanıza olanak tanır.
Ve genişletilebilirlik. Herkes mevcut geleneksel termostatını bizimkiyle değiştirebilir. Minimum çabayla. Piyasadaki en popüler 5 sensörü seçtik ve bunlara destek ekledik. Ancak sensör özel özelliklere sahip olsa bile kullanıcı onu termostatımıza bağlayabilecektir. Bunu yapmak için termostatı belirli bir sensörle çalışacak şekilde kalibre etmeniz gerekecektir. Talimatlar vereceğiz.
Bir termostatı veya başka bir cihazı bağladığınızda, aynı anda her yerde görünür: hem web arayüzünde hem de PWA uygulamasında. Bir cihazın eklenmesi otomatik olarak gerçekleşir: cihazı Wi-Fi ağına bağlamanız yeterlidir.
Sistemimizin Server'a ihtiyacı yoktur ve arızalanırsa balkabağına dönüşmez. Acil durumlarda bileşenlerden herhangi biri arızalansa dahi sistem çalışmaya başlamaz. Denetleyiciler, sensörler, cihazlar; her öğe hem Sunucu hem de istemcidir, dolayısıyla tamamen özerktir.
İlgilenenler için sosyal ağlarımız: , , , , .
E-posta: [e-posta korumalı]
PS Sunucuyu terk etmenizi önermiyoruz. Ayrıca bir MQTT sunucusunu da destekliyoruz ve kendi bulutumuz var. Amacımız sistemin istikrarını ve güvenilirliğini tamamen yeni bir seviyeye taşımaktır. Böylece Sunucu zayıf bir nokta olmayıp işlevselliği tamamlar ve sistemi daha kullanışlı hale getirir.
Kaynak: habr.com