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.
miércoles, 20 de enero de 2016
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.
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.
sábado, 9 de enero de 2016
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.
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.
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.
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.
- Parar el programa. sudo /etc/init.d/weewx stop
- 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. - 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
- 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:
- stop weewx
- Make a copy of the archive database
cp weewx.sdb weewx-YYMMDD.sdb
- Verify the bad data exist where you think they exist
sqlite3 weewx.sdb sqlite> select dateTime,outTemp from archive where outTemp > 1000;
- See whether the bad temperature and wind data happened at the same time
sqlite> select dateTime,outTemp,windSpeed from archive where outTemp > 1000; - 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;
- Delete the statistics database so that weewx can regenerate it without the anomalies
- start weewx
- 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:
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.
martes, 5 de enero de 2016
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.
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:
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.
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.
Preparando el entorno de pruebas. Segunda Parte.
2016-1-5.
Tras configurar y dejar funcionando el registro de log's del entorno de pruebas, paso a configurar el espacio de pruebas. Esto basicamente se basa en los siguientes puntos:
Tras configurar y dejar funcionando el registro de log's del entorno de pruebas, paso a configurar el espacio de pruebas. Esto basicamente se basa en los siguientes puntos:
- Crear un archivo pruebas.conf basado en el archivo weewx.conf. Este está situado en el directorio /etc/weewx/.
- Editar este archivo para que las páginas que se generen lo hagan en el directorio dedicado a ello. El apartado a modificar es el siguiente:
[StdReport]
# Where the skins reside, relative to WEEWX_ROOT
SKIN_ROOT = /etc/weewx/pruebas
# Where the generated reports should go, relative to WEEWX_ROOT
HTML_ROOT = /mnt/var/www/pruebas - Copiar el directorio Skins completo en otro llamado pruebas, quedará situado en el directorio apuntado por Skin_Root del punto anterior. Esto no es obligatorio, podemos llevarnos todo esto al espacio que nos de la gana tanto de la Sd como del disco duro si lo tuvieramos.
- Crear un espacio Pruebas donde alojar las páginas generadas de prueba y que estas puedan ser servidas por el servidor WEB. En mi caso como tengo todo alojado en el disco duro pues le creo un directorio como apunta en HTML_ROOT del punto 3. Tal como se crea este directorio no se puede ver desde el servidor web, ya que el servidor sirve las páginas desde /var/www. Tengo que crear un enlace simbólico desde el disco duro a la Sd. El comando sería este:
ln -s /mnt/var/www/pruebas/ /var/www/pruebas
De esta manera ya se puede ver desde internet. - Si todo está correcto podemos comenzar a lanzar el primer comando de pruebas:
sudo wee_reports /etc/weewx/pruebas.conf
Si no lanzamos el comando con sudo nos da error de permisos, ya que weewx se instaló y corre bajo root, sus directorios y archivos le pertenecen y aunque son accesibles como lectura no se dejan sobreescribir ya que somo pi o el usuario correspondiente con el que nos logueemos. - Podemos realizar el seguimiento del resultado de la generación de las páginas con el comando:
tail -f /path hacia el archivo log/wee_reports.log
Preparando el entorno de pruebas. Primera parte
2016-1-5.
Bueno pues como de los errores se aprende, tras el último estropicio que ha sido el cargarme la página principal de la estación (index.html), acometo lo que tenía que haber hecho hace ya tiempo.
Con esta entrada documento el principio de lo que voy a llamar el entorno de pruebas o desarrollo, según he estado viendo por internet también se le llama sandbox. Esto creo que es una alegoría a lo que hacen los niños pequeños en los parques, pues eso jugar en un cajón de arena.
Como he aprendido a probar las modificaciones realizadas en la plantilla sobre la marcha sin esperar a que cumpla la temporización por el proceso principal WEEWX, lo primero es separar las acciones y los mensajes generados por ambos procesos diferenciados.
El proceso que lanzo para probar es el WEE_REPORTS. Por tanto lo primero es redirigir los mensajes que genere este proceso a un archivo log independiente para poder visualizarlos y llevar un seguimiento de los resultados.
La tarea de mantener un registro de todos los mensajes la realiza el proceso RSYSLOG del SO.
Este proceso por defecto lee todos los archivos de configuración que se incluyan en su directorio RSYSLOG.D. Bueno pues he copiado el archivo de configuración existente 99-weewx.conf en el archivo 99-wee_reports.conf y lo he modificado quedando de esta manera:
:programname,startswith,"wee_reports" /mnt/var/log/wee_reports.log
:programname,startswith,"wee_reports" ~
El proceso Rsyslog se lanza con el sistema operativo y funciona permanentemente.
Como este archivo se está alimentando continuamente de mensajes y mas si es de pruebas, pues como el resto de los archivos log's lo voy a incluir en la tarea LOGROTATE para que se reciclen de tal manera que cambie de nombre y se compriman cada cierto periodo de tiempo.
Para ello hago algo parecido a lo anterior.
La tarea LOGROTATE por defecto tambien lee todos los archivo *.conf que existen en su directorio /etc/logrotate.d/, por lo que copio el archivo weewx en el archivo wee_reports y lo modifico quedando de la siguiente manera:
/mnt/var/log/wee_reports.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 644 syslog adm
sharedscripts
postrotate
reload rsyslog > /dev/null 2>&1
endscript
}
Con esto mantengo la misma politica sobre los archivos log's que para el resto de aplicaciones.
El proceso Logrotate se lanza con la tarea CRON y es ejecutado cada cierto tiempo según se haya configurado en el demonio CRON. En mi caso se encuentra dentro del directorio cron.daily$, por lo que se lanza diariamente.
Bueno pues como de los errores se aprende, tras el último estropicio que ha sido el cargarme la página principal de la estación (index.html), acometo lo que tenía que haber hecho hace ya tiempo.
Con esta entrada documento el principio de lo que voy a llamar el entorno de pruebas o desarrollo, según he estado viendo por internet también se le llama sandbox. Esto creo que es una alegoría a lo que hacen los niños pequeños en los parques, pues eso jugar en un cajón de arena.
Como he aprendido a probar las modificaciones realizadas en la plantilla sobre la marcha sin esperar a que cumpla la temporización por el proceso principal WEEWX, lo primero es separar las acciones y los mensajes generados por ambos procesos diferenciados.
El proceso que lanzo para probar es el WEE_REPORTS. Por tanto lo primero es redirigir los mensajes que genere este proceso a un archivo log independiente para poder visualizarlos y llevar un seguimiento de los resultados.
La tarea de mantener un registro de todos los mensajes la realiza el proceso RSYSLOG del SO.
Este proceso por defecto lee todos los archivos de configuración que se incluyan en su directorio RSYSLOG.D. Bueno pues he copiado el archivo de configuración existente 99-weewx.conf en el archivo 99-wee_reports.conf y lo he modificado quedando de esta manera:
:programname,startswith,"wee_reports" /mnt/var/log/wee_reports.log
:programname,startswith,"wee_reports" ~
El proceso Rsyslog se lanza con el sistema operativo y funciona permanentemente.
Como este archivo se está alimentando continuamente de mensajes y mas si es de pruebas, pues como el resto de los archivos log's lo voy a incluir en la tarea LOGROTATE para que se reciclen de tal manera que cambie de nombre y se compriman cada cierto periodo de tiempo.
Para ello hago algo parecido a lo anterior.
La tarea LOGROTATE por defecto tambien lee todos los archivo *.conf que existen en su directorio /etc/logrotate.d/, por lo que copio el archivo weewx en el archivo wee_reports y lo modifico quedando de la siguiente manera:
/mnt/var/log/wee_reports.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 644 syslog adm
sharedscripts
postrotate
reload rsyslog > /dev/null 2>&1
endscript
}
Con esto mantengo la misma politica sobre los archivos log's que para el resto de aplicaciones.
El proceso Logrotate se lanza con la tarea CRON y es ejecutado cada cierto tiempo según se haya configurado en el demonio CRON. En mi caso se encuentra dentro del directorio cron.daily$, por lo que se lanza diariamente.
domingo, 3 de enero de 2016
Error en la generación de la página web
2016-1-3. Error generando la página web.
Modificando el template he tenido que hacer algo que me está generando un error y se sale del proceso de generación por lo que la página no se genera.
Este es el error que me da:
Modificando el template he tenido que hacer algo que me está generando un error y se sale del proceso de generación por lo que la página no se genera.
Este es el error que me da:
Jan 3 22:21:25 raspberrypi weewx[24064]: cheetahgenerator: Generate failed with exception '<type 'exceptions.TypeError'>'
Jan 3 22:21:25 raspberrypi weewx[24064]: cheetahgenerator: **** Ignoring template /etc/weewx/skins/Standard/index.html.tmpl
Jan 3 22:21:25 raspberrypi weewx[24064]: cheetahgenerator: **** Reason: tuple indices must be integers, not str
Jan 3 22:21:25 raspberrypi weewx[24064]: **** Traceback (most recent call last):
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "/usr/share/weewx/weewx/cheetahgenerator.py", line 295, in generate
Jan 3 22:21:25 raspberrypi weewx[24064]: **** print >> _file, text
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in __str__
Jan 3 22:21:25 raspberrypi weewx[24064]: **** rc = getattr(self, mainMethName)()
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "cheetah__etc_weewx_skins_Standard_index_html_tmpl_1451856084_5_93744.py", line 1537, in respond
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "cheetah__etc_weewx_skins_Standard_index_html_tmpl_1451856084_5_93744.py", line 672, in __errorCatcher87
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "<string>", line 1, in <module>
En este momento todavía no he averiguado que es lo que provoca el error, está claro que es el archivo index.html.tmpl ya que lo he cambiado por el que trae la distribución y no provoca el error.
Página para la generación de scripts para la sindicación de Feeds RSS
2016-1-3.
He encontrado la siguiente página Web para la generación de scripts y poder incluirlos en página web. Así podré tener los titulares de un blog por ejemplo. En mi caso mi blog en el que llevo todo lo referente a mi estación meteorológica y todo lo que relacionado con ella.
La dirección de la web es la siguiente:
http://rss.sindicacion.net/
He encontrado la siguiente página Web para la generación de scripts y poder incluirlos en página web. Así podré tener los titulares de un blog por ejemplo. En mi caso mi blog en el que llevo todo lo referente a mi estación meteorológica y todo lo que relacionado con ella.
La dirección de la web es la siguiente:
http://rss.sindicacion.net/
Modificación de la ubicación de la página WEB
2016-1-3. Cambio de la ubicación de los archivos de la página WEB.
Para minimizar los accesos a la tarjeta SD de la Raspberry pi, redirecciono la generación de los archivos del programa weewx al directorio /mnt/var/www/ del disco duro.
Para no tocaar la configuración del servidor Apache creo un enlace simbólico del archivo /var/www/weewx a la ubicación de los archivos de la página web /mnt/var/www/ para que se sirva la página web.
La dirección de acceso a la página web sigue siendo la misma.
Para minimizar los accesos a la tarjeta SD de la Raspberry pi, redirecciono la generación de los archivos del programa weewx al directorio /mnt/var/www/ del disco duro.
Para no tocaar la configuración del servidor Apache creo un enlace simbólico del archivo /var/www/weewx a la ubicación de los archivos de la página web /mnt/var/www/ para que se sirva la página web.
La dirección de acceso a la página web sigue siendo la misma.
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.
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:
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:
- Acceso remoto de Windows, instalando el servidor Remote Desktop Protocol XRDP en Raspberry y el cliente de Conexión de Acceso Remoto para Mac.
- Acceso VNC, instalando el Servidor TightVncserver en Raspberry y el cliente VNC viewer en Mac.
- Acceso X11 con la aplicación XQuartz de Mac OSX.
Archivos Log's en Raspberry. Apache2 y Weewx
2016-1-1. Para minimizar los accesos continuos sobre la SD de la Raspberry, dirigí el archivado de los archivos Log's de las aplicaciones Apache y Weewx al disco duro que tengo instalado en un puerto Usb de la Raspberry. Este lo tengo montado en /mnt/var/log/
A día de hoy el archivado se está realizando correctamente en el disco duro.
A día de hoy el archivado se está realizando correctamente en el disco duro.
-rw-r--r-- 1 root adm 1228789 ene 1 17:06 weewx.log
-rw-r--r-- 1 root root 406596 ene 1 16:55 access.log
..etc.
Modificación rango de temperatura Weewx.conf, apartado StdQc
2016-1-1. Debido a la recepción errónea esporádica de valores extremos de temperatura, modifico el rango de temperatura en el archivo weewx.conf en su apartado de control de calidad StdQc.
dejo los valores acotados entre -10º y 49º de mínimo y máximo. Considero que en esta localización nunca debemos de superar esos márgenes por lo que no son aceptables valores como los que sin saber porque mi estación manda esporádicamente. Espero que con esta modificación queden resueltos estos errores. De momento no se como afectará esta modificación al funcionamiento del programa.
La modificación queda como a continuación:
dejo los valores acotados entre -10º y 49º de mínimo y máximo. Considero que en esta localización nunca debemos de superar esos márgenes por lo que no son aceptables valores como los que sin saber porque mi estación manda esporádicamente. Espero que con esta modificación queden resueltos estos errores. De momento no se como afectará esta modificación al funcionamiento del programa.
La modificación queda como a continuación:
El valor original de temperatura mínima era de -40ºF, que son -40ºC. Lo dejo en 14ºF que son -10ºC. El resto queda tal como estaba.
# This section is for quality control checks. If units are not specified,
# values must be in the units defined in the StdConvert section.
[StdQC]
[[MinMax]]
barometer = 26, 32.5, inHg
outTemp = 14, 120, degree_F
inTemp = 10, 120, degree_F
outHumidity = 0, 100
inHumidity = 0, 100
windSpeed = 0, 120, mile_per_hour
Imagen que muestra el error esporádico que recibo:
Incidencia en la garita de platos.
2016-1-1. La pintura no ha agarrado bien y se está yendo.
Bueno pues lo que me temía está ocurriendo antes de lo que me esperaba, bueno no tan antes. A la primera de cambio, sufriendo la intemperie y con una lluvia de lo mas ligera y sin apenas viento, el plato superior ya está empezando a descascarillarse. Ya tiene una superficie notable sin pintura.
Esto no tiene mas remedio que volver a desmontar y retomar la pintura con otra forma de aplicación que garantice su agarre o con otra imprimación. Ya lo veremos.
En definitiva, el tema de la pintura fracaso absoluto.
Bueno pues lo que me temía está ocurriendo antes de lo que me esperaba, bueno no tan antes. A la primera de cambio, sufriendo la intemperie y con una lluvia de lo mas ligera y sin apenas viento, el plato superior ya está empezando a descascarillarse. Ya tiene una superficie notable sin pintura.
Esto no tiene mas remedio que volver a desmontar y retomar la pintura con otra forma de aplicación que garantice su agarre o con otra imprimación. Ya lo veremos.
En definitiva, el tema de la pintura fracaso absoluto.
Suscribirse a:
Entradas (Atom)