msgbartop
بنو أمية
msgbarbottom

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

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

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.

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

Etiquetas: , , , , , , ,

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:

rv285r-pinout

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:

IMG_20200824_103439438

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:

IMG_20200824_185905184

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.

IMG_20200824_185913934_HDR

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.
pinout-wemos-mini-d1

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:

mqtt-capture

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

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

Etiquetas: , , , , , , , , ,

03 feb 20 Dash button doméstico con ESP-01

Uno de los proyectos de mejora que tenía para la domótica de la casa era el añadirle un dash button para controlar alguno de los sistemas. ¿Y qué es un dash button? En pocas palabras, es un pequeño pulsador que permite comprar de manera completamente automatizada un producto en concreto a Amazon, con la idea de facilitar la compra sencilla de bienes consumibles.

Ejemplo de dash button

Ejemplo de dash button

El caso es que aunque el producto fue exitoso, tuvo que enfrentarse a una serie de problemas legales, y Amazon acabó retirándolos de la venta. Pero el concepto detrás de ellos seguía siendo interesante. No tardé en encontrar un proyecto en Thingiverse sobre cómo implementar un dash button software libre, y no tardé demasiado tiempo en preparar mi propia versión, con algunas modificaciones sobre el diseño original.

Dash button doméstico

Dash button doméstico

En mi caso, en vez de hacer uso de un ESP8266, opté por usar un ESP-01, más compacto, y un botón rojo externo en vez de un pulsador interno. Por lo demás, el diseño es el mismo. En lo referente a la lógica del sistema, se basa en el modo deep sleep de los ESP. En este caso, el sistema queda durmiendo de manera permanente hasta que el botón es pulsado, lo que despierta al sistema, ya que el botón puentea el puerto RST del ESP-01 con el GND. Combinado con el uso de la batería CR2 de 3V, en teoría hay alimentación para varios años. ¿Y en cuanto a la acción en sí? Sencillo: el sistema despierta, conecta a mi WiFi doméstica, y actualiza un topic MQTT. Después de eso, vuelve a dormir hasta una nueva pulsación.

Parece poca cosa, pero con esa actualización del topic MQTT se puede programar cualquier acción que deseemos en el sistema de domótica. Eso ya queda para una segunda fase. :mrgreen:

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

Etiquetas: , , , , ,

02 feb 20 Integración de Aqara Cube en el sistema de domótica

Seguimos con actualizaciones sobre domótica. En esta ocasión se trata de un mando un tanto especial: un Aqara Cube de Xiaomi. Consiste en un cubo con una serie de sensores de movimiento y acelerómetros que permiten (según el fabricante) definir seis gestos con el que controlar distintos elementos del sistema de domotica: agitar, golpear dos veces, girar a la izquierda, girar sobre una cara, voltear 90º y voltear 180º. Y especifico lo de “que dice el fabricante” porque existe la manera de sacar mucho más partido de las especificaciones base: utilizar Zigbee2MQTT.

Aqara Cube

Aqara Cube

El cubo se integra en el sistema de domótica (bien el del fabricante, bien de un tercero) mediante protocolo Zigbee. Y es aquí donde viene lo interesante: si se hace uso del sistema de integración de código abierto Zigbee2MQTT, se descubre que el cubo envía mucha más información de la que el fabricante permite hacer uso en su sistema propietario. A las acciones anteriores añade información extra de la cara desde la que se realiza la acción; en el caso de las acciones de giro, si es a derecha o izquierda, y el ángulo del giro aplicado; y en el caso de las acciones de volteo, las caras origen y destino. Todo esto permite dotar de mucha más potencia a la integración con el sistema, definiendo una gran variedad de gestos para controlar distintos sistemas. La única pega es que el cubo sólo identifica visualmente una cara (con el logo del producto), pero no el resto, así que puede resultar un tanto confuso a menos que nosotros marquemos visualmente el cubo de alguna manera.

En cuanto a la integración con el sistema, en la parte Zigbee2MQTT es prácticamente inmediata: el mismo sistema identifica e integra el cubo en sus elementos soportados, sin necesidad de acciones adicionales. Una vez integrado, las acciones realizadas se vuelcan a log y al servidor MQTT con un formato JSON como el siguiente:

