Ma piscine tournait sur un planning fixe programmé dans l’appli Shelly : 21h-7h la nuit, 12h-18h en journée, tous les jours de l’année, qu’il fasse 18°C ou 30°C dans l’eau. Ça marchait, mais ça ne collait à rien de réel. Une pompe qui tourne 14h par jour en plein hiver alors que l’eau n’a besoin que de 9h de filtration, c’est de l’électricité jetée par la fenêtre. Et à l’inverse, un électrolyseur qui continue de saler l’eau alors qu’elle est déjà parfaitement désinfectée, c’est du sel et de l’usure de cellule pour rien.
L’idée de départ était simple : faire tourner ma piscine au plus juste, ni trop ni pas assez, en s’appuyant sur ce que les sondes mesurent réellement plutôt que sur un planning figé. Et en chemin, j’en ai profité pour combler un vrai trou de sécurité : ce planning aveugle ne savait même pas qu’un capteur de fuite surveillait le sol du local technique juste à côté.
Le point de départ : un planning qui ignorait tout de la piscine
Mon installation repose sur un Shelly Pro 3 dans le cabanon technique, qui pilote trois relais : le moteur de filtration, l’électrolyseur (traitement au sel) et l’éclairage. Des sondes séparées mesurent en continu la température de l’eau, le pH et l’ORP, le potentiel d’oxydo-réduction, qui indique en temps réel si l’eau est bien désinfectée. Un capteur de fuite Zigbee, posé au sol du cabanon, complète le dispositif.
Toute cette intelligence existait déjà dans Home Assistant. Le problème, c’est que rien ne la reliait à la pompe : le planning vivait isolé dans l’appli Shelly, sourd à la température de l’eau, à la qualité de la désinfection et même à un risque de fuite juste à côté. Deux systèmes qui s’ignoraient superbement.
Un budget de marche basé sur la température, pas sur l’horloge
C’est le cœur du projet. Il existe une règle empirique classique en entretien de piscine : la durée de filtration idéale équivaut à la température de l’eau divisée par deux, exprimée en heures. À 28°C, ça donne 14h de filtration par jour. À 22°C, seulement 11h. En hiver, ça peut descendre à 8-9h. Un planning fixe ne fait aucune de ces distinctions, il tourne pareil en toute saison.
J’ai transformé cette règle en automatisation réelle dans Home Assistant, avec deux mécanismes complémentaires :
Le premier agit au démarrage d’un créneau programmé (le planning nuit + midi a été recréé dans Home Assistant à l’identique, mais cette fois connecté au reste de la maison). Si l’objectif du jour est déjà atteint, typiquement le soir après une nuit et un midi de filtration cumulés, le moteur ne redémarre tout simplement pas.
Le second surveille en continu pendant que la pompe tourne. Si l’objectif est franchi en cours de route, par exemple démarré à 21h avec l’objectif pas encore atteint, puis dépassé au milieu de la nuit, le moteur est coupé sur-le-champ plutôt que d’attendre la fin du créneau.
J’ai ajouté une exception avec un peu de bon sens : si ce dépassement a lieu après 23h30, on ne coupe pas. Inutile d’arrêter le moteur pour trente minutes avant son redémarrage normal à minuit, quand le compteur du jour repart à zéro.
Et parce qu’une automatisation trop rigide finit toujours par gêner un jour ou l’autre (une soirée au bord de la piscine, une baignade improvisée qui trouble l’eau), chaque fois que le plafond empêche la pompe de démarrer ou la coupe, une notification Telegram arrive avec un bouton « Relancer le moteur » pour passer outre en un geste.
Le petit truc en plus
La règle « température divisée par deux » est un point de départ, pas une loi gravée dans le marbre. Elle mérite d’être ajustée selon le volume du bassin et la puissance de la pompe. L’important n’est pas la formule exacte, c’est d’avoir un objectif qui bouge avec la réalité de l’eau plutôt qu’un horaire figé sur un calendrier.
Garder une eau parfaite sans gaspiller de sel
La même logique d’optimisation s’applique à l’électrolyseur. Son rôle est de transformer le sel dissous dans l’eau en chlore actif, et l’ORP est justement l’indicateur qui dit si cette désinfection est suffisante ou déjà excessive. Un ORP trop bas veut dire une eau mal traitée, un ORP trop haut veut dire qu’on continue à produire du chlore alors que l’eau est déjà largement traitée, ce qui use la cellule d’électrolyse et pousse la consommation de sel pour rien.
J’ai donc ajouté une automatisation qui coupe l’électrolyseur dès que l’ORP dépasse 750 mV, et le relance automatiquement une fois redescendu sous 700 mV. Cette marge de 50 mV entre le seuil de coupure et le seuil de relance évite que l’électrolyseur s’allume et s’éteigne en boucle autour d’une valeur pivot, un cycle court qui userait le matériel bien plus vite qu’une désinfection légèrement prolongée.
D’abord, ne jamais risquer un dégât des eaux
Avec cette logique d’optimisation posée, il restait un point que je ne pouvais pas laisser de côté : que se passe-t-il si une fuite d’eau se déclare dans le local technique pendant que la pompe tourne ? Dans l’ancien système, rien. L’appli Shelly ignorait complètement l’existence du capteur de fuite posé à deux mètres du relais qu’elle pilotait.
Dès que le capteur détecte de l’eau au sol du cabanon, deux choses se produisent immédiatement, sans délai ni confirmation : le moteur de la pompe est coupé, et une alerte Telegram part aussitôt. Cette alerte se répète toutes les minutes tant que la fuite reste active, avec un bouton « Stopper l’alarme (1h) » pour respirer sans pour autant relancer le moteur. Si la fuite est toujours là au bout de cette heure de silence, les notifications reprennent automatiquement.
En complément, une seconde automatisation totalement indépendante surveille l’état réel du moteur en permanence : si jamais il repasse en marche alors qu’une fuite est toujours active, peu importe la source de la commande (planning, tablette, appli Shelly), il est immédiatement recoupé. La sécurité prime toujours, quelle que soit la façon dont on a tenté de la contourner, et ce filet reste actif même pendant l’heure de silence des notifications.
Les capteurs mentent parfois un peu
Un détail que je n’avais pas anticipé : le capteur de fuite Zigbee a des micro-coupures réseau régulières, quelques secondes toutes les dix à quinze minutes, avant de revenir à la normale. Ma première version de l’automatisation « fuite terminée » se déclenchait à chaque reconnexion, envoyant un message de confirmation alors qu’il n’y avait jamais eu de fuite réelle.
La correction n’était pas d’attendre plus longtemps avant de confirmer, un simple délai de stabilisation ne suffisait pas puisqu’une reconnexion peut rester stable largement au-delà de ce délai. La vraie solution était de vérifier que le capteur venait bien d’un état « fuite détectée » authentique avant d’envoyer la confirmation de fin. Sans cette transition réelle, pas de message. Un bon rappel : un capteur qui redevient « off » ne veut pas toujours dire ce qu’on croit, il faut vérifier d’où il vient, pas seulement où il va.
Un tableau de bord qui centralise tout
Toute cette mécanique reste invisible au quotidien, ce qui est justement le but. Une popup dédiée dans Home Assistant regroupe l’état du moteur, de l’électrolyseur et de l’éclairage (avec bascule directe au tap), le pH et la température actuels, l’ORP en mV, deux boutons « Tout allumer » et « Tout couper », ainsi qu’un historique 24h du fonctionnement moteur/électrolyseur et des courbes pH, température, ORP. Un seul écran pour vérifier d’un coup d’œil que tout tourne comme prévu, sans avoir à se souvenir de la logique qui tourne derrière.
Un bug de dashboard qui faisait mentir l’affichage
Dernier détail découvert en cours de route : le widget qui affichait la progression « durée de marche / objectif du jour » se basait sur un compteur glissant sur 24h, plutôt que sur le vrai compteur remis à zéro chaque minuit. Résultat : l’affichage indiquait parfois 100% de l’objectif atteint alors que la pompe continuait de tourner normalement, parce que le calcul et la décision réelle ne regardaient pas le même chiffre. Corrigé pour que l’écran affiche exactement ce qui pilote la pompe, ni plus ni moins.
Ce que j’en retiens
La vraie valeur de ce projet n’est pas dans le gadget technique, elle est dans deux idées simples appliquées avec rigueur : ne jamais gaspiller (le temps de filtration, le sel de l’électrolyseur) et ne jamais risquer (une fuite qui continue en silence pendant que la pompe tourne). Un Shelly qui pilote un planning tout seul dans son coin, c’est pratique le premier jour. Mais il ne saura jamais que l’eau a gagné trois degrés cette semaine, ni que l’ORP est en train de grimper, ni qu’un capteur au sol vient de détecter de l’humidité. Centraliser tout ça dans Home Assistant, c’est simplement laisser la piscine réagir à ce qui se passe réellement, au lieu de suivre une horloge aveugle.
Bonus : tableau electrique
Sur la photo, le coffret en haut est dédié à la piscine : c’est là que tout se raccorde, avec le Shelly Pro 3 en sortie qui pilote le moteur, l’électrolyseur et l’éclairage via un contacteur Schneider. À gauche, le petit boîtier gère la partie panneaux solaires. En bas, le coffret correspond à l’arrivée générale dans le cabanon.
FAQ
Pourquoi couper l’électrolyseur à 750 mV plutôt que de le laisser tourner en continu ?
Un ORP durablement au-dessus de 750 mV signifie que l’eau est déjà largement désinfectée. Continuer à produire du chlore dans ces conditions use la cellule d’électrolyse et consomme du sel pour un bénéfice quasi nul.
Pourquoi une marge entre le seuil de coupure et le seuil de relance ?
Sans hystérésis, l’automatisation allumerait et éteindrait l’électrolyseur en boucle dès que l’ORP oscille autour d’une valeur unique. La marge de 50 mV entre 750 et 700 mV lisse ces variations et évite l’usure prématurée du matériel.
La règle « température divisée par deux » est-elle fiable pour toutes les piscines ?
C’est une règle empirique largement utilisée en entretien de piscine, un bon point de départ plutôt qu’une vérité absolue. Elle mérite d’être ajustée selon le volume du bassin, la puissance de la pompe et la fréquentation réelle.
Que se passe-t-il si le capteur de fuite perd sa connexion Zigbee ?
C’est un point de vigilance réel : les automatisations ne se déclenchent que sur un état « fuite détectée » explicite, pas sur une perte de communication. Un capteur hors ligne ne génère donc aucune alerte, ce qui reste une limite à corriger avec une surveillance de disponibilité dédiée.
