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

[pierre-gilles]

Salut à tous!

Certains d’entre vous se sont plaint de ne pas réussir à différencier certains appareils de d’autres dans les select box de Gladys. (@Terdious, @Romuald_Pochet )

J’ai noté ce cas par exemple:

Il est vrai que sur certaines intégrations (Z-Wave, Zigbee, MQTT et Sonoff), il peut parfois y avoir plusieurs fonctionnalités du même type sur un même device, et du coup c’est peu lisible actuellement !

Cependant, ce n’est pas le cas avec toutes les intégrations:

Au contraire, dans d’autres intégrations, Philips Hue par exemple, le nom du device est intéressant, mais le nom de la feature ne peut même pas être changé et n’a pas grand intérêt. (Dans le cas de Philips Hue, les ampoules Philips Hue sont assez simple: On/off, couleur et luminosité et c’est tout)

Je me suis penché sur le problème, et comme il est impossible de satisfaire tout le monde, je pense faire un affichage différent selon les intégrations, comme on a fait sur la vue “Appareil de la pièce” sur le dashboard.

Pour l’instant je suis parti sur ça:

Pour les intégrations:

• mqtt
• zigbee2mqtt
• zwave
• ewelink
• tasmota

Edit:

• bluetooth

On affichera le nom de la feature, et pour les autres le nom du device!

Qu’en pensez-vous ?

Est-ce qu’il manque des intégrations dans cette liste ?

[GBoulvin]

Top top !
Ça va grandement nous simplifier la tâche !

[pierre-gilles]

J’ajoute une autre question, est-il vraiment utile du coup d’afficher entre parenthèse le type de la feature, là ou le nom est peut-être suffisant, ce qui ferait:

[GBoulvin]

A voir mais perso, je le laisserais (ne fusse que l’icône correspondante).

[pierre-gilles]

Là on parle juste du texte, et il n’y a pas d’icône car on parle des vues “Trigger changement d’état de l’appareil”

Pour moi de ce que j’ai testé c’est hyper redondant quand on affiche la feature sur cette vue, ça fait lourd dans l’UI

[pierre-gilles]

La PR est sur Github:

For some integrations, display the device feature name and not the device name in the UI

[Terdious]

Salut @pierre-gilles,

Je me permets de rebondir :

@pierre-gilles

Je me suis penché sur le problème, et comme il est impossible de satisfaire tout le monde, je pense faire un affichage différent selon les intégrations, comme on a fait sur la vue “Appareil de la pièce” sur le dashboard.

Je ne sais pas quand cela a été fait, mais pour ma part ça n’a jamais été fonctionnel, étrange que personne d’autres ne l’ai fait remonter, ce qui pour le coup a été mon cas à plusieurs reprise mais à dû passer inaperçu ^^ Pas de soucis ^^ Je pensais que c’était en cours et ncore une fois pas fait d’issue github !! Un exemple (mais c’est idem sur MQTT et autres) :

Device Tasmota :

Edition dashboard :

Dashboard :

Du coup dans cet optique, il serait bon de repasser sur le dashboard et l’édition du dashboard en même temps

@pierre-gilles

On affichera le nom de la feature, et pour les autres le nom du device!

Qu’en pensez-vous ?

Mais du coup ça complexifie le tout, pourquoi pour les intégrations du style Philips hue, ne pas mettre en DB dans le champs « nom » la catégorie de la feature si c’est ça ? En fait que ce soit n’importe quelle intégration AMHA, on souhaite toujours affiché le nom de la feature. Si on ne peut pas changer le nom de la feature Philips Hue peu importe, c’est fait dans le code et pour le coup on peut lui mettre le nom de la categorie et du type si on souhaite. Et ça évite de devoir faire des spécificités tout en restant simple non ?
Ca me fait d’ailleurs penser que … pourquoi on ne peut pas modifier ce nom d’ailleurs, on est bien d’accord que côté Dev, ce nom n’est jamais utilisé (et heureusement). Ca simplifierai beaucoup de chose.

[pierre-gilles]

@Terdious

Je ne sais pas quand cela a été fait, mais pour ma part ça n’a jamais été fonctionnel, étrange que personne d’autres ne l’ai fait remonter

Sur le dashboard je me rappelle tu m’avais demandé pour les appareils MQTT uniquement, donc le fix je l’avais fais pour les appareils MQTT Tu confirme que le fix est bien fonctionnel pour les appareils MQTT sur la box appareil de la pièce ? En tout cas chez moi ça l’est.

My bad pour tes retours, je lis beaucoup de messages par jour, si il n’y a pas une demande écrite et mise dans le backlog (github si bug, forum si feature), c’est 100% sûr que ce ne sera pas fait ^^

Du coup pour Tasmota c’est normal que ce soit affiché comme ça actuellement.

@Terdious

Du coup dans cet optique, il serait bon de repasser sur le dashboard et l’édition du dashboard en même temps

Yes c’est fait, j’ai appliqué la même liste d’intégrations sur les deux vues

@Terdious

En fait que ce soit n’importe quelle intégration AMHA, on souhaite toujours affiché le nom de la feature.

Pourquoi complexifier les intégrations qui sont simple ?

C’est pas juste, ce serait rendre complexe les intégrations simple à cause des autres intégrations complexe, c’est du nivellement pas le bas ^^

Pour moi les intégrations MQTT / Zigbee2Mqtt / Tasmota c’est des intégrations pour développeurs, et pas pour le grand public. Elles ont un fonctionnement très particulier qui n’est pas généralisable.

Le grand public qui utilise Gladys, il va brancher :

• Du Philips Hue
• Du Sonos
• Des prises types TP-Link

