22 dic 19 Instalación manual del firmware Tasmota en dispositivos Sonoff Mini
Editado: Esta versión del artículo se ha quedado obsoleta. En los comentarios se encuentra un enlace a la nueva versión del mismo.
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
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
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
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
- 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.
Etiquetas: apache2, domótica, ncat, sonoff, sonoff mini, tasmota
15 oct 19 Solución hardware para los problemas de conectividad WiFi de la Orange Pi Zero+
Soy usuario habitual -quien lea esto habitualmente lo sabrá a estas alturas- de dispositivos de cómputo en formato single-board computer: para entendernos, Raspberry Pi, Orange Pi y dispositivos similares. Y es que, echando la cuenta, rondan por casa cinco cacharros de este tipo: dos RPi Modelo B (una haciendo de sistema de telemetría en el Mercedes irlandés), una Asus Tinker Board con el Home Assistant, una RPI 3 Modelo B+, y una Orange Pi Zero+, conectada a la impresora 3D. En concreto, tengo una cierta experiencia con las Orange Pi Zero, ya que han pasado por mis manos cuatro de ellas, tres modelos Zero (una en el centro de enseñanza de Ana, otra en casa de mis padres en Córdoba, y otra en casa de mi cuñado Fernando, todas ellas con Home Assistant como plataforma de domótica). El caso es que hace algún tiempo me hice con la evolución de este modelo, una Orange Pi Zero+, pero no había llegado a darle un uso intensivo hasta que la utilicé para controlar la impresora con Octoprint. Y como no le había dado un uso intensivo, no había notado un irritante problema que parece sufrir esta versión del dispositivo: un comportamiento algo errático de la tarjeta WiFi.
En mi caso, este comportamiento se manifiesta cuando se inicia el dispositivo sin estar conectado a ninguna red cableada, y el problema es que la mayoría de las veces la WiFi ni siquiera llegaba a iniciarse. Curiosamente sí funcionaba sin problemas cuando la red cableada también se encontraba conectada, o bien cuando iniciaba la misma con el puerto serie conectado para ver los mensajes de carga del sistema. En estos casos, casi sin excepción la WiFi arrancaba igualmente. Tras leer diversos foros de Armbian, y probar las más variapintas soluciones (versiones de kernel, versiones de sistema operativo, ramas de desarrollo, etc…) y no conseguir nada en claro, finalmente opté ayer por tirar por la calle de en medio: hacer uso de un terminador ethernet de tipo loopback, un viejo truco que usaba en tiempos pretéritos para engañar al sistema operativo de servidores y permitir configurar las interfaces de red sin tenerlas conectadas a redes reales.
Conector loopback RJ45
Tenía mis dudas al respecto, pero ha funcionado perfectamente. A raíz de usar este conector, e incluso sin ninguna configuración específica de la tarjeta de red cableada (simplemente aparece como activa, pero sin dirección IP), la WiFi ya se levanta perfectamente, tras múltiples encendidos, reinicios, apagados, tanto ordenado como desordenado. En fin: puede que no sea una solución muy elegante, pero lo que se puede asegurar es que funciona. 
Por cierto, que mi conector loopback no es tan elegante como el de la imagen de arriba: es un simple conector cortado de un cable de red viejo, cortado y con los pines 1-3 y 2-6 empalmados. 
Etiquetas: armbian, loopback, orange pi zero
14 oct 19 Repetidor WiFi con router doméstico y OpenWRT
Uno de los inconveniente de tener la casa domotizada, con múltiples sensores y actuadores ubicados a lo largo de las tres plantas de la misma (y todo eso sin contar teléfonos, portátiles y otros cacharros que se conectan a Internet), es que la fiabilidad de la señal WiFi se resiente enormemente. Es normal, a más dispositivos queriendo usar de manera simultánea el canal de comunicación, peor es la calidad de la transmisión. Para los profanos, es como hablar por el patio de luces con tu vecino del quinto, si vives en el segundo: si sólo habláis vosotros os entenderéis bastante bien, pero si también hablan los del primero con el tercero y los del sexto con el bajo, a menos que os pongáis de acuerdo para hablar por turnos (con el consiguiente retardo en la conversación), lo único que se oirá será un guirigay de voces. Existen varias maneras de solucionar este problema, a saber:
- Utilizar red cableada frente a WiFi siembre que sea posible: La mejor solución. Pasas de un canal compartido half-duplex a uno dedicado full-duplex. Pero suele tener como principal inconveniente el divorcio si prentendes llevar cables ethernet por toda la casa para que el sensor de temperatura del salón tenga un canal dedicado para sí. Bromas aparte, para aquellos equipos que estén ocultos, cercanos al router o que consuman un gran ancho de banda es la solución óptima, si bien es la más difícil de implementar a medida que los dispositivos se alejan de los puntos de red, y tiene una movilidad muy escasa.
- Utilizar un dispositivo PLC para llevar otro punto WiFi/Ethernet a otra ubicación de la casa: Los dispositivos Power Line Communication consiguen utilizar la red eléctrica de la casa para propagar una señal de datos. Bastante interesante, ya que los cables eléctricos están por toda la casa, pero tienen como inconveniente que precisa de dos convertidores de medios para poder implementar la solución, con el consiguiente coste económico. Lo bueno es que muchos proporcionan de manera simultánea la conversión de medios PLC y punto de acceso WiFi de manera unificada, además de la toma de red cableada, por lo que en cierto sentido se mitiga el impacto económico, que puede estar en torno a los 50€
- Un repetidor WiFi: La opción más económica, y no tan ineficiente como parece. Se trata de ubicar un repetidor de la señal WiFi en las zonas donde la intensidad de la señal del punto de acceso maestro empiece a flojear, para levantar una nueva WiFi (o extender la existente de manera transparente) que tenga más calidad de señal. Aunque parece contraintuitivo que añadir un nuevo dispositivo WiFi a la red pueda mejorarla, la gracia del asunto es que el repetidor emitirá en un canal WiFi diferente al original, por lo que las señales ya no se pisarán tanto.
En mi caso esta ha sido la opción que he elegido para solucionar el problema. Pero en vez de comprar un repetidor comercial, he optado por una opción más sostenible medioambientalmente: poner en servicio un viejo router Huawei EchoLife HG556a de Vodafone que andaba rondando por casa, reprogramarlo con el software OpenWRT, y utilizar sus capacidades para actuar como repetidor WiFi. En este caso la idea es complementar la instalación base de OpenWRT con la interfaz de administración web LuCi, para una configuración más sencilla.
Configuración del repetidor WiFi
…y la verdad es que funciona como la seda. En mi caso, he preferido levantar una WiFi complementaria a la principal (UPC******), y hasta ahora -lleva ya unos cuantos meses, desde que puse en el salón el Amazon Fire Stick- funciona como la seda. Además de tener la ventaja de darme un mini-switch para enchufar la televisión Philips, que es una smartTV arcaica sin WiFi, pero con toma de red Ethernet. Y tan contento.
P.S.: Sí, el nombre de mi WiFi original es el nombre de mi configuración doméstica de Dublín, con el operador de cable UPC Ireland. Pequeños detalles que me recuerdan los días pasados allí, y que en cierto sentido me hacen lucir una sonrisa al recordarme los años que allí viví. 
Etiquetas: amazon fire stick, ethernet, huawei, luci, openwrt, wifi
06 oct 19 Impresora 3D controlada de manera remota
Y seguimos a vueltas con la impresora 3D. En este caso, en el ámbito de la usabilidad. Mi impresora es una Creality Ender 3 Pro, que en su configuración de fábrica se utiliza mediante una tarjeta micro SD y un control en base a una botonera. Sin embargo, la impresora viene con una interfaz mini USB que permite el control remoto de la impresora. Tras un rato de investigar, he encontrado una aplicación llamada OctoPrint que facilita enormemente el control remoto de la impresora. En líneas generales, habilita una interfaz web que permite subir los ficheros .gcode y cargarlos en línea, sin tener que grabarlos previamente en la micro SD de la impresora.
Interfaz gráfica de OctoPrint
No sólo eso, sino que permite controlar todos los aspectos de la impresora, desde la ubicación del cabezal de impresión hasta la temperatura de la cama caliente y extrusor, además del progreso de la impresión. Incluso permite configurar una webcam (bien conectada localmente al servidor donde se encuentre OctoPrint o una cámara IP) para visualizar de manera remota cómo progresa la impresión.
Interfaz gráfica de OctoPrint
En mi caso, he utilizado para albergar OctoPrint un miniservidor Orange Pi Zero+ que había comprado hace algún tiempo (y cuya carcasa había creado con la impresora) con una Armbian recién descargada. Si bien por el momento la alimentación de ambos dispositivos es independiente (existe una manera de obtener la alimentación para la Orange Pi desde la impresora), en mi caso he optado -para optimizar el consumo energético del sistema- por utilizar por delante de la impresora un interruptor general Sonoff Basic con el firmware Tasmota instalado, a fin de poder controlar el sistema desde mi plataforma de domótica de casa, pudiendo encender todo el conjunto cuando vaya a imprimir, y tenerlo apagado cuando no se encuentre en uso. Y así cerramos el círculo: impresora 3D controlada por mi sistema de domótica.
Etiquetas: armbian, creality, ender 3 pro, impresora 3d, octoprint, orange pi zero plus, sonoff, tasmota
22 ago 19 Hacking lab sobre Modbus TCP. Lecciones aprendidas
A modo de finalización de esta serie de artículos, a continuación se describen las lecciones aprendidas de esta práctica, que fueron las siguientes:
- El protocolo MODBUS es un protocolo enormemente inseguro, al no haber sido planteado en su diseño un sistema de autenticación o comprobación de protocolos. Cualquier elemento que esté en la misma red que un sistema PLC que se comunique con MODBUS sobre TCP tiene la capacidad de influir y alterar los valores de dicho PLC.
- En función de la implementación del sistema HMI puede ser más o menos sencillo percibir cambios en los valores del PLC. En este caso, al leerse los cambios cada 500ms, es difícil ocultarse a dichas variaciones.
- Es esencial una adecuada segmentación de la red, para evitar explotación de amenazas mediante movimientos laterales E-O. Esta segmentación puede realizarse mediante un sistema cortafuegos, bien ruggerizado o no, con inspección de protocolos a nivel industrial. Dicha inspección profunda de paquetes, además de crear las reglas convencionales de tráfico permitido en función del origen y destino, permite crear reglas más finas, como por ejemplo otorgar permiso para realizar sólo operaciones de lectura para determinados orígenes (ej.: sistemas de monitorización), y permisos de lectura y escritura para los sistemas de control (HMI), además de denegación para el resto de elementos de la red.
Cortafuegos Check Point de categoría industrial
- Una buena manera de proteger un dispositivo PLC, además de la anteriormente expuesta, es mediante un Gateway que permita implementar las funciones adicionales de autenticación que el propio PLC puede no permitir en función de su implementación.
- En lo referente a los sistemas de reconocimiento utilizados, como nmap, es necesario afinar con la configuración del escaneo, ya que un escaneo masivo como el planteado puede levantar alertas en el sistema de correlación de alertas, si existe, al realizar conexiones masivas a los elementos de la red.
Etiquetas: cortafuegos, hacking, hmi, modbus, tcp
Medidor de entropía
