Bonjour tout le monde,
j’ai installé le plugin GeckoSpa de @chris94440 dans sa version alpha sur une copie de mon Jeedom 4.4.3 avec Python 3.9.
Chris m’avait prévenu que le plugin n’était pas finalisé dans sa version asynchrone.
J’ai néanmoins des données qui descendent au démarrage du démon (seulement).
Après le démarrage je suis sensé être en asynchrone et le cron appelle un refresh des datas de manière périodique. Aucune données n’est mise à jour par la suite. Tout ce qui descend est toujours identique.
J’ai pu localiser le problème : suite au démarrage, les tâches qui bouclent sont annulées et je n’arrive pas à savoir pourquoi.
Lorsque je remonte le code, je reste bloqué sur cette fonction, mais je n’arrive pas à déterminer pour quelle raison et par quelle partie de code c’est exécuté :
async def _sequence_pump(self) -> None:
"""SpaMan sequence pump coordinates running the manager from the
parameterized constructor and machine state"""
_LOGGER.debug("SpaMan sequence pump started")
try:
while True:
#_LOGGER.debug("----------LBE SPAMAN SEQUENCE PUMP1-------------")
if (
self.spa_state == GeckoSpaState.IDLE
and self._spa_descriptors is None
):
await self.async_locate_spas(self._spa_address)
#_LOGGER.debug("----------LBE SPAMAN SEQUENCE PUMP2-------------")
if (
self.spa_state == GeckoSpaState.LOCATED_SPAS
and self._spa_identifier is not None
and self._facade is None
):
await self.async_connect(self._spa_identifier, self._spa_address)
#_LOGGER.debug("----------LBE SPAMAN SEQUENCE PUMP3-------------")
await asyncio.sleep(GeckoConstants.ASYNCIO_SLEEP_TIMEOUT_FOR_YIELD)
except asyncio.CancelledError:
_LOGGER.debug("Spaman sequence pump cancelled")
raise
Forcément c’est là cause de « asyncio.CancelledError » que la tâche asynchrone s’arrête.
Le plugin s’appuie un projet dans GITHUB (Gazoodle/GECKOLIB) qui est livré avec un shell de test qui marche très bien sur mon spa. Après le démarrage, je peux continuer à accéder aux données du spa et même les modifier.
Est-ce que ça parle à quelqu’un ou bien auriez-vous une idée de ce que je pourrai faire pour continuer les investigations/corrections?
sinon sans voir le code au complet c’est impossible d’aider, montrer juste une fonction ne sert à rien.
asyncio.CancelledError c’est l’exception qui sera déclenchée dans une coroutine lorsque la tâche doit être annulée
donc ce n’est pas vraiment une erreur, généralement c’est « juste » en moyen de notifier une tache de fond (ici un while true) qu’elle doit se couper car on stoppe l’application.
Merci @Mips ,
j’ai pourtant fait une recherche sur le forum avec le mot clé Python mais ton thread ne m’était pas remonté (ou je n’ai pas fait le lien).
Je vais y jeter un coup d’oeil très attentif.
EN effet je me doute que c’est un moyen de fermer correctement les vannes lorsqu’on souhaite arrêter le démon.
Le projet geckolib est vraiment complexe et bien qu’ayant déjà pas mal développé (C# et langage propriétaire) je suis nouveau né sur Python. Pas mal de subtilités m’échappent.
J’ai un peu peur de m’être attaqué à un morceau trop gros pour moi mais pour l’instant je ne lâche pas l’affaire.
Je reviendrai peut-être (certainement) lorsque j’aurai plus élagué le sujet.
merci encore pour ta réponse si rapide et pour la doc/projet.
Et Asyncio est encore un monde bien à lui, au début c’est un peu prise de tête pour comprendre les concepts, mais ensuite ca fonctionne plutôt bien, et le code exemple de notre ami @Mips pour communiquer avec Jeedom aide bien pour démarrer
Pour info, je me suis appuyé sur son projet exemple pour démarrer le codage du plugin TVRemote (encore en cours, même s’il commence à prendre forme), et le asyncio m’a valu quelques longues heures de neurones en ébullition
Et pour info je prépare une autre doc avec une base de démon (une évolution de ce qui est présenté dans ce post) pour permettre de démarrer plus facilement un nouveau dev et surtout ne pas s’encombrer avec tous les détails et pouvoir juste coder la logique nécessaire.
D’ici 1 a 2 semaines je pense pouvoir en dire plus
Merci @TiTidom , je pense que j’en aurai…(des questions).
EN tout cas, j’ai un peu avancé et je crois bien que c’est lors du retour d’infos depuis le spa vers une classe asyncUdpProtocol qu’à un moment ou à un autre la connexion se perd avec l’émetteur.
Du coup ça cancel le tout et ça ferme la boutique.
Ce qui m’embête vraiment là, c’est que c’est dans le code le la lib geckolib et il y a une bonne douzaine de classes qui interagissent.
je n’arrive pas à me faire une idée d’ensemble donc je patine forcément.
L’autre truc, c’est que le shell pour lancer directement la lib marche sans souci pendant des heures et c’est contradictoire avec le fait que le souci serait dans le code la lib externe.
J’avais commencé le dev pour un pote mais n’ayant pas le spa et pas accès au spa cela était compliqué …et j’ai lâché l’affaire…le mieux a mon avis est de repartir a 0 et pas forcément avec asyncio
@chris94440 , ça m’embête un peu de tout reprendre de 0 pour tout le travail que tu as déjà fourni.
Surtout que je reste persuadé qu’il ne reste plus grand chose à faire mais le truc c’est que la lib geckolib est tellement tentaculaire et complexe.
Je n’ai pas encore dit mon dernier mot en tout cas.
Franchement t’inquiète pas de soucis j’ai pas passé temps de temps que cela …et je sais que reprendre le travail de qu’un est pas idéal …j’avais commencé ce plugin pour justement apprendre le python …mais je trouve pas le temps de m’investir …
Alors je t’invite à commencer là: jeedomdaemon · PyPI
Attention, ce n’est qu’une pré-version mais suffisamment au point pour que je puisse la partager je pense
J’ai adapté mon plugin demo pour qu’il se base sur cette lib (ainsi que plusieurs autres de mes plugins sur ma dev)
Cette lib se repose sur asyncio pour son fonctionnement interne et du coup permet l’utilisation de asyncio dans le code de chacun mais ce n’est absolument pas imposé: libre à chacun de faire l’implémentation qui lui convient dans son code.
