How to deploy a Node-Red environment on a GCP instance

Son numerosos los tutoriales en Internet que explican cómo montar un servidor Node-RED sobre GCP haciendo uso de clústers. Sin embargo cuesta encontrar (si es que los hay), tutoriales sobre como desplegar dicho servidor en una instancia, por lo que en este tutorial, nos centraremos en este caso. ¿Te suena a chino todo lo que hemos dicho? ¿Por qué montarlo sobre una instancia y no un clúster? Expliquemos brevemente los conceptos más raros de la frases anteriores para entendernos mejor.

  • Node-RED: es una herramienta de programación, de libre distribución, la cual nos permite de una forma rápida, y sobretodo muy intuitiva, desplegar una web con un estilo moderno y funcional. Node-RED hace uso de la programación “en cajas”, en la cual interconectamos distintos bloques ya pre hechos de las librerías disponibles. Node-RED usa Javascript y permite introducir bloques con nuestro propio código, pero para las tareas más sencillas no será siquiera necesario saber Javascript. Un ejemplo de un desarrollo simple en Node-RED sería el siguiente:

node_red_example

Node-RED permite además añadir librerías creadas por usuarios, siendo la librería “dashboard” una de las más populares, pues incorpora cajas con elementos visuales que permiten la interacción con el usuario así como la visualización de datos. Un ejemplo de ello:

maxresdefault

¿Fácil, verdad? Quien diría viendo esa web que se ha hecho sin necesidad de saber ningún lenguaje, solo juntando las cajas correctas. Existen otras opciones, como thingsboard.io, pero para gustos los colores, además de no ser la mayoría gratuitas (o tener planes gratuitos muy limitados). Nosotros preferimos Node-RED porque integra soporte para comunicaciones por UDP, TCP y el reciente MQTT, lo que permite comunicaciones con cualquier tipo de dispositivo, especialmente con dispositivos IoT. Además, la comunidad de desarrolladores es enorme y podemos encontrar muchos ejemplos ya hechos para su libre distribución, siendo estos ejemplos a veces, justo lo que buscamos.

Tenemos muchas formas de ejecutar Node-RED, en nuestro PC (esto es corriendo en un servidor local), en páginas que ponen a nuestra disposición servidores ya montados y listos para empezar a trabajar (FRED) o en servidores virtuales privados (VPS) de los cuales hay cientos de ofertas en Internet (aunque destacan por su catálogo y precios Microsoft Azure, Amazon Web Services [AWS] y Google Cloud Platform [GCP]). Las ventajas de ejecutar nuestro entorno en un VPS frente a nuestro ordenador o un entorno ya hecho (y cerrado) son inmensas: disponibilidad total, herramientas de protección, escalabilidad, no compromiso de nuestros datos privados, gestión de recursos… y esas son solo alguna de ellas.

  • Google Cloud Platform: es uno de los tantos servicios de gestión de VPS que hay hoy en día. Si bien es cierto que uno de los que más fuerza tiene es AWS, Google ofrece algo que no ofrece el resto: un servidor gratuito al año con 24/7 en ejecución. Vale que es un servidor muy modestito (10 GB de almacenamiento; 0.6 GB de RAM y un único procesador), pero es gratis y para diseños simples puede ser más que suficiente. Es por esto que nos centraremos en este gestor VPS en este tutorial.
  • Instancia vs. cluster: Google denomina a cada uno de los VPS que creamos instancia. Un grupo de instancias trabajando de forma conjunta, compartiendo recursos y distribuyéndose el tráfico de red entre ellas forma un clúster. Claro, a priori parece que el clúster es mejor (y lo es), pero no es gratis. La instancia, sin embargo, sí. Siempre y cuando esa instancia sea de las más simples de Google, como ya hemos comentado antes.

Ahora que ya hemos explicado todo un poco, relee si quieres el primer párrafo del post. Ahora ya parece obvio por qué queremos desplegar Node-RED (y no otro) sobre una instancia (y no un clúster), porque…

free

 

Empecemos…

Lo primero, lógicamente, es tener una cuenta de Google activa. Nos dirigiremos a la consola de Google Cloud y activaremos nuestra cuenta, registrándonos en la versión de prueba gratuita.  Solo por registrarnos Google nos regala 300 $ en servicios GCP. Para nuestros propósitos no nos harán falta, pero nos vendrán genial si queremos cacharrear con todas las opciones que GCP ofrece. Completaremos todos nuestros datos (incluida la tarjeta de crédito, pero no pasa nada: Google nos avisará previamente en caso de que hiciéramos algo que incurriera en un desembolso). Tras registrarnos se nos creará nuestro primer proyecto (que podremos renombrar si queremos pinchando en configuración de proyecto).

En el buscador escribimos Compute Engine y en la nueva ventana, una vez cargue, creamos una nueva instancia, con la configuración que vemos en la siguiente imagen:

g1
La zona da igual siempre que sea en América (salvo Virginia del Norte). América es la única región con VPS gratuitas. El tipo de máquina ha de ser micro y permitir el tráfico HTTP y HTTPS. Nosotros hemos elegido Ubuntu por familiaridad con los comandos, pero cualquier otra distribución de las gratuitas que ofrece Google es válida. Notad que para saber que estáis siguiendo los pasos correctos, debe apareceros el texto de la derecha donde os informa de que la máquina seleccionada es gratuita. Pulsamos en crear y esperamos.

Una vez creada, hay diferentes cosas que sería interesante hacer antes de empezar a cacharrear (asignarnos una IP estática y abrir algunos puertos).

-Asignando IP estática podremos entrar en nuestro servidor sin necesidad de consultar qué IP nos ha concedido Google esta vez: siempre será la misma. Para ello escribimos Red de VPC en el buscador y entraremos en la sección del menú lateral izquierdo “Direcciones IP externas”. Seleccionaremos nuestra instancia y cambiaremos su tipo a estática. Le ponemos un nombre identificativo a esta IP y aceptamos.

-Abriendo puertos (bien sea TCP o UDP) permitiremos un acceso remoto a nuestro servidor. Hay que notar que esto es un arma de doble filo, pues si bien no podemos hacer mucho sin tener acceso a nuestro servidor remoto también es una puerta abierta a hackers, por lo que recomendamos abrir solamente los puertos que vayamos a necesitar. En nuestro caso será obligatorio abrir el puerto TCP 1880, pues será el que usará Node-RED tanto para la interfaz de diseño (donde colocaremos las cajitas) como para la interfaz web (donde nos mostrará el resultado de colocar y conexionar esas cajitas). Para ellos tecleamos en el buscador “Reglas de cortafuegos” y elegimos la opción que lleve también escrito Red de VPC.

Creamos una regla nueva:allowtcp

 

El nombre es opcional, todo lo demás, recomiendo dejarlo a esos valores. Cuando cojáis más soltura con GCP os recomiendo etiquetar vuestras distintas instancias para poder elegir destinos de reglas del cortafuegos y así que cada máquina tenga abiertos los puertos que necesita. Por ahora, y como solo tenemos una máquina creada, no pasa nada por aplicar en el campo destinos “todas las instancias de la red”. Guardamos y ya estaremos listos para empezar la instalación de Node-RED sobre nuestro VPS.

Volvemos a la vista de Compute Engine, donde estará nuestra instancia. En el campo “Conectar” pulsamos sobre SSH. Se nos abrirá una ventana nueva y cuando cargue ya estaremos dentro de nuestro VPS.

Para poder empezar a trabajar, tecleamos los siguientes comandos:

Nótese que entre los comandos, se instalará nodejs. En nuestro caso hemos instalado la versión 8.x por ser la recomendada en el momento de realizar este tutorial, pero se aconseja mirar en la página de nodejs cual es la última versión recomendada. Escribimos ahora el comando que instalará Node-RED en nuestro VPS.

Es también interesante instalar algunas herramientas de node-red que nos harán más fácil la gestión de nuestro servidor, por lo que teclearemos:

Después de esto ya podemos probar que Node-RED está correctamente instalado. Para ellos tecleamos:

Lo que debería arrojar en el terminal una salida que acaba con:

Esto es indicativo de que todo está correcto. ¡Probémoslo! Escribamos en nuestra barra del navegador la IP estática concedida por Google (sin http ni https delante seguida del puerto de acceso a Node-RED, separado por dos puntos “:”), algo así como 123.123.123.123:1880. Deberíamos ver esto:

node-red1

 

¡Todo funciona! Sin embargo esto presenta un enorme, enorme inconveniente: cualquiera que sepa nuestra IP puede acceder a nuestro servidor Node-RED y borrarnos todo el trabajo o inyectar código malicioso. Por ello, el siguiente paso, de vital importancia, es proteger nuestro servidor. Volviendo a la terminal abierta por SSH, pulsamos ctrl+C para parar la ejecución de Node-RED y escribiremos:

Lo que nos preguntará por la contraseña con la que deseamos proteger el servidor. Tras escribirla y pulsar intro, nos devolverá una secuencia hash con nuestra contraseña encriptada, que deberemos copiar, pues usaremos ahora. Escribiremos sobre el archivo de configuración de Node-RED. En el terminal tecleamos:

y dentro de este archivo buscaremos el siguiente texto:

adminAuth: {
type: “credentials”,
users: [{
username: “USUARIO“,
password: “HASH_GENERADO“,
permissions: “*”
}]
},

