Salut à tous, salut @pierre-gilles,
Voici une idée sur laquelle j’aimerais ton avis avant d’aller plus loin : pouvoir composer une carte du tableau de bord à partir de plusieurs éléments (valeurs, jauges, graphiques) choisis parmi n’importe quels appareils de Gladys.
Le constat
Aujourd’hui, un widget = une fonction. Pour suivre une pièce, j’empile par exemple :
- un widget « Température de la pièce » pour la valeur actuelle,
- un widget « Graphique » pour l’historique,
- un widget « Jauge » pour l’humidité.
Ça fait trois cartes, avec chacune son titre, ses marges et son espace vide, pour des informations qui vont ensemble. Sur mobile surtout, on fait vite défiler beaucoup d’écran pour peu d’information.
(Je sais que le widget Graphique affiche déjà la dernière valeur et la variation au-dessus de la courbe : ça couvre le cas le plus simple, mais pas le mélange de plusieurs appareils ou de plusieurs types d’affichage.)
Ce que ça permettrait
Quelques exemples concrets :
- Une pièce en une carte : température et humidité en tuiles, courbe de température sur 24 h en dessous.
- Énergie : jauge de puissance instantanée + graphique de consommation de la semaine.
- Comparaison : deux graphiques côte à côte (température intérieure / extérieure, production / consommation solaire).
- Chauffage : consigne, température mesurée et état de la vanne en tuiles, avec l’historique de la température mesurée.
- Extérieur : quelques valeurs de la station météo + la courbe de pluie.
Pourquoi je ne l’ai pas fait avec une intégration externe
J’ai regardé si les widgets des intégrations externes (Gladys 5.1) pouvaient servir à ça, puisque leur format a déjà presque tout : rangée de tuiles (valeur, jauge), graphique relié à l’historique des appareils, texte…
Mais deux choses l’empêchent, et c’est normal :
- Un widget d’intégration ne peut citer que ses propres appareils. Le cœur ignore tout appareil d’une autre intégration (un graphique qui en cite un est retiré en entier). C’est une isolation voulue, et je la trouve saine.
- Un seul élément principal par carte (graphique, liste ou image), dans un ordre fixé par le cœur : pas de graphiques côte à côte.
Le seul contournement possible serait une intégration qui lirait l’API de Gladys avec une clé d’API pour renvoyer des données « à plat ». Ça fonctionnerait, mais sans temps réel, avec une clé à pleins droits dans un conteneur tiers et contre l’esprit de l’isolation. Je ne veux pas partir là-dessus sans ton avis.
Deux pistes possibles
Piste A — un widget natif « Composite » (ma préférence)
Un nouveau type de widget dans le cœur, dont l’édition consiste à ajouter des blocs :
- blocs possibles : valeur, jauge, graphique (en reprenant les widgets existants) ;
- disposition simple : une ou deux colonnes, les blocs s’empilent dans l’ordre choisi ;
- chaque bloc pointe vers n’importe quelle fonctionnalité d’appareil, via le même sélecteur que les widgets actuels.
Avantages : rien ne sort du cœur, pas de nouvelle question de sécurité, temps réel par websocket comme les autres widgets, et le code des widgets existants peut sans doute être réutilisé en grande partie.
Piste B — autoriser les widgets d’intégration à citer des appareils choisis par l’utilisateur
Un réglage de widget de type « appareil » qui proposerait tous les appareils (et pas seulement ceux de l’intégration). L’utilisateur donnerait son accord explicite, appareil par appareil, au moment de configurer le widget.
Avantage : la communauté pourrait publier toutes sortes de mises en page sans toucher au cœur. Inconvénient : ça ouvre une brèche dans l’isolation, puisqu’une intégration pourrait lire des données qui ne sont pas les siennes. Et ça ne règle pas la limite d’un seul graphique par carte.
Les implications que je vois
- Performance : une carte avec plusieurs graphiques fait autant de requêtes d’historique. Une limite (par exemple 4 blocs, 2 graphiques) garderait les choses raisonnables, surtout sur Raspberry Pi.
- Mobile : deux colonnes côte à côte doivent sans doute repasser en une seule colonne sur petit écran.
- Édition : le formulaire d’un widget composite est plus complexe que celui des autres widgets. Il faut qu’il reste simple à utiliser.
- Maintenance : la piste A ajoute un type de widget à maintenir. La piste B déplace ce travail vers les intégrations mais touche au modèle de sécurité.
- Compatibilité : les deux pistes sont additives. Aucun widget existant ne change.
Mes questions
- Est-ce que le besoin te parle, et est-ce que tu verrais ça dans le cœur ?
- Piste A, piste B, ou autre chose (par exemple, laisser simplement les widgets Graphique et Jauge afficher plusieurs valeurs) ?
- L’isolation des widgets d’intégration est-elle un principe à ne pas toucher ?
Si la piste A te convient, je veux bien me charger de la PR, en suivant tes indications sur le périmètre.
Merci !