Archivo de la etiqueta: API REST

Integración Node-RED con Otros Servicios

Integración con MQTT

Para integrar Node-RED con servicios MQTT existen los nodos de MQTT de publish y suscribe.

Más información: http://www.steves-internet-guide.com/configuring-the-mqtt-publish-node/

MQTT Recipes:

Integración con API REST

Para integrar Node-Red con APIs que utilizan el protocolo HTTP demos usar las HTTP requests de Node-RED. HTTP recipes en Node-RED: https://cookbook.nodered.org/http/

Nodo HTTP request: https://flows.nodered.org/node/node-red-contrib-http-request

NOTA: antes de usar el nodo de HTTP request para acceder a una API pública buscar en https://flows.nodered.org/ si ya de ha publicado el nod que lo haga. Por ejemplo https://flows.nodered.org/node/node-red-node-openweathermap

HTTP requests

HTTP request para novatos: http://www.steves-internet-guide.com/node-red-http-request-node-beginners/

El nodo de solicitud http se mejoró enormemente en Node-RED versión 0.20 con la adición de los modos de autenticación Bearer y Digest. Además, se agregó una nueva opción para permitir la creación de una cadena de consulta de msg.payload.

El nodo de solicitud HTTP opcionalmente puede codificar automáticamente msg.payload como parámetros de cadena de consulta para una solicitud GET.

Por ejemplo:

Ejemplo Básico 

Ejemplo sencillo de recopilación de datos regularmente de una web de terremotos https://earthquake.usgs.gov/, convertir los datos y generar una alerta si el terremoto tiene un valor mayor o igual que 7.

Obtengo los terremotos significativos de los últimos 30 días: https://earthquake.usgs.gov/earthquakes/map/#%7B%22feed%22%3A%2230day_sig%22%2C%22search%22%3Anull%2C%22listFormat%22%3A%22default%22%2C%22sort%22%3A%22newest%22%2C%22basemap%22%3A%22terrain%22%2C%22autoUpdate%22%3Atrue%2C%22restrictListToMap%22%3Afalse%2C%22timeZone%22%3A%22utc%22%2C%22mapposition%22%3A%5B%5B-78.49055166160312%2C74.8828125%5D%2C%5B78.42019327591201%2C325.1953125%5D%5D%2C%22overlays%22%3A%7B%22plates%22%3Atrue%7D%2C%22viewModes%22%3A%7B%22map%22%3Atrue%2C%22list%22%3Atrue%2C%22settings%22%3Afalse%2C%22help%22%3Afalse%7D%7D

Tutorial: https://nodered.org/docs/tutorials/second-flow 

Ejemplo AEMET

Ejemplo más complejo donde se deben realizar varios pasos para obtener los datos de la AEMET.

Ejemplos: https://github.com/jecrespo/Curso-Node-RED/tree/master/01-REQUEST%20API%20REST

Ejemplo de integración con API de lectores 2N

Es posible integrar Node-RED con los lectores de tarjetas de 2N. Card readers AccessUnit: https://www.2n.cz/en_GB/products/ip-access-control

Manual API: https://wiki.2n.cz/hip/hapi/latest/en

Si quiero abrir remotamente el switch mediante Node-RED, me conecto a las APIs:

Usa digest authentication:

Envío de Emails

Nodo para envío de emails: https://flows.nodered.org/node/node-red-node-email

npm: https://www.npmjs.com/package/node-red-node-email

Si está accediendo a GMail, es posible que necesites habilitar una contraseña de aplicación o habilitar un acceso menos seguro a través de la configuración de su cuenta de Google.

Si inicias directamente no deja hacerlo google porque: https://support.google.com/accounts/answer/6010255?p=lsa_blocked&hl=es&visit_id=637210948261881071-1978480038&rd=1

Para resolverlo:

Solucionar problemas si no puedes loguearte con tu cuenta de gmail: https://support.google.com/mail/answer/7126229?visit_id=637210978957705918-3645915622&rd=2#cantsignin

Input: Repetidamente recibe correos electrónicos de un servidor IMAP o POP3 y los reenvía como mensajes si aún no los ha visto. El asunto se carga en msg.topic y msg.payload es el cuerpo del texto sin formato. Si hay texto / html, se devuelve en msg.html. msg.from y msg.date también se establecen si los necesita.

