Aidez nous ! Projet - Gestion domotique

[tochinet]

@zoroastre,

Quelques petits problèmes pour comprendre ton code et tes courbes : tu n'as pas défini tes variables (p.ex. "regulation" ou "seuil" ?)

En fait, je suis un trajet un peu parallèle et je te recommande d' éjecter les lectures extrêmes de tes capteurs. Perso, j'ai constaté un nombre important de lectures fausses, mais çà dépend évidemment de ton installation.

[zoroastre]

Yep!

tu n'as pas défini tes variables

Il s'agit plus de verbaliser des idées que de donner un code complet et précis.

Les variables 'regulation' et 'seuil' sont respectivement, une valeur fixe déterminant la température de chauffe maximale à T°+regulation ou T°+0.8 par exemple, et une consigne minimale d'enclenchement de la  chauffe, valeur évoluant au rythme des changements de mode de fonctionnement (confort, eco, ...).

Le problème de suivre la courbe est que l'on ne peut éviter des erreurs de lecture de la sonde. Déterminer la tendance en énumérant et comparant des moyennes, fussent-elles lissées ou non, conduit indubitablement à accepter une proportion d'erreurs.
La méthode de rejeter les extremums, comme je l'ai déjà dit, conduit à refuser une population qui peut être viable ou pas, et impacte directement sur la réactivité du processus de décision.

J'ai pour ma part rejeté le principe de suivre la courbe avec une comparaison de moyenne et m'oriente plutôt sur une methode se basant sur l'écartement entre le sommet de la courbe et la température mesurée. L'avantage principale est que l'on se rapproche du temps réel et, de plus, cette solution me semble universelle.

