Archivo de la etiqueta: API REST

API REST

Las API REST se han convertido en una herramienta muy importante para los desarrollos con IoT al permitir conectar servicios entre sí. Vamos a explicar qué son exactamente.

La interfaz de programación de aplicaciones, conocida también por la sigla API, en inglés, application programming interface, es un conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.

Hoy en día la mayoría de las empresas utilizan API REST para crear servicios. Esto se debe a que es un estándar lógico y eficiente para la creación de servicios web. Por poner algún ejemplo tenemos los sistemas de identificación de Facebook, la autenticación en los servicios de Google (hojas de cálculo, Google Analytics, …).

Las APIs forman el pegamento de conexión entre las aplicaciones modernas. Casi todas las aplicaciones utilizan APIs para conectarse con fuentes de datos corporativas, servicios de datos de terceros u otras aplicaciones. La creación de un formato de descripción abierto para los servicios de API que sea neutral para los proveedores, portátil y abierto es fundamental para acelerar la visión de un mundo verdaderamente conectado.

Una API es básicamente una forma de hacer una solicitud a otra aplicación. Por ejemplo, si estamos desarrollando una aplicación y queremos encontrar a las personas que nos siguen en Twitter, podría solicitar esta información a la API de Twitter: “Dame una lista de todas las personas que me siguen”. No hay diferencias si nuestra aplicación está en Ruby, Php, Javascript, etc., y Twitter otro lenguaje porque la API transmite y recibe datos en un formato común (normalmente JSON o XML). Esto permite que dos aplicaciones totalmente separadas envíen y reciban datos.

REST, REpresentational State Transfer, es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP. REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras alternativas como SOAP y XML-RPC. REST se definió en el 2000 por Roy Fielding, coautor principal también de la especificación HTTP. Podríamos considerar REST como un framework para construir aplicaciones web respetando HTTP.

Conocer bien HTTP no es opcional para alguien de desarrollo APIs ni para los consumidores de las mismas. El RFC es sencillo de leer.

Para desarrollar APIs REST los aspectos claves que hay que dominar y tener claros son:

Más información:

Según Fielding las restricciones que definen a un sistema RESTful serían:

  • Cliente-servidor: esta restricción mantiene al cliente y al servidor débilmente acoplados. Esto quiere decir que el cliente no necesita conocer los detalles de implementación del servidor  y el servidor se “despreocupa” de cómo son usados los datos que envía al cliente.
  • Sin estado: aquí decimos que cada petición que recibe el servidor debería ser independiente, es decir, no es necesario mantener sesiones.
  • Cacheable: debe admitir un sistema de almacenamiento en caché. La infraestructura de red debe soportar una caché de varios niveles. Este almacenamiento evitará repetir varias conexiones entre el servidor y el cliente para recuperar un mismo recurso.
  • Interfaz uniforme: define una interfaz genérica para administrar cada interacción que se produzca entre el cliente y el servidor de manera uniforme, lo cual simplifica y separa la arquitectura. Esta restricción indica que cada recurso del servicio REST debe tener una única dirección, “URI”.
  • Sistema de capas: el servidor puede disponer de varias capas para su implementación. Esto ayuda a mejorar la escalabilidad, el rendimiento y la seguridad.

Las operaciones más importantes que nos permitirán manipular los recursos son cuatro:

  • GET para consultar y leer
  • POST para crear
  • PUT para editar
  • DELETE para eliminar.

Ventajas e inconvenientes de las API REST: http://www.desarrolloweb.com/articulos/ventajas-inconvenientes-apirest-desarrollo.html

Arquitectura de una API REST: https://juanda.gitbooks.io/webapps/content/api/arquitectura-api-rest.html

Buenas prácticas de diseño de API REST: https://elbauldelprogramador.com/buenas-practicas-para-el-diseno-de-una-api-restful-pragmatica/

Qué es REST:

Enlaces:

Cliente REST de Arduino: https://github.com/csquared/arduino-restclient

Requests HTTP en python:

En informática, CRUD es el acrónimo de “Crear, Leer, Actualizar y Borrar” (del original en inglés: Create, Read, Update and Delete), que se usa para referirse a las funciones básicas en bases de datos o la capa de persistencia en un software.

Wikipedia: https://es.wikipedia.org/wiki/CRUD

Crear una API: https://desarrolloweb.com/manuales/manual-desarrollo-api.html 

Pulling and pushing data con Arduino usando HTTP:

Pull: Una aplicación en un ordenador o servidor pregunta a Arduino por los datos

Push: Arduino se comunica con el servidor para mandarle los datos

