Raspberry Pi: ¿qué temperatura hace en mi casa?

Estaba dudando si este sería el lugar adecuado para poner estas cosas o si debería crear otra bitácora. Visto mi ritmo de trabajo (lento), creo que será más razonable ponerlo aquí e ir contando las cosas que haga, si es que tengo tiempo de hacerlas (y luego de explicarlas).

Vamos a hablar de un mini-proyecto que consiste en tener una Raspberry Pi conectada a la WiFi de casa y cómo controlarla desde el exterior (el trabajo, con un móvil, …) y aprovechar sus prestaciones.

Para ello, he estado preparando un pequeño montaje que tiene un sensor de temperatura, y además es capaz de hacer un par de cosas (pequeñas) más.

Para la parte del sensor seguí el tutorial que publicó Pablo Murillo en Tutorial Arduino # 0005 – Sensor de temperatura NTC:

En este proyecto vamos a aprender a implementar un sensor de temperatura a nuestros proyectos Arduino, en este proyecto simularemos cinco estados de aviso de exceso de temperatura, sobre los cuales los cuales podríamos conectar cualquier elemento que quisiéramos que actuara llegado dicho nivel, podríamos conectar circuitos de ventilación de manera que si no consiguieran mitigar el exceso de calor llegara un punto que desconectara el sistema que estemos monitorizando, en resumen, en cualquier lugar donde un control de exceso de temperatura sea necesario.

Como no tenemos un Arduino, sino que tenemos una Raspberry Pi, necesitamos algo que sirva para hablar con los sensores analógicos. En mi caso (por cercanía física y también por simpatía con el proyecto) lo que he utilizado es el Raspberry Pi to Arduino shields connection bridge de la gente de Cooking Hacks.
Con la biblioteca que proporcionan ellos, podemos utilizar las ideas (y los programas, casi tal cual) de los proyectos de Arduino en nuestra ‘raspi’ con bastante facilidad. Sirven los mismos esquemas de conexiones y todos los documentos disponibles para esta plataforma.

Una imagen del montaje:

.

Y un vídeo de la ‘cosa’ en acción.

Se pueden ver algunos elementos más (hay un sensor de luz que se ve a la derecha del de temperatura), pero básicamente allí está el proyecto propuesto por Pablo Murillo.

Aunque el tema de los LEDs es bastante llamativo (a mi me lo parece, siendo una persona más de programas que de cacharros) lo que más me atrae del cacharrito es que se trata de un ordenador completo.
Uno no se siente a gusto si no mete internet por enmedio y algo de interacción con el aparato.

Buscando un poco por ahí encontré el proyecto SleekXMPP que nos permitiría interactuar con nuestro ordenadorcito a través del protocolo XMPP. Este protocolo nos permite comunicarnos en tiempo real y ha sido utlizado, entre otras cosas, por algunos sistemas de mensajería instantánea (por ejemplo el GTalk de Google -aunque últimamente parece que podrían estar pensando en cambiar-, Jabber, …).

En los ejemplos del proyecto hay un ‘bot’ que repite las instrucciones que le envíamos y programé una modificación para poder preguntarle a la raspi sobre la temperatura de la habitación en la que se encontraba.

Podemos ver la interacción en este vídeo:

Pero el bot de ejemplo no está pensado para este tipo de comportamiento y necesitábamos alguna arquitectura que hiciera sencillo extender el proyecto, añadirle instrucciones e interactuar remotamente (¿la meta podría ser poder añadirle instrucciones por GTalk?) así que me puse a buscar.

El amigo Javier Candeira me sugirió probar phenny, que es un bot extensible, diseñado para recibir instrucciones remotamente y con solo una diferencia con mi proyecto inicial: está pensado para ser controlado desde una canal de IRC.

El proyecto se convierte (por ahora) en un bot de IRC que es capaz de proporcionarme información del entorno de la raspi que tengo en una estantería de mi casa.

Como primer paso, modifiqué el programa que había generado a partir del tutorial de Arduteka.
En lugar de encender más o menos luces, lo que quería era saber la temperatura así que lo que hace el programita es (además de encender las luces si se dan las condiciones adecuadas), escribir en la salida estándar el mensaje:

Temperatura:

seguido de la temperatura que se haya medido.
Para eso se toman medidas 5 veces con una separación de 0.5 segundos y después se calcula la media.

El código puede verse (y descargarse) en temperatura.cpp y se compila y ejecuta de la misma forma que en el tutorial antes referido.

Para invocar remotamente este programa entra en juego phenny.
Lo primero que hay que hacer es ejecutarlo, se generará un fichero de configuración (en ~/.phenny/default.py) que hay que editar para ponerle nuestro servidor de IRC favorito, canal y algunas cosillas más y ya lo tenemos listo para funcionar.
Por defecto viene ya con un buen montón de instrucciones que podemos probar.

Pero el proyecto sigue. Queremos añadir nuestras propias instrucciones y las elegidas han sido de momento tres:

  • .temp: devuelve la temperatura que mide en ese momento el sensor instalado.
  • .ip: devuelve la ip (interna) de la raspi, que se conecta a internet a través de un router WiFi hogareño normal y corriente.
  • .ls: devuelve un listado de ficheros del directorio actual donde se haya ejecutado phenny.

El código de esta parte puede verse (y descargarse) de: testing.py y copio aquí un trozo de código de la primera de esas tres acciones para que cada uno se haga idea de lo fácil (o difícil) que es prepararlo.

def temp(phenny, input):
   arg='sudo /home/pi/usr/src/pruebas/temperatura'
   p=subprocess.Popen(arg,shell=True,stdout=subprocess.PIPE)
   data = p.communicate()
   split_data = data[0].split()
   tempC = split_data[0]
   my_ip = 'La temperatura es %s' % tempC

   phenny.say(input.nick + '!' + ' ' + my_ip)
temp.priority = 'high'
temp.commands = ['temp']

También puede verse en Código para llamar al programa que nos dice la temperatura.

Como puede verse, invocamos al programa (lo he puesto con el path completo) lanzando un proceso con Popen.
Le pedimos el resultado, lo procesamos y creamos una cadena de caracteres my_ip que luego le pasamos al bot para que la escriba en el canal de IRC.

Nótese que phenny permite asignarle un nombre (o varios) a la instrucción (temp.commands = ['temp']) y también asignarle una prioridad, que hemos puesto en los tres casos como alta (‘high’).

Una vez hecho esto podemos volver a lanzar phenny (en realidad el bot puede cargar nuevas instrucciones de manera dinámica pero eso no importa ahora) y responderá a las instrucciones que ya ‘conocía’ y a estas tres que acabamos de añadir.

Podemos verlo en acción en:

Como decía arriba, el uso del canal de IRC ha sido un hito intermedio:

El objetivo ahora tiene varias líneas de avance:

  • Modificar phenny para que también acepte instrucciones desde un cliente
    de mensajería instantánea.
  • Añadir instrucciones a phenny (¿añadirle una webcam y poder ver una foto de la habitación desde nuestro teléfono móvil?, ¿descargar un documento cuya dirección le pasemos? ¿avisarnos si la temperatura alcanza determinados umbrales? …).
  • Añadir/utilizar capacidades de administración para que algunas instrucciones sólo puedan ejecutarse por personas autorizadas

Trataremos de seguir informando.
Si alguien ve mejoras a lo que ya hay publicado (las bondades del código existente son debidas a sus respectivos autores; los defectos me corresponden a mi) o necesita alguna aclaración no tiene más que decirlo.
También si alguien conoce otros proyectos que se puedan utilizar de forma similar o de los que obtener inspiración.

Datos sensibles en nuestros programas

Un sistema informático moderno es una pesadilla desde el punto de vista de dónde están realmente nuestros datos (cachés, swaps, páginas, memorias, discos …). Por eso conviene recordarlo: de cara a que nuestros datos sensibles estén el menor tiempo posible por ahí en claro; y también por tratar de evitar mediante las facilidades que tengamos disponibles que esos datos terminen escritos donde no conventa. De eso hablaban en

Añadir una instrucción a Python

