Meteoclimatic
Software => WeeWX => Mensaje iniciado por: Xavi-EA5ZF en 19 de Julio de 2018, 19:07:31
-
Hola, se me ha terminado la buena suerte y como no, en periodo estival en el que no resido en la misma casa y no puedo hacer el mismo mantenimiento de la web, me he dado cuenta de que he tenido un cata-crash en el weewx, y ahora voy a tener que pensar en una estrategia adecuada para la mejor recuperación del contenido.
El tema es que un día petó el sistema weewx, dándo un mensaje de database is malformed.
Eso parece indicar que la memoria en la que está se ha dañado, y con ella parte de la BBDD.
El problema es que lo indicado es recuperar un backup anterior y actualizar desde él aprovechando la memoria de la estación, pero al revisar un poco los log veo que ya hace días que estaba avisando.
El tema es que puedo retrotraerme a una sana de hace un mes o mas y luego he de actualizar, pero no puedo hacerlo desde la consola y debo hacerlo desde lo que pueda exportar desde la base de datos que hoy mismo está activa.
No sé cual sería la mejor forma de hacerlo, supongo que una vez copiada la base de datos anterior, había que ir sacando via SQL los datos modificados de la base de datos e ir metiéndolos via importación.
Supongo que el comando sería tabla a tabla parecido a este:
SELECT * FROM nombre_tabla WHERE DATETIME > epoch_final_bbdd_antigua;
y exportando esto a CSV para luego importarlas una a una cada una de las mas de 40 tablas.
Es correcto o hay alguna forma mejor?
El comando .DUMP avisa que hay errores y no me fío de utilizarlo, aunque no sé que podría pasar si recupero la base de datos anterior y luego le doy a importar el DUMP eliminando sus comandos iniciales de borrado de las tablas.
Lo dicho, el tema es para especialistas...
-
Bueno, el tema parece que ya lo he resuelto.
Aviso a navegantes: la BBDD estaba corrupta desde hace meses y el weewx no avisaba.
How-to:
He estado mirando diferentes copias de la BBDD hasta encontrar una tabla archive con todos los datos y que no tenga ningún error.
El error se nota en que no te informa del nº real de registros o bien si al exportar datos da el error de "database malformed"
Una vez con una copia correcta pero desactualizada de la BBDD he exportado la tabla archive.
Desde diferentes copias mas actuales de la BBDD he exportado y aislado los datos complementarios para actualizarla a fecha de hoy, al final he tenido que mezclar datos de 4 bases de datos diferentes para completar el total de días y no perder nada.
Una vez todo esto en ficheros de texto SQL, el tema es crear una BBDD vacía y nueva e importar los datos de las tablas archive previamente exportados.
Me hice un excel para ir controlando y no perder nada:
Desde epochtime xxxx a yyyy
desde epochtime yyyyy a zzzzz ... etc
Una vez todo importado, la base de datos es correcta y ya no muestra lo de malformed, solo falta recrear las tablas accesorias con el wee_database -- rebuild_diary (creo recordar que es así)
Todo esto me ha hecho pensar en una estrategia buena para próximas ocasiones, creo que lo mejor es alternar varios tipos de copia, por una parte la fisica que es copiar el fichero weewx.sdb del directorio /var/lib/weewx y por otra ir haciendo exportaciones de datos e ir controlando que no se hagan con errores.
Para esto hay que entrar en la bbdd con sqlite3 indicarle un fichero para el dump (el dump es un fichero de texto plano SQL) y luego realizarlo:
sqlite3 /var/lib/weewx/weewx.sdb
.output backup.dmp
.dump
.quit
o bien:
sqlite3 /var/lib/weewx/weewx.sdb
.output backup.dmp
select * from archive;
.quit
Me falta hacer el script para automatizarlo, como no tengo tiempo por temas familiares graves en un próximo capitulo iré probando y actualizando el post con el script resultante.
Saludos.
Xavi
-
# Copia de la base de datos weewx semanalmente
5 0 * * 1 root /home/pi/dump_archive >dev/null
10 0 * * 1 root /home/pi/dump_weewx >dev/null
Añadir esto al crontab y he puesto en /home/pi dos ficheros, uno para la tabla archive y el otro para el dump de la base de datos total.
cd /home/pi
sqlite3 /var/lib/weewx/weewx.sdb .dump > dump_backup.txt
y el otro:
cd /home/pi
sqlite3 /var/lib/weewx/weewx.sdb 'select * from archive;' > dump_archive.txt
A partir de aquí cada cual que piense y haga lo que decida... copia física, copia lógica o ambas o ninguna.
-
He encontrado una posible solución a la corrupción de datos de la BBDD de weewx.
Aparte de una buena y sana politica de realización de copias de la BBDD, adjuntaré un script para sanear la BBDD que al menos a mí me ha ayudado a volver a tener la BBDD operativa.
En mi caso no se ha perdido ningún dato, pero nunca está de mas tras la recuperación hacer algunas pruebas y cerciorarse de la continuidad de los datos almacenados.
El script es este;
#!/bin/sh
#
# repairsdb.sh
#
# requires sqlite3 (apt install sqlite3)
# adjust following line with path/file.sdb
DBFILE="/var/lib/weewx/weewx.sdb"
# dump
echo "Dump corrupted sqlite file $DBFILE to $DBFILE.dump.gz"
echo '.dump' | sqlite3 $DBFILE | gzip -c >$DBFILE.dump.gz
# backup sdb
echo "Rename corrupted sqlite file $DBFILE to $DBFILE.backup"
mv $DBFILE $DBFILE.backup
# rebuild sdb from dump
echo "Building proper sqlite file $DBFILE from dump $DBFILE.dump.gz"
zcat $DBFILE.dump.gz | sqlite3 $DBFILE
echo "Done !"
Espero que sea de utilidad.
Adjunto también la utilidad de dump de la BBDD:
#!/bin/sh
#
# dump_archive.sh
#
# requires sqlite3 (apt install sqlite3)
# adjust following line with path/file.sdb
DBFILE="/var/lib/weewx/weewx.sdb"
# dump
echo "Dump BBDD archive file $DBFILE to $DBFILE.dump.gz"
echo '.dump' | sqlite3 $DBFILE | gzip -c >$DBFILE.dump.gz
mv $DBFILE.dump.gz /home/pi/
Y la de exportación de todos los datos...
cd /home/pi
# sqlite3 /var/lib/weewx/weewx.sdb 'select * from archive;' > dump_archive.txt
DBFILE="/var/lib/weewx/weewx.sdb"
# dump
echo "Dump sqlite archive file $DBFILE to $DBFILE.dump.gz"
echo 'select * from archive;' | sqlite3 $DBFILE | gzip -c >/home/pi/dump_archive.txt.gz
-
hola
continuando un poco el tema de este hilo y evitar abrir o duplicar otro, me gustaría saber si es posible (explicado paso a paso) que WeeWX haga la mayor parte de sus operaciones en un USB externo (actualizar la BD básicamente y otras operaciones que requieran escritura/lectura de forma asidua ) y así reducir los ciclos de escritura/lectura en la tarjeta SD.
Lo pregunto porque tras seis meses de uso 24/7 de la Raspberry, está empezando a comportarse de forma 'extraña' (pierde la conexión del router de forma imprevisible tardando en volver a estar online minutos o incluso horas) y he pensado que puede ser cosa de la propia tarjeta SD que aunque sólo está al 10% quizás la esté penalizando tanto acceso de escritura/lectura.
saludos.
-
Hola
Yo tengo weewx grabando a base de datos y generando los archivos del skin cada minuto casi dos años y aparentemente no encuentro nada raro en la SD ni en el funcionamiento del SO...
Puedes hacer que weewx cree la base de datos en otro lugar como un pendrive externo configurándolo en weewx.conf
[DatabaseTypes]
# Defaults for SQLite databases
[[SQLite]]
driver = weedb.sqlite
# Directory in which the database files are located
SQLITE_ROOT = /var/lib/weewx
En la parte en negrita pones la dirección del pendrive y ten en cuenta que tendrá que ser montado al iniciar la raspi.
-
Hola
Yo tengo weewx grabando a base de datos y generando los archivos del skin cada minuto casi dos años y aparentemente no encuentro nada raro en la SD ni en el funcionamiento del SO...
Puedes hacer que weewx cree la base de datos en otro lugar como un pendrive externo configurándolo en weewx.conf
[DatabaseTypes]
# Defaults for SQLite databases
[[SQLite]]
driver = weedb.sqlite
# Directory in which the database files are located
SQLITE_ROOT = /var/lib/weewx
En la parte en negrita pones la dirección del pendrive y ten en cuenta que tendrá que ser montado al iniciar la raspi.
Gracias!quizás es probable que no sea tema de la SD, no sé, la verdad es que me está dando algún que otro dolor de cabeza el asunto pero ya no sé qué pensar.... de todas formas probaré tu consejo.
-
Hola,
Yo lo tengo montado de una manera parecida a la que tu comentas.
En toda SD con raspbian hay 2 particiones: "/boot" y "/root". La primera unicamente (a grosso modo) sirve para arrancar el sistema operativo, mientras que la segunda es la partición que contiene el SO propiamente dicho, y es aquí donde se realiza toda escritura/borrado.
Para que estos ciclos de escritura/borrado sean hechos en un usb externo, tienes 2 opciones: o poner raspbian en un usb externo con ambas particiones y usar solo este, sin SD, o indicarle a la SD que el sistema operativo donde ha de escribir (/root) se encuentra en un usb externo. Es decir, usar la SD para arrancar la raspi y funcionar con el USB externo.
En este último caso, en caso de que fallase el USB, solo habría que cambiar el identificador del mismo en la SD y poner uno nuevo. Y a funcionar.
Yo tengo 2 sistemas funcionando de este modo y de momento van de perlas (voy a tocar madera por si acaso). Ambos llevan casi 2 años funcionando sin problemas.
Aquí tienes un tutorial paso a paso para que veas como se hace, por si te interesa: http://www.kupply.com/move-your-raspberry-pi-system-to-usb-in-10-steps/ (http://www.kupply.com/move-your-raspberry-pi-system-to-usb-in-10-steps/)
-
Hola PacoJavi
Una puntualización, /root es la carpeta personal del usuario root al igual que /home/pi es la carpeta personal del usuario pi.
De donde salen todas las particiones es de "/" que es la carpeta raíz (root) del sistema y del que penden todas ellas. Se puede ver con ls -l / en el terminal.
Otras particiones del sistema se pueden ver también con df -h
Como dije antes, poniendo la BBDD de weewx en el USB no hace falta poner todo el SO en él. No tiene por que haber problema en que el SO esté en la tarjeta micro SD.
Saludos
-
Holauna cuestión rápida ¿cómo puedo añadir registros a mi actual base referidos al año pasado? lo pregunto porque tras el 'apagón' de estos días he estado 4 días sin datos (los primeros del año) hasta que ha empezado a funcionar la cosa pudiendo recuperar, hoy día 9, los registros guardados en la Davis desde el día 4. El tema es que tengo la BBDD 'antigua' la del año pasado en copia de seguridad y me gustaría poder añadir todos sus registros a esta nueva BBDD. ¿es posible?
-
Hola JosMar
Veamos... pon la BBDD antigua en /var/lib/weewx con otro nombre que no sea weewx.sdb y sitúate en ese directorio
Detén weewx y haz copia de seguridad de las dos BBDD que tienes a otro directorio y ejecuta estos comandos:
sudo sqlite3 basededatos1.sdb .dump > temporal.sdb
sudo sqlite3 basededatos2.sdb .dump >> temporal.sdb
sudo sqlite3 weewx.sdb .dump < temporal.sdb
sudo rm temporal.sdb
Pon en marcha weewx a ver cómo va.
basededatos1.sdb y basededatos2.sdb serán las BBDD a unir
Tardará su tiempo en cada operación y puede que dé errores al unirlas.
Lo importante es hacer copia de seguridad de ambas por si saliera mal la operación.
-
He modificado el mensaje anterior ya que había puesto las BBDD con extensión .sql en vez de extensión .sdb
-
Ummmmm........
No sé si este método funcionará. El comando .dump, al menos lo que yo recuerdo vagamente, vuelca la estructura de una base de datos en un fichero de texto, pero no recuerdo que sirva para insertar datos en una tabla o base da datos.
Tendría que revisar la documentación.
El modo más seguro es el de “insert into tabladedestino select from tabladeorigen”
No obstante, aunque funcione un método u otro, preveo muchos dolores de cabeza con las inconsistencias.
-
De todos modos.....la premisa es....
Tocad la base de datos lo menos posible.
De ese modo weewx lleva funcionando 6 años en mi vieja raspberry Pi sin ningún tipo de problema
-
No sé si este método funcionará. El comando .dump, al menos lo que yo recuerdo vagamente, vuelca la estructura de una base de datos en un fichero de texto, pero no recuerdo que sirva para insertar datos en una tabla o base da datos.
.dump vuelca la estructura y datos para ser insertados en pantalla o a un archivo de texto como dices (> archivodump) de manera que queda con los comandos para ser volcados a una nueva base de datos.
Esto sería el principio de ese fichero de volcado:
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY, `usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `barometer` REAL, `pressure` REAL, `altimeter` REAL, `inTemp` REAL, `outTemp` REAL, `inHumidity` REAL, `outHumidity` REAL, `windSpeed` REAL, `windDir` REAL, `windGust` REAL, `windGustDir` REAL, `rainRate` REAL, `rain` REAL, `dewpoint` REAL, `windchill` REAL, `heatindex` REAL, `ET` REAL, `radiation` REAL, `UV` REAL, `extraTemp1` REAL, `extraTemp2` REAL, `extraTemp3` REAL, `soilTemp1` REAL, `soilTemp2` REAL, `soilTemp3` REAL, `soilTemp4` REAL, `leafTemp1` REAL, `leafTemp2` REAL, `extraHumid1` REAL, `extraHumid2` REAL, `soilMoist1` REAL, `soilMoist2` REAL, `soilMoist3` REAL, `soilMoist4` REAL, `leafWet1` REAL, `leafWet2` REAL, `rxCheckPercent` REAL, `txBatteryStatus` REAL, `consBatteryVoltage` REAL, `hail` REAL, `hailRate` REAL, `heatingTemp` REAL, `heatingVoltage` REAL, `supplyVoltage` REAL, `referenceVoltage` REAL, `windBatteryStatus` REAL, `rainBatteryStatus` REAL, `outTempBatteryStatus` REAL, `inTempBatteryStatus` REAL);
INSERT INTO archive VALUES(1577833200,16,1,1033.9184870972262242,1019.0710743604474153,1033.3511365830867489,12.5,7.6111111111111124927,64.000000000000003552,88.000000000000007105,0.96561120001789539912,64.555805166451261101,3.2187040000596525146,60.999999999999996447,0.0,0.0,5.7513713696524799701,7.6111111111111124927,7.6111111111111124927,0.0,0.0,0.0,7.600000000000001421,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,88.09999999999998721,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,0.0,5.0499999999999998223,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO archive VALUES(1577833260,16,1,1033.9269017587111587,1019.0790431527625425,1033.3591975949421026,12.5,7.5555555555555526936,64.000000000000003552,87.787878787878774744,1.3167425454789487559,75.18549021140406019,3.2187040000596525146,67.000000000000001776,0.0,0.0,5.6616930498190027876,7.5555555555555526936,7.5555555555555526936,0.0,0.0,0.0,7.5,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,88.200000000000002842,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,0.0,5.0499999999999998223,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
…………….
Crea las tablas e inserta los valores. La comodidad es que puedes editar los valores, copiar y pegar los que quieras o no etc etc con un editor de texto.
Luego se vuelca a la base de datos que se quiera con bbddnueva < archivodump.
Lo más importante de la BBDD de weewx es la tabla archive que son los datos de la estación. Siempre que se tenga se pueden quitar las tablas de diarios (drop-daily) o regenerarlos (rebuild-daily).
Lo normal es lo de insert into etc etc... pero con dump también se puede hacer y sobre todo para unir dos BBDD como he puesto antes. A fin de cuentas es como exportar una base de datos de MySQL con phpmyadmin o con mysqldump en la línea de comandos.
-
Interesante, no lo he usado nunca para unir dos bases de datos.
Saludos
-
Aún no me he 'atrevido' a hacer el volcado de la vieja base de datos en la nueva. Me da cierto reparo pensar que pueda ocurrir alguna inconsistencia y eche por tierra todo el proceso teniendo que volver a reinstalar y empezar de nuevo, aunque por otra parte, no tendré más remedio que armarme de valor ::) y probar si quiero tener todos los registros en una misma base de datos. Si lo consigo dejaré por aquí los pasos y resultados.
un saludo.
-
Creo que para unir dos bases de datos hay que hacer una cosa mas que sacar los dos dump y unirlos ya que al hacer el dump, se crea un fichero de texto con la orden de crear la tabla correspondiente y luego los insert necesarios, al concatenar los dos dump, el primero se ejecutará bien, pero al tratar el siguiente, la tabla se volvería a crear y creo que se borraría lo insertado primero, dejando solo los últimos datos.
Yo creo los dos ficheros de texto del dump, y lo que hago es insertar los datos (las lineas con los insert) al final, y con eso se inserta todo sin problemas.
No hay que temer tener datos duplicados porque la base de datos weewx tiene clave unica y es la fecha y la hora, al tratarse de la misma base de datos, si un registro ya existe no lo inserta.
Para hacerlo utilizo el Notepad++ que es un editor de texto que le da cien patadas al bloc de notas del windows.
Sobre todo insistir en una buena política automatizada y chequeada de copias, lo deseable es el conjunto completo o sea copia física del fichero de la bbdd, y luego sacar exportación y dump o volcado. Con esto nunca nos quedaremos sin algo utilizable y actualizado, que luego con el dataloger completamos para no perder ni un solo dato.
Saludos.
Xavi
-
Sí Xavi... sería lo mejor hacerlo así y nos desentendemos de problemas, errores y resultados inesperados.
Saludos
-
Hola
retomo este hilo. Disculpad que no haya podido comentar antes mi resultado uniendo las dos bases de datos pero solamente quería decir que tras mucho trastear con SQL tuve que abandonar porque me fue totalmente imposible hacer una unión correcta (ya sabéis, que las dos bases de datos copiaran sus tablas a la perfección sin errores, etc etc etc..) finalmente conseguí mi propósito con un pequeño script en Python que realiza la operación sin problemas consiguiendo una única base de datos limpia con clave primaria sin errores (dateTime) y todos los registros de las tablas volcados consecutivamente y sin errores en aquellos que sean NULL (vacíos)
saludos.
-
Comparte el script, compañero😉😉😉
-
Comparte el script, compañero😉😉😉
Hola jantoni,
por supuesto aquí tenéis el script. A mi me ha funcionado a la primera sin problemas, pero no me hago responsable si otro lo intenta y le estropea la base de datos eh? 8)
Las bases de datos que han sido unidas tras el uso de este script pertenecen a la versión de WeeWX 3.9.2Pasos que he seguido sudo /etc/init.d/weewx stop- realizar una copia de seguridad de la base de datos que está actualmente en ejecución. Nos colocamos en la ruta
/var/lib/weewx/ y desde ahí renombramos con mv weewx.sdb weewx_old.sdb/home/pi/ con sudo nano /home/pi/unirbd.py un archivo nuevo que contenga este script
import sqlite3
def number_columns(table_name):
db_2020 = sqlite3.connect('/home/pi/weewx2020.sdb')
db_2020.row_factory = sqlite3.Row
db_cursor = db_2020.cursor()
db_cursor.execute("SELECT * FROM " + str(table_name))
row_1 = db_cursor.fetchone()
db_cursor.close()
return row_1.keys()
db_2019 = sqlite3.connect('/home/pi/weewx2019.sdb')
db_2020 = sqlite3.connect('/home/pi/weewx2020.sdb')
b_cursor = db_2020.cursor()
b_cursor.execute('SELECT name FROM sqlite_master WHERE type ="table" ')
output = b_cursor.fetchall()
a_cursor = db_2019.cursor()
for row in output:
print("Table name: " + str(row[0]))
columnNames = number_columns(str(row[0]))
ques = []
ques = ["?"] * len(columnNames) # Generate list [?, ?, ?, ?,........till length equals length of columnNames[1:]
ques = ",".join(ques) # Generate string "?,?,?,?,?........"
columnNames = ",".join(columnNames) # Generate string "col1, col2, col3............"
b_cursor.execute('SELECT * FROM ' + str(row[0]))
rows = b_cursor.fetchall()
for item in rows:
#print(item)
#print(columnNames)
#print(ques)
#print('INSERT or IGNORE INTO {0}({1}) VALUES ({2})'.format(str(row[0]), columnNames, ques))
a_cursor.execute('INSERT or IGNORE INTO {0}({1}) VALUES ({2})'.format(str(row[0]), columnNames, ques), item)
db_2019.commit()
a_cursor.close()
b_cursor.close()
- desde el terminal ejecutamos el script con
sudo python /home/pi/unirbd.py y en unos segundos debería obrar su magia. Tras la unión de ambas bases de datos movemos la resultante hasta /var/lib/weewx/weewx.sdb procurando poner el nombre original. En esta ruta ahora tendremos weewx.sdb y weewx_old.sdb- arrancar de nuevo WeeWX con
sudo /etc/init.d/weewx start y esperar al siguiente ciclo de escritura en la base de datos para comprobar que todo ha ido bienExplico un poco el contenido del script
como veis de lo que se trata es de unir dos bases de datos, una de 2019 y otra de 2020 (en mi caso la de 2019 iba desde el 17 de junio al 31 de diciembre y la de 2020 iba desde el 1 de enero hasta la fecha en la que hago la unión de ambas) por lo que debo conseguir una base de datos que recoja el periodo desde el 17 de junio de 2019 a la fecha actual, ordenando todos los registros por la clave primaria que en este caso es dateTimePara este escript he renombrado ambas bases de datos. La de 2019 la he llamado weewx2019.sdb y la de 2020 weewx2020.sdb para que esté más claro. Ambas bases de datos las he colocado en misma ruta donde he creado el script.
El script comienza llamando a sqlite3 por lo que debereis comprobar que lo tenéis instalado previo a su ejecución. Si no está instalado simplemente con sudo apt-get install sqlite3 solucionamos este paso. Tras la instalación un sudo apt-get update && sudo apt-get upgrade no vendría mal. Tras la importación de sqlite3, y si esta es exitosa, identifica las columnas (entidades) de las tablas que intervienen en el proceso. Una vez identificadas las entidades establece las conexiones entre ambas bases de datos. En este paso identificará las tablas que corresponden a cada base de datos.
Con toda esta información lo siguiente es definir la base de datos en la que se hará el volcado; en mi caso quiero que se haga en la de 2019 por lo que apunto a ella con a_cursor = db_2019.cursor () Tras este punto comienza el proceso.
-
Muchas gracias.
Por supuesto, el que quiera usarlo, bajo su responsabilidad y haciendo siempre copias de seguridad
-
Buenas
Retomando un poco el tema de las BBDD y viendo que la mía empieza a "engordar" después de 6 años...me preguntaba si es posible o conveniente empezar una nueva por ejemplo anualmente.
Dejar los archivos NOAA generados hasta la fecha y si al empezar y una nueva BBDD estos se mantendrían en weewx y no generarían inconsistencias en meteoclimatic. ???
Saludos
-
No sé muy bien cual es tu objetivo, pero vamos a ello.
Los archivos NOAA los puedes dejar, sin en la base de datos no hay valores para esas fechas, no creo que Weewx los "mate", por si acaso, antes copia de seguridad.
Pero casi seguro que en el menú de selección de visualización, no van a aparecer los informes NOAA que no tenga controlados Weewx.
Para visualizarlos, tendrías que modificar el skin. En Seasons lo tendrías que hacer en:
/etc/weewx/skins/Seasons/titlebar.inc
Incorporando de alguna manera los NOAA antiguos.
En cuanto a inconsistencias no tengo clara la pregunta:
- Si es por los informes NOAA, estos no afectan para nada. Son simples archivos de texto generados a partir de la base de datos.
- Si es por la generación de bases de datos anuales. La respuesta es: bien hecho no.
Las inconsistencias se generan mensualmente y anualmente.
Si lo hiciera yo haría lo siguiente:
- En enero de cada año pararía weewx
- haría una copia de seguridad de la base de datos
- Calcularía el epoch time del primer segundo del nuevo año.
- Eliminaría los registros con epochtime inferior al calculado, en todas las tablas de la base de datos.
- Reiniciaría Weewx.
-
Yo hago esa operación en el cambio de año con la base de datos de weewx con un crontab configurado para que se ejecute el 1 de enero a las 0:01
#!/bin/sh
service weewx stop
cd /var/lib/weewx
mv weewx.sdb "weewx"`date --date='-1 year' +"%Y"`".sdb"
service weewx start
exit
Detiene weewx, cambia el nombre a la BBDD poniéndole el año en el nombre (weewx2019.sdb para este pasado año por ejemplo) e inicia weewx que creará una nueva BBDD (weewx.sdb) que será con la que opere el nuevo año.
Lo hago mayormente porque weewx en mi caso graba cada minuto y se nota al cabo del año (creo que unos 50 MB de BBDD o cosa así).
En cuanto a lo que dice jantoni de los NOOA es cierto, están todos en el directorio /var/www/html/weewx/NOAA pero weewx pondrá en el despegable de su página sólo los que estén en su BBDD actual.
Habría que modificar ese archivo que indica jantoni para que incluyese todos los que hay en ese directorio donde están los NOAA.
-
Es que actualizar cada minuto es "muy bestia" *+* *+* *+* *+* *+* *+* *+*
Al fin y al cabo, si quieres usar los datos dentro de 5 años, vas a usar 3: la máxima, la mínima y la media *-* *-* *-*
-
Así lo tengo en el datalogger de la Davis jantoni … y lo quiero así ya que si por alguna circunstancia tienes que quitar diarios de la base de datos (drop-daily) y regenerarlos (rebuild-daily) te pondrá los valores máx/mín que hayan en los logs, y está claro que habrán más registros en 1 minuto para sacar las máx/mín verdaderas que en 5 ó 10 minutos.
Como es la estación de mi casa y tengo acceso a ella todos los días tener dos días y pico de datalogger no es un inconveniente si tengo todos los minutos. Me sirve para los logs de cualquier programa.
Y creo que la BBDD de weewx con los años se puede hacer enorme y luego moverse por esa base de datos no es fácil. Deberían de haberla creado de otra forma... por años, gestionando sólo el año que esté en curso.
-
Es que cada uno tiene unas necesidades.
Yo no las he tenido. No recuerdo haber tenido que modificar ningún dato desde que empecé con Weewx. Posiblemente alguna vez antes de cambiar la FineOffset antigua por la Davis, pero hace tanto tiempo que no me acuerdo.
Y si, es cierto, la base de datos se hace grande. Si la mía ocupa 132 Megas los últimos 6 años, imagínate, con 1 minuto de actualización estaría cerca de los 700 megas.
-
Buenas
Si ese era mi objetivo...
Mi BBDD tiene unos 110mb de tamaño en 6 años y en ocasiones que hay que regenerar por una instalación nueva o hay "navegar" entre tanta línea para corregir algún dato erróneo pues la cosa hay que tomársela con paciencia.
Yo además,a pesar de la copia de seguridad a menudo,me da miedo que se corrupta la base de datos al tener tantos datos.
La duda es si dejo los archivos noaa de la anterior BBDD para poder acceder a ellos en cualquier momento desde la web,si al generar los nuevos se mantendran los anteriores al no tener weewx datos de donde generarlos... :-\
Entonces un rato igual pruebo y comienzo una nueva BBDD si consigo mantener los noaa anteriores :;
-
Repito que los NOAA que tengas en /var/www/html/weewx/NOAA no los va a borrar weewx.
Weewx genera periódicamente el del mes y año en curso, los pasados cuando los ha terminado de generar a principio del mes o del año ya no los toca porque no los genera y se quedan en esa carpeta.
Esta tarde he modificado el /etc/weewx/skins/Seasons/titlebar.inc de esta manera para que salgan todos los NOAA de ese directorio.
Recomiendo hacer copia del archivo por si hay imprevistos aunque a mí me ha funcionado bien:
## titlebar for weewx skins
## Copyright Tom Keffer, Matthew Wall
## See LICENSE.txt for your rights
#errorCatcher Echo
#encoding UTF-8
<div id="title_bar">
<div id="title">
<h1 class="page_title">$station.location</h1>
<p class="lastupdate">$current.dateTime</p>
</div>
<div id="rss_link"><a href="rss.xml">RSS</a></div>
<div id="reports">
#import re
#set noaa = sorted(os.listdir("/var/www/html/weewx/NOAA"))
$noaa.reverse()
#set tot = []
#for $res in $noaa
$tot.append(re.sub('(NOAA-|\.txt)','',$res))
#end for
Monthly Reports:
<select name="reports" onchange="openTabularFile(value)">
#for $monthYear in $tot
#if re.search('-', $monthYear)
<option value="$monthYear">$monthYear</option>
#end if
#end for
<option selected>- Select Month -</option>
</select>
<br/>
Yearly Reports:
<select name="reports" onchange="openTabularFile(value)">
#for $yr in $tot
#if not re.search('-', $yr)
<option value="$yr">$yr</option>
#end if
#end for
<option selected>- Select Year -</option>
</select>
<br/>
</div>
</div>
Como ejemplo en mi weewx tengo la BBDD como anterioremente he dicho de solamente este año y solo me salían estos meses y ahora me salen todos en los NOAA anuales y mensuales:
http://www.meteoarchena.es/opi/
-
Buenas noches.
Corregir la BBDD cuando ha habido un dato anormal esporádico lo tengo controlado, pero ¿se pueden corregir los gráficos generados que aún permanecen con ese error una vez corregida la BBDD ?
Corregida la parte que yo conozco...
-
Hola miguelru
Weewx vuelve a generar los gráficos cada poco tiempo y los datos con los cuales los genera son los de la BBDD.
Espera a medianoche y deberán de estar todos generados con los cambios.
Saludos
-
Hola miguelru
Weewx vuelve a generar los gráficos cada poco tiempo y los datos con los cuales los genera son los de la BBDD.
Espera a medianoche y deberán de estar todos generados con los cambios.
Saludos
Podéis borrar todo el contenido de var/www/html/weewx/ (no se si es asi o /var/html/www/weewx/ ), en el próximo ciclo weewx genera TODO de nuevo, con los datos antiguos sin perder nada. Por lo menos desde la versión 3.8 que yo tengo en una estación.
-
Si, esta claro. Pero era que no había corregido la tabla "archive"
:;
-
Weewx guarda los datos que graba en cada generación en la tabla archive y los diarios de cada valor en sus tablas archive_day_valor (archive_day_rain por ejemplo)
Que se modifique una no significa que se modifique la otra por lo que si en la tabla archive modificamos valores de temperatura máxima o de lluvia por ejemplo éstos no se van a cambiar en su tabla diaria correspondiente... tendríamos que hacerlo manualmente.
La utilidad wee_database de weewx tiene dos funciones para manejar esto. wee_database --drop-daily borra todas las tablas diarias y para reconstruirlas se hace con wee_database --rebuild-daily.
--drop-daily no suele usarse y para modificar los diarios si solo modificamos un día o varios wee_database --rebuild-daily acepta periodos de fechas para reconstruir.
Más info como siempre en la documentación de weewx:
http://www.weewx.com/docs/utilities.htm#Action_--rebuild-daily
-
Voy ha cambiar próximamente la estación PCE FWS-20, funcionando desde 2015 por una Ecowitt que ya tengo en pruebas y sin problemas. Pero quería aprovechar para cambiar el horario a UTC, aprovechando la base de datos anterior.
Me dijeron, tiempo atrás, que no había ningún problema pues se graba siempre en horario Epoch. Pero yo si encuentro un problema. Weewx genera el registro del día a las 00:00 que con horario local son las 22:00 UTC.
Al poner en marcha weewx con hora UTC a partir de la base datos anterior (se genero en horario Local) provoca que en los NOAA aparezcan registros desde un día antes por los registros a las 22:00 UTC y todos los registros los desplaza un día. Supongo que con datos de lluvia u otros en ese rango de 22:00 a 00:00 cambian los totales diarios.
Lo que me preocupa es que al enviar y cotejar las plantillas no cuadrarán con los datos registrados en Meteoclimatic y tendré miles de inconsistencias. Por que no creo que activando simplemente la pestaña de envío en horario UTC, en mi ficha de estación en Meteoclimatic haga que se adapten los datos registrados desde 2015 y cuadren con la plantilla actual sin generar inconsistencias.
No sé si tiene arreglo mas o menos asumible, si alguien lo ha hecho. Mi nivel en BB.DD. es bajo. ¿Mejor la dejo en horario local para siempre?
Saludos.
PD. He releído hilos y la guía de weewx sobre base de datos sin encontrar respuesta.
-
Bueno, no acabo de entender muy bien el problema.
Veamos. La base de datos está siempre, como dices, en formato epoch, por lo que podernos asumir que es UTC, aunque no lo es al 100%
Modificar el tiempo epoch, es fácil, le sumas a cada registro los segundos que correspondan, una o dos horas. Cambiar registros en SQL es sencillo.
Ahora bien, una cosa es que sea sencillo, y otra cosa es que cambiar una base de datos con miles, o decenas de miles de registros, y cada uno con un "offset" diferente, una o dos horas, no sea tarea de mucho, muchísimo tiempo.
Bueno, en realidad sólo hay que calcular el epoch de los cambios de hora y hacer cambios de registros selectivos.
Pero..... Es meterse en un berenjenal muy gordo *+* *+* *+*
Por meteoclimatic no ese problema, o no lo es tanto
Y ello es porque a meteoclimatic, solo se le informa, en la plantilla de los datos actuales, diarios, mensuales y anuales
Por tanto, solo podría tener inconsistencias en el mes actual y en el año actual.
Nada que no podrías corregir fácilmente, pues estamos a mediados de mes y a primeros de año.
La verdad es que nunca me había planteado el problema. Desde el principio de los principios, siempre he manejado el día con formato UTC y todos mis ordenadores estén en formato UTC, salvo el mierda Windows.
Espero haberte ayudado.....a pesar de que no he dicho nada *+*
-
Veamos, puntualizaciones....si pones weewx en UTC te generará informes, reseteo de máx/mín etc a la 1:00 hora local (0:00 UTC), en horario de verano a las 2:00 hora local.
La gran ventaja de weewx como decís es que los registros de la tabla archive los guarda en epoch, así no pierde ninguno en los cambios de fecha y genera informes, reseteos y demás cosas covirtiéndolos a la zona horaria que tengamos en el sistema.
Siempre, como he explicado en el mensaje anterior de más arriba, se pueden reconstruir las tablas diarias con wee_database --rebuild-daily desde cuando se quieran cambiar como es tu caso. Por ejemplo wee_database --rebuild-daily --from=2021-01-01 recrearía las tablas de diarios con el nuevo horario.
Como siempre las pruebas mejor hacerlas haciendo copia de seguridad de la base de datos antes.
Y como siempre digo menos mal que no vivimos en China por ejemplo. Si allí pones horario UTC la lluvia del día sería la recogida desde las 7 de la mañana hasta las 7 de la mañana del día siguiente, nada que ver con la habría caído en el día local aparte de máximas mínimas de temperatura etc
Aquí con una hora de diferencia en invierno y dos en verano es poca la diferencia pero haberla hayla....por mi parte lo tengo claro y es lo que me gusta de weewx... registros en epoch y generaciones de días en local.
-
Anda mira
Eso no lo sabía. Será porque no he tenido que tocar la base de datos más que una o dos veces....y era cuando estaba con la PCE antigua......aunque creo que era cuando usaba Wview.....
Una magnífica utilidad.
Gracias máster.
-
Vale, creo que esta claro, ha sido fallo mío.
Así lo había hecho (wee_database --rebuild-daily) pero no borre los NOAA que ya tenia generados en /var/www/html/weewx, por lo que al volver a consultarlos no veía ningún cambio.
Esta mañana con la mente mas fresca lo primero que he hecho ha sido borrar esos NOAA y "voila" se han generado los nuevos con la corrección aplicada.
Muchas gracias jmviper plau2
-
Anda mira
Eso no lo sabía. Será porque no he tenido que tocar la base de datos más que una o dos veces....y era cuando estaba con la PCE antigua......aunque creo que era cuando usaba Wview.....
Una magnífica utilidad.
Gracias máster.
Es lo malo que tiene weewx.... que no tienes que trastear cosas a menos que quieras probarlas *-* *-*
Esta mañana con la mente mas fresca lo primero que he hecho ha sido borrar esos NOAA y "voila" se han generado los nuevos con la corrección aplicada.
Es lo bueno de tener ahora mañanas frescas *+* *+*