Archivo de la categoría: HTTP

Protocolos IoT Capa Aplicación

5 respuestas

En informática y telecomunicación, un protocolo de comunicaciones es un sistema de reglas que permiten que dos o más entidades de un sistema de comunicación se comuniquen entre ellas para transmitir información por medio de cualquier tipo de variación de una magnitud física. Se trata de las reglas o el estándar que define la sintaxis, semántica y sincronización de la comunicación, así como también los posibles métodos de recuperación de errores. Los protocolos pueden ser implementados por hardware, por software, o por una combinación de ambos.

Los sistemas de comunicación utilizan formatos bien definidos (protocolo) para intercambiar mensajes. Cada mensaje tiene un significado exacto destinado a obtener una respuesta de un rango de posibles respuestas predeterminadas para esa situación en particular. Normalmente, el comportamiento especificado es independiente de cómo se va a implementar. Los protocolos de comunicación tienen que estar acordados por las partes involucradas.

Ejemplos de protocolos de red (wikipedia)

Algunos Protocolos de comunicación IoT de capa de aplicación, con los que comunicar el HW con el SW

  • MQTT
  • API REST/HTTP
  • SNMP
  • CoAp
  • Websockets
  • Buses de campo industriales, modbus, etc…

Más información: https://es.wikipedia.org/wiki/Protocolo_de_comunicaciones

El protocolo de red MQ Telemetry Transport (MQTT) sería una buena opción para monitorizar y controlar los paneles solares. MQTT es un protocolo de publicación/suscripción con corredores de mensajes centrales. Cada panel solar puede contener un nodo IoT que publique mensajes de tensión, corriente y temperatura.

MQTT de un vistazo

  • Ancho de banda muy bajo
  • TCP/IP
  • Publicar/suscribir transferencia de mensajes
  • Topología de muchos a muchos a través de un broker central
  • Sin metadatos
  • Tres niveles de QoS
  • Última Voluntad y Testamento revela nodos desconectados

Para los nodos IoT de los aerogeneradores, preferiría una interfaz más basada en API. El Protocolo de aplicación restringida (Constrained application protocol – CoAP) utiliza el conocido patrón de diseño REST, en el que los servidores ponen recursos a disposición en una URI y los clientes acceden a los recursos utilizando métodos como GET, PUT, POST y DELETE. Los estándares publicados facilitan la interpretación de los formatos de contenido: por ejemplo, XML (ID=41) o JSON (ID=50).

CoAP es un protocolo del IETF (Internet Engineering Task Force) que se ha diseñado para proporcionar aplicaciones RESTful modeladas en la semántica de HTTP, pero más pequeño y binario a diferencia del basado en texto. CoAP es un enfoque tradicional de cliente-servidor en comparación al de brokers, diseñado para correr sobre UDP.

Las turbinas podrían consultarse entre sí para optimizar el rendimiento de la matriz. Por ejemplo, una turbina podría consultar a la turbina adyacente para determinar si el viento estaba aumentando o disminuyendo. El vecino podría a su vez consultar a su vecino y así sucesivamente. Esta simple regla podría permitir a una turbina anticiparse a los cambios de viento y prepararse en consecuencia. Si todo el array tiene acceso a la web (vía HTTP) y un servidor DNS, es fácil traducir el URI a: http:// turbine20.domain.tld/speed y monitorizar el campo remotamente.

El CoAP de un vistazo

  • Transferencia de documentos cliente/servidor REST
  • Fácil de traducir a HTTP para la integración web
  • Topología uno a uno con conexiones directas
  • Metadatos para diferenciar clases de documentos
  • UDP
  • Seguridad a través de DTLS

En entornos industriales OPC UA (Unified Architecture, ‘arquitectura unificada’) es el estándar de nueva generación que le sigue a OPC Foundation. OPC clásico es bien conocido en la industria y provee una interfaz estándar para comunicarse con los PLC (Programmable Logic Controller, ‘controlador lógico programable’). OPC UA pretende expandir la compatibilidad de OPC al nivel de los dispositivos y de las empresas.

