Go Down

Topic: Aidez nous ! Projet - Gestion domotique (Read 153864 times) previous topic - next topic

Oliv4945

J'arrive un peu après la bataille mais bon  :P
Pour le stockage des paramètres je pense qu'ils doivent être initialisés à des valeurs logique (par exemple chauffage de 6 à 8h et 16 à 23h) au démarrage du programme.
Reglage via le web au démarrage si possible, et dès qu'un paramètre est changé dans l'interface web il est envoyé à l'Arduino.
J'envisage le stockage en EEPROM mais pas eu le temps  :)

Brisebee

Si je résume ce qui est proposé pour le stockage des données, et particulièrement celles de type "plages horaires" :
- On fixe des plages horaires par défaut, en dur => EEPROM ou flash (à voir en fonction de la carte arduino), ce qui permet d'avoir un système qui fonctionne en autonomie, même sans connexion au web.
- On vient modifier les plages horaires  sur un serveur web externe (plusieurs possibilités : hébergement, NAS, petit serveur autonome, ...) ces plages modifiées deviennent les nouvelles plages par défaut (donc remplace les anciennes ?).
Comment identifier les plages horaires qui ont été modifiées par le web pour pouvoir les changer en mémoire EEPROM ou Flash de l'arduino ?
J'ai pensé :
- le serveur web vient récupérer toutes les données pour les afficher, on les regroupe par paquets (par jour, ou par zone, ou ...) on fait un checksum par paquet,
- on vérifie les checksum des paquets en mémoire dans l'arduino et ceux des données affichées,
- si les checksum ne sont pas identiques, on transmet le paquet.
Qu'en pensez-vous ?
Ou avez vous d'autres solutions plus opérationnelles.

Artouste

#197
Dec 14, 2011, 01:46 pm Last Edit: Dec 14, 2011, 01:48 pm by Artouste Reason: 1

Si je résume ce qui est proposé pour le stockage des données, et particulièrement celles de type "plages horaires" :
- On fixe des plages horaires par défaut, en dur => EEPROM ou flash (à voir en fonction de la carte arduino), ce qui permet d'avoir un système qui fonctionne en autonomie, même sans connexion au web.
- On vient modifier les plages horaires  sur un serveur web externe (plusieurs possibilités : hébergement, NAS, petit serveur autonome, ...) ces plages modifiées deviennent les nouvelles plages par défaut (donc remplace les anciennes ?).
Comment identifier les plages horaires qui ont été modifiées par le web pour pouvoir les changer en mémoire EEPROM ou Flash de l'arduino ?
J'ai pensé :
- le serveur web vient récupérer toutes les données pour les afficher, on les regroupe par paquets (par jour, ou par zone, ou ...) on fait un checksum par paquet,
- on vérifie les checksum des paquets en mémoire dans l'arduino et ceux des données affichées,
- si les checksum ne sont pas identiques, on transmet le paquet.
Qu'en pensez-vous ?
Ou avez vous d'autres solutions plus opérationnelles.

réflexion
L'index simple est aussi utilisée dans certains domaine pour verifier si une nouvelle MAJ distante doit être faite en local.
L'index 0 faisant office de RAZ
L'interrogation du distant par le local ne faisant que vérifier périodiquement  si le dernier index distant est supérieur au dernier index local récupéré/enregistré (l'écrasement de l'index local par celui distant  étant la dernière opération à effectuer) pour enregistrer en EEP (ou autre demi dur) la dernière version dispo.
un index de type word sur une MAJ possible de 12 fois par jour (c'est déjà luxe)  permet déjà sans débordement de frôler les 15 ans ..
et dans 15 ans .... 8)

Chajo

Bonjour,

Ayant lu l'ensemble des participations à ce fil très intéressant et compte tenu du besoin que j'avais exprimé il y a quelques jours, il me semble important de définir la structure du système. Je viens donc vous faire part de cette réflexion.

Voici comment je vois la structure d'un tel système :

1) Un réseau temps réel constitué d'une carte arduino maître et de cartes esclaves spécialisées en terme de fonctions.
Pour respecter l'aspect temps réel, les modules dialoguent à l'aide d'un bus terrain sur RS 485 par exemple.  J'imagine que les librairies existent déjà pour l'arduino.
Ce sous-système gère les capteurs et actionneurs ; il doit être totalement autonome en terme de process, les paramètres de fonctionnement étant stockés dans l'arduino maître, avec des paramètres par défaut et des paramètres "courants" issus de la dernière modification par l'utilisateur, les valeurs par défaut permettant un démarrage initial.
Par ailleurs, chaque carte de fonction, en plus de faire tourner ses algorithmes (régulation, autosurveillance...) renvoie des infos de valeurs et d'états à la carte maître.
Ce sous-système est relié au reste du monde par une liaison Ethernet sur le réseau local de la maison.

2) Un sous-système de supervision chargé d'assurer l'interface homme-machine.
Il est inutile que la supervision soit "temps réel", un bus informatique lui convient ce qui autorise de la même manière, les actions locales et distantes à travers le web.
La supervision consisterait donc en un site web installé sur un serveur (NAS ou autre) implanté sur le réseau local de la maison.
Quelques pages web devraient suffire pour permettre de modifier les paramètres "courants" contenus dans la carte maître du sous-sytème 1 et donc son comportement.
La supervision rapatrierait également les infos d'état du sous-sytème 1 ainsi que des données des capteurs…à définir.

3) Une fonction d'alerte
La fonction d'alerte est nécessaire pour signaler spontanément des informations de dysfonctionnement du sous-système 1 ou encore des alarmes d'intrusion si la fonction de système d'alarme est utilisée.
Sur occurrence d'un tel évènement, la carte maître pourrait faire émettre un sms circonstancié par le web vers un téléphone programmé.

En conclusion, la structure définie ci-dessus est autonome sur le process, consultable et modifiable en local ou à distance grâce à la supervision ; elle génère "également des messages spontanés (alarme, dysfonctionnement…).

Qu'en pensez-vous ?

Skuzmitoo

C'est en gros ma vision des choses et celle des autres participants de ce fil. Je vois en tout cas que beaucoup de personnes suivent celui-ci et toutes les contributions sont intérréssantes.

Une question mais venue a l'esprit ce soir, le contrôle d'une ampoule peu facilement s'effectuer a l'aide d'un MOC + TRIAC mais qu'en est t'il de ces fameuses ampoules a économies d'énergie, sont t-elles toutes des charges inductives cas dans lequel il faudra adapter le dispositif de commande a la puissance de l'ampoule si j'ai bien compris, c'est un peu galère cela. De plus en faisant des recherches a ce sujet j'ai appris deux choses concernant ces ampoules elle rayonnent beaucoup et de plus celui-ci change en fonction de la polarité de l'ampoule (position de la phase et du neutre).

Chajo

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

osaka

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 ?

tochinet

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

tochinet

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

osaka

Bonsoir 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 :smiley-mr-green:) 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.
;)

zoroastre

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 :
Code: [Select]
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 :
Code: [Select]
/*
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.
Gné! ;)

Artouste



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)


zoroastre

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.
Gné! ;)

Skuzmitoo

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 ?

zoroastre

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.
Gné! ;)

Go Up