FIWARE es una iniciativa de código abierto que define un conjunto universal de estándares para la gestión de datos de contexto que facilitan el desarrollo de soluciones inteligentes para diferentes dominios como Smart Cities, Smart Industry, Smart Agrifood y Smart Energy.

En cualquier solución inteligente existe la necesidad de recopilar y gestionar la información del contexto , procesando esa información e informando a los actores externos, permitiéndoles actuar y, por tanto, alterar o enriquecer el contexto actual. El componente FIWARE Context Broker es el componente central de cualquier plataforma «impulsada por FIWARE». Permite al sistema realizar actualizaciones y acceder al estado actual del contexto.

El Broker de contexto, a su vez, está rodeado por un conjunto de componentes de plataforma adicionales , que pueden proporcionar datos de contexto (de diversas fuentes, como un sistema CRM, redes sociales, aplicaciones móviles o sensores de IoT, por ejemplo), lo que respalda el procesamiento, análisis y visualización de datos o brindar apoyo al control de acceso a los datos, la publicación o la monetización.

¿POR QUÉ UTILIZAR FIWARE?

Todas las interacciones entre las aplicaciones o los componentes de la plataforma y Context Broker se llevan a cabo utilizando la API RESTful de FIWARE NGSI , un estándar abierto simple pero poderoso.

• SENCILLO:Proporciona una interfaz intuitiva fácilmente accesible para cualquier desarrollador web.
• PODEROSO:Admite suscripción / notificación, consultas geográficas, federación, paginación y datos vinculadosnorte
• ESTÁNDAR ABIERTO:Las especificaciones actuales de FIWARE NGSI son públicas y libres de regalías y se alinean con las  especificaciones NGSI-LD publicadas por ETSI.

La naturaleza de estándar abierto de FIWARE NGSI ofrece a los programadores la capacidad de trasladar sus aplicaciones a diferentes plataformas «Powered by FIWARE» y un marco estable para el desarrollo futuro . Se puede agregar fácilmente funcionalidad adicional a una solución inteligente simplemente usando componentes adicionales de FIWARE o de terceros para los cuales se resuelve la integración con el componente FIWARE Context Broker. Esta integración se simplifica ya que todos los componentes cumplen con la interfaz estándar FIWARE NGSI, lo que elimina el bloqueo del proveedor . La naturaleza basada en componentes de una solución basada en FIWARE permite rediseñar la arquitectura a medida que la solución evoluciona de acuerdo con las necesidades comerciales.

El ecosistema de FIWARE Lab es rico en información de contexto de dispositivos ubicados en Smartcities conectadas para que nuestros desarrolladores puedan integrarlos en sus aplicaciones o productos. La siguiente imagen muestra las principales ciudades con dispositivos públicos disponibles en la actualidad. Y estos son solo los primeros, ¡muchos llegarán pronto!

Los desarrolladores pueden consumir fácilmente esta información a través de la instancia global segura de Orion Context Broker. Descubra cómo hacerlo en el anexo de este tutorial.

Sin embargo, creemos que podemos impulsar nuestro ecosistema si contribuyes conectando tus propios dispositivos , sean caseros, comerciales o lo que sea.¿Qué obtendrá a su vez? Podrá crear fácilmente aplicaciones, servicios o simplemente paneles de control útiles gracias al extenso catálogo de FIWARE GEs. Además, puede compartirlo con otros desarrolladores, que pueden hacer que funcione para usted.

1: Comprender las opciones para conectar dispositivos al laboratorio FIWARE

Básicamente, existen 3 formas o escenarios para conectar dispositivos a FIWARE Lab:

A) ContextConsumer : si está conectando un dispositivo que solo consume información de FIWARE Lab, como un reloj inteligente, lentes inteligentes, un dron que toma decisiones sobre las condiciones de los recursos de FIWARE Lab, etc., solo necesita conectarse a la instancia global de Orion ContextBroker como descrito en este manual . Además, hay un ejemplo práctico en el anexo de este artículo al final.

Por el contrario, si está conectando dispositivos que brindan información a FIWARE Lab y posiblemente reciben comandos, entonces tiene dos opciones según la escala y el alcance de su solución:

B) Grandes despliegues de IoT , especialmente si los dispositivos son sensores o puertas de enlace 2G / 3G autónomos. En este caso, recomendamos utilizar nuestra solución de nivel de operador “DCA-IDAS Backend Device Management GE”. Recomendamos este enfoque incluso cuando comienza con un número limitado de dispositivos

C) Implementaciones limitadas de IoT : en este caso, puede omitir el componente DCA y alimentar un ContextBroker directamente como lo haría cualquier otro ContextProvider, siempre que pueda desarrollar las operaciones NGSI REST en su dispositivo o en una puerta de enlace IoT cercana.

El escenario (A) no es realmente específico de IoT, ya que sus dispositivos consumirán información de contexto, como lo haría cualquier otra aplicación.

Para las opciones (B) y (C), la mejor manera de comenzar es usar una Raspberry PI como IoT Gateway y nuestra herramienta Figway de código abierto para RaspberryPI . Puede conectar dispositivos comerciales a Raspberry PI (Z-wave se explica en este artículo) o incluso dispositivos basados ​​en Arduino conectados al PI GPIO. Hay un buen tutorial para eso aquí.

Si no está utilizando una Raspberry Pi en absoluto, aún puede usar esta publicación para comprender los conceptos básicos, analizar el código fuente de los comandos (C / C ++) y otros archivos para que pueda adaptar fácilmente el código y la filosofía a su propia plataforma .

2: Instalar y configurar el software Figway en una Raspberry PI

Acceda al repositorio GIT en: https://github.com/telefonicaid/fiware-figway/ 

Obtenga una Raspberry PI con el último sistema operativo Raspbian instalado y clone nuestro software ejecutando:

> git clon git: //github.com/telefonicaid/fiware-figway/

Cambie a la carpeta «figway / sources» y compile con el siguiente comando:

> cd figway / fuentes

> g ++ -o registerDevice registerDevice.cpp clientSocketHttp6-test.cpp clientSocketHttp6-test.h g ++ -o sendObservations sendObservations.cpp clientSocketHttp6-test.cpp clientSocketHttp6-test.h g ++ -o addObservation addObservation.cpp

> g ++ -o fizway_switchd fizway_switchd.cpp

> cd ..

Si está conectando una red de dispositivos Z-wave, continúe ahora con el «PASO 6: Usar las herramientas de Fizway para conectar una red Z-wave completa»; de lo contrario, siga leyendo. 

Los archivos relevantes para usted en este momento son:

• registerDevice : permite registrar un dispositivo en una plataforma M2M (a través de SensorML o NGSI9 / 10). Se espera que proporciones un DEVICE_ID y un DEVICE_TYPE. Los dispositivos deben registrarse en la plataforma M2M antes de enviar / recibir datos.
• addObservation : una vez que recopila una observación de un sensor, puede almacenarla en el RPI con este comando.
• sendObservations : una vez que haya recopilado todas las observaciones de un dispositivo, puede enviarlas todas en un solo paquete con este comando. Generará un error si no se agregan observaciones o no se han actualizado todos los tipos de observación.

Puede ignorar con seguridad los archivos fizway * ya que estos están relacionados principalmente con las redes Z-wave discutidas en el PASO 6, aunque también necesitará algunos de ellos para recibir comandos en el PASO 5.

Antes de ejecutar estos comandos, es posible que deba verificar y editar el archivo «Config» de figway. Se proporciona un archivo de ejemplo «Config.example».

Todos los comandos anteriores proporcionan ayuda sobre el uso si se ejecutan sin argumentos.

Echemos un vistazo al archivo de configuración:

De hecho, se explica por sí mismo. Esta es la forma en que tienes que actualizarlo:

3: Uso de los comandos de Figway para registrar sus dispositivos

• DEPURACIÓN = 1. Déjelo en 1 a menos que esté depurando.
• PLATFORM_IP = 130.206.80.44 para el escenario B o C.
• PLATFORM_PORT = 8002 para el escenario B o
• PLATFORM_PORT = para el escenario C.
• PLATFORM_PROTO = SML para conectarse a DCA (escenario B) o
• PLATFORM_PROTO = NGSI para conectarse a ContextBroker
• APIKEY = 6rs973ggt1q04gp7d9p0nho1bl. Solo es necesario para el Escenario B, ya que se ignora si se selecciona el Escenario C arriba.

Antes de enviar observaciones o recibir comandos de FIWARE Lab, todos sus dispositivos deben estar registrados. El registro es una operación idempotente, puede repetir este proceso para actualizar la información almacenada o si no está seguro de haberlo hecho antes.

