{"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 ti abbiamo presentato un termostato intelligente<\/a><\/noindex>. Questo articolo \u00e8 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\u00f2 che abbiamo realizzato, \u00e8 necessario delineare l'intera concezione nel suo complesso.<\/p>\n

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

Sull'automazione<\/h3>\n

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

Categoria 2<\/u> \u2014 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\u00e8, viene creato il proprio server per la casa intelligente. Vantaggi: compatibilit\u00e0 sotto un'unica centrale, il che offre ampie possibilit\u00e0 di gestione. Svantaggi: in caso di guasto del server, l'intero sistema torna alla fase 1, ovvero diventa disconnesso o inutile.<\/p>\n

Categoria 3<\/u> \u2014 la variante pi\u00f9 hardcore. Nella fase di ristrutturazione vengono installate tutte le comunicazioni e duplicate tutte le sistemi. Vantaggi: tutto \u00e8 perfezionato e la casa diventa davvero intelligente. Svantaggi: estrema costosa rispetto alle categorie 1 e 2, necessit\u00e0 di pianificare tutto in anticipo e di tenere conto di ogni dettaglio.<\/p>\n

La maggior parte degli utenti sceglie la variante uno, per poi passare gradualmente alla variante due. E in seguito, i pi\u00f9 perseveranti arrivano alla variante 3. <\/p>\n

Ma esiste una variante che pu\u00f2 essere definita sistema distribuito: ogni singolo dispositivo sar\u00e0 sia server che cliente. In sostanza, \u00e8 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. <\/p>\n

\u00c8 possibile che qualcuno dica che una tale soluzione sia gi\u00e0 stata sviluppata. Ma tali soluzioni sono molto specifiche; per persone con competenze di programmazione. Il nostro obiettivo \u00e8 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.<\/p>\n

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

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 \u00e8 obbligatoria. Da qui nasce il problema principale \u2013 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. <\/p>\n

Noi abbiamo invece optato per un'altra via, in cui ogni dispositivo \u00e8 autosufficiente. In questo modo, il Server non gioca un ruolo decisivo, ma semplicemente espande le funzionalit\u00e0.<\/p>\n

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 \u00e8 implementata la funzione SSDP<\/a><\/noindex>. SSDP \u00e8 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\u00f2 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\u00e0 tale 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 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 \u00e8 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\u00ec:<\/p>\n
\"Lytko
\n
\nMa se ad esp8266\/esp32 sono collegati altri sensori radio tramite cc2530 (ZigBee) o nrf24 (MySensors)? <\/p>\n
Progetti<\/h3>\n
\nNel mercato sono presenti vari sistemi distribuiti. Il nostro sistema consente di integrarsi con i pi\u00f9 popolari. <\/p>\n
Di seguito sono riportati i progetti che cercano in vari modi di cambiare la situazione di incompatibilit\u00e0 tra i diversi produttori. Ad esempio, SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> o ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> \u00e8 legato a un server MQTT, quindi non \u00e8 adatto come esempio. <\/p>\n
Una delle opzioni di implementazione di MySensors \u00e8 un gateway basato su ESP8266. Gli altri esempi sono basati su ESP32. In essi \u00e8 possibile implementare il nostro principio di funzionamento per la rilevazione e la creazione dell'elenco dei dispositivi. <\/p>\n
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\u00e0 alla risposta standard un elenco di dispositivi che vi sono collegati. Sulla base di queste informazioni, il browser generer\u00e0 una pagina. In termini generali, questo 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_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 indipendentemente l'uno dall'altro. Sono collegati 3 termostati con indirizzi IP propri e 5 sensori diversi con ID unici. Se un sensore \u00e8 collegato a una rete Wi-Fi, avr\u00e0 il proprio IP, se \u00e8 collegato a un gateway, l'indirizzo IP del dispositivo sar\u00e0 l'indirizzo IP del gateway.<\/p>\n
Per comunicare con i dispositivi utilizziamo WebSocket. Ci\u00f2 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. <\/p>\n
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\u00e0 semplicemente omesso il dispositivo che \u00e8 scomparso dalla lista. Ma il segnale di scomparsa, se necessario, arriver\u00e0 come una notifica nell'app dell'utente. <\/p>\n
Il primo tentativo di implementare questo approccio \u00e8 stata un'applicazione PWA. Ci\u00f2 consente di memorizzare il database dei blocchi sul dispositivo dell'utente e di richiedere solo i dati necessari. Tuttavia, a causa delle peculiarit\u00e0 della struttura, questa opzione \u00e8 incompleta. E l'unica soluzione \u00e8 l'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, \u00e8 possibile passare a un controllo esterno. Cos\u00ec, quando l'utente lascia la rete locale, l'app si commuta automaticamente sul cloud. <\/p>\n
Il controllo esterno \u00e8 una duplicazione completa della pagina. Quando viene attivata la pagina, l'utente pu\u00f2 accedere al server e gestire i dispositivi tramite l'area personale. In questo modo, il server espande la funzionalit\u00e0 permettendo di controllare i dispositivi rimanendo al di fuori della casa e non essendo vincolati al port forwarding o a un IP dedicato.<\/p>\n
Pertanto, l'opzione sopra descritta \u00e8 priva degli svantaggi dell'approccio server e presenta una serie di vantaggi sotto forma di flessibilit\u00e0 nel collegamento di nuovi dispositivi.<\/p>\n
Su termostato<\/h3>\n
\nEsaminiamo il sistema di gestione prendendo come esempio il nostro termostato.<\/p>\n
Prevede:<\/p>\n
    \n
  1. Regolazione della temperatura di ciascun termostato (visualizzata come un blocco separato);<\/li>\n
  2. Impostazione del programma di funzionamento del termostato (mattina, pomeriggio, sera, notte);<\/li>\n
  3. Scelta della rete Wi-Fi e collegamento del dispositivo ad essa;<\/li>\n
  4. Aggiornamento del dispositivo 'over the air';<\/li>\n
  5. Impostazione di MQTT;<\/li>\n
  6. Impostazione della rete alla quale \u00e8 collegato il dispositivo.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nOltre al controllo tramite web-interfaccia, \u00e8 prevista anche la modalit\u00e0 classica \u2014 tramite pressioni sul display. A bordo c'\u00e8 un monitor Nextion NX3224T024 da 2.4 pollici. La scelta \u00e8 caduta su di esso per la semplicit\u00e0 d'uso con il dispositivo. Tuttavia, \u00e8 in fase di sviluppo un monitor proprietario basato su STM32. Le sue funzionalit\u00e0 non sono inferiori a quelle di Nextion, ma coster\u00e0 meno, il che influenzer\u00e0 positivamente il prezzo finale del dispositivo.<\/p>\n
    \"Lytko
    \n
    \nCome qualsiasi schermo di un termostato che si rispetti, il nostro Nextion \u00e8 in grado di:<\/p>\n