Aidez nous ! Projet - Gestion domotique

[olebrun]

Chacun voit midi à sa porte. En tout cas le protocole existe et est utilisé, la lib est dispo et si ça peut aider quelqu'un tant mieux. Moi je l'utilise et je pilote toute ma maison avec donc je peux te dire que c'est viable
++

Edit:
J'ai lu une partie des 27 pages pour mieux comprendre pourquoi cette "animosité" envers xPL ... j'aurai du le faire avant  .
En partant sur de multiples "noeuds", une des obligations est de taille au mieux chaque µc pour limiter le cout (corrigez si je me trompe) du coup, je comprends mieux. Dans cette archi on pourrait voir xpl seulement sur un des noeuds (une passerelle) qui serait charger de dialoguer avec le reste du monde ?

[osaka]

En partant sur de multiples "noeuds", une des obligations est de taille au mieux chaque µc pour limiter le cout (corrigez si je me trompe) du coup, je comprends mieux. Dans cette archi on pourrait voir xpl seulement sur un des noeuds (une passerelle) qui serait charger de dialoguer avec le reste du monde ?

C'est principalement moi qui part sur une solution modulaire complète, 1 µc par tache différentes comme pour le knx par exemple (chaque tache peut également être étendu pour en augmenter le nombre, ex: 5 modules de 8 I/O,2 module 5 entrée ana pour divers capteurs, etc) , zoro lui par exemple réparti les taches lente et rapide sur deux µc.
Pour ma part la raison est simplement de supprimer les dépendance entre taches (facilite le dév également), par exemple si 1 de mes modules 8 I/O vient à rendre l'âme,les autres sont toujours fonctionnel tendis qu'avec 1 seul be tu à l'intégralité de tes taches en rade, de plus je ne suis pas limiter aux nombre d'I/O d'un seul µc puisque je peux les étendres (avec une limite quand même selon la façon dont seront gérer les adresses : 1 octet = 256 adresses possible,2 octet = 65536 adresses possible, il y a de quoi faire  ).
Donc ça parait disproportionné et niveau cout c'est sans doute plus chère que la solution 1µc pour tous gérer  mais beaucoup moin qu'une solution knx par exemple qui se monte vite à quelque millier d'€ ou même zwave, plcbus, etc (1 module par prise ou interrupteur, volet à mini 30€ sans le contrôleur : zibaze ou autre  ).

Mais bon il faut dire qu'ici on a presque toute les connaissances pour pouvoir le réaliser (raison du topic, on s'entraide avec les connaissances de chacun, dev, elec, ...), ce n'est pas tout le monde qui peux ce permettre de réaliser un système de A à Z comme ont est en train de le faire, d'où l'intérêt du xpl par exemple (s'il est textuel c'est bien pour que les humain non initié sachent le lire et le comprendre et non les machines qui ne parle que binaire alors que pourtant c'est à eux que s'adresse le message au final), maintenant ici comme tu le dis rien ne m'empêche d'ajouter un module qui ferait office de passerelle xpl et ne ferait que ça.
Pour la com avec le monde extérieure on gèrera également l'intégralité, surement via client léger (web) et ou client lourd mais toujours en perso.


Edit: regarde le tuto de barbu http://arduino.cc/forum/index.php/topic,102540.0.html pour mieux comprendre la différence entre protocoles.

[olebrun]

Code: [Select]

raison du topic, on s'entraide avec les connaissances de chacun, dev, elec, ...

C'est bien pour cela que j'ai posté ici . Apres je peux comprendre les differentes orientations bien sur.

Si ca interresse, voici mon retour d'expérience:
Pour ma part, c'est simple la priorité au départ était le cout et ne m'y connaissant pas trop en elec j'ai trouvé l'arduino super abordable. Ensuite ça a évolué vers la fiabilité, cout et évolutivité. Du coup un Arduino par tableau (vielle maison), mais extensible, je peux ajouter une carte et piloter une io d'une carte depuis une autre, comme tu veux faire en fait.
L'arduino se contente de gerer les fonctions basiques, et un nas sert à loger en base toutes les remontées (capteurs, io etc) pour faire des scenarios évolués et des statistiques de conso d'energie. Et héberge l'interface web de commande (j'ai developpé un debut d'addon xbmc et une app android aussi ... bcp plus reactif que l'interface web).

