Le local tuya attire surtout ceux qui veulent garder leurs prises, lampes ou volets réactifs sans dépendre en permanence du cloud. Dans un projet domotique, la vraie question n’est pas seulement “est-ce que ça marche ?”, mais “est-ce que ça répond vite, de façon fiable, et sans créer un système fragile à maintenir ?”. Ici, je fais le tri entre les approches qui fonctionnent vraiment dans Home Assistant, les appareils qui s’y prêtent, et les pièges qui font perdre du temps.
Ce qu’il faut retenir avant de passer Tuya en local
- Le contrôle local améliore surtout la réactivité et la dépendance au cloud, mais ne coupe pas automatiquement l’appareil de l’Internet.
- Dans Home Assistant, les deux pistes les plus utiles sont LocalTuya et tuya-local; l’intégration officielle Tuya reste cloud-based.
- Pour faire fonctionner un appareil, il faut généralement son IP locale, son identifiant et sa local key.
- Les prises, interrupteurs, lampes, volets et certains climatiseurs sont de bons candidats; les capteurs sur pile sont souvent de mauvais candidats.
- Si vous bloquez l’accès Internet, il faut aussi traiter le DNS, sinon certains appareils deviennent injoignables en local.
Ce que recouvre vraiment l’intégration locale de Tuya
Quand on parle d’intégration locale, on parle d’un appareil Tuya piloté sur le réseau domestique, sans passer à chaque commande par les serveurs du fabricant. Le principe est simple sur le papier: Home Assistant parle directement à l’appareil, souvent via une local key, c’est-à-dire la clé locale qui permet d’authentifier et de chiffrer l’échange. En pratique, on gagne surtout en latence et en fiabilité perçue, parce que l’action ne dépend plus de l’état du cloud.
Je nuance tout de suite un point important: local ne veut pas dire “magiquement privé”. Beaucoup d’appareils Tuya continuent à communiquer avec le cloud si on ne les isole pas explicitement. Le contrôle local est donc une amélioration fonctionnelle, pas un blindage de sécurité par défaut. C’est précisément pour cela que le sujet mérite d’être traité proprement, et pas juste comme un bricolage de plus.
Dans l’écosystème Tuya, il faut aussi distinguer la voie officielle de la voie locale. L’intégration officielle de Home Assistant s’appuie sur le compte Tuya/Smart Life et passe par le cloud. Elle est pratique, mais elle n’a pas le même objectif qu’une intégration locale. Si votre besoin prioritaire est de garder la main sur des appareils bien précis, en réduisant les dépendances externes, il faut regarder du côté des intégrations locales. La suite dépend alors du niveau de confort que vous acceptez dans la configuration.
Je passe donc à la vraie décision: quelle approche choisir selon votre matériel, votre réseau et votre tolérance à la mise au point. C’est là que les différences comptent vraiment.
LocalTuya, tuya-local et l’intégration officielle ne répondent pas au même besoin
Il y a souvent confusion entre les noms, alors que les usages ne sont pas identiques. LocalTuya et tuya-local sont des intégrations personnalisées pour Home Assistant, pensées pour piloter des appareils Tuya en local. L’intégration officielle Tuya, elle, reste orientée cloud. Si on mélange tout, on finit avec de fausses attentes sur la compatibilité, la latence ou les limites.
| Solution | Dépendance au cloud | Forces | Limites | Je la choisis quand |
|---|---|---|---|---|
| Intégration officielle Tuya | Oui | Installation simple, configuration guidée, bonne pour démarrer vite | Support partiel selon les catégories d’appareils, dépendance Internet | Je veux une mise en route rapide et peu d’entretien |
| LocalTuya | Non au runtime, cloud optionnel pour récupérer des clés | Réponse rapide, push des états, prise en charge de nombreux profils, suivi énergie sur appareils compatibles | Mapping des DPS plus technique, configuration plus manuelle, pas une solution officielle | Je veux un contrôle local précis sur des appareils filaires ou sur secteur |
| tuya-local | Non au runtime, cloud optionnel pour simplifier la configuration | Installation via HACS, profils d’appareils nombreux, configuration assistée, bonne base communautaire | Certains appareils restent incompatibles, les capteurs sur pile sont souvent hors jeu, les hubs ont des limites | Je veux une voie locale structurée avec une large base de compatibilité |
Dans la pratique, je conseille de penser en trois couches. Pour les appareils Wi-Fi Tuya simples, une intégration locale est pertinente. Pour les appareils Zigbee Tuya, je préfère souvent sortir du monde Tuya et passer par ZHA ou Zigbee2MQTT. Pour les objets Bluetooth, un pont dédié comme `tuya_ble` peut être plus logique qu’un contournement en force. Ce tri évite d’installer la mauvaise brique sur le mauvais matériel.
Cette comparaison étant posée, il faut maintenant préparer le terrain. Sans cela, même une bonne intégration finit par sembler capricieuse.
Ce qu’il faut préparer avant l’installation
Je commence toujours par vérifier quatre choses: la présence de l’appareil dans l’application Tuya ou Smart Life, une adresse IP stable, l’accès au même réseau local que Home Assistant, et la possibilité de récupérer la local key. Sans cette base, l’installation peut réussir à moitié puis casser au moindre redémarrage ou au moindre changement d’adresse IP.
- Réserver l’adresse IP dans la box ou le routeur. C’est bête, mais c’est souvent ce qui fait gagner le plus de temps.
- Ajouter l’appareil dans Smart Life ou Tuya Smart avant de le faire passer en local, surtout si vous comptez utiliser la récupération assistée des clés.
- Vérifier l’accès LAN entre Home Assistant et l’appareil. Un VLAN mal pensé ou un Wi-Fi invité suffit à bloquer tout le flux.
- Prévoir HACS si vous partez sur une intégration communautaire. C’est la voie la plus simple pour installer et mettre à jour LocalTuya ou tuya-local.
Il faut aussi accepter une réalité parfois négligée: sur certains appareils, le cloud sert à récupérer des informations de départ, puis on s’en passe ensuite. Cette configuration assistée est pratique, mais elle ne remplace pas une vraie compréhension de l’appareil. Si vous ne savez pas ce qu’est un point de données, vous devrez l’apprendre rapidement.
Le terme technique à connaître ici est le DPS pour “data point”. C’est l’unité fonctionnelle que l’appareil expose: un interrupteur, une valeur de température, un mode, une vitesse de ventilation, etc. Tant qu’on n’a pas identifié les bons DPS, un appareil peut apparaître “connecté” tout en restant incomplet dans Home Assistant. C’est pour cela que la phase de configuration compte autant que l’installation elle-même.
Une fois ce socle posé, on peut passer au concret et ajouter le premier appareil sans s’enfermer dans des réglages inutiles.
Installer et configurer une première prise ou une lampe
Sur un premier appareil, je recommande de rester simple. Une prise ou une lampe sont les meilleurs bancs d’essai, parce qu’ils révèlent rapidement si l’intégration locale fonctionne sans multiplier les variables. Si ça ne marche pas sur ce type d’objet, inutile de commencer par un thermostat ou un volet motorisé.
Avec tuya-local
La logique la plus confortable consiste à passer par HACS, installer l’intégration, puis utiliser la configuration assistée. Selon les cas, l’outil peut utiliser votre compte Tuya/Smart Life pour retrouver les informations de connexion locale, puis vous guider dans le choix du modèle d’appareil. C’est souvent le chemin le plus rapide quand on ne veut pas tout saisir à la main.
Ensuite, je choisis le type d’appareil, je vérifie l’adresse IP détectée et je donne un nom clair à l’entité dans Home Assistant. Si le mauvais type est sélectionné, il faut parfois supprimer et recréer l’appareil, parce que la structure des entités n’est pas la même. C’est un point banal en apparence, mais il évite beaucoup de confusion plus tard.
Lire aussi : Installer Domoticz - Le guide complet pour une domotique stable
Avec LocalTuya
LocalTuya suit une logique plus manuelle, mais reste très efficace quand on sait ce qu’on fait. J’ajoute l’intégration, je fournis l’ID, la clé locale et l’hôte, puis je mappe les fonctions de l’appareil sur les bons DPS. Si l’accès au cloud est configuré, il peut aider à récupérer les clés plus facilement, mais il n’est pas obligatoire pour l’exécution locale.
Je fais attention à deux réglages. D’abord, le scan interval ne doit pas être agressif: en dessous de 10 secondes, la stabilité peut se dégrader sur certains appareils. Ensuite, le réglage manuel des DPS ne sert qu’en dernier recours, quand l’appareil n’annonce pas correctement ses points. Dans la vraie vie, je préfère d’abord tester l’appareil avec l’application officielle fermée, puis revenir à Home Assistant. C’est souvent ce détail qui débloque l’ajout.
Une fois la première prise ou la première lampe stable, le vrai sujet devient moins “comment l’ajouter” que “comment éviter les faux problèmes”. C’est ce que je traite maintenant.
Les pièges réseau qui font échouer les tests
Le piège le plus courant, c’est de croire qu’un simple blocage Internet suffit. En réalité, si vous coupez uniquement les sorties vers le web mais laissez le DNS intact, certains appareils continuent à chercher leur environnement cloud et finissent dans un état inutilisable en local. Je le vois régulièrement: l’objet semble vivant, mais il ne répond plus correctement au moment où on en a besoin.
- Bloquez aussi le DNS si vous décidez d’isoler l’appareil. Sans cela, la coupure est souvent incomplète.
- Ne laissez pas l’application mobile ouverte sur le même Wi-Fi pendant les tests. Beaucoup d’appareils n’aiment pas les connexions locales concurrentes.
- Évitez d’utiliser deux intégrations locales sur le même appareil. Les conflits de découverte et de connexion sont très fréquents.
- Ne vous battez pas avec des capteurs sur pile. Leur logique d’économie d’énergie les rend souvent incompatibles avec un contrôle local classique.
Un autre point de friction concerne les hubs. Certains hubs Tuya n’acceptent qu’un petit nombre de connexions locales vers les sous-appareils, souvent 1 ou 3 connexions selon le module embarqué. Cela change complètement l’équation dès qu’on a plusieurs objets derrière le même pont. À ce stade, je regarde sérieusement si le hub Tuya a encore du sens ou si je dois basculer vers une alternative Zigbee plus ouverte.
Enfin, il faut accepter que le nom commercial d’un produit ne garantit rien. Deux appareils vendus sous la même référence peuvent embarquer des firmwares différents, et une mise à jour peut casser une compatibilité qui fonctionnait la semaine précédente. C’est frustrant, mais c’est la réalité de cet écosystème. Mieux vaut le savoir avant de chercher un bug qui n’existe pas chez vous mais dans le matériel lui-même.
Une fois ces pièges identifiés, on peut regarder froidement ce que le contrôle local améliore vraiment, et ce qu’il ne résout pas.
Ce que le local améliore vraiment, et ce qu’il ne change pas
Le gain principal, c’est la sensation de pilotage immédiat. Sur une prise, un éclairage ou un volet, la commande locale est souvent plus rapide et plus régulière que le passage par le cloud. Dans une maison occupée tous les jours, cette différence se sent. Les scènes sont plus fluides, les retours d’état plus réactifs, et Home Assistant dépend moins d’un service externe pour faire ce qu’on lui demande.
En revanche, je ne vendrais jamais cette approche comme une mesure de sécurité en elle-même. Le local améliore la réactivité, pas l’isolement. Si l’objectif est la confidentialité ou la réduction des échanges externes, il faut aller plus loin: segmentation réseau, filtrage DNS, règles de pare-feu, voire choix d’un matériel nativement plus ouvert.
La compatibilité, elle aussi, mérite une lecture prudente. Certaines intégrations locales prennent en charge des appareils sur protocoles Tuya 3.1 à 3.4, avec de bons résultats sur les équipements filaires les plus courants. Mais les capteurs sur batterie restent souvent hors cadre, et les hubs doivent composer avec leurs limites propres. C’est pour cette raison que je distingue toujours trois cas: l’appareil simple qui mérite une intégration locale, le matériel Zigbee qui gagne à sortir de l’écosystème Tuya, et le produit exotique que je ne vais pas forcer à rentrer dans un moule.
Si vous cherchez une boussole rapide, voici celle que j’utilise: pour les prises, lampes, variateurs, volets et certains climatiseurs, l’approche locale est souvent pertinente; pour les capteurs sur pile, je regarde d’abord ZHA ou Zigbee2MQTT; pour les hubs récents qui supportent Matter over Wi-Fi, je teste aussi cette voie avant de complexifier davantage le réseau. Ce tri évite de surinvestir dans une solution locale quand une alternative plus standard ferait mieux.
Il reste une dernière question: comment je m’y prendrais pour construire un système durable, sans finir avec une pile de bricolages mal documentés ?
Ce que je ferais pour garder un réseau Tuya lisible dans le temps
Si je partais de zéro, je commencerais petit: une prise ou une lampe bien supportée, une IP réservée, un nom d’entité propre, puis seulement ensuite un blocage réseau partiel pour valider le contrôle local. Cette progression a l’air lente, mais elle évite les installations qui fonctionnent “presque” et qu’on ne parvient plus à dépanner un mois plus tard.
Je documenterais aussi systématiquement trois choses: l’adresse IP, l’ID de l’appareil et la méthode utilisée pour récupérer la clé locale. Dans un environnement domotique, ce n’est pas du luxe administratif, c’est de l’assurance anti-perte de temps. Le jour où un appareil change de comportement après une mise à jour, ces informations deviennent utiles immédiatement.
Enfin, je garderais une règle simple: si un appareil Tuya peut être remplacé par une solution plus native et plus ouverte sans perdre en confort, je n’hésite pas à le faire. Le contrôle local est un excellent outil, pas une religion. Il vaut surtout pour les équipements où il apporte un vrai gain de vitesse, de stabilité ou d’indépendance. C’est là qu’il tient ses promesses, et c’est là qu’il mérite sa place dans une installation domotique sérieuse.