Además, msg.header contiene el objeto de encabezado completo que incluye a, cc y otras propiedades potencialmente útiles.

Output: Envía msg.payload como un correo electrónico, con un asunto de msg.topic. El destinatario predeterminado del mensaje se puede configurar en el nodo; si se deja en blanco, se debe configurar con la propiedad msg.to del mensaje entrante.

Opcionalmente, puede anular la dirección de correo electrónico desde configurando msg.from, de lo contrario, el nodo utilizará la configuración de ID de usuario desde la conexión del servidor.

El payload puede tener formato html. Si payload es un búfer binario, se convertirá en un archivo adjunto. El nombre del archivo debe establecerse usando msg.filename. Opcionalmente, se puede agregar msg.description para el texto del cuerpo.

Alternativamente, puede proporcionar msg.attachments que deben contener una matriz de uno o más archivos adjuntos en formato nodemailer.

Estos nodos utilizan el módulo npm imap y nodemailer.

Ejemplos:

Otros relativos a email:

Envio SMS

Mandar SMSs usando el servicio de Twilio: https://www.twilio.com/

Pricing: https://www.twilio.com/pricing

Free account: https://www.twilio.com/docs/usage/tutorials/how-to-use-your-free-trial-account

Trial de Twilio: https://support.twilio.com/hc/en-us/articles/223136107-How-does-Twilio-s-Free-Trial-work-

Limitaciones de la cuenta gratuita: https://support.twilio.com/hc/en-us/articles/360036052753-Twilio-Free-Trial-Limitations

TwiML: https://www.twilio.com/docs/voice/twiml

Nodo: https://flows.nodered.org/node/node-red-node-twilio

Envía un mensaje SMS o realiza una llamada de voz utilizando el servicio Twilio. El nodo de salida Twilio está configurado para enviar SMS o hacer llamadas, dependiendo de la opción seleccionada ingrese el número de teléfono o número de teléfono y una URL para crear el archivo de respuesta TWiML.

msg.payload se usa como el cuerpo del mensaje. El nodo se puede configurar con el número al que enviar el mensaje. Alternativamente, si el número se deja en blanco, se puede configurar usando msg.topic. La carga útil también puede ser la URL para crear el archivo de respuesta TWiML.

Debe tener una cuenta con Twilio para usar este nodo.

Aquí hay un ejemplo del uso de este nodo para crear un IVR simple: https://flows.nodered.org/flow/637b5f6128a8d423503f

SMS con Node-RED USANDO UN PINCHO 3G: https://maker.pro/raspberry-pi/tutorial/how-to-make-an-sms-app-for-raspberry-pi-with-node-red

Telegram

Este paquete contiene un receptor y un nodo emisor que actúan como un bot de Telegram. Lo único que se requiere es el token que puede recuperar el bot de telegram @botfather.

Bots en Telgram: https://core.telegram.org/bots

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

Nodo: https://flows.nodered.org/node/node-red-contrib-telegrambot

Basado en https://github.com/yagop/node-telegram-bot-api

El nodo de entrada recibe mensajes del bot y envía un objeto de mensaje con el siguiente layout:

  • msg.payload contiene los detalles del mensaje
    • chatId: la identificación única del chat. Este valor debe pasarse al nodo de salida al responder al mismo chat.
    • type: el tipo de mensaje recibido: mensaje, foto, audio, ubicación, video, animación, voz, contacto
    • content: contenido del mensaje recibido: cadena o id_archivo, u objeto con datos completos (ubicación, contacto)
  • msg.originalMessage contiene el objeto de mensaje original de la librería https://github.com/yagop/node-telegram-bot-api

El nodo de salida envía el contenido a un chat específico. Un flujo de eco simple se ve así:

Nodo de Configuración

Lo único que se debe ingresar aquí es el token que recibió de @botfather al crear un nuevo bot. El nodo contiene dos propiedades opcionales: users y chatids. Puede ingresar una lista de nombres y/o chatids que estén autorizados para usar este bot.

Receiver Node

Este nodo recibe todos los mensajes de un chat. Simplemente invita al bot a un chat. Puede controlar si el bot recibe todos los mensajes llamando / setprivacy @botfather.

El mensaje original de la biblioteca de nodos subyacente se almacena en msg.originalMessage.

