Nota sobre moneda. Las cifras de este artículo se expresan en CNY. Cuando un precio de origen se publicó en otra moneda, el equivalente en CNY se convierte al tipo de referencia fijo 2026-10 de 1 USD ≈ 6.71 CNY, mostrando junto a él la moneda original. Los precios publicados públicamente provienen de fuentes distintas con alcances inconsistentes; indican orden de magnitud y no son una recomendación de compra.

Un proyecto LoRaWAN está terminado. Los sensores están montados, la pasarela está en línea y la plataforma muestra curvas limpias. Entonces el cliente hace una sola pregunta: ¿pueden estos datos llegar al sistema de gestión de edificios que ya tenemos?

Lo que sigue a esa pregunta es trabajo que nadie quiere especialmente. La gestión de edificios habla BACnet. La planta habla Modbus. LoRaWAN no habla ninguno de los dos. Así que o compras otra pasarela de protocolos, o pagas a un integrador para que escriba un servicio puente que traduzca mensajes MQTT en valores de puntos. Ese trabajo no produce datos nuevos: solo hace que los datos que ya tienes sean legibles para un sistema que no puede leerlos. Y aun así lleva asociado un precio, un cronograma y un proceso de gestión de cambios que dura toda la vida del proyecto.

ThinkLink incluye un servicio BACnet/IP integrado y un servidor Modbus TCP integrado en sus formas TKE (servidor edge) y TKG (en la pasarela), y exactamente para eso sirven. Este artículo recorre la integración en el orden en que realmente ocurre: cuándo puedes usarlos, cómo los campos se convierten en puntos, qué hay que comprobar antes de entregar una lista de puntos y por qué «la tabla de puntos se guardó correctamente» no es lo mismo que «el BMS está leyendo valores».

1. Primero el alcance: BACnet y Modbus son solo para TKE / TKG

Esto es lo primero que hay que dejar claro, porque es un límite estricto y no un problema de configuración.

La documentación oficial afirma lo mismo en tres lugares: el servicio BACnet solo es compatible con dispositivos TKE desplegados de forma independiente y con pasarelas que ejecutan TKL (TKG); la versión en la nube no lo proporciona. El servidor Modbus TCP tiene una restricción idéntica.

No es una función que se haya retenido. Se deriva del protocolo. BACnet/IP funciona sobre UDP 47808 (0xBAC0) de forma predeterminada, y el descubrimiento de dispositivos depende de la difusión local: una estación de trabajo envía una difusión Who-Is y cada dispositivo que la oye responde con un I-Am. Eso funciona dentro de un mismo dominio de difusión. Los routers IP no reenvían difusiones, así que cruzar subredes requiere un BBMD (BACnet Broadcast Management Device). Una nube pública multiinquilino no tiene ni el dominio de difusión local del cliente ni un puerto UDP fijo hacia su red interna. Esto es arquitectura, no una tarea pendiente.

Así que alinea a ventas y preventa en esto antes de que salga la propuesta: si el cliente está en la Nube, los datos salen mediante el reenviador MQTT o la API REST, y el integrador los convierte en puntos de su lado. Prometer «puntos BACnet directamente desde la nube a su BMS» es un compromiso que falla durante la implementación.

Hay una segunda restricción operativa fácil de pasar por alto: un único proceso de backend ejecuta el servicio BACnet para una sola organización. Iniciar BACnet en otra organización detiene la instancia de la organización anterior; no se pueden ejecutar varias organizaciones en paralelo en puertos distintos dentro de un mismo proceso. El servidor Modbus TCP se comporta igual: una instancia sirve a una organización, y cambiar la organización del servicio reemplaza la instancia en ejecución. Un despliegue edge multiinquilino (un TKE que sirve a varias filiales, por ejemplo) debe diseñarse explícitamente. La operación en paralelo no es lo predeterminado.

2. Lo que realmente cuesta este segmento: el sector cobra por punto

La automatización de edificios y la integración industrial comparten una unidad de cuenta: el punto. Una temperatura, un estado de válvula, una lectura de contador: cada uno es un punto. Una vez que interiorizas eso, queda claro qué elimina un servicio de protocolo integrado.

