Aidez nous ! Projet - Gestion domotique

[68tjs]

Je ne peux pas vous servir à grand chose mais je sais où aller chercher les normes.
Ci joint deux documents provenant de l'ITU (ex CCITT) sur les normes RS-485.
Pour info :
IUT = en français : UIT = union internationale des télécommunication
CCITT = comité consultatif international téléphonique télégraphique

[osaka]

Ce que je peu retenir, c'est que dans l'idéal,il faut :

- un arduino + ethernet pour les commandes depuis l'extérieur qui jouerait le rôle de maître
- un arduino par pièce pour gérer les différents capteurs et actionneurs (plus de problème pour la distance entre capteurs et arduino)(pourquoi pas intégrer le tout dans un plafonnier a voir)
- un bus RS485 pour faire communiquer les arduinos entre eux
- le protocole Xpl pour le transmission des consignes et des valeurs des capteurs

Maintenant il y a des câbles a tirer et encore pas trop, mais dans n'importe quel cas il faudra tirer des câbles.

Vous êtes d'accord avec moi ?

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

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

- 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) .
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.
- rs-485 à l'unanimité. 
- Xpl c'est la solution de gromain pour l’interconnexion avec d'autre système hors arduino.


J'essaierais une fois de refaire des dessins/schémas/diagrammes des différentes solution envisagée. 

[Brisebee]

- un arduino + ethernet pour les commandes depuis l'extérieur qui jouerait le rôle de maître

Ce sera aussi l'horloge du système.

- un arduino par pièce pour gérer les différents capteurs et actionneurs (plus de problème pour la distance entre capteurs et arduino)(pourquoi pas intégrer le tout dans un plafonnier a voir)

Il faudra voir en fonction des configurations et des fonctionnalités recherchées par chacun, s'il est utile de mettre un Arduino par pièce. Pour ce qui me concerne j'ai une maison avec une cave ou vide sanitaire accessible => tout le Rez de Chaussée peut-être accessible par là, et par ailleurs j'ai des combles accessibles => tout l'étage peut-être accessible par les combles, et des réservations faites à la construction permettent de tirer des câbles entre le local technique qui se trouve à la cave et les combles. Tout cela pour dire qu'à priori, avec deux ou trois Arduino, dont le maître, je devrais pouvoir tout faire. Mais sur le principe, cela ne change rien, à partir du moment où il y a plusieurs Arduino, il faudra les faire communiquer.

- un bus RS485 pour faire communiquer les arduinos entre eux
- le protocole Xpl pour le transmission des consignes et des valeurs des capteurs

Je ne connais pas le protocole Xpl, mais je ne demande qu'à apprendre !

J'ai commencé à faire quelques essais sur mon nouveau matériel : Arduino Mega 2560 + Ethernet shield + Horloge DS1307 :
Tout fonctionne avec des bouts de programme trouvés à droite et à gauche et surtout sur l'excellent site très pédagogique : mon-club-elec.fr
Je vais bientôt pouvoir commencer à travailler concrètement sur le projet.

Pour l'instant il faut que je trouve le moyen de passer les paramètres de plages horaires, depuis le serveur web vers l'Arduino, si quelqu'un sait faire, je suis preneur, si possible avec des explications.
Je sais, je suis exigeant, mais j'aimerais bien comprendre ce que je fais.

[osaka]

Je ne peux pas vous servir à grand chose mais je sais où aller chercher les normes.
Ci joint deux documents provenant de l'ITU (ex CCITT) sur les normes RS-485.
Pour info :
IUT = en français : UIT = union internationale des télécommunication
CCITT = comité consultatif international téléphonique télégraphique

Génial pour ma compréhension de celui-ci. 

[osaka]

Pour l'instant il faut que je trouve le moyen de passer les paramètres de plages horaires, depuis le serveur web vers l'Arduino, si quelqu'un sait faire, je suis preneur, si possible avec des explications.
Je sais, je suis exigeant, mais j'aimerais bien comprendre ce que je fais.

Peut être ouvrir un post dédié à celui-ci pour avoir plus d'aide ?
Quel sont tes connaissances niveau langage web (html, php, javascript, ...)?

[Brisebee]

Peut être ouvrir un post dédié à celui-ci pour avoir plus d'aide ?
Quel sont tes connaissances niveau langage web (html, php, javascript, ...)?

Tu as raison, c'est ce que je ferai le moment venu, pour l'instant il faut d'abord que je comprenne les programmes qui tournent :
- Affichage de l'horloge sur LCD
- Serveur web avec commande d'un LED depuis le serveur
Cela me prendra sûrement du temps.

Mes connaissance des langages web sont très faibles, mais je compte bien là aussi progresser.
J'avance tout doucement sur le site du zéro.
Cela fait beaucoup de choses à la fois !

[osaka]

J'avance tout doucement sur le site du zéro.
Cela fait beaucoup de choses à la fois !

Très bonne idée le site du zéro, n'hésite pas à demandé si besoin. 
J'ai voulu commencé la partie communication mais un souci http://arduino.cc/forum/index.php/topic,81484.0.html m'a coupé dans mon élan. 
Entre () l'arduino mini est très très intéressant je trouve et pour mini il est vraiment mini je dirais même micro, 6x (2x en longueur et 3X en largeur) plus petit en comparaison avec ma duemilanove et pour un prix entre 7/10 € pièce en chine je crois que je vais m'en commandé quelques un  .

[Oliv4945]

Pour l'instant il faut que je trouve le moyen de passer les paramètres de plages horaires, depuis le serveur web vers l'Arduino, si quelqu'un sait faire, je suis preneur, si possible avec des explications.
Je sais, je suis exigeant, mais j'aimerais bien comprendre ce que je fais.

Je suis sur un telephone mais je te montre demain un exemple. Sinon tu peux aussi regarder du cote du protocole ntp (Network Time Protocole) qui doit etre inclus dans la librairie ethernet

[Skuzmitoo]

Pour ma part j'ai des connaissances plutôt bonne en html, php,css et sql donc je peut essayer de gérer l'interface web pour le moment car je n'ai pas encore mon arduino, c'est prévu pour noël XD.

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

[osaka]

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.

Code: [Select]


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



[Skuzmitoo]

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 ?

[osaka]

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 .

[zoroastre]

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

[Oliv4945]

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

[osaka]

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  
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  ), mais une grosse partie serait similaire.
(pour un début et pour un brouillon je trouve ça très propre   )