Introduction : un besoin clair, une solution pas si évidente

L’objectif initial était simple : utiliser l’électricité produite en surplus par des panneaux solaires pour alimenter un chauffe-eau, sans injecter inutilement sur le réseau et sans consommer aux heures de pointe. Pour cela, l’utilisateur s’appuyait jusqu’ici sur l’application SmartLife. Mais cette dernière ne permettait pas de vérifier si le surplus était stable sur une durée donnée. Conséquence : par temps nuageux, le chauffe-eau s’activait et se coupait fréquemment.

La migration vers Home Assistant visait donc à régler ce comportement erratique. Mais comme souvent, les premiers pas réservent leur lot de pièges.

Mettre en place une logique de déclenchement stable

La première étape a été de remplacer les règles basiques de SmartLife par une automatisation dans Home Assistant utilisant sensor.envoy_..._current_net_power_consumption. Cette entité expose la puissance nette injectée ou prélevée.

Un premier piège apparaît : le déclencheur numeric_state doit être combiné avec for: "00:05:00" pour que l’état soit maintenu pendant 5 minutes avant d’agir. Sans cela, le chauffe-eau se met à osciller au gré des variations rapides de puissance.

Mauvaise logique de coupure : un seuil à l’envers

Initialement, la logique d’extinction du chauffe-eau était déclenchée si la production descendait en dessous de 1,5 kW. Cela semblait logique, mais ne fonctionnait pas : il fallait en réalité déclencher l’arrêt quand l’import sur le réseau dépassait 2 kW (donc sensor.envoy_... > 2). Une fois corrigé, la coupure était pertinente.

Déclenchements multiples et répétitions non désirées

Autre effet de bord : l’automatisation se redéclenchait en boucle, même si le chauffe-eau était déjà allumé. Pourquoi ? Parce que for: "00:05:00" redéclenche l’automation à chaque fois que l’état redevient stable 5 minutes.

La solution retenue a été d’ajouter une condition d’état sur switch.chauffe_eau_switch :

- condition: state
  entity_id: switch.chauffe_eau_switch
  state: "off"

Ainsi, on ne tente d’allumer le chauffe-eau que s’il est bien éteint. L’inverse a été appliqué pour l’extinction.

Mesurer le temps de chauffe avec history_stats

Pour décider s’il fallait lancer une chauffe de secours à 23 h, il était nécessaire de savoir si le chauffe-eau avait fonctionné au moins 4 h depuis le début de la journée. Le capteur history_stats a été choisi, mais l’utilisateur a utilisé un seuil below: 240 en pensant à des minutes.

Erreur : ce capteur retourne des heures décimales. Il fallait écrire below: 4 pour 4 h. Cette subtilité n’est pas visible dans l’interface mais confirmée dans la documentation.

L’automatisation de coupure coupe même en mode « surplus »

Le script d’arrêt automatique à 17 h était conçu pour les cas de chauffe forcée. Mais il éteignait aussi le chauffe-eau même s’il était en mode « surplus ». La logique n’était donc pas conditionnée à l’origine de l’allumage.

La solution : ajouter un input_boolean.chauffe_eau_forcage activé uniquement lors des forçages (13 h ou 23 h). L’automatisation de 17 h ne coupe plus que si ce flag est actif.

Mauvaise détection météo : sunny ou ensoleillé ?

Dans l’automatisation de forçage, la météo était exploitée pour éviter d’allumer si le ciel est ensoleillé. Mais l’état attendu était ensoleillé, alors que l’API de Met.no renvoie sunny.

Un simple test dans Outils de développement ▸ États a permis de corriger le mot-clé.

Suppressions et nettoyage final

Avec les nouvelles automatisations, plusieurs anciennes étaient devenues redondantes ou incohérentes :

• allumages forcés fixes,
• détections de seuils avec des input_boolean,
• reset manuel de la mémoire de production,
• ID dupliqués dans les automatisations YAML,
• capteurs non créés via l’UI.

Tout cela a été supprimé, ramenant la logique à quatre automatisations bien distinctes :

• surplus,
• forçage (13 h),
• secours (23 h),
• extinction/reset (07 h/17 h/00 h).

Besoin d’aide pour votre propre configuration ?

Chaque environnement est différent : modèle de chauffe-eau, seuils de production, comportement des onduleurs, tarif heures creuses, etc. Si vous avez besoin d’adapter cette logique à votre situation ou si vous rencontrez des comportements inattendus, n’hésitez pas à nous contacter pour un accompagnement précis.