Corrección de incongruencias de datos en la BBDD, y II.

20-1-2016.
Continuando con la tarea de mantener una base de datos libre de datos incongruentes, esta vez me estoy dedicando a limpiar los datos del punto de rocío. Este dato lo calcula y lo entrega en un principio la propia estacion meteorológica. Como digo es un dato calculado y se apoya en la humedad relativa y la temperatura exterior para su cálculo. Bien pues como es de todos sabido, esta estación nos da esporádicamente unos valores que no se corresponden con la realidad. Concretamente y estos días atrás he estado corrigiendo valores extremos y absurdos de temperatura. Estos valores también le afectaban como he dicho al cálculo del punto de rocío. En esa misma ocasión podría haber corregido ambos, pero para no complicarme y liarme pues no lo hice. Ahora me encuentro en ese menester.
El procedimiento es muy similar al ya realizado anteriormente, con la salvedad que al pedir el volcado de la base datos tengo que sacar los datos de outTemp y outHumidty para llevarlo a una calculadora de punto de rocío y calcularlo. En internet hay muchas páginas que hacen esta tarea. Si es cierto que no me queda otra que hacerlo uno por uno, y si no lo hubiera dejado tanto pues no tendría tanto trabajo. En el siguiente enlace puedes ver un ejemplo de ello. Es el que estoy usando:
Calculadora de punto de rocío

Para facilitar un paso de conversión en la fecha, me estoy ayudando de la funcion datetime() de sqlite. Con esta función puedo mostrar la fecha que se guarda en la BBDD en el formato unixepoch en un formato mas amigable y entendible dd-mm-aa hh:mm:ss.
Su uso sería:

datetime(dateTime,'unixepoch')-->dateTime sería el nombre del campo en el registro de la BBDD. No confundir con el nombre de la función sqlite.

De esta manera es mas fácil de localizar la incongruencia.

Corrección de incongruencias en datos de la BBDD.

14-1-2016.
Estos días atrás me he estado dedicando a resolver los fastidiosos datos erróneos que de vez en cuando y no se porque aparecen registrados en la BBDD.
Que haya un registro erróneo de lluvia lo puedo aceptar, se puede mover el pluviómetro por sacudidas de viento o como ahora que tengo la estación en mantenimiento y la he bajado a la terraza por lo que la recogida de lluvia no es fiable. Pero que de vez en cuando me registre una temperatura de -29 grados es lo que no entiendo. El caso es que este dato como se utiliza para calcular otro como puede ser el punto de rocío pues ya son dos los datos que aparecen anómalos en las gráficas. Esos son los fastidiosos picos que aparecen en las gráficas.
Bien pues como ya he aprendido a modificar esos datos, bien fácil que es, solo los tengo que localizar en la BBDD y promediarlo con los datos aledaños, anterior y posterior. Aunque sea una modificación a mano creo que es la manera de no alterar mucho la realidad, le asignamos un valor que se acerca al real ya que se tiene en cuenta la tendencia en ese momento entre 5 minutos antes y 5 minutos después.
Una vez actualizada la BBDD, y siguiendo el procedimiento de Tom Keffer, borro las tablas de DAILY o datos diarios y las vuelvo a generar.
A partir de aquí no tengo muy claro como se resuelve el resto. Lo que si me he dado cuenta es que el resultado no aparece inmediatamente, al menos en los resultados anuales que es donde apreciaba los errores. Pero si al cabo de un tiempo. Los gráficos anuales no se generan cada vez que se lanza el proceso REPORTS, ni aunque se lance a mano. Esto lo descubrí al ver que no se modificaban las fechas de los archivos anuales tras una generación. Lo dejé y al poco tiempo ya estaban actualizados. Pero no he descubierto la regla que sigue dicha actualización.

Garita de platos. Segundo intento.

2016-1-9.
Espero que como dice el refrán, a la segunda sea la vencida. Tras limpiar los platos de la primera pintura, los he lijado todos para quitarle el brillo y que se quedaran ásperos y los he vuelto a dar tres manos de pintura. Esta vez extendiendo todo lo posible la aplicación y siendo lo mas fina posible. De esta manera parece que la pintura agarra mejor y tras las tres manos y su tiempo de secado de al menos 24 horas al doblar los platos y someterlos a mal trato no se decapan ni le salta la pintura.
Ya he montado nuevamente la garita y desde hoy vuelve a estar otra vez operativa. Lo único que me falta es mecanizar un soporte para albergar al cargador fotovoltaico de las baterías. Como la garita es un poco voluminosa y con las ráfagas de aire se cimbrea mucho he compartido el peso entre su brazo y el brazo del pluviometro, queda mucho mas robusta y se cimbrea menos. El cargador lo quiero poner delante del pluviometro pero por debajo de su nivel para que no le afecte.
Estas son unas fotos de como ha quedado. Básicamente está igual que la otra vez pero algo mejor pintada.
También he aprovechado para cambiarle el conector RJ11 al cargador, cuando lo quité me fijé que estaba sulfatado. Le he puesto uno nuevo, el conector hembra del módulo principal no lo he cambiado, lo he limpiado todo lo mejor que he podido.

