Affichage des noms des fonctionnalités au lieu du nom des devices pour certaines intégrations!

Justement, c’est vrai que c’est peut-être contraignant de devoir forcer l’utilisateur à nommer chaque feature de chaque intégration.

Encore le MQTT je comprend (c’est manuel), mais au final pour les intégrations type Z-Wave, ça va vite être un enfer en fait… Surtout que dans les solutions de maison connectées grand public, personne ne fait ça.

Désolé @Terdious mais je pense que je vais rollback la PR pour la plupart des intégrations (je laisse le MQTT uniquement je pense), on manque d’information, j’ai mergé ça un peu trop dans la précipitation et sans consulter les autres membres de la communauté qui ont des setups différents :slight_smile:

@Romuald_Pochet dans le cas du Z-Wave, en fait dans 99% des cas c’est ok d’afficher un combo « deviceName + (feature name depuis les trads) », je pense c’est vraiment les 1% des devices bizarre qui posent problèmes (ceux dont on parle dans le topic Z-Wave cf https://community.gladysassistant.com/t/v4-integration-z-wave/6057/53?u=pierre-gilles ), et eux il faut plutôt essayer de les splitter en plusieurs device plutôt que de devoir changer toute notre façon de faire pour ces 1%.

Je pense que pour continuer ce débat, il faut aller chercher plus d’informations.

Dans un premier temps, au niveau de Gladys:

  • Faire la liste des intégrations dans Gladys, et pour chaque intégration lister comment fonctionne le nommage actuellement (nommage du device, et nommage du device feature)
  • Identifier les cas qui posent problèmes, et comprendre individuellement ces cas: est-ce que ça fait vraiment sens d’avoir un device unique comportant 200 features ? Faut-il mieux pas splitter le device ?

Dans un second temps, en dehors de Gladys:

  • Aller voir chaque système domotique grand public: Google Home, Alexa, Apple Homekit (j’insiste sur le grand public: home assistant, domoticz, ne sont pas des inspirations, je ne dis pas que ces systèmes ne sont pas bien, mais ils sont destiné à un autre public donc c’est pas ce dont on veut s’inspirer ici :slight_smile: ).

Si quelqu’un veut faire cette petite enquête, il est le bienvenue :slight_smile: Je peux investir du temps dessus, mais je dois prioriser ça avec toutes les autres features demandées (est-ce que c’est plus prioritaire que la vue graphique? que l’intégration Alexa? à vous de me dire)

Je viens de revert le changement dans cette PR: User patch by Jean-PhilippeD · Pull Request #132 · GladysAssistant/Gladys · GitHub

L’affichage du deviceFeature.name ne reste le cas que pour le MQTT comme avant.

J’ai fais ma petite enquête sur les autres systèmes domotiques grand public:

Apple Homekit

Chaque appareil a un nom (équivalent deviceName), et c’est ce nom uniquement qui est affiché.

Il n’y a pas de notion de deviceFeature, du moins ce n’est pas exposé au public, il ne voit qu’un device avec des “capabilities” qui ne sont pas nommées:

Google Home

Même principe que Apple Homekit, chaque appareil a un nom et un type de device, et chaque device a des “traits” (une feature).

Dans l’UI, seul le device name est affiché:

Ceux qui se voit dans le code de l’intégration Google Home d’ailleurs, un device ressemble à ça:

{
   id: 'UN_ID_UNIQUE',
    type: 'action.devices.types.LIGHT',
    traits: ['action.devices.traits.OnOff'],
    name: {
      name: 'Lampe salon',
    },
    deviceInfo: {
      model: 'XXXX',
    },
    roomHint: 'Salon',
    willReportState: true,
}

Il n’y a pas de notion de deviceFeature name, juste chaque appareil physique a un nom.

Amazon Alexa

Le fonctionnement est assez similaire à Google Home, chaque device est représenté par son nom et par une liste de “capabilities”. Les capabilities n’ont pas l’air d’être nommée ni affichée dans l’interface

Du coup je me demande: comment font les gens qui ont des appareils complexe type prise multiple pour les gérer dans ces plateformes ?

En y réfléchissant, je suis de moins en moins persuadé que le feature.name a un sens…

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

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 :

image

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

image

Effectivement, toute la partie chauffage n’est pas encore gérée dans Gladys core.

C’est un développement qui reste à faire :slight_smile:

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

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

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 »