EDIT1:
Mon raisonnement :
Une moyenne incluera forcément des erreurs de lecture, qu'elles soient uniques ou multiples, la tendance sera faussée ou véritable. Il faut nécessairement la confirmer avant de dire au système, je suis en distribution ou en perdition de calories.
La principale composante est la sonde de température, j'utilise une DS18B20 qui, à une résolution de 12 bits, variera de +/- 0.06 (arrondi).
Si mon besoin est davoir au moins deux confirmations, cela me permet de dire qu'il me faut 2x0.06 °C de variation, soit 0.12 °C, pour conclure de l'état de ma courbe.
Cette variation doit être comparée à une valeur fixe ou déterminée. Le sommet de la courbe s'impose d'elle même dans cette optique.
L'interêt de déterminer le sommet de la courbe est qu'elle prendra de facto aussi bien la distribution active (en cours de chauffe) que la distribution passive (chauffage à l'arrêt).
Une fois que la coube commencera à s'infléchir, l'ecart grandira, il sera soit nul soit strictement positif.

Il faut que je reflechisse désormais à voir comment articuler cette méthode avec différents mode de fonctionnement et déterminer les seuils de décision, dont :
 - Si la température est sous la consigne : il faut être plus réactif = ecart plus faible.
 - Comment interpréter les apports calorifiques dû à l'ensoleillement par exemple.
 - Determiner un gain en mode confort uniquement ?

Tres simplement :

Code: [Select]


float HYSTERESIS = 0.2;
float sommetCourbe, ecart;

if (temperature != DEVICE_DISCONNECTED) {

sommetCourbe = max(sommetCourbe, temperature);
ecart = (sommetCourbe - temperature);

if (ecart >= HYSTERESIS) { perdition = true; }
else { perdition = false; }
}
if ((temperature < consigne_courante) && (perdition == true)) {
chauffage = "on";
if (chauffage =! chauffage) { sommetCourbe = 0.0; }
}



@+

Zoroastre.

[Skuzmitoo]

Il y a une librairie pour faire de la régulation PID. As-tu déjà regardé de ce coté (toi ou quelqu'un d'autre)?
En tout cas super pour les courbes c'est plus parlant comme cela.

[zoroastre]

Yep!

Une régulation PID n'est pas adapté à une régulation de chauffage Tout Ou Rien. Ce type de régulation est idéal pour maintenir une charge, par example contrôler l'ampérage d'une résistance chauffante pour accrocher une température précise. Si on est en dessous de la température, on augmente l'ampérage et inversement.
Il faudrait pour que je puisse utiliser ce type de régulation avoir une vanne 3 voies proportionnelles et ainsi contrôler la température du fluide. C'est le principe de l'aquastat.
Mon système de chauffage est contrôlé par un relais simple, on ferme le contact, le circulateur et les brûleurs s'activent, on ouvre le contact, tout s'arrête.
Pour qu'une régulation PID puisse être efficace, il faut une cible constante, les fonctions intégration et dérivé servant à réduire l'hysteresis entre l'appareil de puissance et la lecture de la sonde.

Il est vrai que le terme régulation est peut être mal adapté à ma situation et à tout ceux qui ont un système de chauffage 'archaïque'. Les thermostats modernes d'ailleurs utilisent allégrement les mots régulation PI/PID/RST, auto-adaptation, logique floue, etc...et j'aurais été heureux d'apporter une modèste pierre à cet édifice, tant il y a peu de ressources dans ce domaine.

Je ne vois pas comment apporter une régulation de ce type à mon projet, mais je peux me tromper

@+

Zoroastre.

[zoroastre]

Yep!

Pour revenir une dernière fois sur la régulation, cela fait quelques temps que je lorgne sur la logique floue. L'énorme avantage est qu'il n'est pas nécessaire de construire de savants algorithmes pour avoir quelque chose qui marche. Il suffit de dire ce que l'on attend du système pour ensuite traduire le verbe en données exploitables par celui-ci.
Suivre la courbe n'est pas satisfaisants et s'assujetir uniquement aux consignes revient à négliger l'hysteresis entre la commande et l'apport réel de calories (disribution active + passive).
L'hypothèse de départ est d'associer ces élements et de leur apposer un poids. Ainsi chaque élément pouvant influancer le rythme de chauffe a sa propre mesure et son importance. La consigne conserve son importance, mais elle sera quelque peu nuancée en fonction de la température exterieure et du flechissement de la courbe de chauffe.
Le régulation d'un chauffage central n'est pas une chose aisée, je vous présente déjà ma 3eme version.

Principe :
J'ai 3 élements : la consigne, la température exterieure, l'ecart par rapport au sommet de la courbe.
Pour chacun des élements, j'ai dréssé un tableau, par exemple pour la consigne, la température est LOIN de la consigne, MODERE ou PROCHE, la température exterieure, FREEZE pour en dessous de zero, COLD, WINTER,etc, pour l'ecart, j'ai une approche plus probabilistique, ecart +1, +2, +3, +4, plus l'ecart monte plus je m'apprioche de la certitude que la courbe flechit.
Grosso modo, si je suis PROCHE de la consigne et que la température exterieure est FREEZE et que j'ai une ou deux confirmation que la courbe à bien flechis à un instant indéterminé, ALORS je chauffe.

Cette methode à l'avantage d'être réactive et de pouvoir émettre des règles d'anticipation si besoin.

La partie le plus compliqué est de rendre des valeurs à la pensée. C'est pourquoi, j'ai utilisé un poids, respectivement 0.7, 0.15 et 0.1 pour la consigne, la temperature exterieure et l'ecart. Bon çà fait pas 100%, mais mon tableau (en pièce jointe) respecte mes attentes.

J'ajoute également un petit code c++ qui fera office d'illustration. Il est possible de modifier la consigne et la température exterieure en fonctionnement, il suffit pour cela d'envoyer *e;#! ou *c;#! en remplacant le # par une valeur intégrale ou flottante. La sonde de temperature et le chauffage sont simulés.

La régulation n'est pas une mince affaire !!! Perso je galère grave docteur !
Et j'attends avec plaisir vos remarques, recommendations, villipendages

@+

Zoroastre.

Code: [Select]

/*
REGULATION
*/

#define STARTBIT '*'
#define STOPBIT '!'
#define BUFFERSIZE 96
char buffer[BUFFERSIZE + 1];
char* TRAME[4];

const float POIDS1 = 0.7; /* CONSIGNE */
const float POIDS2 = 0.1; /* PROBABILITE DEPERDITION CALORIFIQUE */
const float POIDS3 = 0.15; /* TEMPERATURE EXTERIEURE */

float CIBLE[5][3] = {
{ -127.0, 0.0, POIDS1*100 }, /* UNDER */
{ 0.0, 0.1, POIDS1*100 }, /* TOUCH */
{ 0.1, 0.2, POIDS1*86 }, /* NEAR */
{ 0.2, 0.3, POIDS1*80 }, /* MEDIUM */
{ 0.3, 127.0, POIDS1*0 } /* FAR */
};

float PROBABILITY[5][3] = {
       { -127.0, 0.0, POIDS2*0 },
{ 0.0, 0.1, POIDS2*10 }, /* ECART P1 */
{ 0.1, 0.15, POIDS2*30 }, /* ECART P2 */
{ 0.15, 0.2, POIDS2*80 }, /* ECART P3 */
{ 0.2, 127.0, POIDS2*100 } /* ECART P4 */
};

float EXTERIEUR[6][3] = {
{ -127.0, -2.0, POIDS3*100 }, /* FREEZE */
{ -2.0, 2.0, POIDS3*80 }, /* COLD */
{ 2.0, 6.0, POIDS3*60 }, /* WINTER */
{ 6.0, 10.0, POIDS3*40 }, /* AUTOMN */
{ 10.0, 16.0, POIDS3*20 }, /* SPRING */
{ 16.0, 127.0, POIDS3*0 } /* SUMMER */
};

const int longueurTable1 = sizeof(EXTERIEUR)/sizeof(EXTERIEUR[0]);
const int longueurTable2 = sizeof(CIBLE)/sizeof(CIBLE[0]);
const int longueurTable3 = sizeof(PROBABILITY)/sizeof(PROBABILITY[0]);

float sommetCourbe, ecart, temperature = 19.0, temperature_ext = 4.0, consigne = 18.4;

boolean regulation;
int chauffage, compteur;
int value1, value2, value3;

void setup() {
Serial.begin(9600);

regulation = true;
chauffage = -1;
compteur = 0;
 }

void loop() {
 
 checkMsg();

 sommetCourbe = max(sommetCourbe, temperature);
 
 if (regulation) {
   
   ecart = (sommetCourbe - temperature);

   for (int i = 0; i < longueurTable1; i++) {
if ((temperature_ext > EXTERIEUR[i][0]) && (temperature_ext <= EXTERIEUR[i][1])) { value1 = EXTERIEUR[i][2]; }
   }

   for (int i = 0; i < longueurTable2; i++) {
if (((temperature - consigne) > CIBLE[i][0]) && ((temperature - consigne) <= CIBLE[i][1])) { value2 = CIBLE[i][2]; }
   }

   for (int i = 0; i < longueurTable3; i++) {
 if ((ecart > PROBABILITY[i][0]) && (ecart <= PROBABILITY[i][1])) { value3 = PROBABILITY[i][2]; }
   }

   if ((value1+value2+value3) >= 80) { chauffage = 1; }
   else { chauffage = -1; };
 }
 
 Serial.println("################################");  
 Serial.print("value1 = "); Serial.println(value1);
 Serial.print("value2 = "); Serial.println(value2);
 Serial.print("value3 = "); Serial.println(value3);
 Serial.print("total = "); Serial.println((value1+value2+value3));
 Serial.print("temperature is "); Serial.println(temperature);
 Serial.print("chauffage is "); Serial.println(chauffage);
 Serial.println("################################");
 
 delay(5000);
 
 if (chauffage == -1) { temperature = temperature - 0.06; }
 if (chauffage == 1) {
   sommetCourbe = 0.0; regulation = false;
   temperature = temperature + 0.2;
   compteur++;
   if (compteur >= 5) { chauffage == -1; compteur = 0; regulation = true;}
 }

}

void checkMsg() {
 if (getSerialString()) {                                                  // On verifie que la trame soit complete
   filldata(buffer);                                                       // On remplit la structure des donnees
   checkdata();                                                            // On renseigne les variables modifiees
 }
}

boolean getSerialString() {
 int dataBufferIndex = 0;
 boolean storebuffer = false;
 delay(20);
 if(Serial.available() > 1){
       char incoming = Serial.read();
       if(incoming==STARTBIT){
           dataBufferIndex = 0;                                            //Initialize our dataBufferIndex variable
           storebuffer = true;
       }
       if(storebuffer){
         while(Serial.available()){
           char incoming = Serial.read();
           delay(50);
           if(dataBufferIndex == BUFFERSIZE){dataBufferIndex = 0; break; }
           if(incoming == STOPBIT) {buffer[dataBufferIndex] = 0; dataBufferIndex = 0; storebuffer = false; return true; }
           else { buffer[dataBufferIndex++] = incoming; }
         }
       }
 }
 return false;
}

void filldata(char *buffer) {
 char *p = buffer;
 char *str;
 int i = 0;
 while ((str = strtok_r(p, ";", &p)) != NULL) {                             // delimiter is the semicolon
   char *q = str;
   TRAME[i] = q;
   i++;
 }
}

void checkdata() {
 if (strcmp(TRAME[0], "c") == 0) {
   if (strcmp(TRAME[1], "#") != 0) { consigne = string2float(TRAME[1]); Serial.print("RECU c: "); Serial.println(consigne); }                        // Auto update Time
 }
 if (strcmp(TRAME[0], "e") == 0) {
   if (strcmp(TRAME[1], "#") != 0) { temperature_ext = string2float(TRAME[1]); Serial.print("RECU e: "); Serial.println(temperature_ext); }                        // Auto update Time
 }
}

float string2float(char* data) { return atof(data); }

[Brisebee]

Bonjour,

Je reviens vers vous, après avoir fait pas mal d'essais sur les différents éléments : Ethernet shield, NAS, serveur web, ... (il me manque encore les capteurs DHT11, que je n'ai pas encore reçu).
J'ai pratiquement pu valider toutes mes orientations générales.
Voici en pièce jointe un schéma global qui décrit l'architecture fonctionnelle que je vais très probablement adopter.
Je suis à l'écoute de vos remarques et suggestions.

