Caso Real: Sistema IoT con ESP32 y Sensores en Dolibarr

TL;DR

La empresa necesitaba monitorizar temperatura y humedad en tiempo real en varios puntos. Diseñé un sistema híbrido: sensores DIY con ESP32 (coste < 10€/punto) para zonas con WiFi, y sensores Ubibot para zonas sin red. Firmware propio con control de errores, API REST segura y dashboards integrados en Dolibarr. 12+ meses en producción sin fallos críticos.

<video src=“/videos/sensor.mp4” controls muted playsinline class=“w-full rounded-xl my-6 shadow-lg” style=“max-height: 480px; object-fit: cover;”

Tu navegador no soporta vídeo HTML5.

---

El problema de la empresa

La empresa tenía requisitos de control ambiental en varias zonas pero:

• Mediciones manuales — alguien iba con un termómetro y apuntaba en un Excel
• Sin alertas — si la temperatura subía de noche, nadie se enteraba hasta la mañana
• Sin histórico fiable — el Excel tenía huecos, errores de lectura y datos perdidos
• Soluciones comerciales caras — un sistema de monitorización profesional cotizado en 3.000-5.000€

Lo que me pidieron: “Queremos ver la temperatura en la pantalla del ordenador y que nos avise si algo va mal. Y que no cueste una fortuna.”

---

Decisión 1: Sistema híbrido (DIY + comercial)

No todas las zonas eran iguales. Algunas tenían WiFi y enchufe cerca, otras no. En vez de forzar una solución única, diseñé un sistema híbrido:

Sensores DIY (ESP32/ESP8266)

Para zonas con WiFi y alimentación:

Componente	Precio	Función
ESP32 DevKit	5€	Microcontrolador con WiFi
DHT22	3€	Temperatura + humedad (±0.5°C)
SHT31	6€	Alta precisión (±0.3°C) para zonas críticas
DS18B20	2€	Solo temperatura, impermeable
Fuente 5V USB	3€	Alimentación
Total por punto	~10€

Sensores comerciales Ubibot

Para zonas sin WiFi o donde no se podía cablear:

• Ubibot WS1: sensor autónomo con SIM 4G integrada
• Coste: ~120€/unidad + datos móviles
• Ventaja: funciona sin infraestructura, batería de 6 meses

La integración

Zona con WiFi:                    Zona sin WiFi:
┌──────────┐                      ┌──────────┐
│ ESP32 +  │──WiFi──▶ API REST    │ Ubibot   │──4G──▶ Ubibot Cloud
│ DHT22    │         propia       │ WS1      │         │
└──────────┘           │          └──────────┘         │
                       │                               │
                       ▼                               ▼
                  ┌──────────────────────────────────────┐
                  │         Dolibarr ERP — Módulo IoT     │
                  │  · Dashboard tiempo real              │
                  │  · Alertas automáticas                │
                  │  · Histórico + gráficas               │
                  └──────────────────────────────────────┘

Las dos fuentes de datos (propia y Ubibot API) se unifican en Dolibarr. El usuario ve todos los sensores en el mismo dashboard, sin saber cuál es DIY y cuál comercial.

---

Decisión 2: Firmware probusto (no un sketch de ejemplo)

Los tutoriales de Arduino muestran un loop() de 10 líneas que lee un sensor y lo imprime por serial. En producción, eso falla en 48 horas.

Lo que puede salir mal (y sale)

• WiFi se desconecta → el ESP se queda enviando al vacío
• El sensor devuelve NaN → se envía basura
• El servidor no responde → el HTTP request se cuelga
• El ESP pierde alimentación → al reiniciar, no reconecta

Mi firmware real

#include <WiFi.h>
#include <HTTPClient.h>
#include <DHT.h>

#define DHT_PIN 4
#define SENSOR_TYPE DHT22
#define READ_INTERVAL 60000   // 1 lectura/minuto
#define MAX_RETRIES 3
#define WIFI_TIMEOUT 10000

DHT dht(DHT_PIN, SENSOR_TYPE);

void setup() {
  Serial.begin(115200);
  dht.begin();
  connectWiFi();
}

void loop() {
  // Verificar WiFi antes de leer
  if (WiFi.status() != WL_CONNECTED) {
    connectWiFi();
  }

  float temp = dht.readTemperature();
  float hum = dht.readHumidity();

  // Validar lectura (descartar NaN y valores imposibles)
  if (isnan(temp) || isnan(hum) || temp < -40 || temp > 80) {
    Serial.println("Lectura inválida, reintentando...");
    delay(2000);
    return;
  }

  // Enviar con reintentos
  bool sent = false;
  for (int i = 0; i < MAX_RETRIES && !sent; i++) {
    sent = sendData(temp, hum);
    if (!sent) delay(5000);
  }

  delay(READ_INTERVAL);
}

void connectWiFi() {
  WiFi.begin(SSID, PASSWORD);
  unsigned long start = millis();
  while (WiFi.status() != WL_CONNECTED) {
    if (millis() - start > WIFI_TIMEOUT) {
      ESP.restart();  // Reinicio forzado si no conecta
      return;
    }
    delay(500);
  }
}

