TOUG : passerelle DIY ESPHome pour PAC Aldes T.One

Une passerelle locale, ouverte… et fiable

La TOUG (T.One Ultimate Gateway) est une passerelle DIY basée sur ESPHome qui permet de piloter entièrement en local une pompe à chaleur Aldes T.One AIR ou AquaAIR, sans cloud et sans passerelle propriétaire.

Ethernet, Modbus, télécommande, USB, bouches motorisées, ECS solaire, sécurité et intégration Home Assistant : tout y est.

Le tout dans un boîtier rail DIN propre, fiable, et surtout…
👉 qui fonctionne sans qu’on ait à y penser.

Projet 100 % open-source, né et développé avec la communauté HACF ❤️

Contexte & objectif

Le T.One AIR/AquaAIR n’est pas une PAC gainable “classique”.
Une PAC gainable traditionnelle souffle l’air via un réseau de gaines distribué dans la maison.

 Le T.One adopte une autre approche :

• Pas de gaines visibles ni encombrantes, mais un plénum intégré dans le faux-plafond qui répartit l’air.
• Des bouches motorisées pièce par pièce, chacune associée à un thermostat sans fil.
• Une unité intérieure compacte, qui regroupe pompe à chaleur, appoint électrique et (sur AquaAIR) ballon d’eau chaude sanitaire.

Sur le papier, c’est séduisant. Dans la pratique tout passe par la passerelle AldesConnect® Box (environ 200 €), fermée et cloud-dépendante, obligatoirement reliée à l’application AldesConnect… une appli à la réputation légendaire : 1,4/5 sur le store. Autant dire qu’on a affaire à un “chef-d’œuvre logiciel”.

AldesConnect Box

Il faut donc se passer de la passerelle officielle et chercher des alternatives. Et autant le dire tout de suite, il a fallu se débrouiller seuls, car Aldes ne fournit aucune documentation sur d'éventuelles interfaces de communication alternatives.

En analysant la carte mère du T.One, on peut apercevoir plusieurs connecteurs :

• L'USB de la passerelle officielle
• Un connecteur nommé Modbus
• Un connecteur nommé iBus
• Un connecteur nommé Remote qui est branché à l'écran central, appelé télécommande dans la documentation d'Aldes.

Après de longues heures de recherches et d'analyses, on en sait à présent un peu plus sur chaque connecteur.

• L'USB implémente un hôte USB CDC ACM qui est ni plus ni moins qu'un port série sur lequel Aldes a implémenté son propre protocole
• Le Modbus (RS485) a bien été implémenté et un membre a réussi à se procurer une documentation officieuse d'Aldes
• L’iBUS est un bus de communication propriétaire Aldes, alimenté en 24 V et à logique inversée, proche dans son principe de l’eBUS, utilisé par la carte mère pour dialoguer avec la passerelle Aldes Connect. Cette interface n'a pas été retenue car elle nécessite des composants électroniques pour la décoder et elle n'apporte rien de plus que l'USB.

• La télécommande implémente également le protocole Modbus mais sur un autre bus dédié. Jouant le rôle de client, nous ne pouvons donc pas nous brancher en parallèle, il faudra la remplacer pour communiquer avec cette interface.

Une fois les possibilités analysées, nous pouvons définir les objectifs :

• Reprendre la main localement
• Avoir un matériel et logiciel fiables
• Être intégré dans un boîtier, bien câblé, discret et accepté par toute la famille (pas question d’un tas de fils qui pendouillent dans la chaufferie)
• Remplacer la télécommande (écran central)
• Répondre aux besoins de tous les utilisateurs du forum :
  • Gestion des thermostats, du chauffage, de la clim, ECS
  • Lecture des températures des pièces
  • Détection des ouvertures des bouches motorisées
  • Branchement USB (comme la passerelle officielle)
  • Bonus : pouvoir intégrer un routeur solaire

📊 Récapitulatif des interfaces disponibles

Une passerelle pensée comme un ensemble de briques

Dès les premières versions, un principe s’est imposé naturellement : la TOUG devait rester modulaire.

Tout le monde n’a pas les mêmes besoins, ni le même niveau d’exigence, ni les mêmes contraintes. Certains veulent simplement lire des informations et les exposer dans Home Assistant. D’autres veulent piloter finement la machine, interfacer un routeur solaire, détourner des entrées, ajouter des relais, expérimenter.

Plutôt que de concevoir une carte “tout-en-un” lourde, complexe et coûteuse, le choix s'est porté sur un socle commun solide, sur lequel chacun peut ensuite bâtir ce dont il a réellement besoin. C’est cette philosophie qui a guidé les choix techniques : des jumpers plutôt que des décisions irréversibles, des interfaces séparées plutôt qu’un bus opaque, des interrupteurs à glissière, et surtout une architecture suffisamment lisible pour qu’un maximum de personnes puisse comprendre ce qu’il fait — et pourquoi il le fait.

On peut considérer que la TOUG est structurée autour de 7 grandes fonctions :

1. Alimentation
2. ESP32 (WT32-ETH01)
3. Modbus utilisateur
4. Télécommande (écran central)
5. Interface USB (passerelle Aldes)
6. Détection (bouches, appoint)
7. Routeur solaire ECS (optionnel)

