Juan P. Schwindt

Arduino al rescate de una balanza

2016-08-27T00:00:00+00:00

Motivación

Al igual que la Pava eléctrica, la balanza de cocina dejó de funcionar al poco tiempo de uso, simplemente encendía y quedaba siempre en cero. La desarmé para ver si se podía hacer algo, pero a simple vista no había nada que pareciera estar mal, y como se trataba de un típico chip-on-board las chances de repararla eran nulas.

De los elementos que formaban la balanza, lo único que podía ser útil era el sensor de peso o “strain gauge”, así que me propuse diseñar una balanza nueva.

El sensor de peso

Resulta que el sensor de peso de 5 Kg que traía la balanza es bastante común y existe un módulo basado en el chip HX711 que hace de amplificador de la tensión diferencial que se genera en el puente de Wheatstone y además convierten de analógico a digital. La forma de conectarlo es la siguiente:

También, gracias a la magia del código abierto, existe un módulo de software para Arduino para comunicarse con el HX711 y leer el dato del peso.

Arduino Pro Mini y el display

Para este proyecto necesitaba muchas puertas de I/O: 11 salidas para manejar los 4 dígitos del display de 7 segmentos que muestra el peso, 2 para clock y datos del HX711 y una entrada leer la tecla de puesta a cero (tara). Al mismo tiempo tenía que ser lo suficientemente pequeño para caber dentro del gabinete de la balanza. Para esto el Arduino Pro Mini resultó no sólo ser barato (no tiene la interfaz serie ni la fuente de alimentación del Arduino Uno), sino que también tiene la separación de pines que calza exactamente con los del cuádruple display de 7 segmentos, con lo cual el montaje quedó super compacto:

En cuanto al manejo del display usé una idea sencilla que permite ahorrar componentes: tradicionalmente se suele poner un transistor, con su resistencia en la base) por cada dígito de manera de soportar la corriente de los 7 segmentos del dígito, y 7 resistencias más, una por cada segmento, para limitar la corriente de cada led. Pero si resignamos un poco de luminosidad y encendemos de a un segmento por vez y un display por vez, sólo necesitamos 4 resistencias, una por cada display ánodo común, ya que cada salida del controlador puede manejar la corriente necesaria para un led, lo cual simplifica mucho el conexionado.

Así quedó el circuito:

La alimentación del circuito se realiza mediante una fuente externa de 5V, que puede provenir de un simple cargador de celular, para lo cual le puse un conector micro-usb montada al gabinete. Así quedó todo dentro de la Arduino-balanza:

Software

El soft es una clásica aplicación Arduino son su setup() y loop(), aunque decidí usar una interrupción de timer para el multiplexado de los segmentos y dígitos. No conocía mucho del manejo de los registros de los timers del microcontrolador, pero encontré un buen artículo en www.instructables.com con todo lo que necesitaba. La interrición de tiempo se genera cada 512 microsegundos y en ella lo que se hace es apagar el segmento que estaba encendido, calcular cuál es el próximo segmento y encenderlo, para lo cual hay que poner HIGH en el ánodo del display correspondiente y LOW en el segmento. El ciclo completo dura 28 * 0.512 = 14 milisegundos, lo que da una buena frecuencia de refresco.

El código lo publiqué en Github: código fuente de la balanza.

La balanza terminada y funcionando:

Pava digital para mate

2016-07-02T00:00:00+00:00

Motivación

Compré una pava eléctrica con control de temperatura para el agua del mate, pero al poco tiempo el termostato de 85ºC se rompió y no hubo forma de conseguir el repuesto. La molestia de estar siempre atento a que el agua no hierva hizo que el problema se convirtiera rápidamente en una oportunidad para jugar con Arduino en un proyecto concreto de “digitalizar” la pava.

El sensor de temperatura

La primera idea fue usar el LM335 ya que tenía uno a mano. Este sensor entrega 10mV por ºK, es decir que para el rango de 10 a 90ºC del agua, la tensión que entrega es de 2,83 a 3,63V, es decir menos de 1V de variación, y como la idea es utilizar el ADC del Arduino, que mide de 0 a 5V, se desperdiciaría el 80% del rango de conversión. Otro problema es que al tener un encapsulado plástico, el contacto térmico y la inercia térmica complicaban el control.

Finalmente me sugirieron utilizar un NTC 100K a 25ºC con encapsulado en vidrio, que se usa en las impresoras 3D y es muy barato. Con esto es muy fácil regular el rango de tensión cambiando la resistencia del divisor, la que quedó en 22K. La respuesta del divisor de tensión no es lineal (ver tabla de resistencia del NTC), pero para el uso como termostato eso no es importante.

