Il y a un an quand j'ai commencé à utiliser des Shelly sous Home Assistant l'évidence était d'utiliser l'intégration tierce Shelly4HASS. Depuis la compatibilité MQTT s'est bien améliorée et j'y ait trouvé un intérêt, alors même que les équipes de Home Assistant ingéraient le support natif de Shelly au core. Donc aujourd'hui il n'y a plus vraiment d'intérêt à utiliser cette intégration tierce, toujours dans la logique de faire au plus simple. Bien que Shelley4HASS fonctionne toujours très bien et présente l'avantage de fournir beaucoup d'informations dans les attributs.
Deux options
- Vous débutez en domotique ou vous voulez juste allumer deux ampoules et actionner un relaie. Laissez vous guider, HA découvrira vos modules et vous les piloterez en deux clics afin d'n exploiter toutes les possibilités, l'intégration de base supporte toutes les possibilités et s'améliore de releases en releases.
- Vous passez vos nuits sur votre serveur domotique, vous fréquentez des barbus qui vous poussent à souder des cartes électroniques, votre facteur vous regarde bizarrement depuis que vous recevez plusieurs fois par semaine des paquets en provenance de Chine. Attention, bientôt vous n'aurez plus de famille, d'ailleurs votre femme pense à demander le divorce. Mais faites vous plaisir prenez la route MQTT, en attendant de retrouver la votre, c'est aussi une forme de liberté.
Je ne vais pas vous expliquer MQTT, d'autres l'ont fait, mais MQTT est un vrai protocole domotique en devenir. Attention toutefois, chez Shelly, c'est Cloud (App mobile, Alexa, GH) ou MQTT. Il faut choisir. Attention également aux modules Shelly fonctionnant sur piles, personnellement j'ai abandonné ces modules car même avec du WI-FI Low Energy les piles sont trop rapidement à changer, et il y a des chances qu'en MQTT ce soit encore pire. Donc pour les sondes et autres capteurs, Zigbee est à mon sens plus adapté.
MQTT sur Home Assistant
Je ne vais pas détailler ici l'a mise en œuvre de MQTT, ce n'est pas le propos, mais en gros on installe un broker (dans les adons) et ensuite on ajoute l'intégration MQTT depuis la page des intégrations. Et si on ne veut pas se taper la configuration individuelle des modules, on installe Shelly Discovery qui est un script Python qui va le faire pour vous. Pourquoi ça alors que d'autre modules vont en MQTT créer tout ce qui est nécessaire sous HA ? Simplement parce que Shelly se veut générique et ainsi ils n'ont pas à gérer cette partie. Ca se défend.
Migration vers MQTT
On commence par imprimer une liste des Shelly existants sous Shelly4HASS avec leur adresse et leur usage afin de pouvoir les repérer en MQTT.
Dans l'intégration MQTT qui a remonté nos modules c'est le moment de penser au renommage. C'est un point important et il sera bien moins aisé d'y revenir. Il y a plusieurs écoles.
- Renommage soft ou on renomme juste le display name.
- Renommage hard ou l'on renomme le display name et l'entité. Dans ce cas il faut le faire avant d'aller faire le travail suivant car ça aura des conséquences sur le travail d'intégration.
- Renommage unique du display name de l'entité qui actionne (light ou switch). Ca sera utile pour le présenter dans Alexa ou GH.
- Dans tous les cas il ne faut pas oublier d'affecter une pièce (qui sera également reprise dans Alexa et GH)
- Et sur la config des Shelly de type relais (1, 1PM, 2.5 ou prises) utilisés pour les éclairages, aller dans Appliance type et changer
general
pour light
.
A ce stade on veut virer Shelly4HASS dans les intégrations et aussi le composant dans HACS. Avantage on va voir tout de suite ce qui ne fonctionne plus. Mais on peu aussi le faire après avoir migré en MQTT si on ne pense pas pouvoir faire ce travail d'une traite. Quand Shelly4HASS n'est plus présent on va voir remonter automatiquement les modules via l'intégration de base Shelly. On peut éviter ça si on en a beaucoup ou simplement clique sur ignorer dans les intégrations.
discovery:
ignore:
- shelly
Ensuite il va falloir de la patience et comme toujours de la rigueur.
Point à vérifier pour chaque module :
- S'ils sont affichés dans Lovelace (relais et conso).
- S'ils sont télécommandés (par quoi, automation, BP ou ComanderX).
- S'ils sont déclarés en utility_meter:
- S'ils sont utilisé dans les automations ou des thermostats
- S'ils sont utilisés dans d'autres cas particuliers.
On les faits les uns après les autres et on valide chaque étape en en vérifiant le bon fonctionnement.
Bienvenue dans MQTT !
En bonus, MQTT Explorer qui sera bien utile pour mettre au point des choses complexes et vérifier ce qui se trame sur votre broker. Broker que l'on a ici monté sur HA, mais qui dans l'absolu pourrait être sur une autre machine, un NAS, voire même sur un autre site. Il existe d'ailleurs des brokers publics pour faire communiquer différents objets entre eux. Vous allez me dire que c'est une façon de recentraliser l'information, oui, mais ça peut être nécessaire en IoT avec des objets volatiles car si l'objet A ne parvient pas à joindre l'objet B, le broker conservera alors le message le temps que l'objet B soit disponible... D'où l'intérêt d'une certaine centralisation qui peut d'ailleurs être répartie...
EDIT : un article très bien fait : https://henriksozzi.it/2021/02/shelly-e-home-assistant/ (clic droit traduire si vous ne maitrisez pas l'italien...)