Edito de nuevo la entrada para añadir una imagen que es muy significativa.
Es la evolución de la temperatura durante el transcurso del montaje de la garita.
Se puede observar la temperatura que estaba midiendo con la garita original de la PCE, cuando se la quité para comenzar el montaje de la de platos y la evolución a medida que la fuí montando. Además la diferencia entre la original y la de platos.
Creo que es muy interesante. La aportaré como dato interesante cuando vaya a solicitar la acreditación en meteoclimatic, a ver si me la aceptan por que mi estación me la van a mirar con lupa, creo que es la que mas cruces rojas lleva en toda la historia de meteoclimatic.

De la garita PCE a no tenerla de 22 a 28 grados, 6 grados de diferencia.

De no tener a la garita de platos de 28 a 18 grados, -10 grados de diferencia.

Y entre la garita PCE y la de platos de 18 a 14, -4 grados de diferencia.

Mantenimiento de la base de datos. Weewx.sdb

2016-1-6.
Como arreglar las incongruencias de la base de datos era algo que tenía pendiente y contra mas tiempo pase mas incongruencias se me iban acumulando, hoy he decidido ponerme manos a la obra.
Tras leer el post de Jantoni en el que explica este procedimiento y viendo que en la documentación de Weewx viene también documentado, no he visto mayor problema que seguir las indicaciones.

1. Parar el programa. sudo /etc/init.d/weewx stop
2. Ejecutar sqlite3 abriendo la base de datos. O nos ponemos en el directorio /var/lib/weewx o lo direccionamos con el comando:
   sqlite3 weewx.sdb. Ojo si no lo hacemos con Sudo asegurarse que con el usuario que estamos trabajando tiene permisos de escritura sobre el archivo.
3. Realizar las modificaciones que tengamos pendiente, todo sobre la tabla archives. Este es el procedimiento que aconsejan en la documentación de Weewx:

Spikes in the graphs

1. Occasionally you may see anomalous readings, typically manifested as spikes in the graphs. The source could be a flaky serial/USB connection, radio or other interference, a cheap USB-Serial adapter, low-quality sensors, or simply an anomalous reading.
   Sensor quality matters. It is not unusual for some low-end hardware to report odd sensor readings occasionally (once every few days). Some sensors, such as solar radiation/UV, have a limited lifespan of about 5 years. The (analog) humidity sensors on older Vantage stations are known to deteriorate after a few years in wet environments.
   If you frequently see anomalous data, first check the hardware.
   To keep bad data from the database, add a quality control (QC) rule such as Min/Max bounds. See the QC section for details.
   To remove bad data from the database, you will have to do some basic SQL commands. For example, let's say the station emitted some very high temperatures and wind speeds for one or two readings. This is how to remove them:
   1. stop weewx
   2. Make a copy of the archive database

      cp weewx.sdb weewx-YYMMDD.sdb

   3. Verify the bad data exist where you think they exist

      sqlite3 weewx.sdb
      sqlite> select dateTime,outTemp from archive where outTemp > 1000;

   4. See whether the bad temperature and wind data happened at the same time

      sqlite> select dateTime,outTemp,windSpeed from archive where outTemp > 1000;

   5. Remove the bad data by setting to NULL

      sqlite> update archive set windSpeed=NULL where outTemp > 1000;
      sqlite> update archive set outTemp=NULL where outTemp > 1000;

   6. Delete the statistics database so that weewx can regenerate it without the anomalies
   7. start weewx
2. Rehacer las tablas diarias:
   

pi@raspberrypi:/var/lib/weewx$ wee_database --drop-daily

Using configuration file /etc/weewx/weewx.conf

Using database binding 'wx_binding', which is bound to database 'archive_sqlite'

Proceeding will delete all your daily summaries from database 'weewx.sdb'

Are you sure you want to proceed (y/n)? y

Dropping daily summary tables from 'weewx.sdb' ... 

Dropped daily summary tables from database 'weewx.sdb'

