capture écran de graphiques sous Home Assistant Graphiques et gestion de chaudière sous Home Assistant

Suite de l'article sur une domotisation quasi gratuite, nous verrons cette fois comment interfacer ebusd à Home Assistant grâce au protocole MQTT, puis comment commencer à personnaliser son installation en ajoutant des widgets.

Home Assistant est une application libre incontournable en domotique (citons tout de même deux concurrents : Jeedom et Domoticz). C'est un service offrant une interface web destinée à contrôler tous les appareils qui peuvent l'être. Tout n'est pas ultra positif avec Home Assistant, mais il a deux énormes avantages à mes yeux : L'application mobile et le bon goût d'être écrit en Python.

Sommaire

MQTT, le pont entre ebusd et Home Assistant

MQTT (Message Queuing Telemetry Transport) est le protocole de choix pour la communication des systèmes connectés de l'Internet des Objets. Le principe est simple : Des clients souscrivent à des topics hébergés sur un serveur (broker) ; ces topics sont employés pour publier ou obtenir des données.

Quelques-unes de ses forces :

  • Capable de faire transiter n'importe quel type de données (fichiers inclus) ;
  • Consomme peu de bande passante ;
  • Possède des paramètres ajustables de fiabilisation de la transmission (QoS) ;
  • Gestion des droits et chiffrement.

C'est via le broker Mosquitto que se feront les échanges entre ebusd et la plateforme de domotique Home Assistant.

Mosquitto - Notes d'installation

Le but de ce chapitre n'est pas de faire un tuto sur l'installation de Mosquitto étant donné qu'il existe une multitude de documents à ce sujet, mais simplement d'y apporter quelques précisions.

Le guide de DigitalOcean est par exemple très bien fait : How to install and secure the Mosquitto messaging broker.

Vous devriez toujours faire appel à un utilisateur dédié pour chaque service accédant à Mosquitto. Pour le créer faites :

$ mosquitto_passwd -c /etc/mosquitto/passwd <username>
# /!\ le paramètre -c écrase une ancienne config !!

Puis dans la configuration /etc/mosquitto/conf.d/default.conf, ajoutez :

# disable all non-authenticated connections
allow_anonymous false
# logins file
password_file /etc/mosquitto/passwd

Côté sécurité, sachez que les identifiants circuleront en clair sur le réseau si vous ne configurez pas le support SSL. Le support non chiffré peut néanmoins être conservé pour les services de la machine où est installé Mosquitto (localhost).

Pour ouvrir le port MQTTS (sécurisé via SSL) au réseau local seulement (ipV4), ajoutez la règle au pare-feu ufw :

$ ufw allow proto tcp to 192.168.0.0/16 port 8883 comment MQTTS

Home Assistant

Les types d'installation

Plusieurs procédures d'installation existent pour Home Assistant (voir doc officielle).

Le choix se fera selon vos besoins, vos connaissances et les forces que vous souhaitez engager dans le processus. Sachez que toutes les méthodes sauf l'installation de la version "core" (manuelle) font appel à Docker. Si vous suivez ce blog, vous saurez que je n'appréciais guère cette techno ; mon avis n'a que peu changé. Toutefois si vous choisissez de vous lancer dans une installation manuelle, sachez que vous pourriez aller à l'encontre d'un casse-tête de première importance. Même avec une distribution type Debian 11 à jour les problèmes de dépendances seront là à moyen et long terme.

