TL;DR
La TOUG (T.One Ultimate Gateway) est une passerelle ESPHome pour piloter entièrement la PAC Aldes T.One AIR / AquaAIR en local — sans cloud, sans passerelle propriétaire.
Ethernet, Modbus, USB, bouches motorisées, ECS solaire, sécurité et intégration Home Assistant : tout y est.
Projet 100 % open-source, conçu avec la communauté HACF.
Bonjour à tous,
Je participe au Défi DIY 2025 pour vous présenter la TOUG — T.One Ultimate Gateway, une passerelle DIY basée sur ESPHome qui permet de piloter en local une pompe à chaleur Aldes T.One® AIR ou T.One® AquaAIR, sans passerelle propriétaire ni cloud.
Elle permet également de connecter un routeur solaire pour la version AquaAIR.
Une alternative 100 % locale, stable et open-source pour redonner la main aux utilisateurs !
Contexte & objectif
La 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.
La 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.
Problème : 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” 
.
Mon objectif :
- 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 pendouille dans la chaufferie)
- 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 track : j’ai des panneaux photovoltaïques, je veux pouvoir intégrer un routeur solaire
Genèse du projet
Comme tout projet DIY, la TOUG n’est pas née d’un coup de baguette magique : elle est le fruit de nombreux tests, essais-erreurs, et de pas mal de soirées à jongler entre multimètre, datasheets et YAML 
… mais aussi d’une entraide précieuse sur le forum HACF.
Chaque problème rencontré a trouvé une solution grâce aux échanges avec d’autres passionnés : on avance plus vite (et surtout plus loin) ensemble qu’en solo 
.
Tout commence avec le sujet de @Neuvidor sur le Chauffe-Eau ALDES - B200-FAN T.Flow® Hygro+. Il partage des points communs avec la PAC T.One : même passerelle propriétaire via USB, même bus ibus propriétaire.
La T.One a en plus une interface Modbus (non documentée) et un écran de contrôle (la “télécommande” dans la doc Aldes).
S’ensuivent alors des discussions endiablées entre propriétaires de matériel Aldes pour tenter de faire du reverse engineering :
- de la passerelle AldesConnect (USB),
- du port USB,
- de l’interface ibus et de son protocole propriétaire,
- du Modbus (sur la T.One).
J’avais lu ailleurs que certains équipements Aldes étaient fournis avec une doc officielle du Modbus. J’ai donc tenté de dialoguer avec ma PAC via une clé USB/RS485 en essayant une multitude de paramètres… sans succès.
Puis un jour, un nouveau membre débarque : @visvic, qui a (je cite ) “usé de ses relations professionnelles pour obtenir des informations sur la T.One AquaAIR”. Et là, il nous fournit carrément la doc du Modbus avec la liste des registres 
! On crée un sujet dédié au T.One
Sauf qu’avec les paramètres fournis par Aldes, impossible de communiquer 
. (Aussi doués en documentation qu’en logiciel 
).
Après plusieurs mois de tentatives, j’ai finalement trouvé la bonne combinaison de paramètres : 19200 bauds, 8 bits, Pair, 1 bit de stop ! (ils s’étaient trompés sur la vitesse du bus…) Et c’est là que commence vraiment l’histoire de la TOUG.
Conception
Une fois le modbus disponible, tout devient plus simple, un esp32 et un convertisseur TTL-RS485 et le tour est joué. Quelques jours plus tard, je fournis un yaml générique qui permet d’avoir accès notamment aux:
- Thermostats de chaque pièce
- Température pièce principale
- Modes de chauffage/clim
- Modes ECS
- Température et volume ECS
- Etat du filtre
Voici ce que j’obtiens dans EspHome
J’en profite aussi pour démonter la télécommande centrale, ça avait l’air d’être du Modbus d’après les composants (LTC2862). Bingo, même paramètres modbus ! C’est pas documenté mais ça ouvre l’accès à des centaines de données constructeurs supplémentaires (notamment tous les capteurs des groupes intérieurs et extérieurs)
Côté matériel, c’est @guix77 qui dégaine le premier quelques mois après avec un premier PCB. La carte est alimentée via le 12V du connecteur modbus, converti en 3,3V pour l’esp32. Voici le résultat du premier prototype :
Il apporte ensuite une évolution : elle permet de détecter l’ouverture de 4 bouches motorisées (12V) grâce à des optocoupleurs :
Ensuite c’est au tour de @Hugz d’apporter sa pierre à l’édifice. Il ajoute :
- une deuxième carte d’optocoupleurs pour détecter jusqu’à 8 bouches motorisées
- un deuxième convertisseur TTL-RS485 pour aussi lire le modbus de la télécommande
Voici le résultat :
On commence à être vraiment pas mal mais il reste quelques améliorations à apporter par rapport aux objectifs initiaux :
- Être intégré dans un boîtier
- Communiquer via l’USB de la passerelle officielle
- Piloter un routeur solaire
- Quelques interrupteurs (ON/OFF et Flash Mode)
Je décide alors de me lancer dans une passerelle ultime, qui répond aux besoin de tout le monde.
Je veux qu’elle soit configurable via des jumpers ou interrupteurs à glissière et qu’on puisse choisir les fonctions qui nous intéressent : pas besoin de tous les composants pour que ça fonctionne.
Afin d’avoir une fiabilité maximale, j’ai choisi un ESP32 avec port ethernet (qui fait aussi wifi) : le WT32-ETH01. Afin de faciliter sa programmation, il faudra intégrer un connecteur pour brancher directement un FTDI.
Interface USB
Pour comprendre comment fonctionne l’interface USB, il faut s’aider de la passerelle officielle. On commence par la brancher sur un PC, on obtient :
[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
La passerelle implémente le composant USB CDC ACM, qui n’est rien d’autre qu’une liaison série. Ca signifie que la carte mère du T.One joue le rôle d’hote et implémente le driver USB CDC ACM.
Si on veut communiquer avec l’esp32, il faudra donc un convertisseur USB CDC ACM vers TTL.
On peut utiliser un STM32, c’est la solution choisie par @yanoooou et @Neuvidor pour le Chauffe-Eau ALDES - B200-FAN T.Flow® Hygro+ qui participe aussi au concours [DefiDIY25] - Pilotage chauffe eau thermodynamique ALDES (quel travail d’équipe, c’est beau 
)
Mais il existe aussi des puces qui font directement cette conversion :
- MCP2200
- MCP2221A (il existe une carte toute faite chez Adafruit pour le MCP2221A)
- CY7C65213/A
- STM32 Nucleo-64 development board
Je décide de partir sur une puce MCP2221A, ce n’est pas très cher et très compact (forcément en CMS). Je réalise un petit montage sur breadboard à l’aide de quelques documents trouvés sur internet, notamment celui-ci :
esp32(TxRx)—(TxRx)CDC/ACM(USB)—(USB)PC ou T.One
J’ajoute 2 condensateurs : 0.47µF sur VUSB et 4,7µF sur VDD (5V USB).
Je branche sur mon PC pour commencer… et ding ding 
! Notification USB Windows
Nouveau port COM détecté : j’arrive à faire passer les logs de débug esphome dessus 
.
Il reste plus qu’à brancher sur l’USB de la carte mère du T.One, configurer l’UART en debug dans esphome pour afficher les trames reçues :
uart:
- id: U0
tx_pin: GPIO01
rx_pin: GPIO03
baud_rate: 115200
parity: NONE
stop_bits: 1
rx_buffer_size : 512
debug:
direction: RX
dummy_receiver: true
after:
timeout: 100ms
sequence:
- logger.log: '<<< U0'
- lambda: |-
static unsigned long previousMillis = 0;
unsigned long currentMillis = millis();
unsigned long elapsedTime = currentMillis - previousMillis;
previousMillis = currentMillis;
ESP_LOGD("custom", "Temps écoulé : %lu ms", elapsedTime);
- lambda: UARTDebug::log_hex(direction, bytes, ':');
Résultat : chaque 20s, je reçois ce genre de trames via l’USB (j’ai volontairement remis à la ligne après FA:FD:AF:FF, mais en vrai c’est continu) :
FA:FD:AF:FF:25:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:09:00:00:00:00:00:00:00:20:00:00:00:C5:07:00:00:00:00:00:00:A0:1B:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:12:00:00:00:00:00:00:00:02:00:00:00:7C:0E:00:00:00:00:00:00:9C:01:00:00:17:00:00:00:00:00:00:00:00:00:00:00:82:12:00:00:00:00:00:00:00:00:00:00:FE:A2
FA:FD:AF:FF:25:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:09:00:00:00:00:00:00:00:20:00:00:00:C5:07:00:00:00:00:00:00:A0:1B:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:12:00:00:00:00:00:00:00:02:00:00:00:7C:0E:00:00:00:00:00:00:9C:01:00:00:17:00:00:00:00:00:00:00:00:00:00:00:82:12:00:00:00:00:00:00:00:00:00:00:FE:A2
FA:FD:AF:FF:25:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:12:00:00:00:00:00:00:00:02:00:00:00:7C:0E:00:00:00:00:00:00:9C:01:00:00:17:00:00:00:00:00:00:00:00:00:00:00:82:12:00:00:00:00:00:00:00:00:00:00:FE:A2:00:00:00:00:00:12:00:00:00:00:00:00:00:02:00:00:00:7C:0E:00:00:00:00:00:00:9C:01:00:00:17:00:00:00:00:00:00:00:00:00:00:00:82:12:00:00:00:00:00:00:00:00:00:00:FE:A2
FA:FD:AF:FF:25:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:0
Il reste plus qu’à comprendre ce que nous raconte la carte mère
On a aussi essayé d’analyser les trames envoyées par la passerelle Aldes en la connectant sur un PC en USB avec un logiciel d’analyse série, on obtient en boucle :
Modbus Request (COM3)
Address: 2
Function: 3 (0x03) - Read Holding Registers
Starting Address: 1056
Quantity: 1
Checksum: 0x42a2 - OK
Quand on analyse la requête envoyée par la passerelle il y a un truc qui cloche.
02 03 04 20 00 01 02 42 A2
| Slave address | Function Code | Data | CRC |
|---|---|---|---|
| 1 octet | 1 octet | 0 – 252 octets | 2 octets: 1 CRC low byte and 1 CRC high byte |
| Adresse de l’esclave | holding registers | Adresse 1er registre - Nombre de registres à lire | CRC |
| 1 octet | 03 | 2 octets-2 octets | 2 octets |
| 02 | 03 | 04 20-00 01 | 02 42 A2 |
On a 1 octet en trop…
C’est bizarre cette trame envoyée, c’est presque du Modbus mais ça correspond pas à 100%.
Il faudrait sûrement y passer plus du temps et croiser les infos avec ce qui est décrit par @Neuvidor pour le chauffe-eau.
Le principal c’est qu’on arrive à s’interfacer avec l’USB, le logiciel ça se change facilement par la suite 
Routeur solaire
Prérequis
Le routeur solaire à proprement parlé est externe. Le seul prérequis c’est qu’il soit pilotable à distance par ESPhome de la passerelle ou Home Assistant. Personnellement je suis parti du routeur f1atb et plus précisément de ce qu’il appelle UxI, c’est à dire avec la sonde de courant basique. Il a l’avantage d’être simple, pas cher et de se piloter via MQTT.
Mais encore une fois, n’importe quel routeur sera compatible du moment qu’il est pilotable à distance.
Fonctionnement
Il est possible de piloter la résistance d’appoint ECS par un routeur solaire (Aldes T.One® AquaAIR uniquement)
Dans ce cas, ce n’est plus la carte mère qui pilote directement la résistance d’appoint mais le routeur. La résistance d’appoint sert normalement à monter la température de 50° à 60° pour le cycle anti légionellose ou lorsque la PAC ne suffit pas lors de grand froid. Il est donc important de garder ce mode de fonctionnement en plus du routeur solaire.
Avec le routeur solaire, on peut autoriser le ballon à monter plus haut en température (max 80°, au-delà la sécurité thermique à réarmement manuel Kt°1 se déclenche).
Pour mesurer la température de l’eau, 2 sondes de températures NTC sont connectées à la carte mère, une placée en bas du ballon, l’autre placée en haut. Pour plus de sécurité, j’ai décidé de les connecter également à la passerelle grâce à un ADC ADS1115 afin de mesurer les températures de manière autonome, ça me permet aussi de comparer avec la température renvoyée par le modbus.
Principe général:
Le routeur chauffe l’eau en fonction du surplus non consommé par la maison. Pour cela il va piloter entre 0 et 100% la puissance de la résistance d’appoint.
Sécurité externe:
Si la température dépasse 80° (sonde haut, bas, ou température ECS du modbus),
Alors on désactive le routeur jusqu’à redescendre sous 79°.
Sécurité interne:
Quand la température ECS dépasse 60°, la PAC se met en erreur « Température ECS trop haute », ainsi il faut lui faire croire que la température est à 60¨° Pour celà on bascule la carte mère vers des « fausses » sondes NTC : des résistances de 2.3 kΩ représentant 60°.
Explication détaillée
Pour éviter que la PAC se mettre en erreur lorsque la température ECS dépasse 60°, il faut lui faire croire qu’elle ne dépasse pas 60° en simulant de fausses sondes de température NTC 10K.
Les sondes de température NTC sont des résistances variables en fonction de la température, ainsi, à chaque température correspond une résistance. Grâce à un diviseur de tension interne, la carte mère mesure la tension aux bornes des sondes, proportionnelles à la résistance et donc à la température qu’elle arrive à déduire. La résistance qui correspond à 60° est 2.3 kΩ, il faut donc déconnecter les sondes de la carte mère et lui connecter une résistance de 2.3 kΩ. Mais il faut toujours connaitre les températures Haut et Bas ECS sur notre carte pour ne pas dépasser 80°. Ainsi il nous faut connecter les sondes sur notre passerelle avec notre propre diviseur de tension. Pour résumer :
- En dessous de 60°, on peut se connecter en parallèle de la carte mère pour mesurer la tension aux bornes des sondes en partageant le diviseur de tension de la carte mère.
- Au dessus de 60°, on remplace les sondes par des résistance de 2.3 kΩ côté carte mère, et on continue à lire les sondes sur la passerelle avec un diviseur de tension propre à la passerelle.
Plusieurs solutions possibles :
- Remplacer les sondes côté carte mère par un potentiomètre numérique (par exemple un MCP4461 qui est disponible pour esphome) piloté par la passerelle qui lit en permanence les sondes avec son propre diviseur de tension.
- Utiliser un relais qui bascule les entrées de la carte mère soit vers les vraies sondes, soit vers des résistances de 2.3 kΩ en activant un diviseur de tension côté passerelle pour continuer à lire les valeurs des sondes.
Sur la V1.0 de la passerelle, cette fonctionnalité n’est pas disponible suite à une erreur de design, il faut réaliser donc une carte additionnelle en I2C (en utilisant les connecteurs MCP4728 et ADS1115).
De mon côté j’ai choisi la 2e solution pour corriger le problème.
Commande interne:
Si la carte mère demande à activer la résistance d’appoint,
Alors on force le routeur à 100%, jusqu’à que la carte mère arrête.
Pour détecter la demande, on remplace la phase de la résistance d’appoint sur le connecteur « AUX Heater » de carte mère par 3.3V (ou GND) et on lit la valeur du connecteur de la résistance d’appoint (« TANK HW ») : si le relais s’active on reçoit 3.3V (ou GND)
Ainsi, si en fin de journée la température ECS dépasse la consigne, la PAC ne se mettra pas en route pour chauffer l’eau, sinon elle complètera le routeur.
Boîtier
Dans mon cahier des charges, une exigence était 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é de d’abord choisir le boitier et de faire la carte en fonction.
Pour cela j’ai trouvé un boitier tout prêt et pas cher sur Ali :
- Boitier 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
Pour que ce soit solide et bien connecté, le mieux était de prendre les mêmes connecteurs que la carte mère, ainsi les câbles peuvent se brancher sans adaptation directement sur la passerelle.
J’ai aussi évité les simples borniers à vis, j’ai choisi des borniers à vis débrochables, 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.
- Borniers à vis débrochables 2.54mm pour les bouches de ventilation et résistance d’appoint
- Borniers à vis débrochables 5.08mm pour alimentations externes 5V et 3.3V
- Connecteur femelle JST XAP-04V pour brancher directement la télécommande
- Connecteur femelle JST XAP-06V pour brancher directement les sondes ECS haut et bas (AquaAIR seulement)
- Connecteurs femelles JST XH 2.54 pour liaisons vers carte mère (sondes et modbus) et bus I2C
- Port Ethernet RJ45
Matériel (BOM)
| Quantité | Composant | Rôle |
|---|---|---|
| 1 | WT32‑ETH01 | ESP32 + Ethernet |
| 2 | TTL to RS485 | Convertisseur RS485/TTL |
| 1 | Level shifter | Convertisseur de niveau logique bidirectionnel 5V <=> 3.3V |
| 1 | Step-Down Power Module | Convertisseur 12V => 5V (régler la sortie au multimètre sur 5V avant de le brancher au reste) |
| 2 | Logic Level Converter PNP Output | Convertisseur numérique de niveaux logiques 12V => 3.3V à 4 voies |
| 1 | ADS1115 | Convertisseur Analogique-Numérique 4 voies |
| 1 | MCP2221-I/SL | Convertisseur USB/TTL CDC |
| 1 | 4.7 µF | Condensateur VDD MCP2221 |
| 1 | 0.47 µF | Condensateur VUSB MCP2221 |
| 1 | 10 µF | Condensateur alimentation 5V |
| 1 | 100 nF | Condensateur découplage 5V |
| 3 | 4.7 kΩ | Résistances pull up |
| 2 | SK-12D02-VG7 | Interrupteurs à glissière en façade |
| 2 | KH-SS42D02-G3 | Interrupteurs à glissière 4PDT |
| 1 | SS-24H03-G070 | Interrupteurs à glissière DP4T |
| 1 | Port USB | Port USB 4 pins |
| 1 | KF2EDGR-2.54-8P | Bornier à vis débrochable 8 pins 2.54mm |
| 1 | KF2EDGR-2.54-2P | Bornier à vis débrochable 2 pins 2.54mm |
| 2 | KF2EDGR-5.08-2P | Bornier à vis débrochable 2 pins 5.08mm |
| 1 | S06B-XASK-1(LF)(SN) | Connecteur JST XASK femelle 6 pins sondes température |
| 1 | S04B-XASK-1(LF)(SN) | Connecteur JST XASK femelle 4 pins télécommande |
| 1 | KF2EDGR-2.54-8P | Bornier à vis débrochable 8 pins 2.54mm |
| 4 | JST XH2.54 4P | Connecteur JST XH 4 pins 2.54mm |
| 5 | Pin header 3P | Pin Header 3 pins 2.54mm |
| 5 | Jumper | Jumpers |
| 4 | vis M2.6X6 | Vis autotaraudeuses |
| 1 | Boitier | Boitier 9 modules DIN |
| 1 | PCB | PCB JLCPCB |
PCB
Schéma de principe
┌──────────────┐
│ WT32-ETH01 │
├──────────────┤
Modbus UART1 ─┤ RS485 ↔ PAC Modbus utilisateur
Modbus UART2 ─┤ RS485 ↔ PAC Modbus écran central
USB CDC ──┤ Vers interface passerelle Aldes
GPIO out ┤───> Simulation 60 °C ECS
GPIO in ──┤<─ Sondes températures NTC
GPIO in ─┤<─ Détection bouches
GPIO in ─┤<─ Détection résistance d`appoint
└──────────────┘
Câblage
- Modbus :Connecteur femelle « Modbus » de la carte mère
- Télécommande : Connecteur mâle de la télécommande (écran central).
- Remote : Connecteur « Remote » de la carte mère
- Entrée sondes : Connecteur mâle des sondes de température ECS
- Tank : Connecteur femelle « Tank » de la carte mère
- USB : Branchez au port USB de la passerelle Aldes
- I²C : Extension I2C (Optionnel)
- K1+/K1- à K5+/K5- : Borniers bouches
- RA/K6 : Résistance Appoint ou Bornier bouche K6 selon jumper
Sécurité : Coupez l’alimentation de la PAC avant toute intervention. Vérifiez la continuité des sondes après câblage.
Jumpers
- Sélection 12V : Sélectionne la source de l’alimentation 12V (Télécommande ou Modbus)
- VCC I2C : Sélectionne la tension à envoyer sur le connecteur I2C (5V ou 3.3V).
- Sélection PullUp/PullDown : Connecte une résistance en PullUp ou PullDown sur les entrées GPIO35, 36 et 39
- Ref Résistance d’appoint : Envoie 3.3V ou GND en tant que référence d’entrée pour la détection de la résistance d’appoint (connecteur 9)
- Sélection 5V : Sélectionne la source de l’alimentation 5V (USB ou conversion 12V)
Installation ESPhome
La procédure d’installation d’ESPhome sur la TOUG est décrite ici. Elle permet de télécharger la config ESPhome souhaitée (T.ONE AIR/AquaAIR, ethernet/wifi, avec ou sans routeur solaire) directement depuis Home Assistant
Intégration Home Assistant
Une fois l’intégration du TOUG avec ESPhome faite, installer hass-template-climate dans HACS et ajouter la configuration Yaml
Exemple:
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 :
En image
Retour d’expérience
Et parce qu’un projet DIY ne se juge pas seulement à sa conception, voici un retour après plusieurs mois d’utilisation réelle
Cela fait maintenant 6 mois que la TOUG tourne en production — et même 12 mois si on compte la version breadboard pleine de fils DuPont : ça marche du feu de Dieu
La fiabilité est au top : aucun plantage, aucune intervention, juste du 100 % uptime.
La seule modif que j’ai faite concerne l’alimentation :
au début, je l’alimentais via l’USB, mais après une coupure de courant, elle ne redémarrait pas toujours — sans doute un courant un peu limite.
Depuis que je l’alimente via le 12 V du connecteur Modbus (un simple jumper à déplacer), plus aucun souci.
Côté automatisations, j’ai ajouté :
- Alerte si température ECS ou ambiante trop basse
- Coupure automatique du chauffage si une fenêtre est ouverte
- Notification « Douchez-vous, l’eau est à température max »
- Réglage des thermostats selon les absences
- Gestion complète du routeur solaire
Et ce n’est qu’un début : je prévois d’ajouter la gestion du contrat Tempo EDF pour adapter le chauffage selon les jours rouges et bleus.
Routeur solaire
Côté routeur, le système est maintenant très bien optimisé.
Avec mes 4 panneaux (1600 Wc) en autoconsommation, je n’injecte quasiment jamais sur le réseau — seulement quelques fins d’après-midi d’été quand l’eau atteint 80 °C.
De mars à novembre, le routeur chauffe l’eau exclusivement, et la PAC ne prend le relais qu’en hiver.
Résultat :
Eau chaude : 112 kWh/an (≈ 24 €) pour une famille de 4 personnes
Sondes NTC & “falsification”
Concernant la mesure et la bascule des sondes ECS (haut/bas), tout fonctionne nickel :
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° (en bleu), en dessous il voit les température rélles (rouge et jaune).
Pistes d’amélioration
- Explorer le Modbus entre la télécommande et la carte mère pour extraire davantage de données internes.
- 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
- Corriger le PCB pour la simulation des sondes à 60°, j’avais fait une erreur de design, j’ai dû faire une adaptation
Franchement, c’est devenu un appareil qu’on oublie — et c’est sûrement le meilleur compliment qu’on puisse faire à un projet DIY
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 (chauffe-eau solaire, 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é 
.
Ressources
- Explications, Code, schémas, YAML, BOM : GitHub - djtef/toug: T.One Ultimate Gateway : Passerelle pour la pompe à chaleur Aldes T.One basée sur esphome
- Sujet dédié au Aldes T.One
- Résumé
- Page constructeur T.One
Remerciements
Merci à tous les membres de ce forum pour leurs partages, leurs idées et leur bienveillance.
Une mention spéciale à @visvic, @Hugz et @guix77 pour leurs contributions techniques, leur aide précieuse et leur implication dans les passerelles précédentes. 
Petite info pour les intéressés :
