Adrián Navarro

Lecciones aprendidas con Philips Hue, IKEA TRÅDFRI y Amazon Echo Plus

Tue, 03 Sep 2019 22:30:00 +0000

Hace ya unos diez meses que me compré mi primera "bombilla smart" — una de IKEA TRÅDFRI, que es de lo más asequible y bueno que hay, y hasta hoy, que he llenado mi casa de bombillas "inteligentes" de todo tipo y compatibles entre sí. En este tiempo he aprendido (duramente) un montón de cosas, y malgastado un poco de dinero en el proceso, así que aquí intento detallar lo que he aprendido.

Las lámparas Philips Hue no merecen especialmente la pena. Las bombillas Hue, las tiras LED y demás cacharros son indiscutiblemente buenos, además de caro. Pero las lámparas completas marca Hue no son más que lámparas normales con bombillas Hue o una tira LED en su interior. Puedes hacértelo tú mismo más barato. Ve a cualquier tienda de lámparas, ya verás…

Hay problemas de calidad inesperados. He tenido que devolver varias bombillas E14 de IKEA porque hacen un zumbido insoportable mientras están apagadas (por Zigbee, que aún reciben corriente). En una mesilla, con lámparas en forma de tubo, hacen que sea imposible dormir. Las bombillas Hue no tienen ese problema, pero claro: cuestan exactamente el triple. Pero ojo, no es que todo lo de Philips sea perfecto: también he tenido que devolver una tira Lightstrip Plus 2+1m porque el transformador hace un zumbido insufrible (eso sí, sólo cuando la luz está encendida). Sin embargo, otra tira Lightstrip Plus 2m no tiene ese problema, así que parece ser cuestión de suerte.

La compatibilidad es variable. Varias marcas (Hue, TRÅDFRI, innr…) son compatibles con Zigbee, sin embargo, con matices: por ejemplo, las lámparas con selección de tono de blancos pueden no ser perfectamente compatibles entre sí. Un ejemplo práctico: con el hub TRÅDFRI de IKEA, las bombillas Hue White Ambiance E14 no tienen disponibles todas las escenas de blancos, y además, no se pueden seleccionar con el mando redondo TRÅDFRI (que sí que deja seleccionar tonalidades con las bombillas de IKEA). Si se usa otro hub, como el integrado en el Echo Plus, entonces sí que se pueden seleccionar todas las tonalidades de blancos vía app, pero entonces, el mando redondo TRÅDFRI se vuelve inservible completamente.

No todos los dispositivos parecidos funcionan igual. Pese a ser Zigbee, cada implementación funciona de una forma ligeramente distinta. Por ejemplo, IKEA hace el emparejamiento en dos pasos: primero se empareja el mando con el hub (poniéndolos pegados el uno al otro y pulsando un botón en el mando), y luego se empareja el mando con la luz, quedando todo finalmente emparejado. Con Hue, la cosa es distinta: al encender una luz sin emparejar, se puede emparejar con cualquier hub, aunque esté a varios metros. Si la luz está emparejada pero el hub se ha "olvidado", entonces hay que resetearla usando el número de serie. Y si tienes por casualidad otro hub (como me pasa a mi, que uso el Echo Plus para las luces sin mando, y el hub TRÅDFRI para las luces que también tienen mandos IKEA), eso da lugar a casos divertidísimos donde lanzas el discovery del Echo Plus y termina emparejándote luces que NO querías emparejar (y dejándote los mandos físicos inservibles en el proceso).

HomeKit es un caso perdido. De verdad, es imposible. Yo lo he intentado y no hay manera. La única forma de controlar algo por HomeKit es que el hub sea certificado HomeKit, que el dispositivo que controla sea del mismo fabricante que el hub, y que esté certificado también para HomeKit. Por ejemplo, tanto IKEA TRÅDFRI como Philips Hue tienen hubs y bombillas compatibles con HomeKit, pero no se pueden mezclar (pese a ser compatibles entre sí, con Zigbee), porque no funcionarán: si tienes el hub de IKEA, sólo podrás controlar por HomeKit las luces de IKEA, y viceversa.

· · ·

Hay trucos interesantes que no están detallados de forma oficial. Por ejemplo: se pueden emparejar dos mandos TRÅDFRI entre sí para que controlen el mismo grupo de luces. Esto es bastante útil, por ejemplo, para luces de mesilla en una cama doble, duplicando el control de luces y haciendo que se enciendan y apaguen a la vez. Útil si vives solo, claro…

A día de hoy, esta es mi configuración de iluminación:

Mesillas del dormitorio: dos bombillas Philips Hue E14 (White Ambiance), con dos mandos IKEA TRÅDFRI, enlazadas con el hub de IKEA (porque el Echo Plus no reconoce los mandos)
Techo del dormitorio: una bombilla IKEA TRÅDFRI E27 con selección de tonalidad de blancos, enlazada con el hub del Echo Plus
Salón: dos raíles, cada uno con tres bombillas IKEA TRÅDFRI GU10 (ajuste de brillo únicamente), enlazadas al hub del Echo Plus
Televisión: detrás de la TV, hay una tira Lightstrip Plus de 2m, enlazada con el hub del Echo Plus.
Comedor: un raíl de tres bombillas IKEA TRÅDFRI GU10 (ajuste de brillo únicamente), enlazadas al hub del Echo Plus
Estudio: una única bombilla Philips Hue E27, con ajuste de brillo, enlazada con el hub del Echo Plus
Cocina: dos barras LED de IKEA, modelo OMLOPP (de 60 y 80cm) bajo los muebles de la cocina, con un driver TRÅDFRI de 30W, y un mando a distancia TRÅDFRI, con el driver enlazado al hub de IKEA (para no perder la funcionalidad del mando)

A través del skill de IKEA Smart Home (antes IKEA TRÅDFRI), el Amazon Echo detecta las luces conectadas al hub-gateway de IKEA, y se pueden controlar al mismo nivel que las que están enlazadas directamente con el Echo Plus.

