Daemon nok

En résumer, le deamon du plugin zigbee ne fonctionne pas en raison de bugs dans la version 0.51.0 de la librairie sigpy qu’il utilise.

Voici la liste de modification à faire dans la librairie zigpy pour que le deamon du pluggin zigpy puisse démmarer:

1) Fichier: /usr/local/lib/python3.7/dist-packages/zigpy/util.py

  • Remplacer la ligne 337
@functools.cached_property
  • par les lignes
@property
@functools.lru_cache(maxsize=None)

2) Fichier: /usr/local/lib/python3.7/dist-packages/zigpy/application.py

  • Mettre les lignes 591 et 890 en commentaire
@abc.abstractmethod

devient

# @abc.abstractmethod

3) Fichiers "/usr/local/lib/python3.7/dist-packages/zigpy/application.py" et "/usr/local/lib/python3.7/dist-packages/zigpy/application.py"

  • Supprimer les lignes qui contiennent extemted_timeout comme indiquer plus bas par dans le message de @psychon

:warning: Attention
Ces corrections devront être refaites si les dépendances du plugin sont remise à jour avant qu’une version corrigée de zigpy ne soit disponible.

Attention, util.py et non utils.py :slight_smile:

Et par contre, toujours une erreure sur l’envoie de requetes :

erreur : {"state":"error","result":"request() got an unexpected keyword argument 'extended_timeout'","code":0}

Bien vu. utils.py c’est dans le répertoire du deamon de plugin et celui là, faut pas le toucher.

Merci

J’ai le même message en incluant mon premier capteur :frowning:

C’est encore dans zigpy (normal), mais ce coup-ci dans device.py :

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/zcl/__init__.py", line 327, in request
command_id=hdr.command_id,
File "/usr/local/lib/python3.7/dist-packages/zigpy/endpoint.py", line 244, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.7/dist-packages/zigpy/device.py", line 307, in request
extended_timeout=extended_timeout,
File "/usr/local/lib/python3.7/dist-packages/zigpy/util.py", line 153, in wrapper
return func(*args, **kwargs)
TypeError: request() got an unexpected keyword argument 'extended_timeout'

Le problème, mais que même si on retire l’argument, ou qu’on lui fixe une valeur en dur, ça ne passe pas.

Bon, ben pour que ça marche :

Retirer dans les fichiers application.py et device.py toute ref à extended_timeout, et redémarrer le demon… et c’est magique :

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,

Fichiers concernés :

/usr/local/lib/python3.7/dist-packages/zigpy/device.py
/usr/local/lib/python3.7/dist-packages/zigpy/application.py

Sur ces belles paroles, bonne nuit

Super,
ça fonctionne aussi chez moi, j’ai pu inclure un premier module…

Merci et bonne nuit

Je regarde ça demain

De rien, il fallait de toute façon que ça fonctionne pour moi avant que tlm se lève à la maison

Bonjour à tous

A votre avis dois-je appliquer la solution ci-dessus car j’ai à priori le même problème. Tout fonctionnait juqu’à hier.
Merci d’avance :wink:

Log

ERROR : Echec de la requête HTTP : http://127.0.0.1:8089/device/all cURL error : Failed to connect to 127.0.0.1 port 8089: Connection refused

Zigbeed_1

Merci à tous pour vos contributions
Le daemon se lance mais j’ai cette erreur dans la log quand j’essaie de lancer une commande