Postman

Postman surgió originariamente como una extensión para el navegador Google Chrome. A día de hoy dispone de aplicaciones nativas para MAC y Windows y Linux.

Está compuesto por diferentes herramientas y utilidades gratuitas (en la versión free) que permiten realizar tareas diferentes dentro del mundo API REST: creación de peticiones a APIs internas o de terceros, elaboración de tests para validar el comportamiento de APIs, posibilidad de crear entornos de trabajo diferentes (con variables globales y locales), y todo ello con la posibilidad de ser compartido con otros compañeros del equipo de manera gratuita (exportación de toda esta información mediante URL en formato JSON).

Además, dispone de un modo cloud colaborativo (de pago) para que equipos de trabajo puedan desarrollar entre todos colecciones para APIs sincronizadas en la nube para una integración más inmediata y sincronizada.

Más información: https://www.paradigmadigital.com/dev/postman-gestiona-construye-tus-apis-rapidamente/

El interés fundamental de Postman es que lo utilicemos como una herramienta para hacer peticiones a APIs y generar colecciones de peticiones que nos permitan probarlas de una manera rápida y sencilla.

Las colecciones son carpetas donde se almacenan las peticiones y que permiten ser estructuradas por recursos, módulos o como desees:

Todas las llamadas almacenadas en nuestra colección pueden ser exportadas a múltiples lenguajes haciendo clic en el apartado Generate Code que podéis ver en la captura anterior. Os dejo un ejemplo de cómo exporta una llamada GET para poder ser utilizada automáticamente desde código Python:

Herramienta para las API REST: Postman

Video explicativo: https://www.youtube.com/watch?list=PLM-7VG-sgbtCJYpjQfmLCcJZ6Yd74oytQ&v=ptvV_Fc3hd8   

Como probar una api rest con postman: https://www.luisllamas.es/realizar-peticiones-http-con-postman/ 

Instalar postman y probar a hacer estas dos peticiones:

Autorización/Autenticación API Rest

En el mundo de las API REST, se deben implementar flujos distintos de los habituales en cuanto a la autenticación de usuarios, ya que su arquitectura nos ofrece otro tipo de recursos que los tradicionales. Por lo general, en las aplicaciones web tradicionales, se utilizan las variables de sesión como soporte para memorizar el usuario. Esto viene a decir que en el momento de autenticar un usuario, el servidor genera las correspondientes variables de sesión y en las siguientes páginas consultadas por ese mismo cliente, es capaz de recordar al usuario.

Sin embargo, en las aplicaciones REST, esto no es posible, ya que una de las limitaciones de este sistema es que no se dispone de variables de sesión. Esto es debido a motivos de escalabilidad, ya que las API REST suelen estar alojadas en un cluster de servidores. La solución habitual para salvar este problema es la autenticación por token.

Una API RESTful debería ser stateless (sin estado). Esto significa que la petición de autenticación no debería depender de cookies o sesiones. En lugar de ello, cada petición debería venir con algún tipo de credencial de autorización.

En una API REST, enviar las credenciales una vez para iniciar sesión no es suficiente, las API REST son asíncronas. Al ser asíncrona, la API REST no puede recordar las credenciales ya que no existe ninguna sesión activa HTTP. ¡Así que tienes que indicar quién eres cada vez que hagas una petición!

Siempre que se use SSL, las credenciales de autenticación pueden ser simplificadas a un token de acceso generado de forma aleatoria, que es entregado en el campo de nombre de usuario de HTTP Basic Auth.

De todos modos, este método de autenticación token-over-basic-auth (token sobre autenticación básica) es sólo aceptable en los casos en que sea práctico tener la posibilidad de que el usuario copie un token de una interface de administración del entorno del consumidor de la API.

En los casos donde no sea posible, OAuth 2 debería ser usado para facilitar la transferencia del token seguro a terceros. OAuth 2 usa tokens Bearer y además depende de SSL para su encriptación de transporte subyacente.

Una API que necesita soporte JSONP necesitará un tercer método de autenticación, ya que las peticiones JSONP no pueden enviar credenciales HTTP Basic Auth ni Bearer tokens. En este caso, puede utilizarse un parámetro especial de consulta “access_token”.

Más información:

Basic Auth

Siempre que se use SSL, las credenciales de autenticación pueden ser simplificadas a un token de acceso generado de forma aleatoria, que es entregado en el campo de nombre de usuario de HTTP Basic Auth.

Esta es la forma más sencilla de asegurar tu API. Se basa principalmente en un nombre de usuario y una contraseña para identificarte.