[zoroastre]

Yep!

Brisebee, pourquoi les dht11 et le pluviomètre ne sont pas reliés directement à leur unité de commande

Il serait également interessant de descendre le shema d'un niveau supplémentaire, avec les pièces de ta maison et la totalité des équipements, cela permettrait de vérifier la concordance de l'ensemble (ULN2803) et d'estimer les longueurs de cable.

Ton shema est semblable à une topologie réseau, pourtant je ne vois pas le bus qui permet de communiquer entre les arduino ?

Le circuit d'interfaçage va requerir également un peu plus de détails techniques (nombre d'uln, ampage de pilotage, en parallèle ).
Les opto sont là pour quoi ? Pour l'isolation ou pour transmettre (et quelle genre d'information ?).

Voilà un petit panel de question qui me trotte, là, tout de suite, dans la tête Et ce doit être certainement les élements sur lesquels tu doit travailler en ce moment.

En tout cas, bravo et bon courage

@+

Zoroastre.

[Brisebee]

Merci zoroastre pour tes remarques.

pourquoi les dht11 et le pluviomètre ne sont pas reliés directement à leur unité de commande

Pour ce qui concerne les DHT11 ils servent uniquement à donner une information, à l'écran, sur la température générale et l'hygrométrie de la maison d'une part, et de l'atelier d'autre part, ils n'interviennent pas dans la "gestion automatique" du chauffage, puisque les thermostats et les radiateurs existants sont équipés de leurs systèmes de "régulation" propres. Les deux DHT11 devraient être implantés à moins de 20m de l'unité de gestion, donc selon les données constructeur cela ne devrait pas poser de problème.
Pour ce qui concerne le pluviomètre, je ne l'ai pas encore acheté, (je ne sais donc pas comment il fonctionne réellement). L'unité de commande arrosage existe, telle qu'elle est elle n'est pas prévue pour recevoir les informations d'un pluviomètre. Ce n'est qu'en mode automatique, donc en étant piloté par l'Unité de gestion, que les informations du pluviomètre seront prises en compte. Mon système d'arrosage fonctionne depuis plus de quinze ans sans pluviomètre, c'est vrai que ce n'est pas optimum, mais ce n'est pas dramatique, puisque je puise l'eau sur un forage.

