Arduino + module Ethernet : serveur qui interroge le client ?

Bonjour,

Pour mon projet domotique j'ai plusieurs interfaces reliées à une unité centrale via des câbles Ethernet
Il y a une interface dans chaque pièce de la maison.

Chaque interface est composée :
- d'un Arduino UNO
- d'un Shield Ethernet 2
- d'un écran TFT tactile
- de capteurs et de relais déportés si nécessaire

L'unité centrale est composée :
- d'un Arduino MEGA
- d'un Shield Ethernet 2
- de relais et de capteurs

Les interfaces sont des clients web, l'unité centrale un serveur web.

Les clients interrogent le serveur en donnant une information (typiquement, les coordonnées d'une frappe à l'écran tactile, une commande, ou rien juste pour réclamer l'état du système au serveur unité centrale)
Le serveur exécute la commande, et renvoie au client des informations qui permettent au client de mettre à jour son écran.

Petit problème : dans certains cas, le serveur doit pouvoir demander au client quelque chose :
- lire la valeur d'un capteur déporté (les interfaces peuvent comporter des capteurs, notamment de température ce qui permet de gérer le chauffage)
- mettre à jour l'affichage
- piloter un actionneur déporté (typiquement un buzzer pour répéter le signal de la sonnette ou du téléphone)

Malheureusement, un serveur web ne peut normalement pas envoyer de sa propre initiative une information à un client web pour qu'il réagisse

L'utilisation des modules Ethernet en client ou en serveur est très pratique, en plus on ouvre la possibilité de piloter le système via n'importe quel navigateur web sur un ordinateur ou un smartphone relié au réseau local.
Malheureusement la communication est "unidirectionnelle" ; je devrais plutôt dire que la communication reste exclusivement à l'initiative des clients.

Je vois pour le moment les possibilités suivantes :
- 1) forcer les clients à actualiser la page régulièrement mais c'est bourrin et on devra le faire pas trop rapidement pour ne pas saturer l'unité centrale :aie:
- 2) en plus du câble Ethernet, mes interfaces seront reliées à l'unité centrale par un câble "auxiliaire" qui véhiculera l'alimentation ; je peux utiliser un fil de ce câble pour que l'unité centrale puisse signaler aux interfaces qu'elle doivent actualiser la page ; ce fil sera relié à une sortie de l'unité centrale et à une entrée des interfaces qui devront la scruter régulièrement
- 3) faire fonctionner les interfaces en serveur, qui peuvent faire des requetes GET mais c'est bourrin :aie:
- 4) conserver le fonctionnement des interfaces en client et de l'unité centrale en serveur, et trouver la combine pour que le serveur puisse faire un "ping" à un client quand il se passe quelque chose ; il ne faut pas que le ping soit perdu si l'interface est un peu occupée et ne traite pas le ping immédiatement

