5Tech Edge Bridge (ESP32) — MVP de la Fase 1

Ficha técnica · esp32-edge-bridge-datasheet · Borrador de revisión (preliminar) · 2026-07-08

PRELIMINAR. Esta ficha técnica describe un MVP de la Fase 1 construido sobre una placa de desarrollo ESP32 estándar. Es un prototipo de monitoreo y automatización, no un producto terminado ni certificado. Las constantes verificadas por firmware (pines, UUID de BLE, temas MQTT, temporización, umbrales) se toman directamente del firmware distribuido y se indican tal cual. Los valores marcados con ‡ son marcadores de posición de ingeniería propuestos, de clase ESP32-WROOM-32, dados con la condición bajo la cual deben confirmarse — no están medidos, no son finales, y ningún valor ‡ es una declaración de certificación. Los valores marcados con [TBD] siguen pendientes. Las certificaciones son n/a — prototipo de desarrollo. Véase §12 para el control de cambios.

Figura FIG-001 — 5Tech Edge Bridge, el MVP de la Fase 1 sobre una placa de desarrollo ESP32.

---

1. De un vistazo

El 5Tech Edge Bridge es el MVP de la Fase 1 de la pila 5Tech: firmware sobre una placa de desarrollo ESP32 estándar que conecta sensores, señales de máquina y eventos de prueba con sistemas de automatización por Wi-Fi, Bluetooth LE y MQTT. La Fase 1 valida la canalización completa de sensor a automatización para que la Fase 2 pueda convertir un diseño probado en una PCB personalizada.

Características principales

• Canalización completa de sensor a automatización sobre una placa de desarrollo ESP32 estándar — sin hardware personalizado.
• Tres transportes: Wi-Fi + MQTT, Bluetooth LE (funciona sin red) y una consola serie.
• JSON estructurado: telemetría cada 5 s, un latido de estado de 30 s, publicación inmediata de eventos, estado retenido + Last Will.
• Modelo de dispositivo de nueve estados con un modelo de peligro con enclavamiento WARNING / DANGER (solo limpieza explícita).
• Tres fuentes de entrada intercambiables: GPIO real, botón integrado y un sensor simulado.
• Dos variantes de firmware que hablan un protocolo de comunicación idéntico y verificado por paridad.

Aplicaciones típicas

• Validar la canalización MQTT + Bluetooth LE de extremo a extremo antes de comprometerse con una PCB.
• Demostraciones a clientes / inversores de la ruta de sensor a automatización.
• Pruebas de banco de la integración de automatización (n8n / Node-RED / personalizada).
• El diseño de referencia y la base de firmware a partir de los cuales se construye el hardware de producción de la Fase 2.

---

2. Contexto del sistema

Figura FIG-002 — Sense → Connect → Decide. El Edge Bridge es un prototipo de borde de un solo dispositivo: adquiere la señal de un dispositivo y publica hacia arriba el estado propio de ese dispositivo.

El Edge Bridge es un periférico BLE (un servidor GATT) que publica el estado de su propio y único dispositivo. Adquiere una señal, la resuelve a un estado, expone ese estado por Bluetooth LE y lo publica por MQTT. Arquitectónicamente pertenece al lado Sense, como un nodo de borde de adquisición y publicación — no es un agregador central de otros nodos.

• Sense — un sensor GPIO real, el botón integrado, un sensor simulado o un comando remoto (BLE / MQTT / serie) indica una condición en este único dispositivo.
• Connect (transporte) — el ESP32 resuelve su estado, construye una carga útil JSON y la publica por Wi-Fi a un broker MQTT; un servidor GATT Bluetooth LE expone las características propias de este dispositivo (Det1, Det2, Con1, Cmd, Resp) para control local que sobrevive a una red caída.
• Decide — un flujo de automatización (n8n / Node-RED / personalizado) se suscribe, filtra y enruta el mensaje a paneles, alertas y registros.