Dos conjuntos de cifras publicadas públicamente (2026):

China — precios de software de sistema BA, con software y puesta en marcha incluidos

El rango más amplio del sector para proyectos medianos (aproximadamente 2,000–5,000 puntos) es de unos CNY 80–200 por punto, incluyendo controladores, sensores, licencias de software y puesta en marcha; los entornos de altas prestaciones, como las salas limpias de hospitales y los centros de datos, superan los CNY 300 por punto. Los dos conjuntos difieren en alcance —el primero es principalmente plataforma de software, el segundo incluye hardware e instalación—, así que considera ambos solo como orden de magnitud.

Precios de modernización en el extranjero (moneda original; CNY a 1 USD ≈ 6.71)

La fila del medio es la que importa: los puntos que necesitan una pasarela de protocolos cuestan entre 2.5 y 3 veces lo que cuestan los puntos conectados directamente. Una guía de costes de BMS del Reino Unido de 2026 llega al mismo punto, citando £300–600 por punto conectado y nombrando el número de puntos como el principal factor de coste.

Ese es el valor de un servicio de protocolo embebido. Mueve los datos de LoRaWAN del grupo de "necesita una pasarela de protocolo" al grupo de "se conecta directamente". Lo que ahorra no es dinero en sensores: es el multiplicador 2.5× sobre cada punto, más el coste recurrente de volver a ejecutar el proceso de cambio cada vez que se mueve la lista de puntos.

3. BACnet vs Modbus: entregas objetos o entregas direcciones

Ambos protocolos exponen los datos de la plataforma a un sistema de terceros. Lo que se entrega es completamente distinto, y ahí es donde suele fallar la selección.

Una línea los separa: BACnet para automatización de edificios, Modbus para el lado industrial. Puedes ejecutar ambos a la vez: un único TKE puede publicar objetos BACnet al BMS y registros Modbus a SCADA de forma independiente. Tienen permisos de servicio y puertos separados.

La prueba es sencilla. Si el otro sistema puede escanear la red y listar los nombres de los puntos por sí mismo, estás en el mundo BACnet. Si el otro ingeniero empieza con "mándame la lista de puntos y dime qué es 40001", estás en el mundo Modbus.

4. BACnet en cinco pasos, en este orden

Paso 1: el administrador del sistema habilita el permiso del servicio

Desde 2.00.077, System Platform → System Configuration incluye dos interruptores independientes, ModbusTcpServer y BACnet, almacenados en system_param.service_enable (no como subcampo de config).

Dos detalles importan:

• Solo un booleano JSON false lo deshabilita. Una clave ausente, null, o un objeto vacío se interpretan por defecto como permitido. No dejes el campo en blanco.
• Deshabilitarlo detiene el servicio, bloquea las operaciones de configuración y de tabla de puntos, e impide tanto el inicio manual como la recuperación automática. La configuración y las tablas de puntos se conservan; volver a habilitarlo requiere un reinicio manual : nada se inicia por sí solo.

Paso 2: configurar los campos BACnet en el modelo de dispositivo

Antes de habilitar el servicio BACnet, debes configurar los atributos BACnet de los campos que quieres exponer, dentro del modelo de dispositivo. El campo del modelo de dispositivo unit se corresponde con el unitsdel objeto BACnet.

Esta es la causa más común de retrabajo: un modelo de dispositivo entregable tiene cuatro partes: el script de análisis, los campos de visualización, el mapeo Modbus y los campos BACnet. Un script que funciona y analiza los datos correctamente no es lo mismo que tener los campos BACnet configurados. El artículo 21 cubrió el script de análisis y el artículo 22 cubrió los disparadores; este es un cuarto bloque de trabajo de configuración, independiente.

Paso 3: habilitar BACnet en el dispositivo

Detalles del dispositivo → Información básica, habilitar BACnet (en el lado Modbus el equivalente es establecer modbus_tcp en TRUE).

