Aidez nous ! Projet - Gestion domotique

[Oliv4945]

Edit: grillé par Oliv  

Oui mais bon, tu expliques mieux !!!

Je ne compte pas utilisé le même type de chauffage (d'un autre côté je n'en ai pas encore  )

Dis donc sans chauffage par les temps qui courent… Tu dois te peller non? 

[osaka]

Oui mais bon, tu expliques mieux !!!

Pourtant j'ai beaucoup de mal par moment à me faire comprendre, enfin il y a toujours de la confusion entre certain mots comme par exemple si je parle de "serveur", est ce que je parle de serveur matériel, d'application serveur , serveur de contenus, de fichiers, de websocket (tout dépend du service rendu)   

Dis donc sans chauffage par les temps qui courent… Tu dois te peller non?  

Disons que ce n'est pas le mien  :*, en même temps je reste souvent fenêtre ouverte, même maintenant ça raffermis les bonbons.    

[Skuzmitoo]

Oulàlà il y a comme une grosse méprise ou confusion dans ta description de mon (notre ?) idéal  smiley-kiss.

-  Moi je pars plutôt sur un micro serveur (web) avec quelque chose genre http://www.friendlyarm.net/products/micro2440 (non arduino) connecté au bus via son rs-232.
Un arduino+ethernet en client donc serveur en complément obligatoire, l'arduino+eth ne serais qu'un intermédiaire entre le serveur et le système, si le serveur peux se connecté aux système directement pas besoin d'arduino+eth.

Que le serveur soit en ligne ou en local il n'y a pas de différence il faudra un arduino + ethernet