OPC UA es un protocolo cliente/servidor. Los clientes se conectan, navegan, leen y escriben al equipamiento industrial. UA define la comunicación desde la aplicación hacia la capa de transporte, lo que lo hace muy compatible entre vendedores. También es muy seguro, y usa mensajes bidireccionales firmados y encriptación de transporte.

OPC UA tiene una amplia base instalada en el mundo industrial. Es una buena solución para conectar información de sensores y PLC en aplicaciones industriales ya existentes como sistemas MES (Manufacturing Execution System, ‘sistema de ejecución de manufactura’) y SCADA (Supervisry Control and Data Acquisition, ‘supervisión, control y adquisición de datos’), en donde la conectividad OPC y OPC UA ya estén disponibles.

Sin embargo, OPC UA es nuevo para las tecnologías de información. Algunas personas de TIC (tecnologías de la información y comunicación) se asustan ante la complejidad de UA en comparación con otros protocolos TIC. Bastante de esta complejidad reside en el hecho de que OPC UA sea un protocolo industrial, pero esta percepción ha llevado a ralentizar su adopción para plataformas IoT y la comunidad de código abierto.

Pero la cosa están cambiando: hace muy poco, OPC Foundation abrió el código del estándar OPC UA para hacerlo más accesible y colaborar a que se incremente su adopción.

Más información:

Comparativa de protocolos IoT:

Conclusión

OPC UA, HTTP, MQTT, CoAP, DDS, AMQP, etc.. todos tienen lugar en IoT. Cuál de estos protocolos tiene la mayor parte del mercado no está claro, pero cada uno tiene sus pros y sus contras. Es importante elegir el protocolo que mejor se adapte a sus necesidades, y seleccionar los socios tecnológicos que se puedan adaptar a tales protocolos. Esto asegurará el éxito para sus aplicaciones IoT y lo protegerá de las guerras de protocolos.

Muy buen resumen de protocolos de IoT: https://www.postscapes.com/internet-of-things-protocols/

Otro Buen resumen de protocolos IoT de la capa de aplicación: https://www.14core.com/the-iot-protocols-the-base-of-internet-of-things-ecosystem/

Anuncio publicitario

Video. Conectar ESP8266 a Internet. WifiClient

6 respuestas

TODO: poner enlace al vídeo

Una vez escaneadas las redes, vamos a conectarnos a una de ellas y acceder a internet llegando a un servidor y ver su contenido.

El ejemplo WiFiClientBasic que podemos encontrar en Archivos – Ejemplos – ESP8266WiFi – WiFiClientBasic.

Este ejemplo se conecta a una red WiFi y manda un mensaje a un servidor TCP, en este caso a la IP 192.168.1.1 y al puerto 80.

La clase ESP8266WiFiMulti es igual que la clase ESP8266WiFi pero que permite configurar múltiples conexiones a puntos de acceso que en caso de perder la conexión se conecte al siguiente: http://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/station-examples.html?highlight=ESP8266WiFiMulti

Con WiFi.mode(WIFI_STA); pongo el ESP8266 en modo estación, es decir, para conectar a una red WiFi de un punto de acceso.

Para más información:

Una vez conectado entramos en el loop y me conecto a un servidor como cliente. La clase cliente permite acceder a servicios de los servidor pudiendo enviar y recibir datos:

NOTA: en caso que el router wifi de una IP en otro rango que no sea el 192.168.1.x, cambiar la IP de la variable host por la IP del router wifi al que nos conectamos.

Ejercicio propuesto: conectar a https://www.aprendiendoarduino.com/servicios/aprendiendoarduino/ y leer el mensaje que devuelve.

Solución: https://github.com/jecrespo/aprendiendoarduino-curso-esp8266-youtube/blob/master/WiFiClientBasicMejorado/WiFiClientBasicMejorado.ino

En este caso debemos usar un lenguaje de comunicación común para hablar entre el servidor y el ESP8266, es el mismo lenguaje que usa cualquier navegador que se conecta a una página web y es el HTTP.

Una vez conectados al puerto 80 debe mandar un GET con la ruta del servidor y acabar con una línea nueva, tal y como funciona este protocol. Para ello mando:

 
client.println("GET /servicios/aprendiendoarduino/ HTTP/1.0");
client.println("Host: www.aprendiendoarduino.com");
client.println();

Si todo funciona bien recibiré la respuesta “HTTP1.1 200 OK” seguido de las cabeceras y luego una línea nueva, tras la cual aparecerá la respuesta del servidor. Para leer todas las líneas y no solo la primera es necesario hacer un bucle while mientras haya datos recibidos con la instrucción client.available(): https://www.arduino.cc/en/Reference/WiFiClientAvailable

NOTA: es necesario añadir la cabecera HTTP “Host: http://www.aprendiendoarduino.com” para que el hosting de la web resuelva el nombre del dominio.

La respuesta obtenida es:

Mensaje oculto: “Bienvenido al servidor de http://www.aprendiendoarduino.com”

Más información sobre el protocolo HTTP: https://aprendiendoarduino.wordpress.com/2017/06/26/protocolo-http-2/

Manejo de Conexiones HTTP Arduino

2 respuestas

Cliente

Cuando usamos Arduino como cliente HTTP, simplemente se programa la petición o http request. A la hora de recibir la respuesta o http response, dado que puede ser un número de datos muy grande podemos establecer varias estrategias:

  • Recoger toda la respuesta en un string o array de caracteres. Esto tiene un consumo muy alto de memoria.
  • Analizar línea a línea, puesto que el protocolo http se define por líneas, de forma que el consumo de memoria es pequeño y me puede permitir descartar el resto de respuesta http si ya no me interesa, para ello con un close() se cierra el socket y se descarta el resto de respuesta.
  • Leer a media que llega y usar alguna función que lea todo hasta que detecte lo que buscamos. Usa menos memoria, pero es más difícil de programar y es menos flexible.

Ejemplo: recoger datos de un servidor web y analizar los datos línea a línea o todo junto. Solicitar una petición de un json a http://www.aprendiendoarduino.com/servicios/aprendiendoarduino/string_avanzado.json

Solución: https://github.com/jecrespo/aprendiendoarduino-Curso_Arduino_Avanzado_2017/tree/master/Ejercicio21-Strings_Avanzado

Servidor. Muestra de Datos

En caso que queramos mostrar los datos de los sensores conectados a Arduino en una web podemos hacerlo de dos formas:

Además esta técnica me permite tener un histórico de datos que con un Arduino está limitado a la memoria o sino habría que usar una tarjeta SD u otro almacenamiento externo.

Por ejemplo la web http://www.aprendiendoarduino.com/servicios/datos/index.html muestra los útimos 30 datos mandados al servidor con el código https://github.com/jecrespo/aprendiendoarduino-servicios/tree/master/arduino_code/data_logger_temperatura_DHCP que manda la temperatura medida con un sensor de temperatura TMP36 por el Arduino.

Esquema de conexión:

Servidor. Control Remoto

En caso que queramos controlar un elemento remotamente, como encender una luz o la calefacción o mover un servo, la problemática es la misma que en el caso anterior si queremos acceder directamente al Arduino, en caso de estar en otra red y no tener IP pública nos obliga a abrir puertos en nuestro router.

Otra opción sería usar VPNs, pero Arduino no soporta VPN, así que necesitaríamos un elemento adicional.

Dos técnicas para control remoto:

  • Mandar datos directamente al Arduino. Arduino como web server y abrir puertos.
  • Usar un servidor intermedio al que se manda la orden y arduino pregunta periódicamente (Pull). Esto supone que el control acumula un retraso máximo del periodo que configuramos Arduino para que consulte al servidor.
  • Una tercera opción es montar un websocket entre Arduino y el servidor, de forma que el servidor comunica inmediatamente el cambio a Arduino (Push). Habría que buscar una librería que funcione bien.

Servidor. Eventos (Push/ Pull)