Solo se mapean los dispositivos con este interruptor activado. Cuando generas una tabla de puntos por modelo de dispositivo, solo abarca los dispositivos ya vinculados a ese modelo de dispositivo y ya habilitados para BACnet : no genera objetos para todos los dispositivos del inquilino.

Paso 4: generar la tabla de puntos

Operations → BACnet → Incremental Generate → seleccionar el modelo de dispositivo → confirmar.

También puedes añadir objetos manualmente. Restricciones del formulario manual:

Desde 2.00.077 el botón «Apply point table» ya no está en la interfaz. Guardar, eliminar, importar, generar de forma incremental y renumerar objetos sincroniza automáticamente el servicio en ejecución. Lo contrario también es cierto: guardar una tabla de puntos no inicia un servicio detenido — iniciar es una acción independiente en la configuración del servicio.

Paso 5 — configurar los parámetros del servicio y reiniciar

System Management → Server Configuration → BACnet. Rellene los parámetros de red y de dispositivo, haga clic en Submit y luego en Restart.

Los valores de referencia son solo para la configuración en campo — no significan que el formulario de nueva entrada esté rellenado previamente. Lea la configuración existente y confirme cada elemento con el integrador del BMS. Cambiar los parámetros de escucha sigue requiriendo Submit seguido de Restart.

5. Tres restricciones de la tabla de puntos con largo alcance

1. object_id va de 0 a 4194303, y la renumeración cambia lo que el integrador está usando

La lista ofrece una acción «renumber object id». Parece una tarea de mantenimiento. Pero cambia los identificadores de objeto que el integrador ya está usando — el BMS direcciona los puntos por número de instancia de objeto, así que una pasada de renumeración por su parte desalinea todos los puntos del lado del integrador. Tras renumerar debe reemitir la lista de puntos entregada y avisar al integrador para que reconfigure.

El rango permitido es 0–4194303, que refleja el campo de número de instancia de objeto de 22 bits en BACnet. Los números de instancia de dispositivo BACnet también deben ser únicos en toda la interred BACnet; los duplicados producen fallos intermitentes realmente desagradables de diagnosticar, porque el síntoma es «a veces no lee», no «nunca lee».

2. data_from es texto libre, no un enum

Desde 2.00.085, los campos BACnet llevan data_from. Su tipo es una cadena libre (varchar(32)), no un enum fijo. Se sugieren tres valores:

Memorice la regla de respaldo: fuente desconocida, valor ausente, null, cadena vacía o espacios en blanco recurren todos a default_value; pero los numéricos 0 y los booleanos false se conservan.

Lo que lleva a la conclusión importante: un valor por defecto no es evidencia del estado real del dispositivo. Un respaldo a 0 puede significar «el valor es 0» o «la fuente no existe», y el BMS muestra ambos de forma idéntica.

3. La clave única es una cuádrupla, no un nombre de campo

La clave de negocio de un objeto es (eui, data_from, thing_model, field_name). Los campos BACnet del modelo de dispositivo usan la clave compuesta «fuente + nombre de campo». Los campos con el mismo nombre de fuentes distintas pueden coexistir — así que no dedupliques solo por el nombre del campo; eliminarás el equivocado.

Relacionado: añadir un objeto de atributo directamente no requiere un modelo de dispositivo, pero la generación incremental por modelo de dispositivo solo cubre los dispositivos vinculados a ese modelo con BACnet habilitado, y no generará objetos de estado para todos los dispositivos automáticamente. Si quieres un punto "en línea", añádelo manualmente.

6. Convertir "Sin conexión" en un punto que el BMS pueda leer

Un BMS necesita saber si un sensor sigue activo. En el lado de ThinkLink, expones el estado en línea como un punto de atributo.

Tres pasos:

1. En la información básica del dispositivo, establece notify_offline = "TRUE" y configura el periodo de latido real (confirma el origen del estado de detección).
2. Añade un objeto BACnet manualmente: elige el EUI real del dispositivo y un ID/nombre de objeto que no entre en conflicto, establece el origen en server_attrs, el campo en _online, el tipo en binaryInput, las unidades en noUnits.
3. Guarda la tabla de puntos, confirma que el servicio en ejecución se ha sincronizado y luego comprueba en línea, sin conexión por tiempo de espera y recuperación desde el BMS.