Finalement, seuls l’alimentation et l’ESP32 sont indispensables.
Tout le reste est optionnel, activable ou non selon les besoins.

Dans la prochaine partie, nous allons détailler chaque fonction : leur but, les choix techniques et la réalisation.

ESPHome comme fondation logicielle

Côté logiciel, le choix d’ESPHome s’est imposé naturellement.

La philosophie est simple :

• bénéficier des composants déjà implémentés
• ne coder que les spécificités
• exposer un maximum d’entités natives,
• laisser Home Assistant faire ce qu’il sait faire de mieux : orchestrer.

La TOUG expose ainsi :

• des thermostats,
• des températures,
• des modes de fonctionnement (ECS, Chauffage, Clim...)
• des capteurs internes,
• des commandes avancées (installateur, tests, programmation).

Modularité totale : réutilisable dans d’autres projets

Le code ESPhome est découpé en différents YAML par fonction pour qu’ils puissent être inclus proprement dans n’importe quel projet ESPHome (comme la TOUG), via un simple !include.

👉 C’est totalement modulaire

Cela permet à d’autres projets passerelles d’intégrer par exemple directement l’émulation de télécommande sans réécrire une seule ligne.
Il suffit d’inclure les fichiers, déclarer l’UART… et ça marche.

Cette modularité était primordiale: que chacun puisse en bénéficier facilement, TOUG ou autre.

L'alimentation

Ce n'est pas la partie à laquelle on pense en premier quand on réalise une passerelle, mais à la fin, c'est la plus importante, car sans elle, rien ne fonctionne.

Pour la concevoir, il faut se poser deux questions : de quoi a-t-on besoin et qu'avons-nous à disposition ?

Pour le besoin, c'est classique, tous nos composants s'alimentent en 5 V (dont la plupart en 3.3 V également). L'ESP32 WT32-ETH01 n'ayant pas de connecteur USB, il faut obligatoirement ajouter un connecteur d'alimentation à notre passerelle.

Pour alimenter notre carte, le plus simple est d'utiliser les tensions disponibles sur la carte mère :

• 5 V par l'USB
• 12 V sur le connecteur Modbus
• 12 V sur le connecteur de la télécommande

La carte devant rester modulaire, l'alimentation est sélectionnable par jumpers:

• Le premier permet de choisir la source 5 V ou 12 V
• Pour le 12 V, un deuxième permet de choisir la source (Modbus ou télécommande)

Pour utiliser le 12 V, un module convertisseur DC-DC réglable a été ajouté pour fournir le 5 V.

Pour finir, un interrupteur latéral ON/OFF accessible facilement a été ajouté, ainsi qu'un condensateur de filtrage de 10 µF pour stabiliser la tension.

Le cœur : un ESP32 Ethernet fiable

Le choix du WT32-ETH01 n’est pas anodin.

Il apporte :

• un port Ethernet natif, bien plus fiable que le Wi-Fi (disponible également) en chaufferie,
• 3 UART pour gérer deux bus Modbus distincts ainsi que la communication USB
• un nombre suffisant de GPIO
• une parfaite compatibilité avec ESPHome.

La TOUG peut communiquer ainsi :

• avec le Modbus utilisateur,
• avec le Modbus de la télécommande,
• avec l’interface USB CDC de la carte mère.

Le WT32-ETH01 n'ayant pas de port USB, il faut un convertisseur USB/TTL pour le flasher (souvent appelé FTDI). Pour entrer en mode Flash, il faut également mettre le GPIO0 à la masse.

Pour simplifier cette opération, un connecteur femelle coudé est ajouté en bord de passerelle pour y brancher directement la carte FTDI. De plus, un interrupteur latéral est disponible à ses côtés et permet d'activer le mode Flash facilement.

Pour être tout à fait complet, un condensateur de découplage de 100 nF est ajouté au plus près de la broche 5 V.

Le Modbus utilisateur

Le Modbus utilisateur est la première interface officielle facilement exploitable fournie par Aldes sur le T.One.

Étrangement aucune documentation officielle n'y fait référence. Cela reste un mystère, car c'est un gros avantage sachant que les principales fonctions que nécessite une installation domotique y sont présentes. Une documentation officieuse a été publiée sur le forum.

Techniquement, il s’agit d’un bus Modbus RTU sur liaison RS485 (19 200 bauds, parité paire avec 1 bit de stop), exposé sur un connecteur dédié de la carte mère.

Ce bus permet notamment :

• de piloter les consignes des thermostats individuellement
• de piloter les modes (chauffage, clim et ECS)
• de lire le volume et la température ECS
• de lire la température de la pièce principale

Choix techniques

Pour interfacer proprement ce bus avec l’ESP32, la TOUG repose sur une architecture classique, mais robuste :

• un module TTL ↔ RS485 dédié,
• connecté à l'UART1 matériel du WT32-ETH01,
• avec un level shifter pour garantir des niveaux logiques propres et fiables en 3,3 V coté ESP32.

La ligne RS485 est accessible via un connecteur dédié, permettant un câblage propre vers la carte mère, sans bricolage ni soudure volante.

Intégration logicielle

Côté logiciel, ESPHome fournit déjà tout le nécessaire :

• composant modbus,
• gestion des délais, CRC, timeouts,
• exposition native des entités dans Home Assistant.