Límite del producto frente al Sensorium™ Gateway. Este prototipo es un periférico BLE que sirve el estado propio de un único dispositivo; no agrega otros nodos BLE. El rol Connect de agregación central — un central BLE que recopila muchos nodos Sensorium™ y los reenvía aguas arriba — pertenece al Sensorium™ Gateway, un producto aparte. Lo que el Edge Bridge valida son los patrones de adquisición de borde y publicación MQTT (identidad del dispositivo, el modelo de estados, cargas útiles JSON, estado retenido + Last Will y manejo de comandos) — no la lógica de agregación del Gateway.

---

3. Descripción funcional

Figura FIG-003 — Bloques funcionales: fuentes de entrada, el núcleo de decisión compartido, tres transportes y E/S local.

El firmware se organiza en cuatro grupos funcionales:

1. Fuentes de entrada — las entradas digitales Det1 (GPIO18) y Det2 (GPIO19), el botón integrado (GPIO0) y un sensor simulado (un paseo aleatorio acotado), además de comandos remotos por cualquier transporte. Cualquier fuente puede alimentar la canalización; ninguna es necesaria para ejecutar la demo.
2. Núcleo de decisión compartido — un detector de eventos (NORMAL < WARNING < DANGER, con enclavamiento) y un modelo de dispositivo de nueve estados resuelto en prioridad estricta. Este núcleo se compila textualmente en ambas variantes de firmware, de modo que su lógica no puede divergir.
3. Comunicación — un cliente Wi-Fi estación + MQTT, un servidor GATT Bluetooth LE y una consola serie. Los comandos entrantes de las tres se ponen en cola y se ejecutan en el bucle principal.
4. E/S local — un LED de estado con un patrón de parpadeo por estado (GPIO2), un zumbador opcional (GPIO25, deshabilitado de forma predeterminada) y la salida de contacto Con1 (GPIO23).

Ruta de datos: entrada → detector de eventos → estado del dispositivo → carga útil JSON → MQTT / BLE / serie → automatización. Los comandos recorren la ruta inversa y se ponen en cola, nunca se ejecutan en una tarea de callback de radio, de modo que una respuesta QoS 1 no puede bloquearse contra la tarea que debe confirmarla.

---

4. Información de pedido

El Edge Bridge es un MVP de la Fase 1, no un producto comercial; no hay códigos de pedido. Se ensambla a partir de piezas estándar:

Los códigos de pedido del hardware de producción de la Fase 2 (PCB personalizada + carcasa) son [TBD] y no se comprometen hasta que la Fase 1 congele los requisitos de sensor, conector, alimentación y carcasa.

---

5. Especificaciones mecánicas

No hay carcasa personalizada ni diseño mecánico en la Fase 1 — el MVP es una placa de desarrollo desnuda. Una PCB y una carcasa personalizadas son trabajo de la Fase 2.

---

6. Especificaciones eléctricas

Preliminar. El comportamiento verificado por firmware (niveles lógicos, la suposición de sensor activo en bajo, el pin Con1) se toma directamente del firmware distribuido y no lleva marca. Los valores marcados con ‡ son cifras propuestas de clase ESP32-WROOM-32, indicadas con su condición y aún no medidas; se confirman por medición durante la Fase 1. [TBD] marca un valor todavía pendiente.

AVISO. Los pines GPIO son de lógica de 3.3 V y no toleran 5 V. No conecte a una entrada GPIO un sensor o señal que supere 3.3 V sin el acondicionamiento de nivel adecuado.

AVISO — Con1 es un pin de nivel lógico, no un controlador de relé. Con1 (GPIO23) es una salida GPIO de 3.3 V simple. Para conmutar un relé, un contactor o cualquier carga inductiva o de red eléctrica necesita un controlador externo (una etapa de transistor / MOSFET o un módulo de relé optoaislado), un diodo de retorno / de rueda libre (flyback / free-wheeling) en paralelo con cualquier carga inductiva y un aislamiento eléctrico adecuado. No conmute tal carga directamente desde el pin.

AVISO — Sin protección de entrada (no industrial). La alimentación es una entrada USB 5 V simple sin protección contra polaridad inversa, sobretensión ni ESD en el conjunto, y las entradas GPIO / Det tampoco llevan protección añadida contra sobretensión ni ESD. Esta es una placa de desarrollo de banco, no una etapa de entrada de grado industrial; proporcione protección externa si el entorno de despliegue lo exige.