El comando utilizado para el registro tiene la siguiente sintaxis:
> ./ registerDevice [DEVICE_ID] [DEVICE_TYPE]

• [DEVICE_ID] es un identificador de 4 dígitos de su dispositivo. Este número debe ser único para cada dominio Raspberry PI conectado. Lo más fácil es hacer un plan de numeración para sus dispositivos como este: “0001”, “0002”, “0003”, etc.
• [DEVICE_TYPE] es el tipo de dispositivo que está utilizando y debe coincidir con uno de los disponibles en la carpeta SensorML (Escenario B) o la carpeta NGSI (Escenario C). La razón de esto es que en el proceso de registro esa plantilla será modificada y enviada a nuestro backend de IoT.

Como ejercicio práctico asumiremos el siguiente escenario:

Nuestro ejercicio de ejemplo tiene tres dispositivos:

• un “sensor 4IN1”: medición de presencia, iluminancia, temperatura y humedad.
• un “Sensor de puerta”: envío de actualizaciones de estado de apertura / cierre.
• Un “Interruptor controlado”, que envía el consumo de energía, su estado actual (ENCENDIDO / APAGADO) y puede recibir comandos ENCENDIDO / APAGADO.

Tenga en cuenta que si comprende este escenario propuesto, podrá conectar cualquier otro tipo de dispositivos comerciales o caseros.

Tenga en cuenta también que ahora no nos importa cómo se conectan realmente los dispositivos a la Raspberry PI, porque puede utilizar cualquier tipo de solución: desde el cableado directo a la RaspberryPI GPIO o cualquier tecnología de radio / cable con los correspondientes dongle y controladores en la Raspberry. PI, como: X-10, X-10 RF, Zigbee, Z-wave (este en particular se explica más adelante en esta publicación).

3.1: Edite los archivos de plantilla para el registro de dispositivos

1. Para el Escenario B, verá todas las plantillas de dispositivo que necesitamos en la carpeta SensorML / y las modificará de esta manera:

• Register_4IN1. Edite este archivo y:
    – Reemplace todas las cadenas de «HACKSANTANDER» con el nombre real del servicio que estamos usando «OpenIoT» (nota importante: distingue entre mayúsculas y minúsculas).
•     Register_DOOR. Del mismo modo, edite este archivo y:
  – Reemplace las cadenas de «HACKSANTANDER» por «OpenIoT».
•     Register_SWITCH. Como se trata de un actuador, necesitamos configurar no solo el servicio que estamos utilizando, sino también la dirección IP y el puerto para recibir comandos. Por lo tanto, edite este archivo y:
  – Reemplace las cadenas «HACKSANTANDER» por «OpenIoT».
  – Reemplace “http://194.73.233.51:7777” por “http: // [IP]: 10000” donde IP es la dirección IP pública de su Raspberry PI.

Para el Escenario C, proceda exactamente igual que para el Escenario B pero:

• trabajando en la carpeta NGSI /.
• reemplazando las cadenas «UKCAMPUSPARTY» por «OpenIoT».
• y, para el SWITCH, reemplazando “http://1.0.0.1:8888” por “http: // [IP]: 10000” donde IP es la dirección IP pública de su Raspberry PI.

Nota importante: si se encuentra en un entorno NAT-ed (el PI tiene una IPv4 privada):

• Para el campo [IP] en ​​los archivos anteriores, use la dirección IPv4 pública de su enrutador-NAT. No olvide configurar ese enrutador-NAT para reenviar el puerto TCP 10000 a la dirección IPv4 privada de su PI y Puerto 10000.
• Tenga en cuenta que Figway está preparado para IPv6, por lo que si su ISP se lo proporciona, puede usar las direcciones PI IPv6 para recibir comandos. De esta forma evitará configurar un enrutador-NAT. Solo asegúrese de que su firewall v6 esté aceptando conexiones TCP entrantes al puerto 10000 para la dirección PI v6.

3.2: Registro de sus dispositivos en FIWARE Lab IoT Backend

Ahora que ha identificado y editado las plantillas de registro para su [DEVICE_TYPE] específico, solo necesita registrar dispositivos ejecutando:

> ./ registerDevice 0001 4IN1
> ./ registerDevice 0002 DOOR
> ./ registerDevice 0001 INTERRUPTOR

