Go Down

Topic: Domotique: projet xPLDuino (Read 7155 times) previous topic - next topic

Gromain59

Bonjour,

j'avais déjà évoqué mon projet dans l'ancien forum (Projet "domotique", faisabilité)
Depuis, il est en service chez mon beta-testeur de frère. Couplé au logiciel libre DOMOGIK grace au protocole XPL, je peux surveiller et commander à distance la maison via une page WEB. Quelques fonctions disponibles:
- commande ouverture volet en %
- ouverture/fermeture automatique des volets en fonction d'un seuil de luminosité...
- commande éclairage en %

Il y a quelque temps, un membre de l'équipe de développement de DOMOGIK m'a suggéré de mettre en ligne mon projet. C'est chose faite sous la forme d'un wiki accessible ici: Wiki xPLDuino
Désolé, il est essentiellement en anglais, mais je pense que la fonction de traduction Google saura aider les plus anglophobes.
Pour le moment il est très incomplet, mais j'essaierai de l'enrichir au fur et à mesure.

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

bluemax2011

Intéressant.

Tu vas pouvoir tout commander avec un seul arduino ?

Pour ma part, je suis resté bloqué à la commande de 4 switch avec l'Arduino !!!

Gromain59

Salut,

Quote
Tu vas pouvoir tout commander avec un seul arduino ?


On peut raisonnablement gérer 32 E/S avec un arduino, plus c'est tout à fait possible. Mais ce n'est pas le but de mon projet.
Pour faciliter l'intégration des composants dans des boitiers DIN, je vise plutôt un ensemble d'arduino spécialisés dans une tache, communiquant en réseau (Ethernet).

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

taddot

bonjour Gromain,

je m'incruste un peu dans ton topic :)

C'est du beau travail ce que tu as fait et j'ai une question : pourquoi avoir choisi d'intégrer la commande (capteurs/interrupteurs) ET la puissance ET la communication ethernet dans un même module ? Ne serait-ce pas plus simple (en terme de maintenance et de cout), d'avoir des modules "commandes", des modules "puissances", un module ethernet (+éventuellement des modules "communications" tel visiophone, interphone, ...), tout ce petit monde communicant via un "bus" qu'il serait aisé de mettre en oeuvre au niveau du tableau électrique (car, en domotique, tous tes capteurs et actionneurs doivent arrivés au TEG, non?)

En tout cas, beau travail, et très sympa de le faire partager. As tu une idée du cout comparé à une solution "commerciale" (InOne de Legrand, Tébis de Hager, etc...) ?

PS : oui, je sais, je suis un chieur :)

Gromain59

Salut,
Quote

je m'incruste un peu dans ton topic

Pas de problème !

Quote
pourquoi avoir choisi d'intégrer la commande (capteurs/interrupteurs) ET la puissance ET la communication ethernet dans un même module ?

Dans la première version, il y a un module (boitier) arduino+ shield ethernet, relié à des modules interfaces (commandes, puissances..). Le fait de pouvoir associer n'importe quel type de module d'interface sur n'importe quel "port" impose d'avoir un soft polyvalent, relativement compliqué à gérer.
Dans la deuxième version sur laquelle je concentre mes efforts, j'ai une approche un peu différente: je vais intégrer commande et interfaces dans le même boitier. Mais ce sera des circuits (pcb) différents: un circuit intégrant arduino+ethernet sur la même carte (commun à tous les boitiers), et en fonction de la configuration souhaitée, deux petites cartes multiplexeur ou démultiplexeur connectés aux cartes d'interfaces (gradateurs/capteurs/relais...). Ainsi, j'aurai un tronc commun hard et soft, et une partie personnalisée.
L'intégration mécanique en sera facilité (un seul boitier, au lieu de 3 pour les mêmes fonctions), la maintenance aussi: les données applicatives du boitier seront stockées sur mémoire externe. En cas de besoin de changer le boitier, il n'y aura qu'à rebrancher la mémoire externe sur le nouveau boitier, et remettre sous tension.

Quote
tout ce petit monde communicant via un "bus" qu'il serait aisé de mettre en œuvre au niveau du tableau électrique

J'ai réfléchi à un système de bus pour relier les cartes d'interfaces à la carte de commande arduino. Même si cela apporte de la souplesse, ça ne résout pas le problème de complexité du software.
Quote
(car, en domotique, tous tes capteurs et actionneurs doivent arrivés au TEG, non?)

Et justement, la solution d'intégrer tout dans un boitier commande/ethernet/interface, permet à la fois l'intégration dans un tableau électrique (ethernet faisant office de bus), mais permet aussi de déporter les boitiers au plus près du besoin (tableaux électrique décentralisés communiquant entre-eux par ethernet), afin de faire des gains  au niveau câblage. Plus besoin de tout centraliser au sein d'un même tableau. La maison pouvant être divisés en zones gérées chacune par un boitier.

