msgbartop
¡Pocoyízate, Borja, pocoyízate!
msgbarbottom

31 ene 21 Concentrador Zigbee basado en software libre: zigbee2mqtt

Llevo ya unos cuantos artículos hablando sobre mi sistema de domótica, y hasta ahora he omitido uno de los puntos centrales del mismo: el concentrador zigbee. Mi sistema de domótica es algo sui generis, ya que es un compendio de distintas piezas que he ido amalgamando con el paso del tiempo. El punto central del mismo es el estupendo software Home Assistant, junto con un servidor MQTT. Sobre este núcleo he ido añadiendo diversos dispositivos, empezando por hardware basado en NodeMCU programados por mí mismo. Empecé con ello en 2016, en Irlanda, pero realicé algunos proyectos preliminares aún antes, pero completamente desacoplados. Pero todo lo hecho ha tenido como hilo común el experimentar con diversas tecnologías.

Como parte de ese proceso de experimentación acabé introduciendo dispositivos Zigbee. Son unos elementos interesantes, y la tecnología en la que se basan ha tenido gran difusión en el ámbito de la domótica doméstica. Para transmitir la señal se basan el frecuencia de 2’4GHz, lo que provoca que en entornos saturados de redes WiFi y Bluetooth estemos añadiendo más elementos que pueden provocar perturbaciones. Sin embargo, no es ese su gran problema. El gran problema que tienen es que estos dispositivos necesitan de un aparato que realice las veces de concentrador de señales, actuando como pasarela entre los dispositivos en sí y el software de control que nos permite interactuar con ellos. Y si este concentrador fuera genérico, no sería demasiado malo, pero cada fabricante requiere que uses el suyo y nada más que el suyo, lo que implica que no es posible mezclar, por ejemplo, luces del sistema TRÅDFRI de Ikea con sensores de temperatura Xiaomi, o interruptores Silvercrest de Lidl, a menos que quieras tener que usar tres concentradores y tres aplicaciones distintas para cada componente. Un verdadero rollo.

Y es aquí donde entra nuestro amigo el software libre. Existe un magnífico proyecto de desarrollo de un concentrador multifabricante que permite precisamente eso: utilizar un solo concentrador abierto para gestionar dispositivos de diversos fabricantes. Ese es el proyecto zigbee2mqtt. La idea de partida es sencilla: escuchar las señales Zigbee de los diversos dispositivos, procesarlas, e inyectarlas en un servidor MQTT para poder ser utilizadas posteriormente como mejor convenga a tus intereses. Sencilla, pero brillante. Y en mi caso, dado que ya disponía de un Home Assistant configurado y mi servidor MQTT, algo que me venía como anillo al dedo.

Arquitectura de zigbee2mqtt

Arquitectura de zigbee2mqtt

Sin embargo, hasta ahora he hablado sólo de sofware, y para construir un concentrador que reciba señales físicas es preciso de algo de hierro. El hardware esencial es el adaptador Zigbee que recibe las señales de los dispositivos. En mi caso hago uso de un adaptador CC2531, que se conecta por USB. Es preciso programarlo con un firmware que en la propia página de zigbee2mqtt se encargan de proporcionar. Y además de eso, hace falta un dispositivo linux donde instalarlo. La respuesta más obvia es una Raspberry Pi, pero hay otras alternativas:

  • En mi caso, allá por 2016, empecé utilizando una Asus Tinker Board, que por aquel entonces ofrecía mucha más potencia que la Raspberry Pi 2 que había disponible. Una placa estupenda, con mucha potencia, y con una versión de linux, Linaro OS, basada en Debian, por lo que ofrecía todo lo que necesitaba. Sin embargo, tenía una cierta pasión por devorar tarjetas microSD, por lo que hace algunos meses acabé migrando el sistema y desconectándola.
  • Otra opción interesante, dado que las necesidades de potencia de zigbee2mqtt son ciertamente reducidas (y ni de lejos requieren hacer uso de algo como una Raspberry Pi 4), es hacer uso de una placa más modesta. En mi caso, estoy teniendo estupendos resultados con una humilde Orange Pi Zero. Eso sí, siempre que cuides de ponerle un sistema de disipación y ventilación, ya el talón de Aquiles de esta placa es su disparatado problema de sobrecalentamiento del micro. Este sistema lo tengo en uso a día de hoy en Forcarey.
  • Y otra opción, perfectamente viable, es hacer uso de una máquina virtual. Este es el caso del entorno que tengo actualmente en Santiponce. Después de desechar la Tinker Board, moví el sistema a una pequeña máquina virtual en un servidor de virtualización basado en Proxmox que tengo en casa. El punto clave en este caso era verificar que el adaptador Zigbee funcionara presentándolo desde el servidor de virtualización a la máquina virtual (ya que, claro, no es posible conectar un hardware físico a una máquina virtual sin conectar el hardware al servidor de virtualización), cosa que hasta el momento ha ido como la seda. Y en cuanto a los recursos de la máquina virtual, no se necesita nada espectacular: con 512 MB de RAM y 1 vCPU hay de sobra para mover Home Assistant, zigbee2mqtt, el servidor MQTT y alguna que otra cosa más que tengo por ahí.
