Aidez nous ! Projet - Gestion domotique

Bonsoir,

Je reviens vers vous, pour vous tenir au courant de l’avancement de mes travaux.
Je viens de finir mes essais et le schéma structurel de l’unité d’interfaçage arrosage.
Cette unité en I2C vient s’intercaler entre l’unité de gestion (arduino) et l’unité de commande arrosage.
Je joins le schéma à ce post.
N’hésitez pas à me faire des commentaires et des remarques.
Je vais la câbler dès que j’ai reçu tous les composants, il ne me manque plus grand chose.

Bien à vous tous

Schéma structuel unité d’interfaçage arrosage.pdf (137 KB)

Yep!

Je viens de jeter un oeil. J'ai presque tout compris à part les transistors sur les lignes scl et sda qui à mon goût ne servent pas à grand chose :grin:

En tout cas super boulot, faudra nous mettre une jolie photo kicad 3d XD

@+

Zoroastre.

En fait, j'ai repris un schéma que j'ai trouvé sur le net, et qui doit permettre d'augmenter la distance sur la liaison I2C, j'ai fait quelques essais avec une longueur de 10m cela fonctionne très bien. En fait je n'ai besion que d'environ deux mètres, mais je préfère assurer.

J'enverrai des photos dès que j'aurai fini le câblage. En attendant voici des photos de l'unité de commande arrosage et de l'unité de commande chauffage.

Face avant unité commande arrosage 800x600.jpg|526x600

Face avant unité de commande chauffage 800x600.jpg|800x516

Intérieur unité de commande arrosage 800x600.jpg|800x600

Platine unité de commande arrosage 800x600.jpg|800x504

Yop Yop BriBri, Tu as bien avancé, en tout cas super boulot qui devrait en inspiré plus d'un. :) Grâce à toi je viens de découvrir le pcf8574 :sweat_smile: qui m'apparait très intéressant pour étendre le nombre d'e/s. :open_mouth:

Pour l'instant je ne travaille plus trop sur le bus, je suis en train de me faire une application java serveur de websocket qui permettra la communication websocket<->arduino via shield ethernet mais également via port serie, ce qui permettra de lier web <-> arduino sans même être obligé de disposé d'un shield ethernet. :open_mouth:

osaka: je viens de découvrir le pcf8574 :sweat_smile: qui m'apparait très intéressant pour étendre le nombre d'e/s. :open_mouth:

Le PCF8574 est très intéressant et facile à mettre en oeuvre avec un arduino.

osaka: je suis en train de me faire une application java serveur de websocket qui permettra la communication websocket<->arduino via shield ethernet

Pour ce que j'ai compris, ton principe de websocket permet d'utiliser des fonctions (ou modules) pour échanger des informations entre l'arduino et le serveur web, c'est ce dont je vais avoir besoin. Je vais bientôt attaquer la partie programmation et notamment ce qui concerne la partie web. Pour le moment, je n'en suis pas encore là, j'avance doucement, pas à pas. Mais j'aurai besoin d'aide à ce moment là.

@+

Yep!

Pour ma part, je viens de finir la sérigraphie de mon premier proto double coeur à 20 Mhz.

J'ai quelques défauts de conception : petit manque de place au niveau de l'alimentation qui n'est pas définitive à l'heure actuelle. J'attends la livraison de régulateurs 5v/2A et 3.3v (le pion rouge) ainsi que des condo chimiques. Je me suis planté sur l'empreinte des quartz. C'est exploitable pour l'heure et je vais lancer les tests dés que j'aurais définitivement validé la partie alimentation (faudrait pas que çà chauffe de trop quand je vais tirer dessus).

J'attaque le shield ethernet + eeprom + ds1307 déssiné dans les grandes lignes.

@+

Zoroastre.

Brisebee:

osaka: je suis en train de me faire une application java serveur de websocket qui permettra la communication websocket<->arduino via shield ethernet

Pour ce que j'ai compris, ton principe de websocket permet d'utiliser des fonctions (ou modules) pour échanger des informations entre l'arduino et le serveur web, c'est ce dont je vais avoir besoin.