Ton shema est semblable à une topologie réseau, pourtant je ne vois pas le bus qui permet de communiquer entre les arduino ?

Pour l'instant, et dans l'état actuel de mon projet, je n'ai besoin que d'un seul arduino Mega qui correspond à l'unité de gestion.
Mais je me laisse la possibilité d'utiliser un second arduino pour une unité de commande déportée, ou nécessitant un processeur, mais ce sera une évolution non prévue encore (dans ce cas la liaison se fera en RS485).
En attendant, je mets de coté car j'ai suffisamment à faire.

Le circuit d'interfaçage va requerir également un peu plus de détails techniques (nombre d'uln, ampage de pilotage, en parallèle ).
Les opto sont là pour quoi ? Pour l'isolation ou pour transmettre (et quelle genre d'information ?).

Effectivement je n'ai pas encore fait le point exact des E/S nécessaires, je ne sais pas encore si je vais systématiquement reboucler les sorties sur des entrées pour pouvoir lire l'état des sorties même en cas de forçage manuel ou pas. Je ne sais pas encore comment relier les DHT11, ni le pluviomètre.
Les opto-coupleurs sont existants sur mon système actuel, et je me pose la question de réutiliser la carte existante ou si je vais en refaire une, en fait cela dépendra beaucoup des décisions prisent par rapport aux questions précédentes, ils servent effectivement à isoler les entrées et à protéger l'unité de gestion. Chaque unité de commande a son alimentation propre, seul le 0V est commun, ce qui réduit la sensibilité des entrées par rapport aux diverses perturbations transmises par les câblages.