J'aimerais que l'unité centrale reste un serveur web (pour la possibilité de pilotage via un navigateur web d'ordinateur ou de smartphone)... je sais c'est pas simple !

Qu'en pensez vous ?

A bientôt

Bonjour,

Je ne connais que de nom, mais il me semble que c'est ce que permettent les WebSockets.

Bonjour.

Quand on associe WebSocket à Arduino dans Google, il y a plein plein d'articles.

Celui-ci mentionne aussi le Raspberry Pi côté client: https://projetsdiy.fr/communication-...266-en-python/
Le Raspberry Pi peut donc avoir un serveur Web qui va interroger (comme client) par exemple des Arduino, ESP8266 ou ESP32 (au travers de Websockets).

Une recherche Google avec websockets esp32 est aussi significative: un grand nombre d'articles, donc d'utilisations.
J'aime bien: https://shawnhymel.com/1882/how-to-create-a-web-server-with-websockets-using-an-esp32-in-arduino/

Je me répète sans doute, mais dès qu'on a d'autres tâches à exécuter en // sur un "arduino", cela risque d'être un sac de noeud.
L'article ci-dessus est bien joli, mais imaginons qu'on aimerait avoir aussi sur notre "arduino" un détecteur de mouvement et un relais, pas forcément relier à notre application websockets, on aura des soucis.
Mais pas avec un ESP32 :D qui supporte le multi-tâche ... et cela marche vraiment bien!

Cordialement

Citation:

---

Je me répète sans doute, mais dès qu'on a d'autres tâches à exécuter en // sur un "arduino", cela risque d'être un sac de noeud.

---

Pas si vous structurez votre code en programmation événementielle plutôt que purement linéaire.

Une boucle teste l’arrivée d’évènements Pertinents pour un état donné et réagit. L’événement peut être la réception d’un SMS, le PIR qui se déclenche, un bouton, la température qui passe j’ seuil ou la réception d’une trame ethernet. C’est la même chose. On traite souvent cela par machine à états.

Le multi tâche simplifie certaines choses ou les rendra plus réactives avec plusieurs cœurs mais il faut faire attention à la synchro des taches et aux conflits d’accès aux données partagées.

Citation:

---

Envoyé par Jay M

Pas si vous structurez votre code en programmation événementielle plutôt que purement linéaire.

Une boucle teste l’arrivée d’évènements Pertinents pour un état donné et réagit. L’événement peut être la réception d’un SMS, le PIR qui se déclenche, un bouton, la température qui passe j’ seuil ou la réception d’une trame ethernet. C’est la même chose. On traite souvent cela par machine à états.

Le multi tâche simplifie certaines choses ou les rendra plus réactives avec plusieurs cœurs mais il faut faire attention à la synchro des taches et aux conflits d’accès aux données partagées.

---

Entièrement d'accord !
Les interruptions c'est l'enfer...
J'avais conçu une carte à base de 8051 qui devait gérer :
- un clavier matriciel
- un écran LCD 2X16
- des entrées
- des sorties
- la mesure précise du temps (fontions horloge et minuterie...)
Je n'ai utilisé qu'une seule interruption pour mesurer le temps de façon précise, à part cela j'ai tout géré moi-même dans une boucle.
Les interruptions peuvent survenir à n'importe quel moment dans l’exécution du code, ça complique énormément les choses surtout dans un microcontrôleur ou les ressources sont rares et partagées.
Devoir sauvegarder plusieurs registres fait perdre pas mal de temps, et au final, la réactivité peut être moins bonne avec une interruption qu'avec une boucle 'maison' bien faite.

S'agissant de l'Arduino :
- Le Shield Internet gère la couche TCP/IP et a une mémoire tampon : l'Arduino n'est pas obligé de tout traiter immédiatement Le Shield en lui-même a une capacité de traitement autonome.
- Pareil pour la dalle tactile, son microprocesseur a une mémoire tampon que l'on interroge.
- L'écran TFT a lui aussi une mémoire, comme les écrans LCD 2x16 d'ailleurs.
Ces périphériques "intelligents" n'ont pas besoin d'un traitement temps réel. Personne n'utiliserait une dalle LCD nue avec un Arduino !

Pour piloter des relais ou lire des capteurs de températures, pas besoin d'une réactivité élevée.

On me parle tout le temps des Raspberry PI... En oubliant que Raspberry PI et Arduino ne sont pas interchangeables :
- Arduino : carte électronique à base de microcontrôleur
- Raspberry PI : ordinateur avec un système d'exploitation

Pourquoi choisir Arduino pour mon projet :
- consommation électrique moindre
- alimentation possible via une entrée 7V à 12V (les Raspberry PI réclament chacun un bloc secteur USB de bonne qualité avec un câblage court)
- vitesse de boot rapide (notamment si on supprime le bootloader, ce que je ferais une fois la version finale mise au point)
- extinction possible sans devoir faire d'arrêt propre (un Raspberry PI sous Linux doit être éteint proprement)
- résistance aux virus informatiques

De même, je souhaite rester "en filaire" donc en Ethernet... La plupart des cartes qu'on me propose sont des cartes WIFI.

A bientôt

Bonjour,

Petite réflexion du soir...

L'univers "embarqué" associe des informaticiens et des électroniciens.
Ils n'ont pas la même approche.

Un informaticien est habitué à programmer sur un ordinateur un logiciel qui fera tout de A à Z.

Un électronicien est habitué à concevoir des circuits analogiques avec beaucoup de composants, où chaque groupe de composants a un rôle simple.

En fait, l'analogique c'est la seule chose qui permet d'avoir du vrai multitâche.
Un microprocesseur ne fait que commuter rapidement entre les tâches.
Même s'il y a des microprocesseurs multicoeurs, un disque dur, une mémoire, un périphérique ne peut faire qu'une chose à la fois.

Selon moi, l'erreur à ne pas commettre avec un microcontrôleur c'est de vouloir toujours tout faire dans le programme.

Un microcontrôleur est juste un composant du produit final.
Il peut très bien y avoir autour du microcontrôleur d'autres composants qui effectuent des tâches dont le microcontrôleur ne s'occupe pas.

Regardez par exemple un ampli tuner FM ou une machine à laver.
Dans l'ampli tuner, le microcontrôleur va gérer l'affichage et la télécommande mais la réception, la démodulation FM, la correction de tonalité seront faites en analogique.
Dans la machine à laver, la vitesse d'essorage peut être contrôlée par un potentiomètre directement relié au variateur de vitesse, le microcontrôleur ne connait pas la vitesse d'essorage.

Quand ça devient compliqué, il faut toujours se poser la question de savoir si une fonction ne peut pas être faite en analogique.

Exemple : une impulsion, brève et pouvant survenir à n'importe quel moment, doit déclencher un monostable ou commander un relais.
Si c'est le microcontrôleur qui gère cette fonction, il faudra recourir à une interruption, ça peut être compliqué si le microcontrôleur a déjà beaucoup de choses à faire.
Cette fonction peut être facilement réalisée en analogique, peut-être même sans composant supplémentaire (le transistor qui sert à piloter le relais peut être commandé directement par l'impulsion au lieu du microcontrôleur)

Je conçoit qu'il faut que le programmeur accepte que telle ou telle fonction lui échappe, la fonctionnalité finale du produit dépendant de l'ensemble microcontrôleur programmé + circuit analogique, il faut avoir une vision globale du projet.
Certes les fonctions analogiques ne seront pas modifiables avec une mise à jour du firmware mais ne sont pas figées pour autant.
Un potentiomètre, un interrupteur ou un cavalier sur la carte électronique rend la partie analogique paramétrable. C'est même bien plus facile et pratique de changer ces réglages "mécaniques" que de flasher le microcontrôleur.

L'analogique a aussi un énorme avantage : ça ne plante pas.
Beaucoup de systèmes de sécurité (relais de sécurité, chien de garde, ...) sont faits en analogique.

J'ai attendu longtemps avant de me mettre aux microcontrôleurs, j'ai réalisé en analogique des choses relativement complexes.

A bientôt

@ electroremy
:ccool:
Tout à fait. Il faut trouver le juste milieu entre ce que l'on fait en soft et ce que l'on fait en hard.

Un exemple typique que je vois souvent est le rebond des boutons:
- Le "softeux" (informaticien) va traiter cela dans son code avec une boucle, millis() une gestion des états etc. ça fonctionnera sans soucis mais n'est pas trivial à coder pour un débutant.
- Le 'hardeux' (électronicien) va rajouter un condensateur aux bornes du bouton et n'aura qu'à lire l'état dans son code sans se soucier des rebonds, il n'y en aura pas, le condo aura résolu cela pour lui.

il en va de même pour filtrer des hautes ou basses fréquences, lisser les évolutions d'une mesure analogique etc...

faut trouver le juste milieu ou faire avec ce que l'on a (en fonction du matos dispo et de ses connaissances)


Ensuite les architectures avancées des ordinateurs aujourd'hui permettent de faire de nombreuses choses en parallèle (multi-coeur, multi-path, DMA, segmentation, ...). Plus on gère de tâches simultanées et plus les notions de synchro / rendez-vous, sémaphore, mutex ... sont importantes à comprendre.

Ce n'est généralement pas à portée des débutants directement, mais de nombreuses librairies peuvent aider (un exemple sur ESP32 est la bibliothèque ESPAsyncWebServer qui traite sur le second coeur en tâche de fond les fonctions de call-backs associées aux URL. ça entraîne quelques contraintes sur la synchro avec le processus principal par exemple)