msg.payload contiene los datos más importantes como chatId, tipo y contenido. El contenido depende del tipo de mensaje. Si recibe un mensaje, el contenido es una cadena. Si recibe una ubicación, el contenido es un objeto que contiene latitud y longitud.

La segunda salida se activa cuando se aplica seguridad y el usuario no está autorizado para acceder al bot.

Cuando el nodo receptor recibe datos como videos, documentos, etc., el archivo se descarga automáticamente al disco duro local cuando saveDataDir se configura en el nodo de configuración. El directorio también forma parte de la carga útil del mensaje: msg.payload.path. Además, el mensaje contiene el enlace de descarga directa en la carga útil: msg.payload.weblink

Los siguientes tipos pueden ser recibidos:

  • message – content is text
  • photo – content is the file_id of the photo with the highest resolution (all photos are stored in the photos property of the output object)
  • audio – content is the file_id of the audio file
  • document – content is the file_id of the document
  • sticker – content is the file_id of the sticker
  • animation – content is the file_id of the animation file
  • video – content is the file_id of the video file
  • video_note – content is the file_id of the video note file
  • voice – content is the file_id of the voice file
  • location – content is an object with latitude and longitude
  • venue – content is the venue object
  • contact – content is the contact information object Note that media groups are received not as group, but as separate messages of type photo and video.

Sender Node

Este nodo envía la carga útil al chat. La carga útil debe contener los siguientes campos:

  • msg.payload.chatId – chatId o una matriz de chatIds si desea enviar el mismo mensaje a muchos chats
  • msg.payload.type, p.e. «message»
  • msg.payload.content – su mensaje de texto
  • msg.error – se establece cuando ocurre una excepción

Junto al envío de contenido, el nodo remitente se puede utilizar para enviar comandos directos a la API. msg.payload.type debe establecerse en uno de los siguientes, msg.payload.content contiene los argumentos necesarios, mientras se pasan argumentos adicionales en msg.payload.options:

  • editMessageCaption
  • editMessageText
  • editMessageReplyMarkup
  • deleteMessage
  • editMessageLiveLocation
  • stopMessageLiveLocation
  • callback_query
  • inline_query
  • action
  • leaveChat
  • kickChatMember
  • unbanChatMember
  • restrictChatMember
  • promoteChatMember
  • exportChatInviteLink
  • setChatPhoto
  • deleteChatPhoto
  • setChatTitle
  • setChatDescription
  • pinChatMessage
  • unpinChatMessage
  • getChatAdministrators
  • getChatMembersCount
  • getChat
  • getChatMember

Command Node

El nodo de comando se puede usar para activar un mensaje cuando se recibe un comando específico: p. help.

Tiene dos salidas

  1. se activa cuando se recibe el comando
  2. se activa cuando no se recibe el comando

El segundo es útil cuando quieres usar un teclado. Los comandos generalmente comienzan con /. De acuerdo con la documentación de la API de Telegram, el comando debe emitirse siguiendo el nombre del bot como /foo@YourBot. Esto es importante cuando agrega varios bots diferentes a un solo chat grupal. Para evitar que el bot maneje comandos que no se le envían directamente usando la notación larga, puede establecer el modo «estricto» en las opciones del nodo de comando. En este caso, el bot solo acepta la notación de comando completo en los chats grupales.

Event Node

El nodo recibe eventos del bot como:

  • callback_query de teclados en línea.
  • inline_query
  • edited_message que se activa cuando alguien modifica un mensaje ya enviado.
  • edited_message_text que se activa cuando alguien modifica un mensaje de texto ya enviado.
  • edited_message_caption que se activa cuando alguien modifica un caption ya enviado, p.e. una foto
  • channel_post que se activa cuando el bot es miembro de un canal público (/setprivacy to disabled).
  • edited_channel_post, que se activa cuando alguien modifica un mensaje ya enviado en un canal público.
  • edited_channel_post_text, que se activa cuando alguien modifica un mensaje de texto ya enviado en un canal público.
  • edited_channel_post_caption que se activa cuando alguien altera un caption ya enviado de p.e. una foto en un canal público.

Reply Node

El nodo de respuesta espera una respuesta a un mensaje específico. Debe usarse junto con el nodo emisor.

Ejemplos

Implementar un comando help:

Implementar un teclado:

La respuesta es enviada a la segunda salida que activa el flujo inferior. Los datos se pasan a través de propiedades globales aquí.