Para comunicar estas credenciales desde el cliente hasta el servidor, se debe realizar mediante el encabezado HTTP Autorización (Authorization), según la especificación del protocolo HTTP.

Este método de autentificación está algo anticuado y puede ser un problema de seguridad en tu API REST.

API Key

Las API Keys son el primer método que apareció para realizar accesos a este tipo de servicios. Los desarrolladores no dudan en pensar en ella como la primera alternativa a la hora de autenticarse en su API. Esto se debe a que entre sus ventajas están su simpleza, la posibilidad de sacar estadísticas de accesos o peticiones y a su facilidad de uso para implementarlas en las aplicaciones que consumirán el servicio. Generalmente cuando accedemos a una web con este tipo de autenticación, vamos a nuestro perfil y en la sección de configuración nos encontramos con la API Key lista para ser cargada en alguna app móvil o servicio web para hacer tests de API.

Todo esto trae aparejados dos grandes problemas que son: su falta de seguridad y la pésima experiencia de usuario. En muchos casos, estas claves son enviadas dentro de la URL en donde se realiza la petición al servicio, lo que permite ser accedida por alguien que no debería. Para esto el estándar nos dice que las keys deberían viajar en el Header de la petición, para dificultar un poco su acceso por parte de terceros, aunque en la práctica se pueden ver en el Header Authorization, en un Header personalizado o en la URL.

Token

Un token es un valor que nos autentica en el servidor, Normalmente se consigue después de hacer login mediante usuario/contraseña.

Un token se genera normalmente como un hash calculado con algún dato (p.ej. login del usuario + clave secreta). Además el token puede llevar datos adicionales como el login.

Cada vez que el cliente deba realizar nuevas solicitudes al servidor, certificando que es un usuario correctamente autenticado, tendrá que enviar el token de nuevo al servidor. Por lo tanto, una vez recibido el token, deberá ser almacenado del lado del cliente para enviarlo con las posteriores solicitudes. En estos casos, el token suele viajar en las cabeceras del HTTP, de modo que llegue al servidor.

El servidor que recibe el token tiene la capacidad de desencriptarlo, de modo que pueda comprobar qué usuario es el que está realizando esta solicitud. Durante el proceso de decodificación del token, el servidor puede comprobar si este es válido y si resulta serlo, puede recuperar toda la información encriptada en el mismo, que suele ser al menos la referencia inequívoca del usuario involucrado. Por supuesto, si en cualquier momento se detecta que el token no es correcto, se obligará al usuario a autenticarse nuevamente.

Más información: https://desarrolloweb.com/articulos/autenticacion-token.html

JSON Web Token

Este tipo de token es mucho más largo que los demás ya que depende de la cantidad de datos que queramos almacenar en él. Sin embargo, una buena utilización del mismo nos permitiría mantener un token que se puede enviar por la red sin ocupar mucho espacio.

Este token está compuesto por varios campos codificados en base64 donde se guarda la información, identificación de usuario, alcance de los permisos del token, y finalmente una firma de todo los datos contenidos del token hecha por el servidor de la API para comprobar que el token es válido. Esta comprobación es mucho más eficiente y rápida que el acceso a la base de datos para determinar a quién pertenece, qué permisos tiene, etc.

OAuth 2

Con frecuencia, cuando se habla de seguridad y de OAuth, los conceptos de autenticación y autorización se solapan y son completamente diferentes:

  • La autenticación se define como el proceso mediante el cual se verifica quién eres, es decir, su ámbito se refiere a la identificación.
  • La autorización es el proceso mediante el cual se verifica a qué tienes acceso, es decir, su ámbito se limita al control de acceso.

Atendiendo a esos conceptos, OAuth es un framework que permite delegar la autorización de acceso a las APIs, NO es un protocolo de autenticación. Para que una app pueda acceder a servicios de terceros sin que el usuario tenga que darle a la app sus credenciales del servicio. Se basa en el uso de un token de sesión.

Este método es el mejor para las APIs que contengan información de usuarios. ¿Por qué? Principalmente por ser la más robusta de las tres alternativas y por cómo está definido el protocolo OAuth nos posibilita declarar permisos para cada aplicación que quiere acceder a la API y así tener varios tipos de autorización para apps diferentes. 

Las implementaciones de OAuth utilizan uno o los dos tokens siguientes:

  • Token de acceso: se envía como una API key, permite acceder a la información del usuario. Opcionalmente pueden tener una expiración.
  • Token de refresco: son un token opcional que sirve para actualizar el token de acceso en caso de que éste haya expirado.

Más información: 

WebHooks

