In questo articolo tratteremo il collegamento dei dispositivi Shelly con Home Assistant analizzando le varie possibilità a disposizione con i loro pro e contro. Ma prima ancora ti presento i dispositivi che secondo me possono esserti più utili per farti un’idea precisa di cosa può servirti per le esigenze di casa tua.
Qui non copriremo quindi i dettagli di come integrare i dispositivi (che comunque se segui i miei consigli sarà facilissimo!) ma questa vuole essere un’analisi delle possibilità, dei pro e contro di ognuna di esse, così da farti una tua idea. Tanti blog, infatti, partono da un punto di vista che il più delle volte non è il più intuitivo né il più saggio. Tanti utenti rischiano quindi partire con la soluzione più complessa o meno aderente alle proprie necessità pensando sia “la cosa giusta” o l’unica soluzione “per non usare il cloud” (ne parlerò meglio più avanti).
Prosegui quindi la lettura con lo spirito di orientarti verso le soluzioni esistenti nel modo che riterrai più opportuno, avendo un quadro della situazione il più completo possibile.
Sommario
- 1 I dispositivi Shelly
- 2 Una raccomandazione importante
- 3 I migliori dispositivi Shelly con Home Assistant
- 4 Il cloud tra leggende metropolitane e false credenze
- 5 Le possibili integrazioni di Shelly in Home Assistant
- 6 Conclusione: quale integrazione per Shelly in Home Assistant?
- 7 Aggiornamenti lenti con integrazione nativa o ShellyForHass?
- 8 Un aiuto nella decisione
- 9 Ti va di darmi una mano?
I dispositivi Shelly
La società Allterco Robotics Ltd. con base in Bulgaria, produce una serie di prodotti noti con il marchio Shelly, che stanno riscuotendo un grande successo commerciale, per più di un buon motivo.
Tutti i prodotti Shelly sono basati su microcontrollore ESP8266 e si collegano alla rete wifi a 2,4 GHz.
I loro prodotti vengono suddivisi nelle seguenti categorie:
- Relays: dispositivi per accendere luci o carichi singoli o doppi a 230V, strip RGBW, dimmer, lettura stato interruttori e carichi 230V. Alcuni possono anche essere usati a 12V, 30-50V.
- Plug&Play: dispositivi pronti per essere usati come smart plug, lampadine smart e pulsanti, oltre ad un purificatore
- Sensori: sensori di presenza, temperatura, allagamento, apertura porte/finestre, gas e fumo. Alcuni di essi alimentati a batteria
- Accessori: pezzi aggiuntivi per i prodotti di cui sopra
I prodotti Shelly danno in dotazione un proprio sistema cloud illimitato incluso nel prezzo di acquisto dei dispositivi. Sebbene questa sia un’ottima opzione per l’utente meno esperto e permette delle semplici automazioni (all’interno del loro ecosistema) non è questo il tema dell’articolo, volendo invece trattare l’integrazione di tali prodotti con l’hub di domotica Home Assistant.
Ma quali sono i vantaggi salienti che caratterizzano i prodotti Shelly rispetto alla concorrenza?
mostra peculiarità dei prodotti Shelly
- Sono prodotti in Europa (Bulgaria), rispettano quindi le norme CE e UL in quanto a emissioni, sicurezza elettrica, sicurezza dei materiali e qualità costruttiva.
- L’approccio della società è molto aperto e parzialmente open source. Le API sono aperte a chiunque e ben documentate sul sito. Il firmware originale è quindi totalmente interoperabile così com’è con qualunque sistema che possa effettuare una chiamata HTTP REST o MQTT (anch’esso integrato nativamente nel firmware) e la connessione al cloud è opzionale.
- La società è molto onesta riguardo ai problemi che si sono verificati nel tempo risultando sempre in post pubblici sul loro gruppo Facebook di assistenza direttamente dal CEO Dimitar Dimitrov, in cui hanno sempre descritto in tutta onestà l’origine del problema e cosa avessero fatto / stessero facendo per risolverlo.
- Risultato dell’approccio aperto ed onesto è che il firmware può essere sostituito nei dispositivi senza invalidarne la garanzia (anche se non ci sono molti motivi se non particolari per farlo) e che se un dispositivo si brucia anche a causa di un errato collegamento, Allterco Robotics ne spedisce un’altro gratuitamente (se comprati dalla casa madre).
- I relay, al contrario di quando si usano lampadine smart comandate da interruttori smart, hanno tutti un ingresso collegabile al classico interruttore / deviatore / pulsante così che la modalità d’uso delle luci non subisca alcuna differenza rispetto all’uso in un impianto non domotico e continui a funzionare normalmente in caso di guasti ad Home Assistant o alla rete di casa.
- Il collegamento wifi, sebbene porti delle complicazioni, ha il grande vantaggio di sfruttare la copertura preesistente della nostra casa tramite il router / sistema mesh / repeater e access point già presenti nella nostra abitazione.
- Il prezzo non è elevato
- Ehi, non mi pagano per scrivere questo articolo, sto dando le mie oneste opinioni 🙂
Ne risulta quindi che i dispositivi Shelly possano essere degli utili alleati per domotizzare casa nostra, particolarmente nei casi di retrofitting, ovvero quando l’impianto elettrico è già esistente e non predisposto per la domotica.
Una raccomandazione importante
Prima di iniziare vorrei raccomandarti di valutare attentamente le modifiche all’impianto elettrico. Al di fuori dei prodotti nella categoria Plug&Play gli altri dispositivi richiedono l’installazione a regola d’arte da parte di persone con competenza e conoscenza degli impianti elettrici. Se non ti senti in grado o hai dubbi su come si installano non pensarci due volte: chiedi al tuo elettricista di fiducia.
Con la tensione di casa a 230V non si scherza, un errore può essere fatale!
Sembra un’ovvietà ma il gruppo Facebook di supporto Shelly è pieno di post con foto di dispositivi installati in modo non idoneo, senza usare puntalini e le più basiche norme di installazione.
I migliori dispositivi Shelly con Home Assistant
Ho personalmente provato quasi tutti i dispositivi Shelly e, prima di passare alle integrazioni da utilizzare, posso quindi stilare un elenco di quelli che secondo me sono più utili e a cosa possono servire concretamente, per aiutarti nella valutazione di uno o più di questi dispositivi.
< class="collapseomatic " id="id66494c9a8b3c0" rel="shelly-highlander" tabindex="0" title="Shelly 1 / Shelly 1L / Shelly Plus 1" >Shelly 1 / Shelly 1L / Shelly Plus 1Questi articoli sono due semplici relay (on / off) che accettano anche un ingresso da un interruttore / deviatore / pulsante a 230V così da poter comandare direttamente il carico collegato. Si prestano quindi a domotizzare dei punti luce di impianti tradizionali nascondendo questi dispositivi nella scatola 503 (se c’è un frutto libero), in una scatola di derivazione o dentro la lampada, se c’è posto.
La differenza tra i due è che Shelly 1 può funzionare anche a bassa tensione (12V) mentre Shelly 1L solo a 230V ma non ha necessità di essere collegato anche al neutro.
Come il precedente anche Shelly 1PM è un relay con ingresso per interruttore / deviatore / tasto a 230V AC o 24-60V DC ma in più misura anche il consumo istantaneo del carico collegato al relay in output.
Sebbene le specifiche lo diano per 16A di consumo massimo ne sconsiglio l’uso su apparecchi molto energivori per lunghi periodi come il forno. Meglio in tal caso utilizzare uno Shelly EM.
Questo dispositivo è molto versatile in quanto equivale a due Shelly 1PM combinati in un unico device. Ha due relay in uscita e due ingressi per interruttori / deviatori / pulsanti a 230V.
Può essere configurato per gestire due carichi indipendenti come due luci oppure per gestire il motore di una tapparella, facendo divenire i relay interbloccati.
In questa ultima configurazione gestisce la posizione parziale della tapparella effettuando una prima calibrazione automatica ed il rilevamento ostacoli, impostando una soglia di intervento in W.
Unica nota quando usato per carichi accesi costantemente tende a scaldare parecchio, superando anche i 70° ma questo non comporta alcun problema.
Anche questo dispositivo è molto versatile, alimentato a 12V o 24V, DC o AC. Può essere utilizzato in due modalità: controller per una lampada o strip RGB o RGBW oppure per controllare fino a quattro luci led in bassa tensione dimmerabili. Anch’esso dispone di un ingresso collegabile ad un interruttore / deviatore / pulsante ma attenzione che in questo caso deve essere un circuito in bassa tensione utilizzante la stessa alimentazione data a Shelly.
Con questo dispositivo è possibile comandare una illuminazione dimmerabile a 230V (tra quelle supportate, verificare sul sito). Dispone anche di due ingressi per interruttori / deviatori / pulsanti a 230V con cui comandare direttamente il carico. Può essere cablato, se si rispettano certi requisiti, senza utilizzare il neutro (verificare il manuale)
Se vuoi misurare l’energia che consumi in ogni istante questo è il dispositivo giusto. Ha due canali cui si collegano due pinze amperometriche (apribili, così non devi nemmeno scollegare le fasi sulle quali li posizionerai…) e un’uscita per collegare un teleruttore. Si può montare nel quadro principale per misurare il consumo totale e il secondo canale può essere usato per misurare la produzione dei pannelli fotovoltaici o, come ho fatto io, per misurare il consumo di una sezione dell’impianto.
Altra modalità di utilizzo è per misurare il consumo in modo sicuro di elettrodomestici energivori come forno, lavastoviglie o piano ad induzione dove sarebbe più saggio usare questo dispositivo piuttosto che uno Shelly 1PM.
Una Smart Plug davvero versatile. La Shelly Plug S è solo poco più grande di un adattatore schuko (forse la più compatta che puoi trovare!) e supporta un carico massimo di 2500W. Rileva il consumo istantaneo e la potenza assorbita nel tempo, oltre che poter spegnere e accendere il carico collegato.
Shelly Plug, invece, è la sorella più ingombrante ma con carico massimo di 16A.
Per la sicurezza della casa questi due dispositivi sono l’ottima versione moderna dei rilevatori di fumo/gas che, oltre a suonare, segnalano la concentrazione di gas / fumo e possono far scattare automazioni, allarmi, notifiche e tutto quel che vuoi.
Shelly Gas esiste in due versioni: LPG per il gas GPL (le bombole) e CNG per il metano. Entrambe richiedono una presa 230V.
Shelly Smoke funziona invece a batteria o alimentato da micro USB e rileva l’eventuale fumo di combustione presente.
Nell’elenco sopra avrai notato che non ho incluso alcun dispositivo a batteria (H&T, D&W, Flood). Tali device, infatti, sono quelli che preferisco meno in quanto il vincolo della tecnologia di comunicazione wifi, sebbene perfettamente idoneo ai dispositivi alimentati, diventa un handicap per i dispositivi a batteria. Sia per quanto riguarda la scarsa durata e grande dimensione della batteria che per il principio di funzionamento.
Tali dispositivi, infatti, sono normalmente disconnessi e si riconnettono al wifi solo in caso di necessità (per aggiornare i dati). In tale modalità impostarne una configurazione differente diventa molto difficile se non si è presenti in luogo premendo il pulsantino che permette di effettuare una connessione al wifi.
Se sei interessato a sensori porta, temperatura, allagamento, ecc ti consiglio piuttosto di orientarti alla tecnologia Zigbee, molto più idonea a tale utilizzo, con batterie a bottone della durata di oltre un anno e molto più veloci nell’invio di cambio stato. Ti consiglio anche di leggere gli articoli dedicati a Zigbee: Home Assistant e ZigBee: orientiamoci e ZigBee: copertura, router, canali.
Il cloud tra leggende metropolitane e false credenze
Rispondendo spesso a frequenti dubbi espressi da molti utenti sul gruppo Facebook Home Assistant Italia mi sono reso conto che c’è un grosso falso mito che aleggia tra gli utenti che si avvicinano a questo mondo
Se integro Shelly con una integrazione nativa lo uso attraverso il cloud, se invece lo integro con MQTT allora non uso il cloud.
Questa credenza è semplicemente FALSA!
La verità è che… non esiste alcuna integrazione che utilizza il cloud di Shelly (c’è una piccola eccezione che nominerò descrivendo l’integrazione ShellyForHass).
E allora perchè c’è questa diffusa credenza? Secondo me ci sono più fattori sommati.
- Il primo deriva da Sonoff, diffusi prima che i prodotti Shelly diventassero noti. Essi utilizzavano il cloud obbligatoriamente. Per poterli usare in locale si era soliti cambiarne il firmware (invalidandone la garanzia appena acquistati… al contrario degli Shelly) con il famoso Tasmota, che appunto comunica in MQTT. Può quindi venir facile pensare allo stesso modo anche con Shelly, che però ha dei principi ben diversi alla base.
- Il secondo è che per vincoli della limitata memoria presente sui dispositivi se si utilizza MQTT si è obbligati a disattivarne il cloud in quanto la memoria non basterebbe a far funzionare entrambe le funzionalità contemporaneamente. Questo significa che con l’integrazione nativa il cloud può rimanere attivato. Attenzione, il fatto che possa essere attivato non significa che debba né tantomeno che lo si stia utilizzando. E’ semplicemente una possibilità in più.
Le possibili integrazioni di Shelly in Home Assistant
Fugata questa grossa leggenda infondata passiamo ora ad analizzare le tre integrazioni disponibili in Home Assistant che permettono di utilizzare i nostri dispositivi Shelly.
Per ognuna di esse analizzerò i pro e contro così da farci un’idea più precisa di cosa abbia ognuna da offrire così che ti possa orientare su quella che ti sembra più idonea al tuo modo di valutare.
Su quest’ultimo punto vorrei insistere. Per questo come per altri argomenti dove bisogna effettuare una scelta non credere a me, non credere agli esperti, non credere a chi ha una risposta perentoria. Acquisisci le informazioni che leggi e fatti una tua opinione personale che sia il più conscia possibile perchè solo te sai quali sono le tue priorità.
Integrazione Shelly nativa
Questa è l’integrazione inclusa in Home Assistant “out of the box”. E’ la più recente ma proprio per questo è stata realizzata nel migliore dei modi, sfruttando l’esperienza di ShellyForHass alle spalle. Nel momento in cui scrivo, con la release 2020.3 di Home Assistant, supporta il 100% dei dispositivi Shelly, compreso il nuovissimo Shelly Motion.
E’ certamente l’integrazione più facilmente fruibile (basta un click…) Espone quasi tutte le informazioni che i device sono in grado di fornire (ad esempio segnale wifi o temperatura interna), semplicemente attivando le entità per default disattivate che ti interessano. Risulta ben funzionante, rapida e intuitiva.
Ha la capacità di prelevare il nome configurato nei nostri dispositivi dalla memoria locale degli stessi, facilitando l’operazione di rinominare le entità.
Nota: è possibile tenere attivo il cloud di Shelly parallelamente all’utilizzo locale da parte di Home Assistant.
Protocolli di comunicazione
I comandi da Home Assistant al dispositivo vengono inviati direttamente dall’integrazione utilizzando dei semplici comandi HTTP REST che implementano out of the box tutti i dispositivi Shelly e sono documentati molto bene. La comunicazione è quindi diretta e veloce tra Home Assistant ed il nostro dispositivo.
Le comunicazioni dei nostri dispositivi verso Home Assistant, invece, utilizzano CoAp-msg, un protocollo concorrente a MQTT ma ritenuto migliore in termini di velocità e latenza. Una comparazione tra i due protocolli sarà trattata più avanti nell’articolo.
Il risultato è che la ricezione degli eventi come “luce spenta” è immediata, con la latenza più bassa possibile.
Pro e contro dell’integrazione nativa
PRO
- Semplicissima da utilizzare, pochi click del mouse
- Supporta tutti i dispositivi Shelly esistenti, compreso il nuovissimo Shelly Motion
- Integrazione nativa , supportata e attivamente sviluppata
- Protocolli efficienti e comunicazione diretta con i dispositivi
- Realizzata di recente: utilizza le migliori tecniche
CONTRO
- Supporta solo i firmware 1.8 o seguenti (anche se non lo vedo un problema. Li aggiorni i tuoi Shelly… vero?)
ShellyForHass
Questa è l’integrazione più anziana, sviluppata dal rivenditore Shelly per la Svezia è diventata diffusa in quanto ottimamente funzionante e supportata attraverso la sua pagina GitHub.
E’ installabile manualmente come custom component o, molto più comodamente, usando HACS.
Negli anni sono state fatte tante migliorie, implementazioni e bugfixing. E’ quindi ora in uno stato di maturità anche se il suo sviluppo sembra andare da un po’ di tempo a questa parte un po’ a rilento in quanto il responsabile Håkan Åkerberg probabilmente ha poco tempo da dedicarvi.
Sono supportati tutti i dispositivi Shelly al di fuori del nuovo Shelly Motion. Come l’integrazione nativa si può usare senza configurare nulla anche se un minimo di opzioni sono consigliate per avere qualche sensore in più come la temperatura interna del dispositivo o il segnale wifi. Si tratta comunque di pochissime banali righe.
Accennavo precedentemente ad una eccezione nell’uso del cloud di questa integrazione: è possibile impostare l’accesso al cloud Shelly nella configurazione (qua il riferimento) all’unico fine di prelevarne il nome già assegnato quando viene rilevato un nuovo dispositivo. Non c’è alcun altro utilizzo del cloud, che risulta solo un plus di comodità opzionalmente attivabile, una feature in più insomma. Questa è comunque una feature che l’integrazione nativa implementa meglio, prelevando il nome del dispositivo direttamente dal dispositivo spesso, focalizzandosi questa sui nuovi firmware che implementano la memorizzazione locale del nome dispositivo. ShellyForHass, invece, gestisce tutte le versioni di firmware.
Una feature che ha più dell’integrazione nativa è un server light MQTT interno, riuscendo quindi a comunicare, se così si vuole, in MQTT con i dispositivi senza usare un broker esterno.
Nota: è possibile tenere attivo il cloud di Shelly parallelamente all’utilizzo locale da parte di Home Assistant (se non si utilizza MQTT)
Protocolli di comunicazione
Al pari dell’integrazione nativa, i comandi da Home Assistant al dispositivo vengono inviati direttamente dall’integrazione utilizzando dei semplici comandi HTTP REST che implementano out of the box tutti i dispositivi Shelly e sono documentati molto bene. La comunicazione è quindi diretta e veloce tra Home Assistant ed il nostro dispositivo.
Le comunicazioni dei nostri dispositivi verso Home Assistant, sempre come l’integrazione nativa, utilizzano CoAp-msg, un protocollo concorrente a MQTT ma ritenuto migliore in termini di velocità e latenza.
Il risultato è che la ricezione degli eventi come “luce spenta” è immediata, con la latenza più bassa possibile.
Pro e contro di ShellyForHass
PRO
- Semplicissima da utilizzare, pochi click del mouse al massimo poche righe per alcune banali opzioni
- Supporta tutte le versioni di firmware e tutti i dispositivi (tranne il nuovo motion, ad oggi)
- Integrazione matura e ben collaudata. C’è però da dire che nuovi problemi vengono affrontati in tempi lunghi quindi in caso di stravolgimenti firmware potrebbe trasformarsi in un “contro”…
- Protocolli efficienti e comunicazione diretta con i dispositivi
- Ha la possibilità di configurare i dispositivi in MQTT e attivare un light MQTT server interno all’integrazione per far comunicare alcuni/tutti i dispositivi qualora si avessero problemi con il router o per esigenze particolari, senza quindi usare alcun broker esterno.
CONTRO
- Quando escono nuovi dispositivi o nuovi problemi i tempi di reazione dell’autore non sono sempre fulminei per via del suo poco tempo, accennato precedentemente
- L’autore ha ultimamente poco tempo da dedicare e lo sviluppo sembra essersi fermato
MQTT
L’utilizzo di Shelly in MQTT è esposto da molti come fosse l’unico degno di nota, la modalità migliore a disposizione ma non è esattamente così…
Questa modalità di utilizzo prevede la disattivazione del cloud sui dispositivi Shelly (perchè, come detto precedentemente, per vincoli di memoria non è possibile tenere attive entrambe le funzionalità) e l’attivazione della modalità MQTT.
Andrà inoltre installato e configurato un MQTT broker su altro dispositivo o sullo stesso che esegue Home Assistant (in cui è disponibile come Add-on con Mosquitto Broker).
In seguito, su Home Assistant, andrà installata l’integrazione MQTT che va fatta collegare al broker MQTT di cui sopra.
Sarà infine necessario scrivere righe di configurazione e creare delle automazioni che effettuino delle operazioni sui dispositivi al riavvio di Home Assistant.
Nota: non è possibile tenere attivo il cloud di Shelly parallelamente all’utilizzo locale da parte di Home Assistant.
Protocolli di comunicazione
I comandi da Home Assistant vengono inviati tramite comunicazione TCP al broker MQTT che si occuperà a sua volta di inviare la comunicazione al dispositivo attraverso un comando MQTT su di una connessione TCP al dispositivo.
Ne consegue che la latenza non possa che essere superiore rispetto alle due soluzioni precedenti in quanto vengono effettuate due connessioni TCP passando da un software esterno, prima di raggiungere il dispositivo.
La ricezione degli eventi dai dispositivi, in questa modalità, avviene per mezzo di una comunicazione MQTT che il dispositivo effettua al broker attraverso una connessione TCP. Il broker, a sua volta, invierà questo messaggio ad Home Assistant per mezzo di un altra connessione TCP attraverso l’integrazione MQTT.
Ne consegue che la latenza non possa che essere superiore rispetto alle due soluzioni precedenti in quanto vengono effettuate due connessioni TCP passando da un software esterno, prima di raggiungere Home Assistant.
Le connessioni TCP sono poi più pesanti per i dispositivi embedded e meno performanti, da un punto di vista della latenza. Ecco perchè confrontandolo con un protocollo basato su UDP e per giunta diretto non può che avere un tempo superiore.
Pro e contro di MQTT
PRO
- Ottima se si utilizza MQTT in altri progetti, ad esempio in firmware personali su microcontrollori con cui si vuole comandare dei dispositivi o se ci sono più fruitori, oltre ad home assistant, dei dati scambiati su MQTT
CONTRO
- Protocollo prolisso e non autodescrittivo basato su testo ASCII e connessioni TCP
- Necessaria applicazione esterna per funzionare (MQTT broker)
- Comunicazioni multiple TCP per ogni comando inviato o ricevuto
- Può risultare più complicato da configurare, per gestire tutti i dati ricevuti, i topic, i parametri e le unità di misura.
Conclusione: quale integrazione per Shelly in Home Assistant?
Qual è quindi il migliore dei modi per collegare i nostri dispositivi Shelly a Home Assistant? La risposta non è univoca e condivisa da tutti. Esporrò di seguito la mia opinione che potrai valutare secondo il tuo personale criterio avendo acquisito i dati esposti sopra.
La prima delle valutazioni da fare è se usare MQTT o i protocolli nativi.
A mio avviso l’utilizzo di MQTT aveva senso soltanto prima del firmware 1.10 di Shelly. Prima di tale versione, infatti, l’utilizzo di CoIot (usato per inviare gli eventi dai dispositivi a Home Assistant) era vincolato alla modalità multicast, che quindi non permetteva il funzionamento senza polling in caso di Shelly in subnet/VLAN differenti da Home Assistant o problemi del proprio router a gestire multicast.
Con l’aggiornamento 1.10 è possibile però, accedendo via browser all’IP del dispositivo Shelly e andando in Internet & Security -> Advanced – Developer settings -> CoIoT peer, inserire l’ip di Home Assistant (senza porta!) per indirizzare i pacchetti di aggiornamento stato CoIoT direttamente all’IP senza passare da multicast, risolvendo quindi qualunque problema di routing precedentemente risolvibile solo con MQTT.
E’ quindi secondo me molto meglio utilizzare i protocolli nativi di Shelly, ovvero HTTP REST + CoAp-msg e non MQTT.
Questo perchè, come spiegato sopra, MQTT “passa la palla” al broker, prima di arrivare ad Home Assistant, con multiple connessioni TCP, aumentando quindi la latenza e rendendo il sistema più complicato senza una ragione razionale.
C’è inoltre da tenere in considerazione che il protocollo MQTT è formattato con stringhe di testo estese intellegibili ASCII (quindi prolisse) ed è basato su TCP, mentre CoAp-msg (parte di CoIoT) è basato su UDP, molto più snello e indicato per messaggi a bassa latenza, e i messaggi sono binari e più compatti, aumentando ulteriormente il gap tra i due protocolli.
Per chi volesse approfondire consiglio la lettura di uno studio comparativo in uno scenario di utilizzo tra MQTT e CoAp.
Nel caso decidessi di utilizzare MQTT avresti comunque due possibilità:
- se hai già un broker MQTT configurato e attivo per altro, potresti utilizzare quello
- se non lo hai ti consiglio invece di provare ShellyForHass che permette l’utilizzo dei dispositivi in MQTT, qualora lo si volesse, integrando al suo interno un server MQTT light che non richiede alcuna configurazione né addon esterno. Anche la configurazione degli Shelly avverrebbe automaticamente, semplificando tutta la gestione.
Se hai optato invece, come me, per HTTP REST + CoAp-msg hai due possibilità:
- Integrazione nativa
- ShellyForHass
L’integrazione nativa è realizzata ex novo, con concetti più nuovi, aderenza del 100% con le API e programmazione asincrona e dall’aggiornamento 2020.3 di Home Assistant (appena rilasciato mentre scrivo) supporta il 100% dei dispositivi compreso il nuovissimo Shelly Motion. Sarebbe facile pensare che possano presentarsi problemi di gioventù del progetto ma in realtà uno degli autori (Simone Chemelli) era contributore anche di ShellyForHass e ne ha trasportato il know-how del lungo sviluppo nella nuova integrazione che, effettivamente, devo appuntare avesse davvero pochi issue aperti su github che comunque sono stati tutti chiusi per la release 2020.3. Lo sviluppo futuro, ad ogni modo, sembra molto vigoroso, visto il ritmo di implementazione dei vari dispositivi.
ShellyForHass è un progetto più vecchio e con qualche possibilità in più ma non sviluppato attivamente, negli ultimi periodi. Allo stato attuale funziona molto bene ma in caso di necessità di modifiche i tempi potrebbero non essere fulminei… Rispetto all’integrazione nativa offre due possibilità aggiuntive: supporto dei firmware precedenti all’1.8 e supporto ad un light MQTT server interno, qualora lo si volesse usare.
Quale delle due usare quindi? Entrambe sono valide ma credo sia meglio iniziare con l’integrazione nativa a meno che non servano delle peculiarità di ShellyForHass (Firmware < 1.8 o serva MQTT)
Ringrazio Simone Chemelli, sviluppatore di entrambi i progetti, per avermi condiviso delle utili informazioni interne che mi hanno convinto che questa sia la strada giusta da seguire.
Se non hai quindi un’esigenza specifica di quelle espresse sopra, sia che tu sia alle prime armi, sia che tu sia un guru di Home Assistant, ti consiglio di provare l’integrazione nativa, che si ottiene semplicemente da Impostazioni -> Integrazioni – Aggiungi integrazione e selezionando Shelly smart home.
Se invece ti serve una delle feature che ha in più (firmware vecchi, MQTT interno) allora ShellyForHass sarà comunque un’ottima scelta.
Aggiornamenti lenti con integrazione nativa o ShellyForHass?
Come accennato sopra è possibile che il tuo router non gestisca correttamente il multicast (o non sia configurato correttamente) per far funzionare il protocollo CoIoT per i pacchetti CoAp-msg usati dagli Shelly per inviare gli aggiornamenti sugli stati in tempo reale.
Questo può accadere anche se il tuo impianto è sezionato in diverse subnet / VLAN.
Cosa succede in questi casi? Sia l’integrazione nativa che ShellyForHass utilizzeranno il polling per determinare lo stato dei dispositivi (accesi / spenti, stato degli input, temperatura, consumo, ecc), il che significa richiedere ai dispositivi ogni intervallo configurato lo stato ai dispositivi (dovrebbe essere 30 secondi, in ShellyForHass è configurabile). Questa è una situazione ovviamente ben lontana dall’essere desiderabile…
Ci si può accorgere facilmente, ad esempio, tenendo in mano lo smartphone con l’app companion che mostra lo stato dell’entità di uno Shelly e premendo il pulsante collegato al suo input. Se il cambio di stato visibile sullo smartphone è immediato allora CoIoT sta funzionando correttamente.
Se invece passano diversi secondi dalla pressione dell’interruttore all’aggiornamento dello stato sullo smartphone allora è del tutto probabile che CoIoT non stia funzionando per uno dei motivi elencati ad inizio paragrafo.
Ma niente paura, risolvere è semplicissimo! Basta configurare i dispositivi Shelly per usare unicast e non multicast.
Per farlo anzitutto assicurati che i dispositivi Shelly siano aggiornati alla versione 1.10 o seguente in quanto unicast è configurabile solo da tale release.
A questo punto accedi all’interfaccia web usando un pc o un telefono ma usando il browser, non l’app. Basta digitare l’indirizzo IP del dispositivo Shelly nel tuo browser.
Ora vai in Internet & Security -> Advanced – Developer settings: assicurati che Enable CoIot sia abilitato e nella casella CoIoT peer inserisci l’indirizzo IP (senza porta) del tuo server Home Assistant al posto di mcast. Poi premi SAVE.
Ripeti questa operazione per tutti i tuoi dispositivi Shelly e rieffettua il collaudo dello smartphone: vedrai che ora i tempi di risposta sono immediati!
Un aiuto nella decisione
A riassunto della mia opinione personale motivata nel paragrafo precedente riporto un semplice flow chart decisionale di come effettuerei io la valutazione dell’integrazione da usare per i dispositivi Shelly in Home Assistant.
Parti da START e arriva all’integrazione consigliata.
Ti va di darmi una mano?
Il contenuto di questo sito è completamente gratuito senza pubblicità invasive e il fine non è certo guadagnare …ma mantenere un sito ha un costo. Se ti va di darmi una mano per sostenere le spese o ti va di sostenere questo progetto hai le seguenti modalità:
- Donazione con Paypal:
- Regalami un caffè su Buymeacoffee:
- Effettua i tuoi acquisti Amazon a partire da QUESTO LINK (o tramite i prodotti sotto)
- Acquistare i tuoi prodotti Shelly usando QUESTO LINK
- Effettuare i tuoi acquisti AliExpress usando QUESTO LINK
Shelly Plus 2PM, Interruttore a Relè 16A, Wi-Fi e Bluetooth, Misuratore di Potenza, Automazione delle tapparelle, Compatibile con Alexa e Google Home, App iOS Android
SONOFF MINI R4 WiFi Smart Switch 2-Way, Interruttore intelligente fai-da-te, modalità relè staccabile, WiFi 2.4G, controllo APP, Funziona con Alexa, Google Home Assistant, controllo remoto eWeLink
Shelly Plus 1PM, Relè Interruttore Intelligente, Wi-Fi e Bluetooth, Misuratore di Consumo, Domotica, Compatibile con Alexa e Google Home, App iOS Android, Nessun Hub Richiesto
17,99 €
Shelly Plus i4, Controllore Wi-Fi e Bluetooth Intelligente a 4 poli, Casa Domotica, Compatibile con Alexa e Google Home, App iOS Android, Nessun hub richiesto
Shelly Plus 1, Relè interruttore intelligente, Wi-Fi & Bluetooth, Contatti a potenziale zero, Compatibile Con Alexa & Google Home, App iOS Android, Nessun Hub Richiesto
Shelly Pro EM 50A, Contatore di energia Wi-Fi e Bluetooth con comando a Contattori Con Misurazione Dei Consumi, Domotica, Compatibile Con Alexa e Google Home, Nessun Hub Richiesto
Shelly EM, Contatore di Energia Wireless Intelligente e Interruttore a Relè Restringente, Domotica, Funziona con Alexa e Google Home, App iOS Android, Nessun Hub Richiesto
49,90 €
Shelly Uni, Modulo per l'automazione di vecchi elettrodomestici, Wi-Fi, 2 ingressi, Contatti puliti, Compatibile con Alexa e Google Assistant, App iOS e Android
Sempre chiaro!!!
Matteo
Grazie Matteo! In realtà ho appena modificato l’articolo aggiornando molte informazioni grazie al contributo di Simone Chemelli, sviluppatore di ShellyForHass e ora dell’integrazione nativa. Non cambiano i concetti fondamentali ma alcuni pro/contro, la valutazione finale ora propende per l’integrazione interna e il flow chart è ora aggiornato.
Complimenti Henrik, ma soprattutto grazie! Come ti anticipavo per gli altri articoli, ci vuole parecchio tempo e nervoso per arrivare, con l’esperienza, ad una consapevolezza di questo tipo. Riesci sempre ad esporre le cose con una banalità disarmante. La cosa più bella è che, alla fine dell’articolo, il lettore prende consapevolmente la sua strada. grazie ancora!
Alessandro grazie mille! Queste tue parole sono la migliore ricompensa alle ore di sonno perse per scrivere questi articoli ❤️
What about Shellies Discovery? https://github.com/bieniu/ha-shellies-discovery
Hello Bieniu, Shelly Discovery seems a good way to simplify Shelly configuration using MQTT as it automatically create entitites in Home Assistant when MQTT topics are detected and I think is a must if you’re planning to use MQTT. However, in my point of view using MQTT, even with the help of this script, is much more complicated than using native integration or ShellyForHass. Just see the minimum configuration requested by this script or the full configuration (that adds to the MQTT broker and per device configuration) and compare it to the minimum configuration requested by other integration (none) 🙂
In the end this does not add or remove anything to the protocol comparation and considerations 😉 I would use MQTT only in the final flow chart case.
Complimenti per la guida Henrik!
Ho scoperto per caso il tuo sito e ho già letto tutti gli articoli che hai pubblicato!
In questo articolo in particolare, mi hai “convinto” a provare l’integrazione nativa di Shelly. Avendo già la configurazione con mqtt attiva, cosa devo fare per passare alla configurazione nativa?
Grazie
Ciao e grazie Antonio! Se vuoi provare l’integrazione nativa ti consiglio anzitutto di fare un backup / snapshot prima di iniziare, così puoi tornare indietro 🙂
Poi rimuovi l’integrazione MQTT in HA (il Broker se non lo usi per altro lo puoi anche eliminare ma anche se lo lasci non da fastidio)
A quel punto configuri i dispositivi Shelly disattivando MQTT, è importante, non saltarlo (e riattivando il cloud, se lo volessi utilizzare ma ricordo che è parallelo e non c’entra niente con HA). Vai nelle integrazioni, aggiungi l’integrazione “Shelly smart home” e i device saranno scoperti automaticamente. Se così non fosse premi Configura e verranno scoperti tutti. Segui comunque le indicazioni ufficiali: https://www.home-assistant.io/integrations/shelly/
Onestamente non sono proprio d’accordo…
Il problema più grande della integrazione nativa è che funziona con metodo “polling” vuol dire che aspetta un determinato numero di tempo prima di andare a vedere cosa succede sullo shelly. Questo è assolutamente inaccettabile quando si ha bisogno di essere immediatamente notificati di qualcosa (vedi per esempio, quando si preme l’interruttore quando lo shelly è configurato in detached mode “.
Allo stesso modo, MQTT risolve questo problema ed usando lo script che scopre automaticamente gli shelly, hai tutto configurato in pochi secondi (e con molti più sensori)…
Il discorso che fai avrebbe senso… non fosse che parte da un presupposto errato: l’integrazione nativa, così come ShellyForHass, non si basano su polling!
Leggi con attenzione l’articolo in quanto espongo i protocolli utilizzati. E scoprirai che per la ricezione degli eventi si basano su CoAp-msg (un protocollo binario ed efficiente basato su UDP) e HA riceverà quindi le informazioni più velocemente rispetto a MQTT (per le ragione esposte nell’articolo).
Solo se il tuo router non supporta correttamente il multicast allora queste integrazioni passeranno al polling in quanto “meglio di niente”. In Realtà ShellyForHass ha anche una modalità aggressiva per risottoscrivere regolarmente il multicast su router che lo implementano male.
Io sono stato in questo caso con un TP-Link Deco M5 ed ho preferito però risolvere il problema, piuttosto che circumnavigarlo… Ho preso un Fritz 7590 e il multicast (oltre che tutto il resto) funziona a meraviglia.
Infine non è vero che con MQTT hai molti più sensori in quanto sia con ShellyForHass che con l’integrazione nativa hai a disposizione il 100% delle informazioni che i dispositivi Shelly sono in grado di fornire (compresa ad esempio temperatura interna, potenza del segnale wifi, stato di sovraccarico, ecc)
Tutto questo è scritto nell’articolo comunque…
Guida abbastanza lunga, ma molto interessante. Ho iniziato da poco, ora ho tutto zigbee, ma mi serviva qualcosa che andasse, non a sostituire ma ad affiancare, i pulsanti fisici a muro.
Ora ho 2 shelly plug S, in seguito conto di fare tutta la casa con gli shelly.
Grazie! Ora mi vado a guardare tutti i tuoi articoli, perche’ se sono scritti come questo, rende il tutto facile come leggere un romanzo.
GRAZIE!
P.s. come faccio a sapere se il mio router accetta il multicast? lo sapro’ quando andró a provare gli shelly o ci sono dei link/guide da guardare?
Ti ringrazio, purtroppo è difficile rendere breve un articolo che contiene tante informazioni. Tanti altri rendono brevi gli articoli non esponendo le scelte scrivendo “si fa così, così e così” ma è un dei motivi per cui ho aperto il mio blog: non nascondo cosa preferisco ma espongo le alternative e soprattutto argomenti tecnicamente i pro ed i contro delle scelte così che ognuno si possa fare una propria opinione razionale. E questo purtroppo richiede tante “parole” 🙂 Ma vedo che la cosa è apprezzata e questo mi rende felice.
Riguardo al multicast ho a lungo ricercato un metodo semplice per capirlo ma non ne ho trovato uno che non richiedesse scrivere un articolo a sè… Tu però hai degli shelly Plug S, basta usare quelli. Assicurati che abbiano l’ultima versione fw (1.10.x), Integrali in Home Assistant con l’integrazione nativa, mostra il dispositivo su Home Assistant dal PC e con il telefono tramite l’app Shelly o tramite la pagina raggiungibile al suo indirizzo IP ne cambi lo stato. Se vedi riflettersi il nuovo stato immediatamente (ordine di millisecondi) su PC allora il multicast funziona. Se invece passano secondi prima che lo stato del PC si aggiorni allora non funziona. In alternativa puoi impostare l’ip al posto di mcast nelle impostazioni (come spiegato in fondo all’articolo) per esser sicuro, a quel punto non ti interessa che funzioni o no.
Pingback: Uno sterilizzatore UV smart fai da te • Henrik Sozzi TECH
E’ possibile integrare uno shelly installato in un altra abitazione tramite cloud? Quando provo ad aggiungerlo tramite l’integrazione ufficiale mi chiede l’indirizzo ip.
So che tramite mqtt potrei integrarlo facilmente ma perderei il cloud.
Ciao Roberto, che io sappia tramite cloud non c’è nulla che ti permetta di integrare gli Shelly. Credo che sia perché avendo delle API locali ben documentate e rientrando nel principio di HA di comandare tutto senza cloud la strada giusta sia quella. Però certo avere la possibilità di usare uno Shelly remoto non sarebbe male. Puoi fartelo a mano usando le API rest di Shelly.cloud, se ti piace la “hard way” 😀
Ad ogni modo puoi farlo con integrazione nativa a patto di avere una VPN o un IP statico dove hai lo shelly remoto.
Buongiorno Henrik, ottima guida anche in questo caso e condivido i complimenti già espressi per la volontà di “guidare” e non di imporre soluzioni.
Fatta la sincera premessa, avrei una domanda di cui non ho trovato risposta in giro: che tu sappia c’è la possibilità di ridurre la frequenza di rilevazione della potenza (uso uno shelly plug s)? Il mio ho visto fa rilevazioni anche ogni 4 secondi… fin troppo scrupoloso! L’alternativa è fare una nuova entità interpolando i dati, ma magari c’è una soluzione più semplice. Grazie in anticipo, un saluto
Ciao Alberto, grazie per le parole gentili! Che io sappia no, non c’é un modo per ridurre la frequenza perché dipende dal dispositivo stesso e che io sappia non c’è un parametro per impostare la frequenza di invio.
Tieni conto però che può essere utile per rilevare picchi e comportamenti rapidi, oltre che per rilevare condizioni velocemente (io ad esempio la uso per rilevare quando si accende/spegne una vecchia TV non smart)
Se proprio non vuoi ti rimane solo l’interpolazione.
Provo a chiedere allo sviluppatore dell’integrazione comunque, se salta fuori qualcosa ti faccio sapere qui.
Ciao Henrik e grazie per le tue guide fantastiche. Ho installato alcuni Shelly I3 in HA con l’integrazione nativa visto che non ho problemi con gli altri Shelly 2.5 ecc. Sappiamo che I3 offre la possibilità di avere più comandi per lo stesso “tasto” (S, SS, SSS, SL, LS, L) ma anche la funzione di STATO se collegato ad un sensore tipo “cancello aperto” “antifurto disattivato” tenda su”.
Quest’ultima funzione molto interessante non è integrata in HA. Al momento ho risolto facendo attivare uno Shelly 2,5 in modalità interruttore con uno script nell’app Shelly… e quindi HA vede lo stato dello Shelly 2.5…. Conosci un sistema per ovviare al problema o pensi che al prossimo aggiornamento implementeranno questa funzione poco conosciuta?
Ciao, grazie per l’aggettivo usato! 🙂
Ho un I3 a casa preso per curiosità di provarlo ma non l’ho ancora mai collegato. Mi sembra però strano che con l’integrazione nativa non si possa rilevare lo stato degli input come si fa con qualunque altro Shelly… Non è che vanno semplicemente abilitati i sensori binary_sensor.NOMESHELLY_input? Io li uso per alcuni Shelly 1 e 2.5 e riportano in un binary lo stato dell’input che cambia in tempo reale. Non c’è la stessa cosa per gli I3? Li trovi nella scheda Sensori del dispositivo, clicchi su “+x entità disabilitate”, clicchi sul sensore e lo abiliti.
Se il problema non è questo fammi sapere che coinvolgo Simone Chemelli (uno dei dev dell’integrazione Shelly)
Ciao Henrik no mi dice “Questa entità non è disponibile.” e sotto “Le entità disabilitate non saranno aggiunte a Home Assistant
Nota: questo potrebbe non funzionare ancora con tutte le integrazioni.” Ho anche usato il tasto per abilitare i sensori e altre voci ma non funzionano. (funziona solo “reboot” e “OTA update”). Tutto perfetto invece con gli altri Shelly i3 usati come “pulsante” con integrazione nativa. Ovviamente firmware aggiornato.
Ok. Inoltro questi commenti a Simone Chemelli. Vediamo che dice.
Ciao Massimo, ti dispiace fare un report su https://github.com/home-assistant/core/issues così io e il resto del Team possiamo verificare cosa succede ?
Ricordati di allegare anche uno screenshot del device così da vedere che entità ci sono nella tua installazione.
Grazie,
Simone
Ciao Simone ho provato ad inserire l’issue nel link indicato ma mi rimane sempre un asterisco che mi blocca il submit. Avevo anche scritto in inglese… 🙂 Succede questo: nell’app Shelly nelle impostazioni x i3 puoi scegliere la modalità “momentaneo “momentary” e nell’integrazione di HA trovi tutte le funzioni S,SS,SSS, LS… perfettamente funzionanti. Se nell’app cambi la modalità in “interruttore” (toggle mode) da usarsi con i sensori di stato filari per esempio, nell’integrazione non compaiono le funzioni che sarebbero solo 2, attivo e non attivo per esempio. Ho anche 2 screenshot ma non so dove inviarveli. Comunque se fate una prova vedete anche voi. Sembra che l’integrazione dell’i3 non sia completa e che manchi proprio una parte.
Grazie mille per l’articolo … molto esaustivo, e fa risparmiare tanto tempo, per cui grazie ancora.
Avrei una domanda, alla quale non ho trovato risposta in giro: è possibile utilizzare gli shelly su home assistant, anche attraverso Alexa, ma senza l’utilizzo del Cloud?
Ciao, grazie 🙂
Certamente. L’utilizzo del cloud con i dispositivi Shelly dipende solo se ti interessa mantenere la possibilità di poterli controllar con l’app Shelly. Nulla ha a che fare con l’integrazione in Home Assistant che non può nemmeno volendo usare il suo cloud (tutte le integrazioni disponibili funzionano in locale).
Per utilizzare i device Shelly (e tutti gli altri che hai in Home Assistant…) con Alexa devi integrare Home Assistant su Alexa e per farlo hai due modi: Nabu Casa, pagando 6,50€ al mese con cui sostieni il progetto di Home Assistant e hai una serie di servizi ben fatti e sicuri già pronti per l’uso oppure Haaska che è gratuito ma lo devi installare e configurare da solo su un’istanza cloud di Amazon che devi crearti.
Ricapitolando colleghi Shelly (come tutti gli altri dispositivi) a Home Assistant e Home Assistant ad Alexa, potendo quindi controllare TUTTI i dispositivi ed anche script configurando routine che riconoscono frasi che vuoi tu.
Ciao Henrik, ottima guida ma non capisco perché a random i miei shelli 2,5 in home assistant si rendono non disponibili. Con l’ app di shelly non ho problemi, le ho provate tutte, resettando varie volte i rele’ e provando a installarli da app o da indirizzo ip ma non cambia nulla. ho provato anche a mettere l’indirizzo ip di home assistant al posto di mcast ma non ho visto miglioramenti. Ho una rete con fritz box 7530 ax con due reapeter 1200 in mesh, non vorrei provare mqtt anche perché mi sembra più complicato, ma se non riesco a risolvere mi sa che è l’unica soluzione che ho. hai qualche idea? Grazie per la tua eventuale risposta
Ciao Ivan, immagino che i firmware siano aggiornati. Che strano che rimangano disponibili (e funzionanti?) sul cloud di Shelly ma non in locale… Ti garantisco che con Fritz funzionano configurati a default con mcast (uno dei fattori che mi ha fatto scegliere Fritz quando non era ancora stato implementato unicast in CoAp-msg). Personalmente uso 7590 + 1200 ed ho zero problemi con i miei 23 device Shelly di tutti i tipi (2.5 compresi).
Se comunque hai problemi a raggiungere i device è probabile che anche comunicando in MQTT ti porti dietro gli stessi problemi. Personalmente verificherei di configurare i device con IP statici, in un range di IP non utilizzato dal DHCP, ovviamente verificare che non ci siano conflitti di IP duplicati e, infine, di verificare il canale che utilizzi che non sia intasato da altri segnali wifi o, potenzialmente, anche da segnali non wifi provenienti (a solo titolo di esempio) da sensori a microonde, ripetitori di segnale TV wireless, sistemi home theater con casse wireless, ecc. Mentre i segnali wifi dei vicini puoi facilmente rilevarli con un’app tipo Wifi Analyzer su Android, i secondi necessitano di un analizzatore di spettro che non è alla portata di tutti (io ho la fortuna di averlo al lavoro). Ad ogni modo puoi provare, compatibilmente con il canale zigbee ed i canali wifi dei vicini, a cambiare canale wifi per vedere se le cose migliorano.
Verifica anche il segnale sugli Shelly, puoi usare l’apposito sensore RSSI che fornisce l’integrazione e creare un grafico che includa tutti i device che usi così da vedere eventuali anomalie quando accadono e magari capire se c’è qualcosa che accade contemporaneamente che può esser causa.
In bocca al lupo.
Buongiorno Henrik, vorrei segnalare una cattiva esperienza con gli shelly_door/windows e in genere con gli shelly a batteria. In effetti tu non li hai consigliati, però devo aggiungere che anche l’assistenza ‘shelly-italia’ è stata un po’ una presa in giro: – dopo avermi fatto postare mille configurazioni e chiesto di fare varie cose i problemi non si sono risolti, e alla richiesta di restituire i dispositivi la logica è stata fare richieste di ulteriori schermate e altro (vale a dire tempo di lavoro inutile). Comunque in sostanza i dispositivi vanno off-line dopo settimane e le pile non sono più utilizzabili (ho provato varie marche di pile stesso risultato), segnalo inoltre che l’integrazione con Home Assistant a volte è stata parziale: alcuni dispositivi non sono riuscito a fargli esporre tutti i sensori del cloud, e su alcuni non sono riuscito a impostare l’ IP fisso consigliato dalla casa. Per finire sono stato bannato dal forum https://forum.shellyitalia.it/ senza neanche aver scritto una riga di discredito, brutta esperienza.
Ciao Daniele, mi dispiace per la tua brutta esperienza ma, visto che non piacciono nemmeno a me la maggior parte dei dispositivi Shelly a batteria, avevo proprio scritto un warning a riguardo proprio alla fine del capitolo I migliorei dispositivi Shelly con Home Assistant, sconsigliandoli proprio…
In tale paragrafo evidenzio i difetti dei sensori a batteria consigliando di orientarsi piuttosto a Zigbee (scelta che tuttoggi condivido ancora).
Io ho ancora uno shelly H&T che uso d’inverno in una piccola serra e la batteria dura di solito qualche mese (ma dipende anche quanti aggiornamenti si configurano).
Infine occhio che Shelly Italia, nonostante il nome fuorviante, NON ha nulla a che fare con il brand Shelly, creato da Allterco Robotics Ltd. Shelly Italia è una società italiana, con sede in prov. di Lecce (ti invito a ricercare su google Street View l’indirizzo riportato sul sito di Shelly Italia). Se fai una ricerca Whois del dominio shellyitalia.com scoprirai che tutti i dati dell’intestatario sono “REDACTED FOR PRIVACY”, che è un brutto segno di quando non si vuol far sapere chi c’è dietro ad un marchio.
Ma se cerchi la partita iva, che sono obbligati dalla legge italiana ad esporre, vedrai che la società NON è Shelly Italia ma DALES S.r.l. che corrisponde al negozio di termoidraulica presente all’indirizzo riportato che si chiama “D’Alessandris”.
Con questo devo anche dire che non ho nulla contro questa società, ci mancherebbe altro. Ma ho letto tanti feedback negativi su di loro e io stesso ho comprato in passato dei prodotti di revisione vecchia da loro… Questo rovina la percezione del marchio ed è un gran peccato.
In sintesi Shelly Italia non ha a che fare con l’azienda madre ed è un semplice rivenditore.
Detto questo ti consiglio di acquistare sul sito della casa madre https://shelly.cloud . Personalmente mi sono sempre trovato benissimo. Dividendo le spese di spedizione facendo un ordine con amici e parenti non fa nemmeno una gran differenza.
Ti ringrazio molto, comunque, per aver condiviso la tua esperienza!
Buongiorno Henrik, mi sono comprato il nuovo Shelly-plus 1pm è la mia felicità è durata poco; quando ho cercato di integrarlo in HA l’integrazione ufficiale mi dice:
“Dispositivo non completamente supportato. Si prega di contattare il supporto Shelly”
Hai idea se ci sono all’orizzonte delle possibilità, oppure sto configurando male il dispositivo? grazie un saluto
Ciao Daniele, no qualcosa non torna. Anch’io ho uno Shelly Plus 1 PM (questo per intenderci) e funziona perfettamente con l’integrazione ufficiale nel core di HA.
Non è che non hai aggiornato il firmware del dispositivo?
Esatto, scusami infatti dopo aggiornamento è andato tutto, grazie
Ciao Henrik, ti chiedo ancora un particolare su Shelly Plus 1 PM, non mi espone ‘power’ sull’integrazione di Home Assistant, il messaggio è:
“Questa entità non viene più fornita dall’integrazione shelly. Se l’entità non è più utilizzata, eliminala nelle impostazioni.”
Non ho fatto caso ma mi sembrava andasse, è un problema degli aggiornamenti ? a te funziona tutto?
(mia HA 2022.11.3 – Supervisor su Doker, in effetti ho cambiato installazione e sono passato da raspi a minipc-Herobox, avevo necessità di nextcloud e ho migrato tutto li, il componente di HA-nextcloud non mi ha funzionato)
Grazie un saluto.
Ciao Daniele, scusa per il ritardo. No, i miei Shelly Plus 1 PM espongono l’entità power senza alcun problema. Verifica che sia tutto ok (non è che hai ancora i file di shellyforhass nella cartella custom_components?), eventualmente prova ad eliminare l’integrazione di quel dispositivo e ricreala.
Non mi è mai capitato un caso così comunque. Anche migrando su altro hardware non vedo il motivo per cui debba accadere. Fammi sapere se risolvi!
Buongiorno Henrik grazie della risposta, in effetti mi ero dimenticato dello shelly Plus 1 PM, fino all’altro giorno che ha iniziato a segnalare un problema di sovraccarico e in continuazione spegneva il dispositivo allacciato (lavatrice). Ho provato a riavviare e anche aggiornare, ho tenuto osservato lo shelly, cercando di capire se si surriscaldasse, ma nulla e poi tutto si è rimesso ad andare compreso ‘power’: forse l’aggiornamento? non capisco il comportamento.
Aggiornare cosa? Il firmware dello Shelly? Perché se aveva un firmware vecchio poteva essere quello. Se intendi Home Assistant, a meno che avessi una versione molto vecchia, direi che non c’entra niente.
Magari lo fai già ma ti consiglio qua do installi gli Shelly nuovi come prima cosa di aggiornarne il firmware prima di aggiungerli in HA. A volte arrivano con versioni vecchie e contenenti bug.
Se invece il firmware non c’entra e inizia ancora a dare il problema coinvolgo uno degli sviluppatori dell’integrazione.
non sono molto d’accordo sul discorso shelly a batteria.. io ne ho parecchi.. sono settati con il loro ip fisso e la durata della batteria varia da 6 a 8 mesi.. e nessun impiccio di fili in giro….
Ciao Roberto, capisco la tua posizione, ognuno ha un punto di vista unico in base alle proprie esigenze e al proprio modo di vedere le cose. La mia è un’opinione personale peraltro basata sulla generazione di dispositivi della data a cui ho scritto l’articolo. Da allora non ho più provato Shelly a batteria più recenti, magari sono migliorati.
Personalmente continuo a preferire Shelly alimentati in quanto sempre raggiungibili (mentre gli Shelly a batteria vanno in deep sleep per minuti e minuti durante i quali sono offline, per risparmiare batteria). Inoltre gli Shelly a batteria hanno tempi di reazione più lenti agli eventi (apertura porta, ad esempio) e batterie più grosse rispetto ai medesimi dispositivi ZigBee come Aqara, che trovo molto più idonei essendo molto più piccoli, con batteria piccolissima, durata che supera due anni e tempo di reazione immediati.
A casa mia avevo installato ben prima del Covid sensori Aqara ad ogni finestra, PIR in ogni ambiente dove mi era utile per un totale di 25 sensori e…. Le batterie riportano ancora percentuali > 50% 😊
Cmq ho ancora un paio di Shelly H&T che uso ancora e funzionano regolarmente. Ad ognuno la sua scelta! 👍🏻
Buongiorno Henrik
Uso uno shelly em interfacciato ad Hassio per controllare la quantità di energia prelevata da enel per evitare che i carichi eccessivi possano far saltare il contatore.
Per questo tengo, con delle precedenze, limitato l’accensione delle utenze entro il limite del 33% per un massimo di 3 ore (come previsto da enel) abbassando poi la soglia al 10% per un’ora.
Tutto bene ma, mentre l’applicazione rileva in modo pressochè istantaneo ( un paio di secondi) le variazioni, su Hassio l’aggiornamento avviene grossomodo ogni 30 sec.
Questo ritardo non credo sia causato da un sovraccarico del Raspberry, che ha la cpu impegnata per un 4-6 % con punte brevi al 15-18
Hai idea se c’è un modo di aumentare la frequenza di refresh del dato?
Mi permetterebbe di poter ridurre il margine di sicurezza che devo tenere rispetto alle soglie
Grazie
Ho risolto usando le istruzioni riportate qui: https://community-assets.home-assistant.io/original/4X/5/b/9/5b99820451bc819429ee4f44de06690a84f560a5.png
così potrà esser utile a chi ha la stessa esigenza
Grazie comunque dell’ospitalità
Si, è la stessa cosa che consiglio anche nell’articolo… 😉
Pingback: Quali dispositivi per Home Assistant? • Henrik Sozzi TECH
Buongiorno Henrik, sono un neofita e sono giorni che cerco di risolvere questo problema. Ho n. 5 Shelly 2.5 installati per motorizzare le serrande di casa. Nella sostituzione di un esemplare mi trovo in questa situazione: n.1 lo vedo accedendo con user e psw mentre gli altri 4 li vedo opzionando “Dispositivi rilevati”. Se cerco di aggiungere i 4 al blocco che vedo dopo user e psw mi segnala che è già associato ad altro utente/account. Credo di aver generato due account per cui non posso spostare dispositivi. Credo che la soluzione è quella di eliminare un utente/account ma non so come farlo. Mi suggerisci un percorso o un altro sistema per risolvere il mio problema. Ti ringrazio anticipatamente. Tommaso Natale
Ciao scusa il ritardo. Il problema che hai è nell’inclusione dei dispositivi nell’app Shelly (ovvero nel cloud Shelly). Questo è totalmente indifferente per Home Assistant che li usa in locale. Anche io li ho aggiunti usando l’app per comodità e li ho lasciati associati al cloud come “backup” (anche se non ne ho mai avuto bisogno, ad onor del vero)
La soluzione sarebbe quella di accedere con il primo account con cui hai associato i primi 4 e rimuoverli. Se non ricordi user/pass, anche usando gli strumenti per ricordare la password, onestamente non so quali soluzioni ci siano ma cercando su internet, nel gruppo di supporto FB https://www.facebook.com/groups/1686781668087857 oppure chiedendo a support@shelly.cloud sicuramente ne vieni fuori.
L’alternativa è che te ne freghi del cloud, ti colleghi ai singoli IP degli Shelly usando il loro indirizzo IP, ne disattivi il cloud (lato cloud resteranno associati ma lato Shelly li avrai staccati) e li aggiungi ad Home Assistant.
Salve Henrik, complimenti per l’articolo. ho una domanda, se posso, da farti essendo io un neofita.
Ho da poco installato Home Assistant e avendo uno Shelly EM per l’impianto fotovoltaico l’ho integrato con ShellyForHass. Vorrei provare l’Integrazione nativa, ma non riesco ad eliminare ShellyForHass. Come fare?
Potresti indicarmi almeno un sito dove è spiegato? Grazie in anticipo e buona giornata.
Giacomo
Buongiorno Henrik, interessantissimo articolo di comparing dei protocolli. Io ho una ventina di Shelly in casa più o meno e oramai storicamente tutti integrati con mqtt, ma visto il tuo articolo mi viene tanto la voglia di utilizzare http con CoIoT che mi sembra decisamente più diretto. Hai mica qualche suggerimento di snippet per iniziare questa great migration? Grazie mille in anticipo e complimenti ancora per l’articolo
Ciao Luca, grazie! Si, secondo me non ha senso (se non per esigenze particolarissimo) usare gli Shelly in mqtt con Home Assistant oggi.
Non ho alcuno snippet ma l’operazione è davvero semplice: li togli da Mqtt e li aggiungi ad ha dalla rilevazione automatica o da aggiungi dispositivi inserendo l’indirizzo ip.
Ti consiglio di provare con uno, vedi come ti trovi e ti fai un’idea di come farlo per tutti gli altri.
Se tieni gli stessi entity id non devi nemmeno rifare le automazioni, in teoria.
Fammi sapere se lo fai come ti trovi.
Buongiorno Enrik,
scrivo sotto questo tuo ottimo articolo per un problema riguardante Shelly EM.
circa 8 giorni fa il mio shelly EM che monitorava consumi e fotovoltaico è andato offline e non sono più riuscito a farlo funzionare. Alla fine l’ho sostituito con uno shelly nuovo ma così facendo nella plancia energia di home assistant non vedo più i dati storici (circa 2 anni) ma solo i dati a partire dal momento della sostituzione.
La mia domanda è se esiste un sistema per rivedere tutto lo storico sotto la plancia energia?
Ciao, quando sostituisci un device se gli dai lo stesso identico nome che origina quindi gli stessi nomi entità mantieni continuità nei dati. Home Assistant non sa che hai cambiato device se gli entity id restando gli stessi.
Ciao Henrik,
prima di tutto complimenti per i tuoi articoli.
Utilizzo svariati dispositivi Shelly ma ho il seguente problema: utilizzo in due casi la modalità di estensore di portata wi-fi di un dispositivo per raggiungere un’altro dispositivo, sempre shelly. Il fatto è che la rete estesa ha una classe diversa da quella del router e pertanto non riesco a raggiungere il secondo dispositivo connesso. Posso farlo tramite browser indicando l’indirizzo IP del primo dispositivo e indicando una porta specifica, nel mio caso 192.168.188.139:11100.
Il fatto che in Home Assistant indicando l’indirizzo precedente mi ritorna un errore.
Esiste un modo per risolvere?
buonasera Henrik ho uno shelly plug installato da 15 su presa fotovoltaico plug and play perchè se stacco e accendo velocemente il plug and play mi salta il differenziale mi sai aiutare grazie
Ciao, non ho capito cosa mi vuoi chiedere, lo shelly plug è installato da 15… cosa? Inoltre che cosa è il plug and play che stacchi e accendi…? Perdonami ma così è davvero difficile dare una risposta sensata.
Ad ogni modo tieni presente che il differenziale rileva dispersioni verso terra. Shelly plug non usa la terra (è passante per la spina che ci colleghi) quindi la causa va cercata nel carico che ci hai collegato.
scusami se non ho scritto bene, il pannello fotovoltaico non ha un relè fisico, ma al suo posto c’è un triac o mosfet, quindi con questo tipo di shelly che non usa la terra ma è passante mi fa scattare il differenziale . Quindi lo devo eliminare ed usare uno shelly em che dici?
Ciao Henrik e grazie per le preziose informazioni.
Volevo indicarti questa mia difficoltà ad aggiungere lo Shelly Plus 1 al server Home Assistant.
La configrazione comprende HoAss installato con Docker su NAS (QNAP) residente in ufficio con indirizzo IP pubblico.
Lo shelly è a casa (serve a comandare la caldaia). Quando, utilizzando l’app da casa cerco di aggiungerlo con l’integrazione Shelly di HoAss mi chiede di inserire in Host l’indirizzo IP dello Shelly ma inserendolo correttamente mi dice impossibile connettersi ( o qualcosa del genere). Come devo inserire l’indirizzo ? utilizzando nel mio caso 192.168.1.4 o altro ? Devo modificare qualcosa sullo Shelly ?
Grazie per il supporto che vorrai fornirmi.
Ciao Claudio,
se ho capito bene il tuo host è in ufficio con IP pubblico ma non hai una VPN permanente verso casa. In tal caso usando l’app da casa stai guardando l’interfaccia web dell’host che è comunque in ufficio. Quando tu aggiungi un device e gli dai un IP della tua LAN locale a casa Home Assistant non ha modo di raggiungerlo perché il tuo NAS in ufficio cerca di accedere al tuo IP 192.168.1.4 di casa che, ovviamente, non è raggiungibile.
Ma la domanda è: perché far girare Home Assistant in ufficio, visto che una delle peculiarità principali è quella di gestire la domotica in locale? Anch’io in ufficio ho macchine sempre accese e posso capire la tentazione ma, credimi, ti conviene usare un hardware poco energivoro (consiglierei un MiniPC con un celeron) e installarlo in casa.
Se invece vuoi proprio usarlo così allora vedo una sola possibilità dalla sicurezza decente:
Installi il broker MQTT (io uso Mosquitto, ad esempio), apri la porta di MQTT sul router dal tuo ip pubblico all’ip del NAS (il broker andrà protetto con utenti dalla password adeguata) e farai puntare a quella istanza di MQTT lo Shelly. Poi andrà configurato a mano in Home Assistant.
Però davvero, perché Home Assistant non è locale…?
Buongiorno Henry e grazie per l’esauriente risposta.
Come hai sottolineato è “comodo” avere un NAs in uffifcio sempre acceso e e collegato a un UPS !
In ogni caso ho ordinato un ZimaBlade sul quale installerò Home Assistant a casa successivamente.
Ieri ho installato in rete locale dell’ufficio, uno Shelly Plus H&T (seconda generazione) attivando prima sul dispositivo il Websocket e poi inserendo come Server : ws://MioNAS:8123/api/shelly/ws e a questo punto è stato visto da HoAss.
Ora (in attesa del nuovo server ZimaBlade che naturalmente installerò a casa) proverò la tua soluzione (MQTT).
Una domanda il broker MQTT devo naturalmente installarlo sul NAS in Docker (https://indomus.it/guide/installare-e-configurare-il-broker-mqtt-mosquitto-con-docker-su-qnap-via-containerstation/); ti tengo aggiornato !
Ancora grazie
Passa ad HA su zimablade a casa il prima possibile. Sarà tutto molto, molto, molto più semplice, immediato e coerente 🙂
Gli Shelly H&T sono particolari perchè vanno in sleep (per non consumare) e quindi si comportano in modo diverso ed è necessaria una configurazione manuale per connetterli. Gli Shelly alimentati, invece, vengono rilevati in automatico da Home Assistant e aggiunti con un click (se in rete locale 😉 )
Tieni conto che io sono contro l’uso di MQTT per gli Shelly, sostenendo che aggiunge una inutile complicazione laddove l’integrazione nativa funziona benissimo, con le ottime api native degli Shelly e quindi è assurdo usare MQTT. L’unico caso d’uso è, secondo me, il tuo (HA e Shelly su due reti diverse). Si, il broker lo installi sul NAS e ne apri la porta sul tuo IP pubblico che farai puntare dagli Shelly a casa.
Però, davvero, anticipa la zimaboard e usa il tutto come è stato pensato nativamente se ne hai la possibilità.
il zimablade è un Blade 7700 che ho acquistato in pre-order lo scorso 12 feb; da come c’è scritto sulla store dovrebbero esseri spediti da fine marzo.
Nel frattempo mi esercito con HoAss.
Ancora grazie
Ciao Henrik, Ho installato il Broker mosquitto su Qnap attraverso il docker e sembra che tutto sia andato bene.
Ho poi inserito l’integrazione MQTT in HoAss e anche questo sembra sia andato bene.
Non riesco però a far vedere lo Shelly Plus 1 ad HoAss anche dopoa aver configurato lo Shelly con i dati necessari ! Mi avevi scritto di configurarlo “a mano” … come faccio ?? Scusami ma sto entrando da poco in questo fantastico mondo di HoAss.
Saluti
Mi spiace non poterti aiutare direttamente perché non ho mai configurato alcuno Shelly in questo modo (sono contrario all’uso di MQTT per gli Shelly ma nel tuo caso è l’unica possibilità). Ti posso suggerire un link, però, dove spiega come farlo.
Non mi piace che tu scopra il mondo di Home Assistant passando dai modi più difficili e arzigogolati di integrare i device… Ricordati che stai passando dalla Sicilia per andare da Roma a Milano… 😉
Quando avrai i device in locale puoi buttare via MQTT, ti vedrà in automatico i device e con un click li hai integrati alla perfezione.
Buongiorno Henry e grazie per l’ottima guida.
Volevo porti una domanda, c’è modo di integrare in Home Assistant dispositivo shelly condiviso da altro utente? Ho uno shelly 1 condiviso funzionante da cloud shelly ma non viene visto in Home Assistant nativamente.
Utilizzo integrazione nativa.
Ciao e grazie 🙂
No, quel che vedi dall’app è all’interno del cloud Shelly. L’integrazione nativa non utilizza il cloud ma i device fisicamente raggiungibili via LAN.
Il fatto quindi che tu abbia condiviso un device è un “magheggio” che avviene all’interno del cloud Shelly, nei loro server, Home Assistant non ne fa uso.
Se vuoi usare tale device presente in una rete diversa da quella di casa tua temo che l’unica possibilità sia quella di installare un broker MQTT, aprirne l’accesso sull’IP pubblico e collegare ad esso lo shelly remoto.
Che è il contrario di quel che consiglio ma in quello specifico scenario è l’unica possibilità senza passare dal cloud. E visto che un’integrazione che usi il cloud di Shelly proprio non esiste è l’unica alternativa in assoluto 🙂
Ciao HenriK volevo dirti che grazie alle tue indicazioni e ad altre info trovate i rete sono riuscito finalmente a raggiungere l’obbiettivo!
Ora lo Shelly Plus 1 istallato a casa viene gestito con HoAss istallato sul server in ufficio !
Grazie ancora
Buongiorno Henrik, continuo con le mie configurazioni ! Riepilogo:
Ho una configurazione NAS QNAP su cui ho installato (Container Station) sia Home Assistant che Mosquitto Broker.
Ora (anche grazie ai tuoi preziosi consigli !) ho configurato due sensori Shelly BLU (1 Door/Window e 1 Motion) che attraverso uno script caricato sullo Shelly Gateway Bluetooth inviano i dati attraverso MQTT Broker (Mosquitto).
Riesco a vedere i dati inviati con Mosquitto Explorer come rappresentato nell’immagine sotto presa da Mosquitto Explorer: https://1drv.ms/i/s!AhyZ_RD8f_M-jAgyvF0-JHqravrz?e=Az4zI9
Dovrei configurare il file configuration.yaml per vedere i sensori in HoAss. Purtroppo non riesco a farlo.
Hai qualche esempio da cui partire ? Grazie !
Ciao, scusa per la risposta tardiva. Ma no, mi spiace, non ho mai configurato Shelly in MQTT usandoli in locale è davvero inutile, avendo l’integrazione nativa che con un click funziona con un ottimo protocollo ben documentato locale. Ti sei scelto una strada davvero in salita te 🙂 Comunque cercando in rete dovresti trovare esempi in quanto certi blog spacciavano MQTT come “la soluzione” per collegare i device IoT (frutto dell’eredità passata quando sui Sonoff si metteva il firmware Tasmota per renderli controllabili localmente ma Shelly lo è sempre stato nativamente e in modo ottimale…)
In bocca al lupo, mi spiace non poterti aiutare su questo topic specifico ma se non ho know-how preferisco lasciare la parola a chi ce l’ha su quello specifico argomento.
Onestamente non capisco perchè da un sensore BLU (bluetooth low energy) devi far inviare dei messaggi MQTT…. Io ho circa 5 sensori di movimento (quelli nuovi piccoli BLU: https://www.shelly.com/en/products/shop/shelly-blu-motion) di Shelly ma uso l’integrazione via Bluetooth direttamente che espone correttamente gli stati che mi interessano (presenza/assenza/luminosità/batteria) e poi a questi stati, tramite automations, ci collego i comportamenti che mi servono. Per l’integrazione via bluetooth ho usato questo custom component: https://github.com/custom-components/ble_monitor
Ciao Luca, il motivo è che i sensori BLU (motion e door) si trovano in un luogo DIVERSO rispetto a quello dove è installato il server con HoAss !
Con MQTT riesco a far arrivare i dati dal dispositivo BLU attraverso il Broker MQTT a HoAss.
Saluti
Si questo vale anche nel mio caso, ma visto che ogni device shelly plus è un ripetitore bluetooth e tenendo conto che il segnale bluetooth non è limitatissimo, dovresti farcela comunque a meno che non hai una casa su più piani e con enormi pareti che ne limitano il segnale
… per “luogo diverso” intendo in un’altra parte della città !
Grazie Henrik se davvero una persona molto gentile.
Sembra che qualcosa abbia trovato e il sistema ora funziona !
Grazie ancora