En fait ça permettra surtout une communication full-duplex, dans le cas de serveur de contenu web (pages html, ...) la communication ne peux être initié que d'un seul côté, celui qui fais la requête (navigateur [requête]) ->arduino [réponse]-> navigateur). Dans le cas du websocket chacun pourras initié la conversation (navigateur<->arduino). Entre () contrairement à la solution ajax et socket php, ici le code html pourra ce trouver sur un hébergeur distant comme la beaucoup n'accepte pas les sockets.

Brisebee: Mais j'aurai besoin d'aide à ce moment là.

Pas de problème, on t'aideras du mieux possible.

zoroastre: je viens de finir la sérigraphie de mon premier proto double coeur à 20 Mhz.

Pourquoi un double coeur ? As-tu une application particulière en projet ? Quels CI utilises-tu ?

Yep!

Brisebee: Pourquoi un double coeur ? As-tu une application particulière en projet ? Quels CI utilises-tu ?

Je vois que tu as raté un épisode... EDIT1: Pourtant, tu étais là page 18 :stuck_out_tongue_closed_eyes:

Petit rappel : Je me suis inspiré des automates modernes qui possèdent une tache rapide et une tache normale. Ainsi, le premier uC (Atmega644), dans mon idée, s'occupera de la partie IHM (interface Homme/Machine : ethernet+Glcd) et le second de la communication avec les modules rs485 et sondes. J'escompte faire dialoguer les 2 uC en I2c, avec une option multimaitre pour plus tard.

Outre l'expansion du nombre d'entrée/sortie et le partage des tâches, j'envisage dans les communications d'établir un système de priorisation des ordres.

Remarquons aussi que le débugage des programmes est facilité d'une certaine manière.

@+

Zoroastre.

PS : J'avouerais que je lorgne un peu vers la robotique en ce moment. Ce n'est pas encore ma priorité actuellement.

zoroastre: Je vois que tu as raté un épisode... EDIT1: Pourtant, tu étais là page 18 :stuck_out_tongue_closed_eyes:

Effectivement, j'étais là, mais ma mémoire a quelquefois besoin d'être raffraichie.

Et maintenant je comprends mieux ce dont tu parlais à ce moment là.

En fait, il y a différentes problématiques qui n'ont pas du tout besoin des mêmes temps de réponse.

Pour l'instant de la manière dont je conçois mon système de domotique les temps de réponse peuvent être lents, qu'une électrovanne, ou un chauffage se mette en ou hors circuit avec une seconde de retard n'a que très peu d'importance.

Probablement que lorsque je travaillerai sur l'interface web, les choses seront différentes, car s'il faut attendre trop longtemps pour que l'ensemble des données soient collectées puis affichées, ce sera une autre histoire ! Mais bon je n’y ai pas encore vraiment réfléchi, chaque chose en son temps.

Et évidemment pour la robotique c’est encore une toute autre chose !

@+

Yep!

Brisebee: Probablement que lorsque je travaillerai sur l'interface web, les choses seront différentes

Je suis effectivement face à cette problématique. Mon système actuel est plutôt réactif et je n'ai pas trop à m'en plaindre. Le seul hic se situe au niveau de mon afficheur tactile, outre une latence toute naturelle due à la dalle résistive, dans mon projet initial, j'avais envisagé de positionner à deux endroits différents 2 afficheurs. La connectique fût déjà mon premier problème et je me suis vite rendu compte également que j'allais démultiplier d'autant le nombre de cycle réquisitionné par l'arduino.

Pour l'instant, je palie au problème en désactivant soit la connection internet soit la dalle tactile en fonction d'où provient les ordres. Solution simple et efficace, mais qui limite outrageusement l'utilisation globale sans pour autant la pénaliser certes. L'autre solution est de déporter tous les modules dans une résolution indépendante et communicative. Cependant, le protocole de com a plutôt interêt d'être costaud et de subordonner tout autre module pouvant ralentir le système global, la déléguation, le rebond, la redondance sont la clé. La dernière solution est de disposer d'un pc serveur centralisant toutes les informations et pilotant les modules.

