Showcase: un petit écran météo dans la cuisine

À la maison, il y avait une question qui revenait souvent:

« Il fait combien dehors? »

Pas une question compliquée. Pas un gros problème d’infrastructure. Juste une vraie petite question de tous les jours, posée plusieurs fois par jour par ma conjointe.

Oui, on peut regarder sur son téléphone. Oui, on peut demander à un assistant vocal. Oui, on peut ouvrir une application météo avec des pubs, du tracking, un compte utilisateur, trois popups et une prédiction météo d’un serveur on-ne-sait-où.

Mais ça m’a donné envie de faire quelque chose de plus simple: un petit écran dans la cuisine qui affiche directement l’information utile.

Un genre de mini-dashboard maison.

Le besoin réel

Le but n’était pas de faire un projet compliqué pour le plaisir de le compliquer.

Le besoin était plutôt:

• voir rapidement la température extérieure;
• ne pas avoir à sortir son téléphone;
• avoir l’information à un endroit logique, dans la cuisine;
• garder le tout simple, local et fiable;
• éviter que l’écran reste allumé 24/7 pour rien.

C’est un détail, mais c’est souvent comme ça que les bons petits projets commencent. Quelqu’un répète une question assez souvent, et on finit par se dire: « il y aurait probablement une meilleure façon de faire ça ».

Le matériel

Le projet roule sur un Raspberry Pi 4B avec un petit écran tactile DSI de 800×480.

L’écran est prévu pour rester sur le comptoir de cuisine, pas pour être un poste de travail. Donc je n’avais pas besoin d’un environnement desktop complet avec mille options. Je voulais quelque chose qui démarre, affiche la bonne page, et se fait oublier.

J’ai aussi ajouté un capteur de présence HLK-LD2410C, un petit capteur mmWave capable de détecter la présence dans la pièce.

L’idée est simple:

• quelqu’un arrive dans la cuisine: l’écran s’allume;
• il n’y a plus personne: on attend un peu, puis l’écran s’éteint;
• le Raspberry Pi reste allumé en arrière-plan.

Ce n’est donc pas un système de veille complet du Pi. Je coupe seulement le rétroéclairage de l’écran.

Un petit extra: Spotify dans la cuisine

Tant qu’à avoir un Raspberry Pi avec un haut-parleur dans la cuisine, j’ai aussi installé Raspotify, un client Spotify Connect.

Ça transforme le Pi en sortie audio disponible dans Spotify. N’importe qui à la maison peut donc choisir l’appareil dans l’application Spotify et envoyer de la musique sur le haut-parleur de la machine.

Ce n’était pas le but principal du projet, mais c’est le genre de petit bonus qui rend l’installation plus utile au quotidien. L’écran donne la météo, et la même boîte peut aussi servir pour mettre de la musique pendant qu’on cuisine.

Un bouton pour les lumières

J’ai aussi ajouté un bouton dans l’interface, dans le coin droit de l’écran, pour allumer les lumières de la cuisine via Home Assistant.

C’est un autre petit détail, mais il suit la même logique: si l’écran est déjà là, autant qu’il serve à autre chose qu’afficher un chiffre. Pas besoin de sortir le téléphone, pas besoin d’ouvrir une application, pas besoin de chercher le bon interrupteur intelligent. Un bouton visible, une action utile.

C’est aussi une bonne démonstration de ce que j’aime avec l’autohébergement et la domotique locale: on peut adapter l’interface à la vraie vie de la maison, au lieu de seulement accepter ce qu’une application commerciale veut bien offrir.

Pourquoi ne pas juste laisser l’écran allumé?

Je pourrais. Ce serait plus simple.

Mais un écran qui reste allumé toute la journée, ça use inutilement le rétroéclairage. Ça consomme un peu plus. Et, honnêtement, dans une cuisine, ce n’est pas nécessaire d’avoir une petite lumière permanente quand personne n’est là.

Je voulais que le comportement soit naturel:

• on entre dans la pièce, l’information est là;
• on quitte, l’écran disparaît après un délai raisonnable.

Le délai est important. Si l’écran s’éteint dès qu’on bouge moins, ça devient irritant. J’ai donc choisi une logique du genre: présence détectée = allumage immédiat; absence continue pendant environ 60 secondes = extinction.

Le navigateur: pas besoin de Chromium pour ça

Au départ, on pourrait penser à lancer Chromium en mode kiosk. C’est souvent la solution facile pour afficher une page web sur un Raspberry Pi.

Mais pour ce projet, Chromium me semblait beaucoup trop gros. Dans mes tests initiaux, lancer Chromium semblait hardu; ça prenait environ 20 secondes avant de voir l’interface principale, et quelques secondes supplémentaires avant que Chromium puisse se connecter à mon site web d’affichage météo.

Je voulais afficher une seule page locale, sans onglets, sans barre d’adresse, sans extensions, sans fonctionnalités de navigateur complet. Juste une fenêtre plein écran qui charge la page météo.

J’ai donc fait un petit navigateur minimal en Python avec GTK et WebKitGTK. Il ouvre la page météo, démarre en plein écran et garde quelques raccourcis pratiques pour le dépannage.

Ce n’est pas un navigateur généraliste. C’est volontairement limité. Et c’est exactement ce que je voulais.