En bref, vous avez le choix entre une grosse galère pour une installation légère (~300Mo) et des enclumes conteneurisées à 20Go (pouvant aller jusqu'à 40Go en quelques mois).

Southpark choix poire à lavement ou sandwich au caca ? Hum, que choisir...

Voici vos options :

  • Image système (système minimal pour Raspberry Pi par ex) : lien.

  • Image Docker : lien.

  • Mode Supervised : Installation manuelle du Supervisor de containers Docker : lien.

  • Home Assistant Core : lien.

    Installation manuelle sous Python 3.9 par exemple, via un environnement virtuel et un utilisateur dédié. Vous n'aurez pas la fonctionnalité Supervisor, pas de possibilité d'installer les addons via l'interface web (installation manuelle toujours possible). L'interface web est tout aussi fonctionnelle et c'est l'essentiel.

Je reviendrai dans un chapitre critique sur la gestion du projet et de ses releases. Pour le moment, comme je n'aime pas les boîtes noires obèses, j'ai choisi l'installation manuelle et je propose quelques pistes pour la simplifier.

Astuces pour l'installation manuelle de Home Assistant

Vous avez choisi la voie difficile. Bravo vous avez du temps à perdre et des Go à économiser. Éant donné qu'Internet manque cruellement de ressources à ce sujet, voici quelques points qui pourraient vous servir.

  • Choisissez bien votre version de Python pour bénéficier des wheels précompilées et vous épargner bien des soucis.

    N'oubliez pas que le projet piwheels pour plateformes ARM ne propose des librairies précompilées que pour les versions de Python disponibles sur Raspbian (c.-à-d. en janvier 2023 : 3.7 et 3.9). Je ne saurais que trop vous conseiller de vous baser sur cela pour choisir la version de Python qui hébergera Home Assistant. Tant pis si vous ratez les récentes mises à jour. Croyez-moi ça ne vaut pas le coup.

    Vous pouvez aussi compiler votre propre version de Python depuis les sources. Ce n'est pas bien compliqué.
    J'ai déjà réalisé un article à ce sujet. Rapidement, dans le dossier des sources de Python faites :

    ./configure --enable-optimizations
make -j
# Allez prendre un café
# altinstall évite le remplacement de la version Python3 du système (c'est important)
sudo make altinstall

    L'exécutable sera /usr/local/lib/python3.9 et c'est lui que vous devrez utiliser lors de la création de votre environnement virtuel.

  • Créez votre environnement virtuel "presque" comme indiqué sur la doc

    $ mvirtualenv homeassistant --system-site-packages --python=/usr/local/lib/python3.9

  • Étapes d'installation du paquet Home Assistant

    La dernière version compatible avec votre version de Python sera automatiquement sélectionnée. Toutefois essayez de l'identifier sur PyPI vous en aurez besoin pour récupérer les requirements.

    Observez la construction de l'url avec la version demandée :

    $ curl -L 'https://pypi.org/pypi/homeassistant/2021.1.5/json' | jq '.info.requires_dist' > requirements.txt

    Supprimez toute référence à pip dans ce fichier, il est stupide de se passer de ses récentes mises à jour.

    Installez les dépendances :

    $ pip install -r requirements.txt

    Vous allez avoir des incompatibilités, à vous de les gérer et de corriger itérativement les versions dans le fichier.

    Enfin installez vraiment Home Assistant sans faire appel aux dépendances lors du processus :

    $ pip install homeassistant==2021.1.5 --no-deps

  • Avant le premier lancement

    Le programme essaie par la suite de se mettre à jour avec ses paquets d'origine et donc d'écraser ce que vous venez de faire !!!

    Éditez du mieux que vous pouvez le fichier suivant selon vos précédents ajustements :
    ~/.virtualenvs/homeassistant/lib/python3.9/site-packages/homeassistant/package_constraints.txt

  • Croisez les doigts pour le premier lancement et résolvez progressivement les erreurs

    $ hass
pas content
pas content
pas content
...

  • Erreur LoadError: libffi.so.7: cannot open shared object file: No such file or directory

    Cette erreur est générée par le paquet bcrypt trop récent. Voici comment la tester :

    $ python3.9 -c "import bcrypt"

    Votre système est "ancien" et ne possède pas la mise à jour de cette lib :

    $ ldconfig -p |  grep ffi
libffi.so.7 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libffi.so.7
libffi.so.6 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libffi.so.6
    • Soit vous rétrogradez bcrypt jusqu'à ce que vous n'ayez plus d'erreur.

    • Soit vous créez un lien symbolique à l'arrache car vous devriez avoir libffi.so.6 :

      ln -s /usr/lib/arm-linux-gnueabihf/libffi.so.6 /usr/lib/arm-linux-gnueabihf/libffi.so.7

    • Soit vous installez le .deb idoine et vous croisez les doigts quitte à laisser apt dans un état non configuré (le paquet requiert des ressources que votre OS n'aura aucune chance de se procurer).

      $ wget http://ftp.fr.debian.org/debian/pool/main/libf/libffi/libffi7_3.3-6_armhf.deb
$ sudo dpkg -i libffi7_3.3-6_armhf.deb

  • Erreur Version 3.27.2 of SQLite is not supported; minimum supported version is 3.31.0.

    La version 3.31.0 apporte la possibilité de créer des tables à partir de données calculées sur d'autres tables. C'est du sucre syntaxique et j'ignore s'il est réellement utilisé. Toujours est-il que chez moi l'enregistrement des données fonctionne quand même.

  • Have Fun

Critique sur la gestion du projet Home Assistant et des versions hébergées sur PyPI

L'équipe de Home Assistant publie ses releases en figeant avec bien peu de justifications les versions des dépendances publiées au moment du processus. Ces dépendances font souvent appel à des versions de librairies système TRÈS récentes, que votre distribution n'aura probablement même pas encore songé à empaqueter.

En admettant que votre système soit compatible, le paquet ne s'installe pas par défaut ! En effet, souvent les versions des dépendances spécifiées dans les requirements du paquet ne sont pas compatibles entre elles et vous devrez éditer les requirements à la main.

En admettant² que vous passiez à travers les gouttes, sachez qu'il en est de même avec les versions de Python requises qui ne suivent pas les engagements de support à long terme de la PSF. Ainsi la version 2021.1.5 publiée en janvier 2021 a été la dernière à supporter Python 3.7 dont la maintenance officielle s'arrêtera en juin 2023. Idem pour Python 3.8 qui n'est plus supporté depuis la version 2022.2 de février 2022 alors que sa maintenance prendra fin en octobre 2025. Soit une dépréciation anticipée de plus de 3 ans ><.

On ne devrait jamais avoir un échec quasi-systématique d'installation d'un paquet par pip sur un système compatible. On ne devrait jamais faire une release par commit réalisé (j'exagère à peine...). De telles pratiques et une telle précipitation sur les nouvelles versions ne se justifie pas.
Sauf dans certains cas :

  • Une hipsterisation des développeurs qui sautent sur les nouvelles versions au mépris de la stabilité et de la diffusion au plus grand nombre. Bloquer une version de Python car on a sauté sur les nouvelles syntaxes des typing hints est inepte (fonctionnalité facultative qui depuis 7 ans casse systématiquement la rétrocompatibilité du code, démontrant que ce module standard a été publié dans un état immature dès Python 3.5).

  • La diffusion étant essentiellement faite par des images Docker, les problèmes de rétrocompatibilité ne sont pas pris en compte tant que ça fonctionne dans cet environnement.

  • Pour faire chier et forcer l'adoption des d'installations conseillées.

L'intégration MQTT d'ebusd

Home Assistant propose une personnalisation très poussée MAIS à base de code Python, inclus dans des templates Jinja, eux-mêmes inclus dans un format de configuration : YAML.

Oui dit comme ça, ça paraît bizarre et franchement mal tiré par les cheveux. (Ça l'est.) Rassurez-vous on peut concevoir des scripts Python indépendants pour alléger les fichiers YAML. Pour plus d'informations à ce sujet, voir la doc, et l'excellent projet pyscript.

Les versions récentes disposent d'un système de configuration automatique (MQTT Discovery) faisant gagner beaucoup de temps. ebusd supporte cette fonctionnalité MAIS les types d'entités supportés sont limités.

Je rappelle que les fichiers requis se trouvent ici.

Configuration

En attendant, il vous faudra modifier la configuration de l'intégration d'ebusd pour la rendre compatible avec les règles rédigées spécifiquement pour Chaffoteaux.

Etant donné que je ne souhaite pas assurer la maintenance d'un fichier géant pour quelques lignes ajoutées, il n'est pas prévu que je publie ma version complète du fichier mqtt-hassio.cfg. Je ne publie donc qu'un patch à appliquer au fichier dont vous disposez en ayant installé/compilé ebusd. Pour savoir ce que ce patch contient et la raison des modifications, je suggère vivement d'étudier les commits du dépôt portant le tag [ebusd_HA] (lien de recherche).

Munissez-vous des fichiers /etc/ebusd/mqtt-hassio.cfg et mqtt-hassio.cfg.patch puis appliquez la commande suivante :

$ patch mqtt-hassio.cfg < mqtt-hassio.cfg.patch

Redémarrez ebusd avec de nouveaux arguments pour activer l'intégration MQTT :

$ ebusd -d 192.168.1.65:3333 --latency=200000 --configpath=/path_to_your_config_files/ --enablehex --receivetimeout=100 \
--mqtthost 127.0.0.1 --mqttport 1883 --mqttuser=<mqtt_user> --mqttpass=<password> --mqttjson \
--mqttint=/path_to_your_mqtt_config_file/mqtt-hassio.cfg \
--pollinterval=10

Gérer les entités à choix multiples

capture écran d'un input_select sous home assistant Entité input_select ajoutée manuellement permettant de sélectionner le mode de régulation du chauffage.

Les boites de dialogue à choix multiples font partie des types devant être codés manuellement. Pour ma chaudière cela concerne surtout les règles z1_thermoreg_type (options 0=fixed_temp;1=basic_on_off;2=room_temp_only;3=outdoor_temp_only;4=outdoor_and_room) et dhw_comfort_mode_status_w (options 0=off;1=delayed_on;2=always_on).

Le fichier contenant le code à ajouter à ~/.homeassistant/configuration.yaml se trouve sur le dépôt.

En voici un exemple documenté. Il s'agit de créer à la main la liste des options, un mapping texte pour humains <=> texte attendu dans la configuration ebusd, et une gestion des évènements de modification des valeurs depuis et vers la chaudière.

input_select:
  # Définition de l'entité sous un id unique
  z1_thermoreg_type:
    # Nom de l'entité créée
    name: Z1 Thermoregulation type
    # Options présentées sur l'interface
    options:
      - "Fixed temp"
      - "Basic On/Off"
      - "Room temp only"
      - "Outdoor temp only"
      - "Outdour and room temp"
    icon: mdi:target

automation z1_thermoreg_type:
  # Définition d'une 1ière automatisation
  # Cette automatisation s'exécute lorsqu'une valeur est reçue par le service MQTT sur un topic spécifié.
  # Elle consiste à mettre à jour la valeur dans la GUI.
  - alias: "Set Thermoregulation type selector"
    trigger:
      platform: mqtt
      # Topic MQTT recevant les nouvelles valeurs du paramètre
      topic: "ebusd/boiler/z1_thermoreg_type"
    action:
      # Appel du service sur l'entité z1_thermoreg_type de la GUI
      # Il s'agit de changer l'option d'une entité de type input_select
      service: input_select.select_option
      target:
        entity_id: input_select.z1_thermoreg_type
      data:
        # Mise en forme de la nouvelle donnée à afficher
        # (elle doit être incluse dans la liste des options prévues).
        # Conversion options ebusd => humains
        option: >
          {% set thermoreg_types_map = {
            'fixed_temp': 'Fixed temp',
            'basic_on_off': 'Basic On/Off',
            'room_temp_only': 'Room temp only',
            'outdoor_temp_only': 'Outdoor temp only',
            'outdoor_and_room': 'Outdour and room temp'
          } %}
          # Par sécurité on spécifie une valeur par défaut
          {{ thermoreg_types_map.get(trigger.payload_json.thermoreg_types.value, 'basic_on_off') }}

  # Définition d'une 2ième automatisation
  # Cette automatisation s'exécute lorsqu'une valeur est changée sur la GUI par l'utilisateur.
  # Elle consiste à envoyer cette nouvelle valeur sur le topic MQTT spécifié.
  - alias: "Set Thermoregulation type"
    trigger:
      # Le déclenchement se produit lors d'un changement d'état de l'entité z1_thermoreg_type
      platform: state
      entity_id: input_select.z1_thermoreg_type
    action:
      service: mqtt.publish
      data:
        # Topic MQTT destiné à envoyer les nouvelles valeurs du paramètre
        topic: "ebusd/boiler/z1_thermoreg_type/set"
        # Mise en forme de la donnée affichée sur la GUI vers une donnée attendue par le service ebusd
        # Conversion options humains => ebusd
        payload: >
          {% set thermoreg_types_map = {
            'Fixed temp': 'fixed_temp',
            'Basic On/Off': 'basic_on_off',
            'Room temp only': 'room_temp_only',
            'Outdoor temp only': 'outdoor_temp_only',
            'Outdour and room temp': 'outdoor_and_room'
           } %}
           # Par sécurité on spécifie une valeur par défaut
           {{ thermoreg_types_map.get(states.input_select.z1_thermoreg_type.state, 'basic_on_off') }}

Notons au passage la lourdeur du format : Chaque chaine de caractères est suffisamment répétée pour générer des erreurs de codage et de maintenance.

Conclusion

Un article assez court cette fois, mais vous devriez avoir les bases pour commencer à créer vos widgets de configuration et statistiques sur Home Assistant à partir des données recueillies.

Dans le prochain article nous verrons comment créer des automatisations à partir de ces données pour reproduire le comportement des sondes d'ambiance couteuses vendues par les constructeurs (sélection de loi d'eau, calcul de la température de l'eau en fonction de la température extérieure/ambiante, etc.).

Sources