0% encontró este documento útil (0 votos)
9 vistas63 páginas

documentacionAPI 1.2

El documento describe un sistema de tele gestión de luminarias que utiliza tecnología PLC sobre el estándar MODBUS, incluyendo sus elementos de hardware y software, así como su API de comunicaciones. Se detallan los componentes clave como el Driver LED SPLIT80, la pasarela de comunicaciones MTGSP_G y la plataforma de telegestión, además de las topologías disponibles para su implementación. La API permite la interacción con el sistema a través de peticiones HTTP/HTTPS, gestionando accesos y comandos para el control de luminarias y otros dispositivos.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
9 vistas63 páginas

documentacionAPI 1.2

El documento describe un sistema de tele gestión de luminarias que utiliza tecnología PLC sobre el estándar MODBUS, incluyendo sus elementos de hardware y software, así como su API de comunicaciones. Se detallan los componentes clave como el Driver LED SPLIT80, la pasarela de comunicaciones MTGSP_G y la plataforma de telegestión, además de las topologías disponibles para su implementación. La API permite la interacción con el sistema a través de peticiones HTTP/HTTPS, gestionando accesos y comandos para el control de luminarias y otros dispositivos.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

Descripción API

comunicaciones
sistema Telegestión
PLC sobre ModBus
AUTOR Revisión Comentarios Fecha

DAVID DOMINGUEZ 1.0 Versión Inicial 12/09/19


SANCHEZ incompleta

DAVID DOMINGUEZ 1.1 Versión Inicial 16/09/19


SANCHEZ completa

DAVID DOMINGUEZ 1.2 Se actualizan 27/07/20


SANCHEZ el mapa de
memoria del
modem

2 Rev 1.1
Tabla de contenido
1. Sistema de tele gestión Solar Power Innovations ................................................................ 5
2. Elementos del sistema .......................................................................................................... 6
2.1. Elementos Hardware ......................................................................................................... 6
2.1.1. Driver LED SPLIT80......................................................................................................... 6
2.1.2. Pasarela de comunicaciones MTGSP_G........................................................................ 6
2.1.3. Analizador de redes ....................................................................................................... 7
2.1.4. Servidor Internet ........................................................................................................... 8
2.2. Elementos Software .......................................................................................................... 8
2.2.1. API de comunicaciones de Solar Power ....................................................................... 8
2.2.2. Aplicación de instalación y puesta en marcha ............................................................. 8
2.2.3. Plataforma de telegestión............................................................................................. 9
3. Topologías............................................................................................................................ 10
3.1. Sistema estándar ............................................................................................................. 10
3.2. Sistema propietario ......................................................................................................... 10
4. Descripción API .................................................................................................................... 11
4.1. ApiSPLIT ........................................................................................................................... 11
4.1.1. Envío de peticiones hacia la API ................................................................................. 11
[Link]. Credenciales, tipos de usuario ................................................................................ 12
[Link]. ID pasarela ............................................................................................................... 12
[Link]. Parametros ModBus................................................................................................ 12
4.1.2. Recepción de respuestas desde la API........................................................................ 14
4.1.3. Limitaciones de las peticiones .................................................................................... 15
4.1.4. Formato de la trama.................................................................................................... 15
[Link]. READ_COILS: (Comando estándar) ......................................................................... 15
[Link]. READ_INPUTS: (Comando estándar) ...................................................................... 16
[Link]. READ_HOLDING_REGISTERS: (Comando estándar) ............................................... 17
[Link]. READ_INPUT_REGISTERS: (Comando estándar) .................................................... 18
[Link]. WRITE_COILS: (Comando estándar) ....................................................................... 19
[Link]. WRITE_HOLDING_REGISTERS: (Comando estándar) ............................................. 20
[Link]. WRITE_ID: (Comando no estándar) ........................................................................ 21
[Link]. SCAN: (Comando no estándar) ............................................................................... 22
4.1.5. Mensajes de error ....................................................................................................... 24

3 Rev 1.1
4.2. geoLoc .............................................................................................................................. 26
5. Mapa de memoria driver Led SPLIT80 ................................................................................ 27
6. Mapa de memoria de la pasarela MTGSP_G...................................................................... 41
7. Mapa de memoria del analizador de redes........................................................................ 53
8. Funciones de conversión de datos...................................................................................... 59
9. Permisos de los usuarios ..................................................................................................... 63

4 Rev 1.1
1. Sistema de tele gestión Solar Power Innovations
El sistema de tele gestión de Solar Power es un sistema de control de luminarias punto
a punto bidireccional que emplea tecnología PLC de banda estrecha sobre el estándar
de comunicación industrial MODBUS.

5 Rev 1.1
2. Elementos del sistema
Los elementos que componen el sistema son los siguientes:

2.1. Elementos Hardware


2.1.1. Driver LED SPLIT80
Elemento que debe ir ubicado en cada luminaria, por lo tanto en general
tendremos tantos driver LED SPLIT80 como luminarias haya en una instalación.
Las funciones de este dispositivo son:
Suministrar la alimentación requerida por los LEDs.
Dotar de comunicación PLC a la luminaria

2.1.2. Pasarela de comunicaciones MTGSP_G


Este elemento es único en cada instalación y su función es la de hacer de
interface entre los mensajes PLC, que se intercambian con las luminarias, y las
tramas TCP que se envían o reciben por internet.
La pasarela es trifásica y generalmente está ubicada en el cuadro general de
alimentación de la instalación.
Además de lo anteriormente mencionado, la pasarela dispone de los siguientes
canales de comunicación:
GPRS: es el canal principal de comunicación, y se utiliza para enviar y recibir
tramas MODBUS desde internet hacia las luminarias
BUS Modbus-485: desde este bus la pasarela puede ser controlada mediante
comandos ModBus provenientes de un autómata programable o cualquier otro
equipo electrónico compatible ModBus. Además en este bus se pueden
conectar un analizador de redes como veremos mas adelante.
BLUETOOTH: la pasarela dispone de un modulo de comunicación bluetooth,
cuya finalidad es la de configurar los parámetros de acceso a internet de la
pasarela.

6 Rev 1.1
2.1.3. Analizador de redes
Este elemento es único en cada instalación y aunque no es estrictamente
necesario para el funcionamiento del sistema* se considera muy recomendable
su uso para mejorar la eficiencia de las comunicaciones**.

Existen versiones monofásicas y trifásicas de este elemento por lo que


dependiendo de tipo de instalación se instalará una u otra.

Este elemento se conecta a la pasarela mediante el bus ModBus-485 y


proporciona todo tipo de información sobre la calidad de la señal de la red, asi
como datos de consumo y otros datos de funcionamiento del sistema.

* En caso de querer monitorizar el consumo de una instalación y generar informes e


históricos de consumo, no se puede prescindir de este elemento.
**La tecnología PLC de la pasarela es tal que a mayor corriente por fase menor
es la cantidad de comandos que se pueden enviar por minuto. En caso de

7 Rev 1.1
existir analizador de redes en una instalación, la pasarela puede conocer en
cada momento la corriente consumida por cada fase y adecuar así el número
de transmisiones por minuto de una manera optimizada al consumo en cada
instante. Sin embargo, si la instalación no dispone de analizador de redes, la
pasarela no conoce el consumo por lo que por seguridad tomara este valor
como el máximo posible repercutiendo esto en la capacidad de envío de
mensajes por minuto.

2.1.4. Servidor Internet


En el servidor será donde se ejecutaran algunos de los elementos software que
se describen en el siguiente apartado. Este servidor como se verá más adelante
en este documento puede pertenecer a Solar Power o bien pertenecer
terceros.

2.2. Elementos Software


2.2.1. API de comunicaciones de Solar Power
La API de comunicaciones de Solar Power es un conjunto de programas, bases
de datos, servicios y otros recursos informáticos corriendo en un servidor, a la
cual se puede acceder mediante http o https, y a la que se le pueden lanzar
consultas dirigidas a un elemento o a un grupo de elementos dentro de una
instalación. Estos elementos pueden ser las luminarias, la pasarela de
comunicaciones o el analizador de redes descritos anteriormente.
Estas consultas no podrán ser enviadas por cualquier usuario de la red ya que
se requiere una autenticación.
Tras una consulta, válida o no, el API responde a través de http o https una
cadena de texto con la respuesta a dicha consulta. Para más detalles sobre el
funcionamiento de la API consultar el apartado específico de este documento
denominado “Descripcion API”.
Dependiendo de la topología elegida por cada cliente, esta API podrá residir en
un servidor de Solar Power o bien residir en servidores propiedad del cliente.

2.2.2. Aplicación de instalación y puesta en marcha


Esta aplicación se ejecuta en un teléfono móvil Android y es utilizada por los
técnicos responsables de cada instalación para indicar al sistema la ubicación
GPS de cada una de las luminarias así como la ubicación del cuadro eléctrico
donde se encuentra la pasarela de comunicación. Esta aplicación se utiliza

