Mostrando entradas con la etiqueta base de datos. Mostrar todas las entradas
Mostrando entradas con la etiqueta base de datos. Mostrar todas las entradas

martes, 20 de septiembre de 2016

Retomando la actividad con la estación meteorológica

Tras detectar una cantidad de spikes en la estación, el 30 de agosto decido desactivarla de Meteoclimatic ya que me voy a llevar un periodo de tiempo por motivos laborales en el que no voy a poder atenderla y no quiero que vuelva a estar señalada por mal funcionamiento ahora que parecía que iba bien.
Este problema de Spikes no lo he sufrido con tanta intensidad desde que la tengo.
Estoy investigándolo a ver si descubro el motivo por el que quedan registrado esos valores tan disparatados.
De momento y para poder seguir manteniendo la base de datos con valores válidos me estoy dedicando a depurarla y quitar todos los datos incongruentes como los 1600 lts. de lluvia que indica cada vez que se produce un spike.

Hoy he vuelto a activar la estación en Meteoclimatic, a ver si consigo mantenerla viva en la red.

miércoles, 20 de enero de 2016

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.



jueves, 14 de enero de 2016

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.



miércoles, 6 de enero de 2016

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$ 


martes, 5 de enero de 2016

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.

sábado, 2 de enero de 2016

Parada de Weewx por base de datos ocupada

2016-1-2.
Trasteando con la base datos he provocado que el programa se parara debido a que al intentar acceder a la base de datos, esta se encontraba bloqueada por el programa SqliteBrowser que era con el que estaba visualizando los registros.
Por tanto cada vez que se abra la base de datos hay que parar el programa.
Este es el error que ha dado en el archivo weewx.log:
Jan  2 10:55:37 raspberrypi weewx[22893]: engine: Shutting down StdReport thread
Jan  2 10:55:37 raspberrypi weewx[22893]: engine: Caught database OperationalError: database is locked
Jan  2 10:55:37 raspberrypi weewx[22893]:     ****  Waiting 2 minutes then retrying...
Jan  2 10:57:38 raspberrypi weewx[22893]: engine: retrying...
Jan  2 10:57:38 raspberrypi weewx[22893]: engine: Using configuration file /etc/weewx/weewx.conf
Jan  2 10:57:38 raspberrypi weewx[22893]: engine: Loading station type FineOffsetUSB (weewx.drivers.fousb)
Jan  2 10:57:38 raspberrypi weewx[22893]: fousb: driver version is 1.8
Jan  2 10:57:38 raspberrypi weewx[22893]: fousb: polling mode is ADAPTIVE
Jan  2 10:57:38 raspberrypi weewx[22893]: fousb: found station on USB bus=001 device=005
Jan  2 10:57:38 raspberrypi weewx[22893]: engine: StdConvert target unit is 0x1
Jan  2 10:57:38 raspberrypi weewx[22893]: engine: Archive will use data binding wx_binding
Jan  2 10:57:38 raspberrypi weewx[22893]: engine: Record generation will be attempted in 'hardware'
Jan  2 10:57:39 raspberrypi weewx[22893]: engine: Using archive interval of 300 seconds
Jan  2 10:57:44 raspberrypi weewx[22893]: engine: Caught unrecoverable exception in engine:
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****  database is locked
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****  Traceback (most recent call last):
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/engine.py", line 842, in main
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      engine = EngineClass(config_dict)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/engine.py", line 75, in __init__
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      self.loadServices(config_dict)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/engine.py", line 136, in loadServices
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/engine.py", line 504, in __init__
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      self.setup_database(config_dict)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/engine.py", line 602, in setup_database
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      dbmanager = self.engine.db_binder.get_manager(self.data_binding, initialize=True)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/manager.py", line 824, in get_manager
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      self.manager_cache[data_binding] = open_manager(manager_dict, initialize)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/manager.py", line 973, in open_manager
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      manager_dict['schema'])
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/manager.py", line 137, in open_with_create
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      dbmanager = cls(connection, table_name=table_name, schema=schema)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/manager.py", line 1108, in __init__
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      super(DaySummaryManager, self).__init__(connection, table_name, schema)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weewx/manager.py", line 69, in __init__
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      self.sqlkeys = self.connection.columnsOf(self.table_name)
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weedb/sqlite.py", line 154, in columnsOf
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      column_list = [row[1] for row in self.genSchemaOf(table)]
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****    File "/usr/share/weewx/weedb/sqlite.py", line 143, in genSchemaOf
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****      for row in self.connection.execute("""PRAGMA table_info(%s);""" % table):
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****  OperationalError: database is locked
Jan  2 10:57:44 raspberrypi weewx[22893]:     ****  Exiting.

Quedó resuelto con un arranque del programa Weewx de nuevo.
sudo /etc/init.d/weewx start

Tal como arrancó el programa actualizó la base de datos con todos los registros pendientes desde que se paró el programa.


viernes, 1 de enero de 2016

Administrador de bases de datos SQLITE

2016-1-1. Instalación de SqliteBrowser.
Para la administración de la base de datos de Weewx he instalado el administrador de bases de datos Sqlite SqliteBrowser.
El comando como siempre es:
sudo apt-get install sqlitebrowser

El programa se abre en entorno gráfico por lo que hay que acceder a la Raspberry en entorno gráfico.
Desde mi Mac, las opciones para ello pueden ser:

  1. Acceso remoto de Windows, instalando el servidor Remote Desktop Protocol XRDP en Raspberry y el cliente de Conexión de Acceso Remoto para Mac.
  2. Acceso VNC, instalando el Servidor TightVncserver en Raspberry y el cliente VNC viewer en Mac.
  3. Acceso X11 con la aplicación XQuartz de Mac OSX.
La diferencia es que las dos opciones primeras lo que hacen es arrancar el escritorio en la Raspberry y te la traen a tu escritorio local, mientras que la aplicación X11 es un protocolo nativo de Linux y se trata de un servidor de ventanas, por lo que lo único que te traen a tu escritorio local es la aplicación que tu arranques, no el escritorio completo de Raspbian. Por tanto para el tema de la carga aplicada a la pequeña Raspberry le viene mejor esta última, así como para la transmisión de datos por línea que será menor también.