Suivre sa consommation électrique appareil par appareil, distinguer ce qu’on soutire du réseau de ce qu’on injecte grâce au solaire, et repérer une dérive avant qu’elle ne se voie sur la facture : voici comment j’ai construit ce monitoring avec du matériel grand public et quelques capteurs template.
Le problème du compteur unique
Un Linky, aussi bien intégré soit-il dans Home Assistant, ne donne qu’un chiffre global : la conso du foyer, heure par heure. C’est utile pour suivre le budget, totalement inutile pour répondre à la question qui compte vraiment : qu’est-ce qui consomme le plus chez moi ? Le lave-vaisselle qui tourne trois fois par semaine ? Le chauffage d’appoint qu’on oublie allumé ? La cave à vin qui tourne en continu depuis des années sans qu’on y pense ?
Sans sous-comptage, ces questions restent des suppositions. Avec, elles deviennent des courbes qu’on peut consulter en dix secondes.
Le contexte : pourquoi ce chantier
Le déclencheur a été très concret : une facture en hausse sans explication évidente, et l’incapacité de dire si le coupable était le chauffage, un appareil de cuisine ou une fuite de conso permanente. Ajoute à ça l’installation de deux panneaux solaires (810W crête), et la question devient double : combien je consomme, et combien de cette conso vient du réseau plutôt que du soleil.
Les contraintes du chantier étaient simples : pas de gros budget (pas question de refaire le tableau électrique avec un compteur professionnel à plusieurs centaines d’euros), pas de dépendance à un cloud propriétaire, et une intégration propre dans l’écosystème Home Assistant déjà en place pour le reste de la maison. Le compromis retenu a été un compteur multi-canaux en local, complété par des prises connectées pour les appareils isolés qui valaient le coup d’œil.
L’implémentation
Le socle : compteur Linky
La base reste le Linky, via l’intégration native ou Enedis selon la configuration. Deux capteurs principaux en sortent : la conso journalière en tarif Base et celle en tarif Tempo, avec une détection automatique du tarif actif (le contrat peut changer entre les deux selon les périodes). C’est la vérité de référence, celle qui doit correspondre à la facture, et qui sert de garde-fou pour vérifier que le reste du monitoring ne dérive pas trop.
Le sous-comptage : Refoss EM06P
Le cœur du dispositif est un compteur 6 canaux en WiFi local (pas de cloud, tout reste sur le réseau domestique), qui mesure directement au tableau électrique. Chaque canal est câblé sur un circuit précis : four, frigo cuisine, plaque de cuisson, lave-vaisselle, chauffage général, et un canal réservé à l’arrivée générale du tableau. Chaque canal expose une entité de puissance instantanée et une entité de conso journalière, ce qui suffit à construire des historiques exploitables sans calcul supplémentaire.
Réserve toujours un canal du compteur multi-voies pour l’arrivée générale du tableau plutôt que pour un appareil de plus : c’est ce canal signé qui te donne gratuitement le split injection/soutirage sans matériel supplémentaire.
Isoler chaque appareil : Zigbee et WiFi
Au-delà des 6 canaux du compteur principal, une bonne partie du reste du suivi passe par des prises connectées individuelles (Zigbee et WiFi selon les cas), avec des seuils de détection propres à chaque appareil pour distinguer un état « actif » d’un état « veille ». Au total, ce sont 26 appareils qui remontent une conso en kWh et une durée d’activité sur 24h : chauffe-eau, machine à laver, congélateur, téléviseurs, cave à vin, petit électroménager de cuisine. Chaque capteur de puissance brute est doublé de capteurs dérivés (quotidien, hebdomadaire, mensuel) via des compteurs utilitaires, pour obtenir des tendances plutôt que des instantanés.
Suivre le solaire
Côté production, l’onduleur expose sa puissance instantanée ainsi que la tension et le courant de chaque chaîne de panneaux. Deux compteurs utilitaires transforment cette puissance en production cumulée jour et mois :
utility_meter:
production_solaire_jour:
source: sensor.power_spd800
cycle: daily
production_solaire_mois:
source: sensor.power_spd800
cycle: monthly
Ces deux totaux permettent de comparer la production réelle aux prévisions météo, et surtout de détecter une panne de production (onduleur éteint, connexion coupée) avant qu’elle ne dure des jours sans que personne ne le remarque.
Les pièges rencontrés
Le vrai piège de ce chantier n’a rien eu à voir avec le réseau ou l’intégration logicielle : c’est le signe des mesures qui a posé problème.
Sur le canal de la plaque de cuisson, le transformateur de courant (CT) a été monté à l’envers lors du câblage. Résultat : toutes les valeurs de puissance remontaient en négatif. Home Assistant ne râle pas pour ça (une conso négative reste un nombre valide), mais toutes les statistiques et graphiques devenaient inexploitables. Plutôt que de recâbler physiquement le CT (accès difficile au tableau), la solution a été un capteur template qui inverse la valeur brute :
template:
- sensor:
- name: "Puissance plaque cuisson"
unique_id: puissance_plaque_cuisson
unit_of_measurement: "W"
device_class: power
state: >
{{ (states('sensor.em_channel_3_power') | float(0)) * -1 }}
Le second piège, plus subtil, concerne justement le canal branché sur l’arrivée générale du tableau. Ce canal capte à la fois ce qui est soutiré du réseau (valeur positive) et ce qui est injecté vers le réseau grâce au solaire (valeur négative). Sans traitement, impossible de savoir lequel des deux domine à un instant donné. La solution a été de scinder ce signal signé unique en deux capteurs distincts, un pour l’injection et un pour le soutirage, chacun ramené à zéro quand il n’est pas pertinent :
template:
- sensor:
- name: "Puissance injectée EDF"
unique_id: puissance_injectee_edf
unit_of_measurement: "W"
device_class: power
state: >
{% set p = states('sensor.em_channel_5_power') | float(0) %}
{{ [p * -1, 0] | max }}
- name: "Puissance soutirée EDF"
unique_id: puissance_soutiree_edf
unit_of_measurement: "W"
device_class: power
state: >
{% set p = states('sensor.em_channel_5_power') | float(0) %}
{{ [p, 0] | max }}
Ce genre de bug est difficile à repérer tant que personne ne compare les courbes obtenues à la logique physique attendue. La leçon générale : avec du matériel de mesure bon marché, vérifie toujours le signe et l’ordre de grandeur des toutes premières valeurs avant de construire quoi que ce soit par-dessus.
Depuis la 2026.7 : ce qui ne demande plus de YAML
La mise à jour Home Assistant 2026.7, sortie début juillet 2026, généralise les triggers et conditions « orientés intention » testés en Labs depuis fin 2025 : ils deviennent le comportement par défaut de l’éditeur d’automatisation graphique. Concrètement, une alerte du type « préviens-moi si la conso dépasse un seuil » ne nécessite plus de configurer un trigger numeric_state à la main : on choisit directement « quand la consommation dépasse une valeur » dans l’éditeur, et Home Assistant gère seul les états unknown ou unavailable que peuvent temporairement remonter des capteurs de mesure électrique. On peut aussi cibler une zone entière, par exemple regrouper les gros consommateurs d’une pièce, sans lister chaque entité une par une.
Pour une alerte simple sur l’arrivée générale ou sur un canal précis, cette approche graphique suffit largement et évite de toucher au YAML. En revanche, pour tout ce que décrit cet article, la correction de signe par capteur template, le split injection/soutirage, les cumuls utility_meter par appareil ou les comparaisons de coût entre tarif Base et Tempo, le YAML garde tout son intérêt : ce sont des calculs que l’éditeur graphique ne sait pas faire. Le conseil pratique : commence par les alertes de seuil sans YAML, et réserve le YAML aux capteurs qui transforment vraiment la donnée brute.
Bilan et pour la suite
Ce dispositif couvre aujourd’hui une bonne partie de la maison, mais il reste incomplet : plusieurs prises restent en simple « monitoring » sans seuil de détection propre, ce qui limite les automatisations possibles dessus (pas d’alerte de fin de cycle, pas de détection de panne). La prochaine étape logique serait d’harmoniser tous les capteurs de puissance dérivés (quotidien/hebdo/mensuel/coût) sur l’ensemble des 26 appareils suivis, alors qu’aujourd’hui seuls certains ajouts récents en bénéficient pleinement.
L’autre chantier, plus structurant, serait de croiser production solaire et conso soutirée en temps réel pour déclencher automatiquement les gros consommateurs (lave-vaisselle, machine à laver) pendant les pics de production plutôt que de les lancer manuellement. Le socle de données est là, il ne manque que la couche de décision.
Pourquoi ne pas se contenter du Linky pour suivre sa conso ?
Le Linky donne un total global utile pour le budget, mais ne permet jamais d’identifier quel appareil consomme quoi ni de repérer une dérive précise sans sous-comptage.
Un compteur multi-canaux WiFi local est-il fiable sans cloud ?
Oui, tant que le compteur communique en local (LAN) avec Home Assistant : aucune dépendance à un serveur distant, aucune coupure liée à un service tiers indisponible.
Comment corriger une mesure de puissance négative sur un canal mal câblé ?
Plutôt que de recâbler le transformateur de courant, un capteur template qui multiplie la valeur brute par moins un suffit à corriger le signe sans toucher au matériel.
Comment distinguer l’énergie injectée de l’énergie soutirée avec un seul capteur signé ?
En créant deux capteurs template dérivés du même canal : un qui ne garde que les valeurs positives (soutirage), un qui ne garde que les valeurs négatives inversées (injection).
Faut-il un compteur par appareil pour un suivi énergie complet ?
Non : un compteur multi-canaux couvre les gros postes fixes du tableau, complété par quelques prises connectées ciblées sur les appareils qu’on veut vraiment surveiller.
Stack utilisée
- Linky (intégration native / Enedis) pour la conso de référence et le tarif Base/Tempo
- Refoss EM06P, compteur 6 canaux WiFi local, pour le sous-comptage tableau électrique
- Zigbee2MQTT pour la mesure directe sur circuit dédié (PAC) et prises Zigbee
- Prises connectées WiFi/Zigbee (dont intégration Netatmo) pour les appareils individuels
- Onduleur solaire en local via LocalTuya, 2 panneaux 405W
- Capteurs template Home Assistant pour la correction de signe et le split injection/soutirage
- Compteurs utilitaires (
utility_meter) pour les cumuls jour/semaine/mois
