Qualche tempo fa ti abbiamo presentato . Questo articolo è stato originariamente pensato come una dimostrazione del suo firmware e del sistema di gestione. Ma per spiegare la logica di funzionamento del termostato e ciò che abbiamo realizzato, è necessario delineare l'intera concezione nel suo complesso.
Sull'automazione
In linea di massima, tutta l'automazione può essere suddivisa in tre categorie:
Categoria 1 — dispositivi “intelligenti” singoli. Acquisti lampadine, kettle, ecc. da diversi produttori. Vantaggi: ogni dispositivo espande le possibilità e aumenta il comfort. Svantaggi: per ogni nuovo produttore è necessaria una propria applicazione. I protocolli dei dispositivi di produttori diversi sono spesso incompatibili tra loro.
Categoria 2 — installazione di un PC a scheda unica o compatibile x86. Questo elimina le limitazioni in termini di potenza di calcolo, e su questa macchina viene installato MajorDoMo o qualsiasi altro sistema operativo server per gestire la casa intelligente. In questo modo, i dispositivi della maggior parte dei produttori si collegano in un'unica area informativa. Cioè, viene creato il proprio server per la casa intelligente. Vantaggi: compatibilità sotto un'unica centrale, il che offre ampie possibilità di gestione. Svantaggi: in caso di guasto del server, l'intero sistema torna alla fase 1, ovvero diventa disconnesso o inutile.
Categoria 3 — la variante più hardcore. Nella fase di ristrutturazione vengono installate tutte le comunicazioni e duplicate tutte le sistemi. Vantaggi: tutto è perfezionato e la casa diventa davvero intelligente. Svantaggi: estrema costosa rispetto alle categorie 1 e 2, necessità di pianificare tutto in anticipo e di tenere conto di ogni dettaglio.
La maggior parte degli utenti sceglie la variante uno, per poi passare gradualmente alla variante due. E in seguito, i più perseveranti arrivano alla variante 3.
Ma esiste una variante che può essere definita sistema distribuito: ogni singolo dispositivo sarà sia server che cliente. In sostanza, è un tentativo di prendere e unire la variante 1 e la variante 2, portando insieme tutti i loro vantaggi ed escludendo gli svantaggi, cercando un compromesso.
È possibile che qualcuno dica che una tale soluzione sia già stata sviluppata. Ma tali soluzioni sono molto specifiche; per persone con competenze di programmazione. Il nostro obiettivo è abbassare la barriera di accesso a sistemi distribuiti simili, sia come dispositivi finali che come integrazione di dispositivi esistenti nel nostro sistema. Nel caso del termostato, l'utente rimuove semplicemente il suo vecchio termostato, installa quello intelligente e collega i sensori in suo possesso. Senza ulteriori azioni.
Consideriamo l'integrazione nel nostro sistema attraverso un esempio.
Immaginiamo di avere in rete 8 moduli Sonoff. Alcuni utenti si accontenteranno del controllo tramite il cloud Sonoff (categoria 1). Altri inizieranno a utilizzare un firmware di terze parti e passeranno gradualmente alla categoria 2. La maggior parte dei firmware di terze parti funziona secondo lo stesso principio: trasmissione di dati a un server MQTT. OpenHub, Majordomo o qualsiasi altro servono a un'unica scopo: unire dispositivi disparati in uno spazio informativo unico, situato o su Internet o in una rete locale. Di conseguenza, la presenza di un Server è obbligatoria. Da qui nasce il problema principale – in caso di guasto del Server, l'intero sistema smette di funzionare in modo autonomo. Per prevenire questo, i sistemi si complicano, vengono aggiunti metodi di controllo manuale che duplicano l'automazione in caso di guasto del Server.
Noi abbiamo invece optato per un'altra via, in cui ogni dispositivo è autosufficiente. In questo modo, il Server non gioca un ruolo decisivo, ma semplicemente espande le funzionalità.
Torniamo all'esperimento mentale. Prendiamo di nuovo gli stessi 8 moduli Sonoff e installiamo su di essi il firmware Lytko. In tutti i firmware Lytko è implementata la funzione . SSDP è un protocollo di rete basato su un insieme di protocolli di Internet, utilizzato per dichiarare e scoprire servizi di rete. La risposta alla richiesta può essere sia standard che ampliata. Abbiamo incluso in questa risposta, oltre alle funzioni standard, la creazione di un elenco di dispositivi nella rete. In questo modo, i dispositivi trovano autonomamente l'uno l'altro e ciascuno avrà tale 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 contiene gli ID dei dispositivi, l'indirizzo IP nella rete, il tipo di modulo (nel nostro caso, un termostato basato su Sonoff). Questo elenco viene aggiornato ogni due minuti (questo intervallo è sufficiente per rispondere alla modifica dinamica del numero di dispositivi nella 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 il numero richiesto di moduli. Ogni modulo corrisponde a un dispositivo/sensore/controllore. Visivamente, l'elenco appare così:
Ma se ad esp8266/esp32 sono collegati altri sensori radio tramite cc2530 (ZigBee) o nrf24 (MySensors)?
Progetti
Nel mercato sono presenti vari sistemi distribuiti. Il nostro sistema consente di integrarsi con i più popolari.
Di seguito sono riportati i progetti che cercano in vari modi di cambiare la situazione di incompatibilità tra i diversi produttori. Ad esempio, , o . è legato a un server MQTT, quindi non è adatto come esempio.
Una delle opzioni di implementazione di MySensors è un gateway basato su ESP8266. Gli altri esempi sono basati su ESP32. In essi è possibile implementare il nostro principio di funzionamento per la rilevazione e la creazione dell'elenco dei dispositivi.
Facciamo un altro esperimento mentale. Abbiamo un gateway ZESP32 o SLS Gateway, o MySensors. Come possiamo unirli in un unico spazio informativo? Alle funzioni standard di questi gateway aggiungiamo una libreria del protocollo SSDP. Quando ci si rivolge a questo controllore tramite SSDP, aggiungerà alla risposta standard un elenco di dispositivi che vi sono collegati. Sulla base di queste informazioni, il browser genererà una pagina. In termini generali, questo apparirà così:
Interfaccia web
Applicazione PWA
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"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"
}
Dall'esempio si può vedere che i dispositivi vengono aggiunti indipendentemente l'uno dall'altro. Sono collegati 3 termostati con indirizzi IP propri e 5 sensori diversi con ID unici. Se un sensore è collegato a una rete Wi-Fi, avrà il proprio IP, se è collegato a un gateway, l'indirizzo IP del dispositivo sarà l'indirizzo IP del gateway.
Per comunicare con i dispositivi utilizziamo WebSocket. Ciò consente di ridurre al minimo il consumo di risorse rispetto alle richieste GET e di ricevere 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. In questo modo, in caso di guasto di uno qualsiasi dei dispositivi, il sistema continua a funzionare. Nell'interfaccia web verrà semplicemente omesso il dispositivo che è scomparso dalla lista. Ma il segnale di scomparsa, se necessario, arriverà come una notifica nell'app dell'utente.
Il primo tentativo di implementare questo approccio è stata un'applicazione PWA. Ciò consente di memorizzare il database dei blocchi sul dispositivo dell'utente e di richiedere solo i dati necessari. Tuttavia, a causa delle peculiarità della struttura, questa opzione è incompleta. E l'unica soluzione è l'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, è possibile passare a un controllo esterno. Così, quando l'utente lascia la rete locale, l'app si commuta automaticamente sul cloud.
Il controllo esterno è una duplicazione completa della pagina. Quando viene attivata la pagina, l'utente può accedere al server e gestire i dispositivi tramite l'area personale. In questo modo, il server espande la funzionalità permettendo di controllare i dispositivi rimanendo al di fuori della casa e non essendo vincolati al port forwarding o a un IP dedicato.
Pertanto, l'opzione sopra descritta è priva degli svantaggi dell'approccio server e presenta una serie di vantaggi sotto forma di flessibilità nel collegamento di nuovi dispositivi.
Su termostato
Esaminiamo il sistema di gestione prendendo come esempio il nostro termostato.
Prevede:
- Regolazione della temperatura di ciascun termostato (visualizzata come un blocco separato);
- Impostazione del programma di funzionamento del termostato (mattina, pomeriggio, sera, notte);
- Scelta della rete Wi-Fi e collegamento del dispositivo ad essa;
- Aggiornamento del dispositivo 'over the air';
- Impostazione di MQTT;
- Impostazione della rete alla quale è collegato il dispositivo.
Oltre al controllo tramite web-interfaccia, è prevista anche la modalità classica — tramite pressioni sul display. A bordo c'è un monitor Nextion NX3224T024 da 2.4 pollici. La scelta è caduta su di esso per la semplicità d'uso con il dispositivo. Tuttavia, è in fase di sviluppo un monitor proprietario basato su STM32. Le sue funzionalità non sono inferiori a quelle di Nextion, ma costerà meno, il che influenzerà positivamente il prezzo finale del dispositivo.
Come qualsiasi schermo di un termostato che si rispetti, il nostro Nextion è in grado di:
- impostare la temperatura desiderata dall'utente (pulsanti a destra);
- accendere e spegnere la modalità di lavoro secondo il programma (pulsante N);
- visualizzare il funzionamento del relè (freccia a sinistra);
- disporre di una protezione per bambini (le pressioni fisiche sono bloccate finché il lucchetto non è rimosso);
- mostra il livello del segnale WiFi.
Inoltre, tramite il monitor è possibile:
- selezionare il tipo di sensore installato dall'utente;
- gestire la funzione di protezione per bambini;
- aggiornare il firmware.
Cliccando sulla barra WiFi l'utente può scoprire informazioni sulla rete collegata. Il codice QR viene utilizzato per accoppiare il dispositivo nel firmware HomeKit.
Demo del funzionamento con il display:
Abbiamo sviluppato con tre termostati collegati.
Vi chiederete: “Qual è la peculiarità del vostro termostato?” Attualmente sul mercato esistono molti termostati con funzione Wi-Fi, programmabili e con controllo touch. Gli appassionati hanno scritto moduli per interagire con la maggior parte dei popolari sistemi di smart home (Majordomo, HomeAssistant, ecc.).
Il nostro termostato è compatibile con tali sistemi e possiede tutte le caratteristiche sopra menzionate. Ma la caratteristica distintiva è che il termostato viene costantemente migliorato, grazie alla flessibilità del sistema. Con ogni aggiornamento, la funzionalità sarà ampliata. Al metodo standard di controllo del sistema (secondo programma), aggiungeremo un metodo adattivo. L'applicazione consente di ricevere la geolocalizzazione dell'utente. Grazie a ciò, il sistema cambierà dinamicamente le modalità di funzionamento in base alla sua posizione. E il modulo meteo permetterà di adattarsi alle condizioni atmosferiche.
E l'espandibilità. Chiunque desideri può sostituire il termostato standard installato con il nostro. Con il minimo sforzo. Abbiamo selezionato i 5 sensori più popolari presenti sul mercato e abbiamo aggiunto il loro supporto. Ma anche nel caso di caratteristiche esclusive del sensore, l'utente potrà collegarlo al nostro termostato. Per questo sarà necessario calibrarlo per lavorare con il sensore specifico. Forniremo le istruzioni.
Collegando il termostato o qualsiasi altro dispositivo, esso appare contemporaneamente ovunque: sia nell'interfaccia web che nell'app PWA. L'aggiunta del dispositivo avviene automaticamente: basta collegarlo alla rete Wi-Fi.
Il nostro sistema non necessita di un server, e in caso di guasto non si trasforma in una zucca. Anche in caso di guasto di uno dei componenti, il sistema non inizia a funzionare secondo uno scenario di emergenza. Controllori, sensori, dispositivi: ogni elemento è sia server che cliente, quindi completamente autonomo.
Per chi è interessato — i nostri social media: , , , , .
Email: shop@lytko.com
P. S. non chiediamo 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 completi la funzionalità e renda il sistema più comodo.
Fonte: habr.com