[osaka]

Yop Yop,
zoroastre on vois que tu connais bien ton sujet concernant la régulation, si je comprend bien c'est basé sur la probabilité et prévision ?
BriBri vivement les détails de chaque unité  .
Pour ma part je travailles sur le bus rs485 et j'ai déjà quelques résultat intéressant (half 2 fils et full duplex 4 fils), également de bon résultat sur le multi-processor Communication Mode des atmega sur un mega et 3 mini.
Un seul frein à la bonne continuation de mes testes c'est le temps d'attente du matériel commandé sur le web .
(si quelqu'un sait où je peux trouvé une boutique (physique) qui vende des sn75176 en BE du côté du brabant wallon  ).

[Artouste]

(si quelqu'un sait où je peux trouvé une boutique (physique) qui vende des sn75176 en BE du côté du brabant wallon  ).

au plus pres chez Elecdif Chnord ? 
http://www.electronique-diffusion.fr/advanced_search_result.php?keywords=sn75176&x=8&y=8
Dunkerque
- Wervicq (pas sur qu'il y ai une boutique)
- Villeneuve d'Ascq
- Lens

téléphoner avant pour s'assurer de la dispo (reserver) et si c'est comme pour Paris(Malakoff) si pas dispo en boutique, "ils" commandent et c'est dispo sur site qq jour après. (pour Paris c'est le mercredi pour commande jusqu'au samedi precedent )

[zoroastre]

Yep!

Tiens "brabant wallon" c'est du côté de Dunkerque

Mes sn75176, je les aies acheté chez electronique diffusion sans réservation ni coup de téléphone, ni rien, ils ont à priori un stock, que je pensais juste réservé pour moi seul  XD

@+

Zoroastre.

[osaka]

Tiens "brabant wallon" c'est du côté de Dunkerque

Juste un poil moins de 200Km  , merci quand même Artouste  .

[Artouste]

Tiens "brabant wallon" c'est du côté de Dunkerque

Juste un poil moins de 200Km  , merci quand même Artouste  .

J'ai mis ce qu'il y avait au nord ... de la seine 
Et puis Nivelles Lille (villeneuve d'ascq) ça fait à vol de coq moins de 100km 
Bon d'accord,  ce n''est pas ce qu'il y a de plus ecolo et économe comme solution pour recuperer qq SN75176 

[zoroastre]

Yep!

Pour répondre à ta question Osaka,

...si je comprend bien c'est basé sur la probabilité et prévision ?

La régulation s'effectue en 3 étapes.

Tout d'abord, on situe la temperature par rapport à la consigne grace à des bornes.
 - Si la temperature est entre la consigne et la consigne+0,1, on est TRES PROCHE.
 - Si la temperature est entre la consigne+0,1 et la consigne+0,2, on est PROCHE
 - et ainsi de suite...

On fait de même avec la temperature exterieure.
 - Si la temperature exterieure est en dessous de zero, on est GELE.
 - Si la temperature exterieure est entre 0 et +5, on a FROID.
 - et ainsi de suite.

Pour l'inertie, l'approche par la moyenne ne me satisfaisant pas, j'emets d'autres hypothèses dont, le sommet de la courbe et l'ecart entre celui-ci et la temperature.
Les sondes DS18B20, à une résolution de 12 bits, ont, arrondi, une variance de +/-0.06 °C.
Ainsi :
 - Si l'ecart est de 0.06, la certitude est PLUTOT FAIBLE.
 - Si l'ecart est de 0.12, la certitude est PROBABLE.
 - Si l'ecart est de 0.18, la certitude est PROPAGEE.
 - Si l'ecart est de 0.24, la certitude est PLUS QUE PROBABLE.
Cette solution a le merite de partir de données certifiées, c-a-d, le sommet de la courbe et l'ecart. De plus, ces valeurs ne sont pas trop compliquées à déterminer. Contrairement à la moyenne, lissée ou non.
J'ai une autre idée en tête, determiner la valeur max de l'ecart, normalement toujours constant en déperdition, et placer d'autres bornes servant à repérer les hypothétiques distributions calorifiques dû au soleil par exemple.
Importer les conditions météorologiques est une autre solutions, sachant qu'elles sont plutôt favorable l'aprés midi en cas d'ensoleillement.

L'étape suivante est de donner un poids à chacun de ces éléments de par leur importance. Ainsi, la consigne est essentielle et se voit attribuée une note élevée. La temperature exterieure et l'inertie ont une note plus faible, mais qui peut avoir son importance dans des situations précises.

En mélangeant tout çà, on arrive à obtenir un tableau correspondant au fonctionnement du chauffage dans différentes circonstances. Si des valeurs sont erronnées, on ajuste certaine note jusqu'à arriver au fonctionnement voulu. C'est un peu la soupe, car empirique, mais une fois que les règles sont établies et les notes attribuées, ben çà marche.

Il y a ensuite deux méthodes d'ecritures possibles pour le code, soit on repertorie les règles qui marchent et on les écrit une à une, soit comme dans mon exemple, on ecrit les tableaux, les bornes et leurs notes et on prend en compte tous les cas.
Cette seconde méthode me plait plus, car il sera possible à l'utilisateur de choisir si il désire prendre en compte ou pas la temperature exterieure par exemple et ainsi donner plus de poids à la consigne et se soustraire des anticipations de chauffe lors de grand froid. Il sera possible de définir des réglages avancés sans trop rentrer dans le détail, du genre MODE 1 { CONSIGNE SEUL }, MODE 2 { ANTICIPATION FORT }, etc...

@+

Zoroastre.

[Artouste]

Pour l'inertie, l'approche par la moyenne ne me satisfaisant pas, j'emets d'autres hypothèses dont, le sommet de la courbe et l'ecart entre celui-ci et la temperature.
Les sondes DS18B20, à une résolution de 12 bits, ont, arrondi, une variance de 0.06 °C.
Ainsi :
 - Si l'ecart est de 0.06, la certitude est PLUTOT FAIBLE.
 - Si l'ecart est de 0.12, la certitude est PROBABLE.
 - Si l'ecart est de 0.18, la certitude est PROPAGEE.
 - Si l'ecart est de 0.24, la certitude est PLUS QUE PROBABLE.

juste sur ce point , attention avec les DS18B20 (et d'ailleurs les capteurs T° courants surtout ceux emportant de l'AD)
Si la résolution est de 0.0625° la precision elle n'est au mieux que de +/- 0.5° sur la gamme "courante -10 +85 °" et +/- 2° sur les bords extrêmes de la gamme.
J'ai fait il y a déjà quelques temps des tests "de pure curiosité" en enceinte climatique de deverminage, la variation rendue n'est pas toujours dans le sens de la variation effective ou en régime stabilisé, il faut tenir compte de certaines aberrations due à la conversion A/D.
Jouer là sur les 2 bits de poids faibles (résolution de 4 * 0.6xx) me semble "illusoire" .
mais ceci n'est là à ce stade que mon approche de la méthode fuzzy logic envisagée !