Domotizing XI – DAQ for kWh – Part I (yes, in English)

The blog is read most by people that is not from Spain so … although I don’t like too much the idea of beginning to write in English (because my English is incredibly awesome, you will discover it) … I think it is a ‘must do’ … so how’s your English then?? xD

Last time I wrote about power consumption management system in my house I started manipulating files, arrays of characters, editing configuration files, and so on… and then I decided that I was wasting my time because I was programing a data/files management system without having any data adquiring system or even data!

Well, I have been programming since then a system with which I could store power data from everyday in a little bit organised style.

First of all I made a little modification to the program that gives all the data when capturing current (A) waveform. This program normally gave me all this info:

Captura de pantalla 2016-09-16 a las 17.50.17.png

The thing is that, for adquiring information about the power consumption I don’t need the graph, the number of samples, time, current peak, … Indeed, I only need ‘Potencia’ (power) value.

The modification I made to have only the power value, was to insert input parameters into the C program I had made before:

Captura de pantalla 2016-09-16 a las 17.54.23.png

As you can appreciate in the screen capture I ‘filtered’ the additional information with ‘argc’ input parameter in ‘main’. In addition to that, if the parameter introduced when we make the call to the program is “pg”, I give only power value and also I generate the graphic of current.

I also  made a little help screen so as to remember how to work with this program. We get to this information by typing the parameter ‘?’ on the program call. It returns this:

Captura de pantalla 2016-09-16 a las 18.00.28.png

  • Parameter ‘p’ gives only the actual power value in W.
  • Parameter ‘pg’ gives actual power value in W and generates current graphic.
  • No parameters gives all information and generates current graphic

OK then, this was the first step to start generating power information data files, now I would need to make another program that catches data every X seconds and stores all this information in files.

The initial idea was to create files with the actual day information on its name like this:

  • data_01_01_2016.txt

(The format is in Spanish DD/MM/YYYY). I was tempted to do it in Basque as it is the normal format I use (YYYY/MM/DD) but day-month-year format I think is easier for this context.

So, inside that .txt file the information would be stored in columns:

Captura de pantalla 2016-09-17 a las 11.30.15.png

First column would be time of day and second column is the Wh at that moment. For example, 16.13 with 45.62 Wh means that from 15.13 to 16.13 we have a power consumption of 45.6 W.

This would be OK but I don’t like it too much because my idea was to store this data in a file with the format:


… and also the information on every specific time of day like this:


Probably your are thinking that storing the data with that filename is not complex, and indeed you’re right, complexity = 0… but, what would happen when you have to access to that specific hour/minute of the day to show the informatio? How could you know if you have to write in ‘HHMM’ 1613, 1713, 2134, …?

So the solution is easy: force MM to be ALWAYS ’00’:


I created this function that generates a string with the specific path and name of the data file. Parameters ‘crear_ruta’ and ‘crear_ruta_hora’ will indicate this function if the returning string has in the name the actua day and also the hour or if it has only the actual day. The comment there ‘Para que se cree el fichero ….’ means: This is to force the data file to has ceros in the minute field in all cases’.

So after all this I have only created a file ‘pathing’.Let’s start with the rest of the program.

I created in the beginning of the program a ‘samples’ (muestra) tag. In my case this is 360, and it is configurable. For example, if you set 3600 this will store data every second, with 360 it will be every 10 seconds, and so on … The next screen capture shows this constant value in the beginning of the program:


(360 samples means 1 sample every 10 seconds in 1 hour; 3600 samples would be 1 sample every second in 1 hour).

Now we go to main program structure.

Captura de pantalla 2016-09-25 a las 10.52.32.png

Here you can see the tags declaration. There are timing variables, buffering strings, double data arrays for storing power reads. Remember that ‘muestra’ means ‘sample’ in Spanish.


We create the file that will contain Wh every hour in the beginning as you see in the previous capture. We open with “a” so as not to overwrite if the file exists and append the information in the end of it.

Captura de pantalla 2016-09-25 a las 10.58.31.png

And finally we start with the main loop.

As you see it is infinite loop that is catching the time data the whole time (first paragraph). Second paragraph named ‘CHEQUEAMOS EL DIA….’ means ‘we check that the actual day has not finished’. With this we detect a flank if the day is increasing so as to increase the path file for the new day.


I got the previous piece of code from the internet as I did not really know how to get the output data of an executable file to come into another program. I thought that it coul be done by ‘./lecturaA p > potencia.dat‘ and then read ‘potencia.dat’ file but I thought there must be another more elegant method … so that is what I found and it works!.

‘lecturaA’ is the executable file I modified in the beginning. With ‘p’ parameter I get only the actual power read.

Captura de pantalla 2016-09-25 a las 11.05.50.png

Finally this bunch of code. Lots of letters, but don’t worry, most of them are comments :P. What I do here (I remind you we are inside the while loop yet) is checking if the counter is equal to the constant defined value ‘samples’ (muestras).

Normally we will be storing power data and timing data so if we pay attention to what is under ‘most-left-else’ we see an ‘IF’ that is checking that we read correctly the power value. If the reading is good it assigns ‘potencia’ (power) value we catched before. If not read a valid number it assigns 44.0 W by defect. (Need to check this last thing as my current sensor does not read less than 44 W :/ On low currents the information is not accurate).

The sprintf stores the time information in the 2D array I created in the beginning and counter (contador) increases by 1.