Así quedó el termistor dentro del espacio del viejo termostato:

El circuito y el armado con el ATtiny85

El circuito definitivo es muy sencillo ya que el microcontrolador no necesita ningún componente externo para funcionar:

Esta es la plaquetita terminada:

La fuente de alimentación tenía que ser pequeña para que entrara en la base de la pava eléctrica, así que lo más fácil fue usar un cargador de celular sin su encapsulado plástico.

Y todo montado en la base de la pava:

Software

El soft es muy sencillo, pero como hay que tener en cuenta la inercia térmica de la pava y del sensor, fue necesario hacer una pequeña máquina de estado. El funcionamiento es el siguiente: primero calienta el agua hasta alcanzar aproximadamente los 60ºC. A partir de ahí comienzan ciclos de 10 segundos de espera (para que se estabilice la medición de temperatura), y 7 segundos de calentamiento. Cuando se llega a los 85ºC buscados, se apaga la resistencia y se pasa a un estado de espera hasta que la temperatura pasa por debajo de los 80ºC, donde vuelve a empezar el ciclo.

El LED se utiliza para saber en qué parte del ciclo se encuentra: si está encendido en forma permanente significa que el agua se encuentra lista para preparar el mate. Si estamos en el proceso de calentamiento, el LED titila con una velocidad variable y se acelera a medida que nos acercamos a los 85ºC. El código lo publiqué en Github: código fuente de la pava.

Durante el desarrollo usé un Arduino Uno ya que de esa forma podía usar la interfaz serie para enviar mensajes de debug y de esa forma acelerar el proceso. Luego, cuando llegó el momento de programar definitivamente el ATtiny85, seguí las instrucciones de estos tutoriales Video: How to make a DIY ATtiny Programmer y Programming an ATtiny w/ Arduino 1.6.

La pava “electrónica” terminada:

Balanceador de carga para HTTPS (SSL/TLS) con HAProxy

2013-10-08T00:00:00+00:00

Intro

Cuando se trata de balancear la carga HTTP me gusta utilizar HAProxy ya que es muy liviano y flexible para configurar. Pero hace unos días tuvimos la necesidad de balancear HTTPS para una aplicación de Facebook desarrollada en RoR y es por eso que me puse a investigar cómo hacerlo. En este artículo les cuento primero cómo obtener un certificado válido de SSL/TLS en forma gratuita y luego cómo configurar el HAProxy para que use dicho certificado.

Certificado SSL/TLS gratuito

Actualización 2016: Hoy en día conviene utilizar Let’s Encrypt.

El sitio StartSSL emite certificados SSL/TLS legítimos y gratuitos (clase 1), pero el proceso para poder utilizarlos correctamente en el servidor web o en el balanceador de carga tiene sus vueltas y me llevó un tiempo hasta que logré hacerlo funcionar correctamente.

Primero hay que registrarse en el sitio e instalar un certificado en el navegador. Ese certificado es el que nos permite luego ingresar al panel de control y gestionar todo lo necesario para obtener el certificado final. Una vez adentro, los pasos son los siguientes:

Ir a Validations Wizard y elegir Domain Name Validation. Este procedimiento manda un mail a alguna de las cuentas del administrador del dominio con un código de validación, que luego debe cargarse en el formulario correspondiente.
Una vez validado el dominio se debe generar una clave privada y luego el certificado. Para esto utilizar el Certificates Wizard con la opción Web Server SSL/TLS Certificate. Utilizar los valores default de Keysize y Secure Hash Algorithm para asegurarse la compatibilidad con navegadores viejos. Luego guardar la clave privada (como ssl.key, por ejemplo) y el certificado (como ssl.crt, por ejemplo).
Luego conviene eliminar el password de la clave privada para que no haga falta ingresarla cada vez que levante o reinicie el servidor web o el HAProxy. Esto se puede hacer de 2 formas: utilizando la opción Decrypt Private Key del Tool Box o mediante openssl en línea de comando:

openssl rsa -in ssl.key -out ssl.nokey
Este último paso es importante y corresponde al armado del archivo final que se va a utilizar en el servidor. Para esto es necesario descargar previamente 2 archivos desde el Tool Box opción StartCom CA Certificates: StartCom Root CA (PEM encoded) y Class 1 Intermediate Server CA y concatenarlos todo en un único archivo:

cat ssl.crt ssl.nokey sub.class1.server.ca.pem ca.pem » ssl.full.crt