info 2020-01-28 15:05:20: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:157,”action”:”shake”}’
info 2020-01-28 15:05:20: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:157,”action”:”"}’
info 2020-01-28 15:05:34: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:141,”action”:”rotate_left”,”angle”:-164.38}’
info 2020-01-28 15:05:34: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:141,”angle”:-164.38,”action”:”"}’
info 2020-01-28 15:05:35: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:134,”angle”:-6.42,”action”:”rotate_left”}’
info 2020-01-28 15:05:35: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:134,”angle”:-6.42,”action”:”"}’
info 2020-01-28 15:05:38: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:144,”angle”:202.68,”action”:”rotate_right”}’
info 2020-01-28 15:05:38: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:144,”angle”:202.68,”action”:”"}’

En lo referente a la integración con el sistema de domótica Home Assistant, tampoco supone mayor problema. La idea es definir automatizaciones para los distintos elementos a controlar, con una sintaxis similar a la siguiente:

automation:
– alias: Respond to Cube action
trigger:
platform: mqtt
topic: ‘zigbee2mqtt/ condition:
condition: template
value_template: '{{ "tap" == trigger.payload_json.action }}'
action:
entity_id: light.bedroom
service: light.toggle

…en las que la idea es recoger el valor JSON del topic MQTT correspondiente, y disparar acciones en el sistema. Esto se puede complicar todo lo que se quiera, para identificar las caras del cubo, ángulos de giro, etc… ¿Y el resultado? Pues algo como lo que sigue:

Control de las luces del salón de la casa.

Control de la pérgola del patio.

La experiencia de uso es muy buena, ya que permite integrar el control de múltiples dispositivos en un mismo mando, y obviar el uso del control del teléfono para acciones avanzadas, como veníamos haciendo hasta ahora. Una gran adquisición.

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

Etiquetas: , , , ,

22 dic 19 Instalación manual del firmware Tasmota en dispositivos Sonoff Mini

Gran parte de la domótica que tengo instalada en casa está basada en dispositivos Sonoff. Empezando por el Sonoff Basic, y siguiendo con interruptores de pared y sistemas duales, estos aparatos me han proporcionado una gran versatilidad para controlar de manera remota diversos elementos que tengo por casa. Al principio realizaba estos despliegues con montajes basados en NodeMCU y relés convencionales, pero la falta de un buen empaquetamiento de estas soluciones ad-hoc generaba algunos problemas de seguridad en casa. Así que cuando tuve conocimiento de los Sonoff, y vi que desde el punto de vista económico no había mucha diferencia con lo que gastaba en mis sistemas hechos a medida, decidí pasar a emplearlos en mis nuevos montajes.

El principal problema con los Sonoff, sin embargo, es que no me hace mucha gracia utilizar una plataforma de terceros sobre la que no tengo el control. Por otro lado, con el firmware de casa enfocado al uso de esta plataforma propietaria, no tenía capacidad para integrarlos de manera adecuada en mi propia plataforma. Para solucionar este problema tuve la enorme suerte de conocer el firmware libre Tasmota, que permite independizarse de manera completa de la plataforma propietaria del fabricante, e integrar el sistema con soluciones abiertas (como por ejemplo basadas en protocolo MQTT, que es la base de mi sistema domótico).

Hasta ahora había estado enormemente contento con esta solución, pero desde el principio esta solución tenía un lunar: si bien los dispositivos Sonoff funcionaban excepcionalmente bien por sí solos, o controlados mediante el sistema de domótica, no había una solución adecuada para integrarlos con interruptores de pared convencionales: dado que los Sonoff sólo disponen de entrada y salida de fase (y si acaso de neutro), no presentan la tercera conexión que permite integrarlos en un sistema de llaves conmutadas. Y si bien es cierto que existe la serie TX de interruptores de pared, éstos tampoco pueden usarse de manera conmutada, lo cual es un fastidio bastante importante para usarlos en habitaciones grandes, o en dormitorios.

Esquema de montaje de luces conmutadas

Esquema de montaje de luces conmutadas

Pues bien, la nueva serie Sonoff Mini ha venido a solucionar este gran inconveniente. Este dispositivo dispone de dos entradas de control, de tal manera que se puede colocar cualquier interruptor convencional para interactuar con el dispositivo, incluyendo interruptores conmutados. Lo único que hay que tener en cuenta (y desde mi punto de vista es una ventaja) es que estos interruptores pasan a formar un circuito separado, por los que no pasan ni fase ni neutro, y que lo único que hacen es cerrar el circuito de control en el Sonoff. Mejor desde el punto de vista de la seguridad.

Esquema de montaje de un Sonoff Mini con interruptores conmutados

Esquema de montaje de un Sonoff Mini con interruptores conmutados

