Bonjour
Suite à différents tests en suivant progressivement la page fournie par
Edgar Bonet
(
https://www.tala-informatique.fr/wiki/index.php?title=Arduino_W5100_web_server),
les solutions d'architectures proposées par Edgar Bonet, je vais
prendre l'exemple 2 car :
primo
L'intermédiaire (un serveur avec l'api pour alimenter et visualiser des
tables MySQL contenant les données de divers capteurs) et ce capteur
(activant des ventilos et remontant la température, etc) sont dans la
même armoire.
secundo
La carte ethernet et la carte moteur des ventilos ont malheureusement
des pins communs donc on peut pas utiliser les deux en même temps si on
veut gérer deux moteurs différents
Je vais donc finir juste le test avec 1 seul moteur pour aller au bout
de la démarche et qui sait ça servira pour un autre capteur-actionneur
qui sera ailleurs que dans l'armoire informatique.
Ensuite, je basculerais sur l'arduino et juste la carte des moteurs et
le capteur de température pour mettre au point l'échange via USB entre
le serveur et l'arduino (que je testerais sur mon ordi avant de basculer
sur le serveur).
La déjà sur l'arduino la partie "Process incoming commands" d'Edgar
Bonet va servir (pour les royalties Edgar tu prend en chèque, CB,
Paypal, chèque vacances :-) ).
Restera à imaginer le "Process outcoming commands".
Puis l'ajout, dans "l'api" en PHP , pour recevoir ou envoyer via l'USB à
l'arduino.
La faudra que je trouve des exemples de communication USB via PHP ou
autre langage permettant de travailler avec MySQL, USB, etc.
A suivre.
Le 04/07/2024 à 12:18, Edgar Bonet a écrit :
> Bonjour !
>
> Frédéric Bressy a écrit :
>> je voudrais [...] que l'arduino envoie les données [...] à une api sur
>> un serveur et que ce dernier, en fonction si des seuils de température
>> sont dépassés (réglage par utilisateur via une interface web), renvoie
>> des données ou plutôt ordres pour activer ou non des ventilo et
>> modifier leur vitesse.
>
> Si je comprends bien, dans l'appli que tu cherches à développer, tu
> aurais :
>
> – Un Arduino, qui interface les capteurs et les ventilos, et qui est à
> la fois serveur et client Web ;
> – Une machine intermédiaire (un serveur dans l'armoire informatique ?)
> qui est aussi serveur et client Web, basé sur PHP ;
> – Un utilisateur avec un navigateur Web, qui accède à la machine
> intermédiaire pour consulter les données et configurer des seuils.
>
> En voici le schéma, où les flèches représentent les connexions HTTP, du
> client vers le serveur.
>
> ┌────────┐ ┌───────────────┐ ┌─────────┐
> │ │ │ │ données │ │
> │ │ config │ │◀──────────────│ │
> │ navig. │───────────▶│ intermédiaire │ │ Arduino │
> │ │ │ │ commandes │ │
> │ │ │ │──────────────▶│ │
> └────────┘ └───────────────┘ └─────────┘
>
> Est-ce que j'ai bien compris ?
>
> Si c'est bien ça, je trouve personnellement l'architecture un peu trop
> compliquée : il y a deux serveurs et trois clients HTTP ! Ce que
> j'aurais envie de faire dans un cas comme ça est, du plus simple au plus
> compliqué :
>
> 1. Si l'Arduino peut avoir un shield pour carte micro-SD, me passer de
> l'intermédiaire et implémenter toute l'appli dans l'Arduino. La
> logique à implémenter pour commander les ventilos est probablement
> très simple, et la partie serveur d'API ne devrait pas être trop
> lourde. Par contre, le code client (HTML/CSS/JS) peut être un peu
> volumineux, d'où l'intérêt de le servir depuis une carte micro-SD.
>
> 2. Si l'intermédiaire et l'Arduino sont dans la même Armoire, les
> relier par un câble USB, et les faire communiquer par liaison
> série/USB (objet Serial de l'API Arduino). L'Arduino répondrait
> alors a des simples commandes textuelles, faciles à parser, et son
> code serait super léger. C.f. cet exemple d'interpréteur de
> commandes[1]. J'ai implémenté un architecture de ce type avec
> Node.js / Raspberry Pi pour la machine intermédiaire, et ça marche
> très bien. C'est peut-être moins facile en PHP qu'en Node.js.
>
> 3. Si la communication entre l'intermédiaire et l'Arduino doit passer
> par du TCP/IP, alors implémenter dans l'Arduino un serveur HTTP
> uniquement (pas de client), et laisser l'intermédiaire le consulter
> pour récupérer périodiquement les données dont il a besoin. Ou
> mieux, se passer de la couche HTTP et envoyer de simples commandes
> textuelles dans un tuyau TCP, comme on ferait dans le cas numéro 2.
>
> À+,
>
> Edgar.
>
> [1] https://gist.github.com/edgar-bonet/607b387260388be77e96
>
--
Cordialement
Bressy Frederic
Pensez ENVIRONNEMENT : n'imprimer que si nécessaire
Think ENVIRONMENT: print only if necessary