Mon experience a débuté sur des choses simples, celle qui sont réactives et demandent peu de travail à l'arduino. Mais plus le système évolue, plus les ressources sont sollicitées et selon les organes embarqués, la consommation devient rapidement exponentielle.

Aujourd'hui, je choisis de conserver une approche centralisée des choses et de disposer de plusieurs connectiques rs485, afficheurs, rs232, i2c, 1wire, sur une seule carte + shield. L'idée de modules déportés a fait son chemin et je l'ai aujourd'hui consideré, cependant, j'aimerais que mes modules déportés soient le plus discrets possible.

Il y a plusieurs avantages d'avoir deux cerveaux à sa disposition. Le nombre de sortie est démultiplié, les programmes sont précis et dédiés à chaque puce, les temps de cycle sont mieux maitrisés, le fonctionnement minimal est garantie si l'un des uC lache...

@+

Zoroastre.

zoroastre: Aujourd'hui, je choisis de conserver une approche centralisée des choses

C'est aussi mon idée.

Je trouve, que globalement ta réflexion est très intéressante, mais, en fait, il faut considérer les moyens mis en œuvre par rapport à l’objectif (ou les objectifs) recherché(s). Et les solutions retenues pour certaines situations ne sont pas forcément les meilleures pour d’autres. C’est pour cela qu’il est important de fixer le champ des contraintes, et de rédiger un cahier des charges le plus précis possible pour chaque projet (c’est vari qu’on ne sait pas toujours jusqu’où on va aller lorsqu’on se lance dans un projet). Ce qui ne devrait pas empêcher de mettre en œuvre des systèmes modulaires, tu as raison de dire que c’set alors les protocoles de communications qui sont à peaufiner. Il me semble que c’est ce qu’Osaka cherche à faire (ou a fait). @+

Salut à tous,