Cuando queremos que un Arduino mande un evento, por ejemplo una puerta abierta o una alta temperatura, Arduino lanza un aviso contra otro Arduino para que ejecute una acción como por ejemplo mandar un SMS si la puerta se abre o encender el aire acondicionado si hay mucha temperatura.

Ocurre lo mismo que con el control remoto, dos formas de hacerlo:

  • Como Push el Arduino que detecta el evento manda aviso cuando ocurre. Hay que abrir puertos si no hay conectividad directa.
  • Como Pull Arduino que detecta evento es un servidor y el cliente le pregunta periódicamente. Pero también hay que abrir puertos en el Arduino que actúa como servidor.
  • Una opción intermedia es que el Arduino que detecta eventos manda datos a un servidor público (Push) y el Arduino que debe actuar consulta periódicamente al servidor a ver si tiene que hacer algo (Pull)

Pull vs Push

Un ejemplo de la tercera solución es el envío de SMSs en http://www.aprendiendoarduino.com/servicios/SMS/index.html usando este código para el Arduino que manda el evento:

Este problema lo soluciona el protocolo MQTT

Pila de protocolos MQTT:

Librería MQTT:

Brokers MQTT públicos y gratuitos: https://github.com/mqtt/mqtt.github.io/wiki/public_brokers

Protocolo HTTP

6 respuestas

Protocolo HTTP

Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo de comunicación que permite las transferencias de información en la WWW. Se trata de un protocolo de capa 7 de aplicación.

En arduino con la librería ethernet solo trabajamos con la capa de aplicación, todas las otras capas de la pila TCP/IP ya están implementadas por Hardware, ya sea con la ethernet shield o el módulo WiFi correspondiente. Aunque si queremos realizar algunas funciones de capas inferiores, podemos hacerlo con los comandos adecuados comunicándonos con el chip ethernet o wifi via SPI.

Veamos algunos protocolos de la capa de aplicación que serán los que tengamos que implementar en nuestro arduino directamente o usando la librería adecuada:

HTTP es un protocolo muy importante puesto que es el que se va a usar para comunicar Arduino con cualquier elemento de la WWW o de una intranet. En el IoT es uno de los protocolos más usados y sobre todo si queremos obtener o mandar datos a servidores o usar las APIs que nos ofrecen algunos servicios para obtención de información, por ejemplo, para obtener el tiempo meteorológico de la AEMET https://opendata.aemet.es/centrodedescargas/inicio y con esos datos que Arduino actúe de una forma u otra.

Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la World Wide Web. HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force.

HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web) se lo conoce como «user agent» (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL).

HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de «sesión», y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el código de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario. Ejemplos de encabezados: HTTP_ACCEPT y HTTP_USER_AGENT.

Más información sobre HTTP:

Para intercambio de archivos por HTTP usamos MIME: http://es.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions

Líneas de encabezado o headers, son muy importantes y dan información adicional de la conexión y el comportamiento puede cambiar en función de ellas:

Interesante HTTP quick guide: https://www.tutorialspoint.com/http/http_quick_guide.htm

Métodos de Petición HTTP

Lo más importante para comunicar arduino por HTTP con otros dispositivos, ya sean servidores, ordenadores, otros Arduinos, etc… es conocer los métodos GET y POST del protocolo HTTP. HTTP define 8 métodos que indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor.

GET

GET: Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL. La petición puede ser simple, es decir en una línea o compuesta de la manera que muestra el ejemplo.

Ejemplo simple:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

Ejemplo con parámetros:

GET /index.php?page=main&lang=es HTTP/1.1

POST

POST: Envía los datos para que sean procesados por el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.

Los otros métodos de HTTP:

Más información:

Entender los métodos get y post:

Un explicación muy buena de HTTP también se puede encontrar en:  http://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html

HTTP request

Un cliente HTTP debe formar una petición HTTP (request) al servidor de una forma determinada para que sea entendida por el servidor. Cuando Arduino trabaja como cliente hay que programar esta petición correctamente, sino el servidor nos mandará un mensaje de error.