La segunda característica interesante es que los Sonoff Mini tienen un tamaño bastante reducido, que en teoría permitiría colocarlos dentro del mismo hueco donde tengamos nuestro interruptor. Y digo en teoría porque, si bien es cierto que por ancho y alto entrarían perfectamente (miden 42.6×46.6mm), el problema viene por la profundidad de 20mm, que me temo que en la mayoría de los casos basta para imposibilitar colocarlos detrás del enchufe. En cualquier caso, no es un gran problema: siempre se pueden colocar dentro de la caja de registro de la habitación, y a correr.

Dicho todo esto, no podía menos que hacerme con algunos de ellos para probarlos. Y en efecto, son una pequeña maravilla. El problema, en mi caso, vino a la hora de cambiarles el firmware de fábrica por el Tasmota. Por lo general con los Sonoff no es demasiado complicado: soldar los pines para conectar un conversor serie-TTL en los conectores que los dispositivos traen de fábrica, y cargar el firmware desde el IDE Arduino. La dificultad con el Mini es que todo es mucho más reducido, por lo que la ubicación de estos conectores en muy poco conveniente, encima el fabricante ha dejado soldados estos conectores, lo que fastidia bastante a la hora de querer usarlos (y encima luego tienes que desoldar lo que sea que conectes, porque si no, la caja del dispositivo no cierra):

Conectores 3.3V, GND, RX y TX en el Sonoff Mini

Conectores 3.3V, GND, RX y TX en el Sonoff Mini

En teoría, esto no tendría que ser necesario, ya que el fabricante proporciona unas instrucciones y una aplicación específica para cargar firmware personalizado mediante una actualización OTA (y que el mismo fabricante publicita, indicando que estos dispositivos son DIY): supuestamente es cuestión de descargar dicho software, conectar un jumper (que viene con el mismo Sonoff) para entrar en modo DIY, levantar la WiFi de programación que el dispositivo espera encontrar, y cargar el firmware que queramos. Pero en la práctica no he parado de encontrarme inconvenientes: el software del fabricante sólo funciona en Windows (que, para colmo, lo marca como posible software malicioso), la mitad de las veces el software es incapaz de detectar de manera correcta el Sonoff Mini, y para colmo, a la hora de realizar el cambio de firmware, el software trata de hacer una conexión a un servidor del fabricante para notificar que estás cambiando el firmware, y paraliza la actualización si no es capaz de conectar con dicho servidor (ver punto 17 del este enlace).

