Bonjour,
J’ai comme beaucoup un souci avec mon daemon Zigbee depuis que j’ai lancé les dépendances ce soir. Ci-joint mon fichier debug zigbeed_1, dont les messages n’ont pas l’air tout à fait les mêmes que les autres, c’est pourquoi je recrée un sujet.
J’ai une clé pizigate, un Jeedom en 4.0.61, je joins également la conf de mon plugin.
J’ai écumé le forum, tenté des solutions proposées qui datent de mars (suppression de fichiers .py etc.), rien n’a fonctionné. J’ai remis une sauvegarde récente pour revenir en arrière sur les modifs que j’ai fait, de peur d’avoir empiré les choses. Mais le daemon reste NOK Si vous avez une idée grâce au debug, je suis preneur, car je suis désespéré …
Je progresse : en analysant les erreurs dans les logs, j’ai déplacé les fichiers du répertoire /var/www/html/plugins/zigbee/resources/zigbeed/specifics qui semblaient générer les erreurs, puis ceux du répertoire /var/www/html/plugins/zigbee/resources/zigbeed/quirks. A chaque fois je relançais le démon et regardais les logs pour voir quel fichier génèrait l’erreur, jusqu’à ce que je n’ai plus ce type d’erreur.
Maintenant, j’ai le log en PJ. Ça ressemble à un problème lié à python maintenant :
[2022-10-03 23:40:10][ERROR] : [start_zigbee] Fatal error : Can’t instantiate abstract class ControllerApplication with abstract methods reset_network_info, send_packet
Le problème avec les method reset_network_info et send_packet corespond aus problème que nous avons eu ce weekend suite à la mise à jour du module tiers zigpy
Première chose à faire:
Mettre le plugin zigbee à jour (dernière version mise à disposition ce lundi)
Lancer la mise à jour de dépendances (provoquera un downgrade du module zigpy et d’autres modules zigpy-* qui sont liés à zigpy
Si ceci ne résoud pas le problème, c’est probablement que la mise à jour des dépendances a installé une version trop récente du module zigpy-zigate.
Merci pour ta réponse ktn. Le problème c’est que je n’arrive pas à mettre à jour zigbee, ça met que l’opération a échoué, au bout d’à peine 3s. Et je reste dans ma version du 23/12/2021…
J’ai commenté les lignes que vous avez mentionné avec psychon dans les fichiers device.py et application.py et eureka! Je ne touche plus à rien! Mais quelle galère… merci et bonne nuit à tous.
Je vais étudier ce sujet, mais bien en profondeur avant de faire une quelconque modif qui va me faire coucher à 2h00 du matin Pour l’instant, ça fonctionne, mais effectivement, je créerai un topic si le problème ne se résout pas, et je vais envisager la maj de Jeedom que j’ai repoussé jusque là.
En attendant, je remets les solutions appliquées à mon problème, qui ont déjà été évoquées sur ce forum par ktn et psychon, et je clos ce topic. Plusieurs problèmes se sont enchainés en regardant les logs :
Problème du type :
[2022-10-03 22:33:50][INFO] : LOADER------Import de la configuration *<nom_repertoire>*.*<nom_fabricant>*
[2022-10-03 22:33:50][INFO] : Impossible d'importer *<nom_repertoire>*.*<nom_fabriquant>* : `manufacturer_attributes` is deprecated. Copy the parent class's `attributes` dictionary and update it with your manufacturer-specific `attributes`. Make sure to specify that it is manufacturer-specific through the appropriate constructor or tuple!
Solution : supprimer les fichiers <nom_fabriquant>.py du répertoire /var/www/html/plugins/zigbee/resources/zigbeed/<nom_repertoire>
Problème du type : [2022-10-03 23:40:10][ERROR] : [start_zigbee] Fatal error : Can’t instantiate abstract class ControllerApplication with abstract methods reset_network_info, send_packet
Solution : dans le fichier : /usr/local/lib/python3.7/dist-packages/zigpy/application.py, commenter les lignes 591 et 890 (@abc.abstractmethod devient #@abc.abstractmethod)
Problème du type extended_timeout avec certains modules
Solution : dans les fichiers "/usr/local/lib/python3.7/dist-packages/zigpy/application.py" et "/usr/local/lib/python3.7/dist-packages/zigpy/application.py", commenter toutes les lignes avec « extended_timeout » :
application.py: # extended_timeout: bool = False,
application.py: :param extended_timeout: instruct the radio to use slower APS retries
application.py: # extended_timeout=extended_timeout,
device.py: # extended_timeout = False
device.py: # extended_timeout = True
device.py: # extended_timeout=extended_timeout,
bonjour j’ai toujours des erreurs alors qu’il n’y a pas de ligne extended_timeout dans les fichiers de zigpy
File "/var/www/html/plugins/zigbee/resources/zigbeed/zdevices.py", line 86, in command
await command()
File "/usr/local/lib/python3.7/dist-packages/zigpy/device.py", line 325, in request
return await asyncio.wait_for(req.result, timeout)
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/var/www/html/plugins/zigbee/resources/zigbeed/restServer.py", line 271, in put
await zdevices.command(self.json_args)
File "/var/www/html/plugins/zigbee/resources/zigbeed/zdevices.py", line 91, in command
await command()
File "/usr/local/lib/python3.7/dist-packages/zigpy/device.py", line 325, in request
return await asyncio.wait_for(req.result, timeout)
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
Ca l’air d’être un problème complètement différent. Je te suggère d’ouvrir un topic dédié, en expliquant ta config, les paramètres du plugin (capture d’écran), le matériel, les logs, le contexte dans lequel s’est produit le problème. Ce sera plus clair
oui alors désolé, effectivement j’ai un autre problème, mes modules répondent à nouveaux je pense que c’était un problème de portée du réseau zigbee
mais j’ai bien ce problème de table d’entrée
Si vous avez une idée grâce au debug, je suis preneur, car je suis désespéré 
Pour l’instant, ça fonctionne, mais effectivement, je créerai un topic si le problème ne se résout pas, et je vais envisager la maj de Jeedom que j’ai repoussé jusque là.