Autor Tema: Minimizar la pérdida de datos del último cuarto de hora del día  (Leído 39424 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #45 en: 11 de Septiembre del 2016, 13:24:23 pm »
En cuanto al retraso en la actualización de los mapas (que es algo que particularmente me incomoda mucho, pero que tampoco me causa mayor trastorno) animo al lector a calcular el número de mapas que genera Meteoclimatic cada quince minutos, cada hora, cada día...

Y yo lo entiendo. Mi intención era manifestar e informar de algo que me llamaba la atención y que según parece era conocido.

Pero quizá me llama más la atención la diferencia tan alta de temperaturas máximas entre Estaciones próximas y a la misma hora, que se produce entre las 00:00 CEST y las 02:00 CEST con sus respectivos retrasos, motivada por la diferencia de hora establecida por cada Estación (UTC o CEST), que implica que las que establecen la hora CEST están dando la temperatura máxima del nuevo día, y las que establecen la hora UTC estan dando la temperatura máxima del dia anterior desde el punto de vista de las primeras (esto lo he analizado y sabido despues de que llamara mi atención).

Y entiendo que es todavía mas complicada la solución de este hecho, que reducir el retraso en la actualización de los mapas, aunque no imposible.

Saludos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado jantoni

  • Investigación
  • Hero Member
  • ******
  • Mensajes: 3.835
    • Ver Perfil
  • Estación: ESMAD2800000028522A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #46 en: 11 de Septiembre del 2016, 23:14:18 pm »
Ya lo hemos dicho muchas veces.....pero otra tampoco viene mal.

Fijarse mucho en las estaciones cercanas, no es bueno, no es sano y al final uno se puede obsesionar, cuando las diferencias de temperatura pueden ser reales.

Fijaros en las diferencias que hay entre las 3 estaciones de Rivas-Vaciamadrid.....y las 3 temperturas son correctas.

En definitiva, las estaciones cercanas solo valen como referencias.....

Bueno.....en la presión, si tu vecino tiene bien calibrada la presión, es otra historia
« Última modificación: 11 de Septiembre del 2016, 23:17:25 pm por jantoni »

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #47 en: 12 de Septiembre del 2016, 11:24:56 am »
No quiero polemizar en absoluto pero creo que te estas refiriendo a diferencias debidas a las diferentes calibraciones e instalaciones de las Estaciones, a causas naturales e inevitables.
Yo me estaba refiriendo a diferencias de 15°C o mas.

Saludos jantoni.
« Última modificación: 12 de Septiembre del 2016, 11:37:33 am por Amon-K »
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado jantoni

  • Investigación
  • Hero Member
  • ******
  • Mensajes: 3.835
    • Ver Perfil
  • Estación: ESMAD2800000028522A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #48 en: 12 de Septiembre del 2016, 15:58:30 pm »
Totalmente de acuerdo, no te había entendido correctamente.

Controlar 1600 estaciones de firma totalmente artesanal,  es decir leyendo la pantalla,  es complicado,  muy complicado

Pero podemos tener vuestra ayuda,  bien con el sistemas de comunicación de errores que hay integrado en cada estación,  o bien por correo a meteoclimatic@meteoclimatic.com

Saludos

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #49 en: 12 de Septiembre del 2016, 23:25:16 pm »
Bien, lo informaré a esa dirección de correo a ver si allí le ven solución.

Saludos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado B.Santiago

  • Moderador Global
  • Hero Member
  • ******
  • Mensajes: 1.997
    • Ver Perfil
  • Estación: Ávila- La Colilla [ESCYL0500000005192A]
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #50 en: 14 de Septiembre del 2016, 08:24:53 am »
Ya veo que estamos de acuerdo en casi todo.
Es una magnitud, y como tal es ponderable.
Su unidad el segundo (s)
Y como aquello de san Agustín: " Si no me lo preguntan..." etc.
[img width=180

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #51 en: 14 de Septiembre del 2016, 19:45:43 pm »
San Agustín vivió intensamente y seguro que sabía muy bien lo que tenía que responder. Yo solo soy un aprendiz y estoy aprendiendo que lo importante no es discutir sino dialogar.

Saludos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #52 en: 21 de Octubre del 2016, 02:43:31 am »
El pasado día 12 de Octubre llegaron las tan deseadas lluvias al Sur, y casualmente llovió en los últimos minutos del día (horario UTC) lo cual me va a permitir escribir esta "Crónica de una Inconsistencia Anunciada".

Como recordatorio, Meteoclimatic actualiza datos en los minutos 06, 21, 36 y 51 de cada hora.

Actualmente yo tengo configurado la raspi para que envíe el registro de las 00:00h y no envíe el siguiente registro de las 00:05h para que cuando Meteoclimatic actualice a las 00:06h lo haga con el registro de las 00:00h.

Hasta las 23:50h del día 12 habían caído 12,6mm por lo que Meteoclimatic a las 23:51h tenía como precipitación acumulada esta cifra. Entre las 23:50h y las 00:00h cayeron 0,4mm más. Cuando Meteoclimatic a las 00:06h actualizó, como considera este registro como perteneciente al día siguiente (día 13), tomó, erróneamente, como precipitación del día 13 los 13mm del registro de las 00:00h, y como Episodio Precipitación 25,6mm (2 días), (12,6 + 13 = 25,6).

Todo esto es lo que nos muestra la imagen adjunta de la página web Meteoclimatic de mi Estación tomada pocos minutos despues de las 00:06h del día 13.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #53 en: 21 de Octubre del 2016, 02:47:11 am »
Entre las 00:00h y las 00:20h cayeron otros 0,4mm por lo que en la siguiente actualización, a las 00:21h, Meteoclimatic toma correctamente, como precipitación del día 13 estos 0,4mm, pero ignora los primeros 0,4mm (los caídos entre las 23:50 y las 00:00h) ya que toma ahora como Episodio Precipitación 13mm (2 días)
   
Adjunto la imagen de la página web Meteoclimatic de mi Estación tomada pocos minutos despues de las 00:21h del día 13, donde aparecen estos datos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #54 en: 21 de Octubre del 2016, 02:49:11 am »
Como comprobación de lo dicho anteriormente, adjunto una imagen de la ficha Mis Datos de la Estación tomada poco despues de la anterior. Efectivamente se han perdido los primeros 0,4mm.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #55 en: 21 de Octubre del 2016, 02:51:06 am »
Terminado el Episodio de Precipitación (3 días) podemos comprobar, en la imagen adjunta, que la suma de la precipitación de cada día (12,6 + 0,8 + 2,8) no coincide con la precipitación del mes de Octubre (16,6).
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #56 en: 21 de Octubre del 2016, 02:53:11 am »
Sin embargo la inconsistencia no aparece todavía. La inconsistencia aparecerá, si no se corrige antes, cuando termine el mes. Pero como Weewx ha considerado los datos del registro de las 00:00h correctamente, solo tenemos que consultar el informe NOAA para corregir fácilmente la inconsistencia. Véase en la imagen adjunta.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #57 en: 21 de Octubre del 2016, 03:09:42 am »
Todo esto nos muestra que los datos del registro de las 00:00h no se tienen en cuenta para el día que termina porque Meteoclimatic considera erróneamente que pertenecen al siguiente día, y lo que realmente ocurre es que esos datos se pierden, y precisamente en él es donde están los maximos y minimos de temperatura, humedad y presión, el máximo de viento y el acumulado de precipitación, definitivos todos ellos, del día que termina. Lo que ha pasado con la precipitación, podría coincidir que ocurriera con cualquiera de los otros datos.


Para solucionar todo esto me voy a atrever a pedir a Meteoclimatic que estime las siguientes consideraciones:

1ª. Que considere el registro de las 00:00h perteneciente al día que termina.

2ª. Que las actualizaciones que se realizan actualmente en los minutos 06, 21, 36 y 51 de cada hora se trasladen a los minutos 01, 16, 31 y 46, o lo más cercano posible a estos minutos de tal manera que permita que todo el software de gestión de Estaciones envíe, previamente a la actualización correspondiente, el registro de las 00:00h. (Así nos aseguramos que el registro de las 00:00h y no el siguiente, será considerado para la actualización)

Que se sugieran configuraciones para cada software que aseguren que el registro de las 00:00h se envíe y además se envíe lo más pronto posible.


Yo sé que parte de esto implica modificar el código de Meteoclimatic, y no puedo valorar cuánta dificultad entraña, pero creo que Meteoclimatic debería hacer todo lo posible para no despreciar los datos que recibe, sobre todo pensando en que se nos pide ser meticulosamente estrictos con la información que enviamos a Meteoclimatic.

Saludos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado jmviper

  • Investigación
  • Hero Member
  • ******
  • Mensajes: 4.403
  • "Vortex Complex"
    • Ver Perfil
    • www.meteoarchena.es
  • Estación: Archena - ESMUR3000000030600B
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #58 en: 21 de Octubre del 2016, 07:41:19 am »
Buenas Amon-K

El problema es enviar en una plantilla con hora 0:00 los datos del día de ayer. Meteoclimatic o cualquier script PHP, software etc siempre va a considerar las 0:00 como del nuevo día y por lo tanto en él los datos deben de estar reseteados. El último minuto del día son las 23:59 (o para ser más exactos en segundos 23:59:59).

Los programas gestores de estaciones meteorológicas hacen (si lo tienes así programado) su reseteo diario a las 0:00. Por ejemplo con WD si yo envío la plantilla de las 0:00 me saldrán los valores reseteados y si envío (como es lo que hago) la plantilla de las 23:59 mando los últimos datos del día anterior (hay un minuto que no entra pero es difícil que en ese minuto se dé algún cambio).

Si como tú estas exponiendo le pones a meteoclimatic como lluvia del día (la plantilla de las 0:00) esos 13 mm y como lluvia del día anterior los 12.6 mm es normal que te saque esos 25.6 mm en el episodio de precipitación y si en el día de hoy le estás poniendo 0.4 mm más los 12.6 mm que meteoclimatic consta que hubieron en el día de ayer es normal que salgan esos 13 mm. Los números cuadran porque 2 + 2 son 4 siempre para un programa informático.

Resumiendo: no conozco ningún programa meteorológico que envíe con hora 0:00 los valores máx/mín del día de ayer (ni WD ni Cumulus que son los que yo uso aunque parece ser que con weewx sí se puede hacer  ::)) por lo que poner tus sugerencias en práctica me parece bastante difícil.

Saludos


Archena, Valle de Ricote (Murcia). 120 msnm. 19.622 hab.
Davis Vantage Pro2 Plus

www.meteoarchena.es

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #59 en: 21 de Octubre del 2016, 10:57:26 am »
Buenos días jmviper.

Gracias por tu rápida respuesta, el tema es un poco árido.

Voy a intentar dar mi visión de todo lo que me dices.

El problema es enviar en una plantilla con hora 0:00 los datos del día de ayer. Meteoclimatic o cualquier script PHP, software etc siempre va a considerar las 0:00 como del nuevo día y por lo tanto en él los datos deben de estar reseteados. El último minuto del día son las 23:59 (o para ser más exactos en segundos 23:59:59).

Weewx lo hace espontáneamente, yo no he hecho nada. ¿Has comprobado que hace WD?. Yo suponía lo mismo que tú, hasta que lo comprobé, y resulta que no, que en ese registro van los datos correspondientes al intervalo entre ese registro y el anterior. De otra manera se perderían, y esto no tendría sentido.
Por otro lado yo diría que el último minuto va desde las 23:59 a las 00:00, y el último segundo va desde las 23:59:59 a las 00:00:00 (es verdad que acostumbramos a denominar, por ejemplo, un minuto con la cifra que representa su final, pero no hay que olvidar que en realidad es un intervalo de tiempo).
¿En el registro de las 00:00 van datos del día siguiente?, ¡pero si no ha transcurrido ni siquiera un segundo de ese día!. Por reducción al absurdo hay que considerarlo como perteneciente al día que termina.

Los programas gestores de estaciones meteorológicas hacen (si lo tienes así programado) su reseteo diario a las 0:00. Por ejemplo con WD si yo envío la plantilla de las 0:00 me saldrán los valores reseteados y si envío (como es lo que hago) la plantilla de las 23:59 mando los últimos datos del día anterior (hay un minuto que no entra pero es difícil que en ese minuto se dé algún cambio).

No puedo hablar de WD, no lo conozco, pero ¿qué impide resetear justo despues de ese momento para no perder esos datos?. Hay que hacer lo que responda a la realidad o al menos intentarlo y acercarse lo más posible. Piensa que si reseteas a las 00:01 no pierdes absolutamente nada porque la Estación en el siguiente registro incluirá los máximos, mínimos y acumulados del intervalo entre registros que sigue a las 00:00.
Por otro lado, suponiendo que tienes configurada la Estación para registrar datos cada 5 minutos que es lo normal, la plantilla de las 23:59 por lógica está enviando los datos del registro de las 23:55, con lo cual estas perdiendo datos de los últimos 5 minutos del día, suponiendo que esa plantilla sea la que lea Meteoclimatic, porque si no es así estarás perdiendo un intervalo mayor.

Si como tú estas exponiendo le pones a meteoclimatic como lluvia del día (la plantilla de las 0:00) esos 13 mm y como lluvia del día anterior los 12.6 mm es normal que te saque esos 25.6 mm en el episodio de precipitación y si en el día de hoy le estás poniendo 0.4 mm más los 12.6 mm que meteoclimatic consta que hubieron en el día de ayer es normal que salgan esos 13 mm. Los números cuadran porque 2 + 2 son 4 siempre para un programa informático.

Creo que no lo he explicado suficientemente. Yo no le he puesto nada a la plantilla de las 00:00, weewx ha enviado la realidad, 12,6mm caídos hasta las 23:50 más 0,4mm caídos entre las 23:50 y las 00:00 son los 13mm enviados. Meteoclimatic en ese momento al considerar que esa plantilla pertenece al día siguiente ha sumado erróneamente los 12,6mm (lo caído anteriormente en el día que termina) con las 13mm (total del día que termina enviado en la plantilla de las 00:00), y por eso coloca como Episodio Precipitación los 25,6mm. Sin embargo la realidad es que en ese momento en el día que termina han caído 13mm y en el día que empieza han caído 0mm, luego la suma es 13mm. De esta manera si cuadran los números.

Resumiendo: no conozco ningún programa meteorológico que envíe con hora 0:00 los valores máx/mín del día de ayer (ni WD ni Cumulus que son los que yo uso aunque parece ser que con weewx sí se puede hacer  ::)) por lo que poner tus sugerencias en práctica me parece bastante difícil.

Repito, Weewx lo hace espontáneamente y por otro lado lógicamente como ya hemos visto. Por los demás programas no puedo hablar pero si no lo hacen, deberían hacerlo, o corregirlo, para no perder datos. Hasta ahora todos pensábamos que esos datos no estaban en ningún registro pero no es verdad, Weewx lo hace correctamente y envía todos esos datos. Debemos comprobar cualquier afirmación cuando hay que resolver un problema.

Saludos jmviper.
« Última modificación: 21 de Octubre del 2016, 11:32:43 am por Amon-K »
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1