Utilisateur du plugin depuis quelques années sans problème, un problème de désactivation est apparu depuis hier suite à une mise à jour. Quelle idée me direz-vous
Contexte qui fonctionnait : Système DIY avec Debian 10, Jeedom version stable, modules zwave avec plugin openzwave.
Souhait : Debian 10 n’étant plus supporté depuis quelques mois, j’ai voulu passer en Debian 11.
Problème : plugin openzwave incompatible, nécessité de passer par ZwaveJS.
Contexte actuel : Système DIY avec Debian 11 (mise à jour sans problème), jeedom stable, modules zwave avec plugin ZwaveJS (la bascule s’est faite sans problème également).
Maintenant, à chaque commande du plugin volets, ZwaveJS trouve toujours le moyen d’envoyer un retour d’état du volet pendant le mouvement, ce qui désactive la gestion automatique.
Exemple :
0416|[2023-10-08 11:02:07]INFO : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Jour] : Exécution de la gestion du lever du soleil
0417|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée] : Le plugin est configuré en mode été
0418|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée] : Le plugin est configuré en mode été
0419|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Azimut] : L’azimut 131° est compris entre : 122° et 251° => Vrai
0420|[2023-10-08 11:02:07]INFO : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Jour] : La gestion par Azimut prend le relais
0421|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Altitude] : Le soleil est estimée à 0.13m en dessous le toit
0422|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Altitude] : Le soleil est estimée à 0.13m dans le fenetre
0423|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Altitude] : proportionnel : 0.13 / 1.8
0424|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Altitude] : La hauteur du volet est estimée à 7%
0425|[2023-10-08 11:02:07]INFO : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Azimut] : Lancement aléatoire de volet
0426|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Azimut] : Position actuelle = 54
0427|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Azimut] : Position demandée = 11
0428|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Azimut] : Exécution de #[Rezdechaussee][Volet Baie Vitrée][Positionnement]# ({« slider »:11})
0429|[2023-10-08 11:02:07]INFO : [Rezdechaussee][Gestion Volet Baie vitrée][Etat] : Changement de l’état réel du volet => 11%
0430|[2023-10-08 11:02:07]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Etat] : Le changement d’état est autorisé
0431|[2023-10-08 11:02:13]INFO : [Rezdechaussee][Gestion Volet Baie vitrée][Etat] : Changement de l’état réel du volet => 37%
0432|[2023-10-08 11:02:13]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Etat] : Le changement d’état n’est pas autorisé
0433|[2023-10-08 11:02:13]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée] : Le plugin est configuré en mode été
0434|[2023-10-08 11:02:14]INFO : [Rezdechaussee][Gestion Volet Baie vitrée][Gestion Manuel] : Un évènement manuel a été détecté: La gestion a été désactivée
0435|[2023-10-08 11:02:21]INFO : [Rezdechaussee][Gestion Volet Baie vitrée][Etat] : Changement de l’état réel du volet => 11%
0436|[2023-10-08 11:02:21]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée][Etat] : Le changement d’état n’est pas autorisé
0437|[2023-10-08 11:02:21]DEBUG : [Rezdechaussee][Gestion Volet Baie vitrée] : Le plugin est configuré en mode été
Comme vu dans d’autres sujets de personnes ayant eu ce problème, j’ai tenté de réinstaller les dépendances, de toucher à des paramètres divers et variés sans succès. Si quelqu’un à une idée…
Cela ne va pas t’aider mais j’ai le même problème avec zwavejs et ce plugin. J’utilise des FGR222.
En contournement j’ai un réarmement automatique, mais qui m’impose de désactiver la gestion auto quand je veux agir manuellement sur le volet.
J’ai tenté de modifier plusieurs paramètres sur mes modules, mais sans effet.
Désolé je n’ai pas le temps de tout lire alors je réponds peut être a côté.
Les problème de désactivation lors d’une commande sont très souvent liée à une incompatibilité du retour d’état venant de ton protocole (émission d’état illogique) qui déclenche le mode manuel
1 interdit la répétition sur l’état de ta commande protocole
2 si c’est des Somfy désactivé la fonction my
3 désactivation du mode manuel
Pas de soucis, je vais déjà répondre aux propositions :
Vérification faite, tous les modules sont déjà en interdiction de répétition.
Ce ne sont pas des Somfy
C’est la solution temporaire retenue mais qui ne convient pas vraiment à notre usage.
J’ai bien conscience que le problème semble venir côté ZwaveJS, peut-être un paramètre à modifier pour éviter une transmission de l’info « état » pendant le mouvement du volet. J’ai tenté de mettre une « durée avant retour d’état » à 1 min. Mais ça ne change rien au problème.
Autre idée, est-il possible de mettre une temporisation sur la prise en compte d’un changement d’état du côté du plugin volet, afin d’éviter toute désactivation inutile ?
Incompatible avec le fonctionnement nominale.
Toute les solutions de contournement envisager et tester on eu des effets de bord indésirables et on réduit les performances du plugin.
Le problème c’est que c’est bien le module Fibaro qui envoie cette mise à jour intempestive. J’avais vérifié dans zwavejsUI.
Rien vu non plus dans le github de zwavejsUI.
Problème déjà existant sur OZW mais apparemment le plugin Jeedom filtrait car jamais observé de mon côté avec FGR222.
Si tu attends que ce soit le plugin zwavejs qui filtre je ne suis pas certain que cela aboutisse.
Sans m’avancer Sarakha pourrait également considérer que le problème est du côté de ton plugin plus que celui de zwavejs.
Je peux toujours tenter un ticket cela dit étant donné que cela semble avoir été fait avec le plugin OZW.
Intéressant.
J’étais parti du principe que ca ne touchait que les Fibaro.
Apparemment j’avais tout faux
Ça semble pointer donc le doigt vers zwavejsUI plutôt que vers un FW buggé. Mais d’un autre côté mon lien montre un problème avec un module Fibaro sous OZW.
Cela pourrait vouloir dire que seul le plugin OZW Jeedom (qui était en réalité un fork d’OZW) avait corrigé ce problème.
Bon… J’ai tenté un sujet dans la section dédiée au plugin Zwave-JS, ça ne semble pas passionner la communauté.
Nous ne sommes vraiment que 2 à avoir ce problème ?
Solution de repli trouvée de mon côté, si ça peut servir à d’autres :
J’ai mis des conditions de réactivation automatique : si la position verticale demandée par l’automate correspond à la position réelle.
Dans le détail :
Je fais déjà fonctionner mes volets par palier afin d’éviter de demander aux modules et moteurs de bouger pour 1% d’ouverture. En mode Azimut, j’ai mis par exemple : round(#[Etage][Gestion Volets Ch Parents][Ratio Vertical]#/11)*11. Au lieu d’avoir les 100 positions (de 0 à 99), j’ai 0, 11, 22, 33, … jusqu’à 99.
Avec le plugin gestion de volet, = le ratio vertical renvoyé donne soit la position calculée par l’Azimut en mode été, soit 98 (pourquoi pas 99 d’ailleurs ?) en mode hiver avec le soleil dans la fenêtre, soit 0 la nuit et l’hiver quand le soleil ne donne pas dans la fenêtre.
Donc sur chaque template du plugin, dans l’onglet condition, ça donne quelques conditions à contrôler pour une réactivation automatique :
round(#[Etage][Gestion Volets Ch Parents][Ratio Vertical]#/11)*11 == #[Etage][Volet Chambre Parents][Etat]# en mode manuel été et hiver ##Ça couvre la gestion azimut l’été, la nuit et l’hiver quand le soleil donne dans la fenêtre##
#[Etage][Gestion Volets Ch Parents][Ratio Vertical]# == 0 et #[Etage][Volet Chambre Parents][Etat]# == 99 en mode manuel hiver uniquement ##Pour l’hiver de jour quand le soleil ne donne pas dans la fenêtre et que je souhaite quand même conserver le volet ouvert##
Il reste un effet de bord, si je souhaite fermer le volet en hiver et qu’il n’y a pas de soleil, la gestion auto se réactivera et donc le volet va se rouvrir (c’est ce que j’ai mis dans mes actions). Idem en plein été, si le plugin demande de fermer complètement (position 0) et que je souhaite ouvrir en entier (99), ça va aussi réactiver. Pour le moment, ça ne résout donc pas complètement le problème, c’est juste un pis-aller en attendant mieux !
