Bonjour,
Certaines fonctionnalités ne fonctionnent plus dans mon installation domotique (Debian 11/Jeedom 4.4.5), ce matin je me rends compte que dans la configuration de certaines commandes, dans « Action sur valeur », je n’ai plus qu’un choix de test (égal). Et conséquence de ce choix unique tous mes tests sont devenus 'égal"…
Suis-je le seul dans cette situation ?
Si je vais dans Analyse, Equipements, Actions définies je remarque que les autres tests sont encore présents.
Mais dans la fiche de configuration des commandes je n’ai plus que le test égal de disponible, et ceci sur 3 installations Jeedom différentes, toutes en 4.4.5 mais j’ignore quand le problème est apparu.
Bonjour,
c’est une info binaire ?
Hello,
j’avais déjà constaté ceci quand j’étais en version 4.3.x. Mais je n’ai pas creusé plus que ca le pourquoi du comment ; je gère par scénario ce que je ne peux pas/plus gérer via l’action sur valeur.
Effectivement le problème semble exister que sur les infos binaires.
tu as update vers la 4.4 depuis quelle version ? car en 4.3 c’est aussi le cas il me semble.
tu peux poster une capture d’écran pour exemple, il est peut-être possible de faire une modif sur le core pour gérer ce problème.
4.3 mais je n’avais pas vu avant, je ne sais donc pas dire quand cela est arrivé.
Certainement que sur une version précédente il était possible de choisir d’autre comparateurs.
Après pour une version binaire faire un check si >= -1 c’est pas très commun non plus 
Oui mais c’est le seul moyen de dire « tout le temps » !
Du coup j’ai triché en mettant un type numérique pour avoir tous les tests, puis j’ai changé pour binaire ensuite.
En attendant une correction du core…
Bonjour.
C’est a dire…
On ne peut pas passer une commande « tout le temps »
Une commande est réalisée sur un événement.
Du coup, je le demande si tu fais pas un truc que tu devrais pas…?
Bien sur qu’on peut ! On peut dire « valeur supérieur à -1 », j’utilise cette possibilité depuis longtemps.
Pardon, je me suis mal exprimé
Ce n’est pas « pouvoir »
C’est on ne doit pas.
Si on veut une info a 1.
On passe la commande 1 une fois.
Puis on ne fait rien tant que l’on ne souhaite pas que l’info soit à 0.
A ce moment, on passe une fois la commande 0
Puis on ne fait rien tant que l’on ne souhaite pas que la commande soit a 1.
Et ainsi de suite.
On ne doit donc pas toujours envoyer / solliciter la commande 1 ou 0.
L’action sur la valeur réalisant une commande, ne doit pas toujours etre vrai…
C’est ce que je voulais dire (on ne doit pas / on ne peut pas / il ne faut pas / il n’est pas conseillé de…)
Bref, le but etait simplement de comprendre ce que tu souhaites faite pour t’indiquer comment le faire autrement.
Oui j’ai bien compris mais cependant je ne partage pas votre avis. C’est une fonctionnalité qui existe et qui a été proposée longtemps, il est donc dans tout les cas problématique de la retirer.
Et par ailleurs qui pour décider de ce qui « doit » se faire et de ce qui ne « doit pas » se faire…
Et pourquoi ce ne serait plus proposé pour les types binaires mais toujours pour les numériques par exemple ?
Moi j’ai plusieurs situations ou je trouve pratique d’utiliser ce « doit toujours » exécuter une ou plusieurs commandes lors du changement de valeur. Cela m’évite d’ajouter des scénarios (que j’ai déjà en grand nombre) pour des cas simples.
Mais je pense que le fond n’est pas le sujet ici. Si Jeedom décide qu’effectivement cela ne doit plus se faire alors je n’aurai pas le choix je devrai faire autrement mais en tant que développeur je trouve délicat de retirer ainsi une possibilité qui a été offerte aux utilisateurs pendant un temps, quand bien même ils auraient « dévier » l’utilisation (mais je ne pense pas que cela le cas ici).
En fait, il suffit de mettre #value# avec le choix « égal » et l’action est bien exécutée lors de chaque changement et c’est bien explicite.
J’avais oublié cela mais je me souviens l’avoir lu quelque part, merci !
Je suis mitigé…
Ce n’était pas logique de pouvoir faire ce genre de choses (un binaire c’est vrai ou faux, pas de comparaison), cela aurait dû être bloqué dès le départ.
Cela ne l’a pas été et l’utilisation a été détournée ce qui fait qu’à présent que ce bug (en fait) est fixé, les personnes ayant profités de la faille sont bloqués.
Et moi je trouve cela sain de modifier ce type de problème mais on est d’accord que cela reste un breaking change à annoncer comme tel (cela a peut-être été le cas, je ne sais pas)
Hors sujet mais un autre cas similaire gros comme une maison: tout le monde ou presque ici conseille de mettre un espace devant l’unité pour éviter la conversion auto. C’est une connerie monumentale! On sait déjà que ça posera problème un jour! Moi j’aurai fait un trim dès le premier jour pour empêcher cette deviance.
Faudrait effectivement revenir sur le besoin derrière ce test pour voir quelle autre solution pourrait être apportée (en respectant l’esprit de la fonctionnalité pour ne pas avoir le même problème plus tard)
