jueves, 24 de noviembre de 2016

Hoy he vuelto a detectar que la estación meteorológica ha vuelto a quedarse parada. Es el mismo fallo de la última vez. El mensaje del log WEEWX es este:
****PENDIENTE DE PONER******

La solución pasa por desconectar y volver a conectar el cable USB de la estación en la raspberry. En ese momento vuelve a recuperarse la comunicación entre ambos dispositivos.
Estos son los mensajes de la raspberry tras volver a reconocer el dispositivo.
Nov 25 08:00:57 raspberrypi kernel: [1721944.958689] usb 1-1.2.2: USB disconnect, device number 13
Nov 25 08:01:01 raspberrypi kernel: [1721948.479093] usb 1-1.3: new low-speed USB device number 14 using dwc_otg
Nov 25 08:01:01 raspberrypi kernel: [1721948.625362] usb 1-1.3: New USB device found, idVendor=1941, idProduct=8021
Nov 25 08:01:01 raspberrypi kernel: [1721948.625403] usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Nov 25 08:01:01 raspberrypi kernel: [1721948.668760] hid-generic 0003:1941:8021.0005: hiddev0,hidraw0: USB HID v1.00 Device [HID 1941:8021] on usb-20980000.usb-1.3/input0
Esto realmente no nos dice nada del problema pero lo aporto como información.

Tras recuperar la comunicación comienza el volcado de datos pendiente. Este tema lo tiene bien resulto el programa WEEWX y afortunadamente no hay mucha pérdida de datos siempre que el periodo entre que se pierde la comunicación y vuelve la comunicación no exceda del tamaño del buffer de la estación meteorológica. Una vez puesta al dia la base de datos se genera la página web y volvemos a recuperar el interfaz visual de la estación.

domingo, 6 de noviembre de 2016

Incidencia en la estación meteorológica

He detectado por la página web que la estación se encuentra parada. Tras investigar y revisar los logs del programa weewx, he comprobado que ha dejado de recibir datos de la estación meteorológica. Esto es algo que suele ocurrir también de vez en cuando. No se porque deja de recibir datos por el enlace USB entre la estación y la Raspberry. Este fallo suele ser poco grave ya que la estación meteorológica sigue almacenando en Hardware los datos meteorológicos y en el momento que se restablece el enlace de datos el propio software WEEWX comienza a descargar los datos que tiene pendiente y actualiza la base de datos.
Hasta ahora la solución pasa por desconectar el cable USB entre la estación y la raspberry y volviéndolo a conectar. En la mayoría de las veces suele quedar bien a la primera, hoy por ejemplo no ha funcionado y he tenido que cambiarlo de USB en la raspberry. En esta segunda ocasión se ha quedado bien y ha comenzado a descargar ya todos los datos pendientes de la consola de la estación.
El único problema que tiene este tipo de incidencias es que la actuación debe de realizarse  in-situ, por lo que si no estoy cerca es imposible de subsanar. Por ello y como me ha pillado el puente que no he estado al lado de la estación, en esta ocasión se ha retrasado un poco la resolución de la incidencia.
Según la página web, se ha quedado parada el dia 2 a las 00:00 aproximadamente. Como toma datos cada 300 segundos o 5 minutos, esto es 288 registros cada dia por 5 dias, son unos 1440 registros los que tiene pendientes de actualizar. Además esta acción es por duplicado ya que tiene que actualizar la base de datos de DAILY y la de SUMMARY. Por tanto esta actualización se lleva un buen rato. Como ahora mismo está trabajando, cuando acabe de actualizarse tomo los datos de tiempo y los pongo aquí para tener una referencia de lo que tarda el proceso.

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.

lunes, 29 de agosto de 2016

Hoy he situado la estación en su ubicación definitiva. He quitado el mástil del trípode móvil y lo he fijado a una de las estructuras metálicas del patio.
Pongo unas fotos para ilustrar la instalación.
Al realizar el cambio, obviamente el pluviómetro ha contado, con las mismas he borrado de la base de datos esa anotación poniéndola a cero, he borrado los daily de la base de datos y al arrancar de nuevo el programa se han actualizado quedando como estaba antes de su movimiento.
He solicitado también la reactivación en  Meteoclimatic.
Ya solo queda esperar que funcione eficazmente, hasta la próxima incidencia.






Es todo por el momento.

domingo, 28 de agosto de 2016

Resolviendo incidencias...continuación.

