Home Assistant & Shelly

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

  1. 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.
  2. 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...)

 

Home Assistant, Shelly & Energy

Il y a quelques avantages à choisir des modules Shelly plutôt que des chinoiseries. D'abord ces modules sont aux normes européennes, et ce n'est pas juste un adhésif CE posé par un mineur au fond d'une usine chinoise (pensez surtout aux assurances qui peuvent se montrer tatillonnes en cas de sinistre), le tarif est accessible et si vous avez une question (technique ou autre) le CEO de la boite vous répondra dans le fil Facebook de la marque ou par mail.

Une chose intéressante est également que beaucoup de ces modules remontent la consommation instantanée et cumulée. Je pensais naïvement que tous conservaient la consommation cumulée en cas de coupure secteur, mais, même si dixit le CEO c'était vaguement en projet en 2019, ce n'est toujours pas le cas et cette information sera perdue localement (sauf EM), bien qu'elle reste accessible sur le cloud Shelly via l'application idoine, mais impossible à récupérer via l'API.

Pour conserver cette information je me suis un peu torturé l'esprit depuis quelques jours en cherchant différentes solutions pour stocker et conserver ce chiffre, alors qu'en fait la solution était sous mes yeux et que je l'avait déjà utilisée quand j'avais déployé mon module de calcul des couts électrique globaux. La solution passe par l'intégration utility_meter: proposée de base par Home Assistant.

Utility Meter est une intégration qui va permettre de stocker le cumul d'une valeur sur une période donnée (hourlydailyweeklymonthlybimonthlyquarterly and yearly), ainsi que la même valeur sur la période n-1. Par exemple, si vous configurez en journalier,  à 13:45 vous pourrez afficher (ou utiliser) la valeur de consommation d'un compteur depuis minuit ainsi que celle à la même heure pour le jour précédent. Imaginez juste le code et les template qu'il aurait fallut imaginer sans cette intégration...

En ce qui me concerne, en prenant par exemple un Shelly 1PM qui pilote un convecteur, ce qui va m'intéresser est de connaitre la consommation cumulée en cours et celle pour le même jour l'an dernier.

Bien sur il est possible, avec un peu d'imagination et quelques lignes de code YAML, de stocker les années précédentes dans un input_number: ou même l'évolution dans une base de données et pour les plus maniaques d'utiliser Grafana pour afficher de beaux histogrammes. Même si ça ne changera probablement rien à la facture EdF, en partant du principe que si la domotique apporte un indéniable confort, de part le surcoût induit elle permet au final rarement réaliser de vraies économies.

En pratique

Dans cet exemple j'utilise l'intégration Shelly for Hass, mais il est toute à fait possible de faire la même chose avec d'autres types de modules, voire en intégrant les modules Shelly (ou autres) avec MQTT...

On crée nos entrées utility_meter: dans notre fichier de configuration : 

utility_meter:
  energy_total_yearly_ch_bureau:
    source: sensor.shelly_shplg_s_f8ccf83_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_cheminee:
    source: sensor.shelly_shsw_pm_68c63afaf521_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_salon:
    source: sensor.shelly_shsw_pm_68c63afaf658_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_cuisine:
    source: sensor.shelly_shsw_pm_68c63afaf1ca_total_consumption
    cycle: yearly

Ensuite on va pouvoir les utiliser directement pour les afficher, ici dans une carte ou j'ai utilisé le composant multiple-entity-row pour les besoins de l'affichage. Vous remarquerez l'utilisation de l'attribut last_period pour afficher l'année précédente.

entities:
  - entities:
      - attribute: last_period
        name: Année passée
        unit: kWh
    entity: sensor.energy_total_yearly_ch_cheminee
    name: Convecteur Cheminée
    secondary_info: last-changed
    show_state: true
    state_header: Année en cours
    type: 'custom:multiple-entity-row'
title: Consomation cumulée
type: entities

Bonus

Etant donné que j'avais dans un séjour ouvert trois convecteurs qui fonctionnent en même temps, j'ai créé deux sensor: pour regrouper ces informations afin de pouvoir afficher une seule ligne pour le séjour, un pour l'année en cours et un pour l'année précédente, qui de fait sera à zéro pour un moment. Attention, utility_meter: commence à compter au moment ou les entrées sont crées.

