Aidez nous ! Projet - Gestion domotique

Bonsoir,

Les ampoules à économie d’énergie peuvent être commandées par un triac mais uniquement en tout ou rien, elles sont généralement spécifiées “non dimmable” ce qui signifie qu’elle ne peuvent être modulées par un variateur équipé d’un triac qui fait varier l’angle de passage du courant pour diminuer la valeur efficace.
Seules les lampes halogènes (encore autorisées…) permettent de les connecter à un variateur.

Que les lampes à économie d’énergie rayonnent un champ électromagnétique, c’est normal puisqu’elles contiennent un convertisseur haute fréquence. Par contre, je ne vois pas pourquoi ce champ serait dépendant du sens de connexion à la phase et au neutre…

Je me posais également cette question sur les lampe à économie d'énergie et la variation, il semble y en avoir de plus en plus avec cette possibilité. exemples : http://www.produits-economiques.com/produkt.php?lang=fr&pm_id=1495 http://www.produits-economiques.com/products/stufenlos_dimmbare_esl.php?lang=fr

Ca devrait passé non ?

Post précédent apparemment pas envoyé ce W-E.

En ce qui concerne le stockage des données du programme pour les plages horaires, pour un MEGA je recommande vraiment l'EEPROM : facile à utiliser, largement assez grand (4K), fiable, et surtout, limite les dépendances (tant des librairies que de "l'environnement").

La carte SD, c'est peut--être plus pratique, mais il faut alors aussi inclure dans le sketch toute une série de "précautions" : que faire si elle est absente lors d'un reset, comment détecter le changement, quid des erreurs de format dans le fichier, etc.

Evidemmmnt, on peut rajouter un système de commande déporté avec site web, mais il faut plus voir çà comme de l'OAM (gestion des opérations), çà doit pouvoir "foirer".

A noter au sujet des ampoules économiques et dimmer : j'ai expérimenté à ce sujet, et si les halogènes sont bien dimmables, ce n'est pas à recommander : J'ai une suspension avec 6 lampes 220V G9, dimmée, et deux appliques assorties (une ampoule) non dimmées. La durée de vie des ampoules dimmées est bien inférieure aux autres. J'ai lu quelque part qu'il fallait faire tourner les ampoules halogènes à 100% régulièrement pour redéposer les particules gazeuses sur le filament, ou quelque chose comme çà. Pour en terminer sur les halogènes : le rendement des 12V est supérieur à celui des ampoules 220V, même en tenant compte des pertes du transfo.

Pour les TL dimmables, pas trop recommandé non plus : plus de scintillement visible, et perte sensible d'efficacité, car la lampe à 80% de puissance a probablement perdu 50% de lumière émise.

En plus, les dimmers coûtent cher, et chauffent, donc durée de vie limitée aussi.

Au sujet des LED, méfiance : toujours se rappeler que la LED n'est que 10x plus efficace que l'incandescence. Donc une 'super LED' 3W ne brille que comme une ampoule 30W.

Conclusion : mieux vaut éviter les dimmers, et choisir la source de lumière adaptée (luminaire, ampoules) pour la faire fonctionner à 100%.

Bonsoir tochinet,

tochinet: J'ai lu quelque part qu'il fallait faire tourner les ampoules halogènes à 100% régulièrement pour redéposer les particules gazeuses sur le filament, ou quelque chose comme çà.

J'ai lu ça également, maintenant on ne demande de la gradation que pour quelques postes genre salon et pas toute la maison, pour par exemple quand on visionne un film ou faire un gros câlin :* donc dimmé que rarement finalement (ça dépend du nombre de gros câlins :grin:) le reste du temps éclairé à 100%. Par contre si c'est pour économisé de l'énergie ou autre constamment, là en effet c'est pas conseillé, enfin c'est plus du luxe quoi. ;)

Yep!

Pour revenir un peu sur une régulation tor du chauffage central, voici 1 semaine que je ‘monitore’ mon installation et je tenais à vous faire part de mes conclusions.