Home Assistant y zigbee2mqtt en Proxmox

Home Assistant y zigbee2mqtt en Proxmox

Una vez determinada qué opción para componer el concentrador, el resto es sencillo: ya hemos hablado del primer paso, que es cargar el firmware en el CC2531. El segundo es desplegar el software zigbee2mqtt en el concentrador. El proceso es bastante sencillo, ya que se trada de una aplicación Node.jsm y se instala tan sólo haciendo uso de un comando npm, una vez preparado el entorno para que pueda ejecutar este tipo de aplicaciones.

Procesos de zigbee2mqtt en Orange Pi Zero

Procesos de zigbee2mqtt en Orange Pi Zero

Por último, para tener el concentrador listo, hay que integrarlo con un servidor MQTT, que se hace mediante un fichero de configuración. Y a partir de ahí, tan sólo es cuestión de sacarle partido. Y es aquí donde entra de nuevo Home Assistant: zigbee2mqtt tiene una integración excelente con este sistema de domótica, siendo posible integrarlo con Home Assistant, y hacer que el proceso de descubrimiento en éste de los dispositivos registrados en zigbee2mqtt sea automático.

Pero he dejado lo mejor de todo para el final. Comentaba que el problema de utilizar concentradores de fabricante es que cada uno soporta solo y exclusivamente sus propios dispositivos. ¿Cuántos dispositivos soporta zigbee2mqtt? Literalmente cientos. A día de hoy, 1217 dispositivos de 189 fabricantes distintos. Y es una lista que no para de crecer. Hace algunas semanas han sido añadidos los Silvercrest de Lidl de los que escribí recientemente, solucionando el problema de que el botón físico de los interruptores no era reconocido dentro de las acciones: ahora sí lo reconoce.

