Aidez nous ! Projet - Gestion domotique

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

20120425_190337 [800x600].jpg

20120425_190511 [800x600].jpg

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 !

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

Si je comprend bien en fait tu n’as pas d’énorme besoin, donc stocker le site directement sur l’arduino peut être plus simple et éviter ainsi un intermédiaire (nas) ?

Chico avait obtenu un résultat assé sympa sur son enc28j60 (le plus gros de son problème).

http://arduino.cc/forum/index.php/topic,66139.405.html

On lui avais fais un site multi pages assé simple mais suffisant et sympa, c’était mes débuts sur arduino et le forum :grin:.

Brisebee:
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é.

C’est bien celui là ?
https://iomega-eu-en.custhelp.com/app/answers/detail/a_id/26387#home_media
En effet en regardant le mode d’emplois qui est assé vague et flou, difficile de s’y retrouver … :sweat_smile:
Juste trouvé ça page 69:

Paramètres de la page d’accueil
La page Paramètres de la page d’accueil vous permet de personnaliser l’apparence de la page d’accueil sur votre Home Media Network Hard Drive. Vous pouvez
attribuer un nom à la page d’accueil et choisir d’y afficher un diaporama et des partages.

  1. Saisissez un titre pour la page d’accueil. Ce titre s’affiche dans la bannière supérieure de la page d’accueil lorsque des utilisateurs accèdent à l’Home
    Media Network Hard Drive.
  2. Sélectionnez Afficher les partages pour afficher les partages Lorsque vous choisissez d’afficher les partages, l’utilisateur voit tous les partages
    présents sur le Home Media Network Hard Drive, mais il ne peut y accéder que s’il détient les autorisations d’accès requises.
  3. Cochez la case Afficher les diaporamas pour afficher les diaporamas contenus dans les dossiers du Home Media Network Hard Drive. Cliquez sur Gérer
    des diaporamas pour configurer les diaporamas que vous souhaitez afficher. Le diaporama peut se situer dans n’importe quel dossier associé au Home
    Media Network Hard Drive, y compris un lecteur USB ou un emplacement DFS.
  4. Cliquez sur Appliquer pour enregistrer vos modifications.
    Suppression d’un diaporama
    Pour supprimer un diaporama à partir de la liste des diaporamas disponibles, cliquez sur . Après avoir supprimé un diaporama, vous pouvez en configurer
    un autre.

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

Les socket tu les utilises tous les jours rien qu’en surfant. :open_mouth: :open_mouth:
Pour faire simple ça permet la communication inter processus (applications), c’est une sorte de canal de communication entre programme on va dire.
C’est grâce aux socket qu’une application peux communiquer avec une autre à travers les réseaux par exemple (navigateur <-> appli serveur).

osaka:
Si je comprend bien en fait tu n’as pas d’énorme besoin, donc stocker le site directement sur l’arduino peut être plus simple et éviter ainsi un intermédiaire (nas) ?

J’ai prévu de faire les choses en deux temps :

  • dans un premier temps un fonctionnement minimal très simple, celui décrit dans le post ci-dessus, pour apprendre et valider des solutions.
  • dans un second temps le fonctionnement complet, que je n’ai pas encore complètement défini, qui sera bien plus complexe.

Je vais décrire ce fonctionnement complet, car le choix d’une solution, probablement même pour le premier temps, doit tenir compte de ce que je veux faire au final.

Je vais m’y mettre dès que j’ai un moment, et je le soumettrai à la sagacité des participants à ce Forum (surtout Osaka, qui semble être le seul à me suivre encore) .

Yep!

Brisebee:
surtout Osaka, qui semble être le seul à me suivre encore)

Ouuuuuuhhh le faux teasing que voilà !!!

Je ne pourrais pas trop t’aider dans cette affaire de site web, perso, j’ai tout d’abord préferé entreprendre la com pc/arduino avec un langage que je maitrise pas trop mal : python.

Les interfaces web sont trés prisées mais ne sont pas l’unique solution.

Bon courage.

@+

Zoroastre.

zoroastre: Yep!

Brisebee: surtout Osaka, qui semble être le seul à me suivre encore)

Ouuuuuuhhh le faux teasing que voilà !!!!

Je reconnais, c'était une petite provocation !

Je vais continuer à avancer, pas par pas, et je ferai à chaque fois un écho sur ce forum, en donnant un maximum d'infos, car 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.

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 @+ ;)