educantabria/nodo00/m5atom/boton – al pulsar publica “press” o “longpress”
educantabria/nodo00/m5stack/boton/A – al pulsar botón A publica “press”
educantabria/nodo00/m5stack/boton/B – al pulsar botón B publica “press”
educantabria/nodo00/m5stack/boton/C – al pulsar botón C publica “press”
educantabria/nodo00/m5stack/led – suscrito (1 dibuja en pantalla círculo rojo, otro valor dibuja en pantalla círculo verde)
educantabria/nodo00/m5stack/text – suscrito, muestra por pantalla el texto
educantabria/nodo00/m5stick/temperatura – publica dato temperatura cada 1 segundo
educantabria/nodo00/m5stick/humedad – publica dato humedad cada 1 segundo
educantabria/nodo00/m5stick/presion – publica dato presión cada 1 segundo
educantabria/nodo00/m5stickplus/distancia – publica dato distancia cuando se activa
educantabria/nodo00/m5stickplus/button – al pulsar botón publica “press”
educantabria/nodo00/m5stickplus/led – suscrito (1 led ON, otro valor led OFF)
educantabria/nodo00/m5stickplus/label – suscrito (“red” – circulo rojo, “yellow” – circulo amarillo, “green” – circulo verde, “black” – círculo verde)
educantabria/nodo00/raspberry3/CPU – publica Node-RED el datos de CPU
educantabria/nodo00/raspberry3/Temperatura – publica Node-RED el datos de temperatura procesador
educantabria/nodo00/raspberry3/Memoria – publica Node-RED el datos de memoria libre
educantabria/nodo00/raspberry3/Dashboard/# – publica Node-RED cualquier dato del Dasboard
educantabria/nodo00/raspberry3/Datos/# – suscrito Node-RED para recibir cualquier dato externo
educantabria/nodo00/raspberry3TT/CPU – publica Node-RED el datos de CPU
educantabria/nodo00/raspberry3TT/Temperatura – publica Node-RED el datos de temperatura procesador
educantabria/nodo00/raspberry3TT/Memoria – publica Node-RED el datos de memoria libre
educantabria/nodo00/raspberry3TT/Dashboard/# – publica Node-RED cualquier dato del Dasboard
educantabria/nodo00/raspberry3TT/Datos/# – suscrito Node-RED para recibir cualquier dato externo
educantabria/nodo00/raspberryzero/tomafotomqtt – suscrito Node-RED un valor cualquiera enviado, toma una foto y publica en el topic educantabria/nodo00/raspberryzero/foto en baja resolución.
educantabria/nodo00/raspberryzero/foto – publica Node-RED una foto al mandar cualquier dato en el topic educantabria/nodo00/raspberryzero/tomafotomqtt
Grafana es un software libre basado en licencia de Apache 2.0,que permite la visualización y el formato de datos métricos. Permite crear cuadros de mando y gráficos a partir de múltiples fuentes, incluidas bases de datos de series de tiempo como Graphite, InfluxDB y OpenTSDB. Originalmente comenzó como un componente de Kibana y que luego le fue realizado una bifurcación.
Grafana es multiplataforma sin ninguna dependencia y también se puede implementar con Docker. Está escrito en lenguaje Go y tiene un HTTP API completo.
Además de administrar cuadros de mando clásicos (adiciones, eliminaciones, favoritos), Grafana ofrece compartir un cuadro de mando actual mediante la creación de un enlace o una instantánea estática del mismo.
Todos los paneles de control y las fuentes de datos están vinculados a una organización, y los usuarios de la aplicación están vinculados a organizaciones a través de roles.
Para iniciar el servicio: sudo service grafana-server start
Esto iniciará el proceso grafana-server como el usuario grafana, que se crea durante la instalación del paquete. El puerto HTTP predeterminado es 3000, y el usuario y el grupo predeterminados son admin. Nombre de usuario y contraseña por defecto admin/admin
Grafana: Una herramienta que te permite visualizar series de datos temporales de una forma visualmente muy atractiva. Además de la parte visual, dispone de un potente motor y editor de consultas, que te permite seleccionar y tratar los datos que necesitas mostrar en las gráficas y Dashboards que puedes crear en su interfaz web. Además, los datos que muestra se pueden incluir desde diversas fuentes de datos, entre las que se encuentran Graphite, InfluxDB, Prometheus, ElasticSearch, AWS CloudWatch, StackDriver, MySQL y muchos otros mediante los plugins que tiene disponibles.
InfluxDB: Es una base de datos diseñada para almacenar series de datos temporales, esto quiere decir, que se almacenan una serie de datos en registros asociados a un valor principal o índice, que es la marca de tiempo (fecha y hora). La monitorización es un caso típico de este almacenamiento de datos, donde se guarda la marca de tiempo, el nombre del host y los valores de métricas que se pretenden almacenar (CPU, memoria, IO, red, …). InfluxDB es software libre, y el rendimiento que definen para este tipo de entornos es muy competitivo.
Telegraf: Es un agente que se encarga de recopilar datos/métricas de un determinado sistema y almacenarlos donde le indiquemos. Por ejemplo, Telegraf recopilará datos de sistema tradicionales (uso de memoria, uso de MySQL/Apache, …) y los enviará a la URL con la API de InfluxDB, que se encargará de almacenarlo. Telegraf, al igual que InfluxDB, pertenecen a Influxdata, por lo que la integración entre ambos es perfecta.
Chronograf es la aplicación web de código abierto de InfluxData. Utilice Chronograf con los otros componentes de la pila TICK para visualizar sus datos de monitorización y crear fácilmente reglas de alerta y automatización.
Kapacitor es un motor de procesamiento de datos nativo. Puede procesar stream de datos de InfluxDB. Kapacitor le permite conectar su propia lógica personalizada o funciones definidas por el usuario para procesar alertas con umbrales dinámicos, hacer coincidir las métricas de los patrones, calcular anomalías estadísticas y realizar acciones específicas basadas en estas alertas, como el reequilibrio de carga dinámico.
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:
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:
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.
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.
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:
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”.
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.
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.
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.
El acrónimo LAMP está compuesto por las iniciales de sus cuatro componentes: Linux, Apache, MySQL y PHP. Estos forman la infraestructura en el servidor, que hace posible la creación y el alojamiento de páginas web dinámicas. Los componentes individuales se acumulan unos sobre otros, por lo que esta plataforma también recibe el nombre de LAMP stack (del inglés “apilar”).
Su funcionamiento es muy simple. Linux sirve como sistema operativo base para ejecutar el servidor web Apache. Este último no puede interpretar contenidos dinámicos, pero es aquí donde PHP entra a ejercer sus funciones de programación del lado del servidor. El proceso funciona entonces de la siguiente manera: Apache le envía un código fuente al intérprete PHP, incluyendo la información correspondiente sobre las acciones del visitante de la web, y permite el acceso a la base de datos MySQL. El resultado es devuelto a Apache y este se muestra finalmente en el navegador web del visitante.
El lenguaje de programación PHP es uno de los más extendidos para el desarrollo de páginas web. La ventaja de utilizar PHP para el desarrollo de páginas web es que nos permite crear páginas web dinámicas, es decir, que se generan cuando un usuario visita la página.
MySQL es un sistema de gestión de bases de datos relacional desarrollado bajo licencia dual: Licencia pública general/Licencia comercial por Oracle Corporation y está considerada como la base datos de código abierto más popular del mundo, y una de las más populares en general junto a Oracle y Microsoft SQL Server, sobre todo para entornos de desarrollo web.
Este proyecto monta un pequeño servidor web Apache con lo que podrías por ejemplo alojar tu propia página web entre otras cosas. Además, si despliegas alrededor de tu casa, por ejemplo, varios sensores y actuadores (temperatura, humedad, luces, etc…) comandados por Arduino, podrías utilizar la Raspberry Pi 3como centro de envío y recepción de datos a través de su red. Y por supuesto utilizar la página Web para mostrar y controlar los datos a través de Internet.
Instrucciones para su instalación:
#Update system
sudo apt-get update
sudo apt-get upgrade
#Install Apache2
sudo apt-get install apache2
Comprobar que accedemos entrando a la IP de la Raspberry Pi desde un navegador
La página web por defecto está en /var/www/html
Crear un fichero prueba.html en el directorio /var/www/html que contenga el texto: “HOLA MUNDO”
Para comprobar que funciona entrar desde un navegador a la dirección: http://ip_raspberry/prueba.html y ver que aparece el texto “HOLA MUNDO”
Durante el proceso de instalación se pedirá el password de root de MySQL, poner el mismo que tiene el usuario pi de la Raspberry Pi y poner a Yes todas las opciones de mysql_secure_installation
Estos comando instalan una BBDD MariaDB
Para comprobar que todo funciona ejecutar sudo mysql -u root -p y poner la contraseña, saldrá:
Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 61 Server version: 10.1.23-MariaDB-9+deb9u1 Raspbian 9.0 Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others. Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
#Install MySQL
En caso de quere instalar MySQL en lugar de MariaDB usar estos comandos:
Durante el proceso pide la contraseña del usuario phpmyadmin de MySQL y el servidor a instalar el apache y poner yes en dbconfig-common
En caso que no hayamos configurado el servidor web correctamente o queramos hacer una configuración de phpmyadmin después de la instalación, usar el comando: sudo dpkg-reconfigure -plow phpmyadmin
phpMyAdmin es una herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas web, utilizando Internet. Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos y está disponible en 72 idiomas. Se encuentra disponible bajo la licencia GPL Versión 2.
Para probar que funciona ver en un navegador: http://IP-raspberry/phpmyadmin con el usuario phpmyadmin y la contraseña usada.
El usuario phpmyadmin no tiene privilegios. Para crear un usuario “pi” con privilegios ejecutar:
sudo mysql -u root -p
CREATE USER ‘pi’@’localhost’ IDENTIFIED BY ‘tu_contrasena‘;
CREATE USER ‘pi’@’%’ IDENTIFIED BY ‘tu_contrasena‘;
GRANT ALL PRIVILEGES ON * . * TO ‘pi’@’localhost’; (Para acceso local)
GRANT ALL PRIVILEGES ON *.* TO ‘pi’@’%’; (Para acceso remoto)
GRANT GRANT OPTION ON *.* TO ‘pi’@’localhost’; (Privilegios para dar permisos a otros usuarios)
FLUSH PRIVILEGES;
Para conectarnos desde otro servidor: mysql -h ip_raspberry -u root -p
#Install servidor ftp (VSFTPD)
sudo apt-get install vsftpd
Una vez instalado, configurar con: sudo nano /etc/vsftpd.conf
Comentar estas dos opciones:
#local_enable=YES #ssl_enable=NO
Y añadir al final del fichero:
# CUSTOM ssl_enable=YES local_enable=YES chroot_local_user=YES local_root=/var/www user_sub_token=pi write_enable=YES local_umask=002 allow_writeable_chroot=YES ftpd_banner=Welcome to my Raspberry Pi FTP service.
También necesitamos añadir el usuario pi al grupo www-data, dar la propiedad de la carpeta /var/www al usuario y al grupo www-data, cambiar la carpeta de inicio del usuario pi a la misma, y aflojar algunos permisos en la carpeta /var/www:
sudo usermod -a -G www-data pi
sudo usermod -m -d /var/www pi
sudo chown -R www-data:www-data /var/www
sudo chmod -R 775 /var/www
Y reiniciar el servicio: sudo service vsftpd restart
Para comprobar que funciona usar un cliente ftp con https://filezilla-project.org/ y hacer una conexión con la siguiente configuración:
Host – 192.xxx.x.xxx (IP address)
Port – 21
Protocol – FTP (File Transfer Protocol)
Encryption – Use explicit FTP over TLS if available
Escribir el nombre de la imagen en la ruta donde los guardemos.
Y luego pulsar read. Una vez hecho esto, esperar a que el proceso finalice.
Probar LAMP con Arduino
Para probar el servidor LAMP que acabamos de instalar en nuestra Raspberry Pi vamos a usar Arduino y mandar datos de luminosidad de la sala usando un LDR.
Una fotorresistencia o LDR (por sus siglas en inglés “light-dependent resistor”) es un componente electrónico cuya resistencia varía en función de la luz.
Se trata de un sensor que actúa como una resistencia variable en función de la luz que capta. A mayor intensidad de luz, menor resistencia: el sensor ofrece una resistencia de 1M ohm en la oscuridad, alrededor de 10k ohm en exposición de luz ambiente, hasta menos de 1k ohm expuesto a la luz del sol. Aunque estos valores pueden depender del modelo de LDR.
El LDR actúa como una resistencia variable. Para conocer la cantidad de luz que el sensor capta en cierto ambiente, necesitamos medir la tensión de salida del mismo. Para ello utilizaremos un divisor de tensión, colocando el punto de lectura para Vout entre ambas resistencias. De esta forma:
Dónde Vout es el voltaje leído por el PIN analógico del Arduino y será convertido a un valor digital, Vin es el voltaje de entrada (5v), R2 será el valor de la resistencia fija colocada (10k ohm generalmente) y R1 es el valor resistivo del sensor LDR. A medida que el valor del sensor LDR varía, obtendremos una fracción mayor o menor del voltaje de entrada Vin.
Crear una base de datos llamada “DatosArduino” con una tabla llamada “luminosidad” que tenga 4 campos: “id” auto incremental y sea el campo clave, “fecha” de tipo timestamp y que se actualice al actualizar, un campo “arduino” de tipo entero y un campo “IntensidadLuminosa” que sea de tipo entero.
O con la query:
CREATE TABLE `luminosidad` ( `id` int(11) NOT NULL, `fecha` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(), `arduino` int(11) NOT NULL, `IntensidadLuminosa` int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; ALTER TABLE `luminosidad` ADD PRIMARY KEY (`id`); ALTER TABLE `luminosidad` MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=4;
Para insertar un dato:
INSERT INTO `luminosidad` (`arduino`, `IntensidadLuminosa`) VALUES (’22’, ’22’);
Subir por FTP seguro los ficheros Graba_GET.php y Graba_POST.php a Raspberry Pi al directorio /var/www/html o crearlos con el comando nano:
sudo nano Graba_GET.php y sudo nano Graba_POST.php
Recordad poner en el fichero el usuario y contraseña adecuado.
Para ejecutar Node-RED en el arranque: sudo systemctl enable nodered.service
En caso de problemas ver el log con: node-red-log
Instalar Webmin
Webmin es una herramienta de configuración de sistemas accesible vía web para sistemas Unix, como GNU/Linux y OpenSolaris. Con él se pueden configurar aspectos internos de muchos sistemas operativos, como usuarios, cuotas de espacio, servicios, archivos de configuración, apagado del equipo, etcétera, así como modificar y controlar muchas aplicaciones libres, como el servidor web Apache, PHP, MySQL, DNS, Samba, DHCP, entre otros.
Antes de empezar recordar comprobar la posición de los pines porque en caso de error podemos dañar la Raspberry Pi ya que los GPIO no tienen ninguna protección.
Cuando conectes cables a los GPIO procura no equivocarte y fíjate bien.
Usa cables con recubrimiento del tipo Dupont Macho-hembra por ejemplo, y no acerques cables sin proteger a tus GPIO (Y mucho menos un destornillador) porque puedes hacer un corto con facilidad.
Una vez que conectes un cable hembra protegido, vuelve a mirar y asegúrate de que lo has conectado al pin que querías y no al de al lado.
Especial cuidado con los pines que uses para sacar 3V o 5V de tu Raspi. No dejes el otro extremo al aire: Asegúrate de conectarlo a algún sitio.
NO CONECTES NADA DE 5V si no estás seguro. Tu Raspberry funciona a 3.3V y meterle 5V en un pin puede suponer quemar el procesador central.
Instalar las librerías para el uso de los pines GPIO desde Python, asegurandonos de tener actualizado Raspbian:
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install python-dev
sudo apt-get install pyton-rpi.gpio
Tened en cuenta que en esta ocasión vamos a alimentar el LED con 3.3V (Que es lo que proporciona un pin de la Raspi) y que la intensidad que obtendremos será: 3.3 / 1K Ω = 3 mA, que no es mucho para iluminar un LED pero suficiente.
Esquema de GPIO:
Conectamos GND al pin 6 de la Raspberry y vamos a usar el pin 12 (GPIO 18) como control del encendido mediante una resistencia intermedia. El esquema de conexión es:
Abrir el IDLE de Python 3 para empezar nuestro programa:
Y copiar código:
import RPi.GPIO as gpio
import time
gpio.setmode(gpio.BOARD) gpio.setup(12, gpio.OUT)
for x in range ( 0, 10): gpio.output(12, True) time.sleep(0.5) gpio.output(12, False) time.sleep(0.5)
print «Ejecución finalizada»
Guardar el fichero con el nombre blink.py en /home/pi y ejecutarlo pulsando F5
Un Gateway IoT es un dispositivo físico o un programa de software que sirve como punto de conexión entre la nube y los controladores, sensores y dispositivos inteligentes. Todos los datos que se mueven a la nube, o viceversa, pasan por el gateway, que puede ser un dispositivo de hardware dedicado o un programa de software. Un gateway IoT también puede denominarse pasarela inteligente o nivel de control.
Algunos sensores generan decenas de miles de puntos de datos por segundo. Una pasarela proporciona un lugar para preprocesar esos datos localmente en el borde antes de enviarlos a la nube. Cuando los datos se agregan, se resumen y se analizan tácticamente en el borde, se minimiza el volumen de datos que deben ser enviados a la nube, lo que puede tener un gran impacto en los tiempos de respuesta y en los costes de transmisión de la red.
En contraposición con la infraestructura cloud tradicional, basada en grandes centros de datos que centralizan el poder computacional, otros paradigmas como Fog Computing proponen la distribución de esta capacidad de cómputo hacia los extremos de la red. Este paradigma busca solventar los problemas de comunicación de datos entre los dispositivos generadores y consumidores de los mismos al acercar los centros de procesado y análisis de datos hacia ellos, reduciendo de esta forma la latencia y el uso de la infraestructura de red.
Se habla de Edge Computing en referencia a una infraestructura, que se puede entender como un caso específico de Fog Computing. Un escenario típico puede ser el caso de uso de Internet of Things (IoT) en el que los nodos de computación se necesitan estar físicamente cerca de las fuentes de datos, como un robot industrial o un sensor de presión de un tanque de combustible o un indicador de consumo de la red eléctrica. En general se puede definir un nodo de computación Edge como un hardware con capacidad de cómputo situado físicamente cerca de los dispositivos o equipos que hacen uso de sus recursos, bien sea en la propia maquinaria, en una planta de producción o en un almacén.
Otra ventaja de una pasarela de IoT es que puede proporcionar seguridad adicional para la red de IoT y los datos que transporta. Dado que el gateway gestiona información que se mueve en ambas direcciones, puede proteger los datos que se mueven hacia la nube de fugas y dispositivos de IoT de ser comprometidos por ataques externos maliciosos con características tales como detección de manipulaciones, cifrado, generadores de números aleatorios de hardware y motores de cifrado.
La pasarela IoT desempeña un papel importante en la gestión de los dispositivos. Cada dispositivo (sensor/actuador) tiene un caso de uso diferente y emite mensajes a través de diferentes canales como Wifi, BLE, Zigbee, Ethernet, RF, LPWAN, LTE, etc. y el gateway realiza varias funciones como conectividad de dispositivos, traducción de protocolos, agregación, filtrado, correlación, seguridad, actualizaciones, administración y más. Se sitúa entre los dispositivos y la plataforma de nube.
Además un Gateway puede hacer conexión VPN segura entre localizaciones diferentes, permitiendo unir de forma segura diferentes puntos a través de Internet.
Hace no tantos años la conexión remota era por módem o por GSM con conexiones pto a pto. En la actualidad usamos internet para el telecontrol, pero es un problema el tema de la seguridad. Ya existen dispositivos como el router industrial eWON Flexy https://ewon.biz/es/productos/flexy modular que es servidor OPC UA y cliente openvpn, es muy potente para conectar y dar funcionalidades adicionales a unos autómatas.
eWON monta la VPN y al ser servidor modbus TCP y OPC UA, es posible acceder remotamente y de forma segura a los datos del autómata e integrarlo con datos de otras localizaciones.
Los gateways industriales permite la traducción de protocolos típicamente industriales como Modbus RTU/ASCII/TCP a PROFINET o PROFIBUS a protocolos de Internet como HTTP o MQTT, permitiendo actualizar los dispositivos industriales a los nuevos protocolos de comunicación en Internet.
Los gateways de IIoT o «nube» se distinguen por su énfasis en servir datos de dispositivos hasta una nube u otros componentes de la Internet industrial. Los factores diferenciadores incluyen el uso de un microprocesador y un sistema operativo estándar, como la plataforma Intel IoT, así como el soporte de APIs de Transferencia de Estado Representacional (REST), Transporte de Telemetría de Colas de Mensajes (MQTT), y otros protocolos de integración y transporte de datos de la IoT. También se puede utilizar para este fin la OPC UA (Arquitectura Unificada).
Estos gateways también pueden añadir una capa adicional de seguridad con el uso de VPNs u otras comunicaciones seguras.
Un Edge Gateway se encuentra en la intersección de los sistemas de borde (edge), entre la Internet externa y la intranet local que está siendo utilizada por los otros dispositivos de su ecosistema. Por lo tanto, es el punto de acceso clave para la conectividad de red, tanto dentro como fuera del ecosistema de dispositivos.
Existen tres principios fundamentales de la seguridad: confidencialidad, integridad y disponibilidad. Deberá asegurarse de que todas las comunicaciones entre el gateway y los dispositivos cumplen cada uno de los tres principios mientras se produce la comunicación en las redes internas y externas.
También vale la pena señalar que la puerta de enlace es a menudo la primera en ser atacada por dos razones:
Tiene una mayor potencia de procesamiento, que puede utilizar para ejecutar aplicaciones más intensivas. Más potencia significa mejor software, pero mejor software significa más vulnerabilidades para que un hacker las explote.
Debido a su ubicación como dispositivo Edge entre Internet e Intranet, el gateway es el punto de entrada de cualquier vector de amenaza (así como la primera línea de defensa del sistema).
Las recomendaciones sobre la seguridad de un dispositivo de pasarela de la IoT constan de tres pasos.
Identidad para el dispositivo Gateway. Dar al gateway una identidad (utilizando un certificado digital X.509).
Habilitar la identidad «sólida» para el dispositivo Gateway
Utilizar el Gateway para proporcionar identidad a su ecosistema
Aprendiendo Arduino 
