{"id":55356,"date":"2020-01-18T00:00:00","date_gmt":"2020-01-17T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/lytko-obedinyaet"},"modified":"2020-02-18T14:03:28","modified_gmt":"2020-02-18T11:03:28","slug":"lytko-obedinyaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko unisce","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Qualche tempo fa vi abbiamo presentato un termostato intelligente<\/a><\/noindex>. L'articolo attuale \u00e8 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\u00f2 che abbiamo implementato, \u00e8 necessario delineare l'intero concetto nel suo complesso.<\/p>\n

\"Lytko
\n<\/a><\/noindex><\/p>\n

Sull'automazione<\/h3>\n

\nIn linea di massima, l'automazione pu\u00f2 essere suddivisa in tre categorie:
\nCategoria 1<\/u> \u2014 dispositivi \u201cintelligenti\u201d singoli. Acquistate lampadine, bollitori, ecc. da diversi produttori. Vantaggi: ogni dispositivo amplia le possibilit\u00e0 e aumenta il comfort. Svantaggi: ogni nuovo produttore richiede la propria applicazione. I protocolli dei dispositivi di diversi produttori sono spesso incompatibili tra loro.<\/p>\n

Categoria 2<\/u> \u2014 installazione di un PC single-board o compatibile x86. Questo rimuove i limiti di potenza di calcolo, e su questa macchina \u00e8 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\u00e8, si ha il proprio Server per la smart home. Vantaggi: compatibilit\u00e0 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\u00e8 diventa disgiunto, o risulta inutile.<\/p>\n

Categoria 3<\/u> \u2014 la soluzione pi\u00f9 hardcore. Durante il processo di ristrutturazione, vengono installate tutte le comunicazioni e duplicate tutte le sistemazioni. Vantaggi: tutto \u00e8 perfezionato e il risultato \u00e8 una casa davvero intelligente. Svantaggi: costo estremamente elevato rispetto alle categorie 1 e 2, necessit\u00e0 di pianificare tutto in anticipo e di considerare ogni dettaglio.<\/p>\n

La maggior parte degli utenti sceglie la prima opzione e poi passa gradualmente alla seconda. In seguito, i pi\u00f9 determinati arrivano alla terza opzione. <\/p>\n

Tuttavia, esiste un'opzione che pu\u00f2 essere chiamata sistema distribuito: ogni singolo dispositivo sar\u00e0 sia server che cliente. In sostanza, \u00e8 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. <\/p>\n

\u00c8 possibile che qualcuno dica che un'opzione simile \u00e8 gi\u00e0 stata sviluppata. Ma queste soluzioni sono molto specifiche; per persone con competenze di programmazione. Il nostro obiettivo \u00e8 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\u00e0 possiede. Senza ulteriori azioni.<\/p>\n

Consideriamo l'integrazione nel nostro sistema con un esempio. <\/p>\n

Immaginiamo di avere 8 moduli Sonoff nella nostra rete. Per alcuni utenti, sar\u00e0 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 \u00e8 obbligatoria. Ne deriva il problema principale: in caso di guasto del Server, l'intero sistema smette di funzionare in modo autonomo. Per evitare ci\u00f2, i sistemi vengono complicati, aggiungendo metodi di controllo manuale che duplicano l'automazione in caso di guasto del Server. <\/p>\n

Noi invece abbiamo seguito un'altra strada, in cui ogni dispositivo \u00e8 autonomo. In questo modo, il Server non gioca un ruolo fondamentale, ma espande solo le funzionalit\u00e0.<\/p>\n

Torniamo all'esperimento mentale. Prendiamo di nuovo gli stessi 8 moduli Sonoff e installiamo in essi il firmware Lytko. In tutti i firmware Lytko \u00e8 implementata la funzione SSDP<\/a><\/noindex>. SSDP \u00e8 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\u00f2 essere sia standard che avanzata. In questa risposta abbiamo incluso, oltre alle funzionalit\u00e0 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\u00e0 un proprio elenco. Esempio di elenco SSDP:<\/p>\n