Conocer como funciona un compilador es una buena idea para cualquiera que tenga que ver con la informática.
Este artículo no va de eso, pero da algunas pistas de las interioridades de un lenguaje que es bien interesante, Python: Python internals: adding a new statement to Python.

This article doesn’t attempt to suggest the addition of an until statement to Python. Although I think such a statement would make some code clearer, and this article displays how easy it is to add, I completely respect Python’s philosophy of minimalism. All I’m trying to do here, really, is gain some insight into the inner workings of Python.

Copiar y pegar código no siempre es malo

Un artículo sobre copia/pega de código que tenía por ahí guardado: [PDF] “Cloning considered harmful” considered harmful: patterns of cloning in software.

Típicamente, cuando se copia y pega el código en un sistema se considera una mala práctica. Sin embargo, los autores consideran que hay que analizarlo mejor y ver cuando puede tener sentido y cuando no.

This paper describes several patterns of cloning that we have observed in our case studies and discusses the advantages and disadvantages associated with using them. We also examine through a case study the frequencies of these clones in two medium-sized open source software systems, the Apache web server and the Gnumeric spreadsheet application. In this study, we found that as many as 71% of the clones could be considered to have a positive impact on the maintainability of the software system.

Por ejemplo, podría aportar estabilidad en zonas ya probadas y que
funcinonan, mientras se experimenta en otras partes más novedosas:

There is no doubt that code cloning is sometimes an indication of sloppy design and in such cases should be considered to be a kind of development “bad smell” (Fowler et al. 1999). However, we have found that there are many instances where this is simply not the case. For example, cloning may be used to introduce experimental optimizations to core subsystems without negatively affecting the stability of the main code. Thus, a variety of concerns such as stability, code ownership, and design clarity need to be considered before any refactoring is attempted; a manager should try to understand the reason behind the duplication before deciding what action (if any) to take.
This paper introduces eleven cloning patterns that we have uncovered during
case studies on large software systems,…

Interesante.

El año de seguridad en Java

John Melton comenzó a principios de este año su serie sobre seguridad para Java. Aunque los ejemplos son con este lenguaje, lo cierto es que casi siempre la prsentación es suficientemente general como para aprender/recordar algunas cosas aunque Java no sea nuestro lenguaje favorito. Comenzó con Year Of Security for Java – Introduction y lleva hasta ahora más de cuarenta entradas, todas muy interesantes.

Por poner una pega, no hay un índice. La búsqueda por Java Security en el blog debería ayudar.

Considero su lectura muy recomendable para cualquier persona interesada en estos temas, como recordatorio, temas en los que no habíamos pensado tanto …

Actualización: la serie ha terminado y pueden verse todos los enlaces en

Year Of Security for Java – Conclusion and Links y también descargar un pdf con todo, tal y como se anuncia en Year of Security for Java – PDF

Algunas ideas sobre nombres en programas

Los nombres son importantes; sobre todo cuando tenemos que usarlos más veces después de hacer un programa. En On Naming se discuten algunas ideas y lo traigo aquí porque hacía tiempo que no veía mucha discusión sobre esto. Supongo que se da por hecho que hay que tener cuidado, pero nunca viene mal recordarlo.

Un desbordamiento de enteros y como no solucionarlo

En The blind leading the blind una historia interesante de un fallo de desbordamiento de enteros y los sucesivos pasos que se fueron dando para solucionarlo. Aunque los pasos no fueran correctos.

Interesante.

¿El código se toma vacaciones?

Una nota curiosa en Quality Coding Takes A Break For The Holidays. But Why? donde examinando código detectan que la calidad (desde el punto de vista de fallos de seguridad encontrados) tiene un pico (en sentido de encontrar más fallos) hacia los meses de octubre y noviembre:

For the time period I looked at (the last 24 months), January through September is relatively flat and in line with the average flaw density. Then, there is a big bump in flaw density in October and November. Things begin to settle down once we go into December. The jump in application flaws is easy enough to spot. But what could cause this? Some of it could be seasonal. Maybe the build up to Thanksgiving has developers distracted? Are developers adjusting after the Summer break when “the living is easy” and the roads are quiet? Fall brings the extra pressure of dropping kids at school and rushing in the evenings to pick them up after sports. There is also the added pressure to produce a high volume of code to meet end of year deadlines and releases.

