Daemon nok

Bonjour à tous
Même problème pour moi alors que tout fonctionnait auparavant

En passant sur la version 0.50.2 on a un souci de requote :s … il faudrait aussi downgrader certains trucs de yarl.

le module zigpy/application contient une class ApplicationController qui contient des method abstract. La problème est que les classes héritières ne redéfinissent pas ces methods.
Pour le moment, j’ai le problème avec les méthod

  • reset_network_info()
  • send_packet()

1 « J'aime »

:smiley:
Le deamon tourne mais je n’ai pas testé s’il est fonctionnel.

Je fais fait un message dans le 5 10 minutes
avec ce que j’ai dû faire. Ensuite, se sera porte ouverte pour de tests…

Pareil, j’ai supprimé les 2 méthodes, qui sont pour l’instant vide.

Le démon se lance, on récupère bien les informations des modules, mais dés que l’on veut envoyer une requête pour par exemple allumer une lumière, on a une erreur de paramètre dans les requests, sur un extended timeout

1 « J'aime »

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 »