8 Rev 1.1
también para verificar los números de serie de cada luminaria y para configurar
los parámetros de conexión a internet de la pasarela utilizando una conexión
bluetooth.
Esta aplicación utiliza funciones y servicios de la API y aunque está desarrollada
por Solar Power y es de uso gratuito, el cliente podría desarrollar su propia
aplicación personalizada utilizando los recursos proporcionados por la API.

2.2.3. Plataforma de telegestión


La plataforma es el conjunto de páginas web que utilizando los servicios y
funciones de la API y nutriéndose de los datos almacenados en ésta, permite al
usuario final manejar sus instalaciones, bien consultando información en
tiempo real, enviando configuraciones o consultando históricos de
funcionamiento.
Aunque existe una plataforma desarrollada por Solar Power que puede ser
utilizada libremente por los clientes, también existe la posibilidad de que el
cliente desarrolle su propia plataforma apoyándose en la API de Solar Power.

9 Rev 1.1
3. Topologías

En función de cada cliente y de las necesidades del mismo, este puede elegir la
topología del sistema de tele gestión con el que más cómodo se sienta y que
más se ajuste a sus necesidades. Algunos de los criterios para elegir una u otra
topología son:
Conocimientos técnicos para desarrollar aplicaciones WEB y APPs, y
disponibilidad de recursos.
Necesidad de disponer de una solución completa en un tiempo determinado.
Nivel de control deseado de los datos y de acceso a los programas
Necesidades especificas no cubiertas por las soluciones existentes

3.1. Sistema estándar


En esta topología tanto la API como la plataforma corren en los servidores de
Solar Power. Al APP de instalación también es la desarrollada por Solar Power.
Esta solución es adecuada para usuarios que no quieran hacer desarrollos y
adopten la solución existente. No es necesario ningún trabajo previo a las
instalaciones.

3.2. Sistema propietario


En esta topología tanto la API como la plataforma corren en los servidores del
cliente. Al APP de instalación también deberá ser desarrollado por el cliente.
Esta solución es adecuada para usuarios que quieran personalizar el diseño de
la plataforma web y la aplicación. Esta solución además permite la integración
con otros sistemas de tele gestión que pueda utilizar el cliente. Todos los datos
tanto de usuarios como ubicaciones de luminarias y configuraciones, residirían
en las bases de datos propiedad del cliente por lo que el acceso y control a los
datos también es mucho más personalizado.

10 Rev 1.1
4. Descripción API
Como se indicó anteriormente la API se accede mediante http o https, y se utilizan las
URLs de los servicios que se quieren utilizar. Existen dos servicios independientes, uno
es el que se utiliza para las consultas realizadas desde la plataforma, llamado ApiSPLIT
y requiere como argumentos los parámetros que se usan en el protocolo modbus, y
otro servicio más enfocado a APP móviles de instalación, denominado geoLoc, que
permite ubicar las luminarias y la pasarela y además permite mandar ordenes de test a
luminarias concretas para comprobar en campo la correcta instalación de cada punto
de luz.

ApiSPLIT: Enfocada a la explotación de la plataforma. En el caso de usar los


servidores de solar power esta se encuentra en la siguiente URL:
[Link]/telegestion/Services/[Link]
geoLoc: Enfocada al desarrollo de app móviles. En el caso de usar los servidores
de solar power esta se encuentra en la siguiente URL:
[Link]/telegestion/Services/[Link]

4.1. ApiSPLIT

4.1.1. Envío de peticiones hacia la API


La forma de interactuar con la API es mediante los parámetros enviados en la URL de
llamada. Los parámetros necesarios son las credenciales de acceso, el identificador de
la pasarela con la que queremos conectar y los parámetros del comando ModBus que
queremos usar. Estos últimos parámetros hace que la comunicación con la API utilice
un pseudo protocolo modbus ya que no se trata de modbus estándar, aunque las
tramas tcp/ip entre pasarela y servidor si utilizan dicho estandar.

Nombre
Tipo parámetro Valores Comentarios
parámetro
Usuario
autorizado para
el comando y la
user Usuario
pasarela que
Credenciales queremos
utilizar
Password del
password Password usuario
autorizado
ID pasarela imei xxxxxxxxxxxxxxx Id de la

11 Rev 1.1
pasarela que
coincide con el
imei del
modulo GPRS
de la misma
Grupo del
group 0-16
dispositivo
Dispositivo
device 0-15 dentro del
grupo
Parámetros de Id del
READ_COIL,
comando commando
command WRITE_COIL,
ModBus ModBus que
READ_INPUT,…
queremos usar
Datos del
Datos
comando
data requeridos por
indicados por
cada command
Modbus

[Link]. Credenciales, tipos de usuario


Existen diferentes tipos de usuarios que permiten diferentes acciones sobre las
instalaciones. Así por ejemplo un usuario tipo administrador tendrá permitido
cualquier comando a cualquier elemento de la instalación mientras un usuario
de tipo usuario no tendrá por ejemplo permitido cambiar la corriente máxima
que puede entregar un driver SPLIT80. Los usuarios definidos son:
administrador,usuario e instalador. Para más información, ver el capitulo,
“Permisos de los usuarios”
Por otro lado cada usuario tendrá permitidas unas instalaciones determinadas
de tal manera que un usuario de un cliente no pueda manejar las instalaciones
de otro cliente que no esté relacionado con él.
El usuario y la contraseña son introducidos en la API mediante los parámetros
‘user’ y ‘password’ de la url respectivamente.

[Link]. ID pasarela
Es el identificador de la pasarela de comunicación MTGSP_G con la que
queremos conectar y se indica mediante el parámetro ‘imei’ de la url. Este
identificador coincide con el imei del modulo GPRS integrado en la misma y es
esta impreso en la etiqueta del equipo.

[Link]. Parametros ModBus

12 Rev 1.1
Una vez que el usuario y contraseña son correctos y que se dispone del
identificador de la pasarela a la que se quiere enviar comandos es el momento
de indicar el identificador del equipo o del conjunto de equipos dentro de la
instalación a la que nos dirigimos. Dependiendo de la combinación de los
parámetros ‘group’ y ‘device’ de la url, podemos comunicar con un driver SPLIT
80, con un grupo de drivers SPLIT80, con todos los drivers SPLIT80, con el
analizador de redes o con la pasarela de comunicaciones MTGSP_G. Es
importante destacar que no están permitidas consultas de datos (lecturas) a
grupos ya que el protocolo no permite multi-casting y no se puede recibir
información de más de un dispositivo al mismo tiempo. Los comandos a grupos
o broadcast están pensados para enviar órdenes (escrituras, siempre que el
valor que indiquemos sea editable como es un coil o un holding register) pero
no para recibir información (lecturas).

Element
Permitid Permitid
Valor Valor os
Tipo o o
GROUP DEVICE Afectado
Escritura Lectura
s
Todos
Broadcast los
0 --
total drivers
SPLIT80
Drivers
SPLIT80
cuyo
Broadcast grupo
[1-15] 0
grupal coincide
con el
especific
ado
Driver
SPLIT80
cuyo
grupo y
Comando dispositi
[1-15] [1-15]
individual vo
coincide
n con el
especific
ado
Analizador Analizad
16 1
redes or de

13 Rev 1.1
redes
Pasarela
de
Pasarela comunic
16 6
telegestión aciones
MTGSP_
G

Respecto a los parámetros ‘command’ y ‘data’, indicar que el segundo no es un


parámetro en sí, si no un conjunto de parámetros cuyo significado y tamaño
dependen del primero, y que se ajusta a la definición de los comandos modBus
según la siguiente tabla:

data
command
Campo1 Campo2 Campo3 Campo4 Campo5 Campo6
READ_COILS start quantity -- -- -- --
READ_INPUTS start quantity -- -- -- --
Comandos READ_HOLDING_REGISTERS start quantity -- -- -- --
estandar READ_INPUT_REGISTERS start quantity -- -- -- --
WRITE_COILS start quantity data0 data1 >> dataN
WRITE_HOLDING_REGISTERS start quantity data0 data1 >> dataN
Comandos WRITE_ID data0 data1 data2 data3 data4 --
personalizdos SCAN start quantity -- -- -- --

4.1.2. Recepción de respuestas desde la API

Respecto a la respuesta emitida desde la API, esta es un texto plano encerrado


entre ‘{‘ y ‘}’ con una o varias de las siguientes parejas clave-valor:
Clave Valor
targetDevice Identifica el ID modbus del
elemento al que se dirigió el
comando
fCode Nombre del comando modbus
al que pertenece la respuesta
data Array de bytes que ha emitido el
protocolo ModBus como
respuesta
group Grupo del elemento al que
pertenece la respuesta
device Dispositivo del elemento al que
pertenece la respuesta
dataX Información procesada obtenida
de la clave anterior ‘data’ que
hace más sencilla la lectura de la
respuesta. Por ejemplo
descomposición de los valores de
cada coil individualmente en vez

