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.

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.

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.

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/

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..

Vuelta a la vida de la estación meteorológica y todo lo que conlleva.

25-8-2016.

Retomando el tema de la estación, me la he traído al trabajo y la he puesto de momento sobre un trípode con un mástil. El hecho de hacer esto es porque así la puedo ir moviendo de ubicación para encontrarle el mejor sitio y que a la unidad interior le llegue bien los datos por RF.
Creo este último sitio es bueno ya que llegan bien los datos y en toda esta semana no he tenido pérdida de ellos, se encuentra en un lugar despejado y tengo soporte para poder cambiarla y quitarla del trípode.
Desde el 18 que la puse en marcha he tenido tres incidencias, una leve y otra jodida ya que es de dominio general y por lo visto algo innato en este modelo de estación meteorológica, la tercera todavía la estoy investigando ya que no entiendo porque ha ocurrido.

1. Una vez situada en el trípode y puesto este en un soporte móvil, debido al desplazamiento por terreno irregular el pluviómetro ha sido sometido a sacudidas e inevitablemente ha contado lluvia inexistente. Esto es fácilmente subsanable. Se accede a la BD y se borran los datos.
2. Este otro son los famosos spikes que cada cierto tiempo suele dar esta estación. Como no está claro por que ocurre, yo por si acaso he cambiado el USB donde lo tenía conectado y lo he puesto directamente a la Rpi. Estaba en uno de la placa de extensión que le tengo puesto a la Rpi. El resto volver a a acceder a la BD y quitar los datos incoherentes.
3. Este último no entiendo porque ha pasado, de buena a primera el barómetro tiene una caída de 3,3 mBar. No se porque ha pasado esto, no es un spike... ha mantenido ese desfase y continúa midiendo en ese rango. Creo que ha tenido que ver con el cambio de altura que le he corregido al haberla cambiado de ubicación. Tendré que volver a calibrar el barómetro, tampoco es algo complicado. Intentaré corregirlo cuanto antes.
   NOTA.- Justo, la corrección de altura aplicada esta mañana al pasar de 45m que estaba antes a los 7 que está ahora son los 3 mBares de diferencia.

 Para colmo esta misma mañana he creado un post en meteoclimatic para solicitar que me levanten el castigo y liberen la presentación de datos al haber corregido los defectos. Ahora me dirán que siguen los datos mal y con razón...

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

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

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

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

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

Corrección de incongruencias en datos de la BBDD.

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

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

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

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

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

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

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:

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.

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.

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:

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.