En el futuro, me gustaría reemplazar el hub de IKEA por el del Echo Plus, que es evidentemente superior al de IKEA en todos los aspectos excepto en el soporte de mandos a distancia de IKEA (que los detecta como un "Nuevo Dispositivo" desconocido sin funcionalidad alguna).

Hasta que los soporte (si es que algún día lo hace), tengo que decidir si aguanto con dos hubs, o si cambio los mandos de IKEA por otros que quizás sí sean compatibles (¿Cuáles lo son? ¡Quién sabe! Aunque el Echo Plus parece ser plenamente compatible con el Hue hub, y por extensión, con todas las cosas Hue)

Toca tener paciencia.

La fibra de Movistar: routers y ONTs

Fri, 09 Sep 2016 11:31:00 +0000

Hace unos días recibí dos routers Mikrotik hAP ac, pedidos con la esperanza de poder sustituir el nefasto Comtrend de Movistar —en modo monopuesto, por Imagenio— y mi fiel Asus RT-N66U que ya empezaba a fallar a nivel físico, además de no llevarse demasiado bien con un TP-Link WA801ND, que generaba problemas de ARP que no conseguí resolver. Y además carecía de PoE Gigabit…

Primero, tomar alguna que otra decisión ejecutiva. Por ejemplo, acabar con el deco nefasto de Movistar en favor del app de Yomvi para Smart TV. Imagenio funciona a través de su propia VLAN, con una configuración propia (que ha de exportarse del router Comtrend) y otras cosas más. Como en casa apenas usamos la tele y aún menos el deco, y el app de Yomvi funciona perfectamente en la tele (sólo faltan unos pocos canales — y ninguno importante para nosotros), parece que el beneficio es más grande que la pérdida.

Manos a la obra. Primer paso, trastear con el ONT. Traté de configurar el ONT (Huawei HG8240) como router monopuesto.

