Qualche tempo fa vi abbiamo presentato . L'articolo attuale è stato originariamente concepito come una dimostrazione del suo firmware e del sistema di gestione. Tuttavia, per spiegare la logica di funzionamento del termostato e ciò che abbiamo implementato, è necessario delineare l'intero concetto nel suo complesso.
Sull'automazione
In linea di massima, l'automazione può essere suddivisa in tre categorie:
Categoria 1 — dispositivi “intelligenti” singoli. Acquistate lampadine, bollitori, ecc. da diversi produttori. Vantaggi: ogni dispositivo amplia le possibilità e aumenta il comfort. Svantaggi: ogni nuovo produttore richiede la propria applicazione. I protocolli dei dispositivi di diversi produttori sono spesso incompatibili tra loro.
Categoria 2 — installazione di un PC single-board o compatibile x86. Questo rimuove i limiti di potenza di calcolo, e su questa macchina è possibile installare MajorDoMo o qualsiasi altra distribuzione server per la gestione della smart home. In questo modo, i dispositivi della maggior parte dei produttori vengono integrati in un'unica informazione. Cioè, si ha il proprio Server per la smart home. Vantaggi: compatibilità sotto un unico centro, il che offre opzioni avanzate di controllo. Svantaggi: in caso di guasto del server, l'intero sistema torna allo stadio 1, cioè diventa disgiunto, o risulta inutile.
Categoria 3 — la soluzione più hardcore. Durante il processo di ristrutturazione, vengono installate tutte le comunicazioni e duplicate tutte le sistemazioni. Vantaggi: tutto è perfezionato e il risultato è una casa davvero intelligente. Svantaggi: costo estremamente elevato rispetto alle categorie 1 e 2, necessità di pianificare tutto in anticipo e di considerare ogni dettaglio.
La maggior parte degli utenti sceglie la prima opzione e poi passa gradualmente alla seconda. In seguito, i più determinati arrivano alla terza opzione.
Tuttavia, esiste un'opzione che può essere chiamata sistema distribuito: ogni singolo dispositivo sarà sia server che cliente. In sostanza, è un tentativo di prendere e unire l'opzione 1 e l'opzione 2. Prendere tutti i loro vantaggi ed escludere gli svantaggi, trovare un giusto equilibrio.
È possibile che qualcuno dica che un'opzione simile è già stata sviluppata. Ma queste soluzioni sono molto specifiche; per persone con competenze di programmazione. Il nostro obiettivo è abbassare la barriera all'ingresso per tali sistemi distribuiti, sia come dispositivi finali che come integrazione di dispositivi esistenti nel nostro sistema. Nel caso del termostato, l'utente semplicemente rimuove il suo vecchio termostato, installa quello smart e collega i sensori che già possiede. Senza ulteriori azioni.
Consideriamo l'integrazione nel nostro sistema con un esempio.
Immaginiamo di avere 8 moduli Sonoff nella nostra rete. Per alcuni utenti, sarà sufficiente il controllo tramite il cloud Sonoff (categoria 1). Alcuni passeranno a utilizzare firmware di terze parti e passeranno gradualmente alla categoria 2. La maggior parte dei firmware di terze parti funziona secondo lo stesso principio: trasferimento dei dati a un server MQTT. OpenHub, Majordomo o qualsiasi altro servono a un'unica scopo: unire dispositivi disparati in un unico spazio informativo, situato o su Internet o in rete locale. Di conseguenza, la presenza di un Server è obbligatoria. Ne deriva il problema principale: in caso di guasto del Server, l'intero sistema smette di funzionare in modo autonomo. Per evitare ciò, i sistemi vengono complicati, aggiungendo metodi di controllo manuale che duplicano l'automazione in caso di guasto del Server.
Noi invece abbiamo seguito un'altra strada, in cui ogni dispositivo è autonomo. In questo modo, il Server non gioca un ruolo fondamentale, ma espande solo le funzionalità.
Torniamo all'esperimento mentale. Prendiamo di nuovo gli stessi 8 moduli Sonoff e installiamo in essi il firmware Lytko. In tutti i firmware Lytko è implementata la funzione . SSDP è un protocollo di rete basato su un insieme di protocolli Internet, utilizzato per l'annuncio e la scoperta di servizi di rete. La risposta a una richiesta può essere sia standard che avanzata. In questa risposta abbiamo incluso, oltre alle funzionalità standard, la creazione di un elenco dei dispositivi presenti in rete. In questo modo, i dispositivi possono trovarsi l'uno con l'altro e ognuno avrà un proprio elenco. Esempio di elenco SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Come si può vedere dall'esempio, l'elenco comprende gli ID dei dispositivi, l'indirizzo IP nella rete e il tipo di modulo (nel nostro caso, un termostato basato su Sonoff). Questo elenco viene aggiornato ogni due minuti (questo intervallo è sufficiente per rispondere ai cambiamenti dinamici nel numero di dispositivi in rete). In questo modo, monitoriamo l'aggiunta, la modifica e la disconnessione dei dispositivi senza alcuna azione da parte dell'utente. Questo elenco viene inviato al browser o all'app mobile, e lo script genera automaticamente una pagina con un numero specifico di moduli. Ogni modulo corrisponde a un dispositivo/sensore/controllore. Visivamente, l'elenco appare così:
Ma se a esp8266/esp32 sono collegati altri sensori radio tramite cc2530 (ZigBee) o nrf24 (MySensors)?
Progetti
Sul mercato sono presenti diversi sistemi distribuiti. Il nostro sistema consente di integrarsi con i più popolari.
Di seguito sono riportati progetti che cercano in vari modi di affrontare la questione della compatibilità tra diversi produttori. Questi includono, ad esempio, , o . è collegato a un server MQTT, quindi non è adatto per l'esempio.
Uno dei modi per implementare MySensors è un gateway basato su ESP8266. Gli altri esempi sono su ESP32. È possibile integrare il nostro principio di rilevamento e creazione di una lista di dispositivi.
Facciamo un altro esperimento mentale. Abbiamo un gateway ZESP32, SLS Gateway o MySensors. Come possiamo unirli in uno spazio informativo unico? Aggiungeremo la libreria del protocollo SSDP alle funzioni standard di questi gateway. Quando si interroga il controller tramite SSDP, esso aggiungerà alla risposta standard un elenco dei dispositivi connessi. Sulla base di queste informazioni, il browser formerà una pagina. In linea generale, apparirà così:
Interfaccia web
Applicazione PWA
"ssdpList":
{
"id": 94967291, // identificatore unico del dispositivo
"ip": "192.168.x.x", // indirizzo ip nella rete
"type": "thermostat" // tipo di dispositivo
},
{
"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"
}
Dall'esempio si può vedere che i dispositivi vengono aggiunti in modo indipendente l'uno dall'altro. Sono collegati 3 termostati con indirizzi IP propri e 5 sensori diversi con ID unici. Se un sensore è connesso a una rete Wi-Fi, avrà il suo IP, se è collegato a un gateway, l'indirizzo IP del dispositivo sarà quello del gateway.
Per comunicare con i dispositivi utilizziamo WebSocket. Questo permette di ridurre al minimo il consumo di risorse rispetto alle richieste get e di ricevere informazioni in modo dinamico alla connessione o alla modifica.
I dati vengono presi direttamente dal dispositivo a cui appartiene il modulo, bypassando il server. In questo modo, in caso di guasto di uno qualsiasi dei dispositivi, il sistema continua a funzionare. Nell'interfaccia web semplicemente non verrà visualizzato il dispositivo mancante dalla lista. Tuttavia, un segnale di perdita, se necessario, verrà inviato sotto forma di notifica all'app dell'utente.
Il primo tentativo di implementazione di questo approccio è stato un'app PWA. Questo consente di memorizzare il database dei blocchi sul dispositivo dell'utente e di richiedere solo i dati necessari. Tuttavia, a causa della struttura, questa opzione risulta incompleta. L'unica soluzione è un'app nativa per Android e iOS, attualmente in fase di sviluppo attivo. Per impostazione predefinita, l'app funzionerà solo all'interno della rete interna. Se necessario, tutto può essere trasferito alla gestione esterna. Così, quando l'utente lascia la rete locale, l'app passa automaticamente al cloud.
La gestione esterna è una duplicazione completa della pagina. Quando la pagina è attivata, l'utente può effettuare il login sul server e gestire i dispositivi tramite il proprio pannello personale. In questo modo, il server espande le funzionalità, permettendo di gestire i dispositivi anche al di fuori della propria casa, senza essere vincolati al port forwarding o a un IP statico.
Pertanto, la soluzione sopra descritta è priva degli svantaggi dell'approccio server e presenta diversi vantaggi in termini di flessibilità nell'aggiungere nuovi dispositivi.
Su un termostato
Esaminiamo il sistema di gestione attraverso il nostro termostato.
Incluso:
- Regolazione della temperatura di ciascun termostato (visualizzata come un blocco separato);
- Impostazione del programma operativo del termostato (mattina, giorno, sera, notte);
- Scelta della rete Wi-Fi e connessione del dispositivo a essa;
- Aggiornamento del dispositivo tramite OTA;
- Impostazione di MQTT;
- Configurazione della rete a cui è connesso il dispositivo.
Oltre alla gestione tramite interfaccia web, abbiamo previsto anche il controllo classico — tramite tocchi sul display. È presente un monitor Nextion NX3224T024 da 2.4 pollici. È stato scelto per la sua facilità d'uso. Tuttavia, stiamo sviluppando un monitor personalizzato basato su STM32. Le sue funzionalità non sono inferiori a quelle del Nextion, ma costerà meno, il che sarà un vantaggio per il prezzo finale del dispositivo.
Come ogni rispettabile schermo di termostato, il nostro Nextion sa:
- impostare la temperatura desiderata dall'utente (con i pulsanti a destra);
- attivare e disattivare la modalità programmata (pulsante N);
- mostrare il funzionamento del relè (freccia a sinistra);
- ha una protezione per bambini (viene bloccato l'ingresso fisico finché il lucchetto non è disattivato);
- visualizza il livello del segnale WiFi.
Inoltre, con il monitor è possibile:
- selezionare il tipo di sensore installato dall'utente;
- gestire la funzione di protezione per i bambini;
- aggiornare il firmware.
Cliccando sulla barra WiFi, l'utente può scoprire informazioni sulla rete connessa. Il codice QR viene utilizzato per associare il dispositivo con il firmware HomeKit.
Demo del funzionamento del display:
Abbiamo sviluppato con tre termostati connessi.
Chiederete: “Qual è la particolarità del vostro termostato?” Attualmente, sul mercato ci sono numerosi termostati con funzionalità Wi-Fi, programmazione e controllo touch. Inoltre, gli appassionati hanno creato moduli per interagire con la maggior parte dei sistemi di domotica più popolari (Majordomo, HomeAssistant, ecc.).
Il nostro termostato è compatibile con i sistemi sopra citati e possiede tutte le funzionalità indicate. La sua caratteristica distintiva è che viene costantemente migliorato grazie alla flessibilità del sistema. Con ogni aggiornamento, le funzionalità si espanderanno. Oltre al metodo standard di gestione del sistema (su base oraria), aggiungeremo anche uno adattivo. L'applicazione permette di ottenere la geolocalizzazione dell'utente. In questo modo, il sistema modificherà dinamicamente le modalità operative in base alla sua posizione. Inoltre, il modulo meteo consentirà di adattarsi alle condizioni atmosferiche.
E la sua espandibilità. Chiunque potrà sostituire il termostato tradizionale con il nostro. Con il minimo sforzo. Abbiamo selezionato 5 dei sensori più popolari disponibili sul mercato e ne abbiamo aggiunto il supporto. Ma anche nel caso di caratteristiche esclusive del sensore, l'utente potrà collegarlo al nostro termostato. Per fare ciò, sarà necessario calibrare il termostato per lavorare con il sensore specifico. Forniremo le istruzioni.
Collegando un termostato o qualsiasi altro dispositivo, esso appare simultaneamente ovunque: sia nell'interfaccia web che nell'app PWA. L'aggiunta del dispositivo avviene automaticamente: basta connetterlo alla rete Wi-Fi.
Il nostro sistema non ha bisogno di un Server, e in caso di guasto non si trasforma in una zucca. Anche se uno dei componenti si guasta, il sistema non entra in modalità di emergenza. Controller, sensori, dispositivi: ogni elemento funge sia da Server che da cliente, rendendolo completamente autonomo.
Per chi è interessato — i nostri social media: , , , , .
Email: shop@lytko.com
P. S. non stiamo chiedendo di rinunciare al Server. Abbiamo anche il supporto per il server MQTT e un nostro cloud. Il nostro obiettivo è portare la stabilità e l'affidabilità del sistema a un livello qualitativamente superiore. Affinché il Server non sia un punto debole, ma integri le funzionalità e renda il sistema più conveniente.
Fonte: habr.com
