Salut j’ai pas compris tes points ?
Pour moi c’est une options ajouter dans le panneau de config d’une commande
Ça serait une simple case à cocher qui proposerais d’inverser les valeurs binaires recues
Donc par défaut jamais coché et a l’utilisateur activer l’option pour chaque commande qu’il désire inverser
soit ici
soit ici
Prends le temps pour ma 4.2
Elle est top mais pas sur que tt le monde soit préparé lol
Comlunique ce qui va changer… laisse le temps aux user de le faire
Apres si faut tester certains points demande
Mais ça va être Noël souffle et prenons le temps !
Oui oui mais faut quand meme que je test tout et ca prend du temps…
C’est ps si simple car une fois inversé faut dire que dans le widget tu veux plus inverser ou que tu veux inverser, ensuite pour chaque equipement/scénario utilisant la commande faut que tu reinverses (ou pas) partout. Ensuite il va falloir que je repasses sur les milliers de conf pour mettre a jour les json pour inverser quand c’est nécessaire, puis va falloir expliquer aux utilisateurs pourquoi un équipement nouvellement ajouté et inversé et pas l’ancien… (et je parle pas des pros et autres utilisateurs avec des conf bizarre ou ca va aller mais pas partout…)
Si tu as besoin de faire des tests particulier mets nous a contribution
Ne tepuise pas.
Aprzs tout les bêta testeurs sont la pour ca
Je me rappelle de mon père tester des trucs avec toi… dc hésite pas
La c’est surtout le nouveau syteme DNS qui m’intéresse j’ai besoin de voir si il tient la charge (même si l’autre va pas disparaître le nouveau est quand même nettement mieux donc il va avoir du monde)
Heu mauvaise idée ça… j’ai pas tout lu de vos discussions mais par le passé ça avait posé problème !
voila j’ai fait une proposition (PR)
c’est vraiment tout bête , une simple case a cocher.
ensuite , pour ce que tu décris @Loic , à chaque user de l’utiliser comme bon lui semble.
Mais ainsi , si on change d’un capteur Zwave a EnOcean , et qu’on a migrer le tout, on peut juste cliquer sur cette case, et tout le reste suivra puisque désormais le capteur lorsqu’il envoi false, on enregistrera true.
je n’ai rien activé par défaut !
Ensuite il va falloir que je repasses sur les milliers de conf pour mettre a jour les json pour inverser quand c’est nécessaire, puis va falloir expliquer aux utilisateurs pourquoi un équipement nouvellement ajouté et inversé et pas l’ancien… (et je parle pas des pros et autres utilisateurs avec des conf bizarre ou ca va aller mais pas partout…)
Désolé, je comprend rien, j’ai l’impression qu’on parle pas de la même chose !
ca se contente , si on coche la case de faire ca
if ($this->getSubType() == 'binary' && $this->getConfiguration('invertBinary') == 1){
$value = ($value == 1) ? 0 : 1;
}
C’est alpha, par contre pour rappel je ne fais pas de maintenance sur du code que je n’ai pas fait (j’ai deja assez de mal pour celui que je fais je vais pas m’en rajouter)
Demain je suis off. Je teste sur la alpha 4.2.5
Je débarque (j’ai vue le PR forcément…) et je trouve que c’est une bonne solution pour ce problème.
On ne touche pas à l’existant. C’est donc une option propre à une commande qu’il faut activer volontairement. çà, c’est top.
Par contre, l’option est affichée dans la modal cmd de toutes les infos, je vais limiter aux cmd binary non ? Plus cohérent et çà évitera la confusion.
Quel est la différence avec le invertBinary actuel que plein ont coché sur des capteurs de portes etc ? (J’ai bien compris que celui si changeait la valeur que s’il était coché de manière volontaire) mais qu’en est-il de l’ancien invertBinary ?
C que de l’affichage comme avant. Donc en fait rien ne change sauf si tu le veux et par commande.
De ce que je comprend car j’ai jamais eu besoin de l’un ou l’autre
Heu justement non la valeur est bien modifiée ici, mais ma question est plutôt que cette configuration existait non ? Genre dans le plugin virtuel, (de mémoire, pas accès à un pc) donc si celle ci modifie la valeur et que c’est la même configuration… il va y avoir un conflit non ?
Le « invert binary » qu’on a dans la liste des commandes (de tout plugin suivant le standard du plugin template) n’influancait, en théorie, que l’affichage sur le dashboard: donc pas les autres plugins, pas la valeur réelle en db…
la config est stockée dans « display » > « invertBinary »
typiquement ce code dans le js:
tr += '<div><label class="checkbox-inline"><input type="checkbox" class="cmdAttr checkbox-inline" data-l1key="display" data-l2key="invertBinary"/>{{Inverser}}</label></div>';
Ici c’est « invertBinary » stocké dans la configuration.
Donc effectivement si on active celui-ci et que l’inversion à l’affichage était aussi activé, cela va inversé pour sauver en db puis re-inverser à l’affichage sur le dashboard mais par contre tous les autres plugin/scénario font avoir la valeur inversée alors que jusqu’à présent ils ne l’avaient pas.
Edit: cela pourrait rejoindre la standardisation dont on discute pour les types génériques en « forçant » que ferme / éteint soit 0 et ouvert / allumé soit 1.
Exactement
Ok bien vu la différence entre display et configuration donc on va pouvoir invertBinary display sur un invertBinary configuration… pas sûr que ça va pas rendre tout ça encore plus confu… je pense que la réflexion doit aller plus loin et doit être intégrée à celle dès types génériques. Car pourquoi inverser une valeur ? Si ce n’est pour coller à une « norme ». Chose qu’on va essayer de définir dans ce projet…
De fait avoir 2 « config » qui se nomment « invert » va apporter de la confusion.
(@frixo j’ai bien vu le texte d’aide sur le pr).
Est-ce que ça va faire 20% de confus pour 80% de satisfait ou l’inverse, c’est la question à 100 balles (et un mars).
Oui si l’idée à terme est de pouvoir faire (par ex) un « Si porte = ouverte » dans un scénario, cette notion d’inversion ne doit pas être dans les mains ses utilisateurs, c’est leur compliquer la vie inutilement je trouve… c’est de la « popote » de developpeurs…