El archivo ssl.full.crt es el que utilizaremos en HAProxy según se explica en el apartado siguiente.

HAProxy con SSL/TLS

Una gran ventaja de tener a HAProxy como punto de terminación de las conexiones SSL/TLS es que simplifica la configuración de los backend ya que la conexión hacia adentro se realiza por HTTP como siempre, y el único punto de configuración HTTPS resulta ser el proxy. Por otro lado eso también nos permite apuntar el proxy hacia diferentes aplicaciones de múltiples backends y todas compartiendo el mismo certificado.

Para utilizar HAProxy con HTTPS en necesario instalar la versión de desarrollo ya que el soporte para SSL/TLS recién comenzó a partir de la 1.5-dev12, pero ya tuvo varias revisiones y la versión actual (1.5-dev19) es muy estable y no tuve problemas en producción.

La instalación es muy sencilla y pueden ver los pasos necesarios para Debian/Ubuntu en http://dylancopeland.com/posts/setting-up-and-configuring-haproxy.

En cuanto a la configuración, la directiva para habilitar el proxy de HTTPS se realiza mediante bind en donde se especifican los datos necesarios, por ejemplo:

frontend web
  bind 0.0.0.0:80
  bind 0.0.0.0:443 ssl crt /etc/haproxy/certs/ssl.full.crt

donde ssl.full.crt es el certificado que armamos en el apartado anterior. El resto de las directivas son las usuales para este tipo de utilización. Aquí se puede ver un ejemplo completo de la configuración: https://gist.github.com/jschwindt/6902596

Finalmente, una vez que el HAProxy está corriendo es importante probar que toda la cadena de certificados y la compatibilidad con los distintos navegadores esté funcionando correctamente. Para eso hay varias herramientas online, por ejemplo: http://www.sslshopper.com/ssl-checker.html. Un problema que tuve durante las pruebas es que con Firefox aparecía un error de certificados y eso se debía a que dentro del certificado final faltaba el de la autoridad certificante intermedia, cosa que no se manifestaba con el resto de los navegadores.

Conclusión

Dio un poco de trabajo y la información estaba un poco dispersa, pero es perfectamente posible utilizar HTTPS sin invertir dinero en comprar un certificado y utilizando las herramientas de código abierto existentes.

Redis Cluster con Ruby

2013-08-22T00:00:00+00:00

Intro

En Comenta.Tv procesamos gran cantidad de tweets, que obtenemos a partir de la API de streaming de Twitter, y generamos estadísticas y reportes en tiempo real.

Para lograr escalar a cientos de mensajes por segundo y para poder generar los reportes con tiempos de respuesta rápidos, nos valemos principalmente de Redis, que demostró ser una herramienta ideal para logar nuestra meta.

El “problema” de Redis (y también su virtud) es que toda la base de datos tiene que caber en la memoria RAM, y rápidamente esto se convierte en un recurso escaso. La solución ideal sería disponer ya de Redis Cluster, pero como todavía no está disponible hubo que encarar una solución más casera para particionar el contenido en distintos servidores.

Redis::Distributed

Según la documentación de Redis, hay distintas opciones para particionar los datos en múltiples servidores y una de las opciones es utilizar directamente el cliente de Redis en Ruby utilizando la opción “distributed”.

La documentación para utilizar Redis::Distributed es casi nula y encontré pocos ejemplos y demasiado básicos como para tomarlos en serio. Luego de cometer algunos errores que me llevaron a andar moviendo millones de claves de un servidor a otro, decidí escribir este post para tratar de evitar que otros pasen por lo mismo.

¿Cómo funciona?

Normalmente para utilizar Redis desde Ruby con un sólo servidor hacemos algo así:

client = Redis.new('redis://127.0.0.1:6379/0')

client.set "clave1", "Hello!"        # "OK"
client.get "clave1"                  # "Hello!"
client.del "clave1"                  # 1

Cuando utilizamos Redis::Distributed el uso es similar, pero el cliente se inicializa con un array de servidores Redis en lugar de un único servidor:

REDIS_ARRAY = [ 'redis://127.0.0.1:6379/0', 'redis://127.0.0.1:6380/0' ]

client = Redis::Distributed.new(REDIS_ARRAY)
client.set "clave1", "Hello!"        # "OK"
client.get "clave1"                  # "Hello!"

Como vemos ahora tenemos múltiples server, pero el funcionamiento del los comandos es similar. Ahora el servidor de destino se elige en base al valor de la clave:

