Saltar al contenido principal

Comunicaciones

La sección Comunicaciones de la interfaz de usuario agrupa todas las interfaces y protocolos en seis pestañas: LAN, Serial y Modbus, Módem, Bluetooth / NTP, MQTT y LoRa.

LAN​

En la pestaña LAN se configuran el access point propio del equipo y la conexión a una red WiFi o Ethernet existente.

Pestaña LAN

Access Point

  • Habilitar AP — activa o desactiva el access point propio del equipo.
  • SSID AP / Contraseña AP — nombre y contraseña de la red que crea el RTU-X. La contraseña de fábrica es password; se recomienda cambiarla antes de instalar el equipo en campo. Si la contraseña se deja vacía, el access point queda abierto sin seguridad.
  • Ocultar — oculta el SSID para que no sea visible al escanear redes, aunque sigue siendo accesible si se conoce el SSID y la contraseña.

En esta configuración, la dirección del RTU-X es siempre 192.168.4.1 y DHCP se encuentra habilitado: el equipo le asigna una IP a cada dispositivo que se conecte al access point.

Interfaz de Red WiFi

  • Station WiFi / Ethernet — se pueden habilitar ambas interfaces a la vez, además del access point. La opción Ethernet solo está disponible en el modelo DIN.
  • SSID / Contraseña — credenciales de la red a la que se conecta el equipo.
  • IP fija — si no se marca, el equipo toma la IP por DHCP de la red a la que se conecta; si se marca, se puede configurar una IP estática.

Serial y Modbus​

La pestaña Serial y Modbus agrupa la configuración de las interfaces seriales RS-485 (módulos de expansión opcionales) y del servidor Modbus del equipo.

Pestaña Serial y Modbus

RS-485 Extensión 1 / Extensión 2

Para cada interfaz serial se puede configurar el Baudrate y la Paridad.

Servidor Modbus local

  • Modbus Slave ID — el número de esclavo Modbus del RTU-X (por defecto 1).
  • Puerto Modbus TCP — el puerto TCP a utilizar para conexiones Modbus TCP (por defecto 502).

Gateway Modbus

Define la interfaz a la que se reenvían los mensajes Modbus cuyo destinatario no coincide con el Slave ID del RTU-X: Sin gateway (responde error a esos mensajes), RS-485 Ext1 o RS-485 Ext2. Mediante esta funcionalidad el RTU-X puede actuar de intermediario para que un cliente se comunique de forma transparente con un dispositivo conectado al bus RS-485 en los módulos de expansión.

Módem​

En la pestaña Módem se configuran los parámetros del módem celular, un módulo opcional.

Pestaña Módem
  • Tecnología — según el módulo instalado, soporta distintas tecnologías de comunicación y bandas.
    • Quectel BG95: LTE Cat-NB1 o LTE Cat-M1 con “down grade” a 2G.
      • Cat M1 / NB-IoT - B1/B2/B3/B4/B5/B8/B12/B13/B18/B19/B20/B25/B26/B27/B28/B31/B66/B71/B72/B73/B85
      • EGPRS 850/900/1800/1900 MHz
    • Quectel EG91: LTE con “down grade” a 3G / 2G.
      • LTE - B1/B2/B3/B4/B5/B7/B8/B28/B66
      • WCDMA - B1/B2/B5/B8
      • EGPRS 850/900/1800/1900 MHz
  • Encender módulo al encender RTU-X — modo de funcionamiento normal cuando el RTU-X está siempre encendido y conectado a una fuente estable de alimentación. Si se deshabilita, es posible controlar el encendido y apagado del módem desde el script con la variable modem_on; se suele usar en aplicaciones de consumo crítico, para encender el módem por períodos cortos y enviar solo la información almacenada en el log.
  • Aceptar conexiones entrantes — permite que el RTU-X acepte conexiones entrantes en el puerto 502 usado por la interfaz de usuario. Deshabilitada por defecto.
  • PIN — el PIN de la SIM, si ésta lo requiere.
  • Utilizar GPS — habilita el GPS; la información queda disponible en variables del script.
  • Utilizar SMS — habilita el envío y recepción de SMS (ver sección SMS).
  • Utilizar datos — habilita la conexión de datos con el APN configurado (APN, usuario y contraseña).
  • Bandas — bandas habilitadas para la tecnología seleccionada; los botones Seleccionar todas / Ninguna aceleran la configuración.

Bluetooth / NTP​

