ESP8266 sans page Web


9

Puis-je envoyer des données à un ESP8266 sans créer de serveur Web?

J'accède aux broches GPIO de l'ESP8266 via un serveur Web. Maintenant, je veux créer une application Android pour cela. Je souhaite donc envoyer des données au 8266 sans créer de serveur Web. Est-ce possible?


En utilisant une application Android, seriez-vous sur le même réseau?
Rohan

Réponses:


8

Oui, vous pouvez envoyer des données à un ESP8266 sans utiliser de serveur Web, mais vous voudrez peut-être en utiliser un ou utiliser quelque chose de fonctionnellement lié à celui-ci.

Un ESP8266 est un appareil informatique à usage général avec une radio WiFi et une pile réseau.Par conséquent, vous pouvez implémenter à peu près n'importe quel protocole raisonnable que vous souhaitez décrire dans le code.

Cependant, il est devenu très populaire de mettre en œuvre des protocoles qui ressemblent et agissent un peu comme des pages Web miniatures destinées à la consommation humaine.

c'est-à-dire, au lieu que votre client se connecte et fasse quelque chose comme

GET /index.html HTTP/1.1

ça pourrait dire

GET /gpio/15/value HTTP/1.1

Où l'URL ne fait pas référence à un document spécifique, mais à des données sur l'appareil auquel vous souhaitez accéder. Vous pouvez faire des choses semblables pour POST, PATCH, DELETEdemandes , etc.

Sauf si vous créez une page pour la consommation humaine, les données que vous échangez ne seront généralement pas des pages HTML. Souvent, cela pourrait être quelque chose comme JSON à la place. Donc par exemple

GET /gpio/15/value HTTP/1.1

pourrait déclencher une réponse comme

{"gpio": 15, "direction": "in", "value": 0}

De même, vous pouvez créer un point de terminaison où votre client pourrait définir un GPIO en disant

POST /gpio/15 HTTP/1.1
{"direction": "out", "value": 1}

Il s'agit dans une certaine mesure d'une question sémantique ou spécifique à l'implémentation si le programme répondant à de telles requêtes est un "serveur Web" - il peut s'agir d'un serveur Web qui exécute diverses tâches d'assistance pour gérer les données et les gpios (tout comme un serveur servant des pages pourrait dynamiquement générer une partie de leur contenu à partir de requêtes de base de données), ou ce pourrait être un programme dédié qui traite à la fois les données et sait parler HTTP.

Et bien sûr, utiliser HTTP pour échanger des charges utiles JSON n'est qu'une des nombreuses façons de faire les choses - il se trouve que c'est une méthode actuellement populaire qui réutilise de nombreux concepts de type serveur Web, et peut même dans une certaine mesure autoriser l'utilisation d'un navigateur Web pour tester.


Il convient également de garder à l'esprit qu'un tel schéma fonctionne généralement mieux localement, lorsque le téléphone et l'ESP8266 sont clients du même réseau Wi-Fi domestique. Si le téléphone n'est pas "à la maison" ou qu'il l'est, mais qu'il se trouve uniquement sur un réseau mobile, lui permettre d'atteindre l'ESP8266 signifierait autoriser les demandes externes sur le réseau domestique, ce qui est de préférence évité. Dans ce cas, il est assez populaire d'utiliser un protocole où l'appareil ESP8266 et le téléphone atteignent indépendamment un serveur de relais externe, qui transmet les messages entre eux. MQTT est un exemple de schéma souvent utilisé pour un système avec une architecture basée sur un serveur relais.


De plus, je suis curieux de mettre en œuvre DELETEun port ;-)
Arjan

1
Sur de nombreux systèmes Linux, vous devez "exporter" un GPIO avant de pouvoir l'utiliser avec l'interface / sys / class / gpio. Je ne sais pas du haut de ma tête si vous pouvez "annuler l'exportation", mais conceptuellement cela pourrait correspondre à une SUPPRESSION :-)
Chris Stratton

2

Oui, vous pouvez écrire un serveur TCP personnalisé . Ou, pour un poids plus léger, utilisez un serveur UDP .

Dans tous les cas, définissez votre propre protocole d'application par-dessus TCP / UDP et demandez à votre application de l'envoyer. Et vous économisez sur les frais généraux de HTTP. (HTTP peut avoir environ 1000 octets de surcharge par message!)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.