Je suis en Jeedom 4.2.12. J’utilise les plugins mode et virtuel et je récupère l’information du mode sélectionné dans un virtuel avec une commande de type autre puisque c’est du texte.
Apparemment le « et » est transformé en « && ». C’est la même chose dans le testeur d’expression.
(dashboard)
Par contre, dans la configuration et si j’affiche directement l’objet mode, c’est bon.
(configuration)
(dashboard)
Autre exemple avec un virtuel seul et des commandes de type autre. Il semble que c’est seulement en ne mettant pas de guillements ou d’apastrophes que le remplacement ne se fait pas. Mais si on omet de commencer par un mot c’est encore plus étrange vu que ce qui est après le « et » disparaît.
Je ne l’avais pas remarqué avant donc je pense que c’est relativement récent (quelques semaines). Peut-être un effet de bord d’une autre modification. J’imagine que le traitement des chaînes de texte et de savoir quand il faut interpréter ou pas n’est pas ce qu’il y a de plus simple.
Le and et or existent bien en php et n’ont pas la même precedence que && ||
On en discute de supprimer les et ou mais ça forcerai beaucoup de user à revoir leurs scénarios. En 4.3 la modale dans les scénarios propose les && || pour aller dans ce sens.
Dans une évaluation oui je serais d’accord, mais là on parle de chaînes de texte et donc du coup le « et » a toute sa place.
Cela éviterait en effet de mauvaises surprises mais je comprends l’hésitation.
Je ne comprends toutefois pas pourquoi ce phénomène apparaît aujourd’hui sur les commandes de type autre (et pas seulement sur les formules). Je suis quasiment certain que ce n’était pas le cas.
C’est pas pour tout de suite, et pour un script faut pas rêver, le risque de tout casser est grand … Faudrait récupérer toutes les expressions, remplacer les et et ou entourés d’espaces, et proposer une interface de validation. En automatique c’est trop dangereux, et je vois déjà ceux qui vérifieront pas …
Peu être que qqlun pourrait proposer un truc, pas le temps en ce moment mais pas d’urgence non plus.
Non, pas d’urgence, effectivement. Mais si on ne fait rien, on casse tout de toute façon le jour ou les ET/OU ne sont plus supportés.
Pas le temps non plus, mais ok pour tester un script si quelqu’un se dévoue.
Non, mais quand les tags sont arrivés dans jeedom, j’ai assez rapidement opté pour une architecture de mes scénarios en « fonction ». Histoire d’éviter les duplication de code et faire en sorte que mes équipements soient présents dans un minimum de scenarios.
Et comme j’essaye effectivement d’automatiser un max de truc, et que je suis sur jeedom depuis 2013, ben ca donne 430 scénarios
Moi je pense que vos discutions vont trop loin si elles sont de cet ordre.
L’intérêt de jeedom c’est d’être abordable par tous, si vous voulez ne vous adresser qu’à des programmeurs ça va réduire le champ des utilisateurs. Il y a beaucoup de gens qui ont mis en place leur système de manière succincte dans un premier temps et qui au fil du temps le reprennent pour ajouter des équipements. S’ils doivent reprendre un dictionnaire des correspondances à chaque fois ils abandonneront rapidement.
Interpréter un « et » ou un « ou » en langage informatique, c’est le rôle de la machine et ça doit rester transparent pour l’utilisateur comme les autres commandes qui facilitent la vie de tous les utilisateurs. Les puristes sauront mettre && || s’ils le préfèrent.
SELECT * FROM `scenarioExpression` WHERE `type` = 'condition' AND (`expression` LIKE '% ET %' OR `expression` LIKE '% OU %')
Par contre si tu a ’ et ’ dans un matches, ou genre #trigger# == "[Salon et salle][Prise][Etat]" ça passera aussi… C’est bien pour ce genre de choses qu’on ne fera pas de script automatique …
D’accord avec toi sur ce point. Et ayant converti des amis non informaticiens a Jeedom, j’apprécie aussi le fait de pouvoir coder en langage humain.
Par contre, j’ai lu que ca pouvait réduire un peu les perfs, et du coup, je migrerais bien mes scénarios en ET/OU pour les remplacer par des &&/|| (mais pas a la main! )
MErci pour la requete, je vais jeter un oeil sur ce qu’elle donne chez moi. Mais il est clair que je vais avoir des exceptions. Mais je me pose une question : si le moteur de scénario sait faire la différence entre un ET (condition) et un ET dans le nom d’une commande, pourquoi un script de migration ne saurait pas le faire?
Edit : ah ben non tiens, les équipements sont stockés avec leur id… cool.
En script php on peu aller plus loin qu’une commande sql oui, mais de là a être sûr qu’il n’y aura aucun soucis pour 30000 utilisateurs je prendrai pas le risque …
Bien sur, sinon on ne pourrai jamais rien renommer sans tout casser.
moi aussi je fais du Jeedom depuis des lustres et j’ai passé progressivement tous mes scénarios les plus compliqués en code natif php … comme ça fini les galères de relecture et des champs trop petits sur l’écran.
cela dit je suis d’accord c’est la galère de mettre à jour 1 par 1 er comme le dit kiboost je vois mal comment scripter ça en SQL simplement, sauf peut être à se prendre la tête à faire un procédure stockée avec des regex pour ne transformer que les " et " qui sont pas entre deux crochets. ça peut se faire aussi avec d’autre langage pour itérer, même avec du code php en scénario en parcourant les valeurs …
Au passage de Domoticz à Jeedom, j’avais hésité aussi à passer en php, mais l’éditeur de scénario de jeedom est tellement sympa, que je n’en ai jamais ressenti le besoin par la suite. (Sauf 2-3 exceptions, bien sur.
Pour le script SQL, franchement, j’ai beau regardé, je vois pas ou il pourrait y avoir des Et et des ou autres que des conditions dans des blocs de type condition.
Du coup, un update avec 2 replace imbriqués me semblent assez safe (dans mon cas)
Edit : update passé avec succès. merci Kiboost. Je vous dirais pour la différence de perf.
(dashboard)
(configuration)
(dashboard)
seigneur tu as domotisé un aéroport 
