Un inversor, un cargador de vehículos eléctricos o una bomba de calor que ya informa a su fabricante ofrece dos vías de acceso a sus datos. Puede consultar la API del fabricante o leer el dispositivo en la instalación mediante Modbus u otra interfaz local. Los contadores secundarios próximos suelen carecer de conexión a la nube, así que para ellos un Gateway local es la única vía. Tome la decisión por dispositivo, no para toda la instalación.
Algunas API de terceros agrupan las nubes de varios fabricantes. Ahorran trabajo de integración, pero interponen un segundo proveedor, con su propio intervalo y cuota, entre usted y los datos.
Comparación
| Pregunta | API en la nube del fabricante | Gateway local |
|---|---|---|
| ¿Qué puntos? | Los que el proveedor expone a su cuenta, a menudo menos de los disponibles en el dispositivo | Los que ofrece la interfaz local del dispositivo y el Gateway puede mapear |
| Intervalo | El intervalo de envío del dispositivo y la agregación del proveedor, limitados después por la cuota de llamadas | El intervalo de sondeo o información que configure, a menudo de 1 s a 1 min |
| Marca temporal | Hora de medición o de envío, según la API | Hora de sondeo, salvo que el dispositivo aporte su propia hora |
| Interrupción de internet | No llegan datos nuevos. El hueco solo se rellena después si el dispositivo conserva datos y la API ofrece historial | La recopilación, el historial local, los paneles y la automatización continúan. El envío externo se reanuda desde el búfer |
| ¿Qué equipos? | La gama de un fabricante o varias mediante un agregador | Cualquier dispositivo con una interfaz local admitida, en un modelo de datos que usted controla |
| En la instalación | Ningún equipo adicional | Un Gateway, su alimentación y una conexión de red |
| Trabajo continuo | Credenciales, renovación de tokens y cambios en la API del proveedor | Actualizaciones de software, copias de seguridad y reglas del cortafuegos |
| Control | Solo las órdenes que expone el proveedor, a través de sus servidores | Escrituras locales, con los límites y enclavamientos que configure |
Cuándo conviene una API en la nube
Una API en la nube es la vía más rápida cuando el equipo ya está conectado y la tarea es generar informes. Entonces, la cuota de llamadas determina la vigencia posible de los datos. Enlighten API v4 de Enphase permite 10 llamadas por minuto y 1.000 al mes en su plan gratuito Watt, 50.000 al mes en Kilowatt y 300.000 en Megawatt (planes para desarrolladores de Enphase). Una llamada por sistema cada 15 minutos equivale a 96 llamadas al día o unas 2.900 al mes. El plan gratuito no puede mantener esa frecuencia ni para un sistema. Cuarenta sistemas necesitan unas 117.000 llamadas al mes, por encima del límite de Kilowatt.
Esos mismos 40 sistemas solo necesitan 40 llamadas al día si la integración recoge cada noche los intervalos del día completo de un endpoint que los devuelve en una sola llamada. Un informe mensual de una cartera funciona bien así. Un panel que deba mostrar la última hora, no.
Compruebe estos puntos con una cuenta y un dispositivo reales, no con los ejemplos de la documentación:
- el intervalo que realmente devuelve la API para sus dispositivos y la cuota de su plan;
- hasta dónde llega el historial y si los intervalos perdidos aparecen más tarde;
- si cada marca temporal corresponde a la medición o al envío, y en qué zona horaria;
- cómo representa la API un dispositivo desconectado: un hueco, el último valor repetido o un cero;
- quién es responsable de la cuenta y cómo se transfiere el acceso cuando se vende la instalación o el activo;
- con cuánto aviso retira el proveedor un endpoint.
El último punto constituye un riesgo real. El 20 de febrero de 2026, Enphase anunció que retiraría nueve endpoints el 16 de marzo de 2026, 24 días después. A partir de esa fecha, las llamadas a ellos devuelven HTTP 401 (aviso de retirada de Enphase).
Cuándo conviene un Gateway local
Un Gateway local conviene cuando los dispositivos tienen interfaces locales y carecen de conexión a la nube. Un ejemplo es una instalación con 20 contadores secundarios Modbus RTU en un bus RS-485, una salida de impulsos en el contador de gas y un sistema de gestión de edificios BACnet/IP. Ninguno envía datos a un servicio externo. El Gateway los lee con el intervalo que configure, conserva el historial en la instalación y ejecuta la automatización sin ir y volver a un servidor.
Cuando lee usted mismo un dispositivo, también es responsable de mapear sus datos. Los errores más habituales están en los registros: un valor de 32 bits leído con sus dos palabras en el orden equivocado, un factor de escala aplicado dos veces o un registro de energía en Wh que el mapa declara en kWh. Cada uno produce un número verosímil, pero incorrecto. La guía de mapas de registros Modbus explica cómo comprobar cada punto con la pantalla del propio contador.
El Gateway es también un equipo que debe administrar. En la puesta en marcha, asigne a una persona la responsabilidad de las actualizaciones de software, las copias de seguridad y las reglas del cortafuegos. Un Gateway sin responsable no se actualiza.
Marcas temporales e intervalos de demanda
Un cargo por demanda en intervalos de 15 minutos se calcula a partir de la energía de cada intervalo; por eso la marca temporal decide a qué intervalo pertenece una lectura. Supongamos que un dispositivo conserva datos durante una interrupción de tres horas con una media de 400 kW y envía 1.200 kWh al restablecerse la conexión a las 14:07. Si la API o la plataforma asigna a esas lecturas la hora de envío, los 1.200 kWh caen en el intervalo de 14:00 a 14:15. Ese intervalo muestra entonces una demanda de 4.800 kW, doce veces el valor real.
La solución es conservar la hora de medición desde el dispositivo hasta la plataforma. Un sondeo local presenta una versión menor del mismo problema. El Gateway marca una lectura Modbus con la hora de sondeo, así que un registro del contador que se actualiza una vez por minuto puede llevar hasta un minuto de retraso cuando se lee. La guía de hora de origen y hora de llegada explica cómo especificar qué hora representa cada campo. La calculadora de demanda por intervalo muestra cómo un solo intervalo erróneo cambia el pico facturado.
Diseños híbridos
Una instalación suele utilizar ambas vías. Pensemos en una planta fotovoltaica de 250 kW cuyos inversores informan al portal del fabricante, un contador principal de importación y seis contadores secundarios Modbus, uno en el alimentador fotovoltaico. Dos reglas mantienen correcto el diseño.
La primera es una fuente por punto. En los 15 minutos anteriores a las 13:00, el contador del alimentador fotovoltaico lee 182 kW y la API del inversor informa de 185 kW. Son dos mediciones de un mismo flujo. Si suma ambas a la generación de la instalación, el informe muestra 367 kW procedentes de una planta de 250 kW. Utilice el contador del alimentador, cuya clase de exactitud conoce, y conserve el valor de la API para diagnosticar el inversor. No sustituya una lectura ausente del contador por el valor de la API sin marcarla como sustituida.
La segunda regla es un responsable por cada punto escribible. Una plataforma de flexibilidad despacha la batería de la instalación a través de la API del fabricante y fija la descarga en 0 kW para un evento de carga. Al mismo tiempo, una regla local para reducir picos ordena una descarga de 150 kW cuando la importación supera su límite. Ambas interfaces indican éxito. La consigna cambia cada vez que escribe uno de los sistemas y su tendencia dibuja dientes de sierra. Asigne la consigna a un solo sistema. El otro la lee o pide un cambio al responsable.
La guía de calidad de datos explica cómo marcar valores sustituidos y obsoletos.
Seguridad y acceso
Las dos vías sitúan la frontera de confianza en lugares distintos. Con una API en la nube, la credencial es el activo. Enlighten API v4 utiliza OAuth 2.0. El propietario del sistema aprueba la aplicación; el token de acceso dura un día y el de renovación, un mes (guía de inicio de Enphase). Si la integración no se renueva en ese mes, necesita otra autorización del propietario. Registre a nombre de qué cuenta está inscrito cada activo. Una venta de la instalación o un cambio de instalador pueden quitarle el acceso.
Con un Gateway, el activo es el dispositivo situado en su red de tecnología operativa (OT). No necesita un puerto abierto hacia internet, porque inicia una conexión saliente con la plataforma. NIST SP 800-82 Rev. 3, apartado 5.2.3.1, recomienda segmentar OT e IT, permitir conexiones solo entre zonas adyacentes y restringir las reglas salientes tanto como las entrantes. Para un Gateway, esto supone una lista de destinos permitidos reales: el broker o endpoint de la plataforma, los servidores horarios y el servicio de actualizaciones. Una regla general que permita todo el HTTPS saliente no es una lista de destinos permitidos.
Probar una interrupción
Antes de vincular toda una cartera a una de las vías, interrumpa la conexión a internet en una instalación piloto siguiendo un plan acordado. Desconecte el enlace WAN, no la alimentación del Gateway: un corte de energía prueba otro fallo. Mantenga la conexión interrumpida al menos dos horas. Así abarcará ocho intervalos de demanda de 15 minutos.
- Durante la interrupción, registre qué sigue funcionando en la instalación: lecturas, historial local, paneles y automatización.
- Registre cómo muestra la plataforma el periodo ausente: un hueco, un valor obsoleto mantenido sin cambios o ceros. Los ceros son el peor resultado, porque parecen lecturas reales.
- Restablezca la conexión y cuente lo recibido. Cincuenta puntos a intervalos de un minuto durante dos horas deberían producir 6.000 lecturas. Menos indica pérdidas; más, duplicados que la plataforma debe eliminar. MQTT QoS 1 ofrece entrega al menos una vez (MQTT 5.0, apartado 4.3.2), por lo que los duplicados tras una reconexión son un comportamiento normal, no un fallo.
- Compruebe que las lecturas recuperadas conservan su hora de medición y que ningún intervalo de demanda muestra un pico como el del ejemplo anterior.
- Para una API, compruebe si el proveedor rellena el hueco, cuánto tarda y si la integración vuelve a solicitar el periodo ausente.
La prueba se supera cuando el recuento es correcto, cada lectura conserva su marca temporal original y la plataforma nunca mostró ceros durante la interrupción. La lista de comprobación de puesta en marcha ofrece un registro para la prueba. La guía de almacenamiento y envío diferido explica cómo dimensionar el almacenamiento local para la interrupción máxima prevista.
Informar y controlar son funciones distintas
Una integración para informes necesita lecturas periódicas. Una integración de control necesita un ciclo de vida de las órdenes: caducidad, límites locales, comprobación por medición y una alternativa segura cuando falla el enlace. Una API en la nube no puede proporcionar esa alternativa, porque el enlace fallido es precisamente la ruta a la nube.
Una respuesta satisfactoria de la API significa que el proveedor aceptó la orden. Una respuesta a una escritura Modbus significa que se escribió el registro. Ninguna demuestra que actuara el equipo. La guía de verificación de órdenes BESS explica cómo comprobar la respuesta mediante mediciones. La matriz de fallos de enclavamientos muestra cómo decidir qué debe hacer la instalación si falla la ruta de órdenes.
Edge en el Gateway
Edge se ejecuta en el Gateway ZGW-20 en la instalación. Lee dispositivos inalámbricos de EpiSensor, dispositivos Zigbee y LoRaWAN de terceros, equipos Modbus TCP y RTU y controladores BACnet/IP en un inventario. Conserva el historial localmente y ejecuta paneles y automatización sin conexión a internet. Envía datos mediante MQTT o HTTPS, o como archivos por FTPS, en formato JSON o CSV. Ningún servicio en la nube de EpiSensor interviene en esa ruta. El Gateway consume 5 W en reposo y 15 W como máximo.
En la prueba de interrupción, Edge coloca los envíos fallidos en una cola en disco. Para los destinos gestionados por Edge, comprueba la cola cada minuto y reenvía los datos cuando vuelve a estar disponible el destino. Las lecturas reenviadas conservan sus marcas temporales originales y no vuelven a ejecutar la automatización local. Dos límites afectan al recuento del paso 3: un lote que siga en memoria cuando el Gateway pierda la alimentación puede perderse, y un lote que el receptor haya almacenado antes de que Edge registre el éxito puede llegar dos veces.
Preguntas frecuentes
¿Cuál es la diferencia entre una API en la nube y un Gateway local?
Una API en la nube devuelve lo que el equipo ya ha enviado a su fabricante. Un Gateway local lee los equipos de la instalación mediante Modbus, BACnet, Zigbee o LoRaWAN y conserva las lecturas antes de enviarlas. Durante una interrupción de internet, el Gateway sigue recopilando y la API no devuelve novedades. Ninguna de las dos vías llega a la plataforma hasta que vuelve la conexión.
¿Cuándo es suficiente una API en la nube?
Cuando los equipos ya informan a su fabricante, la API ofrece los puntos necesarios al intervalo necesario y la tarea es elaborar informes, no controlar. Un informe mensual de una cartera de sistemas fotovoltaicos es un caso habitual.
¿Por qué utilizar un Gateway Edge para monitorización energética?
Muchos contadores secundarios de instalaciones comerciales solo tienen una interfaz Modbus o de impulsos y carecen de conexión a la nube; un Gateway es la única forma de leerlos. El mismo Gateway mantiene el historial local y la automatización durante una interrupción de internet.