Formación de un HTTP request, esta petición habrá que programar en Arduino:

Trama en HTTP, fijaros en el uso de cr (retorno de carro – carriage return – ASCII 13) y lf (line feed – nueva linea – ASCII 10): http://www1.ju.edu.jo/ecourse/abusufah/cpe532_Spr06/notes/BookOnLine/HTTP%20Request%20Message.htm

HTTP/1.1 se definió en el estándar RFC2616,que es la más usada actualmente. En junio de 2014 RFC2616 se retiró y HTTP/1.1 se redefinió en RFCs 7230, 7231, 7232, 7233, 7234, and 7235, HTTP/2 está en proceso de definición.

Y cuando usar GET o POST?: http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist

HTTP response

Después de recibir e interpretar el servidor un HTTP request, el servidor debe responder con un mensaje de respuesta:

Para cumplir con el protocolo HTTP, arduino debe implementar estas respuestas cuando lo uso como servidor web, como devolución a un request mandado por un cliente como puede ser un browser o navegador. De esta forma puedo implementar en Arduino una web embebida.

Por lo tanto Arduino podemos programarlo para comportarse como cliente, como servidor o como ambos.

Veamos esto gráficamente:

Ejercicio: Ver las tramas HTTP con las funciones de depuración del navegador y también con wireshark, un web sniffer on-line y algún plugin para el navegador.

Listado de web sniffers: http://scraping.pro/web-sniffers-review/

Servidor Web Embebido en Arduino

Para poder implementar un servidor web embebido en un Arduino e interactuar con él, se debe programar los mensajes http en Arduino para responder al navegador de forma adecuada.

La secuencia que se produce en una web embebida para encender y apagar un led es:

  • El navegador manda un http request GET a la IP de Arduino cuando pongo su IP en el navegador. p.e. http://192.168.1.15
  • Arduino recibe la petición que comienza por «GET / HTTP/1.1»
  • Arduino devuelve el http response con «HTTP/1.0 200K» y luego la web con el código html, haciendo print sobre el cliente ethernet y cierra la comunicación.
  • El navegador recibe el http respnse y muestra la web, en este caso un botón.
  • Al pulsar el botón en el navegador, el código HTML ya está configurado para mandar una petición POST.
  • Arduino recibe la petición que comienza por «POST / HTTP/1.1” y enciende o apaga el led según corresponda.
  • Luego Arduino muestra la web con el estado del led actualizado.

Ver este proceso con wireshark o con las herramienta de desarrollador del navegador pulsando F12.

Ver sketch en: https://github.com/jecrespo/aprendiendoarduino-Curso_Arduino_2017/tree/master/Ejercicio40-Boton_Mejorado_DHCP

Diagrama de flujo:

Más información:

Programa botón para diferentes Arduino. Comparar:

Librerías HTTP

Libreria Webduino

Webduino es una librería muy popular que nos permite implementar un servidor web en nuestro Arduino.

La web del creador: https://code.google.com/p/webduino/

El reference de la librería: https://code.google.com/p/webduino/wiki/Documentation

Repositorio de la librería: https://github.com/sirleech/Webduino

Snippet Webduino en el playground: http://playground.arduino.cc/Main/WebduinoFileServer

Para Shields con Microchip ENC28J60 no es válida esta librería puesto que necesita SW adicional para implementar la pila TCP/IP.

Una presentación que explica como funciona: https://docs.google.com/presentation/d/1QUG4XJTK3jKtU-eYUfM1DvUdRaKBrp__LEwZQfz9s6E/edit#slide=id.i0

Hilo de soporte de la librería: http://forum.arduino.cc/index.php/topic,37851.0.html

Ejercicio 29-Webduino Entender cómo funciona la librería y ver el ejemplo webdemo

Luego hacer la aplicación web buzzer.

Streaming: http://arduiniana.org/libraries/streaming/

Class Templates: http://www.cprogramming.com/tutorial/templates.html

Solución en https://github.com/jecrespo/Aprendiendo-Arduino/tree/master/Ejercicio29-Webduino

Otras Librerías