Je gerais (gerais car je viens de vendre ma maison) avec un arduino mega ~15points lumineux et leurs interrupteurs, radiateurs elec par fil pilote, volets, store banne, un reseau 1wire pour les températures.
et sur un duemilanove, la chaudiere(bruleur, cirulateur et motorisation vanne 4 voies), 2 compteurs d'eau.
Le tout fesait des remontés en xpl à chaque changement d'état et étaient pilotés en http (pas encore de parseur xpl à ce moment là).

Voila ce que je peux dire de ma petite expérience. J'avais un mega en spare au cas ou. Il a servit une fois, changement en 2minutes (le probleme venait du shield ethernet en fait). A part cela, aucun problemes pendant 2ans, aucune lenteur malgre les multiples taches.

Edit:
Un exemple de l'intérêt d'utiliser un protocole standard (que ce soit xpl ou autre). Hier soir j'ai installé un addon xPL sur xbmc. Du coup, je peux faire réagir mes arduino en fonction des actions xbmc sans rien développer, à part les réactions souhaitées. C'est un des avantages.

[MiGaNuTs]

Bonjour,

j'arrive sur ce topic suite au conseil d' Osaka sur un autre topic du forum.

Je suis électricien industriel au départ (j'ai un BTS electrotech depuis un bon moment maintenant, et quelques années d'expérience en installation, mise en service, maintenance, SAV de trucs divers dans l'industrie), et avec le temps je mets de plus en plus les pieds dans le monde de l'automatisme et de l'informatique industrielle (je délaisse un peu le multimetre pour le PC petit a petit). Du reste au mois d'octobre si tout va bien je devrais reprendre mes études (a 34 ans) et me lancer dans une licence pro Automatisme et info industrielle (parce que niveau programmation j'ai qd même des lacunes)

Des qu'il y'a un peu de logique programmable qui commande des machins électriques, ca attire mon attention (c'est plus fort que moi), et par extension je m'intéresse aussi a la domotique.

J'avais déjà ma petite idée (pas complètement figée cependant) pour utiliser un Arduino en guise d'automate avant de passer sur ce sujet, (je vous mets mon griboulli en pièce jointe. c'est le même que sur l'autre topic) et je constate que vous avez déjà pas mal creusé la question, vous êtes même allés bcp plus loin que moi.

Je m'attelle dons a la lecture intégrale de ce topic, et je vous tiens au courant de ce que j'en pense.
En attendant vous pouvez toujours me dire ce que vous pensez de mon approche de la question. Je me suis "vachement inspiré" de ce qui existe deja dans l'industrie.

[osaka]

j'arrive sur ce topic suite au conseil d' Osaka sur un autre topic du forum.

Yop Yop

(je délaisse un peu le multimetre pour le PC petit a petit). Du reste au mois d'octobre si tout va bien je devrais reprendre mes études (a 34 ans) et me lancer dans une licence pro Automatisme et info industrielle (parce que niveau programmation j'ai qd même des lacunes)

Moi je fais l'inverse à33 ans, je passe du monde de la programmation au monde industriel.  

En attendant vous pouvez toujours me dire ce que vous pensez de mon approche de la question. Je me suis "vachement inspiré" de ce qui existe deja dans l'industrie.

D'après ton diagramme ton approche modulaire est assé proche de la mienne.

Edit: skuzmi est devenu Blizzard27 ?

[Skuzmitoo]

Salut, oui j'ai changé de pseudo. Je ne vous ais pas abandonné et je lis toujours vos avancées mais malheureusement pour moi je suis toujours en location, je me familiarise toujours avec l'arduino, je commence a dompter un peu la bête, je suis actuellement sur un projet d'applique murale avec 6 LED's 3W RGB avec gestion télécommande IR, SPI avec les WS2801 et Transformation de fourrier pour gérer l'audio avec tout cela je serais calé, je m'efforce de créer de objets afin d'avoir un code propre. La prochaine étape sera la construction d'une CNC car c'est un truc qui me manque vraiment et après je vous rejoindrais même si je vois que chacun de vous a bien avancé sur le sujet.

Etant en location, je partirais sur une brique logiciel pour gérer un capteur de température, d'humidité, de lumière et de présence par pièce et une autre brique pour avoir un suivi de la consommation électrique. Viendra ensuite une brique pour gérer l'éclairage tout en gardant le mode manuel comme prioritaire.

Pour résumé, je suis toujours là, même si j'ai un peu déserté le sujet pour le moment et avec deux enfants le temps passe vite.

[MiGaNuTs]

En fait apres réflexion et lecture de vos messages, je pense que l'arduino "master" de mon croquis, on peut s'en passer et confier le boulot au serveur.

Le RS 485 me semble le bus le plus adapté pour faire communiquer tout ce petit monde de façon fiable.

Reste la question du protocole de communication pour tout ce petit monde.

[MiGaNuTs]

Je m'auto réponds, bien qu'en fait ma réponse amène d'autres questions.

Le soft qui pourrais faire l'affaire sur le serveur de mon installation semble deja exister, ou du moins il en existe un qui pourrais peut etre faire l'affaire :

http://mango.serotoninsoftware.com

La chose communique en modbus, technologie éprouvée sur le RS485.

l'arduino servirait donc uniquement pour réaliser des esclaves indépendants gérant chacun un petit bout de l'installation (ainsi en cas de panne on ne perds qu'une partie de l'installation et non pas tout).

[chestroled]

Salut Miganuts,

j'opte moi aussi pour un système ou les arduinos sont esclaves et le serveur central maitre ( il n'y a dans mon cas pas de raison valable d'utiliser une Arduino en maitre) , je pense aussi passer par une gestion série mais ne saisi pas encore les différence entre RS232 ou RS485 étant débutant dans le domaine des communications et de la prog...

Pour ton soft, j'ai jeté un coup d'oeil et je ne sais pas quels sont tes projets exacts et si il pourra répondre à ceux-ci. Peut-être pourrions nous comparer nos objectfs ?

Dans mon cas j'ai déjà investi dans le logiciel Homeseer PRO ( j'ai craqué sur la licence à moitié prix...), faut avouer j'ai un peu du mal avec les systèmes Linux toussa...


Au plaisir

[MiGaNuTs]

Mon objectif principal est d'apprendre, en utilisant autant que possible des "trucs" open software, open hardware, etc...

Je pense que je vais commencer par une station météo, avec des courbes sur le long terme etc. (j'ai déjà + ou - qqch qui fait du datalog pression, température, humidité (enfin le capteur de HRE déconne depuis qu'il a pris une averse un peu trop sévère ^^), mais je suis pas complétement satisfait de mon taff)
Ensuite peut être un module de régulation de chauffage, ou un compteur d'énergie ou je ne sait pas encore.