pi@raspberrypi:/var/lib/weewx$ wee_database --backfill-daily

Using configuration file /etc/weewx/weewx.conf

Using database binding 'wx_binding', which is bound to database 'archive_sqlite'

Backfilling daily summaries in database 'weewx.sdb'

Backfilled 'weewx.sdb' with 151756 records over 554 days in 1814.17 seconds

pi@raspberrypi:/var/lib/weewx$ 

Trabajo de pintura en la garita de platos. Nuevo método.

2016-1-6.
Como el resultado de la pintura de la garita de platos no ha sido válido para dejarlo como está y subirla a la azotea, retomo el asunto. He estado probando otra manera de pintar los platos y esta vez el resultado parece mas prometedor.
Como se pudo ver en las fotos de la otra entrada la base o imprimación no se quedaba adherida al plato por lo que a la mínima agresión al plato esta se desprendía a lascas. Esto era porque el plato viene muy pulido en su superficie y las manos de pintura las daba muy gruesas. En esta ocasión tras decapar el plato lo he lijado con una lija fina quitándole todo el pulido y dejándole la superficie lo mas áspera posible y las manos de imprimación extendiéndolas para que quede una capa fina. Ya desde la primera mano se observa otro acabado, y tras secarse se aprecia que la imprimación queda mas adherida y al flexionar el plato se le ve mas elástica. Tampoco hay que obligar mucho el material, una vez que se monte eso no va a sufrir tanto estres mecánico como para que se doblen los platos.
Tras pintar el plato superior lo volví a montar en la garita y aprovechando el mal tiempo lo sometí a prueba. En esta ocasión no se aprecia que la pintura se escame ni vaya a saltar. Por tanto el resto de los platos va a seguir el mismo tratamiento.
Desmonto la garita y vuelvo a poner la original de la PCE.
Con solo esta semana que ha estado al garita de platos se puede apreciar a través de los resultados como modera las temperaturas e impide que suban tanto como con la garita original. Para muestra la gráfica:

Desde hoy la estación está funcionando con la garita original PCE.

Vuelta a la normalidad. Página web funcionando de nuevo.

2016-1-5.
Tras poner en marcha el entorno de pruebas, reconozco que es una gozada modificar cualquier cosa referente a la página web. De hecho el error que estaba sufriendo y que me ha obligado a poner la página por defecto que trae weewx durante un par de días lo he subsanado en un rato. Lejos de aplicar un conocimiento profundo de programación que no poseo, lo he aislado eliminando código y añadiendolo poco a poco hasta que me ha vuelto a dar el error. Si ya se que es bastante chapucero pero no poseo conocimiento para mas....como dicen en mi entorno, tengo el conocimiento justo pa echar el día....
Bueno pues el caso es que me las he apañado para subsanarlo y otra vez vuelve a esta operativa mi página web y ademas con la mejora del Feed RSS de mi blog.
No es el que quería poner pero de momento se va a quedar hasta que consiga poner en marcha el script que me ha estado dando problemas.

Haciendo un backup de la base de datos

2016-1-5.
Buscando por internet he encontrado un metodo por el cual se puede realizar un backup de la base de datos online, esto es, sin necesidad de realizar una copia del archivo ya que ese procedimiento puede dar lugar a un error en la copia o dejar la base de datos inoperativa.
Este método al realizarse desde el propio SQlite, establece los mecanismos para acceder y bloquear la base de datos mientras está en uso.
La información fundamentalmente la he sacado de la siguiente página web:
http://www.ibiblio.org/elemental/howto/sqlite-backup.html

Y este es el extracto que me interesa:

Backing up the database

To make a backup copy of the database, simply do a "dump" and redirect the results to a file.

cd /home/sqlite
sqlite3 sample.db .dump > sample.bak

En principio y desde la consola de comandos he comprobado que funciona y que se realiza el volcado correctamente. Ya solo queda crear un archivo de comandos del sistema operativo e incluirlo en el directorio crondaily$ para que se ejecute diariamente o con la periodicidad que nos parezca oportuno para nuestra seguridad.

Bien pues este es el archivo que he creado para realizar la copia de seguridada automática:
#!/bin/bash
cd /mnt/datos/home/pi/backups
if [ -e weewx.sdb.bak ];
then
mv weewx.sdb.bak weewx.sdb.bak2
else
echo "El archivo weewx.sdb.bak no existe"
fi
sudo sqlite3 /var/lib/weewx/weewx.sdb .dump > weewx.sdb.bak

exit

Lo incluyo en el cronweekly$ directorio y a esperar a que cumpla con su tarea voluntariosamente.