Le principe de mon programme original était de déterminer les moments d’inertie de l’air ambiant et de poursuivre, à l’aide de la moyenne de 5 températures, la courbe de température. Les temperatures étaient initialement stocké dans un tableau à une frequence de 4 minutes, soit 4x5 = 20 minutes, puis la moyenne était effectué. Ce délai de 20 minutes m’a confronté à une incohérence et je me suis retrouvé avec 2 enclenchements conséqutifs de mon chauffage central. En effet, l’information d’état inertiel demeura en perdition d’un cycle à un autre, ce qui me permetta de conclure que la frequence de 4 minutes était trop importante et ne permettait pas la réactivité requise, 35 minutes de chauffe sur 40.

La solution la plus simple serait de réduire la frequence de remplissage du tableau, cependant, une trop grande réactivité ne permet pas de réagir face aux variations multiples. C’est pourtant la methode que j’utilise actuellement avec une légère pondération afin d’éviter de trop grande fluctuation.

Une idée du code :

if (temperature1 != DEVICE_DISCONNECTED) {
                    total = total - comparateur[index];
                    comparateur[index] = temperature1*100;
                    total = total + comparateur[index];
                    index++;
                    if (index >= ROW) {
                      index = 0;
                      average = total/ROW; 
                      if ((average - prev_average) >= 5) { inertie = 1; }                              // DISTRIBUTION
                      else if ((average - prev_average) <= -5) { inertie = -1; }                       // PERDITION
                      else if (((average - prev_average) < 5) && ((average - prev_average) > -5)) { inertie = 0; } // STABLE
                      prev_average = average;
                    }
                  }

Mes différentes simulations me démontrent que les valeurs actuelles suivent correctement la courbe de chauffe, elles sont, par contre, plus d’ordre impulsionnelles et considèrent assez peu dans certain cas une distribution inertielle passive.
Afin d’optimiser ma régulation, je suis donc obligé de considérer une autre stratégie. L’idée de suivre la courbe de chauffe au plus prés est plutôt bonne, mais pas suffisante. Les impulsions doivent être filtrées.

J’ouvre donc une reflexion dans ce sens :

/*
REGULATION
	- determiner sommetCourbe
	- tableau 5 temperatures, freq = 1/mn
	- moyenne 5 temperatures = pulse 1, 0, -1 
	- pulse -1 --> calcul differenciel sommet/temperature
*/

#define HYSTERESIS 0.2

void setup() { }

void loop() {
	if (temperature1 != DEVICE_DISCONNECTED) {
		total = total - comparateur[index];
		comparateur[index] = temperature*100;
		total = total + comparateur[index];
		
		sommetCourbe = max(sommetCourbe, temperature);
		
		index++;
	
		if (index >= ROW) {
			index = 0;
			average = total/ROW; 
			if ((average - prev_average) > 0) { 
			pulse = 1; 
			}
			else if ((average - prev_average) < 0) { 
			pulse = -1; 
			}
			else if (average - prev_average) == 0) { 
			pulse = 0; 
			}
		prev_average = average;
		}
	}
	
	if (pulse == 1) { 
	}
	
	if (pulse == -1) { 
		
		ecart = (sommetCourbe - temperature);
		
		if (ecart >= HYSTERESIS) {
			amplitude = (sommetCourbe - seuil); 
			pourcentage = (int)((ecart*100)/amplitude);
			
			if (pourcentage >= 90) && (exterieure = "TRES FROID") { 
				anticipation = true;
			} 
			
			perdition = true; 
		}
		else { 
			perdition = false; 
		}
	}
	
	if (pulse == 0) { 
	}
	
	if (((temperature < seuil) && (perdition == true)) || (anticipation = true)) { 
		chauffage = "on";
		if (chauffage =! chauffage) { flipon = true; }
	}
	
	if (temperature > (temperature + regulation)) {
		chauffage = "off";
		if (chauffage =! chauffage) { flipoff = true; }
	}
	
	if (flipon == true)  {
		//gain = consigne - sommetCourbe;              // bascule mode ???
		sommetCourbe = 0.0;
		flipon = false;
	}
	
	if (flipoff == true) { 
		flipoff = false;
	}

}

