+++
title = "Home Assistant : Projet Consonance, l’avant-boutique"
date = 2025-08-19
[taxonomies]
tags = [ "système", "home assistant", "infrarouge", "logitech harmony", "consonance" ]
+++

![Aquaman Meme, en haut Frontend, en bas Backend](/2025/08/aquaman.jpg)

<!-- more -->

# Dis à Tiny Tim que son papa ne rentrera pas pour Noël

Juste une petite note avant de commencer. Je pensais que le hub serait quelque chose qui marche bien. Et bien, je me trompais. **Ça marche putain de sa grand-mère bien**.

Comme le hub est fixe dans la pièce, il peut vraiment être placé de manière ultra optimale. Et ce que j’ai réalisé (et que je ne comprends toujours pas vraiment dans les faits), c’est que finalement ce placement pouvait être pas mal au pif. Mon lecteur de Laserdisc est à pratiquement un mètre, sur la droite du hub, dans meuble presque fermé et ça marche quand même !

Je trouve ça assez ouf dans le principe. J’ai vraiment l’impression que ça joue sur des rebonds ou quelque chose de ce goût-là. Et ça rend l’ensemble hyper fiable et limite très largement le recours aux commandes isolées ou au bouton *Help* comme on pouvait l’avoir avec une Harmony. C’est simple, ça ne foire quasiment jamais.

# Dis à Scarlett que c’est le cadet de mes soucis

Donc résumé de l’épisode précédent : on a un hub, on a des scripts et on a pu tester l’ensemble. Ça marche plutôt pas mal mais ça ne permet pas d’avoir des boutons spécifiques à certaines activités ou d’interagir directement au cours d’une activité (pour mettre à pause, baisser le son, etc…).

Je vais donc tenter de décrire une ou deux activités types pour montrer à quel point c’est important et qu’est-ce qui a guidé mes réflexions sur l’ergonomie de la solution retenue (qui est l’absence de solution en fait, mais on verra ça plus tard).

## Description des activités

Je vais essayer de ne pas te barber, mais voici quelques constats que j’ai fait quand j’ai regardé les activités que j’avais sur la télécommande Harmony :
* toutes les activités utilisent systématiquement les enceintes : écouter un vynil ne nécessite pas la TV mais utilisent les enceintes, toutes les autres activités (JV, Blu-Ray, etc…) utilisent aussi mécaniquement les enceintes ;
* quasiment toutes les activités utilisent la TV, mais une fois que l’entrée est réglée, seule l’activité « Regarder la TV » utilisent les touches de la TV (pour changer de chaîne, etc…)

De ces deux points, on peut tirer quelques évidences :
* pouvoir contrôler le son (volume +, volume -, muet) est primordial pour toutes les activités ;
* comme on ne peut pas passer d’une activité à l’autre, le bouton pour éteindre doit aussi être tout le temps visible.

Le reste a demandé un peu plus d’investigation, notamment pour déterminer un certain nombre de stéréotypes de commandes. Typiquement :
* les lecteurs de média de manière générale (Kodi, lecteur Blu-Ray, lecteur de Laserdiscs) ont souvent un cluster de commandes de lecture qui sont à peu près toutes les mêmes : lecture, pause, avance, arrière, suivant, précédent, etc…
* quasiment toutes les activités nécessitent un cluster de navigation : haut, bas, gauche, droite, confirmer, retour, menu, info, etc…
* l’activité « Regarder la TV » elle-même contient des commandes quasi-uniques : chaîne suivante, chaîne précédente et le pavé numérique.

De ces trois points, on peut de nouveau faire quelques déductions :
* on peut parfaitement se passer d’un pavé numérique : une seule activité l’utilise vraiment, néanmoins, ça donne pas mal de boutons supplémentaires (et numérotés qui plus est) pour faire d’autres choses, on y reviendra ;
* le cluster de commandes média sont généralement assez mal foutues sur les vraies télécommandes : mon lecteur de laserdiscs n’a qu’une seule commande pour Lecture et Pause alors que mon lecteur Blu-Ray a une touche pour Lecture et une touche pour Pause ;
* le cluster de commandes média doit contenir une touche Éjecter qui est rarement présente sur les télécommandes universelles (Logitech Harmony comprise !) ;
* le cluster de navigation est quasi obligatoire pour la moindre activité, et fort heureusement les touches sont relativement simples à implémenter.

Ça donne quelques perspectives intéressantes sur le design moderne des télécommandes. La mode semble être à la télécommande assez minimaliste, mais il y a toujours un bouton lecture/pause, des boutons pour le volume (s’ils sont marqués intelligemment, ils peuvent aussi faire suivant/précédent) et un cluster de navigation. C’est vraiment le strict minimum pour les média modernes.