¿Qué cuál es mi configuración? Bueno, a día de hoy es pelín compleja, pero tiene su gracia. Estrictamente hablando, hago uso de dos concentradores zigbee2mqtt, uno en Santiponce, y otro en Forcarey, que reportan a mi servidor MQTT, ubicado en Santiponce. Y manejo los dispositivos desde un único Home Assistant, también ubicado en Sevilla. Cada zigbee2mqtt escribe en el servidor MQTT bajo un topic diferenciado, ya que la cantidad de dispositivos es pelín larga ya. En Santiponce hago uso de:

  • Una luz Ikea TRÅDFRI, que fue la que lo empezó todo, ubicada en el salón. Es la luz que permite variar la calidez de la luz y la intensidad de la misma.
  • Su correspondiente mando, que no está integrado directamente con la luz, sino que se comunica con ella de manera independiente a través de zigbee2mqtt. Esto permite reconocer las acciones del mando en Home Assistant, y llegado el caso permitiría que el mando administrara dispositivos de terceros.
  • Una luz Müller Licht Tint de Aldi, de varios colores.
  • …y su mando a distancia. En este caso la integración no es tan limpia como en el del mando de Ikea, pero funciona bien.
  • Un cubo Aqara, que utilizo no sólo para controlar la luz Ikea del salón, sino para realizar acciones sobre la pérgola del patio. Y esto nos lleva a otra ventaja de utilizar zigbee2mqtt: que se puede interactuar sobre dispositivos que no son Zigbee. En mi caso, sobre un NodeMCU programado por mí mismo, a través de topic MQTT.
  • Tres sensores de apertura de puertas y ventanas Aqara MCCGQ11LM, que reportar la apertura de las mismas mediantes mensajes de Telegran y WhatsApp.
  • Un router CC2530 para mejorar la comunicación de los dispositivos Zigbee con el controlador. Y es que, aunque los dispositivos Zigbee pueden construir una red de tipo Mesh para llegar al concentrador, las comunicación con éste se veía perjudicada por la cantidad de señales en la banda de 2’4GHz y las distancias existentes en el caso de la casa de Santiponce. El uso de este concentrador mejoró de manera ostensible el comportamiento del sistema.
Diagrama de dispositivos de Santiponce

Diagrama de dispositivos de Santiponce

…y en el caso de Forcarey:

  • Los mismos sensores de apertura de puertas y ventanas Aqara MCCGQ11LM que comentaba antes.
  • Varios interruptores Lidl HG06337 para controlar los radiadores eléctricos del piso.
  • Otro Aqara Cube para controlar las luces del salón, que he domotizado mediante unos Sonoff Mini con software Tasmota.
  • Sensores de temperatura, humedad y presión atmosférica Aqara WSDCGQ11LM, que permitirán automatizar el encendido de los radiadores en función de las condiciones de las habitaciones.
Diagrama de dispositivos de Forcarey

Diagrama de dispositivos de Forcarey

No está mal, ¿no?

VN:F [1.9.20_1166]
Rating: 10.0/10 (2 votes cast)

Etiquetas: , , , , , , , , , , , , , , , ,

03 jul 19 Hacking lab sobre Modbus TCP. Introducción

Esta entrada es la parte 1 de 4 de la serie Hacking Lab Modbus TCP

Por temas relacionados con un máster de ciberseguridad industrial que estoy cursando he tenido que preparar una serie de ejercicios para el mismo, entre los que se encuentra la realización de un hacking lab. La idea de un hacking lab es preparar un entorno controlado en el que poder hacer ataques a un sistema para aprender posibles vulnerabilidades, técnicas para desvelarlas, y herramientas que se pueden utilizar para ello, a fin de ser capaz en un futuro de proteger un entorno real con las lecciones aprendidas en el entorno de pruebas.

Para la realización de este hacking lab opté por preparar un escenario en el que se pudiera realizar un ataque a un entorno de control industrial que hiciera uso de comunicaciones basadas en Modbus sobre TCP. Modbus es un protocolo de comunicación industrial desarrollado en 1979, y que constituye un estándar de facto en los sistemas de producción industrial. El objetivo general es perturbar el funcionamiento de un sistema de iluminación LED cuyo sistema de control está implementado empleando Modbus sobre TCP. El mismo consta de los siguientes elementos:

  • Una red plana que simula una red de control industrial. En este caso es una red del rango 192.168.0.0/24. Si bien en un caso real sería una red cableada, para este escenario de prueba es una red mixta cableada y WiFi, con un enrutador proporcionando conectividad a los distintos elementos de la misma.
  • Un PLC que actúa como Master Modbus, y que permite controlar, mediante el uso de tres bobinas (coils), el encendido y apagado de un sistema de iluminación LED de colores rojo, verde y azul. Este PLC, al no tener disponible ningún dispositivo real disponible, se simula mediante el aplicativo Node-RED de IBM con una librería Modbus desarrollada al efecto. Este PLC (virtual) tiene la IP 192.168.0.39, y escucha en el puerto 1502 (por razones de privilegios en el dispositivo, no se ha hecho uso del puerto estándar 502/TCP de Modbus).
  • Un actuador físico como Slave Modbus, que en base a las lecturas que realiza de los valores de las bobinas del Master Modbus, enciende y apaga los LEDs del sistema de iluminación. Este actuador físico se ha implementado con un dispositivo ESP8266 programado mediante Arduino IDE y librerías específicas. Las comunicaciones con el Master Modbus se realizan mediante protocolo Modbus sobre TCP. El actuador tiene la IP 192.168.0.34.
  • Un HMI de control de las luces, que permite controlar el encendido y apagado de las mismas mediante una aplicación web tipo SCADA. Este HMI se ha desarrollado mediante el aplicativo Node-RED de IBM y las librerías gráficas para desplegar cuadros de mando, así como una librería MODBUS desarrollada al efecto. EL HMI tiene la IP 192.168.0.31.
  • Un dispositivo atacante, que tiene como objeto descubrir sistemas Modbus en la red desplegada, e interferir los valores normales de operación de los mismos. Este dispositivo es una Raspberry Pi con Kali Linux instalado, teniendo la IP 192.168.0.99.