// To password protect the node-defined HTTP endpoints (httpNodeRoot), or
// the static content (httpStatic), the following properties can be used.
// The pass field is a bcrypt hash of the password.
// See http://nodered.org/docs/security.html#generating-the-password-hash
httpNodeAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},
httpStaticAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},

En usuario escribiremos el usuario que queramos, y en los campos password y pass, el hash generado anteriormente. La primera parte protegerá la parte de gestión (donde colocamos las cajitas), la segunda, la parte de visualización (la web que crean las cajitas). Es importante descomentar las lineas necesarias (esto es, eliminar los caracteres “//” con los que empiezan algunas lineas), para que el resultado quede tal y como hemos puesto arriba. Guardamos con CTRL+O y salimos con CTRL+X.

Por último, será interesante que nuestro servidor cargue automáticamente Node-RED cuando se reinicie, lo que hará más tolerante a fallos nuestra implementación. Para ello, escribimos:

Que nos indicará nuestro nombre de usuario. A continuación:

donde copiaremos el siguiente texto:

[Unit]
Description=Node-RED
After=syslog.target network.target

[Service]
ExecStart=/usr/bin/node-red
Restart=on-failure
KillSignal=SIGINT

# log output to syslog as ‘node-red’
SyslogIdentifier=node-red
StandardOutput=syslog

# non-root user to run as
WorkingDirectory=/home/TUUSUARIO/
User=TUUSUARIO
Group=TUUSUARIO

[Install]
WantedBy=multi-user.target

Hay que modificar solo los campos en rojo. Nuevamente, guardamos con CTRL+O y salimos con CTRL+X. Activamos el servicio creado escribiendo:

Comprobaremos que todo se haya hecho correctamente. Para ello primero es necesario reiniciar, por lo que escribimos:

Y tras esperar unos dos minutos, cargamos de nuevo la página con la IP del servidor en nuestro navegador. Ahora, al cargar node-RED debería pedirnos login, tanto a la parte de gestión como a la de visualización.

¡Eso es todo por nuestra parte! Ahora, a jugar.

El eSpMART105 toma forma

Dentro de la colaboración del B105 ESL con la empresa Valoriza nace el proyecto Lázaro, con el objetivo de crear un sistema para la detección automática de barreras usando visión por ordenador y realidad aumentada.

Además de este primer objetivo, el proyecto persigue otra importante meta, el desarrollo de una red de sensores inalámbrica para monitorizar las condiciones de vida de personas con necesidades especiales, como ancianos o personas con minusvalía.

Es dentro de este segundo objetivo donde nace nuestro wearable: eSpMART105.

El dispositivo que hemos desarrollado es una pulsera, capaz de medir la temperatura (ya sea ambiente o corporal del paciente), medir su ritmo cardíaco, su saturación de oxígeno y monitorizar su actividad diaria, detectando posibles caídas y avisando al personal que se encuentre a cargo de dicho paciente.

Imagen 2
Pulsera eSpMART105

Gracias a una aplicación móvil para Android, también desarrollada por nosotros, el personal sanitario puede en todo momento consultar el estado del paciente, ver un registro de sus últimas medidas, así como cambiar la periodicidad de las mismas, consultar su historial clínico, recibir alertas sobre posibles valores anómalos en el paciente o caídas y administrar, sencillamente desde el móvil, a todos los pacientes de la residencia.

Main_Activity2
Una de las vistas de la aplicación

La comunicación entre la pulsera y el móvil se realiza mediante Bluetooth Low Energy, el más actual de los estándares Bluetooth disponibles.

Además, en caso de que se detecte un evento de gran peligrosidad como una caída o un pulso anormalmente alto, la pulsera es capaz de realizar una búsqueda exhaustiva de puntos de acceso Wi-Fi almacenados en su base de datos y establecer conexión con ellos, enviando el aviso. Esto hace a nuestra solución capaz de comunicarse con dos de las tecnologías inalámbricas más ampliamente usadas en el mercado actual. Todo ello con un consumo muy bajo, que permite a la pulsera (dependiendo de los intervalos de medición de parámetros del paciente) una vida de hasta dos semanas. Para el desarrollo de esta pulsera nos hemos basado en el ESP32, un dispositivo genial para desarrollo debido a su integración en un reducido tamaño de Wi-Fi y Bluetooth, así como numerosos GPIO’s, I2C, SPI, UART, control para pantallas táctiles y mucho más.

Imagen 3
ESP32

La caja de la pulsera, así como su correa es también diseño nuestro. Ha sido impreso en material 3D, recurriendo a filamento rígido transparente para la caja, pues la rigidez de este material aporta robustez mecánica al diseño, y material blanco flexible para la correa, compuesto que la hace más cómoda de llevar.

Paralelo a este desarrollo hemos recurrido a relojes de la marca Pebble, que permiten programar aplicaciones en C e incorporan también comunicación Bluetooth y sensor de ritmo cardíaco. Gracias a este reloj podemos obtener datos nuevos del paciente como su nivel de actividad, sus pasos diarios y una segunda medición de ritmo cardíaco, que aporta robustez a la medida de nuestro sistema. Los datos que recoge esta otra pulsera son también enviados a la misma aplicación de Android, quedando por tanto, toda la información del paciente centralizada.

Avances en el proyecto LÁZARO

¡El Proyecto LÁZARO para la detección de barreras arquitectónicas y sensorización sigue avanzando a buen ritmo!

Finalmente una de las ideas de diseño que abordaremos, en el lado del paciente, será el uso de un dispositivo wearable (un reloj), dotado de comunicación por puerto serie, que se conectará a una placa de desarrollo con funcionalidades Wi-Fi, Bluetooth y sensado de temperatura del paciente.

Ya hemos recibido los primeros prototipos para las placas que implementarán todo el diseño y que podéis ver en la foto que acompaña a esta entrada. En breve comenzaremos a montar en ella los componentes y a comenzar las primeras pruebas, una vez que el software sea funcional. ¡Estamos muy ilusionados con este proyecto!

Para el reloj hemos recurrido a la compañía Pebble, aunque una línea futura en la que nos gustaría trabajar es en el desarrollo de nuestro propio wearable, que nos permitirá un grado de personalización y optimización mucho mayor.

Para las comunicaciones móviles nos apoyaremos en el módulo ESP32.

¡Os seguiremos informando según avance el proyecto!

TFG: DESARROLLO DE UNA INTERFAZ INALÁMBRICA IEEE 802.11 PARA LA IMPLEMENTACIÓN DE FUNCIONALIDADES DE UN NODO PASARELA PARA UNA RED INALÁMBRICA DE SENSORES COGNITIVA

Las redes cognitivas de sensores, CWSN por sus siglas en inglés (Cognitive Wireless Sensor Network) son capaces de modificar sus parámetros de transmisión y recepción, adaptándose a las variaciones del entorno, permitiendo optimizar la comunicación. Estas redes son capaces, por ejemplo, de modificar la modulación, la velocidad de transmisión o la frecuencia de emisión, recurriendo a las bandas menos saturadas y por tanto, optimizando la comunicación. Estas redes además, suelen contar con numerosos sensores, algunos de ellos usados para obtener información del entorno y otros empleados en la propia optimización de la comunicación.

Como indica el título del proyecto, durante el mismo se ha trabajo en la mejora del banco de pruebas para redes inalámbricas de sensores cognitivas del B105, conocido como TestBed cNGD, donde cNGD  son las siglas de cognitive New Generation Device, nombre que reciben los nodos que conforman esta red cognitiva.

cNGD

Fotografía de un nodo cNGD

El proyecto se ha centrado en el diseño de un nodo pasarela, que permite una comunicación sencilla entre un ordenador y la CWSN, pudiendo obtener información de ésta. El diseño de este nodo se ha basado en el estándar IEEE 802.11 ya que está muy extendido y existen numerosos dispositivos que lo implementan.

Para diseñar este nodo pasarela, se ha recurrido a las cabeceras de expansión del cNGD, que permiten la colocación de distintos módulos que aumentan sus funcionalidades. Se ha creado, por tanto, un nuevo módulo Wi-Fi compatible con dichos pines. Durante este proyecto se ha realizado tanto el diseño del mismo como la implementación en circuito impreso.

Para que este módulo de expansión sea capaz de funcionar en los nodos, ha sido necesario crear software nuevo propio para el módulo, así como modificar el software del cNGD, añadiendo nuevas funciones, modificando las ya existentes y eliminado las que se han quedado obsoletas.

A día de hoy, aún faltan por realizar algunas pruebas, ¡¡pero la implementación parece ser todo un éxito!!

El módulo de expansión Wi-Fi es el que aparece al principio de esta publicación.

Para dotar a este nodo, y en general, a cualquier nodo de mayor movilidad, se ha realizado también el diseño e implementación de un sistema de carga de baterías de litio. Este módulo de expansión permite actualizar la antigua alimentación a pilas, a una basada en baterías de litio recargables, más cómoda y eficiente. Este sistema de carga, igual que ocurre con el módulo Wi-Fi, hace uso de los pines de expansión con los que cuenta el nodo. El módulo, es capaz de cargar la batería desde diferentes fuentes de alimentación y permite simultáneamente alimentación y carga. Este módulo se puede usar en cualquier nodo de la red sin que sean necesarias modificaciones.

Las pruebas para este módulo sí que se han realizado ya y se ha comportado según lo esperado, por lo que se puede dar por finalizado el mismo y realizar el montaje para que todos los nodos de la red dispongan de un cargador.


ChargerPCB

Módulo de expansión cargador de baterías