Permettre aux commandes actions de sous-type other (ou message ?) le support de valeur dynamique

[Minscof]

Bonjour,

J’avais besoin d’une commande action qui renvoie une chaine de caractères « saisie par l’utilisateur » et qui soit liée à une commande info, c-à-d que cette commande info prenne la valeur de la commande et qu’inversement, quand la commande info à une valeur, le widget associé aux commandes actions puisse en tenir compte.

En regardant le code du core de jeedom, et en faisant des tests, je me suis aperçu que cette fonction n’est « complètement » implémentée que pour des commandes actions de sous-type slider ou color.

Dans mon cas, la valeur n’étant ni une valeur numérique (slider), ni une couleur, mais une simple chaine de caractère, je voulais utiliser une autre sous-type qui porte sur des valeurs de type chaine.

Les sous-types other, select et message supportent les chaines de caractères, mais pas avec toutes les possibilités des commandes slider et color.

Pour other, la valeur de la commande est définie statiquement au moment de la déclaration de la commande (paramètre value dans configuration). Je n’ai pas su faire prendre en compte une valeur saisie par l’utilisateur.

Pour message et select, qui supportent toutes les 2 des valeurs saisies/choisies dynamiquement par l’utilisateur, j’ai rencontré d’autres limitations.

Je crois que message ne supporte pas l’association à une commande info.

Et enfin ni message, ni select ne supportent de mettre à jour une commande info quelconque via le mot clé updateCmdId, supporté par le core de jeedom.

Ma demande est d’améliorer les commandes de sous-type other en gérant le mot clé value (par exemple ou string…) à la manière des mots clés slider et color pour supporter des valeurs quelconque saisies par l’utilisateur.

Mon contexte fonctionnel pour avoir besoin de cette fonction est de construire une commande pour sélectionner 1 ou plusieurs jours d’une semaine afin de réaliser un planificateur pour un dispositif d’arrosage.

C’est une simple suggestion d’amélioration, sachant qu’on peut déjà « détourner » les commandes slider pour faire cela.

Je n’ai pas su ajouter ce message dans la catégorie suggestion…

[Loic]

Bonjour,
C’est vraiment pas clair, j’ai absolument pas compris ce que tu veux…

[ajja17orange]

bonjour,
vu ton nombre de demande ici ou lå . je m’abstenais (car j’ai pas envie de le faire). comme input date-local, calendar ou clock.
mais tu es persévérant.

pour te donner le comment je vois ta solution

tu créés un widget action slider base « input checkbox »
celle ci reporte sur l’info autre

tu auras
lundi,mardi,… si coché ou non
si tu veux pommes,poire. …

ensuite ton besoin sera si l’info contient ou pas le(s) mot(s) qui t’interesse
et jeedom l’intègre

et tu peux mettre en forme ton checkbox

Pour ton plug si tu regarde le plug todo-list il intègre un input calendar alors qu’il n’existe pas de widget (hormis ma bidouille/creation)

[Minscof]

Bonjour @Loic,

Voilà visuellement le rendu du widget

voilà la définition des 2 commandes info et action pour faire cet affichage :

et voici le détail de la commande action de sous-type slider qui utilise la possibilité du core via les paramètre updateCmdId et updateCmdToValue

Concrètement, ma commande action gère une chaine de caractères de 7 lettres pour les initiales des 7 jours de la semaine.

Je n’ai trouvé que la commande action de sous-type slider pour faire ce que je voulais, alors que je ne gère pas une donnée numérique mais une chaine de caractères. J’avais cru comprendre que ce n’est pas le rôle de slider de gérer des chaines de caractères mais que slider est fait pour gérer des données numériques.

L’implémentation dans le core de jeedom des sous-types actions autres que slider et color me semble être moins complète et empêche de faire la même chose qu’avec ces 2 sous-types.

L’amélioration demandée est de compléter le core de jeedom pour permettre d’utiliser les commandes actions de sous-type other (voire select et message) avec les mêmes facilités que ce que le core permet pour slider ou color, sachant qu’avec ces autres commandes, la valeur est de la chaine de caratères.

Est-ce que c’est plus clair à présent ?

[Loic]

Non désolé toujours rien compris

[lunarok]

Par hasard, tu cherches pas la commande de sous type select ? Car la, un choix parmis 7 en type caractères, c’est un peu ca

[Minscof]

@Loic, je tente à nouveau de mieux expliquer, mais tu ne m’aides pas beaucoup en me disant que tu n’as rien compris .

J’ai besoin d’une commande action qui envoie une chaîne de caractères composée de 7 lettres, choisies par l’utilisateur.

Pour faire cela, la commande action de sous-type message parait le plus approprié. Est-ce que tu es d’accord ?

(La commande de sous-type liste(select) est plutôt destinée à choisir dans une liste fermée de valeurs, alors que le sous-type message permet de choisir les 7 caractères que l’on veut.)

Lorsque cette commande est soumise, j’ai besoin :
1 : qu’elle mette à jour une commande info qui lui est associée pour mémoriser les 7 caractères et
2 : qu’elle déclenche un traitement pour un équipement piloté par une extension du plugin blea.

Pour faire le point 1, le core met à disposition dans la définition d’une commande action, dans la section configuration les mots clés updateCmdId et updateCmdToValue pour mettre à jour une commande info, uniquement quand le sous-type est Curseur(slider) ou Couleur(color)

Ce paramétrage n’est donc pas pris en compte par le core quand la commande est de sous-type message.

L’amélioration demandée consiste à faire en sorte que ces 2 paramètres , updateCmdId et updateCmdToValue, soient pris en compte par le core pour toutes les commandes actions.

Est-ce que cette description du fonctionnement du core de jeedom est juste ?

Est-ce que tu comprends la limitation dont je parle à présent ?

[Loic]

Ok la j’ai compris et pas sur que ça soit possible malheureusement c’est pas aussi simple que tu le dis… Tu as 7 commandes actions qui doivent mettre une valeur dans une commande info en fonction de la valeur de celle-ci. Tu n’auras pas d’autre choix que de passer par un scénario en mode code la tellement c’est spécifique.