Mais le manque d’accès direct à certaines fonctions est quand même, à mon sens, relativement gênant. Même sans lire un CD, quand on écoute de la musique comment savoir si droite correspond à passer 10 secondes ou à passer au morceau suivant ?

Encore une fois, l’approche est intéressante mais trop limitée.

# Première tentative

Partant de cela, ma première idée a été de me dire qu’il suffirait de prendre un petit écran tactile dédié. Ça ressemble à ça et ça coûte entre 15 et 20 balles sur AliExpress :

![ESP32 avec écran tactile](/2025/08/esp32_tactile.webp)

Tous ces petits modules sont construits sur une base ESP32 et ça tombe drôlement bien parce qu’il existe un module côté Home Assistant qui permet de configurer un ESP32, y compris les boutons, l’écran tactile et les éventuels capteurs, tout ça dans un YAML plus ou moins compréhensible. Il s’agit d’[ESPHome](https://esphome.io/) et il dispose même des composants nécessaires pour construire des interfaces graphiques via [LVGL](https://esphome.io/components/lvgl/index.html).

Et mine de rien, et bah ça marche pas mal. Alors, il y a quelques pièges à éviter bien sûr mais en s’accrochant un peu et en utilisant quelques astuces de YAML (notamment en abusant des *anchors* YAML), on peut obtenir une interface utilisateur tout-à-fait agréable à utiliser.

Mon idée de base étant qu’on ne peut pas passer d’une activité à l’autre, j’ai donc fait un système assez simple :
* la page d’accueil contient un bouton par activité (10 au total)
* quand on clique sur le bouton en question, ça lance le script correspondant côté Home Assistant et ça affiche la page spécifique à l’activité
* sur cette page, le bouton Éteindre est toujours disponible, lance le script d’extinction et revient à la page principale
* toujours sur cette page, les boutons de volume sont disponibles en permanence en haut de l’écran (et c’est un vilain *anchor* YAML bien crade)
* chaque touche après ça envoie directement une commande Home Assistant avec la bonne commande IR derrière

C’est relativement chiant à construire parce qu’il y a quand même beaucoup de boutons (8 pour un cluster média, 10 pour un pavé numérique, etc…) et qu’on ne peut pas vraiment « programmer » : il faut obligatoirement tout assigner à la main. Encore une fois, avec des morceaux d’*anchors* YAML, on s’en sort, mais c’est loin d’être confort.

Et du coup, ça se présente comme ça :

{{ video(src="static/2025/08/esp32_tactile_activity.mp4", autoplay=false) }}

Et si comme moi, tu t’es posé la question : non, je n’ai pas trouvé d’émulateur correct pour ce truc. J’aurais bien testé sans acheter de matériel, mais malheureusement, ça n’a pas été possible.

Tout est évidemment disponible [là](https://giteu.be/home_assitant/consonance/src/branch/main/esphome/esp32cc.yaml) si tu veux y jeter un œil. Il y a quelques astuces à connaître, mais au final, quand on a compris comment fonctionne ESPHome, ça va relativement vite à construire.

# Évaluation de l’ensemble

C’est pas tout de construire un frontend, encore faut-il l’éprouver.

Et donc, ça marche dans l’ensemble pas trop mal. Avec un peu d’expérience, on se rend vite compte qu’il vaut mieux utiliser le widget [button matrix](https://esphome.io/components/lvgl/widgets.html#buttonmatrix) plutôt que des boutons à placer. On finit par comprendre la logique pour placer des boutons les uns par rapport aux autres, etc… Ça ressemble beaucoup à du CSS au final, où l’on place les choses les unes par rapport aux autres et on indique des centrages, des tailles, des tailles relatives, etc…

Sincèrement, je trouve que le système, même s’il n’est pas parfait, permet quand même de faire des choses assez impressionantes. LVGL permet vraiment de construire des interfaces relativement complexes avec des onglets, des pages, des boutons, des visualiseurs, etc… J’imagine qu’on pourrait très facilement y faire de petites interfaces de contrôle pour le chauffage, pour un EVSE ou plein d’autres choses.

Mais est-ce que ça marche correctement pour une télécommande ? Et bien, fonctionnellement, c’est pas mal : ça donne une interface qu’on peut personnaliser très facilement et avoir un truc assez minimaliste pour certaines activités et très chargé pour d’autres activités. Typiquement, mon activité « Nintendo Switch 2 » ne contient que guère que le bandeau de volume que tu as pu voir précédemment. Parce qu’il n’y a pas grand-chose de plus de nécessaire. Mon activtité « Blu-Ray » contient un cluster média et un cluster de navigation.

Et c’est là qu’on voit le premier problème : les boutons ne sont pas toujours placés au même endroit à l’écran, en dehors du bandeau du haut, en fonction de l’activité. J’ai essayé de garder un peu de cohérence en plaçant par exemple toujours le cluster de navigation en haut de l’écran, mais il n’empêche : c’est pas toujours tout au même endroit.

Cela veut dire qu’on est souvent obligé de **regarder** l’écran pour trouver le bouton qu’on cherche. Au bout de quelques heures, on n’a effectivement un peu moins besoin de le faire, mais dans la pratique, je trouve qu’on regarder très souvent l’écran : d’abord parce que les boutons ne sont pas tous au même endroit et ensuite parce qu’on n’a pas vraiment de retour tactile des boutons, c’est juste un écran.

Ce qui m’amène au second défaut : **il n’y a pas de retour haptique et évidemment pas de sensation tactile**. Quand on démarre ce genre de choses, on se dit que l’écran tactile, c’est parfait parce que ça permet de construire n’importe quelle interface et de faire un peu n’importe quoi. On n’est pas obligé de mettre un bouton « Enregistrer » si on n’en a pas besoin. On n’est pas obligé d’utiliser un bouton aléatoire pour une fonction particulière. **On peut concevoir chaque bouton précisément pour ce qu’on a besoin.**

Mais c’est oublier un peu vite qu’on n’a pas l’écran sous les yeux en permanence. Quand tu utilises ton téléphone, tu vois à la fois l’interface (les boutons, les coches, etc…) et ce que tu es en train de manipuler. Quand tu utilises une télécommande, tu regardes généralement ton moniteur, pas la télécommande.

Ça revient au final au même problème que la WiiU : quand tu joues sur la télé, si tu dois baisser les yeux pour aller chercher une commande sur l’écran tactile, c’est plus long, tu interromps ton activité, tu es obligé de refocaliser tes yeux sur autre choses, plus proche, puis de revenir à ton activité, et de refocaliser tes yeux.

Donc au final, efficace oui, ergonomique moyen.

# Alternatives

Alors qu’est-ce qu’on peut faire d’autres ? On a vu que finalement un écran, aussi tactile soit-il, n’est pas forcément l’alpha et l’oméga. C’est peut-être aussi pour ça que la plupart des télécommandes Logitech Harmony ont un écran tactile mais pour des commandes additionnelles, pour des choses spécifiques, pas pour des fonctions que l’on doit accéder souvent.

On pourrait donc imaginer d’utiliser un clavier sans fil par exemple : en réécrivant les labels sur les touches et avec un peu d’habitude, on pourrait facilement convertir un petit clavier, avec ou sans pavé numérique, en télécommande. Ça donnerait rapidement quelque chose d’utilisable. On pourrait par exemple imaginer de mettre tout le cluster média sur le bas du clavier :
* Espace pour lecture (ou lecture pause)
* Pause sur Alt Gr
* Stop sur Alt
* Super Gauche pour Précédent
* Super Droite pour Suivant
* Ctrl Gauche pour Rembobiner
* Ctrl Droit pour Avancer

Et voilà, boum, les 7 touches essentielles pour contrôler les médias, toutes sur la même ligne et assez facile à « apprendre » avec les mains. Bon après, un clavier, c’est très encombrant, donc ça peut être une solution, mais ça reste un peu bizarre.

La seconde solution, ce serait simplement de se servir d’un *dashboard* Home Assistant. L’avantage, c’est que ça fonctionne déjà sorti de la boîte et qu’on peut faire quand même beaucoup de choses dans un *dashboard*. Le problème, c’est que ça oblige à avoir un navigateur ouvert en permanence. Ça pourrait se faire avec un petit écran tactile pour Raspberry Pi par exemple, mais on reviendrait au même problème que précédemment : c’est de nouveau un écran tactile. Et quand au fait d’être obligé d’utiliser son téléphone pour tout faire, c’est moyen pour les invités ou pour les enfants. Ou pour quand t’as la tête dans le cul.

La troisième solution, ce serait de construire soi-même une télécommande. [Certains l’ont fait](https://www.thestockpot.net/videos/theeverythingremote) et le résultat est plus ou moins disponible pour être réutilisé par n’importe qui.

De base, ça donne une télécommande assez minimaliste (peut-être trop), mais ça peut donner des idées… Des idées intéressantes…

# Conclusement

Voilà, dans cette partie, nous avons vu comment construire une interface graphique avec ESPHome et LVGL et comment on pouvait s’en servir pour faire une télécommande. Je suis conscient que le système est loin d’être parfait : il envoie des commandes directes à Home Assistant là où il devrait plutôt envoyer des signaux ; il est 100% tactile ce qui pose des problèmes d’ergonomie à l’utilisation.

Mais voilà, il faut bien le dire : ça marche. Ça peut remplacer une télécommande Harmony qui n’est plus supportée ou qui est tombée en panne. Pour une poignée d’euros (20 pour le *blaster IR* et 20 pour l’écran tactile), on peut reconstruire un système de commande utilisable par n’importe qui.

Mais j’ai envie d’aller plus loin. Alors, je vais aller plus loin.
