Domotiser son espace de travail - Partie 1

Domotiser son espace de travail - Partie 1


La domotique “grand public” s’installe de plus en plus dans les foyers, notamment grâce aux nouveaux assistants personnels (Google Home, Alexa) ou encore aux solutions de domotisation “clefs en main”. toutefois, elle reste plutôt absente dans les environnements pros et particulièrement dans notre cas, celui du développement. Pourtant les choses ont pas mal bougé ces dernières années dans le domaine.

Dans cet article, nous allons voir comment construire un dashboard d’équipe à l’aide de la solution domotique home-assistant.io et de quelques objets connectés (Philips Hue, Google Home).

home-assistant.io

Mais qu’est-ce donc que Home Assistant ? Home Assistant (hass) est une solution domotique/automatisation open source, privacy-first qui commence à se faire vraiment bien connaître dans le monde de la domotisation. Elle est développée en python, basée sur un système événementiel et “packagé” avec l’ensemble des plugins (pas d’installation de plugin à posteriori).

Nous allons tout d’abord installer hass, et pour se faire, plusieurs choix s'offrent à nous (Docker, hassbian ou hass.io). Dans le cadre de ce tuto, nous allons le faire tourner sous Docker mais je vous invite à tester Hassbian qui marche très bien sous raspberry.

Cela tient en deux commandes (sous linux) :

$ mkdir home-assistant $ docker run -d --name="home-assistant" -v /PATH_TO_YOUR_FOLDER_HASS:/config -e "TZ=Europe/Paris" -p 8123:8123 homeassistant/home-assistant

Toutes les infos sur l’installation sont disponibles ici

Et voilà, votre home-assistant tourne maintenant en local, et vous pouvez y accéder ici : http://localhost:8124/

home-assistant

Il vous suffit maintenant de créer votre login/pass pour accéder à hass. Nous allons voir à présent comment activer un component, en commençant avec sensor.gitlab_ci.

Components et Sensor Gitlab CI

Tout d’abord, un petit laïus sur comment fonctionne home-assistant.

Si vous regardez dans le répertoire home-assistant que vous avez créé dans la première étape, vous devriez voir ceci :

$ ls home-assistant automations.yaml customize.yaml groups.yaml home-assistant_v2.db secrets.yaml configuration.yaml deps home-assistant.log scripts.yaml tts

Globalement, toute la configuration se passe dans le fichier configuration.yaml, les autres .yaml étant inclus dans celui-ci.

Comme vous pouvez le voir, il est déjà rempli d'un certain nombre d’éléments, qui sont visibles sur votre home-assistant (map, plugin jour/nuit et météo).

Pour faire simple, il existe plusieurs types de components installables sur hass. Celui qui va nous intéresser c’est le type sensor, celui de gitlab-ci :

Dans la partie sensor du fichier configuration.yaml :

sensor: - platform: gitlab_ci #référence du plugin gitlab_id: xxx #ID du projet à monitorer token: xxx #token gitlab name: Test gitlab projet X # va être l'id de votre sensor

Pour récupérer votre token gitlab, c'est par ici

On va maintenant vérifier que le fichier yaml est correct, puis relancer home-assistant pour prendre la configuration en compte.

home-assistant

Vous devriez maintenant voir apparaître le dernier statut du build du projet.

home-assistant

Et si vous cliquez sur le sensor, vous aurez plus d’infos :

home-assistant

Design

Bon c’est bien sympa, mais on ne voit pas grand chose et c’est assez minimaliste tout ca. Allons ajouter un coup de template là-dessus. Hass utilise maintenant lovelace par défaut. Nous allons activer le mode yaml de lovelace pour simplifier l'édition.

#configuration.yaml lovelace: mode: yaml

Et créer le fichier de configuration qui va bien dans le répertoire racine.

$ touch ui-lovelace.yaml

Comme à chaque modification du fichier configuration.yaml, pensez à redémarrer Hass.

Next, nous avons besoin de faire apparaître les valeurs secondaires du plugin Gitlab comme un sensor à part entière, nous allons donc les créer "à la mano".

