Régulation solaire Nouvelle génération

Régulation solaire Nouvelle génération
26/04/2011

1 Quelques éléments
2 Hardware et plans
2.1 Structure générale
2.2 L'horloge et le DCF77
3 Touches pannel
3.1 Séquence appui des touches
3.2 Structure séquence CLA
4 La tables des messages et datas
5 Le cumul de l'énergie
5.1 Le volume (ou le débit)
5.2 Principe pour l'énergie
5.3 Principe de calcul d'une intégrale


6 Précision et calculs en 24 bits
7 Quelques réflexions fondamentales
8 Calculs de température
8.1 Calculs sur les températures en ELTS
8.2 Calculs des minis de température
8.3 Calculs des maxis de température
8.4 Calculs des moyennes de température
8.5 Températures de process
9 Calcul du débit primaire
10 Energie cumulée jour J
10.1 Puissance instantanée échangeur
10.2 Contrôle de l'inversion des échanges
11 Le pyranomètre à BPW34
12 Le principe de régulation
12.1 État des lieux
12.2 Le principe même de régulation
12.3 Mise en fonction de la pompe
12.4 La routine de surveillance
12.5 Conclusions sur le principe
13 La RS232
13.1 TX
13.2 Fonction radio TX (et RX)
13.3 Autres possibilités Radio
14 Conclusions et retour d'expérience
15 Explications des relevés "jour 2"
15.1 Les paramètres utilisés
15.2 Les différentes courbes
15.3 Le pyranomètre
15.4 La conclusion de ces essais
16 Les débits "câblés"

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

---

Avant propos

Ce texte a été élaboré tout au long de la construction et de la mise au point du programme de cette nouvelle régulation solaire afin d'oublier le moins possible d'éléments.
Si vous êtes novice en électronique et en programmation, ne vous éternisez pas sur la technique mais seulement sur les principes, car c'est un peu "indigeste" pour ceux qui n'ont pas quelques connaissances en électronique et programmation.

