Hace unos días me encontré con un problema raro: mi aspiradora no respondía a mis órdenes en la app. Pero lo mas raro era el estado de los botones: estaba cargando, pero el botón de «volver a casa» estaba activo, y el de «empezar a limpiar» estaba desactivado.
Un vistazo rápido a los logs me permitió descubrir que el estado actual de la aspiradora era «10», y antes había pasado por el «9» y por el «7». Esto era muy raro, pues los únicos estados que conocía hasta ahora iban desde el «1» (limpiando), hasta el «6» (en la base, batería cargada), tal y como comenté en la entrada «A ritmo de conga (6)».
Obviamente esto era muy raro, así que empecé a investigar revisando los logs, y descubrí qué ya me había ocurrido lo mismo en dos ocasiones más. Las preguntas obvias eran: ¿por qué? y ¿Qué significaban esos nuevos estados?
Entonces me fijé en un detalle raro: antes de pasar al modo «9», la aspiradora estaba limpiando (modo «1»), pero la batería estaba muy baja. De pronto se puso en modo «9», y unos segundos después pasó a modo «10», y entonces el nivel de la batería, de pronto, empezó a subir. Y cuando llegó al 100%, volvió a modo «1», o limpiar.
La respuesta era obvia: cuando la aspiradora está limpiando y ve que la batería está demasiado baja como para terminar el trabajo, ella sola se vuelve a la base (modo «9») para cargarla de nuevo (modo «10») y continuar la operación donde la dejó. El «7» todavía no se qué puede ser. A lo mejor tiene que ver con un par de veces que se me quedó atascada por culpa de un reflejo del sol (no se por qué, pero si da el sol en el parqué, el sensor antiescaleras se lía), pero tengo que hacer más pruebas para confirmarlo.
Así, la lista de estados posibles pasa a ser:
1: limpiando
2: detenida
4: regresando a la base
5: en la base, cargando la batería
6: en la base, batería cargada
7: ??????
9: regresando a la base por batería baja
10: en la base, cargando batería, para continuar un trabajo previo interrumpido por batería baja
Hoy hice algunos cambios extra en el repositorio de OpenDoñita. Para empezar, dado que han actualizado OSMC y ya trae Python 3.7, ahora ya es posible instalar mi servidor directamente en una Raspberry Pi con él. Así lo hice, así que aproveché para añadir un nuevo instalador que sea más sencillo. Ahora, al ejecutar install.sh, se bajarán los paquetes necesarios (tanto de python como del sistema operativo), se instalará todo en el sitio correspondiente, y se lanzarán los servicios necesarios.
Por otro lado, he escrito un nuevo programa para emparejar la aspiradora. Tiene esta pinta:
Gracias a ella, ahora es un poco más sencillo realizar el emparejado desde cualquier ordenador, con la única condición de que éste tenga WiFi.
Hace tiempo había descubierto un curioso mecanismo denominado protothreads. Se trata de una manera de añadir capacidades asíncronas a C. El truco es bastante curioso, pues se basa en una característica poco conocida de C, que consiste en que un switch puede saltar a la mitad de un bucle, ya sea for, while o do…while. Esto es, este código es legal:
switch (a) {
default:
while(1) {
do something
return;
case XXXX:
do more things
}
}
Esto funciona perfectamente en C, y además es perfectamente legal, gracias a la definición explícita de cómo funcionan los bucles en este lenguaje.
La idea detrás de esto es generar a mayores una serie de macros y definiciones que permitan embellecer el código, y hacer que se parezca más a programación asíncrona.
La cuestión es que llevo unas semanas trabajando en un proyectillo en C que utiliza eventos y programación asíncrona, y para simplificar y mejorar el código decidí implementar protothreads. Por supuesto, también utilizaba mi viejo analizador estático crust para analizar el código y detectar errores, y justo aquí me encontré con el problema: no era capaz de analizar correctamente estas estructuras.
Así que aquí tenía dos opciones: o pasar de crust, o actualizarlo para que lo soporte. Y obviamente me decidí por lo segundo.
Esta creo que por fin será la última entrada en una serie que se ha prolongado muchísimo más de lo que esperaba. En esta hablaré de los últimos comandos que quedan por analizar.
En primer lugar está el comando 143. Este comando es el que se emite cuando se pulsa una especie de diana que hay en la parte superior derecha de la app oficial, y hace que el robot emita un pitido. En el manual no dice para qué sirve, por lo que lo único que se me ocurre es para localizarlo cuando no sabes donde anda. Sin embargo lo veo poco útil, pues si está en marcha lo escucharás perfectamente, y si está en pausa, al cabo de un minuto más o menos se apagará y dejará de responder a los comandos enviados por WiFi.
Por otro lado, ya he descubierto para qué sirve el comando 400, y no es para indicar que se ha abierto la app. Resulta que, al contrario de lo que pensaba, es la propia aspiradora la que recuerda las tareas cuando la programamos para que aspire tal día a la semana a tal hora. Así, si por ejemplo tenemos dos tareas programadas, una para que limpie de lunes a viernes a las 19:00 horas, y otra para que limpie sábados y domingos a las 16:30 horas, cuando emitimos el comando 400 nos devolverá esto:
En orders es donde viene toda la información clave: es una lista con tantos diccionarios como programaciones haya. En ellos, el campo sign es el identificador de cada programa. En orderIds vienen los días de la semana en los que se activará, siendo 0 el domingo, 1 el lunes, etc. El campo valid vale 1 si el programa está activo, y 0 si está desactivado. Los campos hour y minute especifican, como cabe suponer, la hora a la que se quiere que comience. Por último, los campos mode, fan y watertank indican el modo de limpieza, la potencia del ventilador y el modo de fregado que se quieren utilizar para ese programa concreto.
El siguiente comando importante es el 402, que permite añadir un nuevo programa a la lista o modificar uno ya existente. El formato es el siguiente:
El formato es aún más sencillo: junto con el comando y el campo signs, que indica qué programa se quiere borrar, se incluye el campo orderIds con los días del programa a borrar. Este campo tiene que coincidir con lo que contenga en ese momento el campo del mismo nombre del programa a borrar. No he probado qué ocurre si contiene menos o más valores.
Un ultimo detalle curioso es que hace un par de días actualicé el firmware de la WiFi, y curiosamente el contenido del tercer entero de las cabeceras enviadas por el servidor cambió de 0x01090000 a 0x01F20000. Lo mismo para el PONG de respuesta a un PING, que pasó de 0x01080001 a 0x01F10001. Sin embargo, si utilizamos los valores viejos todo sigue funcionando exactamente igual, lo que es curioso.
Una funcionalidad que echaba en falta es el control manual: poder controlar el robot para mandarlo de un lado a otro con el teléfono, en lugar de tener que cogerlo físicamente.
El problema es que, tras analizar el protocolo de control manual a partir de las capturas que había hecho, me encontré con que era ligeramente diferente del que ya estaba utilizando. Para empezar, los comandos no iban a través del servidor, sino que se enviaban directamente desde el móvil a la aspiradora (por fin tenía sentido el puerto 8888). Por otro lado, los «valores misteriosos» no seguían el mismo patrón. Para empezar, es la tablet quien envía los PINGs, y siempre con el mismo número de secuencia: 1a 27 00 00. Por otro lado, estas son varias cabeceras de comandos enviados desde la tablet a la aspiradora:
Vemos que el primer campo sigue siendo el tamaño, el cuarto sigue siendo un número de secuencia, y el segundo y el cuarto tienen los mismos valores que en el protocolo con el servidor; pero el tercer campo es diferente; de hecho es el valor del número de secuencia pero con los bytes invertidos y sumándole uno al tercer byte.
Esto ya plantea algunas dudas; por ejemplo ¿qué pasa si el número de secuencia es mayor de 0xFFFF? ¿Está prohibido tal vez? Si está permitido ¿el campo tercero será el cuarto más 256 y con los bytes en orden inverso? De hecho ¿realmente el número de secuencia es de cuatro bytes también en el protocolo original, o puede que sean sólo dos bytes?
De hecho, para probar esto último decidí ver hasta qué valor devolvía la aspiradora, y tras varias pruebas me encontré con que 10.000 es el número de secuencia más grande que envía en el protocolo original, tras el cual vuelve al 1. Pero el servidor sí envía números más grandes de 10.000.
Aparte de este problema, está la cuestión de que en el código tendría que añadir un nuevo socket y gestionarlo… no es difícil, pero sí un rollo. Sin embargo… ¿Qué pasaría si se pudiese controlar desde la conexión original? ¿Puede el servidor enviar comandos de control manual?
La pregunta es legítima, pues cabe suponer que el control manual utiliza la conexión directa para reducir la latencia (a fin de cuentas, es un control interactivo), y además, si estamos en el bar no tiene sentido querer controlar manualmente una aspiradora que no podemos ver. Pero aún así hay casos en los que puede ser necesario, por ejemplo que tengamos varias WiFis en nuestra casa y que el teléfono esté conectada a una y la aspiradora a otra. Así que decidí probar justo eso y… ¡¡¡Funcionó!!! ¡¡¡Es posible enviar comandos de control manual a través del socket del servidor!!! Eso simplifica la tarea enormemente.
Ahora toca analizar el formato. Veamos un primer caso: ordenamos al aspirador ponerse a girar alrededor de sí mismo hacia la derecha durante tres segundos (las respuestas de la aspiradora son, simplemente, el estado actual, así que he borrado casi todo el contenido y lo he reemplazado por unos puntos suspensivos para no alargar demasiado el bloque):
Y ya vemos cómo va: el comando es el 108 , y luego hay un campo direction que vale 4. ¿Será el comando 108 para girar a la derecha, y habrá otros para el resto de direcciones, o será un único comando para todo y el campo direction indica cual de los cuatro posibles movimientos se desea? Además, al cabo de dos segundos vemos que se vuelve a repetir el comando. ¿Por qué?
Finalmente, al cabo de tres segundos se emite el comando con la dirección 5, por lo que cabe suponer que eso significa detente. ¿Pero qué significa el campo tag?
Para resolver todas estas preguntas, veamos todos los comandos emitidos para los cuatro movimientos posibles (adelante, atrás, izquierda y derecha):
¡Ajá! Ahora tiene sentido: se utiliza un único comando, el 108, para los movimientos manuales, con 1, 2, 3 y 4 para moverse adelante, atrás, izquierda y derecha respectivamente. Cuando se quiere parar se emite el mismo comando pero con la dirección 5, y el campo tag especifica qué movimiento es el que se cancela (probablemente por si los comandos llegan fuera de orden).
Además, si probamos con movimientos que duren más tiempo se ve que el servidor vuelve a enviar el comando de movimiento cada dos segundos. Todo apunta a que es una manera de asegurar que el servidor «sigue ahí», y que si pasa mucho tiempo sin recibir un comando de refresco, la aspiradora dejará de ejecutar el último comando. Esto tiene sentido: si se pierde la conexión es importante que el robot no se quede ejecutando una orden de movimiento manual…
Y con esto ya tenemos todo lo necesario para implementar el control manual, y así de bonito se ve en la app:
Como se ve, hay un nuevo icono que permite alternar entre modo mapa y modo control manual, y pulsando las flechas el robot se moverá. Eso sí, por desgracia la aspiradora no puede estar en la base para que este modo funcione, parece una limitación del propio firmware del robot, no de la app original.
Hasta ahora he estado utilizando la web app para controlar mi aspiradora robot tanto desde el ordenador como desde el móvil. El problema es que es bastante pesado, en el móvil, tener que:
Abrir el navegador
Abrir una pestaña en blanco
Escribir la IP del servidor número a número
Así que decidí que tenía que hacer una app para Android. Obviamente no me iba a matar repitiendo todo el trabajo que ya había hecho en JavaScript, así que la solución obvia era hacer una aplicación que simplemente tuviese un WebView (que no es más que un widget con un navegador web completo) y que cargase automáticamente la web app de OpenDoñita automáticamente cada vez que se abriese. Así cualquier cambio que hiciese a la web app aparecería automáticamente también en la app de Android.
Sin embargo, antes que eso tenía que resolver un problema nada trivial: ¿cómo saber la IP del servidor de OpenDoñita? Sí, en mi casa se cual es, pero obviamente si quiero que otras personas puedan usarlo, no es plan de tener que poner la IP «a mano». Además ¿y si el DHCP hace de las suyas en un reinicio y cambia la IP?
La solución vino de la mano de uPnP. Se trata de un estándar para que dispositivos multimedia puedan anunciarse en una red doméstica, y que otros dispositivos puedan identificarlos y comunicarse con ellos de manera estandarizada. También sirve (y será lo que les suene a muchos) para poder abrir puertos externos en el router cuando usamos NAT.
El protocolo uPnP es, en esencia, relativamente sencillo: se utiliza la dirección multicast 239.255.255.250 y el puerto 1900 para enviar y recibir paquetes UDP. Así, si un dispositivo quiere anunciar que cumple con el estándar uPnP, emitirá una serie de paquetes NOTIFY a dicha dirección y puerto, y aquellos dispositivos interesados estarán suscritos a ella para detectar dichos mensajes. Otra manera es que un dispositivo envíe a dicha dirección y puerto un paquete M-SEARCH, y los dispositivos responderán cada uno indicando sus capacidades y demás.
Por supuesto, cuando entramos en detalles nos encontramos con que el protocolo es mucho más rico y complejo de lo que parece. Pero afortunadamente existe el módulo de python iot-upnp, que permite de manera sencilla configurar un dispositivo como servidor uPnP. Precisamente ella ha sido el motivo de que convirtiese el código a asyncio. Básicamente basta con asignar un UUID y un par de cosas más a un diccionario, y nuestro programa ya es un servidor uPnP y responde a los anuncios. Este código está añadido en la última versión del servidor OpenDoñita.
La segunda parte es conseguir que la app de Android pida a los dispositivos uPnP que se identifiquen. En este caso no me compliqué y me limité a crear un socket UDP y enviar directamente una petición uPnP de tipo M-SEARCH, que es un paquete con estos datos:
Con eso recibiré un paquete UDP por cada dispositivo raíz uPnP directamente al mismo socket desde el que envié el paquete. Y como sólo quiero conocer la IP y nada más, lo único que necesito hacer es esperar a que aparezca uno que contenga el UUID que envía mi web app, y ese será.
Por supuesto, las cosas no son tan sencillas, pues la clase de sockets, DatagramSocket, es síncrona, lo que significa que no la podemos utilizar desde el bucle principal de Android sino que necesitamos crear un thread. Para ello utilicé una clase que extiende AsyncTask. Aunque es un método obsoleto, lo es a partir de la API 30, la cual fue lanzada ayer como quien dice (pertenece a Android 11), por lo que prefiero utilizarla y garantizar que mi código va a funcionar en móviles antiguos. Ahora simplemente implemento el método doInBackground() y dentro hago un bucle en el que envío el paquete anterior, me pongo a esperar respuestas con un timeout de 2 segundos (que coincide con el valor de MX de mi petición), y cuando salte éste, si no he conseguido la IP, repito el proceso. Pero si en alguno de los paquetes venía el UUID correcto, salgo del bucle y retorno del método. Es entonces cuando se ejecutará el método onPostExecute() recibiendo como parámetro el valor que devolví en doInBackground(). Lo interesante es que mientras que ésta última se ejecutaba en otro thread, onPostExecute() se ejecuta en el mismo thread desde el que se creó el objeto, o sea, desde el bucle principal en mi caso, con lo que ahí podré llamar al método loadUrl() del WebView para que cargue la página.
La otra cuestión importante es poder capturar el botón de Atras de Android para poder ocultar la pantalla de configuración si se pulsa, pero salir de la app si se pulsa desde la pantalla principal. Para ello sobreescribo en la actividad principal el método onBackPressed(), que es el que se llama cuando el usuario pulsa el botón, y dentro de él utilizo evaluateJavascript() para llamar a la función back_android() de la web app. Esta función hará lo que tenga que hacer y devolverá el valor 0 si no se debe hacer nada, o 1 si se debe salir de la aplicación.
Estos días de vacas estuve aún haciendo alguna que otra cosita con la aspiradora. Para empezar, he portado el código a asyncio, además de permitir rotar el mapa y limpiar un poco el código JavaScript de la app web.
Sin embargo, por accidente me encontré con un serio problema de mi aspiradora. Todo empezó un día que, al mandarla limpiar, se paró a los diez minutos sin venir a cuento. Le daba a limpiar de nuevo, se movía un poco y volvía a detenerse… muy raro. Entonces me di cuenta de que la batería estaba bajo mínimos, por debajo del 30%. Eso era muy raro, pues llevaba más de un día cargando, pero supuse que, a lo mejor, no había enganchado bien, y no le di mayor importancia. La puse a cargar, y cuando estuvo al 100% la puse a limpiar sin más problema.
Sin embargo, un par de días después me di cuenta de que la aspiradora estaba constantemente conmutando de «cargando» a «cargada» cada diez-quince segundos pero la carga de la batería estaba muy baja… bastante raro. Probé a quitarla de la base y a ponerla de nuevo y el problema pareció corregirse, pues ahora sí se puso a cargar y el nivel de la batería empezó a subir. Sin embargo me ocurrió lo mismo unos días después, así que decidí echar un vistazo a los logs de mi webapp, en concreto al nivel de la batería, y me encontré con algo muy raro:
Ahí arriba vemos el histórico de la carga de la batería. En azul está cuando la aspiradora está en la base cargándose, en verde cuando está en la base ya cargada, y en rojo cuando está limpiando. Y esos bloques de carga-cargada son bastante raros… Probemos a ampliar uno, a ver…
Efectivamente, es lo que había notado: pasa constantemente de «cargando» a «cargado» y viceversa, pero la batería no parece cargarse sino todo lo contrario… al menos hasta llegar al 30%, que parece haberse puesto a cargar por fin… Ampliemos ese trozo a ver…
Efectivamente, parece que va alternando entre carga y cargado, y de pronto empieza a cargar de nuevo. Pero parece que hay algo en el punto en el que se arregla. Ampliemos un poco más…
¡Bingo! No sólo está alternando constantemente entre ambos estados, sin cargar realmente la batería, sino que hasta que le di la orden de separarse de la base y volver a ella la batería no empezó a cargarse de nuevo correctamente.
Obviamente esto es bastante raro, y suena a bug: si alguien utiliza la aspiradora todos los días o cada dos días nunca notará este problema, pero si, como yo, la pasas cada tres días, entonces te encuentras con él.
Esto es un problema bastante serio, pues la aspiradora consume bastante batería en reposo al estar la WiFi constantemente encendida, por lo que, cuando empieza a hacer esto, la batería se consume relativamente rápido. Además, no parece haber un periodo exacto tras el que ocurre, sino que aparentemente empieza entre 24 y 48 horas después de la última vez que empezó a cargar.
Obviamente esto no me hacía ninguna gracia: no sólo puede suponer que cuando quiera usar la aspiradora ésta no esté lista, sino que, encima, descargarse tantísimo no es nada bueno para las baterías.
Pero, afortunadamente… ¡¡¡Tengo el poder!!! La aspiradora está conectada a MI servidor, lo que significa que puedo añadir algo de código para detectar esta situación. Es más, puedo añadir algo más de código para que cuando ocurra, automáticamente separe la aspiradora de la base y la vuelva a conectar. Y ya puestos, para que no haga demasiado ruido, poner el ventilador al mínimo durante la operación y restaurar el valor original justo después. Y dicho y hecho: ahora, cada vez que el servidor detecta que la batería pasa de «cargando» con una carga del 80% o menos a «cargado» tres veces seguidas, automáticamente da la orden de separarse de la base y conectarse de nuevo.
Ah, y el trozo de cartón es porque esa parte del suelo está muy pulida y resbaladiza, y las ruedas no siempre consiguen hacer tracción a la hora de separarse de la base.
Pues nada, que al final no me convencía cómo quedaban los mapas, así que hice un cambio chorras y ahora salen así, más parecidos a los de la app original.
No esperaba escribir esta entrada, pero al final me animé. Resulta que, aunque estoy muy contento con mi robot aspirador, tiene un defectillo que no me convence nada, y es que cuando hay una alfombra y tiene que girar estando encima del borde, se suele atascar.
El motivo es que en la parte trasera, justo en el borde del depósito de suciedad/tanque de agua, hay una rueda para apoyarse. Ésta en concreto:
El problema con ella es que si la aspiradora está justo medio subida en una alfombra, con la mitad del cuerpo encima y la otra mitad fuera, y en ese momento gira sobre sí misma en lugar de avanzar, esa rueda tropezará contra el borde de la alfombra y no dejará que la aspiradora gire, sino que la empujará fuera. En un mundo ideal sería una rueda loca y no habría ese problema.
Pero como yo no soy de quedarme de brazos cruzados, decidí intentar solucionarlo.
Las primeras búsquedas de ruedas locas en internet no dieron ninguna solución adecuada: o eran muy grandes, o eran carísimas (¿en serio más de diez euros por una bola de acero y un soporte impreso en 3D?). Así que decidí buscar una solución más artesanal, al menos para intentar probar el concepto y ver si lo resuelve o no.
Al principio decidí buscar dos bolas de rodamiento de 15 milímetros de diámetro y hacer dos soportes con impresión 3D. Algo parecido a la rueda frontal del mClon. Esos soportes con las bolas irían montados a cada lado de la rueda trasera y sobresaldrían un milímetro más que ésta. Eso debería ser suficiente para salvar cualquier alfombra.
Sin embargo, tras hablar con mis compañeros de A industriosa, me indicaron que, realmente, esa rueda loca no gira demasiado y que además es bastante pesada, y que para lo que yo quiero, algo estático (un simple vástago redondeado) haría la misma función y sería más sencillo de construir.
Ante esto, me acerqué a mi Todo a 100 de confianza y empecé a buscar «cosas esféricas» que me pudiesen servir, y encontré unas pelotas de una goma dura que eran perfectas:
Lo primero fue cortarla a la mitad, de manera que midiese 18 milímetros. Esto lo hice fácilmente con un cutter.
El siguiente paso fue recortar un lateral para que encajase en la zona de la rueda actual, cubriéndola por completo.
Y por último, un poco de cola térmica para fijarla. La ventaja de la cola térmica es que se disuelve con un poco de alcohol, lo que me permitirá quitarla sin dejar rastro en caso de que no funcione.
Y el resultado es, sencillamente, perfecto: ya no se atasca cuando tiene que girar en el borde de una alfombra, sino que sube perfectamente sobre ella como si estuviese bañada en mantequilla. Aunque sí es cierto que se desgasta un poco, no creo que sea un problema, pues en último caso, cuando llegue a la rueda, empezará a apoyar en ella y se acabará el desgaste, pero con la ventaja de que estará rodeada por la goma esférica y seguirá cumpliendo la función de ayudar a sortear alfombras al girar.
Esta será, en principio, la última entrada. En ella voy a describir el servidor/app que escribí para controlar mi aspiradora robot.
DISCLAIMER: no seré responsable si alguien decide seguir mis pasos y se carga su aspiradora. En principio todo lo que cuento debería ser seguro, pero por motivos obvios no me puedo responsabilizar de lo que hagan otras personas, sólo de lo que haga yo.
El código está escrito en python, está disponible en mi cuenta de Gitlab en servidor para robots Conga 1490, y se llama OpenDoñita. Esta descripción complementa a la del capítulo 5.
Para empezar, está cómo hacerlo funcionar. Yo lo he puesto en una Raspberry Pi 4 que tenía muerta de risa por casa (de momento OSMC no funciona en ella), la misma con la que configuré la red WiFi interna para analizar el tráfico. Sin embargo es posible ponerla en cualquier ordenador, siempre y cuando se configure un DNS adecuado. En efecto, si recordamos, la aspiradora se conectará siempre a dos dominios concretos, bl-app-eu.robotbona.com y bl-im-eu.robotbona.com, por lo que necesitamos engañarla de alguna manera para que se conecte a nuestro servidor. La manera más sencilla es entrar en la configuración de nuestro router Wifi y y configurar la IP de nuestra Raspberry Pi como la IP del servidor DNS de nuestra red. Luego, en dicha Raspberry instalamos dnsmasq, pero no configuramos la parte de DHCP, sólo el servidor DNS. Una vez hecho esto editamos el fichero /etc/hosts y añadimos estas dos entradas:
Siendo 192.168.X.Y la IP del equipo en donde vayamos a poner a correr el servidor (que, normalmente, será la misma Raspberry Pi).
Un detalle importante es que mi código necesita Python 3.6 o superior, lo que significa que funcionará en Raspbian, pero no en la versión actual de OSMC pues está basada en la versión stretch de Debian (lo he probado; quería meter todo en la misma Raspberry pero no ha podido ser). Hasta que actualicen el sistema base a buster (y me consta que están en ello) no se podrá hacer.
Una vez que está hecho reiniciamos dnsmasq para que refresque los valores, y ya podemos lanzar nuestro servidor. Para ello, desde un terminal, vamos al directorio donde esté el código y escribimos:
sudo screen ./congaserver
Es importante estar en el directorio correspondiente pues, por defecto, es ahí donde el servidor buscará el directorio html con las páginas de la aplicación web que se utiliza para controlar a las aspiradoras. Si lo lanzamos desde otro directorio lo más probable es que no funcione. Para más información sobre screen, recomiendo leer la documentación. Es necesario usarlo (o bien nohup en su lugar) para poder salir de la sesión SSH de la RPi y que el programa siga corriendo.
Podemos probar si funciona todo correctamente simplemente abriendo un navegador y escribiendo en un terminal
ping bl-app-eu.robotbona.com
Si todo está correcto, debería resolver a la IP de nuestra Raspberry Pi.
Y ahora que está todo listo y corriendo, ya podemos conectar la aspiradora. Para ello tenemos tres opciones:
Apagar la WiFi y volverla a encender. En este caso, la aspiradora volverá a conectarse a ella, buscará el servidor de nuevo y se conectará al nuestro, pues recibirá la IP desde nuestro servidor DNS.
Apagar la aspiradora y volverla a encender. Para ello es necesario retirarla de la base de carga y apagar el interruptor situado en el lado derecho, esperar unos segundos y volver a encenderlo.
Volver a emparejar la aspiradora. Es el más lioso, pues con el DNS en marcha la app oficial no podrá conectarse al servidor (usa un puerto diferente) y se negará a arrancar, por lo que tendremos que utilizar el script configconga.py, que explicaré más adelante.
En cualquiera de los tres casos sabremos si hemos tenido éxito porque en la pantalla de nuestro servidor aparecerán mensajes que indican que se están haciendo peticiones.
Una vez conectada, ya está todo listo para empezar a trabajar. Si ahora abrimos un navegador y metemos la IP del equipo de nuestro servidor, nos aparecerá la siguiente pantalla:
En la parte blanca de la derecha es donde aparecerá el mapa, pero de momento estará en blanco. Por otro lado, en la parte superior izquierda tenemos un indicador de carga de la batería. Cuando esta completamente negra estará cargada, y si está blanca estará descargada. Ahí se ve que está casi cargada del todo.
El símbolo del rayo indica que está cargando. Cuando esté cargada del todo (o cuando no esté en la base) dicho símbolo desaparecerá.
A continuación vemos los cuatro botones que podemos utilizar. El primero, con forma de casa, ordena a la aspiradora volver a la base. Sin embargo, si ya está en la base aparecerá sólo en forma de líneas, sin relleno (tal y como se ve en la captura).
El siguiente botón, con forma de «play», le indica a la aspiradora que comience a trabajar. Al hacerlo cambiará a un cuadrado, o sea, «stop».
El tercer botón, con forma de altavoz, permite activar o desactivar el pitido de aviso de la aspiradora. Tal y como está en la captura, está desactivado. Al activarlo sonará un pitido de aviso y el icono pasará a estar relleno.
El último botón, el engranaje, muestra la pantalla de configuración de modo de limpieza. Al pulsarlo aparece esta imagen:
Los cuatro superiores, con forma de ventilador, representan las cuatro potencias de aspiración (nada, eco, normal y turbo). Las cuatro siguientes, con forma de gota de agua, la cantidad de líquido que se utiliza para humedecer la fregona (nada, poco, normal, mucho). Un detalle importante es que no es posible escoger a la vez los modos «nada» de aspiración y fregona. Por último, los siete inferiores representan los modos de aspirado y fregado disponibles, aunque lo normal es utilizar el modo auto y no complicarse.
Lo mejor de todo es que recuerda el modo escogido incluso si se apaga la aspiradora, pues la configuración se guarda en nuestro servidor.
Para cerrar esta ventana basta con pulsar la flecha situada abajo a la derecha.
Si ponemos a funcionar la aspiradora, se irá generando poco a poco el mapa, cuyo tamaño se irá ajustando poco a poco a medida que se va calculando. Por eso al principio estará formado por círculos gigantescos, pero luego irán haciéndose más pequeños a medida que la superficie descubierta aumente. Así, al principio veremos algo así:
El protocolo REST
Y tras esto, paso a describir el protocolo REST utilizado por el servidor. Porque, efectivamente, la nueva app es una aplicación web, por lo que se puede actualizar y tunear sin necesidad de parar el servidor y volver a lanzarlo (lo que, además, exigiría volver a hacer que la aspiradora se conectase a él usando uno de los tres métodos comentados antes).
Los comandos que acepta son los siguientes. Para empezar, están los tres específicos del emulador del servidor de Robot Bona, que son:
El primero devuelve una lista con el identificador de cada robot que está conectado ahora mismo al servidor. Este identificador se puede utilizar para enviar comandos a un robot específico si tenemos varios en casa.
Los otros cuatro son comandos de servidor. El parámetro XXXXX sería un identificador del robot al que va dirigido (obtenido con list), o bien puede ser all si queremos dirigirnos a todos. De hecho, actualmente la app no soporta discernir entre robots, y siempre envía los comandos a all. Si en el futuro me compro otro robot puede que lo implemente.
getStatus devuelve el estado actual de la aspiradora. Se trata de un diccionario con los datos enviados por la aspiradora al servidor, tales como el mapa, el nivel de batería, el modo actual de trabajo… Cada vez que la aspiradora envía una actualización, el servidor la almacena internamente, y es esta caché la que se envía aquí. Eso significa, por ejemplo, que si no estamos aspirando, el mapa que recibamos será el último que se envió, aunque haya sido hace horas. También si hubo algún error aparecerá su código en el campo correspondiente, aunque haga mucho que no se produjeron más errores.
setStatus permite modificar alguno de los valores anteriores, pero sólo en la caché del servidor. No afecta a la aspiradora. Existe para poder resetear algunos campos que se activan en casos muy concretos, como por ejemplo el campo error, y así poder detectar cuando se ha producido uno nuevo. Actualmente no se utiliza para nada.
getProperty y setProperty se utilizan para almacenar datos personalizados en el servidor, referidos a una aspiradora concreta. Actualmente se utilizan para almacenar la configuración deseada (potencia de succión, cantidad de agua en modo fregado, y modo de limpieza), de manera que aunque se apague la aspiradora, el sistema recordará la configuración deseada por el usuario. La forma de almacenarlo es como pares clave/valor, y siempre son strings.
Por último, la lista de comandos que van a la aspiradora. Son:
clean, stop y return controlan la operación básica de la aspiradora: comenzar un ciclo de limpieza, parar, y volver a la base. No tiene más complicación.
updateMap envía un comando 131, de manera que en torno a una décima de segundo después tendremos la variable map actualizada, y podremos obtener su nuevo valor con /robot/XXXXX/getStatus.
sound permite activar (1) o desactivar (0) el pitido de aviso de la aspiradora. Teniendo en cuenta que cada vez que termina de cargar emite un pitido, yo personalmente prefiero apagarlo.
fan y watertank permiten escoger la potencia de aspiración y la cantidad de agua que se utilizarán durante el ciclo de limpieza.
mode permite escoger entre los siete modos de limpieza, aunque lo normal es utilizar auto.
notifyConnection emite un comando 400. En la app actual se emite nada más cargar la página, para avisar de que hay una app abierta.
askStatus emite un comando 98, el cual hace que unos milisegundos más tarde la aspiradora envíe una actualización de su estado. El servidor, al recibirlo, actualizará su caché y podremos leer los cambios con robot/XXXXX/getStatus.
Por último, cualquier petición que no coincida con este formato se asumirá que está pidiendo un fichero, por lo que se buscará en la carpeta html. Es así como se sirven las páginas HTML y las imágenes de la app.
Emparejando la conga a una red WiFi
Una vez que hemos cambiado el DNS veremos que la app oficial, la del móvil, ya no funciona. Esto es porque intenta conectarse al servidor oficial, y al no poder por apuntar ahora al nuestro, se niega a abrirse siquiera. Eso significa que no podemos utilizarla si necesitamos emparejar nuestro aspirador con otra red WiFi.
Afortunadamente, para eso está configconga.py. Es un programita que permite realizar la operación de emparejado. Para ello necesitamos un ordenador con WiFi.
Lo primero es poner la aspiradora en modo emparejamiento. Para ello hay que mantener pulsado el botón de encendido hasta que el piloto de WiFi empiece a parpadear y suene un pitido.
En este momento la aspiradora se ha convertido en un punto de acceso WiFi, con un nombre CongaGyro_XXXXXX (siendo XXXXXX el identificador único de la aspiradora). Ahora tienes que conectarte desde tu ordenador a esa WiFi (no tiene contraseña), y ejecutar el programa anterior con:
./configconga.py WIFI_SSID WIFI_PASSWORD
Siendo SSID el identificador de la red WiFi a la que quieres conectar tu aspiradora, y PASSWORD la clave de dicha red WiFi. Una vez hecho esto la aspiradora dejará de ser un punto de acceso, y pasará a conectarse a la WiFi indicada.
