Bonjour,
Je ne sais pas trop pourquoi (je n’ai pas regardé les logs) mais j’ai le plugin zigbee qui a lancé 24 instances de deCONZ et qui sature donc mon système. Pouvez-vous ajouter le kill de toutes les autres instances (killall deCONZ) avant de lancer une nouvelle instance ?
Merci !
Bonjour.
Je suppose qur le plug in Zigbee est le plug in Deconz (selon titre du fil de discussion).
24 instances lancées à quel moment :
- Lors de l’installation du plug in et de l’installation de deCONZ ?
- Lors du démarrage de la box domotique ?
- Lors du démarrage du démon ?
En effet deCONZ est lancé par le service debian ad hoc.
Donc s’il y a 24 instances de lancées c’est qu’il y a un bug ailleurs dans la configuration et un kill all ne changera pas grand chose en tout cas pas si les instances sont liées à une boucle).
Le plug in ne lance pas deCONZ en tant que tel. Il installe deCONZ (opération lancée manuellement par l’utilisateur une seule fois en configuration) et configure le service Debian pour un démarrage automatique c’est tout. deCONZ est une application (process) ensuite autonome de Jeedom. Le seul lien de Jeedom avec l’API deCONZ est un websocket.
Donc il faut en premier lieu chercher quel est la cause du lancement des multiples instances de deCONZ (et à priori hors Jeedom) d’autant plus qu’une seule aura accès au port COM avec la clef Conbee2 les autres tourneront sans connexion au coordinateur réseau.
faux, cf deconzd.py du plugin qui lance manuellement le démon
ce matin, pareil à nouveau. système à genoux après 38 instances simultanée de deCONZ. il doit certes y avoir un problème avec la clé ou qqchose comme ça, mais c’est pas normal tout de même.
j’ai ajouté ça ligne 112 dans la fonction handleLaunchDeconz:
subprocess.Popen([« sudo », « killall », « deCONZ »], stdout=log,stderr=log,shell=False)
Pas normal.
La clef ne sert que de « modem » pour communiquer couches basses sur le réseau. Avec ou sans la clef il ne doit pas y avoir de multiples lancements du process deCONZ.
Sans la clef (facile de faire le test) on doit avoir des erreurs de port COM et des erreurs remontées au niveau application Jeedom mais pas plus (sur mes trois configs dont deux en V4 sur NUC intel et debian V10 et RPI3B+ et une en V3 sur NUC intel debian V9 c’est le constat)…
Une voie d’investigation serait d’utiliser deCONZ GUI Jeedom non démarré (donc deCONZ en stand alone) sur ta box pour vérifier le comportement.
- Si comportement identique => il faudra se pencher sur la configuration Linux parce que la pour le coup l’appli est lancée une seule fois par l’opérateur.
- Dans le cas contraire =>désinstallation du package deCONZ (faire une sauvegarde de la configuration sous Phoscon au préalable) , désinstallation du plug in deCONZ, supprimer les services deCONZ (sensibles à la version debian utilisée V9 ou V10), redémarrer, réinstaller le plug in Jeedom Deconz, puis l’appli deCONZ depuis la page de configuration du plug in Jeedom Deconz (et pas en ligne de commande par ailleurs comme recommandée par Dresden), reconfigurer le plug in Deconz, activer le démon et checker les process lancés.
Peu importe la configuration, ça ne doit pas lancer 100 fois le démon.
Je n’investiguerais pas sur « pourquoi ça marche pas » mais plutôt ici sur « pourquoi quand ça marche pas, ça me crash tout mon système ». Et mon fix me semble un bon garde fou.
Et à propos de deconz GUI, attention: 90% (95 ? 99%?) des utilisateurs ici n’ont pas de GUI sur leur box jeedom.
Je pense qu’il veux dire en manuel, pas lancé par le plugin jeedom, et tu peux le faire pour deconz en mode headless aussi (tu vires la ligne dans le script de lancement a la bourrin si il le le faut, vu que tu as l’air de gerer les scripts)
Mais dans tout les cas je ne pense pas que ce soit deconz qui se lance lui même plusieurs fois, il n’y aurait pas un watchdog bancale dans un script (ou ailleurs) ?
Je suis bien d’accord. je supposais que tu avais un environnement graphique installé sur ta Debian.
Je ne généralise pas aux x% des autres utilisateurs le support que j’(essaie) d’apporter à un seul…
