J’ai un jeedom qui tourne sur un odroid C2, depuis plusieurs années ; avec, comme plugins de type protocole, rfxcom et z-wave
Depuis le début, j’ai programmé par cron un reboot de l’odroid toutes les semaines, le lundi matin à 2h ; je n’ai jamais eu de soucis avec cela.
J’ai installé le plugin deconz récemment. Depuis, suite au reboot hebdo, le plugin z-wave est en erreur.
Dans la page de conf du plugin z-wave, le démon est en statut ‹ NOK ›. Pas de messages dans la log Openzwave et Openzwaved.
Pas de process de type ‹ wave › dans le système (ps -edf | grep -i wave)
Si je lance un redémarrage du démon dans jeedom, tout refonctionne.
La semaine dernière, j’ai relancé un reboot manuellement (/sbin/reboot) après avoir relancé le démon dans jeedom ; ca c’est bien passé, z-wave était opérationnel.
Ce lundi, après avoir constaté le problème, j’ai lancé un reboot manuel sans avoir relancé de démon dans jeedom auparavant ; au redémarrage, le plugin z-wave est resté en erreur.
J’ai fait ensuite un redémarrage du démon z-wave dans jeedom : OK.
Puis un reboot manuel ; OK, le démon a bien démarré automatiquement.
Je soupconne, sans en être certain à 100%, que le problème vient de l’installation du plugin deconz. En tout cas, le problème est arrivé juste après.
Entre temps, j’ai fait également des mises à jour de jeedom et de plugins comme proposé dans jeedom, mais j’ai toujours fait cela régulièrement sans rencontrer de problème.
Mon environnement :
odroid C2. armbian 5.73. debian-version 9.8
jeedom à jour :
. core : 3.3.32
. z-wave : 3.2.12
. deconz : 3.3.28
Si vous avez des pistes de recherche, je suis preneur
Bonjour, le port de l’usb zwave vous l’avez en mode automatique ou sélectionné où il est ? J’avais l’habitude de l’avoir en mode automatique et quand je redémarre le démon n’a jamais démarré, jusqu’à ce que je l’ai configuré dans son port au lieu du mode automatique.
Le dongle z-wave est une aeotec Z-Stick gen5.
Dans la conf du plugin z-wave, le ‹ Port clé Z-Wave › est positionné à la valeur ‹ 0658 0200 (/dev/ttyUSB-zstick1) ›
A savoir que, lors de l’install de jeedom avec les clé z-wave et rfxcom, j’avais rajouté ces règles udev :
Le dongle conbee est vu comme /dev/ttyACM1.
C’est le logiciel deCONZ qui la détecte automatiquement, je n’ai pas osé faire une règle udev.
Ta remarque est intéressante, je n’avais pas pensé d’un éventuel conflit à ce niveau.
Lors du prochain dysfonctionnement, je regarderais de ce coté avant de relancer le démon.
Meme problème sur un autre jeedom DIY, installé également sur un odroid, avac les clés ‹ Z Stick gen5 › et conbee V2.
avec la même règle udev : SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyUSB-zstick1"
Le défaut est aléatoire, pas de problème coté syslog et dmesg.
En fait, sur le second jeedom, le défaut semble systématique.
Après boot, la clé z-wave peut se trouver sur /dev/ttyACM0, et la conbee sur /dev/ttyACM1 ; et d’autre fois, c’est l’inverse.
J’ai constaté le problème dand les 2 cas.
Et même quand le démon z-wave n’a pas démarré, la règle udev était bien appliquée :
/dev/ttyUSB-zstick1 → ttyACM0, ou /dev/ttyUSB-zstick1 → ttyACM1 suivant que la clé z-wave était sur ttyACM0 ou ttyACM1
D’ailleurs, une relance manuelle du démon z-wave fonctionne.
Je rappelle que, dans le plugin z-wave, j’ai bien indiqué comme ‹ port clé z-wave › le périphérique ‹ 0658 0200 (/dev/ttyUSB-zstick1) › ; ceci sur les 2 jeedom en question.
Je n’ai aucun problème avec le plugin deconz.
Je vais pallier le problème en paramétrant un hearbeat sur le démon z-wave… ce n’est pas le top, mais ca marchera probablement.
Je ne pense pas qu’il soit possible de décaler le démarrage du démon après boot ; je soupconne que ca serait suffisant.
Sinon, y a-t-il moyen de tracer pourquoi le démon ne démarre pas parfois au boot ?
J’ai tenté de passer les logs du plugin en niveau debug ou info, mais il n’y a aucune info sur aucune des 4 logs disponibles lors du boot. Par contre, j’ai de l’info sur les log Openzwave et Openzwaved lorsque je redémarre le démon … mais c’est trop tard.
Je n’ai maintenant ce problème que sur une install jeedom ; plus sur l’autre.
Je ne sais pas pourquoi.
Sur le système qui dysfonctionne :
je reproduit le problème systématiquement après un restart d’apache (service apache restart). Le démon zwave ne redémarre pas seul, il faut le faire à la main.
j’avais mis un heartbeat à 15mn, en cochant « Redémarrer le démon ». J’espérais que jeedom relancerait le démon au bout d’une quinzaine de minutes, mais non.
j’ai passé les logs en debug, puis restarté apache ; rien dans les logs
Je soupconnais un conflit avec le plugin deconz ; j’ai désactivé ce plugin et restarté apache, même problème.
J’ai essayé de comparer les 2 systèmes : celui qui marche (S_OK), et celui qui dysfonctionne (S_NOK)
en fonctionnement normal, une commande ‹ ps -edf | grep -i wave › retourne la même chose des 2 cotés : exécution du script python openzwaved.py
. sur S_OK : si j’arrete apache (service apache2 stop), ce script reste en exécution. Apache redémarre automatiquement (cron watchdog) dans les 5 mn
. sur S_NOK : si j’arrete apache, ce script s’arrete aussitot, et ne redémarre jamais. Apache redémarre automatiquement dans les 5mn, mais le script python ne redémarre pas.
Ce qui me gene : c’est de n’avoir aucun message dans les logs, lors du redémarrage, alors que j’ai mis en mode debug.
J’aimerais comprendre comment jeedom lance ce script openzwaved.py : quand je clique manuellement sur redémarrer le démon, ca fonctionne à tous les coups.
Et ce qui est surprenant, c’est que l’exécution de ce script s’arrête dès qu’apache s’arrete, alors que sur S_OK, il ne s’arrete pas.
Je précise que je n’ai rien ‹ bidouillé › dans le jeedom malade. C’est une installation récente, avec juste les plugins deconz et z-wave, plus 2 sondes de température deconz et 2 modules z-wave pour volets roulants.
Pour le moment, on n’ose pas aller plus loin…
Si vous avez des informations sur le lancement de ce script, ou des pistes de recherche, je suis preneur.
Arff ! problème réglé, après pas mal de temps passé sur ce ‹ problème ›.
Dans la configuration du plugin, partie démon, il fallait cliquer sur le bouton ‹ activer › dans ‹ gestion automatique ›.
Je suis pourtant certain de ne pas avoir cliqué précédemment volontairement sur ‹ désactiver › … je l’ai peut-être fait involontairement.