La pestaña Bluetooth / NTP agrupa la configuración de la conectividad BLE y la sincronización horaria.

Pestaña Bluetooth / NTP

Bluetooth

El RTU-X cuenta de base con conectividad BLE 4.2, que puede utilizarse para conectarse al equipo desde la interfaz de usuario y también para actuar como maestro de otros dispositivos BLE, como sensores de temperatura y humedad.

  • Habilitar Bluetooth — activa la interfaz.
  • Nombre — nombre con el que el equipo se anuncia (por defecto RTU-X-YYYYYY).
  • PIN — código solicitado al emparejar. El PIN de fábrica es 123456; se recomienda cambiarlo antes de instalar el equipo en campo.

NTP

  • Interfaz — WiFi/Ethernet, módem, o la misma interfaz que se utiliza para la conexión MQTT.
  • Servidor — URL o dirección IP del servidor NTP.
  • Huso — huso horario relativo a UTC.

MQTT​

El protocolo MQTT es un protocolo de comunicaciones sobre TCP/IP que ha sido adoptado como uno de los estándares más utilizados para dispositivos de IoT.

El RTU-X utiliza MQTT para el envío de los registros del log a un servidor en la nube, pero también se utiliza para realizar otras funciones más complejas cuando el RTU-X se encuentra conectado a Thingsboard: la actualización de toda la configuración, la sincronización de variables compartidas o el envío de comandos RPC.

Configuración MQTT​

Los parámetros a configurar para la conexión MQTT son los siguientes:

  • Interfaz - El RTU-X implementa el protocolo MQTT sobre WiFi/Ethernet y la conexión de datos del módem. Se debe seleccionar la interfaz física a utilizar.
  • Formato – Se encuentran disponibles las siguientes opciones, y la pantalla cambia según cuál se elija:
    1. JSON - Utiliza el formato JSON para el envío de los registros del log.
    2. Ultralight - Utiliza el formato Ultralight 2.0 para el envío de los registros de log.
    3. Predix - Utiliza el formato JSON compatible con el MQTT Data Collector de General Electric de acuerdo a lo establecido aquí.
    4. Thingsboard - En esta opción, el RTU-X se configura para establecer la conexión con un servidor Thingsboard. Telemetry+ de Nettra es una instancia profesional de Thingsboard gestionada por Nettra.
Pestaña MQTT con formato Thingsboard

Formato Thingsboard

Pestaña MQTT con formato JSON, Ultralight o Predix

Formato JSON, Ultralight o Predix

  • URI – Define el tipo de conexión, el servidor y el puerto. El URI debe tener el formato “esquema://host:puerto” donde esquema puede ser mqtt o mqtts dependiendo si se quiere o no establecer una conexión SSL. Un ejemplo de URI es mqtts://myhost.com:8883.
  • Access token / Usuario, contraseña y Client ID – Con formato Thingsboard (primera imagen), el campo se simplifica a un único Access token: el mismo valor se usa como usuario y como Client ID, y la contraseña queda vacía (tal como lo exige ThingsBoard). En los demás formatos (segunda imagen) se completan los tres campos Usuario, Contraseña y Client ID por separado, de acuerdo al protocolo MQTT.
  • Tópicos (telemetría, atributos, RPC) – Con formato Thingsboard los tópicos son fijos y quedan ocultos; el botón Configuración Telemetry+ completa automáticamente URI y certificado con los valores por defecto de la instancia de Nettra. En los demás formatos, los campos Telemetry Topic, Attribute Topic y Tópico de RPC quedan visibles y son definidos por el usuario.
  • Watchdog – En minutos. Permite implementar un mecanismo de seguridad en caso de falla de comunicación: si no se logra establecer la conexión MQTT en el tiempo configurado, el RTU-X se reinicia automáticamente. Con el valor en cero, esta funcionalidad queda deshabilitada.
  • Certificado – Certificado del servidor en formato PEM en caso de utilizar SSL para la conexión MQTT. Dejar en blanco si no se usa.
Usando Telemetry+

Cuando se utilice la instancia Telemetry+ de Nettra, se debe seleccionar el formato Thingsboard y presionar Configuración Telemetry+ para completar automáticamente URI y certificado; solo resta completar el Access token que será proporcionado por Nettra.

Incompatible con LoraWan

Cuando se habilita MQTT, los datos registrados mediante las sentencias log y report son transmitidos utilizando este protocolo de transporte. Esto no es compatible con la habilitación del protocolo LoraWan.

