C’est bien l’idée que j’ai en tête, attendre d’autre avis, ce n’est pas forcement une demande perso.
Pas de soucis, c’était juste pour anticiper, car avec ces milliers d’utilisateurs, j’imagine déja plusieurs demandes « comment changer la couleur … »
Je me base aussi sur le plugin jmqtt, qui je pense est une bonne référence pour ce cas de figure,
Bad utilise un textarea, ce qui permet de pouvoir sélectionner/copier la valeur, ça ma souvent été utile pour débogage …, hors avec le span la valeur n’est plus sélectionnable.
Pour la couleur pas sur qu’il y ait de la demande en plus en gardant cette variable ça nous permet de facilement adapter la couleur aux clients lors de la vente en marque blanche. C’est quand même pratique.
Pour la sélection moi j’arrive parfaitement à sélectionner et copier la valeur même quand c’est pas dans un textarea. Je mettrais pas de textarea c’est pas un champs éditable c’est un champs d’information donc je ne vais pas surcharger l’affichage avec.
Si c’est bien état de commande, mais, si je ne m’abuse, tant que la commande n’est pas historisée, cet état ne rentre pas en base de donnée, donc reste en cache, je me trompe ?
Oui mais si c’est juste pour du cache faut pas le mettre dans une commande il y a des mécanismes pour le cache dans jeedom juste pour ça. Car le mettre dans une commande même non historisée ça reste consommateur a chaque maj de la valeur (scénario, listener, envoi en évent a l’ui et pas mal d’autre process…)
Je vais y réfléchir, mais à date 1 topic = 1 cmd, puis on affine avec du JsonPath s’il y a besoin.
jMQTT a toujours (bien) fonctionné de la sorte. Les payload >200 octets restent rare et >1Ko marginaux.
La question va probablement aussi se poser pour MQTT Manager, voir les dépendances.
Ne pas mettre tous les topic dans des commandes serait un chantier plus qu’ambitieux pour jMQTT.
Le plugin mqtt manager et la pour être une aide pour d’autres plugin il n’a as vocation à avoir des commandes et autre même si c’est possible.
Je connais pas du tout jmqtt donc je suis pas bien placé pour te dire comment faire mais a froid loi j’aurais fait :
un champs dans la commande qui donne le topic, un autre champs qui explique comment récupérer l’info dans la valeur du topic
lors de la réception d’un topic stockage de la valeur dans le cache de l’équipement avec comme clef celle du topic
une fois la valeur stockée mise a jour de toute les commandes utilisant ce topic pour mettre à jour la valeur de celle ci en fonction de l’autre champs expliquant comment récupérer la valeur
Après c’est a froid sans vraiment savoir comment marche le plugin donc sûrement a côté de la plaque
Le MQTT étant en temps réel, dès la réception d’un message sur un topic, on met à jour uniquement les commandes précises qui on besoin du payload :
si la commande a besoin du payload complet, on l’update,
si elle a besoin d’un morceau du payload (jsonpath), on l’update juste avec ce dont elle a besoin,
si aucune commande n’a besoin du payload, rien n’est stocké/updaté.
Ce n’est que dans le cas où un utilisateur a besoin d’un gros payload (ou qu’il conserve une commande inutile) qu’il y aurait potentiellement un souci.
Ok je vois donc pour moi les cas où l’ajout de l’état de la commande dans le tableau peut poser c’est un cas de mauvaise utilisation du plugin par l’utilisateur
La commande 16089 n’est censée existée que le temps de la découverte des « sous-commandes », puis une fois les sous-commandes créées par l’utilisateur, elle peut être supprimée.
pour une commande qui n’est pas (encore) valorisée mais qui a une unité définie → est ce qu’il ne faudrait mieux pas ne rien afficher plutôt que d’avoir seulement l’unité ?
Bonsoir,
Je pense que dans le sujet que tu cite, il y a peut-être confusion dans le tag, il est indiqué gsh par son auteur, hors en analysant les conversations, il semble que ça ressemble plus a googlecast (non officiel).
.