Ok merci pour la réponse
mon questionnement était que je ne voulais pas me lancer dans un correctif sans être sûr que cela ne changerait pas.
c’est vraiment un bogue caché que je n’avais pas vu.
Je confirme il ne faut pas faire ça il ne faut pas mettre de " a cet endroit la, c’est au plugin d’avoir l’intelligence de les ajouter (ou pas si pas besoin) . En aucun cas il ne devrait avoir dans ce type de champs du json ou des "
Re,
Merci @Alexandre je vais regardé
Ok mais ce n’était écrit nulle part.
De plus j’ai vraiment un souci pour résoudre ce problème.
J’ai des commandes custom qui sont de la forme :
"1":2,"3":"open","4":true
le nouveau comportement de la 4.2 va enlever les " sans échappement ni rien.
il aurait été préférable de les échapper plutôt que de simplement les enlever. Je suis coincé dans plein de cas.
Pouvez-vous m’apporter une solution ?
les solutions qui fonctionnent consistent à tout entourer de simples guillemets, ces derniers sont supprimés et les doubles restent. sinon de mettre des guillemets avec échappement en plus des guillemets à l’extérieur.
J’ai besoin de ces double guillemets sinon mon plugin ne pourra pas fonctionner.
Une solution est de les échapper par autre chose sans perturber l’interface utilisateur.
Il me semble que le core pourrait au lieu de supprimer les guillemets de les échapper.
Il me semble que les réponses apportées par la team explique de ne pas utiliser de json ou der guillemets à cet endroit et que c’est au plugin de traiter les valeurs.
non ce n’est pas une réponse.
Le périphérique attend des guillemets et la commande ne peut pas être reconstruite.
Plutôt qu’une suppression simple, il est préférable d’échapper pour écrire/lire la bdd
On ça remettre les choses en place ce changement on l’a pas fait pck on s’est dit un matin tien on va enlever les guillemets en plus ça sera cool ça emerdera les dev. On a la fait car on a un nombre significatif d’utilisateur qui nous l’ont demandé !!!
Donc là pour ton cas pour être propre faut revoir la syntaxe avec un truc type
1=2,3=open
Et dans ton plugin tu fais la mise en forme attendu par l’API que tu contactes.
Loïc,
je ne comprend pas cette demande. Mais si elle est justifiée pourquoi pas. Dans ce cas pourquoi ne pas échapper les double guillemets surtout qu’il y a un moyen de bricoler en mettant des simples tout autour, le but ne sera donc pas atteint.
J’ai deux lampes qui vont ne plus fonctionner. Yeelight qui a des commandes du type :
“id”:1,”method”:”set_scene”,”params”:[“cf”,0,0,”500,1,255,100,1000,1,16776960,70”]
et l’exemple du dessus chez Tuya mais qui sont entrés directement par l’utilisateur pour faire des modes complexes. Je n’ai pas moyen de détecter ce que l’utilisateur va entrer.
Mon souci est l’interface utilisateur d’une part et d’autre part les configs d’utilisateurs de 4.1 qui ne vont plus fonctionner et je ne vois pas pas faire un update de chaque commande sans faire de bêtises vu la complexité parfois.
De ce que je comprends, les guillemets sont bien mis dans la base puisque restitués à l’affichage ou alors je n’ai pas compris. C’est lors de l’utilisation de :
$CmdUp->getConfiguration('parameters');
qu’ils sont filtrés.
Je n’ai pas de solution à mon problème puisque l’utilisateur entre lui-même les commandes complexes contenant des guillemets.
Je sais pas quoi je suis un simple exécutant on me demande je fais c’est tout rien de plus rien de moins… Les utilisateurs voulez ce nettoyage pour éviter les double " lors de l’évaluation de test je crois je l’ai fait c’est tout. Je ne suis pas là pour réfléchir (quand je le fait ça part au mieux en discution interminable et a la fin on ne me crois de toute façon pas et je passe pour le méchant). Maintenant l’utilisateur veut je fais c’est tout, ça casse tout ben tant pis l’utilisateur est content et moi j’ai pas perdu des heures a lui expliquer que non c’est une mauvaise idée et que ça finisse sur d’autres forum en Loïc c’est un con il dit toujours non ils sont vraiment pas sympa chez jeedom faut pas y aller.
Un peu de calme voyons.
On ne peu pas reprocher à @bernardfr.caron de remonter une transformation qui a un fort impact et qui cherche avec l’équipe le meilleur des 2 mondes (avant et après 4.2).
Essayez d’échanger intelligemment. je ne pense pas qu’il y ait des reproches que ça soit envers l’équipe Jeedom ou le dev du plugin .
Allez je vous laisse continuer cette analyse fort intéressante.
Bonjour Bernard,
pour mes plugins, j’ai laissé tombé depuis longtemps l’idée de sauvegarder du json dans les configuration… car j’avais souvent des problèmes (parsé/pas parsé, tronqué à une certaine taille etc). j’ai le même cas que toi dans un plugin mais je dois stocker un gros JSON et à cause de ce tronquage, j’ai du passer par un fichier .json que je stock dans dossier le plugin… donc au final, je n’ai pas ton problème
je sais c’est plus lent, je sais c’est pas super élégant… mais ca serait peut-etre une solution de contournement pour toi ici ?
Clairement j’évite toute polémique et ma préoccupation ce sont les utilisateurs qui ne peuvent plus fermer ou ouvrir leurs volets.
J’entends l’argument de supprimer les guillemets dans la BDD.
Pour moi ils sont bien mis dedans puisque lorsqu’on en met dans une commande actions et que l’on revient dans l’interface ils y sont toujours. Il sont filtrés lors de l’appel à
::getConfiguration()
De plus pour supprimer le problème il suffit de remplacer tous les doubles guillemets par des \" et que la totalité de la chaine soit entourée de double guillemets.
Le correctif va mettre encore plus de guillemets dans la BDD et il risque de sauter dans une nouvelle version.
La solution consistant à construire la chaine à envoyer au périphérique à partir de données sans guillemets n’est pas possible pour 2 protocoles gérés par le plugin.
Pourquoi ne pas faire un échappement avant/après écriture dans la bdd ?
Bonjour,
Le soucis n’a rien a voir avec le stockage en DB… C’est la fonction evaluate qui fait ca je pense.
Aucun soucis pour l’échappement je vais l’ajouter. Par contre je préviens ca va faire planter enormement de scénario chez plein d’utilisateur donc quand ils me demanderont le retour arriere je le ferais jusqu’a ce que tu me demande de les remettre et ainsi de suite.
…Sinon l’auteur du plugin trouve une solution pour se mettre en accord avec le core…
J’ai arreté de me battre avec les gens je fais maintenant c’est le dernier qui parle qui a raison
on discute pour trouver une solution.
Donc c’est
jeedom::evaluateExpression ($formula)
qui me pose souci
j’avoue avoir été trompé sur le fait que c’était dans la BDD et pour moi la valeur stockée.
Je regarde de plus près
et je ne doute pas que vous allez la trouver 
Bon courage à tous !
$parameter['parameters'] = str_replace('"', '\"', $parameter['parameters']);
$parameter['parameters'] = jeedom::evaluateExpression ($parameter['parameters']);
$parameter['parameters'] = str_replace('\"', '"', $parameter['parameters']);
Ma seule remarque est qu’il aurait fallu prévenir. J’ai testé ON/OFF l’interface mais pas ce cas.
En beta pour ceux qui sont en 4.2
2 « J'aime »
Question tu fais de l’évaluation d’expression dans ton code ? Genre #cmd_id# == 1 ? Car je vois pas pourquoi tu utilises cette fonction…
Mais oui on aurais du prévenir et j’en assume l’entière responsabilité si ca vous arrange, de toute facon tous les soucis jeedom son uniquement du a Jeedom SAS et jamais a personne d’autre.