Quelques ajouts pour finaliser mon installation domotique avec l’ajout des nouveaux panneaux (3.8kWc en toiture contre 1.6kWh) et le routage eau chaude (2 dimmers - puissance variant de 0 à 800W + 1 contacteur on/off pour le jour ou la nuit en fixe à 800W).
De ça :
On passe à ça :
Le boitier de gestion dimmers/contacteur (voir plus haut) :
En résumé :
2 dimmers + 1 sonoff qui sert pour remonter l’eau chaude la nuit si trop basse ou en délestage la journée;
2 mitigeurs installés sur le LV (on met bien moins de temps pour chauffer de 38 à 60/70°C par condensation) ; sur le LL (on lave à « froid », plus de résistance dans la courbe de charge !).
1 sonoff qui sert pour la reprise de la température la nuit ou sur des conditions de météo défavorables le lendemain.
1 ballon de 2400W de 3 résistances, modifié en 3 résistances pour 800W (830/840W chacune dans les faits).
1 carte ACI (qui bloque si le ballon arrive à 65°C) dont le câblage fil est modifié (pour être remis rapidement d’origine).
vu la toiture installée, je ne pourrai jamais avoir plus de 240/250% de routage : soit < 2000W car toiture 3.8kWc / 3kW et j’ai 450/550W de talon.
Dans le principe, le sonoff, les dimmers prennent l’alimentation 220V du tableau élec sur la voie eau chaude (20A). Leurs sorties sont renvoyées sur des contacteurs qui alimentent les résistances. Un shelly reçoit la sortie de la carte ACI (220V quand la température est < 65°C) sur son entrée SW1. Donc par défaut, la sortie du shelly active les contacteurs (mais bon si le sonoff ou les dimmers sont à 0… voir plus bas). Si par contre, le ballon atteint les 65.5°C et pour une raison ou une autre il continue de chauffer, l’alimentation SW1 va se couper ; dévalidant O1 et donc les contacteurs ; CQFD (protection mécanique par la carte ACI ou pilotage par jeedom).
En parallèle, un petit scénario pour piloter tout ça côté domotique. Pour rappel, les dimmers ont en interne une gestion qui stoppe la chauffe si la température de la sonde dallas dans le ballon atteint 65°C ; mais que le premier dimmer.
Donc 3 parachutes au total… car j’ajoute la couche avec jeedom. Les dimmers, routeur PV envoient en MQTT les infos.
A cela, modification du design de suivi de l’énergie et de l’électricité.
Les dimmers pouvant continuer à envoyer une valeur de routage même si le ballon est full, je les filtre si le ballon est full.
Depuis Agrégateurs / DimmerX => Dans Gestion Routage ECS
-
Routage ECS est un binaire qui dit si le routage est cours
-
Cumulus full est un binaire quand le ballon est plein (65.5°C sur hystérésis)
-
Le routage ECS (%) est la somme du contacteur jour (100%) et des 2 dimmers quand le ballon n’est pas full
-
Ppulse ou Routage ECS puissance sont la puissance du compteur pulse de la voie ECS ou l’estimée (8.32 x %total)
-
Dimmer 1 / Dimmer 2 / Contacteur sont les % mises en forme si le ballon n’est pas full
Pour la gestion ON/OFF chauffe (jour ou nuit) un interrupteur pour la journée, un pour la nuit. Et pour éviter les carambolages :
Un scénario Chauffe ON/OFF (jour ou nuit) qui pilote le contacteur de jour ou de nuit.
On active le scénario « répétition » correspondant (toutes les 5min en répétition). Par sécurité timeout sur les scénarios à 30s.
Chaque scénario vérifie que le contacteur « opposé » l’autorise.
Chauffe OFF JOUR => Nuit doit être à 0 => on peut faire Contacteur Jour OFF
Chauffe ON JOUR => Nuit doit être à 0 => on peut faire Contacteur Jour ON
Chauffe OFF NUIT => Jour doit être à 0 => on peut faire Contacteur Nuit OFF
Chauffe OFF NUIT => Jour doit être à 0 => on peut faire Contacteur Nuit ON
Le design principal de suivi de la maison a été un peu modifié côté énergie :
En détails :
La puissance active est donnée par le routeur. Je ne me sers pas de cette valeur pour le calcul suivi conso, car après vérification le routeur calcule depuis une tension fixe et j’ai un écart avec la facturation (logique). Le suivi conso se base sur l’index BASE (pas de HC/HP pour ma part). Je calcule une puissance active moyenne chaque minute par delta de l’index. A noter qu’après plusieurs semaines chez Total, j’ai vérifié et ça colle.
Donc le S (apparent) en VA vient du linky ; le W vient soit du routeur (à calibrer dans le futur quand j’aurai plus de données) ou calculer chaque minute.
Pour le PV, même principe. Compteur pulse (raspberry + jeedouino). Mais c’est la production 
… pas l’autoconsommation. D’ailleurs on voit que je rejette de la puissance sur le réseau.
Le 0% c’est le pourcentage de routage sur l’eau chaude (bein là le ballon est plein à craquer :D). Donc c’est normal, je rejette… Hier, 2.56€ autoconsommé pour un ratio d’autoconso de 94% (donc j’ai rejeté 6% sur le réseau).
Concernant l’eau chaude, le ballon est plein (67°C, je vais chercher son max à 66) ; 100% chauffé gratuitement ; soit 0.8€ gagné pour 6.5h de chauffe aujourd’hui (malgré 3 douches, 2 machines…).
Petit widget au survol comme les autres :
Me permet de voir si ça chauffe, si le ballon est full (à fond de son stockage), si la carte ACI est activée pour chauffer. Le sonoff est le contacteur J/N « fixe » de 800W. Les dimmers eux vont jusqu’à 800W chacun. Mais pour éviter de les charger à mort, un scénario me permet de délester les dimmers sur le contacteur …
Ce délestage marche sur 150% des 2 dimmers et se coupe sur 30% des dimmers…
Bien sûr, il faut que le contacteur soit non activé pour que le scénario s’enclenche et dans l’autre cas que le contacteur soit activé… et que le ballon ne soit pas plein !
Il y a pas mal de choses « cachées » notamment pour la mise en forme et un comptage « juste » propre au routeur Wifi que j’utilise de Clyric (je recommande ce routeur pour l’association APER derrière). J’ai modifié le code source aussi pour pouvoir ajouter le principe de délestage du dimmer.
Un scénario qui regarde si le ballon est full ; de toutes les manières, j’ai conservé la carte ACI qui est la source du shelly qui pilote les contacteurs. Donc c’est plus de la mise en forme et du suivi qui se déclenche sur la température de l’eau chaude (remonté par l’ESP du premier dimmer) :
Dans le principe, la ventilation du boitier tourne et s’arrête 20min après le dernier « ON » (d’un contacteur, d’un dimmer) pour avoir un refroidissement efficace du boitier.
Donc la ventilation se déclenche sur :
Qui est un interrupteur qui revient à 0 au bout de 20min. Donc on fait des ON à chaque fois qu’on a un événement (monostable à durée fixe) :
Qui déclenche un autre scénario par #[Eau Chaude][ECS][Ventilation]# qui lui va activer ou non le shelly qui autorise la chauffe (depuis la carte ACI si l’eau n’est pas à fond - protection mécanique du ballon). Cette ventilation doit marcher que ce soit pour la chauffe de nuit, de jour mais est normalement utile pour les dimmers qui chauffent (voir plus bas).
Et je peux déroger la chauffe de nuit, ou forcer une chauffe de nuit ou de jour…
Un exemple de délestage durant la journée des dimmers vers le contacteur ; ce qui me permet d’avoir 250% environ (800W * 2.5) de puissance dispo sur le ballon par effacement (puisque j’efface d’abord la puissance de la maison qu’elle soit talon ou utilisation).
Quelques exemples :
- en bleu la température du ballon
- en vert le délestage sur le contacteur (puissance fixe à 800W)
- en jaune la puissance des dimmers incluant le délestage (soit 300% au max et donc la puissance max du ballon)
- en orange quand le ballon est full
- en vert : la ventilation (et donc si pas de ventilation ; pas d’autorisation de chauffer)
- en orange : la puissance routée sur le ballon (contacteur, dimmers) jusqu’à 2000W
- en bleu : la température du boitier avec les dimmers (justement qui chauffent …) et qui ne dépasse pas 27°C au plus haut (2000W)
note : le rebond du matin de la ventilation sera supprimé, j’ai affiné le % des dimmers pour le délestage du contacteur (l’hystérésis était buggué).
Quand on zoome un peu plus loin, on voit la faiblesse de l’architecture à deux dimmers. Le second continue de chauffer car il ne tient pas compte de la protection de la température (qui est sur le premier dimmer).
Mais la protection mécanique du ballon se coupant, cela coupe l’alimentation du contacteur et donc il n’y a plus de puissance qui passe… alors je grapille quelques °C de plus, mais bon … le ballon est full.
Le top serait d’avoir un dimmer2 qui tient compte de la température du premier. Pour l’heure, c’est jeedom qui fait le travail en coupant l’alimentation du shelly même si la carte ACI autorise encore la chauffe à quelques °C près…
La difficulté est que je ne veux pas couper la ventilation tout de suite, donc je laisse le shelly enclenché et je le coupe que 15min après ; donc potentiellement le dimmer 2 peut encore envoyé un peu …
Du coup, je préfère rester en délest ou en equal.
Ensuite pour avoir une analyse de ce que je produis, autoconsomme et « perds » de ma toiture…
Dans le principe l’algo est simple pour ceux qui sont familiers avec l’énergie, la puissance.
- on récupère les points de mesure du routeur et les temps sur la journée précédente
- on calcule à chaque point :
- le delta de temps,
- l’énergie vue sur la valeur remontée par le routeur pendant ce delta de temps,
- on stocke la borne temps supérieure pour le coup d’après,
- l’énergie est donc la multiplication du temps et de la puissance sur la période (W = W.s pour les non-connaisseurs),
- on regarde le sens de la puissance active vue :
si positive, elle est consommée
si négative, elle est perdue et rejetée (pour rappel le routeur veut tendre vers 0 suivant sa possibilité !)
- en sortie, on normalise en Wh (/3600)
Seule faiblesse, le routeur n’est pas précis car il ne mesure pas la tension mais que l’angle (pour rappel P=UxIxcosphi. Donc le I et cosphi sont justes… mais le U c’est une constante.
Pas grave, j’ai le compteur Linky par la TIC qui lui est fiable et juste (pour l’avoir pointé et encore heureux !).
Bon et je fais ça… par un scénario avec bloc code :
// récupération de l'ID pour la puissance mesurée par le routeur
$cmdIdprouteur= cmd::byString("#[Agrégateurs][Routeur PV][Puissance]#")->getId();
// définition des bornes de temps pour l'étude pour la veille
$debut = date("Y-m-d H:i:s", strtotime("yesterday 00:00:00"));
$fin = date("Y-m-d H:i:s", strtotime("today 00:00:00"));
// permet de stocker le précédent temps pour la normalisation
$previous = $debut;
// definitions en kWh
$erouteur = 0; // energie extraite par somme cumulée
$epositive_routeur = 0; // energie vue par le routeur
$enegative_routeur = 0; // energie vue par le routeur
$temps_obs = 0; // pour vérifier le nombre de secondes observées pour le calcul
// on récupère les valeurs
$values = history::all($cmdIdprouteur, $debut, $fin);
foreach ($values as $value) {
$date = $value->getDatetime();
$temp = $value->getValue();
$deltatemps = strtotime($date)-strtotime($previous);
$temps_obs = $temps_obs+$deltatemps;
// on regarde le signe de cette énergie
if ($temp >= 0) {
// si positive dans le compteur énergie positif (consommée)
$valuenorm = $temp*$deltatemps;
$epositive_routeur = $epositive_routeur+$valuenorm;
//$scenario->setLog("@temps $date pour delta $deltatemps : valeur positive $temp norm $valuenorm soit $epositive_routeur Wh");
}
else if ($temp < 0) {
// si négative dans le compteur énergie négative (rejetée)
$valuenorm = $temp*$deltatemps;
$enegative_routeur = $enegative_routeur+$valuenorm;
//$scenario->setLog("@temps $date pour delta $deltatemps : valeur negative $temp norm $valuenorm soit $enegative_routeur Wh");
}
// on stocke le temps de référence pour le pas suivant
$previous = $date;
}
// normalisation en Wh et absolu
$epositive_routeur = $epositive_routeur/3600;
$enegative_routeur = abs($enegative_routeur)/3600;
$scenario->setLog("Total analysé : $temps_obs s - Total Consommé : $epositive_routeur Wh - Total Perdu : $enegative_routeur Wh");
// sortie par variable
$scenario->setData('econso_routeur', $epositive_routeur);
$scenario->setData('erejet_routeur', $enegative_routeur);
Ensuite je sors quelques variables pour stats :
- effacement : je regarde sur la veille quand P=0 ; j’ajoute ça chaque jour pour avoir l’effacement depuis le début de l’installation.
round(durationBetween(#[Energie][Puissance Instantanée][Consommation]#,0,yesterday 00:00,today 00:00)/60,2)
- je calcule le ratio d’erreur entre le routeur et linky pour normaliser
- j’estime la vraie consommation vue par le routeur (celle facturée est celle du linky), la production est donnée par le compteur pulse et le rejet sur le réseau (le but étant d’avoir 0…)
- on sort les statistiques suivantes :
- production totale de la veille (par pulse),
- la production depuis la mise en service,
- l’autoconsommation (ce que j’ai consommé de ce que j’ai produit, le but est de tendre à 100%) en % et en Wh,
- l’autoconsommation totale depuis la mise en service (avant, j’avais partagé le code, j’estimais cette autoconsommation sur la base d’un talon de consommation à défaut de mieux car je n’avais pas la courbe de rejet par la mesure d’un routeur),
- le ratio total de l’installation (depuis son installation) d’autoconsommation,
- l’efficacité électrique du routage d’eau chaude par rapport à la consommation électrique (en toute rigueur, 100% d’une durée de chauffe de l’eau chaude ne me donne pas 100% de consommation gratuite… bein oui, y a de l’électronique dans le boitier : dimmers, ventilo, alimentation etc),
- le gain financier du jour (par rapport au prix HT du kWh,
- le gain total HT et l’amortissement (pareil calculé HT car le kWh est HT…)
et un petit télégram tous les matins qui s’ajoute à celui du suivi des usages de la maison …
![]()
Pour les plus attentifs (il y avait une erreur dans la variable autoconso c’est corrigé et le prix économisé de l’eau chaude est corrigé aussi) :
Autre modification le design de suivi de l’énergie :
-
j’avais intégré les excellents graphiques de suivi conso widget, très pratique pour avoir l’évolution de l’année de l’électricité, la production et l’eau.
-
le tableau de mise en forme jour/veille ; semaine/semaine préc et mois/mois préc n’a pas bougé.
-
j’ai ajouté un tableau de suivi de la production et de l’électricité pour la veille qui s’appuie entre autres sur le précédent scénario :
-
et un tableau de suivi des années (année en cours/an-1/an-2)… je remets la consommation électrique totale (autoconsommation + consommation Linky) et les principaux usages ou sources :
- ainsi avec 1.6KWc sur une maison, on peut viser jusqu’à 20% d’une consommation totale ;
- la climatisation (chaud et froid) ; en A-2 il n’y qu’un étage climatisé chaud/froid d’où l’écart et là on sort de l’hiver donc logique qu’on tape du 36%…
- de même la piscine qui est bien basse (5%) par contre, clairement, iopool m’a permis de bien mieux filtrer avec moins de produits (20% il y a 2 ans, 12% alors que la piscine a été ouverte 2 mois de plus !)
- le chauffage électrique est tout petit (car ce sont juste les salles de bains),
- l’onduleur de la maison (routeur, nas, fibre, routeur 4G, etc) mine de rien 5% !
- le cumulus qui tire 13 à 16% de l’usage de la maison (on comprend l’intérêt de chauffer cette eau sur la production solaire) et le routage en place depuis 10 jours…
J’ai aussi supprimé weather que je trouvais moins fiable que meteofull au final. A ce jour, la consigne d’eau chaude pour la nuit est déduite par la météo ; weather m’annonçait systématiquement du couvert ou nuageux alors que le lendemain était « clair ». Meteofull est plus « propre » au niveau des conditions je trouve. Maintenant que ça fait 6 mois que je l’utilise j’en suis très satisfait, certes il est très complet…
Pour l’heure, soit j’ai internet et je regarde si la météo du lendemain est :
(#[Extérieur][MétéoFull][Condition 24h]# matches "/Ensoleillé/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Ciel voilé/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Faibles passages nuageux/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Stratus/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Stratus se dissipant/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Eclaircies/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Faiblement nuageux/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Fortement nuageux/")
et fonction du nombre de personnes à la maison, je vais chauffer un peu la nuit ou non.
Si pas d’internet, j’ai pris la moyenne des autres cas par principe…
Mais je pense intégrer une prédiction de l’ensoleillement en fonction de la saison… pour mieux gérer la température et le besoin en fonction des machines.