client.node_for "clave1"             # <Redis client v3.0.4 for redis://127.0.0.1:6379/0>
client.node_for "clave2"             # <Redis client v3.0.4 for redis://127.0.0.1:6380/0>

Limitaciones

Múltiples claves

El hecho de que cada clave se encuentre en un servidor distinto impone algunas limitaciones, por ejemplo: todas las operaciones que impliquen múltiples claves no son posibles:

client = Redis::Distributed.new(REDIS_ARRAY)

client.mset("clave1", "val1", "clave2", "val2")
  >> Redis::Distributed::CannotDistribute: Redis::Distributed::CannotDistribute

Esto no significó un problema para nosotros porque no utilizamos ninguna de dichas operaciones ya que todo lo realizamos en base a claves independientes.

Agregar servidores

Una vez que uno tiene el cluster de servidores funcionando y con contenido, no es posible agregar un nuevo servidor al array porque eso alteraría automáticamente la distribución de claves y las ya existentes quedaría inaccesibles.

Entonces, ¿cómo hacer cuando nos volvemos a quedar sin memoria? La primera opción sería agregar memoria a los servidores actuales, pero esto no siempre es posible.

La solución sugerida es que en el armado del cluster tengamos la previsión de tener muchos servidores Redis corriendo, aunque inicialmente todos los procesos pueden estar en el mismo servidor físico y a medida que necesitamos, vamos migrando el contenido a nuevos servidores físicos. La cantidad de servidores no debemos cambiarla nunca y no hay que tener miedo de tener muchos servidores Redis corriendo en el mismo server físico ya que la utilización de memoria y CPU es muy baja.

Armado del cluster

Identificar los servidores por ID

En los ejemplos que había visto con Redis::Distributed la inicialización se realizaba siempre especificando un array de urls de redis, tal como se ven en los ejemplos anteriores, pero para mi sorpresa la distribución de claves no se realiza en base a la posición del servidor dentro del array sino en base a su ID, que por defecto es la url del servidor. Por lo tanto, si cambiamos la IP o el puerto de un servidor redis, ¡la distribución de claves cambia!

La solución es especificar el array de servidores de la siguiente forma:

REDIS_ARRAY = [
  { id:  'redis_0',
    url: "redis://127.0.0.1:6379/0",
  },
  { id:  'redis_1',
    url: "redis://127.0.0.1:6380/0",
  },
  #
  # more servers
  #
  { id:  'redis_n',
    url: "redis://127.0.0.1:63xx/0",
  },
]

De esta forma, cuando agregamos un nuevo servidor físico para aumentar la capacidad del cluster, lo único que tenemos que hacer es replicar la base de datos de Redis y luego cambiar sólo la url correspondiente en el REDIS_ARRAY.

Script de arranque para Ubuntu 12.04

Para simplificar el arranque y detención de los múltiples servidores Redis que corren en el mismo servidor físico, modifiqué el script alojado en /etc/init.d/ para agregar fácilmente múltiples servidores en distintos puertos. En el siguiente gist se puede ver el archivo /etc/init.d/redis-__port__ que sirve de base para crear los servidores.

Una vez que tenemos dicho archivo en /etc/init.d/ y con los permisos de ejecución correspondientes, lo único que hace falta hacer es crear links simbólicos cuyo nombre tiene que contener el port en el que queremos que el servidor Redis esté escuchando:

cd /etc/init.d/

ln -s redis-__port__ redis-6380
ln -s redis-__port__ redis-6381
ln -s redis-__port__ redis-6382
ln -s redis-__port__ redis-6383

update-rc.d redis-6380 defaults
update-rc.d redis-6381 defaults
update-rc.d redis-6382 defaults
update-rc.d redis-6383 defaults

También es necesario tener el archivo /etc/redis/_common.conf que contiene toda la configuración común a todas las instancias. Opcionalmente también se pueden especificar configuraciones particulares a cada instancia creando el archivo correspondiente en /etc/redis/_\[port\].

Al arrancar un servidor, por ejemplo con:

/etc/init.d/redis-6380 start

el script se encarga de crear la configuración correspondiente en /etc/redis/redis-6380.conf y luego arrancar la instancia con dicha configuración, que como ejemplo va a tener el siguiente contenido:

port 6380
pidfile /var/run/redis/redis-6380.pid
logfile /var/log/redis/redis-6380.log
dbfilename dump-6380.rdb
include /etc/redis/_common.conf

Si además detecta que existe el archivo /etc/redis/_6380.conf, la configuración tendrá además incluido dicho archivo antes del _common.conf.

Migración de claves

TODO