Un sistema IoT conecta observación física, procesamiento y comunicación. El sensor entrega una lectura a ESP32; la placa prepara un mensaje; la red lo transporta; un servicio local valida y conserva el último aceptado; la app lo consulta y presenta. Las flechas tienen dirección y finalidad: enviar una medida y consultar la última son acciones distintas. La red transporta información, pero no decide automáticamente si una medida es válida.

Los componentes no conocen todo el recorrido ni trabajan necesariamente al mismo tiempo. ESP32 puede medir sin conseguir enviar. El servicio puede responder con una lectura anterior cuando el emisor está desconectado. La app puede mantener un número visible después de una consulta fallida. Por eso un valor en pantalla no demuestra medida actual ni montaje físico. Un identificador de ensayo y un registro temporal permiten seguir una lectura sin añadir datos personales. El proyecto puede funcionar en una red local autorizada sin Internet público; esa elección define dependencias que debemos explicar y probar.

WiFi permite conectar un dispositivo a una red inalámbrica; HTTP organiza solicitudes y respuestas de aplicación. Tener conexión WiFi no garantiza que un servicio esté disponible. BLE es otra tecnología y requiere componentes y programación compatibles; no sustituye automáticamente el intercambio HTTP. En la arquitectura del aula, ESP32 actúa como cliente de la red preparada, y el equipo del servicio debe ser alcanzable desde los dispositivos autorizados.

Una dirección IP identifica una interfaz en su red. El puerto indica dónde escucha el proceso y la ruta identifica el recurso solicitado. La forma http://direccion:8000/lectura permite distinguir esas partes sin inventar la configuración real del centro. 127.0.0.1 y localhost señalan el propio equipo: en una tablet no llevan al ordenador del servicio. Un servidor que escucha solo allí no acepta por eso conexiones de otros dispositivos. El docente prepara interfaz de escucha, red y cortafuegos; cambiar la dirección del cliente no configura el servidor ni abre el acceso permitido.

JSON representa datos mediante nombres, valores y tipos. El contrato del laboratorio acepta valor como número finito entre 0 y 100 y unidad como el texto exacto escala. El número 42 no es el texto «42» y un nombre parecido no sustituye una clave acordada. El receptor debe revisar campos, tipos y dominio: recibir un texto que parece JSON no demuestra que contenga una lectura interpretable.

La escala es didáctica y normalizada, sin atribuirle lux, centímetros ni porcentaje físico de humedad. La primera serie generada por ESP32 se marca SIMULADO. Para incorporar el sensor validado se sustituye la función de lectura y se documenta cualquier conversión, conservando origen y limitaciones. Cambiar una etiqueta no transforma una simulación en medida real. El servicio añade tiempo de recepción y rechaza mensajes inválidos sin reemplazar la última lectura válida. Validar también en el receptor importa porque otro cliente puede enviar datos distintos de los previstos, aunque el emisor del equipo funcione bien.

HTTP organiza un intercambio entre un cliente que solicita una acción y un servicio que responde. La petición reúne método, destino, cabeceras y, cuando corresponde, cuerpo. En el laboratorio, POST envía una lectura y GET consulta la última disponible. La clave de acceso viaja en una cabecera y la medida se representa en el cuerpo JSON. Esta separación permite entender qué se solicita, a qué recurso y con qué información; haber enviado la petición todavía no confirma que el servicio la haya aceptado.

La respuesta contiene un código y contenido que deben interpretarse conjuntamente. El contrato escolar utiliza 201 para un envío aceptado, 400 para un dato inválido, 401 cuando faltan credenciales válidas y 404 para una ruta inexistente. Estos resultados describen la respuesta del servicio, no mensajes universales de un sensor. Un rechazo recibido demuestra que hubo respuesta, aunque la acción solicitada no se haya autorizado o aceptado. Por eso un mensaje de error no debe convertirse en una confirmación de actualización.

Incluso una consulta con código 200 necesita revisar lo que devuelve. Antes del primer envío aceptado, puede responder disponible: false: la comunicación ha funcionado, pero corresponde mostrar SIN DATOS. Mostrar cero inventaría una lectura. El cliente comprueba primero el código, después la estructura y finalmente la disponibilidad y antigüedad del dato. Ese recorrido distingue ausencia de lectura, rechazo y falta de respuesta. También orienta la investigación hacia la parte observada, en vez de atribuir cualquier problema a WiFi o considerar válido cualquier texto que haya llegado.