El siguiente diagrama de red muestra el sistema desarrollado:

Diagrama de la red

Diagrama de la red

En siguientes artículos iré dando mayor detalle de los dispositivos del entorno, así como de los pasos dados en el hacking lab, además de las conclusiones obtenidas de la puesta en marcha del mismo.

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , ,

20 feb 17 Mejoras en el sistema de telemetría

Este fin de semana he estado con Ana y unos amigos en Waterford. Ha sido la oportunidad perfecta para probar el sistema de telemetría. Y la verdad es que se ha portado de fábula. Como muestra, un botón:

Telemetría del viaje a Waterford

Telemetría del viaje a Waterford

Como se puede apreciar, la recogida de datos funcionó a la perfección durante las dos hora de viaje desde Dublín a Waterford. Por ello, me he decidido a realizar algunas modificaciones en el sistema de telemetría:

  • Recogida de parámetros adicionales: Hasta ahora recogía 3 valores de la centralita del coche: velocidad, revoluciones por minuto y flujo de aire entrante en el motor, este último, junto con la velocidad, para realizar el cálculo del consumo de combustible. Ahora voy a pasar a recoger 14 parámetros en total, que son los que proporciona la centralita del coche. En otros vehículos más modernos se pueden recoger muchos más parámetros, pero por el momento tengo información más que suficiente de múltiples valores: temperaturas, sensores de depósito, % de potencia utilizada, % de recorrido del acelerador… El detalle de los parámetros recogidos es el siguiente:
    PIDs OBD II Mercedes W203

    PIDs OBD II Mercedes W203

  • Modificación en la frecuencia de recogida de valores: Dado que paso a recoger más parámetros, y anteriormente he tenido problemas de uso del canal de comunicación Bluetooth, voy a reducir la frecuencia de recogida de valores desde los 2 segundos a los 5. Si el sistema se sigue mostrando estable, consideraré volver a recoger valores cada 2 segundos.
  • Cálculo de distancia recorrida: Uno de los valores que la centralita no proporciona es la distancia recorrida. Así que he introducido el cálculo de la misma, basado en los datos proporcionados por el sensor GPS.
  • (En desarrollo) Incorporación de acelerómetros: De nuevo, un valor no proporcionado por la centralita. En este caso, se trata de medir la aceleración del vehículo en los ejes X, Y y Z. La centralita no los proporciona, y la Raspberry Pi tampoco. Así que he encargado un acelerómetro con giróscopos incorporados, que proporcionará información a través del los puertos GPIO de la RPi.
VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , ,

29 ene 17 Sistema de telemetría y geoposicionamiento para vehículos

Escribía en mi entrada anterior que estaba trabajando en un sistema de telemetría para el Mercedes. Durante estas últimas semanas he estado realizando algunas mejoras en el sistema, y si bien aún es posible incorporar algunas más, en este momento ya empieza a tener un desarrollo bastante definido. En pocas palabras, se trata de un sistema de telemetría que recoge datos de dos fuentes, la centralita del coche y un módulo GPS, para transmitirlo a un servidor donde se almacenan los datos para su posterior tratamiento. En este momento, el tratamiento consiste en dos actividades: representación gráfica de velocidad, revoluciones por minuto y consumo del coche, y geoposicionamiento en mapas en tiempo real. Este es un esquema básico de la plataforma:

Esquema del sistema de telemetría

Esquema del sistema de telemetría

El sistema está compuesto por los siguientes elementos:

  • Sonda de captura de datos: La sonda de captura de datos consiste en una Raspberry Pi que se conecta con la centralita del coche mediante un módulo bluetooth. La centralita del coche se ha equipado, a su vez, con un módulo OBD-II con bluetooth. Esta sonda, de igual manera, dispone de un módulo GPS para proporcionar datos relativos a la posición del vehículo.
  • Programa de telemetría: En la sonda de posicionamiento he desplegado un programa que recopila información de las fuentes anteriores, que he desarrollado en Python. Este programa, en líneas generales, comprueba el estado de las fuentes de datos antes mencionados, recopila la información y la prepara para su transmisión. Para ello, se apoya en un broker MQTT instalado en la propia sonda. Por último, se hace un almacenado local en ficheros csv de la información recopilada, junto con una marca de tiempo.
  • Broker MQTT local: Para realizar la transmisión de datos al servidor de almacenamiento y procesado de datos se hace uso de un broker MQTT local. MQTT es un protocolo ligero de mensajería para pequeños sensores y dispositivos móviles ideado por IBM. Está optimizado para realizar la transmisión de datos incluso en redes no confiables y en entornos de alta latencia, por lo que es ideal para delegar en él la capa de transmisión de datos del programa anterior, ya que es presumible que el vehículo pueda encontrarse en situaciones de escasa cobertura o incluso pérdida total de la misma, además de en situaciones en las que la transmisión de datos haya de efectuarse haciendo uso de redes GSM de escasa capacidad. Además, tiene la ventaja de que produce menos sobrecarga que otros protocolos como HTTP, y (en teoría) hace un menor consumo de datos. La idea es la siguiente: el programa anterior delega en el broker MQTT el establecer el envío de paquetes al servidor. El broker MQTT actúa además como buffer local de los paquetes transmitidos, en caso de pérdida o inestabilidad de las comunicaciones. Este buffer local, gracias a una pequeña base de datos interna, es persistente incluso ante reinicios inesperados de la sonda. El broker MQTT local está sincronizado con otro broker MQTT desplegado en el servidor de recepción de datos, y es capaz de garantizar la correcta sincronización, como se ha comentado, incluso en situaciones de pérdida total de conectividad y reinicios en la sonda de datos.
  • Envío de datos mediante tethering bluetooth: El broker local MQTT es dotado de conectividad a Internet mediante tethering bluetooth con un teléfono móvil. Si bien a priori sería más interesante hacer uso de tethering wifi para esto mismo, hay tres buenas razones para optar por bluetooth: La primera es que al hacer uso de MQTT el volumen de información a intercambiar es bastante reducido, por lo que es posible hacer uso de bluetooth para ello, con el consiguiente impacto positivo en el consumo de energía necesario para establecer el canal de datos. La segunda es una limitación física en la sonda. La Raspberry Pi 2 que utilizo tiene sólo dos puertos USB, uno usado con el módulo GPS y otro con el módulo bluetooth para conectar con la centralita, por lo que no queda sitio para un módulo WiFi. Y la tercera, es que todo es mejor con bluetooth. :mrgreen:
  • Servidor de recepción de datos: El segundo bloque del sistema es el servidor de recepción y análisis de datos. Consiste en líneas generales en un servidor Graphite donde se almacenan los datos proporcionados por la sonda de captura de datos, y que permite su posterior utilización, bien para la representación de gráficas de dichos datos mediante Grafana, bien para la el geoposicionamiento del vehículo en tiempo real, con información añadida del resto de parámetros proporcionados por la sonda.
  • Broker MQTT: La comunicación, como se ha comentado, se realiza mediante un broker MQTT que sincroniza con el broker MQTT de la sonda. Este broker recibe los datos proporcionados por la sonda, y los inyecta, mediante una pasarela desarrollada en Python, en el servidor Graphite. Dado que es posible que la información proporcionada por el broker MQTT de la sonda no se reciba en tiempo real debido a posibles cortes en las comunicaciones, se hace uso de la marca de tiempo incluida en cada transmisión de la sonda remota para inyectar los datos en el servidor Graphite con información de tiempo de creación correcta.
  • Servidor Graphite: El servidor Graphite consolida la información proporcionada por la sonda de captura de datos, la almacena en una sistema de base de datos buffer de corta duración (Carbon) y posteriormente la consolida en una base de datos da larga duración (whisper).
  • Servidor Grafana: Los datos consolidados en el servidor Graphite son consumidos por Grafana, software para visualización de métricas. Se han creado una serie de gráficas que permiten acceder a la información relativa a la velocidad, revoluciones por minuto, entrada de aire en el motor, consumo de combustible y altitud con respecto al mar, así como a sus valores medios en un rango de tiempo establecido. Grafana proporciona, además, la capacidad de integrar estas gráficas en una plataforma de terceros.
  • Captura de posicionamiento de vehículo con datos en tiempo real

    Captura de posicionamiento de vehículo con datos en tiempo real

  • Sistema de geoposicionamiento: El broker MQTT permite, además, el procesamiento de la información proporcionada por la sonda para representar en tiempo real la ubicación geográfica del vehículo, así como la traza de las posiciones anteriores mediante una línea de posición. Además, se proporciona información en tiempo real de los parámetros proporcionados por la sonda. Este sistema está basado en Node-RED, una herramienta desarrollada por IBM para permitir una interconexión sencilla de diversas aplicaciones y dispositivos IoT. También hace uso de OpenStreetMap, mediante la librería WorldMap.

