Aidez nous ! Projet - Gestion domotique

Oliv4945: Je suis pas loin si vous avez des questions

Merci pour tes réponses et ta proposition.

Je vais avancer tout doucement, et essayer de comprendre ce que je fais et ce que cela produit comme effets. Je suis un électronicien de la vieille école, j'ai pas mal programmé en assembleur mais très peu sur des langages plus éloignés de la machine. J'ai du mal à accepter d'utiliser des fonctions que je ne maîtrise pas, comme des boîtes noires, mais cela viendra !

Bonjour à tous les férus de domotique,

je découvre seulement ce topic donc j’arrive un peu tard…

J’ai lu que vous faisiez référence à mon projet xPLduino, un ensemble de module compatible arduino interconnectés via Ethernet (protocole UDP pour le transport, protocole XPL pour le formatage des messages). :slight_smile:

Je confirme que le choix d’un seul arduino gérant une multitude de fonction (volet, éclairage…) est un mauvais choix. C’était mon choix avec xplduino_v1. L’idée était de profiter du grand nombre d’E/S d’une Mega et de limiter les couts car le shield Ethernet Wiznet n’est pas donné.
Le point fort:

  • ça marche en production depuis 1 an, sans problème majeur
    Les points faibles:
  • une maintenabilité du code assez pénible (nombreuses fonctions logicielles empilées)
  • une mise à jour impossible sans black-out de la maison (au moins le temps du chargement du soft, plus si loupé dans les modifs)
  • une intégration mécanique de l’arduino dans un boitier délicate

Entre temps, j’ai étudié la solution Ethernet à base d’ENC28J60. Elle fut plus complexe à mettre en oeuvre au départ car l’arduino à plus de travail à réaliser: les datagrammes arrivent brutes de décoffrage au contraire du wiznet qui fait le gros du boulot.
Mais finalement ce n’était pas la mer à boire. En a découlé xplduino_v2 qui est bien avancé désormais. Le code de la v1 est porté à 80% en v2, les performances sont satisfaisantes.
La version 2 s’architecture autour d’un µC plus modeste (atmega328p) et d’un ethernet plus basique (débit 10mbps). Tous les composants existent au format DIP, donc je vais pouvoir réaliser une carte 2-en-1 qui s’intégrera parfaitement dans les boitiers sur rail DIN du marché, et qui sera très peu cher. La répartition des fonctions sur plusieurs modules interconnectés mais néanmoins autonomes apporte une plus grande fiabilité et flexibilité. Le code est commun à toutes les modules, mais optimisé pour chaque type de modules (éclairage, volet, E/S). La maintenance est simplifié.

Maintenant, pourquoi le choix de l’ethernet UDP ? je dirais le choix d’une certaine modernité lol. C’est le média universel et moderne par excellence. Alors oui, il nécessite un switch pour faire communiquer plusieurs modules entre eux, mais qui n’a pas de switch chez lui ? Il permet de s’affranchir des distances, et est modulaire (topologie en étoile, pas besoin de faire courir un bus dans toute la maison, on peut étendre le réseau à l’infini).

J’ai bien hésité un moment entre RS485, I2C et CAN, mais je trouve ces technos certes éprouvés, mais soit pas adpatés (I2C) soit d’une autre époque (RS485). Pour le CAN, d’une grand fiabilité, il est malheureusement très mal implémenté dans les arduino/atmega. Pour l’utiliser, autant partir sur l’excellent projet Domocan de BigOnOff, mais c’est du Pic. Toute la documentation est en wallon.

Au début du projet j’avais commencé à écrire mon propre protocole (largement pompé sur domocan d’ailleurs), mais je me suis vite rendu compte que l’ouverture vers le monde extérieur serait vite limitée. Puis j’ai découvert le protocole xPL (à ne pas confondre avec la techno CPL hein !!!). C’est un protocole ouvert, assez bien documenté, et supporté par un nombre croissant d’équipement (Squeezebox par ex) et de solutions logiciel (DOMOGIK étant ma préférée car 100% open-source, avec une IHM web, une appli android fonctionnelle et cerise sur le gateau, française). Son but est justement d’unifier l’incroyable profusion de techno plus ou moins propriétaires du monde de la domotique en faisant abstraction de la techno (plcbus, knx, x10, RF etc.).

