J’ai le cas avec une prise double Meross , j’ai 3 devices dans Alexa et ça me va très bien ( 1 général et 1 par prise )
J’ai une multi-prises (avec ports USB) SmartLife/Tuya et 1 device par prise et par port USB
Google Home:
D’accord, dans l’UI, le device feature catégorie seul peut avoir du sens (on est souvent contextualise à une pièce donc à une liste déterminée de device). Ex. “Température” pour afficher “la” feature d’un device qui se trouve dans une pièce. Si il y en avait 2, rien n’empêche de mettre à jour le libellé!
Par contre, dans une scène, il faut pouvoir choisir la bonne feature et donc rajouter le device et la pièce est être très utile… C’est ma demande initiale
PS: cela ne remets pas en question le besoin d’avoir un split d’un device ou autre manière (device_feature.location ?)
Ok merci @VonOx et @Romuald_Pochet, du coup c’est bien ça la solution: splitter ces périphériques en plusieurs device dans Gladys 
Comme ça ça permet effectivement:
- De bien différencier ces appareils dans Gladys
- De pouvoir placer chaque prise dans une pièce différente (pas possible si on ne les splitte pas)
- De gérer la compatibilité avec Google Home / Alexa, car sinon ça ne marchera pas pour ces devices
1 « J'aime »
Possible de rajouter Xiaomi dans la boucle car j’ai les soucis avec mes doubles interrupteurs ou je ne pas dissocier le gauche pour salon et le droit pour salle à manger et idem pour la cuisine.
1 « J'aime »
Yes!
On a eu d’autres appareils demandés comme ces prises multi-prises:
Exemple: Zigbee2mqtt: Add device HG06338 · Issue #1333 · GladysAssistant/Gladys · GitHub
Hello,
Je travail à l’intégration d’une vanne thermostatique chez moi, et j’ai ca :
Chaque “bouton” correspond à une feature de type Binaire sur ma vanne.
Je ne suis pas sur que le “split” dont vous parlez corresponde à mon problème.
Comment je peux faire pour que l’affichage change ?
Si je change le type, je vais devoir bricoler des types différents pour chaque feature, ce qui n’est pas top. De plus, je devrais modifier la Box dans le front pour autoriser chaque device, donc fastidieux à souhait.
Chez moi j’ai le même soucis avec une tête de chez moes.
La raison est simple : certains types ne sont pas encore pris en charge par Gladys. Mais ça va arriver, il faut le réflechir en amont pour gérer le chauffage puis développer tout ça.
En fait j’ajouterais bien les différents type pour mon intégration enocean, mais ma vanne a son propre protocole, donc j’aurais des types qui ne vaudraient sans doute que pour ce type de vanne, sachant qu’au final, ca reste un type Binary.
Exemple:
Donc je trouve que conserver un type bninary de base suffit, mais c’est bien l’affichage coté front qui me pose problème pour ma part.
Pour les features de type sensor, ca fonctionne :
Mais pas pour les features “non sensor” (readOnly: false):
Effectivement, toute la partie chauffage n’est pas encore gérée dans Gladys core.
C’est un développement qui reste à faire
N’hésite pas à faire une proposition de fonctionnalité, c’est le plus gros boulot a réaliser, pour que le développement se fasse rapidement ensuite.
Un peu comme réfléchir aux plans de ta maison avant la construction, quand tu sais où tu vas, ça se déroule tout seul.
J’avais fait une première esquisse qu’il faut que j’actualise avec mon expérience de mes têtes connectés actuelles, n’hésite pas à en faire une nouvelle ou à la compléter :
Autre exemple de spécification fonctionnelle (by @pierre-gilles) :
1 « J'aime »
Je rajoute mon grain de sel ici, je ne sais pas si cela dépend de la même problématique… J’ai un interrupteur 4 canaux zigbee dans mon jardin. Et il s’affiche comme ça malgré le fait que j’ai donné de jolis noms aux features :
En fait l’idée pour ces appareils qui sont un peu des multiprises, ce serait de faire en sorte que l’intégration split le device en plusieurs devices, et ce pour plusieurs intérêts :
- Etre capable de nommer proprement chaque device
- Pouvoir placer chaque device dans une pièce différente (car un relais peut contrôler des appareils dans plusieurs pièces)
- Que ces appareils soient gérés par les assistants vocaux (Google Home, Alexa), qui ne gèrent qu’une fonctionnalités du même type par appareil
C’est comme ça que font la plupart des autres systèmes domotiques.
C’est un développement dans l’intégration Zigbee2mqtt 
1 « J'aime »
Ok je comprends tout à fait !
Je patienterai alors car je ne suis malheureusement pas développeur.
1 « J'aime »
Je ressuscite un peu le topic , ça ne s’applique pas partout 
Juste pour rajouter un jeton dans la machine, z2m le lixee tic, je vois pas pourquoi on ferai plusieurs devices.
Et pour montrer à quel point c’est inutilisable
Qui est qui ? C’est la loterie
Edit: L’edition des features name est quasi impossible, et l’utilisation dans les scènes c’est la misère
Contournement pour le dashboard est les scenes, en prendre un au hasard et éditer les selector en db
1 « J'aime »
Effectivement, le Lixee TIC est un peu extrême (beaucoup de features).
Dans le cas du Lixee TIC, pour moi la solution c’est juste de mieux classifier chaque feature, car je suppose que chaque feature a un intérêt et montre une valeur différente de sa voisine ?
Contrairement aux multiprises qui elles ont vraiment 5 feature qui font exactement la même chose, je suis sûr que dans le cas du Lixee il s’agit bien de X features réellement différentes, non ?
Je remonte ce topic pour savoir si une âme charitable s’est penché sur ce développement ?
Il semble que pas mal de messages récents sur le forum aboutissent à cette problématique.
1 « J'aime »