bool sendData(float temp, float hum) {
  HTTPClient http;
  http.setTimeout(10000);
  http.begin(API_URL);
  http.addHeader("Authorization", "Bearer " + String(API_TOKEN));
  http.addHeader("Content-Type", "application/json");

  String payload = "{\"temperature\":" + String(temp, 1) 
                 + ",\"humidity\":" + String(hum, 1) 
                 + ",\"device_id\":\"" + DEVICE_ID + "\"}";

  int code = http.POST(payload);
  http.end();
  return (code == 200 || code == 201);
}

Diferencias con un sketch tutorial:

• Reconexión WiFi automática con timeout
• Reinicio del ESP si no reconecta (watchdog casero)
• Validación de lecturas (descarta NaN y valores fuera de rango)
• Reintentos con backoff en el envío HTTP
• Autenticación JWT en cada petición
• Timeout en las peticiones HTTP (evita cuelgues)

---

Decisión 3: API REST segura

El ESP32 envía datos por HTTP. Esa API necesita:

1. Autenticación: token JWT por dispositivo (un token robado no da acceso a nada más)
2. Validación server-side: rango de temperatura, frecuencia de envío, device_id registrado
3. HTTPS obligatorio: SSL/TLS en el servidor para cifrar los datos en tránsito
4. Rate limiting: máximo 1 lectura/minuto por dispositivo (evita floods por bug en firmware)

// Endpoint PHP en Dolibarr
function receiveSensorData($request) {
    // 1. Verificar token JWT
    $device = $this->validateDeviceToken($request->getHeader('Authorization'));
    if (!$device) return $this->unauthorized();

    // 2. Validar datos
    $temp = floatval($request->getParam('temperature'));
    $hum = floatval($request->getParam('humidity'));
    if ($temp < -40 || $temp > 80 || $hum < 0 || $hum > 100) {
        return $this->badRequest('Valores fuera de rango');
    }

    // 3. Guardar en BD
    $this->db->insert('iot_readings', [
        'device_id' => $device->id,
        'temperature' => $temp,
        'humidity' => $hum,
        'timestamp' => date('Y-m-d H:i:s'),
    ]);

    // 4. Verificar alertas
    $this->checkAlerts($device, $temp, $hum);

    return $this->ok();
}

---

Decisión 4: Integración Ubibot

Los sensores Ubibot envían datos a su nube. Para integrarlos en Dolibarr sin depender de su interfaz web:

1. CRON job cada 5 minutos consulta la API de Ubibot
2. Descarga las últimas lecturas de cada sensor
3. Las normaliza al mismo formato que los sensores DIY
4. Las guarda en la misma tabla iot_readings

Resultado: en el dashboard de Dolibarr, un sensor Ubibot y un ESP32 se ven exactamente igual. El usuario no necesita saber la diferencia.

---

Dashboard en Dolibarr

Funcionalidad	Detalle
Vista en tiempo real	Temperatura y humedad actuales de todos los puntos
Gráficas históricas	Chart.js con rango de fechas seleccionable
Alertas automáticas	Email cuando temperatura > umbral configurado
Estado de sensores	Verde (OK), naranja (lectura antigua), rojo (sin datos)
Exportación	CSV para auditorías y reporting
Configuración	Umbrales, intervalos y destinatarios de alertas por sensor

---

Lo que consiguió la empresa

Antes	Después
Mediciones manuales con termómetro	Monitorización automática 24/7
Excel con huecos y errores	Histórico continuo y fiable
Sin alertas	Notificación inmediata por email
Presupuesto rechazado (3.000-5.000€)	Coste total: ~200€ (hardware + servidor existente)
Datos en papel	Dashboard en tiempo real integrado en el ERP
1 zona monitorizada (la fácil)	Todas las zonas cubiertas (WiFi + 4G)

Ahorro: el sistema DIY costó un 95% menos que la solución comercial cotizada. Y lleva 12+ meses funcionando.

---

Lo que aprendí

1. Híbrido > purista — usar solo DIY o solo comercial habría dejado zonas sin cubrir o habría costado 10x más.
2. El firmware es lo que separa un prototipo de un producto — reconexión, validación, reintentos y watchdog son obligatorios.
3. JWT por dispositivo — si roban un token (acceso físico al ESP), solo comprometes ese sensor.
4. Los sensores mienten — el DHT22 ocasionalmente devuelve NaN o valores absurdos. Sin validación, contaminas la BD.
5. CRON + API externa funciona bien para integrar servicios de terceros sin acoplamiento.

---

¿Tu empresa necesita monitorización IoT?

Si necesitas controlar temperatura, humedad, o cualquier variable ambiental integrada con tu sistema de gestión, hablemos.

Más casos reales:

• Cómo construí un SaaS multitenant con NestJS y React
• Sistema GPS de flota con Traccar y Leaflet
• Módulo de comisiones automáticas para Dolibarr ERP
• Ecosistema IA para reuniones con Gemini y Supabase