Mais bon, libre à vous de créer un n nième protocole domotique :smiley:

Voilà pour mon modeste point de vue.

@ bientôt

Gromain59

PS1: un début de spécification de xplduino_v2 ici.
PS2: je suis toujours ouvert à toute collaboration :wink:

Bonsoir,

J'ai découvert ce forum et particulièrement ce post cet après-midi. J'aime la démarche collaborative, d'autant plus que je ne dispose pas de toutes les compétences. Je suis moi-même intéressé par certaines fonctions domotiques et leur implémentation sur des modules arduino.

Tout comme Brisebee je suis un électronicien de la vieille école ayant programmé beaucoup en assembleur sur le 6809 entre autres et en turbopascal (un peu de C également). Depuis quelques années, je suis en retraite et forcément, je dispose de peu de temps...pour moi.

Ceci dit, je réfléchis depuis pas mal de temps sur un système de gestion domotique qui incluerait au minimum les fonctions suivantes :

  • commande chauffage électrique (modif consignes, contrôle température donc bouclage des ordres)
  • contrôle consommation électrique générale
  • contrôle production photovoltaïque (comptabilisation production et pour vérifier que le différentiel n'a pas disjoncté)
  • système d'alarme intrusion
  • consultation par le web
  • envoi de sms sur portable sur évènements prédéfinis (plus performant que la retransmission tph)

Je dispose d'ores et déjà d'un serveur que j'ai construit sous ubuntu sur mon réseau local.

Charles

Yep!

Je ne suis pas tout à fait d’accord sur la multiplication des arduinos…Je concois naturellement qui’il faut quelque-chose à l’autre bout pour interpréter les messages.
Gromain59, d’ailleurs, nous apporte une solution qui va à contrario, même si au demeurant, j’ai bien entendu son bêmol.
Il faut considérer que dans un système de communication multiple, les appels, traitements et retours d’information feront certainement appel à une gestion des latences rigoureuses. Les trains d’informations devront être entre-coupés d’attentes afin de libérer le bus le temps que se forme la réponse. De plus, Je choisirais plutôt une liaison 4 fils. Deux pour l’émission, deux pour la réception. Dans ce cas ci, les trains seront plus rapides, mais les attentes existeront toujours, l’arduino maître aura sa propre latence et il ne peut se passer des retours.
Si l’idée est de gérer 4 pièces par exemples, en sus du maestro, nous avons 5 arduinos à considérer avec chacunes sa propre vitesse d’execution, sa propre faculté à composer le message et l’envoyer. Vous me direz, qu’est-ce 50 ou 80 ms !!! Cependant, si l’on double les arduinos, je vous laisse deviner…(pas sûr que ce soit proportionnel en plus)

Gromain59 utilise le protocole UDP via une liaison ethernet 10Mbit. Mais que veut dire

les performances sont satisfaisantes.

et combien d’arduino as-tu sur ta nouvelle topologie ?? UDP = perte possible, qu’en est-il ???

Je suis persuadé que l’on est loin d’utiliser toutes les capacités du langage de programmation. Sans évoquer le multitâche (*qui n’existe pas en fait), je pense qu’il faut cependant s’en inspirer. La principale limitation de la plupart des micro-controleur se situe dans la gestion serie des tâches qui lui incombe, séquentielle, j’ai souvent mesuré les temps d’execution de mes programmes, pour voir, et j’ai été régulièrement surpris de constater que le programme mettait 3 fois plus de temps à dérouler sa boucle dés qu’il y a communication (en moyenne 30-40 ms).

Vous me direz qu’une arduino par tâche est plus rapide qu’une seule qui s’occupe de tout, cependant ce que vous gagnez en vitesse d’execution, vous risquez de le perdre en communication.

Pour en revenir à la programmation, il manque plusieurs chose pour optimiser la gestion des tâches. Premièrement, il faut établir des règles de priorités et des règles de décisions. Je m’entends, si deux informations arrivent en même temps ou à peu d’intervalle, une avec un priorité “0”, l’autre “1” (ou 2, ou 3, etc), j’execute d’abord la première.
Secondement, il faut stocker ces tâches, les trier, les executer en utilisant une partie de la mémoire flash (rapide?) et en s’inspirant des règles du premièrement. Ainsi, on se rapprocherait du *préemptif que je suggérais plus haut. J’ai un ordre local et distant simultanément, je donne la priorité à l’ordre local. Le message y, arrivé aprés x, est plus important. Etc.

Pour ma part, je commence à envisager également une évolution de mon projet, je m’oriente plutôt sur une carte à deux microcontroleurs (ATMEGA644), avec règles de décision, priorités et délégations vers le second processeurs au cas par cas. Du simili-clustering ou par analogie avec les automates modernes, une tâche rapide et une seconde pour le reste. J’y vois comme avantage la proximité entre les deux processeurs, donc des temps de communication trés réduit, doublement de la force de calcul (si j’arrive à implémenter du vrai clustering), une plus grande réactivité face aux événements multiples.
Je commence à me documenter sur différents algos qui pourraient m’aider dans cette tâche. Je ne suis pas encore arrété sur le protocole “ethernet”.

@+

Zoroastre.

Gromain59: J'ai lu que vous faisiez référence à mon projet xPLduino, un ensemble de module compatible arduino interconnectés via Ethernet (protocole UDP pour le transport, protocole XPL pour le formatage des messages). :)

Entre temps, j'ai étudié la solution Ethernet à base d'ENC28J60. Elle fut plus complexe à mettre en oeuvre au départ car l'arduino à plus de travail à réaliser: les datagrammes arrivent brutes de décoffrage au contraire du wiznet qui fait le gros du boulot. Mais finalement ce n'était pas la mer à boire. En a découlé xplduino_v2 qui est bien avancé désormais. Le code de la v1 est porté à 80% en v2, les performances sont satisfaisantes. La version 2 s'architecture autour d'un µC plus modeste (atmega328p) et d'un ethernet plus basique (débit 10mbps). Tous les composants existent au format DIP, donc je vais pouvoir réaliser une carte 2-en-1 qui s'intégrera parfaitement dans les boitiers sur rail DIN du marché, et qui sera très peu cher. La répartition des fonctions sur plusieurs modules interconnectés mais néanmoins autonomes apporte une plus grande fiabilité et flexibilité. Le code est commun à toutes les modules, mais optimisé pour chaque type de modules (éclairage, volet, E/S). La maintenance est simplifié.

Maintenant, pourquoi le choix de l'ethernet UDP ? je dirais le choix d'une certaine modernité lol. C'est le média universel et moderne par excellence. Alors oui, il nécessite un switch pour faire communiquer plusieurs modules entre eux, mais qui n'a pas de switch chez lui ? Il permet de s'affranchir des distances, et est modulaire (topologie en étoile, pas besoin de faire courir un bus dans toute la maison, on peut étendre le réseau à l'infini).