La TOUG se contente donc de déclarer les registres utiles et les décoder, Home Assistant fait le reste.

Pour les utilisateurs disposant d’une T.One de dernière génération, le Modbus utilisateur constitue souvent le socle principal de la communication.

L’interface télécommande (écran central)

Sur les générations plus anciennes de T.One (notamment Ribo / RBUV), le Modbus utilisateur est absent.
Dans ce cas, toute l’intelligence passe par l'écran central, aussi appelée télécommande dans la documentation Aldes.

Cette télécommande n’est pas un simple afficheur :
elle échange en permanence avec la carte mère via un bus Modbus dédié, distinct du Modbus utilisateur.

Une contrainte majeure

La télécommande joue le rôle de client Modbus.
Cela implique une contrainte importante :

👉 il est impossible de se brancher en parallèle sur ce bus sans perturber la communication. Il faut donc la remplacer complètement pour utiliser cette interface.

Principe retenu

La TOUG se substitue à la télécommande Aldes :

• elle se connecte directement sur le bus dédié,
• elle implémente le protocole attendu,
• et elle reproduit fidèlement les échanges nécessaires au bon fonctionnement de la machine.

Ce travail a nécessité :

• beaucoup de reverse-engineering,
• de longues phases d’observation et de tests,
• et de nombreuses itérations pour couvrir tous les cas (chauffage, ECS, climatisation, erreurs, états transitoires, mode installateur…).

Implémentation matérielle

D’un point de vue matériel, l’interface télécommande repose sur :

• un second module TTL ↔ RS485,
• connecté à l'UART2 matériel de l’ESP32,
• sur le second canal du level shifter du Modbus utilisateur,
• un connecteur pour brancher la télécommande (le même que la carte mère)
• un connecteur dédié vers la carte mère,
• un interrupteur pour activer/désactiver la télécommande physique

Cette séparation physique et logique permet :

• d’éviter toute ambiguïté entre les bus,
• de remplacer la télécommande en coupant son alimentation,
• la réactiver en cas de besoin.

Intérêt fonctionnel

Cette interface est centrale et la plus complète dans la TOUG :

• elle permet de piloter la PAC même sans Modbus utilisateur,
• elle fournit des informations plus riches et plus cohérentes (état réel des bouches, modes actifs),
• elle devient la référence fonctionnelle pour les modèles anciens (Ribo / RBUV)
• et elle reste pertinente même sur les modèles récents, en complément du Modbus utilisateur.

Elle permet entre autres de :

• lire les températures de chaque pièce
• lire les températures haut et bas ECS
• modifier les réglages du T.One
  • Date/heure
  • Prix du kWh
  • Composition du foyer
  • Devise
• lire une multitude de capteurs des groupes intérieurs et extérieurs
  • pressions
  • températures
  • fréquences
  • puissances
  • dégivrages
  • bouches
  • filtre…
• afficher les défauts et erreurs
• afficher les consommations (ECS, chauffage, clim, appoint)
• gérer la programmation horaire chauffage (prog. A et B) et clim (C et D)
• activer les modes Vacances et Hors-gel

Interface USB

Sur la carte mère du T.One, un port USB est présent dès l’origine.
C’est celui utilisé par la passerelle officielle AldesConnect®, et c’est également par ce biais que l’application mobile communique avec la machine.

Ce que fait réellement l’USB

Contrairement à ce que l’on pourrait penser, l’USB n’expose pas un périphérique complexe ou propriétaire au sens USB du terme.

La carte mère implémente un périphérique USB CDC ACM, c’est-à-dire…
👉 un port série.

On en a confirmation lorsqu'on branche la passerelle AldesConnect sur un PC :

[300161.390849] usb 1-2: new full-speed USB device number 9 using xhci_hcd
[300161.541031] usb 1-2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[300161.541038] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[300161.541042] usb 1-2: Product: STM32 Virtual ComPort
[300161.541045] usb 1-2: Manufacturer: STMicroelectronics
[300161.541047] usb 1-2: SerialNumber: 00000000001A
[300161.575392] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[300161.575673] usbcore: registered new interface driver cdc_acm
[300161.575674] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Aldes y a ensuite implémenté son propre protocole applicatif, au-dessus de cette liaison série.

En clair :

• l’USB = un UART encapsulé,
• le protocole = 100 % logiciel,
• et la passerelle officielle n’est qu’un adaptateur wifi + un logiciel fermé.

Choix technique : MCP2221A

Pour interfacer l’ESP32 avec l’USB de la carte mère, il fallait un composant capable de :

• jouer le rôle de périphérique USB CDC ACM,
• exposer une liaison série exploitable,
• être fiable, documenté et disponible.

Le choix s’est porté sur le MCP2221A de Microchip.

Il s’agit d’un convertisseur USB ↔ UART / GPIO, largement utilisé, bien documenté, et parfaitement adapté à ce type de montage.

👉 Le MCP2221A permet de séparer clairement les responsabilités :

• USB d’un côté,
• UART de l’autre,
• et l’ESP32 reste dans ce qu’il sait faire de mieux.

Architecture matérielle

L’interface USB de la TOUG repose donc sur :

• un MCP2221A en CMS,
• connecté à un port USB C,
• et relié à l’ESP32 via un UART dédié.