Tras resolver el tema de las inconsistencias de la lluvia y solicitar la reactivación o levantamiento de la restricción del sensor de lluvia, resulta que me comunican que el anemómetro está subiendo datos erróneos. En este caso debido a que la unidad configurada en weewx es m/s y la subida de datos a meteoclimatic requiere que los datos y la unidad sea en Km/h.
Tras investigar averiguo que hay que cambiar la unidad en el apartado units del StdReport del archivo WEEWX. Efectivamente estaba configurado en m/s, lo cambio a Km/h y tanto en la página web como en los datos de Meteoclimatic ya aparecen en Km/h y con valores coherente en comparación a las estaciones circundantes.
A pesar de todo me indican que cuando acabe con todas las pruebas y la estación se encuentre en su ubicación definitiva solicite la reactivación de la estación.
Así que hasta que no esté todo ok no vuelvo a pedirlo.
Creo que mañana podré ubicar el mástil en una estructura sólida.
De todas maneras todas las incidencias parece que se van resolviendo y la estación va funcionando de manera mas fina. Al menos los datos observados se corresponden con las estaciones cercanas que ya es mucho.


Es todo por el momento.

viernes, 26 de agosto de 2016

Nueva incidencia del sistema...

Esta vez y no será la última, la culpa no es de la estación ni de la raspberry.
Esta vez la culpa la ha tenido el FTTH. Escapándose de mi control, el FTTH donde está ahora conectado no tiene la dirección IP fija, si es cierto que no cambia todos los días. Desde que la puse no ha cambiado, pero esta mañana no accedía al servidor web y meteoclimatic no tenía datos. Tras investigar descubrí que había cambiado la IP pública.
Bueno pues ante este incidente no queda mas remedio que tirar de un DNS dinámico.
Como ya tengo cuenta en DnsDynamic y registrado el dominio para la raspberry pues no tengo mas que reutilizarlo. Ahora bien, para la actalualización de la IP en el servidor he instalado en la Raspberry el cliente DDclient.  No tiene mas historia que instalarlo con:

sudo apt-get install ddclient

Durante la instalación te pide datos para su funcionamiento. Aunque se los demos después hay que editar el archivo /etc/ddclient.conf para actualizar unos parámetros.
Este es el archivo que uso.
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
daemon=900-->El tiempo que quieres que tarde en actualizar la IP en segundos.
protocol=dyndns2
use=web, web=http://myip.dnsdynamic.org/---> Esto es lo que hay que cambiar. El original coge la ip del interfaz ethernet y esa dirección es privada y no sirve, como no lo hagas te quedas tirado sin acceso desde remoto.
server=www.dnsdynamic.org
login=tuemail@elquesea
password='tupassword'

tudomino.dnsdynamic.com

Con esto ya no debería de tener mas este problema.
Ya vendrán otros.

P.D. ; No se han hecho esperar. Todo está configurado correctamente y el daemon de la raspberry actualiza correctamente la IP pública en el servidor, pero el servidor no devuelve la dirección¡¡¡¡¡.....parece que es un problema de DnsDynamic. Quiero recordar que ya hace tiempo ocurría y por eso lo abandoné. Otra cosita mas....buscar un servicio de DNS dinámico que funcione y que sea gratuito.

P.D.2; Como Dnsdynamic no me presentaba la página, me he registrado en Dynu.com y esta si que funciona. Así que ya tengo DNS dinámico y ya se puede encontrar la página y la plantilla si cambia la IP. Al menos eso espero.
http://ulisespi.dynu.com/weewx/



jueves, 25 de agosto de 2016

Resolviendo incidencias comunicadas por METEOCLIMATIC

Bueno, tras solicitar el levantamiento de la sanción por subir datos erróneos a la web de Meteoclimatic, me comunican que debo de corregir los datos de YPCP y MPCP, estos son los acumulados anuales y mensuales de precipitación que estaban idos de madre y se estaban subiendo a meteoclimatic en la plantilla de actualización de datos.
He buscado los datos que disparaban estos acumulados y los he puesto a cero que es como debería de estar. Una vez actualizada la BD le he dado el comando de borrar los resúmenes diarios y arranco WEEWX, este lo primero que hace es ver que no tiene los resúmenes y se pone a crearlos. Este trabajo tarda un buen rato.
Esto ha sido lo que ha tardado:
Aug 25 22:59:23 raspberrypi weewx[29559]: manager: Created daily summary tables
Aug 25 22:59:23 raspberrypi weewx[29559]: engine: Using binding 'wx_binding' to database 'weewx.sdb'
Aug 25 22:59:23 raspberrypi weewx[29559]: engine: Starting backfill of daily summaries

Aug 25 23:46:56 raspberrypi weewx[29559]: engine: Processed 192086 records to backfill 697 day summaries in 2853.28 seconds
La pobre Raspberry se pone a tope, se nota que le duele...con el comando TOP se puede ver que PYTHON (WEEWX) le ocupa todo el tiempo de proceso. No vendría mal que Tom Keffer le hubiera puesto un indicador de proceso a este comando.
Por cierto, mira yo que oportuno que me pongo a realizar este trabajo y da la casualidad que se pone a llover. Espero no perder la captura de esta lluvia..