- Pas un arduino par pièces mais plutôt par "fonctions" et tous réunis au même endroit (coffret) sauf pour certains préférable comme un module dédié à la chaudière par exemple. (d'où le fait que j'ai parlé de l'installation électrique général en étoile) .

Une fois que les fonctions pour chaque capteurs et actionneurs seront écrite, chacun pourra faire a sa sauce en mettant ce qu'il veut sur l'arduino

Maintenant l'arduino par pièces est possible, dans le premier cas grande longueur de câbles électrique (vob 1,5²/2,5² ...) et dans ce l'autre grande distance du cablage de bus.
Pour la partie capteurs divers on avais parlé de conversion analogique/numérique pour palier le problème de distance.

Exact, nous pouvons nous pencher sur la partie électronique pour interfacer un capteur analogique en I2C cela peut servir a plein de personne

- rs-485 à l'unanimité.  smiley-mr-green

Ok

Xpl c'est la solution de gromain pour l'interconnexion avec d'autre système hors arduino.

Le protocole avait l'air assez simple et correspondait a notre usage, est ce bien la peine d'en développer un nouveau ?

[Skuzmitoo]

Pour revenir aux prémices du projet et comme tout le monde semble être d'accord sur la partie gestion du chauffage. Je propose mon script sur pastebin, il pourra ainsi servir de base documentaire et permettra d'éviter certaines erreurs auquelles on ne pense pas toujours.

C'est clair que pour du brouillon, c'est plutôt propre.

Par contre une petite remarque j'ai parcouru ton code dans les grandes lignes et j'ai remarqué que tu gérais ton chauffage en mode "scénario" on va dire. J'entends par la que tu n'utilise pas le fil pilote a 100%. Il serait bien de pouvoir utilisiser les 6 ordres qui sont possibles et de gérer le chauffage en mode "ambiance" également:


Certe un petit montage électronique s'impose mais nos amis électronicien ne devrait pas avoir trop de mal a nous faire un truc de bien. J'ai trouver un début de piste, mais celui-ci ne gère que 4 ordres, il faudrait rajouter un petit oscillateur pour gérer les 2 autres ordres. Voici un début de piste que j'ai trouver sur le net :

Il faut rajouter des résistances pour que les optotriacs commutent apparement mais de quelle valeur ? Cela dépasse mon domaine de compétence. L'idéal serait de pouvoir adapter ce montage électronique afin de le faire marcher en OneWire.

Ainsi, il serait possible de commander son chauffage par "ambiance" en choisissant "Confort - Confort -1°C - Confort -2°C - Eco - Hors gel - Arrêt" ou bien par scénario que l'utilisateur pourrait créer comme par exemple : "Départ Vacance - Départ Travail - Absence Courte - Couché". Ces scénarios pourront également intéragir avec d'autres éléments tel que les volets, les lumières, ... etc.

[osaka]

Que le serveur soit en ligne ou en local il n'y a pas de différence il faudra un arduino + ethernet

Me suis mal expliqué  , quand j'ai dit serveur (web) j'aurais pas du le mettre entre parenthèse et plutôt parlé de "serveur de contenu" (contenu: html, javascript, php, autres et local ici). 
En fait comme l'arduino+eth est limite (nb connexion, ram, langage de script, ...) pour en faire un serveur complet, on ne peux l'utilisé que comme client (passerelle entre le véritable "serveur de contenu" et le système) donc dans tous les cas on a besoin d'un serveur de contenu (local ou pas).
Maintenant si on peux relier le "serveur de contenu" (non limité comme le shield eth) directement au système via son port rs-232/485 comme on l'aurais fais avec l'arduino+eth on n'a plus besoin de celui-ci comme intermédiaire, il en devient donc inutile non ?

[web -> Serveur de contenu -> ethernet ->arduino+eth -> rs232/485 -> bus système]
[web -> Serveur de contenu -> rs232/485 -> bus système]

Enfin ici c'est plutôt mon choix. 

Xpl c'est la solution de gromain pour l’interconnexion avec d'autre système hors arduino.

Le protocole avait l'air assez simple et correspondait a notre usage, est ce bien la peine d'en développer un nouveau ?

Xpl on en a jamais vraiment discuté, mais vu les performances d'ont on a besoin sur le bus il serait beaucoup plus lourd.
Un exemple du protocole, rien qu'en taille une simple commande ferait 102 (+-) octet pour une commande simple, rajoutons que l'analyse de chaîne de caractère est très lourd également en mémoire et process (recherche de la chaine correspondante pour chaque partie, comparaison, conversion de valeurs,... ) c'est énorme  :~
Xpl est prévu à la base pour de l'interaction entre différents système complètement différents (plus performant que le notre) et qui n'ont parfois aucun rapport avec ce que l'ont veux faire ici (squeezbox, ... ), pour ça je serais parti sur des solutions x10, plcbus, ..., +domogic ou homeseer(pc+software, ...) alors  $).

Code: [Select]


xpl-cmnd
{
    hop=1
    source=xpl-xplhal.myhouse
    target=acme-cm12.server
}
x10.basic
{
    command=dim
    device=a1
    level=75
}


Mon protocole basé sur de l'existant, assez simple.

Ici l'emplacement des donnéees dans la trame sont parfaitement connu, il n'y a aucune recherche à faire que de la comparaison entre valeurs numériques et une seule trame fais minimum 10 octet pour des commandes simple comme celle de l'exemple xpl.

[zoroastre]

Yep!

Pour répondre à Skuzmitoo, mon installation est, disons d'un temps ancien. Losque j'ai acheté la maison, il existait un thermostat mécanique, avec un précision douteuse, dont l'unique fonction, tel un interrupteur, est de démarrer ou éteindre le circulateur. L'électronique, "électronique" entre guillemets, de la chaudière s'occupant de la vanne et des brûleurs. Il faut comprendre que ces deux derniers élements sont assujetis au circulateur. Il n'y a pas à proprement parler de fils pilote chez moi.
L'idée m'est venue d'utiliser un microcontrolleur le jour où le thermostat, suite à des travaux, m'a laché.
Le temps d'évaluer les solutions et d'investir dans le matériel, nous utilisions un simple interrupteur pour commander le chauffage à la demande. Ce n'était naturellement pas pratique et la nuit, lors de grand froid, j'habite Dunkerque, au confin du nord polaire , la temperature descendait allégrement sous les 15 degrés. Lorsque nous partions en week-end, la maison était glaçiale. J'ai de plus deux enfants en bas ages (3 et 5 ans).
J'ai donc avant tout terminé mes travaux d'isolation, la cléf de la réussite en fait, et je me suis ensuite concentré sur le thermostat à base d'arduino.

Il me reste un certains nombres de finitions à apporter et des évolutions dont je commence à étoffer les prémices.
LES POURS:
  - Je suis assez satisfait de la régulation actuelle.
  - Le pilotage par mon logiciel python est fonctionnel. (Un pc serveur + hub font la liaison)
LES CONTRES:
  - Le pilotage local est un peu décevant. en ce sens, que l'utilisation d'une dalle tactile ralentie fortement           l'applicatif et pénalise l'ergonomie génerale. Je pense que pour un pilotage local, un afficheur + quelques boutons sont plus adaptés.
  - Actuellement, je démarre la chauffe à la température actuelle + 0.8 °C (température actuelle correspondant au seuil bas, +0.8 pour le seuil haut). Je suis contre toute tentative de temporisation de la chauffe, ou alors une tempo doit exister uniquement pour alarmer en cas de débordement.
En fait, il ne s'agit aucunement d'une régulation et c'est actuellement sur ce problème que je penche. Une courbe de chauffe ne peut être facilement représentée mathématiquement, l'élevation de température est rapide, l'inertie perdure un moment puis la baisse de température s'accentue au fur et à mesure. L'inertie du batiment est difficilement mesurable (à moins d'être un expert), et la température exterieure sont des données essentielles si l'on désire se rapprocher du meilleur rendement possible.
Avec l'aide du forum, j'ai ouvert les yeux sur la régulation PI ou PID. Cependant, elles semblent convenir pour maintenir une charge entre deux valeurs.
Je dois donc trouver autre chose. Je planche donc sur la logique floue et les algorithmes génetiques. Ce qui me permettrait de construire des scenarios logiques et rendre ma courbe auto-adaptative. Bref vaste sujet !!!
Le but serait en fait, pour un temps de chauffe quasi identique, à mode constant, en fonction de la température exterieure, d'obtenir le même écart temps entre deux chauffes. Le rendement serait optimisé en fonction naturellement des préferences de confort de l'utilisateur.