Un interrupteur à glissière permet de choisir dynamiquement l'UART à utiliser ou de le désactiver. Ceci est utile pour activer les logs sur le port série de l'ESP32, ou pour changer d'UART si le modbus n'est pas utilisé.

Reverse-engineering : un travail toujours en cours

Le protocole USB Aldes n’est évidemment pas documenté.

Il a fallu :

• observer les échanges entre la passerelle officielle et la PAC,
• décoder les trames,
• comprendre les commandes critiques,
• et vérifier les effets réels sur la machine.

Une partie importante du protocole est aujourd’hui comprise :

• lecture d’états,
• commandes principales,
• cohérence avec les autres interfaces (Modbus, télécommande).

👉 Le reverse-engineering de l’USB est toujours en cours, mais la base est solide et exploitable.

C’est aussi pour cette raison que la TOUG a été pensée comme un projet évolutif :
le matériel est prêt, même si toutes les fonctionnalités ne sont pas encore exploitées.

Pourquoi conserver l’USB si Modbus existe ?

La réponse est simple :

• le Modbus est stable, mais limité et demande une connectique spécifique vers la carte mère.
• l’USB est plus complet, fidèle au comportement officiel et très facile à brancher, tout le monde a un câble USB chez lui.

En résumé :

si Aldes peut le faire via sa box, la TOUG pourra le faire aussi — localement.

Routeur solaire

Pourquoi intégrer un routeur solaire ?

Le T.One AquaAIR dispose d’une résistance d’appoint ECS, initialement prévue pour :

• compléter la PAC en cas de grand froid,
• assurer le cycle anti-légionellose (50 → 60 °C).

Lorsqu’on dispose d’une installation photovoltaïque, cette résistance devient une opportunité idéale pour valoriser le surplus solaire.

L’objectif est donc simple :

utiliser l’énergie excédentaire pour chauffer l’eau, sans perturber le fonctionnement normal de la PAC, ni compromettre la sécurité.

Prérequis

Le routeur solaire est externe à la TOUG.

La seule contrainte est qu’il puisse être :

• piloté à distance,
• depuis ESPHome ou Home Assistant.

Personnellement, le choix s’est porté sur le routeur f1atb, dans sa version UxI (sonde de courant simple), pour plusieurs raisons :

• simplicité,
• coût réduit,
• pilotage via MQTT.

👉 Mais n’importe quel routeur compatible conviendra.

Contraintes et sécurités

Limites thermiques

• Au-delà de 60 °C, la PAC déclenche une erreur :

Température ECS trop haute

• Au-delà de 80 °C, la sécurité thermique mécanique (KT°1) se déclenche.

👉 Il est donc impératif de :

• bloquer la température vue par la PAC à 60 °C,
• tout en continuant à mesurer la température réelle,
• arrêter le routeur avant 80 °C.

Stratégie globale

La stratégie retenue repose sur trois principes :

1. En dessous de 60 °C
   → fonctionnement strictement constructeur côté T.One
   → le routeur chauffe de manière autonome
2. Au-dessus de 60 °C
   → le T.One “voit” 60 °C
   → le routeur continue de chauffer
   → la TOUG surveille la température réelle
3. Sécurité absolue
   → si une sonde dépasse 80 °C (haut, bas ou Modbus)
   → le routeur est immédiatement coupé

Principe de falsification de température

Les sondes de température ECS sont des NTC 10 kΩ.

Chaque température correspond à une résistance précise : à 60 °C, la résistance est d’environ 2.3 kΩ.

Au-delà de 60 °C, l’idée est donc simple :

• déconnecter les sondes réelles de la PAC,
• les remplacer par des résistances fixes équivalentes à 60 °C,
• tout en continuant à lire les vraies sondes ailleurs.

Architecture matérielle

Commutation des sondes

Un relais Omron G6K-2P (U15), alimenté en 3.3 V, permet de basculer :

• soit vers les sondes NTC réelles (TempH_Sonde, TempB_Sonde),
• soit vers des résistances fixes de 2.4 kΩ (R23+R22 et R21+R20).

Par défaut (relais au repos) :
👉 fonctionnement strictement constructeur.

Commande du relais

Le relais est piloté via un transistor NPN 2N2222 (Q4) :

• R17 (820 Ω) limite le courant de base,
• le transistor est correctement saturé,
• en cas de panne, le relais reste au repos (sécurité passive).

Lecture des sondes réelles

Lorsque les sondes sont déconnectées de la PAC, il faut continuer à les mesurer.

Un ADC ADS1115 est utilisé, avec des diviseurs de tension VDIV réalisés par R19 et R18 (10 kΩ).

Problème clé :

Ces diviseurs ne doivent exister que lorsque les sondes sont déconnectées de la PAC, sous peine d’interférer avec le diviseur interne de la carte mère.

Activation conditionnelle des diviseurs

L’alimentation des diviseurs est contrôlée par un MOSFET P AO3401 (Q6) :

• VDIV est alimenté (3.3V) uniquement quand nécessaire,
• R14 (100 kΩ) garantit un OFF par défaut,
• R15 (100 Ω) limite les courants transitoires.

Synchronisation relais / diviseurs

Un seul GPIO pilote l’ensemble. Problème, pour falsifier les sondes :