Campos clave al crearlo (el EUI, el identificador de objeto y otros campos obligatorios también aplican):

"data_from": "server_attrs", "thing_model": "", "field_name": "_online", "object_type": "binaryInput", "units": "noUnits", "default_value": 0

Una advertencia debe figurar en el documento de entrega: un default_value de 0 no demuestra que el resultado de la detección sea sin conexión — un atributo ausente también devuelve 0. Con la notificación de sin conexión deshabilitada, _online puede congelarse en su último estado.

El estado en línea también tiene tres significados no intercambiables en la plataforma (tratados en el artículo 22): la hora de actividad en la lista de dispositivos, server_attrs.online (un número 1/0 mantenido por el detector), y el booleano data.online en las notificaciones MQTT. notify_offline es un interruptor de cadena en el dispositivo o la plantilla, "TRUE"/"FALSE", deshabilitado por defecto — cuando no está habilitado, o falta, no puedes tratar el dispositivo como sin conexión.

7. Modbus TCP: cuatro tipos de registro y diez codificaciones

Tres pasos de configuración

1. El administrador del sistema habilita ModbusTcpServer en los permisos de servicio de la organización.
2. Gestión del sistema → Configuración del servidor → Servidor Modbus TCP: establece el puerto de escucha (normalmente 502), Enviar y luego Reiniciar.
3. Detalles del dispositivo → Información básica: establece modbus_tcp en TRUE.

Entradas de mapeo de registros

Operaciones → Modbus TCP → lista de registros; añade mapeos para los dispositivos habilitados:

Tres trampas al rellenar el formulario

Las direcciones son hexadecimales, los recuentos de registros son decimales. No mezcles ambos.

El recuento de registros se calcula a partir del tipo y no se puede editar. Al seleccionar FloatBE se muestra un recuento de 2. Cuando asignes la dirección siguiente, ten en cuenta la longitud total ocupada — un FloatBE consume dos registros de 16 bits, por lo que el siguiente punto debe empezar dos direcciones después. Comprobar solo la dirección inicial hará que se solapen.

LE/BE es una elección de codificación y debe coincidir con cómo el lector interpreta los bytes. Elige FloatBE en la plataforma mientras el SCADA decodifica little-endian y obtendrás un número completamente erróneo, sin que se genere ningún error.

Comportamiento de lectura y escritura

Lectura: cuando el cliente lee un registro, ThinkLink devuelve el valor actual del campo mapeado. El valor se actualiza en cada enlace ascendente del dispositivo — no se necesita configuración de sondeo.

Escritura: el registro debe tener un RPC vinculado. ThinkLink llama al RPC vinculado con el valor escrito como parámetro, en la forma { _eui, [field_name]: value }, con el origen de la llamada marcado bacnet_server (el mismo mecanismo se aplica en el lado de Modbus).

Uso típico: SCADA escribe un holding_registers valor para cambiar el intervalo de muestreo; ThinkLink dispara un RPC de "establecer intervalo de muestreo" hacia el dispositivo.

8. La ruta de escritura: tres cosas que aceptar por separado

Aquí es donde surgen las disputas de integración. La documentación es deliberadamente cuidadosa en su redacción:

Una escritura BACnet exitosa no significa que el dispositivo la haya ejecutado; verifique la respuesta del dispositivo o un uplink posterior. Escritura aceptada, ejecución exitosa en el dispositivo y persistencia del atributo completada deben verificarse por separado.

Las tres etapas:

1. Escritura aceptada — la plataforma recibió la solicitud y el valor del objeto en la tabla de puntos puede que ya esté actualizado. Esto se completa en segundos.
2. Ejecución exitosa en el dispositivo — el RPC llega al dispositivo y el dispositivo realmente cambia el parámetro. Para un dispositivo final LoRaWAN de Clase A, un downlink solo puede enviarse en las ventanas de recepción después de un uplink (RX1 a aproximadamente 1 s, RX2 a aproximadamente 2 s). Un dispositivo que reporta cada diez minutos puede tardar diez minutos en recibir el comando.
3. Persistencia del atributo completada — el dispositivo reporta el nuevo valor de vuelta, se escribe en los atributos y el BMS ve el resultado real en su siguiente lectura.

