Pas de capteur « fin de cycle » vendu avec ton électroménager ? Home Assistant peut déduire le début et la fin d’un lavage rien qu’en observant la consommation électrique de l’appareil.
L’accroche
Rien de plus frustrant que d’oublier une machine terminée depuis une heure, ou de découvrir que le lave-vaisselle tourne encore alors qu’on pensait la cuisine tranquille pour la soirée. Sans capteur dédié ni appareil « connecté » nativement, la seule donnée fiable et disponible à moindre coût reste la consommation électrique instantanée. Le reste n’est qu’une question de logique de seuils et de patience dans les automations.
Le contexte
Ni le lave-linge ni le lave-vaisselle de la maison ne sont des appareils connectés. Pas de Wi-Fi, pas d’API constructeur, pas d’appli mobile propriétaire à intégrer de force dans Home Assistant. Investir dans un modèle « smart » uniquement pour avoir une notification de fin de cycle n’a pas beaucoup de sens quand l’appareil existant fonctionne très bien mécaniquement.
La solution la plus simple et la moins chère reste donc de brancher l’appareil sur une prise connectée avec mesure de puissance. Ce type de prise remonte en continu la consommation en watts dans Home Assistant, sous forme d’un capteur numérique classique. À partir de là, tout le travail se fait côté logiciel : plus de puissance consommée qu’un seuil donné, cela veut dire que le moteur, la résistance de chauffe ou la pompe de vidange sont actifs, donc que la machine tourne. En dessous de ce seuil pendant un certain temps, le cycle est terminé.
L’avantage de cette approche, c’est qu’elle est totalement indépendante de la marque ou du modèle d’appareil. Elle fonctionne aussi bien sur un vieux lave-linge que sur un lave-vaisselle récent, tant que la prise connectée supporte la puissance de l’appareil. L’inconvénient, c’est qu’il faut construire soi-même toute la logique de détection : rien n’est fourni « out of the box », contrairement à un capteur de porte ou de mouvement, même si une partie de cette logique se construit désormais sans écrire de YAML, comme expliqué plus loin dans cet article.
L’implémentation
Détecter le démarrage du cycle
La première brique est un binary_sensor basé sur un template, qui compare la puissance mesurée à un seuil. Pour le lave-linge, ce seuil se situe autour de 50W : en dessous, l’appareil est considéré comme éteint ou en veille, au-dessus, un cycle est en cours.
template:
- binary_sensor:
- name: "Machine à laver en cours"
unique_id: machine_a_laver_en_cours
default_entity_id: binary_sensor.machine_a_laver_en_cours
device_class: running
state: >
{{ states('sensor.machine_a_laver_puissance') | float(0) > 50 }}
delay_off:
minutes: 3
Le delay_off est la partie la plus importante de ce bloc : sans lui, la moindre micro-coupure de puissance (essorage qui ralentit, pause entre deux phases) ferait basculer le binary_sensor sur « off » puis à nouveau sur « on » quelques secondes plus tard, ce qui génère de fausses fins de cycle.
Mesurer la durée et classifier le programme
Une fois le début et la fin du cycle capturés, une automation mémorise l’horodatage de départ dans un input_datetime, et calcule la durée totale à la fin. Cette durée sert ensuite à deviner quel programme a été lancé, en comparant à des plages de durée connues pour chaque appareil.
automation:
- alias: "ML - Fin de cycle et classification"
trigger:
- platform: state
entity_id: binary_sensor.machine_a_laver_en_cours
to: "off"
action:
- variables:
duree_min: >
{{ ((now() - states.input_datetime.ml_debut_cycle.last_changed)
.total_seconds() / 60) | round(0) }}
- service: input_text.set_value
target:
entity_id: input_text.ml_dernier_programme
data:
value: >
{{ 'Long' if duree_min | int > 90 else 'Court' }}
Pour le lave-vaisselle, la même logique s’applique mais avec davantage de programmes possibles (rapide, normal, mode intelligent, intensif, éco), chacun ayant une plage de durée assez distincte pour être identifiable sans ambiguïté la plupart du temps.
Avant de fixer ton seuil de puissance, laisse tourner un cycle complet en notant juste l’évolution du capteur watts dans l’historique Home Assistant : ça t’évite de deviner un seuil à l’aveugle et de le corriger trois fois.
Gérer le redémarrage de Home Assistant en cours de cycle
Un point souvent oublié : que se passe-t-il si Home Assistant redémarre (mise à jour, coupure électrique) pendant qu’un cycle est en cours ? Les input_datetime et compteurs peuvent perdre leur contexte logique, même s’ils survivent au redémarrage. Une automation dédiée, déclenchée au démarrage de Home Assistant, revérifie l’état réel de la puissance consommée par chaque appareil et resynchronise les binary_sensors en conséquence, plutôt que de repartir sur un état potentiellement obsolète.
Les pièges rencontrés
Le premier piège, déjà évoqué, ce sont les faux positifs liés aux variations naturelles de puissance en cours de cycle. Un lave-linge ne consomme pas de façon linéaire : phase de remplissage, chauffe, brassage, essorage, chaque étape a sa propre signature électrique, avec des creux qui peuvent tomber sous le seuil de détection pendant quelques secondes. Sans temporisation (delay_off ou équivalent avec un for: dans un trigger), l’automation déclenche des notifications de fin de cycle en pleine phase de lavage.
Le deuxième piège concerne spécifiquement le lave-vaisselle : la phase de chauffage de l’eau a une signature de puissance très différente du reste du programme, avec des paliers marqués. Une détection trop simpliste basée uniquement sur « puissance > seuil » peut confondre une pause entre deux phases avec une fin de cycle réelle, d’où l’intérêt de suivre séparément le début et la fin de la phase de chauffe plutôt que de se fier à un seul binary_sensor global.
Le troisième piège, plus rare mais plus gênant : un cycle interrompu (coupure de courant, porte ouverte en cours de route, disjoncteur qui saute) laisse l’état « en cours » bloqué indéfiniment si aucune détection de crash n’est prévue. La solution consiste à ajouter un timeout : si la puissance reste anormalement basse sans repasser au-dessus du seuil pendant une durée largement supérieure au programme le plus long possible, l’automation force un reset de l’état plutôt que d’attendre une fin de cycle qui ne viendra jamais.
Depuis la 2026.7 : ce qui ne demande plus de YAML (et ce qui arrive peut-être)
La mise à jour 2026.7 de Home Assistant, sortie le 1er juillet 2026, fait passer les triggers « orientés intention » en comportement par défaut de l’éditeur d’automatisation graphique. Concrètement, l’éditeur propose désormais des déclencheurs formulés en langage courant, comme « la température franchit un seuil ». Pour la puissance d’une prise, il n’y a pas encore de déclencheur dédié : on passe par le déclencheur « valeur numérique », qui se configure aussi sans YAML. Le binary_sensor template et son delay_off restent utiles pour absorber les creux de puissance en cours de cycle.
Dans l’annonce de cette version, l’équipe Home Assistant est allée plus loin en citant un exemple pour illustrer le potentiel du nouveau moteur d’automatisation : celui d’une intégration de machine à laver qui exposerait directement un trigger « linge terminé », sans que l’utilisateur ait besoin de savoir quel état ou quel attribut technique signifie réellement la fin du cycle. C’est important à préciser : il s’agit d’un exemple donné par l’équipe elle-même pour illustrer une perspective d’avenir, pas d’une fonctionnalité confirmée disponible aujourd’hui pour un lave-linge ou un lave-vaisselle du commerce. Si une telle intégration existait un jour pour ta machine, elle rendrait inutile toute la logique de seuils et de durées décrite dans cet article.
En attendant, et en l’absence d’une intégration officielle de ce genre pour la plupart des appareils du marché, la méthode par seuil de puissance reste la solution la plus pratique, que tu la construises désormais dans l’éditeur graphique ou en YAML comme montré ci-dessus.
Bilan et pour aller plus loin
Cette approche par seuils de puissance fonctionne bien au quotidien et évite d’investir dans du matériel spécifique, mais elle reste approximative par nature : la classification du programme utilisé se base sur des plages de durée qui peuvent se chevaucher légèrement entre deux programmes proches. Le reset automatique après 30 minutes d’inactivité, bien que pratique, est aussi un peu un pansement : il gère les cas limites sans les résoudre à la racine.
Une évolution possible serait d’affiner la reconnaissance de programme en analysant la forme de la courbe de puissance dans le temps (nombre de paliers, durée de chaque phase) plutôt qu’une simple durée totale, ce qui rapprocherait la détection d’une vraie empreinte de signature électrique. Pour l’instant, la logique actuelle par seuils simples couvre l’essentiel des besoins : savoir quand une machine a fini de tourner, sans notification oubliée ni fausse alerte.
Faut-il un capteur de puissance différent pour chaque appareil ?
Oui, chaque appareil (lave-linge, lave-vaisselle) a besoin de sa propre prise ou capteur de puissance, car les seuils et durées de détection leur sont propres.
Pourquoi ne pas simplement utiliser une notification à heure fixe ?
Les cycles n’ont pas une durée constante d’un lavage à l’autre, une notification programmée serait souvent en avance ou en retard par rapport à la vraie fin du cycle.
Le seuil de 50W fonctionne-t-il pour tous les lave-linge ?
C’est un point de départ raisonnable, mais il vaut mieux le vérifier sur l’historique de consommation réel de son propre appareil avant de le figer.
Que faire si le cycle reste bloqué en « en cours » ?
Ajouter une détection de timeout qui force un reset de l’état si la durée dépasse largement le programme le plus long possible évite ce blocage.
Cette méthode consomme-t-elle plus de ressources sur Home Assistant ?
Non, un binary_sensor template et quelques automations restent très légers, sans impact notable sur les performances du serveur.
Stack utilisée
- Home Assistant (automations YAML, templates)
- Prise connectée avec mesure de puissance (par appareil)
binary_sensortemplate avecdelay_offinput_datetime,input_text/ compteurs pour la mémorisation du cycle- Automation de resynchronisation au démarrage de Home Assistant