• Le relais nécessite un niveau HIGH,
• Le MOSFET nécessite une mise à la masse de sa grille.

Ainsi, un second transistor 2N2222 (Q4) permet d’inverser la commande du MOSFET :

• HIGH → relais activé + diviseurs actifs

Résultat final

✔ Sécurité passive
✔ Aucune interaction parasite
✔ Une seule commande GPIO
✔ PAC jamais en erreur
✔ Température réelle toujours mesurée

Interaction avec la carte mère

Si la carte mère demande l’appoint ECS :

• le routeur est forcé à 100 %,
• jusqu’à ce que la demande cesse.

🌞 Bonus — Une pompe à chaleur asservie au surplus solaire

L’intégration complète de la télécommande dans la TOUG ne permet pas uniquement de remplacer l’écran central.

Elle ouvre également l’accès au menu installateur, et donc aux modes de test internes de la PAC, directement depuis Home Assistant.

Parmi ces modes, deux sont particulièrement intéressants :

• Test Chauffage
• Test Climatisation

Ces modes permettent de forcer :

• la vitesse du ventilateur intérieur,
• la fréquence du compresseur,

des paramètres directement liés à la puissance électrique consommée par la machine.

Démonstration

Voici ce qu'il se passe lorsqu'on active le mode Test du chauffage et qu'on joue sur les consignes. La démo est accélérée, car elle durerait plusieurs minutes en réalité. À noter que la puissance du Linky n’est pas fournie par la TOUG, c’est juste pour montrer le lien de cause à effet.

Vers un asservissement au surplus solaire

En pilotant dynamiquement ces paramètres depuis Home Assistant ou ESPHome, il devient possible d’adapter la puissance du T.One :

• en fonction du surplus de production photovoltaïque,
• sans modifier le fonctionnement interne de la PAC,
• en restant dans des modes prévus par le constructeur (tests installateur).

Concrètement, cela ouvre la voie à :

• une PAC qui ne consomme plus quand le soleil produit,
• et qui se fait plus discrète quand le surplus disparaît.

On ne parle plus seulement de “router l’appoint ECS”,
mais bien d’un pilotage fin de la PAC elle-même, intégré dans une logique énergétique globale.

Climatisation et solaire : une adéquation parfaite

Il y a un point particulièrement intéressant dans cette approche, et souvent sous-estimé :
👉 la climatisation est précisément nécessaire quand la production solaire est maximale.

• il fait chaud → besoin de clim,
• il fait soleil → production photovoltaïque élevée,
• donc du surplus disponible.

Le mode de test Climatisation permet justement de piloter finement la puissance de la PAC, ce qui en fait un cas d’usage idéal pour l’autoconsommation solaire.

Un scénario énergétique cohérent sur la journée

On peut alors imaginer un fonctionnement très naturel :

• Matinée / fin de matinée
  • surplus solaire utilisé pour chauffer l’ECS via le routeur,
  • montée progressive de la température du ballon.
• Après-midi
  • une fois l’ECS à température,
  • bascule automatique vers la climatisation “gratuite”,
  • la PAC ajuste sa puissance en fonction du surplus restant.

Le surplus n’est plus subi ni écrêté :
👉 il est converti en confort thermique, au bon moment.

La TOUG devient alors non seulement une passerelle de pilotage,
mais un véritable chef d’orchestre énergétique entre production solaire, ECS et confort d’été.

En résumé

Grâce à la TOUG, le T.One peut devenir un acteur à part entière de l’optimisation énergétique de la maison, et pas seulement un consommateur passif.

Détection (bouches, appoint)

Au-delà des interfaces de communication (Modbus, télécommande, USB), la TOUG intègre également une brique dédiée à la détection d’événements matériels directement issus de la carte mère.

L’objectif n’est pas de piloter ces éléments, mais de savoir ce que fait réellement la machine, indépendamment des ordres envoyés :

• est-ce que l’appoint est sollicité ?
• quelles bouches sont en train d’être actionnées ?
• quand et combien de temps ?

Cette approche apporte une vision beaucoup plus fine du fonctionnement réel du T.One, utile pour le diagnostic, l’optimisation énergétique et l’intégration domotique avancée.

Détection de l’appoint électrique

Le T.One dispose d’une résistance électrique d’appoint, utilisée notamment pour :

• compléter la PAC en conditions défavorables,
• assurer certains cycles spécifiques (montée en température ECS, anti-légionellose),
• sécuriser le fonctionnement global.

Lorsque la résistance d'appoint est pilotée par un routeur solaire, il est fondamental de savoir précisément quand cet appoint est sollicité.

Principe (avec routeur solaire)

La TOUG détecte la demande d’appoint directement au niveau de la carte mère, sans intervenir sur la puissance ni sur la commande de la résistance.

Voici le schéma électrique de l'alimentation extrait de la notice d'installation :

Le principe est simple :

• On déconnecte la phase de l'alimentation d'appoint ALIM_1 et on la remplace par la sortie Ref/K6- de la TOUG. Selon la position du jumper RES APP REF, la TOUG enverra GND ou 3.3V.

• On déconnecte la résistance d'appoint du connecteur TANK HW et on la connecte directement à la sortie du routeur solaire (phase et neutre), qui devait précédemment être connecté sur ALIM_1.
• On relie le connecteur TANK HW à l'entée RA/K6+ de la TOUG.

