Un caso de uso con hardware y software: cómo detectar el problema real de un usuario, diseñar una red de sensores y construir el sistema que la gestiona.
Un proyecto de hardware y software también empieza con una persona concreta y un problema medible. Este es el nuestro.
Cuando el problema involucra el mundo físico (temperatura, humedad, luz, calidad del aire) la solución requiere dos capas: hardware que capture datos del entorno y software que los procese, muestre y use para tomar decisiones.
Ninguna de las dos capas es opcional. Un sistema de sensores sin interfaz es solo un aparato. Una app sin sensores propios no puede medir el ambiente real.
El equipo debe demostrar que entiende ambas capas y que la solución integra las dos de forma coherente con el problema del usuario.
Antes de elegir un microcontrolador o un sensor, el equipo debe entender qué necesita medir, dónde, con qué frecuencia y para qué. Eso solo se obtiene entrevistando al usuario.
Sensor incorrecto → dato incorrecto → decisión incorrecta.
Un proyecto de hardware requiere al menos dos entrevistas. La primera para conocer al usuario y su entorno. La segunda, ya con contexto, para profundizar en el problema y relevar los datos técnicos que definen el hardware.
Primera entrevista — Conocer al usuario y su entorno. El objetivo no es todavía levantar requerimientos técnicos. Es entender quién es Valeria, cómo trabaja, qué siente que está mal y cuál es el contexto general del estudio. Se usan los bloques A, B y C. Dura aproximadamente 30 minutos y permite al equipo llegar a la segunda entrevista con contexto real.
Segunda entrevista — Relevar el problema en profundidad. Con el contexto de la primera, el equipo puede hacer preguntas técnicas precisas: cuántos ambientes tiene, si la red WiFi llega a todos los sectores, qué restricciones de instalación hay. Se usan los bloques D, E, F y G. Esta entrevista produce los datos que definen el hardware.
Sin esta separación, el equipo llega a la primera reunión con preguntas que el usuario no puede responder porque aún no confía ni entiende para qué sirven.
El formulario tiene los mismos bloques que el caso Roberto (perfil, tecnología, problema, accesibilidad) más dos bloques nuevos exclusivos de proyectos físicos:
Bloque E — Entorno físico: relevamiento del espacio. Metros cuadrados, cantidad de ambientes, tipo de construcción, fuentes de calor artificiales.
Bloque F — Instalación: restricciones para montar el hardware. ¿Se puede agujerar paredes? ¿Hay tomacorrientes disponibles? ¿La red WiFi llega a todos los rincones?
Sin estos datos, el equipo no sabe si puede instalar un sensor o si va a necesitar una solución inalámbrica con batería.
Entrevistada: Valeria Gómez · Segunda entrevista (específica) · ~55 minutos
Suponemos que Valeria respondió. Ahora transformamos sus respuestas en la línea de base del proyecto, separamos síntomas de causas, y obtenemos las decisiones de hardware.
En un proyecto de hardware, hay un nivel extra de análisis: del síntoma se extrae la causa, y de la causa se determina qué variable medir y con qué sensor.
Ejemplo: "Huele a encierro" → causa: CO₂ elevado → variable: concentración de CO₂ → sensor: MQ-135 ubicado en la zona de mayor ocupación.
Sin este encadenamiento, el equipo elige sensores al azar y después descubre que no miden lo que el usuario necesita.
Espacio propio · 4 ambientes · Claro Fibra 600 MB — la red WiFi solo llega bien a la oficina central, no al resto · PC de escritorio como principal · Celular Samsung con SmartThings para consulta fuera del estudio · Tecnología: 3/5 · Quejas de temperatura: 3–4 veces por semana · Sin registro de consumo eléctrico · No conoce sistemas similares · Ambientes con temperatura variable entre sí · Puede perforar paredes · No hay servidor 24/7 (opción: cloud o Raspberry Pi) · Splits sin conectividad propia (candidatos a enchufe inteligente SmartThings) · Prefiere número actual + histórico · Dispuesta a pagar si se justifica el ahorro
4 nodos ESP32 (uno por ambiente) · Repetidor de red WiFi para extender cobertura al resto del estudio · Alimentación por USB desde tomacorriente · Enchufe inteligente SmartThings en el circuito de cada split (los equipos no tienen conectividad propia) · Backend en la nube o Raspberry Pi · Dashboard web responsive (desktop + mobile)
En un proyecto de hardware y software, los requerimientos abarcan cinco categorías: funcionales, no funcionales, hardware, software y las limitaciones explícitas de la entrega. Cada uno tiene su lugar en el documento.
RF Requerimiento Funcional: qué hace el sistema. "El nodo debe leer temperatura cada 30 segundos y enviarla al servidor."
RNF No Funcional: cómo lo hace. "El nodo debe reconectarse automáticamente si pierde señal de red sin reiniciarse."
RHW Hardware: características físicas. "El nodo debe montarse en pared con doble faz, máximo 10×8×4 cm."
ISW Interfaz de Software: componentes de software del sistema y cómo se articulan entre sí. "El backend expone una API REST que el dashboard React consume."
LIM Limitaciones: lo que el sistema explícitamente no va a hacer en esta entrega. Define el alcance hacia el usuario y evita expectativas incorrectas.
RF Sección 4.1 — Requerimientos funcionales
RHW Sección 4.3 — Interfaces de hardware + diseño 3D
ISW Sección 4.4 — Interfaces de software
RNF — firmware Sección 3.4.2 — Limitaciones de hardware
RNF — conectividad Sección 3.4.6 — Protocolos señalados
RNF — interfaz Sección 4.2 — Interfaces de usuario
LIM Sección 2.2 — Alcance del sistema
Un usuario que no sabe qué no hace el sistema asume que lo hace todo. Cuando descubre que no, lo vive como una promesa incumplida.
Documentar las limitaciones no es admitir debilidad del proyecto: es establecer un contrato claro de alcance que protege al equipo y genera confianza en el usuario.
Las limitaciones de esta entrega pueden convertirse en la sección 3.6 — Evolución previsible del sistema (funcionalidades para versiones futuras).
| ID | Nombre | Prioridad | Origen |
|---|---|---|---|
RF01 | Dashboard en tiempo real por ambiente Muestra temperatura, humedad, CO₂ y luminosidad actuales de cada sector en una pantalla única. | Alta | "No sé si está bien hasta que alguien se queja" |
RF02 | Historial de lecturas con gráfico temporal El usuario puede ver la evolución de cualquier variable en cualquier rango de fechas. | Alta | Bloque G: "Quiero número actual + histórico" |
RF03 | Alertas automáticas por umbral Email o notificación push si temperatura, CO₂ o humedad superan los valores configurados. | Alta | Bloque D: "Me interesa recibir alertas" + CO₂ en oficina del fondo |
RF04HW | Alerta de equipo encendido sin ocupación + apagado remoto vía SmartThings Si el PIR detecta que no hay personas y hay consumo activo, se genera una alerta. El usuario puede apagar el equipo remotamente desde la app Samsung SmartThings en su celular, sin necesidad de ir al lugar. | Alta | S2: splits viejos sin conectividad propia → enchufe inteligente SmartThings |
RF05HW | Reporte mensual de consumo eléctrico por sector | Media | "La factura subió mucho" + sensor SCT-013 |
RF06 | Dos perfiles de usuario: administradora y empleado Valeria: acceso total. Empleados: solo visualización, sin modificar umbrales. | Alta | Bloque D: "Solo yo debería poder cambiar los umbrales" |
RF07 | Configuración de umbrales desde el dashboard | Media | Bloque D: "¿quién puede modificar los umbrales?" |
RF08 | Vista resumen para celular (acceso fuera del estudio) | Media | Bloque B: "Celular para cuando estoy fuera" |
| ID | Nombre | Categoría | Origen |
|---|---|---|---|
RNF01 | El nodo ESP32 debe reconectarse automáticamente si pierde la señal de la red WiFi Sin reiniciar ni perder lecturas; reintentar cada 30 segundos. | Firmware | Posibles cortes de corriente → se asume posible pérdida de señal de red |
RNF02 | El sistema debe funcionar con latencia menor a 5 segundos entre lectura y visualización | Rendimiento | RF03: alerta en tiempo real no tiene sentido con demoras de minutos |
RNF03 | El dashboard debe ser accesible desde PC y celular sin instalar ninguna app | Usabilidad | Bloque B: "PC + celular" como dispositivos principales |
RNF04 | Interfaz sin jerga técnica — estado del ambiente en lenguaje natural Ejemplo: "Temperatura OK", "CO₂ elevado — ventile la sala", no valores crudos sin contexto. | Usabilidad / HCI | Bloque B: comodidad tecnológica 3/5 |
RNF05 | Protocolo de comunicación: MQTT entre nodo y servidor | Protocolos | Sección 3.4.6 del documento — MQTT es el estándar para IoT de bajo consumo |
RNF06 | Los datos deben almacenarse con fecha, hora y sector de origen | Datos | RF02: historial temporal requiere timestamp en cada lectura |
| ID | Nombre | Prioridad | Origen |
|---|---|---|---|
RHW01 | El nodo debe ser compacto y montable en pared con doble faz o tornillo Dimensiones máximas aprox. 10×8×4 cm. Sin cables visibles colgando. | Alta | Bloque F: "el estudio es de atención a clientes, el aspecto importa" |
RHW02 | Alimentación por cable USB-C desde tomacorriente — sin batería Hay toma disponible en todos los ambientes. Evita recarga periódica. | Alta | Bloque F: "Hay tomacorrientes en todos los ambientes" |
RHW03 | El sensor de temperatura debe ubicarse lejos de fuentes de calor artificial Mínimo 50 cm de impresoras, y alejado de ventanas con sol directo. | Alta | Bloque E: "hay impresoras láser en recepción y en la sala de reuniones" |
RHW04 | El diseño 3D del nodo debe incluir tapa con ventilación para el sensor MQ-135 El sensor de CO₂ necesita contacto con el aire. La carcasa no puede ser hermética. | Media | Restricción técnica del sensor MQ-135 — sección 4.3.1 |
RHW05 | El nodo debe incluir LED de estado visible (verde: OK / rojo: error) | Baja | HCI: Valeria o un empleado debe poder saber si el nodo funciona sin abrir el dashboard |
RHW06 | Instalación de repetidor de red WiFi antes del despliegue de los nodos La red WiFi actual solo cubre la oficina central (donde está el router). Los demás ambientes no tienen señal suficiente para que los ESP32 se conecten. El repetidor (access point o mesh) es un prerequisito de infraestructura que debe resolverse en la etapa de instalación. | Alta | Bloque B: "La red WiFi no llega a los demás ambientes" — Claro Fibra 600 MB con router en oficina central |
RHW07 | Enchufe inteligente compatible con SmartThings en el circuito de cada split Los equipos de climatización son viejos y no tienen conectividad propia. El enchufe inteligente (por ejemplo: Samsung SmartThings Plug o compatible Zigbee/Z-Wave) se incorpora entre el tomacorriente y el split, permitiendo a Valeria y empleados apagarlo remotamente desde la app SmartThings en sus celulares Samsung. | Alta | S2: splits sin conectividad propia + Valeria y empleados usan Samsung con SmartThings |
| ID | Componente | Tecnología / Stack | Rol en el sistema |
|---|---|---|---|
ISW01 |
Firmware del nodo Software que corre en cada ESP32. Responsable de leer los sensores, gestionar la conexión de red y publicar datos. |
C++ / Arduino Framework Bibliotecas: DHT, PubSubClient (MQTT), ArduinoJSON, WiFiManager |
Capa de adquisición de datos. Lee sensores cada intervalo configurado y publica en el topic MQTT correspondiente al ambiente. |
ISW02 |
Broker MQTT Intermediario de mensajería entre los nodos ESP32 y el backend. Recibe publicaciones de los nodos y las distribuye a los suscriptores. |
Mosquitto (Eclipse) Protocolo MQTT 3.1.1 · Puerto 1883 (o 8883 con TLS) |
Desacopla los nodos del backend. Si el backend cae temporalmente, los mensajes se pueden retener. Se puede alojar en la misma instancia cloud que el backend. |
ISW03 |
Backend / API REST Servidor que suscribe al broker MQTT, persiste las lecturas en la base de datos, y expone los datos al dashboard a través de una API REST. |
Node.js + Express ORM/Query: Prisma o pg directo · Autenticación: JWT |
Capa de lógica de negocio. Evalúa si una lectura supera un umbral y dispara alertas. Expone endpoints GET/POST para el dashboard y futuros clientes. |
ISW04 |
Base de datos Almacena las lecturas de los sensores con marca temporal, el sector de origen, los umbrales configurados y los usuarios del sistema. |
PostgreSQL (datos relacionales) Opcional: TimescaleDB (extensión para series temporales) si el volumen de lecturas es alto |
Persistencia central del sistema. El historial de lecturas (RF02) y los reportes de consumo (RF05) dependen directamente de la integridad de esta capa. |
ISW05 |
Dashboard web (Frontend) Interfaz gráfica que consume la API REST del backend. Muestra datos en tiempo real, historial, alertas activas y configuración de umbrales. |
React + Vite Gráficos: Recharts o Chart.js · Estilos: Tailwind CSS · Responsive (desktop + mobile) |
Capa de presentación. Es el único punto de contacto de Valeria y los empleados con el sistema. Diseñada en Figma antes de programarse (sección 4.2.1). |
ISW06 |
Integración Samsung SmartThings El backend se conecta a la API de Samsung SmartThings para enviar comandos de encendido/apagado a los enchufes inteligentes cuando el sistema detecta una anomalía. |
SmartThings REST API (Samsung) Autenticación: OAuth 2.0 · Endpoint: api.smartthings.com/v1/devices/{id}/commands |
Permite que el sistema no solo detecte que un split está encendido sin nadie, sino que lo apague automáticamente o le avise a Valeria para que lo haga desde su celular. |
ISW07 |
Servicio de alertas Módulo del backend que evalúa las lecturas contra los umbrales configurados y dispara notificaciones al canal definido por el usuario administrador. |
Nodemailer (email) y/o OneSignal (push) Canal a confirmar en entrevista — Valeria mencionó preferir notificaciones en el celular |
Implementa RF03. No requiere que Valeria tenga el dashboard abierto para recibir alertas. Se ejecuta como proceso background en el servidor. |
| ID | Qué NO hace el sistema en esta entrega | Por qué | ¿Versión futura? |
|---|---|---|---|
LIM01 |
No controla los splits automáticamente sin intervención humana El sistema detecta que un ambiente está vacío y el split encendido, y alerta a Valeria. Ella decide si lo apaga desde SmartThings. El apagado automático sin confirmación no está incluido en esta versión. |
Un apagado automático incorrecto (por ejemplo, si el PIR falla y no detecta a alguien que está quieto) puede generar problemas graves. Se necesita validación en campo antes de automatizar esta acción. | Sí — v2 puede incluir reglas de apagado automático con confirmación configurable y período de gracia. |
LIM02 |
No gestiona el sistema de ventilación ni abre/cierra ventanas El sensor MQ-135 detecta CO₂ elevado y lanza una alerta. El equipo no controla ningún actuador de ventilación en esta entrega. |
La oficina no cuenta con un sistema de ventilación motorizado. Instalar actuadores requeriría una obra adicional fuera del alcance del proyecto. | Sí — v2 podría integrar un extractor de techo inteligente compatible con SmartThings si el estudio lo instala. |
LIM03 |
No incluye acceso a los datos desde fuera de la red local sin configurar el backend en la nube Si el equipo decide alojar el backend en una Raspberry Pi local en lugar de un servicio cloud, el dashboard solo será accesible dentro del estudio. El acceso remoto desde el celular de Valeria requiere una solución cloud. |
El costo de un servicio cloud (AWS, Railway, Render, etc.) es parte de la oferta económica. Si el presupuesto no lo permite, el sistema funciona solo en red local. Es una decisión que debe tomarse con Valeria. | Sí — migración a cloud es un upgrade directo sin cambios en el código. |
LIM04 |
No incluye aplicación móvil nativa (iOS o Android) El acceso desde el celular se hace a través del navegador web del celular, no de una app descargada desde la tienda. |
Desarrollar una app nativa duplica el tiempo de desarrollo y requiere cuentas de desarrollador en App Store / Play Store. El dashboard web responsive es funcionalmente equivalente para el uso de Valeria. | Sí — v3 podría publicarse como PWA (Progressive Web App) que se instala en el celular sin tienda. |
LIM05 |
No mide la calidad del aire con precisión de laboratorio El sensor MQ-135 es un sensor de bajo costo que detecta tendencias de CO₂ y gases, pero no es un instrumento calibrado. Los valores son orientativos, no certificados. |
Para un estudio contable el objetivo es detectar cuándo el ambiente se deteriora, no medir con precisión analítica. Si se requiriera certificación, sería necesario un sensor industrial de otro orden de precio. | Sí — v2 puede incorporar sensor SCD40 (CO₂ real, NDIR) para mayor precisión si el usuario lo requiere. |
LIM06 |
No incluye mantenimiento del hardware post-entrega El proyecto contempla la instalación, puesta en marcha y documentación. El mantenimiento correctivo de los nodos (reemplazo de sensor dañado, actualización de firmware) no está incluido en el alcance de esta entrega. |
El alcance del proyecto es académico. Un contrato de mantenimiento requeriría negociación separada si el proyecto se comercializa. | Sí — puede formalizarse como acuerdo de soporte técnico anual. |
LIM07 |
No integra con el sistema de facturación ni con el software de gestión contable del estudio SensorOffice es un sistema de monitoreo ambiental independiente. No se conecta a ningún software contable, ERP ni sistema interno del estudio. |
No fue solicitado por Valeria y está fuera del alcance funcional del proyecto. | No aplica. |
Los OKRs de este proyecto tienen una dimensión extra: medir el impacto en el mundo físico. No solo "cuántos usuarios tiene el sistema" sino "cuánto bajó el consumo eléctrico".
Un proyecto de software mide su éxito con métricas digitales: tiempo de respuesta, usuarios activos, errores en producción. Un proyecto con hardware debe medir también el impacto en el mundo físico.
En este caso: ¿cuánto bajaron las quejas de temperatura? ¿Cuánto bajó la factura de luz? ¿El CO₂ se detecta antes de que alguien lo note?
Esas métricas físicas son el KR más valioso de este tipo de proyecto.
En la presentación final (E06), el equipo debe mostrar datos reales de la línea de base comparados con los KR alcanzados. No alcanza con que el sistema funcione: tiene que demostrar que el problema de Valeria se resolvió.
En este proyecto hay tres perfiles: la administradora (cliente principal), los empleados (usuarios frecuentes) y el técnico instalador (usuario interno del equipo).
En proyectos de hardware existe un perfil que los proyectos de software no tienen: la persona que instala y configura el dispositivo en el campo.
En este caso, ese perfil es uno o dos integrantes del equipo de 7mo. Sus necesidades condicionan cómo se diseña el proceso de configuración del nodo: ¿necesita una app para configurar la red WiFi? ¿Un portal web de setup? ¿Configuración por Bluetooth?
Si no se diseña bien la experiencia del instalador, cada nodo puede tardar horas en configurar en el campo.