Faire dialoguer une voiture avec sa maison, ça sonne gadget. Sur le terrain, c’est surtout deux automations qui évitent de faire sauter le disjoncteur et qui rendent l’habitacle vivable en été sans y penser.
Le problème du quotidien
Une voiture électrique, c’est une charge électrique de plusieurs kilowatts qui démarre sans prévenir, parfois pile au moment où le four, le lave-linge et la clim tournent déjà. Sans garde-fou, le risque de disjonction n’est pas théorique. À l’inverse, arriver dans un habitacle à 40°C en plein été alors que la maison sait très bien que je suis à moins d’une heure de route, c’est juste absurde une fois qu’on a goûté à la domotique.
Ces deux frustrations ont un point commun : la voiture expose déjà les données nécessaires (état de charge, position, distance estimée) via son API constructeur. Le travail de l’intégration Home Assistant, c’est de transformer ces données brutes en décisions automatiques, sans que je doive sortir une app à chaque fois.
Le contexte : une API cloud, pas un bus local
Contrairement à une prise Shelly ou une lampe Hue qui répondent en local en quelques millisecondes, une Tesla ne parle pas directement à Home Assistant. Tout transite par l’API cloud du constructeur : HA interroge ce cloud, qui interroge à son tour la voiture (souvent en la réveillant si elle dort). Ça change trois choses par rapport à un device domotique classique.
D’abord la latence : compter plusieurs secondes, parfois davantage si le véhicule est en veille profonde, entre l’envoi d’une commande et son exécution réelle. Ensuite le rate limit : le constructeur borde le nombre d’appels autorisés par période, donc hors de question de faire du polling agressif toutes les 10 secondes comme sur un capteur ZigBee. Enfin la dépendance réseau double : il faut que la voiture ait du réseau mobile ET que le cloud du constructeur soit disponible, ce qui ajoute un point de défaillance que je ne maîtrise pas.
Cette réalité a orienté tous mes choix d’implémentation : peu d’automations, mais robustes, avec des callbacks manuels en filet de sécurité plutôt qu’une confiance aveugle dans l’automatisation.
L’implémentation
Protéger le disjoncteur pendant la charge
Le principe est simple : dès que la charge démarre, l’automation vérifie la consommation globale de la maison et ajuste l’ampérage demandé au véhicule pour ne jamais dépasser le seuil du disjoncteur (22A chez moi). Le trigger se déclenche sur le changement d’état du chargeur, l’action appelle le service de réglage de courant exposé par l’intégration.
automation:
- alias: "Tesla - Limite charge 22A maison"
trigger:
- platform: state
entity_id: binary_sensor.tesla_charger
to: "on"
- platform: numeric_state
entity_id: sensor.puissance_maison_totale
above: 5000
condition:
- condition: state
entity_id: binary_sensor.tesla_charger
state: "on"
action:
- service: number.set_value
target:
entity_id: number.tesla_charge_current
data:
value: 22
Un point important : cette automation n’est pas un simple « set and forget ». Elle se redéclenche à chaque variation significative de la consommation globale, ce qui permet de remonter l’ampérage si un gros consommateur s’éteint (four, sèche-linge) et de le redescendre sinon.
Un bouton pour ignorer la limite temporairement
Il arrive que j’aie besoin d’une charge rapide malgré tout (départ imminent, faible autonomie). Plutôt que de désactiver l’automation à la main dans l’interface, un callback Telegram déclenche une fenêtre de tolérance limitée dans le temps.
automation:
- alias: "Tesla - Ignorer limite 22A pendant 5h"
trigger:
- platform: event
event_type: telegram_callback
event_data:
data: "tesla_ignore_limit"
action:
- service: input_boolean.turn_on
target:
entity_id: input_boolean.tesla_ignore_limit
- delay: "05:00:00"
- service: input_boolean.turn_off
target:
entity_id: input_boolean.tesla_ignore_limit
La condition de limitation ci-dessus intègre ensuite un simple not sur cet input_boolean. C’est volontairement grossier : pas de logique complexe, juste une fenêtre temporelle qui se referme toute seule pour éviter d’oublier un bypass actif pendant des jours.
Mets toujours une extinction automatique sur tes bypass manuels (via un delay ou un timer). Un garde-fou qu’on peut désactiver sans limite dans le temps finit toujours désactivé pour de bon.
Pré-conditionner la clim à l’approche
La seconde automation surveille la distance estimée entre le véhicule et le domicile. Sous un seuil correspondant à environ une heure de trajet, elle déclenche le pré-conditionnement de l’habitacle, en s’appuyant sur le capteur de distance exposé par l’intégration plutôt que sur des coordonnées GPS brutes gérées manuellement.
automation:
- alias: "Tesla - Clim confort si arrivée < 1h"
trigger:
- platform: numeric_state
entity_id: sensor.tesla_temps_estime_arrivee
below: 60
condition:
- condition: state
entity_id: climate.tesla
state: "off"
action:
- service: climate.turn_on
target:
entity_id: climate.tesla
Rien de spectaculaire, mais la vraie valeur est dans la condition qui vérifie que la clim n’est pas déjà active : sans elle, l’automation se redéclenche à chaque petite fluctuation du temps estimé et spamme l’API cloud pour rien.
Les pièges rencontrés
Le piège principal n’a rien à voir avec le YAML : c’est la fiabilité de l’API cloud elle-même. Un véhicule en veille profonde met parfois plusieurs dizaines de secondes à se réveiller avant qu’une commande n’aboutisse, et il arrive que l’intégration remonte un état « indisponible » pendant une fenêtre de rate limit. Résultat concret chez moi au début : des automations qui se déclenchaient en double parce que le premier essai semblait avoir échoué (timeout côté HA) alors qu’il avait en réalité fini par passer côté véhicule avec du retard.
La solution a été d’ajouter des conditions strictes sur l’état courant avant chaque action (comme le climate.turn_on conditionné à state: "off" plus haut), plutôt que de me fier uniquement au trigger. Ça évite les doubles commandes et ça encaisse mieux la latence variable du cloud. J’ai aussi renoncé à tout polling serré : les capteurs Tesla se rafraîchissent par nature moins vite qu’un capteur local, autant composer avec plutôt que lutter contre.
Depuis la 2026.7 : ce qui ne demande plus de YAML (et ce qui arrive peut-être)
La mise à jour Home Assistant 2026.7, sortie début juillet 2026, change la donne pour ce genre d’automation simple. Les triggers « orientés intention », jusque-là réservés au Labs, sont devenus le comportement par défaut de l’éditeur graphique. Concrètement, un déclencheur du type « quand le temps d’arrivée estimé passe sous un seuil » se construit maintenant en quelques clics, en langage naturel, sans ouvrir l’éditeur YAML. Pour le pré-conditionnement de la clim décrit plus haut, c’est exactement le genre de logique que l’éditeur graphique gère désormais nativement.
Home Assistant est allé plus loin dans son annonce, en donnant un exemple pour illustrer le potentiel du nouveau moteur d’automatisation : plutôt que chacun ne reconstruise le même template pour connaître le prix de l’électricité le plus bas du moment, une intégration de borne de recharge pourrait un jour exposer directement ce trigger métier, prêt à l’emploi. Attention, c’est un exemple donné par l’équipe HA pour illustrer une direction possible, pas une fonctionnalité confirmée disponible aujourd’hui pour une intégration Tesla précise. Rien à brancher chez soi sur ce point précis pour l’instant.
En revanche, la protection du disjoncteur détaillée plus haut, avec son ajustement dynamique de l’ampérage selon la consommation globale de la maison, reste une logique propre à mon installation (seuil de 22A, capteur de puissance globale spécifique). Aucune intégration générique ne peut deviner ça : le YAML et l’automation classique restent ici la solution la plus fiable.
Bilan et pour aller plus loin
Ces deux automations tournent depuis des mois sans intervention, ce qui est plutôt le signe qu’elles sont bien calibrées : peu de logique, des conditions défensives, un filet de sécurité manuel via Telegram. Ce que je changerais si c’était à refaire : ajouter un historique des ajustements d’ampérage pour visualiser dans un dashboard les moments où la maison a réellement bridé la charge, histoire de savoir si le seuil de 22A est encore pertinent ou s’il mérite d’être révisé après un changement d’abonnement électrique.
La prochaine étape naturelle serait de croiser la charge Tesla avec la production solaire pour ne charger qu’avec le surplus photovoltaïque, mais ça demande une automation dédiée et une fiabilité de mesure que je n’ai pas encore validée en conditions réelles.
Si ce qui t’intéresse c’est plutôt l’historique détaillé des trajets, de la charge et de l’état de la batterie sur le long terme, j’avais couvert ça dans un article dédié à TeslaMate : ces deux automations et TeslaMate sont complémentaires, pas redondants, l’un pilote la maison, l’autre journalise le véhicule.
FAQ
Faut-il un abonnement payant au constructeur pour intégrer sa Tesla à Home Assistant ?
Cela dépend de l’intégration choisie et des évolutions de l’API constructeur, qui a changé plusieurs fois ses conditions d’accès. Vérifie l’état actuel avant de te lancer.
Pourquoi ne pas utiliser un contacteur physique pour limiter l’ampérage ?
Un contacteur limite de façon fixe, alors que l’automation ajuste dynamiquement selon la consommation réelle de la maison, ce qui permet de charger plus vite quand c’est possible.
Que se passe-t-il si le cloud Tesla est injoignable ?
Les automations ne se déclenchent simplement pas : la charge continue au dernier réglage connu et la clim reste dans son état courant, sans risque de commande erronée.
La latence de l’API rend-elle le pré-conditionnement inutile ?
Non, car le seuil déclencheur (environ une heure avant l’arrivée) absorbe largement les quelques dizaines de secondes de latence possibles côté cloud.
Peut-on appliquer ce principe à d’autres véhicules connectés ?
Oui, tant que le constructeur expose une intégration Home Assistant avec des capteurs de distance, d’état de charge et de commande climatique équivalents.
Stack utilisée
- Home Assistant (automations YAML)
- Intégration Tesla (capteurs de charge, distance, climatisation)
- Callbacks Telegram pour les bypass manuels
input_booleanpour les fenêtres de tolérance temporaires- Capteur de puissance globale maison (suivi de consommation)