---

7. Interfaces y protocolos

Características GATT de BLE (todas bajo el UUID de servicio anterior):

Temas MQTT (raíz 5tech/iotbridge, <id> = 5tech-bridge-<mac6>):

Cadencia de publicación (verificada por firmware). La telemetría se publica cada 5 s (TELEMETRY_INTERVAL_MS = 5000); el estado se vuelve a publicar en cada cambio de estado y en un latido de 30 s (STATUS_INTERVAL_MS = 30000), de modo que un suscriptor tardío siempre ve un estado retenido en vivo; los eventos se publican de inmediato al cambiar. El keep-alive de MQTT es de 30 s (MQTT_KEEPALIVE_S = 30).

La variante Arduino / PlatformIO publica todos los temas con QoS 0 (su cliente MQTT no tiene parámetro de QoS); sus suscripciones y el Last Will siguen registrándose con QoS 1. Todos los temas, las claves de la carga útil y el orden de las claves son, por lo demás, idénticos byte a byte entre las dos variantes y se verifican por paridad en la compilación.

---

8. Especificaciones ambientales y clasificaciones

Esta es una placa de desarrollo desnuda sin sellado ni clasificación ambiental. Opérela en un banco en un entorno seco, interior y a temperatura ambiente.

---

9. Conformidad y normas

n/a — prototipo de desarrollo. Este dispositivo no posee certificaciones de producto, y ninguna se declara. El propio módulo ESP32-WROOM-32 lleva su propia aprobación de radio modular FCC / ISED (IC) / CE-RED, pero esa aprobación a nivel de módulo no se transfiere al prototipo ensamblado de la Fase 1, que no es un producto certificado y no debe representarse como tal. La certificación (radio/telecomunicaciones, EMC, seguridad, ambiental) es trabajo de la Fase 2, una vez que haya una placa de producción que certificar.

Este no es un dispositivo de seguridad. No lleva ninguna certificación de seguridad de ningún tipo y no debe utilizarse para proteger personas o equipos.

---

10. Accesorios y productos relacionados

Documentos relacionados

• Manual: manuals/esp32-edge-bridge-manual/ — puesta en marcha, flasheo, configuración, flujo de demo.
• Descripción del producto: products/esp32-edge-bridge/ — posicionamiento y aspectos destacados.
• Firmware y documentación de ingeniería completa: modules/5tech-edge-iot-bridge/ — arquitectura, API de MQTT, API de Bluetooth, alcance de la Fase 1 y la hoja de ruta de la PCB de la Fase 2.
• Hardware relacionado: el Sensorium™ Gateway — un producto aparte que desempeña el rol Connect de agregación central BLE (recopilando muchos nodos Sensorium™ aguas arriba). El Edge Bridge no implementa ni apunta a ese rol; valida los patrones de adquisición de borde y publicación MQTT en un único dispositivo (véase §2).

---

11. Comportamiento de señal y alertas

Figura FIG-004 — Ilustrativo — una señal monitoreada que cruza su umbral de alerta configurado (o una tendencia anómala) genera una alerta; una persona decide cualquier acción. Comportamiento representativo, no datos medidos.

El Edge Bridge informa una señal monitoreada y evalúa una regla simple; cuando una entrada cruza su umbral configurado (un estado DANGER) o muestra una tendencia anómala, genera una alerta y una persona decide cualquier acción. Es un prototipo que valida esta ruta —no realiza ninguna acción autónoma y no es un dispositivo de seguridad. El gráfico es ilustrativo; los umbrales se configuran por implementación ([TBD]).

Ejemplos de señales monitoreadas y disparadores de alerta

Ilustrativo — representativo, no medido; valores [TBD].

---

12. Revisión y control de cambios

Historial completo de cambios: revision.md. Fuentes y normas citadas: references.md.

---

Figuras

Las especificaciones son preliminares y están sujetas a cambios. Véase revision.md para el control de cambios, references.md para las fuentes e image_prompts.md para el índice de figuras/prompts.