Un Webhook es una manera de ser notificado cuando un evento ha ocurrido en tu aplicación o la de un tercero. Es básicamente una solicitud POST que se envía a una URL específica. Esa URL está configurada para recibir el cuerpo de la solicitud POST y procesarla de alguna manera.

Una API se utiliza para hacer preguntas directas y un Webhook se utiliza para notificar cuando se producen ciertos eventos. En lugar de preguntar constantemente si algo ha cambiado, un webhook puede activarse y notificarnos automáticamente apenas se produzca el evento.

API está haciendo cosas cuando se lo pides, mientras que Webhook hace cosas propias cuando ciertos criterios coinciden.

La principal diferencia entre el funcionamiento de los Webhooks y las APIs es que, mientras que las APIs realizan llamadas sin saber si reciben alguna actualización de datos como respuesta o no, los Webhooks reciben llamadas a través de HTTP POSTs desde sistemas externos sólo cuando éstos tienen algunas actualizaciones de datos.

Por otro lado, los Webhooks son llamadas automáticas de example.com a un servidor. Estas llamadas se activan cuando ocurre un evento específico en example.com. Por ejemplo, si un nuevo usuario se registra en example.com, la llamada automática puede configurarse para pedir al servidor que envíe un correo electrónico de bienvenida.

Si empezamos a pensar más en Webhooks, podemos empezar a ver a todos los Web Services como un gran repositorio de librerías asíncronas. Con el uso de Webhooks podemos por ejemplo pensar en implementar notificaciones en tiempo real sin necesidad de estar haciendo polling.

Un webhook no es una API, no es una tecnología, es solo un patrón de diseño donde definimos hooks que pueden ser invocados por terceros vía HTTP. Simple y Elegante. Esto es muy fácil implementarlo en Arduino.

Más información:

WebHooks IFTTT

Son webhooks para luego lanzar otros servicios: https://ifttt.com/maker_webhooks

Para disparar un evento, hacer un POST o GET a: https://maker.ifttt.com/trigger/{event}/with/key/aaabbbcccdddeee con un cuerpo JSON opcional con el formato: { “value1” : “”, “value2” : “”, “value3” : “” }

Ejemplo de APIS

API Telegram: https://core.telegram.org/bots/api

API Twitter: https://developer.twitter.com/en/docs

API thingspeak: https://www.mathworks.com/help/thingspeak/

API Rest con Arduino

Práctica: API AEMET

Documentación: https://opendata.aemet.es/dist/index.html?

Predicción municipio horaria: https://opendata.aemet.es/dist/index.html?#!/predicciones-especificas/Predicci%C3%B3n_por_municipios_horaria_Tiempo_actual

Código Logroño: 26089

Práctica: Conexión a Thingspeak

Escribir datos en un canal: https://es.mathworks.com/help/thingspeak/write-data.html

Detalles: https://es.mathworks.com/help/thingspeak/writedata.html

Práctica: Conexión a EmonCMS

Documentación API: https://emoncms.org/site/api 

Thingspeak

ThingSpeak es un plataforma de Internet of Things (IoT) que permite recoger y almacenar datos de sensores en la nube y desarrollar aplicaciones IoT. Thinkspeak también ofrece aplicaciones que permiten analizar y visualizar tus datos en MATLAB y actuar sobre los datos. Los datos de los sensores pueden ser enviados desde Arduino, Raspberry Pi, BeagleBone Black y otro HW.

Web: https://thingspeak.com/

Thingspeak es parte de Mathworks https://en.wikipedia.org/wiki/MathWorks que es la empresa de entre otros Matlab y Simulink.

Uso comercial: https://thingspeak.com/pages/commercial_learn_more

Precios: https://thingspeak.com/prices

Features Thingspeak:

También puede acceder a los recursos de MATLAB y Simulink con una cuenta gratuita de MathWorks.

Apps de Thingspeak, son los servicios de la plataforma IoT: https://thingspeak.com/apps

Librería Thingspeak para Arduino, ESP8266 y ESP32: https://github.com/mathworks/thingspeak-arduino

La estructura de Thingspeak es:

  • Canales (Channels): los datos que recogemos en los dispositivos se guardan en canales.
  • En cada canal se disponen de una serie de campos para guardar datos, así como otra información adicional
  • Los canales pueden ser públicos o privados.
  • Dentro de cada canal podemos añadir visualizaciones o Widgets
  • Los datos del canal se pueden importar o exportar
  • En la pestaña de API keys está la información con las contraseñas (API Keys) para usar con las APIs.

Tutoriales Thingspeak: https://community.thingspeak.com/tutorials/