Quote
As tu une idée du cout comparé à une solution "commerciale" (InOne de Legrand, Tébis de Hager, etc...)

franchement, non, je ne sais pas. Je ne connais pas les prix des solutions commerciales, même si je sais qu'elles sont hors de prix pour la plupart (prix des modules, prix du logiciel de configuration...).
Le coût d'un module se limitera au coût des composants et du boitiers (entre 50 et 80€ pour 16 à 32 E/S, les cartes gradateurs étant les plus couteuses). Mon but étant de proposer une solution DIY, flexible et ouverte sur le monde (du libre).

D'ailleurs, si certains sont intéressés pour participer, que ce soit au niveau programmation ou conception de carte électronique (mon point faible), je suis preneur ! le projet est complétement ouvert (xplduino at gmail.com)

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

RaphYot

Alors, ca me parait être le moment idéal pour te remercier  :D
J'ai passé quelques semaines a chercher les moyens de faire de la domotique pas trop cher, pour m'amuser et pas trop compliquée (ou hors de mes compétences on va dire). Tu ne peux pas imaginer le nombre de fois ou je suis tombé sur un de tes posts a partir du moment ou je me suis intéressé a adruino, xpl et domogik :-)
J'ai décidé de franchir le pas et j'ai reçu mon arduino la semaine passée, ma première étape serait d'interfacer ma centrale d'alarme en xpl, et a terme d'interagir avec sur d'autre systèmes connectés aussi en xpl, ce qui me semble maintenant faisable.

Très bonne idée le wiki, je vois que tu écris le code pour l'ENC28J60, bon courage!

Gromain59

Quote
Alors, ca me parait être le moment idéal pour te remercier


c'est toujours le bon moment de remercier, même si j'ajouterai "pourquoi donc ?"  :smiley-red:

Quote
J'ai décidé de franchir le pas et j'ai reçu mon arduino la semaine passée, ma première étape serait d'interfacer ma centrale d'alarme en xpl, et a terme d'interagir avec sur d'autre systèmes connectés aussi en xpl, ce qui me semble maintenant faisable.