#configuration.yaml sensor: #... ajoutez uniquement ces deux platforms sous le noeud sensor - platform: template sensors: test_gitlab_projet_x_build_branch: #nom que l’on donne à notre sensor custom value_template: "{{ state_attr('sensor.test_gitlab_projet_x', 'build branch') }}" # On récupère et affiche l’attribute ‘build branche’ friendly_name: "Branch" entity_id: test_gitlab_projet_x #Le sensor va écouter cette entity pour changer ses valeurs test_gitlab_projet_x_commit_date: value_template: "{{ state_attr('sensor.test_gitlab_projet_x', 'commit date') }}" friendly_name: "Date" entity_id: sensor.test_gitlab_projet_x

Attention à bien insérer les deux nouveaux sensors sous le noeud sensor existant déjà dans le fichier configuration.

Ici state_attr nous permet de récupérer l’attribut 'commit date' du sensor gitlab.

Enfin, il nous reste plus qu’à configurer notre template pour afficher notre card.

#ui-lovelace.yaml title: Dashboard views: # View tab title. - title: Gitlab icon: mdi:gitlab id: gitlab cards: - type: entities title: Gitlab X Project entities: - entity: sensor.test_gitlab_projet_x - entity: sensor.test_gitlab_projet_x_build_branch - entity: sensor.test_gitlab_projet_x_commit_date icon: mdi:calendar-range - title: Other id: other

Tadaaa :

home-assistant gitlab-ci

Dernière étape, nous allons créer une card spécifique pour la branche master afin de suivre spécifiquement cette branche. Pour cela, nous allons utiliser un custom component : variable. Il suffit simplement de copier le dossier variable de ce projet dans un repertoire custom_components à la racine du projet.

Ensuite, nous allons créer notre variable de status de CI pour master :

#configuration.yaml variable: master_status: value: "Waiting next commit on master"

Puis, il va falloir créer une automation pour mettre à jour le status de la CI sur cette variable uniquement lorsque le pipeline est sur master.

#automation.yaml - trigger: platform: state entity_id: sensor.test_gitlab_projet_x condition: - condition: template value_template: "{{ is_state('sensor.test_gitlab_projet_x_build_branch', 'master') }}" action: - service: variable.set_variable data: variable: master_status value_template: "{{ states('sensor.test_gitlab_projet_x') }}"

Ici nous avons :

  • trigger: chaque changement lance cette automation
  • condition: il faut que notre entity branch ait la valeur master
  • action: si la condition est remplie, nous changeons la valeur de notre variable avec le status de la pipeline

Enfin, il nous reste plus qu'à ajouter la card dans lovelace.

#ui-lovelace.yaml #... - type: entities title: Gitlab X Project Master entities: - entity: variable.master_status

Le résultat :

home-assistant gitlab-ci

Voilà pour la partie design, il y à des dizaines d’améliorations à apporter que nous ne verrons pas dans cet article.

Par exemple :

  • Changer la couleur de la card en fonction du test / résultat de la pipeline
  • Raccourci vers le résultat de la CI
  • Stats sur les CI/CD

Pour information, vous pouvez faire la même chose avec Github.

Voila pour la première partie de l'article, vous pouvez retrouver le code de cet article sur Github

Dans le prochain article, nous verrons comment nous pouvons agir physiquement en fonction des résultats des pipelines dans notre espace de travail, grâce aux Philips Hue ou encore avec GoogleHome.

Auteur(s)

Rémy Jardinet

Rémy Jardinet

Architect @ Eleven Labs. Spécialisé dans la Data, l'IOT et les schémas avec des boiboites.

Voir le profil

Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !

Notre équipe d'experts répond à toutes vos questions.

Nous contacter

Découvrez nos autres contenus dans le même thème

Archi - L’outil de modélisation qui vous veut du bien

Archi - L’outil de modélisation qui vous veut du bien

Quand il s’agit de faire des schémas d’architectures en projection ou en documentation, il y a pléthore d’outils disponibles, que ce soit en client lourd, web, SaaS… Et avec eux, une multitude de “templates”, presque propres à chaque outil, avec des problématiques de passage à l’échelle dès que l’on commence à avoir plusieurs contributeurs sur ces documents.