Ainsi, lorsque le relais est activé, l'ESP32 recevra sur son GPIO le GND ou 3.3V (selon le jumper RES APP REF), ce qui permettra de détecter quand le T.One commande la résistance d'appoint.

👉 Il ne s’agit pas d’une estimation logicielle, mais bien d’un retour matériel réel.

Intérêts concrets

Cette détection permet notamment :

• de savoir exactement quand l’appoint est utilisé,
• de mesurer sa durée d’activation,
• d’alimenter un routeur solaire ECS de manière cohérente,
• de détecter un comportement anormal (appoint trop fréquent ou inattendu).

Détection des bouches motorisées

Les bouches motorisées du T.One constituent un élément central du fonctionnement pièce par pièce : elles ouvrent ou ferment le flux d’air en fonction des consignes des thermostats de chaque pièce.

Contrairement à ce que l’on pourrait penser, la TOUG ne pilote jamais directement les bouches.
Elle se contente de faire ce qu’elle fait partout ailleurs : observer, comprendre, exposer.

Pourquoi détecter les bouches ?

La détection des bouches présente plusieurs intérêts selon les configurations :

• vérifier qu’une demande de chauffage / clim entraîne bien une ouverture réelle,
• savoir quelle pièce est en train de chauffer / rafraichir
• corréler l’état des bouches avec :
  • les thermostats,
  • les consignes,
  • la puissance réellement délivrée par la PAC,

Cependant, cette détection n’est pas indispensable dans tous les cas.

👉 Lorsque la TOUG remplace complètement la télécommande Aldes, l’état des canaux actifs est déjà accessible via le protocole de la télécommande, de manière plus directe et plus fiable.

La détection matérielle des bouches devient alors optionnelle, utile principalement :

• pour les modèles sans télécommande remplacée,
• ou à des fins de vérification matérielle indépendante.

Subtilité importante : des bouches à alimentation intermittente

Les bouches du T.One ne sont pas pilotées par un moteur classique, mais par un vérin thermique.

Principe :

• une résistance interne chauffe un élément thermique,
• ce chauffage provoque l’ouverture de la bouche,
• une fois la position atteinte, l’alimentation peut être coupée temporairement.

Conséquence directe :
👉 l’absence de tension ne signifie pas “bouche fermée”.

La détection ne permet donc pas de connaître la position mécanique absolue de la bouche, mais uniquement de détecter une phase d’activation, c’est-à-dire :

“la carte mère est en train de chauffer le vérin de cette bouche”.

Ainsi, pour tirer des conclusions, il faut observer l'alimentation de la bouche pendant quelques minutes. C’est une information partielle, mais extrêmement précieuse pour comprendre le comportement réel du système.

Principe retenu

La TOUG détecte la présence de tension 12 V sur l’alimentation des bouches motorisées.

• aucune coupure,
• aucune modification du câblage constructeur,
• aucune charge supplémentaire significative.

On se branche en parallèle des bouches, on reste dans une logique :

strictement passive et non intrusive.

Architecture matérielle

La détection repose sur des cartes à 4 optocoupleurs 12 V → 3,3 V.

Chaque canal est constitué de :

• une entrée 12 V issue de l’alimentation d’une bouche,
• un optocoupleur assurant :
  • isolation galvanique complète,
  • protection de l’ESP32,
  • immunité aux parasites,
• une sortie logique 3,3 V exploitée directement par un GPIO de l’ESP32.

L'avantage de ce choix est que la TOUG n'a aucune interaction électrique avec la carte mère et il simplifie grandement la fabrication : il suffit d'enficher un module tout prêt.

Nombre de bouches détectables

L'ESP32 WT32-ETH01 ne disposant plus que de 6 GPIO une fois les 3 UART utilisés, on ne peut détecter que 6 bouches maximum (nommés K1 à K6 sur le T.One). Les autres peuvent néanmoins être suivies via l’interface télécommande lorsqu’elle est remplacée.

Comme pour le reste du projet : rien n’est imposé.
La détection des bouches est entièrement optionnelle et dépend :

• des besoins réels,
• du modèle de T.One,
• des autres briques activées sur la passerelle.

En résumé

✔ détection passive et sans pilotage
✔ isolation électrique complète
✔ jusqu’à 6 bouches (4 avec routeur solaire)
✔ commande de la résistance d'appoint
✔ optionnel

👉 La TOUG ne se contente pas de piloter la PAC : elle observe ce qui se passe réellement de manière non intrusive.

Bonus : extensions

Afin de répondre au maximum de besoins, la TOUG expose volontairement :

• Un connecteur pour le bus I2C
• Un bornier pour chaque alimentation : 12 V, 5 V et 3,3 V
• La possibilité de bypasser les cartes optocoupleurs par de simples jumpers pour avoir accès directement aux 6 GPIO

Le boîtier

Dans le cahier des charges, une exigence est essentielle : l’intégration dans le placard de la PAC.
Il fallait absolument que ce soit discret et connecté de manière fiable.
N’ayant pas d’imprimante 3D, j’ai décidé tout d’abord de choisir le boîtier et de faire la carte en fonction.
Pour cela, j'ai trouvé un boîtier tout prêt et pas cher sur Aliexpress :