Ambas funciones se pueden usar con variables de tipo telemetry o attribute.

Integración con Thingsboard​

Cuando se selecciona Thingsboard como formato para la conexión MQTT, el RTU-X implementa funcionalidades adicionales además del envío del log por MQTT.

A continuación, se describen estas funcionalidades.

Atributos compartidos​

Cuando una variable del script se define con el prefijo shared, el valor de la variable se sincroniza con el valor del atributo compartido en Thingsboard con el mismo nombre si existe.

Esto se logra sin que el usuario tenga que hacer nada especial porque al establecer la conexión MQTT, el RTU-X se suscribe automáticamente a los topicos.

Reporte periódico de atributos internos​

El RTU-X publica automáticamente al servidor una lista de variables internas de utilidad. Las mismas son registradas en el sistema como atributos de cliente.

Las siguientes variables se publican cada vez que se establece la conexión con el servidor:

VariableDetalle
modelRTU-X model (DIN o IP68) y versión de hardware
mac_wifiDirección MAC del módulo wifi.
ext1Información del módulo conectado en el sócalo de extensión 1.
ext2Información del módulo conectado en el sócalo de extensión 2.
modem_imeiIMEI del módem (si hay un módem presente en el sócalo de comunicación).
modem_imsiIMSI de la SIM (si hay un módem presente en el sócalo de comunicación).

Las siguientes variables se envían periódicamente cada 10 minutos:

VariableDetalle
batteryPorcentaje de batería.
battery_statusEstado de funcionamiento de la batería. Puede ser Charged, Charging o No power.
internal_temperatureTemperatura interna del RTU-X
modem_signalNivel de señal del módem en dBm.
wifi_signalNivel de señal wifi en dBm.

Publicación de telemetría​

En la tabla siguiente se describe el formato de JSON que se publica la telemetría mediante MQTT para cada formato posible.

FormatoVariable telemetry
JSON y Thingsboard
{ 
    "ts":XXX,
    "values": { 
        "variable1":value,
        "variable2":value 
    } 
}

donde XXX es el timestamp en UTC en formato unix en milisegundos de los registros

Ultralight 2.0ts|TTT|variable1|value|variable2|value

donde TTT es el timestamp en UTC en formato ISO8601

Predix
{
    "body":[
        {
            "attributes":{"machine_type":"RTU-X"},
            "datapoints":[[1558110998983,9547909,3]],
            "name":"NombreVariable"
        }
],
    "messageId": " "
}

Todos los registros de log creados con una misma fecha/hora se envían en un mismo paquete MQTT.

Si la conexión se pierde, todos los registros quedan almacenados en el log y se envían cuando se reestablece la conexión.

Publicación de atributos​

FormatoVariable attribute
JSON y Thingsboard
{ 
    "variable1":value1,
    "variable2":value2
}

Ultralight 2.0variable1|value1|variable2|value2

Predix
{
    "body":[
        {
            "attributes":{"machine_type":"RTU-X"},
            "datapoints":[[1558110998983,9547909,3]],
            "name":"NombreVariable"
        }
],
    "messageId": " "
}

Comandos RPC​

RPC significa “Remote Procedure Call” y se utiliza para enviar comandos y consultas desde un servidor. El formato de envío de comandos y l respuesta a dichos comandos depende del formato utilizado. A continuación se detallan los comandos disponibles.

Formato Thingsboard​

FunciónDescripciónComandoRespuesta
setModifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valor
{ 
    "method":"setNAME",
    "params": VALUE
}

OK

getConsulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variable
{
    "method": "getNAME"
}

VALUE

resend_logSolicita reenvío de los últimos N registros almacenados en el log de eventos
{ 
    "method": "resend_log",
    "params": N
}

OK

unixtimeDefine la hora del RTU-X en GMT-0. T es el instante actual en formato unix
{ 
    "method": "unixtime",
    "params": T
}

{
    "reply": "OK"
}

{
"reply": "ERROR"
}

localtimeDefine la hora local del RTU-X a partir de año, mes, día, horas, minutos y segundos del instante actual
{ 
    "method": "localtime",
    "params": "Y/m/d,H:M:S"
}

{
    "reply": "OK"
}

{
    "reply": "ERROR"
}

timezoneDefine el timezone del RTU-X, donde N es el nuevo huso horario
{
    "method": "timezone",
    "params": N
}

OK

resetProduce un reset del RTU-X
{ 
    "method":"reset"
}