Et il va s’attendre à ce que Gladys fonctionne comme un Google Home / Apple HomeKit / Alexa.

Ces plateformes n’exposent même pas les notions de deviceFeatures à leurs utilisateurs, dans Google Home / Home Kit / Alexa, seul le nom du device compte, et je pense qu’il faut faire pareil pour nos intégrations « grand public ».

[pierre-gilles]

Edit: J’ai rajouté l’intégration bluetooth à la liste

[Terdious]

@pierre-gilles

Sur le dashboard je me rappelle tu m’avais demandé pour les appareils MQTT uniquement, donc le fix je l’avais fais pour les appareils MQTT Tu confirme que le fix est bien fonctionnel pour les appareils MQTT sur la box appareil de la pièce ? En tout cas chez moi ça l’est.

Je confirme que sur le dashboard on récupère bien le nom, mais pour la page édition dans la sélection ce n’est pas le cas non plus pour MQTT. Ca apparait comme Zigbee2Mqtt et Tasmota :

Les 4 commutateurs ci-dessus sont nommés « Ouverture […] », « Fermeture […] » etc.

@pierre-gilles

My bad pour tes retours, je lis beaucoup de messages par jour, si il n’y a pas une demande écrite et mise dans le backlog (github si bug, forum si feature), c’est 100% sûr que ce ne sera pas fait ^^

Vraiment aucun soucis !! Je comprend complètement !!

[pierre-gilles]

@Terdious

Je confirme que sur le dashboard on récupère bien le nom, mais pour la page édition dans la sélection ce n’est pas le cas non plus pour MQTT. Ca apparait comme Zigbee2Mqtt et Tasmota :

Ok tout est normal donc

Je merge bientôt la PR, ça partira dans la prochaine release de Gladys !

Edit: c’est mergé sur master!

[lmilcent]

Je triche depuis le début en utilisant d’abord l’interface de Zigbee2Mqtt pour renommer les devices, puis les “scanner” et intégrer dans Gladys avec un nom parlant
Super idée en tout cas, ça sera beaucoup plus simple

[Romuald_Pochet]

Bonsoir,

Je viens de récupérer le PR. Je viens d’essayer de mettre a jour ma scène, mais le nom du device n’apparaît plus…

Si je rajoute le nom du device, c’est parfait pour moi (hormis le nom des feature z-wave que je devrais mettre dans un dictionnaire)

PS: j’ai mis le node id z-wave dans le nom du device pour me permettre de retrouver plus facilement, cela va disparaitre

[pierre-gilles]

@Romuald_Pochet

Je viens de récupérer le PR. Je viens d’essayer de mettre a jour ma scène, mais le nom du device n’apparaît plus…

Ah, c’est exactement ce que fait la PR en fait Mais bon, peut-être que ça s’adapte pas bien au Z-Wave… On peut changer ça.

Voilà ce que j’ai modifié:

En gros, pour les appareils des intégrations:

• MQTT
• Z-Wave
• Zigbee2mqtt
• Ewelink
• Tasmota

On n’affiche plus que le nom du deviceFeature, le nom du device n’est plus affiché nul part.

ça pose problème avec le Z-Wave ?

[Romuald_Pochet]

Disons que j’ai plusieurs device avec une feature Temperature (en z-Wave c’est le nom de la classe associée, en Zigbee le ‘expose’), on aura donc ‘Temperature’ plusieurs fois, non?

Ce que j’ai fait:

const getDeviceFeatureName = (dictionnary, device, deviceFeature) => {
  const deviceService = get(device, 'service.name');
  const featureDescription = get(dictionnary, `deviceFeatureCategory.${deviceFeature.category}.${deviceFeature.type}`);
  if (deviceService && DISPLAY_FEATURE_NAME_FOR_THOSE_SERVICES[deviceService]) {
    return `${device.name} (${deviceFeature.name})`; 
  }
  return `${device.name} (${featureDescription})`;
};

[pierre-gilles]

@Romuald_Pochet

Ce que j’ai fait:

Oui mais justement, pour ces intégrations le parti pris c’était de ne plus utiliser le device.name.

Si c’est pour faire ça, je peux rollback le changement sur le Z-Wave pour faire comme avant

Le pilier de la philosophie de Gladys, c’est de faire un produit qui est utilisable par tout le monde, même un public non-tech.

Du coup la question ce serait: comment on pourrait faire pour que les appareils Z-Wave aient un nom « human friendly », lisible, et qui permettent d’identifier facilement le device.

Parce-qu’au final, des 3 propositions que je vois pour le Z-Wave (actuellement, la PR que j’ai faite hier, et ta proposition), la proposition qui me semble la plus propre au final c’est celle qu’on a actuellement (donc rollback PR d’hier)

[Romuald_Pochet]

Tout a fait d’accord pour la philosophie

Si on ne mets pas le device (name ou autres) dans la liste déroulante, il faut garantir que le libellé des feature soit unique, est-ce envisageable? Si j’ai 2 capteurs de température (device + 1 feature Temperature), je ne peux pas appeler ma feature ‘Température’ mais ‘Température du capteur toto’ ou ‘Température salon’.

Ce n’est pas lié à une intégration en particulier. Avec MQTT on doit donner un nom donc le problème est moindre, sauf qu’il faut un nom unique pour chaque feature. On peut partir sur ce même principe, c’est l’utilisateur qui choisit un nom pour la feature.

[pierre-gilles]

@Romuald_Pochet

Si on ne mets pas le device (name ou autres) dans la liste déroulante, il faut garantir que le libellé des feature soit unique, est-ce envisageable?

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

@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 ).

Si quelqu’un veut faire cette petite enquête, il est le bienvenue 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)

[pierre-gilles]

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.

[pierre-gilles]

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…