Un fallo en cualquier etapa se presenta como "el BMS muestra que la escritura fue exitosa pero el dispositivo no cambió". Si el RPC falla o el dispositivo reporta su valor original, una notificación de atributo posterior puede devolver el valor real en caché — pero ese envío llega en la siguiente actualización de atributo, no de inmediato.

Por lo tanto, en la hoja de aceptación, el control de escritura debe especificarse como "leer de vuelta y confirmar dentro de N ciclos de reporte", no como "la operación de escritura devolvió éxito".

9. Red y puertos: 47808 no funciona solo porque lo configuró

Los requisitos de red para BACnet/IP son más específicos de lo que la mayoría espera.

UDP 47808, en ambas direcciones. Las reglas de firewall deben permitir UDP 47808 entrante y saliente. Una regla solo saliente significa que la estación de trabajo puede enviar Who-Is y nunca verá volver un I-Am.

La difusión solo funciona dentro de un mismo dominio de difusión. La estación de trabajo envía un Who-Is por difusión y solo responden los dispositivos en el mismo segmento Layer-2. Coloque un router IP en medio y el router no reenvía las difusiones, por lo que el descubrimiento falla silenciosamente — la estación de trabajo informa "no se encontró nada", nunca "red inalcanzable". La solución estándar para cruzar subredes es un BBMD: uno por subred que contenga dispositivos, cada uno con una Broadcast Distribution Table que nombre a sus pares. Una difusión se envía por unicast a esos pares y cada uno la re-difunde localmente.

Algunas reglas estrictas al configurar BBMD: la tabla de distribución debe coincidir en cada BBMD — una subred listada en una tabla y omitida en las demás es alcanzable solo en una dirección; la propia dirección del BBMD debe ser estática, porque los registros de dispositivos externos y las entradas de la tabla de pares apuntan a ella por dirección; y dos BBMD en la misma subred es un error de configuración, no redundancia, lo que produce tráfico duplicado y respuestas I-Am duplicadas.

NAT rompe BACnet/IP. BACnet/IP lleva la dirección de origen dentro de la carga útil del mensaje — en el Forwarded-NPDU que envía un BBMD y en un registro de dispositivo externo. NAT reescribe la cabecera IP y deja la carga útil intacta, por lo que las solicitudes salen y las respuestas nunca llegan. La vía viable es una conexión enrutada o VPN, no la traducción de direcciones.

Las VPN de sitio a sitio y los puentes inalámbricos con frecuencia descartan la difusión. Que el unicast funcione no es evidencia de que la difusión funcione; la supervisión a través de dicho enlace normalmente necesita registro de dispositivo externo en lugar de descubrimiento simple.

Una nota a nivel de despliegue. La guía de despliegue de TKE Docker lista los puertos entrantes del host (80/8080, 443, 18083, 18084, 1883, 8883, 8083, 8084, 1700 UDP, 9000, 9001) y no incluye 47808 ni 502. El instalador no crea mapeos ni reglas de permiso para estos dos servicios; el equipo de despliegue tiene que confirmar por sí mismo el mapeo de puertos del contenedor, el firewall del host y las reglas del grupo de seguridad. Si se pasa esto por alto, el síntoma es "la plataforma dice que el servicio está en ejecución, pero el BMS no encuentra nada".

Un último punto es un requisito de seguridad más que una opción: BACnet se diseñó para redes de control aisladas, y gran parte de la base instalada tiene poca o ninguna autenticación. Una vez que la red de control es accesible desde la red corporativa, esa suposición deja de ser válida. Tanto UDP 47808 como TCP 502 deben ser accesibles solo desde el segmento de automatización de edificios o SCADA — nunca desde la internet pública.

10. Verificación con YABE y entrega de la lista de puntos

Un ciclo de cinco minutos con YABE

