Qualchì tempu fà vi avemu presentatu . Stu articulu hè statu urigginariamente pensatu cum'è una dimostrazione di u so firmware è u sistema di cuntrollu. Ma per spiegà a logica di u termostatu è ciò chì avemu implementatu, hè necessariu di spiegà u cuncettu sanu in tuttu.
Circa l'automatizazione
Cunvinziunali, tutta l'automatizazione pò esse divisa in trè categurie:
Categoria 1 - dispusitivi "intelligenti" separati. Cumprate lampadine, teapots, etc. da diversi fabricatori. Pros: Ogni dispusitivu espansione e capacità è aumenta u cunfortu. Cons: Ogni novu fabricatore richiede a so propria applicazione. I protokolli di i dispusitivi di diversi fabricatori sò spessu micca cumpatibili cù l'altri.
Categoria 2 - installazione di un PC unicu-board o x86 compatible. Questu elimina e restrizioni à a putenza di l'informatica, è MajorDoMo o qualsiasi altra distribuzione di u servitore per a gestione di una casa intelligente hè stallata nantu à sta macchina. Cusì, i dispositi di a maiò parte di i fabricatori sò cunnessi in un spaziu di informazioni unicu. Quelli. u vostru propiu Servitore per una casa intelligente appare. Pros: cumpatibilità sottu un centru unicu, chì furnisce capacità di gestione avanzate. Cons: se u servitore falla, tuttu u sistema torna à u stadiu 1, i.e. diventa frammentatu o diventa inutile.
Categoria 3 - l'opzione più hardcore. In u stadiu di riparazione, tutte e cumunicazioni sò disposti è tutti i sistemi sò duplicati. Pro: tuttu hè purtatu à a perfezione è allora a casa diventa veramente intelligente. Disadvantages: estremamente caru cumparatu cù e categurie 1 è 2, a necessità di pensà à tuttu in anticipu è piglià in contu ogni pocu dettagliu.
A maiò parte di l'utilizatori sceglienu l'opzione unu è poi passanu senza intoppi à l'opzione duie. E poi i più persistenti arrivanu à l'opzione 3.
Ma ci hè una opzione chì pò esse chjamata un sistema distribuitu: ogni dispusitivu individuale serà un servitore è un cliente. Essenzialmente, questu hè un tentativu di piglià è cumminà l'opzione 1 è l'opzione 2. Pigliate tutti i so prufessiunali è eliminà i contra, per catturà u mediu d'oru.
Forsi qualchissia dicerà chì una tale opzione hè digià sviluppata. Ma tali decisioni sò strettamente focalizati; per e persone esperte in a prugrammazione. U nostru scopu hè di calà a barriera à l'entrata in tali sistemi distribuiti, sia in forma di dispositivi finali sia in forma di integrazione di i dispositi esistenti in u nostru sistema. In u casu di un termostatu, l'utilizatore simpricamente sguassate u so vechju termostatu, installà un intelligente, è cunnetta i so sensori esistenti à questu. Senza alcunu passu supplementu.
Fighjemu l'integrazione in u nostru sistema cù un esempiu.
Imaginemu chì avemu 8 moduli Sonoff in a nostra reta. Per certi utilizatori, u cuntrollu via u nuvulu Sonoff (categoria 1) serà abbastanza. Qualchidunu accuminciaranu à aduprà u firmware di terzu partitu è si move in a categuria 2. A maiò parte di u firmware di terzu partitu travaglia nantu à u listessu principiu: trasferimentu di dati à un servitore MQTT. OpenHub, Majordomo o qualsiasi altru serve un scopu - unisce i dispositi disparati in un unicu spaziu d'infurmazione situatu sia in Internet sia in una reta lucale. Dunque, a prisenza di un Servitore hè ubligatoriu. Questu hè quì chì u prublema principali si trova - se u Servitore falla, u sistema tutale ferma di travaglià in modu autonomu. Per impediscenu questu, i sistemi diventanu più cumplessi, i metudi di cuntrollu manuale sò aghjuntu chì l'automatizazione duplicate in casu di fallimentu di u Server.
Avemu pigliatu un percorsu sfarente, induve ogni dispusitivu hè autosufficiente. Cusì, u Servitore ùn ghjucà micca un rolu decisivu, ma solu espansione a funziunalità.
Riturnemu à l'esperimentu di pensamentu. Pigliemu dinò i stessi moduli 8 Sonoff è stallà u firmware Lytko in elli. Tutti i firmware di Lytko anu a funzione . SSDP hè un protokollu di rete basatu nantu à a suite di protokolli Internet per publicità è scuperta di servizii di rete. A risposta à una dumanda pò esse standard o allargata. In più di e funzioni standard, avemu inclusu in questa risposta a creazione di una lista di i dispositi in a reta. Cusì, i dispusitivi stessi si trovanu l'altri, è ognuna di elli avarà una tale lista. Esempiu di fogliu SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Comu pudete vede da l'esempiu, a lista include l'ID di u dispositivu, l'indirizzu IP nantu à a reta, u tipu di unità (in u nostru casu, un termostat basatu in Sonoff). Questa lista hè aghjurnata una volta ogni dui minuti (stu periodu hè abbastanza per risponde à i cambiamenti dinamichi in u numeru di dispusitivi in a reta). In questu modu, tracciamu i dispositi aghjuntu, cambiati è disattivati senza alcuna azzione d'utilizatore. Questa lista hè mandata à u navigatore o l'applicazione mobile, è u script stessu genera una pagina cù un certu numaru di blocchi. Ogni bloccu currisponde à un dispositivu / sensore / controller. Visualmente a lista s'assumiglia cusì:
Ma chì se altri sensori radio sò cunnessi à l'esp8266 / esp32 via cc2530 (ZigBee) o nrf24 (MySensors)?
Circa i prughjetti
Ci sò diversi sistemi distribuiti in u mercatu. U nostru sistema vi permette di integrà cù i più populari.
Quì sottu sò prughjetti chì sò un modu o un altru chì prova di cambià a situazione cù l'incompatibilità di diversi fabricatori cù l'altri. Questu hè, per esempiu, , o . hè ligatu à un servitore MQTT, cusì ùn hè micca adattatu per l'esempiu.
Una opzione per implementà MySensors hè un gateway basatu annantu à l'ESP8266. U restu di l'esempii sò nantu à ESP32. È in elli pudete implementà u nostru principiu di funziunamentu di detectà è creà una lista di i dispusitivi.
Facemu un altru esperimentu di pensamentu. Avemu un gateway ZESP32 o SLS Gateway, o MySensors. Cumu ponu esse cumminati in un unicu spaziu d'infurmazione? Avemu da aghjunghje a libreria di protokollu SSDP à e funzioni standard di sti gateway. Quandu accede à stu controller via SSDP, aghjunghje una lista di i dispositi chì sò cunnessi à questu à a risposta standard. Basatu nantu à sta infurmazione, u navigatore generà una pagina. In generale, sarà cusì:
Interfaccia Web
L'applicazione PWA
"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"
}
L'esempiu mostra chì i dispositi sò aghjuntu indipindentamente l'un l'altru. 3 termostati cù i so indirizzi IP è 5 sensori diffirenti cù ID unichi sò cunnessi. Se u sensoru hè cunnessu à una rete Wi-Fi, avarà u so propiu IP; se hè cunnessu à una porta, l'indirizzu IP di u dispusitivu serà l'indirizzu IP di a porta.
Avemu aduprà WebSocket per cumunicà cù i dispositi. Questu permette di minimizzà i costi di risorsa cumparatu per uttene richieste è uttene infurmazione dinamicamente quandu si cunnetta o cambia.
I dati sò pigliati direttamente da u dispusitivu à quale appartene u bloccu, bypassing u servitore. Cusì, se qualcunu di i dispusitivi falla, u sistema cuntinueghja à funziunà. L'interfaccia web solu ùn mostra micca u dispusitivu chì manca da a lista. Ma un signalu nantu à a perdita, se ne necessariu, vene in a forma di una notificazione in l'applicazione di l'utilizatori.
U primu tentativu di implementà stu approcciu era una applicazione PWA. Questu permette di almacenà una basa di bloccu nantu à u dispusitivu di l'utilizatore è dumandà solu i dati necessarii. Ma per via di e peculiarità di a struttura, sta opzione hè incompleta. È ci hè solu una manera - una applicazione nativa per Android è iOS, chì hè attualmente in sviluppu attivu. Per automaticamente, l'applicazione funziona solu nantu à a reta interna. Sè necessariu, pudete trasfiriri tuttu à u cuntrollu esternu. Allora, quandu l'utilizatore abbanduneghja a reta lucale, l'applicazione cambia automaticamente à u nuvulu.
Cuntrolla esterna - duplicazione cumpleta di a pagina. Quandu a pagina hè attivata, l'utilizatore pò accede à u servitore è gestisce i dispositi attraversu u so contu persunale. Cusì, u Servitore espansione a so funziunalità, chì vi permette di gestisce i dispositi mentre fora di a casa, è micca esse ligatu à u portu forwarding o una IP dedicata.
Cusì, l'opzione sopra ùn hà micca i disadvantages di l'approcciu di u servitore, è hà ancu una quantità di vantaghji in a forma di flessibilità in a cunnessione di novi dispositi.
À propositu di u termostatu
Fighjemu u sistema di cuntrollu cù u nostru termostatu cum'è un esempiu.
Fornitu:
- Controlu di temperatura per ogni termostatu (mostratu cum'è un bloccu separatu);
- Stabbilimentu di u prugramma di funziunamentu di u termostatu (mattina, dopu meziornu, sera, notte);
- Selezziunate una reta Wi-Fi è cunnette un dispositivu à questu;
- Aghjurnà u dispusitivu "over the air";
- Configurazione di MQTT;
- Configurate a reta à quale u dispusitivu hè cunnessu.
In più di u cuntrollu via l'interfaccia web, avemu furnitu u classicu - clicchendu nantu à a visualizazione. Ci hè un monitor Nextion NX3224T024 2.4-inch à bordu. A scelta hè cascata nantu à ellu per via di a facilità di travaglià cù u dispusitivu. Ma sviluppemu u nostru propiu monitor basatu annantu à STM32. A so funziunalità ùn hè micca peghju chè quella di Nextion, ma costarà menu, chì avarà un impattu pusitivu nantu à u prezzu finali di u dispusitivu.
Cum'è qualsiasi schermu termostatu chì si rispettu, u nostru Nextion pò:
- stabilisce a temperatura richiesta da l'utilizatore (usendu i buttoni à a diritta);
- accende è spegne u modu di funziunamentu pianificatu (buttone H);
- funziunamentu di u relé di visualizazione (freccia à manca);
- hà prutezzione di i zitelli (i clicchi fisichi sò bluccati finu à chì a serratura hè eliminata);
- mostra a forza di u segnale WiFi.
Inoltre, cù u monitoru pudete:
- selezziunà u tipu di sensor installatu da l'utilizatori;
- gestisce a funzione di serratura di u zitellu;
- aghjurnà u firmware.
Cliccà nant'à a barra WiFi, l'utilizatore hà da truvà infurmazioni nantu à a reta cunnessa. U codice QR hè utilizatu per accoppià u dispusitivu in u firmware HomeKit.
Demo di travaglià cù u display:
Avemu sviluppatu cù trè termostati cunnessi.
Puderete dumandà: "Chì hè speciale di u vostru termostatu?" Avà nantu à u mercatu ci sò assai termostati cù funzione Wi-Fi, operazione pianificata è cuntrollu di u toccu. È i dilettanti anu scrittu moduli per interagisce cù i sistemi di casa intelligente più populari (Majordomo, HomeAssistant, etc.).
U nostru termostatu hè cumpatibile cù tali sistemi è hà tutte e sopra. Ma a caratteristica distintiva hè chì u termostatu hè constantemente migliuratu, grazia à a flessibilità di u sistema. Cù ogni aghjurnamentu, a funziunalità si espansione. À u metudu standard di gestione di u sistema (sicondu un calendariu), aghjunghjemu un adattativu. L'applicazione permette di ottene a geolocalizzazione di l'utilizatore. Grazie à questu, u sistema cambierà dinamicamente i modi operativi secondu u so locu. È u modulu climaticu vi permetterà di adattà à e cundizioni climatichi.
È l'espansione. Qualchissia pò rimpiazzà u so termostatu cunvinziunali esistenti cù u nostru. Cù u minimu sforzu. Avemu sceltu 5 di i sensori più populari nantu à u mercatu è aghjustatu supportu per elli. Ma ancu s'è u sensoru hà caratteristiche esclusive, l'utilizatore puderà cunnette cù u nostru termostatu. Per fà questu, avete bisognu di calibre u termostatu per travaglià cù un sensoru specificu. Avemu da furnisce struzzioni.
Quandu cunnessu un termostatu o qualsiasi altru dispositivu, appare simultaneamente in ogni locu: sia in l'interfaccia web sia in l'applicazione PWA. Agghiuncennu un dispusitivu hè automaticamente: vi basta à cunnette si à a reta Wi-Fi.
U nostru sistema ùn hà micca bisognu di un Servitore, è s'ellu falla, ùn si trasforma micca in una zucca. Ancu s'ellu unu di i cumpunenti falla, u sistema ùn principia micca à operare in un scenariu d'emergenza. Controllers, sensors, devices - ogni elementu hè à tempu un Servitore è un cliente, dunque completamente autònuma.
Per quelli interessati, e nostre rete suciale: , , , , .
Mail: [email prutettu]
PS Ùn vi incuragiscemu micca à abbandunà u Servitore. Supportemu ancu un servitore MQTT è avemu a nostra propria nuvola. U nostru scopu hè di portà a stabilità è l'affidabilità di u sistema à un livellu sanu novu. Cusì chì u Servitore ùn hè micca un puntu debule, ma cumplementa a funziunalità è rende u sistema più còmuda.
Source: www.habr.com