Super nouvelle. Qu’entends tu par souflerie (un sèche serviette ? ) Je ne pense pas que le fil pilote puisse le piloter la souflerie à moins que le boitier « non » libéré le faisait fonctionner ?
Bonsoir !
Le sèche serviette a des fonctionnalités avancées du genre lancer un cycle douche qui allume le radiateur, lance la soufflerie et sèche la serviette ensuite etc. Mais c’est pilotable par la télécommande et non pas un mode confort ou autre. Il agira donc comme un radiateur simple mais connecté !
Je vais voir pour le connecteur à Vtherm maintenant. On doit obligatoirement passer un over climate ou on peut piloter directement le mode par le fil pilote ? (Si tu es familier avec Vtherm).
Encore merci pour le boulot ! C’est top 
Salut,
un grand merci chrisb06 pour la création du code et de la doc pour remplacer le firmware TIKO par le tien :
J’ai flashé 5 boitiers et 4 fonctionnent super bien.
En les démontant, j’ai remarqué 3 modèles différents : le premier est comme celui des photos, avec le connecteur J200 occupée par une antenne collée sur le couvercle du boitier, j’en 3 autres sans antenne, qui n’ont pas les circuits intégrés pres des 6 broches IO>EN. Ces 3 boitiers fonctionnent quand meme avec le code commun.
Mon souci est sur l’un des boitiers qui est très particulier, il n’a pas de fil pilote et il a un relai en plus, il est branché à un vieux convecteur. Ce boitier ne fonctionne pas avec le code fourni. La commande HEAT/OFF ne fait rien, le radiateur n’est pas piloté seulement avec les fils phase et neutre qui sortent du boitier. Sauriez vous modifier le code pour commander le relai ?
Merci
Salut,
Heureux que cela ait fonctionné sur des versions différentes de boitier !
De mon coté, j’en ai flashé 3 et cela fonctionne aussi vraiment bien, et j’adore la led qui clignote rouge quand il est en chauffe, le petit détail agréable quand on aime surveiller sa consommation ou pour s’apercevoir que l’on chauffe alors que la fenetre est ouverte 
Pour celui qui est sans fil pilote, c’est étonnant car c’est le principe même de ces boitiers. Je pense qu’il agit directement sur le radiateur en jouant sur l’alimentation, ce qui semble être la seule solution sur un convecteur ancien. Peux tu envoyer quelques photos de la carte ?
Merci
Merci,
Voici 3 photos, recto/verso de la carte et le branchement avec les 3 fils radiateurs et le 2 fils secteur. Le fil pilote du radiateur n’est pas utilisé, seulement phase et neutre.
Le comportement que j’observe : le radiateur n’est pas asservi par le boitier, il reste alimenté qqsoit la commande envoyée (pas d’effet entre OFF et HEAT dans HA).
Hello à tous!
Merci beaucoup Chris pour cette investigation et reverse de qualité!
Je me lance enfin dans le flash de mes 8 boitiers, première obstacle je n'ai aucun retour sur le Rx de l'UART.
J'ai une led Rx sur l'adaptateur UART->USB. Elle clignote quand je branche ou quand je fais un short bref EN-GND pour le reset. Si j'inverse Rx-Tx elle ne clignote pas donc le branchement est ok. De plus, le chip est fonctionnel et alimenté car les info de temp/hum sont bien poussées (D'ailleurs ça m'étonne car j'avais crus comprendre qu'il avait besoin du 220v pour le wifi 
).
J'ai essayé différent tools pour lire le port serie (screen, minicom, stty) en changeant un peu les baudrate mais rien à faire. Esptool direct n'arrive pas non plus à communiquer.
J'en conclus qu'il y a un verrouillage de l'ESP (Version plus récente de matériel Tiko ?), je vais essayé de passer en direct prochainement.
Si vous avez d'autre idée je suis preneur.
Bonne journée!
Joris
Hello à tous,
Update suite à mon dernier message — résolu via le JTAG natif de l'ESP32-S3. Je documente ici au cas où d'autres tomberaient sur la même révision.
Diagnostic : UART verrouillée par eFuse
Après plusieurs tentatives infructueuses sur l'UART (y compris en testant d'autres pads à l'opposé de ceux mentionnés dans le guide), j'ai exploré la rangée de pads et identifié leurs fonctions par continuité :
GND, Rx, Tx, EN, VCC, IO0, N/A, IO20, IO19
IO19 et IO20 correspondent à USB_D- et USB_D+ sur le datasheet de l'ESP32-S3 — autrement dit, le port USB-Serial-JTAG natif de la puce, qui est un contrôleur matériel indépendant de l'UART0.
Solution : flash via USB-JTAG
J'ai sacrifié un vieux câble USB-A :
- Fil blanc (D−) → pad IO19
- Fil vert (D+) → pad IO20
- Fil noir (GND) → pad GND
- Fil rouge (5 V) → non connecté (boîtier alimenté séparément via l'adaptateur UART sur le pad VCC habituel)
Attention : sur ma révision, le pad VCC de cette rangée est en 3,3 V régulé, pas 5 V. À vérifier au multimètre avant câblage, sous peine de griller la puce.
Au branchement, dmesg affiche immédiatement :
usb 1-1: Product: USB JTAG/serial debug unit
usb 1-1: Manufacturer: Espressif
Et /dev/ttyACM0 apparaît. esptool se connecte sans aucune manip EN/IO0 — le contrôleur JTAG entre en download mode tout seul.
Confirmation du verrouillage
J'en ai profité pour lire les eFuses (espefuse --port /dev/ttyACM0 summary) et l'impossibilité d'utiliser l'UART est confirmée :
UART_PRINT_CONTROL = Disable (0b11)
Tiko a brûlé cet eFuse sur cette révision.
Suite
Le reste s'est passé parfaitement : backup du firmware d'origine, flash ESPHome avec le YAML de Chris tel quel, intégration HA OK, fil pilote validé sur les 4 presets avec un Delonghi Trao Rialto 1000W.
Merci encore @chris pour cette doc et le temps passé. 
Joris
Bonjour à tous,
Un grand merci pour tout ce travail et ce tuto.
J'aimerais aller plus loin dans cette aventure et je cherche la meilleure solution pour piloter mes radiateurs indépendamment avec les jours de la semaines et pouvoir mettre n'importe quelle température avec pourquoi pas plusieurs programmes pour gérer aussi la maison en cas de vacances ou de présence dans la maison.
Merci de votre aide
Bonjour,
J'ai utilisé Versatile thermostat et Scheduler, je dois donc mettre le versatile en thermostat sur thermostat. Pour plus d'efficacité j'aimerais que la programmation de mon boitier Tiko soit en switch et pas en thermostat tout en gardant le boost, hors gel, éco et confort. Mais je ne absolument pas le programmer, pouvez-vous m'aider?
Bonjour, à ma connaissance, les boîtiers Tiko ne fonctionnent qu’en mode thermostat. Même après un flashage, c’est forcément thermostat over thermostat.
Bonne journée
Bonjour Chris,
Tout d'abord, un grand merci pour ton travail et pour la procédure publiée ici. Grâce à tes explications, j'ai réussi à flasher 5 boîtiers et à mettre en place chez moi le framework ESPHome/Home Assistant. C'est vraiment une très bonne base et ça fonctionne déjà très bien.
Je cherche maintenant à traiter un point de sécurité qui me semble important.
Mon problème
Le pilotage du radiateur est réalisé par l'ESP32 via ESPHome, avec Home Assistant comme interface de commande.
Je voudrais éviter le cas suivant :
Home Assistant tombe ou devient indisponible alors qu'un radiateur est en train de chauffer → l'ESP32 ne reçoit plus de contre-ordre et le radiateur pourrait rester en chauffe indéfiniment.
Mon objectif serait donc d'avoir une sécurité locale dans l'ESP32, indépendante de Home Assistant :
-
tant que Home Assistant est disponible : fonctionnement normal ;
-
si Home Assistant est indisponible pendant une durée prolongée (par exemple 1 heure) : forcer le radiateur en Arrêt ;
-
éventuellement, à terme, remplacer Arrêt par le mode Hors-Gel si celui-ci peut être piloté directement par le boitier.
Ce que j'ai testé
J'ai essayé de détecter la présence de Home Assistant avec :
api:
encryption:
key: "..."
et notamment :
interval:
-
interval: 10s
then:
-
if:
condition:
api.connected: state_subscription_only: truethen:
- logger.log: "WATCHDOG TEST : Home Assistant CONNECTÉ"else:
- logger.log: "WATCHDOG TEST : Home Assistant ABSENT"
-
Lorsque Home Assistant fonctionne, le boîtier indique bien :
WATCHDOG TEST : Home Assistant CONNECTÉ
J'ai ensuite arrêté Home Assistant pour tester la détection de perte de connexion.
Le problème est que la connexion au dashboard ESPHome disparaît également, et je n'ai donc pas pu observer si l'ESP32 finit effectivement par détecter l'absence de Home Assistant.
Ma question
Est-ce que ce problème de sécurité vous paraît pertinent / important à traiter dans le framework ?
Et surtout, as-tu déjà rencontré ou résolu ce problème ?
Si oui, je serais très intéressé par la solution retenue, notamment pour savoir :
-
quelle méthode tu utilises pour détecter une perte prolongée de Home Assistant ;
-
comment tu mémorises le dernier état de connexion ;
-
comment tu déclenches localement l'arrêt du radiateur après un délai ;
-
et éventuellement comment tu gères le retour de Home Assistant.
L'objectif est vraiment d'avoir une sécurité embarquée dans l'ESP32, et non une automatisation Home Assistant, afin que le dispositif reste sûr même si le serveur Home Assistant est complètement indisponible.
Merci encore pour le travail réalisé sur cette solution !
Si tu veux voir ce que fais ton ESP sans avoir le dashboard connecté, tu as le composant web server
web_server:
Et attention, par défaut quand un ESPHome est prévu pour être connecté à l'API HA, il reboot toutes es 15mn en cas de perte de connexion
merci pour ta réponse. Donc si je comprends bien, le reboot de l'ESPHome au bout de 15 minutes après perte de connexion le met déjà à l'arrêt ?
la perte de connexion le fait rebooter, et s'il retrouve pas la connexion avec HA il reboot 15 minutes plus tard... en boucle jusqu’à ce qu'il retrouve la connexion. ça ne l'arrête pas.
Ce comportement peut être annulé, ou le temps changé.