Sin respuesta
calendarEvents

Define eventos de calendario que dan valor a las variables calendar declaradas en el script.

Cuando tsStart < unix_ts_utc < tsEnd para un evento, las variables calendar toman los valores definidos en el evento. En otro caso, las variables toman el valor por defecto declarado en el script.

{
    "method": "calendarEvents",
    "params": [
        {
            "tsStart": 1753492586,
            "tsEnd": 1753592586,
            "variables": [
                {"a": 3},
                {"b": 7}
            ]
        },
        {
            "tsStart": 1753482586,
            "tsEnd": 1753493586,
            "variables": [
                {"a": 4},
                {"b": 5}
            ]
        }
    ]
}

Sin respuesta
Dos formas de cargar eventos

El comando RPC calendarEvents no es la única forma de definir eventos de calendario. Hay dos:

  • Eventos en la nube — se cargan desde la plataforma Telemetry+, que por detrás envía este mismo comando RPC al RTU-X.
  • Eventos locales — se cargan directamente desde la sección Eventos de la interfaz de usuario, sin depender de Telemetry+ ni de conexión a internet.

Los modos Nube y Local son excluyentes: solo una de las dos fuentes de eventos está activa a la vez.

Formato JSON​

FunciónDescripciónComandoRespuesta
setModifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valor
{ 
    "method":"setNAME",
    "params": VALUE
}

{
    "reply": "OK"
}

{
    "reply": "ERROR"
}

getConsulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variable
{
    "method": "getNAME"
}

{
    "NAME": VALUE
}

{
    "reply": "ERROR"
}

resend_logSolicita reenvío de los últimos N registros almacenados en el log de eventos
{ 
    "method": "resend_log",
    "params": N
}

{
    "reply": "OK"
}

{
    "reply": "ERROR"
}

unixtimeDefine la hora del RTU-X en GMT-0. T es el instante actual en formato unix
{ 
    "method": "unixtime",
    "params": T
}

{
    "reply": "OK"
}

{
    "reply": "ERROR"
}

localtimeDefine la hora local del RTU-X a partir de año, mes, día, horas, minutos y segundos del instante actual
{ 
    "method": "localtime",
    "params": "Y/m/d,H:M:S"
}

{
    "reply": "OK"
}

{
    "reply": "ERROR"
}

timezoneDefine el timezone del RTU-X, donde N es el nuevo huso horario
{
    "method": "timezone",
    "params": N
}

{
    "reply": "OK"
}
{
    "reply": "ERROR"
}

resetProduce un reset del RTU-X
{ 
    "method":"reset"
}

Sin respuesta

Formato Ultralight​

FunciónDescripciónComandoRespuesta
setModifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valorsetNAME|VALUE 

reply|OK

reply|ERROR

getConsulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variablegetNAME 

NAME|VALUE

reply|ERROR

resend_logSolicita reenvío de los últimos N registros almacenados en el log de eventosresend_log|N 

reply|OK

reply|ERROR

unixtimeDefine la hora del RTU-X en GMT-0. T es el instante actual en formato unixunixtime|T 

reply|OK

reply|ERROR

localtimeDefine la hora local del RTU-X a partir de año, mes, día, horas, minutos y segundos del instante actuallocaltime|Y/m/d,H:M:S 

reply|OK

reply|ERROR

timezoneDefine el timezone del RTU-X, siendo N el nuevo huso horariotimezone|N 

reply|OK

reply|ERROR

resetProduce un reset del RTU-Xreset

Sin respuesta

LoraWan​

El RTU-X puede conectarse a una red LoraWan desde la pestaña LoRa. Para ello, en el zócalo WAN se instala un módulo RAK3172 al que se le puede conectar una antena externa.

Pestaña LoRa

General

  • Encender módulo al encender RTU-X — modo de funcionamiento normal cuando el RTU-X está siempre encendido y conectado a una fuente estable de alimentación. Si se deshabilita, es posible controlar el encendido y apagado del módulo desde el script con la variable modem_on.
  • Banda — es posible seleccionar entre US915 y AU915.
  • Subbandas — habilitan canales tomados de a ocho: la subbanda 1 habilita los canales 0 a 7, la 2 habilita los canales de 8 a 15, etc.
  • Modo de activación — es posible seleccionar entre OTAA y ABP.
  • Clase — dependiendo de las restricciones de consumo eléctrico de la solución, es posible seleccionar entre clase A y C.
  • Data Rate — el data rate a utilizar, de acuerdo a la banda seleccionada.
  • ADR (Adaptive Data Rate) — habilita o no esta funcionalidad.
  • Potencia TX — índice de potencia de transmisión según el estándar LoRaWAN: 0 es la potencia máxima permitida por la banda, y cada valor superior la reduce un paso.
  • Confirmación — habilita o no el envío de mensajes con solicitud de confirmación.

