Modifications de jeedom::evaluateExpression() -> bug?

Bonjour,

Depuis ces 2 commits c6887fd & 430f004, jeedom::evaluateExpression() est en mesure de retourner une valeur de type Array (notamment dans le cas du passage d’un tableau json en $_input).

Est-ce normal et attendu ? Précédemment le retour n’était que de type bool, int ou string.

Avant les commits :

public static function evaluateExpression($_input, $_scenario = null) {
	try {
		$_input = scenarioExpression::setTags($_input, $_scenario, true);
		$result = evaluate($_input);
		if (is_bool($result) || is_numeric($result)) {
			return $result;
		}
		return $_input;
	} catch (Exception $exc) {
		return $_input;
	}
}

Après les commits :

public static function evaluateExpression($_input, $_scenario = null) {
	try {
		return evaluate(scenarioExpression::setTags($_input, $_scenario, true));
	} catch (Exception $exc) {
		return $_input;
	}
}

Merci,
Bad

Salut,

Précédemment le retour était booléen ou numérique sinon c’est l’input qui était retourné. L’idée de ce commit est de pouvoir utiliser des ternaires pour retourner un string directement dans Jeedom le cas échéant.

C’est en beta donc le bon fonctionnement doit être validé par vos retours justement.

Du coup tu vois une limitation suite à ces modifications ? Tu as un cas concret à partager si besoin ?

Salut @Salvialf,

Non je n’y vois pas de limitation à proprement parler, c’est un ajout fonctionnel, mais je ne comprends pas trop le cas d’usage que tu présentes, peux-tu m’en dire plus ?

C’est aussi un changement de comportement. Dans le plugin jMQTT, par exemple, nous traitons souvent des messages (valeurs) en JSON et ce changement a pour conséquence la transformation automatique de JSON en array, alors qu’ils restaient en string avant. En soit, ce n’est pas un problème, un simple test à rajouter pour repasser l’array en JSON.

Vu que le commentaire du commit était très succinct et que la modification ressemblait plus à une simplification un peu rapide du code, je me suis demandé si ce n’était pas une erreur.

Merci.

Ce commit permet par exemple de faire un virtuel info/string « heures creuses/heures pleines » avec un simple ternaire :

time_between(date('Hi'), 2230, 630) ? 'Heures creuses' : 'Heures pleines'

Mais effectivement si le retour est un tableau il pourrait renvoyer l’input, je vais y regarder de plus près dès que possible

Merci, je comprends mieux.

C’est profitable aussi pour jMQTT avec l’exemple de configuration suivant :

#513# → cmd info qui récup le champ « state » du tableau json dans le topic « dummy/set »
#514# → cmd action on doit envoyer au topic « dummy/set » exactement le texte {"state":"ON"}
#515# → cmd action off doit envoyer au topic « dummy/set » exactement le texte {"state":"OFF"}
#516# → cmd action toggle doit envoyer au topic « dummy/set » le texte {"state":0} ou {"state":1}

Avant la v4.2.2 :

  • les commandes #514# et #515# envoyaient bien ce qu’elles devaient → OK
  • la commande #516# envoyait {"state":1-0} ou {"state":1-1} → NOK, impossible à gérer

Après la v4.2.2 (en l’état) :

  • les commandes #514# et #515# envoient {'state':'ON'} ou {'state':'OFF'} → NOK
  • la commande #516# envoie {'state':0} ou {'state':1} → NOK, mais gérable

Suite au patch en préparation pour remettre un coup de json_encode les array en v4.2.2 :

  • les commandes #514# et #515# envoient bien ce qu’elles devaient → OK
  • la commande #516# envoie bien {"state":0} ou {"state":1} → OK

 
Donc c’est un changement positif, mais il peut poser problème si l’appelant n’a pas prévu les cas où autre chose que bool/int/string lui serait renvoyé.
Selon moi, la sérialisation devrait être réalisée dans le core pour encadrer les types retournés.

Ca lève d’autres questions auxquelles je n’ai pas encore cherché de réponse :
Suffit-il (pour tout le monde) de json_encode une valeur de sortie autre que bool/int/string/null ?
Le json est-il le seul format interprété « à la volée » par evaluateExpression() ?
Sinon, quelle serait les bonnes transformations et comment les appliquer ?

Je reste à votre écoute :wink:

J’ajoute un autre cas de figure que j’ai eu hier sur toutes les lampes avec slider :
image

Cette commande c’est retrouvé NOK hier suite MàJ core, j’ai remonté la sav du 29 et c’est de nouveau OK
Jeedom 4.2.5
jMQTT béta du 2021-10-26 01:01:05

As-tu eu le temps de te pencher sur le sujet de ma demande ?
Dois-je faire un PR sur le Core pour avoir une base de discussion ?

Merci

Bonjour,

Je pense que ce sujet est lié :

Oui je pense que c’est lié mais la team a répondu : il ne devrait pas y avoir de json ni de guillemets ici, c’est au plugin de traiter l’input.

Si je comprends bien, une commande action ne doit pas contenir de JSON, c’est bien ça ?
Ce n’est pas envisageable en MQTT, car beaucoup d’ordres doivent être construits en JSON.

1 « J'aime »