Je viens d'installer mango pour voir ce que ça donne, pour le moment j'arrive même pas a le démarrer. Le support a l'air pas terrible (surtout comparé a la communauté arduino ou y'a qd même bcp d'intervenants).

Bref, je creuse.

[chestroled]

Salut Mignatus,

je ne sais pas si cela répondra à tes besoin car c'est plus orienté interface mais il existe Domogik , il est sortit en V0.1.0 donc c'est encore le début mais semble très prometteur et bien sur opensource

Bon dimanche

[osaka]

Salut, oui j'ai changé de pseudo

Bon ben finalement ça sera Blibli au lieu de skuzmi on est pas loin de Bribri.  

La prochaine étape sera la construction d'une CNC.

Sujet qui devrait intéresser du monde.

Dans mon cas j'ai déjà investi dans le logiciel Homeseer PRO ( j'ai craqué sur la licence à moitié prix...), faut avouer j'ai un peu du mal avec les systèmes Linux toussa...

mmmmh je ne sais pas trop ce que peux apporter Homeseer (windows only, pc, ...)  dans la gestion de plusieurs esclaves arduino, plugin existant ou à développer, je pense pas ou plutôt ne sais pas s'il en existe et si oui ça doit être limiter coté arduino ?
Pour Domogik le projet xpl de Gromain ou ce dont parlait olebrin peut être intéressant pour les débutants ?

En fait apres réflexion et lecture de vos messages, je pense que l'arduino "master" de mon croquis, on peut s'en passer et confier le boulot au serveur.