Otras librerías para implementar un servidor web en Arduino:

Y una librería para implementar un cliente HTTP:

Librería http client: https://github.com/amcewen/HttpClient

Arduino Web Client

3 respuestas

IMPORTANTE: Para los ejercicio con conexión Ethernet es imprescindible poner en la MAC del Arduino en los dos últimos dígitos el número del kit. En todos los sketchs hay que sustituir YY por el número de kit.

Para las prácticas la IP de los Arduinos se asignará dinámicamente por DHCP, en este caso ya nos asigna también el servidor DNS y por lo tanto podemos usar nombres de páginas web.

Conexión a una Web con Arduino

Crear un cliente ethernet que se conecte varias webs y escriba por consola los datos recogidos. También guarde los datos recibidos en un string. Probar a conectar a varias páginas web y usa el servicio DNS poniendo la url en lugar de la IP.

Webs:

Tutorial: webclient con ejemplo de métodos get y post: http://playground.arduino.cc/Code/WebClient

Solución: https://github.com/jecrespo/aprendiendoarduino-Curso_Arduino_2017/tree/master/Ejercicio35-EthernetClient_DHCP

API AEMET

AEMET API: http://www.aemet.es/es/datos_abiertos/catalogo (open data)

Tiempo en logroño: http://www.aemet.es/xml/municipios/localidad_26089.xml

Nueva API aemet: https://opendata.aemet.es/centrodedescargas/inicio

Ejemplos para desarrolladores: https://opendata.aemet.es/centrodedescargas/ejemProgramas

Avanzado: Obtener la temperatura en logroño actualizada por el display LCD sin necesidad de un sensor de temperatura.

Open data:

Un poco de información:

Ver https://es.wikipedia.org/wiki/ELIZA

POST vs GET con Arduino

Mandar por método GET y método POST dos valores, el número de Arduino y un mensaje. Estas peticiones se hacen a las funciones PHP GET_Request.php y POST_Request.php, que están en la ruta “www.aprendiendoarduino.com/servicios/aprendiendoarduino/”.

Es servidor responderá con los datos enviados y un “OK” al final que servirá al Arduino para saber que se han recibido correctamente los datos.

Solución GET: https://github.com/jecrespo/aprendiendoarduino-Curso_Arduino_2017/tree/master/Ejercicio36-GET_Request

Código en el servidor:

 
<?php
if(isset($_GET["arduino"]) && isset($_GET["mensaje"])){
	$arduino = $_GET["arduino"];
	$mensaje = $_GET["mensaje"];
}
else {
	die("error en el envio de parametros");
}
 
echo ("<h4>Hola Arduino numero $arduino!!</h4>");
echo ("He recibido el mensaje: \"$mensaje\" mediante GET");
echo ("OK")
?>

Solución: POST: https://github.com/jecrespo/aprendiendoarduino-Curso_Arduino_2017/tree/master/Ejercicio37-POST_Request

Código en el servidor:

 
<?php
if(isset($_POST["arduino"]) && isset($_POST["mensaje"])){
	$arduino = $_POST["arduino"];
	$mensaje = $_POST["mensaje"];
}
else {
	die("error en el envio de parametros");
}
 
echo ("<h4>Hola Arduino numero $arduino!!</h4>");
echo ("He recibido el mensaje: \"$mensaje\" mediante POST");
echo ("OK")
?>

NOTA: podéis usar estos códigos como snippets para otras aplicaciones.

NTP básico

Montar un Arduino para que recoja y mantenga la fecha y hora de un servidor NTP y así teniendo un Arduino conectado a Internet no siendo necesario usar un RTC para mantener la fecha y hora en Arduino.

Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123. Está diseñado para resistir los efectos de la latencia variable.

Servidores NTP: http://www.pool.ntp.org/es/use.html

Este es un ejemplo de cliente web, pero UDP en lugar de TCP.

Conceptos a manejar:

Solución: https://github.com/jecrespo/aprendiendoarduino-Curso_Arduino_2017/tree/master/Ejercicio38-NTP_DHCP