Widget multistate update en V4

Je suis en Jeedom 4.4.8.1 sous bullseye. Créer un widget simple (On/Off) c’est ultra facile.
Créer un widget multistate me paraissait assez facile aussi. Mais l’update automatique lors d’un changement de valeur ne fonctionne pas.
L’update manuel et automatique après une minute fonctionnent sans problème.
La doc mentionne qu’il faut ajouter du code dans le widget:

<script>
    Jeedom.cmd.update['#id#'] = function(_options){
      $('.cmd[data-cmd_id=#id#]').attr('title','Date de valeur : '+_options.valueDate+'<br/>Date de collecte : '+_options.collectDate)
      $('.cmd[data-cmd_id=#id#] .state').empty().append(_options.display_value +' #unite#');
    }
    Jeedom.cmd.update['#id#']({display_value:'#state#',valueDate:'#valueDate#',collectDate:'#collectDate#',alertLevel:'#alertLevel#'});
</script>

J’ai bien essayé de comprendre le contenu de la doc, mais ma petite tête se fracasse sur le mur de mon ignorance: Comment insérer du code dans mon wiget? Comment nommer le fichier? Ou le mettre? Dois-je modifier quelque chose? Mes essais n’ont rien changé. Voilà ce que j’ai fait:


Merci à qui prendra cinq minutes pour renseigner un pôvre interno-naute, bien dans le besoin.

Bonjour,

Aucun code à ajouter et l’update auto fonctionne.

Si ce n’est pas le cas chez vous je pencherais plutôt pour le fait que la valeur de la commande n’a pas changée => comment est mise à jour cette commande?

Bonjour Mips,
Votre réponse me conforte dans mon idée que l’ajout de code n’était pas indispensable pour faire des widgets relativement simples, mais bien pratiques et bien jolis…
J’ai actuellement plusieurs solutions pour changer et contrôler le changement d’une valeur:

  • Deux plateformes jeedom (Production et test)
  • MQTTexplorer (Résultat immédiat)
  • BSB-LAN (Résultat sur cible)
    Je pense donc pouvoir affirmer que l’auto-update immédiat ne fonctionne pas avec certitude.
    Le premier point mentionné dans le post était: Un widget simple fonctionne. Par contre un widget multistate pose problème lors de la mise à jour suite à la commande.
    Lorsque vous dites « L’update auto fonctionne » comment l’avez-vous validée? Je ferai la même chose sur mon installation, si possible pour essayer l’aller plus loin dans la recherche de la solution à mon problème.
    Mosquito tourne sur mon Jeeserver de production. Le probléme est avéré sur les deux serveurs. Le refresh semble bien s’effectuer (l’indicateur tourne deux secondes puis s’arrête) mais l’affichage reste en position initiale.
    Merci encore pour vos conseils.

Donc si vous regardez la valeur de la commande info dans la liste des commandes de l’équipement, elle a une valeur X mais dans le widget (ouvert avant le changement de valeur), c’est toujours la valeur Y?

il vaudrait une capture de la page santé jeedom également (à fournir à chaque demande pour qu’on ne doive pas demander systématiquement)

Voici la capture de la santé de mon serveur de production:


J’avais vérifié la santé avant de poser une question, mais vous faites bien de rappeler.
En ouvrant deux instances de jeedom (GUI et tableau des commandes), j’actionne la commande sur la GUI qui passe de « Marche » à « Arrêt » alors que la commande reste sur « Marche » dans le tableau de commande jusqu’à la mise à jour programmée sur une minute. Vous aviez bien compris.
L’allure commandée (Arrêt) reste indiqué dans la liste jusqu’à l’update, puis disparait. Corrolaire?
Si je lance un test avant l’update programmée, la valeur est mise à jour et l’update du widget se fait bien.

Donc c’est ce que je disais: le widget n’a aucun problème de refresh, il indique l’état de la commande (que vous voyez dans la liste des commandes) qui est resté sur « marche » jusqu’à ce que votre virtuel soit rafraichi (par l’auto-actualisation dans ce cas-ci);
donc le « problème » c’est que votre virtuel n’a pas la valeur que vous voudriez avoir.

c’est quoi ce virtuel? pourquoi avoir un virtuel et ne pas utiliser l’équipement source directement?

Pardonnez moi, pourquoi parlez vous de virtuel? Je n’ai pas utilisé de virtuel ici. J’utilise directement l’équipement.

ok j’ai regardé trop vite la capture écran et je croyais que c’était un équipement virtuel

donc le « problème » est sur le plugin qui ne rafraichi pas immédiatement la commande en question mais seulement chaque minute

Oui c’est bien ça, et c’est très génant à l’utilisation. Lorsque ça ne répond pas immédiatement, c’est « L’ANGOISSE » pour l’utilisateur. Vous savez bien… Le « WAF »

ok mais donc ce n’est pas un problème ni sur le widget multi-state ni sur les widgets en général qui ne font qu’afficher la valeur d’une commande info; si cette commande info n’est pas à jour, on ne peut rien faire ici.

il faut faire un post sur le plugin pour savoir s’il peut mettre à jour la valeur info plus rapidement.

Je vais donc poser la question idiote: Comment fait-on un post sur le plugin?
Je pensais que la commande refresh était là pour faire la mise à jour.
Comment puis-je la faire exécuter après la commande « Mode » ? Y a t-il une hiérarchie dans l’exécution des commandes suivant leur position dans le tableau?
Merci encore.

en créant un post dans la catégorie du plugin avec l’étiquette du plugin

c’est certainement le cas

ce n’est pas automatique, en contournement vous pouvez configurer une action après exécution de la commande via la config avancée de la commande « mode »
ce n’est pas très propre mais ca fonctionnera probablement:

non mais question pas relevante puisqu’aucune commande n’est jamais exécutée automatiquement.

Effectivement le contournement fonctionne. Pour la beauté de la chose, pourquoi dites-vous que ce n’est pas très propre?
Il y a effectivement un petit quelque chose pas très clair quelque part, puisque les widgets simples se mettent à jour instantanément. Donc tout n’est pas parfait.
Pour ma part, vu la complexité de l’application Jeedom, je pardonnerai bien volontiers ce petit détail et je trouve le contournement très élégant car la solution existe nativement. Et ça c’est super!
Encore un grand merci pour votre aide et votre réactivité. Le support sur le forum c’est vraiment quelque chose.
PS: La dernière partie de la doc sur la conception de widgets (Mise à jour des valeurs) m’avait un peu embrouillé les méninges (Il n’en reste pas beaucoup d’actives à c’t’heure)

parce que je trouve que cela devrait être géré dans le plugin directement, ce n’est pas super qu’un utilisateur doive configurer ce genre d’action.

le widget multistate aussi se met à jour instantanément, vous n’avez pas encore bien compris la différence entre un widget et un équipement je pense:

  • le widget est une représentation fidèle et instantanée de la commande, il ne gère aucun état ni aucun refresh, il se contente d’afficher la valeur
  • l’équipement et ici la commande gardait une valeur obsolète et ca c’est le plugin utilisé qui s’en charge.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.