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.
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.
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.
Mais non au contraire 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)
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.
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.
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 ?
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