Ver más ejemplos en: https://flows.nodered.org/node/node-red-contrib-telegrambot

Twitter

Nodos para usar twitter con Node-RED

Nodo: https://flows.nodered.org/node/node-red-node-twitter

Es necesario darse de alta como developer en Twitter: https://developer.twitter.com/en/apps

Proporciona dos nodos: uno para recibir mensajes y otro para enviar.

Nodo de entrada de Twitter. Se puede usar para buscar:

  • el público o la transmisión de un usuario para tweets que contienen el término de búsqueda configurado
  • todos los tweets de usuarios específicos
  • mensajes directos recibidos por el usuario autenticado

El nodo de salida de Twitter tuitea msg.payload.

Para enviar un mensaje directo (DM), use una carga útil como:

  • D {username} {message}

Consumir streaming data de Twitter: https://developer.twitter.com/en/docs/tutorials/consuming-streaming-data

Open Weather Map

Obtener datos climatológicos: https://openweathermap.org/

Se podría usar la API y hacer una integración similar a la vista en el apartado de API REST, pero en este caso al haber un nodo, se simplifica todo.

Y ver openweathermap y la API: https://openweathermap.org/api

Open Weather Map:

Un nodo de Nodo-RED que obtiene el informe meteorológico y el pronóstico de OpenWeatherMap.

Dos nodos que obtienen el informe meteorológico y el pronóstico de OpenWeatherMap.

Se requiere una clave API para usar estos nodos. Para obtener una clave API, vaya a OpenWeatherMap.

Input Node: Obtiene el clima actual o el pronóstico de 5 días en una ubicación especificada por ciudad y país o latitud y longitud cada 10 minutos, y genera un mensaje si algo ha cambiado.

Query Node: Acepta una entrada para activar la obtención del clima actual, ya sea desde una ciudad y país específicos o latitud y longitud.

Resultados de clima actual:

  • description – a brief verbal description of the current weather for human reading.
  • weather – a very short description of the current weather.
  • icon – the weather icon code for the current conditions.
  • id – the id given to the current weather by OpenWeatherMap
  • tempc – the current ground temperature at that location in Celsius.
  • tempk – the current ground temperature at that location in Kelvin.
  • humidity – the current relative humidity at the location in percent.
  • windspeed – the current wind speed at the location in metres per second.
  • winddirection – the current wind direction at the location in meteorological degrees.
  • location – the name of the location from which the data was sourced.

Pronóstico de 5 días:

  • dt – epoch timestamp
  • pressure – in hPa
  • humidity – in %
  • speed – wind speed in metres per second
  • deg – wind direction in degrees
  • clouds – cloudiness in %
  • temp – an object with various temperatures in degC,
    • day, min, max, night, eve, morn
  • weather – an object with some misc. data,
    • description, icon, main, id

Más información en: https://flows.nodered.org/node/node-red-node-openweathermap

Ejemplos:

IFTTT

Cualquiera puede pensar que node-red es un superconjunto de IFTTT y que todo lo que puede hacer con IFTTT debe poder hacerlo con node-red. Pero en algunos casos nos puede ser útil y más rápido hacerlo con IFTTT.

Tres librerías:

Es necesaria la API key de IFTTT.

Maker Webhooks: https://ifttt.com/maker_webhooks

Me permite hacer llamadas a webhooks que se integran con herramientas de terceros.

Publica msg.payload.value1, 2 y 3 en el canal Maker en IFTTT en el canal especificado.

Creo el evento “nodered” para mandar datos al webhook.

Otra librería más avanzada pero en un estado de desarrollo temprano es: https://flows.nodered.org/node/node-red-contrib-ifttt-broker

Ejemplos:

Itinerario Formación IoT/Industria 4.0

En un acercamiento a esta disciplina, se busca conocer las tecnologías necesarias para el desarrollo de soluciones IoT/Industria Conectada y valiéndonos para ello de herramientas, tecnologías, protocolos y software libre/open source que hay a nuestra disposición, de forma que cualquier empresa por pequeña que sea pueda hacer un proyecto sencillo de IoT/Industria 4.0 con una inversión mínima, sea cual sea el sector al que pertenezca.

No solo las grandes empresas pueden dar el salto a IoT, la tecnologías libres permiten que sea factible la digitalización de las pymes con una inversión económica mínima y que surja la innovación desde las propias empresas con una formación adecuada a sus trabajadores.