Lors de la relecture et des toutes dernières mises au point, le schéma général a été véritablement allégé, (L'ancien schéma est indiqué en rouge au paragraphe suivant) sans qu'il n'y ait plus de 4 à 5 fils supprimés et 2 ou 3 coupures à réaliser. Aussi l'ancienne version et la nouvelle cohabitent pratiquement sur la totalité.

Au niveau programme pas plus de 2 à 3 lignes sont touchées par cette dernière modif. Serait-ce une erreur ? Non mais seulement l'abandon d'une fonctionnalité inutile qui est la réception radio.
L'ensemble est donc plus simple, moins coûteux, mais nécessite autant de lignes de programme !

L'ordre de présentation de cet article n'est pas toujours le plus judicieux, car la reprise complète et ordonnée nécessiterait un travail assez lourd pour être un tant soit peu pédagogique, aussi l'indulgence est de mise.
Il y aura parfois quelques "redites", mais cela aura également l'avantage d'être mieux compris sur des pointsimportants.
Cet article paraîtra avant la mise au point finale et la mise en place définitive, mais un dernier paragraphe de "retour d'expérience" pour dire "comme les grands qui parlent du Japon"… sera ajouté et enrichi au fur et à mesure des problèmes rencontrés qui seront je l'espère peu nombreux.
Vous pourrez également faire les liens avec toute une série d'articles qui ont contribués à la finalité de cette régulation solaire de nouvelle génération.
Tous ces autres développements (thermomètres, pyranomètres, compteur d'eau primaire, mesures...) avaient été principalement réalisés dans cet objectif ultime de régulation solaire qui est l'aboutissement de l'ensemble de ces autres réalisations et articles.

Vous trouverez en premier lieu le principe général et la description de cette régulation solaire.

(En avant première sur le prochain article qui je l'espère sortira l'année prochaine et qui sera le pilotage du panneau solaire aux équations solaires, non plus avec un PC et en turbo Pascal comme c'est la cas aujourd'hui, (Économies d'énergie obligent) mais avec un PIC identique à celui utilisé ici et en assembleur…Il va falloir ruser pour les fonctions trigonométriques en assembleur PIC, et si certains ont des informations exceptionnelles sur le sujet, cela m'intéresse beaucoup).

Voici la liste des articles qui lient directement ou de façon très proche cette réalisation, avec les n° d'articles que vous retrouverez sur la page d'accueil : http://bricolsec.canalblog.com

72   Convertisseur radio RS232 sur 433.92 MHz (03/11/2010)
71   Photodiode utilisée en pyranomètre (BPW34) (08/10/2010)
69   Capteur pour compteur d'eau SCHLUMBERGER | ACTARIS (V2)
68   Pyranomètre à diodes pour mesures en solaire thermique.
66    Mesures sur un panneau solaire thermique (ECS)
64   Vannes à sphère, courbe angulaire de débit et actionneur
63   Sondes de température LM35 et diodes
2    Chauffage solaire de l'eau chaude sanitaire en poursuite du soleil

Nota : Quelques termes en Anglais sont dus au fait que c'est très souvent plus court et que cela s'affiche plus facilement au display LCD…Ce n'est donc pas pour faire joli ! Et en général je mélange allègrement Français et Anglais dans un "joyeux mix", désolé !
Au niveau alimentation la consommation du montage en 220V est en moyenne de 17 mA (avec les 3 relais excités). La puissance apparente moyenne consommée est donc de 3.74 VA que l'on peut ramener je pense sans se tromper beaucoup à 2 W de puissance active. (voir ces notions de puissances)

Les photos trop petites peuvent toutes être ouvertes dans nouvel onglet ou une nouvelle fenêtre et être agrandies. Je conseille de tirer plans et schéma sur papier pour ceux qui veulent s'atteler à comprendre ce qui est précisément réalisé.

1 Quelques éléments

Cette nouvelle régulation solaire de dernière génération a été nécessitée par ma première régulation d'origine (De 1982 et vieillissante, car ayant déjà subit un coup de foudre), et qui, comme les différents relevés effectués l'indiquent, peut être améliorée. (Voir l'article 66 déjà cité et les courbes de fonctionnement)

Ce renouvellement inclut les progrès technologiques qui n'existaient pas à l'époque des années 80.

En effet il n'y avait pas de PIC en 1982 (C'était l'époque des premiers IBM PC AT....).
Depuis, ceux-ci sont apparus (Aussi appelés RISC) et j'ai pu y consacrer un peu de mon temps seulement très récemment.
Toujours un peu débutant sur les PIC, il n'est pas un jour que je ne découvre quelque point particulier ayant échappé à ma vigilance, mais ce qui me surprend toujours, c'est l'extrême insensibilité aux parasites de ces composants.

Quand on a pratiqué la TTL et toutes les technologies avec les bus accessibles, on est réellement surpris d'une absence totale de parasites…Il faut dire que les bus internes sont si petits qu'ils ne peuvent recevoir aucun signal électromagnétique tangible.
Les PIC me surprennent toujours et principalement l'assembleur qui reste mon langage préféré bien que plus difficile à manier qu'un Pascal, du C  ou du Basic, le Simulateur est suffisamment bien fait pour s'en sortir, parfois avec une petite "bidouille" pour les cas où c'est bon au simulateur mais que ça "accroche" au réel.

(Encore merci à BIGONOFF pour son document de base à partir duquel j'ai fait mon apprentissage des  PIC !)

En ce qui concerne le "hardware", il n'y a rien de très particulier à dire, sinon qu'il utilise des mini cartes déjà exposées dans les articles indiqués.
Le cœur du sujet précis est donc essentiellement une alimentation associée à un "fond de panier" comprenant quelques relais et composants communs (Mini backpanel).

Une seule carte principale comportant le PIC 16F886, un ULN2804, un MAX 232 (Et un 4016 maintenant disparu : photo carte principale au paragraphe suivant) est le cœur du montage. Il y a aussi le petit récepteur DCF77 (acheté) et le module d'émission radio (le module de réception radio a été retiré).

Les principaux éléments de description sont les suivants :
Régulation solaire ayant 4 capteurs de température dédiés au process et un capteur de température extérieure.
Il y a aussi un capteur d'impulsions de compteur d'eau ainsi qu'un pyranomètre.
Un afficheur LCD et 3 touches permettent de visualiser et de paramétrer les différentes constantes du circuit.
Pour l'analyse précise de chaque installation, une collecte des principales données numérisées et digitales peut être transmise par la RS232 et/ou par radio. Ce point est important car on peut assimiler cela à un datalogger intégré. Cette possibilité permettra la mise au point sur site mais aussi le suivi régulier et précis des performances. (Chaque changement logique donne également lieu à une trame RS232)
L'ensemble fonctionne en interruptions et scanning très rapide, (même en modification des paramètres).

2 Hardware et plans

2.1 Structure générale

Les plans sont décrits ci après, et ne posent aucune difficulté.

Dans ce genre de montage, c'est le programme, le cœur réel du fonctionnement. Je présente le premier schéma de cette réalisation qui est abandonné et juste à la suite, le nouveau, beaucoup plus simple...
L'horloge utilisée est celle du quartz interne du PIC 16F886 à 8 MHZ. Aussi les entrées RA6 et RA7 sont utilisées à d'autres fins.
L'organisation avec les E/S a été vue également pour faciliter la programmation en assembleur (Je pense par exemple à la lecture de toutes les entrées analogiques en séquence (Sauf la température extérieure qui est lue en permanence, même la nuit à cause des mini et maxi)

Cette partie météorologique n'est pas essentielle mais m'est nécessaire pour d'autres raisons et son emplacement dans la régulation solaire n'est pas anachronique, c'est un "petit plus" qui ne dérange pas...
L'alimentation des capteurs de température "process", est permanente de jour.
Par opposition, la nuit cette alimentation est coupée pour de minuscules économies d'énergie.
Cela n'a pas été fait de jour pour ne pas perdre de temps supplémentaire à attendre la stabilisation de la tension d'alimentation des thermomètres, mais les courants sont très faibles et ne perturbent pas les mesures.
De jour, autant les performances énergétiques sont seulement enregistrées toutes les minutes, autant la surveillance des deltas de température au niveau échangeur du cumulus est permanente. C'est même la raison principale pour ne pas couper l'alimentation des thermomètres à cause de cette surveillance.

La majeure partie des entrées de données est réalisée en interruptions. Ceci concerne les 3 switchs, le compteur de débit ACTA, la RS232 (Rx) et TX. La mesure des températures, nécessitant quelques délais d'acquisition n'est pas traitée ainsi, mais simplement en scanning groupé. Les délais constructeur du PIC 16F886 ont étés largement réduits par rapport à ceux des PIC 16F877 par exemple, et la gestion en interrupts n'apporterait pratiquement aucun gain réel de temps.

La gestion des compteurs horaires de pompe est également traitée intégralement en interruption directement.

Le débit du compteur est lui aussi traité en interruptions, sans oublier les "tops" horaires pour les secondes, les minutes, les heures, les jours, les semaines et les années.

La RS232 qui n'est pas active de façon normale est maintenant commandée directement au panel par le switch à glissière, et la partie radio TX est commandée séparément par paramétrage au panel (Émission). Ceci est fait pour éviter les perturbations à 433.92 MHz qui pourraient gêner d'autres appareils. 
La réception radio initialement montée est totalement abandonnée ainsi qu'il a été dit, car d'aucune utilité et de mauvaise qualité de plus. (La liaison réception RS232 RX a cependant été conservée, mais elle n'est pas utilisée. La partie interrupt correspondante a été laissée en place).

Ma décision finale est donc de lire le switch à glissière et d'effectuer la préparation du buffer TX en conséquence.
La mise sous tension de la fonction émission radio par le paramètre Param_11 est accessible au panel. Quant à la réception radio, je l'abandonne purement et simplement.

Le CMOS 4016 n'a donc plus aucune utilité, et il est retiré de son support.

Pour éviter toute consommation inutile, R4 et R5 seront également retirées. Pour rétablir une éventuelle utilisation RX en RS232 la liaison RX et MAX232 sera simplement rétablie en direct mais ne servira pas dans ce projet.

NOTA : J'avais dans un premier temps alimenté le MAX232 par le switch à glissière, mais j'avais fait quelques erreurs de modifications et j'ai donc corrigé plusieurs choses à la fois. Des fils n'étaient pas correctement connectés car la  LED RX/TX ne fonctionnait qu'avec TX et était allumée en plein si RS232.
Le condensateur aux bornes du MAX232 étant de 1 µF comme ceux de pompage, je l'ai augmenté à 6.8µF.
Le problème de la LED RX est donc résolu mais finalement ne sert à rien puisque RX n'est pas utilisé, mais je préfère que cela soit "clean", car on se fait souvent des oublis et parfois on trébuche dans le tapis....Alors j'ai rétabli l'alimentation du MAX232 permanente pour 4 milliwatts !

Voici la réalisation de la carte principale (ci-dessus).
On y distingue à gauche le récepteur DCF77, au centre le PIC 28 pins, puis l'ULN2804, et enfin au même niveau le rectangle blanc qui est l'émetteur RT4 (sur céramique) et juste en dessous le MAX232.

(Au besoin, en cas de nécessité, le port RC7 du PIC (RX) pourra être récupéré à d'autres fins).

Une autre particularité est d'utiliser un des fils du module LCD pour commander en même temps une LED. Ceci est dû à un manque d'entrées sorties et cela nécessite une petite gymnastique programme, ordonnée, pour à la fois travailler avec le module LCD et allumer ou non la LED…
Mais c'est une bonne solution quand on a rien d'autre, et les faibles durées LCD conjuguées à la persistance rétinienne font largement le travail de discernement.

Au niveau LCD, le signal de lecture/écriture R/W a bien entendu été abandonné d'origine faute de pouvoir le commander, par un port du PIC à cause du manque d'E/S. L'afficheur a donc son signal W validé en permanence. Tout est donc basé sur le respect des temps d'accès, en interface 4 bits.
Et ma foi, ça se passe bien, sans problèmes particuliers.

Un délai de 50 µS à chaque écriture de data de 8 bits est respecté, et 2 µS entre les quartets. Les autres commandes (Clearet home) sont traitées spécifiquement, car elles nécessitent des délais plus importants.
Ce mode de fonctionnement sans R/W a au moins un avantage, il ne bloque pas le programme sur attente "not Ready" et permet de "suivre" les datas directement avec le simulateur sans réaliser de commande debbug.

Une seule commande est en fonction barre, c'est l'alimentation des capteurs de température, le capteur compteur et le Pyranomètre.
Toutes les autres sont en logique positive bufferisés par un ULN2804 (8 transistors).

ATTENTION à ne pas raccorder le VCC de ce circuit (commun des diodes anti-retour), ni au VCC, ni au +12V, car les ULN commandent à la fois du +5 et du +12V, et il ne faut pas créer de court-circuit d'alimentation !!!!!
(J'y suis passé par l'habitude de connecter le VCC d'un CI, mais je n'avais cependant pas oublié des diodes externes plus "solides" qui doivent être raccordées soit au +5 soit au +12 V!)
(Le 4016 assurait le multiplexage radio ou RS232 RX direct. Il est donc supprimé car son rôle était d'aiguiller soit la prise DB9, soit la réception radio vers l'entrée RX du PIC).

Un transistor Q1 assure la visu (RX) ou TX, mais il doit rester à cause du RX non utilisé mais raccordé directement au MAX232.
RB7 assure la lecture du switch à glissière d'alimentation du MAX232. Ce switch assurait en même temps l'alimentation du seul récepteur. Vu l'abandon de RX, ce switch est maintenant seulement lu et le choix radio ou non est alors uniquement fait par le paramètre PARAM_11…
L'analyse par programme de l'état de l'entrée RB7 résulte en une commande de la sortie RA6 d'alimentation de l'émetteur.
Tout arrêt RS232 par le switch à glissière remet automatiquement le paramètre radio à "N".

L'ensemble est donc assez simple, et les liaisons entre le back panel et la carte processeur sont réalisées par des petites nappes de 2x5 broches (Je n'avais que cela, mais on peut largement faire mieux).

Voir la feuille OPEN OFFICE CALC ci-dessus qui définit les E/S et comporte toute une série d'informations utiles. Cette feuille sert réellement de base à la programmation assembleur, surtout dans la partie des définitions avec les #define ou des macros. C'est réellement la "feuille de route" pour la vérification du "hard" et la mise au point.

Je n'ai pas mentionné le petit CI fixé au panel qui reçoit les 3 switchs, le switch à glissière et 5 LED.
Une LED "PUMP" très lumineuse est à droite ainsi qu'une LED de présence tension 6V~. Le schéma est ci-contre.

2.2 L'horloge et le DCF77

L'horloge du PIC est assurée par les fonctionnalités internes au PIC, à savoir l'horloge à 8 Mhz. Avec cette fréquence il n'est pas possible d'avoir des divisions exactes du temps en secondes. J'ai donc repris le principe du simulateur de présence (voir cet article ne faisant pas directement partie du sujet principal).
Cette fréquence de base permet néanmoins une transmission à 2400 bps avec une erreur de fréquence de 0.16%
Le registre TMR0 est chargé avec la valeur la plus petite de temps qui peut s'inscrire avant dépassement de la prochaine valeur. La valeur -156 correspond à cette définition. Le petit écart de temps manquant est alors ajouté sous forme d'instructions de très léger ajustement avant la réécriture du registre TMR0 qui remet aussi à zéro le pré diviseur, ce dernier point est essentiel pour assurer la précision.

Il aurait peut-être été plus simple d'ajuster le temps avec OSCTUNE, mais j'avais préféré m'en passer pour éventuellement pouvoir réutiliser des PIC ne possédant pas cette fonctionnalité, qui en l'absence d'expérience ne permettrait peut-être pas la précision requise, car quelques % de variation sont trop importants…
Mon copain "Riri" avait mesuré 0.8% à chaque pas OSCTUNE ce qui devrait donner 2.7 secondes par jour avec pré diviseur à 256 (j'avais oublié de diviser aussi par le pré diviseur) mais c'est réalisé autrement et ça fonctionne aussi très bien ! J'essayerai une autre fois OSCTUNE!

De plus je n'ai besoin de précision que sur 24 heures, car la mise à l'heure par le DCF77 sera réalisée tous les jours à 4 heures du matin et lorsque les informations éventuelles de changement d'horaire seront déjà appliquées.
Cette opération restera donc invisible dans les résultats du process, mais je ne sais pas éviter de façon simple une double mesure ou une absence…(Il est très difficile de jouer avec le temps !) Le DCF77 permet donc de ne pas se soucier des problèmes de changement d'heures, ni des jours de la semaine, et donne une excellente précision journalière de l'heure.
Ceci évitera aux jours du mois de passer à 32 ou d'être faux (Ce sera tout de même le cas seulement durant un très court instant !) Bref le calendrier est géré par le DCF77 et si vous dormez comme je le suppose, vous n'y aurez rien vu ....

La partie de mise à jour des "jours", mois et années n'est pas traitée directement en interrupt mais dans la boucle principale au top des jours. (TOPJOUREX)

Une petite différence de présentation de la fonctionnalité DCF77 avec les autres montages est dans la connexion d'un timer et l'attente d'un front montant ET d'un front descendant. 
Si au terme de 15 secondes ce résultat n'est pas présent, on considèrera que le DCF77 est absent ou ne fonctionne pas.
Deuxième évolution, au lieu d'allumer des LED (inexistantes ici) j'ai utilisé le LCD pour visualiser les 1 et 0 de la trame DCF qui défile les groupes d'informations horaires. Différentes sorties d'erreur confirment chaque problème par un chiffre >1 ou une lettre, et la LED ERR s'allume en dynamique sur parité.
Cette petite évolution est intéressante car cette réception pose souvent des problèmes et on ne sait jamais si ça marche correctement ou non suivant les emplacements et orientations. 
;
; Retours erreurs
;
DCF_2 2 init incomplète
DCF_3 3 erreur synchro   
DCF_4 4 Seconde supprimée en bit 19
DCF_5 5 Basculement été/hiver
DCF_6 6 Erreur STORBIT minutes
DCF_7 7 Erreurs conversion + parité minutes
DCF_8 8 Erreur Minutes hors limites
DCF_9 9 Erreuur STORBIT heures
DCF_A A Erreur conversion + parité heures
DCF_B B Erreur heures hors limites
DCF_C C Erreur Jour de la semaine hors limites
DCF_D D Erreur Mois hors limite
DCF_E E Erreur STORBIT Année

Au final j'ai ajouté un menu d'introduction de date pour ceux qui n'auraient pas de DCF77. Cela m'aidera aussi pour faire les essais de basculements de données sur les "éléments-1".
Sans tout casser la structure, j'ai été obligé de "coller" tous les éléments de date à la suite faute de place possible. C'est un peu moins "luxueux" que les autres paramètres, mais ça fonctionne.

3 Touches pannel

3.1 Séquence appui des touches

Cette séquence est basée sur l'horloge interne cadencée à 8 Mhz avec interruptions au pas de 20 ms (Prescaler à 256 sans Watchdog). Cela ne concerne que les 3 touches. Seul l'appui est mémorisé dans l'octet "Bit_SW1" en valeur logique positive (Bien que l'appui de touche réalise une mise à zéro).
Le registre interne du PIC, WPUB est utilisé pour les résistances de rappel avec RBPU.

Le reset correspondant sera réalisé par la séquence utilisatrice, lors du scan général.
En même temps que l'appui sur une touche, un timer est lancé pour un délai de 800 ms définissant un appui long.
Le compteur/timer est au pas de 20 ms et porte le nom de C20ms4. Ce compteur est chargé en valeurs positives qui sont décrémentées toutes les 20ms. une fois le zéro atteint, le compteur se bloque.
(Ce principe de l'auto-blocage est très utile car il permet de renseigner même après le temps passé).

La caractéristique d'une touche longue est de voir une touche encore à 0 et le timer C20ms4 à zéro, car le timer est toujours lancé à la mise à 0 d'une touche (appui). Il ne peut y avoir deux touches ensembles. C'est la précédence de recherche programme des touches qui assure la touche choisie.

Au delà de 800mS, un indicateur d'appui long sera positionné et devra être remis à zéro par la séquence utilisatrice. Il faut de toutes façons attendre la retombée à 0 de C20ms4 pour conclure en regardant si la touche PORTB correspondante au Bit_SW1 est toujours à 0.
La seule touche SWVAL aura cette possibilité d'appui long. Un appui court fera changer le type de mesure et un appui long validera parallèlement l'entrée en modification d'un paramètre.

L'appui long est donc reconnu seulement au relâché de la touche.

La mémorisation dans l'octet Bit_SW1 est utile car tout appui sera toujours traité, même si il a disparu du PORTB. Ceci évite largement de se soucier des éventuels rebonds de touche ainsi que de la longueur du cycle de la boucle principale.
On regardera donc le bit_SW1 ayant été positionné puis on lira le PORTB correspondant et on regardera ensuite l'état de C20ms4. S'il est à 1 c'est un appui court. S'il est à 0 c'est un appui long !

Les séquences ci-dessous sont en logique positive pour l'explication, mais la réalité est l'inverse.
              _________
_______I                I___________  touche réelle portB (appui court)
              __________
_______I                   I___________________  Timer à 800 ms
              __________________
_______I                                  I_________  Bit_SW1 (appui long)

Le prolongement d'un appui ne sera pas gênant puisque le passage logique de 1 à 0 (front arrière) n'est pas recherché et que SW1 aura été remis 0 par la séquence de demande de données.

Une fonctionnalité prévue au départ mais laissée "sur le bas côté", était un fonctionnement suivant un paramétrage de base avec prise en compte des touches au moment de la mise sous tension de l'appareil.
La prise en compte des switchs à la MST est toujours réalisée (Start_Mod), mais n'est plus exploitée du fait qu'un nombre important de paramètres sont modifiables par les touches (En association avec l'afficheur LCD).

3.2 Structure séquence CLA

La séquence CLA est une très importante partie qui sera en mesure de faire défiler toutes les valeurs de résultats à l'écran par l'appui sur les 3 touches panel et d'afficher les valeurs demandées, mais aussi de modifier les paramètres. Dans ce cas le test de durée des appuis ne servira qu'à changer de type et ne portera toujours que sur la seule touche SWVAL.
Le message sera affiché préalablement avec l'heure et le curseur du display LCD sera pré positionné en adresse 8 de la ligne 2 pour recevoir la valeur numérique.
Updt1 est l'entrée de 1 à 3 digits numériques ou 1 à 2 caractères à l'aide des 3 touches.
Le message sera affiché en ligne 1 et la réponse en ligne 2 avec l'heure HH:MM:SS.
Chaque digit sera entré et validé individuellement. La conversion du digit sera faite en comparaison de la valeur affichée depuis les PF jusqu'à la fin.
La valeur 5 est choisie comme valeur médiane limitant les appuis sur + ou -.
La séquence comprendra aussi les appels à l'affichage de l'entrée des appuis de touches.

4 La tables des messages et datas

Cette table pointe à la fois sur les messages à afficher et sur les datas correspondants.
Il y a 3 bytes par entrée de table.

Cette table multiple est sur un seul module de 1K, et les tables des messages sont réparties sur 3 zones de 256 pour être traitées en RETLW (ou dt).

L'ordre est celui défini à la fois pour la facilité de programmation et pour la facilité d'exploitation des résultats et des  paramètres visualisés  sur l'afficheur, mais était aussi nécessité par la sauvegarde en EEPROM de la totalité des valeurs.

Aucun indicateur ne le précise et seul le nombre est déterminé depuis l'adresse 110 de la bank2. A ce jour tout est sauvegardé en EEPROM. Les adresses de BANK 2 et d'EEPROM étant identiques, les transferts sont très simples.
Initialement seule une partie des données était sauvegardée, mais au final rien n'empêchait de tout sauvegarder, d'autant qu'il y a largement de place en EEPROM, et c'est ce qui a été fait et qui permet ainsi un historique important.

La position dans cette table permet de l'indexer au premier niveau et d'en déduire ensuite les zones et les index dans chaque zone de 256.
Cet index primaire est donc représenté directement par la position en mémoire programme. Il va de 0 à 41. Un autre index constitué de "Type et Zone" pointe les messages associés, et les caractéristiques Zone mémoire de 256 pour les messages, les formats d'affichage et le nombre de caractères nécessités par chaque valeur.
(Quelques paramètres complémentaires de régulation sont également ajoutés en fin de table)

Chaque zone de 256 comprend 14 messages numérotés de 0 à13, de 16 caractères, y compris la dernière zone consacrée aux paramètres qui est en lecture écriture.

Il n'a pas été judicieux de scinder les messages en deux, (Malgré un entête souvent commun), car le gain de place en mémoire programme aurait été très faible et la complexité de la table encore augmentée.

Un cas particulier concerne le Start_Mod qui déterminait le mode fonctionnement suivant l'équipement. Si au moins un switch à la MST a été positionné, le "Start_mod" est recopié et sera réécrit chaque jour. De même toute modification des paramètres sera toujours recopiée en EEPROM (Une recopie toutes les 24 heures seulement ou à la demande -pour sauver un historique par exemple-).
Le "Start_Mod" avec la modification possible de beaucoup de paramètres offre maintenant peu d'intérêt, mais il a cependant été gardé, mais n'a aucune utilisation à ce jour. (On verra par la suite)

Cette table est compliquée dans sa réalisation assembleur et elle reste DANGEREUSE car en cas de modification, il y a risque de pouvoir introduire des doublons, mais les contraintes d'exploitation sont importantes et il fallait un index primaire, un index secondaire, et une navigation par seulement 3 touches avec navigation par thèmes (Au nombre de 8).
Il faut aussi pouvoir pointer les valeurs à afficher dont une est une intégrale des valeurs, et la longueur de chaque élément pointé est variable. Enfin il faut pouvoir sauver ce qui doit aller en EEPROM (historique) en une seule opération.
Le droit d'écrire ou non un paramètre peut agrémenter les possibilités, mais surtout indiquer le format d'affichage au display. (Ceci figure en bas de la table avec les 3 octets de tables de chacune des entrées)

Chaque élément est si particulier à cause des unités et des calculs en entiers que les deux bits restants du format d'affichage seront utilisés pour le positionnement du point décimal à l'affichage.
Cette facilité est très pratique pour pouvoir AFFICHER des valeurs décimales à partir d'entiers.

La table permet donc l'accès aux messages d'informations chiffrées, mais aussi aux paramètres. Elle est compliquée et difficile à appréhender.
Les adresses de BANK et les longueurs de chaque entrée on été une première fois vérifiées par un programme, mais les modifications incessantes suite à des problèmes de calculs m'ont amené à chercher comment calculer en hexaavec OPEN_OFFICE, et c'est là qu'Internet est précieux, car je me suis aperçu que c'est possible (et je ne le savais pas) avec les fonctions DECHEX() et HEXDEC().
Cela a également été appliqué au niveau MPASM en utilisant cette fois les calculs d'adresses et les opérations logiques dans les expressions "dt" grâce aux pseudos instructions EQU.

Chaque zone de Constantes en mémoire programme (RETLW ou plus facilement "dt") est limitée au nombre de 3, c'est-à-dire à 3 modules de 256 octets soit 42 messages maximum. On notera que 2 bits sont utilisés pour les Zones (de 256), et 42 messages avec datas sauvegardés en EEPROM (0 à 41).

Vu les différentes difficultés en frontière de pages mémoire, chaque zone débutera en adresse exacte à 0 avec la addwf  PCL,f à cette même adresse. On ne pourra donc stocker que 15 messages au maximum de 16 caractères, pourtant on n'en stockera que 14 pour garder un peu de place pour d'éventuels ajouts.

Cette table peut être utilisée en index général, mais ce ne sera pas le cas sauf pour lecture écriture EEPROM et le scan des types (appui SWVAL). En effet à l'aide des touches, elle est le plus souvent balayée en totalité très rapidement. Elle peut surtout être examinée séquentiellement, par Type avec la touche SWVAL, et DANS le type par les touches gauche et droite SW- et SW+ qui permettront la rotation complète des affichages sur le type choisi par balayage de la totalité de la table pour le type.

Les types sont les suivants :
0 Température Extérieure min max et historiques
1 Température niveau process solaire et extérieure instantanée
2 Énergies en WH et KWH
3 Puissances en watts
4 Débit primaire en L/mn
5 Pompe (Nb de démarrages et heures de fonctionnement)
6 Divers (Delta calculé au niveau échangeur)
7 Paramètres de configuration

Voir le tableau CALC  qui résume toutes ces particularités

Attention à une particularité des valeurs affichées et des valeurs mémoire. En effet toutes les valeurs en mémoire sont élaborées au plus juste pour une bonne précision et dans des unités qui ne sont pas celles affichées au display. La table permet de positionner correctement la virgule au display.
Cette façon de faire fonctionne parfaitement et n'affecte que le display. En effet au niveau des calculs internes tout est réalisé en 24, (voire parfois en 32 bits) sur la base des seules valeurs mesurées en 1/1024 ou dans des unités adaptées pour la précision.
Dans le tableau REGULSOL3.ODS, une colonne explicative "Unités Mem" indique les unités manipulées en mémoire pour pouvoir les afficher correctement.
On peut ainsi voir que suivant les quantités cumulées par résultat, les unités mémoire changent et on passe ainsi des centi wattheures au kilo wattheure avec les intermédiaires Wattheures et Déca wattheures, mais les affichages au LCD, resteront en WH ou KWH par exemple.

Enfin un bit read/write fera partie de la table pour autoriser ou non l'écriture de valeurs dans les paramètres. L'écriture des valeurs mesurées n'est pas acceptée. On se proposera de valider la modification ou l'entrée d'une valeur de paramètre à partir d'un appui long sur SWVAL. Dans le cas d'une lecture seule indiquée par la table, l'appui long ne sera pas pris en compte. (Ce bit n'est pas utilisé pour l'instant)

J'ai pensé à introduire un code d'accès aux paramètres, mais comme c'est pour mon seul usage, c'est resté de côté, mais c'est tout à fait possible de l'implémenter.

Une fonction Affich_D (Affichage Direct) prendra donc les données dans la mémoire programme et les transfèrera DIRECTEMENT sur le display SANS passer par le tampon BUF_Disp.
C'est un gain de temps et une libération du temps nécessaire à ce transfert. Ceci est possible bien entendu pour les corps de messages qui sont fixes, mais impossible sans bufferiser pour la modification des paramètres (surtout à cause de l'impossibilité de relire le display LCD).

La feuille REGULSOL3.ODS est une réelle nécessité pour comprendre les imbrications diverses et tous les éléments liés de cette table assez compliquée.

Pour Temp_2 (à 3 octets), la moyenne est exprimée sur 2 octets et le 3ème octet est le nombre de mesures (voir explications ci-après pour l'intégration)

5 Le cumul de l'énergie

5.1 Le volume (ou le débit)

Volume durant un temps donné ou débit…c'est la même chose !
En effet pour le calcul d'énergie on utilisera un delta d'UNE minute. C'est-à-dire que le débit exprimé en L/mn représentera le volume de référence dans la formule de l'énergie !
Bien remarquer que nous traitons des L/mn, mais que c'est en réalité toujours un VOLUME de 1 litre  dont on mesure précisément le temps de passage et donc que la confusion est vite réalisée et qu'il ne faut surtout pas vouloir homogénéiser les unités !
Pour plus de précision la mesure du temps sera réalisée à la demi seconde, ce qui permettra également de rester dans des valeurs exprimables sous 8 bits.

5.2  Principe pour l'énergie

L'énergie solaire n'étant pas constante tout au long de la journée, il est nécessaire d'utiliser de petits écarts de temps et de réaliser la somme de ces minis éléments d'énergie. Pas de calcul intégral théorique, mais un principe simple du cumul d'énergie par petits intervalles d'une minute.

Le principe que j'ai retenu et qui est un compromis entre la folie et le laxisme consiste à mesurer toutes les minutes suivant la formule déjà utilisée dans les autres articles, et qui est :

E (WH)=1.16*Volume(L)*Delta température (°C)

En réalité la formule va se réaliser en entiers suivant un scénario particulier qui permettra de préserver les décimales qui seront toujours perdues lors des divisions. Le but est de limiter au maximum les divisions qui génèrent des pertes de précision par l'abandon du reste. Il faut également se définir des limites qui vont nécessairement simplifier largement les calculs.

Dans cet aspect immédiatement applicable au premier groupe de valeurs, on se limitera en valeur basse à des temps de mesure de 255 ½ secondes, soit un volume 0.47 L/mn ou 47 cl/mn et 28 L/H.
En limite haute ce sera pour ne pas dépasser 8 bits en valeur de DEBIT/Volume soit 12000/255=47 demi secondes représentant :2.55L/mn ou 255cl/mn ou 153 L/H.
(NOTA : sans préjuger des possibilités réelles du circuit primaire, j'avais pensé pouvoir aller jusqu'à 250 L/H (4.1L/mn)…l'expérience réelle m'a donné un débit maxi de seulement 153 L/H à cause des pertes de charge du circuit !)

Il aurait été possible d'envisager le groupement avec la constante "116" de la formule, mais cela correspond à l'énergie alors que nous devrons aussi faire le stockage pour l'affichage, alors on fera les calculs séparément, tant pis ! On notera encore que ce résultat INTERMÉDIAIRE de l'énergie n'est pas signéet qu'il sera donc toujours positif. Le mouvement d'eau est théoriquement impossible en arrière à cause du sens de la pompe mais aussi du clapet anti-retour pratiquement toujours présent, donc il sera toujours positif.
(Dans cette nouvelle régulation, on pourrait presque se passer du clapet grâce à la vanne de réglage du débit, mais….je préfère la sécurité !)

Voyons maintenant le facteur écart de température. Il s'agit bien entendu de l'écart de température au niveau échangeur, c'est-à-dire EC/EF
L'écart de température est le suivant (125*(x1-x2))/1024 avec pour x1 et x2 des valeurs ELTS du convertisseur 10 bits. Si on multiplie par 1250 au lieu de 125 nous aurons donc le 1/10 de degré ou approximatif. La formule de l'écart de température  en1/10 de degrés est donc
DELTA T=1250(x1-x2)/1024
On se rappellera que 125 est l'étendue de mesure des sondes de température. En nombre de bits cela donne donc : 16*16=32 bits à diviser par 1024.
Or le calcul en 32 bits ne devait pas être abordé,...mais il l'est pourtant par le bais d'un division par 1024 qui est très facile puisque l'on décale de 10 bits à droite c.a.d que l'on "oublie" l'octet de poids faible et l'on décale tout le reste de 2 bits à droite. Il reste alors un nombre sur 22 bits…..(soit 24 bits pratiquement)
(Le final des calculs sur la formule de l'énergie nécessitera tout de même hélas, un calcul en 32 bits pour retrouver cette fois des unités de mesures adaptées.)

Pour les températures, ceci donne finalement un résultat sur 24 bits, mais le maximum étant de 1250, on pourra supprimer également l'octet de poids fort qui doit normalement être à zéro.

Parallèlement on gardera le signe dans un "petit coin" car le delta de température pourrait peut être, être NÉGATIF. On remarquera que l'on ne dépassera jamais la valeur de 1250 qui correspondra à l'EM.

Ce résultat partiel (Delta de température) est à multiplier par le premier résultat lui aussi en 16 bits.

Le volume pourra légèrement varier suivant la position de la vanne de régulation, et je me suis posé la question de savoir si je voulais prendre cette partie de débit variable en compte...

Après analyse des chiffres réels et des précisions maximales en calcul en 24 bits (voir ci-après), je pense que ce serait un peu comme un coup d'épée dans l'eau. Alors on considèrera le débit comme celui mesuré au compteur ou celui pré-établi pour ceux qui n'auront pas de vanne.
De plus le delta de température est nécessairement entaché d'une incertitude non négligeable et que pour quelques minutes à vitesse rapide ou réduite, "le jeu n'en vaut pas la chandelle". (Même s'il me reste un peu de place en mémoire programme je pense que je n'irai pas jusque là).
Une deuxième incertitude vient entacher ces résultats qui sont le cumul d'éléments de faible précision pour ne pas dépasser les limites d'entiers sur 16 bits. (volume principalement)

En réalité cela va réellement "se débrouiller", car la mesure du débit est faite par interruptions, mais l'application du résultat à l'énergie peut être différée d'une ou plusieurs minutes. En bref, il y aura une certaine pondération, sans que l'on puisse réellement donner une règle très précise (c'est du temps réel, et il n'est pas possible de synchroniser le compteur avec les minutes !).

5.3 Principe de calcul d'une intégrale

Le principe pour obtenir une intégration sans garder toutes les valeurs est le suivant :

On calcule la moyenne du nombre d'éléments considérés. Lors de l'ajout d'un élément on procède ainsi:

On effectue en premier le produit de la précédente valeur moyenne par le nombre d'éléments. On ajoute ensuite le dernier élément à cette somme, et on divise ensuite par le nouveau nombre d'éléments, c'est-à-dire avec +1.
Il y a donc deux nombres attachés à une intégration, la valeur moyenne déjà calculée et le nombre d'éléments déjà mesurés.
Ce principe revient à calculer la surface d'un rectangle moyen pour un nombre "n" d'éléments de mesure. Pour intégrer un nouvel élément, on multiplie cette valeur moyenne par "n", à laquelle on ajoute la nouvelle valeur. On divise ensuite cette dernière par "n+1".

Cette opération est alors reconduite suivant la finesse des intégrations désirées.
Pourtant, plus le nombre d'éléments est élevé, plus la précision va décroître dans le contexte des microcontrôleurs avec calculs en entiers.

Exemple:
Supposons une valeur moyenne quelconque d'intégration de 967.00 W par exemple, pour 345 mesures. Une nouvelle mesure de 970 W vient s'ajouter. Quelle est la nouvelle intégrale de puissance après cette période ?

967 * 345=333615  à ajouter à 970 W  ----> 334585.
Cette somme correspond donc maintenant à 346 mesures et donne une énergie intégrée de :967.0086 WH.
Avec 2 décimales, on voit parfaitement que cette nouvelle valeur sera identique à la précédente si l'on n'utilise que 5 chiffres significatifs

On constate que la dernière mesure n'a apporté que très peu de modification à l'intégration, car la valeur (avec en plus  la précision de quelques %) ne donne rien de réellement différent à la surface mathématique développée. En effet le nombre d'éléments est élevé, chaque mesure intervient pour un coefficient très faible.
(Une valeur nulle de la dernière mesure aurait tout de même fait chuter à 964.205 la valeur de l'intégrale).

Initialement je me suis fourvoyé en pensant que l'énergie allait être une intégrale…C'est seulement en commençant les lignes de programme que je me suis aperçu que c'était un simple cumul au rythme des minutes.
Il n'y a donc pas à "traîner" le nombre d'éléments ayant participé ! Le mal est fait car j'avais réservé 2 octets de trop en table et après avoir eu peur de rectifier la table, je m'y suis tout de même résolu et la structure automatique de calcul d'adresses en fonction du nombre d'octets de chaque valeur a rendu parfaitement service sans problèmes réels.
Cela m'a permis au contraire de rectifier des réservations de datas en BANK2 que j'avais oubliées de reporter en EEPROM.
Pourtant il y a bien une intégrale nécessaire, mais qui correspond cette fois à la température moyenne qui sera prise toutes les heures (Suivant les habitudes les plus fines en vigueur).
(Pour les minima et maxima, le scan sera permanent sans attendre la minute juste -et sans intégration-)

6 Précision et calculs en 24 bits

Chaque terme de la formule de base de l'énergie avec valeurs en nombres réels doit donc être multipliée autant de fois par 10 pour obtenir des entiers. Il faudra ensuite diviser par autant de puissances de 10 pour retrouver une valeur correcte.

E (WH) = 1.16*Volume en litres*Delta de température en °C

J'avais (presque) abandonné l'idée de calculer en 32 bitspour seulement le cumul en WH journalier. Ce sera donc seulement en 24 bits soit un comptage maxi de 16 777 214 non signé.
Il y a pourtant des multiplications 16x16 dont la valeur finale est plus faible que le total autorisé en 24 bits, mais les séquences 16x16 sont toujours sur 32 bits…!

Mais si j'ai calé sur quelques opérations en 32 bits, c'est pour mieux diviser par 1024 en "oubliant" un octet de poids faible et en décalant de 2 bits le résultat final, ce qui fait exactement 1024 ! On peut ainsi continuer en 24 bits !...Sauf pour la dernière opération de division par 1000 qui sera en 32 bits !

Je n'ai malheureusement pas pu échapper à cette dernière division 32 bits par 1000 pour obtenir les CWH (centiwattheures affichés en WH au display)

Il faut dès à présent bien garder à l'esprit le calcul pur en évitant les arrondis intermédiaires et les stockages mémoire ou affichages display qui peuvent être tronqués. Il faut donc évaluer l'unité de représentation d'une valeur en mémoire, son affichage, la facilité des calculs, mais aussi la précision.

Pour chaque calcul on travaillera le plus souvent sur 24 bits au maximum, car les valeurs décimales seront multipliées de façon à ne retrouver que des entiers en opérations (Pas de calcul en nombres réels)
Il faut également prendre en compte le stockage en mémoire de ces valeurs, et il n'y a pas beaucoup de place alors pour chaque valeur, on se limitera donc à des entiers de 16 ou 24 bits. (La colonne Nb du tableau REGULSOL3.ODS indique le nombre d'octets utilisés pour le stockage des valeurs de DATAS)

(Limite numérique pour 24 bits non signés = 16 777 216)

En réalité, j'ai du revenir sur les calculs en 24 bits après avoir vérifié les pertes de précision. En effet à chaque division entière on abandonne un reste et donc cela impacte directement la précision.

En premier lieu j'avais d'abord entrepris d'effectuer le calcul du zéro de température immédiatement après résultat du convertisseur A/D.
Ce n'était pas une bonne idée, car beaucoup d'éléments sont représentés par des différences de température et il est plus judicieux de garder l'intégralité des valeurs initiales en 1/1024 qui évitent de positionner "un Zéro un peu flottant"...et limitent les calculs avec cette fois un signe à gérer sur chaque terme.
Le Zéro degré est très proche de la valeur 164/1024…. puisque cela donne 163.84/1024 arrondis à 164 éléments pour le Zéro degré et 860 éléments de 0 à 105 degrés. Ceci ne sera effectif que pour l'affichage (et non pour les deltas de températures).
On va donc garder toute la précision des acquisitions, pour le calcul des deltas de température et lors de l'exportation des valeurs numériques par la RS232.
Les commandes de process sont toujours un écart de température, aussi on gardera les valeurs des convertisseurs A/D en éléments natifs (ELTS) La soustraction de deux valeurs supprime de fait le zéro degré et sa petite imprécision. L'ensemble sera donc parfaitement homogène, d'autant que j'ai pu étalonner le pyranomètre pour 1024 W/M² d'étendue de mesure (EM)

Bien que délicates, les valeurs signées seront représentées en complément à 2. L'affichage devra déterminer si le nombre est négatif et réaliser le complément à 2 avant visualisation

Ces deux derniers éléments sont fondamentaux dans la série des calculs.

Bien entendu, l'affichage sera en degrés Celsius avec 1/10 de °C et on affichera par le signe "-" une valeur négative. La virgule à l'affichage sera positionnée en fonction du format d'affichage ET de l'unité mémoire en cours.

Enfin, il pourra y avoir une légère différence entre les valeurs stockées, affichées à l'écran LCD et celles utilisées pour le calcul de l'énergie. La précision sera maintenue en gardant les valeurs d'origine.

NOTA : Pour la partie transmission RS232 tous les éléments sont natifs et les calculs externes pourront ainsi être réalisés avec la précision d'un tableur.

7 Quelques réflexions fondamentales

Vous vous souvenez que j'avais prévu une vanne de régulation du débit, et que ce point restait un peu obscur, concernant la modification du débit lors d'un faible ensoleillement…
Il faut donc repenser au niveau supérieur pour faire le lien avec la réalité, sur la base de la formule de l'énergie.

En effet augmenter la vitesse réduit les échanges thermiques au niveau de l'échangeur du cumulus, mais AUSSI au niveau du panneau solaire. Alors choux vert ou vert choux ? Pas si sûr ! (Si on ne maintient pas la vitesse par exemple)

Imaginons le départ de la circulation primaire en début d'une belle journée…Ce départ a été donné par un écart de température suffisant (Paramètre Param_3) entre la cuve et le haut du panneau.
Cependant si le circuit primaire est assez long comme c'est souvent le cas, on va donc commencer par refroidir la cuve avec l'eau des tuyaux qui est restée à basse température. Comment faire pour limiter ce problème ?
Dans la formule de l'énergie, il s'agit d'un volume passé, or ce volume est incompressible puisqu'il dépend de l'installation. Cela veut-il dire qu'il n'y a pas moyen d'outrepasser cet inconvénient ? Eh bien si en théorie, car il faut réfléchir en énergie et cette formule d'énergie est un gain (ou une perte) durant une PÉRIODE DONNÉE.
Et c'est là que se situe le nœud de la solution. En effet si on accélère le passage d'eau froide, les échanges ne se réaliseront que faiblement et la SURFACE (d'énergie) sera d'autant plus faible. Cela ne changera pas beaucoup les pointes d'énergie perdue mais seulement le TEMPS durant lequel ces échanges seront réalisés. Plus le temps sera court, moins il y aura d'échanges et donc de pertes. (C'est majoritairement la surface de la pointe qui sera rétrécie)

Pour le début de journée, il est essentiel de démarrer la pompe à GRANDE VITESSE jusqu'à l'apparition d'une température à l'entrée de l'échangeur au moins égale à la température de sortie d'échangeur. A cet instant il faut réduire "rapidement" la vitesse de passage pour laisser le temps au soleil de chauffer cette fois, l'eau du panneau.
On voit également à ce stade que le volume prisonnier des tuyaux en relation avec celui du panneau lui-même peut modifier le scénario.)
Dès le début de la remontée de température (après la baisse inévitable) correspondante à la "dernière eau" sortie du panneau, on peut reprendre le fonctionnement à vitesse faible cette fois.
Cette baisse ne sera pas mesurée car elle risque d'être noyée dans le "bruit de fond" des variations, mais fera l'objet d'un temps de latence avant surveillance pour éviter toute inversion. (PHASEMST1)

Cet artifice est rendu possible par les sondes placées à l'entrée et en sortie échangeur. Il limitera cette petite perte au démarrage et le risque d'arrêt. Le réglage de ce problème est donc facilement transposable d'une installation à une autre par l'utilisation d'un temps de réglage et non par une température, toujours plus délicate à mettre en œuvre à cause des différentes longueurs de tuyauteries. (Paramètre temps de circulation Param_2)

Ainsi si l'on veut arriver exactement en débit réduit lors de l'égalité EC/EF il suffira de régler ce délai, sans se soucier des caractéristiques de l'installation.

Lors de la baisse d'énergie en fin de journée, le problème est un peu similaire, et il est toujours nécessaire d'éviter un arrêt suivi d'un redémarrage à cause du refroidissement de l'eau dans les tuyauteries primaires.

On va donc favoriser les échanges en ralentissant la vitesse, mais cela aura aussi le désavantage d'augmenter le temps et d'autoriser un refroidissement plus important du circuit primaire.
Dans ce cas où les températures sont à priori élevées dues à une journée de soleil, il y aura des compromis de vitesse à trouver pour prolonger l'action d'échange sans arrêter la pompe.
Le pyranomètre interviendra éventuellement à ce stade pour valider la mesure de puissance reçue jusqu'à une valeur de l'ordre de 150 à 200 W/M² . On entrera alors dans la phase d'arrêt de la pompe avec réduction du débit et surveillance de l'écart positif de température au niveau échangeur.

L'arrêt définitif sera commandé par la différence des températures au niveau échangeur passant à zéro. La consommation de l'électronique de commande est réellement insignifiante face à cela, puisque la mesure avait donné 2 W environ essentiellement consommés par les relais et les LED.

Ce contrôle des températures au niveau de l'échangeur est certainement le point le plus important de cette régulation, car il évite les déficits par l'inversion des échanges. En effet il est je pense préférable de ne pas fonctionner du tout que de perdre en échanges négatifs comme j'ai pu le voir (Voir les relevés effectués sur l'ancienne régulation, qui n'était pas totalement mauvaise, mais qui demandait une mise à jour technique avec des éléments d'actualité, ainsi qu'une méthode différente pour diminuer les pertes de mise en route et arrêts).
Il est d'ailleurs fort probable que j'envisage sérieusement de déplacer le cumulus pour réduire la longueur du circuit primaire, car perdre jusqu'à 7° me semble trop important. (A suivre !)

D'autre part, on ne chauffe pas de l'eau seulement pour la stocker, et ce point est extrêmement important. En effet les tirages d 'eau chaude vont faire baisser la température au niveau cuve, et en même temps au niveau des tubulures de l'échangeur, mais ce n'est pas cela l'important...

L'important est de contrôler  que entrée et sortie échangeur sont bénéficiaires.

Beaucoup vont trouver cette régulation compliquée, surtout en matériel de thermométrie. Il est vrai qu'il y a beaucoup de choses pas toujours essentielles au process. Je pense aux températures extérieures par exemple.
On peut ajouter aussi les thermomètres avec diodes qui sont mieux que de simples thermistances. Que penser du compteur et de la mesure du débit ? Tout autant que du pyranomètre ?

C'est à chacun de voir en fonction de ses propres impératifs, ainsi le pyranomètre permettra de confirmer si, de toutes façons on va arrêter car c'est la fin de journée, ou si c'est un simple passage nuageux. Cette possibilité n'est pas encore utilisée mais le sera plus tard lors des relevés. (Je pense empêcher une mise en marche en début ou fin de journée si un minimum de puissance n'est pas reçu au panneau, peut être associé à un calcul d'énergie au niveau du cumulus pour quelques degrés d'écart)
 
Non je ne suis pas allé jusqu'à établir le calendrier des jours de lever et coucher de soleil de l'année, mais une approche est peut-être possible, du fait que l'on a en permanence le maintien du paramètre "temps" (date et heure), et que le DCF77 assurera la précision dans le temps avec une mise à jour "journalière" de l'heure.
Le DCF77 indique aussi la semaine par le numéro du jour ainsi que le mois de l'année, et donner des positions de coucher et lever du soleil est assez facile en approche grossière.

8 Calculs de température

8.1 Calculs sur les températures en ELTS

Tous les calculs sont réalisés par le convertisseur AD en 1/1024, ce qui simplifie largement et réduit les temps de calculs. L'affichage des températures en 1/1024 est généralisé pour des températures positives ou négatives.
Chaque valeur de température est comparée en ELTS de 1/1024 (ELTS=éléments de 1024) au zéro °C.

Ce zéro degré est figé définitivement par rapport à l'étendue de mesure choisie pour les thermomètres, soit 125°C (pour ma réalisation) pour 1024 ELTS. Cette valeur du Zéro est de 164 ELTS ce qui correspond à un écart de température de 20.01°C par rapport à 0 ELTS. On constate donc que l'erreur est particulièrement faible et unique. Ce forçage de 0.01 °C n'est même pas affiché au display (affichage des 1/10 de degrés seulement), et n'affecte donc pas le moins du monde les calculs.

On aura donc 164 ELTS pour représenter les valeurs négatives de température de -20° à 0 °C et 860 ELTS pour représenter les 105°C restants. On a donc bien 164+860=1024 et 105 +20=125°C.

A remarquer que le 1/10 de degré est déjà thermiquement très fluctuant car un simple courant d'air modifie de plusieurs 1/10.

Méthode d'affichage :
comparaison à 164, si >= température positive ou nulle, on applique la formule 105*10/860*val qui donne directement une valeur en 1/10 de degrés.

Les calculs de température et notamment des DELTAS sont nécessaires avec des valeurs signées qui sont déterminées par le bit 7 des poids forts.

8.2 Calculs des minis de température

Là aussi les calculs vont rester résolument en ELTS. Il s'agira d'une simple soustraction 16 bits entre la valeur mini actuelle moins la valeur en cours.
Si cette valeur est >=0, alors carry=1 et la valeur est supérieure et rien n'est à faire.
L'affichage reprend alors l'affichage standard de valeurs en ELTS. Le stockage mémoire sera en ELTS.

Ce calcul est effectué en permanence quel que soit le jour ou la nuit. L'alimentation du thermomètre de température Extérieure instantanée est également permanente. (Pas de commande d'alim)

Cette valeur est mise à 0x03 et 0xFF à minuit tous les jours. Il n'y  pas de mini à la semaine. Seule la moyenne, est à la semaine.

8.3 Calculs des maxis de température

C'est exactement l'opposé et on reste toujours en ELTS. On réalisera la même opération.
On va soustraire du dernier maxi connu, la valeur actuelle de température.
Si cette valeur est positive ou nulle (carry=1), alors la nouvelle valeur est plus faible que le maxi et il n'y a rien à effectuer. Dans le cas inverse, (carry=0), il faut remplacer le maxi en cours par la nouvelle valeur.

L'affichage suit les mêmes règles que le mini. On notera que les valeurs stockées en mémoire seront également en ELTS
Ce calcul est effectué en permanence.
Cette valeur est initialisée tous les jours à minuit à 0x00. Il n'y  pas de maxi à la semaine. Seule la moyenne est à la semaine.

8.4 Calculs des moyennes de température

Il y a 2 moyennes à calculer en permanence. Moyenne jour et moyenne semaine.
Les températures moyennes sont calculées seulement toutes les heures "précises" lors de l'apparition du bit TOPHEUREX positionné par l'horloge dans la séquence d'interruptions.

Les températures seront donc là aussi calculées en moyennes d' ELTS (éléments de 1024), et le stockage sera cumulé sur 16 bits et divisé par le nombre de points mesurés. (Intégration à l'heure : 24 pour le Jour J)

Pour la moyenne de la semaine, on fera le cumul par jour divisé par le nombre de jours (Sans le  jour en cours qui est incomplet et qui a déjà sa propre moyenne en cours)

L'affichage suivra la règle des températures.
Ce calcul est effectué toutes les heures, et c'est le seul véritable calcul intégral, puisque tous les autres calculs ne sont que de simples cumuls.

8.5 Températures de process

Ce sont les mêmes règles qui s'appliquent.
On calcule de plus la différence point haut du capteur et température cuve (HP/TK), ainsi que la différence entre l'entrée et la sortie de l'échangeur du cumulus (EC/EF ou Hot Echg/Cold Exchg).
Ces valeurs résultent de mesures unitaires et sont toujours réalisées de base en ELTS ce qui limite toujours les imprécisions.
Ces calculs ne sont effectués que de jour. La nuit arrête cet ensemble de mesures qui n'ont plus de sens. (Le soleil est couché et la pompe est à l'arrêt !)

On notera que la notion de jour et de nuit est utile, car elle procure en premier lieu la sécurité de non échanges par le verrouillage par l'heure.

Il ne peut pas y avoir d'échanges thermiques de nuit sauf cas particulièrement très exceptionnels. Cette notion permet de faire les différentes mises à jour des historiques en situation fixe. Elle permet également de reprendre la synchronisation de l'heure légale notamment dans les changements d'horaires printemps/automne, et d'assurer la cohérence des jours mois années en l'absence de calculs calendaires.

(A cet instant, Jours mois et années n'étaient pas prévus pour être modifiés par paramétrage, c'est maintenant réalisé, car certains n'auront peut -être pas la volonté d'installer le DCF77, mais cela ne résoudra pas les abérrations du calendrier au niveau du jour et du mois. Il y aurait jusqu'à 255 mois et 255 jours dans le mois....Alors je me sens obligé d'intégrer un calendrier minimum. C'est à suivre....
Les mises à jour se réaliseront à minuit les erreurs sur ces valeurs entraîneront le positionnement à 1 du jour et du mois. Les jours de semaines sont gérés normalement (à la désynchronisation près, car il n'y a pas de véritable calendrier)

9 Calcul du débit primaire

Le débit primaire de l'ordre de 50 à 150 L/H est mesuré par un simple compteur d'eau qui délivre des tops au rythme de 1 top par litre. Les débits étant relativement faibles, compter des impulsions nécessiterait au moins une heure ce qui n'est pas acceptable. (J'ai déjà vu le faire par de "mauvais pros") Aussi ayant une possibilité de mesure de temps suffisamment précise par l'horloge du PIC, nous allons donc mesurer le temps entre deux fronts montants d'impulsions définissant 1 litre passé. C'est-à-dire que le débit sera donné par l'inverse avec les unités appropriées, soit  :

Le débit sera donc de = 1*60/Temps en secondes pour avoir des litres par minute. En multipliant par 60, nous pourrions avoir les litres/H. En affichage on utilisera les L/mn

Encore une précision , et c'est le cas de le dire, mesurer à la seconde près environ 40 à 60 secondes est tout de même assez peu précis, aussi nous allons doubler cette précision en utilisant la DEMI SECONDE comme résolution minimale de temps. (La résolution de la demi seconde sera générée par l'horloge du PIC)
Pour obtenir le volume en centilitres et par minute il faut donc appliquer la formule

Volume (cL)= 12000/Temps (s)

Ce volume (débit à la minute) ne sera utilisé que pour l'affichage exprimé en L/mn et pour le calcul de l'énergie (durant une minute).
Le fait de doubler la fréquence de mesure du temps en gardant toujours 8 bits va affecter principalement la partie basse de l'échelle de mesure.
Ainsi en comptant à la demi secondes on va de 0.47L/mn soit 28L/H pour 255 tops d'une demi seconde, à 2.55L/mn soit 153 LH pour 47 tops. On se rappellera que l'affichage est multiplié par 100 (centilitres) et qu'il ne peut aller que de 2.55L/mn à 255 Tops soit 0.47L/mn ou 28L/H.

Le fait de choisir la demi-seconde augmente la précision en affectant peu les vitesses élevées mais principalement les vitesses basses. Ceci ne nous arrange pas vraiment dans l'optique de garder une mesure du temps et des débits sur 8 bits, mais c'est ainsi et je pense préférable de garder la demi-seconde en fréquence minimale pour une meilleure précision aux valeurs moyennes qui représentent la majeure partie du fonctionnement.
Dans le cadre du fonctionnement à vitesse élevée au démarrage de la pompe, je pense que l'on sortira des limites, mais il a été dit que ce mode ne sera pas comptabilisé, alors ….! La vitesse au démarrage aurait dû être dans un rapport 10 à 12 par rapport à la vitesse de 1.39L/mn, et les indications seraient alors fausses tant pour le débit que l'énergie, mais la réalité hydraulique du circuit fait que l'on atteindra que 150L/H au maximum. Ce n'est pas très grave…
L'incertitude de mesure du temps est donc améliorée dans le rapport 2 avec le choix des tops horloge à la demi-seconde.

Enfin dernière particularité pour des temps très longs, le comptage va donner un report à 255, et dans ce cas, l'interprétation serait évidemment fausse. Sans repasser à 16 bits pour le comptage de ½ secondes, on bloquera le compteur de demi-seconde à 255. Son nouveau départ ne pouvant être relancé que par un top du compteur.
Ainsi en cas d'arrêt pompe par exemple on sera bloqué à 255 ½ secondes soit à 0.47L/mn ou 28/LH. Cette valeur forcera la valeur mémoire et l'affichage à un débit nul. De même une valeur trop faible de temps entre tops compteur ne sera pas comptabilisée en dessous de 10 secondes soit un débit de 6 L/mn ou 360 L/H. Une telle valeur sera considérée comme un parasite.

10 Energie cumulée jour J

La formule de base du calcul en WH est : 1.16*litres*Delta température.

En réalité pour pouvoir travailler en nombres entiers, on va procéder aux calculs en CENTI WATT HEURES soit 100 CWH= 1 WH. (Ceci est dû au fait que l'énergie récupérée en 1 minute est de l'ordre de 20 WH au maximum, ce qui est peu, et qui avec les calculs donnerait beaucoup trop de dispersion et rendrait ainsi les calculs avec une précision totalement dérisoire et anarchique).

Aussi, plusieurs éléments ont été évalués pour pouvoir travailler avec un minimum de précision.
La mesure du volume d'eau primaire passée au niveau de l'échangeur est réalisée par mesure du temps entre fronts montants, donné par le capteur situé sur le compteur. La mesure du temps se réalise sur environ une minute mais plus précisément en mesurant un volume de 1 litre avec un incrément du temps de la demi-seconde, ce qui donne une précision de 1% environ. Ceci avait du être revu suite à une mesure à la seconde trop imprécise.
Le choix de la demi seconde permet de garder une valeur sur 8 bits en évitant le passage à 32 bits dans les calculs intermédiaires.

Ainsi pour les valeurs utilisées ici, cela correspond à environ 1.39 L/mn qui sera multiplié par 100 pour pouvoir traiter tous les chiffres significatifs. La formule est la suivante :
12000/demi secondes. Cette formule sera cumulée à d'autres telle la constante 116 pour maintenir la précision globale.
En effet effectuer chaque petit calcul indépendamment entraîne des pertes de précision, et il est préférable de cumuler les opérations jusqu'à ne pas dépasser les 24 bits.

(Le coefficient 1.16 sera lui aussi multiplié par 100 pour intégrer les décimales).

Ainsi le 116 sera immédiatement multiplié par le volume passé dont la formule est ci-dessus : 12000/temps en demi secondes.

Enfin le delta de température sera géré au 1/10 de degré et la valeur sera donc multipliée cette fois par 10 soit un total de 10E5. (100 000) pour le résultat final de l'énergie.

A la suite, le delta de température sera préalablement calculé car on dépasserait alors les 24 bits.

La formule se complique en apparence et devient donc :
E (CWH)= ((116*12000/temps en sec)*(DeltaT en 1/10 de °C)/1000

Le résultat en CWH de chaque mesure (Ordre de grandeur de 2000 représenté au LCD par la notation 20.00) sera donc cumulé sur une journée (soit 2 880 000). Ces valeurs "tiennent" pour des nombres de 24 bits.

Une précision encore, l'écart de température (entrée sortie échangeur), pouvant être négatif, cela implique de traiter les nombres signés, ce qui sera réalisé. Les deltas négatifs peuvent correspondre à une aberration de fonctionnement (manque d'arrêt pompe, sonde défectueuse, clapet qui fuit ou vanne restée ouverte par exemple).

Ces écarts négatifs restent tout à fait possibles le plus naturellement lors de l'arrêt de la pompe et lorsque les différents points de mesures vont prendre leur équilibre en fonction de la température extérieure pour le panneau et des températures des tubulures de sortie du cumulus.
(Le plus embêtant serait qu'ils se produisent en début de journée lors de la mise en fonctionnement et lorsque le global est quasiment nul. Ce cas sera examiné, mais il me semble que le comptage positif ou négatif devrait simplement résoudre cette éventualité.

Au niveau de l'affichage seul, les CWH seront affichés au display en WH avec le point décimal correctement positionné (2 digitsà droite), car (entre nous), je n'évalue pas très bien l'énergie d'un CWH. (Il n'est pas question de repasser en Joules à cause des limites de calcul imposées en 24 bits, et nous connaissons tous bien mieux WH et KWH que le centi-watt heure dont je ne sais même pas s'il fait réellement partie des sous-multiples officiels.
Il est en tous cas utilisé en mémoire !

10.1 Puissance instantanée échangeur

La formule est celle utilisée depuis bien des articles et adaptée au calcul en entiers (C'est la formule de l'énergie, voir ci-dessus).
Les valeurs individuelles utilisées sont donc multipliées autant de fois par 10 pour obtenir une précision suffisante. La troncature se faisant seulement en fin des calculs ou d'affichage avec pour règle essentielle de ne pas dépasser 24 bits de précision….Mais le dernier calcul obligera en réalité à passer en 32 bits et de réaliser la seule division 32 bits par 1000.

Cette fois il faut partir de l'énergie calculée sur une minute et multiplier par 60 pour avoir des watts heures (par heure) ou des kilowatt heures (par heure). En réalité on sera amené à stocker en mémoire des déci watt (DW) et afficher des W.
Une énergie de 1 KWH développée durant 1 heure correspond à une puissance instantanée de 1 KW qui s'est exercée durant 1 heure.

Cette puissance sera donc déduite de chaque calcul d'énergie effectué toutes les minutes et servant au cumul d'énergie reçue. (Les valeurs guide sont de l'ordre de 5 à 30 WH/mn suivant les ensoleillements et surfaces en cause.)

Cette valeur est seulement mise à jour toutes les minutes si elle est demandée en affichage. Cette valeur instantanée n'est pas utilisée par ailleurs mais elle est calculée très facilement. Cette valeur témoigne de la puissance instantanée fournie à l'échangeur. Elle ne fera pas partie des données de transmission RS232, faute de place dans la trame limitée à 80 caractères, mais pourra être recalculée par le tableur.

10.2 Contrôle de l'inversion des échanges

Cette partie qui au niveau puissance parait incontournable est en réalité très simple. Dans la formule de l'énergie, le fait d'avoir un delta T° négatif entraîne un échange déficitaire par une énergie qui est empruntée cette fois au cumulus.

Plutôt que de travailler sur les énergies, et de laisser encore des précisions "sur le bas côté de la route", il est tout à fait possible de contrôler ce point par la seule différence des températures au niveau de l'échangeur. Un delta négatif entraînant de fait une énergie négative (Car dans la formule de base, seul l'écart de température peut être négatif)

Ce contrôle est masqué durant la phase de démarrage de la pompe, pour permettre l'arrivée de l'eau chaude en provenance du capteur solaire. Ceci est représenté par un temps qui est appelé constante de circulation. En effet cela dépend de chaque installation, par la longueur des tuyauteries. Ce temps correspondant au paramètre Param_2 est naturellement modifiable directement au panel.

11 Le pyranomètre à BPW34

L'étalonnage avait donné pour 844W/M² un nombre d'éléments de 776. L'étendue de mesure a été rectifiée pour une valeur précise, car les circonstances l'ont permis. Aussi, de ces calculs, il faut retenir une étendue de mesure de 1024 W/M² correspondant donc à 1024 éléments des convertisseurs A/D du PIC.
Je pense que cette valeur d'EM à 1024 est la plus adaptée au sujet et de plus très simple puisque la valeur en ELTS est directement la mesure en W !

Dans le cas contraire, la valeur à afficher aurait été le résultat du calcul suivant :
Puissance en W = EM (en W/M²) * Nbr d'ELTS / 1024

(Voir l'article sur le pyranomètre à BPW34)

Les nombres sont si proches que l'erreur est garantie lors de l'abandon des décimales de la division.
Initialement j'étais calibré à 1113 W/M², mais j'ai décidé de reprendre l'étalonnage pour avoir une EM de 1024 W/M². C'est beaucoup plus simple !

12 Le principe de régulation

12.1 État des lieux

SANS régulation, c'est naturellement le mieux ! Mais pour cela il faut réaliser l'installation en thermosiphon, ce qui est peu pratique à cause de la nécessité de mettre le panneau solaire en contrebas du cumulus. (Cela est souvent possible en pays de montagne mais plus rarement ailleurs…)
Aussi dans la majorité des cas il faut réguler.

Tous les chauffe eau solaires sont à distance non nulle du panneau capteur. Cela est un PROBLÈME DE FOND MAJEUR qui va perturber largement le fonctionnement (Voir l'article sur les courbes obtenues avec une régulation basique à 2 températures seulement).
En effet après une période de repos, l'eau primaire des canalisations s'est refroidie. Juste après le démarrage de la pompe, sur un écart de température Haut panneau / Cuve, on introduit de l'eau froide dans le circuit d'échange du chauffe eau (Sans pouvoir y remédier).
Bien entendu cela ne durera pas trop longtemps, mais c'est du négatif et il faut déjà compenser cette perte avant de pouvoir penser à gagner ! Ça compte tout de même.
De même lors des arrêts suite à manque d'énergie solaire temporaire, il y a des arrêts et redémarrages qui sont sources de pertes à causes des "overshoot" dus au refroidissement des canalisations.
Les solutions possibles sont naturellement la proximité la plus resserrée entre le panneau et le cumulus, mais cela n'est pas toujours possible et le contexte fait que le plus souvent on ne peut rien y faire physiquement.
Alors il reste à trouver quelques parades logiques…C'est le paragraphe suivant !

Pour rappel, la vitesse variable n'est pas réalisable car trop onéreuse pour de faibles puissances de 15 à 30 VA et peut-être même sans véritable solution pour des pompes 220V~ (En tension véritablement sinusoïdale).
La seule solution plausible de débit variable reste la vanne de réglage de débit !

Note : Le fonctionnement des petites pompes en régime "pseudo-sinusoïdal" amènerait certainement leur destruction rapide.

12.2 Le principe même de régulation

J'ai distingué deux phases essentielles dans la régulation :
La première est la mise en marche de la pompe, et la deuxième le maintien en fonctionnement. (Phase_Mst1 et Phase_Mst2).
Je rappelle qu'il y a 4 sondes de températures (Température process) disposées en Haut du panneau solaire, une autre associée en milieu de cuve, une troisième sonde est à l'arrivée eau chaude (EC) de l'échangeur du cumulus, et la dernière est sur le retour d'eau froide échangeur (EF).

La mise en marche de la pompe est conditionnée par un delta de température (positif) entre le haut du panneau et le milieu de cuve. Cet écart est paramétrable au panel (Param_3). Ceci est nécessaire pour assurer le démarrage de la pompe. De même il ne faut pas réagir au simple passage "d'un oiseau", et il faut de plus confirmer une certaine réserve de chaleur dans le panneau, aussi outre l'écart de température, un délai (Param_0) est associé au paramètre de delta de température ci-dessus.

La commande d'arrêt de la circulation primaire sera simplement détectée par l'égalité de températures entre l'arrivée EC et le retour EF au niveau de l'échangeur lors de la phase 2.

Aucun délai de ne sera associé à cet arrêt, car d'autres réglages vont préalablement confirmer cette phase d'arrêt irréversible par manque d'énergie.
Voyons maintenant les détails.

12.3 Mise en fonction de la pompe

Cette mise en fonction (Phase_Mst1) se déroule en plusieurs étapes.
Dès la détection d'un écart de température suffisant 5° à 7°C (Paramétrable au panel : Param_3) entre Haut du panneau et milieu de cuve, il faut donc faire une première opération d'ouvrir la vanne de régulation pour le passage rapide du fluide primaire à 150 L/H. (Toutes valeurs pour fixer les idées et qui seront certainement ajustées lors de la mise au point finale)
Cette vitesse se prépare par le positionnement de la vanne de régulation. Ce positionnement est basé sur le temps de rotation du moteur de vanne. La durée de rotation pour 90° angulaires est importante et est au maximum de 25 à 30 secondes.
Les premières 15 secondes seront très significatives, et de plus il ne pourrait réellement y avoir débit qu'après 8 secondes (Voir courbe relevée. La forte démultiplication est nécessaire pour vaincre les frottements de la vanne 15x21, (qui sera cependant choisie pour être "douce" voir l'article sur cette vanne).
Le temps de manœuvre de la vanne est indépendant du délai de mise en service de la pompe. Les deux sont lancés simultanément par des timers séparés issus de l'horloge du PIC et se terminent automatiquement en interruption horloge.

Dès que la température HP/CUVE est atteinte ET que le délai de mise en service de la pompe est également atteint, la pompe est alors lancée quelque soit la course effective de la vanne (En principe la vanne devrait être ouverte en plein, et le débit maximum).
A cet instant, il faut lancer un autre timer correspondant au temps de circulation pour obtenir l'arrivée d'eau chaude. Ce timer (qui est paramétrable également), autorisera la poursuite ou l'arrêt de la pompe suivant l'écart de température obtenu à la fin du temps prévu.

En effet durant cette phase inévitable où l'inversion des températures d'échanges est une réalité incontournable, il faut contrôler que cet écart de température au niveau échangeur est légèrement positif (+1.2° environ et non paramétrable au panel mais seulement en EEPROM) à la fin du timer. Si ce n'est pas le cas, on arrête tout le processus pour une durée minimale de 180 secondes (Paramétrable seulement en EEPROM).
Dans le cas contraire et normal, on passe immédiatement la vanne en VITESSE LENTE, tout en continuant le pompage. Pourquoi ?

Nous recevons à cet instant la première eau chaude provenant du haut du panneau et qui a traversé tout la tuyauterie jusqu'à l'entrée EC. L'eau devrait donc continuer d'être de plus en plus chaude, et il n'y a pas lieu de craindre une baisse immédiate.
Mais alors pourquoi réduire la vitesse ? Simplement parce que le circuit étant une boucle, on a injecté de l'eau froide en bas du panneau, et que pour réduire "l'overshoot" il faut laisser du temps au soleil pour réchauffer cette eau qui ne peut pas l'être instantanément.
Cette façon de procéder devrait permettre de laminer un peu ces pointes toujours gênantes dans les processus de régulation simple.

Le processus de mise en marche est alors terminé et on ne repassera plus dans cette partie sans un nouveau démarrage. La suite se continue sur la surveillance normale de fonctionnement….

12.4 La routine de surveillance

Cette routine est scannée en permanence plusieurs fois par seconde et surveille en premier lieu tout passage à zéro de l'écart de température au niveau de l'échangeur.
En cas d'écart de température nul, un arrêt immédiat est effectué. En réalité cet arrêt se produira un peu avant le zéro grâce aux fluctuations de la température différentielle.
Ces fluctuations sont de quelques dixièmes de degrés dus à la stabilité des thermomètres, à la stabilité du convertisseur du PIC, de la stabilité des tensions, etc…etc…
Disons simplement que l'on sera juste à la limite précédant des pertes d'énergie. Cette valeur de zéro n'est pas paramétrable, car c'est le principe même de récupération du maximum d'énergie qui est en cause. (En cas de difficultés, il serait toujours possible de prendre une valeur paramétrable très légèrement positive)
L'arrêt sera alors immédiat et un nouveau départ repassera alors par la mise en fonction de la pompe comme précédemment par la phase 1. Un délai minimum de 180 secondes (non paramétrable au panel) protégera d'un battement Arrêt/marche.

Passons maintenant aux autres cas où la différence EC/EF varie. Un écart paramétrable au panel de 2° (Param_4) est testé et suivant les cas on réalise les opérations suivantes :
(En rappel nous sommes arrivés dans cette phase de vitesse lente depuis la phase de mise en fonction de la pompe).

Si l'écart de température au niveau échangeur est supérieur à 2°, alors on lance une temporisation paramétrable Param_1 de 250 secondes maxi, qui permettra alors de passer en vitesse normale pour la surface de panneau considérée, soit dans mon cas à 1.39L/mn.
Si toutes fois on restait avec un écart inférieur à 2°, alors la vitesse lente restera maintenue.
Dans cette phase de fonctionnement, on passera d'une vitesse normale à une vitesse lente instantanément, et si les conditions s'améliorent, et après un délai paramétrable on pourra repasser en vitesse normale. (Ce délai évite les battements lors des écarts juste en limite) 
Cela aussi souvent que l'énergie variera. Cette approche permettra de ne pas couper la pompe et d'attendre jusqu'à l'extrême limite avant de couper. C'est un point très important qui devrait donner de bons résultats et éviter de couper la pompe et de laisser refroidir le fluide dans les tuyauteries, puis de redémarrer et d'arrêter définitivement cette fois, en ayant perdu beaucoup d'énergie.

Dans cette phase de surveillance, il sera possible de comparer la vitesse de circulation et au besoin de corriger, voire même d'asservir totalement la vanne de régulation avec les valeurs de débit et d'écart de température (Régulation PID ?).
Cette vision est tout à fait réalisable, mais dans cette approche, je préfère rester humble et avoir un système simple, avant de passer à quelque chose de plus compliqué.

En effet dans cet aspect il peut y avoir des interactions non souhaitées, car le but premier est bien d'extraire le maximum d'énergie sur la base des calculs d'énergie.
Mais il faut aussi prévoir que  tout arrêt sera une source de pertes importante, et que cette vision reste finalement assez difficile à maîtriser complètement sans une étude très poussée des différents phénomènes. Alors je préfère rester prudent ! 

(Il me semblerait déjà préférable de corriger les problèmes de distance entre panneau solaire et cumulus avant toutes choses).

En résumé de la phase de surveillance, il y a une vitesse lente et une vitesse normale ainsi que l'arrêt à delta de température échangeur à zéro. Je rappelle que cette régulation de TEMPÉRATURE au niveau échangeur est le reflet de l'énergie suivant la formule déjà mentionnée. (Un delta de température à 0 implique une énergie nulle).

12.5 Conclusions sur le principe

Cette partie de régulation a été délicate à mettre au point sans l'aide de petits outils spécifiques, mais ce principe est resté simple.
J'ai simplement ajouté deux potentiomètres à la place de deux diodes de mesure, ce qui permet d'avoir des DELTAS qui seuls affectent le fonctionnement.

Le diagramme des vitesses de circulation ci-avant explique mieux que tout, les différentes possibilités utilisées. On remarquera que la vanne équipée d'un "tourne broche" à 4 Euros est des plus simple et facilement réalisable avec un deuxième réducteur concentrique "un peu plus solide" (Réducteur d'anciennes imprimantes ou autres petites machines).
Sur ces petits moteurs "lowcost" les vitesses sont légèrement différentes en avant et en arrière. Cela est pris en compte par des temps prédéfinis suivant les opérations Avant ou Arrière.
Il ne devrait pas y avoir de grands décalages sur une dizaine de fonctionnement normal/lent par jour.

(Je n'ai pas précisé que le moteur de tourne broche est un petit moteur à courant continu qui tourne dans un sens et dans l'autre par inversion des polarités. Il a d'ailleurs été changé pour un moteur 4 à 6 volts qui réclame un peu moins de courant tout en gardant le précieux réducteur "en carton pâte".
Un moteur 220V~ serait beaucoup plus précis en positionnement mais ne peut pas être facilement commuté en inversion de rotation. A chacun de voir ce qu'il peut utiliser !)

Tout arrêt de la pompe entraîne une re-synchronisation de fait pour toutes les commandes suivantes, avec fermeture complète de la vanne.
Au premier scan de la boucle de mise sous tension, il n'y a aucune temporisation et les données sont prises en compte immédiatement (Delta de Température). Ce n'est pas le cas sur un arrêt en cours de fonctionnement par manque d'énergie, auquel cas une temporisation s'appliquera pour un nouveau départ.

Ce principe me paraît bien, car il devrait résoudre les problèmes d'arrêts /départs fréquents avec le cortège de pertes inhérentes.

La mesure des différences de température tant HP/Cuve que EC/EF est réalisée par programme et soustraction desdites températures. La visualisation des écarts fait ressortir une petite fluctuation de quelques dixièmes de degrés due aux causes déjà exposées, mais non véritablement gênantes. 
Ces fluctuations restent faibles, et pourraient être réduites en utilisant des thermomètres différentiels analogiques.
Je le savais, ainsi que je l'avais déjà évoqué je crois, mais c'est mon choix de n'avoir qu'un seul type de thermomètre. C'est une question de développement et de maintenance, mais aussi d'étude fine de l'évolution de chaque température.
Pour ceux qui voudraient faire avec des thermomètres différentiels, ils perdront la valeur absolue de température ce qui me semble important tout de même, et ils devront développer quelque chose qui ressemble dans le principe à mon pyranomètre thermique. (Ce principe différentiel existait dans mon ancienne régulation et la valeur absolue de chaque température me manquait pour appréhender le niveau des échanges)

Tiens…Pyranomètre ! Pour l'instant je ne l'introduis pas encore dans la régulation de surveillance, mais l'emplacement dans l'organigramme est tout à fait possible, et l'électronique est présente, alors…j'attendrai les relevés réels RS232 avant toutes choses pour voir si il sera encore possible d'améliorer. La valeur est cependant affichable au LCD.

Le contrôle du débit permettra de mesurer assez correctement l'énergie au niveau du fonctionnement de surveillance principalement. (La comptabilisation de l'énergie en phase de démarrage est réalisée automatiquement sans que l'on ait à s'en occuper. Il ne peut y avoir d'énergie que si la pompe fonctionne)

13 La RS232
 
13.1 TX

Cette régulation comporte également la partie transmission RS232 ou radio. Dans quelle utilité ?
Simplement pour récupérer les données brutes des différents capteurs, et refaire ainsi en différé le suivi de bon fonctionnement en traçant les courbes.
Le rôle est quasiment identique à un datalogger, mis à part qu'il est inclus dans le programme.
La fonction TX peut être mise en fonction par le basculement du switch à glissière du panel.
Cela permet ainsi de voir sur plusieurs jours ce qui pourrait "clocher" ou reprendre certains réglages de Température ou de temps.
C'est un outil d'exploitation particulièrement utile qui ne consomme que peu de temps puisqu'il fabrique seulement 80 caractères ASCII dans un buffer, et que celui-ci est géré en interruptions, ce qui ne perturbe pas le processus.

De jour, la récupération des données transmises est réalisée à un rythme paramétrable définit par le paramètre Param_8, soit au rythme minimum de boucle de 1 seconde jusqu'à 250 secondes.

De nuit, il y a une transmission toutes les heures (Non paramétrable), Ceci permettant de suivre l'évolution des températures (qui sont mesurées sur les différents points thermiques : panneau, tubulures EC / EF cuve, et qui peuvent témoigner de tirages d'eau chaude, mais aussi des pertes internes)

Les données transmises en ASCII sont la date et l'heure, les 4 températures de base des capteurs du process, la température Extérieure, mini, maxi et moyenne du jour, le pyranomètre et le débit. Les caractères de contrôle sont indiqués dans le tableau ci-dessus, et l'ensemble devrait rester affichable sur tout traitement de texte simple au format TXT.

Le contrôle des écarts de température devra être réalisé en effectuant les calculs sur un tableur, ce qui éliminera toute erreur ou imprécision des calculs sur le PIC. De même les données sont brutes en 1/1024 issues du convertisseur AD.

Un ensemble de 7 bits logiques est également transmis (Valeurs accompagnant les données de base voir également le tableau ci-dessus). On y trouve :
l'état actif ou non de la pompe, le jour ou la nuit, la LED erreur, la présence ou l'absence d'alimentation des capteurs (Tous sauf la température Ext instantanée), l'alimentation de la radio, l'état de la vanne de régulation active ou non ainsi que le sens.
Tout changement de ces valeurs logiques déclenchent automatiquement l'envoi d'une trame "extra" par rapport au délai standard entre envois, ce qui permet d'avoir toute la précision requise. (Indication d'un mouvement de vanne ou de pompe et évaluation des temps de réaction)

Cette fonction de datalogger est réellement très fine et autorise une surveillance précise. Ainsi il est possible de voir les baisses éventuelles de performances relativement à l'ensoleillement, par le biais du pyranomètre et d'en déduire des actions à mener au niveau isolation, nettoyage échangeur etc…

13.2 Fonction radio TX (et RX)

Cette fonction est directement issue du paramètre Param_11 accessible au panel. Les données TX sont simplement amenées à l'entrée data de l'émetteur RT4.
L'alimentation de l'émetteur, ainsi que déjà évoqué n'est réalisée que par programme sur une sortie suite à la lecture du switch à glissière.

Le switch à glissière commande uniquement l'alimentation du circuit MAX232 et envoie cette information à RB7 qui pourra, suivant le paramètre Param_11, commander l'alimentation de l'émetteur radio (Ou non).

Cette fonction radio permet de recevoir les données sur le PC familial avec le petit outil récepteur déjà décrit dans ce blog (voir cet article ) et avec l'utilisation de l'excellent programme TERMINAL.EXE de Bray++.

13.3 Autres possibilités Radio

Si vous avez un dispositif annexe à commander, (Orientation de panneau par exemple, charge de batteries, commutation de champ captant etc…) une trame avec adresse spécifique est possible pour activer ou désactiver un dispositif.
Dans mon cas j'enverrais par exemple un ordre de repli du panneau en fin de journée avant le coucher du soleil si on voit que les températures sont insuffisantes pour produire quelque échange thermique.
Il est en effet toujours préférable que le panneau puisse trouver sa position de repli toujours plus sécurisante en cas de phénomènes météorologiques.

Dans l'état actuel, cette action pourrait  couper automatiquement après repli l'alimentation du PC…en attendant la future centrale d'asservissement du panneau par PIC.

Bref c'est à chacun d'imaginer...

14 Conclusions et retour d'expérience

Beaucoup de points  émaillent cette réalisation et je vais seulement commencer à l'installer. Je pense que je vais la mettre en // sur la régulation existante, pour observer les éléments auxquels je n'avais pas accès. (Température EC/EF, principalement). Je ferai seulement le basculement après "période de rodage".

Je n'ai pas encore pris de décision sur la diffusion ou non du programme source, mais il est fort probable que je diffuse seulement le binaire .HEX, pour ne pas encourager les fabricants à "pomper" et gagner toujours plus d'argent. Pour donner une idée du travail de programmation assembleur, il y a à ce jour 85 pages format A4 taille 8 et 7250 lignes environ et une programmation de 5 mois environ.
 
Pour le retour d'expérience, rien pour l'instant, mais ce paragraphe sera complété à chaque problème rencontré.

----------------------------

Tout arrive... et voilà le résultat du premier essai réel réalisé le 21/04/2011, avec pour commencer un relevé effectué par radio sur le premier essai. Un beau graphique à commenter...

(Une correction tout de suite... la courbe pompe n'est la bonne mais seulement celle du sens de la vanne. C'est expliqué ci-après)

Le premier élément est caractérisé par des perturbations de la transmission radio de façon irrégulière. La reprise avec l'abandon des valeurs est fastidieuse mais sans problème car avec un enregistrement toutes les 5 secondes, il y avait assez de points...!

Le deuxième point est la courbe hachée, du haut panneau (bleue) déjà rencontrée sur le datalogger, et dont je pense avoir trouvé l'origine cette fois. Ce ne serait pas un problème de parasites mais un problème d'emplacement de sonde.

En effet, la diode de mesure est fixée contre le collecteur haut du panneau, mais premièrement cette fixation est un peu aléatoire, car faite depuis l'extérieur pour ne pas retirer la feuille de verre, alors le serrage est un peu lâche et il n'y a qu'un contact de la génératrice du cylindre de la diode et de la génératrice du collecteur cuivre. (pas de pâte thermique ajoutée) 
Mais le plus important facteur est certainement le rayonnement direct du soleil qui chauffe rapidement la diode indépendamment du corps noir de l'absorbeur dont la résistance thermique avec la diode n'est pas parfaite. De plus un troisième paramètre peut peut-être intervenir mais je n'en suis pas certain, c'est le fait que toute jonction se comporte aussi comme une photopile ? (à vérifier par les spécialistes de la matière).
La diode devra être cachée du rayonnement direct du soleil et avoir un contact thermique de bonne qualité avec l'absorbeur, pour ne représenter que cette seule température sans possibilité annexe de complément solaire direct.

Autre souci, la mesure de débit d'eau primaire fonctionne mal car elle a une trop grande sensibilité à la dérive et aux problèmes thermiques. Je crois que ce dispositif devra être modifié et placé au plus proche du compteur, car le fait que du 450 KHz se promène sur un fil blindé de 2 mètres de longueur n'est pas correct.

Dans les points positifs, le paramétrage n'a pas été changé depuis la mise au point et ça fonctionne tout de même. Vers la fin d'enregistrement, j'ai modifié, mais j'ai fait plus de mal que de bien...
On constate aussi qu'en dessous de 100W/M², il n'y a pratiquement plus rien à récupérer d'autant que le niveau de température en fin de journée est assez élevé. Mais des tirages d'eau chaude peuvent cependant amener à une reprise du pompage de façon tout à fait normale et énergétiquement bénéficiaire.

La régulation avec la vanne semble bien marcher et l'arrêt de pompe est conforme au niveau 0°C à l'échangeur du cumulus. Pour le reste, il n'y a rien à ajouter sinon qu'au gré du tirage d'eau chaude, il arrive que l'on reparte en échange, alors que l'on s'était arrêté, mais rien que de très normal.

Au niveau pompe, il y a un arrêt en fin de graphique. Etant à côté à cet instant, le graphique n'est pas la réalité. C'est un petit mystère à éclaircir ! ---> (Mystère résolu, ce n'est pas la pompe mais le sens de la vanne (courbe en vert fonçé))
Il y a eu aussi d'autres arrêts non analysés, car la journée était brumeuse et il a pu y avoir des arrêts normaux par absence d'énergie. (Là aussi ce sont des changements de sens sur énergie faible)

A ce stade il faut aussi remarquer, que plus on monte en température dans le cumulus, plus le seuil pour élever cette même température est élevé. On le voit bien le matin ou il n'y a pas d'arrêts, (changement de sens) mais seulement l'après midi et lorsque le ciel est brumeux avec des creux de rayonnement.

Je pense que le principe retenu à 3 vitesses et de l'arrêt pompe est un bon principe, mais qui surprend peut-être, par rapport à l'ancienne régulation dont on ne voyait que les températures de cuve et de haut de panneau, ce qui était restrictif et très certainement consommateur d'énergie par inversion d'échanges jamais mis réellement en évidence.
Cette fois le delta de température EC/EF est réellement représentatif de l'énergie, et c'est un réel gage de bon fonctionnement sans inversion.

Je vais temporairement compter l'énergie sur la base d'un débit fixe de 1.39 L/mn , en attendant de reprendre ce dispositif de comptage un peu trop instable. (Ceci sans modifier le fonctionnement de la vanne de régulation). Les chiffres d'énergie seront temporairement un peu erronés, (mais assez peu je pense).

15 Explications des relevés "jour 2"

Vous avez pu voir au paragraphe précédent les résultats du tout premier relevé. Il y manquait un certain nombre d'éléments de synchronisation permettant d'expliquer les différentes courbes.

Cette deuxième campagne (qui ne sera pas la dernière), permet déjà d'apprécier un bon nombre de points positifs mais aussi des points spécifiques qui demandent une amélioration ou parfois une correction.

Ces courbes sont nombreuses et sont représentées sur un même graphique. Ce graphique sera dilaté 2 fois (Courbes 1,2 et 3) pour permettre de bien vérifier les fonctionnements de la vanne de régulation.

Il est difficile de structurer un tel chapitre, car ce sont des points particuliers qui nécessitent d'être commentés. Cependant je vais essayer d'expliquer ce qui se passe au niveau général puis de passer seulement après aux détails.

Pour éviter les problèmes de transmission, les données ont été enregistrées cette fois directement par liaison directe RS232 sur un net book avec adaptateur USB/RS232. (Les problèmes de transmission sont pour beaucoup dus aux passages de personnes entre l'élément émetteur et récepteur, à cause de la mauvaise transmission des ondes au travers des dalles en béton avec treillis de ferraillage).

(Je pense que la partie émission radio est bien pour des contrôles ponctuels à distance, mais pas pour des enregistrements devant durer des heures).

15.1 Les paramètres utilisés

Ceci détermine directement les résultats sur les courbes, et il est ainsi facile de vérifier si le programme  effectue bien ce qui a été prévu.
Param_0E de 180 ; Dly Start pompe
Param_1E de 120 ; Dly vitesse lente à normale 10
Param_2E de 30 ; DLY Cte temps circulation  (mini EC) à 2L/mn 4
Param_3E de 7 ; Delta température start pompe
Param_4E de 2 ; Delta température passage vitesse lente
Param_5E de 5 ; Constante vanne L/seconde temps moteur
Param_6E de 2 ; Panel Area M² (modifié depuis en seuil pyrano)
Param_7E de 0 ; Réglages vanne
Param_8E de 10 ; DLY Start scan TX
Param_9E de 0 ; update jour mois année jour semaine
Param_10E de 0x65 ; Affichage default Index
Param_11E de 0x00 ; RS232 + Radio Y=1 N=0
Param_12E de 0x00 ; Save EEPROM
Param_13E de 23 ; Update time partie des heures
Param_13F de 35 ; Global Param_13 partie Minutes
Param_14E EQU $
 
Ecart_min_ph1E de 16 ; écart de T° mini phase 1 en 1024 (de base 12/1024)EEPROM
DLY_Tenta_ph1E de 120 ; Délai de reprise après échec température ph1 EEPROM
DLY_Reencl_ph2E de 120 ; délai de réenclenchement après arrêt pompe ph2 EEPROM
ADREGSOLE  de 0x45 ; Adresse 0X45  par défaut EEPROM

15.2 Les différentes courbes

Une majorité des courbes sont représentées en 1/1024, qui est l'unité de base du convertisseur du PIC. Il est facile d'appliquer les règles pour convertir en °C mais c'est par simple paresse que j'ai laissé en 1/1024. (Vous pouvez obtenir REGUL1_LOG2 les fichiers des courbes seulement au format ODS (OPEN OFFICE), car les tracés sont d'une qualité insuffisante )
D'autres informations binaires permettent de vérifier le fonctionnement relativement aux différentes conditions binaires (commandes de vanne avant/arrière et ON/OFF).

Reprenez la liste des éléments transmis par RS232 au paragraphe 13, il y a sur le graphique, 17 valeurs représentées…! C'est beaucoup mais on ne les regarde heureusement pas toutes ensembles !

COURBES 1 & 2  JOUR2

Certaines courbes ont trait à la température Extérieure qui ne nous intéressera pas dans l'immédiat, mais que l'on va traiter tout de suite pour ne plus y revenir. C'est la courbe violette en escalier qui est la valeur moyenne journalière. Cette allure d'une température moyenne est calculée toutes les heures comme on peut le vérifier par l'écart des paliers. Elle est conforme, et on constate donc des écarts importants au départ, qui s'amenuisent avec le nombre de mesures, ce qui semble parfaitement normal lors de l'intégration.
NOTA : Faute de sonde Extérieure dans l'instant, c'est une température intérieure de sous-sol qui est prise.

Courbe du Pyranomètre et Haut Panneau. La courbe verte foncé très hachée est celle du pyranomètre…Elle représente l'activité solaire dans une grande partie des longueurs d'ondes rayonnées. On peut constater les passages nuageux et évaluer combien cette activité thermique est variable. (Journée claire mais nuageuse)

Suite à ce qui avait été constaté la veille, la diode haut capteur a été simplement protégée du soleil direct par un carton entourant le collecteur et la diode (Courbe jaune). A priori on constate bien une diminution réelle du bruit de fond sur le capteur HP (Haut panneau), en fonction des grandes variations de puissance solaire, la supposition proposée semble donc bonne. Il restera à réaliser une meilleure fixation avec un contact thermique de qualité, à l'aide d'une pâte conductrice (Comme pour les transistors de puissance montés sur radiateur)

NOTA: la pâte conductrice thermique est aussi à réaliser pour toutes les autres prises de températures…c'est nettement mieux pour la précision, mais attention de ne surtout pas abuser, car l'effet serait inverse en augmentant l'inertie thermique. ("Coller" juste une génératrice de la diode)

On se rappelle du problème rencontré avec le capteur de débit qui a simplement été retiré pour cause de mauvais fonctionnement, et le débit a été remplacé par une valeur fixe de 1.39 L/mn. C'est la courbe Orange qui représente finalement l'activité de la pompe. La courbe couleur "prune" tout en bas du graphique est une réplique binaire de l'état du relais de pompe. Elle a le même profil que la courbe orange (Dans ce cas d'absence de mesure de débit)

D'autres valeurs binaires sont également représentées mais ne sont là que pour le contrôle à posteriori du programme, avec le voyant erreur, l'alimentation des capteurs, l'alimentation de la radio, l'état jour/nuit…
Concernant l'aspect erreur, une division par zéro peut provoquer une erreur. Il y a eu un palier anormal à partir de 16h36 qui a provoqué l'allumage de la LED erreur. Cela a disparu à l'appui sur les touches. Je ne sais pas expliquer cela pour l'instant.

Dans le processus de régulation lui-même, on peut constater l'évolution des 4 températures du process, et vérifier que les échanges sont toujours positifs.
On constate un point important qui est l'absence des "overshoot" comme il y en avait dans la régulation à deux sondes. Tout est laminé et je suis même un peu surpris moi-même car je pensais que ces rebonds seraient seulement atténués, mais pas réduits de façon si importante.

De ces courbes "process" on peut mesurer combien les tirages d'eau chaude sanitaire (ECS) ont une influence directe sur la régulation. Il n'y a pas deux situations identiques, et c'est pour cela que les températures au niveau échangeur sont si importantes. Ainsi on constate que le redémarrage vers 17:22 est principalement occasionné par un important tirage d'eau chaude vers 17:17 (Courbe Cuve "vert moyen" sur courbe N°2)

Voici les couleurs concernant les températures du process:
Jaune Haut panneau
Vert moyen Cuve
Prune EC échangeur cumulus
Bleu clair EF échangeur cumulus

Ainsi vous pourrez constater que la rencontre des courbes EC et EF provoque l'arrêt immédiat du  pompage.

Vous pourrez aussi constater qu'en période de faible énergie solaire, il y a tout de même des arrêts de pompage, mais que ceux-ci sont moins gênants, car ils dépensent moins d'énergie en overshoot, et on voit une certaine régulation dynamique avec la vanne, qui s'établit à partir de 17:30.
Par opposition on voit également que le matin, dès le début, il n'y a eu aucune régulation, car le pompage pouvait s'établir largement sans faire appel au débit réduit.

Pour la régulation proprement dite, vous vous souvenez que lorsque l'on trouve un écart suffisant entre la cuve et le haut panneau, on démarre la pompe. Cet écart qui était initialement à 7° a été augmenté à 8° pour assurer une meilleure stabilité et limiter les arrêts initiaux toujours gênants, car l'énergie matinale est toujours faible suite à une faible température extérieure qui augmente encore les pertes de démarrage.

COURBE N°3 JOUR 2 (Courbe dilatée au maximum)

Le délai de mise en marche a été porté à 120 secondes que l'on peut vérifier en courbe 3.
Pour comprendre ce qui se passe, les courbes, binaires (rouge) de sens de la vanne et (bleu moyen) de marche de la vanne sont très importantes. C'est ce couple de commandes qui va permettre de réguler correctement le débit et donc de réduire pratiquement à zéro, les overshoots de démarrage.

A 7 ou 8° d'écart, HP / Cuve, pompe à l'arrêt, on déclenche l'ouverture en plein de la vanne de régulation avec sens positif (ouverture) et commande moteur vanne.
120 secondes plus tard, on commande la pompe, et on peut voir que le mouvement de vanne est largement terminé à cet instant, ce qui n'aurait pas été un problème, car cela aurait eu en plus un certain effet d'amortissement.

Une minute plus tard correspondant à la constante de circulation, la vanne repasse cette fois en débit faible, pour laisser le temps au panneau de reprendre ses "esprits", car il a reçu de l'eau froide ayant séjourné dans les canalisations de retour EF. (Suivant les moments, cette eau réputée froide le matin, sera mitigée suite à un arrêt dans le courant de la journée, suivant le temps qu'elle aura passé en immobilité).

A 16:12 on constate que l'écart de température étant supérieur à 2°C entre EC et EF, on effectue cette fois la commande de mise en vitesse normale à 1.39 L/mn.
A 16:05, l'énergie n'est plus suffisante pour maintenir 2 ° d'écart au niveau échangeur. Aussi on repasse en vitesse lente. Puis le cycle se continue ainsi. A 16:22 et après un délai de 120 secondes, on tente une nouvelle fois le passage en vitesse normale qui fonctionne durant 3 minutes, puis s'écroule de nouveau à 16:25 etc…etc…

Cela représente tout l'avantage de cette régulation. On voit que l'on peut extrapoler largement vers une régulation de type PID ou encore plus finement vers une régulation procurant le maximum d'énergie à l'échangeur, mais pour cela il faut un capteur de débit correct et peut-être une mesure plus rapide du débit !

Ainsi que je l'ai déjà évoqué, je vais déjà faire fonctionner parfaitement celle-ci avant de me lancer dans le "futur plus que parfait".

Dans cette approche de vanne de régulation, on voit combien les courbes EC/EF sont modulées par les débits différents associés aux arrêts. On voit aussi que tout franchissement de l'écart à 0 provoque un arrêt immédiat, ce qui est le principe même de conservation de l'énergie acquise durant les heures de pompage, sur lequel aucune dérogation ne peut être admise.

15.3 Le pyranomètre

Il est pour l'instant plus "spectateur", mais je vois déjà son application à la lumière du graphique 1. En effet en dessous d'un certain seuil d'énergie solaire, mais aussi en fonction des différents écarts de températures, il serait utile, soit de ne pas redémarrer le pompage, soit de démarrer, mais sans jamais repasser en vitesse normale.
Ainsi les 4 mises en marche de fin de journée, bien que non déficitaires, pourraient être réduites à seulement à une ou deux je pense. (penser tout de même qu'il y a un temps d'absence de contrôle de température...)
Voilà donc une réponse pressentie et très utile à l'utilisation de ce pyranomètre.

Dans un premier temps, en dessous de 250 à 300 W solaires, je vais maintenir la vitesse lente et bloquer le passage en vitesse normale durant la phase 2, ce qui devrait à mon sens donner toute satisfaction en évitant une modulation trop en à-coups, et en permettant d'élever la température de l'eau du cumulus.
Le paramètre Param_6 de surface de panneau sera remplacé par le seuil du pyranomètre(seuil divisé par 2 pouvant donc aller jusqu'à 512 W, car les paramètres sont tous sur 8 bits)

15.4 La conclusion de ces essais

Certes il y a toujours des problèmes qui peuvent arriver ou qui ne sont pas élucidés, mais l'essentiel est acquis, et c'est cela le plus important. Dire que c'est parfait serait un "tantinet prétentieux", dire que ça parait bien, représente plus la réalité.
Enfin, je crois que le plus important repose sur le principe même qui permet de ne pas perdre d'énergie vers l'extérieur, et en ce sens, le contrôle au niveau échangeur me semble le point crucial de ce type de régulation.

Je crois en avoir déjà fait allusion, pour limiter la complexité au niveau électronique, il est possible de créer des sondes couplées par paires pour mesurer le différentiel HP/Cuve mais aussi le différentiel EC/EF.

Enfin, la dernière conclusion, et certainement la plus importante, est de placer le cumulus au plus près du panneau solaire comme je l'ai déjà signalé à plusieurs reprises, car il y a trop de pertes dans les tuyauteries.

Pour être encore plus précis sur ce sujet, je dirais qu'il est préférable de perdre de la chaleur pour alimenter un robinet d'utilisation, car la durée est limitée. (Alors que perdre de la chaleur durant tout le temps de pompage reste une perte énergétique très lourde ! C'est ma façon de voir les choses !)

Ce dernier paragraphe ajouté à cet article le terminera, et sauf problème majeur rencontré, il n'y aura plus d'autres nouveaux éléments.

Voici encore une dernière courbe qui manquait,avec le "réveil du panneau" le matin, …On y constate que les températures n'étaient réelles qu'à 9 Heures ce qui est un peu tard et qui est corrigé pour débuter à 7 heures.

On peut y voir aussi que vers 9h45 le panneau solaire a pris sa position de poursuite du soleil, et que cela se traduit par une montée spectaculaire de la puissance au pyranomètre, ce qui est normal.

Bien entendu et pour le feu d'artifice, la journée très ensoleillée n'a nécessité qu'une seule mise en marche de la pompe (contrairement à la veille). La modif du pyranomètre n'était pourtant pas encore présente à cet instant...!

La modification pour intégrer le pyranomètre est réalisée et est en cours d'essais. La modification a été insérée dans la phase 2 de surveillance, et juste en sortie du test de Vitesse Lente. A cette heure l'enregistrement est encore en cours. Le tracé fera peut-être l'objet  d'un dernier PNG d'ici quelques jours. (Le voici ci-contre)

On peut voir l'efficacité durant la phase 2, mais une idée me vient lors de l'arrêt de la pompe, et tout n'est peut être pas si rose que je le pensais, car les tuyauteries prennent la température à la hauteur correspondante de la cuve.

Ceci sera à "creuser" d'avantage, mais me conforte dans la nécessité de bloquer également un éventuel démarrage lors d'une faible puissance solaire.

Il est trop tôt pour conclure sur ce sujet, mais il faut y penser...et tout n'est peut-être pas si simple qu'il n'y parait...

                                             ---------------------------------

Pour donner encore quelques éléments nouveaux correspondant à l'analyse des courbes, voici celles du "jour 7" soit du 30 Avril 2011.

Le programme du PIC a encore subit une modification, cette fois le contrôle du pyranomètre a encore été ajouté avec un offset complémentaire lors de la mise en marche de la pompe durant la phase 1. Une constante de 70 1/1024, et donc de 70 WATTS est ajoutée uniquement lors de la décision de mise en marche de la pompe. Cela permet de passer outre les pertes initiales de lancement qui ne sont pas totalement résorbées lors de la mise ne circulation rapide du fluide primaire. Nous sommes en Version 18-6 du programme, et les paramètres ont encore été ajustés d'après les valeurs enrgistrées par la régulation elle-même. (Cette fonction intégrée est réellement nécessaire pour l'ajustage fin du paramétrage et du suivi) 

En voici la liste principale :

Param_0E de 180 ; Dly Start pompe Sec 55

Param_1E de 120 ; Dly vitesse lente à normale 10

Param_2E de 160 ; DLY Cte temps circulation  (mini EC) à 2L/mn 214

Param_3E de 8 ; Delta température start pompe

Param_4E de 3 ; Delta température passage vitesse lente

Param_5E de 5 ; Constante vanne L/seconde temps moteur

Param_6E de 90 ; Seuil pyrano/2 (sera multiplier par 2 dans les calculs =250)

Param_7E de 0 ; Reglages vanne

Param_8E de 10 ; DLY Start scan TX

Param_9E de 0 ; update jour mois année jour semaine

Param_10E de 0x65 ; Affichage default Index

Param_11E de 0x00 ; RS232 + Radio Y=1 N=0

Param_12E de 0x00 ; Save EEPROM

Param_13E de 23 ; Update time partie des heures
Param_13F de 35 ; Global Param_13 partie Minutes
Param_14E EQU $

Ecart_min_ph1E de 16 ; écart de T° mini phase 1 en 1024 (de base 12/1024)EEPROM
DLY_Tenta_ph1E de 150 ; Délai de reprise après échec température ph1 EEPROM
DLY_Reencl_ph2E de 120 ; délai de réenclenchement après arrêt pompe ph2 EEPROM
ADREGSOLE  de 0x45 ; Adresse 0X45  par défaut EEPROM
OFFSETPYRE  de 70 ; +70 W au démarrage de pompe

FTABLE  EQU $  ; Détermine la fin de table

Il y a eu durant cette journée un assez long passage nuageux/orageux. Vous trouverez en courbe ci contre, la fin de la période ensoleillée principale où l'on peut voir juste un peu avant 17:30 le passage en vitesse lente car l'énergie est insuffisante, puis finalement l'arrêt  par les courbes vert/jaune qui se touchent. (écart de température nul au niveau échangeur)

La courbe suivante devrait vous permettre de mieux appréhender le fonctionnement et les modifications de paramétrage.

Avant cela je dois de nouveau souligner le caractère éphémère de ce qui se passe au niveau d'un panneau solaire.
En effet les situations ne se reproduisent pratiquement jamais de façon identique, et il est donc nécessaire de trouver un juste milieu dans la régulation.
Tout est fluctuant et principalement le soleil qui ne brille pas en permanence, pas plus que l'utilisation d'ECS qui change suivant les heures et habitudes et qui est totalement asynchrone du rayonnement.

Etre trop restrictif conduit à ne pas récupérer toute l'énergie encore disponible. Etre "large" conduit à dissiper de l'énergie du cumulus vers le panneau. Je vais donc expliquer ce qui s'est passé durant cette reprise d'activité. (Si vous voulez faire un tirage de cette dernière courbe, ce sera plus clair).

Explications de la dernière courbe :

Au point 0, il s'est passé plusieurs choses concomitantes : Le soleil refait son apparition avec un assez bon niveau de puissance. Le capteur Haut panneau commence à se réchauffer. Vers 18h56 il y a un tirage d'ECS matérialisée par la baisse de la courbe rouge de température de la cuve. Ces 2 phénomènes inversent littéralement les deux courbes bleues et rouge et au point 0 l'écart de température nécessaire pour entrer en phase 1 de démarrage est atteint (8°C ou 65/1024).

Ainsi qu'il a été dit, la vanne de régulation en position fermée va s'ouvrir en plein pour éviter de refroidir au maximum l'eau du cumulus. Point 1 avec la dénomination "RAPID" pour préparer le débit Rapide. Après le délai de 180 secondes, (Param_0E) la pompe est mise en service et le débit primaire est établit. 160 secondes plus tard, on contrôle qu'il y a au moins 1.2 °C positif entre l'entrée échangeur et la sortie au point 2. On passe alors en vitesse lente pour laisser le temps au panneau de se réchauffer.
Malheureusement, au point 3,  lors de la phase 2, il y a rencontre des courbes verte/jaune EC/EF et donc l'écart de température est nul ce qui provoque l'arrêt immédiat de la pompe.

On reprend alors un nouveau cycle de démarrage avec le délai de 120 secondes de réenclenchement d'une phase de démarrage pompe. A ce moment, le panneau qui reste au calme de la circulation primaire par l'arrêt pompe "a repris quelques couleurs" et de même le tirage d'eau s'est stabilisé. Tous les éléments sont maintenant acquis pour un nouveau démarrage et on prépare de nouveau l'ouverture de vanne en grand (point 4).

Cette fois sera la bonne, et après les étapes identiques, on arrive au point 6 avec le passage en vitesse normale durant la phase 2. Il y a en effet plus de 2°C d'écart durant un très court instant, puisque les temps des points 6 et 7 sont à quelques secondes d'écart seulement.

Là aussi, on est encore tangent, mais comme on ne franchit pas un écart nul EC/EF, on continue en vitesse LENTE.

Après quelques minutes, un autre évènement vient modifier la situation, qui est un deuxième tirage d'ECS, qui va augmenter l'écart EC/EF et permettre au point 8 de repasser en vitesse normale.

Mais la journée s'achève et un nuage se présente faisant baisser l'énergie, et on repasse au point 9 en vitesse lente, que l'on ne quittera plus jusqu'à l'arrêt définitif par absence évidente d'énergie solaire au point 10. Le regain de soleil un peu après 19h40 n'est plus suffisant car les courbes vert/jaune se rapprochent et le point 10 est finalement atteint.
(Cette fois le troisième tirage d'ECS très petit n'a pas pu inverser la tendance)

Parmi les points à remarquer, on peut vérifier la constante de circulation point 11, qui est de 160 secondes, qui est bien réglée par valeur supérieure, car on obtient le petit écart positif de 1.2° au point 2.

Au point 10, on constate que la double condition énergétique de delta de température HP/Cuve ne sera plus jamais atteinte, car les courbes bleue/rouge convergent, et le seuil pyranomètre de 180 W n'est plus possible, car c'est a fin de journée.

Je considère ce fonctionnement comme répondant correctement au programme, et à ma vision pour moduler un peu et éviter des arrêts/départs trop fréquents, et il me semble difficile de trouver de façon non mathématique un meilleur compromis.
Comment faire encore mieux ? Peut être en travaillant sur la dérivée des différentes courbes et en régulant finement le débit par une régulation PID. (Je rappelle que la mesure du débit ne fonctionne pas correctement et qu'elle est abandonnée provisoirement).
Il faudrait aussi intégrer dans un savant "mix" l'énergie solaire, le tirage d'ECS, les températures absolues, les différents écarts de température et faire les prévisions pour des valeurs de temps supérieures à la constante de circulation. 

Dans l'immédiat, je suis arrivé à ce que je souhaitais, et il ne devrait plus rester beaucoup de "bugs". Je laisserai un message si j'en découvre encore. Par contre le paramétrage m'est spécifique et ne fera pas l'objet de corrections.

16 Les débits "câblés"

Je pensais en avoir fini avec cet article et puis j'ai eu quelques remords...C'est souvent ainsi, et le fait d'avoir dû abandonner (peut-être provisoirement) la mesure réelle du débit du fluide primaire, m'a laissé un parfum de "non achevé".

Alors parfois le fait de tomber sur un problème permet de mobiliser un peu plus d'énergie.
Aussi je me suis dit que si je n'arrivais pas à mesurer ce débit, j'avais pourtant tous les outils pour étalonner (c'est un bien grand mot !) le temps d'ouverture de la vanne de régulation et le débit.
Une première vérification en réel puis un assemblage de nouveau et quelques corrections pour implanter ces valeurs de référence, et le tour sera joué...

Fut-dit fut-fait, et voici cette fois les dernières courbes agrandies pour les parties intéressantes de la régulation proprement dit, où cette fois on voit le signal débit qui  change en fonction des commandes de vanne.
Courbes du matin et du soir seules utiles à représenter sur les graphiques
Ce n'est pas une question de beauté du graphique, mais seulement une question de justesse des valeurs d'énergie. En effet ce sont bien les valeurs réelles de débit et donc l'énergie se trouve ainsi plus précise

Alors j'ai assez commenté toutes les autres courbes, je vous laisse le soin de tout retrouver, mais pour vous guider, la courbe Cyan a donc un niveau 0, un niveau maxi pour le démarrage, un niveau faible, et un niveau de débit "normal".

Le niveau du pyranomètre était un peu trop optimiste et j'ai dû le diminuer car j'arrivais en saturation à 1023 W/M², ce qui n'est pas normal.
Au mieux d'après les calculs on peut obtenir pour mon site 1003 W/M² en journée ensoleillée (sans nébulosités) et cela à la date du solstice d'été du 21 Juin à 14 heures (heure d'été). Donc le nouvel étalonnage a été repris pour la date de réglage. (C'est moins bien qu'un étalonnage comparatif, mais pour l'emploi, cela semble suffisant)
Ceci est donc le dernier point corrigé.

Pour l'instant tout marche bien et ...me donne satisfaction...

____ (retour début d'article) ____

____ (retour accueil bricolsec) ____
____ ( retour accueil lokistagnepas) ____

Comments

[lokistagnepas]

bonjour,

Votre solution est également intéressante. J'ai retenu la solution "vanne" car j'espérais bien obtenir un jour la notion de débit de façon fiable avec un simple compteur d'eau.

Il n'y a pas eu de publication depuis de nombreux mois car je travaille à un capteur pour compteur ACTARIS qui me permettrait de faire une régulation à débit variable en continu, alors que j'ai seulement 2 paliers de vitesses à ce jour.

(Le point le plus important cependant reste la longueur du circuit primaire et ses pertes associées)

La régulation que vous entreprenez par relais static est bonne également en théorie,

mais je ne l'ai pas choisie car elle fait souffrir les pompes (en 220 V~) et reste délicate à mettre en œuvre.



Pour la régulation par relais static il vous faudra une régulation PID. Vous pouvez réfléchir à une régulation de ce type que j'ai réalisée pour une enceinte thermique, voir l'article sur ce sujet.

http://bricolsec.canalblog.com/archives/2013/01/13/26133974.html

Cependant une lampe de 100W n'a rien de mécanique comparativement à une pompe qui a une courbe de débit en fonction de la vitesse de rotation qui est très différente de la chaleur dissipée par la lampe. Vous devrez faire une étude complète assez délicate sur point d'étalonnage.

De plus en MLI, des impulsions de 1 ou 2 alternances risquent effectivement de griller la pompe. Donc la MLI devra avoir des seuils minis. De toutes façons, à ce stade le débit ne pourra être réalisé que par "bouffées" de plusieurs alternances espacées d'un certain temps...

Allez je ne vous décourage pas, et le sujet est intéressant, que ce soit avec PIC ou Arduino ou autre.

Merci des compliments et bonne chance.



Meilleures salutations

bricolsec



NOTAS : - Brider une pompe est une opération réalisée couramment en AEP et cela n'a pas à ma connaissance de conséquences sur la longévité des pompes (surtout pour les pompes d'exhaure).

- La variation de vitesse par la fréquence ne peut pas être permanente sur ce type de machine à service permanent.

[jc]

Bonjour,



Je suis impressionné par la réalisation et surtout les explications données.



Un peu d'histoire, celà fait maintenant 3 ans que je me suis lancé dans le solaire thermique. Etant en maison en location, j'ai les pieds et main liés sur tout les choix d'emplacements.



Ainsi, mon proto est entièrement démontable avec 3 clefs plates.. et l'installation d'origine peut être remise en service en 1h. Le panneau solaire (il n'y en avait qu'un), n'avait pas d'autre emplacement que devant la maison.. plein sud. Il avait des masques solaires en hiver.. (la cloture..), au printemps et en été, un arbre le matin, la maison qui déborde le soir... mais peu importe, je voulais toucher au sujet.. et je ne le regrète pas.



J'ai pas mal galéré en plomberie (la première fois de ma vie que je joue avec un chalumeau).. et je ne me sentais pas me lancer dans un projet de régulation (peur que ça tombe en panne en mon absence). J'ai donc acheté une régulation du commerce (et pas trop cher en plus.. de quoi me justifier le fait de ne pas la faire..)

La régulation avait un fonctionnement similaire à votre première.. 2 sondes.. quelques seuils.. et un fonctionnement On/OFF de la pompe (avec une fonction anti-gel).

Je suis comme vous, en eau claire.. mais je vidange en hiver pendant 2 mois.. car pas assez de couverture solaire pour justifier de refroidire l'ECS produite au gaz toutes les nuits.)



Au bout d'un été.. 1 panneau.. bof.. ça fait quelques 35° max dans le ballon en plein été.. bof bof.. vraiment.



J'ajoute un 2ème panneau... et là wouaaaaaaaaaaaaaaaaahhh.. enfin on frise la surchauffe en été.. avec une autonomie totale sur 4 mois.. pour un bricolage du dimanche, c'est juste.. magique.



Sauf que voilà.. masque solaire important le matin et le soir.. pendant 1h j'ai un fonctionnent avec un seul panneau le matin, et 1h l'après midi.



J'ai donc revu le système et cassé la tirelire.. et acheté une belle régulation pour gérer 2 circuits.. avec une régulation de vitesse des pompes.



Très très content de cette régulation.. sauf.. que je suis un bricoleur.. et j'ai pas la possibilité d'étudier en temps réel l'installation.



Je me suis donc lancé à la recherche d'une interface pour récupérer les infos.. j'ai trouvé.. mais finalement inutilisable.



L'avantage de mon installation : moins de 4m de tuyau pour aller aux panneaux, pareille pour le retour. 16mm partout, sauf sur la partie commune aux 2 circuits : 22.



Je me suis donc mis en tête de faire une régulation avec un Arduino (c'est un microcontroleur un peu comme un PIC).



Sauf que voilà... j'ai été fasciné par la gestion "PWM" qui n'est pas vraiment du PWM, mais une variation de vitesse par train de sinus.. (on fait ON sur quelques sinus.. on coupe.. on relance .. on coupe..)



Je me suis donc intéressé juste sur ce point, à comment on peut faire.. avec un microcontroleur.. y a peut de monde qui s'amuse à faire ça..



En fait, il faut utiliser un relai statique, car contrairement à un moteur à courant continu, on ne peut pas réduire la tension d'un circulateur pour réduire sa vitesse.. ça va légèrement marcher car on va légèrement augmenter le glissement.. et puis ça va finir par griller.



Le relais statique permet de commuter au passage à Zéro de la sinus (50Hz du 220V)... ce qui évite de faire du n'importe quoi sur le réseau éléctrique de la maison, et surtout évite de générer des perturbations élétromagnétiques. Enfin.. le fait d'envoyer du +220v -220v.. à des moments où le rotor n'a pas les pôles où il faut.. risque de réduire prématurément la vie du circulateur.



Le fait de faire des trains d'ondes sur le circulateur permet donc de faire varier la vitesse.. et permet d'économiser le prix d'une vanne motorisée.. et sa gestion..



Mon projet est en attente de l'hiver (je suis actif, et j'ai très peu de WE de dispo.. donc peur de péter l'installation si je n'ai pas le temps de terminer ce que je commence.) Cet hiver, l'installation sera couverte, et je pourrais faire quelques essais.. en laissant en plan tout le système si jamais pas le temps de fini.



Quand vous avez utilisé la vanne pour la réduction de vitesse, aviez-vous connaissance d'autres moyen de réduire le débit ?



Si vous aviez connaissance de l'utilisation de train d'ondes, quels seraient pour vous des avantages, ou des inconvénients par rapport à votre solution (que j'ai également envisagée (mais peut-être avec une 3 voies pour éviter de faire forcer la pompe, ou une soupape différentielle en parallèle de la pompe)



Certains disent qu'une régulation par train d'onde permet de réaliser des économies de courant, je m'interroge... car une pompe lancée en continue consomme sur son régime établit, une pompe relancée périodiquement doit travailler sur son régime transitoire.. qui consomme plus.



Encore une fois, je le répète, vos articles sont excellents, et ont le don de me faire bouillir la cocotte minute (très positif)

[lokistagnepas]

Bonjour,

Merci, il est vrai que le texte est dense et qu'il est difficile d'appréhender tout, d'un seul coup d'oeil !

En ce qui concerne le pilotage par PC du panneau, le fait est résolu par la réalisation d'une carte à base d'un PIC 16F886 et de sa programmation (8800 lignes de programme). Cette carte vient d'être installée il y a 8 jours et remplace avantageusement le vieux PC.

(Je suis en train de rédiger cet article qui va prochainement sortir sur ce blog).



Si cela vous intéresse également vous pouvez vous inscrire à la Newsletter pour les deux rubriques (Rassurez vous il n'y a pas de spam et juste une communication à chaque article et un petit mot une ou deux fois par année). Vous serez ainsi averti automatiquement des nouveaux articles.



En ce qui concerne votre réalisation, elle est certainement intéressante, et je veux bien recevoir votre description, et on verra ce qu'elle apporte et qui peut être utile aux lecteurs. Je vais prendre le contact avec vous par mail à l'adresse que vous avez laissé sur votre message

Meilleures salutations

bricolsec

[Richardel]

Bonjour,

Tout d'abord mes félicitations pour vos descriptions techniques des différents sujets de votre blog. c'est la troisième fois que je lis cet article sur la régulation pour toujours mieux comprendre et je ne m'en lasse pas.



Suite à une modification de mon installation solaire (ajout de deux cuves), j'ai construit une régulation similaire à la vôtre (et j'ajouterais même que seulement quelques mois de décalage séparent les deux réalisations).



Décrire ma réalisation serait trop longue ici mais peut-être pourrais-je vous l'envoyer ? Vous pourriez, peut-être, y puiser quelques idées ce qui ne serait que justice car votre article va me permettre d'améliorer certains points de mon programme.



Il est évident que si vous jugez une partie de ma réalisation intéressante, vous pourrez en parler sur votre blog (pas de droit d'auteurs :-)) et j'en serais même fier.

Envoyez-moi un petit e-mail a l'adresse ci-dessus, laissez moi quelques jours pour taper le résumé et je vous l'enverrais.



je pense, aussi, avoir une solution intéressante pour remplacer votre pc dont vous parlez dans l'article ( puissance équivalente mais 5W de consommation (ordinateur sheevaplug)). A titre d'info (je ne vends rien) http://fr.wikipedia.org/wiki/SheevaPlug



encore bravo pour votre blog.

[bricolsec]

Bonjour,

La question est abupte et ne souffre aucune dérobade ! Il ne faut pas oublier que je ne suis pas à votre service et que la politesse fait partie du dialogue.
Certains ont toujours du mal à comprendre voyez d'abord cet article pour plus de précisions :
http://bricolsec.canalblog.com/archives/2010/06/08/18190847.html

Ceci étant, je vais tout de même répondre car votre empressement sera au moins profitable aux autres lecteurs.
L'article sur la nouvelle régulation n'est pas très ancien et les données de retour restent restreintes, mais les voici :

date et Heures heures KWH/sem
24.04.2011 09:00 7,6
01.05.2011 08:00 7,.6
08.05.2011 08:00 9,0
15.05.2011 08:00 67,2
23.05.2011 08:00 137,4 5,162
30.05.2011 08:00 203,4 40,947
06.06.2011 08:00 247,8 24,774
13.06.2011 08:00 286,3 18,078
20.06.2011 08:00 340,1 20,770

Ceci concerne 2 M² de panneaux mobiles en poursuite du soleil et pour mes coordonnées de l'Est de la France.
(Avec le cumul des heures de pompage et les KWH par semaine aux dates indiquées)

J'espère que votre seul intérêt financier à été satisfait.
Evidemment je vous laisserai le soin de prendre le prix du KWH et d'effectuer vous même les calculs.
Meilleures salutations
bricolsec