IoT
El sensor funcionaba. Lo difícil era decidir qué hacer con la alerta.
2 min de lectura
Conectar un sensor y ver un número en una pantalla se siente como haber terminado.
En muchos proyectos apenas es el principio.
Un dato tiene valor cuando cambia una decisión: apagar algo, avisarle a alguien, detener un proceso, registrar una incidencia o simplemente guardar evidencia para revisarla después.
Medir no es lo mismo que vigilar
Supongamos que quieres conocer una temperatura. El sensor puede reportarla cada minuto sin fallar y aun así el sistema ser inútil.
Falta decidir qué rango importa, cuánto tiempo debe mantenerse fuera de ese rango, quién recibe la alerta y qué pasa si nadie responde.
También hay preguntas menos bonitas: ¿qué ocurre si se cae internet?, ¿cómo sabemos si el sensor dejó de reportar?, ¿un valor imposible se guarda o se descarta?, ¿cuánto historial necesitamos?
Una alerta que grita por todo termina ignorada
Si cada variación dispara una notificación, muy pronto nadie le presta atención.
El software alrededor del sensor tiene que distinguir entre dato, evento y problema. A veces importa un umbral; otras veces importa cuánto duró, la velocidad del cambio o que un equipo dejó de enviar información.
Ese contexto normalmente vale más que el hardware.
El mundo físico falla diferente
En software podemos reintentar una petición. En campo hay energía, señal, humedad, distancia, cables, baterías y personas desconectando cosas porque necesitaban el contacto.
Por eso un proyecto de IoT no debería diseñarse como si el dispositivo viviera dentro de un diagrama perfecto.
Hay que pensar qué pasa cuando algo se cae y cómo vuelve sin perder la historia.
El objetivo no es tener sensores
Es saber algo a tiempo para poder actuar.
Si el proyecto termina en una gráfica bonita que nadie revisa, medimos mucho y resolvimos poco.
Para nosotros, la pregunta importante no es “¿qué sensor ponemos?”. Es: cuando este dato cambie, ¿qué debería pasar después?