Disons que l'idée d'utilisé l'udp ou tcp/ip est tentant niveau "facilité" de communication, mais comme tu le dis le Wiznet n'est pas donné et l'enc28j60 rajoute une grosse surcouche niveau programme donc source processeur et mémoire :~ Le fait d'être limité par le nombre de ports du/des switch me dérange également, sauf à prendre en conséquence ou en les empilant, mais bon consommation et cout serait également de la partie. J'aime également la pensée de maitrisé la chaine d'un bout à l'autre d'où le choix d'une solution "simple" :sweat_smile: à déployé tel que rs-485. Enfin tout ça est plutôt un avis et une réflexion personnel parce que cette solution est parfaitement sensée et valable et je ne contredirais pas ton choix là dessus .

Gromain59: J'ai bien hésité un moment entre RS485, I2C et CAN, mais je trouve ces technos certes éprouvés, mais soit pas adpatés (I2C) soit d'une autre époque (RS485). Pour le CAN, d'une grand fiabilité, il est malheureusement très mal implémenté dans les arduino/atmega. Pour l'utiliser, autant partir sur l'excellent projet Domocan de BigOnOff, mais c'est du Pic. Toute la documentation est en wallon.

J'avais également pensé au can mais c'est clair mal implémenté et les solutions rencontrée (shield tout aussi couteux que le wiznet) n'apporte rien de plus à comparé avec udp ou tcp/ip par exemple. L'I2C je préfère le réservé à d'autre chose. Le rs-485 d'une autre époque d'accord mais toujours maintenue et largement utilisé en entreprise (ce n'est pas pour rien). Une chose qui a tendance à saouler de nos jours c'est l'utilisation à outrance de nouvelle technologies certe moderne mais surdimensionné pour des chose simple et basique qui n'en on pas besoin. Je pense par exemple à l'usb qui ne fait que rajouté une complexité (drivers donc dépendance constructeur, os, etc ...) pour certaine tache qui n'en on pas l'utilité, une utilité c'est indéniable il en a mais c'est surtout le fait d'en faire une généralité et l'unique moyen de communiqué.