14 Rev 1.1
de leer los diferentes bits de uno
de los bytes de respuesta
fuenteX Información sobre un driver
concreto en una orden de scan
errorMsj Identifica la causa que ha
provocado el error

4.1.3. Limitaciones de las peticiones


Comandos de escritura en las fuentes: 8 REGISTROS POR COMANDO MAXIMO
Los IGBTs del modem se calientan transmitiendo tantos datos (el calentamiento
depende de la carga).
La fuente llena su fifo de escrituras en diferido si los registros están en
EEPROM.
COMANDO LECTURA DE FUENTES: 16 REGISTROS POR COMANDO MAXIMO
El transmisor de la fuente se calienta al tener el transistor conectado mucho
rato.

4.1.4. Formato de la trama


En este apartado se mostrara un ejemplo de envío a la API de cada uno de los
tipos de comando cada uno con sus parámetros correspondientes. Para
conocer el significado de de cada coil, input y registro, consulte los capítulos
‘Mapa de memoria del driver led SPLIT80’, ‘Mapa de memoria de la pasarela
MTGSP_G’ y ‘Mapa de memoria del analizador de redes’ respectivamente.

[Link]. READ_COILS: (Comando estándar)


Campos petición
• user: usuario que realiza la petición
• password: password del usuario
• imei: identificador de la pasarela
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• command: READ_COILS
• start: Dirección del primer coil a leer
• quantity: Cantidad de coils a leer

Campos de la respuesta
• targetDevice: id Modbus del elemento destino
• fCode: READ_COILS

15 Rev 1.1
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• data: nº de bytes con información de los coils seguido de dichos bytes
(ModBus)
• data0: Estado del primer coil leído
• data1: Estado del segundo coil leído
• data(N-1): Estado del n-simo coil leído

EJEMPLO:

Lectura de 2 coils empezando desde el 0 de la luminaria con grupo 1


dispositivo 1 de la instalación cuya pasarela tiene el imei 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?u
ser=usuarioDemo&password=1111&imei=869286032284418&group=1&de
vice=1&command=READ_COILS&start=0&quantity=2