J'ai donc encore pas mal de taff en perspective. Mais aprés trois semaines de fonctionnement, je n'ai pas noté de dysfonctionnement majeur. C'est encouragant

@+

Zoroastre.

[Skuzmitoo]

[web -> Serveur de contenu -> ethernet ->arduino+eth -> rs232/485 -> bus système]
[web -> Serveur de contenu -> rs232/485 -> bus système]

Je me suis mal expliqué peu être mais c'est cela que j'avais compris

[Skuzmitoo]

Pour répondre à Skuzmitoo, mon installation est, disons d'un temps ancien. Losque j'ai acheté la maison, il existait un thermostat mécanique, avec un précision douteuse, dont l'unique fonction, tel un interrupteur, est de démarrer ou éteindre le circulateur. L'électronique, "électronique" entre guillemets, de la chaudière s'occupant de la vanne et des brûleurs. Il faut comprendre que ces deux derniers élements sont assujetis au circulateur. Il n'y a pas à proprement parler de fils pilote chez moi.

Ok je comprend mieux, je vais donc regarder ton code pour essayer de créer une librairie compatible chauffage On/Off - Fil pilote 4 ordres - Fil pilote 6 ordres

[osaka]

Que le serveur soit en ligne ou en local il n'y a pas de différence il faudra un arduino + ethernet

[web -> Serveur de contenu -> ethernet ->arduino+eth -> rs232/485 -> bus système]
[web -> Serveur de contenu -> rs232/485 -> bus système]

Je me suis mal expliqué peu être mais c'est cela que j'avais compris

