Aidez nous ! Projet - Gestion domotique

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.

@+

zoroastre: 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)

C'est d'accord, j'ai trouvé de l'info et des exemples => je mets cela de coté pour plus tard. => je vais modifier le cahier des charges en ce sens.

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

En fait pour éviter de stocker toutes les données (plages horaires + ...) => que j'estime à environ 2ko, dans l'arduino, j'ai imaginé n'en transférer que ceux nécessaires durant une périodes données par exemple 1 jour. Mais en fait si je peux stocker ces données sur la carte SD, il n'y a plus de problème, je n'ai pas besoin d'avoir une connexion pour fonctionner. J'aurai besoin d'une connexion pour connaître à distance les états du système et les grandeurs mesurées, mais du coup ce sera beaucoup plus simple => je vais là aussi modifier mon cahier des charges.

Encore merci pour votre aide.

Bonjour,
je suis revenu :stuck_out_tongue:
Ci-joint mon cahier des charges concernant le projet Hexintelli pour avis et commentaires
Je cherche aussi conseils concernant :
Type de composants ou cartes manquantes ou de meilleure qualité/rentabilité
Orientation concernant le serveur Web « langage de programmation, Nom serveur Web, interface avec smartphone…etc. »
Merci d’avance :D.

cahier des charges Hexintelli.pdf (270 KB)

Très sympa ton projet. Cela me donne des idées pour prolonger le mien !

Tes questions sont très larges, quelles solutions as-tu déjà retenues et validées ? Sur quelles parties cherche tu de l'aide ? As-tu déjà travaillé sur la partie mécanique de ton robot ?

Ton cahier des charges est assez global, c'est comme cela qu'il faut commencer. Mais ensuite il faudra rentrer plus dans le détail.

Pour ce qui me concerne, j'ai plus de compétences sur la partie électronique que sur la partie programmation. Parmi les contributeurs à ce Forum il y a de grands spécialistes sur les différentes parties.

@+

J’ai corrigé ma partie du cahier des charges concernant de l’unité de gestion, suites aux remarques (merci Zoroastre).

Je vous le soumets à nouveau, puis je l’intègrerai dans le cahier des charges global.

@+

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

Merci Pour ma part je du domaine informatique « option BDD XD», je cherche de l’aide sur la partie électronique, surtout pour le volet IR « car je n’arrive pas à bien comprendre comment puis-je schématiser et avec quel composants je peux le faire» et la protection des composants « alimentation des relais et servo » pour la partie mecanique j'ai pas encore commencé :) @+

nadirovick: je cherche de l’aide sur la partie électronique, surtout pour le volet IR « car je n’arrive pas à bien comprendre comment puis-je schématiser et avec quel composants je peux le faire

Il faudrait que tu en dises plus sur ce que tu veux faire exactement, comment cela doit fonctionner.

Pour ta partie IR qui semble relier un écran (TV ?) que veux tu afficher ?

Il y aura probablement une partie fixe (au moins certains actionneurs et peut-être capteurs + ...) pour commander les éléments domotiques, et d'autres mobiles embarqués sur le robot. Il faudrait déjà déterminer cela. Après on peut voir comment il faut alimenter cela.

Si tout est mobile (mais cela ne me semble pas réaliste => poids + communications avec les différents éléments domotiques)=> l'alimentation se fera sur batterie => il faudra voir comment la dimensionner (poids, capacité, ...) et comment la recharger. Sinon il y aura aussi une partie sur secteur.

@+

Pour la partie IR elle est très simple, je veux piloter ma télévision et le climatiseur via Arduino [u]Exemple pour la télévision :[/u] Je peux l’allumer ou l’eteindre « elle est alimentée et en mode veille » via arduino [u]Exemple pour le climatiseur :[/u] Allumer/éteindre et Changer la température du climatiseur via Arduino « Toujours à partir du Mode veille » [u]Exemple pour le démodulateur starsat 4200D ou autre :[/u] Changer les chaines de télévision via arduino et commandes vocales Globalement l’arduino va jouer le rôle des télécommandes en plus à commande vocale @+

OK, je comprends mieux.

Je n'ai pas grande expérience dans ce domaine, mais à une époque j'ai cherché de l'info sur ce sujet, j'avais pour projet de piloter un petit robot (self bricolated) en le commandant par une télécommande IR, mais finalement je ne l'ai jamais fait (mais j'y pense toujours !).

En fait, c'est la fonction inverse, mais cela revient à mettre en œuvre les mêmes technologies, pas forcément les mêmes composants, puisque tu auras besoins d'émettre et non de recevoir.

Je vais voir ce soir si je retrouve des choses.

@+

Je n'ai pas retrouvé grand chose sur le sujet des télécommandes IR, car il s'agit de cela, il faut se substituer à la télécommande, il faut fabriquer une télécommande universelle.

Il y a quelques infos ici : http://www.robot-mobile-irbot.com/8-telecommander-robot-irbot.htm http://www.roboticus.org/electronique/15-la-telecommande-infrarouge-theorie

Mais peut-être en cherchant sur un moteur de recherche : "principe de fonctionnement d'une télécommande universelle IR". Je sais que cela se faisait (remplacer la télécommande) avec un PAD et maintenant avec un smartphone => il doit bien être possible de trouver des information sur le fonctionnement des télécommandes IR.

@+

Salut a tous. Apres avoir lu d'une traite les 24 pages de ce topic, j'ai appris beaucoup de chose, et j'entrevoie certaine solutions pour mon projet. Pour faire avancer le schmilblick, je me permet une petite réflexion: Concernant la partie serveur Web: Il existe de petite machine sur plateforme ATOM, qui ne coute pas très chère genre Zotac Zbox, et qui ne consomme pas grand chose. Ça c'est disponible de suite, et opérationnel sous Windows/Linux. Sur une plateforme ATOM D525, on peut faire tourner Windows 2003 Serveur, avec virtualbox qui fait tourner une Debian Squeeze. Le tout ne consomme que quelques dizaine de watts. Pour moi, toute la partie Web dois se trouver en dehors de l'arduino. Les contraintes sont trop importantes. Pour palier celles-ci, il faudra trouver des astuces, déporter une partie du code sur le client, etc... Il est, a mon sens, bien plus simple de réduire la partie web de l'arduino a appeler des page php sur un serveur local en passant les paramètres en arguments. Voir même, via une liaison série Arduino <-> Serveur Web. C'est le serveur Web qui s'occupe ensuite de mettre les données en formes, de les stocker, etc... De la même façon, l'arduino possède en dur, des paramètres de départ a froid, qu'il utilise jusqu'à ce qu'il puisse obtenir les donnée a jour du serveur (ou que l'utilisateur les modifie en direct). Une fois obtenu les info, on les stocke dans l'EEPROM: en cas de reset (soft ou hard), le système repart comme il était avant le problème (je ne parle pas de l'état des actionneurs qui retrouverons un état "quelconque" selon leur mode de fonctionnement) Pour déclencher la mise en mémoire des info nouvellement modifier, un simple appel d'une page sur l'arduino (qui ne renvoi rien, si ce n'est un http 200) qui déclenche la lecture d'un fichier texte sur le serveur (par ex: http://serveurweb/infoparametage.txt) De la même façon, on peut même imaginer que c'est le serveur Web qui se signale "vivant" a l'arduino suite à un problème, et non à l'arduino de monopoliser des ressources pour faire des appels régulier au serveur.

Merci de ne pas taper sur le nez, je suis fragile :grin: :grin: :grin: