¶ Wifi
En la ventana de comunicaciones, en la pestaña “Wifi, Serial y Modbus” se pueden configurar los parámetros relacionados a la interfaz wifi.
Aquí se puede seleccionar el modo de funcionamiento entre las siguientes opciones:
- Apagado
Al deseleccionar los check-box de Access point y Station, el módulo wifi queda apagado y no es utilizado. - Access Point
El RTU-X crea una red wifi con el SSID y contraseña configurados y luego acepta conexiones de los dispositivos. En esta configuración, la dirección del RTU-X es siempre 192.168.4.1 y DHCP se encuentra habilitado, es decir que el RTU-X le asigna una IP a los dispositivos que se conecten al access point. Si la contraseña se deja vacía, el access point se crea abierto sin seguridad. Existe la opción de ocultar esta red para que no sea visible para otros dispositivos, pero que quede accesible en caso de saber el SSID y contraseña. - Station o Ethernet
- IP fija OFF (DHCP)
El RTU-X se conecta a la red wifi con el SSID y contraseña configurados, y toma la IP del access point al que se conecta. - IP fija ON (Estática)
El RTU-X se conecta a la red wifi con el SSID y contraseña configurados, y utiliza la configuración de red que tenga configurada (IP, subred, Gateway y DNS).
- IP fija OFF (DHCP)
El RTU-X permite la posibilidad de quedar en modo Access Point y Station al mismo tiempo. La opción de Ethernet solo es configurable en el modelo DIN a partir de la versión 3.3.08 de firmware.
¶ Serial RS-485
En la ventana de comunicaciones, en la pestaña “Wifi, Serial y Modbus” se pueden configurar los parámetros relacionados a las interfaces seriales RS-485. Las interfaces seriales RS-485 son módulos de expansión opcionales.
Para cada interfaz, se puede configurar la velocidad y la paridad.
¶ Modbus
En la ventana de comunicaciones, en la pestaña “Wifi, Serial y Modbus” se pueden configurar los parámetros relacionados a Modbus.
Los parámetros son:
- Modbus Slave ID
El número de esclavo Modbus del RTU-X (por defecto 1). - Puerto Modbus TCP
Para el caso de conexiones por Wifi, el puerto TCP a utilizar (por defecto 502). - Max. Conexiones Modbus TCP
La cantidad máxima de conexiones Modbus TCP simultáneas que acepta el RTU-X (por defecto 4). - Gateway Modbus
Define la interfaz de comunicaciones por defecto a la que se reenvían todos los mensajes Modbus cuyo destinatario no coincida con el Slave ID del RTU-X. Si se selecciona la opción "Sin gateway", el RTU-X responderá con mensaje de error a todos los paquetes Modbus que no sean para él. De lo contrario, los reenviará por el bus RS-485 dependiendo de cuál se haya seleccionado y luego reenviará la respuesta al remitente. Mediante esta funcionalidad, el RTU-X puede actuar de intermediario para que un cliente pueda comunicarse de forma transparente con un dispositivo conectado al bus RS-485 en los módulos de expansión.
¶ Módem
En la ventana de comunicaciones, en la pestaña “Módem, Bluetooth, NTP” se pueden configurar los parámetros relacionados al módem. El módem es un módulo opcional.
Los parámetros que se pueden configurar son:
- Red a utilizar
El usuario puede elegir entre distintos módulos, los cuales soportan 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
- Quectel BG95: LTE Cat-NB1 o LTE Cat-M1 con “down grade” a 2G.
- Encender módem al encender RTU-X
Este es el modo de funcionamiento normal en los casos que el RTU-X está siempre encendido y conectado a una fuente estable de alimentación. Si se deshabilita esta opción, es posible controlar el encendido y apagado del módem desde el script por medio de la variable modem_on. Este caso se suele usar en aplicaciones donde el consumo de energía es crítico, y se desea encender el módem por períodos cortos de tiempo solo para enviar la información almacenada en el log. - Aceptar conexiones entrante
Cuando esta opción es seleccionada, se el RTU-X acepta conexiones entrantes en el puerto 502 utilizado por la interfaz de usaurio. Por defecto esta opción está deshabilitada. - PIN
El PIN de la SIM si ésta lo requiere. - Utilizar GPS
Habilitar esta opción para habilitar el GPS. La información del GPS queda disponible en variables del script. - Utilizar SMS
Se debe habilitar esta opción si se desea enviar y recibir SMS. - Utilizar datos
Se debe habilitar esta opción para que el módem establezca la conexión de datos con el APN configurado. - Bandas LTE
Bandas a ser utilizadas cuando se utiliza LTE para la conexión a la red celular.
¶ Bluetooth
El RTU-X cuenta de base con conectividad BLE 4.2 que puede utilizarse para conectarse al equipo desde el software de configuración y también para actuar como maestro de otros dispositivos BLE, como sensores de temperatura y humedad.
En la ventana de comunicaciones, en la pestaña “Módem, Bluetooth, NTP” se pueden configurar los parámetros relacionados a Bluetooth.
Se debe seleccionar el nombre del dispositivo (será el nombre con el que se encuentre) y el pin de seguridad, que será solicitado a la hora de conectarse.
¶ NTP
En la ventana de comunicaciones, en la pestaña “Módem, Bluetooth, NTP” se puede establecer la configuración de un servidor NTP para la sincronización horaria.
Se debe seleccionar:
- Interfaz
Puede ser wi-fi, 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; como 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 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:
- JSON - Utiliza el formato JSON para el envío de los registros del log.
- Ultralight - Utiliza el formato Ultralight 2.0 para el envío de los registros de log.
- Predix - Utiliza el formato JSON compatible con el MQTT Data Collector de General Electric de acuerdo a lo establecido aquí.
- 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 professional de Thingsboard gestionada por Nettra.
- URI – Define el tipo de conexión, el servidor y el puerto. El URI debe tener el formato “equema://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
- Usuario, contraseña y client ID – De acuerdo al protocolo MQTT.
- Tópico de telemetría – Define el topic MQTT al que se envían los registros almacenados utilizando las funciones log y report del script para variables de tipo telemetry.
- Tópico de atributos – Define el topic MQTT al que se envían los registros almacenados utilizando las funciones log y report del script para variables de tipo attribute.
- Tópico de RPC - Define el topic MQTT al que se envian comando RPC (Remote Procedure Call).
- Watchdog – 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. Si el tiempo configurado es 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.
Para la opción de formato Thingsboard, solo se debe configurar el URI, usuario (token) que identifica al dispositivo de forma única en la plataforma y certificado (en caso de usar mqtts). Los tópicos están predeterminados. En los demás formatos los tópicos son definidos por el usuario.
Cuando se utilice la instancia Telemetry+ de Nettra, se debe seleccionar el formato Thingsboard y completar únicamente el usuario (token) que será proporcionado por Nettra. El URI y certificado son los valores que se cargan por defecto al seleccionar Thingsboard.
Cuando se habilita MQTT, los datos registrados mediante las sentencias log y report, son transmitidos utiizando este protoclo 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 topics
¶ 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:
| Variable | Detalle |
| model | RTU-X model (DIN o IP68) y versión de hardware |
| mac_wifi | Dirección MAC del módulo wifi. |
| ext1 | Información del módulo conectado en el sócalo de extensión 1. |
| ext2 | Información del módulo conectado en el sócalo de extensión 2. |
| modem_imei | IMEI del módem (si hay un módem presente en el sócalo de comunicación). |
| modem_imsi | IMSI 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:
| Variable | Detalle |
| battery | Porcentaje de batería. |
| battery_status | Estado de funcionamiento de la batería. Puede ser Charged, Charging o No power. |
| internal_temperature | Temperatura interna del RTU-X |
| modem_signal | Nivel de señal del módem en dBm. |
| wifi_signal | Nivel de señal wifi en dBm. |
¶ Publicación de telemetría
En la tabla siguiente se describe el formato de JSON que se transmite la telemetría mediante MQTT.
| Formato | Variable telemetry |
| JSON y Thingsboard |
donde XXX es el timestamp en UTC en formato unix en milisegundos de los registros |
| Ultralight 2.0 |
donde TTT es el timestamp en UTC en formato ISO8601 |
| Predix |
|
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
| Formato | Variable attribute |
| JSON y Thingsboard |
|
| Ultralight 2.0 |
|
| Predix |
|
¶
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ón | Descripción | Comando | Respuesta |
| set | Modifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valor |
|
|
| get | Consulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variable |
|
|
| resend_log | Solicita reenvío de los últimos N registros almacenados en el log de eventos |
|
|
| timezone | Define el timezone del RTU-X, donde N es el nuevo huso horario |
|
|
| reset | Produce un reset del RTU-X |
|
Sin respuesta |
¶ Formato JSON
| Función | Descripción | Comando | Respuesta |
| set | Modifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valor |
|
|
| get | Consulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variable |
|
|
| resend_log | Solicita reenvío de los últimos N registros almacenados en el log de eventos |
|
|
| unixtime | Define la hora del RTU-X en GMT-0. T es el instante actual en formato unix |
|
|
| localtime | Define la hora local del RTU-X a partir de año, mes, día, horas, minutos y segundos del instante actual |
|
|
| timezone | Define el timezone del RTU-X, donde N es el nuevo huso horario |
|
|
| reset | Produce un reset del RTU-X |
|
Sin respuesta |
¶ Formato Ultralight
| Función | Descripción | Comando | Respuesta |
| set | Modifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valor |
|
|
| get | Consulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variable |
|
|
| resend_log | Solicita reenvío de los últimos N registros almacenados en el log de eventos |
|
|
| unixtime | Define la hora del RTU-X en GMT-0. T es el instante actual en formato unix |
|
|
| localtime | Define la hora local del RTU-X a partir de año, mes, día, horas, minutos y segundos del instante actual |
|
|
| timezone | Define el timezone del RTU-X, siendo N el nuevo huso horario |
|
|
| reset | Produce un reset del RTU-X |
|
Sin respuesta |
¶ LoraWan
A partir de la versión 3.4.0, el RTU-X puede conectarse a una red LoraWan. Para ello, en el zócalo WAN se instala un módulo RAK3172 al que se le puede conectar una antena externa.
- Encender el módulo al encender el RTU-X
Este es el modo de funcionamiento normal en los casos que el RTU-X está siempre encendido y conectado a una fuente estable de alimentación. Si se deshabilita esta opción, es posible controlar el encendido y apagado del módulo desde el script por medio de la variable modem_on.
- Banda
Es posible seleccionar bandas entre US915 y AU915.
- Subbandas
Las subbandas habilitan canales tomados de a ocho. Es decir, 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
Permite seleccionar el data rate a utilizar de acuerdo a la banda seleccionada.
- ADR (Adaptive Data Rate)
Habilita o no esta funcionalidad.
- Confirmación
Habilita o no el envío de mensajes con solicitur de confirmación
- Claves y direcciones
Las claves y direcciones necesarios para establecer conexión con una red LoraWan (AppEUI, AppKEY en modo OTAA y DevADDR, NwksKEY, AppsKEY en ABP) debe ser definidas por el usuario. El devEUI del dispositivo es el definido por el fabricante del módulo y se obtiene en la pestaña principal cuando el módulo es 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
| Puerto | Descripción |
| 100 | Es utilizado para la publicación de datos almacenados en el log de eventos cuando se ejecutan las funciones log y report en el script |
| 101 | Se utiliza para publicar atributos de cliente, es decir, las variables declaradas como attribute en el script. |
| 102 | Se utiliza para recibir valores de atributos compartidos. |
| 103 | Se utiliza para solicitar la actualización de atributos compartidos |
| 104 | Se 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|valueNSiendo 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ón | Descripción | Comando | Respuesta |
| set | Modifica una variable de tipo telemetry, attribute o shared, donde NAME es el nombre de la variable y VALUE el valor |
|
|
| get | Consulta una variable telemetry, attribute o shared, donde NAME es el nombre de la variable |
|
|
| resend_log | Solicita reenvío de los últimos N registros almacenados en el log de eventos |
|
|
| unixtime | Define la hora del RTU-X en GMT-0. T es el instante actual en formato unix (*) |
|
|
| localtime | Define la hora local del RTU-X a partir de año, mes, día, horas, minutos y segundos del instante actual (*) |
|
|
| timezone | Define el timezone del RTU-X, siendo N el nuevo huso horario |
|
|
| reset | Produce un reset del RTU-X (*) |
|
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.
