Dans le tableau des commandes, donner la possibilité d’ajouter des commandes manuellement. Par exemple je voudrais ajouter sur un dimmer une commande spécifique qui fixe la luminosité à une valeur donnée ; bien sur je pourrais faire un virtuel mais c’est comme cela que je faisais dans le plugin zwave
exemple de commande:
Alive/asleep: je vois bien l’intérêt et la valeur de cette info mais de mémoire elle n’est pas publiée par le discovery.
Soit elle l’est et donc elle a sa place dans la gestion du plugin, soit elle ne l’est pas et alors le plugin ne la gérera pas.
Ceci dit, faudrait que je test si ca remonte via le « availability », concept qui existe sur le discovery mais que je n’ai pas encore géré (ce n’est pas beaucoup utilisé excepté par zigbee2mqtt)
Ici la commande slider (par exemple) existe déjà mais toi tu veux en faire une autre (genre message) ou tu forces une valeur; c’est ca?
Je comprends l’idée mais je dois y réfléchir. Je ne veux pas laisser l’utilisateur créer n’importe quelle commande et devoir la configurer lui même.
Tu peux détailler le cas d’usage concret? Pcq dans un scénario par exemple ca n’apporte rien, tu peux utiliser le slider directement
j’avoue que le scénario pourrait le faire avec le slider
2: j’ai fais une commande info « luminosité haute » ; c’est cette commande qui décide de passer le dimmer à 75% par exemple, du coup le scenario appelle luminosité haute , c’est utile quand madame décide de changer la valeur, je n’ai pas à le changer à plusieurs endroits.
et puis je peux faire un virtuel aussi. donc c’est pas très gènant.
1: en effet c’est plutôt un problème de discovery, j’ai le même problème sur mes keypads zipato (autre post) avec des commandes qui ne sont pas dans le discovery publié par zwave-js-ui alors qu’il les appelle ensuite
cela dit ça me bloque pour passer tout sur mqtt discovery car ce sont les commandes info d’activation/desactivation de mon alarme.
au moins en workaround tu peux aussi stocker la valeur voulue dans un virtuel (ou une variable si tu préfères) et dans le scénario utiliser la commande slider d’origine mais avec ta valeur venant de là ou tu l’as mises; c’est peut-etre plus simple que de faire une commande action dans un virtuel
Je voulais donner un mot d’explication sur le pourquoi je ne veux pas juste ouvrir la création de commandes: pour l’instant, si le topic change par exemple (et que le payload du discovery est bien mis à jour), le plugin retrouve la commande et met à jour sa config: ca m’est déjà arrivé plusieurs fois de modifier le nom de l’entité d’une prise sur zigbee2mqtt (qui se retrouve dans le topic du coup) et pas de soucis, c’est adapté directement sous jeedom
si je laisse les configs, cette partie ne fonctionnera plus; ou au contraire, il ne faudrait pas que l’utilsateur configure une commande list avec 3 niveau de luminosité et que le plugin repasse dessus en corrigeant par une commande slider parce que c’est ce que dit la config
Donc je suis pas contre, ca pourrait être sympa, mais je dois y réfléchir pour essayer d’y trouver une solution adaptée.
Oui je comprend.
C’est zwave-js-ui qui ne fait pas la déclaration mqtt discovery correctement pour certains champs de la classe 113.
je vais regarder si je comprend qch au github
Je crois que j’ai peut être un patch à proposer dans zwave-js-ui:
dans api/lib/Gateway.ts
j’ai l’impression qu’il ne publie aucun Event Notification vers mqtt discovery
il ne gère que les objet qui ont un state persistent, pas ceux qui sont stateless
dans le
case CommandClasses.Notification: à la ligne 1465
à la place de
à la ligne 1572
} else {
return
}
} else if (valueId.stateless) {
// Event-type notification: fires momentarily, no persistent state
// e.g. Keypad lock/unlock operation
cfg = utils.copy(hassCfg.sensor_generic) // or whatever we agree on
cfg.object_id = utils.joinProps(
'notification',
valueId.property,
valueId.propertyKey,
)
cfg.discovery_payload.icon = 'mdi:alarm-light'
} else {
return
}