Tutoriales Arduino:

Tutoriales ESP8266:

Tutoriales Raspberry Pi.

Documentación: https://www.mathworks.com/help/thingspeak/

Getting started con Thingspeak: https://www.mathworks.com/help/thingspeak/getting-started-with-thingspeak.html

Ejemplos: https://www.mathworks.com/help/thingspeak/examples.html

Restful y MQTT APIs: https://www.mathworks.com/help/thingspeak/channels-and-charts-api.html

Alertas: https://www.mathworks.com/help/thingspeak/monitor-channel-inactivity-using-multiple-thingSpeak-apps.html

Más información:

Cliente MQTT Thingspeak

ThingSpeak ahora es compatible con la publicación MQTT, que le permite enviar datos a ThingSpeak desde cualquier dispositivo o servicio compatible con el estándar MQTT.

Puede seguir enviando hasta 3 millones de mensajes al año de forma gratuita. Para determinar cuántos mensajes utiliza, puede iniciar sesión y ver el uso de su cuenta.

Tutoriales para usar MQTT con Arduino:

Ejemplo con Thingspeak

Instalar con el gestor de librerías la librería thinkspeak o manualmente desde https://github.com/mathworks/thingspeak-arduino

Crear un nuevo canal: temperatura casa

Los canales guardan todos los datos que una aplicación Thingspeak recoge. Cada canal incluye 8 campos que pueden almacenar cualquier tipo de dato, además de tres campos para localización del dispositivo y uno para el estado de los datos. Una vez los datos son recogidos en un canal, es posible usarlos con las apps de Thingspeak para analizarlos y visualizarlos.

API: https://es.mathworks.com/help/thingspeak/channels-and-charts.html

Thingspeak apps: https://thingspeak.com/apps

Tutorial: https://es.mathworks.com/help/thingspeak/getting-started-with-thingspeak.html

Analizar datos: https://es.mathworks.com/help/thingspeak/analyze-your-data.html

Actuar con tus datos: https://es.mathworks.com/help/thingspeak/act-on-your-data.html

Código con IP fija y sin librería: https://github.com/jecrespo/Aprendiendo-Arduino/tree/master/Ejercicio65-Thingspeak

Código con IP fija y librerías: https://github.com/jecrespo/aprendiendoarduino-iot/tree/master/01-Thingspeak/Temp-y-Hum

Canal público: https://thingspeak.com/channels/242341

Usar MQTT con Thingspeak: http://blogs.mathworks.com/iot/2017/01/20/use-mqtt-to-send-iot-data-to-thingspeak/

Repositorio: https://github.com/jecrespo/aprendiendoarduino-iot/tree/master/01-Thingspeak

Analizar

Ejemplos: https://es.mathworks.com/help/thingspeak/examples.html

Tutorial: https://es.mathworks.com/help/thingspeak/analyze-your-data.html  

Actuar

Con webhooks http, thinghttp: https://thingspeak.com/apps/thinghttp

React: https://thingspeak.com/apps/reacts

React app: https://es.mathworks.com/help/thingspeak/react-app.html

Manual Thinghttp APP: https://es.mathworks.com/help/thingspeak/thinghttp-app.html

Tutorial: http://community.thingspeak.com/tutorials/arduino/cheerlights-with-arduino-and-the-fastled-library/

Restduino: https://github.com/sirleech/RestduinoThingspeak

Time control:

Canal público: https://thingspeak.com/channels/242341

Ecosistema IoT

¿Cómo Conectar a Internet una Tostadora?

Veamos un resumen de los elementos que necesitamos para conectar un dispositivo a Internet y hacer un proyecto de IoT completo.

Supongamos que quiero conectar mi tostadora a Internet y hacer un sistema que conecte mi coche con la tostadora y cuando me acerque a casa ponga en funcionamiento la tostadora y además me informe en el móvil que la tostadora se pone un funcionamiento y me indique la temperatura de la tostadora.

Lo primero que necesito es un sensor para medir la temperatura y un actuador que encienda la tostadora. Para poder leer el sensor y poder manejar el actuador necesitaré un microcontrolador con entradas (sensor) y salidas (actuador), por ejemplo, un Arduino.

Ahora ya puedo leer los datos de la tostadora y encenderla, el siguiente paso es conectarla a Internet.

Primero necesito acceso a Internet (conectividad), puedo usar ethernet, pero ¿Quien tiene una toma de red en la cocina?

Mejor usando comunicaciones inalámbricas como: wifi, bluetooth, redes móviles, XBee, etc…

Una vez tenemos conectividad, necesitamos un protocolo de comunicación para comunicar los datos y las órdenes entre los distintos dispositivos.

  • HTTP REST

  • MQTT

Supongamos tenemos nuestra tostadora con un Arduino integrado y un chip WiFi. Hay dos formas en la que pueden hablar entre el geolocalizador del coche y nuestra tostadora.

  • Tener uno de los dispositivos trabajando como servidor con una dirección IP, de forma que el otro dispositivo se pueda conectar en cualquier momento.
  • Tener un tercer servidor y tanto la tostadora como el coche se conecten al servidor y este mande mensajes a uno y otro.

La opción 1 es la más barata al no necesitar un elemento extra, pero al menos uno de los dispositivos necesita una IP pública conocida y fija, además hay que abrir puertos en el router de casa lo que supone una dificultad adicional y un punto más en la seguridad.

En la opción 2 el servidor maneja los mensajes, en el caso de MQTT se trata del broker. Es un elemento neutral al que las “cosas” se pueden conectar para enviar y recibir mensajes.

Adicionalmente podemos tener una plataforma que almacene datos y luego podamos visualizarlos, analizarlos, hacer cuadros de mando o interactuar con otras plataformas o servicios de terceros.

Elementos que Intervienen en el Ecosistema IoT

Explicación gráfica de los elementos necesarios en IoT: http://www.libelium.com/products/meshlium/wsn/

En resumen, al hacer un proyecto IoT debemos hacernos estas preguntas:

  • Qué quieres medir?
  • Cómo lo quieres conectar?
  • Qué quieres hacer con los datos?

Elementos en IoT:

  • Plataformas Software, para tratar los datos recogidos por nuestros sensores y almacenarlos. Pueden ser plataformas de terceros o plataformas propias desarrolladas por nosotros o simplemente guardar en BBDD propias. Por ejemplo: Carriots, Thingspeak, Temboo, Thinger, etc…
    Además todas estas plataformas SW que están en la nube, deben estar soportadas por un HW de servidores, unas BBDD de gran capacidad y una infraestructura segura que los hospede.
  • Servicios, son los servicios que ofrecen las plataformas como mostrar los datos recogidos, mandar avisos cuando se detecte un evento o la interconexión con otras plataformas o simplemente. Servicios ofrecidos por la plataforma carriots: https://www.carriots.com/que-es-carriots

Sensor — MCU — Comunicación — Protocolo — Plataforma — Servicios

Uno de los retos del IoT es mandar datos de cualquier sensor a través de cualquier protocolo a cualquier plataforma de forma inalámbrica y usando la menor energía posible para uso de baterías

Cadena de valor de IoT:

recoger datos — conectar — almacenar — analizar — mostrar — actuar — predecir

Mapa de IoT:

Mapa más complejo de IoT (imagen de la plataforma IoT de IBM):

Arduino IoT Manifesto: https://www.edn.com/electronics-blogs/eye-on-iot-/4441804/Arduino-s-IoT-Manifesto

“We believe that the best way to grow this environment is to develop open source platforms and protocols to propose as an alternative to the myriad of proprietary hardware and software platforms each one of the big players are developing.

We believe in creating tools that make these technologies understandable to the most diverse set of people as possible, this is the only way to make sure innovation benefits most of humanity.

We propose that connected devices should be: Open, Sustainable and Fair.”

“We foresee a world with billions of connected smart objects. These smart objects will be composed and orchestrated, thus making the Internet of Things a reality. The IoT will be the eyes, noses, arms, legs, hands of a new, extended, cyber body. The nervous system of such a body will be the Internet, allowing the interaction with a distributed intelligence made of hardware processors and human minds, behaviors, software procedures, and services, shared in the Cloud.”

Arduino cree que mediante la creación de nuevos productos conectados con software, hardware y protocolos de comunicación de código abierto podemos crear un entorno más innovador para fabricantes, empresarios y corporaciones. Al ofrecer a los usuarios la posibilidad de compartir su trabajo de forma más abierta, compartimos desafíos, resolvemos problemas y creamos juntos productos mejor conectados. Estamos seguros de que un enfoque abierto y compartido para el diseño de software, protocolos y hardware es la mejor solución.

Protocolos IoT

Esta conferencia sobre IoT con Arduino fue expuesta el 1 de abril de 2017 con motivo del Arduino Day. Puedes ver el video de la conferencia completa en http://www.innovarioja.tv/index.php/video/ver/1661


Protocolos de comunicación, con los que comunicar el HW con el SW

  • API REST/HTTP

  • REST + Websockets

  • MQTT (Message Queue Telemetry Transport).
    Está enfocado al envío de datos en aplicaciones donde se requiere muy poco ancho de banda. Además, sus características le permiten presumir de tener un consumo realmente bajo así como precisar de muy pocos recursos para su funcionamiento.
    Estas características han hecho que rápidamente se convierta en un protocolo muy empleado en la comunicación de sensores y, consecuentemente, dentro del Internet de las Cosas.

Comparativa de protocolos: https://www.slideshare.net/paolopat/mqtt-iot-protocols-comparison

IoT protocols: https://www.postscapes.com/internet-of-things-protocols/

Qué es IoT

Esta conferencia sobre IoT con Arduino fue expuesta el 1 de abril de 2017 con motivo del Arduino Day. Puedes ver el video de la conferencia completa en http://www.innovarioja.tv/index.php/video/ver/1661


Internet de las cosas (en inglés Internet of things, abreviado IoT) es un concepto que se refiere a la interconexión digital de objetos cotidianos con Internet.

Definición de wikipedia: https://es.wikipedia.org/wiki/Internet_de_las_cosas

Arduino es un elemento que nos permite de forma sencilla y económica conectar cosas a Internet. Con un sencillo módulo ethernet o wifi podemos conectar Internet sensores para informar, motores controlados desde cualquier lado del mundo o mandar un SMS o email cada vez que se abra la puerta de casa.

Arduino se ha convertido una figura destacada e incluso uno de los impulsores del IoT y no por casualidad, sino que  por sus características es un HW con gran capacidad para usar en proyectos de IoT.

Características de Arduino para IoT

  • Barato y rápido prototipado.
  • HW libre y por lo tanto es modificable para que consuma menos y para hacer un HW final de características industriales.
  • Disponibilidad de HW de comunicaciones de todo tipo para conectar con Arduino. Nuevas tecnologías de comunicación llegan antes que para elementos comerciales
  • Librerías y SW público para su reutilización o adaptación.
  • Flexibilidad en la programación.
  • Apoyo de la comunidad.

IoT en su amplio concepto es conectar a Internet cualquier cosa, teniendo sentido o sin tenerlo. Por ejemplo, podríamos conectar a internet un sofá con un Arduino y unos pocos sensores, este sofá podría tuitear que nos acabamos de sentar a ver nuestra serie favorita, simplemente detectando el peso de la persona y conectándose a una API de un servidor de streaming como netflix y comprobando que acabo de poner un capítulo de Narcos. Pero esta idea para netflix podría ser muy interesante, monitorizar a la gente que ve su canal.

Otra aplicación de IoT y usando arduino como herramienta, es la de obtener información externa disponible mediante APIs del open data. Un ejemplo es el de un sistema de riego automático que podemos tener en una huerta. En los inicios de la automatización se usaron programadores conectados a una electroválvula donde indicamos las horas entre las que deseamos regar. El siguiente paso fue poner detectores de lluvia para no regar si estaba lloviendo. Otro paso fue poner sensores de temperatura y humedad ambientales y sensores de humedad de suelo que nos indican cuándo debemos regar y en qué áreas de nuestra huerta.

El paso más avanzado que ofrece el IoT es poder conectar todo este sistema, ya de por sí muy eficiente, a los opendata meteorológicos disponibles en Internet como el de la aemet (http://www.aemet.es/es/datos_abiertos/AEMET_OpenData) y que nuestro sistema obtenga datos de prediciones meteorológicas y decida no regar si la predicción de lluvia es mayor del 80% en los próximos dos días o simplemente ajustar el algoritmo de riego en función los valores de los sensores + es de los datos meteorológicos. También puede recibir alertas de tormenta o pedrisco y tomar determinadas acciones o simplemente mandar un email o SMS al propietario del huerto. ¿Podríamos hacer esto con un sistema comercial?

Esto podría extenderse a explotaciones agrícolas usando un servicio como el sistema de información agroclimática de La Rioja:

IoT nos permite actualizar procesos productivos al siglo XXI (Retrofit)

Para mi, IoT no es que un coche se pueda conectar a Internet para ver videos de youtube, sino que este coche esté conectado a Internet para que pueda actualizar su firmware automáticamente sin necesidad de ir al concesionario, pueda ser inmovilizado en caso de robo o pueda mandar datos de los parámetros internos del coche para que sean analizados y poder detectar alertas precoces de fallo y actualizar automáticamente ese fallo sin que el usuario tenga que hacer nada o avisar al usuario para que lleve el coche a reparar y parar el coche si el usuario no ha llevado a revisión al cabo de unos kms para evitar males mayores.

Explicación de IoT http://www.kaaproject.org/iot-101-what-is-an-iot-platform/

Cómo Conectar a Internet una Tostadora?

Veamos un resumen de los elementos que necesitamos para conectar un dispositivo a Internet y hacer un proyecto de IoT completo.

Supongamos que quiero conectar mi tostadora a Internet y hacer un sistema que conecte mi coche con la tostadora y cuando me acerque a casa ponga en funcionamiento la tostadora y además me informe en el móvil que la tostadora se pone un funcionamiento y me indique la temperatura de la tostadora.

Lo primero que necesito es un sensor para medir la temperatura y un actuador que encienda la tostadora. Para poder leer el sensor y poder manejar el actuador necesitaré un microcontrolador con entradas (sensor) y salidas (actuador), por ejemplo, un Arduino.

Ahora ya puedo leer los datos de la tostadora y encenderla, el siguiente paso es conectarla a Internet.

Primero necesito acceso a Internet (conectividad), puedo usar ethernet, pero ¿Quien tiene una toma de red en la cocina?

Mejor usando comunicaciones inalámbricas como: wifi, bluetooth, redes móviles, XBee, etc…

Una vez tenemos conectividad, necesitamos un protocolo de comunicación para comunicar los datos y las órdenes entre los distintos dispositivos.

  • HTTP REST

  • MQTT

Supongamos tenemos nuestra tostadora con un Arduino integrado y un chip WiFi. Hay dos formas en la que pueden hablar entre el geolocalizador del coche y nuestra tostadora.

  1. Tener uno de los dispositivos trabajando como servidor con una dirección IP, de forma que el otro dispositivo se pueda conectar en cualquier momento.
  2. Tener un tercer servidor y tanto la tostadora como el coche se conecten al servidor y este mande mensajes a uno y otro.

La opción 1 es la más barata al no necesitar un elemento extra, pero al menos uno de los dispositivos necesita una IP pública conocida y fija, además hay que abrir puertos en el router de casa lo que supone una dificultad adicional y un punto más en la seguridad.

En la opción 2 el servidor maneja los mensajes, en el caso de MQTT se trata del broker. Es un elemento neutral al que las “cosas” se pueden conectar para enviar y recibir mensajes.

Adicionalmente podemos tener una plataforma que almacene datos y luego podamos visualizarlos, analizarlos, hacer cuadros de mando o interactuar con otras plataformas o servicios de terceros.

En resumen, al hacer un proyecto IoT debemos hacernos estas preguntas:

  • Qué quieres medir?
  • Cómo lo quieres conectar?
  • Qué quieres hacer con los datos?

Elementos que intervienen en el IoT

Elementos en IoT:

  • Plataformas Software, para tratar los datos recogidos por nuestros sensores y almacenarlos. Pueden ser plataformas de terceros o plataformas propias desarrolladas por nosotros o simplemente guardar en BBDD propias. Por ejemplo: Carriots, Thingspeak, Temboo, Thinger, etc…
    Además todas estas plataformas SW que están en la nube, deben estar soportadas por un HW de servidores, unas BBDD de gran capacidad y una infraestructura segura que los hospede.
  • Servicios, son los servicios que ofrecen las plataformas como mostrar los datos recogidos, mandar avisos cuando se detecte un evento o la interconexión con otras plataformas o simplemente. Servicios ofrecidos por la plataforma carriots: https://www.carriots.com/que-es-carriots

Sensor — MCU — Comunicación — Protocolo — Plataforma — Servicios

Uno de los retos del IoT es mandar datos de cualquier sensor a través de cualquier protocolo a cualquier plataforma de forma inalámbrica y usando la menor energía posible para uso de baterías.

Cadena de valor de IoT:

recoger datos — conectar — almacenar — analizar — mostrar — actuar — predecir

IoT Manifesto

Arduino IoT Manifesto: https://create.arduino.cc/iot/manifesto/

“Arduino cree que construyendo nuevos productos conectados con SW, HW y protocolos de comunicación open source, podemos hacer un entorno más innovador para los makers, emprendedores y grandes corporaciones. Dando a los usuarios de posibilidad de compartir su trabajo abiertamente, compartimos retos, resolvemos problemas y construimos mejores productos conectados.

Estamos seguros que con una aproximación abierta y compartida de SW, HW y protocolos es la mejor solución”

Esta aproximación puede extender al mundo empresarial el concepto de DIY, permitiendo hacer pruebas de conceptos y pequeños proyectos por uno mismo y en caso que sea viable lanzarse a proyectos profesionales con el apoyo de expertos.