\"ssdpList\": \n\t{\n\t\t\"id\": 94967291,  \n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostato\"\n\t}, \n\t{\n\t\t\"id\": 94967282,\n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostato\"\n\t}<\/code><\/pre>\n
\nCome si pu\u00f2 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 \u00e8 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\u00ec:<\/p>\n
\"Lytko
\n
\nMa se a esp8266\/esp32 sono collegati altri sensori radio tramite cc2530 (ZigBee) o nrf24 (MySensors)? <\/p>\n
Progetti<\/h3>\n
\nSul mercato sono presenti diversi sistemi distribuiti. Il nostro sistema consente di integrarsi con i pi\u00f9 popolari. <\/p>\n
Di seguito sono riportati progetti che cercano in vari modi di affrontare la questione della compatibilit\u00e0 tra diversi produttori. Questi includono, ad esempio, SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> o ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> \u00e8 collegato a un server MQTT, quindi non \u00e8 adatto per l'esempio. <\/p>\n
Uno dei modi per implementare MySensors \u00e8 un gateway basato su ESP8266. Gli altri esempi sono su ESP32. \u00c8 possibile integrare il nostro principio di rilevamento e creazione di una lista di dispositivi. <\/p>\n
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\u00e0 alla risposta standard un elenco dei dispositivi connessi. Sulla base di queste informazioni, il browser former\u00e0 una pagina. In linea generale, apparir\u00e0 cos\u00ec:<\/p>\n
\"Lytko
\nInterfaccia web<\/i><\/p>\n
\"Lytko
\nApplicazione PWA<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ identificatore unico del dispositivo\n   \"ip\": \"192.168.x.x\", \/\/ indirizzo ip nella rete\n   \"type\": \"termostato\" \/\/ tipo di dispositivo\n},\n{\n   \"id\": 94967292,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostato\"\n},\n{\n   \"id\": 94967293,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostato\"\n},\n{  \n   \"id\": 13587532, \n   \"type\": \"interruttore\"  \n},\n{  \n   \"id\": 98412557, \n   \"type\": \"fumo\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"sensore_di_contatto\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"sensore_di_temperatura_umidit\u00e0_pressione\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"sensore_di_temperatura_umidit\u00e0\"\n}\n<\/code><\/pre>\n
\nDall'esempio si pu\u00f2 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 \u00e8 connesso a una rete Wi-Fi, avr\u00e0 il suo IP, se \u00e8 collegato a un gateway, l'indirizzo IP del dispositivo sar\u00e0 quello del gateway.<\/p>\n
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. <\/p>\n
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\u00e0 visualizzato il dispositivo mancante dalla lista. Tuttavia, un segnale di perdita, se necessario, verr\u00e0 inviato sotto forma di notifica all'app dell'utente. <\/p>\n
Il primo tentativo di implementazione di questo approccio \u00e8 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 \u00e8 un'app nativa per Android e iOS, attualmente in fase di sviluppo attivo. Per impostazione predefinita, l'app funzioner\u00e0 solo all'interno della rete interna. Se necessario, tutto pu\u00f2 essere trasferito alla gestione esterna. Cos\u00ec, quando l'utente lascia la rete locale, l'app passa automaticamente al cloud. <\/p>\n
La gestione esterna \u00e8 una duplicazione completa della pagina. Quando la pagina \u00e8 attivata, l'utente pu\u00f2 effettuare il login sul server e gestire i dispositivi tramite il proprio pannello personale. In questo modo, il server espande le funzionalit\u00e0, permettendo di gestire i dispositivi anche al di fuori della propria casa, senza essere vincolati al port forwarding o a un IP statico.<\/p>\n
Pertanto, la soluzione sopra descritta \u00e8 priva degli svantaggi dell'approccio server e presenta diversi vantaggi in termini di flessibilit\u00e0 nell'aggiungere nuovi dispositivi.<\/p>\n
Su un termostato<\/h3>\n
\nEsaminiamo il sistema di gestione attraverso il nostro termostato.<\/p>\n
Incluso:<\/p>\n
    \n
  1. Regolazione della temperatura di ciascun termostato (visualizzata come un blocco separato);<\/li>\n
  2. Impostazione del programma operativo del termostato (mattina, giorno, sera, notte);<\/li>\n
  3. Scelta della rete Wi-Fi e connessione del dispositivo a essa;<\/li>\n
  4. Aggiornamento del dispositivo tramite OTA;<\/li>\n
  5. Impostazione di MQTT;<\/li>\n
  6. Configurazione della rete a cui \u00e8 connesso il dispositivo.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nOltre alla gestione tramite interfaccia web, abbiamo previsto anche il controllo classico \u2014 tramite tocchi sul display. \u00c8 presente un monitor Nextion NX3224T024 da 2.4 pollici. \u00c8 stato scelto per la sua facilit\u00e0 d'uso. Tuttavia, stiamo sviluppando un monitor personalizzato basato su STM32. Le sue funzionalit\u00e0 non sono inferiori a quelle del Nextion, ma coster\u00e0 meno, il che sar\u00e0 un vantaggio per il prezzo finale del dispositivo.<\/p>\n
    \"Lytko
    \n
    \nCome ogni rispettabile schermo di termostato, il nostro Nextion sa:<\/p>\n