Le souci c’est que j’avais déjà ce problème avec les modules sur piles sur mon raspberry.
Et pour le problème de portée qui vient de se produire, ça fait 3 mois que ma VM tourne sans souci et je n’ai touché à rien dessus. Et puis cet après-midi, j’ai installé la version fournie par Jeedom directement. Je n’ai touché rien d’autre, la VM n’intervient que peu je pense.
Le truc pour tester sans VM c’est que je n’ai pas de machine pour mettre jeedom dessus
Tu m’excuseras mais je n’ai plus les yeux en face des trous, je vais aller me coucher.
Pour t’aider, j’ai besoin d’avoir les idées claires et là ce n’est plus le cas.
Je te dis à demain en espérant que tu puisses trouver le problème d’ici là.
Bonne fin de soirée.
Pas de souci, je pense que de mon côté ça n’est pas mieux !
Je vais essayer d’avoir un raspberry pour tenter ton idée. J’avais enfin quelques jours de repos avec les enfants mais je sens que je vais passer un certain temps à résoudre tout ça.
Merci de ton aide et si demain tu revois un truc qui cloche, n’hésite pas !
Bonne nuit
Bonjour,
N’oubliez pas qu’une fois le module déplacé à son emplacement définitif il faut le soigner pour être sûr que les routes et voisins sont correctes sinon le contrôleur le croit à portée ce qui n’est plus le cas donc module injoignable donc dead.
Bonjour, j’allais corriger pour le texte, désolé. C’est l’empressement hier… Merci à ipapy d’avoir corrigé.
Je ne suis plus trop sûr de l’avoir fait à chaque fois en effet. Mais y a t-il un délai à attendre avant de voir l’effet. Car si je lance soigner le réseau et que j’attends juste le temps du redémarrage et bien le module reste en dead.
Édit : oui mais avec un seul module, que je fasse cette action ou non ça ne devrait rien changer car la seule route possible est par la clé en direct non ?
Alors, hier soir j’ai réinstallé à nouveau une VM toute propre avec rien que le zwave. J’ai juste laissé la clé Aeotec branchée cette nuit. Je viens d’inclure un module FGR222 mais je ne l’ai pas encore mis à sa place. J’ai soigné le réseau. Et déjà je vois un souci. Pourquoi j’ai NOK sur voisins de la clé et pas sur le module ?
PS1 : quand je clique sur configuration de la clé je vois ça, il y a donc bien un souci avec la clé. Pourtant, j’utilise une clé neuve, sortie de l’emballage hier. Bien entendu j’ai essayer les 2 options proposées sans succès.
PS2 : En cliquant sur rafraîchir les infos du noeud, ce souci de voisins NOK est corrigé mais ne change rien en reproduisant les actions ci-dessous.
J’ai loupé quelque chose ? Merci à vous. Normalement je vais avoir un raspberry en fin d’aprem.
J’ai aussi envie d’essayer de couper ma VM de production pour éviter toute interférence avec un autre protocole (même si tout est éloigné grâce à des rallonges USB et mis en dehors de ma baie). Vous en pensez quoi ?
PS3 : je viens de faire un nouveau test. J’ai écarté le module de la clé d’environ 1 m. Pas de souci à signaler dans un premier temps. J’ai fait soigné le réseau, attendu que le réseau redémarre. J’ai ensuite demander l’ouverture (sans que le module soit branché au volet), j’ai bien entendu le clic sur le module. Puis j’ai tenté de cliquer sur fermer et là, module dead !
Je l’ai à nouveau rapproché de la clé et le module est de nouveau OK. J’ai fait plusieurs monter/descendre à suivre et j’ai bien entendu le clic à chaque fois…
En lisant la documentation à ce sujet, je ne comprends pas la même chose. Ils parlent d’utilisation de dongle USB, ce que j’utilise.
Enfin, j’avais sélectionné le port adéquat avant qu’on me conseille de tester en auto et c’est malheureusement pareil…
Le port exact est toujours préférable. J’ai fait cela pour tester sur mon Raspberry, il n’y a pas de différence. Mais ce n’est pas tout a fait pareil dans mon cas. Vous, le port est quand même mappé.
Alors, j’étais bien avec le port exact avant sans souci et aujourd’hui même dans ce mode, mon problème de portée persiste… Je doute du coup de son impact
Nouveau truc dans les logs ce matin. Une idée de ce que veut dire la partie avec Python 2.7 ?
[2021-02-20 08:42:50][ERROR] : RemoveFailedNode, RequestNetworkUpdate. (Failed)
[2021-02-20 08:52:24][ERROR] : RequestHandler Controller is busy
[2021-02-20 09:05:37][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 09:17:44][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 09:17:56][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
Unhandled exception in thread started by <bound method _Timer.__bootstrap of <_Timer(Thread-11587, stopped 140268219311872)>>
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
self.__bootstrap_inner()
File "/usr/lib/python2.7/threading.py", line 789, in __bootstrap_inner
del _limbo[self]
KeyError: <_Timer(Thread-11587, stopped 140268219311872)>
[2021-02-20 09:18:20][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 09:18:52][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 09:18:56][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 10:00:20][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 10:23:19][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 10:25:34][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 10:26:08][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 10:33:09][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 10:34:10][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort
[2021-02-20 10:34:13][ERROR] : Le noeud [Volets][VR_porte_fenetre] (2) est présumé mort