J’ai installé le plugin Deconz pour piloter des volets roulants Profalux avec une clé ConBee2.
Ces volets sont détectés comme des lumières, avec utilisation du paramètre ‹ bri › (brightness) pour contrôler la position du volet.
Ca marche à peu près, sauf qu’il y a une double commande envoyée quand je modifie la position. Qui fait faire un double mouvement au volet.
En effet, lorsque l’on modifie le paramètre bri (via un slider par exemple, mais c’est pareil pour toute action/scenario que utilise la commande), le plugin Deconz rajoute automatiquement un deuxième paramètre ‹ on › en fonction de la valeur de ‹ bri › (ligne 897 dans deconz.class.php).
Côté Gateway, on se retrouve avec les appels suivants :
10:36:25:621 HTTP API PUT /api/0C894FF2A2/lights/3/state - 127.0.0.1
10:36:25:621 Text Data: {"bri":0,"on":false}
11:02:43:391 HTTP API PUT /api/0C894FF2A2/lights/3/state - 127.0.0.1
11:02:43:391 Text Data: {"bri":197,"on":true}
C’est le ‹ on › ajouté automatiquement qui cause le problème.
Que puis-je faire pour éviter ça ? Malheureusement, vu l’implémentation actuelle, je ne vois pas de solution hormis une prise en compte de ce cas par le plugin.
Je me disais, si c’est possible, que le plugin devrait prendre en compte le type générique de la commande pour décider d’ajouter ou non ce ‹ on › sur la commande. Je pense qu’il est peut être nécessaire pour les lumières, mais dans mon cas j’ai bien modifié le type générique en ‹ Volet Bouton Monter ›, ‹ Volet Bouton Descendre › et ‹ Volet Bouton Slider ›, ce qui pourrait indiquer au plugin qu’il n’est pas nécessaire d’envoyer le paramètre ‹ on ›.
Hello,
Ça ne change rien en faisant des commandes persos, car il faut envoyer le paramètre ‹ bri › pour contrôler l’ouverture, et que c’est directement dans le code d’envoi de commande du plugin Deconz qu’est fait l’ajout du paramètre supplémentaire ‹ on › qui pose problème.
Ça fait une double impulsion au niveau du moteur (on entend ‹ tac tac › à quelques 10èmes de secondes d’intervalle)
@Loic salut,
Il me semble que tu es l’auteur du plugin Deconz, que penses-tu de la suggestion d’évolution du plugin que j’ai fait dans le premier post ?
Bonjour,
J’essaye de regarder dans la semaine car c’est pas un truc simple et pour moi ca releve plus d’un defaut d’implementation coté deconz que coté jeedom.
Aurais tu le json fait par le module en question ?
Hello,
Tu parles de quel Json ? Celui envoyé par le plugin Deconz à la Gateway ? Si c’est ça, je l’ai mis dans mon premier post. Sinon dis moi je trouverai ce dont tu as besoin.
Ca ne me parait pas incohérent côté Deconz. D’ailleurs c’est cohérent avec ce qui est recommandé par le fabriquant (Profalux), qui conseille de n’utiliser que le paramètre ‹ bri › pour manipuler le volet, même pour une ouverture/fermeture totale.
Ok merci ! Je vais tester ça.
Juste par curiosité, il y a quelque part où l’on peut avoir accès au code sans forcément installer la version beta ? Je suis développeur pro, et toujours intéressé pour aider à améliorer la qualité en contribuant ou en relisant le code des projets open source que j’utilise.
Je sais où trouver le code une fois installé, mais dans ce cas ci comme dans d’autres, il serait intéressant de proposer un accès au moins en lecture, la communauté pourrait aider
Les gens peuvent toujours se partager le code du plugin une fois installé, mais ça limite le risque effectivement.
Je comprends la crainte, mais c’est dommage de se priver du support de la communauté pour améliorer la qualité de l’offre. Je suppose que c’est quelque chose auquel vous devez avoir réfléchi et débattu en interne, donc je n’insiste pas trop.
Pour ma part, ça me demande, alors que je suis utilisateur payant - je ne m’en plaint pas, hein de devoir te faire confiance et d’installer la béta localement de devoir faire une copie de la version actuelle et faire un diff du filesystem pour comprendre les changements que tu as fait, c’est pas la fin du monde mais ça reste contraignant.
On en a longuement débattu oui et meme comme ca on a pas mal de personne ne jouant pas le jeux c’est dommage pour tout le monde effectivement on est aimerait bien mettre tout en public mais si on fait ca dans 6 mois on ferme tout et on aura tous perdu malheureusement. C’est triste mais pas le choix
Salut,
Avec la version beta j’ai une erreur 500 dès que je tente d’exécuter une commande avec le paramètre ‹ bri ›
En relisant le code, je pense que tu t’es trompé avec setConfiguration('modelid') qui devrait être getConfiguration('modelid')
Ca marche pour le correctif, mais visiblement la gateway n’aime pas bien non plus.
Je vais contacter le développeur de la gateway Deconz, je reviens donner des nouvelles ici dès que j’en sais plus.
Oui, mais c’est étrange. Dans le ticket de demande de support des volets profalux, le développeur lui-même indique qu’il n’était pas recommandé d’utiliser les commandes on/off. J’ai clairement un soucis au niveau de mes volets qui font un double mouvement quand c’est utilisé avec les 2 paramètres, je vais creuser ça avec lui.
Hello @Loic
Les changements nécessaires ont été réalisés dans la gateway deconz, ça sera disponible dans la prochaine release (ticket ici : Issues · dresden-elektronik/deconz-rest-plugin · GitHub commits ici : https://github.com/Smanar/deconz-rest-plugin/tree/profalux)
J’ai pu tester que ça fonctionnait comme attendu, c’est à dire avec les commandes telles qu’envoyées par la version stable du plugin.
Du coup il faut rollback les changements que tu as fait sur la beta.
Merci pour ton aide!