Al hacer eso, y porque soy un manazas, la lié muy parda y borré sin querer mi contraseña del ONT (en la configuración de comunicación con el OLT. Esta contraseña es única para cada cliente de fibra, y también se llama IdONT en jerga de Movistar. Después de intentar conseguir ayuda por parte de Movistar (y aún estoy esperando a que me llamen…) encontré, de paso, una forma de recuperar el IdONT bastante tonta.

Primero, hay que entender que el IdONT (AKA "ONT Authentication") es una cadena hexadecimal de 10 carácteres que a menudo (pero parece que no siempre) comienza por la letra f. Resulta algo confuso porque además la interfaz de configuración la muestra por defecto como una cadena ASCII, así que es un texto más corto con a veces espacios, letras y quizás tildes (no tiene mucho sentido leerlo puesto que es hexadecimal convertido a ASCII).

Pues bien, ese mismo IdONT se usa como usuario para la VoIP, y pese a haberme cargado el IdONT en la configuración, seguía en su lugar la configuración de la VoIP. Sencillamente, yendo a Status > VoIP information aparece en la tabla el campo "User Name", con el formato "IdONT_n". En mi caso, algo parecido a "f2013000919191_1". Volviendo a la configuración de contraseña del OLT, hay que seleccionar el modo hexadecimal, poner la cadena (en el ejemplo, f2013000919191), introducir el SN (número de serie — fácilmente accesible como "SN" en la caja del dispositivo) y guardar. ¡Y hay sincronía!

Para la próxima vez, más vale hacer una copia de seguridad de toda la configuración, apuntar todos los campos que se modifican, tomar capturas de todo y mirar bien qué es cada cosa. Dos veces.

Todo esto para al final descubrir que el PPPoE gestionado directamente por el ONT (lo que buscaba conseguir para convertir al Mikrotik en completamente agnóstico de todo y que únicamente recibiese asignación por DHCP en la WAN), no llega ni de lejos a aprovechar los 300/300. Así que dejo la configuración como estaba antes y busco otra vía.

Segundo intento: configurando el cliente de PPPoE directamente en el router Mikrotik. En pocas palabras, esto supone configurar la interfaz WAN (ether1) con una VLAN (en este caso, ID 6), y sobre esa VLAN, ejecutar un cliente PPPoE con la configuración estándar de Movistar FTTH. Todo esto se puede hacer a través de WebFig, sin necesidad de descargar Winbox. Sería:

Interfaces > VLAN (tab) > Add. Poner VLAN ID a 6, Interface a ether1 (puerto WAN que va al ONT) y guardar.
PPP > Add New (PPPoE client). Interfaz vlan1 (o la que acabamos de crear), usuario adslppp@telefonicanetpa y contraseña adslppp.

Y ya está.

Queda margen para optimización y mejoras. Por ejemplo, montar una red de invitados usando un bridge específico, Virtual AP en Wireless, un nuevo servidor DHCP en esa interfaz, quitando el Default Forward y configurando reglas en el firewall. También tengo pendiente explorar Fasttrack/Fastpath aunque existen limitaciones por el uso de PPPoE (maldita sea, Movistar).

Para terminar sólo queda configurar el segundo AP, conectado mediante ethernet gigabit y alimentado por PoE (power over ethernet), en modo punto de acceso / bridge completo (desactivando el servidor DHCP, configurando el AP con una IP estática en la red del router principal, e incluyendo todas las interfaces existentes en un único bridge).

La guinda en el pastel es el WiFi, 802.11ac en 5 GHz. Se puede configurar (no viene por defecto) con ancho de banda 20/40/80Mhz, y supera los 700 Mbps observados (de unos teóricos, en papel, de 867 Mbps). En la práctica, suele estar por encima de los 500 Mbps. Esto, junto con una configuración de punto de acceso idéntico en el router principal y en el AP, hace que en la práctica sea posible alcanzar bastante más de 300 Mbps inalámbricos en prácticamente cualquier parte de casa, y además con roaming entre los dos puntos de acceso sin notarlo. ¡Esto es el futuro!

París está bien

Fri, 22 Apr 2016 23:27:00 +0000

Hasta el momento, mi única visita consciente y adulta a París fue una escala de un día, entre un Eurostar desde Londres y un vuelo a Madrid al día siguiente por la tarde. No fue especialmente bien: perdí el DNI durante el viaje, me olvidé de comer en París, llegué tarde al tren al aeropuerto y al poco de cogerlo se averió (y pese a todo, conseguí volver a Madrid en mi vuelo — y eso que hasta los carritos de bebé me adelantaban por la terminal de lo agotado que estaba).

Salvando todo ese drama, y unas temperaturas absolutamente insoportables, la visita estuvo bien, pero me dejó con cierto amargor del que hasta ahora no había conseguido librarme. Pero una amiga, Nani, me convenció para ir en enero de este año y … bueno, resulta que con tranquilidad, París está bastante bien. Y ahora he renovado mi fe en París, su maravillosa red de transporte (sí, es que a mi me van esas cosas…) y también su Autolib'. Ya he cumplido mi objetivo de conducir en otra —caótica— ciudad europea. Londres, ahora es tu turno.

Y bueno, aprovechando que estábamos allí no podía faltar un paseo en TGV para comprobar si Estrasburgo está donde dicen que está y cómo están quedando nuestros impuestos.

Está bien París, sí. Mira, mamá, sin miedo.

Porto

Fri, 22 Apr 2016 22:48:00 +0000

Porto tiene tres grandes virtudes. La primera es el vino dulce. La segunda es su aspecto inconfundible. Y la tercera son sus vuelos baratísimos desde Madrid. Así que, ¿por qué no ir a pasar un rato, otro enero más? ¡Daytrip!

La primera vez fue en enero del año pasado. Ya hablé de eso anteriormente, y me vine con algunas fotos que aún me traen buenos recuerdos:

Aprovechando las ofertas de año nuevo, volví, esta vez con Andrea, y a parte de ponernos finos a vino, pudimos ver cosas bonitas y disfrutar de un tiempo espectacular. Gracias, karma.

Para contrastar, os dejo con mi mejor peor foto:

Y bueno, no hay dos sin tres. ¿Nos vemos en enero?

Encapsulando tráfico

Thu, 13 Aug 2015 11:06:00 +0000

"IP over…" da para muchas cosas. Por ejemplo, el maravilloso protocolo de IPoAC. Pero hoy voy a hablar de otra cosa. IP sobre DNS, y de IP sobre ICMP.

¿Motivo? Viajar. Y la necesidad de tener un mínimo de comunicación, aunque sea navegación web reducida a mínimos, Telegram y poco más. Porque a menudo los precios resultan inabarcables… y porque algo bueno tendrá que tener ser un tecnofriki.

Dos cosas, por lo tanto: iodine para encapsular vía DNS, y hans para hacerlo a través de ICMP. En mi caso, he escogido la configuración más sencilla: una máquina en DigitalOcean dedicada exclusivamente para la tarea (dado que interferir con DNS e ICMP puede resultar complicado si no), y un dominio propio con control sobre la zona DNS.

Instalando iodine

Lo primero es crear la zona DNS. Asumiendo que tenemos un dominio h4x0r.com, y la IP de nuestro servidor es 123.123.123.123, bastaría con crearlo de tal manera que iodine.h4x0r.com fuese una entrada A apuntando a la IP, y tunnel.h4x0r.com fuese una entrada NS apuntando a iodine.h4x0r.com. como nombre cánonico. Muy importante el punto al final para que no sea relativo.

Después, en el servidor, hay que instalar iodine. En la última Debian es muy fácil: apt-get install iodine y listo. Con ello, sólo queda configurar bien iodine editando el fichero /etc/default/iodine:

START_IODINED="true"
IODINED_ARGS="10.0.0.1 tunnel.h4x0r.com"    
IODINED_PASSWORD="h4x0r"

La primera línea hace que el daemon se llegue a ejecutar (si no, el script init.d no se ejecutaría). Después, los argumentos: primero, la IP —privada— que tomaría el servidor una vez establecido un túnel, y después, el dominio público que apunta al túnel (ojo: la entrada NS aquí). Y por último, la contraseña en texto plano del túnel que deberán conocer tanto cliente como servidor. Cámbiala.

Llegados hasta aquí, basta con lanzar iodine como un servicio normal, haciendo /etc/init.d/iodined start y listos.

Cosas a tener en cuenta: primero, que iodined actúa en el puerto 53 así que no debe haber ninguna instancia servidor de bind o de dnsmasq corriendo. De ahí el interés de tener un servidor (virtual) y una IP dedicada únicamente para esta tarea. Después, que realmente iodine lleva dos procesos: iodine que es el cliente, y iodined que es el servidor. Ambos usan argumentos casi idénticos así que puede dar lugar a confusión.

Instalando hans

En Debian esto es un pelín más complicado, porque no viene en los repositorios. Pero no es mucho más complicado. Lo primero: tener todas las herramientas para poder compilar, y git también, por comodidad. Si no lo tienes: apt-get install build-essential git y listo. Luego, basta con compilar y moverlo al $PATH, en mi caso, por elección personal, /usr/sbin que es donde está iodine (puedes verlo usando whereis).

git clone https://github.com/friedrich/hans.git
cd hans
make
sudo mv hans /usr/sbin/

Y ya está. Si ejecutas hans en cualquier directorio debería darte la versión.

Siguiente paso: hacer que se comporte como un demonio. Del sistema. Para eso me he limitado a copiar los ficheros de default de iodine y el init.d también, ajustándolo a las necesidades de hans. Luego con insserv se configura como servicio y se lanza al arranque. Aquí están los ficheros que he usado: el primero se debe copiar a /etc/default/hans y el segundo a /etc/init.d/hans. Luego:

chmod +x /etc/init.d/hans
insserv hans

El fichero de defaults es muy similar al de iodine. En la primera línea, dejar que el script de init.d pueda correr (forma fácil de desactivarlo). Después, la IP privada en la que se situará el servidor host (he usado un rango distinto al de iodine para evitar posibles conflictos). El flag -r hace que hans responda también a los paquetes de ping normales, lo cual puede ser útil para saber fácilmente si el proceso está corriendo. Aunque al no responderse desde la capa kernel, es normal que la latencia percibida en el ping se dispare. No pasa nada. Y finalmente, la contraseña del túnel (no olvides cambiarla y recordarla).

Finalmente, un último detalle: hay que hacer que el sistema no responda a los paquetes ICMP, para que hans pueda hacerlo. Muy sencillo. Basta con editar el fichero /etc/sysctl.conf y añadir una línea al final:

net.ipv4.icmp_echo_ignore_all = 1

Aquí es recomendable reiniciar el sistema. No es necesario realmente: con sysctl -p se pueden refrescar los ajustes del kernel sobre ignorar ICMP, y se pueden levantar ambos servicios a mano, pero así veremos si los servicios se levantan a la vez sin problemas. Y para comprobarlo, ejecuta ps aux como root, y tanto hans como iodine deberían figurar en la lista.

Usando iodine y hans desde OSX

Asumo que a estas alturas cualquier persona ya conoce brew en OSX. Así es muy fácil: brew install iodine y tendremos iodine instalado. Puede que dé algún error con la instalación de tun/tap, pero basta con seguir las instrucciones que ofrece el error para instalar ese componente y listo.

Para hans, se puede compilar (muy fácil en OSX si se tienen las herramientas instaladas) o directamente usar el binario compilado oficial y copiarlo al $PATH de tu elección (en mi caso, /usr/local/sbin, porque es donde están los orígenes de los binarios instalados por brew).

Una vez terminada la instalación de ambos componentes, podremos ejecutar iodine y hans en cualquier directorio con éxito. Y como se están ejecutando en el servidor, ya basta con atacar la parte cliente.

El principio de todo esto es de establecer un túnel. Así, si ejecutamos hans en el cliente con todos los parámetros necesarios, establecerá un túnel mediante ICMP de tal manera que en la dirección 10.0.1.1 tengamos al servidor remoto (pero no acceso a internet puramente dicho). Es exactamente lo mismo con iodine, solo que con la IP 10.0.0.1. En ambos casos, son las IP especificadas en los ficheros de default donde se configuran los argumentos de ejecución de servidor.

Desde el cliente, se lanza así:

# Para iodine
sudo iodine -f -P h4x0r tunnel.h4x0r.com
# Para hans
sudo hans -f -c 123.123.123.123 -p h4x0r

Lógicamente, hay que cambiar tanto la IP, como la contraseña y la ubicación de la entrada NS para corresponderse con lo configurado. Aquí sigue los ejemplos. El parámetro -f hace que se mantengan en primer plano. Se pueden ejecutar en segundo plano quitando ese parámetro.

Si todo funciona con éxito, podremos hacer SSH a la IP remota (que varía según usemos hans o iodine, como explico arriba) y conectarnos con el servidor (y nada más). Así que todo lo que queramos hacer pasa a través del servidor.

Aquí entran en juego varias posibilidades. Por ejemplo, montar un proxy SOCKS (que viene directamente con SSH):

ssh -D 1080 root@10.0.x.1

Y así, en 127.0.0.1:1080 tendremos un proxy SOCKS con acceso a internet. Luego basta con configurarlo en las opciones de red de OSX para que lo usen la mayoría de programas, o en los ajustes avanzados de red en el caso de Firefox, especificando la IP del proxy como 127.0.0.1 (local) y el puerto 1080 (el especificado en el argumento -D de SSH). Y así tendremos internet.

Otra opción más avanzada, basada en la misma, es usar sshuttle, que es una especie de "VPN de mentira" sobre SSH que no requiere nada instalado en el servidor remoto y es mucho más liviano. Basta con instalarlo en OSX y ejecutarlo:

brew install sshuttle
sshuttle --dns -r root@10.0.x.1 0/0

Así, tendremos un túnel entre nuestro ordenador y el servidor (con una IP privada que será 10.0.0.1 o bien 10.0.1.1, según qué tipo de túnel sea), y dentro de ese túnel, todo el tráfico (es decir, el de la subred 0.0.0.0/0) estará enrutado mediante sshuttle.

Hay un montón de opciones más. Por ejemplo, si tenemos OpenVPN montado en el mismo servidor, bastará con lanzar el cliente de OpenVPN y especificar la IP privada del servidor al otro lado del túnel, y debería tener acceso completo a internet entonces. O si tenemos OpenVPN en otro servidor, el mismo cliente (por ejemplo, Viscosity) se puede configurar para emplear un proxy SOCKS.

También existen otras opciones más complicadas como configurar el servidor como router, y una vez establecido el túnel, modificar nuestra tabla de enrutado para configurar al servidor remoto al otro lado del túnel como gateway.

Pero dado el limitadísimo ancho de banda que se suele obtener con un túnel, la opción más sencilla suele ser la mejor… y en este caso, yo creo que usar SOCKS con únicamente un navegador es suficientemente satisfactorio (y además, evitas que otros procesos y programas saturen el poco ancho de banda que tienes, porque no pueden salir a internet al desconocer el proxy). Y si SOCKS se queda corto, entonces sshuttle puede ser el combo ideal. ¡Y con unas pocas líneas de terminal!

Orbitando durante un año

Mon, 23 Mar 2015 21:04:00 +0000

La última vez que escribí sobre viajes fue a finales de 2013, tras un año épico: Corea, Tokyo, Alemania, Londres… En general, 2013 fue un año muy intenso. Justo al final, en noviembre, entré a trabajar en ShuttleCloud, donde sigo desde entonces (y más feliz que una perdiz).

Ha llovido muchísimo desde 2013. Pero, pese a tener la universidad de por medio y un nuevo trabajo también, no he dejado de viajar. Y es que 2013 fue sólo un buen comienzo… Porque 2014 no ha estado nada mal.

Empecé el año viajando a Nueva York con la empresa. Fue mi primera vez en NYC, y se podría decir que en EEUU también, por lo menos desde que tengo uso de conciencia (mi único recuerdo de la primera vez de verdad, siendo muy pequeño, se limita a expendedoras de cubitos de hielo, retretes desbordantes y una excursion a Cabo Cañaveral).

No hay nada que pueda escribir sobre NYC que no se haya escrito ya en algún otro sitio (¡luces!, ¡rascacielos!), así que me limitaré a dejar una foto y avanzar:

Unos pocos meses después, topé con una "tarifa error" provocada por la fusión de US Airways con American Airlines (¡gracias, Flyertalk!). Y de forma casi inesperada, terminé de nuevo en NYC, sólo meses después de la primera visita. Aunque esta vez aproveché para visitar también Washington DC. Porque en Boston hacía frío, y porque… pues porque me encanta House Of Cards, a quién voy a engañar:

En este viaje descubrí que si una empresa se llama 'Eastern Bus', no es porque opere en la costa este… Si no por su público asiático. Y también me (re)enamoré del género humano, de nuevo, en DC. (A veces conviene sentirse vivo.)

Después, tocó visitar el Primavera Sound, que omitiré para no pasarme de moderno. Además, inmediatamente después, terminé aterrizando en Sofía. Una ciudad con un nombre precioso, no tan preciosa, que es la capital de Bulgaria. Bueno, en realidad tiene buenos ángulos, y basta con encontrarlos.

Bulgaria es un país muy interesante. También es el país más pobre de la UE, y se nota. Lo realmente curioso, para mi, fue ver como en Sofía, ser turista y no estar solo de paso resultaba extraño y divertido para los locales (¿quién querría visitar esta ciudad?). Me lo pasé como un niño pequeño (pero con edad de tomar mucha cerveza).

En julio, y aprovechando la presencia de compañeros de trabajo de EEUU, visitamos Salamanca. Fue la primera vez que estuve, y fue precioso. ¡Gracias, Félix!

Después siguieron varias escapadas espontáneas: la Euskal Encounter, Francia, y el festival Paredes de Coura. (Quizás el mejor festival, y a la vez, la mayor decepción, del verano.)

Y finalmente cerré el año con un triplete de viajes, cortesía de eDreams y una maravillosa oferta (aunque comercialmente catastrófica para ellos…).

Primero, Ginebra, con amigos y muy rápido. ¡Un lago! ¡Suizos! ¡Cosas carísimas!

Luego, Londres. Casi rutinario, y bastante gris. En ocasiones, pasan cosas. Otras veces sale el sol.

Y finalmente, Budapest. Una espinita clavada desde que visité Sofía y me quedé con más ganas de ir al este (en contra del dictamen de los Pet Shop Boys, unos meses antes, en Murcia… ¡jubílense, señores!). Una ciudad preciosa y vibrante, aunque por desgracia, enormemente turística. Nada es perfecto.

Pero bueno, un post no es un post sin algo de trampa. Hay que empezar 2015 con buen pie, y la mejor forma de hacerlo, es enamorándote. Un poquito. (Nunca del todo.)

Oporto ha sido mi sorpresa personal del comienzo de 2015. Dejo esta puesta de sol maravillosa y cierro post. Ahora queda vivir 2015, y empezamos en tres, dos, uno… click

Problemas con el MacBook Air

Thu, 02 Jan 2014 19:46:00 +0000

Hace poco renové Mac, esta vez pasándome al MacBook Air. Es uno de los mejores ordenadores que he tenido nunca, pero por desgracia, está lejos de ser perfecto. Tiene unos cuantos fallos, aunque por suerte, algunos tienen solución:

El perfil de pantalla. La mayoría de MBA llevan pantallas LCD fabricadas por el LG. El perfil de colores es muy mejorable. Por suerte, tiene muy fácil solución. Y en minutos, la pantalla se vuelve a ver como debería verse.

El bug del apagado de pantalla. En los MBA de mid-2013, al apagar la pantalla, hay un breve periodo entre que se la pantalla se pone en negro hasta que se apaga por completo, incluida la retroiluminación del teclado. Si se toca el teclado o el trackpad antes de que se apague del todo (por ejemplo, justo antes de que la retroiluminación se apague), el ordenador se cuelga. Por el momento, no tiene solución.

El botón de encendido. Por defecto, el botón de encendido del MacBook Air apaga la pantalla y pone el ordenador en reposo. Eso no sería un problema si no fuese por dónde está situado. Para hacerlo peor, el bug anterior hace que la reacción por instinto (lanzar el reposo por accidente y querer interrumpirlo tocando el teclado) hace que se cuelgue del todo. Pero hay una solución: hacer que no se apague la pantalla al tocar el botón.

Lo primero, los riesgos. La solución supone lanzar a cada arranque un binario que analiza una aplicación en memoria y la altera, de tal forma que en lugar de iniciar la entrada en reposo, salte a la acción que muestra el diálogo de encendido. No se trata de algo especialmente peligroso, salvo por el hecho de que una actualización muy posiblemente lo deje inutilizado, o en el peor de los casos, el cambio en tiempo de ejecución que produce deje temporalmente inservible el sistema (algo altamente improbable). De ocurrir, habría que entrar en modo recovery y borrar el plist dentro de /Library/LaunchAgents/ para evitar que se ejecute.

Primero hay que descargar el código fuente aquí, para luego compilarlo y situarlo en la carpeta bin (o cualquier otra, realmente), y finalmente, hacer un plist que haga que se lance a cada arranque. Como recordatorio, hay que tener curl así como las herramientas para poder compilar (es muy fácil).

curl https://raw.github.com/binchewer/power_fixer/master/power_fixer/main.c > main.c
sudo su
gcc -o /usr/bin/power_fixer main.c
chmod +x /usr/bin/power_fixer
echo "ALL     ALL=(root)      NOPASSWD: /usr/bin/power_fixer" >> /etc/sudoers
mkdir -p /Library/LaunchAgents
curl https://gist.github.com/adrinavarro/8226124/raw/74202b0e5b2edd96dba65cbd00a34\
91f369994cb/gistfile1.xml > /Library/LaunchAgents/com.power_fixer.plist
launchctl load -w /Library/LaunchAgents/com.power_fixer.plist

Después de reiniciar, el botón de encendido debería mostrar el diálogo en lugar de apagar la pantalla. No olvides los riesgos, de todos modos.

Nota a junio de 2014: Al parecer alguna actualización de software ha solucionado dos de los tres problemas — todos, salvo el perfil de color, que por otra parte, no es un problema como tal. Hurra!

Con mi cámara

Sun, 17 Nov 2013 17:02:00 +0000

Poco antes de embarcar el vuelo LHR-NRT, entré a una tienda Boots para comprar cosas antes del vuelo. Había oferta de 2x1 en cámaras desechables, y una de ellas era la Kodak Ultra Compact.

Foto tomada de My Camera Cabinet

Es un experimento, más que nada. Con 19 años a mis espaldas, el carrete analógico es más un recuerdo vintage que una realidad. Y quería experimentar con una cámara desechable, con un botón y nada más: nada de ajustes de sensibilidad, tiempo de exposición, enfoque…

El resultado fue interesante:

De hecho, Luis al verlas comentó el aspecto "setentero" de las fotos — y cómo una sociedad como la japonesa puede confundirse en periodos a lo largo del tiempo. ¿No parece como viajar en el tiempo en algunas de las fotos?

El resto de las fotos de Tokyo en 35mm están en Flickr.

Decidí repetir el experimento este verano, al visitar algunas ciudades por Europa (Londres, Berlín y Munich). Y el resultado sigue siendo reseñable:

Una semana en Tokyo

Sun, 17 Nov 2013 14:11:00 +0000

Después de visitar Corea del Sur, me entró el gusanillo de ver más. Y es que las ofertas suelen ser tentadoras, y después de dejárselo caer a Jorge ya teníamos los billetes comprados. Realmente, el título es mentira —estuvimos 8 días y medio— y no sé por dónde empezar…

Lo primero, la sensación. La misma de siempre: the travel bug, pero esta vez, en su máximo exponente. La sensación de estar en un universo donde todo es distinto, y a la vez, reconfortantemente familiar. Y te invaden las ganas de conocerlo todo.

Y eso último aún persiste. En muchos otros casos, en unos días, se termina con la sensación de haber visto suficiente — saciedad turística. Nunca significa haberlo visto todo, porque hasta del lugar menos sospechado se pueden sacar decenas de cosas interesantes pendientes por ver… Pero Japón tiene algo. ¿Qué será?

Cabe mencionar que Tokyo no es especialmente interesante. Pero sí que es impresionante. Por sus contrastes: parques, bosques, centros comerciales, estaciones de tren, edificios enormes y pequeños templos. Por la cantidad de gente que hay. Por su infinita variedad.

En perspectiva, volar hasta Japón y visitar solamente Tokyo es mala idea. Teniendo el JR Pass y algunos vuelos baratos, es imprescindible visitar el resto del país: desde Naha (Okinawa) hasta Sapporo (Hokkaido), pasando por Nagasaki, Fukuoka, Hiroshima, Kyoto, Osaka, Nagoya y Nara. Y muchos lugares entre medias.

El viaje mereció la pena. Por las personas que allí conocimos, por lo que aprendimos, y también por las ganas de volver a visitar todo lo que nos quedó pendiente, que de cierto modo, es casi todo.

Esta vez, más que nunca: toca volver.

Un día en Busan

Tue, 14 May 2013 12:58:00 +0000

Sí, Seúl impresiona. Pero se parece más bien poco a Busan. Uno de los motivos es que, a diferencia de la capital, Busan no fue arrasada durante la Guerra de Corea. Otro es que tiene un puerto internacional, con bastante tráfico con Japón. Y, que, como Luis dice, se trata de una ciudad que rodea a las montañas.

No estuvimos más que unas pocas horas allí —de volver a Corea, intentaría pasar allí por lo menos un par de días—, con lo que nos limitamos a unas impresiones fugaces de todo lo que íbamos viendo. Quizás, lo primero, el desorden urbano: con mercados y comida donde no los esperas, templos impresionantes junto al mar, o bien una enorme torre sobre un monte al que se sube en escaleras mecánicas que salen de una estrechísima calle llena de grandes tiendas.

El resto del día se queda en anécdotas y curiosidades. Como por ejemplo, la cantidad de japoneses (¡y japonesas!) que hay, por los ferrys diarios que unen el puerto de Busan con Japón (Osaka, Fukuoka entre otros). O la playa, rodeada de grandes edificios. O bien, las calles estrechas con negocios y mercados de comida al aire libre donde podías encontrar cualquier cosa a un precio sospechoso.

Conociendo Seúl

Sun, 21 Apr 2013 17:00:00 +0000

Dicen que Seúl es la ciudad más tecnológicamente avanzada del mundo. Quizás no, o quizás compita con Tokyo por ese puesto (y pronto podré desempatar!). Es una ciudad con mucha historia, y a la vez, una ciudad muy reciente (arrasada por guerras en el último siglo), pero con muchas cosas que ver, conocer, e historia que aprender.

Como tal, tiene su dosis de historia en templos como Gyeongbokgung, Changdeokgung y otros palacios cuyo nombre no recuerdo por mucho que lo haya intentado. La entrada suele ser asequible e incluyen visita guiada gratuita en inglés (momento guiri) que está muy bien y es interesante — sobre todo para conocer el pasado dinástico de Corea, sus tradiciones históricas y los eternos roces con el imperio japonés.

Una de las cosas destacables es el contraste que los templos ofrecen. Por ejemplo, a la salida de Gyeongbokgung está la avenida Sejong-daero con edificios enormes, y cuando llegamos nosotros, un evento de celebración de la elección de la nueva presidenta. Pero eso no es nada si comparamos con Changdeokgung y Huwon (el "jardin secreto"). En una ciudad con 17,000 habitantes por kilómetro cuadrado hay un enorme jardín que merece la pena conocer por sus contrastes, harmonía e historia.

Siguiendo la línea histórica, hay muchísimas cosas que ver y conocer. Por ejemplo, Bukchon, un barrio con casas de estilo tradicional, y que nada tiene que ver con el estilo geométrico y moderno que hay en el centro de Seúl (que por cierto, impresiona).

También hay montones de templos, algunos más o menos interesantes y bonitos (recordemos la tradición budista en Corea). O el pequeño río que antes era una autopista y ahora el ahora fluye en sentido contrario… Witty.

Seúl es una ciudad de contrastes. Con enormes avenidas que a su vez tienen pequeñas calles comerciales. O famosas tiendas en coreano (en realidad, era por ser Insadong).

También vimos la N Seoul Tower, en el monte Namsan. La subida es impresionante, en un ¿telecabina? con vistas encima de todo Seúl, y el monte iluminado. Una vez arriba, no decepciona. Y las vistas desde el mirador en el interior de la torre, tampoco.

Las calles comerciales también son impresionantes. Y, en el caos ordenado de la ciudad, también llegamos a toparnos con mercados distintos. Otros lugares, también en el área de "mercados", eran un tanto sorprendentes. En medio de una frenética ciudad, gente de lo más normal comiendo bajo lonas en pequeños puestos improvisados. Y todo era delicioso.

Aún dejándome muchas cosas en el tintero, no puedo dejar tampoco sin destacar el área de Gangnam (ya… la famosa canción…). Supongo que de noche impresiona más que de costumbre. Allí es donde están basadas las grandes (y millonarias) empresas, donde está el ocio nocturno (también en Hongdae), y es el súmmum de la modernidad.

En general, Seúl es impresionante. Y eso contrasta con Busan, que me pareció más relajado y menos puntero que Seúl. Quizás porque tiene sol y playa, o porque es más pequeño…

Corea del Sur

Wed, 13 Mar 2013 17:15:00 +0000

En un giro de los acontecimientos, fui a Corea del Sur a finales de Febrero. Esos diez días fuera de casa dan para varios posts — así que empecemos.

El vuelo con British Airways vía Londres-Heathrow costó 550€, ida y vuelta. Era una oferta, además, solo presente unos días de la semana, pero con la huelga de Iberia tuvimos que cambiar ligeramente las fechas —aunque diría que hasta a mejor—.

Llegamos a Incheon, un aeropuerto enorme, después de doce horas de vuelo —y yo sin dormir— y habiendo tenido el primer vuelo a Heathrow a las 06h45.

Usamos el AREX para llegar hasta Seúl. No el Express, si no la versión "lenta" con paradas por el camino. Es muy asequible y tarda aproximadamente una hora. Se puede comprar un billete sencillo en unas máquinas, que con algo de manoseo puede llegar a hablar en inglés. El tren llega a Seoul Station, que es la estación central de Seúl donde también salen los trenes de alta velocidad, bajo la denominación comercial de KTX y operados por Korail.

Para usar el transporte allí, existe la tarjeta T-money: son tarjetas monedero que sirven a lo largo de Corea del Sur. Para pagar en taxis, algunas tiendas o pasar los tornos del metro o autobús. Especialmente útil para nosotros dado que funciona también fuera de Seúl. Estas tarjetas se venden en las convenience store, "tiendas 24h", y se pueden usar y recargar también en estas tiendas. En total no llegamos a usar más de 26 000 Won (menos de 20€) en metro y autobús durante los siete días que la usamos (entre Seúl y Busan).

Además de Seúl, también pasamos un día Busan. Es una ciudad al sur de Corea del Sur, muy cerca de Fukuoka por mar, y a unos 350 km de Seúl. En KTX, el viaje tarda algo menos de 3 horas, y merece mucho la pena. De volver, pasaría al menos una noche allí.

Para el KTX, usamos el KR PASS —únicamente disponible para extranjeros—, que se debe comprar online y pagar con tarjeta. Es necesario disponer del pasaporte y del número de reserva que da la web de Korail (ojo, no manda correo electrónico de confirmación).

El precio del KR PASS para un solo día fue de 47 700 Won (unos 35€). Es muy asequible, y tiene viajes ilimitados en un día. Interesante, también, por si llegásemos a perder cualquier tren: se puede usar el pase para reservar otro después.

En cuanto a dinero, utilicé una MasterCard de débito de EVO y retiré dinero una vez llegamos a Incheon. Para el viaje abrí una cuenta en este banco —tertulia económica a parte— y utilicé únicamente esa tarjeta para retirar dinero de cajeros y hacer pagos tal como el KR PASS, y así llevar mejor contabilidad de los gastos.

La tarjeta es muy interesante puesto que permite hasta cuatro retiradas al mes sin comisiones astronómicas por ser en el extranjero, y en el resto de casos, las comisiones son muy razonables. Únicamente hay una pequeña comisión (menos de 1%) en la tasa de cambio de MasterCard. No como en mi otro banco…

De todos modos, en Incheon, el cambio de ventanilla en efectivo era muy favorable y bastante cercano al del mercado (¿habremos tenido mucha suerte?). La diferencia entre la tarjeta y llevar efectivo era muy pequeña. Nada que ver con el cambio absurdo que nos ofrecían en Heathrow (casi 80€ de comisión en Londres vs. menos de 8€ en ventanilla ya en Corea — comparando con la tasa de mercado del momento).

Al llegar saqué 500 000 KRW (unos 352€ al cambio cuando los saqué) para los ocho días, a los que se suman los menos de 65 000 KRW (al cambio, 46€) en gastos eventuales en los que no usé la tarjeta (compras en aeropuertos, KR PASS). De ese medio millón de wones, aún sobró algo de dinero en efectivo —unos 30€ al cambio del aeropuerto— después de gastar una parte importante los últimos días en souvenirs y distintos regalos con un interesante sobreprecio, por nuestra condición de turistas.

En general, los gastos allí fueron muy bajos. Se puede comer por un precio entre 5000 KRW y 9000 KRW, y aún menos si sabes defenderte en Coreano… o si te acompaña alguien que sepa. Hay lugares en los mercados o pequeños locales donde algunos platos de comida coreana como el Gimbap pueden costar 2000 KRW.

Y si no, siempre quedará McDonalds o LOTTERIA… Pero francamente: no merecen la pena. Bueno, sí que puede ser interesante probar la hamburguesa de bulgogi del McDonalds y echarle un vistazo al menú de su equivalente asiático, LOTTERIA, una rama más del gigante LOTTE. Pero la gastronomía coreana es exótica a la vez que interesante y saludable, y para tan pocos días allí no hay nada mejor que aprovecharlos y probar lo tradicionalmente coreano. ¡Y además es barato!

Lo mejor para moverse en Corea es el transporte público. Después del "shock" inicial al ver el mapa de la red de metro de Seúl, se hace muy fácil de usar. Las salidas están escrupulosamente numeradas y la señalización en los trenes y en la red es muy buena, con algunas señales en Inglés. Por suerte para los occidentales perdidos como nosotros…

También hay que tener en cuenta el taxi. Creo que la carrera más cara que llegamos a pagar no llegó a 7 000 KRW (¡menos de 5€!). Los taxistas apenas entienden inglés pero tienen coches bastante modernos y con unos GPS que dan envidia. No tanta envidia da la forma que tienen de conducir en ese país. Dan ganas de besar el suelo cuando uno baja del taxi o autobús. Pero sin duda echaré de menos poder coger un taxi sin tener que pensar antes en qué órgano puedo prescindir.

Una cosa a tener en cuenta es el tiempo. Bueno, realmente, eso solo nos pasa a nosotros. A finales de Febrero hacía frío, unos días más que otros. Pero para los días que sí que hizo bajo cero y con viento, estabamos adecuadamente equipados: mallas térmicas, camisetas térmicas, calcetines térmicos (¿notáis un patrón?), así como forros polares, buen abrigo y calzado (no cometáis el error de olvidar esto último, así, como consejo personal). Y que no falte el cuello polar o braga para aguantar el aire frío. Creo que con tanto abrigo podría quedarme dormido en la calle y ser el tipo más feliz del mundo.

Para el alojamiento, elegimos un hostal bastante nuevo, el Khaosan Insadong. Dadas las fechas en las que reservamos, con poca gente y mucho frío, y costó menos de 240 000 KRW (¡menos de 170€!) para dos personas. Además, nos llevamos un upgrade de regalo dada la poca gente que había en el hostal en esa época. Mejor, imposible. Está a pocos pasos de una estación de metro muy grande, 종로3가 (Jongno sam-ga).

Nos sorprendió nada más llegar donde estaba el hostal. Salimos del metro en una avenida muy ancha —realmente, como casi todo en el resto de la ciudad— con inmensas aceras y varios carriles de circulación por sentido. Y nuestro hostal estaba en un pequeño callejón sin nombre…

Pasada la impresión del primer momento, no pudimos estar mejor. Y como llegamos a decir al irnos… Ese callejón chungo y con pescado frito para aburrir no tiene nada que envidiar en seguridad y tranquilidad a las calles más seguras de nuestra capital.

Y es que realmente, conocer Corea del Sur ha sido una gran experiencia… y todo apunta a que es sólo la primera de muchas.

Música en Android usando rsync sobre SSH

Thu, 10 Jan 2013 09:00:00 +0000

He caído. Me he pasado a Android. Y una de las necesidades que me han surgido ha sido la de sincronizar mi librería de música de alguna forma.

El primer intento ha sido Spotify y la suscripción que uso normalmente… y no funciona demasiado bien en Android: con librerías grandes es lento y pesado, y no me interesa mezclar mis librerías de Spotify y "clásicas".

El siguiente intento ha sido Google Play Music: éste soporta streaming y caché local a través de Play Music (servicio gratuito de Google), pero requiere cargar antes al servicio la librería. Y después de varios días para subir más de 20 GB desde el ordenador, y de esperar para que se sincronizase de nuevo al móvil (pinning), ha empezado a dar fallos, como archivos que desaparecen de la caché.

Existe otra opción: copiarla a una SD (en mi caso, una de 32 GB, que además son muy baratas), y usar Apollo o Play Music mismamente para reproducir música.

Aquí es donde entra en juego rsync. Sincronizar tantos gigas de música, que además va cambiando, es de todo menos divertido.

Lo primero pasa por instalar un cliente SSH en el móvil previamente rooteado, como dropbeard, que es gratuito. Después de añadir la clave (en OSX o Linux basta con generarla usando ssh-keygen) y copiarla al móvil para seleccionarlo desde Dropbear).

