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.

Conexión con la red NB-IoT de Vodafone

Ya estamos trabajando con los módulos NB-IoT del proyecto Sensoriza y hemos conseguido conectarnos con la red de Vodafone desde el laboratorio.

Hemos hecho pruebas con dos plataformas hardware. En primer lugar usamos una shield NB-IoT para Arduino de la empresa SODAQ que incorpora el módulo SARA-N211 de u-blox. Nosotros la utilizamos de forma autónoma, alimentándola directamente sin utilizar ningún Arduino. Por otro lado tenemos el módulo BC95 de Quectel montado en su propia Evaluation Board. Ambos se conectan mediante un puerto serie USB a un ordenador, ya que los módulos se controlan mediante comandos AT. El escenario de pruebas es el siguiente, con el módulo de u-blox más pequeño a la izquierda y el de Quectel a la derecha.

pruebasNBIoT

Tras estudiar y entender la sucesión de comandos necesaria, y con la información que nos ha facilitado Vodafone, hemos conseguido conectar ambos dispositivos a la red de forma correcta.

conexionserie

Empezando a trabajar con NB-IoT

Dentro del proyecto Sensoriza desde el grupo B105 hemos empezado a trabajar por primera vez con la tecnología Narrowband-IoT (NB-IoT).

NB-IoT es un estándar promovido por 3GPP que reutiliza una pequeña parte del espectro LTE. Por tanto, con un pequeño cambio en las estaciones base, proporciona el mismo alcance geográfico que la tecnología móvil 4G actual. La conectividad que proporciona es de muy bajo ancho de banda y baja tasa de datos, a la vez que ofrece una cobertura muy profunda llegando a lugares subterráneos o zonas rurales remotas. Por lo tanto está especialmente diseñada para dispositivos autónomos del mundo del internet de las cosas, como contadores inteligentes, alarmas, agricultura conectada, etc.

nbiotbands

Nuestro objetivo es dotar a las máquinas de conservación y mantenimiento de carreteras de un módulo NB-IoT mediante el que puedan transmitir la información recogida por sus sensores ambientales a un centro de control. Utilizando esta tecnología tendremos conectividad desde las carreteras de montaña remotas donde se realizan la mayor parte de actuaciones de vialidad invernal, lo que hasta ahora no era posible.

bc95

Como pasos iniciales estamos trabajando con dos módulos de dos fabricantes diferentes. En primer lugar tenemos un módulo BC95 de Quectel, que nos ha facilitado su distribuidor en España Monolitic. Por otro lado estamos utilizando una plataforma basada en Arduino que incorpora un módulo SARA-N211 de u-blox. Vodafone, que es la principal compañía telefónica que está implantando la tecnología NB-IoT en España, nos ha proporcionado dos tarjetas SIM para hacer pruebas de conexión con su red.

sara-n2

TFM: Implementation and integration of a chart engine oriented to Big Data and it’s application in domotics

IoT (Internet of Things) and Big Data are very relevant today, and they tend to appear together. This happens because the most accepted definition of of IoT is having a lot of wireless sensors generating data continuously. This requires having the infrastructure to be able to save all the data that is generated in databases. However, this presents a problem when doing queries, since queries in big databases (millions of samples) take a long time to finish. Reducing this time is the objective of the following project.

This project consists of a Web application (making it cross-platform) that allows management of a database using a simple user interface. It is also able to select a small sample of data (independently of the amount of data in the database) and plotting it. Finally, it can also be used to monitor live data. These last two functions are extremely useful in domotics, since the data that’s used in those applications (temperature, pressure) are very easy to interpret when plotted.

Captura representación gráfica
Screenshot of the webpage used to chart data

In order to carry out this project we used MongoDB, a NoSQL database. This type of databases have big advantages over traditional SQL databases when taking into account the type of data we are going to store, mainly faster speed and more flexibility. For the web server we used NodeJS, this way all the code written for this project is Javascript, both server-side, using ExpressJS to simplify the development, and client-side, using the native API calls for web manipulation present in most modern web browsers.

Lastly, one of the biggest advantages of our project is the ability to add data to the database sending a HTTP request to a certain URL. With this we can save any type of data from any sensor easily, the only requirement is having a node that supports IP in order to send the HTTP request, which is something very common nowadays.

El Futbolín del Laboratorio B105: Historia

 

Muchos de los nuevos estudiantes de Teleco de la ETSIT-UPM habrán escuchado alguna vez algo sobre el laboratorio donde hay un Futbolín en el edificio B. Pues sí, somos nosotros y sí, tenemos un futbolín.

El Futbolín del B105 tiene ya historia y un propósito especial: la aplicación práctica de electrónica y la motivación continua de estudiantes.

La fecha del instalación del futbolín en el labo no está muy clara, pero sí que hay pruebas gráficas de su existencia en julio de 2005, ya que en ese mes se entregó el segundo diploma. Además la primera temporada, según el “Wall of Fame” del labo, parece ser que se jugó en 2004/2005.

Al principio el futbolín no tenía marcador, y no solo eso, sino que estaba colocado al revés, donde está el Atleti ahora estaba el Madrid, ya que se comprobó que había una cierta ventaja (no está muy clara cuál), y si se jugaba en un determinado lado del campo de juego se ganaba más veces que jugando en el contrario.

screenshot-from-2016-11-04-12-24-13
Diagrama de bloques de la primera versión de marcador

Ya que estábamos en un laboratorio de investigación, se pensó que había que aprovechar los conocimientos que se tenían para meter mejoras al futbolín. A alguien (posiblemente a Curro) se le ocurrió instalar el primer marcador analógico/digital del futbolín. Se marcaba tocando los botones con un dedo tal y como se ve en la imagen de cabecera. Luego se aprovecharon sensores de impresoras para controlar el paso de papel y se transformaron en sensores de gol. De esta forma el marcador era capaz de sumar goles automáticamente cuando la pelota se introducía en una portería.

Esta primera versión de marcador estaba construida con displays de 7 segmentos, chips integrados 74HC191 y 74HC4511 y botones físicos. Tenía una peculiaridad y era que permitía que se pudiera alterar el resultado si de daba con la bola en alguno de los botones: reset, sumar un gol o quitar un gol, ya que el marcador estaba atornillado en uno de los laterales del futbolín.

9026804330_7a42ce6050_k
Pantalla táctil del segundo marcador

Unos pocos años después (allá por el año 2007), aprovechando una pantalla táctil y el software relacionado de un proyecto de investigación que acababa de finalizar, se decidió evolucionar el futbolín y se desarrolló un sistema que gestionase la pantalla táctil y una base de datos que permitiese llevar las estadísticas del futbolín. Los primeros partidos registrados en la base de datos datan de Junio de 2007. Curro hizo un invento aprovechando una pantalla normal y un sensor táctil, y posteriormente se paso a una pantalla táctil integrada. También se evolucionó en los sensores de gol, que pasaron de ser sensores de carrera de impresoras a sensores de infrarrojos por corte.

9024579833_8963f4ecb5_k
Final de la vigesimocuarta temporada triunfal del Futbolín

Desde entonces hasta ahora mucho ha evolucionado el futbolín. Para conocer el estado actual del mismo, continúa leyendo en artículo que lleva por título “El Futbolín Inteligente del Laboratorio B105” o alguno de los artículos relacionados: