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
)
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).
Génial! C’est clairement ce qu’il fallait à mon avis, c’est du pur front ça.
Bonjour,
j’ai généré une image docker avec la feature de modifier la catégorie d’une feature pour les devices Tasmota, seulement si ce sont des prises.
Ainsi, un device détecté avec une feature “prise/interrupteur” pourra être modifié pour une lumière.
Les contraintes/limitations de modification sont volontairement fortes, afin de s’assurer que l’action déclenchée soit bien soumise.
Les modifications ont été apportées sur le composant graphique commun en ajoutant une option qui permet de modifier la catégorie lors d’une édition.
Pour rappel, uniquement sur Tasmota pour le moment.
Si des intéressés veulent tester/vérifier le comportement, voici l’image docker.
atrovato/gladys:change-feature-category
https://hub.docker.com/layers/171261089/atrovato/gladys/change-feature-category/images/sha256-70adc5aeecf3fd192ac2047ba1e63b0fece4f83bb1d96c121a3c5bf1ead386da?context=repo
Une fois cette feature validée, on pourra l’étendre sur chaque service.
Merci.
Bonjour @AlexTrovato,
Essais de ta PR réalisés comme suit avec un Sonoff 4CH:
- Modification de 2 des features commutateur vers éclairage
Sonoff 4CH à la découverte :
Sonoff 4CH après modif :
- Intégration des 4 features sur le dashboard dans 2 box séparées soit 1 avec les 2 commutateurs et 1 avec les 2 éclairages.
- Test allumage des 2 commutateurs les 1 après les autres ok
.
L’interrupteur général de la box ne bouge pas (remarque pour @pierre-gilles également, toujours la même remarque, on s’attendrait à ce qu’il contrôle tous les binaries de la box. Du coup quel intérêt de l’afficher lorsqu’il n’y a pas d’éclairage dans la box ?)
- Test allumage des 2 éclairages les 1 après les autres ok
. L’interrupteur des box s’allume bien à l’allumage du 1er éclairage.
- Test allumage de l’interrupteur de la box ok
. Les 2 éclairages s’allument bien
Suite des tests : contrôle par catégorie dans les scènes
-
Bon encore une fois, je sais que ce n’est pas le problème de cette PR, mais il vaut mieux le rappeler partout : @pierre-gilles, il reste toujours impossible de déterminer de quel feature il s’agit lorsqu’il y a plusieurs features de même catégorie que ce soit dans le déclencheur comme dans l’action “Contrôler un appareil”. L’affichage du nom de la feature pour les intégrations correspondantes serait nécessaire.
-
Egalement, il reste impossible de contrôler un éclairage indépendamment lorsque plusieurs éclairages situés dans différentes pièces appartiennent au même device. Mais l’ajout de l’action “Contrôler un appareil” dépanne bien. Cela peut néanmoins rester frustrant de ne pas pouvoir utiliser l’action faite pour cela ^^ Il en va de même pour les prises.
-
Création de divers scènes :
- Déclencheur : 1er commutateur sur ON / Action 1 : Contrôler un appareil : 2ème Commutateur sur ON / Action 2 : Contrôler un appareil : 1er Eclairage sur ON - Ok
- Déclencheur : 1er éclairage sur OFF / Action 1 : Contrôler un appareil : 1er Commutateur sur OFF / Action 2 : Contrôler un appareil : 2ème Eclairage sur OFF - Ok
- Déclencheur : 1er commutateur sur ON / Action : Allumer la lumière : Sonoff 4CH - Résultat : 1er éclairage allumé donc ok
mais 2ème éclairage non allumé
(Supposition : Lorsqu’un device contient 2 catégories Light/Binary, il n’y a pas de for each prévu. La 1ère feature est donc seulement prise en compte.)
- Déclencheur : 1er éclairage sur ON / Action : Allumer la prise : Sonoff 4CH - Résultat : 1er commutateur allumé donc ok
mais 2ème commutateur non allumé
(Supposition : Lorsqu’un device contient 2 catégories Switch/Binary, il n’y a pas de for each prévu. La 1ère feature est donc seulement prise en compte.)
- Dernier test : Redémarrage du container puis vérification. Tout est bien persistant
En espérant que ça t’aide. Pour la PR en elle même, je ne vois rien à y redire. Merci @AlexTrovato
Tu peux mettre un screenshot de comment ça rend la partie ou tu modifie le type des features ?
Arf, ça doit être noté nul part parce que j’avais complètement oublié Désolé !
J’ai créé une issue pour que ce soit pas perdu:
Désolé, de même j’avais pas du tout le bug en tête.
J’ai créé une issue Github:
ça me fait penser, il va falloir trouver assez vite un moyen de mieux organiser le git car il y a tellement d’issue / PR que je m’y perds complètement, je ne le regarde même quasiment plus vu que c’est le bazar…
Ah, la box « allumer la lumière » a été conçue en pensant que les appareils de type « lampe » avaient forcément une seule feature. Si jamais cette box allumait toutes les lumières du device sélectionné, ça marcherait pour toi ?
C’est bien ça, la box a été créée en prenant en compte qu’une lampe n’avait qu’une seule feature binary. Si j’allume tous les binaires du device, ce serait bon ? Si c’est bon, il faut créé une issue github, sinon ça sera perdu dans 1 minutes
Ne soit surtout pas désolé, clairement j’en suis principalement responsable, j’indique toujours les choses sur le forum, mais depuis le départ j’ai dû créer seulement 1 ou 2 issues sur Github. En tant que contributeur régulier, je devrais me l’imposer. J’avoue que le temps me manque (comme nous tous bien sûr) et que le fait de passer généralement 1h à produire un post qui devrait en prendre 5 à 10 min m’empêche très souvent d’aller sur Github et de devoir en plus le traduire en Anglais … et comme j’ai des difficultés à bien m’exprimer ou à faire des posts trop long … bref je digresse. Je vais m’y forcer un peu pus !!
Merci beaucoup !
En effet !! Gladys V4 prenant de l’ampleur et intégrant maintenant tout de même beaucoup de chose, ça se complexifie ^^ C’est une bonne chose d’un sens
Alors pour le coup je donne vraiment mon point de vue sur ce point, mais il faudra sûrement que ce soit valider par d’autres, à chaque fois que je passe sur cette box, ce que j’en attends (idem pour l’action Allumer/Eteindre la/les prises bien sûr) :
- Qu’elle m’affiche tous mes appareils contenant au moins un éclairage.
- Que je puisse choisir un appareil qui n’a qu’un éclairage
- Si l’appareil contient plusieurs fonctionnalité d’éclairage:
- Que je puisse sélectionner l’appareil en entier (par exemple nommé par le nom de l’appareil avec à la fin « (Tout éclairage) » : « Sonoff 4CH (Tout éclairage) » et qu’il contrôle toutes les fonctionnalités éclairages de cet appareil
- Que je puisse sélectionner une fonctionnalité éclairage de l’appareil : « Sonoff 4CH - Eclairage SdB » ou « Sonoff 4CH - Eclairage WC » et qu’il ne contrôle que cette fonctionnalité.
Tout les scénarios possibles deviennent alors « possible »
C’est propre !
Ok, donc si je comprend bien il faut arrêter de raisonner en « device », mais toujours en « feature ».
Il faut plutôt remplacer le sélecteur de device par un sélecteur de feature.
Ca va pas être simple à changer (il faut migrer l’existant), mais il faut le faire, je créé une issue github pour ça:
Ca sera pas tout de suite tout de suite par contre, c’est pas mal de boulot ^^
Merci du retour !
J’avais déjà fait issue sur le switch de la box
Ah bien vu! Je ferme la mienne
Pour revenir à la fonctionnalité, fonctionnellement c’est bon pour moi.
J’ai fais un retour technique sur le code de la PR.
@pierre-gilles, @AlexTrovato,
Je me permet un petit peu après avoir relu toute la conversation. On est d’accord que cette fonctionnalité à du coup déjà été déployée mais pour le coup seulement pour tous les devices avec un bouton « Editer » ?
@AlexTrovato, cette fonctionnalité étant liée au front on est d’accord qu’il ne manque plus qu’à ajouter le bouton Editer à l’intégration Philips Hue ? Si c’est bien le cas je vais m’y pencher.
Il y a eu un développement d’une fonctionnalité similaire sur une autre intégration oui, mais pas sur l’intégration Philips Hue.