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 :
-
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).
-
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, ...)
-
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 :
-
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.
- 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.
- 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 ... :~