J'ai prévu de permettre l'utilisation du port série pour ce genre de communication avec des équipements externes, afin de faire office de passerelle xPL (idem avec l'I2C)

Quote
tu écris le code pour l'ENC28J60

disons plutôt que j'adapte la bibliothèque pour supporter la réception de datagramme UDP en broadcast... Et ça marche plutôt pas mal. Des soucis encore de réinitialisation de la liaison en cas d'initialisation sans routeur ou PC connecté à l'arduino. Mais ça va le faire.
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

RaphYot


c'est toujours le bon moment de remercier, même si j'ajouterai "pourquoi donc ?"  :smiley-red:


Parce que j'étais parti pour faire un peut de domotique basique probablement juste un peut z-wave avec un serveur sous linux pour allumer/eteindre, j'ai cherché pas mal de solutions mais rien de convainquant. C'est là que j'ai trouvé domogik et xpl, puis l'arduino et ca m'avait l'air d'être la bonne combinaison.
C'est là qu'à chaque fois que je faisais des recherches je tombais sur un de tes posts, donc merci pour la doc online on dirait que personne n'a essayé ca avant ;-) Et puis surtout parce qu'une bonne partie du boulot a déjà été faite côté arduino, et que maintenant ca m'a l'air faisable donc je vais essayer de me lancer doucement dans l'aventure grâce à tout ca!

Pour le broadcast, j'ai parcouru en diagonale les docs XPL, a moins d'avoir mal compris il me semble que tout est fait en broadcast et je ne trouve pas ca très efficace, il me semble qu'il y a des cas ou on pourrait envoyer des packets unicast, genre on apprend l'adresse du hub et on lui répond en unicast, c'est peut-être ce que tu fais?
Je ne sais pas de combien de packets par seconde on parle, mais je me demande les performances de l'arduino suivent dans un plus grand projet par exemple je pense que j'enverrais déjà pas mal de traffic chaque fois qu'un détecteur de mouvement passe high, ca augment les risques de burst et on est en UDP donc risque de pertes... (bon je travaille dans les réseaux ip, déformation professionnelle je suppose).

Gromain59

Quote
C'est là que j'ai trouvé domogik et xpl, puis l'arduino et ca m'avait l'air d'être la bonne combinaison.

si tu n'y passes pas déjà, tu peux passer sur l'IRC freenode #domogik, j'y suis régulièrement la semaine. C'est un bon projet, même s'il n'est pas encore 100% compatible avec le mien (vivement la v2).
Je suis moi-même étonné qu'il n'y ait quasiment rien sur le net mariant arduino et xpl. Pourtant, c'est très complémentaire.

Quote
il me semble que tout est fait en broadcast

oui, c'est bien ça, xpl se base sur le broadcast. A défaut d'être le plus performant, je pense que ça permet de garantir le maximum d'interopérabilité entre les équipements. Si je ne me trompe pas, le multicast obligerait d'avoir un routeur ou un switch compatible et des devices capables de s'inscrire au groupe.
Mais tu as raison, un fort traffic, et tu risques de saturer le rx buffer et de faire planter l'arduino (expérimenté sur un shield officiel wiznet). Il me semble donc qu'il faut un réseau propre, sinon dédié à la domotique pour éviter de saturer les devices.

Quote
je travaille dans les réseaux ip

c'est bon à savoir ça ;)
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

RaphYot

Je suis déjà passé une fois par l'IRC domogik et ils m'ont bien aidé, j'y ai retrouvé pas mal de noms connus des forums ;-)
As-tu pensé renvoyer les packets de l'arduino vers le hub en unicast? Ce n'est pas compatible avec les specs xpl, mais au moins les autres équipements n'auraient pas à traiter tout ce traffic qui ne leur est pas destiné, et a moins que xpl_hub ne vérifie si c'était bien du broadcast il devrait recevoir les données. Je pensais que ca serait une solution si j'arrive a me connecter a cette centrale d'alarme et qu'elle génère trop de traffic.

Gromain59

Quote
As-tu pensé renvoyer les packets de l'arduino vers le hub en unicast?

à vrai dire non. Vu le traffic généré (peut-être 5 messages/secondes), je suis loin de saturer l'arduino. Et je ne pense pas que ton alarme va saturer le réseau, car un port série a un débit beaucoup plus restreint qu'Ethernet.
Ce qui est plus gênant avec l'ENC28J60, c'est qu'il ne peut pas filtrer spécifiquement un port (ex 3865, le port xpl), c'est au µC de le faire. Du coup, comme il faut désactiver le filtre qui exclut les messages broadcast, le µC a beaucoup de boulot si le réseau est pollué par des softs qui passent leur temps à faire des requêtes broadcast (genre google toolbar...).
Avec un switch un peu évolué, on doit pouvoir filtrer tout ça (autoriser uniquement les messages broadcast provenant du port xpl) non ?
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

RaphYot

Oui, donc je ne m'inquiète pas de saturer le réseau mais plustôt les autres modules arduino si ca commence a envoyer des tas de paquets dans tous les sens j'avais l'impression qu'on risque de rater un paquet important assez facilement.

Dommage cette histoire de filtre. Je travaille surtout sur des routeurs (pour Cisco) mais les switch normalement ne regardent pas les informations L3 (IP) ou L4 (UDP) quand ils ne font que du switching, donc trouver un paquet broadcast ca irait (grâce à la MAC adresse, pas a l'adresse IP) mais je ne pense pas qu'on puisse rechercher le port UDP. Donc filtrer au niveau 2 juste sur les adresses MAC n'est pas intéressant dans ce cas. En plus ce n'est pas le genre de switch que je mettrais dans une maison (trop cher pour l'utilisation qu'on en ferait, et surement trop gourmand).

Je crois que la meilleure chose a faire si on ne veut qu'un seul gros switch est encore de séparer les réseaux avec des VLAN, la pluspart des switch "manageable" sont abordables et devraient offrir une bonne solution, et je pense qu'il est assez facile sous linux de créer deux interfaces, une pour chaque VLAN (faire un trunk donc) sur le serveur domogik qui pourrait servir de passerelle entre réseau domo et réseau interne.
Sinon il on peut aussi simplement séparer physiquement les réseaux avec deux "bêtes" switch et avoir un routeur au milieux qui a deux interfaces, une dans chaque switch, là encore on peut le faire sur un serveur linux/domogik.

Gromain59

Quote
si ca commence a envoyer des tas de paquets dans tous les sens j'avais l'impression qu'on risque de rater un paquet important assez facilement.

ça doit arriver ponctuellement, mais le buffer de réception est là pour absorber les pics. Le wiznet et l'ENC28J60 possèdent tout deux 8ko de buffer. Sur le wiznet, ce buffer est partagé par les 4 sockets, mais on peut ajuster leur taille en favorisant l'un ou l'autre.

Je sais que si je connecte les arduinos sur un vieux hub, celui-ci renvoit le message broadcast à tous, y compris l'émetteur, qui fini par tourner bourrique...

Pour les solutions techniques, on verra ça quand le projet aura déjà bien avancé :)
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

Go Up