Attention il y a maître de bus qui gère la communication (collision, priorité, ...) entre esclaves (architecture maître-esclaves -> voir modbus par ex) et il y a maître de l'installation qui lui gère l'installation (ordres, commandes, enregistrement données, horaire, scénarios, ..., interface, ... ) ce n'est pas la même chose et comme je le voyais sur ton schéma je pensais que c'était pour le premier cas ?
(Dans ma gestion du bus je me passe de maître et gère le risque de collision différemment, avec protocole maison mais pas si éloigné de ce qui existe déjà).

[MiGaNuTs]

Dans mon idée le mini serveur est a la fois le maitre de l'installation au sens ou il distribue les ordres aux différents modules, et c'est également lui qui est le maitre du bus, les modules étant des esclaves au fonctionnement le plus simplifié possible.
Au départ je voulais même pas mettre d'intelligence dedans, mais c'est gênant le jour ou le serveur tombe en rideau car plus rien ne fonctionne du coup.


Mango me semble vraiment pas le meilleur choix coté serveur, le support c'est vraiment pas ça. Apparemment la boite qui a repris le projet a son compte ne joue pas trop le jeu de l'open source :/


Je veux éviter au maximum les solutions propriétaires et/ou fermées, et surtout ne pas réinventer la roue.

[Brisebee]

Bonjour,
Me voilà à nouveau sur ce forum, pour faire un point sur l'avancement de mon projet : DOMOWEB 2012.
Même si mon activité durant la période de congés à été fortement ralentie, j'ai tout de même progressé. J'ai avancé sur deux plans :

1) J'ai intégré dans le programme, différentes fonctionnalités, (tout cela fonctionne très bien) :
- Les plages horaires sont stockées sur une carte SD, elles sont lues puis stockées en RAM (pour le moment, lors d'un reset).
- Des plages horaires par défaut sont stockées en EEPROM, en cas de défaut de lecture de la carte SD, ce sont ces plages horaires qui sont transférées en RAM.
- Une LED clignote à une fréquence de 10Hz lorsque le système fonctionne en mode normal, et de 1Hz lorsqu'il est en défaut.
- L'horloge RTC DS1307 est synchronisée avec un serveur NTP, là aussi uniquement lors d'un reset pour le moment.
- Le back light de l'afficheur LCD est éteint lorsque l'éclairement est très faible, cela n'est pas du tout important. Mais comme mon système fonctionne dans un local technique qui n'est en règle générale pas éclairé, en passant devant, et en fonction de la vitesse de clignotement de  la LED, je vois tout de suite si tout est OK, alors que lorsque le back light est allumé, je vois moins distinctement le clignotement de la LED. (c'est un détail !)
- Un capteur de température OneWire DS18B20 donne la température ambiante.
- Les sorties (10 pour le moment, qui correspondent à mes électrovannes d'arrosage) sont activées ou désactivées en fonction des plages horaires.
Je joins le programme de l'arduino (.ino), il est très largement perfectible.

2) J'ai travaillé sur le transfert de données via le web :
A partir des éléments fournis par Osaka (que je ne remercierai jamais assez), j'ai « géré » des sorties (2 pour le moment) en fonction des plages horaires avec une possibilité de forçage via le web.
Je vais très prochainement donner plus d'infos sur cette partie sur cet autre topic http://arduino.cc/forum/index.php/topic,111101.0.html, d'autant plus que j'ai quelques questions à vous poser.
N'hésitez pas à me faire vos remarques, suggestions ou autres critiques, c'est comme cela que j'ai pu avancer, et si cela peut également servir à d'autres ce n'en sera que mieux.
Bien à vous

[Brisebee]

Bonjour,

Je relance ce topic, après plus de 6 mois d'inactivité !
Pour vous dire que j'ai enfin fini la première partie de mon projet.
J'ai encore pas mal de travail pour la suite, et pour optimiser l'existant.

J'ai posté les différents éléments, descriptifs, photos, ... ici : http://g.sinnig.free.fr/spip.php?article7

Je vais également faire un petit post sur projets finis.

N'hésitez pas si vous voulez des compléments d'information.

Bien à vous