Une fois que l’on a déterminer le sommet de la courbe, de nombreuse choses sont possibles.

@+

Zoroastre.

zoroastre: La solution la plus simple serait de réduire la frequence de remplissage du tableau, cependant, une trop grande réactivité ne permet pas de réagir face aux variations multiples. C'est pourtant la methode que j'utilise actuellement avec une légère pondération afin d'éviter de trop grande fluctuation.

bonjour il te faut peutre faire du pseudo filtrage num les solutions les plus simples avec un "arduino" : moyenne sur n-2 échantillons après éjection des 2 valeurs extrêmes des échantillons, une profondeur de 5 est couramment utilisée. là ça ejecte bien les pics en aberration ou le plus utilisé en lissage simple T° lissée =0.85 de n +(0.15 de la moyenne des n prédécesseurs= n-1,n-2,...n-x)

Yep!

Merci Artouste pour ces pistes.

La première solution ejectant les extremums ne me plait guère. Elle consiste en définitive à supprimer une population représentative ou pas. J'avais envisagé la seconde solution avec un rapport 2/3 1/3, elle me semble beaucoup plus cohérente car la dernière valeur mesurée infléchie avec plus de force la moyenne. Cela positionne un bec en bout de courbe pondéré par les 4 valeurs précedentes. Interessant certes !, cependant ce bec peut également être considéré comme une anomalie que rien ne pourra distinguer. L'idée générale est de comparer la moyenne en cours à la précedente pour obtenir une tendance. Le lissage de la moyenne sur des valeurs en définitive aléatoires (ou presque) n'apporte pas grand chose. Pour ma part, une fois une tendance évaluée, il faut confirmer, filtrer, convertir en données exploitables. Sachant que les seules tendances à évaluer sont les déperditions in fine.

Définir le sommet de la courbe de chauffe, permet, je pense, d'envisager des mesures plus précises. - un écart si au dessus du seuil. - une amplitude si au dessus du seuil. - un gain si la consigne n'est pas ou peu atteinte.

Des règles de décisions peuvent découler des éléments pré-cités. Il est d'ailleurs tout à fait possible d'envisager cette hypothèse pour une régulation PI/PID.

@+

Zoroastre.

Merci beaucoup pour cette contribution.

Serait t'il possible d'avoir des courbes pour que l'on voit comment telle méthode réagit sur le chauffage en fonction de la température ambiante ?

Yep!

Cher Skuzmitoo, j’ai mis en pièce jointe un condensé des anomalies que j’ai repertoriées.
Le format n’est pas trop adapté et j’espère que vous m’en escuserais. Les graphiques ont été réalisé sous Openoffice et exporté en pdf.
Je compte exploité GnuPlot pour réaliser mes graphiques plus tard et les intégrer dans une interface web. Je priviligie des solutions aisées pour l’instant.

Je peaufine encore un peu mes hypothèses et passerais à une nouvelle régulation prochainement.

@+

Zoroastre.

courbes.pdf (66.2 KB)

@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.

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 :

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.

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.

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.

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 :wink:

@+

Zoroastre.

/*
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); }

tableau_fuzzylike.pdf (59.3 KB)

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.

Système domotique réseau.pdf (245 KB)

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 :wink: Et ce doit être certainement les élements sur lesquels tu doit travailler en ce moment.

En tout cas, bravo et bon courage :wink:

@+

Zoroastre.

Merci zoroastre pour tes remarques.

zoroastre: 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.

zoroastre: 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.

zoroastre: 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.

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 :grin:).

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

au plus pres chez Elecdif Chnord ? :grin: 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 )