Aidez nous ! Projet - Gestion domotique

Skuzmitoo: Maintenant il va falloir que je regarde comment marche les websockets car je ne maîtrise pas trop.

De ce côté là les websocket fonctionne comme les socket normal, la seule différence ce situe aux niveau du handshake (contrôle) à l'initialisation entre le client et le serveur. C'est d'ailleurs à cause de ce hanshake que ce situe mon problème avec la normalisation toujours pas définitive :( .

Le fonctionnement de base entre le(s) client(s) et le serveur avec JavaScript est assez simple.

function init(host)
{
  try
  {
    if(window.MozWebSocket)
    {
      socket = new window.MozWebSocket(host, 'DDuino');  //initialisation avec le serveur (version Mozilla)
    }
    if(window.WebSocket)
    {
      socket = new window.WebSocket(host, 'DDuino'); // (autres navigateurs)
    }
    
    socket.onopen    = function(msg){ log("Welcome - status "+this.readyState); }; //événement sur ouverture.
    socket.onmessage = function(msg){ log(msg.data);parseJSon(msg.data); }; //événement sur réception message.
    socket.onclose   = function(msg){ log("Disconnected - status "+this.readyState); }; // événement sur fermeture de connexion.
    
  }
  catch(ex)
  {
    log(ex);
  }
}

function send(textejson)
{
  try{ socket.send(JSON.stringify(textejson));  } catch(ex){ log(ex); } //socket.send méthode d’envois au serveur.
}

Très instructif merci, mais je n'utilise pas trop le javascript aurait tu un exemple avec le code de l'arduino en client et le code sur le serveur ?

Sans JavaScript pas possible pour l'instant d'utilisé les websocket côté clients (navigateurs), comme le websocket et le code javascript s'exécute côté client (ton navigateur). :~ . Pour la communication entre le serveur (software) et le socket simple de l'arduino, j'ai utilisé un serveur de websocket en php que j'ai du remanier pour en faire un système hybride socket/websocket. Donc il accepte les clients websocket (navigateurs) et socket simple (pour l'arduino). Mes sources se trouvent ici http://arduino.cc/forum/index.php/topic,72035.0.html

J'ai bien tenté d'implémenté les websocket sur l'arduino, mais bugger et trop lourd pour celui-ci apparemment. Peut être que je retenterais plus tard mais comme je ne compte pas utiliser le shield ethernet de mon côté (serveur directement sur le bus via rs-232) pour le projet comme expliqué dans mon post précédent en haut de la page .

Yep!

Pour la partie web évoquée, je serais plutôt tenté de faire appel à quelques prodiges du php pour nous pondre un jolie cms dédié à l'architecture multiple et modulable qui se profile dans nos esprits. Un peu dans la lignée de phpnuke (the most famous :fearful: ) où l'administrateur aurait la jouissance d'ajouter ou de retirer autant de module qu'il veut en fonction de son installation propre. Par contre, je ne peux pas trop parler du javascript, je n'ai que des notions trés basiques, mais ne serait-il pas préferable dans la lignée que j'ai évoqué plus haut de parler cgi, script python, php, perl ??? Je n'ai rien contre le javascript, mais il y a tant de réussite avec d'autres langages que j'ai du mal à comprendre cette perséverence...

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.

furnace.pde : http://pastebin.com/u/zoroastre74 (Escusez l'aspect trés brouillon du script, j'écrit mes librairies en ce moment pour clarifier l'ensemble.)

@+

Zoroastre.

Par contre, je ne peux pas trop parler du javascript, je n'ai que des notions trés basiques, mais ne serait-il pas préferable dans la lignée que j'ai évoqué plus haut de parler cgi, script python, php, perl ??? Je n'ai rien contre le javascript, mais il y a tant de réussite avec d'autres langages que j'ai du mal à comprendre cette perséverence...

Salut, En fait tous les langages que tu cites sont "équivalents" car exécutés sur le serveur, mais si tu veux du dynamisme côté client tu n'as pas le choix, et il faudra forcément passer par du javascript

zoroastre: Par contre, je ne peux pas trop parler du javascript, je n'ai que des notions trés basiques, mais ne serait-il pas préferable dans la lignée que j'ai évoqué plus haut de parler cgi, script python, php, perl ??? Je n'ai rien contre le javascript, mais il y a tant de réussite avec d'autres langages que j'ai du mal à comprendre cette perséverence...

Le problème ici concerne les websockets, c'est la seul façon de maintenir une connexion client/serveur et d'avoir une interaction temps réel entre ton navigateur(socket client) et le serveur de websocket (non serveur de contenu qui lui par contre peut être écrit dans le langage que tu veux, php, python, perl, java, ...) (le serveur de websocket peux également être écrit dans le langage que tu veux, je l'ai d'ailleurs fais en php). Ici comme javascript est interprété par le navigateur l'api du w3c dans ce langage semble évident puisque celui ci est le seul langage que les différents navigateurs sont capable d'interprété, (hormis html, css, ... non dynamique). Maintenant comme précisé le contenus (global même le code javascript interprété par le navigateur) peux être gérer dynamiquement dans le langage que tu désires, javascript et les websocket ne seront utilisé que pour changer en temps réels certaine données de ce contenu (on pourrais gérer le contenu entier via javascript et websocket mais bon le but n'est pas là) . En gros c'est de l'Ajax temps réel. ;)

Edit: grillé par Oliv :grin: ReEdit:

Concernant la partie chauffage, je vois que tu es déjà bien avancé sur la manière de gérer celui-ci, Bribri sera fortement intéressé. Je ne compte pas utilisé le même type de chauffage (d'un autre côté je n'en ai pas encore :grin:), mais une grosse partie serait similaire. (pour un début et pour un brouillon je trouve ça très propre :) )

osaka: Edit: grillé par Oliv :grin:

Oui mais bon, tu expliques mieux !!!

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

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

Oliv4945:
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) :sweat_smile:

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

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

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 ?

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.

Skuzmitoo: 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é :sweat_smile:, 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). :grin: 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. ;)

Skuzmitoo:

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

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.

osaka:

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

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.

[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

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

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

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

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

zoroastre: j'habite Dunkerque, au confin du nord polaire ;)

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

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

zoroastre: 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 :sleeping: :sweat_smile:) :)

osaka: 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"

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';
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 ;)

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

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.

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

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