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
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
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
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
…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
No está mal, ¿no?
Etiquetas: aldi, aqara, aqara cube, arduino, asus tinker board, debian, domótica, home assistant, ikea, lidl, mqtt, nodemcu, orange pi zero, proxmox, raspberry pi, zigbee, zigbee2mqtt
08 nov 20 Instalación manual del firmware Tasmota en dispositivos Sonoff Mini (versión 2020)
Hace cosa de un año escribí un artículo sobre cómo actualizar de manera manual el firmware de los Sonoff Mini, cambiándolo al firmware Tasmota. Recientemente he adquirido una nueva remesa de Sonoffs Mini, y he comprobado que el manual ya no es válido, debido a un cambio en el firmware de casa que traen los dispositivos. En la práctica, se ha simplificado el proceso, que paso a describir:
- Sigue siendo necesario pasar los dispositivos a modo DIY. La diferencia es que ya no se hace con jumper ni es necesario abrir el dispositivo. Ahora basta con pulsar, una vez encendido el dispositivo, el botón durante 5 segundos, para entrar en modo OTA. El LED empezará a parpadear, y el Sonoff levantará una WiFi con nombre ITEAD-XXXXXXXX, a la que habrá que conectarse. La contraseña es 12345678.
- Una vez conectado, habrá que acceder a la URL http://10.10.7.1/, e indicar a qué WiFi queremos que se conecte el Sonoff, introduciendo su nombre y contraseña. El dispositivo se reiniciará, y se conectará a la WiFi indicada.
- A partir de aquí, el procedimiento de actualización sigue el procedimiento que describí originariamente, con la salvedad de que la versión del firmware Tasmota a cargar es directamente la tasmota-mini, ya que la versión tasmota-wifiman ya no existe, y la mini ocupa menos de los 500 kb que marcan el límite de carga a través de OTA para este dispositivo.
…y como siempre, mucho ojo con no cargar la versión tasmota-minimal, ya que esta versión no carga la interfaz web de administración, y puede dejar el dispositivo inservible.
Etiquetas: domótica, ota, sonoff, sonoff mini, tasmota
07 nov 20 Control de apertura de puertas y ventanas con Zigbee y sensores Aqara MCCGQ11LM
Seguimos con proyectos de IoT y domótica. En este caso, y para el piso de Forcarey, estoy preparando un sistema de control de apertura de puertas y ventanas con dispositivos Zigbee. Para ello, he escogido los sensores Aqara MCCGQ11LM. Son unos dispositivos fiables, razonablemente baratos, y -lo más importante- están perfectamente soportados en Zigbee2MQTT.
Sensor de puertas y ventanas Aqara MCCGQ11LM
Y es que la gracia de todo este asunto es que no voy a hacer uso del gateway propietario de Aqara/Xiaomi. Desde hace ya algún tiempo tengo experiencia haciendo uso de Zigbee2MQTT como gateway de código abierto para algunos dispositivos Zigbee que tengo instalados en Santiponce, y la idea -como no podía ser menos- era hacer uso de la misma tecnología en Forcarey. Para ello estoy diseñando un pequeño dispositivo, basado en una placa Orange Pi Zero, que actúe como gateway de los dispositivos que voy a desplegar en el nuevo piso.
Orange Pi Zero con módem USB. El otro dispositivo es un receptor Zigbee
Sí, el dispositivo con conectividad HSDPA que comentábamos en el artículo anterior.
En lo referente a la instalación de Zigbee2MQTT, en líneas generales basta con seguir las instrucciones de instalación que proporciona la web oficial, con una salvedad: en la versión de Armbian que manejo (Buster 20.08.1 con versión de kernel 5.8.5) a la hora de compilar Zigbee2MQTT daba algunos errores con serialport y node-gyp, que están reportados. En mi caso ninguna de las soluciones propuestas funcionaba. Lo único con lo que conseguí hacerlo funcionar fue ignorando la parte de usar el repositorio de Node.js que se indica en las instrucciones en el apartado 2 de las mismas, e instalar tanto Node.js como específicamente node-gyp desde los repositorios oficiales de Debian. De esta manera todo el proceso de instalación concluyó correctamente.
Una vez concluida la instalación, creé el servicio para iniciar automáticamente Zigbee2MQTT al inicio del sistema, asocié los dispositivos, que fueron reconocidos sin mayor inconveniente, con lo que el proceso de configuración del hardware ha quedado concluido. En cuanto al software, el sistema de notificación de actividad de los sensores, en base a recepción de eventos de los dispositivos y su volcado a un servidor MQTT, está concluido. Los eventos se muestran de la siguiente manera:
Eventos registrados en servidor MQTT
…lo que nos permite, a partir de aquí, crear el sistema de notificaciones. ¿Cómo lo voy a hacer en mi caso? Con el estupendo software Home Assistant, que constituye la base de mi sistema de domótica. Pero eso ya quedará para otro artículo.
Etiquetas: aqara, armbian, debian, domótica, forcarey, home assistant, iot, MCCGQ11LM, mqtt, node.js, orange pi zero, zigbee, zigbee2mqtt
28 ago 20 Adaptación a IoT de un difusor de aceites esenciales TENSWALL con control remoto IR
Seguimos con las adaptaciones a IoT. Otra de las que he realizado recientemente es la integración en mi sistema de domótica basado en Home Assistant de un difusor de aceites esenciales controlado por infrarrojos. A principio de verano le regalamos uno de estos difusores a mis cuñados para su casa, pero como también nos gustó para la nuestra, nos decidimos a comprar uno. Elegimos un modelo en Amazon con iluminación y control remoto por infrarrojos, un Tenswall de 500 ml.
Difusor de aceites Tenswall de 500 ml y control por infrarrojos
Por lo que he podido averiguar, es un modelo bastante estandarizado vendido bajo multitud de marcas y fabricantes: se basa en el uso de frecuencias ultrasónicas para producir una vaporización del agua y los aceites esenciales a ella añadidos, generando una niebla que esparce las esencias, pero sin calentar el agua colocada en el depósito. Existen otros modelos más avanzados que integran capacidad WiFi y controlable desde una aplicación en el teléfono móvil, basado -por lo que recuerdo- en un ESP8266, pero el modelo que nosotros adquirimos tan sólo cuenta con capacidad IR. En realidad, una ventaja para lo que estaba buscando. El modelo que nosotros adquirimos tiene las siguientes funciones:
- Encendido/apagado
- Funcionamiento en modo intermitente (varios segundos generando niebla, varios segundos sin generarla)
- Funcionamiento en modo continuo
- Temporizador de funcionamiento a 60, 120 o 180 minutos, o bien en continuo
- Funcionamiento con mucha niebla o poca niebla
- Encendido de luces led, en modo carrusel, o 16 posiciones posibles
- Apagado de las luces led
Para realizar la adaptación a IoT, lo primero fue capturar los códigos IR enviados por el mando a distancia. Para ello utilicé un receptor IR y una librería arduino que ya en su momento empleé para leer códigos del aire acondicionado. Capturé cada uno de los códigos asociados a los comportamientos indicados más arriba. Los adjunto por si a alguien más le sirvieran, en formato raw, y su equivalencia en protocolo NEC:
- uint16_t rawDataOnOff[67] = {9040, 4466, 600, 532, 604, 530, 596, 538, 598, 536, 598, 534, 602, 532, 594, 538, 596, 536, 598, 1642, 598, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1644, 594, 1646, 594, 1646, 594, 538, 596, 536, 598, 560, 576, 558, 566, 568, 568, 564, 572, 562, 574, 560, 576, 1640, 602, 1640, 600, 1640, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600}; // NEC FF00FF
- uint16_t rawDataIntermittent[67] = {9040, 4462, 592, 540, 594, 540, 596, 536, 598, 534, 602, 532, 592, 542, 594, 538, 598, 536, 600, 1640, 600, 1642, 600, 1642, 600, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1646, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 602, 532, 594, 540, 596, 538, 598, 536, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 598}; // NEC FF807F
- uint16_t rawDataContinuous[67] = {9032, 4466, 600, 532, 602, 530, 594, 538, 596, 536, 600, 534, 602, 530, 594, 540, 596, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 600, 1642, 598, 534, 600, 1640, 600, 534, 592, 540, 594, 538, 598, 534, 600, 532, 592, 540, 596, 1644, 594, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1644, 598, 1642, 598}; // NEC FF40BF
- uint16_t rawDataTiming[67] = {9032, 4464, 602, 530, 594, 538, 598, 536, 600, 532, 602, 530, 596, 538, 598, 534, 600, 532, 602, 1638, 604, 1636, 594, 1646, 594, 1646, 594, 1644, 598, 1642, 598, 1642, 598, 1642, 598, 534, 600, 532, 604, 530, 596, 1644, 598, 534, 600, 534, 602, 532, 594, 540, 596, 1644, 596, 1642, 598, 1642, 598, 534, 602, 1638, 602, 1638, 602, 1638, 604, 1636, 604}; // NEC FF10EF
- uint16_t rawDataBigSmall[67] = {9034, 4466, 600, 532, 602, 530, 594, 538, 596, 538, 598, 534, 602, 532, 594, 566, 570, 564, 570, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 536, 600, 532, 602, 1638, 604, 530, 594, 538, 598, 536, 600, 534, 602, 532, 594, 1646, 594, 1646, 594, 540, 596, 1644, 596, 1644, 596, 1644, 598, 1644, 596}; // NEC FF906F
- uint16_t rawDataLight[67] = {9040, 4462, 594, 538, 596, 536, 598, 536, 600, 532, 602, 532, 604, 530, 596, 538, 596, 538, 598, 1644, 596, 1644, 598, 1644, 596, 1644, 596, 1646, 594, 1646, 594, 1648, 602, 1640, 602, 530, 594, 1648, 602, 532, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 600, 1640, 600, 532, 592, 1648, 602, 530, 594, 1648, 592, 1648, 592, 1648, 592, 1650, 602}; // NEC FF50AF
- uint16_t rawDataLightOff[3] = {9042, 2220, 596}; // NEC (Repeat) FFFFFFFFFFFFFFFF
Posteriormente pasé a crear un código arduino que se suscribe a un topic MQTT específico con el que se interactúa con el difusor. La idea es crear en Home Assistant un objeto que implemente las funciones del mando a distancia, y mapear los comandos enviados desde Home Assistant a los códigos IR anteriores. En Home Assistant, basta con crear un objeto de tipo luz, que implemente las funciones anteriormente descritas:
light:
- platform: mqtt
schema: json
name: Oil Diffuser & Light
state_topic: "<topic>"
command_topic: "<topic>/set"
brightness: true
rgb: false
effect: true
effect_list: [intermittent,continuous,timing,big/small,stopLight,lightOff]
…lo que genera una entidad con el siguiente aspecto:
Entidad generada en Home Assistant
Posteriormente, es necesario crear en Arduino un código que sea capaz de suscribirse al topic definido en Home Assistant, y reacciones a la información JSON enviada por éste. En realidad, todos los casos posibles son bastante sencillos. El caso que más complejidad tiene es el correspondiente a la luz, ya que el mismo botón/código sirve para encender la luz LED (que siempre empieza en carrusel de colores) y para rotar entre los 16 colores disponibles. En mi caso opté por mapear el deslizador de brillo definido (sin hacer uso de la paleta cromática) para escoger entre las 16 opciones de iluminación, más el modo continuo. En mi caso, opté por lo siguiente:
- En el caso de recibir “1″ como valor de brillo (valor mínimo): Apagar la luz LED
- En el caso de recibir “255″ como valor de brillo (valor máximo): Encender en el primer modo, correspondiente a la rotación de colores
- Para el resto de valores: Calcular en cuál de los 16 tramos de luz se encuentra el deslizador (dividiendo el valor por 16), enviar el código de apagado (que consiste en simular una pulsación continua del botón de control de la luz durante 2 segundos), enviar el código de luz para entrar en el modo de rotación de colores, enviar de nuevo el código para detener la rotación de colores, y posteriormente tantas veces el código de luz como el tramo en el que nos hallemos (ya que este es el funcionamiento del dispositivo).
Por último, es necesario cargar el código en un ESP8266, equipado con un emisor IR. Dado que el difusor de aceites que yo escogí dispone de abundante espacio, es bastante sencillo colocarlo. En mi caso, el difusor se alimenta con un transformador de 24v en continua, que no se puede utilizar directamente para alimentar al ESP8266. En mi caso, opté por utilizar un buck converter DC-DC de 24v a 3.3v, con lo que queda solventado el problema de la diferencia de voltaje. ¡Y listo! Con todo esto es posible controlar un difusor de aceites simple desde la domótica de la casa.
Etiquetas: difusor de aceites, domótica, esp8266, home assistant, infrarrojos, iot, json, mqtt
25 ago 20 Adaptación a IoT de un robot de limpieza Dirt Devil e integración en Home Assistant
Estos días he estado juegueteando un poco con un viejo robot de limpieza doméstico del Lidl, un Dirt Devil. Es un robot de limpieza bastante básico, con algo ya de tiempo a sus espaldas. No dispone de ninguna capacidad de integración con sistemas de domótica, ni nada que se le parezca. Es más, ni siquiera tiene WiFi. Pero tiene algo interesante: su funcionamiento se basa en el uso de un chip etiquetado como RV285R, que controla toda una placa de circuitos integrados para realizar las funciones del robot: movimiento de los cepillos, ventilador de succión, detección de golpes, sensores de vacío para que no se caiga por escaleras… El caso es que buscando un poco por Internet, encontré un par de páginas sumamente interesantes sobre cómo reemplazar este chip por un sistema Arduino. Así que aprovechando que sigo de vacaciones, no podía menos que dedicar algo de tiempo al asunto.
De acuerdo a la información compartida por Paijmans, el chip RV285R trabaja a 5 voltios, por lo que es posible hacerlo funcionar directamente en dispositivos Arduino. Con un trabajo de ingeniería inversa, fue capaz de obtener la información de a qué se dedican los pines del chip:
Yo he podido refinarlo un poco más, distinguiendo las funcionalidades de los pines:
- P50: Led azul, o de encendido
- P67: Detector de colisión (bumper)
- P66: Zumbador interno
- VDD: 5 voltios
- P65: Nada
- P64: Ventilador
- P63: Nada (Etiquetado como Reset por el fabricante)
- P51: Led rojo, o de indicación de batería baja
- P52: Motor de rueda izquierda, funcionamiento hacia delante
- P63: Motor de rueda izquierda, funcionamiento hacia atrás
- VSS: Tierra
- P60: Nada (aunque sospecho que es detector de depósito lleno del robot)
- P61: Motor de rueda derecha, funcionamiento hacia delante
- P62: Motor de rueda derecha, funcionamiento hacia atrás
Una vez identificados los elementos del chip, era hora de abrir el robot. Se puede apreciar el chip en la parte central de la placa:
Aunque en Paijmans indican que es posible puentear cada una de las patas del chip y conectarlas directamente al arduino (ya que éste tiene más fuerza en las señales que las que pasa el chip), en mi caso he optado por desoldarlo, y conectarle cables de prototipado. Aunque en un principio parecía una buena idea, al poner de nuevo las carcasas del robot, en mi caso saltaron un par de soldaduras de sus pistas, por lo que tuve que hacer trabajo extra de soldadura. Recomiendo soldar directamente al cable:
Una vez soldados los cables, el siguiente paso es el dispositivo Arduino. He optado por hacer uso de un Wemos D1 Mini Pro, de la familia de los ESP8266, ya que proporciona capacidades WiFi, y viene sin los bornes para los cables de prototipado, por lo que podía soldar directamente los cables para ahorrar espacio. Para la lógica del mismo me he basado en la creada por Conrad Vassallo (Converting a cheap Vacuum Robot into IoT) en su proyecto de domotización, ya que está preparado para integrar directamente en un sistema de domótica Home Assistant.
Algunos comentarios:
- He tenido que hacer algunas modificaciones al trabajo de Conrad, ya que en el código que comparte faltaba la parte de conectar a la red WiFi el ESP8266. También he eliminado algunas librerías de las que no se hacía uso (EEPROM, Wire). Además he tenido que adaptar los valores de detección de batería baja (más en el siguiente punto) para que se amoldara a mi caso.
- Conrad ha añadido al proyecto base una idea interesante: un detector de voltaje de la batería de 16v del robot. Usa para ello el pin A0 del ESP8266, que tiene capacidad para medir voltajes. Sin embargo, es necesario utilizar un conversor de voltaje para no quemar el disposito. Un simple divisor de voltaje con dos resistencias funcionará bien, y esta información estará disponible para Home Assistant.
- Carga el código antes de soldar los pines provenientes de la placa. Una vez soldados, ya no es posible cargar código al Wemos a través del puerto microUSB, ya que el pin D4 mete ruido. En mi caso, tuve que desoldar. Para evitar este problema sería interesante añadir actualización OTA, pero me temo que eso quedará para una nueva versión.
Esquema de conexiones del D1 Mini Pro. Atención al uso del pin D4 para el envío de datos como puerto serie desde el Arduino IDE
Por último, queda la parte de Home Assistant. Con añadir el siguiente código a la configuración, el sistema estará preparado para interactuar con el robot:
vacuum:
- platform: mqtt
command_topic: "vacuum/command"
battery_level_topic: "vacuum/state"
battery_level_template: "{{ value_json.battery_level }}"
charging_topic: "vacuum/state"
charging_template: "{{ value_json.charging }}"
cleaning_topic: "vacuum/state"
cleaning_template: "{{ value_json.cleaning }}"
docked_topic: "vacuum/state"
docked_template: "{{ value_json.docked }}"
error_topic: "vacuum/state"
error_template: "{{ value_json.error }}"
El intercambio de información entre el robot y Home Assistant se realiza mediante MQTT. A continuación se puede ver una captura de los datos intercambiados:
¿Y el resultado? Espectacularmente bueno. Dejo un par de vídeos. El primero, con el robot aún abierto, y con una Victorinox haciendo de contrapeso, ya que si no, los sensores de vacío entran en funcionamiento:
…y el segundo, ya con las carcasas colocadas, y probando algunas funcionalidades adicionales, como la limpieza específica en un punto concreto:
Fuentes:
Etiquetas: arduino, dirt devil, domótica, esp8266, home ass, home assistant, iot, mqtt, rv285r, wemos d1 mini pro
Medidor de entropía