Fundamentos IoT (Nivel 1)20 h
Dispositivos HW IoT (Nivel 2)20 h
Infraestructuras IoT (Nivel 3)20 h
Conectividad IoT (Nivel 3)20 h
Plataformas IoT (Nivel 4)20 h
Desarrollo Soluciones IoT con Herramientas Libres (Nivel 5)20 h

Ver Anexo I con el material necesario para impartir los cursos de este itinerario.

Fundamentos IoT (Nivel 1)

Objetivo

Describir los fundamentos de Internet de las Cosas e identificar los distintos mercados a los que el alumno puede orientar su actividad profesional.

Dado que las comunicaciones, la conexión a Internet y los dispositivos conectados es un aspecto importante actualmente y los conceptos de computación y comunicaciones van unidos de la mano cuando hablamos de las TIC (Tecnologías de la Información y de la Comunicación), vamos a tratar también en este curso las comunicaciones y la programación de los dispositivos conectados.

Toda la documentación del curso y el código usado es libre y accesible desde https://www.aprendiendoarduino.com/.

Al finalizar el curso el alumno será capaz de:

  • Conocer qué es IoT
  • Reconocer las tecnologías y arquitecturas de IoT
  • Capas en IoT
  • Saber los retos de IoT
  • Importancia de la seguridad den IoT
  • Empresas en IoT
  • Conocer los mercados verticales de IoT
  • Saber los servicios que ofrece IoT

Requisitos Alumnos

No son necesarios requisitos previos de los alumnos para asistir a este curso

Contenido del Curso

  • Qué es el IoT. Visión Holística
  • Ecosistema IoT
  • Retos de IoT
  • Industria 4.0. IIoT
  • Empresas en IoT
  • Mercados Verticales IoT
  • Campos Profesionales IoT
  • Aplicaciones IoT

Dispositivos HW IoT (Nivel 2)

Objetivo

Visión general del HW en el ecosistema IoT y puesta en práctica. Identificar la solución Hardware y Firmware más correcta para un proyecto IoT.

Analizar el hardware y el firmware utilizado dentro el ecosistema IoT y programar algunas las plataformas de prototipado más populares del mercado

Toda la documentación del curso y el código usado es libre y accesible desde https://www.aprendiendoarduino.com/.

Al finalizar el curso el alumno será capaz de:

  • Conocer las plataformas HW IoT 
  • Conocer el firmware usado en las plataformas HW
  • Identificar la solución Hardware y Firmware más correcta para un proyecto IoT
  • Utilizar plataformas de prototipado IoT

Requisitos Alumnos

Haber cursado el módulo de Fundamentos IoT o tener experiencia en HW y Firmware IoT.

Contenido del Curso

  • Dispositivos IoT
  • HW IoT Industrial
  • Firmware: SW de los dispositivos
  • Plataforma de Prototipado
  • Prácticas Firmware
  • HW IoT Comercial

Infraestructuras de Comunicaciones IoT (Nivel 3)

Objetivo

Visión detallada de las infraestructuras y conectividad en IoT con ejemplos prácticos en algunas tecnologías. El alumno será capaz de analizar las necesidades de una solución IoT, ofrecer la mejor solución e implementarla. 

Utilizar las Infraestructuras de comunicación que se usan hoy en día para IoT

Toda la documentación del curso y el código usado es libre y accesible desde https://www.aprendiendoarduino.com/.

Al finalizar el curso el alumno será capaz de:

  • Conocer las diferentes infraestructuras de comunicaciones IoT disponibles en el mercado
  • Comparar las tecnologías inalámbricas y saber elegir la más adecuada dependiendo del proyecto.
  • Ofrecer e implantar soluciones IoT a nivel de conectividad e infraestructuras IoT a partir del análisis de necesidades del proyecto
  • Utilizar algunas de las comunicaciones con placas de prototipado como Arduino y ESP8266

Requisitos Alumnos

Haber cursado el módulo de Fundamentos IoT o tener experiencia en infraestructuras y conectividad IoT.

Contenido del Curso

  • Conectividad IoT
  • Redes Inalámbricas IoT
  • Infraestructura de Comunicación IoT
  • Prácticas de Comunicaciones IoT

Conectividad IoT (Nivel 3)

Objetivo

