Compare commits
1 Commits
tamerelol
...
6d59bdf25d
Author | SHA1 | Date | |
---|---|---|---|
![]() |
6d59bdf25d |
@@ -2,25 +2,11 @@
|
||||
name: release
|
||||
|
||||
on:
|
||||
push:
|
||||
tags:
|
||||
- '*'
|
||||
- push
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
zola-builder:
|
||||
container:
|
||||
image: jauderho/zola
|
||||
steps:
|
||||
- name: Checkout main
|
||||
uses: actions/checkout@v4
|
||||
- name: Build only
|
||||
uses: shalzz/zola-deploy-action@v0.20.0
|
||||
env:
|
||||
BUILD_ONLY: true
|
||||
- name: Create archive
|
||||
run: tar -czf public.tar.gz public/
|
||||
- name: Create release
|
||||
uses: https://gitea.com/actions/gitea-release-action@v1
|
||||
with:
|
||||
files: |-
|
||||
public.tar.gz
|
||||
api_key: '${{secrets.RELEASE_TOKEN}}'
|
||||
- run: build
|
||||
|
@@ -173,7 +173,7 @@ Conclusion de la conclusion : ça peut être interéssant de désactiver compl
|
||||
|
||||
Pour cela, on pourra ajouter les lignes suivantes dans le `/etc/rc.local` :
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sysctl net.ipv4.conf.all.forwarding=0
|
||||
sysctl net.ipv6.conf.all.forwarding=0
|
||||
```
|
||||
|
@@ -44,7 +44,7 @@ En toute logique, c’est un cas assez standard et plutôt simple à mettre en
|
||||
|
||||
Donc côté « client », on peut donc commencer par un `main.cf` de ce type :
|
||||
|
||||
```conf
|
||||
```postfix
|
||||
# des trucs génériques dont on se fout un peu
|
||||
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
|
||||
biff = no
|
||||
@@ -77,7 +77,7 @@ smtpd_relay_restrictions = permit_mynetworks,defer_unauth_destination,reject
|
||||
|
||||
Et donc effectivement, toute la magie tient dans les variables `smtp_sasl_*` et notamment le fichier `/etc/postfix/sasl_passwd`, qui contient l’utilisateur/mot de passe pour le serveur SMTP :
|
||||
|
||||
```conf
|
||||
```postfix
|
||||
[smtp.buttse.cx]:587 utilisateur:mot_de_passe
|
||||
```
|
||||
|
||||
@@ -95,7 +95,7 @@ Du coup, il va falloir ruser pour convaincre *Postfix* de faire comme d’habitu
|
||||
|
||||
Sous Debian/Ubuntu, tu peux donc installer le paquet `stunnel4` et faire une petite configuration de ce type, dans `/etc/stunnel/smtp-wrapper.conf` :
|
||||
|
||||
```conf
|
||||
```stunnel
|
||||
[smtp-tls-wrapper]
|
||||
accept = 10465
|
||||
client = yes
|
||||
@@ -104,13 +104,13 @@ connect = smtp.tem.buttse.cx:465
|
||||
|
||||
Et du coup, lorsque l’on démarre le service `stunnel4`, on voit effectivement qu’il écoute sur le port 10465. Il suffit alors de reconfigurer notre petit *Postfix* comme suit pour s’adapter :
|
||||
|
||||
```conf
|
||||
```postfix
|
||||
relayhost = [localhost]:10465
|
||||
```
|
||||
|
||||
Et évidemment, changer également le login/pass/host dans `/etc/postfix/sasl_passwd` :
|
||||
|
||||
```conf
|
||||
```sasl_passwd
|
||||
[localhost]:10465 login:pass
|
||||
```
|
||||
|
||||
@@ -122,13 +122,13 @@ Quand il s’agit de *cron*, le service a tendance à envoyer les messages à l
|
||||
|
||||
Pour cela, on peut forcer *Postfix* à faire une réécriture de tous les messages de destination pour les envoyer ailleurs. Ce n’est pas bien compliqué, il suffit d’ajouter la ligne suivante dans le `main.cf` :
|
||||
|
||||
```conf
|
||||
```postfix
|
||||
recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical
|
||||
```
|
||||
|
||||
Et le fichier `/etc/postfix/recipient_canonical` se présentera comme suit :
|
||||
|
||||
```conf
|
||||
```postfix
|
||||
/.+/ admin@buttse.cx
|
||||
```
|
||||
|
||||
@@ -146,7 +146,7 @@ Heureusement, encore une fois *Postfix* à la rescousse ! On peut aussi forcer
|
||||
|
||||
Pour cela, il va falloir ajouter quelques lignes dans notre `main.cf` :
|
||||
|
||||
```conf
|
||||
```postfix
|
||||
sender_canonical_classes = envelope_sender, header_sender
|
||||
sender_canonical_maps = regexp:/etc/postfix/sender_canonical_maps
|
||||
smtp_header_checks = regexp:/etc/postfix/header_check
|
||||
@@ -154,7 +154,7 @@ smtp_header_checks = regexp:/etc/postfix/header_check
|
||||
|
||||
Et on produit donc les deux *maps* permettant de changer les deux entêtes à la fois dans `/etc/postfix/sender_canonical_maps` et `/etc/postfix/header_check` (c’est exactement le même fichier) :
|
||||
|
||||
```conf
|
||||
```postfix
|
||||
/.+/ youplaboom@mondomainesour.ce
|
||||
```
|
||||
|
||||
|
@@ -5,7 +5,7 @@ date = 2023-12-08
|
||||
tags = [ "truenas", "minio", "s3", "sysadmin", "système" ]
|
||||
+++
|
||||
|
||||
> La mauvaise doc, tu la lis… tu comprends rien ! La bonne doc, tu la lis… bon tu comprends rien non plus, mais c’est une bonne doc !
|
||||
> La mauvaise doc, tu la lis… tu comprends rien ! La bonne doc, tu la lis… bon tu comprends rien non plus, mas c’est une bonne doc !
|
||||
|
||||
<!-- more -->
|
||||
|
||||
|
@@ -1,131 +0,0 @@
|
||||
+++
|
||||
title = "Home Assistant : Projet Consonance"
|
||||
date = 2025-07-18
|
||||
[taxonomies]
|
||||
tags = [ "système", "home assistant", "infrarouge", "logitech harmony", "consonance" ]
|
||||
+++
|
||||
|
||||
> « Hail to the King, baby! »
|
||||
|
||||
*Duke Nukem ou quelque chose, je sais pas, j’ai pas joué au jeu*
|
||||
|
||||
<!-- more -->
|
||||
|
||||
# Le roi est mort, vive… ah attendez…
|
||||
|
||||
Pour ceux qui ne seraient pas au courant, [Logitech](https://www.logitech.com/fr-fr) a annoncé, il y a déjà quelques années, que les télécommandes de la série [Harmony](https://www.myharmony.com/fr-fr/) s’arrêtait.
|
||||
|
||||
Non seulement, Logitech ne va plus les vendre, mais en plus, **les serveurs seront éteints courant de l’année 2025**. Or, nous sommes courant de l’année 2025 et certains serveurs sont effectivement déjà éteints, notamment celui de [l’application historique de Logitech](https://members.harmonyremote.com/EasyZapper/) sur lequel s’appuyait notamment le projet [Concordance](https://github.com/jaymzh/concordance) qui permettait aux utilisateurs de Linux de mettre à jour leur télécommande.
|
||||
|
||||
L’application Windows, écrite avec [Microsoft Silverlight](https://fr.wikipedia.org/wiki/Silverlight), non, non, ce n’est pas une blague, continue de fonctionner mais avec un nombre de télécommandes bien plus limitées et pour un temps probablement lui aussi très limité.
|
||||
|
||||
L’arrêt de serveurs ne transforme pas instantannément toutes les télécommandes Harmony en presse-papier. Elles ont été conçues au début des annnées 2000, période à laquelle il n’était pas forcément possible que tout appareil puisse être connecté.
|
||||
|
||||
Autrement dit, si tu as une télécommande Harmony, la bonne nouvelle c’est qu’elle fonctionne toujours. La mauvaise, c’est que si tu dois y effectuer le moindre changement, ajouter un appareil ou modifier une commande, et bien tu l’as dans l’os.
|
||||
|
||||
# Les alternatives
|
||||
|
||||
L’arrêt ayant été annoncé en 2021, tu pourrais penser que des concurrents reprennent le flambeau. Et bien malheureusement, ça ne se passe pas tout-à-fait comme ça… Je te propose de jeter un petit coup d’œil à ce qui pourrait remplacer une télécommande Harmony en 2025.
|
||||
|
||||
## HDMI CEC
|
||||
|
||||
Le concurrent n°1, c’est évidemment… la norme HDMI elle-même ! Nous sommes en 2025 et la plupart des gens ont des appareils connectés de manière numérique et utilisant une norme permettant le transfert de l’image, du son **et des commandes**.
|
||||
|
||||
Ça s’appelle le [HDMI CEC](https://fr.wikipedia.org/wiki/Consumer_Electronics_Control) et, tant qu’on ne lui en demande pas trop, ça « marche ». Alors soyons très clair, si t’as effectivement une télévision, une barre de son, une Nintendo Switch et un boîtier TV quelconque, ça marche.
|
||||
|
||||
Par contre, dès que tu commences à intégrer des appareils n’ayant pas de CEC, ou simplement que ton installation est plus compliquée que cela et bien ça merde dans les grandes largeurs. Le CEC a été conçu pour des cas simples avec des appareils à fonctions bien définies et uniques. Dès que l’on rajoute ne serait-ce qu’un Switch HDMI, ça commence généralement à partir en couille.
|
||||
|
||||
Sans compter le fait qu’il est toujours compliqué de déterminer qui allume qui, qui éteint qui, etc…
|
||||
|
||||
Bref, je pense que c’est **la raison** qui fait que Logitech a abandonné les télécommandes Harmony : avec le CEC, pour 90% des usages, c’est largement suffisant, sa télécommande ne se justifiait plus que pour un marché de niche, voire d’ultra-niche. Mais il n’empêche que pour les gens qui ont besoin de contrôler plus de choses, le CEC est plus un cauchemar qu’autre chose.
|
||||
|
||||
## SofaBaton
|
||||
|
||||
Présenté par certains comme **LA** solution à la défection de Logitech, [Sofabaton](https://www.sofabaton.com/), malgré son nom ridicule, est effectivement un sérieux concurrent. Une télécommande qui a l’air bien foutue, une liste de compatibilité longue comme… enfin une très longue liste, et un appareil qui lui-même semble plutôt costaud et sympathique à utiliser.
|
||||
|
||||
Sofabaton présente aussi l’avantage de proposer un hub, façon [Harmony Hub](https://support.myharmony.com/fr-fr/hub) sur certains modèles. Le hub, c’est un truc à la con, mais quand on commande des appareils infrarouge, il faut obligatoirement avoir une ligne de vue vers les appareils en question. En fonction de comment est organisé ton salon et tes appareils, ça peut éventuellement être compliqué d’avoir systématiquement **tout** en ligne de mire pour lancer une commande. Donc on retiendra que le Hub, c’est plutôt une bonne idée dans l’absolu, surtout qu’il dispose de sorties infrarouge supplémentaires au cas où.
|
||||
|
||||
Par contre, toutes les Sofabaton ne naissent pas égales. Les modèles [U2](https://www.sofabaton.com/products/u2/) ne fonctionnent pas ainsi selon le principe d’Activités qui a rendu les Logitech Harmony célèbres : tu appuies sur le bouton DVD, ça allume télé, les enceintes, l’ampli, le lecteur DVD lui-même et ça met toutes les bonnes entrées sur tout ce petit monde. Sans cela, et bien on a juste regroupé toutes les télécommandes en une, mais on n’a pas vraiment simplifié la façon de fonctionner de l’ensemble. Fort heureusement, les X1 et [X1S](https://www.sofabaton.com/products/x1s/) corrige le tir en prévoyant un fonctionnement par activité.
|
||||
|
||||
Autre problème : le prix. Quelques fois disponibles pour un peu moins de 200€, bah ça fait quand même 200€. Alors certes, les télécommandes Harmony ont toujours été assez chères aussi. En prenant compte de l’inflation, je pense qu’une Harmony One devait facilement coûter 300€. Mais la proposition de valeur n’est plus tout-à-fait la même aujourd’hui.
|
||||
|
||||
Mais en fait, le vrai gros point noir c’est la configuration. Elle se fait toujours avec une appli, sur mobile cette fois, et cette appli, elle pourrait bien s’arrêter dans quelques années, voire quelques mois. Et j’ai déjà donné, donc non merci…
|
||||
|
||||
## Unfolded Circle Remote Two/3
|
||||
|
||||
[Unfolded Circle](https://www.unfoldedcircle.com/), en dehors d’avoir un nom à coucher dehors, ça a l’air d’être des gens bien. Et leur produit, c’est effectivement un avion de chasse : configuration locale à 100%, plusieurs milliers d’appareils supportés, Bluetooth, gyroscope, *air-mouse*, chargement par induction, etc…
|
||||
|
||||
C’est un truc de gros furieux avec en plus un dock, des relais infrarouges, etc… Et en plus, une API ouverte et plein d’autres trucs. On peut a priori y faire tout et surtout n’importe quoi avec à peu près n’importe quel appareil.
|
||||
|
||||
Le problème… c’est le prix. À 399€, la télécommande seule, 499€ avec le dock, c’est quand même putain de pas donné ! La Rolls Royce des télécommandes, à n’en pas douter, mais clairement une solution bien au-delà de mes moyens pour un truc de ce type.
|
||||
|
||||
# Bricole picole a.k.a. Projet Consonance
|
||||
|
||||

|
||||
|
||||
L’autre alternative. Et bien, c’est Home Assistant.
|
||||
|
||||
En fait, Home Assistant a déjà presque tout ce qu’il faut pour remplacer une télécommande Harmony : des scripts, des entités virtuelles et des intégrations de folie. On peut déjà y coller une TV connectée si on le souhaite, un Kodi, un Nvidia Shield, etc…
|
||||
|
||||
Donc en théorie, on peut déjà contrôler pas mal de trucs si on fait exception de tout ce qui est infrarouge.
|
||||
|
||||
## Blaste cet infrarouge !
|
||||
|
||||
Mais il se trouve qu’on peut aussi y coller un *IR Blaster*. C’est un petit appareil dont la seule utilité est de balancer des éléments infrarouge qu’on lui aura précédemment appris. Il en existe de nombreux : connecté à une application ou pas, en Zigbee, en Z-Wave, sur pile, sur batterie, etc… C’est presque sûr qu’on peut trouver de quoi faire son bonheur. Personnellement, j’ai opté pour le [Broadlink RM4 Pro](https://ebroadlink.com/products/universal-remote-rm4-pro).
|
||||
|
||||
Il vient avec une application qui permet de faire le premier paramétrage et après… on peut l’en détacher complètement et s’en servir directement dans Home Assitant. Il est en Wi-Fi et prend deux commandes très simple : `learn_command` pour apprendre une commande existante et `send_command` pour envoyer une commande existante.
|
||||
|
||||
Alors effectivement, quand on le déconnecte de son appli, il faut se taper l’apprentissage de toutes les commandes via les télécommandes d’origine ou via la Logitech Harmony encore opérationnelle. Mais l’intérêt derrière, c’est que c’est un simple fichier JSON avec des informations assez simple : quel appareil, quelle commande, quel signal.
|
||||
|
||||
Donc changer d’appareil pour envoyer des commandes, rien de plus simple en réalité.
|
||||
|
||||
Une fois le RM4 Pro intégré dans Home Assistant, via l’intégration Broadlink, l’apprentissage se fait en passant par le menu `Outils de développement`, dans `Actions`.
|
||||
|
||||
Voici un exemple :
|
||||
|
||||

|
||||
|
||||
C’est un peu pénible à faire, mais j’en ai eu pour à peu près une heure pour rentrer 5 télécommandes. Le plus relou restant les commandes qui n’existent pas sur la télécommande d’origine. Par exemple, ma télévision LG OLED peut aller directement sur la bonne entrée (`HDMI1`, `HDMI2`, etc…) mais ce n’est pas une touche en accès direct. Il a donc fallu que je repasse par ma Logitech Harmony pour apprendre tout ça au Broadlink.
|
||||
|
||||
## Scripts
|
||||
|
||||
Maintenant qu’on a appris toutes les commandes, il reste à voir commander les ordonnancer proprement pour chaque activité. Et là, un second problème pointe son nez : quand on fait de l’infrarouge, on ne peut pas vraiment savoir si l’appareil a reçu la commande correctement ou non : on blaste les commandes suffisamment fort en espérant que ça passe.
|
||||
|
||||

|
||||
|
||||
Et le second souci à coupler à ce premier : la plupart des appareils infrarouge ont un seul et unique bouton pour allumer et éteindre. C’est un `power_toggle`. Il est assez rare d’avoir une commande d’allumage et une commande d’extinction. Cela veut dire que l’on doit mémoriser quelque part l’état de l’appareil histoire de ne pas tout éteindre/tout allumer aléatoirement tout le temps.
|
||||
|
||||
> Note : l’intégration Broadlink comprend une notion de [communateur (switch)](https://www.home-assistant.io/integrations/broadlink/#setting-up-custom-irrf-switches) qui permet de créer des interrupteurs virtuels. Si on possède effectivement une commande d’allumage et une commande d’extinction, ça marche plutôt bien. Malheureusement, c’est rarement le cas.
|
||||
|
||||
Pour ce faire, j’ai créé des entités virtuelles représentant les différents appareils que je souhaite contrôler. Ce sont des simples interrupteurs (*on/off*) mais on pourrait imaginer de stocker plus d’informations que cela (par exemple la dernière entrée d’un appareil).
|
||||
|
||||
Donc dans `Paramètres` > `Appareils et services` > `Entrées`, j’ai créé les 6 appareil contrôlés en infrarouge. Pour des raisons pratiques, je vais considérer que Kodi est contrôlé via son API (ce sera bien plus simple). Je leur ai tous donné une zolie icône et mis dans une catégorie `Consonance`, puisque ce sera le nom de ce projet. Concrètement, ça donne ça :
|
||||
|
||||

|
||||
|
||||
Partant de là, c’est relativement simple : un script pour chaque activité et un script d’extinction. Pour l’instant, je ne souhaite pas compliquer les choses en permettant de passer d’une activité à une autre, comme mon Harmony savait le faire. Cela pourra venir plus tard, ce n’est pas particulièrement complexe à faire, ça demande juste un peu plus de temps pour pas grand-chose.
|
||||
|
||||
Dans le script d’activité :
|
||||
* on envoie la commande `power_toggle` tous les appareils qui vont bien (TV, enceintes, etc…)
|
||||
* on allume toutes les entrées logiques correspondantes pour garder la mémoire de ce qui est allumé
|
||||
* on attend (5 secondes en général)
|
||||
* on envoie toutes les commandes d’entrée qui vont bien sur les appareils allumés
|
||||
|
||||
Et boum ! On a une activité qui roule. Plus l’activité implique d’appareils, plus les temps d’attente vont varier, mais ce n’est pas beaucoup plus lourd que ça à gérer.
|
||||
|
||||
Pour l’extinction générale pareil, assez simple, pour chaque entrée logique :
|
||||
* on vérifie si elle est allumé
|
||||
* on envoie la commande `power_toggle`
|
||||
* on éteint l’entrée logique
|
||||
|
||||
Avec le langage de script d’Home Assistant, il est difficile de faire des boucles, mais on peut faire des groupes ou traiter tous les appareils indépendamment. On pourrait donc très bien imaginer mettre les appareils dans un groupe ou une catégorie en fonction de l’activité et simplement s’appuyer là-dessus pour gérer la partie interrupteur virtuelle.
|
||||
|
||||
Si l’on veut éviter le gros gloubiboulga en basculant d’une activité à l’autre, on peut forcer le passage par le script d’extinction. Pour cela, il suffit de rajouter une autre entrée logique permettant de dire qu’un activité est en cours (ou prendre une entrée logique existant dont on sait qu’elle est toujours allumée) et d’ajouter une condition au début de l’exécution de chaque script d’activité pour arrêter sa propre exécution si l’entrée logique en question est *on*. Ça rajoute encore une petite couche de logique un peu reloue à gérer, mais c’est le prix à payer.
|
||||
|
||||
Si l’on souhaitait éviter ce comportement et passer d’une activité à une autre en passant par les mêmes scripts, il faudrait revenir à ce que l’on disait plus haut : grouper les interrupteurs virtuels pour garder un état cohérent.
|
||||
|
||||
Sachant que, de toutes manières, on ne pourra jamais vraiment avoir l’état complet du système… tout comme avec les Logitech Harmony !
|
||||
|
||||
# Conclusage
|
||||
|
||||
Là, on a plutôt fait la partie arrière-boutique. La prochaine fois, on verra comment interagir avec Home Assistant pour tout contrôler. En attendant, je te laisse avec [le repo qui va bien](https://giteu.be/home_assitant/consonance) si tu veux repomper le truc ou t’inspirer.
|
@@ -1,131 +0,0 @@
|
||||
+++
|
||||
title = "Home Assistant : Projet Consonance, l’avant-boutique"
|
||||
date = 2025-08-19
|
||||
[taxonomies]
|
||||
tags = [ "système", "home assistant", "infrarouge", "logitech harmony", "consonance" ]
|
||||
+++
|
||||
|
||||

|
||||
|
||||
<!-- 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 :
|
||||
|
||||

|
||||
|
||||
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 controls>
|
||||
<source src="/2025/08/esp32_tactile_activity.mp4" type="video/mp4" />
|
||||
</video>
|
||||
|
||||
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.
|
Binary file not shown.
Before Width: | Height: | Size: 68 KiB |
Binary file not shown.
Before Width: | Height: | Size: 71 KiB |
Binary file not shown.
Before Width: | Height: | Size: 104 KiB |
Binary file not shown.
Before Width: | Height: | Size: 62 KiB |
Binary file not shown.
Before Width: | Height: | Size: 123 KiB |
Binary file not shown.
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
Reference in New Issue
Block a user