Le capteur de présence

Le capteur LD2410C donne une sortie simple: présence ou pas présence.

C’est pratique, mais il y a un piège: si le capteur est débranché ou ne répond plus, une lecture « pas de présence » peut ressembler à une vraie absence.

Autrement dit:

Est-ce que la cuisine est vide, ou est-ce que le capteur est mort?

Pour éviter ce faux positif, j’utilise aussi le port série du capteur. Le module envoie régulièrement des données sur son interface UART. Si ces données arrivent, je sais que le capteur est vivant. Si je ne reçois plus rien, je ne fais plus confiance à son état.

Dans ce cas-là, le choix est volontairement conservateur: l’écran reste allumé.

C’est ce qu’on appelle souvent un comportement fail open. Pour ce projet, c’est le bon choix. Si le capteur brise, je préfère avoir un écran qui reste allumé plutôt qu’un écran impossible à réveiller.

Éteindre le bon morceau

Sur ce type d’écran DSI, les commandes classiques comme xset dpms force off ne fonctionnent pas nécessairement. Le serveur X11 ne voit pas toujours l’écran comme un moniteur standard avec gestion DPMS.

La bonne interface, dans mon cas, était exposée par Linux ici:

/sys/class/backlight/10-0045/bl_power

En écrivant la bonne valeur dans ce fichier, je peux allumer ou éteindre le rétroéclairage.

C’est très Linux comme approche: pas très glamour, mais direct, simple et fiable.

J’aime ce genre de solution parce qu’elle dépend moins de l’environnement graphique. Que je sois en X11, en Wayland ou connecté en SSH, le contrôle du backlight reste un mécanisme du noyau Linux.

Survivre aux pannes de courant

J’ai aussi activé le filesystem overlay de Raspberry Pi OS.

L’idée est de rendre le système plus tolérant aux coupures de courant et aux redémarrages pas très propres. Sur un appareil de comptoir, je veux éviter qu’une panne électrique ou quelqu’un qui tire le mauvais fil corrompe la carte SD et transforme un petit projet pratique en séance de dépannage non prévue.

Est-ce que ça rend la machine indestructible? Non. Mais en théorie, ça devrait aider à garder le système dans un état plus stable. Et pour un appareil qui doit surtout démarrer, afficher une page et jouer de la musique, c’est un compromis raisonnable.

… et j’ai des backups du disque entier juste au cas :)

Pourquoi X11?

Les versions récentes de Raspberry Pi OS poussent davantage vers Wayland, et c’est correct pour plusieurs usages.

Dans mon cas, j’ai volontairement choisi de revenir à X11 pour avoir un environnement léger et prévisible, proche d’un mode kiosk. Ça me permettait aussi d’accéder à l’interface graphique via Meshcentral pour fins de déboguage en cas de pépins. Cette fonctionnalité est disponible seulement avec X11 et pas avec Wayland.

Ce que ce projet montre vraiment

À première vue, c’est juste un petit écran météo dans une cuisine.

Mais côté sysadmin, il y a plusieurs décisions intéressantes derrière:

• partir d’un vrai besoin utilisateur;
• choisir une solution légère plutôt qu’un gros navigateur complet;
• contrôler le matériel via les interfaces Linux appropriées;
• penser aux permissions au lieu de tout lancer en administrateur;
• prévoir le comportement en cas de panne du capteur;
• ajouter un contrôle simple pour les lumières via Home Assistant;
• réutiliser le Pi comme client Spotify Connect avec Raspotify;
• protéger un peu mieux le système avec un filesystem overlay;
• garder le système simple à démarrer et à dépanner;
• faire un projet local, utile, et pas dépendant d’une plateforme fermée.

C’est le genre de projet que j’aime: petit, concret, mais avec assez de détails pour apprendre quelque chose.

Ce que j’aime dans cette approche

J’aime beaucoup quand la technologie devient presque invisible.

Si ma conjointe passe devant l’écran, voit la température, allume les lumières de la cuisine au besoin, part de la musique, puis continue sa journée sans penser au Raspberry Pi, au capteur mmWave, à WebKitGTK, au GPIO ou à /sys/class/backlight, c’est réussi.

Le but n’est pas que tout le monde admire l’architecture. Le but est que le système rende service.

Et si, en plus, ça me permet de pratiquer du Linux embarqué, du kiosk léger, des permissions système, de l’autostart desktop et un peu de logique de capteur, c’est encore mieux.

Conclusion

Ce projet est né d’une question très simple: « il fait combien dehors? »

La réponse aurait pu être une application météo. À la place, c’est devenu un petit affichage local sur Raspberry Pi, pensé pour la cuisine, qui s’allume seulement quand quelqu’un est là, peut contrôler les lumières et peut servir de haut-parleur Spotify Connect.

Ce n’est pas une grosse infrastructure. Ce n’est pas révolutionnaire. Mais c’est utile, compréhensible, maintenable, et adapté aux personnes qui l’utilisent.

Pour moi, c’est souvent ça le bon sysadmin: pas seulement faire fonctionner des serveurs, mais comprendre le besoin, choisir une solution raisonnable, prévoir les pannes possibles, et laisser quelque chose de fiable derrière soi.