Autor Tema: Minimizar la pérdida de datos del último cuarto de hora del día  (Leído 39498 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 #15 en: 03 de Septiembre del 2016, 14:29:53 pm »
Es verdad que solo tengo la experiencia de varios días observando cuando Meteoclimatic hace las actualizaciones y puede cambiar pero en los días que he observado ha sido constante.

En cuanto a donde introducir el delay supongo que será en root/meteoclimatic.sh. ¿Cual sería la sintaxis de ese delay?.

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

Desconectado jantoni

  • Investigación
  • Hero Member
  • ******
  • Mensajes: 3.880
    • Ver Perfil
  • Estación: ESMAD2800000028522A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #16 en: 03 de Septiembre del 2016, 14:59:31 pm »
Si.....probat con

sleep 30

dentro del script

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 #17 en: 03 de Septiembre del 2016, 15:01:22 pm »
Ok. Luego lo haré.  Gracias
  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 #18 en: 03 de Septiembre del 2016, 20:39:45 pm »
jantoni, la solución es perfecta.
He introducido sleep 30 en root/meteoclimatic.sh, con lo cual queda

Código: [Seleccionar]

#!/bin/bash
sleep 30
cd /root/meteoclimatic
#Si no quieres log
#php meteoclimatic_http.php
#Si quieres log
php meteoclimatic_http.php >> /var/log/meteoclimatic.log
exit

He cambiado las líneas de etc/crontab de la siguiente manera:

Código: [Seleccionar]
10-57/5 * * * * root    /root/meteoclimatic/meteoclimatic.sh
0,5 1-23 * * * root    /root/meteoclimatic/meteoclimatic.sh

A las 20:20:31 se ha realizado un envío con los datos del registro de las 20:20, el cual ha sido aceptado por Meteoclimatic, y a las 20:21 Meteoclimatic ha actualizado datos, pero ahora aparece que los datos de la Estación son de las 20:20 ya que allí han llegado a las 20:20:31. Perfecto.

Igualmente ha sucedido a las 20:35.

Seguiremos observando.



  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 #19 en: 04 de Septiembre del 2016, 10:16:47 am »
Las actualizaciones se producen con regularidad total. Anoche a las 00:06 (UTC) actualizó como era de esperar con el envío de las 23:55 que era el objetivo buscado.

Pensando sobre la posibilidad de que Meteoclimatic modificara los momentos en que actualice datos (suponiendo que se mantiene el intervalo de 15 minutos), entre las 23:55 y las 00:10 siempre habría una actualización (actualmente es a las 00:06), que es precisamente la que tomaría el envío del minuto 55 (ya que no existe otro envío posterior), con lo cual tenemos la certeza de que Meteoclimatic siempre tendría en cuenta dicho envío.


Para el caso que deseemos mantener un ritmo de envíos cada 15 minutos además de introducir sleep 30 en root/meteoclimatic.sh hay que introducir en etc/crontab las siguientes líneas:

Código: [Seleccionar]
20-52/15 * * * *      root    /root/meteoclimatic/meteoclimatic.sh
5 1-23 * * *    root    /root/meteoclimatic/meteoclimatic.sh
55 23 * * *      root    /root/meteoclimatic/meteoclimatic.sh

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

Desconectado Ubik

  • Administrator
  • Hero Member
  • ******
  • Mensajes: 2.024
    • Ver Perfil
  • Estación: Villavieja de Yeltes ESCYL3700000037260A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #20 en: 04 de Septiembre del 2016, 11:16:26 am »
Un gran trabajo. Si se pudiera hacer el envío en el minuto 58-59, ya sería rizar el rizo, pero bueno, con 5 minutos ya se reduce considerablemente el problema de la lluvia.

Yo no sabría hacerlo, pero tenía claro hace tiempo que o modifica Meteoclimatic los momentos de lectura o había que cambiar los de subida de forma que la primera lectura del día pudiera leer la última subida del día anterior.

y esta, tenía que hacerse lo más tarde posible.

Enhorabuena.

                         
Davis pro2+cumulus+W7+Lenovo
 
Web http://www.meteovillavieja.es

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 #21 en: 04 de Septiembre del 2016, 11:26:02 am »
Aunque de Weewx no me sé prácticamente nada (el experto es Jantoni) creo que también es un buen trabajo... enhorabuena Amon-K  ;)

Y en cuanto a los que usamos WD como es mi caso y aunque haya muuuucho anti-WD por ahí (y con razón  ::)) decir que este programa te permite poner los tiempos personalizados tanto de creación como de subida de las plantillas y demás archivos por lo que poniendo a crear la última plantilla a las 23:59 prácticamente te aseguras esos últimos datos del día completos (lluvia, temp mínima si se está dando al final del día etc etc)...