• Boîtier générique au format rail DIN (9 modules)
• Ouverture et fermeture via clips
• Fixation de la carte par vis

Il répond à 100 % au besoin, ça fait une très belle finition.

Connectique

Connecteurs et borniers

Pour que le câblage soit robuste et bien connecté, les mêmes connecteurs que la carte mère ont été choisis. Ainsi les câbles peuvent se brancher sans adaptation directement sur la passerelle :

• Connecteur femelle JST S04B-XASK-1(LF)(SN) pour brancher directement la télécommande
• Connecteur femelle JST S06B-XASK-1(LF)(SN) pour brancher directement les sondes ECS

Pour les détections des bouches et de l'appoint, des borniers à vis débrochables ont été préférés aux simples borniers. En effet, c’est très pratique pour la maintenance, ça permet de tout déconnecter et reconnecter très rapidement, sans se poser de question et se tromper.

Rallonges

Bien qu'on puisse connecter les câbles du T.One directement sur la TOUG, si on veut pouvoir la disposer à proximité sans laisser le capot ouvert, il est indispensable d'ajouter des rallonges.

Pour cela, il faudra fabriquer ces rallonges à partir de nappes 4 fils et sertir des connecteurs mâles et femelles.

Vue d'ensemble

Le schéma ci-dessous reprend toutes les connexions possibles avec la TOUG.

Installation ESPhome

La première installation de ESPhome dans la TOUG doit être réalisée avec l'adaptateur FTDI connecté à un PC.

Positionner l'interrupteur de la TOUG FLASH MODE sur FLASH avant de brancher le FTDI.

Vérifier que le jumper du FTDI est bien sur 5 V.

Il suffit d’installer python et esphome sur le PC, la procédure est expliquée ici.

Il faut ensuite récupérer le template qui permettra de télécharger le code de la TOUG directement sur Github.

Editer le YAML en suivant les 5 étapes en commentaires qui permettront de personnaliser ESPhome en fonction du T.One connecté.

Renommer le fichier en toug.yaml.

Ensuite lancer la ligne de commande:

esphome run toug.yaml

Le code se compile puis ESPhome va demander sur quelle interface télécharger le binaire. Il faut sélectionner le port COM correspondant au FTDI.

Une fois le binaire flashé, remettre l'interrupteur FLASH MODE sur OFF puis rebrancher le câble USB de l'adaptateur FTDI pour redémarrer la TOUG.

La page web ESPHome de la TOUG devient disponible sur une adresse ip qu'il faut déterminer (le logiciel Advanced IP Scanner peut aider à la trouver).

Si tout s'est bien passé, Home Assistant détecte automatiquement un nouvel appareil ESPhome.

Les prochaines mises à jour pourront se faire directement depuis l'Addon ESPHome Builder dans Home Assistant. La procédure détaillée est décrite sur Github.

Intégration Home Assistant

Une fois l’intégration de la TOUG avec ESPhome faite, on peut tout piloter depuis Home Assistant. Voici un aperçu des entités disponibles :

Thermostats

Installer hass-template-climate dans HACS et ajouter le thermostat dans le configuration.yaml.

L'exemple suivant est pour la pièce principale (K1) et doit être adapté en fonction du nom des entités de chacun :