Después, y ya mediante SSH, hay que instalar el binario de rsync. Se puede descargar aquí y una vez copiado a la SD sólo queda copiarlo a /system/xbin/. Como está protegido, hay que volver a montar el volumen en read-write de la siguiente manera (y vuelta atrás en read-only):

root@android:/system/xbin# busybox mount -o remount,rw /system
root@android:/system/xbin# cp /sdcard/rsync /system/xbin/
root@android:/system/xbin# busybox mount -o remount,ro /system

Después de eso, sólo queda crear una carpeta en la SD para guardar la música y lanzar el proceso de rsync desde nuestro ordenador. En mi caso, he usado el siguiente comando:

$ rsync -e ssh -rltP --delete --exclude=".*" \
             /Users/Adrian/Music/MusicLibrary/ root@192.168.0.100:/sdcard/Music/

La explicación es sencilla. Por una parte, se ejecuta por SSH según los parámetros estándar (si no, se especificaría el puerto por ejemplo, pasándolo en el parámetro -e).

Hace una copia recursiva (-r, carpetas y sus contenidos), conservando enlaces (-l) y marcas de tiempo (-t, casi imprescindible para agilizar futuras sincronizaciones). Además, muestra progreso.

También suprime los archivos remotos que no concuerden con lo local (convirtiendo la carpeta de la SD en un "espejo" de lo que tenemos en local) y excluye archivos ocultos de la sincronización (los puñeteros .DS_Store, por ejemplo).

Ya sólo queda sincronizar todo. Puede tardar, pero teniendo control sobre el proceso al menos no ocurrirán las desgracias que ocurren con otros sistemas, y siempre mantenemos control sobre nuestros datos. Si se da el caso de que la música no aparece en las distintas aplicaciones, desmontar la SD y volverla a montar desde las preferencias es suficiente para que se "refresquen".

Además, se puede guardar el comando de rsync en el fichero .bash_profile en forma de alias, para que de esta forma baste con ejecutar un comando (p.ej, "sync") en la terminal para que se sincronice. Muy útil si el móvil siempre conserva la misma IP y se sincroniza siempre en el mismo entorno.