También da otras cifras de lo que es ‘normal’:

To do a comparison, you first need to know what normal looks like. Therefore I looked at the thousands of alpha and beta-stage applications Veracode scanned over the past couple of years. I saw an average flaw density of 24 flaws per megabyte of executable code and a median flaw density of 3 flaws per megabyte of executable code.

Curioso. Harían falta más datos, claro.

Las aplicaciones en Java tienen más fallos

Ahora que el Java está de moda por los problemas de su ‘infraestructura’ (ver, por ejemplo, Grave vulnerabilidad sin parche en Java está siendo aprovechada por atacantes ) me ‘toca’ rescatar una noticia que tampoco deja en buen lugar al lenguaje.

Lo contaban en Java apps have most flaws, Cobol apps the least, study finds y se trata de un análisis de esos masivos (Que, por lo tanto, hay que tomar con prevención):

Cast Software, a maker of software quality tools that evaluate the engineering soundness of the architecture and coding of an application, analyzed the 745 applications which combined for some 365 million lines of code. The company Thursday released a report detailing the conclusions of that analysis.

Sobre Java, podría ser falta de formación y/o experiencia:

As for Java, Curtis said he can only speculate on the problems, but said that “there are many people going into Java now that really don’t have strong computer science backgrounds. We may just be seeing the fact that there is an awful lot of people writing code who aren’t gurus in software engineering.”

En New Worldwide Software Quality Study From CAST Exposes Millions in Hidden IT Costs también comentan, con cifras más concretas:

“Our findings, although conservative, revealed an average technical debt of $3.61 per line of code,” said Curtis. “A significant number of applications examined in the study — nearly 15% — had over a million lines of code which means even the smallest of those contains over $3.6 million in technical debt.”

Otras conclusiones:

- Despite assumptions to the contrary, outsourced and in-house developed applications didn’t show any difference in structure quality. The same was true for onshore and offshore applications.
- Java EE applications were the most prevalent among those studied and received significantly lower performance scores as well as carrying greater technical debt than other languages
- Established development methods such as agile and waterfall scored significantly better in structural quality than custom methods, while waterfall scored the highest in transferability and changeability.
- COBOL applications scored the highest in security, while .NET applications received the lowest security scores

Se puede ver la nota de prensa original en: New Worldwide Software Quality Study from CAST Exposes Millions In Hidden IT Costs

Curioso. Tomar con prevención, claro.

¿Seguro que es el mejor algoritmo?

Cambiamos un poco de tema. En Think you’ve mastered the art of server performance? Think again. el análisis del coste de una solución cuando empiezan a entrar diversos factores que afectan a cómo la teoría interpreta los resultados.

Por ejemplo, algunas suposiciones puede ser importante:

A quick browse of the mental catalog flipped up the binary-heap card, which not only sports an O(log2(n)) transaction performance, but also has a meta-data overhead of only a pointer to each object—which is important if you have 10 million+ objects.

La memoria virtual:

It took quite some time before virtual memory took hold, but today all general-purpose, most embedded, and many specialist operating systems use VM to present a standardized virtual machine model (i.e., POSIX) to the processes they herd.

Y como seguimos ignorándola a la hora de medir teóricamente algunas cosas:

The fact is, however, 46 years later most CS-educated professionals still ignore VM as a matter of routine. This is an embarrassment for CS as a discipline and profession, not to mention wasting enormous amounts of hardware and electricity.

Por eso,

What good is an O(log2(n)) algorithm if those operations cause page faults and slow disk operations? For most relevant datasets an O(n) or even an O(n^2) algorithm, which avoids page faults, will run circles around it.

Por eso, nosotros siempre recomendamos medir teóricamente para tener una idea de por donde van los tiros. Pero luego probar con nuestros sistemas reales y con los datos de verdad, para estar seguros de que los resultados teóricos se mantienen.
Y, por supuesto, esto nos da pistas de por qué es importante saber de hardware, del sistema y tratar de estar al día en muchos de estos temas.

Divertido, ¿no?