Serait-il judicieux d’avoir dans la doc, accessible depuis l’integration MQTT, un descriptif et / ou une image de ce que chaque fonctionnalité va donner niveau UI sur le dashboard ?
Car si je cherche à afficher un slider, il me faut pour le moment deviner que ça s’appelle un variateur, ou bien que c’est dans les lumières, etc…
Si j’avais un visuel du rendu final, ça aiderait au choix de ma fonctionnalité.
C’est une bonne idée ! Là dessus, je pense à 2 choses:
Autre option: Repenser l’écran MQTT pour afficher cette « doc » directement dans l’intégration.
Je pense que pour tout ça vous n’avez pas forcément besoin de mon aide, c’est principalement du contenu à écrire 
@qleg Toi qui fait souvent des PRs pour les traductions, limite si tu veux travailler en concert avec @guim31 sur le sujet !
Moi je veux bien me pencher sur ce que vous voulez, mais je ne sais pas utiliser Github (à part pour écrire des Issues) et je ne sais pas utiliser un environnement de développement.
Pour moi, il serait VRAIMENT une meilleure option d’intégrer cette doc dans l’intégration MQTT. Le lambda (dont je fais partie) ne clique que très rarement sur un lien Documentation dans une page web.
Tu verrais ça comment ?
Là comme ça je sèche un peu, mais je veux bien prendre du temps pour y songer et proposer ! 
Alors j’ai fait très vite fait ce machin, j’avoue que mes compétences m’obligent à du bricolage ^^
L’idée est :
Sur la page de création d’un device MQTT, il n’y aurait plus le champ de recherche de fonctionnalité, mais seulement le bouton :
Lorsque l’on clique sur le bouton, s’affiche alors sous le bouton / dans un modal / autre à définir, un encart qui serait surmonté du fameux champ de recherche, ainsi que le « catalogue » des features, qui pourrait être présenté comme ça :
J’ai pas été hyper exhaustif j’avoue ^^ mais l’idée c’est de voir le nom « générique » de la feature, son rendu sur le dashboard, mais aussi les mots-clés auxquels il est rattaché (à voir si c’est super pertinent de les afficher ou non).
Ainsi quelqu’un qui va commencer à taper temp, va créer un filtre de toutes les features contenant cette chaine, comme dans le fonctionnement actuel, mais verra très rapidement ce qu’il recherche : un capteur de température ? Un variateur ? Un variateur de température de couleur ? un détecteur de tempête ?! 
Voilà pour l’idée globale. A vos avis !
Jaime bien l’idée ! De memoire PG disait :
Les modals je pense que cest a proscrire d’un point de vue utilisateur car pas pratiques.
A voir comment intégrer ce composant catalogue
c’est vrai que ca a de la gueule !!!
Alors ce que je trouverai intéressant, à voir si ça rentre dans les guidelines de Gladys niveau UI, ce serait un système de collapse, pour que ce catalogue s’ouvre en dessous du bouton que l’on vient de cliquer. Je trouve que ça guiderait bien l’utilisateur dans sa démarche de création de device.
C’est pas mal ! J’aime bien l’idée, après comment ça rendrait la partie « search/sélection » de la fonctionnalité ?
Parce que cette partie aura déjà les fonctionnalité déjà créé. En plus, niveau fonctionnalité possibles dans Gladys, on parle de dizaines de possibilités, donc ça risque de faire énorme cette partie
Je suis pas certain de comprendre ta question.
En fait dans ma tête c’est un div qui s’afficherait sous le bouton une fois qu’on a cliqué dessus, disons arbitrairement d’une hauteur de 300px, qui serait donc scrollable (et même si je me plante complètement je dirai en « lazy loading » ? c’est comme ça qu’ont dit les trucs qui se chargent au fur et à mesure du scroll?).
En gros j’imagine que la hauteur de ce cadre devrait permettre d’afficher au moins 1 ligne et demi de fonctionnalités, afin que les gens comprennent qu 'ils peuvent faire défiler.
Ça permet surtout de pas avoir 85 tuiles qui vont faire déborder la page à l’infini.
Je ne vois pas de moyen plus efficace d’avoir tout d’un coup d’oeil et de garder le côté searchable pour aller directement là où l’on veut.
Sur ce sujet, j’ai eu un flash hier soir avant de me coucher et je suis allé faire un croquis à la va-vite :
Bon c’est pas très propre mais au moins j’ai noté mon idée 
L’idée c’est d’avoir des features qui soient collapse par défaut et qui puissent s’ouvrir pour modification.
L’ajout de nouvelles features est dans un nouvel écran avec la même présentation que ce que tu avais proposé @guim31
Je ferais bien un petit whimsical de tout ça, peut-être en fin de semaine dans mon prochain jour Gladys
J’aime bien. Quand tu cliques sur la fonctionnalité à droite, ça t’ouvre le form de création/d’édition ?
J’aime bien ! (si j’ai réussi à lire / comprendre haha)
Ça me semble sympa, à moi aussi.
Est-ce que sur la vue de l’appareil virtuel qui montre toutes les fonctionnalités, il pourrait y avoir des infos (sous forme d’icônes peut-être) qui indique si la fonctionnalité est historisée ou pas, et est un capteur ou pas ?
Je me dis que ce serait une bonne réponse à :
Oui pourquoi pas!
Bon, j’ai bien avancé sur le sujet ce matin
J’ai une première proposition de design à vous présenter: MQTT Virtual devices view
Je détaille ici en quelques captures d’écrans:
Liste plus compact, en liste et sans détailler ce qui est déjà dans la vue d’édition.
Je me suis très largement inspiré de la proposition de @guim31
C’est un premier jet, je suis preneur de retour
L’objectif est ensuite d’itérer, et une fois qu’on est tous d’accord, il faudra faire le design mobile, puis la liste de tous les types d’appareils (pour l’étape n°3), et écrire tous les textes.
Enfin, on pourra passer au développement, mais ce n’est que du frontend, rien de très compliqué, le plus dur est vraiment de se mettre d’accord et de créer tout le contenu.
j’adore 
Avoir un visuel du rendu est vraiment top et le classement par pièces aussi.
Attention pour les min/max et unités qui peuvent être cachés par défaut mais je les mettrai accessible au besoin avec un drop-down (si c’est comme ça qu’on dit dans le jargon).
Petite question : à quoi correspondent tes 96% et 14% dans ton premier screenshot ?
Si ça correspond aux batteries des capteurs (ou interrupteurs sur pile) alors ça indique que ce n’est pas un « appareil virtuel » mais un appareil physique (enfin pour moi).
Par contre les appareils physiques sont uniquement ceux issus de z2m ou je me trompe ?
Je verrais bien juste les icônes des fonctionnalités si ça ne fait pas trop lourd visuellement (avec juste un éclair pour 2 puissances déclarées ou plus par ex).
Premier retour rapide : j’aime beaucoup 
. Je vais regarder à nouveau plus en détail ce soir…
Juste un premier point : j’ai souvent des appareils dans lesquels je configure plusieurs fonctionnalités du même type. Par exemple un appareil ‹ consignes de chauffage › pour lequel j’ai une fonctionnalité’consigne min’, une autre ‹ consigne max ›, une autre ‹ variation de température sur 15 minutes ›,… Donc je pense que dans l’écran 2 il faudrait aussi le nom de chaque fonctionnalité.
Pourquoi pas!
Oui c’est bien la batterie.
Peut-être que le terme « appareil virtuel » n’est pas très clair. C’est juste un appareil que tu as déclaré manuellement dans Gladys et qu’y est géré hors Gladys via un Node-RED ou un script maison. Mais ça peut très bien être un vrai appareil physique
Oui tu te trompes, on a plein d’intégrations dans Gladys, pas juste Zigbee2mqtt.
Le nom est bien affiché pourtant