Así que tras una mañana enormemente improductiva tratando de reemplazar el firmware, volví al buen y viejo sistema manual, si bien aún On The Air. Este modo manual es el que desde Tasmota se recomienda para dispositivos Mac, pero he podido comprobar que funciona perfectamente para sistemas Linux. El recetario es el siguiente:

  • Preparar un pequeño servidor web donde alojar el binario a cargar: Para esto vale cualquier dispositivo que tengas por casa, y que luego puedas conectar a la WiFi de programación OTA que el Sonoff espera encontrar. Una Raspberry Pi es ideal, y un Apache2 es perfecto. Aquí es conveniente no pasarse de listo y querer montar un servidor web mínimo con NCAT, ya que a la hora de descargar el firmware el Sonoff Mini compone una URL con parámetros, y NCAT no es capaz de procesarlo adecuadamente. Lo dicho, mejor con Apache. El firmware a descargar habrá de ser inferior a 500Kb, y el precompilado tasmota-wifiman.bin es perfecto para ello. Por último, habrá que obtener la SHAsum del fichero (en adelante, <SHAsum>):
    $ shasum -a 256 tasmota-wifiman.bin
  • Levantar una red WiFi con los siguientes parámetros: SSID: sonoffDiy; Password: 20170618sn . Una vez levantada, se ha de conectar el servidor web anterior a dicha red WiFi. Anotar su IP como <werserver>
  • Poner el Sonoff Mini en modo OTA: Hay que abrir el Sonoff y conectar el jumper para pasarlo al modo OTA. Cerrar y conectar fase y neutro (¡ojo con no invertirlos!)

    Colocación del jumper para modo OTA

    Colocación del jumper para modo OTA

  • Obtener la IP del dispositivo (en adelante <deviceIP>): Bien mediante un escaneo de IPs, mirando en el dispositivo que levante la red, etc…
  • Obtener el identificador del dispositivo (en adelante <deviceID>): Con linux puede realizarse con el comando avahi-browse. Esto puede ejecutarse desde el mismo dispositivo donde se haya levantado el servidor web, o bien desde un tercer dispositivo.

    En este ejemplo, el <deviceID> es 1000988699

    $ avahi-browse -t _ewelink._tcp --resolve

    + wlp3s0 IPv4 eWeLink_1000988699 _ewelink._tcp local
    = wlp3s0 IPv4 eWeLink_1000988699 _ewelink._tcp local hostname = [eWeLink_1000988699.local] address = [192.168.1.109] port = [8081] txt = ["data1={"switch":"off","startup":"off","pulse":"off","pulseWidth":500,"rssi":-47}" "seq=1" "apivers=1" "type=diy_plug" "id=1000988699" "txtvers=1"]

  • Verificar la conectividad con el Sonoff: Lanzar un POST a /zeroconf/info

    $ curl http://<deviceIP>:8081/zeroconf/info -XPOST --data '{"deviceid":"<deviceID>","data":{} }'

    {"seq":2,"error":0,"data":"{"switch":"off","startup":"off","pulse":"off","pulseWidth":500,"ssid":"sonoffDiy","otaUnlock":false}"}

  • Desbloquear las actualizaciones OTA en caso de que estén bloqueadas en el paso anterior):
    $ curl http://<deviceIP>:8081/zeroconf/ota_unlock -XPOST --data '{"deviceid":"<deviceID>","data":{} }'

    {"seq":2,"error":0}

  • Cargar el firmware tasmota desde el servidor web creado anteriormente:

    $ curl http://<deviceIP>:8081/zeroconf/ota_flash -XPOST --data '{"deviceid":"<deviceID>","data":{"downloadUrl": "http://<webServer>/tasmota-wifiman.bin", "sha256sum": "<SHAsum>"} }'

    {"seq":2,"error":0}

  • Verificar en los logs del servidor web que el Sonoff está descargando adecuadamente el fichero: Debería aparecer algo como lo siguiente repetido múltiples veces:
    192.168.4x.xx - - [21/Dec/2019:12:52:33 +0100] "GET /tasmota-wifiman.bin?deviceid=xxxxxxxxxxx&ts=1481765933&sign=95300ceae2fb9cd19f09283e54169cfa7f998d38bf33463ad613e24e76098b20 HTTP/1.1" 206 4394 "-" "itead-device"
    192.168.4x.xx - - [21/Dec/2019:12:52:33 +0100] "GET /tasmota-wifiman.bin?deviceid=xxxxxxxxxxx&ts=1085377743&sign=c96e52cf3e9b7680003df7f3d17a5d266de35d486bf25a62b03d6737a1cc6083 HTTP/1.1" 206 4397 "-" "itead-device"
  • Esperar unos 30 segundos. El Sonoff debería desconectarse de la red WiFi, y levantar una red con SSID tasmota-xxxx. Conectar a dicha red y configurar el dispositivo para conectar a tu red WiFi normal.
  • Configurar el firmware con los siguientes parámetros:
    GPIO Tasmota Component Device Function
    0 Button1 (17) Button
    4 Switch1 (9) S1/S2
    12 Relay1 (21) L Out
    13 LED1 (56) Link/Power Indicator

¡Y listos! Con esto el Sonoff Mini pasa a estar configurado como un nuevo dispositivo con firmware Tasmota. A continuación he dejado un vídeo en el que se ve cómo se puede interactuar con el Sonoff Mini, una vez ya configurado con el software Tasmota, y un interruptor físico:

Editado:

Estas Navidades he estado haciendo algunas pruebas de campo con Sonoff Mini, ya con el firmware Tasmota, y han sido sumamente interesantes. El principal aspecto que he notado es que con el firmware tasmota-wifiman, en el caso de realizar múltiples encendidos y apagados consecutivos pueden perderse algunos de los encendidos y apagados. Para evitar este inconveniente, es recomendable hacer una actualización del firmware a una versión convencional. Para ello, se habrán de realizar los siguientes pasos:

  • Realizar un “Reset 5″ en la ventana de comandos del portal web que levanta el firmware Tasmota ANTES de intentar realizar cualquier actualización OTA del dispositivo. La función de este comando es eliminar cualquier remantente del flasheo realizado para instalar el firmware Tasmota.
  • Actualizar vía OTA el firmware tasmota-wifiman a una versión específica para la variante Sonoff Mini. Esta actualización deberá realizarse utilizando la opción “local File upload OTA”. Está desaconsejado realizar la actualización mediante web OTA, dado el grave riesgo de dejar la unidad inoperativa. El otro requisito es que la versión del firmware ha de tener menos de 500 kB, por lo que se recomienda el uso de la variante tasmota-lite del repositorio de firmare de Tasmota. El binario escogido se descargará al PC local, y desde ahí se subirá al Sonoff Mini vía OTA.
VN:F [1.9.20_1166]
Rating: 10.0/10 (2 votes cast)

Etiquetas: , , , , ,