- platform: template
  sensors:
    energy_total_yearly_ch_sejour:
        friendly_name: "Total Séjour"
        unit_of_measurement: 'kWh'
        value_template: "{{ 
            (states('sensor.energy_total_yearly_ch_cheminee') | float) +
            (states('sensor.energy_total_yearly_ch_cuisinee') | float) +
            (states('sensor.energy_total_yearly_ch_salon') | float) }}"

- platform: template
  sensors:
    energy_total_yearly_ch_sejour_last_period:
        friendly_name: "Total Séjour (N-1)"
        unit_of_measurement: 'kWh'
        value_template: "{{ 
            (states('sensor.energy_total_yearly_ch_cheminee.attributes.last_period') | float) +
            (states('sensor.energy_total_yearly_ch_cuisinee.attributes.last_period') | float) +
            (states('sensor.energy_total_yearly_ch_salon.attributes.last_period') | float) }}"

 

 

EDIT 21/01/2021 : On peut parfois avoir besoin de changer la valeur d'un utility_meter: . Dans les Outils de développement / Services vous trouverez un service utility_meter.calibrate et utility_meter.reset. Sauf qu'il y a un petit bugg et seuls les utility_meter: qui ont une option tariffs: s'affichent. Qu'à cela ne tienne, il suffit de coller le nom de l'entité + TAB et ensuite changer la valeur :

entity_id: sensor.energy_total_yearly
value: 25550

 

 

 

Jeedom : Shelly

On en découvre tous les jours ! Je vais vous parler des équipements Wi-Fi Shelly. Il s’agit de micro-modules, avec un ou deux contacts, des modules au format DIN à insérer dans un tableau électrique, des contrôleurs RGBW ainsi qu’un capteur de température et d’humidité. Rien de bien neuf sur le soleil me direz-vous, mais contrairement aux équipements asiatiques habituels (Sonoff par exemple) qu’il faut flasher ou hacker en perdant au passage le mode de fonctionnement original, les équipements Shelley sont totalement ouverts, et si on souhaite les flasher en ESP Easy le constructeur fournit tout ce qui est nécessaire pour le faire. 

De base on dispose d’une application mobile qui permet la configuration et le pilotage. Un cloud (optionnel) pour un pilotage à distance sans box, la comptabilité MQTT, une API REST et il est bien sur possible de les piloter avec Google Home ou Alexa. Cerise sur le gâteau, ces produits fabriqués en Roumanie sont vraiment certifiés CE et les tarifs sont très attractifs (10 € le relais simple). 

Attention, c’est du Wi-Fi, donc il est impératif d’avoir un réseau Wi-Fi stable.

L’appairage se fait en quelques secondes avec l’application idoine, et des lors que les modules sont reconnus sur le réseau il est possible de terminer la configuration sur le serveur web intégré à ceux-ci. Etant donné que l’on va les exploiter avec une solution domotique externe, Jeedom en l’occurrence, je ne saurais trop conseiller de leur attribuer une IP fixe. Si cela est possible dans la configuration web de chaque module, personnellement je préfère me servir de mon serveur DHCP.

Pour exploiter ces modules en domotique il y a la possibilité MQTT, il doit être également possible de passer des commandes http aux modules, mais je n’ai pas testé car il y a un plugin qui fait très bien le job et qui permet de conserver la compatibilité avec l’application mobile du constructeur. Ce plugin est simple et efficace, pour chaque équipement il suffit de renseigner l’adresse IP et ensuite d’utiliser l’équipement.

Attention toutefois au module capteur de température et humidité, il fonctionne sur pile et se mets en veille, le plugin n'est de ce fait pas toujours capable de récupérer les valeurs et les relevés sont donc trop espacés.

Je trouve ces modules intéressants à plusieurs titres. La simplicité, des tarifs attractifs pour un matériel de qualité, le format DIN et une puissance admissible compatible avec la plupart des radiateurs. A prendre en compte pour remplacer par exemple des équipements Chacon au comportement parfois aléatoire, bref un pas de plus pour l’élimination du RFPLayer…

Sources :

https://lunarok-domotique.com/2019/01/shelly-1-domotiser-prise-10-euros/