Una comunicación asíncrona separa el momento de pedir información del momento de recibirla. Cuando se pulsa Actualizar, la app prepara Web.Url y RequestHeaders, muestra CONSULTANDO y llama a Get. Después de esa llamada todavía puede no existir una respuesta nueva. La etiqueta puede conservar el número de la consulta anterior, porque su contenido no cambia por el simple hecho de pedir otro dato. El estado de espera explica al usuario qué ocurre mientras la app sigue respondiendo a sus acciones.

La recepción se procesa en GotText, utilizando responseCode y responseContent. Para seguir este recorrido con texto, SaveResponse debe estar desactivado. El código permite escoger la rama de respuesta adecuada; después se interpreta el JSON y se comprueba su estructura antes de utilizar sus campos. JsonTextDecodeWithDictionaries convierte un texto JSON que representa un objeto en un diccionario, donde cada clave permite localizar su valor por nombre. Obtener ese diccionario no sustituye la comprobación de que estén presentes los datos esperados y tengan sentido según el contrato.

La espera también necesita un desenlace cuando no llega la respuesta. Un Timeout finito permite ensayar TimedOut y comunicar que se agotó el plazo; otros errores del componente requieren igualmente un mensaje comprensible. La versión inicial utiliza un botón para observar cada fase. Si después se añade un reloj, hay que evitar que acumule solicitudes sin control. El estado pendiente pertenece a esa consulta y es temporal. Una configuración local guardada puede servir para preparar otra petición, pero no demuestra que se haya recibido una lectura actual.

edad_s expresa el tiempo transcurrido desde que el servicio recibió la última lectura válida. En el proyecto, una edad superior a diez segundos produce DATO ANTIGUO; ese plazo es una decisión didáctica, no una norma universal. Un servicio accesible con dato antiguo es distinto de un servicio inaccesible. Si falla la consulta, la app debe indicar SIN CONEXIÓN o el error correspondiente y no presentar silenciosamente el último número como actual.

La fecha de recepción no equivale siempre al instante físico de medida: un dispositivo que almacena antes de enviar puede introducir retraso. Aquí se mide y envía de forma próxima, declarando esa simplificación. Al recuperar comunicación, una lectura nueva puede tener el mismo valor que la anterior; su renovación se demuestra con recepción y antigüedad, no con cambio numérico obligatorio. Prueba por separado emisor detenido, servicio parado y tablet sin acceso. Anota lo que permite distinguir cada observación y lo que sigue incierto, sin atribuir un único origen a cualquier ausencia de respuesta.

El servicio del laboratorio comprueba una clave en cabecera para rechazar solicitudes no autorizadas. Ese control no cifra el tráfico: HTTP local deja el contenido sin protección de transporte. Autenticar acceso, limitar permisos, cifrar y recuperar archivos responden a necesidades diferentes. La práctica funciona en red aislada preparada por el docente y no expone puertos a Internet ni incorpora datos personales. Un servicio real necesitaría controles adecuados a su contexto.

La configuración de acceso se conserva fuera de la entrega; un archivo secrets.example.h muestra nombres con valores ficticios y secrets.h permanece en el equipo autorizado. También se revisan capturas y copias. Una copia restaurada demuestra recuperación del archivo, no secreto protegido durante una comunicación. La nube añade proveedor, cuentas, acceso remoto, conservación y dependencia de Internet. El servicio local depende del equipo y de la red de prácticas. Compara finalidad, datos que saldrían, audiencia y respuesta a desconexiones; la alternativa se estudia con esquema y capturas preparadas, sin crear ni publicar servicios.

Integrar consiste en comprobar que los contratos encajan de extremo a extremo. Una lectura física necesita ficha de sensor, interpretación y conversión documentadas; una serie simulada solo acredita los tramos que utiliza. La microapp debe consultar realmente y mostrar espera y respuesta validada. Un esquema de arquitectura o una captura preparada no sustituyen haber realizado la primera cadena de lectura, envío y consulta que se incorpora a A01.

Las pruebas finales incluyen cinco valores válidos, un mensaje fuera de contrato, clave incorrecta, antigüedad tras detener el emisor y recuperación de datos nuevos. Se añaden ausencia inicial y fallo de comunicación para explicar los estados de la vista. Anota entrada o acción, respuesta esperada, observación y conclusión en orden temporal. Una mejora necesita repetir casos comparables y conservar los archivos editables de placa y app. Cada integrante explica eventos, almacenamiento utilizado y una modificación. El resultado reconoce límites del servicio local, del HTTP sin cifrar y del diagnóstico disponible, sin convertir la demostración escolar en un despliegue público.