@Sescandell
chat-gpt : donc ici le device (qui doit être un commutateur) lorsque qu’il reçoit une commande « passe de 0 à 1 » passe le device à 1 puis envoie un retour « commande executée, passé à 1 » ou un message du même genre
Dans le contexte des dispositifs Z-Wave, has_feedback fait probablement référence à une fonctionnalité permettant de déterminer si un dispositif a reçu un retour d’information (feedback) après avoir envoyé une commande.
Le protocole Z-Wave est conçu pour être bidirectionnel, ce qui signifie que les dispositifs peuvent non seulement recevoir des commandes, mais également envoyer des retours d’information pour indiquer si une commande a été exécutée avec succès ou si une action a été réalisée. Cette fonctionnalité est souvent utilisée pour assurer la fiabilité des commandes et pour obtenir des informations sur l’état des dispositifs.
Ainsi, lorsque has_feedback est utilisé dans le contexte d’un dispositif Z-Wave, il indique généralement si ce dispositif est capable de fournir un retour d’information après l’exécution d’une commande. Cela peut être utile pour les systèmes domotiques ou de surveillance, où il est important de savoir si les commandes envoyées aux dispositifs ont été effectivement exécutées.
Ma question manquait peut-être de contexte : il s’agit d’une propriété côté Gladys et non propre à zWave.
J’ai suivi rapidement le code. Je vois une utilisation sur un saveState, mais je n’ai pas remonté plus. Pierre Gilles doit savoir répondre. Sinon je remonterai la piste.
@Sescandell le has_feedback ca veut dire que l’appareil au bout envoie un retour d’état après que Gladys lui ait envoyé une commande.
Ça permet à Gladys de savoir si elle doit enregistrer la valeur localement en cas de contrôle, ou si elle doit attendre que l’appareil renvoie un évent disant « j’ai bien été contrôlé ».
Exemple de has_feedback = true :
Je contrôle une prise connectée depuis Gladys → Gladys envoie une commande à la prise → la prise envoie un évent « state changed » à Gladys → Gladys sauvegarde le nouvel état de la prise.
Oui j’ai vu le coverage… mais ce sont des cas que le linter m’oblige à ajouter pour « rien »… je vais voir ce que je fais pour les traiter. Je pense que dans ce scénario je vais retourner une valeur undefined, et si undefined cela sous entendra « demande inconnue » et donc « annulation de la demande ». C’est ce qui me semble le plus logique.
Je vois si je peux faire ça ce soir. Sinon ce sera semaine pro, je vais être absent 1 semaine là
Petit bug à signaler sur l’integration zwave, j’ai un appareil zwave par pièce pour gérer chaque radiateur. Dans zwavejs-ui j’ai donc déclarer en nom Radiateur et location la pièce.
Sauf que dans Gladys j’ai que des radiateurs qui s’affichent (normal), mais difficile de savoir qui est qui. Peut-être ajouté la location dans un endroit pour qu’on puisse différencier chaque device? Mais j’ai peur que cela phase doublon avec la pièce Gladys. Comment vois-tu la chose @pierre-gilles ?
Pour en revenir au bug, du coup j’ai un message quand j’essai d’ajouter mes radiateurs à Gladys
Il y a un conflit avec le selector qui n’est pas unique.
En regardant le code je n’ai pas vu de selector dans l’integration zwavejs-ui donc je pense que le selector est formé à partir du name du coup grâce à cette fonction.
J’essaie de proposer quelque-chose pour corriger le selector.
EDIT: En ajoutant le selector je peux sauvegarder tous mes devices
@Sescandell Merci pour la PR sur la température + puissance, ça me parait très bien J’ai mergé et ça partira dans la prochaine version de Gladys ! Je mergerais le site quand la release sera live
@_Will_71 Ta PR est bonne pour moi aussi, par contre du coup il y a un petit conflit avec la PR de @Sescandell que j’ai mergée juste avant, tu peux regarder ?
: donc ici le device (qui doit être un commutateur) lorsque qu’il reçoit une commande « passe de 0 à 1 » passe le device à 1 puis envoie un retour « commande executée, passé à 1 » ou un message du même genre
Hâte de voir ça 
