Aidez nous ! Projet - Gestion domotique

Brisebee: je n'ai pas trouvé (peut-être n'ai je pas bien cherché), un tuto complet => qui explique aussi les avantages et les inconvénients des différentes solutions, des deux cotés (arduino et web) et accessible à un quasi débutant dans ce domaine.

Pour le choix je peux peut être un peut t'orienter.

Choix de l’hébergement :

1) local arduino avantages : - Pas d'intermédiaire, accès direct arduino

inconvénients : - limité par les caractéristiques mémoire de l'arduino. - sécurisation du code compliquée (voir poste chico).

2) local hébergement Nas ou autres avantages : - peux de limite concernant la tailles du code - pas de restriction concernant le choix du langage dynamique (php, java, python, c, ...) et mode de communication (socket, requête http, ...) inconvénients : - intermédiaire en plus à gérer (consommation, configuration, appli serveur, sécurisations, ...)

3) extérieure hébergement mutualisé ou autres avantages : - peux de limite concernant la taille du code - pas besoin de gérer sois même les problème matériels, paramètres réseau, appli serveur, sécurisation, etc, ... inconvénients : - intermédiaire en plus par rapport à la solution arduino - restrictions niveau langage dynamique (php utilisé principalement) et mode de communication (socket bloqué, etc, ...) - si l’hébergeur est out momentanément, plus d'accès faudra patienter

Maintenant point de vue solutions web et échange de données avec l'arduino :

1) html simple avec formulaire page html -> requête avec transmission de valeurs du formulaire -> traitement en réception des valeurs -> construction du nouveau code html -> réponse html.

avantages : - communication et traitement direct - simple

inconvénients : - limite mémoire arduino ... - obligation de régénérer la page complète.

2) html et ajax (javascript+socket php) page html+javascript -> requête http avec valeurs -> réception et traitement page php -> transmission de valeurs via socket php -> réception socket arduino -> traitement des valeurs reçues -> retour socket arduino de valeurs (états ou autre) éventuels -> réception et traitement socket php -> modification de portion du code html avec les valeur retournées via javascript.

avantages : - code étendu et dynamique - pas besoin de régénérer la page complète, juste les valeurs de retour éventuels.

inconvénients : - appli serveur intermédiaire, hébergement du code à l'extérieure (local ou externe au réseau). - complexe, plusieurs langage, ... - traitements intermédiaire.

3) html et WebSocket (javascript)

Entre () les websocket on va dire que c'est un socket implémenté dans ton navigateur (client) et non pas sur le serveur (via php) comme dans la solution précédente, il communiquera directement avec ton arduino (enfin il faut toujours un serveur intermédiaire pour l'instant à cause d'un handshake et masquage des données, opération trop lourde pour l'arduino).

  • page web+javascript -> valeurs transmises via socket directement depuis le navigateur (client) -> serveur de websocket (java, php, ...) traitement spécifique websocket (unmasking) -> réception socket arduino et traitement -> retour de valeurs éventuels -> serveur de websocket (masking) -> réception socket du ou des clients !!! (navigateur) -> modification de portion du code html avec les valeur retournées via javascript.

++ Maintenant sans aucune demande ou intervention du client (navigateur). changement d'états, capteurs ou autres arduino -> serveur de websocket (masking) -> réception socket du ou des clients !!! (navigateur) -> modification de portion du code html avec les valeur retournées via javascript.

avantages : - code étendu et dynamique. - pas besoin de régénérer la page complète, juste les valeurs de retour éventuels. - l'arduino peux initié la communication sans aucune interventions de la part du client (navigateur) et donc modifier l'interface web. - chaque clients sera informé en quasi temps réel d'un changement d'état provoqué par un autre client ou l'arduino même

inconvénients : - appli serveur intermédiaire+ hébergement du code à l'extérieure (local ou externe au réseau). - standard pas encore finalisé (mais ça avance bien). - handshake (uniquement à la demande de connexion au serveur) et masking à gérer (mask obligatoire pour l'instant, optionnel dans le futur normalement).

Bon ici mon choix va aux websocket, maintenant on a toujours besoin d'une appli serveur intermédiaire (que j'ai fais en java momentanément) mais que je compte bien intégrer directement dans le futur via l'arduino DUE plus performante.