En fin WD puede ser un dolor de cabeza muchas veces pero en cuanto a opciones pocos por no decir ninguno le gana... otra cosa es que luego funcionen  ;D ;D

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 #22 en: 04 de Septiembre del 2016, 11:54:24 am »
Gracias Ubik y jmviper.   :D :D :D

Un gran trabajo. Si se pudiera hacer el envío en el minuto 58-59, ya sería rizar el rizo, pero bueno, con 5 minutos ya se reduce considerablemente el problema de la lluvia.

Yo no sabría hacerlo, pero tenía claro hace tiempo que o modifica Meteoclimatic los momentos de lectura o había que cambiar los de subida de forma que la primera lectura del día pudiera leer la última subida del día anterior.

y esta, tenía que hacerse lo más tarde posible.

Enhorabuena.

Yo he partido de dos supuestos, que la Estación registra datos cada 5 minutos, y que los datos de las 00:00 son considerados por Meteoclimatic y por el software de gestión pertenecientes al día que comienza (esto último es lo lógico aunque no lo correcto), por tanto los últimos datos del día registrados son los de las 23:55 y daría igual enviarlos a las 23:55 o a las 23:59, el resultado es el mismo. La lluvia caída a partir del minuto 55 sería contabilizada en el registro de las 00:00, es decir, al día siguiente.

Para reducir esos últimos cinco minutos habría que aumentar la frecuencia de registros de la Estación.

Sin embargo si Meteoclimatic y el software de gestión considerarán los datos registrados a las 00:00 pertenecientes al día anterior ( es decir a las 24:00) no existiría el problema que tratamos aquí.

Saludos.
« Última modificación: 04 de Septiembre del 2016, 12:32:45 pm por Amon-K »
  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 #23 en: 04 de Septiembre del 2016, 12:18:10 pm »
.....
.....
Pensando sobre la posibilidad de que Meteoclimatic modificara los momentos en que actualice datos (suponiendo que se mantiene el intervalo de 15 minutos), entre las 23:55 y las 00:10 siempre habría una actualización (actualmente es a las 00:06), que es precisamente la que tomaría el envío del minuto 55 (ya que no existe otro envío posterior), con lo cual tenemos la certeza de que Meteoclimatic siempre tendría en cuenta dicho envío.
.....
.....

Continuando con mi argumentación anterior, imaginemos por un momento que Meteoclimatic redujera el intervalo de actualizaciones de 15 minutos, en ese caso entre las 23:55 y las 00:10 coincidirían mas de una actualización, la primera de ellas tomaría el envío de las 23:55 y las siguientes no encontrarían envío alguno, con lo cual también conseguiríamos nuestro objetivo.  Aunque lo lógico es modificar la configuración de las líneas de crontab.

Solo en el hipotético caso de que Meteoclimatic aumentara el intervalo de actualizaciones existiría la posibilidad, con la configuración descrita aquí, de perder el envío de las 23:55 (habría que modificarla en consecuencia), y yo personalmente confío que una vez leído este hilo no lo haga.  :) :) :)

Saludos.
« Última modificación: 04 de Septiembre del 2016, 12:48:15 pm por Amon-K »
  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 #24 en: 04 de Septiembre del 2016, 16:04:54 pm »

.....
.....
.................... La lluvia caída a partir del minuto 55 sería contabilizada en el registro de las 00:00, es decir, al día siguiente.
.......
.....

Realmente no sé si esto es así, creo que no estará en ninguno de los dos registros (no estoy seguro), pero debería estar recogida en el de las 00.00 y contabilizarse en el dia que termina.
« Última modificación: 04 de Septiembre del 2016, 20:19:25 pm por Amon-K »
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado Ubik

  • Administrator
  • Hero Member
  • ******
  • Mensajes: 2.024
    • Ver Perfil
  • Estación: Villavieja de Yeltes ESCYL3700000037260A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #25 en: 04 de Septiembre del 2016, 22:17:22 pm »
Citar
Realmente no sé si esto es así, creo que no estará en ninguno de los dos registros (no estoy seguro), pero debería estar recogida en el de las 00.00 y contabilizarse en el dia que termina.

Efectivamente, no está en ninguno de los dos, de ahí la inconsistencia que se produce en el día anterior. Bueno, en el programa sí debiera de estar, pero no en Meteoclimatic.

No puede ser que la lluvia ni ningún dato extremo o acumulado de los últimos 5 minutos se vea en una lectura de las 00:0 dado que ( creo yo) el momento de reinicio de datos diarios debiera de ser a las 23:59:59 , no a las 00:00. Y si el reinicio de contadores es a las 00:00, no debieran de empezar a contar los datos del nuevo día  hasta las 00:01