RESPUESTA
{"targetDevice":1,"fCode":"READ_COILS","data":[1,0],"group":1,"device":1,
"data0":0,"data1":0,"data2":0,"data3":0,"data4":0,"data5":0,"data6":0,"dat
a7":0}

[Link]. READ_INPUTS: (Comando estándar)


Campos petición
• user: usuario que realiza la petición
• password: password del usuario
• imei: identificador de la pasarela
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• command: READ_INPUTS
• start: Dirección del primer input a leer
• quantity: Cantidad de inputs a leer

Campos de la respuesta
• targetDevice: id Modbus del elemento destino
• fCode: READ_INPUTS
• group: grupo del elemento destino

16 Rev 1.1
• device: dispositivo del elemento destino
• data: nº de bytes con información de los inputs seguido de dichos bytes
(ModBus)
• data0: Estado del primer input leído
• data1: Estado del segundo input leído
• data(N-1): Estado del n-simo input leído

EJEMPLO:

Lectura de 1 input empezando desde el 3 de la luminaria con grupo 6


dispositivo 4 de la instalación cuya pasarela tiene el imei 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?u
ser=usuarioDemo&password=1111&imei=869286032284418&group=6&de
vice=4&command=READ_INPUTSS&start=3&quantity=1

RESPUESTA
{"targetDevice":84,"fCode":"READ_INPUTS","data":[1,0],"group":6,"device"
:4,"data0":0,"data1":0,"data2":0,"data3":0,"data4":0,"data5":0,"data6":0,"
data7":0}

[Link]. READ_HOLDING_REGISTERS: (Comando estándar)


Campos petición
• user: usuario que realiza la petición
• password: password del usuario
• imei: identificador de la pasarela
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• command: READ_HOLDING_REGISTERS
• start: Dirección del primer holding register a leer
• quantity: Cantidad de holding registers a leer

Campos de la respuesta
• targetDevice: id Modbus del elemento destino
• fCode: READ_HOLDING_REGISTERS
• group: grupo del elemento destino
• device: dispositivo del elemento destino

17 Rev 1.1
• data: nº de bytes con información de los holding registers seguido de
dichos bytes (ModBus)
• data0: Valor del primer byte leído*
• data1: Valor del segundo byte leído*
• data(N-1): Valor del n-simo byte leído*

*:
Los valores leídos desde los holding registers son los valores crudos
almacenados en memoria. Para dotar de significado a esos valores en función
del tipo de parámetro que estemos leyendo deberemos aplicar las
conversiones aplicadas en el capítulo correspondiente.

EJEMPLO:

Lectura de 1 holding register empezando desde el 2 de la luminaria con grupo 1


dispositivo 2 de la instalación cuya pasarela tiene el imei 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?user=
usuarioDemo&password=1111&imei=869286032284418&group=1&device=2&
command=READ_HOLDING_REGISTERS&start=2&quantity=1

RESPUESTA
{"targetDevice":2,"fCode":"READ_HOLDING_REGISTERS","data":[2,0,26],"group
":1,"device":2,"data0":0,"data1":26}

[Link]. READ_INPUT_REGISTERS: (Comando estándar)


Campos petición
• user: usuario que realiza la petición
• password: password del usuario
• imei: identificador de la pasarela
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• command: READ_INPUT_REGISTERS
• start: Dirección del primer input register a leer
• quantity: Cantidad de input registers a leer

Campos de la respuesta
• targetDevice: id Modbus del elemento destino
• fCode: READ_INPUT_REGISTERS
• group: grupo del elemento destino

18 Rev 1.1
• device: dispositivo del elemento destino
• data: nº de bytes con información de los input registers seguido de
dichos bytes (ModBus)
• data0: Valor del primer byte leído*
• data1: Valor del segundo byte leído*
• data(N-1): Valor del n-simo byte leído*

*:Los valores leídos desde los input registers son los valores crudos
almacenados en memoria. Para dotar de significado a esos valores en función
del tipo de parámetro que estemos leyendo deberemos aplicar las
conversiones aplicadas en el capítulo correspondiente.

EJEMPLO:

Lectura de 2 input register empezando desde el 0 del analizador de redes de la


instalación cuya pasarela tiene el imei 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?user=
usuarioDemo&password=1111&imei=869286032284418&group=16&device=1
&command=READ_INPUT_REGISTERS&start=0&quantity=2

RESPUESTA
{"targetDevice":241,"fCode":"READ_INPUT_REGISTERS","data":[4,67,100,95,12
1],"group":16,"device":1,"data0":67,"data1":100,"data2":95,"data3":121}

[Link]. WRITE_COILS: (Comando estándar)


Campos petición
• user: usuario que realiza la petición
• password: password del usuario
• imei: identificador de la pasarela
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• command: WRITE_COILS
• start: Dirección del primer coil a escribir
• quantity: Cantidad de coils a escribir
• data0: Valor del primer coil a escribir
• data1: Valor del segundo coil a escribir
• data(N-1): Valor del n-simo coil a escribir

19 Rev 1.1
Campos de la respuesta
• targetDevice: id Modbus del elemento destino
• fCode: WRITE_COILS
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• data: primeros dos bytes indican la dirección de inicio y los otros dos
indican la cantidad de coils escritas (ModBus)

EJEMPLO:

Escritura en 1 de 1 coil empezando desde el 0 de la pasarela de comunicaciones


cuyo imei es 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?user=
usuarioDemo&password=1111&imei=869286032284418&group=16&device=6
&command=WRITE_COILS&start=0&quantity=1&data0=1

RESPUESTA
{"targetDevice":246,"fCode":"WRITE_COILS","data":[0,0,0,1],"group":16,"devic
e":6}

[Link]. WRITE_HOLDING_REGISTERS: (Comando estándar)


Campos petición
• user: usuario que realiza la petición
• password: password del usuario
• imei: identificador de la pasarela
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• command: WRITE_HOLDING_REGISTERS
• start: Dirección del primer holding register a escribir
• quantity: Cantidad de holding registers a escribir
• data0: Valor crudo del primer holding register a escribir*

*: Los valores escritos en los holding registers son los valores crudos
almacenados en memoria. Para pasar de valores con significado a esos valores
crudos en función del tipo de parámetro que estemos leyendo deberemos
aplicar las conversiones aplicadas en el capítulo correspondiente.

Campos de la respuesta
• targetDevice: id Modbus del elemento destino

20 Rev 1.1
• fCode: WRITE_HOLDING_REGISTERS
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• data: vacio (ModBus)

EJEMPLO:

Escritura en 7 de 1 holding register empezando desde el 0, del grupo 1 de la


pasarela de comunicaciones cuyo imei es 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?user=
usuarioDemo&password=1111&imei=869286032284418&group=1&device=0&
command=WRITE_HOLDING_REGISTERS&start=52&quantity=1&data0=7

RESPUESTA
{"targetDevice":16,"fCode":"WRITE_HOLDING_REGISTERS","data":[],"group":1,
"device":0}

[Link]. WRITE_ID: (Comando no estándar)


Este comando se utiliza para asignar un grupo y un dispositivo a una driver
SPLIT80 concreto. Para ello se identifica el driver utilizando su número MAC,
que es un identificador único que el driver adquiere en fábrica y será el mismo
para toda la vida del mismo. Tanto el grupo y el dispositivo asignado a un driver
deben estar comprendidos entre 1 y 15, no pudiendo ser en ningún caso 0. El
grupo 16 está reservado para otros elementos de la instalación como son el
analizador de redes, grupo 16 dispositivo 1, y la propia pasarela de
comunicación, grupo 16 dispositivo 6. Los identificadores de estos dos
elementos no pueden ser cambiados.
Campos petición
• user: usuario que realiza la petición
• password: password del usuario
• imei: identificador de la pasarela
• group: 0 (Este comando solo admite broadcast)
• device: 0 (Este comando solo admite broadcast)
• command: WRITE_ID
• start: 0 (Este comando no usa este parámetro)
• quantity: 0 (Este comando no usa este parámetro)
• data0: Valor más alto de la MAC del driver SPLIT80*
• data1: Valor intermedio de la MAC del driver SPLIT80*
• data2: Valor más bajo de la MAC del driver SPLIT80*

21 Rev 1.1
• data3: 0
• data4: ID ModBus corespondiente al group y device que queremos
asignar, según la siguiente fórmula:
𝑰𝑫𝑴𝒐𝒅𝑩𝒖𝒔 = 𝟏𝟔𝒙(𝒈𝒓𝒐𝒖𝒑 − 𝟏) + 𝒅𝒆𝒗𝒊𝒄𝒆

*:La MAC del driver SPLIT80, es un código único para cada unidad de este
modelo y que no puede ser modificado. Está escrito en la superficie del driver
en un código de barras. Es el identificador básico a partir del cual se crea el
identificador group y device, utilizado por el usuario final.

Campos de la respuesta
• targetDevice: 0
• fCode: WRITE_HOLDING_REGISTERS
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• data: vacio

EJEMPLO:

Asignar el grupo 1 y dispositivo 1 a la luminaria con el driver SPLIT80 cuya MAC


es 00-00-61 sabiendo que esta se encuentra en la pasarela de comunicaciones
cuyo imei es 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?user=
usuarioDemo&password=1111&imei=869286032284418&group=0&device=0&
command=WRITE_ID&start=0&quantity=0&data0=0&data1=0&data2=61&data
3=0&data4=1

RESPUESTA
{"targetDevice":0,"fCode":"WRITE_ID","data":[],"group":0,"device":0}

[Link]. SCAN: (Comando no estándar)


La función de scan se utiliza para hacer un barrido rápido del estado de todos
los drivers SPLIT80 de una instalación determinada (típicamente <10s), y es un
comando dirigido a la plataforma, no a los drivers. Este barrido entrega la
siguiente información:
Presencia de drivers sin asignación de grupo y dispositivo
Presencia o ausencia del driver
Fase en la que se encuentra conectado
22 Rev 1.1
Indicador si se ha respetado la indicación de fase y neutro en el conexionado de
entrada
Duplicidad de un identificador ModBus en diferentes drivers de diferentes fases

Respecto a la respuesta ModBus, obtenemos una cadena de bytes indicando en


el primero de ellos el número de bytes que recibiremos a continuación con la
información solicitada.
Cada uno de estos bytes almacena la información de 2 drivers SPLIT80, cada
una contenida en uno de los nibbles del byte de la siguiente manera:

BYTE
NIBBLE ALTO NIBBLE BAJO
Información fuente N Información fuente N+1
Fase de
Inversión F-N Detección Fase de detección Inversión F-N Detección
detección
00: Fase R 00: Fase R
0: OK 0: No detectada 01: Fase S 0: OK 0: No detectada 01: Fase S
1: INVERTIDAS 1: Detectada 10: Fase T 1: INVERTIDAS 1: Detectada 10: Fase T
11:Multiples fases 11:Multiples fases

Para simplificar esta lectura de bits y nibbles, la API devuelve una pareja clave-
valor por cada driver solicitado, identificada con la clave “fuenteN”, y tres
valores denominados, “encontrada”, “fase” e “invertida” que hace más sencilla
la interpretación.
IMPORTANTE: Como cada byte muestra dos fuentes siempre tendremos un
número par de claves “fuenteN” aunque hayamos pedido un número impar de
fuentes a escanear. Por ejemplo, pedimos 3 fuentes y la API nos devuelve 4
fuentes aunque la última será con todos los campos a 0

Por último aclarar que las claves “fuenteN” comienzan a numerarse con los
datos del primer driver SPLIT80 solicitado en la petición (ver campo “start” de
la petición). Las fuentes con identificador ModBus múltiplo de 16 siempre se
mostrarán como no encontradas porque es un identificador no valido en el
sistema de grupo, dispositivo utilizado en este sistema, ya que estos
identificadores se reservan internamente para identificar comandos dirigidos a
un grupo determinado. Si se detecta la luminaria con identificador ModBus=0
es una indicación de que hay drivers SPLIT80 en el sistema en el que no se ha
asignado el grupo y dispositivo teniendo que resolver esta situación antes de
que se pueda considerar que el sistema está completamente configurado.

Campos petición
• user: usuario que realiza la petición

23 Rev 1.1
• password: password del usuario
• imei: identificador de la pasarela
• group: 16
• device: 6
• command: SCAN
• start: Identificador Modbus del primer driver del que queremos hacer el
scan
• quantity: Número de drivers a scanear

Campos de la respuesta
• targetDevice: id Modbus del elemento destino
• fCode: SCAN
• group: grupo del elemento destino
• device: dispositivo del elemento destino
• fuenteN: Datos de la fuente n-sima. Encontrada o no, invertida o no y
fase en caso de ser encontrada.

EJEMPLO:

Escanear 3 drivers SPLIT80 empezando desde el identificador ModBus 1 de la


instalación cuya pasarela de comunicaciones tiene el imei 869286032284418

PETICIÓN
[Link]/telegestion/Services/[Link]?user=
usuarioDemo&password=1111&imei=869286032284418&group=16&device=6
&command=SCAN&start=1&quantity=3

RESPUESTA
{"targetDevice":246,"fCode":"SCAN,"data":[2,68,64],"group":16,"device":6,"fue
nte0":{"encontrada":true,"fase":"R","invertida":false},"fuente1":{"encontrada":
true,"fase":"R","invertida":false},"fuente2":{"encontrada":true,"fase":"R","inve
rtida":false},"fuente3":{"encontrada":false}}

4.1.5. Mensajes de error

En el caso en el que la API detecte algún error en el momento de recibir la


respuesta a una trama determinada, obtendremos entre otras, la pareja clave-
valor “errorMsj” , con un mensaje indicando la causa de dicho error. El
programador debe por tanto comprobar si esta pareja de clave-valor existe en

24 Rev 1.1
la respuesta obtenida y en caso de no obtenerla puede tener la certeza de que
la respuesta no contiene errores.
Los códigos de error que la API arroja son:
Tipo de
ID Mensaje de error Comentario
error
"ERROR: No hemos
-1 encontrado credenciales de
Errores del servidor.
acceso"
Validación Consultar con
"ERROR: Fallo en la conexión
BBDD -2 con la BD"
administrador del
sistema
"ERROR: Fallo al seleccionar
-3 la BD"
El comando solicitado
"ERROR: Comando no es ninguno de los
-1 desconocido" descritos
anteriormente
El usuario o la
"ERROR: Tipo de usuario
-2 desconocido"
contraseña no son
correctos
El usuario es válido
"ERROR: Usuario no tiene
pero no tiene
Validación -3 permiso para ejecutar este
autorizado el comando
comando"
de solicitado
Comando Usuario y comando
"ERROR: Registro no validos pero se ha
-4 encontrado" indicado un registro no
definido en el sistema
El usuario, el comando
y el registro son válidos
"ERROR: Usuario no tiene
pero el usuario no
-5 permiso para acceder a este
tiene acceso al registro
registro"
utilizando ese
comando
"Excepción de código de Similar a comando
ModBus 1 función" desconocido
La dirección del
2 "Excepción de dirección"
registro es errónea
No se ha indicado
todos los datos
3 "Excepción de datos"
necesarios de un
comando
La pasarela no ha
"Excepción fallo de
4 dispositivo"
podido ejecutar el
comando solicitado
La pasarela ha recibido
"Excepción de timeout de
5 modem"
el comando pero no ha
respondido
"ERROR: Modem no La pasarela no está
6 operativo" conectada a la red
La pasarela está
"ERROR: Modem ocupado,
7 inténtelo más tarde"
atendiendo a otra
petición.
"ERROR: No se puede abrir la
8 fifo para escribir" Errores del servidor.
"ERROR: No se puede escribir Consultar con
9 la fifo" administrador del
"ERROR: No se puede abrir la sistema
10 fifo para leer"

25 Rev 1.1
"ERROR: Excepción de
11 timeout de servidor"
"ERROR: Mensaje de La respuesta no es
12 respuesta erróneo" como se esperaba
"ERROR: Acceso no Error de usuario y
API -1 permitido" contraseña
API bloqueada por
"ERROR: Demasiados errores acceso erróneo
-2 de acceso" recursivo. Esperar
tiempo indicado
El imei indicado no
-3 "ERROR: IMEI no valido" pertenece a ninguna
pasarela
No se ha indicado el
"ERROR: No se ha indicado
-4 comando"
comando que se quiere
ejecutar
"ERROR: Grupo o dispositivo Group o device no son
-5 no valido" correctos
No se han introducido
"ERROR: Argumentos de
-6 comando erróneos"
los argumentos
esperados
El comando
"ERROR: Comando introducido no es
-7 desconocido" ninguno de los
esperados

4.2. geoLoc
pendiente

26 Rev 1.1
5. Mapa de memoria driver Led SPLIT80
NOTA: Tanto los nombres de registros como de coils o inputs que comienzan por ‘EE_’, hacen referencia a valores permanentes es decir
no pierden su valor por el hecho de encender y apagar el equipo. El resto de valores son volátiles y solo aplican hasta el siguiente
apagado o reset, momento en el cual perderán su valor y volverán a valores por defecto tras el nuevo arranque

CONVERSION
ACCESS ZONE ID EEPROM RAM NAME DESCRIPCIÓN
FUNCTION
0x00 RESERVED
REG 0 toByte()
0x01 RESERVED
0x02 EE_K
REG 1
0x03 -- Valor interno relacionado con la calibración
cteK()
0x04 -- de corriente a 230Vac
REG 2
0x05 --
0x06 EE_K110
REG 3
0x07 -- Valor interno relacionado con la calibración
INPUT REGISTERS

cteK()
0x08 -- de corriente a 110Vac
READ ONLY

REG 4
0x09 --
0x0A EE_ID_FABRICA
REG 5
0x0B --
idFabrica() MAC del equipo
0x0C --
REG 6
0x0D --
0x0E EE_ID_INSTALACION
REG 7 idInstalacion() Identificador ModBus del disposistivo
0x0F --
0x10 EE_VERSION_SW
REG 8
0x11 --
vSw() Versión de software del dispositivo
0x12 --
REG 9
0x13 --

27 Rev 1.1
REG 0x14 EE_VERSION_HW
vHw() Versión de hardware del dispositivo
10 0x15 --
REG 0x16 EE_CAL_TEMP
toByte() Calibración del sensor de temperatura
11 0x17 --
REG 0x18 EE_CAL_LUZ,
toByte() Calibración de la función de luz constante
12 0x19 --
REG 0x1A EE_CAL_MULTIMODULO
vdc() Calibración de la función multi-modulo
13 0x1B --
REG 0x1C EE_TEMP Temperatura del equipo en el momento del
temperatura()
14 0x1D -- apagado anterior
REG 0x1E EE_ARRANQUES
toInt() Contador de arranques del sistema
15 0x1F --
REG 0x20 EE_SEGUNDOS
16 0x21 -- Contador total de segundos de
segundosLargo()
REG 0x22 -- funcionamiento del sistema
17 0x23 --
REG 0x24 EE_MINUTOS100
Contador total de minutos que el sistema ha
18 0x25 --
minutosLargo estado encendido con un dimmado superior
REG 0x26 --
al 80%
19 0x27 --
0x28 EE_MIN_ANT Contador de minutos que duro el ultimo
REG
toInt() encendido (día anterior) solo si este fue
20 0x29 --
superior a 6 horas
REG 0x2A EE_SOBRE_VOLTAJES Contador total de errores de sobre voltaje en
toInt()
21 0x2B -- la entrada
REG 0x2C EE_PICOS_DE_VOLTAJE Contador total de errores de picos
toInt()
22 0x2D -- transitorios de voltaje
REG 0x2E EE_SOBRE_POTENCIA toInt() Contador total de protecciones por sobre-

28 Rev 1.1
23 0x2F -- potencia
REG 0x30 EE_SOBRE_TEMPERATURA Contador total de protecciones de sobre-
toInt()
24 0x31 -- temperatura
REG 0x32 EE_CIRCUITOS_ABIERTOS, Contador total de errores de circuitos abierto
toInt()
25 0x33 -- en el lado de la carga
REG 0x34 EE_CORTOCIRCUITOS Contador total de errores de cortocircuitos
toInt()
26 0x35 -- en el lado de la carga
REG 0X36 0xFF
27 0X37 0xFF
REG 0X38 0xFF
28 0X39 0xFF
REG 0X3A 0xFF
29 0X3B 0xFF
REG 0X3C 0xFF
30 0X3D 0xFF
REG 0X3E 0xFF
31 0X3F 0xFF
REG 0x40 0xFF
32 0x41 0xFF
REG 0x42 0xFF
33 0x43 0xFF
REG 0x44 0xFF
34 0x45 0xFF
REG 0x46 0xFF
35 0x47 0xFF
REG 0x48 0xFF
36 0x49 0xFF
REG 0X4A 0xFF

29 Rev 1.1
37 0X4B 0xFF
REG 0X4C 0xFF
38 0X4D 0xFF
REG 0X4E 0xFF
39 0X4F 0xFF
REG
40 – 0X50- Descripción de las 4 curvas de consumo no
Patrones 1,2,3 y 4 fijos patron()
REG 0X8F personalizables
71
REG 0x00 tred
frecuencia() Frecuencia de red leída por el sistema
72 0x01 --
REG 0x02 temp
temperatura() Temperatura del sistema
73 0x03 --
REG 0x04 Vip
vac() Voltaje de red leído por el equipo
74 0x05 --
REG 0x06 vledsm
vdc() Voltaje de los leds leído por el sistema
75 0x07 --
REG 0x08 minutero
toInt() Minutos desde el encendido en curso
76 0x09 --
0x0A SegDimadoDigital Segundos que el sistema ha estado dimado
REG
toInt() debido a la señal digital, en el encendido en
77 0x0B --
curso
REG 0x0C contDigital Contador del numero de activaciones de la
toInt()
78 0x0D -- entrada digital, en el encendido en curso
0x0E dimado Nivel de dimmado actual, bien sea porque el
REG
dimmado() dimmado esta forzado, se está ejecutando un
79 0x0F --
patrón o escena o esta activa la señal digital.
REG 0x10 patron toByte() Patrón en ejecución. 0 para indicar que no se

30 Rev 1.1
80 0x11 -- está ejecutando ninguno.
0x12 msjsOK Mensajes recibidos correctamente por PLC,
REG
toInt() fueran o no dirigidos al equipo en el
81 0x13 --
encendido en curso
REG 0x14 msjsAtendidos Mensajes recibidos correctamente por PLC
toInt()
82 0x15 -- dirigidos al equipo en el encendido en curso
REG 0x16 erroresCRC Errores de CRC detectados en la
toInt()
83 0x17 -- comunicación PLC en el encendido en curso
REG 0x18 erroresParidad Errores de paridad detectados en la
toInt()
84 0x19 -- comunicación PLC en el encendido en curso
REG 0x1A erroresFraming Errores de framing detectados en la
toInt()
85 0x1B -- comunicación PLC en el encendido en curso
REG 0x1C causasArranque
toInt() Bits de estado del último arranque
86 0x1D --
REG 0x1E potenciaEntregada Estimación de potencia consumida por la
potenciaOut()
87 0x1F -- fuente
REG 0x20 0x00
88 0x21 0x00
INPUT 0X90 EE_INPUTS1
0-15 0X91 --
INPUT 0X92 EE_INPUTS2
INPUTS

16-31 0X93 --
INPUT 0x00 inputs1
32-47 0x01 --
INPUT 0x02 0x00
48-63 0x03 0x00
COIL 0X94 EE_COILS1
COILS
READ
/WRI
TE

0-15 0X95 --

31 Rev 1.1
COIL 0X96 EE_COILS2
16-31 0X97 --
COIL 0x00 coils1
32-47 0x01 --
COIL 0x02 0x00
48-63 0x03 0x00
0X98 EE_TIPO_DE_MODULO Identificador del tipo de la carga que está
REG 0 toByte()
0X99 -- conectada al driver
0X9A EE_CORRIENTE_MAXIMA Corriente máxima que va entrega la fuente
REG 1 corriente()
0X9B -- bajo cualquier circunstancia
0X9C EE_CORRIENTE_DIM_100 Corriente máxima del dimmado al 100%. Si
este valor es superior a
REG 2 corriente() EE_CORRIENTE_MAXIMA se tomara
0X9D --
EE_CORRIENTE_MAXIMA como la corriente
HOLDING REGISTERS

del 100% del dimado


0X9E EE_PATRON_DEFECTO Selector del patrón a ejecutarse por defecto.
REG 3 toByte()
0X9F -- 0 es sin patrón por defecto
0XA0 EE_COLOR
REG 4 toByte() Selección de la temperatura de color
0XA1 --
0XA2 EE_DIMADO_DEFECTO Selector del dimmado por defecto, o dimado
REG 5 dimmado()
0XA3 -- tras detección si hay sensor de movimiento
0XA4 EE_T_APAGADO Tiempo que se mantiene el
EE_DIM_DEFECTO antes de apagar
REG 6 segundos()
0XA5 -- completamente tras una detección. 0 indica
no apagar nunca
0XA6 EE_DIM_DEFECTO_DIGITAL Selector del dimmado cuando se detecta la
REG 7 dimmado()
0XA7 -- señal digital
REG 8 0XA8 EE_T_DIGITAL segundos() Tiempo que se mantiene el

32 Rev 1.1
EE_DIM_DEFECTO_DIGITAL desde que
0XA9 --
desaparece la detección de señal digital
0XAA EE_SENS_SENSOR_LUZ Sensibilidad del sensor de luz, 0 indica
REG 9 sensor()
0XAB -- desactivado
REG 0XAC EE_SENS_SENSOR_MOV Sensibilidad del sensor de movimiento, 0
sensor()
10 0XAD -- indica desactivado
REG 0XAE EE_P_EMERGENCIA Nivel de dimmado en caso de caída de
dimmado()
11 0XAF -- tensión y alimentación en DC desde batería
REG 0XB0 EE_V_LEDS_MAX
Vdc() Voltaje máximo permitido en los LEDs
12 0XB1 --
REG 0XB2 0xFF
13 0XB3 0xFF
REG 0XB4 0xFF
14 0XB5 0xFF
0XB6 EE_TAM_GRUPO Número de luminarias que hay en el grupo al
REG que pertenece esta luminaria. Este valor
toByte()
15 0XB7 -- afecta a la frecuencia de repetición de la
escena de PÁNICO
REG 0XB8 EE_ESCENA_1
dimmado() Nivel de dimmado en la escena 1
16 0XB9 --
REG 0XBA EE_ESCENA_2
dimmado() Nivel de dimmado en la escena 2
17 0XBB --
REG 0XBC EE_ESCENA_3
dimmado() Nivel de dimmado en la escena 3
18 0XBD --
REG 0XBE EE_ESCENA_4
dimmado() Nivel de dimmado en la escena 4
19 0XBF --
REG 0XC0- Definición del comportamiento del patrón
Patrón 5 configurable patron()
20 - 0XCF configurable 5

33 Rev 1.1
REG
27
REG
28 - 0XD0- Definición del comportamiento del patrón
Patrón 6 configurable
REG 0XDF configurable 6
35
REG
36 – 0XE0- Definición del comportamiento del patrón
Patrón 7 configurable
REG 0XEF configurable 7
43
REG
44 – 0XF0- Definición del comportamiento del patrón
Patrón 8 configurable
REG 0XFF configurable 8
51
REG 0x00 forzarDimado Nivel al que se desea forzar el dimmado
dimmadoConOff()
52 0x01 -- instantáneo de la luminaria.
REG 0x02 forzarPatron
toByte() Patrón que queremos forzar, 0 para ninguno
53 0x03 --
0x04 forzarEscena Escena que queremos forzar, 0 ninguna, 5
REG
toByte() pánico.
54 0x05 --
Prioridad: escena>patrón>dimmado
REG 0x06 calibracionCorriente Registro donde escribir la corriente leída
toInt()
55 0x07 -- externamente para provocar una calibración.
REG 0x08 RESERVED
Reservado para el sistema
56 0x09 RESERVED

34 Rev 1.1
INPUTS
ID EEPROM RAM REG NAME INDICE NAME COMMENTS
0 EE_e_bucle_inicial Error de bucle inicial en arranque anterior
1 EE_e_voltaje_alto Error de voltaje alto en arranque anterior
2 EE_e_pico_voltaje Error de pico de voltaje en arranque anterior
3 EE_e_sobre_potencia Error de sobre potencia en arranque anterior
0x90

4 EE_e_sobre_temperatura Error de sobre temperatura en el arranque


anterior
5 EE_e_circuito_abierto Error de circuito abierto en el arranque anterior
INPUTS 0-15

EE_INPUTS1
6 EE_e_corto_circuito Error de corto circuito en el arranque anterior
7 0
8 0
9 0
10 0
11 0
0x91

12 0
13 0
14 0
15 0
16 0
17 0
INPUTS 16-31

EE_INPUTS2

18 0
0x92

19 0
20 0
21 0
22 0

35 Rev 1.1
23 0
24 0
25 0
26 0
0x93 27 0
28 0
29 0
30 0
31 0
32 RESERVED Reservado para sistema
33 V110 Voltaje de 110V en la entrada
34 ausencia Ausencia de detección del sensor de
movimiento
35 signalDigital Señal digital detectada
36 standby Sistema en standby
0x00

37 muchaLuz Nivel de luz ambiente por encima de la


referencia
INPUTS 32-47

38 dimadoForzado El dimmado esta forzado (No patrón ni


Inputs1

dimmado por defecto)


39 moduloDefectuoso Detectada carga de LED defectuosa en
multimodulo
40 protPicoVoltaje Se ha disparado la protección de picos de
voltaje
41 protPotencia Se ha disparado la protección de sobrepotencia
0x01

42 protTermica Se ha disparado la protección térmica


43 0
44 0
45 0

36 Rev 1.1
46 0
47 0
48 0
49 0
50 0
51 0

0x02
52 0
53 0
INPUTS 48-63

54 0

Inputs2
55 0
56 0
57 0
58 0
59 0
0x03

60 0
61 0
62 0
63 0

37 Rev 1.1
COILS
ID EEPROM RAM REG NAME INDICE NAME COMMENTS
0 EE_dim_prog_sb Dimmado progresivo activado al pasar a standby
1 EE_dim_prog_sd Dimmado progresivo activado al cambio de nivel
2 EE_constant_light Activación de la función luz constante
3 EE_constant_flux Activación de la función flujo lumínico constante
0x94

4 EE_multimodulo Activación de la función multi modulo en la carga


5 EE_sensorAnalogico Indicador de que el sensor conectado es analógico
6 0
COILS 0-15

EE_COILS1
7 0
8 0
9 0
10 0
11 0
0x95

12 0
13 0
14 RESERVED Reservado para el sistema
15 RESERVED Reservado para el sistema
16 0
17 0
18 0
COILS 16-31

EE_IOILS2

19 0
0x96

20 0
21 0
22 0
23 0

38 Rev 1.1
24 0
25 0
26 0
27 0
0x97 28 0
29 0
30 0
31 0
32 reset Activar orden de reset
33 autoIDParpadeo Activar función de identificación LiFi (MAC por
parpadeos)
34 autoIDPArpadeo00 Activar función de identificación LiFi a las
luminarias que tengan su ID en 00 (MAC por
0x00

parpadeos)
35 polling Activar escaneo por PLC
36 Relé Activacion de salida de relé (Solo nodo)
COILS 32-47

37 delta_light Incremento de un 10% de calibración de luz


Coils1

38 0
39 0
40 0
41 0
42 0
43 0
0x01

44 0
45 0
46 0
47 0
CO

48 0
ILS

Co
48

63

02
0x

ils
2
-

39 Rev 1.1
49 0
50 0
51 0
52 0
53 0
54 0
55 0
56 0
57 0
58 0
59 0
0x03

60 0
61 0
62 0
63 0

40 Rev 1.1
6. Mapa de memoria de la pasarela MTGSP_G
NOTA: Tanto los nombres de registros como de coils o inputs que comienzan por ‘EE_’, hacen referencia a valores permanentes
es decir no pierden su valor por el hecho de encender y apagar el equipo. El resto de valores son volátiles y solo aplican hasta el
siguiente apagado, momento en el cual perderán su valor y volverán a valores por defecto tras el nuevo arranque

CONVERSION
ACCESS ZONE ID NAME DESCRIPCIÓN
FUNCTION
EE_DEVICE
REG 0
--
--
REG 1
--
toText() Modelo del dispositivo
--
REG 2
--
--
REG 3
--
INPUT REGISTERS

EE_HARDWARE_VERSION
READ ONLY

REG 4
--
--
REG 5
--
toText() Versión de hardware del dispositivo
--
REG 6
--
--
REG 7
--
EE_SOFTWARE_VERSION
REG 8
--
toText() Versión de software del dispositivo
--
REG 9
--

41 Rev 1.1
REG --
10 --
REG --
11 --
REG EE_ERRORES_COMUNICACION
errorDecodeSIM()
12 --
REG 0xFF
13 0xFF
REG 0xFF
14 0xFF
REG 0xFF
15 0xFF
REG 0xFF
16 0xFF
REG 0xFF
17 0xFF
REG 0xFF
18 0xFF
REG 0xFF
19 0xFF
REG 0xFF
20 0xFF
REG 0xFF
21 0xFF
REG 0xFF
22 0xFF
REG 0xFF
23 0xFF

42 Rev 1.1
REG 0xFF
24 0xFF
REG 0xFF
25 0xFF
REG 0xFF
26 0xFF
REG 0xFF
27 0xFF
REG 0xFF
28 0xFF
REG 0xFF
29 0xFF
REG 0xFF
30 0xFF
REG 0xFF
31 0xFF
REG Fecha_hora
32 --
toTime() Hora UTC del instante de consulta
REG --
33 --
REG Orto
34 --
toTime() Hora UTC del orto del día de consulta
REG --
35 --
REG Ocaso
36 --
toTime() Hora UTC del ocaso del día de consulta
REG --
37 --

43 Rev 1.1
REG Estado fases Numero de fases y estado de las mismas,
estadoFases()
38 -- conectadas al dispositivo
REG
39 - Identificador de la tarjeta SIM (Integrated
ICC ID toText()
REG circuit card identifier)
54
REG
Identificador del modulo de comunicación
55 –
IMEI toText() GPRS (International Mobile Equipment
REG
Identity)
70
REG MCC Mobile Country Code del número de
toInt()
71 -- teléfono
REG MNC Mobile Network Code del número de
toInt()
72 -- teléfono
REG LAC Location Area Code de la antena que
toInt()
73 -- registra el número de teléfono
REG CELL ID
toInt() Cell ID
74 --
REG BSIC
toInt() Base station Identity Code
75 --
REG RXL Received level, relacionado con la calidad
cobertura()
76 -- de la cobertura en dBm
REG Liston R
toInt() Nivel de ruido para el PLC en la fase R
77 --
REG Liston S
toInt() Nivel de ruido para el PLC en la fase S
78 --
REG Liston T
toInt() Nivel de ruido para el PLC en la fase T
79 --

44 Rev 1.1
TemperaturaEstimadaSwitch Temperatura estimada de los elementos
REG
tempSwitch() de potencia. No hay medidores solo
80 --
estimaciones
REG 0x00
81 0x00
REG 0x00
82 0x00
REG 0x00
83 0x00
INPUT 0x00
INPUTS

0-15 0x00
INPUT 0x00
16-31 0x00
COIL 0x00
0-15 0x00
COILS

COIL 0x00
16-31 0x00
EE_ZONA_HORARIA Indicador del uso horario en el que está el
REG 0 toByte()
-- equipo
READ/WRITE

EE_HORARIO_VERANO Indicador de si estamos o no en horario de


HOLDING REGISTERS

REG 1 toByte()
-- verano
EE_OFFSET_ORTO
REG 2 toByte() Minutos de offset para el orto
--
EE_OFFSET_OCASO
REG 3 toByte() Minutos de offset para el ocaso
--
0xFF
REG 4
0xFF
REG 5 0xFF

45 Rev 1.1
0xFF
EE_LATITUD
REG 6
-- Latitud del punto donde está instalado el
toFloat()
-- equipo
REG 7
--
EE_LONGITUD
REG 8
-- Longitud del punto donde está instalado el
toFloat()
-- equipo
REG 9
--
REG EE_PIN
10 --
REG -- PIN (personal identification number) de la
toText()
11 -- tarjeta SIM
REG --
12 --
REG EE_PUK
13 --
REG --
14 --
REG -- PUK (personal unlock key) de la tarjeta
toText()
15 -- SIM
REG --
16 --
REG --
17 --
REG
Dirección APN (Access Point Name) del
18– EE_APN toText()
proveedor de acceso a Internet
REG

46 Rev 1.1
33

REG
34-
EE_APN_USER toText() Usuario del APN para acceder a internet
REG
41
REG
42-
EE_APN_PASSWORD toText() Password del APN para acceder a internet
REG
49
REG
Nombre del servidor donde se encuentra
50 -
EE_SERVER_NAME toText() instalada la API y donde se dirigen las
REG
peticiones
81
REG
82 –
EE_SERVER_PORT toText() Puerto por el que se accede al servidor
REG
84
REG EE_TIPO_MEDIDOR Indicador del tipo de medidor conectado
switchMedidor()
85 -- al modem
REG 0xFF
86 0xFF
REG 0xFF
87 0xFF
REG 0xFF
88 0xFF
REG 0xFF

47 Rev 1.1
89 0xFF
REG 0xFF
90 0xFF
REG 0xFF
91 0xFF
REG 0xFF
92 0xFF
REG 0xFF
93 0xFF
REG 0xFF
94 0xFF
REG 0xFF
95 0xFF
REG RESERVED
Reservado para el sistema
96 RESERVED
REG 0x00
97 0x00
REG 0x00
98 0x00
REG 0x00
99 0x00
REG 0x00
100 0x00
REG 0x00
101 0x00
REG 0x00
102 0x00

48 Rev 1.1
REG 0x00
103 0x00
REG 0x00
104 0x00
REG 0x00
105 0x00
REG 0x00
106 0x00
REG 0x00
107 0x00
REG 0x00
108 0x00
REG 0x00
109 0x00
REG 0x00
110 0x00
REG 0x00
111 0x00

INPUTS
ID REG NAME INDICE NAME COMMENTS
0 EE_AVERIA_IGBTS Indicador de avería en electrónica de potencia
INPUTS 0-15

EE_INPUTS1

1 0
2 0
3 0
4 0

49 Rev 1.1
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
16 60Hz Se ha detectado 60Hz de red
17 Hora Actualizada Se ha actualizado la hora por internet
18 Horario Verano El sistema se encuentra en horario de verano
19 Día Astronómico en horario de día
20 Encendido Salida hacia las luminarias conectadas
21 RESERVED Reservado por el sistema
INPUTS 16-31

22 0
INPUTS1

23 0
24 0
25 0
26 0
27 0
28 0
29 0
30 0
31 0

50 Rev 1.1
COILS
ID REG NAME INDICE NAME COMMENTS
0 EE_reloj_astronomico Control automático de encendidos y apagados
1 0
2 0
3 0
4 0
5 0
6 0
COILS 0-15

EE_COILS1

7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
16 Reset Activar orden de reset del equipo
17 Apagar Apagado o encendido del cuadro de manera
manual
COILS 16-31

COILS1

18 Modo manual Pedir al cuadro que entre en modo manual


19 Config Analizador Envío de configuración al analizador de redes
20 0
21 0
22 0

51 Rev 1.1
23 0
24 0
25 0
26 0
27 0
28 0
29 0
30 0
31 0

52 Rev 1.1
7. Mapa de memoria del analizador de redes
Dado que el analizador de redes no es un equipo diseñado por Solar Power, se puede
usar cualquier modelo del mismo compatible ModBus 485. A continuación mostramos
los registros para un modelo concreto de analizador que es el más utilizado.

Para el analizador de redes SDM630, los INPUT REGISTERS son los siguientes:

53 Rev 1.1
54 Rev 1.1
55 Rev 1.1
Análogamente para los HOLDING REGISTERS:

56 Rev 1.1
57 Rev 1.1
58 Rev 1.1
8. Funciones de conversión de datos

• Corriente:
𝑖(𝑚𝐴) = 50 ∗ (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )

• Dimmado:
100
𝑑𝑖𝑚𝑚𝑎𝑑𝑜(%) = ∗ (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )
31

• Segundos:
𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠 = 5 ∗ (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )

• SegundosLargo:
𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠 = 5 ∗ (16777216 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ +
65536 ∗ 𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐻𝑖𝑔ℎ +
256 ∗ 𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐿𝑜𝑤 +
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )

• MinutosLargo:
𝑚𝑖𝑛𝑢𝑡𝑜𝑠 = 16777216 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ +
65536 ∗ 𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐻𝑖𝑔ℎ +
256 ∗ 𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐿𝑜𝑤 +
𝑏𝑦𝑡𝑒𝑙𝑜𝑤

• Sensor:
100
𝑠𝑒𝑛𝑠𝑖𝑏𝑖𝑙𝑖𝑑𝑎𝑑(%) = ∗ (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )
7

• Temperatura:
𝑐𝑢𝑒𝑛𝑡𝑎𝑠𝐴𝐷𝐶 = 256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤

Como 𝑐𝑢𝑒𝑛𝑡𝑎𝑠𝐴𝐷𝐶 es un valor con signo de 16 bits, hay que restar 65536 si el
valor leído es mayor de 32767

𝑡𝑒𝑚𝑝𝑒𝑟𝑎𝑡𝑢𝑟𝑎(º𝐶) = 25 + 1,851 ∗ (𝑐𝑢𝑒𝑛𝑡𝑎𝑠𝐴𝐷𝐶 )

• TemperaturaSwitch:
256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤
𝑡𝑒𝑚𝑝𝑒𝑟𝑎𝑡𝑢𝑟𝑎(º𝐶) =
100

59 Rev 1.1
• Frecuencia:
2000000
𝑓𝑟𝑒𝑐𝑢𝑒𝑛𝑐𝑖𝑎(𝐻𝑧) =
256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤

• Vac:
508,205
𝑉𝑎𝑐𝑝𝑖𝑐𝑜 (𝑉) = (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )
1023

• Vdc:
130,162
𝑉𝑑𝑐 (𝑉) = (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )+1,76
1023

• Potencia:
57.214,07
𝑃𝑜𝑡𝑒𝑛𝑐𝑖𝑎𝐼𝑁 (𝑊) = (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )
1023 ∗ 1000 ∗ 31
52.064,8
𝑃𝑜𝑡𝑒𝑛𝑐𝑖𝑎𝑂𝑈𝑇 (𝑊) = (256 ∗ 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 )
1023 ∗ 1000 ∗ 31

• cteK:
𝑐𝑡𝑒𝐾 → [𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐻𝑖𝑔ℎ ], [𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐿𝑜𝑤 ], [𝑏𝑦𝑡𝑒𝑙𝑜𝑤 ]

• idFabrica:
𝑀𝐴𝐶 = 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ ∗ 65536 + 𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐻𝑖𝑔ℎ ∗ 256 + 𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐿𝑜𝑤

• idInstalacion:
𝑏𝑦𝑡𝑒𝑙𝑜𝑤
𝑔𝑟𝑜𝑢𝑝 = 𝑃𝑎𝑟𝑡𝑒 𝑒𝑛𝑡𝑒𝑟𝑎 𝑑𝑒 ( + 1)
16
𝑏𝑦𝑡𝑒𝑙𝑜𝑤
𝑑𝑒𝑣𝑖𝑐𝑒 = 𝑀ó𝑑𝑢𝑙𝑜 𝑑𝑒 ( )
16

• vSw:
𝑣𝑆𝑤 → [𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ ] . [𝑏𝑦𝑡𝑒𝑚𝑒𝑑𝑖𝑢𝑚𝐻𝑖𝑔ℎ ] . [𝑏𝑦𝑡𝑒𝑙𝑜𝑤 ]

• vHw:
𝑏𝑦𝑡𝑒𝑙𝑜𝑤
𝑚𝑎𝑦𝑜𝑟 = 𝑃𝑎𝑟𝑡𝑒 𝑒𝑛𝑡𝑒𝑟𝑎 𝑑𝑒 ( )
16
𝑏𝑦𝑡𝑒𝑙𝑜𝑤
𝑚𝑖𝑛𝑜𝑟 = 𝑀ó𝑑𝑢𝑙𝑜 𝑑𝑒 ( )
16
60 Rev 1.1
• Patron:
100
𝑑𝑖𝑚𝑚𝑎𝑑𝑜 = 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ
31 ∗ 8

Si ((bytehigh) &0x06) == 0x06 por porcentaje

𝑝𝑜𝑟𝑐𝑒𝑛𝑡𝑎𝑗𝑒𝑇𝑖𝑒𝑚𝑝𝑜(%) = 𝑏𝑦𝑡𝑒𝑙𝑜𝑤

Si ((bytehigh) & 0x06) != 0x06 por tiempo


𝑡𝑖𝑒𝑚𝑝𝑜(𝑚𝑖𝑛) = (𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ &0𝑥07) ∗ 256 + 𝑏𝑦𝑡𝑒𝑙𝑜𝑤

• Cobertura:
𝑐𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 (𝑑𝐵𝑚) = 𝑏𝑦𝑡𝑒𝑙𝑜𝑤 − 113

• Estado de las fases:


Dependiendo del valor de bytelow podemos decir:
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑭𝑭 → 𝐹𝑎𝑠𝑒𝑠 𝑆 𝑦 𝑇 𝑛𝑜 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑎𝑠
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑭𝑬 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑇 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑆 𝑛𝑜 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑭𝑫 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑆 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑇 𝑛𝑜 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑭𝑪 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑆𝑇 𝑠𝑜𝑛 𝑙𝑎 𝑚𝑖𝑠𝑚𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑬𝑨 → 𝐹𝑎𝑠𝑒𝑠 𝑆 𝑛𝑜 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑬𝟖 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑆 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑇 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑫𝟓 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑆 𝑖𝑛𝑣𝑒𝑟𝑡𝑖𝑑𝑎𝑠 𝑦 𝑇 𝑛𝑜 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑨𝑭 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑇 𝑖𝑛𝑣𝑒𝑟𝑡𝑖𝑑𝑎𝑠 𝑦 𝑆 𝑛𝑜 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑨𝑫 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑆 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑇 𝑖𝑛𝑣𝑒𝑟𝑡𝑖𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑪𝟎 → 𝐹𝑎𝑠𝑒𝑠 𝑇𝑆 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑅𝑇 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑎𝑠
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑫𝟒 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑇 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑆 𝑖𝑛𝑣𝑒𝑟𝑡𝑖𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝑨𝑨 → 𝐹𝑎𝑠𝑒𝑠 𝑅 𝑒𝑟𝑟𝑜𝑛𝑒𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝟖𝟓 → 𝐹𝑎𝑠𝑒𝑠 𝑖𝑛𝑣𝑒𝑟𝑡𝑖𝑑𝑎𝑠
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝟓𝑭 → 𝐹𝑎𝑠𝑒 𝑇 𝑛𝑜 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝟓𝑬 → 𝐹𝑎𝑠𝑒𝑠 𝑅𝑇 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑆 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑎
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝟒𝑨 → 𝐹𝑎𝑠𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑎𝑠
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝟎𝒙𝟎𝑭 → 𝐹𝑎𝑠𝑒𝑠 𝑇𝑆 𝑖𝑔𝑢𝑎𝑙𝑒𝑠 𝑦 𝑅𝑆 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑎𝑠
𝑏𝑦𝑡𝑒𝑙𝑜𝑤 = 𝒐𝒕𝒓𝒐 𝒗𝒂𝒍𝒐𝒓 → 𝐸𝑠𝑡𝑎𝑑𝑜 𝑑𝑒𝑠𝑐𝑜𝑛𝑜𝑐𝑖𝑑𝑜

• toByte:
𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ − 𝑏𝑦𝑡𝑒𝑙𝑜𝑤

61 Rev 1.1
• toLong:

𝑙𝑜𝑛𝑔 = 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ ∗ 16.777.216 + bytemediumHigh ∗ 65.536 + bytemediumLow


∗ 256 + bytelow

• toFloat:

4 bytes (2 registros) por parámetro:


𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ , bytemediumHigh , bytemediumLow , 𝑏𝑦𝑡𝑒𝑙𝑜𝑤
Formato IEEE 754
El registro más significativo se recibe primero

• toText:

Cadena de texto

• toTime:

𝑡𝑖𝑚𝑒(𝑠 = 𝑏𝑦𝑡𝑒ℎ𝑖𝑔ℎ ∗ 16.777.216 + bytemediumHigh ∗ 65.536


+ bytemediumLow ∗ 256 + bytelow

• switchMedidor

0: Para modelos de la familia EASTRON SDMxxx

1: DTS6619

• errorDecodeSim

Pendiente de describir

62 Rev 1.1
9. Permisos de los usuarios

La API no permite ejecutar todos los comandos a todos los usuarios.


Existen 3 tipos de usuarios denominados ‘Administrador’, ‘Usuario’, e
‘Instalador’ respectivamente. En la siguiente tabla se muestran los
comandos permitidos para cada uno de ellos.

Tipo Usuario
Comando
Admin Usuario Instalador
Read COILS
Read INPUTS
Read HOLDING REGISTERS
Read INPUT REGISTERS
Write COILS
Write HOLDING REGISTERS
Write ID
SCAN

Si un usuario tiene permitido un comando esto no implica que tenga


acceso a todos los registros utilizando dicho comando. Además de los
permisos de comando, hay permisos específicos de registro que evitan
lecturas o escrituras no deseadas a determinados tipos de usuarios. Para
el caso de los INPUTs y los COILs también existen estos permisos.

En resumen, para que un comando tenga existo se deben tener tanto el


permiso de comando como el permiso de registro para el tipo de usuario
con el que queramos ejecutar el comando:

𝑼𝑺𝑼𝑨𝑹𝑰𝑶 + 𝑷𝑬𝑹𝑴𝑰𝑺𝑶 𝑪𝑶𝑴𝑨𝑵𝑫𝑶 + 𝑷𝑬𝑹𝑴𝑰𝑺𝑶 𝑹𝑬𝑮𝑰𝑺𝑻𝑹𝑶

63 Rev 1.1

También podría gustarte