Para cada comando anterior, verá algo similar a esto en caso de éxito: (Esta es una instantánea del Escenario B, el Escenario C es una respuesta 200 OK diferente)

3.3: ¿Y si quiero registrar diferentes tipos de dispositivos?

Lo único que necesita es definir un nuevo tipo de plantilla de sensor, decir «MYSENSOR» y crear el archivo de plantilla de registro correspondiente:

• Si es, por ejemplo, simplemente enviando Temperature, simplemente copie el archivo «Register_4IN1» a «Register_MYSENSOR» y edite este archivo eliminando las secciones XML para otras observaciones (Move, Illuminance y Humidity).
• Si su dispositivo solo está enviando cualquier otra observación numérica o de cadena, mejor copie «Register_DOOR» a «Register_MYSENSOR» y modifíquelo en consecuencia.
• Si su dispositivo también está recibiendo comandos, simplemente agregue la sección XML que describe la URL para los comandos http: [IP]: [PORT] tomando «REGISTER_SWITCH» como ejemplo de trabajo.

Para todas estas modificaciones anteriores, recuerde crear los archivos en la carpeta SensorML / para el Escenario B o en NGSI / uno para el Escenario C.

4: Usar comandos de Figway para enviar las observaciones de sus dispositivos

Siempre que desee enviar una observación de un dispositivo al backend de FIWARE Lab IoT, debe hacerlo en dos pasos:

• Agregar observaciones a un archivo temporal (comando addObservation)
• Envíe todas las observaciones en el archivo temporal (comando sendObservation)

La razón de este enfoque es permitir que los dispositivos de detección múltiple (como el 4IN1) almacenen y / o envíen diferentes mediciones en diferentes momentos o desde diferentes componentes o funciones de software.

4.1: Edite los archivos de plantilla para observaciones de dispositivos

De manera similar al proceso de registro, debe identificar cada plantilla y modificarla adecuadamente. La diferencia aquí es que tendrá tantos archivos como tipos de observaciones por cada [DEVICE_TYPE]. En nuestro escenario de ejemplo:

Para el Escenario B, verá todas las plantillas de observación de dispositivos que necesitamos en la carpeta SensorML / y las modificará de esta manera:

• Archivos relacionados con 4IN1: Observation_4IN1_MOV, Observation_4IN1_TEM, Observation_4IN1_LUM, Observation_4IN1_HUM

    – Reemplace las cadenas «HACKSANTANDER» por «OpenIoT».

• Archivos relacionados con DOOR: Observation_Door_STAT.

    – Reemplace las cadenas «HACKSANTANDER» por «OpenIoT».

• SWITCH archivos relacionados: Observation_Switch_POW, Observation_SWITCH_STAT.

    – Reemplace las cadenas «HACKSANTANDER» por «OpenIoT».

Para el Escenario C, proceda exactamente igual que para el Escenario B pero:

• trabajando en la carpeta NGSI /.
• reemplazando las cadenas «UKCAMPUSPARTY» por «OpenIoT».

4.2: Envío de las observaciones de sus dispositivos a FIWARE Lab IoT Backend

La sintaxis correcta de los dos comandos necesarios es la siguiente:

> ./ addObservation [DEVICE_ID] [DEVICE_TYPE] [OBS_TYPE] [OBS_VALUE]
> ./ sendObservation [DEVICE_ID] [DEVICE_TYPE] [OBS_TYPE]

Hagamos el ejercicio para el 4IN1 de dos formas diferentes:

• Su código recopila todas las medidas de los entornos cada 10 minutos y desea enviarlas al backend:

> ./ addObservation 0001 4IN1 TEM [Temperatura]
> ./ addObservation 0001 4IN1 HUM [Humedad]
> ./ addObservation 0001 4IN1 LUM [Illuminance]
> ./ sendObservations 0001 4IN1 TEM
> ./ sendObservations 0001 4IN1 HUM
> ./ sendIN1 LUM LUM

• Su código desea informar el estado de MOVE cada vez que el 4IN1 activa ese evento al detectar una persona en la habitación:

> ./ addObservation 0001 4IN1 MOV MOVIMIENTO
> ./ sendObservations 0001 4IN1 MOV

• Su código quiere informar el estado QUIET siempre que el 4IN1 active ese estado (normalmente un tiempo de espera después de que se detectó MOVE).