climate:
  - platform: climate_template
    name: Séjour
    unique_id: sejour_k1a_climate_template
    icon_template: mdi:home-thermometer
    availability_template: >- 
        {{ is_state('sensor.aiguillage_vanne', 'Air') 
        or  is_state('sensor.aiguillage_vanne', 'Standby')
        or  is_state('sensor.aiguillage_vanne', 'ECS') }}
    modes:
      - "heat"
      - "cool"  # Si la climatisation est activée
      - "off"
    preset_modes:
      - comfort
      - eco
      - away
      - home
      - boost
      - none
    hvac_mode_template: >-
      {% if 'Chauffage' in states('select.mode_air') %} 
          heat
      {% elif 'Clim' in states('select.mode_air') %} 
          cool
      {% else %} 
          off      
      {% endif %}
    preset_mode_template: >-
      {% if is_state('select.mode_air', 'Off') %}
        none
      {% elif 'Confort' in states('select.mode_air') %}
        comfort
      {% elif 'Prog A' in states('select.mode_air') or 'Prog C' in states('select.mode_air') %}
        away
      {% elif 'Prog B' in states('select.mode_air') or 'Prog D' in states('select.mode_air') %}
        home
      {% elif 'Eco' in states('select.mode_air') %}
        eco
      {% elif 'Boost' in states('select.mode_air') %}
        boost
      {% else %}
        none
      {% endif %}
    set_preset_mode:
      - action: select.select_option
        data:
          entity_id: select.mode_air
          option: >-
            {% if 'Chauffage' in states('select.mode_air') %} 
                {% if preset_mode == 'none' %}
                    Off
                {% elif preset_mode == 'comfort' or preset_mode == 'boost' %}
                    Confort Chauffage
                {% elif preset_mode == 'away' %}
                   Prog A Chauffage
                {% elif preset_mode == 'home' %}
                   Prog B Chauffage
                {% elif preset_mode == 'eco' %}
                   Eco Chauffage
                {% endif %}
            {% elif 'Clim' in states('select.mode_air') %} 
              {% if preset_mode == 'none' %}
                    Off
                {% elif preset_mode == 'comfort' or preset_mode == 'eco' %}
                    Confort Clim
                {% elif preset_mode == 'away' %}
                   Prog C Clim
                {% elif preset_mode == 'home' %}
                   Prog D Clim
                {% elif preset_mode == 'boost' %}
                   Boost Clim
                {% endif %}
            {% else %}
              Off
            {% endif %}
    set_hvac_mode:
      - action: select.select_option
        data:
          entity_id: select.mode_air
          option: >-
            {% if hvac_mode == 'heat' %}
              Confort Chauffage
            {% elif hvac_mode == 'cool' %}
              Confort Clim
            {% elif hvac_mode == 'off' %}
              Off
            {% else %}
              Off
            {% endif %}
    hvac_action_template: >-
      {% if is_state('binary_sensor.bouche_k1a', 'off') %}
        off
      {% elif 'Chauffage' in states('select.mode_air') %}
        heating
      {% elif 'Clim' in states('select.mode_air') %}
        cooling
      {% else %}
        idle
      {% endif %}

    #current_humidity_template: "{{ states('sensor.aqara_temperature_et_humidite_thermostat_k1a_humidity') }}" # Avec capteur additionnel
    temp_step: 1
    current_temperature_template: "{{ states('sensor.temperature_piece_principale') }}"     
    min_temp: 0
    max_temp_template: >-
      {% if 'Chauffage' in states('select.mode_air') %} 
          24
      {% elif 'Clim' in states('select.mode_air') %} 
           31
      {% else %} 
          24        {##  pas vraiment besoin  ##} 
      {% endif %}
    target_temperature_template: "{{ states('number.thermostat_1') }}" 
    set_temperature:
      - action: number.set_value
        data:
          entity_id: number.thermostat_1  
          value: "{{ temperature }}"

Voici le résultat :

Programmation horaire

La télécommande (écran central) ayant été complètement implémentée, il est possible de modifier la programmation horaire depuis Home Assistant. Afin d’avoir une ergonomie semblable à la télécommande, plusieurs étapes sont nécessaires.
La procédure est expliquée pas à pas sur la page Github.

Voici le résultat :

En image

Après toutes ces explications, voici le rendu final.

Retour d’expérience

Cela fait maintenant bientôt 1 an que la TOUG tourne en production — et même 18 mois si on compte la version breadboard pleine de fils Dupont : ça fonctionne parfaitement.

La fiabilité est au top : aucun plantage, aucune intervention, juste du 100 % disponible.

Côté automatisations, j’ai ajouté :

• Alerte si température ECS ou pièce principale trop basse
• Coupure automatique du chauffage si une fenêtre est ouverte
• Réglage des thermostats selon les absences
• Gestion complète du routeur solaire
• Notification « Douchez-vous, l’eau est à température max ».

Et ce n’est qu’un début : avec le mode test, ça ouvre la voie à beaucoup d'optimisations.

Routeur solaire

Côté routeur, le système est maintenant très bien optimisé.
Avec 4 panneaux (1600 Wc) en autoconsommation, je n’injecte jamais sur le réseau.
De mars à novembre, le routeur chauffe l’eau exclusivement, et la PAC ne prend le relais qu’en hiver.
Résultat :

Sondes NTC & “falsification”

Concernant la mesure et la bascule des sondes ECS (haut/bas), tout fonctionne comme prévu :

On voit que dès que les deux sondes dépassent 60 °C, la TOUG simule des résistances de 2.3 kΩ pour que le T.One “croie” qu’elles sont à 60 °C (courbe bleue Modbus).

Quand elles repassent sous 60 °C, la PAC relit les vraies valeurs, parfaitement cohérentes avec celles mesurées via l’ADC de la TOUG.

Sur ce deuxième exemple, on voit bien qu’on limite la température vue par le T.One à 60 °C (en bleu). En dessous, il voit les températures réelles (rouge et jaune).

Piste d’amélioration

Il reste à finir de décortiquer le protocole série USB afin d’émuler totalement la passerelle officielle — même si, en pratique, tout est déjà possible via les deux Modbus. Une fois le protocole USB implémenté, ça simplifiera grandement le câblage. 

Conclusion

Ce projet permet une maîtrise complète de la PAC Aldes T.One en local, sans dépendance au cloud, tout en améliorant la fiabilité (Ethernet) et la flexibilité (automatisations Home Assistant).
Il couvre des besoins avancés (tests, alertes, diagnostic, régulation fine) ainsi qu’un branchement à un routeur solaire, que la passerelle officielle ne permet pas.

La TOUG, c’est la preuve qu’avec un peu de persévérance, d’entraide et de YAML, on peut transformer une passerelle fermée en un projet open-source qui rend service à toute une communauté.

🔜 Bientôt : fabriquez votre TOUG vous-même de A à Z

Un tutoriel complet arrive pour reproduire intégralement la passerelle, étape par étape.

Restez dans le coin 😉

Ressources

• Explications, code, schémas, YAML, BOM : Github
• Sujet dédié au Aldes T.One
• Sujet dédié à la TOUG
• Page constructeur T.One

Remerciements

Merci à tous les membres du forum pour leurs partages, leurs idées et leur bienveillance.