When ‘contador’ gets to ‘muestras-1’ then we store the information in 2 different files. The first one is the one I created before with the data ‘dat_DD_MM_YYYY.txt’ and what I make is a sum of all power data (360 values) and divide them by ‘muestras’ => this value will be the ‘Wh‘ in the just passed hour. We store this with the hour information with ’00’ in the minute (as told before, I don’t really care about the minute as I could only get troubles with it).

Next I store ALL samples taken (360 in my case) in a file ‘dat_DD_MM_YYYY_HH00.txt’ I create with the function I described before (fc_crear_ruta….). I create, then record all data and then close the file so as to restart the process again.

As you see I set ‘contador’ to 0 and store the actual power read as indeed a power has been read but I have been storing the previous ones but I need to do this for first power data within the next hour.

And YES, the code that is under ‘contador = 0’ should have been written before the ‘sleep’ as it is common for both xDDD. I will make this modification as it is very easy right now, don’t get angry…

Ok, I think I have written too much today … Next time I will talk about plotting all this information and get a monthly report of power consumption.

Philips Hue ¿¿White??

Pueees si… cogí una bombilla de philips hue (que he de decir son excesivamente caras) de las que se denominan ‘white’ porque quería únicamente luz blanca en algunos puntos de la casa.

Elegí este modelo porque como digo quería color blanco con posibilidad de manejar la intensidad desde el bridge de philips (o sea, desde el movil en mi caso). El precio de esta bombilla es de unos 18€ (como digo bastante cara), ¿cara? sí, pero más barata que los 58€ que cuestan las Philips Hue white and color… (que los de philips se han venido un poco arriba con los precios)

Llegué a casa todo ilusionado para probar mi super-bombilla-led-zigbee-manejabledesdelmóvil (la envié y recogí en donde trabajo) y cuando la pongo en la lámpara de casa cual fue mi sopresa que ….


(NOTA: La philips white es la amarilla de la imagen superior…)

Me dije: a ver… igual desde la aplicación se puede manejar la tonalidad de blanco, o algo …




Pos no… no se podía…

Ante esta situación sólo había 2 opciones ….

1ª – Devolver la bombilla

2ª – ¿Se podrán cambiar los leds para hacerla blanca?

Joder, estaba claro que la segunda opción es bastante más atractiva … jejejej.

Vale, empecemos por el principio…. ¿De cuántos watios estamos hablando? En el casquillo pone:

‘9.5W 50mA’

Venga va, que seguro que encuentro alguna equivalente… en concreto ¿por qué no coger la que está en la imagen superior? Es el tono de blanco que quiero!.

Abrir la bombilla blanca (que por cierto es de Leroy Merlin) fue bastante sencillo… Girando un poco el casquillo y sujetando la capota (de plástico por cierto) sale bastante fácil. Sin embargo para abrir la bombilla de Philips, éstos se lo han currado un poco más y he de decir que la han pegado con dos coj**** el cuerpo de la bombilla al casquillo de cristal plástico.

Total, que había que tirar de dremel y así quedó el percal …


Me acojoné un poco al meterle la dremel a la bombilla de philips porque podía haber algo vital para la bombilla en el interior pero no… el concepto de las bombillas led parece que es el mismo para todos… Consiste en una plaquita de leds sujeta con unos tornillos a una chapita que hay en el interior a modo de refrigerador.

Antes de empezar a romper (más) cosas medí la tensión en los dos cables que salen de ambas bombillas y que van a la placa de leds. La medida inicial no fue nada prometedora:

En contínua la luz de led de leroy merlin daba 100V y sin embargo, la de philips da 30V … :/

Pero bueno, aquí hemos venido a jugar… ya que estamos vamos a probar así que siguiente paso! vamos a poner la placa de led de la de leroy en la philips.

Cómo no, para la bombilla “made in Leroy Merlin” bastó soltar los tornillos que sujetan la plaquita de los led a la estructura de la bombilla y salió bastante fácil. Únicamente tenía un poco de pasta térmica entre la plaquita de leds y la chapa interior.

Una vez cambie la placa de leds paso lo que todos sospechamos: no funciona; de 30V a 100V son demasiados voltios para no tener en cuenta…

Plan B, vamos con otra táctica.

La bombilla de Phlips tenía pegada igualmente la placa de leds a la base, pero, al igual que el casquillo al plástico, estaba pegada con dos coj**** a la chapa. Va pegada con una especie de pegamento gomoso bastante resistente.

 Aunque al final salio!

Captura de pantalla 2016-09-15 a las 19.33.47.png

… con un poco de violencia, pero bueno …

La cosa es que hacía algunos meses había comprado estos leds por internet para hacer pruebas y asi, aunque no los había llegado a usar nunca, tocaba ya:


Segun las características, estos leds son de 12V y 10W, y la “bombilla” da hasta 30V y 9.6W …. bueno… watio arriba watio abajo tampoco nos vamos a poner quisquillosos, que somos ingenieros :P.

Por otro lado si pongo 2 en serie son 24V y la bombilla me daba 30V cuando esta a tope… bah! 6 voltios arriba 6 voltios abajo… voy a meterlos en serie y que sea lo que dios quiera… jejeje.


Pues aquí esta el resultado final …. creo bastante interesante atar lo que son los leds a la chapa de la bombilla porque me huele que se van a calentar un poco. Para uno de ellos lo he tenido facil porque he aprovechado un agujero donde va un tornillo pero para el otro sin embargo … malamente he podido colocarlo gracias a la placa que asoma por el agujero central:


Se me ocurrió pensar que con loctite todo es posible y con un poco de pasta térmica para rematar me habría valido bien para seguir adelante, pero no tengo (no tengo pasta térmica, loctite sí).

Pero no me iba a quedar mirando porque estoy había que ponerlo ya!

Tirando un poco te internet he hecho pasta térmica con pasta de dientes y aceite de girasol (una auténtica guarrada…) y bueno, se quedará así, como se suele decir, temporalmente pa siempre (donde “pa siempre” puede sustituirse perfectamente por “hasta que pete” porque casi seguro que petará … actualizaré esta entrada del blog si es así ;).

Bueno, había que probar, no?

Bueno, no tiene mala pinta … ahora hasta la luz blanca de detras parece amarilla !!!

Vamos a poner la capota de plástico a ver cómo queda:

Bueno, cosas del destino … ahora resulta que la luz que era amarilla hace que parezcan más amarillas las que eran blancas porque ahora SI es BLANCA! jeje

Podemos decir que hemos hecho una Philips Hue White, pero white white !!

La intensidad de blanco se puede manejar de igual forma que antes desde la aplicación o con comandos POST como anteriormente sin problemas:


Me hace gracia cómo ha salido en la fotografía la bombilla de philips que he bajado la intensidad (al mínimo, por cierto) … parece que haya hecho una mierda de edición en Photoshop o algo, pero creedme que no: la foto ha salido asi! Será que los leds que le he metido ahora son de altísima calidad? Cuando peten lo sabremos ….

Domotizando X – Riiiiiing – (… done)

Finalmente encontre la solución al problema que tenía. Resulta que escribir desde una terminal el comando que manda un mensaje por telegram hacía que si se hacían muchas llamadas seguidas, el cliente petase.

Intente arreglarlo con threads y el resultado “mejoro” algo pero habia que poner unos delays bastante elegantes.

El comando “screen” de linux me solucionó la papeleta.

La verdad es que he hecho bastante en el tema de domótica de casa desde que puse el último post pero bueno, me centraré un poco en el tema del timbre, ya habrá tiempo para entrar en otros temas 😉

La cosa es que quería mantener el cliente de telegram ejecutando constantemente en la raspberry. Yo no tengo pantalla así que siempre accedo por SSH con lo que para ejecutar el cliente de telegram…. tenia que hacerlo via SSH.

El problema de conectarse por ssh a un dispositivo es que en el momento que te desconectes cierra todo lo que tuvieras en ejecución…. stenyak me recomendó utilizar “screen” para solucionar ese problema.

Así pues, después de investigar cómo funcionaba, conseguí entenderlo 😛 (soy un poco lentito pa estas cosas si…) y ejecutando con screen el cliente….

Captura de pantalla 2016-08-26 a las 16.57.58.png

Captura de pantalla 2016-08-26 a las 16.56.47.png

se queda en segundo plano y yo puedo cerrar la terminal… una maravilla.

Vale, pero ¿y que? ahora como se puede hacer para usar *ese* cliente que tengo en segundo plano? pues esta todo pensado!! A screen se le puede pasar cadenas de texto para que las ejecute sencillamente haciendo:


Si se escribe desde la terminal directamente sólo hay que tener en cuenta lo que va entre “”. Yo tengo ‘system’ porque estoy ejecutandolo en un programa en C.

Y qué es lo guapo de esto?

Pues que se pueden hacer mil llamadas seguidas (es decir, escribir tantos comandos seguidos como ese) y NO PETA el cliente de telegram 😉 Una maravilla.

Domotizando X – Riiiiing – (Parte 2: Soft)

Pues vamos con la segunda parte de la instalación del timbre-telegram…

Hablemos un poco del tema programación.

Como ya dije en la anterior entrada, parecía que no iba a entrañar mucho problema toda la parte de programación ya que básicamente me hice a la idea de que tendría que ser un proceso que estuviera esperando un flanco (ya sea negativo o positivo) en la entrada GPIO 17 de la raspberry.


Arriba vemos el conexionado que hice de la raspberry corregido, ya que al principio como dije, conecté el cable verde a 3.3V y el gris a a GPIO17 (igual debería haberlo metido en el apartado de hard, pero bueno, supongo que hasta hoy no me apetecía hacer el dibujo en el paint…).

Por cierto, el módulo de relés que aparece en la foto no es el módulo RF que uso para el timbre pero bueno, los relés sí son prácticamente idénticos.

Dicho esto entremos por fin en materia:

Captura de pantalla 2016-08-08 a las 17.21.01.png

Como ya comenté, partí de un programa ejemplo que encontré por internet en el que hacía uso de entradas/salidas GPIO de la raspberry programadas en C. La URL a dicha página creo que la puse, la repito:

Para instalar las librerías y demás solamente hay que seguir el tutorial que viene en la página, bastante sencillo, simple y cómodo.

Después de esas declaraciones y cabeceras de la captura anterior viene el bucle en cuestión:

Captura de pantalla 2016-08-08 a las 17.23.47.png

Antes de entrar en el bucle (no lo he puesto) vemos que hay un memoria_old = digitalRead(butPin). Esto es para inicializar el valor de “memoria_old” para hacer un flanco después de que se detecte el primero y no con el valor basura que nos viene de la declaración de memoria_old.

Como dije, al final opté por utilizar hilos (threads) para este propósito porque me estaba dando problemas el cliente de telegram en consola de comandos. Este cliente como dije en la primera parte, no está muy fino y si le maltratas un poco te hace alguna perrería que otra.