"Toute la documentation est en wallon" en effet, on distingue quelques mots c'est tout. :grin:

Gromain59: Au début du projet j'avais commencé à écrire mon propre protocole (largement pompé sur domocan d'ailleurs), mais je me suis vite rendu compte que l'ouverture vers le monde extérieur serait vite limitée. Puis j'ai découvert le protocole xPL (à ne pas confondre avec la techno CPL hein !!!). C'est un protocole ouvert, assez bien documenté, et supporté par un nombre croissant d'équipement (Squeezebox par ex) et de solutions logiciel (DOMOGIK étant ma préférée car 100% open-source, avec une IHM web, une appli android fonctionnelle et cerise sur le gateau, française). Son but est justement d'unifier l'incroyable profusion de techno plus ou moins propriétaires du monde de la domotique en faisant abstraction de la techno (plcbus, knx, x10, RF etc.).

xpl est bien pour ceux qui veulent profité d'équipements existant, sans trop se prendre le choux ou avoir besoin de maitrisé tel ou tel technologie, mais bon une nouvelle fois personnellement je n'aime pas justement ce côté dispersion/profusion de technologies. Par contre je peux parfaitement comprendre que ce système est intéressant pour ceux qui n'ont pas la patience, connaissances ou motivation dans ce genre de projet et qu'il est certainement plus utile à la communauté que le notre. Ça peux paraitre égoïste mais ici ce projet je le fais d'abord pour moi, je ne fais que le partagé et je vais surement avoir plus besoin d'aide de votre part que le contraire. ;)

Gromain59: Mais bon, libre à vous de créer un n nième protocole domotique :D

Pas vraiment créer, par exemple ici je ne fais que m'inspiré de ce qui existe déjà et assez commun (simple) entre tout ce que j'ai déjà vu dans le domaine.

Gromain59: Voilà pour mon modeste point de vue.

@ bientôt

Gromain59

PS1: un début de spécification de xplduino_v2 ici. PS2: je suis toujours ouvert à toute collaboration ;)

Tout les points de vue sont bon à prendre, même si je peux paraitre têtu et en désaccord je les respectes et comprends parfaitement. Ton projet risque d’intéressé beaucoup de monde surtout http://www.touteladomotique.com :grin: Pour la collaboration pourquoi pas un module xpl justement, c'est tout à fais envisageable sur le bus prévu (surtout pour ce qui est du genre Squeezebox justement :grin:) ;)

Ps: Vous m'entendez et m'entendrez souvent parlé de "dépendance", développeur objet oblige, le plus gros des différents point de vue avec les "électroniciens" viennent probablement de là.

zoroastre: Je ne suis pas tout à fait d'accord sur la multiplication des arduinos...

Il faut considérer que dans un système de communication multiple, les appels, traitements et retours d'information feront certainement appel à une gestion des latences rigoureuses. Les trains d'informations devront être entre-coupés d'attentes afin de libérer le bus le temps que se forme la réponse. De plus, Je choisirais plutôt une liaison 4 fils. Deux pour l'émission, deux pour la réception. Dans ce cas ci, les trains seront plus rapides, mais les attentes existeront toujours, l'arduino maître aura sa propre latence et il ne peut se passer des retours. Si l'idée est de gérer 4 pièces par exemples, en sus du maestro, nous avons 5 arduinos à considérer avec chacunes sa propre vitesse d'execution, sa propre faculté à composer le message et l'envoyer. Vous me direz, qu'est-ce 50 ou 80 ms !!! Cependant, si l'on double les arduinos, je vous laisse deviner...(pas sûr que ce soit proportionnel en plus)

