Qualche tempo fa vi abbiamo presentato . Questo articolo era originariamente inteso come dimostrazione del firmware e del sistema di controllo. Ma per spiegare la logica del termostato e ciò che abbiamo implementato, è necessario delineare l'intero concetto nel suo complesso.
A proposito di automazione
Convenzionalmente, tutta l'automazione può essere divisa in tre categorie:
Categoria 1 — dispositivi “intelligenti” separati. Acquisti lampadine, teiere, ecc. da diversi produttori. Pro: Ogni dispositivo espande le capacità e aumenta il comfort. Contro: ogni nuovo produttore richiede la propria applicazione. I protocolli di dispositivi di diversi produttori spesso non sono compatibili tra loro.
Categoria 2 — installazione di un PC single-board o compatibile x86. Ciò rimuove le restrizioni sulla potenza di calcolo e su questa macchina è installato MajorDoMo o qualsiasi altra distribuzione server per la gestione di una casa intelligente. Pertanto, i dispositivi della maggior parte dei produttori sono collegati in un unico spazio informativo. Quelli. appare il tuo Server per una casa intelligente. Pro: compatibilità sotto un unico centro, che offre funzionalità di gestione avanzate. Contro: se il server fallisce, l'intero sistema ritorna allo stadio 1, cioè diventa frammentato o diventa inutile.
Categoria 3 - l'opzione più hardcore. Nella fase di riparazione, tutte le comunicazioni vengono stabilite e tutti i sistemi vengono duplicati. Pro: tutto è portato alla perfezione e poi la casa diventa davvero smart. Svantaggi: estremamente costoso rispetto alle categorie 1 e 2, la necessità di pensare a tutto in anticipo e di tenere conto di ogni piccolo dettaglio.
La maggior parte degli utenti sceglie l'opzione uno e poi passa senza problemi all'opzione due. E poi quelli più persistenti raggiungono l’opzione 3.
Ma esiste un'opzione che può essere definita sistema distribuito: ogni singolo dispositivo sarà sia server che client. Essenzialmente, questo è un tentativo di prendere e combinare l’opzione 1 e l’opzione 2. Prendere tutti i pro ed eliminare i contro, per raggiungere la media aurea.
Forse qualcuno dirà che tale opzione è già stata sviluppata. Ma tali decisioni sono mirate in modo ristretto; per persone esperte di programmazione. Il nostro obiettivo è abbassare le barriere all’ingresso in tali sistemi distribuiti, sia sotto forma di dispositivi finali che sotto forma di integrazione di dispositivi esistenti nel nostro sistema. Nel caso di un termostato, l'utente rimuove semplicemente il suo vecchio termostato, ne installa uno intelligente e vi collega i sensori esistenti. Senza ulteriori passaggi.
Diamo un'occhiata all'integrazione nel nostro sistema utilizzando un esempio.
Immaginiamo di avere 8 moduli Sonoff sulla nostra rete. Per alcuni utenti sarà sufficiente il controllo tramite il cloud Sonoff (categoria 1). Alcuni inizieranno a utilizzare firmware di terze parti e passeranno senza problemi alla categoria 2. La maggior parte dei firmware di terze parti funziona secondo lo stesso principio: trasferimento di dati a un server MQTT. OpenHub, Majordomo o qualsiasi altro hanno uno scopo: unire dispositivi disparati in un unico spazio informativo situato su Internet o su una rete locale. Pertanto è obbligatoria la presenza di un Server. È qui che sorge il problema principale: se il Server si guasta, l'intero sistema smette di funzionare in modo autonomo. Per evitare ciò, i sistemi diventano più complessi, vengono aggiunti metodi di controllo manuale che duplicano l'automazione in caso di guasto del Server.
Abbiamo intrapreso una strada diversa, dove ogni dispositivo è autosufficiente. Il Server non gioca quindi un ruolo decisivo, ma espande solo le funzionalità.
Torniamo all'esperimento mentale. Prendiamo di nuovo gli stessi 8 moduli Sonoff e installiamo al loro interno il firmware Lytko. Tutti i firmware Lytko hanno la funzione . SSDP è un protocollo di rete basato sulla suite di protocolli Internet per la pubblicità e il rilevamento dei servizi di rete. La risposta ad una richiesta può essere standard o estesa. Oltre alle funzioni standard, abbiamo incluso in questa risposta la creazione di un elenco di dispositivi presenti in rete. Pertanto, i dispositivi stessi si trovano l'un l'altro e ciascuno di essi avrà un elenco del genere. Esempio di foglio SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Come puoi vedere dall'esempio, l'elenco include ID dispositivo, indirizzo IP sulla rete, tipo di unità (nel nostro caso, un termostato basato su Sonoff). Questo elenco viene aggiornato una volta ogni due minuti (questo periodo è sufficiente per rispondere ai cambiamenti dinamici nel numero di dispositivi sulla rete). In questo modo, teniamo traccia dei dispositivi aggiunti, modificati e disabilitati senza alcuna azione da parte dell'utente. Questo elenco viene inviato al browser o all'applicazione mobile e lo script stesso genera una pagina con un determinato numero di blocchi. Ogni blocco corrisponde ad un dispositivo/sensore/controllore. Visivamente l'elenco appare così:
Ma cosa succede se altri sensori radio sono collegati all'esp8266/esp32 tramite cc2530 (ZigBee) o nrf24 (MySensors)?
A proposito di progetti
Esistono diversi sistemi distribuiti sul mercato. Il nostro sistema ti consente di integrarti con quelli più popolari.
Di seguito sono riportati i progetti che in un modo o nell'altro cercano di cambiare la situazione con l'incompatibilità di diversi produttori tra loro. Questo è, ad esempio, , o . è legato a un server MQTT, quindi non è adatto per l'esempio.
Un'opzione per implementare MySensors è un gateway basato su ESP8266. Il resto degli esempi sono su ESP32. E in essi puoi implementare il nostro principio operativo di rilevamento e creazione di un elenco di dispositivi.
Facciamo un altro esperimento mentale. Abbiamo un gateway ZESP32 o SLS Gateway o MySensors. Come possono essere combinati in un unico spazio informativo? Aggiungeremo la libreria di protocolli SSDP alle funzioni standard di questi gateway. Quando si accede a questo controller tramite SSDP, verrà aggiunto alla risposta standard un elenco di dispositivi ad esso collegati. Sulla base di queste informazioni, il browser genererà una pagina. In generale sarà simile a questo:
interfaccia web
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'esempio mostra che i dispositivi vengono aggiunti indipendentemente l'uno dall'altro. Sono collegati 3 termostati con i propri indirizzi IP e 5 diversi sensori con ID univoci. Se il sensore è connesso ad una rete Wi-Fi avrà un proprio IP; se è connesso ad un gateway l’indirizzo IP del dispositivo sarà l’indirizzo IP del gateway.
Usiamo WebSocket per comunicare con i dispositivi. Ciò consente di ridurre al minimo i costi delle risorse rispetto alle richieste di acquisizione e di ottenere informazioni in modo dinamico durante la connessione o la modifica.
I dati vengono prelevati direttamente dal dispositivo a cui appartiene il blocco, bypassando il server. Pertanto, se uno qualsiasi dei dispositivi si guasta, il sistema continua a funzionare. L'interfaccia web semplicemente non visualizza il dispositivo mancante dall'elenco. Ma un segnale sulla perdita, se necessario, arriverà sotto forma di notifica nell'applicazione dell'utente.
Il primo tentativo di implementare questo approccio è stata un'applicazione PWA. Ciò consente di memorizzare una base di blocchi sul dispositivo dell'utente e richiedere solo i dati necessari. Ma a causa delle peculiarità della struttura, questa opzione è incompleta. E c'è solo una via d'uscita: un'applicazione nativa per Android e IOS, attualmente in fase di sviluppo attivo. Per impostazione predefinita, l'applicazione funzionerà solo sulla rete interna. Se necessario, puoi trasferire tutto al controllo esterno. Pertanto, quando l'utente lascia la rete locale, l'applicazione passa automaticamente al cloud.
Controllo esterno: duplicazione completa della pagina. Quando la pagina è attivata, l'utente può accedere al server e gestire i dispositivi tramite il proprio account personale. In questo modo il Server espande le sue funzionalità, permettendoti di gestire i dispositivi anche fuori casa, senza essere vincolato al port forwarding o ad un IP dedicato.
Pertanto, l'opzione di cui sopra non presenta gli svantaggi dell'approccio server e presenta anche una serie di vantaggi sotto forma di flessibilità nel collegamento di nuovi dispositivi.
A proposito del termostato
Diamo un'occhiata al sistema di controllo utilizzando come esempio il nostro termostato.
Fornito:
- Controllo della temperatura per ciascun termostato (visualizzato come blocco separato);
- Impostazione del programma di funzionamento del termostato (mattina, pomeriggio, sera, notte);
- Selezione di una rete Wi-Fi e connessione ad essa di un dispositivo;
- Aggiornamento del dispositivo “over the air”;
- Configurazione MQTT;
- Configura la rete a cui è connesso il dispositivo.
Oltre al controllo tramite l'interfaccia web, abbiamo fornito quello classico: facendo clic sul display. A bordo è presente un monitor Nextion NX3224T024 da 2.4 pollici. La scelta è caduta su di lui per la facilità di lavorare con il dispositivo. Ma stiamo sviluppando il nostro monitor basato su STM32. La sua funzionalità non è peggiore di quella di Nextion, ma costerà meno, il che avrà un impatto positivo sul prezzo finale del dispositivo.
Come ogni schermo del termostato che si rispetti, il nostro Nextion può:
- impostare la temperatura richiesta dall'utente (utilizzando i pulsanti a destra);
- attivare e disattivare la modalità di funzionamento programmato (pulsante H);
- visualizzare il funzionamento del relè (freccia a sinistra);
- ha la protezione bambini (i clic fisici vengono bloccati finché il blocco non viene rimosso);
- visualizza la potenza del segnale WiFi.
Inoltre, utilizzando il monitor è possibile:
- selezionare il tipo di sensore installato dall'utente;
- gestire la funzione di blocco bambini;
- aggiornare il firmware.
Facendo clic sulla barra WiFi, l'utente troverà informazioni sulla rete connessa. Il codice QR viene utilizzato per associare il dispositivo al firmware HomeKit.
Demo di come lavorare con il display:
Ci siamo sviluppati con tre termostati collegati.
Potresti chiedere: "Che cosa ha di speciale il tuo termostato?" Ora sul mercato ci sono molti termostati con funzione Wi-Fi, funzionamento programmato e controllo touch. E gli appassionati hanno scritto moduli per interagire con i sistemi di casa intelligente più popolari (Majordomo, HomeAssistant, ecc.).
Il nostro termostato è compatibile con tali sistemi e ha tutto quanto sopra. Ma la particolarità è che il termostato viene costantemente migliorato, grazie alla flessibilità del sistema. Con ogni aggiornamento la funzionalità si espanderà. Al metodo standard di gestione del sistema (secondo un programma), ne aggiungeremo uno adattivo. L'applicazione consente di ottenere la geolocalizzazione dell'utente. Grazie a ciò, il sistema cambierà dinamicamente le modalità operative a seconda della sua posizione. E il modulo meteo ti consentirà di adattarti alle condizioni meteorologiche.
Ed espandibilità. Chiunque può sostituire il termostato convenzionale esistente con il nostro. Con il minimo sforzo. Abbiamo selezionato 5 dei sensori più popolari sul mercato e ne abbiamo aggiunto il supporto. Ma anche se il sensore ha caratteristiche esclusive, l'utente potrà collegarlo al nostro termostato. Per fare ciò, dovrai calibrare il termostato per funzionare con un sensore specifico. Forniremo istruzioni.
Quando si collega un termostato o qualsiasi altro dispositivo, appare contemporaneamente ovunque: sia nell'interfaccia web che nell'applicazione PWA. L'aggiunta di un dispositivo avviene automaticamente: è sufficiente collegarlo alla rete Wi-Fi.
Il nostro sistema non ha bisogno di un Server e, se fallisce, non si trasforma in una zucca. Anche se uno dei componenti si guasta, il sistema non inizia a funzionare in uno scenario di emergenza. Controller, sensori, dispositivi: ogni elemento è sia Server che Client, quindi completamente autonomo.
Per chi fosse interessato, i nostri social network: , , , , .
E-mail: [email protected]
PS Non ti invitiamo ad abbandonare il Server. Supportiamo anche un server MQTT e disponiamo del nostro cloud. Il nostro obiettivo è portare la stabilità e l’affidabilità del sistema a un livello completamente nuovo. In modo che il Server non sia un punto debole, ma integri la funzionalità e renda il sistema più conveniente.
Fonte: habr.com