Citar
Sin embargo si Meteoclimatic y el software de gestión considerarán los datos registrados a las 00:00 pertenecientes al día anterior ( es decir a las 24:00) no existiría el problema que tratamos aquí.

El problema es que técnicamente las 24:00 no existen, pasamos de las 23:59:59 a las 00:00

                         
Davis pro2+cumulus+W7+Lenovo
 
Web http://www.meteovillavieja.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 #26 en: 05 de Septiembre del 2016, 04:33:11 am »
.....
No puede ser que la lluvia ni ningún dato extremo o acumulado de los últimos 5 minutos se vea en una lectura de las 00:0 dado que ( creo yo) el momento de reinicio de datos diarios debiera de ser a las 23:59:59 , no a las 00:00. Y si el reinicio de contadores es a las 00:00, no debieran de empezar a contar los datos del nuevo día  hasta las 00:01
....

No hay duda de que en los 00:00 coexisten el final de un día y el comienzo de otro porque si tenemos en cuenta todos los datos del momento se cumple que:

0d 24:00h = 1d 00:00h

Si yo utilizo 24:00 me parece que gráficamente y sutilmente me estoy refiriendo al final de un día y si utilizo 00:00 me estoy refiriendo de la misma manera al comienzo de otro. Pero estoy hablando del mismo punto en el tiempo.

Si en el minuto 55 registramos los datos recogidos entre el minuto 50 y el 55, es también lógico  registrar en el minuto 60 los datos recogidos entre el minuto 55 y el 60 y por tanto a las 24:00, registrar los datos entre las 23:55 y las 24:00.
 
Si el momento de reinicio de datos diarios fuera a las 23:59:59 habríamos dejado atrás un segundo del dia que termina, luego lo lógico es hacerlo a las 00:00.

.....
El problema es que técnicamente las 24:00 no existen, pasamos de las 23:59:59 a las 00:00

Es verdad, de las 23:59:59 pasamos a las 00:00, pero teniendo en cuenta todos los datos y todos los pasos intermedios aparecen las 24:00 en uno de esos pasos:

0d 23:59:59 + 1segundo = 0d 23:59:60 = 0d 23:60:00 = 0d 24:00:00 = 1d 00:00:00.

  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 #27 en: 06 de Septiembre del 2016, 03:27:52 am »
Relacionado con la pregunta que nos hacemos sobre cuando se ponen a cero los datos, muchas noches mirando los mapas de Meteoclimatic me encuentro un hecho curioso que se produce hasta aproximadamente las 00:38h UTC.

En el mapa de temperaturas máximas se muestra que algunas Estaciones tienen una temperatura máxima correspondiente al día anterior aunque hayan actualizado sus datos a las 00:35h UTC, y su temperatura máxima del día sea otra, tal y como se muestra en la ventana popup correspondiente. En las imágenes que adjunto todas las Estaciones que marcan 40º o más están en el mismo caso En la imagen primera se muestra la Estación de Puente Genil con una temperatura máxima de 43º en el mapa de colores, y una temperatura máxima de 28,8º actualizada a las 00:35h UTC en la ventana popup. En la imagen segunda se muestra el mismo mapa y la ventana popup correspondiente a una Estación que tiene correctamente actualizada su temperatura máxima actualizada en el mismo momento, las 00:35h UTC.

Esto no ocurre en el mapa de temperaturas actuales.

Según parece Meteoclimatic tarda en tener en cuenta todas los datos recibidos de las Estaciones para generar las imágenes correspondientes, pero me llama la atención que se retrase tanto.
  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 #28 en: 07 de Septiembre del 2016, 03:00:08 am »
Lo anterior tiene relación con la hora en que envía los datos cada Estación porque una situación similar se produce antes de las 00:00 UTC. Creo que las Estaciones que envían los datos según la hora CEST, despues de las 00:00 CEST ya estan enviando la temperatura máxima del nuevo día y según parece, se traslada esta nueva máxima desde ese momento a los mapas. Las que envían datos según la hora UTC no cambian la temperatura máxima del dia hasta despues de las 00:00 UTC. y este cambio se traslada a los mapas despues de esa hora.

Esto implica que entre despues de las 00:00 CEST (supongo que aproximadamente las 00:38 CEST) y despues de las 00:00 UTC (aproximadamente las 00:38 UTC) hay unas Estaciones con la temperatura máxima del nuevo día según su horario, y otras con la temperatura máxima del día que aun no ha acabado según su horario. Esto ahora con las temperaturas tan extremas que estamos soportando provoca que el mapa de temperaturas máximas tenga unos saltos muy bruscos entre unas Estaciones y otras, que es lo que a mi me ha llamado la atención.
  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 #29 en: 07 de Septiembre del 2016, 04:48:58 am »