> ./ addObservation 0001 4IN1 MOV QUIET
> ./ sendObservations 0001 4IN1 MOV

4.3: ¿Y si quiero usar diferentes tipos de dispositivos?

Supongamos que tiene un sensor tipo “MY_SENSOR” que ya ha registrado con su archivo de plantilla “Registration_MYSENSOR” como se indica en los párrafos anteriores.

Ahora necesita identificar cuántos tipos de observación están administrando sus dispositivos.

Supongamos que gestiona la temperatura y la humedad. Luego, necesitaría crear los archivos de plantilla «Observation_MYSENSOR_TEM» y «Observation_MYSENSOR_HUM» que puede tomar de «Observation_4IN1_TEM» y «Observation_4IN1_HUM» respectivamente.

Si su sensor estaría proporcionando un estado numérico o de cadena diferente, puede crear el archivo «Observation_MYSENSOR_STAT» tomando «Observation_DOOR_STAT» como referencia.

Si su dispositivo está recibiendo comandos, no necesita modificar ningún campo específico para eso en ningún archivo de plantilla de observación.

Recuerde crear plantillas de observación en la carpeta SensorML / si está trabajando con el Escenario B o en la carpeta NGSI / si está en el Escenario C,

PASO 5: habilitar dispositivos para recibir comandos

En nuestro escenario, existe un dispositivo SWITCH que es adecuado para recibir comandos de ENCENDIDO / APAGADO. Continúe leyendo esta sección solo si tiene dispositivos que recibirán comandos del backend o de cualquier otro lugar en Internet.

5.1: Configurar la herramienta fizway_switchd para recibir comandos.

Hay un comando que lanzará un servidor TCP por usted, analizará los comandos si los hay y entregará el resultado a otro programa llamado «fizway

Su sintaxis correcta es:
> ./ fizway_switchd [Device_ID] [DEVICE_TYPE] [Server_Port]

Donde [Device_ID] y [DEVICE_TYPE] son ​​los que usó para el registro de ese dispositivo y [Server_Port] es el puerto TCP para escuchar los comandos en Raspberry PI. Este puerto debe coincidir con el proporcionado en la cadena de URL de la plantilla de registro http: // [IP]: [PORT].

En nuestro ejemplo específico, solo necesitamos lanzarlo de esta manera:
> ./ fizway_switchd 0003 SWITCH 10000

Tenga en cuenta que puede iniciar tantos servidores (en diferentes puertos) como dispositivos con capacidad de comando tenga.

5.2: pruebe que sus dispositivos reciban comandos correctamente

Podemos probar para encender nuestro interruptor conectándonos a nuestro servidor de comando en Raspberry PI con un cliente telnet regular (desde el PI o cualquier otra máquina, asumimos que la dirección PI es 192.168.1.50) y tecleamos:

> telnet 192.168.1.50 10000
<FIZCOMMAND 255>

O, para apagar el interruptor con:
> telnet 192.168.1.50 10000
<FIZCOMMAND 0>

La siguiente sección explica cómo hacer que las herramientas efervescentes y su código cooperen para afectar eficazmente su dispositivo.

Paso 5.3: ¿Y si quiero usar diferentes tipos de dispositivos actuadores?

Los comandos enviados a los dispositivos tienen la forma «FIZCOMMAND [COMMAND]», donde [COMMAND] puede ser cualquier cadena sin espacios ni símbolo «>» en el medio siempre que esos caracteres se utilicen para determinar su final.

Los comandos de ejemplo y su resultado son:

• «FIZCOMMAND ON»: válido. El argumento del comando será «ON»
• “FIZCOMMAND OFF”: No válido ya que no hay espacio al final.
• “<FIZCOMMAND ON>” Válido porque hay un símbolo “>” al final.
• «FIZCOMMAND THIS_IS_A_TEST_OF_STRING»: válido.
• “<FIZCOMMAND THIS_IS_A_TEST_OF_STRING>“: válido.
• «FIZCOMMAND ESTO ES UNA PRUEBA DE CADENA»: Válido, pero solo «ESTO» se enviará como argumento del comando.

Una vez que envíe un comando a este servidor y el análisis sea válido, automáticamente invocará el script bash «fizway_command» de esta manera:
> ./ fizway_command [DEVICE_NUMBER] [DEVICE_TYPE] [COMMAND_VALUE]

