+- F1ATB forum (https://f1atb.fr/forum_f1atb)
+-- Forum : Forum de F1ATB (https://f1atb.fr/forum_f1atb/forum-3.html)
+--- Forum : Routeur Photovoltaïque (https://f1atb.fr/forum_f1atb/forum-4.html)
+--- Sujet : Fonctionnement en consommation fractionnée (/thread-274.html)
Fonctionnement en consommation fractionnée - Alban17 - 27-07-2024
Bonjour,
J’ai installé le routeur d’André sous forme d’un module de mesure et d’un module de puissance distant.
J’utilise actuellement un relais statique (marque GEYA) et tout fonctionne parfaitement bien. Encore merci à André pour tout ce travail et toute l’énergie déployée à ce projet.
Cependant, je cherche à améliorer mon dispositif.
Je cherche dorénavant à piloter deux résistances RA et RB distinctes, représentant chacune une puissance dissipée de 1000 Watts :
- l’une (RA) doit être pilotée en mode proportionnel (multi-sinus), comme actuellement.
- l’autre (RB) doit être pilotée en tout ou rien par un relais.
Je cherche à effectuer un pilotage « conditionnel » de ces deux sources :
a) Si la puissance disponible « P(inject) » réinjectée chez ENEDIS est inférieure à 1000 W, je souhaite que :
- RB « éteinte » (donc ne consommant RIEN)
- RA en mode proportionnel pour consommer « P(inject) »
b) Par contre si la puissance P(inject) est supérieure ou égale à 1000 W,
- RB « allumée » ( donc consommant 1000 W)
- RA en mode proportionnel pour consommer : « P(solar) - 1000W »
Mes remarques et questions :
Remarque 1 : Il est évident qu’une hystérésis devra être créée (ou mieux : utiliser la temporisation) pour éviter que le relais de RB ne « clignote » si la puissance reste aux environs immédiats de 1000W
Question 1 : je me demande si l’ordre de déclaration des organes d’action définit des priorités : par exemple si le relais 1 est déclaré dans la liste AVANT le relais 2, est-ce que la condition de passage ON/OFF du relais 1 est appliquée AVANT la condition sur le relais 2 ? Ou est-ce simplement le n° du port GPIO qui définit la priorité ? S’il y a une notion de priorité définie quelque part dans le code.
Question 2 : J’ai du mal à comprendre la notion de routage ON/OFF pour les relais car de quelle puissance active s’agit-il ? de la puissance sortante (donc envoyée vers ENEDIS) ? si oui, le sens indiqué dans la page « Action » n’est pas clair pour moi : le relais passerait « ON » si la puissance sortante devient INFERIEURE à nnn Watt ? Pour moi, logiquement, j’enclenche le relais si la puissance sortante devient TROP grande et non pas trop petite ! Il en va de même avec la condition de basculement à « OFF ».
J’imagine bien qu’il s’agit très probablement d’une lacune de compréhension de ma part, vu que personne ne pose ces questions.
Est-ce que quelqu’un peut m’éclairer sur ces sujets ?
Merci d’avance
Bon,
j'ai déjà compris quelque chose: il est possible de saisir des valeurs de seuil négatifs sur PC (pas possible sur ma tablette qui me servait jusqu'à lors).La notion de puissance "rentrante" ou "sortante" est donc réglée par ce seuil.
Slts
RE: Fonctionnement en consommation fractionnée - Ludovic35 - 28-07-2024
Bonjour,
Il n'y a pas de gestion de priorité pour l'instant, ni gestion groupée d'actions.
Chaque condition est donc évaluée de manière indépendante.
Les variations de consommation vont générer des états transitoires de forte consommation ou de forte injection.
Il est donc obligatoire d'avoir les seuils Pw des conditions ON et OFF séparés de (charge + 200W) par ex.
Pour faire ce que vous voulez, il faudrait que les 2 actions soient liées entre elles. C'est ce que j'avais fait il y a quelques mois:
si RA est à 100% et qu'il faut consommer plus, on allume RB et RA devient 0%
si RA est à 0% et qu'il faut consommer moins, on éteint RB et RA devient 100%
Avec cette logique, RA devient une extension de RB. L'inconvénient, c'est que c'est un mode très particulier.
Et dans ce registre, il peut y avoir beaucoup de besoins différents.
Normalement, vous devriez faire les choses ainsi (mais vous pouvez avoir 1000W d'injection avant de déclencher RB):
sur RA en multisinus, Pw=0W
sur RB, ON si Pw < -1000W, OFF si Pw > 200W
(il faut donc avoir un surplus de minimum 2000W pour que RB se déclenche)
Essayez plusieurs seuils pour trouver le meilleur compromis. Par exemple:
sur RA en multisinus, Pw=0W
sur RB, ON si Pw < -500W, OFF si Pw > 500W
(il faut avoir minimum 1500W de surplus, et on peut se retrouver à consommer 500W)
RE: Fonctionnement en consommation fractionnée - F1ATB - 28-07-2024
Je peux comprendre l'intérêt. Il faut en faire une programmation simple, compréhensible par tous, afin de ne pas avoir une avalanche de 'ça ne marche pas'...
RE: Fonctionnement en consommation fractionnée - Alban17 - 28-07-2024
(28-07-2024, 11:01 AM)Ludovic35 a écrit : Bonjour,
Il n'y a pas de gestion de priorité pour l'instant, ni gestion groupée d'actions.
Chaque condition est donc évaluée de manière indépendante.
Les variations de consommation vont générer des états transitoires de forte consommation ou de forte injection.
Il est donc obligatoire d'avoir les seuils Pw des conditions ON et OFF séparés de (charge + 200W) par ex.
Pour faire ce que vous voulez, il faudrait que les 2 actions soient liées entre elles. C'est ce que j'avais fait il y a quelques mois:
si RA est à 100% et qu'il faut consommer plus, on allume RB et RA devient 0%
si RA est à 0% et qu'il faut consommer moins, on éteint RB et RA devient 100%
Avec cette logique, RA devient une extension de RB. L'inconvénient, c'est que c'est un mode très particulier.
Et dans ce registre, il peut y avoir beaucoup de besoins différents.
Normalement, vous devriez faire les choses ainsi (mais vous pouvez avoir 1000W d'injection avant de déclencher RB):
sur RA en multisinus, Pw=0W
sur RB, ON si Pw < -1000W, OFF si Pw > 200W
(il faut donc avoir un surplus de minimum 2000W pour que RB se déclenche)
Essayez plusieurs seuils pour trouver le meilleur compromis. Par exemple:
sur RA en multisinus, Pw=0W
sur RB, ON si Pw < -500W, OFF si Pw > 500W
(il faut avoir minimum 1500W de surplus, et on peut se retrouver à consommer 500W)
Merci pour cette réponse qui m'éclaire sur pas mal de points.
(28-07-2024, 11:45 AM)F1ATB a écrit : Je peux comprendre l'intérêt. Il faut en faire une programmation simple, compréhensible par tous, afin de ne pas avoir une avalanche de 'ça ne marche pas'...
Mon but n'est pas de complexifier le système: sinon, on risque d'avoir une "usine à gaz" difficilement maintenable.
Je pense qu'il faut oublier ma question ; c'est plutôt à moi de trouver comment contourner mon problème
. Et en termes de développement, j'ai toujours appris par expérience que "si l'on ne peut pas passer par la porte principale, alors il faut tenter de passer par la fenêtre", du moment où la solution reste propre et bien justifiée en termes de choix.