Todo este sistema lo he compilado en la siguente web para su visualización: Telemetría (www.eniac2000.com/telemetria)

Dado que la información mostrada en esa URL proporciona datos en tiempo real, he realizado una captura de datos obtenidos en vivo:

Captura del sistema de telemetría

Captura del sistema de telemetría

…así como un vídeo en el que se aprecia la información, si bien realizando la captura de la información desde las dos fuentes de datos separadas, y no desde el mismo portal:

Como comentaba, el sistema está aún en una fase muy temprana, pero el potencial de mejora es grande. Los principales puntos en los que estoy trabajando son los siguientes:

  • Mejora en la seguridad de comunicaciones entre brokers MQTT
  • Mejora en la fiabilidad de la comunicación OBD-II
  • Reemplazo del sistema de base datos de larga duración de Graphite por un sistema NoSQL, presumiblemente un InfluxDB
  • Dotar de redundancia a los elementos de la plataforma
  • Proporcionar un sistema de persistencia de la información
  • Creación de un portal multiusuario con soporte de múltiples dispositivos
  • Otros… :)

Si bien este proyecto empezó como algo personal, con la idea de comprobar cuánto consumía mi coche en los desplazamientos, tengo el convencimiento de que puede convertirse en algo más que en un mero pasatiempo. Esperemos que así sea.

VN:F [1.9.20_1166]
Rating: 10.0/10 (2 votes cast)

Etiquetas: , , , , , , , , , , , ,

08 ene 17 Sistema de telemetría para el Mercedes

Pues eso. Me he montado un pequeño sistema de telemetría para el Mercedes:

Sistema de telemetría para el Mercedes

Sistema de telemetría para el Mercedes

No es un sistema de Fórmula 1, pero me proporciona datos en tiempo real, accesible por Internet. Otro día escribiré con algo más de tiempo. Pero las palabras claves son: Raspberry Pi, OBD-II, tethering, gps, sockets, Graphite, Grafana y Bluetooth. Porque todo es mejor con Bluetooth. :mrgreen:

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , ,