En essayant de paramétrer des scenarios avec MQTT et en explorant les possibilités, je me rends compte qu’il n’est pas possible de manipuler les objets en format String par scenarios simplement et logiquement, que ce soit en faisant un SETVAL dessus (lui affecter la valeur d’un autre STR en mémoire) ou une comparaison simple (= ou !=) entre 2 chaines.
J’aimerais comprendre le pourquoi d’une telle limitation, et demander si c’est possible d’implémenter ça dans une future MAJ.
Un exemple (celui qui m’a fait me rendre compte de cette impossibilité) : je manipule des vannes thermostatiques en zigbee via zigbee2mqtt, et les commandes à envoyer dessus pour les manipuler ou les infos qu’elles envoient sont des STR32. Du coup je dois ruser et créer beaucoup plus d’objets MQTT que nécessaires - un par ordre différent et par vanne, en fait (open, close, mode boost, etc.) alors que ce serait si logique de modifier par scenario le STR32 du payload dans le JSON. Et je n’ai pas encore trouvé le moyen de gérer les infos STR32 en provenance des vannes sans bidouiller de manière vraiment sale.
Mais je vois bien d’autres cas où ça pourrait être très utile de pouvoir manipuler des STR simplement.
Donc :
1: si quelqu’un voit ou sait le pourquoi du fait que ce n’est pas implémenté, ça m’intéresse
2: si vous voyez des cas d’usage sympathiques qui pourraient inciter GCE à développer la fonction, pourquoi ne pas le dire ici ?
bonjour,
des évolutions ont déjà été demandées concernant les manipulations de Strings.
Je pense que c’est dans la ToDo list, mais non prioritaire pour le moment.
Nouveaux produits à sortir, manque de composants, …
bonne journée
Merci pour ta réponse.
Je me doutais bien que quelqu’un y avait déjà pensé et fait la demande, tant cette limitation est frustrante dès qu’on se met à en avoir besoin. Mais bon, c’est rassurant d’en avoir la confirmation
Je comprends bien les priorités liées à la situation actuelle du marché des composants et à la petite taille de GCE ceci dit, aucun souci là dessus. Et l’IPX est toujours un jouet fantastique pour moi, j’en profite pour saluer encore une fois ici l’extraordinaire travail de GCE et leur envoyer un grand merci.
Enfin voilà, c’était une bouteille à la mer…
D’ailleurs en parlant de ca, comment sont gérées les priorités ? Y a t-il une liste quelque part ?
Une idée qui vaut ce qu’elle vaut, au moins pour les nouvelles fonctions : pourquoi ne pas faire participer la communauté sur les fonctions qu’elle souhaite voir arriver en priorité (vote, ou sondage, etc., GCE restant évidemment maitre de la décision)? Ca me semblerait intéressant. Rien déjà pour voir les cas d’usage des autres utilisateurs et pourquoi pas s’en inspirer pour chez soi.
GCE l’a déjà fait, mais ça devient vite ingérable tant les demandes sont diverses.
GCE recueille donc les demandes et les met à l’ordre du jour quand un nombre suffisant d’utilisateurs en fait la demande, mais ceci en parallèle des sorties de nouveaux produits et du calendrier de production.
je ne pense pas que la taille du BE change quelque chose (GCE l’a doublé pour gérer la nouvelle gamme).
Ce qui gère la priorité est le ratio quantité de travail demandé par un changement / le nombre de clients intéressés par ce changement.
Merci à vous deux pour les précisions.
Du coup j’ai de l’espoir, ca me surprendrait vraiment que la manipulation des strings ne soit pas une demande qui intéresse vraiment les utilisateurs, surtout ceux qui utilisent MQTT sur l’IPX (mais pas que).
pour sourire, 3 alpha testeurs de l’IPX V5 ont généré 349 demandes d’évolution
on va dire que le BE était content quand ça s’est arrêté après 9 Alpha et 5 Béta
C’est comme quand tu dois lâcher une grosse somme d’argent pour un achat plaisir : ca pique sur le moment, mais t’oublies vite la douloureuse. Et ce qui en résulte, t’en es content pour longtemps…
Puis bon, si ca a incité une entreprise locale à embaucher pour repondre aux demandes, c’est du benef
après 9 Alpha et 5 Béta 
