C’est bien ce qui me gène le plus… Surtout que dans la logique va falloir aussi pouvoir inverser des slider/commande numérique et la bonjour le bordel
1 « J'aime »
Vous avez 1mois et demi pour trouver 
A voir si le invert display va pas sauter dans le futur… Mais si on veux normer, le nouveau vrai invert est indispensable. Et le plus important, qqlun qui met à jour en 4.2 n’a aucun changement de comportement.
inclure cela dans la réflexion global a du sens, de nouveau il n’y a probablement pas/plus d’urgence, donc sur quelque chose de si structurant autant avoir une bonne vue d’ensemble avant de prendre une décision finale, je ne peux être que d’accord la dessus.
D’un autre côté je ne jeterais pas l’idée, c’est une approche valide et justement autant essayer de la « casser » pour trouver comment l’améliorer 
3 « J'aime »
Le problème d’origine c’est cet invert d’affichage. Je ne sais pas pourquoi il y a eu cette fonctionnalité mais elle camoufle le fond du problème et rend les choses bien plus complexes qu’elles ne le sont déjà.
Ce qu’on attend d’un produit comme jeedom c’est que quand on intègre un périphérique zwave, zigbee, … les commandes soient correctement configurées. Là c’est pas le cas, on balance la valeur brute, on explique à l’utilisateur tant bien que mal que s’il voit une icone porte ouverte alors qu’elle est fermée sur son dashboard, il a une case à cocher pour inverser, mais alors faudra quand même dans ses scénarios qu’il se méfie en faisant ses tests avec porte_de_devant == 0 et porte_de_derrière == 1, mais aussi porte_du_coté != 1 parce que tu sais pas pourquoi mais l’aeotec gen7 lui il est codé en 256 et 257 …
… bref …
je pense pas que la confusion elle vienne de la case à cocher existante et d’une potentielle nouvelle qui apparaitrait. Pour moi elle vient du manque de normes.
Allez, je prends un autre exemple: pourquoi l’intégration Nuki, pourtant officielle Jeedom, elle remonte verrou fermé avec un 0 ?
Alors je ne sais pas si la correction proposée est la meilleure, il est probablement mieux de bien en discuter avant d’agir, c’est certain, mais au moins elle tue le mal à la source. Moi j’irai même plus loin avec le binaire, avec un concept de NF et NO. On ne vérifie que la valeur cible, et tout autre valeur est considérée comme l’opposé (avec peut etre un log ou quelque chose dans le genre).
Il faut que les bases soient solides pour qu’ensuite on puisse appuyer des fonctions puissantes. Je pense par exemple au type génériques, qui ont énormément besoin de ces valeurs pour rendre les commandes plus génériques et qui ne peuvent pas se permettre des remontées farfelues.
En tous cas merci de prendre le temps d’en discuter !
2 « J'aime »
Oui, orsqu’on débute, c’est horrible ce truc !
Le plus courant reste fermé/repos = 0 et ouvert/actif = 1 (ce qui correspondant à NF).
C’est bien indiqué lors de l’utilisation du bloc SI dans les scénario.
fermé = 0 c’est bon
Pour les alarmes, historiquement, c’est un fil qui parcours tout un tas de capteurs. Pour cela, c’est du Normalement Fermé partout. Dès que le fil est coupé quelque part, elle se déclenche. Si on voulait du simple, ce serait de forcer l’utilisation 0 lorsque les capteurs sont au repos et 1 lorsqu’ils se déclenchent.
Maintenant, lorsque ça fonctionne chez lez gens à coup d’inversions à gauche et à droite, c’est risqué de changer. On ne touche pas à un truc qui marche pour faire plus joli !
1 « J'aime »
C’est pas une question de « faire joli », c’est une question que encore maintenant et sur mes nouveaux modules c’est dépareillé et je me trompe encore dans les plugins alarmes ou mes scénarios, ou mes résumés, pour gérer correctement la notion de ouvert/fermé.
comment ils font dans HA?
C’est peut être une piste a voir et suivre ?
La ou c’est compliqué c’est que dans jeedom on aime pas altérer les informations renvoyées par les modules. La uniformiser c’est changé le comportement décidé par le fabricant et je trouve pas ça terrible. Mais oui on est en train justement d’y réfléchir pour que cette uniformisation arrive dans les prochaines version de jeedom.
4 « J'aime »