Gromain59 utilise le protocole UDP via une liaison ethernet 10Mbit. Mais que veut dire

les performances sont satisfaisantes.

et combien d'arduino as-tu sur ta nouvelle topologie ?? UDP = perte possible, qu'en est-il ???

Je suis persuadé que l'on est loin d'utiliser toutes les capacités du langage de programmation. Sans évoquer le multitâche (*qui n'existe pas en fait), je pense qu'il faut cependant s'en inspirer. La principale limitation de la plupart des micro-controleur se situe dans la gestion serie des tâches qui lui incombe, séquentielle, j'ai souvent mesuré les temps d'execution de mes programmes, pour voir, et j'ai été régulièrement surpris de constater que le programme mettait 3 fois plus de temps à dérouler sa boucle dés qu'il y a communication (en moyenne 30-40 ms).

Vous me direz qu'une arduino par tâche est plus rapide qu'une seule qui s'occupe de tout, cependant ce que vous gagnez en vitesse d'execution, vous risquez de le perdre en communication.

Là dessus il s'agit plus du choix entre dépendances et performances, disons qu'il faut chercher le meilleurs compromis mais que l'un n’empêche pas l'autre. La seule solution c'est de testé et comparé, mais je me doute que les choses ne seront pas simple à mettre en œuvre (mais le plaisir dans tous ça est peut être justement là :) ).

zoroastre: Pour en revenir à la programmation, il manque plusieurs chose pour optimiser la gestion des tâches. Premièrement, il faut établir des règles de priorités et des règles de décisions. Je m'entends, si deux informations arrivent en même temps ou à peu d'intervalle, une avec un priorité "0", l'autre "1" (ou 2, ou 3, etc), j'execute d'abord la première. Secondement, il faut stocker ces tâches, les trier, les executer en utilisant une partie de la mémoire flash (rapide?) et en s'inspirant des règles du premièrement. Ainsi, on se rapprocherait du *préemptif que je suggérais plus haut. J'ai un ordre local et distant simultanément, je donne la priorité à l'ordre local. Le message y, arrivé aprés x, est plus important. Etc.

Pour cela j'avais pensé à la méthode/protocole CSMA (CA/DA ...) similaire à ta description.

zoroastre: Pour ma part, je commence à envisager également une évolution de mon projet, je m'oriente plutôt sur une carte à deux microcontroleurs (ATMEGA644), avec règles de décision, priorités et délégations vers le second processeurs au cas par cas. Du simili-clustering ou par analogie avec les automates modernes, une tâche rapide et une seconde pour le reste. J'y vois comme avantage la proximité entre les deux processeurs, donc des temps de communication trés réduit, doublement de la force de calcul (si j'arrive à implémenter du vrai clustering), une plus grande réactivité face aux événements multiples. Je commence à me documenter sur différents algos qui pourraient m'aider dans cette tâche. Je ne suis pas encore arrété sur le protocole "ethernet".

J'ai également pensé au 644p que j'ai vu sur le projet sanguino, enfin ce qui m'avais intéressé ce sont les deux uart pour justement faire du full-duplex rs-485 4 fils. Faudra absolument que tu nous tiennes aux courant de tes évolutions très intéressante. ;)

Gromain59:
Je confirme que le choix d’un seul arduino gérant une multitude de fonction (volet, éclairage…) est un mauvais choix. C’était mon choix avec xplduino_v1. L’idée était de profiter du grand nombre d’E/S d’une Mega et de limiter les couts car le shield Ethernet Wiznet n’est pas donné.
Le point fort:

  • ça marche en production depuis 1 an, sans problème majeur
    Les points faibles:
  • une maintenabilité du code assez pénible (nombreuses fonctions logicielles empilées)
  • une mise à jour impossible sans black-out de la maison (au moins le temps du chargement du soft, plus si loupé dans les modifs)
  • une intégration mécanique de l’arduino dans un boitier délicate

Mon idée est d’avoir un Arduino maître qui « gère » des unités de commandes autonomes, qui selon le cas peuvent être :

  1. simplement des éléments matériels avec les parties puissance par exemple pour la commande des fils pilote d’une installation de chauffage électrique où chaque pièce est équipée d’un thermostat avec un fil pilote, cette unité de commande (dont je joins le schéma pour une voie) est autonome puisqu’elle peut fonctionner en mode manuel (avec l’interrupteur) ou en mode automatique, alors l’automate (arduino) lui envoie :
  • 0V : mode normal => la température de consigne est celle affichée sur le thermostat,
  • 5V : mode réduit => la température de consigne est celle affichée sur le thermostat – 5°C
    En fonction de plages horaires et ou de commandes (forçage dans un mode ou l’autre) par le web.
  1. des dispositifs plus complexes qui peuvent nécessiter d’avoir leur propre processeur pour être autonomes, et ne recevoir que des commandes simples ou avec passage de paramètres de l’unité « maitre » et renvoyer des comptes rendus et des données là aussi limités. Je pense que dans un premier temps je n’aurai pas besoin de tels dispositifs.

Pour ce qui est de la maintenabilité du code, tu as raison. Même si on essaye de faire les choses très proprement, de documenter un maximum et de programmer d’une façon modulaire, c’est tout de même problématique.

Pour la question de la mise à jour et du black-out, si toutes les unités de commande sont autonomes, cela ne devrait pas poser de problème.

Pour ce qui est du boitier, je n’ai pas ce problème, j’ai un local technique, où j’ai mes tableaux électriques, alarmes, répartiteur téléphonie, système domotique actuel, switch Ethernet et NAS.

Unité de commande 1 voie.pdf (22.4 KB)

bonjour je lis ce topic depuis quelques jours.

ma petite expérience sur la "domotisation" qui vaut ce qu'elle vaut : il y a quelques années j'ai voulu un peu "domotiser ma "petite campagne" :grin: que j'occupe très épisodiquement.

l’écueil principal est AMHA le vecteur du transfert fiable de l'info. Si sur de la construction neuve, il est facile de réfléchir et d’intégrer du câble, ce n'est pas évident sur de l'ancien.

j'avais donc regardé du coté du X10 (à l’époque le CPL du pauvre :grin: ) et j’avais implémenté ça sur de la base PIC. pour mémoire, je me souviens avoir bien galéré sur de l’implémentation issue de schéma/code US , jusqu'à ce que je me rappelle qu'il y a une grande différence pour le X10 entre réseaux 50 et 60 Hz 8) )

mais j'ai assez vite abandonné l’évolution , mon "cahier des charges" se limitant à être prévenu d'une ouverture d’accès, d'une baisse de t°, de pouvoir à distance mettre hors gel , mettre en route chauffage/eau chaude quelques heures avant que j'arrive.

je fais ça "à l'ancienne" depuis pas mal d'année avec un bon vieux modem RTC à 4800 devant un PIC 8) (mais ça pourrait maintenant être arduino based )

La RS485 dont la fiabilité n'est plus à démontrer (différentiel) avec des compo dispos éprouvés à "pas trop cher" est une bonne solution, mais il faut quand même et toujours d'abord "tirer du câble"

Artouste:
l’écueil principal est AMHA le vecteur du transfert fiable de l’info.
Si sur de la construction neuve, il est facile de réfléchir et d’intégrer du câble, ce n’est pas évident sur de l’ancien.

j’avais donc regardé du coté du X10 (à l’époque le CPL du pauvre :grin: )

Ça rejoint tout à fais ma remarque précédente.

Pour moi le mieux serait une installation électrique comme Bribri en étoile (je suppose qu’il l’avait prévu à la construction ou rénovation), mais bon difficile de demandé de modifier son installation existante … (seignée, cablage, … :~)
C’est la principale raison pour beaucoup du choix du x10 (courant porteur) ou du sans fils.

Artouste:
La RS485 dont la fiabilité n’est plus à démontrer (différentiel) avec des compo dispos éprouvés à “pas trop cher” est une bonne solution, mais il faut quand même et toujours d’abord “tirer du câble”

Ça nous conforte dans notre choix. :slight_smile:

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 ?

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

UIT-V11_RS_485.pdf (206 KB)

UIT_X11_RS_485.pdf (518 KB)

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

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

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

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

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

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

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

Brisebee:
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, …)?

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

Brisebee: 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. :grin: 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 :astonished: et pour un prix entre 7/10 € pièce en chine je crois que je vais m'en commandé quelques un :grin:.

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

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.

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