msgbartop
Dale fuego a un hombre y estará caliente un día. Préndele fuego y estará caliente el resto de su vida
msgbarbottom

11 ene 24 Monitorización de vehículos Toyota conectados en Owntracks

Desde hace algún tiempo tenemos en casa un par de Toyotas, un Auris y un Aygo. El Aygo es de 2021, y tiene algo bastante interesante, y es que dispone de conectividad con la plataforma de servicios conectados de Toyota. Con ello, se puede acceder a información sobre viajes, historial, así como generar avisos automáticos en caso de accidente. Existe una aplicación oficial MyToyota, que permite acceder a dichos servicios desde el móvil, además de poder hacerse a través de la web de Toyota.

Pero lo que es más interesante es que alguien se ha currado un proyecto en GitHub que permite acceder con Python 3 a dicha plataforma: MyToyota. Es una versión puesta al día de otro proyecto, MyT, que hacía básicamente lo mismo, pero con una versión anterior de la API de los servicios conectados de Toyota que ha dejado de estar disponible a finales de 2023.

A partir de aquí, ya es echarle imaginación. En mi caso, he desarrollado un programa que permite recabar la información de posicionamiento del vehículo, e inyectarlo en mi MQTT, para integrar esta información en Owntracks. Así tengo centralizado el seguimiento de mis vehículos en una plataforma abierta.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , ,

25 jul 21 Codificación y envío de imágenes por MQTT, y uso de las mismas en HomeAssistant

En fechas recientes he realizado un aprovechamiento interesante de las capacidades de comunicación que proporciona el servidor MQTT que tengo instalado para diversos temas: el envío de imágenes a través del mismo. en principio no es algo para lo que esté pensado un servidor MQTT, que actúa como servidor de mensajería, mediante la suscripción a una serie de topics, mediante los cuales clientes del servidor MQTT pueden intercambiar información en formato texto. Pero como al fin y al cabo, las imágenes no dejan de transmitirse como información codificada, es posible ponerse algo creativo para conseguir su procesamiento correcto.

En mi escenario, se trataba de compartir información proveniente de una webcam, para integrarla en mi sistema de domótica. En otras circunstancias, consumiría la información directamente de la webcam, pero el servidor de domótica y la webcam se encuentran en ubicaciones geográficas distintas, y la red de la webcam se encuentra tras un CG-NAT, por lo que no es posible establecer una publicación directa de puertos. Existe la posibilidad de establecer una VPN, pero esta opción me parecía bastante más interesante. La webcam se trata de una ESP32-CAM, con capacidad para publicar imágenes tanto en formato streaming como imágenes individuales, y acceder a ellas a través de una URL concreta. Mi idea era aprovechar la capacidad de Python de convertir imágenes a arrays de bytes, y volcar la información a un topic MQTT específico, para su posterior consumo. Consumo que en una primera instancia sería una publicación directa en Home Assistant, pero que posteriormente se vio complementado con una idea adicional interesante.

Esquema general del envío de imágenes por MQTT

Esquema general del envío de imágenes por MQTT

Codificación y envío de la imagen por MQTT

La primera parte de este proyecto consiste en el volcado de la información de la imagen en un topic MQTT. En mi caso, aprovechando que dispongo de un servidor Orange Pi Zero instalada en Forcarey para controlar diversos dispositivos Zigbee, creé un pequeño script en Python que toma una captura de imagen de la ESP32-CAM, la vuelca en un fichero temporal, y posteriormente la codifica como un bytearray, para enviarla a un topic MQTT concreto. El código sería el siguiente:

mport paho.mqtt.publish as publish
from PIL import Image
import requests
from io import BytesIO

MQTT_SERVER = “xxx.xxx.xxx.xxx” #Write Server IP Address, or your server FQDN
MQTT_PATH = “path” #Write your MQTT topic path