Moi j'avais compris que tu pensais à la première solution, celle avec arduino+eth comme la deuxième en est dépourvu. 
Va vraiment falloir que je fasse un/des schémas/dessins pour être sure qu'on vois tous bien la même chose.  :%

j'habite Dunkerque, au confin du nord polaire

On est pas si éloigné que ça 200km +-, on dois profité des même précipitations. 

Une courbe de chauffe ne peut être facilement représentée mathématiquement.

J'avais remarqué ça chez mes parents, lors de l'installation d'une nouvelles chaudière il a fallut attendre qu'une personne presque uniquement dédié au réglage de celle-ci vienne.  :~

L'inertie du batiment est difficilement mesurable (à moins d'être un expert), et la température exterieure sont des données essentielles si l'on désire se rapprocher du meilleur rendement possible.

Concernant l'inertie thermique du bâtiment il faut surtout jouer sur les prévisions météo et prévoir le différentiel intérieur/extérieure pour accumulations, pas facile c'est clair.  :~

Tien personnes n'est intéressé par la gestion d'une vmc double flux avec échangeur et couplé à un puis canadien + système d'appuis genre poils à pellet  ? (enfin pour ça j'ai le temps  )

[Oliv4945]

Concernant l'inertie thermique du bâtiment il faut surtout jouer sur les prévisions météo et prévoir le différentiel intérieur/extérieure pour accumulations, pas facile c'est clair.

En fait quand on trace les courbes ça se voit assez vite, surtout en ce moment qu'il y a des gros delta de température



@Brisbee : J'avais oublié de mettre un message sur l'heure hier

Donc la méthode que je fais n'est surement pas la meilleure mais ça m'a servi pour les tests. Un bouton sur l'IHM appelle une fonction javascript qui appelle une page de l'Arduino avec l'heure dedans et la "décode"

Code: ("Arduino") [Select]


if (strncmp( pageAsked, "/id=Set_Date", 21 ) == 0 ) {
                timeToSet.Year = pageAsked[30]-'0+10';
                timeToSet.Month = (pageAsked[31]-'0')*10+pageAsked[32]-'0';
                timeToSet.DayOfMonth = (pageAsked[33]-'0')*10+pageAsked[34]-'0';
                timeToSet.DayOfWeek = pageAsked[35]-'0';
                timeToSet.Hour = (pageAsked[36]-'0')*10+pageAsked[37]-'0';
                timeToSet.Min = (pageAsked[38]-'0')*10+pageAsked[39]-'0';
                timeToSet.Sec = (pageAsked[40]-'0')*10+pageAsked[41]-'0';


Code: ("javascript") [Select]


function sendDate() {
var date = new Date();
date.setTime( date.getTime() );
var dateformatee;
dateFormatee = String( date.getFullYear() );
if ( date.getMonth() < 10 ) dateFormatee +='0';
dateFormatee += String( date.getMonth() );
if ( date.getDate() < 10 ) dateFormatee += '0';
if ( date.getDate() == 0 ) { dateFormatee += '7' }
else { dateFormatee += date.getDate(); }
dateFormatee += date.getDay();
if ( date.getHours() < 10 ) dateFormatee +='0';
dateFormatee += date.getHours();
if ( date.getMinutes() < 10 ) dateFormatee +='0';
dateFormatee += date.getMinutes();
if ( date.getSeconds() < 10 ) dateFormatee +='0';
dateFormatee += date.getSeconds();
$.getJSON( 'http://IP_SERVEUR:PORT/id=Set_Date&date='+dateFormatee, function(output) {});
// alert( dateFormatee );
}

C'est pas ce qu'il y a de plus efficace mais ça fonctionne, je pense que je ferais le même concept mais avec l'arduino qui appelle de lui même une page PHP pour régler l'heure tout seul au démarrage, mais comme il y a une batterie dans le RTC une fois que c'est à l'heure il y rarement besoin de recommencer

[Brisebee]

mais celui-ci ne gère que 4 ordres,

Il faut rajouter des résistances pour que les optotriacs commutent apparement mais de quelle valeur ?

Pour ce qui concerne la commande du fil pilote 6 ordres, le montage proposé est suffisant pour les 6 ordres.
Il faut effectivement rajouter une résistance de 180 Ohms en série sur chaque entrée.
Pourquoi 180 Ohms (en fait de 150 à 330) :
La  tension maximale de la sortie est de 5V, et il faut environ 1,25V aux bornes de la diode de l'opto triac MOC 3041(tension typique selon les données constructeur) pour que le triac conduise. Le courant direct typique de la diode est d'environ 20mA.
Donc R = U/I => (5V-1,25V)/20mA = 187,5 Ohms on choisira donc 180 ou 220 Ohms (valeurs normalisées)

Explication du fonctionnement du montage :

- Confort : les deux entrées (Pic1 et Pic2) sont à 0 => les deux opto sont bloqués => pas de signal.

- Confort - 1°C : les deux entrées sont à 0 pendant 4min57=> les deux opto sont bloqués => pas de signal , puis les deux entrées sont à 1 pendant 3 sec => les deux opto conduisent => les deux alternances sont reconstituées. Et cela cycliquement.

- Confort - 2°C : les deux entrées sont à 0 pendant 4min53=> les deux opto sont bloqués => pas de signal , puis les deux entrées sont à 1 pendant 7 sec => les deux opto conduisent => les deux alternances sont reconstituées. Et cela cycliquement.

- Eco : les deux entrées sont à 1 => les deux opto conduisent => les deux alternances sont reconstituées

- Hors gel : l'entrée Pic1 est à 0 et l'opto MO-1 est bloqué => l'alternance positive est bloquée. L'entrée Pic2 est à 1 et l'opto MO-2 conduit  => l'alternance est transmise sur le fil pilote.

- Arrêt : l'entrée Pic1 est à 1 et l'opto MO-1 conduit => l'alternance positive est transmise sur le fil pilote. L'entrée Pic2 est à 0 et l'opto MO-2 conduit  => l'alternance est transmise sur le fil pilote.

J'espère avoir été suffisamment clair pour tout le monde, n'hésitez pas à me demander d'autres explications si besoin.

[Skuzmitoo]

Merci beaucoup Brisbee pour tes lumières sur la commande du pilote, maintenant, cela ne vas pas être très facile d'intégrer les 4'53 et 4'57 dans l'arduino car les temps de calcul peuvent être variables ou bien je me trompe.

[Brisebee]

cela ne vas pas être très facile d'intégrer les 4'53 et 4'57 dans l'arduino car les temps de calcul peuvent être variables ou bien je me trompe.

Je pense que cela ne devrait pas poser de gros problèmes, enfin je n'ai pas suffisament d'expérience sur l'Arduino.
Mais si je devais le faire en assembleur avec un microcontrôleur, il suffirait de faire une routine qui génère une interruption toutes les secondes (ou sous-multiple), en utilisant un timer du microcontrôleur, on compte les interruptions et le tour est joué. On peut probablement faire quelque chose de similaire en C. Mais, je ne suis (pas encore ?) suffisament avancé pour l'affirmer.

[osaka]

Normalement ça devrait aller avec millis(), maintenant tout dépendra surement du code dans le chemin de la boucle loop().
Difficile à dire sans tester, parfois j'ai du mal à visualisé les performances de l'atmega ,comme aujourd'hui ce n'est plus vraiment la préoccupation majeur du développeur vu nos machine actuels.
Enfin je pense pas que ce soit un problème pour de la "seconde", juste vérifié qu'on ne fais pas de boucle trop conséquente (on peux palier à ce problème en fessant un semblant de multitâche).

[zoroastre]

Yep!

J'ai retrouvé l'article concernant l'application de la logique floue pour la régulation d'un système de chauffage. L'aspect adaptatif de l'application pourrait rendre la régulation universelle.

Bonne lecture : http://docinsa.insa-lyon.fr/these/1997/fraisse/fraisse.pdf

@+

Zoroastre.