Para instalarlo basta acudir al repositorio GitHub que puse en el post de la parte I y seguir las instrucciones. No me voy a meter ahi porque es un coñazo y no viene a cuento. Sólo diré que me tardó LA VIDA en compilar en la raspberry…

Volviendo al tema. En un principio, cuando no hice con hilos, el programa se quedaba trabado en el while en la llamada a la función de ‘telegram-cli’ (porque antes esta llamada no estaba en un hilo, sino en el propio while) que es la función que manda el mensaje como tal al móvil. Solamente se ejecutaba una vez el envío del mensaje, y como hacía muchos envíos seguidos (deduje que sería por eso…) se quedaba ‘pillao’ en algun envío y no volvía a mandar más mensajes.

Para solucionar esto, se me ocurrió que ‘tal vez’ si hacía la llamada en uno hilo, si tras un timeout no respondía (es decir, si tras x segundos, el hilo no terminaba su ejecución) hacer un kill desde el proceso principal.

Para hacer todo esto que he explicado definimos la variable global: “hilo_running”

if (memoria_old != digitalRead(butPin) && hilo_running == 0){

Si detectamos flanco (primer != del if) y además el hilo que envía los mensajes a telegram NO está funcionando, entonces procedemos con la ejecución del tinglado.

Esto es así, porque si no compruebo que el hilo está ejecutándose y hago una segunda llamada a otro hilo el cliente de telegram se queda tonto y me  puede dejar hilos por ahí danzando en memoria…

Si se cumple que no hay ningun hilo anterior ejecutado procedo con la creación de un nuevo hilo:

err = pthread_create(&hiloEscribirMensajes, NULL, &escribirMensajes, NULL);
if (err == 0){
    hilo_running = 1;
    contador = 1;
memoria_old = digitalRead(butPin);

Compruebo que el hilo se ha creado bien (error == 0) y si es así, pongo hilo_running a TRUE (1) y contador lo igualo a 1 para algo que vamos a ver en un momento.

Además de eso hago que memoria_old sea igual al valor actual de la entrada digital para detectar un posible nuevo flanco positivo/negativo.

Luego entraremos en detalle en el hilo, de momento seguimos en el proceso principal (main):

if (memoria_old != digitalRead(butPin) && hilo_running == 1){
    memoria_old = digitalRead(butPin);

Esto lo pongo aquí para por si está ejecutandose el hilo que envía los mensajes y se pulsa de nuevo al timbre (detecta otro flanco) para dejar memoria_old con el mismo valor y que no vengan problemas de que, al acabar la ejecución del hilo, justo la entrada digital este en la posicion invertida a como estaba cuando se llamó al primer hilo, lo que provocaría que se ejecutase otro hilo de seguido. Con esto, esa situación se previene.

if (contador != 0){
    if (hilo_running == 0)
       contador = 0;

Si contador es diferente de 0 significará que habremos iniciado un “temporizador” ya que ha habido una ejecución de un hilo. Si resulta que de repente el hilo ya no está running… no me interesará hacer un timeout del hilo ya que sabremos con certeza que no hay ninguno corriendo (ya sea porque ha terminado de ejecutarse o porque le hayamos matado desde el main), así que pondremos de nuevo contador a su estado inicial: 0.

if (contador > 25){
    if (hilo_running == 1){
       err = pthread_cancel(hiloEscribirMensajes);
       if (err == 0){
           hilo_running = 0;
           printf("**** ERROR EN LA CANCELACION DEL THREAD!\n");
    contador = 0;


Aqui es donde hacemos el timeout del hilo, por si tarda mucho en acabar de ejecutarse.

Como hay un delay(1000) en cada iteracion del bucle infinito 25 serán más o menos 25 segundos de margen de tiempo para que se termine de ejecutar el hilo (es ajustable y posiblemente baje este valor ya que está a modo de prueba).

Lo que hacemos es que si el contador es mayor que 25 (segundos) y el hilo estaba en ejecución, matamos al hilo (pthread_cancel) y si sucede algún error lo imprimimos por pantalla a modo debug.

Además de eso, pondremos el contador a 0.

Vamos con el programa del hilo:

void *escribirMensajes(void *arg)
        system("telegram-cli -W -e \"msg ****** TIMBREE!\"");
        system("telegram-cli -W -e \"msg ****** TIMBREE!\"");
        system("telegram-cli -W -e \"msg ****** TIMBREEEE!!\"");
        system("telegram-cli -W -e \"msg ****** TIMBREEEE!!\"");

        hilo_running = 0;

        return NULL;

No creo que tenga mayor complejidad este hilo, si acaso por la cadena que se le pasa a system (que básicamente ejecuta una instrucción de bash).

telegram-cli -W -e "msg ****** TIMBREE!"

Como tal, la instrucción en bash que manda un mensaje al contacto ****** es esta de aquí arriba (en la parte de programación tiene las ” escapadas con ‘\’ para que las escriba en la terminal bien).

Y aquí es donde radica el mayor problema del programa y que realmente NO he solucionado aun… Por eso tiene delays por en medio. Es debido a que hacer muchas llamadas al cliente de telegram, hace que se bloqueen algunas y se quedan perdidas por ahí en memoria, ejecutandose en segundo plano …

Si logro encontrar la solución a este problema ya lo actualizaré por aquí. Pero de momento tiene que ir así… con esos delays…

El tema del hilo soluciona ‘un poco’ la papeleta porque al menos, no se bloquea la ejecución de llamadas al cliente de telegram… Se me ocurrió lo de incluir hilos porque asumí (mal) que al matar al hilo, mataría también las ejecuciones de system() que tiene dentro, pero esto parece que no es asi …

Así pues, podríamos decir que está aun madurando el programa aún… y que está algo verde igual pero bueno, de momento funciona y es más que suficiente… Supongo que podré ajustar más los tiempos hasta encontrar el punto óptimo en el que no se bloquee el cliente.

Veremos a ver si actualizo este post con mejoras para el sistema del timbre….

Domotizando X – Riiiing! – (Parte 1: Hard)

Cuando entras a vivir en una casa normalmente el timbre te viene puesto; este era mi caso. No obstante, decidimos quitarlo por un par de motivos. Primero, es feo y saca el tipico ruido de timbre que estas a medianoche esperando al repartidor de pizzas y te da un ataque al corazón. Segundo, teníamos intenciones de poner una mirilla inteligente con un botón de llamada integrada para recibir en el movil la notificación de que había alguien en la puerta.

La segunda parte la llevamos a cabo y pusimos una mirilla inteligente; pero algún vecino se nos quejó… en parte normal y en parte… no sé, a mi no me parecería mal que un vecino pusiera una mirilla de este tipo en mi rellano… así que manías y paranoias de cada uno, supongo…

La cosa es que después de esta situación, estabamos sin timbre y hasta AYER no hicimos nada al respecto para remediarlo.

Se nos ocurrió que podíamos coger la idea de la mirilla original (aunque hayamos eliminado la mirilla) y llevarla al timbre. Así pues me puse manos a la obra porque tenía todos los materiales necesarios… Tengo mucha historia electrónica sin usar por ahi… jejeje.

La idea era utilizar un modulo de RF (de estos mandos para abrir puertas de garaje) conectado a la raspberry para que la raspberry emitiera un mensaje al movil avisando que han llamado al timbre. Problemas de esto: el módulo RF lo tengo (lo pillé en banggood). La conexión con la raspberry es trivial… solo hay que tomarse la molestia de hacerlo. El verdadero problema me supuso la interconexión Raspberry – Movil en un principio. Posteriormente te das cuenta que existe mucha gente que se le ha ocurrido ya la idea … xD y localizas repositorios como este:

Que solucionan bastante la papeleta 😉
Probé en una distro Ubuntu el repositorio y funcionaba, no se si bastante bien, pero funcionaba, pese a algunos problemillas que tuve.
Así pues empecé con el hardware:

Si desmontamos el mando nos encontramos con que lleva un par de pilas de boton de 3V y lo que hacen los botones es lo de casi siempre… utilizar una chapita que se comba cuando le pulsas para unir 2 pistas del circuito integrado. La solución para insertar aquí el timbre resulta evidente:


El tema de las pilas, lo dejaré de momento, pero sospecho que podría alimentarlo del propio cable del timbre… Ya investigaré (o no…).

Posteriormente hay que conectar la raspberry a una salida del relé (el ‘A’ en nuestro caso):


Como vemos tengo 4 canales en total, utilizo solo 1… pues 3 reservas… ya se me ocurrirán funcionalidades para meter en la raspberry, que no cunda el pánico 😉

Hecho esto pasé a programar algo para leer las entradas. Tenía la GPIO 17 disponible así que conecté el relé ahí.

Realmente comentí un error de 1º de electrónica … conecté el común del relé a la salida de 3.3V (TRUE) de la raspberry y una salida del relé a la GPIO 17… Esto, cuando el relé está conectando el comun (mis 3.3V) con GPIO17 (la entrada a la raspberry) para este caso concreto, evidentemente leeré un 1 PERO cuando está abierto el circuito (relé cambia de posición), GPIO17 está al aire y estar al aire NO es necesariamente un FALSE (0V), de hecho… a mí me seguía dando un TRUE aunque hubiera ‘desactivado’ el relé…

Así pues, lo que había que hacer realmente era conectar el COMÚN del relé a la GPIO17 y cada uno de los otros 2 extremos del relé a 0V y 3.3V, quedando así:


Podemos ver de la salida del módulo del led azul que el común es el azul que va a la GPIO17 (tapada por los cables rojo y naranja en la imagen :/) y luego los cables verde y blanco van a GND (0V) y 3.3V respectivamente.

Y así sí, teníamos buenas lecturas desde la raspberry !


Así teníamos el hardware ya preparado para funcionar… nos falta el software!

La parte de software la intentaré describir en el siguiente post, no obstante, partí de la librería wiringPi y en concreto de algún ejemplo que me baje de:

Ya sabéis que yo suelo usar C… está python que se supone es más facil pero… bueno, prefiero lo conocido que me voy a pelear menos, jejejejej

Captura de pantalla 2016-08-08 a las 17.51.55.png

Gracias a stenyak y a los maravillosos hackits/solveits de este año he empezado a usar VIM… joder es una herramienta realmente buena! cuánto tiempo de mi vida he perdido con el nano xDD???

Para hacer el programa del timbre empecé partiendo de un proceso únicamente, pero me daba algún que otro problema y se quedaban muchas llamadas al cliente de telegram ejecutandose por ahí en segundo plano en la raspberry.

Para solucionar estos problemas empecé peleando con el comando ‘system’ de C pero no tenía mucho que hacer… finalmente opté por hacer uso de hilos.

Digamos que aún tengo en fase beta el programa del timbre (joder…. pensé que no me causaría tantos quebraderos de cabeza….). Va bastante bien tal y como está ahora, pero estoy pensando en algunas mejoras que le pueden ir bien. Explicaré cuando tenga acabado 100% (o 98%, que nunca dejo bien bien un programa :P).


Domotizando IX – ABORTEN! + RESET ;)

Bueeeeno, pues aquí estamos de nuevo. Que hacía tiempo que no escribía nada… Con la Euskal Encounter en mente, el trabajo y otros temas de la casa he estado bastante entretenido la verdad.

El otro día empecé a escribir el código para el cálculo de kWh en casa, pero no lo tengo terminado porque … lo de siempre, empiezas a escribir y a pensar… pues es que igual necesito hacer esto porque voy a tener este problema (y te desvías) y según estas solucionando un problema aparece otro! (y te desvías) y así hasta… que te aburres o dices… me estoy yendo, voy a empezar de nuevo que seguro que hay una forma más facil de hacer las cosas… jejeje.

Captura de pantalla 2016-07-11 a las 12.04.55

Si si, lo sé, por qué hay un .exe y un .win? Bueno, es que he de confesar que he estado haciendo un poco de programación en windows qué le vamos a hacer… Pero pensando en que no puedo venirme arriba usando la api de windows, eh? que no cunda el pánico…

Aqui va parte del codigo (casi la totalidad del mismo tal y como lo tengo ahora):

Captura de pantalla 2016-07-11 a las 12.09.23.png

Como podeis ver… basicamente lo que tengo aquí es un programilla que gestiona/recoge los datos que hay un archivo de configuración. Un archivo que contendrá los datos que querremos visualizar de consumo.

Va por días, meses y años. La idea es introducir una fecha inicial, una final y el tipo de muestras cada cuanto se están capturando para hacer el cálculo de los kWh. Sencillo.

Captura de pantalla 2016-07-11 a las 12.13.17.png

El “main” del programa, que será el que haga el cálculo (o ya veremos si hago otra funcion para ello). Lo actualizaré cuando lo tenga terminado o semi-terminado. Porque también mi idea es crear un archivo de datos por meses para hacer el calculo para según fechas establecidas en este archivo de configuración… o incluso estaba pensando en pasar por parámetro a este programa los datos de las fechas y quitarme del archivo de configuración (una gran idea que supondría tirar lo que tengo ahora mismo A LA MIERDA ya que no haría falta tanta chirigota con ficheros…)

Conclusión, ya iré actualizando este mismo post según vaya avanzando…


Después de estar más tiempo pensando en toda la liada de datos que voy a tener, cómo los quiero mostrar y qué información quiero dar he llegado a la conclusión de que voy a borrar toda la mierda que he hecho arriba y empezar a replantear todo desde 0 ….

Es un poco triste, pero a veces hay que hacer este tipo de cosas porque da la sensación de que estás haciendo parche sobre parche de algo que ni siquiera está aún terminado (ni empezado incluso….).

En el programa de arriba empiezo a hacer un procesamiento de un fichero de texto que aún no tengo generado …. mal javi, maaaaaal!!

El paso siguiente adecuado es generar el fichero con las potencias muestreadas, no el procesamiento del fichero de las potencias muestreadas … ¿en qué estamos pensando?

Domotizando VIII – Muestreo multiple

Como comentaba en el post anterior, he estado haciendo algún que otro cambio al tema del muestreo.

Creo que las modificaciones que he hecho en el programa están bien pero no obtengo los resultados esperados. La idea es la siguiente: dado que el muestreo lo hace prácticamente cada milisegundo (o más…), se me ocurrió: por qué no cojo dos ciclos de onda en lugar de solamente 1 y los solapo para así tener más datos?

Pues podía parecer una buena idea al principio pero no, los resultados no me han convencido mucho y bueno, no es que no me hayan convencido, sino que realmente no son lo buenos que deberían y es en parte porque los 50Hz ideales que se supone que deberían llegar a nuestro enchufe no son ideales, a parte de que de un ciclo a otro ‘puede’ que haya desfasado según la carga que haya…

A continuación, una captura del resultado de muestrear 2 veces (unas 44 muestras en total, solapadas):

Captura de pantalla 2016-06-09 a las 22.20.40.png

Si bien desde el milisegundo 7 hasta el 14 más o menos, la cosa no tenía mala pinta, después empiezan a verse picos y sólo se me ocurre de que sean porque la onda no es perfecta en frecuencia como digo y en unos puntos sí que está cogiendo bien y solapando un ciclo con el siguiente queda bien, pero en otros no.

En milisegundos anteriores a 7 también hay unos escalones que tampoco sé de dónde podrían venir (muestreo? frecuencia?)

Seguiré investigando al respecto… Se me ocurre así de primeras solapar varias señales con varios plot en lugar de varias señales en 1 solo plot como esta la imagen de la captura…

Seguiré mirando esto un poco como digo y lo próximo… Medir los kWh! que es para lo que está hecho el invento …


Domotizando VII – Calculo eficaz

Han pasado varios días y no he estado inactivo en lo referente al tema de la domotización chancra que ando haciendo en casa.

He estado modificando varias cosas. En primer lugar el tema de control de enchufes que tengo también bajo el mando de la Raspberry y del que ya hablaré en su momento, algún sensor de temperatura y conectividad. Pero a lo que voy en esta entrada es a lo de siempre, mejorar el la captura de datos todo lo posible 😉

A principios de semana me di cuenta de que yo tenía ajustado el valor de pico de la señal al valor eficaz!! Me explico: en posts anteriores donde comparo (creo que puse en un video además) el valor de amperios que me daba la pinza con el valor que leia el CAD estaba comparando el valor eficaz (la pinza amperimetrica da valores eficaces) con valor de pico leido en el CAD habiendo hecho la conversión correspondiente según matlab.

Así pues esto es incorrecto. Para corregirlo, como sé que, por ejemplo, 10A eficaces (leidos con la pinza) me dan 10A también en la raspberry después de la conversión, lo que hay que hacer es multiplicar estos 10A por la raiz de 2, porque lo que tengo es el valor de pico de intensidad; así pues 10A eficaces = 10*1.414214 = 14.14A pico.

Así mismo, multiplicar los valores que estaba obteniendo antes, por esta relación de 1.414214, nos dará como resultado el valor instantáneo REAL de intensidad, quedando así el programa:

Captura de pantalla 2016-06-09 a las 11.05.24.png

Como se ve, queda multiplicado fAef * la raiz de 2 al final de la ultima linea de la captura.

Hecho esto ahora tenemos el fichero, o sea, la grafica de intensidad, con la intensidad real instantánea que circula por nuestra línea general de casa.

Para calcular el valor eficaz de una señal sinusoidal pura basta dividir el valor de PICO entre raiz de 2; que es lo que he dicho antes; PERO tenemos un problema y es que la intensidad que hay en la red de casa NO es una señal sinusoidal pura (A NO SER QUE PONGAS UNA CARGA RESISTIVA PURA como hice yo con los secadores en posts anteriores; y por lo que he aplicado la relación 1.414214 para corregir ahora el fallo; ….. mentira aun asi, porque tienen motores…. pero bueno, asumimos que no afecta :P).

A lo que iba. Lo que sucede en una vivienda es que tenemos una señal más bien deforme y desfasada gracias a cosas como reactancias de focos led, transformadores, standbies de dispositivos como la tele, placa, horno, etc…. entonces NO podemos coger el valor de pico y dividirlo por raiz de 2 sino que hay que acudir a la definición de valor eficaz que es (ai mamita…) una INTEGRAL de la señal de corriente en nuestro caso.

La fórmula de cálculo de valor eficaz para una función contínua viene dada por:

Captura de pantalla 2016-06-09 a las 11.14.09.png

Sería la raiz cuadrada de 1 entre el período de la señal (0.02s ó 1/50Hz) multiplicado por la integral de 0 a T (final del periodo) de la señal de intensidad al cuadrado por diferencial de tiempo…

Bueno, por suerte (o por desgracia, según como se mire) vivimos en un mundo digital y la señal i(t) perfectamente contínua que nos pide la fórmula no existe (vale, existe pero con el CAD NO la puedo sacar) así que hay que pasar esa integral al mundo digital, que como digo, para nuestro beneficio, una integral se convierte en un sencillo sumatorio en formato digital:

Captura de pantalla 2016-06-09 a las 11.18.39.png

Como vemos, esto ya es más ‘computable’ a la vez que fácil 😉

‘N’ son el número de muestras que tenemos y los valores de x, son las muestras que hemos ido capturando. CHUPAU programar:

Captura de pantalla 2016-06-09 a las 11.20.42.png

‘Sum’ va guardando el sumatorio de todas las muestras mientras N va contando las muestras y al final para visualizar se hace la raiz cuadrada del sumatorio/N que queda bien claro en la fórmula.

LISTO! y parece que funciona!!:

Las imagenes pequeñas se puede ver la diferencia entre valor de pico y eficaz, y se aprecia aun mas en las 2 imagenes más grandes, con valores de pico mayores y valor eficaz también mayor.

El próximo post hablraré de cómo he intentado mejorar el muestreo. Tengo ya hecho algo pero tengo que redactarlo y ahora no tengo mucho tiempo…

Domotizando VI – Captura de datos

Vamos a mejorar un poco el programa de captura de datos en la raspberry.

Tal y como lo tenia hasta ahora, lo que hace es buscar en 200 iteraciones el elemento de más valor y darme la tensión de pico, pero como digo, vayamos un paso más allá y hagamos que se puedan capturar (y posteriormente graficar: esto pa otro capi) los datos.

El primer planteamiento que se me ocurre es este:

Captura de pantalla 2016-05-30 a las 19.12.02.png

(Atención a la imagen de fondo donde he buscado en internet la equivalencia en linux de la función de la api de windows GetTickCount() :PPP)

Pues lo que decía; lo primero que podemos pensar es grabar los datos en un archivo … al fin y al cabo, es la mejor forma de tener almacenada la última lectura.

Está muy claro que la escritura del fichero tenía que ser fuera del bucle de captura de datos para poder capturar el mayor número de datos posible. Vamos paso a paso:

while (uiCheckPoint_2 – uiCheckPoint_1) < 20) //por qué? muy sencillo:

La frecuencia que nos llega a casa es 50Hz => 50 ciclos por segundo => 1 ciclo en 0.02 segundos = 20 ms. Facil, no? Lo que hago es comprobar un ciclo completo y como realmente tengo el amplificador operacional que ademas rectifica la señal… realmente me bastaría con 1 semiciclo (o sea 10 ms de lectura) pero vamos allá a ver que leemos con 20.

En la siguiente línea está el primer error *grave* del que me di cuenta: Hacer operaciones en coma flotante chupa muchísimos recursos, y más teniendo en cuenta que estamos hablando de resolución de milisegundos en la captura. Así pues, la línea donde hago la operación de obtener la intensidad directamente  en valor de amperios es una cagada. Por eso el código, cambiado así:

Captura de pantalla 2016-05-30 a las 19.18.26.png

Es sin duda mucho más efectivo… Con la primera versión (captura de arriba) hacía una captura de la increíble cantidad de 10 muestras (si, lamentable) sin embargo, con esta versión en la que leo y opero a posteriori (después de la captura) capturo bastantes más datos:

Captura de pantalla 2016-05-30 a las 19.18.06.png

como bien se puede ver 😉

Vamos a ver los datos de forma bonita con Matlab:

Captura de pantalla 2016-05-30 a las 19.33.35.png

Lo se, lo sé, la resolución es realmente …. lamentable !! Hay que replantearse un poco el programa para ver cómo se podría mejorar esa birria 😉

Se me ocurre así a botepronto alguna idea pero …. no se… voy a ir buscando los apuntes de sistemas informáticos en tiempo real … que me temo que los voy a necesitar para salir de esta…


Pues me he venido a la cocina y he puesto una sarten para meterle caña a tope a la vitro:

Ahí queda eso. Parece un biberón o algo, pero al menos tiene mas forma de onda… jeje casi 12 Amperios de consumo la castaña de la vitro con un fuego a tope … (Iberdrola frotandose las manos ….)

Domotizando V – Captura y polyfit-ing

Y vamos llegando al final de la etapa (de potencia :P). Hoy tocaba probar todo el invento en conjunto, y me refiero a hacer lectura analogica de la señal del amplificador en la propia raspberry y que nos diese un valor legible (es decir, potencia real consumida, o Amperios, que viene siendo lo mismo).

Para ello, he de decir que he perdido mucho mas tiempo a la tarde intentando configurar el wifi de la raspberry (con el pincho usb) que haciendo las pruebas y haciendo el miniprograma en C, pero bueno.

Había que empezar por conectar a la raspberry los periféricos que vamos a utilizar. Estos son: el CAD i2c y el amplificador+rectificador. Así ha quedado el montaje final:


Antes de aventurarme a hacer nada más, había que realizar el programa en C para hacer la lectura de datos.

Hay que tener en cuenta que el amperimetro nos va a dar de 0 a 3.3V siendo esto equivalente a 0 Amperios eficaces y 21 Amperios eficaces respectivamente. Así pues, lo primero que he hecho ha sido coger un amperímetro más decente (ya que ha aparecido hoy uno que tenía por casa) y he realizado varias mediciones más que las veces anteriores.

Captura de pantalla 2016-05-11 a las 17.09.06.png

También como las veces anteriores, he tirado de matlab para meter esos datos y sacar una aproximación, que luego usaremos en el programa en C:

Captura de pantalla 2016-05-11 a las 18.15.54.png

Estas son las mediciones, siendo V el voltaje de pico. Hay que tener en cuenta que esos voltajes son valores digitales una vez pasan el CAD y según las características del CAD estos valores van de 0 a 255 con 0 a 3.3V respectivamente. Con esta información, tenemos que sacar los valores correspondientes en “digital” a esos valores de voltaje analógicos. La solución es bien sencilla; basta una regla de 3:

Si 3.3V -> 255 => xV -> y donde y = round(x*255/3.3). Y el resultado en el caso de este ejemplo es:

Captura de pantalla 2016-05-11 a las 18.20.40.png

Los datos están redondeados por defecto ya que una señal digital no puede tener decimales….

Hecho esto, calculamos los coeficientes para hacer mínimos cuadrados, que como en el capitulo anterior hice se hace con polyfit:

Captura de pantalla 2016-05-11 a las 18.22.44.png

Teniendo estos valores nos bastará realizar la siguiente operación, directamente con el valor digital leido del CAD, para obtener la corriente REAL medida:

A_eficaz = 0.0001*lecturaCAD*lecturaCAD + 0.0595*lecturaCAD + 0.1422;

Así pues, podemos pasar directamente a hacer el programa en C en la misma raspberry.

Captura de pantalla 2016-05-11 a las 18.27.08.png

A la hora de hacer el programa para la lectura de la intensidad el único problema que encontramos es el hecho de que estamos midiendo una onda senoidal rectificada (o sea con la parte negativa invertida) a 50Hz, con lo que estamos leyendo un montón de valores de entre 0 a x.xV; así que hay que filtrar los PICOS de esa onda senoidal. Para ello, la primera aproximación que se puede hacer es el trozo de programa de la parte superior (que funciona bastante bien, pero por supuesto, será mejorable).

Lo que hacemos es durante 200 ciclos de programa hacer lecturas de la entrada analógica y quedarnos con el máximo valor que nos de ésta (entrada analógica conectada al puerto 2 del CAD, que es el libre, para no tener que sacar ningún jumper de los que vienen para pruebas). Después de 200 ciclos de intentos de lectura del valor máximo ‘asumimos’ que tenemos el valor bueno y es entonces cuando entra el “else” y representa el valor real de intensidad para ese valor maximo leido.

Se resetean el contador y la lectura del valor máximo y entonces se imprime en pantalla el valor calculado según la recta de regresión. Este valor representado se queda ahí, hasta que hayan pasado otros 200 ciclos y se haya calculado un valor máximo nuevo.

Y eso es todo! luego actualizo el post y subo un vídeo que he hecho con el movil de lectura en tiempo real.


Próximo objetivo ….. hacer una interfaz web con esta información y colocar ya todo en su sitio en casa!!