Credenciales

Las claves y direcciones necesarias para establecer conexión con una red LoraWan deben ser definidas por el usuario: AppEUI y AppKEY en modo OTAA, o DevADDR, NwksKEY y AppsKEY en modo ABP (los campos que no aplican al modo de activación elegido quedan deshabilitados). El DevEUI del dispositivo es el definido por el fabricante del módulo y se muestra de solo lectura una vez que el módulo está habilitado.

Envío y recepción de datos​

Al igual que con MQTT, cuando se utiliza LoraWan existen mecanimos de intercambio de datos con una plataforma de IoT.

Para lograr la diferenciación entre tipos de datos y comandos, se utilizan varios puertos según se muestra en la siguiente tabla

PuertoDescripción
100Es utilizado para la publicación de datos almacenados en el log de eventos cuando se ejecutan las funciones log y report en el script
101Se utiliza para publicar atributos de cliente, es decir, las variables declaradas como attribute en el script.
102Se utiliza para recibir valores de atributos compartidos.
103Se utiliza para solicitar la actualización de atributos compartidos
104Se utiliza para la implementación de comandos RPC y las respuestas que correspondan

Codificación de datos​

Dado que los nombes de las variables que se transmiten son definidos por el usuario en el script del RTU-X (variables tipo telemetry), es necesario incluir los nombres de las variables reportadas además de sus valores. Entonces, a los efectos de enviar y recibir datos minimizando el overhead se utiliza una variante del formato Ultralight.

En todos los paquetes de datos que contienen más de un elemento, dichos elementos son separados por el caracter “|”. Por ejemplo, los atributos son reportados como nombre|valor.

Publicación de telemetría​

Cuando en el script se ejecuta la sentencia log o report utilizando variables de tipo telemetry, los valores son almacenados en el log de eventos del RTU-X. Si está establecidad la conexión con un gateway, los datos son transmitidos inmediatamente con usando un payload con el formato

ts|key1|value1|key2|value2|...|keyN|valueN

Siendo ts la estampa de tiempo en formato unix correspondiente al instante en que se ejecutó la sentencia log.

keyn y valuen son el nombre y valor de cada una de las variables reportadas

Publicación de atributos​

Si la sentencia log se utiliza con variables tipo attribute, el formato utilizado es el mismo pero sin estampa de tiempo

key1|value1|key2|value2|...|keyN|valueN

Comandos RPC​

Es posible ejecutar comandos RPC via LoraWan. La tabla siguente muestra los comandos implementados

FunciónDescripciónComandoRespuesta
setModifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valorsetNAME|VALUE 

OK
ERROR

getConsulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variablegetNAME

NAME|VALUE

resend_logSolicita reenvío de los últimos N registros almacenados en el log de eventosresend_log|N 

OK
ERROR

unixtimeDefine la hora del RTU-X en GMT-0. T es el instante actual en formato unix (*)unixtime|T 

OK
ERROR

localtimeDefine la hora local del RTU-X a partir de año, mes, día, horas, minutos y segundos del instante actual (*)localtime|Y/m/d,H:M:S 

OK
ERROR

timezoneDefine el timezone del RTU-X, siendo N el nuevo huso horariotimezone|N 

OK
ERROR

resetProduce un reset del RTU-X (*)reset

Sin respuesta

(*) solo tiene sentido su utilización si se configura operación en clase C.

Testing con gateway Milesight y Node-Red​

A continuación está disponible un flow de Node-Red utilizado para testear el envío y recepción de datos.

En el mismo se utiliza un nodo HTTP para ejecutar un método POST que pone los datos en la cola de datos de envío al dispositivo conectado vía LoraWan.

Para que el flow funcione correctamente es necesario configurar el DEVEUI del RTU-X. El RTU-X debe estar configurado en el gateway para que los datos recibidos ingresen al flow. También es necesario configurar la dirección ip del gateway y las credenciales correctas para obtener el jwt necesario para que el HTTP POST funcione correctamente.

flow_testing_lorawan.json

En esta página