YABE (Yet Another BACnet Explorer) es la herramienta común para explorar y depurar dispositivos BACnet. Una vez configurado, conecte YABE a ThinkLink para descubrir los dispositivos BACnet publicados y sus propiedades de objeto, y confirmar que los datos se están publicando correctamente.

Realice las comprobaciones en este orden; cada una aísla una clase diferente de problema:

Modbus no tiene un equivalente de navegador de propósito general; normalmente se utiliza una utilidad maestra Modbus (Modbus Poll y similares) para leer las direcciones una por una contra la lista de puntos. Céntrese en dos cosas: la convención de direcciones (hexadecimal frente a decimal) y el orden de bytes (LE frente a BE).

Entrega de la lista de puntos

Tanto las listas de puntos BACnet como Modbus se exportan a Excel y se importan de vuelta para la configuración masiva. La exportación contiene el tipo de objeto, la dirección, el nombre, la descripción, el tipo de dato, las unidades y los permisos de lectura/escritura — exactamente lo que el integrador necesita para configurar su cliente.

Una advertencia sobre la importación: las entradas con un ID existente se sobrescriben. Es la misma clase de riesgo que las trampas de migración de Excel tratadas en el artículo 23 — exporte una copia de seguridad antes de importar, porque la sobrescritura no se puede revertir.

Dos recomendaciones de entrega:

1. Versione la lista de puntos. Registre la versión de la lista de puntos junto con la versión del modelo de dispositivo y la versión de la plataforma. Si los identificadores de objeto BACnet cambian, todos los puntos del lado del BMS quedan desalineados, y la investigación retrospectiva cuesta mucho más que llevar un registro.
2. Entregue primero, luego ponga en servicio conjuntamente. Entregue la lista de puntos al integrador, deje que configure su cliente y luego realice la puesta en servicio de forma conjunta. Eso es mucho más rápido que ajustar la lista de puntos durante la puesta en servicio. El guardado de la tabla de puntos sincroniza automáticamente el servicio en ejecución, pero cada cambio obliga a la otra parte a reconfigurar.

11. Lista de verificación de aceptación

12. Cierre

Llevar datos LoRaWAN a un BMS o SCADA no es fundamentalmente difícil — los protocolos son públicos y siempre se puede escribir un puente. El costo real es que cada punto tiene que ser configurado por alguien, verificado por alguien y modificado de nuevo por alguien a lo largo de la vida del proyecto. La industria cotiza por punto; los puntos que necesitan una pasarela de protocolo cuestan de 2.5 a 3 veces lo que cuestan los puntos directos. Ese número cotiza la mano de obra de integración, no las características del software.

BACnet/IP y Modbus TCP integrados de ThinkLink en TKE y TKG eliminan ese segmento. Lo que no eliminan es la disciplina de ingeniería: BACnet solo está disponible en las formas autoalojadas, un proceso sirve a una organización, renumerar una lista de puntos rompe la configuración del integrador, una escritura exitosa no es una ejecución exitosa, y UDP 47808 necesita reglas bidireccionales más un BBMD una vez que se cruza una subred.

Todo esto está documentado. Simplemente está repartido entre distintas páginas. Recopilarlo en una lista de verificación de aceptación es la forma más económica de hacer la integración bien a la primera.

Lectura relacionada

• Artículo 21: Scripts decodificadores del modelo de dispositivo de ThinkLink en la práctica — Convertir 15 bytes en una tabla legible
• Artículo 22: Modelos de disparador y reglas de alarma de ThinkLink en la práctica — A tiempo, sin spam, a la persona correcta
• Artículo 23: Despliegue local en el borde de ThinkLink en la práctica — Qué requiere realmente "los datos nunca salen de la planta"

Basado en la documentación oficial de ThinkLink (versiones 2.00.077–2.00.085). Las rutas de configuración y los parámetros siguen su versión desplegada. Manuales oficiales: https://www.think-link.net/docs/en/Maintenance/BACnet.html https://www.think-link.net/docs/en/Maintenance/ModbusTCP.html https://www.think-link.net/docs/en/QuickStart/SystemManagement/ServerConfiguration.html