Donde [COMMAND_VALUE] es el comando que envió al servidor.

De esta manera, solo necesita incorporar en el script “fizway_command” las acciones que desea realizar para su dispositivo específico al recibir ciertos comandos. También puede reemplazar todo el script por cualquier otro componente siempre que mantenga su nombre y sintaxis de invocación para que el servidor «fizway_switchd» lo llame correctamente.

Más adelante en esta publicación se muestra un ejemplo de trabajo para el escenario Z-WAVE.

5.4: envíe comandos a sus dispositivos desde nuestro backend de IoT

En este momento, esta posibilidad solo funciona para el escenario B (DCA). Si se trata del escenario C, deberá enviar los comandos usted mismo al servidor de comandos en Raspberry PI como se explicó anteriormente en la sección 5.2.

Para el escenario B, solo necesitas usar la API de administración de DCA-IDAS que mostramos en la siguiente captura:

Nota: a diferencia de esta captura de pantalla, la API ADMIN se ofrece públicamente en el puerto 80 y está protegida con un keyrock PEP-Proxy como todos los demás GEs públicos en FIWARE Lab. Consulte el anexo de este artículo para saber cómo obtener y utilizar un token de acceso antes de probar el ejemplo anterior.

6: Uso de las herramientas de Fizway para conectar una red Z-wave completa

Todos los pasos anteriores asumen que está conectando cualquier tipo de dispositivo. Sin embargo, hemos facilitado la vida en el caso de que esté conectando una red de dispositivos Z-wave proporcionando también el código para administrarlos como se muestra en la siguiente imagen:

La imagen dibuja el caso del escenario B, pero en realidad el escenario C sería similar pero enviando información directamente al ContextBroker (sin pasar por DCA-IDAS). En el escenario C, los comandos solo se enviarían directamente a RaspberryPI (línea azul punteada).

La buena noticia para los dispositivos Z-WAVE es que solo necesita seguir los siguientes pasos:
1. Construya su red Z-WAVE como lo hace habitualmente. Para las pruebas usamos un RaspberryPI y un dongle GPIO Razberry Z-wave con su software incluido.

2.  Instale y configure la herramienta Figway como se describe en el “PASO 2: Instalar y configurar el software Figway en una Raspberry PI”.

3.  Edite el archivo “fizway_register” y los archivos “fizway”
   a. Actualice las ID correctas de su red z-wave (solo sus dispositivos)
b.  Para los actuadores asignamos un puerto de escucha por cada uno (10000…)

4. Configure los actuadores (plantillas de registro de dispositivos SWITCH y RGBS) para recibir comandos.
     una. Actualice la plantilla de dispositivo con la dirección IP de este RaspberryPI
     b.  El puerto es el puerto asignado al actuador en el paso anterior.

5.    Registre todos sus dispositivos ejecutando «fizway_register»

6.   Ejecute el script «fizway &» para que las observaciones se envíen automáticamente y también se reciban los comandos.
¡Y eso es todo, tendrás todos los dispositivos funcionando con los sencillos 6 pasos anteriores!

Bonus: obtener información de IoT de un Orion ContextBroker seguro

Esta sección muestra un ejemplo sobre la recopilación de información de IoT del agente de contexto de Orion. La documentación completa para esto está disponible aquí.

Hay una instancia global de Orion ContextBroker (CB) que está recibiendo toda la información de los otros Contextbrokers, por lo que no es necesario que te preocupes por eso.

Los pasos necesarios para poder acceder al CB global seguro de FIWARE Lab son:
1.     Regístrese en FIWARE Lab y obtenga una cuenta. http://account.lab.fi-ware.org
2.    Genere un token de acceso Oauth2 usando sus credenciales en (1).
Lo más fácil de probar es utilizar el script proporcionado en:
https://github.com/fgalan/oauth2-example-orion-client/blob/master/token_script.sh

Tenga en cuenta que el Token que se utilizará es el primero: «Token de acceso» (el más largo).

3.    Acceda a la API REST de ContextBroker con un encabezado de autorización configurado para el token de acceso recibido en (2) y luego realice una consulta específica (obteniendo su versión en esta captura de pantalla a continuación).

Mas informacion en https://www.fiware.org/2014/06/18/connect-your-own-internet-of-things-to-fi-lab/