Ayer pensé que, como ya he afirmado anteriormente, no sabía si los datos recogidos por la Estación entre las 23:55 y las 00:00 se perdían o no, pero que lo lógico era que estuvieran en el registro de las 00:00. Me dije que no tenía sentido que se perdieran. Si comprobaba que la lógica se cumpliera, es decir que en el registro de las 00:00 estaban esos datos, la solución para no perder esos datos era forzar a que Meteoclimatic leyera el registro de las 00:00. Y me puse manos a la obra.

Vi que weewx guardaba en su base de datos cada registro de la consola 16 segundos despues de producirse, quería enviar los datos poco despues, con lo cual ajusté el delay de root/meteoclimatic.sh a 20 segundos.

Modifiqué etc/crontab para enviar todos los registros (se producen cada 5 minutos) menos el de las 00:05 para conseguir que en la actualización que Meteoclimatic realiza a las 00:06, leyera el registro de las 00:00. Esas líneas de etc/crontab quedaron así:

Código: [Seleccionar]
#Envía datos a Meteoclimatic cada 5 minutos, excepto a las 00:05
0 * * * * root    /root/meteoclimatic/meteoclimatic.sh
5 1-23 * * * root    /root/meteoclimatic/meteoclimatic.sh
10-57/5 * * * * root    /root/meteoclimatic/meteoclimatic.sh

Y esta noche me he puesto a observar que ocurría a partir de las 00:00 UTC. Estos son los datos que he recogido:

En la ficha de configuración de la Estación despues de las 00:06 tomé la última actualización:
Código: [Seleccionar]
*VER=DATA3a
*COD=ESAND1400000014500A
*TK=1473206421
*UPD=07/09/2016 00:00:21 UTC
*TMP=28.6
*HUM=38
*WND=3
*AZI=
*WRUN=0
*BAR=1012.3
*HUM=38
*SUN=0
*UVI=0
*DHTM=42.7
*DLTM=24.2
*DHHM=38
*DLHM=10
*DHBR=1014.8
*DLBR=1010.5
*DGST=37
*DSUN=0
*DHUV=0
*DPCP=0
*MHTM=43.2
*MLTM=19.8
*MHHM=86
*MLHM=10
*MHBR=1018.1
*MLBR=1010.5
*MGST=51
*MSUN=0
*MHUV=0
*MPCP=0
*YHTM=43.2
*YLTM=1.2
*YHHM=97
*YLHM=7
*YHBR=1028.2
*YLBR=998
*YGST=84
*YSUN=0
*YHUV=0
*YPCP=134.8
*AGENT=Meteoclimatic_HTTP/1.0 (Davis Vantage Pro 2)
*IP=85.51.84.195
*ERR=
*EOT*

En la página Meteoclimatic de la Estación tomé la siguiente imagen:



Se puede ver, por ejemplo, que la temperatura máxima es de 42,7ºC y la temperatura actual es de 28,6ºC. Es decir hasta este momento se mantienen los datos del día que termina, no se ponen a cero todavía.



En la ficha de configuración de la Estación despues de las 00:21 tomé la última actualización:

Código: [Seleccionar]
*VER=DATA3a
*COD=ESAND1400000014500A
*TK=1473207622
*UPD=07/09/2016 00:20:22 UTC
*TMP=27.6
*HUM=40
*WND=11
*AZI=112
*WRUN=0
*BAR=1012.2
*HUM=40
*SUN=0
*UVI=0
*DHTM=28.7
*DLTM=27.6
*DHHM=40
*DLHM=38
*DHBR=1012.3
*DLBR=1012.1
*DGST=14
*DSUN=0
*DHUV=0
*DPCP=0
*MHTM=43.2
*MLTM=19.8
*MHHM=86
*MLHM=10
*MHBR=1018.1
*MLBR=1010.5
*MGST=51
*MSUN=0
*MHUV=0
*MPCP=0
*YHTM=43.2
*YLTM=1.2
*YHHM=97
*YLHM=7
*YHBR=1028.2
*YLBR=998
*YGST=84
*YSUN=0
*YHUV=0
*YPCP=134.8
*AGENT=Meteoclimatic_HTTP/1.0 (Davis Vantage Pro 2)
*IP=85.51.84.195
*ERR=
*EOT*

En la página Meteoclimatic de la Estación tomé la siguiente imagen:



Aquí se puede ver que ya la temperatura máxima se ha actualizado a los valores del nuevo día. La temperatura máxima es ahora de 28,7ºC y la actual es de 27,6ºC.

Yo creo y espero que todo esto quiera decir que lo lógico es lo que realmente sucede, y por tanto esta configuración de etc/crontab es la que permita no perder ningún dato.

Espero que los expertos me den su opinión sobre todo esto. Yo por mi parte mantendré esta configuración para comprobar que el día que llueva en los últimos minutos del día no se produce ninguna inconsistencia.

Saludos.


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