Volver a tu curso / CR3-S03
Computación y Robótica · 3.º ESO · Lectura fácil
Internet de las cosas
Seguirás un dato desde el sensor hasta el móvil.
Cada parte puede fallar.
La pantalla debe explicar qué sabe.
Tu misión
Construye con tu pareja una estación con ESP32, servicio local y app de App Inventor.
No uses datos personales.
Comprueba antigüedad, desconexión y recuperación.
Dibuja una alternativa en nube dentro de las diez sesiones.
Lee una explicación cada vez. Mira el esquema. Después haz la actividad. Puedes cambiar de versión cuando quieras.
Qué herramientas vas a usar
Escribe los textos en Documentos de Google. Haz los diagramas en diagrams.net. Guarda el archivo que puedas editar. Mira qué debes entregar en cada tarea.
3.1. El camino de una lectura
Aprende y practica
IoT conecta observación, proceso y comunicación.
El sensor entrega una lectura a ESP32.
ESP32 prepara un mensaje y la red lo transporta.
El servicio valida y guarda la última lectura aceptada.
La app consulta y muestra el dato.
Enviar y consultar son acciones distintas.
La red no decide si la medida es válida.
La placa puede medir y fallar al enviar.
El servicio y la app pueden conservar un valor anterior.
Un número visible no demuestra una lectura actual ni física.
Sigue una lectura con código de ensayo y tiempo sin datos personales.
La red local autorizada puede funcionar sin Internet público.
- Sensor
- ESP32
- Servicio
- App
La app muestra 61 y la placa deja de enviar.
El servicio puede conservar ese 61.
Comprueba recepción y antigüedad.
La consulta puede funcionar aunque falle el envío.
- Dibuja sensor, ESP32, red, servicio y app en diagrams.net con flechas de envío y consulta.
- En Google Docs, indica qué guarda cada parte y cómo seguirás una lectura.
¿Puede responder el servicio con una lectura anterior?
3.2. Llegar al servicio correcto
Aprende y practica
WiFi conecta a una red inalámbrica.
HTTP organiza peticiones y respuestas.
Tener WiFi no garantiza llegar al servicio.
BLE es otra tecnología con requisitos propios.
ESP32 usa la red preparada en clase.
La IP identifica una interfaz en esa red.
El puerto indica dónde escucha el proceso.
La ruta identifica el recurso.
127.0.0.1 y localhost señalan el propio equipo.
En la tablet no señalan el ordenador del servicio.
El docente prepara escucha, red y cortafuegos.
Cambiar la dirección del cliente no configura el servidor.
- WiFi
- Dirección
- Puerto
- Ruta
localhost funciona en el ordenador, pero en la tablet señala la tablet.
Revisa la interfaz y la preparación del servicio.
Usa la dirección, puerto y ruta proporcionados en clase.
The Internet: Wires, Cables & Wifi
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
- En Google Docs, distingue protocolo, dirección, puerto y ruta y usa solo la configuración autorizada en el equipo.
- Dibuja cliente, punto de acceso y servicio en diagrams.net e indica tres fallos posibles con WiFi conectado.
¿Por qué un puerto incorrecto no se arregla cambiando la medida?
3.3. Acordar los datos del mensaje
Aprende y practica
JSON representa nombres, valores y tipos.
El contrato usa las claves valor y unidad.
valor debe ser un número finito entre 0 y 100.
unidad debe contener el texto exacto escala.
42 como número no equivale al texto «42».
El receptor comprueba campos, tipos e intervalo.
La escala didáctica no significa lux ni humedad física.
La primera serie de ESP32 lleva la etiqueta SIMULADO.
Para usar sensor real, cambia la lectura y documenta su conversión.
Una etiqueta nueva no convierte una simulación en medida real.
El servicio añade tiempo de recepción.
Un mensaje inválido no reemplaza el último dato válido.
- Dato y origen
- JSON
- Revisar
- Guardar si es válido
El servicio acepta 38 y rechaza 138.
La red ha permitido responder.
El dato sigue siendo 38 y conserva su antigüedad.
El rechazo no crea una lectura nueva.
- En Google Docs, prepara mensajes con campo ausente, tipo incorrecto y valor fuera de escala y predice el resultado.
- Con el emisor de Arduino IDE del laboratorio, envía un dato válido y otro inválido y comprueba que el panel conserva el anterior.
¿Por qué la escala 0–100 no es automáticamente humedad en porcentaje?
3.4. Esperar una respuesta comprobada
Aprende y practica
HTTP organiza peticiones y respuestas.
El cliente solicita una acción y el servicio responde.
La petición incluye método, destino y cabeceras.
También puede incluir un cuerpo.
En el laboratorio, POST envía una lectura.
GET consulta la última disponible.
La clave de acceso viaja en una cabecera.
El cuerpo JSON representa la medida.
Así distinguimos acción, recurso e información enviada.
Enviar la petición todavía no confirma que el servicio la acepte.
La respuesta contiene un código y contenido.
Hay que interpretar ambos.
En el contrato escolar, 201 significa envío aceptado.
400 significa dato inválido.
401 indica que faltan credenciales válidas.
404 indica una ruta inexistente.
Son respuestas del servicio.
No son mensajes universales de un sensor.
Recibir un rechazo demuestra que hubo respuesta.
La acción puede haber quedado sin autorización o sin aceptación.
Un error recibido no confirma una actualización.
También debemos revisar el contenido de una respuesta 200.
Antes del primer envío aceptado, puede llegar disponible: false.
La comunicación funciona, pero corresponde mostrar SIN DATOS.
Mostrar cero inventaría una lectura.
El cliente revisa código, estructura, disponibilidad y antigüedad, en ese orden.
Así distingue ausencia de lectura, rechazo y falta de respuesta.
La observación orienta qué parte investigar.
No todo problema se debe a WiFi.
Recibir texto tampoco demuestra que sea un dato válido.
- Petición
- Servicio
- Código
- Revisar contenido
200 con disponible: false significa que el servicio respondió sin datos.
No muestres cero.
Un 401 indica rechazo de acceso.
Ambos son distintos de no recibir respuesta.
Domótica DIY: Servidor Web ESP32 para Control de Iluminación – Paso a Paso
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
- En Google Docs, relaciona sin datos, envío correcto, dato inválido, clave incorrecta y ruta inexistente con sus respuestas.
- Observa código y contenido en el panel local y explica el rechazo al abrir /lectura sin cabecera.
¿Qué distingue sin datos, acceso rechazado y sin respuesta?
3.5. La respuesta llega después
Aprende y practica
En una comunicación asíncrona, pedir y recibir ocurren en momentos distintos.
Al pulsar Actualizar, la app prepara Web.Url y RequestHeaders.
Muestra CONSULTANDO y llama a Get.
Después de Get puede no existir todavía una respuesta nueva.
La etiqueta puede conservar el número anterior.
Pedir otro dato no cambia por sí solo esa etiqueta.
La espera explica al usuario qué está ocurriendo.
Mientras tanto, la app sigue respondiendo a las acciones del usuario.
GotText procesa la respuesta recibida.
Utiliza responseCode y responseContent.
SaveResponse debe estar desactivado para recibir texto por este recorrido.
El código permite elegir la rama de respuesta.
Después se interpreta el JSON.
Se comprueba su estructura antes de utilizar los campos.
JsonTextDecodeWithDictionaries convierte un texto JSON que representa un objeto en un diccionario.
Cada clave permite buscar su valor por nombre.
Obtener el diccionario no garantiza que estén todos los datos esperados.
También hay que revisar su significado según el contrato.
La espera necesita un final aunque no llegue respuesta.
Un Timeout finito permite probar TimedOut.
Este evento comunica que se agotó el plazo.
Otros errores del componente también necesitan un mensaje claro.
La versión inicial usa un botón para observar cada fase.
Si añadimos un reloj, debemos evitar peticiones acumuladas sin control.
El estado pendiente pertenece a esa consulta y es temporal.
Una configuración local guardada puede preparar otra petición.
No demuestra que haya llegado una lectura actual.
- Pulsar
- Esperar
- Pedir
- Recibir o error
- Mostrar estado
La app anuncia actualización antes de recibir GotText.
Puede estar mostrando un dato antiguo.
Procesa la respuesta en GotText y muestra espera mientras llega.
App Inventor 3.2: Mi primera App (Bloques)
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
- En App Inventor, crea botón, etiquetas y Web, configura SaveResponse y Timeout y prueba los eventos con el servicio autorizado.
- Dibuja botón, Get y GotText o TimedOut en diagrams.net e indica dónde revisar código, JSON y disponibilidad.
¿Por qué Get no permite usar ya la respuesta nueva?
3.6. Saber si el dato es reciente
Aprende y practica
edad_s cuenta desde la recepción del último dato válido.
Más de diez segundos significa DATO ANTIGUO en este proyecto.
Diez segundos es una regla didáctica.
Dato antiguo no equivale a servicio inaccesible.
Si falla la consulta, indica SIN CONEXIÓN o el error observado.
No presentes el número anterior como actual.
Recibir no siempre ocurre al mismo tiempo que medir.
Aquí medimos y enviamos de forma próxima.
Dos lecturas nuevas pueden tener el mismo valor.
Recepción y antigüedad permiten ver la actualización.
Prueba por separado emisor, servicio y acceso de la tablet.
Explica qué sabes y qué sigue incierto.
- Recibir
- Pasar tiempo
- Comparar edad
- Mostrar estado
El emisor envía 54 dos veces.
El número no cambia y la edad se renueva.
Si deja de enviar, la edad crece.
Una foto del número no distingue ambos casos.
- En App Inventor, muestra sin datos, actualizado, antiguo o error según el contrato y espera mientras llega respuesta.
- Detén el emisor más de diez segundos, recupéralo y anota valor, edad y estado en Google Docs; compara con detener el servicio.
¿Cómo sabes que llegaron dos lecturas iguales?
3.7. Proteger acceso y elegir arquitectura
Aprende y practica
La clave en cabecera limita el acceso al servicio.
HTTP local no cifra el tráfico.
Acceso, permisos, cifrado y copias tienen funciones distintas.
Usa la red aislada preparada por el docente.
No abras puertos a Internet ni uses datos personales.
secrets.example.h contiene valores ficticios.
secrets.h queda en el equipo autorizado y fuera de la entrega.
Revisa también capturas y copias.
Restaurar un archivo no cifra una comunicación.
La nube añade proveedor, cuentas, acceso remoto y conservación.
El servicio local depende del equipo y de la red del aula.
Compara datos, audiencia y desconexión con un esquema sin publicar servicios.
- Necesidad
- Arquitectura
- Acceso y datos
- Límites
La clave puede quedar visible en una captura aunque no entregues secrets.h.
Revisa todo el paquete.
Recuperar código desde una copia demuestra recuperación y no cifrado.
- En Google Docs, anota acceso permitido y clave ficticia incorrecta y restaura una copia ficticia explicando qué comprueba cada prueba.
- Compara local y nube en diagrams.net con datos, audiencia, conservación y dependencia y revisa que la entrega no tenga secretos.
¿Por qué clave y copia no prueban cifrado de la comunicación?
3.8. Probar todas las partes juntas
Aprende y practica
Integrar comprueba que las partes comparten contratos compatibles.
Una lectura física necesita ficha, significado y conversión documentados.
La simulación solo comprueba las partes utilizadas.
La microapp debe consultar y mostrar espera y respuesta revisada.
A01 incluye una primera cadena ejecutada y no solo un esquema.
Prueba cinco valores válidos y un mensaje inválido.
Prueba clave incorrecta, antigüedad y recuperación.
Comprueba también ausencia inicial y fallo de comunicación.
Anota acciones, predicciones, resultados y conclusiones en orden.
Repite pruebas para demostrar la mejora y conserva placa y app editables.
Cada persona explica eventos, almacenamiento y un cambio.
Reconoce límites locales, HTTP sin cifrar y diagnóstico disponible.
- Sensor real
- Enviar
- Consultar
- Fallo y recuperación
Detener la app no demuestra que el emisor dejó de enviar.
Para probar antigüedad, detén el emisor y mantén la consulta.
Cada fallo necesita su prueba.
- En Google Docs, escribe las pruebas e indica qué parte detendrás para cada fallo.
- Prueba la cadena física con Arduino IDE y App Inventor, registra una incidencia y repite tras corregirla.
¿Qué prueba falta si el panel solo recibió datos simulados?
Tu proyecto y tus entregas
A01 · Diseña la solución
- En Google Docs, define necesidad, sensor y escala y dibuja cadena, protocolo, campos y alternativa en nube en diagrams.net.
- Completa la ficha, compara una lectura física con una simulada y ejecuta una microcadena con conversión, envío y consulta.
- En App Inventor, realiza una microconsulta con espera, GotText y JSON y explica estado temporal y configuración guardada.
- Prepara cinco estados o mensajes con ausencia, rechazo y antigüedad y casos de desconexión y recuperación.
- Prueba acceso y rechazo, excluye secretos, restaura una copia ficticia y guarda CR3-S03_iot_A01_Apellidos con recursos, fuentes y trabajo individual.
Qué debes entregar
- Esquema, contrato y ficha con lectura física y conversión.
- Microcadena y app inicial ejecutadas con eventos y almacenamiento explicados.
- Pruebas previstas, acceso rechazado, copia recuperada y entrega sin secretos.
Haz tu copia en Documentos de Google · Ver la plantilla vacía
A02 · Estación IoT con panel móvil
- Integra sensor físico validado, ESP32, servicio local y app editable con Arduino IDE y App Inventor y muestra valor, escala, edad y estado.
- Prueba cinco valores y cinco recepciones, rechazo de 101 o unidad distinta sin sobrescribir y 401 con clave incorrecta.
- Detén emisor más de diez segundos, comprueba DATO ANTIGUO y recuperación, y prueba pérdida de acceso, ausencia inicial y espera.
- Registra incidencia, mejora y nueva prueba, restaura un archivo ficticio y entrega código y .aia sin secretos con CR3-S03_iot_A02_Apellidos.
- Cada persona explica recorrido, eventos, contrato, almacenamiento, protección y límites y predice o realiza un cambio dentro de A02.
Qué debes entregar
- Cadena física, esquema, código y proyecto .aia.
- Pruebas de contrato, validación, acceso, edad, fallo y recuperación con predicción y resultado.
- Copia recuperada, mejora, instrucciones, fuentes y explicación individual.
Haz tu copia en Documentos de Google · Ver la plantilla vacía
Revisa antes de entregar
- Estas frases describen mi aprendizaje y no sustituyen la rúbrica oficial.
- Distingo WiFi, respuesta HTTP y dato válido o reciente.
- Explico Get, GotText, espera y error siguiendo una petición.
- Demuestro lectura física, rechazo y recuperación sin mostrar secretos.
Plantillas y archivos
Abre la plantilla vacía de A01 o A02. Haz tu copia en Documentos de Google. Guarda también tu programa o proyecto editable.
La plantilla sirve para organizar tu trabajo. Mira qué pide esta unidad. Puedes quitar un campo si no lo necesitas. Haz una copia. No escribas sobre el modelo. No publiques tus respuestas. Compártelas como indique tu docente.
A01 · Diseña la solución
Haz tu copia en Documentos de Google · Ver la plantilla vacía
- Esquema, contrato y ficha con lectura física y conversión.
- Microcadena y app inicial ejecutadas con eventos y almacenamiento explicados.
- Pruebas previstas, acceso rechazado, copia recuperada y entrega sin secretos.
A02 · Estación IoT con panel móvil
Haz tu copia en Documentos de Google · Ver la plantilla vacía
- Cadena física, esquema, código y proyecto .aia.
- Pruebas de contrato, validación, acceso, edad, fallo y recuperación con predicción y resultado.
- Copia recuperada, mejora, instrucciones, fuentes y explicación individual.
Rúbricas de clase
Aquí están las rúbricas de clase. Cada rúbrica explica cómo se valora una entrega. Puedes pedir ayuda para entender una palabra.
Consultar la rúbrica de A01
Diseño y microprueba
CYR.3.1.1 Cadena: sensor, emisor, servicio y vista
Comprender el funcionamiento de los sistemas de computación física, sus componentes y principales características.
Evidencia. Arquitectura, ficha del sensor y primera lectura física contrastada con dato de ensayo.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No distingue sensor y servicio o presenta una constante enviada como medida física sin indicarlo. |
| 3–4,9 | Dibuja la cadena, pero omite función o unidad y no explica la normalización. |
| 5–6,9 | Relaciona sensor, ESP32, red, servicio y app, distingue señales y dato de ensayo y documenta una lectura física y su interpretación. |
| 7–8,9 | Contrasta lectura local y mensaje recibido y localiza dónde se realiza la transformación de dato. |
| 9–10,0 | Justifica otra fuente de medida y qué calibración e interfaz requeriría antes de integrarla. |
CYR.3.2.2 Eventos de la app y contrato de respuesta
Entender el funcionamiento interno de las aplicaciones móviles y cómo se construyen, dando respuesta a las posibles demandas del escenario a resolver.
Evidencia. Microapp con Web, consulta de ensayo y estado pendiente o respuesta validada.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Actualiza la medida antes de recibir respuesta y no distingue interfaz de comunicación. |
| 3–4,9 | Envía consulta, pero no interpreta código o JSON ni sabe qué significa el dato guardado. |
| 5–6,9 | Relaciona interfaz, evento de petición, GotText y JSON en una microapp. Distingue espera, última lectura y configuración local o estado volátil utilizado. |
| 7–8,9 | Prueba rechazo o respuesta tardía y explica cuándo se actualiza la etiqueta y cuándo se conserva el último dato. |
| 9–10,0 | Propone una organización de eventos que evita atribuir una respuesta antigua a otra petición y la justifica con un caso. |
CYR.3.2.3 Solución móvil a fallos de comunicación
Conocer y resolver la variedad de problemas posibles desarrollando una aplicación móvil y generalizando las soluciones.
Evidencia. Escenario, microconsulta y tabla de mensajes y fallos con resultado previsto.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No vincula la app con la necesidad o confunde fallo de autorización y ausencia de WiFi. |
| 3–4,9 | Define funciones, pero faltan respuestas a pérdida de emisor o reinicio del servicio. |
| 5–6,9 | Resuelve una consulta inicial, define contrato y prevé cinco mensajes o estados, incluyendo ausencia, rechazo y antigüedad. |
| 7–8,9 | Relaciona cada fallo con una capa o dependencia y reutiliza una pauta de recuperación en otro caso. |
| 9–10,0 | Compara dos respuestas de interfaz al fallo y justifica cuál informa sin producir falsas confirmaciones. |
CYR.3.3.1 Estación IoT con interacción física
Ser capaz de construir un sistema de computación o robótico, promoviendo la interacción con el mundo físico en el contexto de un problema del mundo real, de forma sostenible.
Evidencia. Microcadena física con sensor, envío de ensayo y primera consulta, más necesidad y recursos.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No demuestra una interacción física ni distingue arquitectura dibujada de sistema construido. |
| 3–4,9 | Se ejecuta cliente y servidor con datos inventados, pero no se integra una lectura física ni se delimita el ensayo. |
| 5–6,9 | Construye una primera cadena con lectura física, envío y consulta y documenta necesidad, conexiones validadas y reutilización de recursos. |
| 7–8,9 | Identifica el tramo que falla y revisa la integración con una prueba por etapas. |
| 9–10,0 | Compara una alternativa local o de nube y argumenta dependencias y recursos para la necesidad. |
CYR.3.6.4 Acceso, secretos y protección del servicio
Conocer las estrategias de ciberseguridad que garantizan protección a los usuarios de Internet.
Evidencia. Microprueba de autorización, archivo de secretos excluido y copia restaurada de código o configuración ficticia.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Incluye claves reales en la entrega o afirma que un token cifra una comunicación HTTP. |
| 3–4,9 | Prevé permisos, pero no prueba autorización o confunde copia y protección de acceso. |
| 5–6,9 | Prueba acceso autorizado y rechazo en el laboratorio, separa secretos y restaura una copia ficticia. Distingue control de acceso, copia y cifrado. |
| 7–8,9 | Comprueba que un dato inválido no sustituye al válido y explica límites de HTTP y alcance local. |
| 9–10,0 | Analiza otra exposición posible en capturas o historial y propone una medida y comprobación proporcionadas. |
Consultar la rúbrica de A02
Producto pruebas y mejora
CYR.3.1.1 Cadena: sensor, emisor, servicio y vista
Comprender el funcionamiento de los sistemas de computación física, sus componentes y principales características.
Evidencia. Cadena física y mensajes, esquema final y explicación de medida y normalización.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Atribuye al servicio una medida que no procede del sensor o usa unidades físicas no justificadas. |
| 3–4,9 | Se reciben datos, pero no explica su origen o confunde escala normalizada y magnitud calibrada. |
| 5–6,9 | Demuestra recorrido sensor ESP32 servicio app y explica componentes, señales, transformación y unidad o escala utilizada. |
| 7–8,9 | Aísla un desacuerdo entre lectura y mensaje revisando etapas y prueba su corrección. |
| 9–10,0 | Compara una alternativa de sensor y argumenta límites de precisión, escala y transmisión sin inventar calibración. |
CYR.3.2.2 Eventos de la app y contrato de respuesta
Entender el funcionamiento interno de las aplicaciones móviles y cómo se construyen, dando respuesta a las posibles demandas del escenario a resolver.
Evidencia. App editable, códigos de respuesta, lectura ausente o antigua y recuperación.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | La vista fabrica una lectura o confirma datos sin comprobar la respuesta del servicio. |
| 3–4,9 | Muestra un número, pero falla ante JSON inválido, ausencia o dato antiguo sin advertirlo. |
| 5–6,9 | La app consulta, valida código y contenido y muestra pendiente, sin dato, actualizado o antiguo según contrato. Explica eventos y almacenamiento utilizado. |
| 7–8,9 | Corrige un error de actualización o decodificación y verifica recuperación sin ocultar el último estado conocido. |
| 9–10,0 | Adapta la interfaz a otra respuesta y prueba una secuencia con retraso o reinicio manteniendo coherencia de estados. |
CYR.3.2.3 Solución móvil a fallos de comunicación
Conocer y resolver la variedad de problemas posibles desarrollando una aplicación móvil y generalizando las soluciones.
Evidencia. Panel y cinco casos de aceptación con fallos de conexión y recuperación.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | El panel no responde al escenario ni explica diferencias entre sus fallos. |
| 3–4,9 | Resuelve consulta normal, pero la respuesta a fallos oculta el problema o altera datos válidos. |
| 5–6,9 | Resuelve necesidad móvil, prueba cinco casos y pérdida y recuperación y justifica las respuestas y límites del servicio local. |
| 7–8,9 | Adapta una solución a otro fallo y demuestra que conserva último dato válido y aviso de antigüedad. |
| 9–10,0 | Resuelve un caso nuevo de dependencia y generaliza una estrategia de consulta y recuperación con pruebas. |
CYR.3.3.1 Estación IoT con interacción física
Ser capaz de construir un sistema de computación o robótico, promoviendo la interacción con el mundo físico en el contexto de un problema del mundo real, de forma sostenible.
Evidencia. Estación física, servicio y app integrados con prueba de desconexión y recuperación.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No hay recorrido físico completo verificable o se afirma funcionamiento del sensor con datos solo simulados. |
| 3–4,9 | Hay comunicación parcial, pero no puede comprobar el origen físico o la recuperación del sistema. |
| 5–6,9 | Integra lectura física, envío, servicio y app, demuestra desconexión y recuperación y explica utilidad, recursos y límites. |
| 7–8,9 | Mejora una dependencia o presentación a partir de un ensayo y verifica el recorrido completo. |
| 9–10,0 | Contrasta otra condición o arquitectura y justifica utilidad, mantenimiento y recursos con evidencias del prototipo. |
CYR.3.6.4 Acceso, secretos y protección del servicio
Conocer las estrategias de ciberseguridad que garantizan protección a los usuarios de Internet.
Evidencia. Pruebas 401 y rechazo, entrega sin secretos y recuperación de archivos.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Publica secretos o presenta el prototipo HTTP local como servicio público protegido completamente. |
| 3–4,9 | El token funciona en un caso, pero no prueba rechazo o no verifica qué contienen los archivos entregados. |
| 5–6,9 | Demuestra acceso y rechazo, excluye secretos, recupera un archivo y explica límites del servicio local y de HTTP sin cifrar. |
| 7–8,9 | Revisa también capturas y configuración y contrasta el rechazo sin pérdida del último dato válido. |
| 9–10,0 | Resuelve un caso nuevo de exposición o pérdida y justifica controles activos y recuperación pasiva sin prometer seguridad absoluta. |
Vídeos y fuentes
The Internet: IP Addresses & DNS
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
The Internet: Packets, Routing & Reliability
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
Puedes aprender más
- Espressif: Wi-Fi API
- MIT App Inventor: Connectivity / Web
- MDN: HTTP response status codes
- AEPD e INCIBE: Privacidad y seguridad en Internet
Contenido revisado en octubre de 2026.