Depuis les derniers posts, j’avais bien progressé dans mon “espionnage” de régulateur (sondes NI1000), et puis … BOUM : cours-jus sur le 230V-3V3, donc MEGA grillé, shield (et p-ê LCD) grillé, et … régulation de tout mon capharnaum grillé. S**T. :-((((( Plus de solaire, plus de chauffage. Si quelqu’un est intéressé par un sketch d’oscilloscope 13 voies avec LCD 2"4 touch, je peux le poster…

Conclusion : on reprend tout à zéro. Plus besoin de penser à conserver le SAUTER, mais plutôt … de ne pas mélanger les fils.

Première étape, installation d’un Arduino Nano sur breadboard pour remettre en route … les trois sondes principales : T° intérieure, extérieure, capteurs. Pas très convaincant.
La feuille de calculs et le sketch est en annexe : avec le Nano en 5V et les NI1000 alimentés par D13 via une 4k7 chacun (sinon ils chauffent), mais une connexion 3V3-Aref, je pensais obtenir une résolution de 1 step/°C et un offset de 272, pas très précis mais bon … Loupé. Mon multimètre montre bien les entrée faire 0-5V à vide et 0-1V avec la NI1000, mais les données sur l’EEPROM soit foireuses.

Ce soir/demain si tout va bien, deuxième essai avec le Nano. Quand çà marchera, je remplace par un DINo acheté le mois passé, et le Pro mini comme extension pour les sondes et les relais, peut-être avec du Firmata entre les deux. Je vous tiendrai au courant.

Pour recentrer sur le thread, l’opposition centralisé/décentralisé est aussi au coeur de mes questions. De toute façon, aucun AVR 8 bits n’a assez d’I/Os pour mon système, sauf le MEGA (16 analog ins), mais il n’était pas aisé à mettre en boîte non plus. Si la communication DINo/Pro mini se passe bien ou mal, on verra.

A+

ADC Calculs.xls (44.5 KB)

regu_mar28a.cpp (12.6 KB)

Brisebee: C’est pour cela qu’il est important de fixer le champ des contraintes, et de rédiger un cahier des charges le plus précis possible pour chaque projet (c’est vari qu’on ne sait pas toujours jusqu’où on va aller lorsqu’on se lance dans un projet).

Je vise toujours aux plus loin (cahier des charges), pour cela la seule réponse que j'ai trouvé c'est dépendance et modularité.

Brisebee: Ce qui ne devrait pas empêcher de mettre en œuvre des systèmes modulaires, tu as raison de dire que c’set alors les protocoles de communications qui sont à peaufiner. Il me semble que c’est ce qu’Osaka cherche à faire (ou a fait).

C'est exact la modularité étant la réponse à certains besoins et problèmes l'impératif devient la fiabilité de communication entre ses modules.

Bon en voyant les différents montages de tout le monde je me dis qu'il serait temps d'acheter un petit fer à souder, je suis juste un peux bloquer niveau finance (Va me falloir un sponsor). :grin:

Bonjour à tous,

Ca y est, j'ai fini le câblage de mon unité d'interfaçage arrosage. C'était un peu plus compliqué que je ne le pensais à priori pour tout faire rentrer dans les boîtiers. Ci-joints quelques photos. J'ai maintenant une chaîne complète : unité de gestion (Arduino) + unité d'interfaçage (que je viens de finir) + unité de commande (que j'avais déjà). Je vais donc pouvoir commencer à programmer pour faire fonctionner tout cela. Je vous tiens au courant de mes essais et je reviendrai très probablement bientôt vers vous, pour avoir votre avis ou pour vous demander de l'aide.

Bien à vous

Principe relations entre unités arrosage.jpg|715x194

20120425_190337 [800x600].jpg|800x600

20120425_190511 [800x600].jpg|800x600

20120425_190543.jpg|2560x1920

Brisebee:
C’était un peu plus compliqué que je ne le pensais à priori pour tout faire rentrer dans les boîtiers.


:grin:

Je pensais pas qu’il fallait jouer en étage lol.

Brisebee:
Je vais donc pouvoir commencer à programmer pour faire fonctionner tout cela.
Je vous tiens au courant de mes essais et je reviendrai très probablement bientôt vers vous, pour avoir votre avis ou pour vous demander de l’aide.

Pas de problème on t’attend de pied ferme. :wink:

osaka:
Je pensais pas qu’il fallait jouer en étage lol.

Eh oui, quand il n’y a pas assez de place disponible au sol, on construit des tours !

@+

Bonjour à tous,

Ça y est, j'ai avancé, mon système fonctionne à minima : - Je commande mon unité d'interfaçage (10 zones) sur des plages horaires, cela fonctionne sans problèmes depuis plus d'une semaine. - J'affiche la température (capteur DS18B20) sur un afficheur LCD. Je publierai quelques photos prochainement.

Je vais maintenant attaquer la partie la plus délicate pour moi : l'interface web !

J'ai cherché un peu partout, j'ai trouvé beaucoup de choses, j'ai même fait quelques essais qui fonctionnent. J'aurai besoin de vos conseils avant de me lancer :

Voici ce que je cherche à faire dans un premier temps : - saisir sur le web des plages horaires : heure de début (hh:mm) et heure de fin (hh:mm) => j'en aurai au maximum 30 à saisir (3 par zones) et les transférer à mon système qui les stockera en mémoire. - afficher sur le web l'état des 10 zones (cela correspond chaque fois à une entrée de l'unité d'interfaçage). - afficher sur le web la valeur de la température.

J'ai plusieurs questions : - quel protocole utiliser pour les transferts de données UDP, TCP, ... ? - existe-t-il des librairies pour faciliter l'écrire la programmation pour l'arduino ? - j'ai trouvé pas mal d'exemples mais rarement des exemples complets => .pde (je ne suis pas encore passé à IDE 1.0) et coté web (php) auriez-vous un exemple simple de mise en oeuvre ?

Je ne demande surtout pas que l'on fasse à ma place, je veux comprendre ce que je fais, mais j'ai besoin d'aide pour faire les bons choix et pour démarrer.

Yop Yop bribti :grin:,

Brisebee: Voici ce que je cherche à faire dans un premier temps : - saisir sur le web des plages horaires : heure de début (hh:mm) et heure de fin (hh:mm) => j'en aurai au maximum 30 à saisir (3 par zones) et les transférer à mon système qui les stockera en mémoire.

Le plus simple à mon avis serait l'utilisation de formulaire. http://www.siteduzero.com/tutoriel-3-13596-les-formulaires.html En faisant abstraction du php transposer en c pour ton arduino. http://www.siteduzero.com/tutoriel-3-14543-transmettre-des-donnees-avec-les-formulaires.html

Brisebee: - afficher sur le web l'état des 10 zones (cela correspond chaque fois à une entrée de l'unité d'interfaçage). - afficher sur le web la valeur de la température.

Pour ceci c'est le plus simple, tout dépend si tu as besoin de rafraichissement fréquent des valeurs, temps réel ou autre ?

Brisebee: J'ai plusieurs questions : - quel protocole utiliser pour les transferts de données UDP, TCP, ... ? - existe-t-il des librairies pour faciliter l'écrire la programmation pour l'arduino ? - j'ai trouvé pas mal d'exemples mais rarement des exemples complets => .pde (je ne suis pas encore passé à IDE 1.0) et coté web (php) auriez-vous un exemple simple de mise en oeuvre ?

Tu peux rester en tcp pour ça fiabilité, udp est surtout utile si tu as besoin de grande performance (tcp est très performant quand même) et si la perte de données n'a pas de grande conséquence comme pour les jeux, la voIP, ... Librairie il en existe je pense mais jamais utilisé, maintenant est-ce utile pour ton projet tout dépand de tes besoins mais c'est pas la meilleur façon pour apprendre ?

Maintenant tout dépend également si tu compte hébergé le code en local sur ton arduino (limite en mémoire), en local sur un petit serveur web genre nas (machine supplémentaire) où à l’extérieure sur du mutualisé ou autre (où tout n'est pas permis) ? Tout dépend également de la taille de ton code (contenu, dynamisme, design, etc, ...), rafraichissement fréquent ,socket?, websocket?, ..., etc, etc, ...

Des solutions il en existe plusieurs, il faut juste trouver celle qui te conviendra le mieux. ;)

(pour l'instant j'ai ma petite appli serveur de socket et websocket que je me suis fait en java qui me permet le full duplex avec l'arduino, peut être que le jour ou la due sort je le porterais sur arduino parce que les websocket avec le handshake, masquage, ... )

Merci Osaka pour tes réponses,

Alors

osaka:

Brisebee: - afficher sur le web l'état des 10 zones (cela correspond chaque fois à une entrée de l'unité d'interfaçage). - afficher sur le web la valeur de la température.

Pour ceci c'est le plus simple, tout dépend si tu as besoin de rafraichissement fréquent des valeurs, temps réel ou autre ?

En fait il faut juste que lorsque je consulte le site j'obtienne l'état des sorties et la température au moment de la consultation.

osaka: Maintenant tout dépend également si tu compte hébergé le code en local sur ton arduino (limite en mémoire), en local sur un petit serveur web genre nas (machine supplémentaire) où à l’extérieure sur du mutualisé ou autre (où tout n'est pas permis) ? Tout dépend également de la taille de ton code (contenu, dynamisme, design, etc, ...), rafraichissement fréquent ,socket?, websocket?, ..., etc, etc, ...

Je pense mettre en oeuvre un serveur web avec un vieux PC, vu qu'apparemment mon NAS (Iomega Home Media Network Hard Drive 1To) ne permet pas de faire un serveur web comme je le souhaite, car il lance un diaporama lorsqu’on se connecte à son adresse IP. Enfin je n’ai pas réussi, mais comme je maîtrise moyennement le zinzin, il est fort possible que quelque chose m’ait échappé.

Pour le reste je ne sais pas encore trop. Socket, websockets => je ne sais pas ce que c'est !