Visión detallada de las infraestructuras y conectividad en IoT con ejemplos prácticos en algunas tecnologías. El alumno será capaz de analizar las necesidades de una solución IoT, ofrecer la mejor solución e implementarla. 

Analizar los protocolos más populares para dotar de conectividad a los dispositivos IoT y configurar el software

Toda la documentación del curso y el código usado es libre y accesible desde https://www.aprendiendoarduino.com/.

Al finalizar el curso el alumno será capaz de:

  • Conocer los protocolos más populares usados en IoT
  • Profundizar en el protocolo HTTP y el uso de API REST
  • Profundizar en el protocolo MQTT y su uso en aplicaciones IoT
  • Instalar, configurar y usar un broker MQTT
  • Ofrecer e implantar soluciones IoT a nivel de conectividad e infraestructuras IoT a partir del análisis de necesidades del proyecto

Requisitos Alumnos

Haber cursado el módulo de Fundamentos IoT o tener experiencia en infraestructuras y conectividad IoT.

Contenido del Curso

  • Protocolos IoT
  • Protocolo HTTP
  • Uso de API REST
  • Protocolo MQTT
  • Práctica MQTT

Plataformas IoT (Nivel 4)

Objetivo

Visión general de las plataformas IoT y trabajo detallado en algunas de ellas. Proponer, instalar y configurar la plataforma más adecuada para el desarrollo de soluciones IoT.

Analizar las  las plataformas existentes en IoT e instalar y configurar alguna de las más utilizadas.

Toda la documentación del curso y el código usado es libre y accesible desde https://www.aprendiendoarduino.com/.

Al finalizar el curso el alumno será capaz de:

  • Conocer las plataformas IoT Generalistas y especializadas más usadas
  • Conocer plataformas open source, instalar y configurar en un servidor
  • Encontrar la plataforma adecuada para una solución IoT, instalación y configuración
  • Programar servicios usando Node-Red
  • Uso de Bases de Datos para almacenamiento de datos
  • Configuración y uso de Dashboards
  • Analizar datos de forma visual

Requisitos Alumnos

Haber cursado el módulo de Fundamentos IoT o tener experiencia en plataformas IoT.

Contenido del Curso

  • Plataformas Cloud Generalistas
  • Plataformas Cloud Especializadas
  • Práctica de Plataformas Cloud
  • Plataformas Privadas/Libres
  • Práctica Plataformas Privadas/Libres
  • Servicios IoT
  • Node-Red
  • Bases de Datos
  • Dashboards
  • Ejemplos prácticos IoT

Desarrollo Soluciones IoT con Herramientas Libres (Nivel 5)

Objetivo

Este curso pretende unificar todos los conocimiento adquiridos en los anteriores cursos del itinerario IoT para hacer un proyecto “full stack” de IoT.

Unificar los conocimientos adquiridos en los otros cursos, identificar necesidades reales con respuestas desde el IoT y desarrollar una solución específica para una necesidad.

Toda la documentación del curso y el código usado es libre y accesible desde https://www.aprendiendoarduino.com/.

Al finalizar el curso el alumno será capaz de:

  • Proponer e implementar soluciones IoT como respuesta a necesidades específicas
  • Desarrollar un proyecto IoT  estructurado según las fases relacionadas en cada módulo  que de respuesta a una necesidad real del entorno del alumno

Requisitos Alumnos

Los alumnos deberán haber cursado todos los cursos del itinerario IoT o tener experiencia en el desarrollo de soluciones IoT

Contenido del Curso

  • Repaso de conceptos
  • Ejemplo de soluciones IoT Completas
  • Identificación de necesidades
  • Presentación preliminar
  • Desarrollo del Proyecto
  • Presentación del Proyecto

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:

Uso de API REST con Node-RED

Para integrar Node-Red con APIs que utilizan el protocolo HTTP debemos usar las HTTP requests/response de Node-RED.

HTTP recipes en Node-RED: https://cookbook.nodered.org/http/

Nodo HTTP request: https://flows.nodered.org/node/node-red-contrib-http-request

NOTA: antes de usar el nodo de HTTP request para acceder a una API pública buscar en https://flows.nodered.org/ si ya se ha publicado el nodo que lo haga. Por ejemplo https://flows.nodered.org/node/node-red-node-openweathermap

HTTP requests

HTTP request para novatos: http://www.steves-internet-guide.com/node-red-http-request-node-beginners/

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.