| Bienvenue, Visiteur |
Vous devez vous enregistrer avant de pouvoir poster.
|
| Utilisateurs en ligne |
Il y a actuellement 206 utilisateurs connectés.
» 10 Membre(s) | 193 Visiteur(s)
Bing, Google, Yandex, AtomeIon, cmichel, f4ame, Fredo33650, Julien, Lolo69, Mikado, tupolev89
|
|
|
| Ajout mesure de puissance chauffe eau par pince |
|
Posté par : Julien - 02-11-2024, 12:25 PM - Forum : Routeur Photovoltaïque
- Réponses (2)
|
 |
Bonjour,
Je suis en train de monter un routeur V12, merci pour tout le travail, le boulot du vulgarisation est top.
Je me demandais si on avait un retour via mqtt de la puissance injectée dans le chauffe-eau, ou si non, s'il était possible de rajouter une pince ampèremétrique au système pour avoir cette puissance (c'est actuellement ce que je fais sur un "routeur Barnabé Chaillot" ...)
Merci pour vos retours.
Julien
|
|
|
| Fonction SIP anti legionnelle |
|
Posté par : Lolo69 - 02-11-2024, 10:26 AM - Forum : Evolutions faites, à faire, dont vous rêvez...
- Réponses (15)
|
|
J ai tiré l acronyme SIP dans le monde industriel de la pharmacie qui signifie Sterilization In Place.
Mais si le terme est utilisé est abusif pour la demande ci-dessous.
La première fonction du routeur qui est de router les watts solaire excédentaires est deja plus sue parfaitement remplie.
La majorité d entre nous , route cette énergie vers un chauffe eau qui fait office de batterie solaire ( moins efficace énergétiquement qu’une batterie électrique, mais infiniment plus rentable financièrement. Le retour sur investissement est inférieur à 6 mois alors que pour les batteries je crains qu’il ne soit infini.
Bref j en viens au fait.
Le dilemme de l eau chaude est que pour se laver de l eau à 40 degrés serait très largement suffisant et donc il y aurait d énormes économies à faire à des descendre la consigne de chauffe vers 40 degrés
MAIS ATTENTION DANGER presque mortel à faire cela à cause des bactéries Legionella qui adorent se reproduire à cette température et risquent de vous provoquer la legionellose maladie qui peut être mortelle.
Il faut trouver un compromis sachant que ces legionelles prolifèrent entre 20 et 50 degrés.
Qu ‘elles ne prolifèrent plus entre 50 et 55 mais restent vivantes
Qu elles meurent en 30 min si vous les cuisez à 60 et en 10 min à 63deg
L'idée serait de mettre une consigne de température de 52 degrés ( au lieu des 55~60) préconisée, cela ralenti le développement des bestioles et economise 1,45kw par jour avec un ballon de 250 litres ( si ca intéresse quelqu’un je peux détailler ce calcul)
Cela représente un gain potentiel supplémentaire d’environ 80 euros par an et de nombreux kilo de CO2 en moins pour la planète
Et la fonction qui manque : faire une programmation « hebdomadaire » pour pouvoir faire une chauffe par semaine à 60degré pour éliminer une tres grande majorité des bestioles qui se seraient développées.
Je sais que niveau programme cela doit être complexe à réaliser avec des pages web de paramètrages.
De mon côté je vais l ecrire dans le code source c’est à ma portée.
Pour André il y a sûrement une méthode « simplifiée » pour pouvoir ajouter ce paramètrages dans le serveur Web
|
|
|
|
| Bug JSY-MK-194T |
|
Posté par : Fred37 - 02-11-2024, 12:11 AM - Forum : Routeur Photovoltaïque
- Pas de réponse
|
|
Bonjour, et bravo pour ce routeur.
Mais j'ai quelques soucis avec:
Routeur v11.19, j'ai le JSY-MK-194T mais il fonctionne visiblement pas correctement:
Dans les données brutes, j'ai des valeurs "bizarres" au lieu du 240V. Pourquoi ?
La "fonction" UxIx2 ne fonctionne pas longtemps, quand elle fonctionne...
Pour avoir des données, il faut que je sélectionne UxI... mais pas réelles...
Ayant lu qq part qu'il fallait "brancher les capteurs au 5V pour éviter des 'faiblesses', serait là la cause de ce dysfonctionnement ? (Tout le monde est maintenant sur 3,3V (sauf l Esp, en mUSB)
De mm, la courbe "tension et courant sur 20ms", je n'ai pas de sinusoide, loin de là...
Pouvez-vous m'aider ? Merci d'avance !! 
Alimentation 240V ok, Port série RX=gpio 26, TX=gpio 27 coché (et pin ok), vitesse testée (via sketch), et réglée, avant televersement sur la SEULE vitesse qui la fait fonctionner
|
|
|
|
| Petit bug avec relais en mode inactif ? |
|
Posté par : AtomeIon - 01-11-2024, 10:41 PM - Forum : Routeur Photovoltaïque
- Réponses (2)
|
|
Bonsoir André,
Est-il normal qu'en mode "inactif" dans le planning, un relais distant reçoive des commandes OFF provenant du routeur ?
Je vous fait part du comportement étrange observé.
Je suis en 12.06, j'utilise une configuration avec gpio externe (sonoff), les 2 paramètres optionnels sont "non exploité"
En mode "ON/OFF", le fonctionnement semble normal.
Si je passe ensuite en mode "inactif" (suivi d'une sauvegarde évidemment), des commandes OFF sont envoyées en permanence au sonoff, à partir du moment ou la "répétition" est supérieur à 0s.
Dans la console du Sonoff (tasmota dans mon cas), on voit bien les commandes arriver avec un intervalle de temps correspondant à celui indiqué dans la case "répétition".
|
|
|
|
| probleme mutisinus |
|
Posté par : 59jag - 01-11-2024, 09:15 PM - Forum : Routeur Photovoltaïque
- Réponses (6)
|
|
Bonjour,
Encore bravo pour votre routeur.
Voulant rajouter un sortie DAC a l esp pour piloter un chargeur de batterie LFP avec votre routeur je me suis plongée dans votre code .
je regarde la partie multisinus , ou il y a le calcul pour remplir les 2 tableaux tabPulseSinusTotal[I] et tabPulseSinusOn[I] normalement pour éviter les composantes continues il faut le couple de valeur soit paire ou impaire, mais pas impaire et pair.
Code : //Tableau Longueur Pulse et Longueur Trame pour Multi-Sinus de 0 à 100%
float erreur;
float vrai;
float target;
for (int I = 0; I < 101; I++) {
tabPulseSinusTotal[I] = -1;
tabPulseSinusOn[I] = -1;
target = float(I) / 100.0;
for (int T = 20; T < 101; T++) {
for (int N = 0; N <= T; N++) {
if (T % 2 == 1 || N % 2 == 0) { // Valeurs impair du total ou pulses pairs pour éviter courant continu
vrai = float(N) / float(T);
erreur = abs(vrai - target);
if (erreur < 0.004) {
tabPulseSinusTotal[I] = T;
tabPulseSinusOn[I] = N;
N = 101;
T = 101;
}
}
}
}
}
pour etre sur j ai fait une simulation avec (T % 2 == 1 || N % 2 == 0) ca donne ceci dans les tableaux
I T N N/T TARGET Resultat
0 20 0 0.000 0.00 ok
1 73 1 0.014 0.01 ok
2 43 1 0.023 0.02 ok
3 31 1 0.032 0.03 ok
4 23 1 0.043 0.04 ok
5 21 1 0.048 0.05 ok
6 32 2 0.062 0.06 ok
7 28 2 0.071 0.07 ok
8 24 2 0.083 0.08 ok
9 22 2 0.091 0.09 ok
10 20 2 0.100 0.10 ok
11 27 3 0.111 0.11 ok
12 25 3 0.120 0.12 ok
13 23 3 0.130 0.13 ok
14 21 3 0.143 0.14 ok
15 26 4 0.154 0.15 ok
16 25 4 0.160 0.16 bad
17 23 4 0.174 0.17 bad
18 22 4 0.182 0.18 ok
19 21 4 0.190 0.19 bad
20 20 4 0.200 0.20 ok
21 29 6 0.207 0.21 bad
22 23 5 0.217 0.22 ok
23 26 6 0.231 0.23 ok
24 21 5 0.238 0.24 ok
25 24 6 0.250 0.25 ok
26 23 6 0.261 0.26 bad
27 22 6 0.273 0.27 ok
28 25 7 0.280 0.28 ok
29 31 9 0.290 0.29 ok
30 20 6 0.300 0.30 ok
31 26 8 0.308 0.31 ok
32 25 8 0.320 0.32 bad
33 21 7 0.333 0.33 ok
34 35 12 0.343 0.34 bad
35 23 8 0.348 0.35 bad
36 22 8 0.364 0.36 ok
37 27 10 0.370 0.37 bad
38 21 8 0.381 0.38 bad
39 23 9 0.391 0.39 ok
40 20 8 0.400 0.40 ok
41 27 11 0.407 0.41 ok
42 24 10 0.417 0.42 ok
43 21 9 0.429 0.43 ok
44 25 11 0.440 0.44 ok
45 29 13 0.448 0.45 ok
46 26 12 0.462 0.46 ok
47 30 14 0.467 0.47 ok
48 21 10 0.476 0.48 bad
49 37 18 0.486 0.49 bad
50 20 10 0.500 0.50 ok
51 37 19 0.514 0.51 ok
52 21 11 0.524 0.52 ok
53 30 16 0.533 0.53 ok
54 26 14 0.538 0.54 ok
55 29 16 0.552 0.55 bad
56 25 14 0.560 0.56 bad
57 21 12 0.571 0.57 bad
58 24 14 0.583 0.58 ok
59 27 16 0.593 0.59 bad
60 20 12 0.600 0.60 ok
61 23 14 0.609 0.61 bad
62 21 13 0.619 0.62 ok
63 27 17 0.630 0.63 ok
64 22 14 0.636 0.64 ok
65 23 15 0.652 0.65 ok
66 35 23 0.657 0.66 ok
67 21 14 0.667 0.67 bad
68 25 17 0.680 0.68 ok
69 26 18 0.692 0.69 ok
70 20 14 0.700 0.70 ok
71 31 22 0.710 0.71 bad
72 25 18 0.720 0.72 bad
73 22 16 0.727 0.73 ok
74 23 17 0.739 0.74 ok
75 24 18 0.750 0.75 ok
76 21 16 0.762 0.76 bad
77 26 20 0.769 0.77 ok
78 23 18 0.783 0.78 bad
79 29 23 0.793 0.79 ok
80 20 16 0.800 0.80 ok
81 21 17 0.810 0.81 ok
82 22 18 0.818 0.82 ok
83 23 19 0.826 0.83 ok
84 25 21 0.840 0.84 ok
85 26 22 0.846 0.85 ok
86 21 18 0.857 0.86 bad
87 23 20 0.870 0.87 bad
88 25 22 0.880 0.88 bad
89 27 24 0.889 0.89 bad
90 20 18 0.900 0.90 ok
91 22 20 0.909 0.91 ok
92 24 22 0.917 0.92 ok
93 28 26 0.929 0.93 ok
94 32 30 0.937 0.94 ok
95 21 20 0.952 0.95 bad
96 23 22 0.957 0.96 bad
97 31 30 0.968 0.97 bad
98 43 42 0.977 0.98 bad
99 73 72 0.986 0.99 bad
100 20 20 1.000 1.00 ok
avec if ((T % 2) ^ (N % 2) == 0)
I T N N/T TARGET Resultat
0 20 0 0.000 0.00 ok
1 73 1 0.014 0.01 ok
2 43 1 0.023 0.02 ok
3 31 1 0.032 0.03 ok
4 23 1 0.043 0.04 ok
5 21 1 0.048 0.05 ok
6 32 2 0.062 0.06 ok
7 28 2 0.071 0.07 ok
8 24 2 0.083 0.08 ok
9 22 2 0.091 0.09 ok
10 20 2 0.100 0.10 ok
11 27 3 0.111 0.11 ok
12 25 3 0.120 0.12 ok
13 23 3 0.130 0.13 ok
14 21 3 0.143 0.14 ok
15 26 4 0.154 0.15 ok
16 31 5 0.161 0.16 ok
17 24 4 0.167 0.17 ok
18 22 4 0.182 0.18 ok
19 32 6 0.187 0.19 ok
20 20 4 0.200 0.20 ok
21 33 7 0.212 0.21 ok
22 23 5 0.217 0.22 ok
23 26 6 0.231 0.23 ok
24 21 5 0.238 0.24 ok
25 24 6 0.250 0.25 ok
26 27 7 0.259 0.26 ok
27 22 6 0.273 0.27 ok
28 25 7 0.280 0.28 ok
29 31 9 0.290 0.29 ok
30 20 6 0.300 0.30 ok
31 26 8 0.308 0.31 ok
32 41 13 0.317 0.32 ok
33 21 7 0.333 0.33 ok
34 64 22 0.344 0.34 ok
35 34 12 0.353 0.35 ok
36 22 8 0.364 0.36 ok
37 35 13 0.371 0.37 ok
38 29 11 0.379 0.38 ok
39 23 9 0.391 0.39 ok
40 20 8 0.400 0.40 ok
41 27 11 0.407 0.41 ok
42 24 10 0.417 0.42 ok
43 21 9 0.429 0.43 ok
44 25 11 0.440 0.44 ok
45 29 13 0.448 0.45 ok
46 26 12 0.462 0.46 ok
47 30 14 0.467 0.47 ok
48 23 11 0.478 0.48 ok
49 39 19 0.487 0.49 ok
50 20 10 0.500 0.50 ok
51 37 19 0.514 0.51 ok
52 21 11 0.524 0.52 ok
53 30 16 0.533 0.53 ok
54 26 14 0.538 0.54 ok
55 31 17 0.548 0.55 ok
56 32 18 0.562 0.56 ok
57 28 16 0.571 0.57 ok
58 24 14 0.583 0.58 ok
59 29 17 0.586 0.59 ok
60 20 12 0.600 0.60 ok
61 31 19 0.613 0.61 ok
62 21 13 0.619 0.62 ok
63 27 17 0.630 0.63 ok
64 22 14 0.636 0.64 ok
65 23 15 0.652 0.65 ok
66 35 23 0.657 0.66 ok
67 24 16 0.667 0.67 ok
68 25 17 0.680 0.68 ok
69 26 18 0.692 0.69 ok
70 20 14 0.700 0.70 ok
71 41 29 0.707 0.71 ok
72 36 26 0.722 0.72 ok
73 22 16 0.727 0.73 ok
74 23 17 0.739 0.74 ok
75 24 18 0.750 0.75 ok
76 25 19 0.760 0.76 ok
77 26 20 0.769 0.77 ok
78 27 21 0.778 0.78 ok
79 29 23 0.793 0.79 ok
80 20 16 0.800 0.80 ok
81 21 17 0.810 0.81 ok
82 22 18 0.818 0.82 ok
83 23 19 0.826 0.83 ok
84 25 21 0.840 0.84 ok
85 26 22 0.846 0.85 ok
86 28 24 0.857 0.86 ok
87 30 26 0.867 0.87 ok
88 33 29 0.879 0.88 ok
89 36 32 0.889 0.89 ok
90 20 18 0.900 0.90 ok
91 22 20 0.909 0.91 ok
92 24 22 0.917 0.92 ok
93 28 26 0.929 0.93 ok
94 32 30 0.937 0.94 ok
95 38 36 0.947 0.95 ok
96 46 44 0.957 0.96 ok
97 59 57 0.966 0.97 ok
98 84 82 0.976 0.98 ok
99 -1 -1 1.000 0.99 ok
100 20 20 1.000 1.00 ok
seul 99 ne donne pas de resultat.
voila j espere ne pas avoir dit trop de conneries
|
|
|
|
| Estimation d'injection avec TIC + CACSI |
|
Posté par : Ludovic35 - 01-11-2024, 05:23 PM - Forum : Evolutions faites, à faire, dont vous rêvez...
- Pas de réponse
|
|
Bonjour,
Pour ceux qui utilisent la TIC pour la lecture, et qui ont un CACSI, la régulation en cas d'injection est plutôt lente, voir très lente si on baisse le seuil de régulation à une faible valeur (Pw=50W dans mon cas).
En cas d'injection, on ne voit donc que Consommation = 0.
Serait-il possible d'intégrer un bout de code qui permet d'estimer la puissance injectée?
Cela ne permettra pas de réduire le seuil de régulation (50W semble être un minimum), mais ça accélère fortement la régulation en cas d'injection.
L'algo que j'utilise est basé sur les informations Irms et Urms de la TIC. Irms étant en entier, l'erreur est de +- 0.5A (soit 115W).
L'algo ne s'active que si la consommation est à 0W (PuissanceS_M); il est donc transitoire car on régule sur 50W.
Détail du calcul ci-dessous (les valeurs sont collectées avant le calcul, "cacsi=true" sur la condition (!EAITvalid && Tm > 8000)).
Les valeurs de puissance apparente SINSTS ne sont utilisées que pour tester si c'est ==0VA, le calcul est fait avec les valeur Urms et Irms.
Si SINSTS==0, alors une valeur de courant non nulle signifie de l'injection, sinon c'est de la consommation.
pPuissance = 0; // initialisation valeur puissance injectée
if (cacsi && PuissanceS_M == 0) { // estimation de la puissance d'injection seulement si PuissanceS_M==0 et si on est en CACSI
pPuissance = 150 + (pSINSTS1 == 0?-1:1) * pURMS1 * pIRMS1; // marge de 150W
if (pIRMS3 != -1) { // triphasé
pPuissance += (pSINSTS2 == 0?-1:1) * pURMS2 * pIRMS2;
pPuissance += (pSINSTS3 == 0?-1:1) * pURMS3 * pIRMS3;
}
}
if (pPuissance >= 0) { // pas d'estimation si l'écart est faible en prenant la marge de 150W
PuissanceI_M = 0;
} else {
PuissanceI_M = -pPuissance; // "-" car on donne la valeur injectée
}
Cela fonctionne bien malgré l'imprécision relative aux mesures d'intensités (la marge de 150W réduit le risque de surestimation de l'injection).
Code ici:
https://drive.google.com/file/d/17LqBHq9...At6yCAiEaE
Exemple du valeurs retournées (routage sur un radiateur de 1500W qui ne consomme pas tout):
https://drive.google.com/file/d/1SOb3sI2...sp=sharing
On voit qu'en injection, les valeurs sont en "escalier" (car le courant est en valeurs entières).
Cela ne change pas la courbe bleue (puissance apparente)
Cordialement,
|
|
|
|
| Agrégation des heures de routage sur plusieurs actions |
|
Posté par : Ludovic35 - 01-11-2024, 04:51 PM - Forum : Evolutions faites, à faire, dont vous rêvez...
- Pas de réponse
|
|
Bonjour,
J'ai un CE triphasé que je pilote avec 2 SSR sur 2 actions différentes (Action1 sur 1400W et Action2 sur 1400W). D'autres le font avec une action sur 2 résistances, et la seconde action sur la 3éme résistance (car un gpio ne peut pas piloter directement 3 SSR).
Action2 est configurée pour ne s'activer que si Action1 est à plus de 70%. La durée de chauffe équivalente sur Action2 n'est donc pas corrélée à celle d'Action1.
Pour le complément de chauffe la nuit, je configure une action pour atteindre 6h équivalentes.
Les 2 actions chauffant le CE, j'aimerais pouvoir utiliser un compteur qui fait la somme des 2 actions pour déterminer si le complément de chauffe doit continuer ou non.
J'ai fait un ajout dans le code permettant cela.
La modification principale est dans la fonction InfoActionExterne() de RMS_Externes.ino
Pour les actions qui sont identifiées comme devant être regroupées, le calcul retourne simplement la somme des heures équivalentes des actions concernées.
if (actionTri > 0) {
LesActions[RMS_Datas_idx].ExtHequiv = 0;
for (int i = 0; i <= actionTri; i++) {
if ( LesActions[i].Actif > 0 ) {
LesActions[RMS_Datas_idx].ExtHequiv += int(PuissanceMax[i] * LesActions[i].H_Ouvre); //*100 dans PuissanceMax
}
}
} else {
LesActions[RMS_Datas_idx].ExtHequiv = int(100 * LesActions[SelectAction].H_Ouvre); //Duree heure decimale *100 action externe
}
Le groupe que je définis est l'ensemble des actions de 0 à actionTri (un booléen par action pourrait remplacer ce mode de sélection).
Et j'ai aussi ajouté un coefficient de pondération PuissanceMax[i] qui permet de retrouver une somme d'heure équivalente pour une valeur de charge unique (on peut mettre 200% sur l'action1 et 100% sur action2 pour indiquer que la charge est 2 fois plus élevée sur Action1 que sur Action2).
Les valeurs PuissanceMax[i], et actionTri sont passées via le titre de l'action. Là encore; cela pourrait se faire différemment.
Cordialement,
|
|
|
|
|
