On avait abordé le sujet pour les devices Tasmota.
Il faut s’assurer que le feature type est le même, lorsqu’on choisit de changer de category.
Light.binary == Switch.binary
Et j’ai pensé, pendant mon sommeil, est-ce que des “virtual-devices” ne permettraient pas ce genre de choses ?
- changer la category
- changer une feature de pièce (pas tout le device)
- controler un appel HTTP (incoming soon via les scenes)
le tout configuré depuis les scenes, si le virtual device change d’état, je change d’état tel autre device.
c’est peut-être un peu lourd et dur à comprendre non? L’utilisateur doit toujours se rappeler qu’il a 2 device juste pour définir une seule chose
Je pense que dans ce cas précis, il vaut mieux que l’utilisateur puisse dire « cette prise est une lumière » 
Je suis assez d’accord que c’est un peu lourd à gérer pour l’utilisateur lambda, ca peut refroidir. D’autant que ca doit pouvoir ce gérer assez simplement dans les parametre du device.
Ceci n’est pas a négliger, on rencontre le cas d’usage dans plusieurs cas de figure avec les devices Sonoff (4ch, 4chpro, dual, …) et pour le coup c’est plus compliqué à gérer. Peut-être a prévoir dans les menus "Découverte " de l’intégration, et avoir une option supplémentaire qui demande si on souhaite séparer les devices voir même pour ces modèles 2 devices, directement séparer les features en 2 ou 4 devices. Il vaut mieux avoir pour le 4ch par exemple 2 devices séparés même s’ils sont dans la même pièce. Ca se configuré de toute façon très bien après.
Mon cas d’usage peut être un bon exemple : j’ai un 4CH Pro qui gère :
- 1 eclairage dans la salle de bain,
- 1 prise dans la salle de bain (chauffage)
- 1 eclairage dans les WC,
- 1 eclairage dans la cuisine.
Si les 4 sont des devices distincts j’ai juste a configurer ensuite les 2 premiers dans la salle de bain, le suivant dans les WC et le dernier dans la cuisine.
Ceci résout également le problème des intitulés sur le dashboard puisque chacun a son nom de device. Reste plus qu’a pouvoir changer la feature dans les paramètres du device si c’est un eclairage.
Vous en pensez quoi ?
Voir même si on ne tiens pas compte du modèle, juste une vérification de l’intégration qui sépare toute feature "commutateur " en plusieurs device.
Si vous êtes OK @pierre-gilles et @AlexTrovato, je peux regarder ça dans la semaine si je suis capable de faire.
Je réfléchissait à la question, là où je suis d’accord qu’on veut rendre le cas “lampe branchée sur prise” possible, je ne suis pas sur qu’on veuille que l’utilisateur puisse modifier toute la configuration de ces services censées être clé en main.
Il faut vraiment que le minimum vital soit exposé à l’utilisateur final.
On d’accord que l’on veut ajouter un bouton “Editer” à l’intégration Philips Hue, dans ce style: ?
Ensuite, ce bouton affiche une vue de ce style:
Sur cette vue, je pense que l’on ne veut permettre la modification de la catégorie que si c’est une prise que l’on veut transformer en lumière.
On pourrait par exemple mettre un toggle true/false “cette prise est une lampe, permettre à Gladys de contrôler cette prise en tant que lampe”, toggle qui switcherait la catégorie de switch à light et inversement.
Vous en pensez quoi ?
1 « J'aime »
@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.