@pierre-gilles, pour moi ce serait déjà parfait de ce point de vue là et amplement suffisant. Simple et efficace = Gladys v4 ^^
Mais qu’en est-il de la partie multi-switch relevé plus haut pour toi ?
Problème beaucoup plus complexe et beaucoup plus « philosophique » que juste ce changement de feature category dans les Philips Hue 
On peut avoir un topic spécifique pour parler de ce problème ?
Sinon dès qu’on va finir la tâche Philips Hue le problème du multi-switch va passer à la trappe.
Tu as totalement raison, désolé !!
Salut, on a ouvert un topic spécifique pour ce sujet ?
Oh non pas encore !!
PR créée ici : WIP - Philips Hue: Added a separate tab for device discovery + Add edit button + Add check #1054
Hello,
Pour faire suite à la PR et aux discussions sur le sujet, pour intégrer cette fonctionnalité, je comptais créer un param pour le device feature a la création du device du genre :
- device_id = id du device
- value = [
{
device_feature_external_id: id du device feature 2,
create_category: "switch"
},
{
device_feature_external_id: id du device feature 2,
create_category: "switch"
}
Du coup quand on cree le device on a bien l’info et quand on coche la case, ça change bien la category en “light” et ce dernier est pris en compte dans les light sans avoir de changement particulier à faire en plus en dev. Apres on peut même ce dire qu’on affiche dans sa card la category de base. Et ceci pourra être repris du coup pour les autres integrations qui ont le même problème (on parlait du souci des relais sonoff en switch qui contrôlaient souvent des lumières)
Est-ce que ca convient ? Pour les équipements déjà créés je comptais mettre dans les actions une condition “si device feature switch/binary et le paramdevice du create_category” n’existe pas, alors on le crée. Ca conviendrait ?
Il existe un fichier on l’on peut éditer manuellement ce paramètre en attendant ?
Hello !! Alors oui et non.
Pour ma part j’ai modifié directement en DB, dans la table t_device_feature dans la colonne category mais attention aux instabilité par la suite (de mon côté je stop le container gladys, et ensuite je modifie en ligne de commande avec sqlite3).
Si tu n’es pas en prod mais en dev, tu peux modifier le fichier server/services/philips-hue/lib/models/plugOnOff.js et changer dans features :
category: DEVICE_FEATURE_CATEGORIES.SWITCH,
par
category: DEVICE_FEATURE_CATEGORIES.LIGHT,
Après on peut peut-être modifier dans le container docker en prod, mais je ne sais pas faire et je pense que ce sera à refaire à chaqe maj.
Je comprend pas pourquoi tu veux faire ça? On avait pas dit qu’on devait juste changer la feature de la catégorie en switch (cf Editer le type de feature des devices Philips Hue - #10 par pierre-gilles )
Salut @pierre-gilles,
Et bien cela fait suite à votre propre demande avec @AlexTrovato sur ce sujet : https://community.gladysassistant.com/t/pouvoir-modifier-les-pieces-des-divers-features-composant-un-device-avec-multiples-relais/5935/7?u=terdious,
soit garder en mémoire :
A la base vous vouliez faire ça avec le model. Mais si on fait ça on se limite à Philips Hue. Or des prises comme ça il y en a énormément. Les relais Sonoff sont dans le même cas.
Bref, pour garder la trace de ce qu’était le e périphérique original, comment penses tu faire autrement que dans la DB. Ou alors je n’ai pas compris la particularité de votre proposition, j’en suis désolé.
Je vois pas pourquoi ça limiterait à Philips Hue !
Actuellement, dans n’importe quelle intégration, quand on reçoit un appareil, on utilise les données fournit par l’intégration pour décider quel catégorie de device assigner à cet appareil.
La seule chose que je propose, c’est qu’au lieu de dire « cette switch est un switch, point barre », c’est de dire « cette switch est un switch mais peut-être transformé en light, car ce switch peut avoir une lumière branché ».
Pour décider si on display ce toggle, je propose de se baser sur les mêmes critères qu’on utilise pour décider si c’est un switch (on ne perd pas cette donnée).
Je sais, c’est hyper dur à expliquer ^^
En effet, my bad, je n’ai pas du tout écrit ce que je pensais ^^. Je visualisais le fait de faire une variable commune répertoriant tout les modèles susceptibles d’être impactés. Ce qui est un non sens. Bref pas de soucis ^^
En fait non du tout. C’est clair avec tes explications ^^ enfin je pense ^^
Par contre aujourd’hui on est d’accord qu’on a pas l’outil côté front pour le faire car de ce que je comprend, tu souhaiterais que l’on :
- crée une nouvelle action côté front pour récupérer la variable « lights » de Philips Hue et de récupérer la category à son arrivée à chaque poll.
- si c’est un « switch-binary » on affiche le toggle.
- si toggle
on modifie la category en light, si décoché on modifie la category a son état d’origine. - et on affiche dans la feature la catégorie de base.
Si c’est bien ça je pense réussir a le faire. Toutefois pourrais-tu regarder ma proposition sur la PR. Elle est fonctionnelle et testable. Car dans cette proposition, il n’y a plus qu’a modifier dans chaque integration comment le device est créé (en ajoutant un param) et le reste est identique pour tous.
Je viens de regarder ta PR @Terdious, je pense pas qu’on veut l’implémenter comme ça le changement de type feature, ça fait pas sens en terme de modélisation DB (ça viole pas mal de paradigme de modélisation DB), je trouve que c’est un peu du bricolage là ^^
Ok, merci d’avoir regardé et pour ton retour en tout cas.
Toutefois il n’y a rien de bricolé là-dedans. En effet de mon côté je suis automaticien/administrateur GMAO et DB GMAO. Et dans notre domaine, c’est ainsi qu’on fonctionne, tout ce qui est paramétrage est toujours enregistré en base, d’où ma proposition ^^. Toutefois en effet, ca ne fonctionne peut-être pas pareil en informatique pure. Je suis là pour apprendre ^^ si tu as le temps de m’expliquer comment tu vois la chose, car je ne vois pas comment récupérer cette donnée sans devoir a nouveau faire appel à l’appareil. Dans tout les cas, on en a discuté avec quelques personnes, peut-être manque-t-il une colonne dans la table device_feature non ?
Toujours aussi intéressé de mon côté à faire !!
Je n’ai pas la réponse là 
Il faut que je me plonge dans le sujet, je pense on pourra regarder ça après que j’ai fini le multi-utilisateur ? (je pense que c’est plus prioritaire, surtout pour toi aha 
)
1 « J'aime »
Clairement oui !!^^ et de mon côté, j’ai netatmo à finir ^^
On voit ça après !!
J’ai fait une proposition PR pour le changement de type (prise → lumière) selon le modèle du device.
https://github.com/GladysAssistant/Gladys/pull/1108
La prise en charge de ce changement est uniquement côté front, se basant sur une méthode pour déterminer si la catégorie de la feature peut etre modifiée.
Ici, pour Tasmota, je connais les modèles de type lumière, je regarde donc si ma feature est switch / binary et que le modèle du device n’est pas dans la liste des types identifés comme lumière.
Dans de cas, je permet l’édition de la catégorie uniquement (pas du type).
2 « J'aime »
Génial! C’est clairement ce qu’il fallait à mon avis, c’est du pur front ça.