Jeedom convertis "et" string en "&&" Logique

Bonjour,

J’avais déjà fais un post, hier, mais ayant une suspicion sur le plugin sonarr, je l’ai donc supprimé.

Mais après plusieurs tests, le plugin sonarr est bien hors de cause.

Voici des exemple :

image

En revanche si le « et » n’est pas suivis d’un espace, ou d’un espace sans rien derrière aucuns soucis :

image

jeedom V4-stable 4.1.25

Par avance merci

Je rajoute quelques informations. Il semble que Jeedom interprète la chaîne de caractère " et " en ET logique "&&".

Avec un petit virtuel:
cmd::byString("#[Aucun][TEST][test]#")->event(", et ,");
me donne ", && ," lors de l’interprétation.

cmd::byString("#[Aucun][TEST][test]#")->event("et");
me donne "et" lors de l’interprétation.

Enfin Jeedom semble faire un trim de la chaîne de caractère " "
cmd::byString("#[Aucun][TEST][test]#")->event(" et ");
me donne "et" lors de l’interprétation.

1 « J'aime »

Je ne suis pas une masse en regex (qui doit servir dans le code de Jeedom) mais il me semble bien compliqué de faire la différence entre un « ET » volontaire dans une condition et un « ET » dans une commande.

D’où ce qu’il se dit de temps en temps : qu’il serait bien d’attaquer la transformation de ses scénarios pour remplacer ces mots clefs par des opérateurs PHP comme « && » pour le ET, « || » pour le OU.

Du coup un jour Jeedom pourra arrêter l’utilisation des opérateurs ET, OU, etc permettant ainsi de les avoir sans problème dans les commandes.

1 « J'aime »

il n’y avait pas de souci avant.

Et dans un résultat de commande il est contenu dans une chaine de caractère.

image logique

image illogique (sans jeu de mot :stuck_out_tongue: )

1 « J'aime »

Tellement vrai …

php comprend && || and or
et /ou c’est purement français et incompréhensible par n’importe quel language.

En tout cas à ma connaissance rien n’a changé là dessus dans le Core

oui cela solutionnerais, mais ce serait un correctif de facilité si je peux me permettre. et cela ne ferais que déplacer le problème, car pour peu qu’une commande contienne de l’anglais, le problème sera le même avec « and » et « or ».

En tout cas le souci est vraiment récent je pensais quelques jours, mais visiblement impossible, mais assurément quelques semaines tout au plus.

Regarde les commits sur v4-stable y’a rien là dessus :thinking:

une régression est rarement annoncé sur un change log :stuck_out_tongue:

Mais non au contraire :slight_smile: Jeedom « transforme » les mots « et » et « ou » en une syntaxe PHP valide, c’est bien le problème. Si on vire cette transfo intermédiaire il n’y aura plus de problème, PHP interprète bien les mots clé et pas les chaines de caractère, donc il ne transformera pas tes event(", and ,")

(au passage je confirme que c’est pas une regression récente, ça fait longtemps qu’on parle de cette transformation intermédiaire de Jeedom sur ce forum)

qui parle de changelog ??? je parle des commits sur le core, on peux rien cacher tout ce qu’on fait est lisible

1 « J'aime »

je comprend bien, mais la transformation a l’intérieurs des chaine de caractère 'une commande, c’est très récent, impossible que ce soit vieux, on a fait beaucoup de beta test avec le plugin sonarr en utilisant le séparateur d’épisode ", et " .

@hbe pourra le confirmer, on ne l’avais pas avant.

Et comme j’ai une annonce vocal quotidienne des téléchargements je m’en serais forcement rendu compte. Je peux concevoir d’avoir pas fait attention, ou alors avoir des épisodes unique sans séparateurs, mais pas a ce point.

Mais non, cela aussi doit sauter bien entendu, pas que le français :sweat_smile:

Tu saurais ou se situe cette Regex dans le core ?

dans utils.php la fonction evaluate

1 « J'aime »

Malgré tout les && / and – || / or ne sont pas identiques en php (précédence)

ok je vois, mais si la fonction n’a pas changé, est-il possible qu’on y faisais pas appel dans les contenu des retour de commandes avant ?

Je vous jure que je n’avais pas de soucis avant…

Il est aussi possible de préfixer le et par un \ si on ne veut pas qu’il soit interprété
image
image

Pour autant, n’y a t’il pas une non prise en compte de ce paramètre dans les dernières versions ? :

Sur le sujet des ET/OU, pour ma part, je trouve cela très bien pour les non initiés à l’algorithmie. Il est plus facile de comprendre un ET qu’un &&. Ceci va clairement dans le sens d’une ouverture de Jeedom à des publics non informaticiens.

Norbert

2 « J'aime »

je suis d’accord avec toi pour les ET/OU, comme pour ton \ j’ai contourné en enlevais l’espace entre ma virgule et le « et » que qui ne pose pas de problème pour une annonce vocale. Hormis cela je pense qu’il peut y avoir d’autre commande qui retournerons ces mots.

Par exemple même dans sonarr/radarr, il suffit qu’un titre contienne ces mots et contrairement a mon séparateur ou j’ai la main, un titre de film/série contenant un ET/OU cela sera impossible de le gérer.

Mais je le répète, il y a bien régression (récente), si ce n’est pas la fonction, cela doit être dans son utilisation. Y avait il bien utilisation de l’evaluate sur les commandes dans les scenarios avant ?

Bonjour,

Petit Mea-culpa !

Là ou j’avais raison c’est que ca fonctionnais bien avant car cela fonctionne encore.
Le remplacement n’est présent que dans le Testeur d’expression, et dans les scenarios les résultats des commandes restent intact.

Pour ceux que ca intéresse mes commandes rejetés par Alexa était due as des message trop long (limite a 250 caractères) et non au &&. Petit PR dans Alexa-api pour contourner le problème qui devrait être dispo dans la prochaine beta.

Merci a ceux qui ont pris un peu de temps pour chercher :wink:

1 « J'aime »