Bonjour,
J’ouvre ce nouveau sujet sur PAC Aldes T.One AquaAir., pour vous partager le fork du projet de @guix77. Il contient des correctifs, et des mecanismes de retry pour gérer les soucis de communications.
Pour le moment, cela semble fonctionner et repondre à mon usage.
la version v3.3.0 est sortie, permettant de voir le mode vacances, le mode hors gel, et de pouvoir également creer via un appel de service une période de vacances.
Bonjour Saniho, j’ai mis à jour mon module de guix77 avec le tiens.
good job ! 
Juste dommage qu’il n’y ait plus d’entité “thermostat” pour chaque pièce mais ça à l’air de mieux fonctionner - plus d’erreurs lors du changement de température. J’utilisais la valeur des thermostats sur des tuiles (pour chaque pièces) de ma page d’accueil.
Parce que je découvre encore, y a t il une entité qui indique l’état de fonctionnement du T-One ? chauffage on ou off ? je n’arrive pas à capter… je pensais que c’était le air mode mais non…
Hello, je vais voir si je peux rajouter l’entité thermostat, et voir indiquer l’etat de fonctionnement( il faut juste que je comprenne la codification )…
Bonjour,
Merci pour ce nouveau projet, et bravo pour le travail effectué ! 
Je viens d’installer, tout semble OK, et l’intégration est vraiment simple à prendre en main et très claire. C’est appréciable 
J’utilisais jusqu’à maintenant un plugin sur HomeBridge installé sur un NAS pour avoir tout ça sur l’appli Maison d’iOS, je vais pouvoir m’en débarrasser.
Trois questions me viennent en tête :
Merci encore pour ce boulot !
Sylvain
Merci @sylvain640
pour les trois questions :
Bonjour,
J’avais pas vu qu’il y avait ce sujet aussi en parallèle de l’autre, je me suis fait avoir vu que les noms se ressemblent 
Je me demande s’il faudrait pas différencier un peu plus les noms pour éviter la confusion.
En tout cas c’est un bon compromis pour ceux qui ont la box officielle. Beau travail 
Hello,
coupure chez moi de la liaison aldes connect… après coup de fil au SAV ALDES, à priori y a une maj de l’application en cours, délais indéfinis
du coup de mon côté je me retrouve sans liaison T-ONE Home Assistant
Idem pour moi, et c’est revenu hier vendredi dans l apres midi
Je découvre ce plugin HA, j’ai fait l’installation cette aprèm, hâte de rentrer à la maison pour tester cela ce soir !
Salut,
Quequ’un avait déjà repris le projet sur ce fork : GitHub - tiagfernandes/homeassistant-aldes: Aldes integration for HomeAssistant based on AldesConnect
Vous pourriez peut être unir vos forces pour le futur des utilisateurs de Connect box qui ne savent pas faire de soudures 
Merci @sylvain640
pour les trois questions :
changement de mode sur ios … tu veux dire via l’appli aldes ?
pour le mode off, oui cela doit etre possible, il faut juste que j’arrive à trouver la commande envoyée au boitier
pour les temps de latences, j’ai moins de problèmes avec le composant que avec le l’application aldes…ps mon composant à un cache, donc si tu veux forcer le refresh, il y a un service nommé aldes.force_refresh
Oups je n’avais pas vu que tu avais répondu à mon message !
Merci pour ton retour !
Merci encore pour ce boulot
Hello 
, yes en plus j’ai réussi à pouvoir afficher et modifier les plannings de programmation depuis HA. Et repris l’ensemble des éléments qui sont dans l’application d’aldes. Mais si @saniho tu as trouvé quelque chose pour faire de retry je suis intéressé par ce que ta fais pour comparer avec ce que j’ai implémenter récemment qui a peut être l’air similaire, parce que leur API REST ne respecte pas trop les standards
Salut @tiagfernandes , en effet ta version à plus de features que la mienne.
Par contre, il y a quelques difference sur l’apisur la gestion des erreurs de connexion :
1. Stratégie de retry (réessai automatique)
La version Saniho utilise le décorateur @backoff.on_exception qui réessaie automatiquement en cas d’échec :
python
@backoff.on_exception(
backoff.expo, (ClientError, asyncio.TimeoutError),
max_tries=3, max_time=60
)
La version Tiago n’a aucun mécanisme de retry automatique - si une requête échoue, elle échoue directement.
2. Gestion des timeouts
La version Saniho définit explicitement un timeout :
python
self._timeout = ClientTimeout(total=30)
La version Tiago n’a pas de timeout configuré, ce qui peut bloquer indéfiniment en cas de problème réseau.
3. Gestion du cache
La version Saniho implémente un système de cache avec TTL qui peut servir de fallback en cas d’erreur :
python
if cache_key in self._cache:
_LOGGER.warning("Using stale cached data due to error.")
return self._cache[cache_key]
La version Tiago n’a aucun mécanisme de cache.
4. Gestion centralisée des requêtes
La version Saniho a une méthode _api_request() qui centralise toute la gestion d’erreurs, alors que la version Tiago répète la logique dans chaque méthode.
5. Gestion des exceptions
La version Saniho capture plus de types d’erreurs : ClientError, asyncio.TimeoutError, KeyError, ValueError, AuthenticationException
La version Tiago ne capture pratiquement aucune exception spécifique dans la plupart de ses méthodes.
…
Ah ok j’avais pas la connaissance de backoff (je suis pas dev python à la base 
) mais il se base que sur des exceptions, sauf que souvent on a la confirmation côté serveur que la commande à bien été prise en compte, donc pas d’exception, et au final c’est jamais pris en compte.
Je prend l’exemple pour les températures des différents thermostats, si on envoi 5 requêtes pour modifier la température 5 thermostats, avec 5-10 secondes d’écart, on peut avoir après 2 min que 2 thermostats de modifiés sur les 5.
Ce problème je sais pas s’il vient côté serveur, ou de la box branchée sur la PAC, du coup j’ai implémenté un fonction qui vérifie après 2 min, si la valeur retournée par le serveur correspond à celle qui avait été transmise, sinon on renvoi la requête
Merci pour ce dev, par contre j’ai installé la version de guix77 et je ne l’ai pas désinstallée. J’ai l’impression que celà peut poser problème non ?
oui il ne faut pas les deux en meme temps
Bonjour,
Je sais pas si vous aviez vu mon message mais j’imagine que tout le monde à une passerelle Aldes ici. Je pense que ça vaut le coup de tenter d’explorer cette piste, ça demanderait aucune soudure, un pauvre ESP32 à 2€ à brancher en USB. Sachant que @yanoooou développé un script pour analyser les trames avec ceci et avec @Neuvidor ils ont déjà analysé la même passerelle (voir ici) avec le chauffe-eau thermodynamique, ça doit ressembler.
Personnellement je n’ai pas de passerelle, mais je peux aider si certains sont motivés.
Salut @djtef j’avais justement commandé un rasp pico pour tester de le sniffer, j’aurai un peu de temps la semaine prochaine pour tester
Bonjour @djtef, le iBUS-Aldes-Sniffer que j’ai développé est pour le Ibus pas pour l’USB. Par contre tu peux utiliser par exemple : usb-sniffer-lite pour sniffer les trames entre la passerelle et la PAC. J’ai déjà essayé de communiquer en USB-CDC avec un ESP32S2 et ESP8266, sans succès.