response = requests.get(“http://xxx.xxx.xxx.xxx/capture”) #Write your ESP32-CAM IP address
f=open(“/tmp/image_test.jpg”,”wb”)
f.write(response.content)
f.close

f=open(“/tmp/image_test.jpg”, “rb”)
fileContent = f.read()
byteArr = bytearray(fileContent)
publish.single(MQTT_PATH, byteArr, hostname=MQTT_SERVER)
f.close

Bastante sencillo. Para no andarme loco con servicios en linux, me limito a invocarlo desde /etc/crontab una vez cada 5 minutos, aunque se puede programar la frecuencia que se desee.

Captura y publicación en Home Assistant

Una vez tenemos nuestra imagen siendo volcada en el topic MQTT correspondiente, se trata de explotarla de manera adecuada. Y en este caso, Home Assistant nos lo pone bastante sencillo, ya que existe una integración de tipo cámara MQTT directamente incorporada a Home Assistant. Su uso es tan sencillo como indicar el topic del que tendremos que recoger la imagen:

camera:
– platform: mqtt
name: MQTT Cam
topic: MQTT_TOPIC_PATH

El resultado es el que sigue:

Captura de cámara MQTT en Home Assistant

Captura de cámara MQTT en Home Assistant

En mi caso, una topa del recibidor del piso de Forcarey.

Otros usos: sistema de alarma mediante correo electrónico con Node-Red

Pero estando ya este sistema montado, y merced a algunos detectores de apertura de puertas y ventanas Zigbee que ya tenía previamente instalados, es posible dar una vuelta de tuerca, y hacer algo más interesante: un sistema que detecte aperturas no deseadas de la puerta de la entrada, que tome varias imágenes, y las envíe por correo electrónico a un buzón previamente definido. El proceso es el siguiente: tengo instalado en la puerta un sensor de apertura Zigbee. La información de este sensor es procesada por un servidor Zigbee2MQTT, que vuelca en un topic MQTT la información de cuándo se activa este sensor. Este topic es procesado mediante una automatización en Home Assistant que, cuando se encuentra activada, envía una señal de alarma mediante un segundo topic MQTT. A su vez, tengo un script en Python en la Orange Pi Zero de Forcarey que se encuentra suscrito a este topic, y que cuando detecta una activación del mismo, toma tres imágenes a intervalos regulares, y las envía codificadas como bytearray por un tercer topic MQTT. Y por último, tengo creado en Node-Red un flujo que está suscrito a este último topic, descodifica las imágenes, y las envía a una cuenta de correo como un adjunto.

Flujo de Node Red de envío de correo

Flujo de Node Red de envío de correo

Admito que tiene que haber maneras más sencillas de hacerlo, pero esta resulta bastante instructiva. :mrgreen:

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: , , , , , , , , , , , ,

23 dic 15 Control remoto de sistemas con WhatApp. Yowsup 2

Nuevos avances. La última vez que utilicé WhatsApp como sistema de control remoto (Riego de jardín con WhatsApp y radiofrecuencia) hice uso de la versión 1 de Yowsup, librería de comunicación con WhatsApp escrita en python. Pero algún tiempo después esta primera versión de Yowsup dejó de ser funcional, y aunque tiempo después fue reescrita en una segunda versión, todo el código que había desarrollado para ello no era compatible.

Después de algunos trasteos, y de comprender cómo funciona esta nueva librería, he conseguido volver a hacer operativo el sistema de comunicación. E incluso el código ha quedado bastante más limpio. Recopilemos: se envía desde un terminal móvil un mensaje de control. Este mensaje es recibido gracias a una aplicación que hace uso de Yowsup, instalada en una Raspberry Pi. El programa interpreta el mensaje, y toma la acción oportuna. Hasta este momento, encender y apagar un relé durante un número de segundos indicado en el mensaje; relé que no se encuentra conectado directamente a la RPi, sino controlado por un chip Attiny85. La RPi, haciendo uso de un emisor de RF de 433 MHz, da las órdenes de encendido y apagado al Attiny85. El Attiny, que se encuentra a la espera de mensajes en un modo de bajo consumo, recibe la señal de interrupción hardware provocada por el receptor de 433 MHz. Sale del modo de bajo consumo, y activa el relé. Posteriormente, bajo otra orden de apagado por parte de la RPi, desactiva el relé y vuelve al modo de bajo consumo.

Teniendo en cuenta que aquí en Irlanda un sistema de riego automático es algo que carece de utilidad (el propio clima es un sistema de riego automático :mrgreen: ), ¿qué se puede querer controlar de manera remota? He aquí la respuesta:

En cuanto a la preocupación por el consumo, éste ha mejorado de manera considerable. El Attiny se encuentra alimentado por una batería de móvil de 2100 mAh, conectada a un panel solar que recarga la batería. Hasta el momento, lleva 4 días funcionando de manera ininterrumpida, y la última medición de la batería indica que la carga es de 3.85v. Un enorme avance con respecto a la anterior versión del reloj de riego de jardín.

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

Etiquetas: , , , ,

24 ene 14 Código de control de Raspberry Pi por WhatsApp

Llevo desde hace algunos meses trabajando en un sistema de control de domótica controlado por WhatsApp en Raspberry: , , . La parte central del sistema es la librería yowsup, que permite comunicarse por línea de comandos con WhatsApp desde linux. He modificado el código del mismo, para poder capturar los mensajes enviados desde el teléfono, e interactuar con los GPIO de la Raspberry. Este es el código que hasta el momento he desarrollado:

Código fuente de control de Raspberry por WhatsApp

Varios comentarios al mismo:

  • El código es feo de narices, lo sé. Hacía mucho tiempo que no tiraba una sola línea de código, y nunca he sido un especialista en python, lenguaje que he tenido que aprender sobre la marcha. Así que no esperes nada especialmente elegante.
  • La manera menos problemática para ejecutar el sistema es la siguiente:screen -dmS whatsapp sudo python /home/pi/yowsup/src/yowsup-cli -c /home/pi/yowsup/src/config.example -E 346xxxxxxxx -a -k, siendo 6xxxxxxxx el teléfono desde el que queremos comunicarnos. El parámetro “-E” es una de las modificaciones que he efectuado. Permite lanzar el yowsup ejecutando el modo de control de las electroválvulas (Electro.py), que es básicamente donde he metido las zarpas.
  • Aunque se puede lanzar sin hacer uso de screen, aconsejo encarecidamente hacer uso del mismo, ya que nos permitirá recuperar la sesión desde terminales distintos a aquel desde donde hemos lanzado el programa, lo que siempre es una ventaja.
  • Es imperativo lanzar mi modificación de yowsup con sudo (o como root), ya que se trastea con la GPIO.
  • Una buena manera de automatizar el inicio de yowsup cuando se encienda la raspberry es añadiendo el comando anterior a /etc/rc.local
  • Aparte del sistema de control de los relés, también contiene el sistema de control de movimiento con el sensor PIR

Espero que os resulte de utilidad. :mrgreen:

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

Etiquetas: , ,