Au final ce qui complexifie les choses pour toi (pour tous) c'est qu'il faille hébergé le code en dehors de l'arduino, donc trouvé un autre moyen de faire la liaison entre ton arduino et ton interface (code html). Maintenant grâce aux socket, requêtes http, ajax, ... on y arrive mais c'est au prix du mélange de différente techno et langages ... :~

Bonjour, Excellent topic, néanmoins je cherche les cahiers de charges associés « je suis exigent je sais :grin:» pour m’inspirer car je compte aussi faire un projet domotique à base d’un arduino mega et reconnaissance vocale pour le reste pratiquement le même principe N.B: Je cherche le cahier des charges pour me mettre sur rail et pouvoir me synchroniser avec vous XD

Une question assez importante pour moi, peut-on gérer un téléviseur, démo, climatiseur » tous équipements à base de télécommande infrarouge à base d’arduino ? une idée peut-être à ajouter sur le cahier des charges Si C’est oui ? Je suis cherche simplement des orientations Merci les amis ;)

Tu trouveras le cahier des charges de Bribri ici http://arduino.cc/forum/index.php/topic,80422.msg713891.html#msg713891 On a pas tous le même, moi je part plus sur une solution modulaire de plusieurs arduino sur bus rs-485, mais ce post est plus une entraide entre nous pour les parties communes, on profite ainsi également des différentes connaissances (electro, prog, ...) de chacun. Pour l'ir il existe pas mal de solutions

http://blog.le-guevel.com/?p=283 http://www.arcfn.com/2009/08/multi-protocol-infrared-remote-library.html http://www.pjrc.com/teensy/td_libs_IRremote.html . . .

Donc c'est tout à fait possible.

;)

Merci Osaka pour toutes ces infos, je vais essayer d’ingérer et digérer tout cela, pour voir ce que je peux en faire.

nadirovick:
N.B: Je cherche le cahier des charges pour me mettre sur rail et pouvoir me synchroniser avec vous XD

J’avais publié sur ce topic une première version du cahier des charges.
J’en profite pour publier la version actuelle, je vais bientôt rajouter le descriftif du fonctionnement de l’unité de gestion (programme arduino) et des communications et échanges de données avec le serveur web (quelle que soit la solution technique retenue).

nadirovick:
Une question assez importante pour moi, peut-on gérer un téléviseur, démo, climatiseur » tous équipements à base de télécommande infrarouge à base d’arduino ? une idée peut-être à ajouter sur le cahier des charges Si C’est oui ? Je suis cherche simplement des orientations

Je n’ai pas réfléchi à cela, mais il y aura surement quelqu’un qui a fait un projet en ce sens.

@+

Cahier_des_charges_detaille_du_systeme_domotique_avec_interface_web[2].pdf (610 KB)

merci les amis :* je serais de retour prochainement sur ce topic je commence et je vous tiens au courant @+ ;)

J’ai repris tranquillement les différentes infos données par Osaka et j’ai revu le post de Chicotore.

C’est vrai que le plus simple serai de pouvoir se passer de serveur externe, peut-être en stockant certaines données, et peut-être aussi les images, sur carte SD. Je n’ai pas vu d’exemple qui utilise la carte SD de l’Ethernet shield en même temps que l'Ethernet fonctionne en serveur web. Est-ce possible ?

Sinon il faudra que je m’oriente vers la solution d’un mini serveur web perso.

Brisebee: C’est vrai que le plus simple serai de pouvoir se passer de serveur externe, peut-être en stockant certaines données, et peut-être aussi les images, sur carte SD. Je n’ai pas vu d’exemple qui utilise la carte SD de l’Ethernet shield en même temps que l'Ethernet fonctionne en serveur web. Est-ce possible ?

Normalement c'est possible, je n'ai jamais essayé mais il y a eu un poste récent qui en parle justement. http://arduino.cc/forum/index.php/topic,104855.0.html

Maintenant tout ça me semble assé lourd et peux adapté à nos peti µc s'il faut rajouter à celui ci toute la gestion domotique :~ .

Brisebee: Sinon il faudra que je m’oriente vers la solution d’un mini serveur web perso.

Comme dit précédemment pour moi l'arduino n'est bon que pour faire du minimaliste, la solution chico même si "légère" est déjà limite, donc les solutions externe à celui-ci sont inévitable si on veux aller plus loin, ou alors prendre plus performant tel que la futur DUE par exemple si on veux éviter les intermédiaires. En solution externe il y a de petite plateforme qui arrivent tels que http://www.raspberrypi.org/ mais pas encore du 100% dispo.

Donc au final tout dépend des besoins, mais le choix est difficile j'en suis toujours à étudié les possibilités ... :sleeping:

Yep!

Dans mon optique, l'arduino n'est pas fait pour heberger un serveur web tel quel. Il faut effectivement s'orienter vers des solutions d'externalisation. Pour ma part, j'ai plutôt opté pour une solution, certes fermée, mais qui correspond plus à mes besoins : développement d'une application complète et si possible portable.

Je ne me suis pas encore arrêté sur le langage de programmation et envisage de plus en plus de remplacer python par c++ ou java.

C'est aussi une des raisons qui me font pencher vers le double coeur tant la comm devient rapidement consommatrice de ressources et de temps.

@+

Zoroastre.

Bon donc je vais essayer de monter un serveur web avec un vieux noteboock sous XP avec Apache.

Je rédigé un peu rapidement, (il y a sûrement des erreurs et des oublis), le cahier des charges de l’unité de gestion avec notamment le transfert des données. J’ai considéré les deux hypothèses : avec serveur web externe ou interne, mais c’est vrai que la seconde hypothèse n’est pas évidente !
Je vous le soumets pour critiques et pour envisager des solutions.

@+

(Cahier des charges détaillé de l’unité de gestion).pdf (16.9 KB)

Yep!

Première remarque, tu peux déjà dissocier la gestion de l'horloge du serveur web. Un serveur ntp est justement fait pour çà.(vf librairie)

Tu émets l'hypothèse que l'arduino doit se renseigner régulièrement auprés du serveur web pour receuillir de nouvelles données. Dans l'idéal, un formulaire avec un bouton de validation informe l'unité de gestion que des nouvelles données sont disponibles. C'est à mon sens plus réactif ainsi.

Egalement, tu peux trés bien intégrer dans ton serveur web, un évenementiel indiquant au système de gestion qu'un utilisateur est entrer en mode paramétrage et renvoyer un echo de connectivité établi. De même pour la lecture des sondes...

Ainsi dans l'essentiel, l'arduino se contente la plupart du temps d'envoyer une trame contenant les informations in situ du système domotique (stats, logs, etc), c'est ici le principal interêt d'un serveur web.

@+

Zoroastre.

Yep!

Pour illustrer, dans mon logiciel, j'ai intégré 2 boites (login + mdp) --> envoi info à l'arduino = il y a un client + mise à jour en direct des sondes.

Lorsque je modifie un paramètre, le bouton validation remplie le buffer de sortie en attente d'expedition vers l'arduino (à la milliseconde prés)...

La trame grosso modo :

self.dicoParam = {'mode':'#', 'abs':'#', 'vac':'#', 't_jour':'#', 't_nuit':'#', 't_abs':'#', 't_vac':'#', 'cal':'#', 'day_at':'#', 'night_at':'#'}

(Le symbole '#' est ignoré par l'arduino)

Ainsi, une grosse portion du code est appelé uniquement à la demande. En parallèle, j'envoie quelques logs à intervalles réguliers.

Pour info, dans ma version, un pc se charge de faire le proxy entre l'arduino et la liaison ethernet. Mais le principe est là pour le fond (ma prochaine étape est de communiquer en liaison direct sans le pc, donc j'y arrive aussi ;) )

@+

Zoroastre.

Merci Zoroastre, je vais voir tout cela, pour le moment je ne sais pas comment faire ce que tu proposes, mais je vais continuer à avancer pas après pas.

En prenant les problèmes les uns après les autres.

@+

Yep!

Je te rassure, j'ai aucune idée de comment faire ceci en php ou java. Nonobstant, qu'un interfaçe web peut trés bien intégrer ce que l'on appèle des scripts cgi écrit en python, ruby, c++ ou tout autre langage compatible. Ces petits programmes agiront comme bon te semble et peuvent parfaitement travailler avec apache entre autre.

Je te recommanderais personnelement de travailler avec un langage que tu maitrises...aprés web ou pas web, c'est une question de gout.

Je reconnais tout de même que d'avoir des graphiques et un historique détaillé est un des avantages indéniable d'un hebergement externalisé.

Bon courage.

@+

Zoroastre.

Quelque schémas pour mieux visualiser les solutions.

Solution 1 : Hébergement du code html sur arduino.

Solution 2 : Hébergement du code html et javascript en externe sur du mutualisé, requête http à l'arduino via ajax.

Solution 3 : Hébergement du code html et javascript interne a son réseau, la communication avec l'arduino ce fait via requête http depuis le navigateur au serveur (ajax) et celui ci redirige les information via socket executé en php, java, ou autre vers l'arduino ...

Solution 4 : Hébergement du code html et javascript en interne ou en externe a son réseau, la communication avec l'arduino ce fait via websocket exécuté directement par le navigateur ce qui permet une liaison direct navigateur -> arduino. Il est possible également de ce passé de bridge ethernet et de lié directement l'arduino au serveur via rs-232, la liaison et l'hébergement sera entièrement géré sur un serveur interne (1: fonctionnel chez moi)(2: adaptable également en solution 3). (Quelque restrictions et pas fonctionnel pour la solution à droite actuellement du au handshake et masking)

Rappel : le code html et javascript sont interprété et exécute par le navigateur, le code php, java, c/c++, ..., par le serveur.

Yep!

Petite question au passage : On peut se créer un interface avec Pachube ou c'est plutôt fermé.

@+

Zoroastre.

Super Osaka.

C'est très bô !

En plus d'être clair.

A priori je pense m'orienter vers la solution 3.

Qu'en dis-tu ?

@+

Brisebee: A priori je pense m'orienter vers la solution 3.

Qu'en dis-tu ?

C'est la solution que j'ai présenté il y a quelques pages. http://arduino.cc/forum/index.php/topic,80422.msg732055.html#msg732055

C'est une très bonne solution pour avoir une communication presque full-duplex et presque temps réel (enfin possible mais en chipotant). Par contre c'est plus ou moin du chipotage, faut dribler entre les différents langages et bidouillages. :grin: C'est pour ça que j'ai choisi la solution websocket, liaison direct possible et moin chipotage intermédiaire, mais bon pas encore à 100% au point.

osaka: C'est la solution que j'ai présenté il y a quelques pages.

Je viens de jeter à nouveau un oeil, mais pour l'instant, je n'y comprends pas grand chose, il va falloir que je reprenne tous ces éléments au début, et commencer par faire des choses très simples pour comprendre.

Pour le moment je galère car j'essaye de passer un sketch simple qui lit un capteur OneWire DS18B20 et affiche la température sur un LCD, qui fonctionne très bien de l'IDE 023 à l'IDE 1.0, je n'arrive absolument pas à implanter la librairie OneWire, j'ai plein d'erreurs de compilation.

Je crois que je suis trop fatigué ce soir. Je verrai demain soir.

zoroastre: Petite question au passage : On peut se créer un interface avec Pachube ou c'est plutôt fermé.

Alors là je ne serais pas te dire, je connais de nom mais jamais trop bien compris son intérêt, partage de données (capteur, temp, ...), graphique ??? :~ Mais : http://arduino.cc/en/Tutorial/CosmClientString?from=Tutorial.PachubeClientString

Brisebee: Je viens de jeter à nouveau un oeil, mais pour l'instant, je n'y comprends pas grand chose, il va falloir que je reprenne tous ces éléments au début, et commencer par faire des choses très simples pour comprendre.

Il va falloir le faire pas à pas, on commencera par utilisé les requêtes http (get, post), puis les sockets, etc.

Brisebee: Pour le moment je galère car j'essaye de passer un sketch simple qui lit un capteur OneWire DS18B20 et affiche la température sur un LCD, qui fonctionne très bien de l'IDE 023 à l'IDE 1.0, je n'arrive absolument pas à implanter la librairie OneWire, j'ai plein d'erreurs de compilation.

Il n'y a pas màj de la lib ou autres, quelqu'un a ou va surement rencontré les même problèmes ?

Ca y est, j'ai effectivement trouvé une librairie à jour, ça marche !

D'abord, Je vais mettre au propre mon programme (enlever toutes les scories) essayer de faire un truc lisible, pour que je puisse partir sur de bonnes bases.

@+