[2022-10-02 10:02:14]ERROR : Exception running handler
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/bellows/ezsp/__init__.py", line 347, in handle_callback
handler(*args)
File "/usr/local/lib/python3.7/dist-packages/bellows/zigbee/application.py", line 468, in ezsp_callback_handler
self._handle_frame(*args)
File "/usr/local/lib/python3.7/dist-packages/bellows/zigbee/application.py", line 505, in _handle_frame
dst_addressing = zigpy.types.Addressing.nwk(
AttributeError: type object 'Addressing' has no attribute 'nwk'
[2022-10-02 10:02:17]INFO : Traceback (most recent call last):
File "/var/www/html/plugins/zigbee/resources/zigbeed/zdevices.py", line 86, in command
await command()
File "/usr/local/lib/python3.7/dist-packages/zhaquirks/tuya/ts130f.py", line 72, in command
tsn=tsn
File "/usr/local/lib/python3.7/dist-packages/zigpy/quirks/__init__.py", line 188, in command
tsn=tsn,
File "/usr/local/lib/python3.7/dist-packages/zigpy/zcl/__init__.py", line 327, in request
command_id=hdr.command_id,
File "/usr/local/lib/python3.7/dist-packages/zigpy/endpoint.py", line 244, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.7/dist-packages/zigpy/device.py", line 315, 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/zhaquirks/tuya/ts130f.py", line 72, in command
tsn=tsn
File "/usr/local/lib/python3.7/dist-packages/zigpy/quirks/__init__.py", line 188, in command
tsn=tsn,
File "/usr/local/lib/python3.7/dist-packages/zigpy/zcl/__init__.py", line 327, in request
command_id=hdr.command_id,
File "/usr/local/lib/python3.7/dist-packages/zigpy/endpoint.py", line 244, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.7/dist-packages/zigpy/device.py", line 315, 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

Ma commande était la montée d’un VR. Elle fonctionne mais arrivée en butée, j’ai systématiquement cette erreur qui remonte (et qui faisait partie du message précédent)

[2022-10-02 10:02:14]ERROR : Exception running handler
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/bellows/ezsp/__init__.py", line 347, in handle_callback
handler(*args)
File "/usr/local/lib/python3.7/dist-packages/bellows/zigbee/application.py", line 468, in ezsp_callback_handler
self._handle_frame(*args)
File "/usr/local/lib/python3.7/dist-packages/bellows/zigbee/application.py", line 505, in _handle_frame
dst_addressing = zigpy.types.Addressing.nwk(
AttributeError: type object 'Addressing' has no attribute 'nwk'

Je viens de tester avec mes lumières, j’ai essayé de ré-inclure les modules mais j’ai la même erreur sur l’attribute nwk…c’est quand même bien la m…cette mise à jour…

Désolé, mais je ne suis pas équipé pour reproduire vos problèmes restants.
Il ne m’est malheureusement pas possible de l’analyser pour proposer un contournement.

J’espère que, suite à cette malheureuse expérience, Jeedom SAS figera la version de zigpy dans la configuration des dépendances du plugin (mais pas avant d’avoir une version fonctionnelle). Ils pourront ainsi faire des tests avant de libérer le déploiement des mises à jour de zigpy.

Pas de soucis @ktn merci à toi pour ton aide en tous cas
je te rejoins sur la nécessité de stabiliser les dépendances dans les futurs déploiement ou à minima de réaliser quelques tests sur un échantillon restreint avant de diffuser des maj aussi bancales…

1 « J'aime »

Salut perso j’ai python 2.7 et 3.9
J’ai remplacé 3.7 par 3.9 et suivi vos instructions et ça a fonctionné 3sec
On est bien d’accord que c’est que le plugin officiel zigbee qui déconne ? Donc si je le shunt et que je passe sur un autre plugin ça devrait fonctionner ?

Bon ben c’est tout jeedom qui est planté même sur abeille il ne trouve pas ma clé popp

Hello,
Non, ce n’est pas le plugin qui déconne mais le module python « zygpy » sur lequel s’appuie le plugin zigbee.

Ce module est potentiellement utilisé par d’autre plugin Jeedom et certainement par d’autres logiciels que Jeedom.

Je ne sais pas si le plugin abbeille utilise le module zigpy. Si oui, c’est probablement l’explication de ton soucis avec abeille qui trouve pas ta clé popp.

Dans l’installation des dépendances, tu dois quand même avoir un lien vers la version 3.7 … cherche la notion de find dans l’installe des dépendances, tu verras qu’il renvoie vers la version figée 3.7, même si tu as la 3.9.

Et je confirme, ce n’est pas le module zigbee qui merde, mais l’intégration de zigpy dans sa version à partir de la 0.51.0. Le comportement global a été fortement modifié comme le montre la somme des modifications sur le commit dans le fichier application.

Le changelog indique : " Use a single structure and mirrored functions for transmitting/receiving Zigbee packets" ce qui change complétement l’approche de transmission de l’information.

En outre, le changelog est vraiment volumineux. Donc plein de changement.

Petite question s’il y a un dev du plugin zigbee. Où se trouve la définition des dépendances à inclure ? J’ai voulu revert zigpy, mais il y a pas mal de choses connexes à revert.

Les dépendances sont définies dans le fichier plugin_info/packages.json du plugin.

Je suppose qu’un downgrade de zigpy nécessite aussi le downgrade des module zigpy-znp, zigpy-xbee, zigpy-deconz et zigpy-zigate.

Pas simple tous ça. Bon courage si tu te lances… nous serons beaucoup à te remercier.