Meteoclimatic
Meteoclimatic => Forum General => Mensaje iniciado por: Amon-K en 28 de Agosto del 2016, 01:46:30 am
-
En varios post ya se ha tratado el tema de la pérdida de datos (sobre todo de precipitación pero igualmente puede afectar a los demás datos) entre el último envío del día, y el primero del día siguiente.
Yo tenía configurado en crontab lo siguiente:
.......
.......
#Envía datos a Meteoclimatic cada 15 minutos, empezando en el minuto 1 de cada hora
1-59/15 * * * * root /root/meteoclimatic/meteoclimatic.sh
.......
.......
Y la consola está configurada para guardar datos cada 5 minutos.
Todo ello según nos aconseja jantoni en su tutorial para la instalación y personalización de Weewx.
Con esta situación Linux hace un último envío cada día a las 23:46h con los datos grabados a las 23:45h y el siguiente lo hace a las 00:01h con los datos grabados a las 00:00h, el cual, por lógica, supongo que será considerado perteneciente al día siguiente.
Quiere esto decir que los datos grabados en la consola a las 23:50h y a las 23:55h constan en la consola y por tanto considerados a efectos de acumulados y de máximos y mínimos en las bases de datos de weewx, y no siendo así considerados por Meteoclimatic por no constarle, y ello puede acarrear inconsistencias.
Se me ocurrió que una solución posible a esta situación es configurar crontab de la siguiente manera:
......
......
#Envía datos a Meteoclimatic cada 15 minutos, empezando en el minuto 1 de cada hora
1-57/15 * * * * root /root/meteoclimatic/meteoclimatic.sh
#Envía datos a Meteoclimatic a las 23:59 de cada dia
59 23 * * * root /root/meteoclimatic/meteoclimatic.sh
......
......
En esta solución se hacen los envíos cada 15 minutos y un envío extra a las 23:59h con los datos grabados a las 23:55h donde constan los acumulados, máximos y mínimos del día. Así he estado mucho tiempo pensando que de esta manera estaba enviando los datos de estos últimos minutos.
Hace unas semanas pensé que también podía probar una segunda solución, hacer envíos cada 5 minutos con lo cual a Meteoclimatic le constaría todos los datos acumulados en las bases de datos de weewx y normalmente no se producirían inconsistencias. He probado esta solución y los envíos cada 5 minutos se producen y son aceptados por Meteoclimatic, sin embargo no sé si Meteoclimatic los tiene en cuenta, porque en las sucesivas actualizaciones de mi estación solo aparecen las enviadas cada 15 minutos. Y por tanto me surge la duda: ¿Es efectiva esta solución?, y si no es efectiva tampoco lo es la primera solución.
Por último se me ocurre una tercera solución. Ajustar el último envío del día a las 23:56h con los datos grabados a las 23:55h lo cual supongo es buena solución y no me surgen dudas de su efectividad, aunque tendré que probarla. Habría que introducir en crontab lo siguiente:
......
......
#Envía datos a Meteoclimatic cada 15 minutos, empezando en el minuto 11 de cada hora
11-57/15 * * * * root /root/meteoclimatic/meteoclimatic.sh
......
......
No obstante me gustaría aclarar las dudas planteadas anteriormente para saber cuales de estas tres soluciones son efectivas y que cada uno de los que lean este tema elija la que más le interese.
Saludos a todos.
-
Prográmalo para hacer 4 envíos empezando en el minuto 11, 26, 41 y 56, te aceptará todos los envíos y se minimizaría la posible pérdida de datos a los 5 últimos minutos.
-
Gracias Ubik por la rapidisima respuesta.
Si, yo tambien llego al convencimiento, porque supongo algunas cosas, de que es la solución pero me quedan sin respuesta las preguntas que me han hecho llegar a esta conclusión.
¿Si hago un envio extra fuera del ritmo normal de envíos, este envío se considera por parte de Meteoclimatic?.
¿Si aumento el ritmo de envíos, estos envios son considerados por Meteoclimatic?. En caso negativo
¿Es obligado mantener un ritmo de envios con un período de 15 minutos?.
Saludos.
-
No os lieis....os lo recomiendo.
ESe margen de error va a existir siempre, aunque se envién (y se acepten) envíos cada 5 minutos.
A tus preguntas:
No
No
No
;D ;D ;D ;D ;D ;D ;D
Veamos, puedes hacer como yo. Enviar cada 5 minutos. Pero Meteoclimatic solo va a tomar 4 envíos a la hora.
Desconozco las tripas internas del software de meteoclimatic, pero la experiencia de estos años, me hace pensar que es algo parecido a esto:
- Hay dos modos de transmisión, Visual y similares, y el típico mal llamado FTP (en realidad por HTTP)
- Las estaciones pueden enviar todos los datos que quieran.....hasta 1 cada minuto
- El servidor de Meteoclimatic, una vez abierta la ventana, lee los FTP y el último dato que tenga almacenado enviado por Visual
Por tanto, si tu envío a las 23:5x es el último almacenado en el momento de abrir la ventana de datos, es el que será utilizado. En caso contrario, usará el anterior.
El problema es que no sabemos en que momento abre la ventana.
Una solución para el cron sería mandar los datos cada 5 o 15 minutos durante todo el día....y en el último cuarto de hora, mandarlo cada minuto.
Pero eso sería una tontería, porque entonces hay que cambiar la generación en el software de la estración en el mismo periodo, de lo contrario volvemos a "maximizar" la diferencia en precipitación o viento.
Sinceramente, lo mejor es lo siguiente:
- Generación en el software cada 5 minutos. Envío cada 5 minutos.
- Revisar, a diario, las diferencias entre nuestro resumen diario y el resumen de Meteoclimatic
- Corregir las posibiles diferencias diarias.
Lo contrario es pretender que todo sea automático. Y eso conlleva a que, al final, desatendemos las estaciones y sus datos, como estamos habituados a ver a diario.
-
Por cierto, este hilo estaría mejor en el foro general o en el de software de meteoclimatic, puesto que no afecta solo a weewx
-
No nos liamos jantoni, justamente pretendemos aclararnos y con tus respuestas avanzamos en ese camino aunque se ve que no es posible del todo porque existen incertidumbres que no podemos salvar.
Aunque con tus tres respuestas me recuerdas a algún político ( ...y que parte del no no......) yo siempre te imagino como un Jefe de Estado que está por encima del mal y nos guías a todos. ;) ;) ;) ;)
Además de esos noes están tus aclaraciones que nos están diciendo que no existe un método fiable al 100%, y que el método que propones es el que más se acerca.
Por otro lado hay que suponer que si tú no has obtenido la respuesta de Meteoclimatic no es posible obtenerla.
Gracias pues.
Saludos.
-
;D ;D ;D ;D
Bueno....es que no puede haberla. Salvo que Meteoclimatic cambiase drásticamente el código de programación e incluyera, por ejemplo, a las 2:30 del día siguiente un resumen del día anterior
Este tema, ya se debatió hace años y, en un sistema con información agrupada cada 15 minutos, o incluso cada menos, es imposible de evitar al 100%.
Y como digo, la mejor manera de estar permanentemente atento a la estación y a la información de Meteoclimatic, es mirando al día siguiente que no se haya generado ningún problema o inconsistencia. Los que confían en que todo va bien, terminan con la estación desatendida y, además, pensando que sus estación es fantástica, que si, que lo és, pero el software y las máquinas se vuelven en contra de uno mismo. ;D ;D ;D ;D ;D
-
Gracias por todo jantoni.
En cuanto a la ubicación del hilo creo que yo no puedo modificarlo.
Saludos.
-
En estos días que han pasado desde mi último post, he estado probando las soluciones que me han dado jantoni y Ubik y paso a relatar mis conclusiones al respecto, siempre teniendo en cuenta que lo hago desde mi instalación en el sistema operativo Linux.
En primer lugar probé la solución de jantoni, es decir, hacer los envíos a Meteoclimatic cada 5 minutos. Para ello introduje en etc/crontab la siguiente línea:
1-57/5 * * * * root /root/meteoclimatic/meteoclimatic.sh
De esta manera Meteoclimatic actualiza solo con los datos enviados en los siguientes minutos: 06, 21, 36 y 51, aunque esporádicamente puede tomar los datos correspondientes a 5 minutos antes de los relacionados, los demás envíos los recibe pero los ignora. Esta solución tiene la ventaja de que Meteoclimatic tiene en cada momento los datos más actuales, es decir, por ejemplo en el minuto 06 o como mucho en el minuto 07 actualiza con los datos enviados en el minuto 06 y de la misma manera con los envíos de los minutos 21, 36 y 51. Y el inconveniente de que al menos el registro correspondiente al minuto 55 de las 23 horas, enviado en el minuto 56, Meteoclimatic lo ignora, lo que implica que si en ese registro se modifica el acumulado de lluvia o alguno de los máximos o mínimos del día, estos datos se pierden y ello implica una inconsistencia para Meteoclimatic (es verdad que esa inconsistencia es muy fácil de comprobar y modificar).
En segundo lugar he probado la solución propuesta por Ubik, es decir, hacer los envíos a Meteoclimatic en los minutos 11, 26, 41 y 56. Para ello introduje en etc/crontab la siguiente línea:
11,26,41,56 * * * * root /root/meteoclimatic/meteoclimatic.sh
De esta manera Meteoclimatic actualiza en el minuto 06 con los datos enviados en el minuto 56 (los últimos enviados) y está así hasta el minuto 21, momento en el cual Meteoclimatic actualiza con el envío del minuto 11. Pero segundos antes de actualizar en el minuto 21 (no más de 30 segundos) Meteoclimatic empieza a dar el mensaje de que la Estación no está actualizada, porque han pasado 25 minutos (desde el minuto 06 hasta ese momento). No estoy seguro de que esto sea o no un inconveniente. Por contra tenemos la seguridad que el envío realizado en el minuto 56 de la 23 horas queda registrado para Meteoclimatic, y por tanto eliminamos la posibilidad de que pueda aparecer una inconsistencia en los datos registrados por Meteoclimatic con motivo del dato acumulado de lluvia, máximos y mínimos del día.
Una vez diseccionados los inconvenientes y las ventajas de cada solución cada uno puede elegir, conociendo lo que está haciendo, es decir espero que os sirva todo este tocho de minutos y envíos.
Saludos.
-
......
......
.......................................................................... Pero segundos antes de actualizar en el minuto 21 (no más de 30 segundos) Meteoclimatic empieza a dar el mensaje de que la Estación no está actualizada, porque han pasado 25 minutos (desde el minuto 06 hasta ese momento). No estoy seguro de que esto sea o no un inconveniente. ..................
......
......
He podido comprobar que esto no es un inconveniente porque este mensaje lo da siempre y en el momento exacto en que Meteoclimatic está actualizando los datos, independientemente de que hayan pasado 15, 20 o 25 minutos.
-
Hola, espero haberlo entendido bien. Mi idea es la siguiente: enviar cada 5 minutos salvo el primer envío del día siguiente, es decir, algo como esto:
06,11,16,21,26,31,36,41,46,51,56 * * * * root /root/meteoclimatic/meteoclimatic.sh
(O bien, quitando también el 06, para que en la lectura de las 00:06 lea el dato de las 23:56)
Así, la estación estará actualizada casi siempre y te aseguras de que se reciba el dato de las 23:56
No sé si dará resultado, pero si no me equivoco, podría ser lo óptimo.
Saludos
-
Efectivamente Wlarues, es la solucion intermedia que iba a proponer como la optima, es decir poner en etc/crontab lo siguiente:
11-59/5 * * * * root /root/meteoclimatic/meteoclimatic.sh
Ya lo he probado y es correcta la sintaxis. En esta solución no se realizan los envíos de los minutos 01 y 06 y cuando en el minuto 06 Meteoclimatic actualice se encuentra como último envío el del minuto 56 de cada hora. Esto permite mantener los datos de la Estación lo más actualizados posible durante el resto de cada hora y al mismo tiempo tener la certeza de que Meteoclimatic considerará el ultimo envío del día.
Saludos
Hay que tener cuidado con no modificar los espacios entre los asteriscos porque colocar dos de ellos entre el primero y el segundo provoca que Linux no cargue el fichero crontab y a mi me ha provocado varios dolores de cabeza buscando el error.
-
Esta solución es mejorable. Se trataría de conseguir que en todas las horas menos en la hora 0 se puedan realizar los envíos correspondientes a los minutos 01 y 06. Para ello se podría introducir otra linea más, es decir:
11-59/5 * * * * root /root/meteoclimatic/meteoclimatic.sh
1,6 1-23 * * * root /root/meteoclimatic/meteoclimatic.sh
Lo he introducido en etc/crontab y Linux lo ha aceptado. Estoy probandolo.
-
Funciona, en esta hora (las 12) los envíos de los minutos 01 y 06 se han realizado, supongo por tanto que la sintaxis anterior es correcta.
Seguiré observando.
En caso que deseemos mantener un ritmo de envíos cada 15 minutos supongo que la mejor configuración sería la siguiente:
21-59/15 * * * * root /root/meteoclimatic/meteoclimatic.sh
6 1-23 * * * root /root/meteoclimatic/meteoclimatic.sh
56 23 * * * root /root/meteoclimatic/meteoclimatic.sh
Aunque habría que probarla porque como ya dije anteriormente Meteoclimatic actualiza en los minutos 06, 21, 36 y 51 y a veces lo hace tan rápido que no le da tiempo a considerar el envío que llega en ese mismo minuto. (Rizando el rizo se podría probar a enviar en el minuto 5.5 pero a priori no confío en que funcione).
-
Si....sería rizar el rizo.....de todos modos, cron no tiene posibilidad, que yo sepa, de trabajar con segundos, solo con los minutos.
No obsante, siempre puedes empezar el script en un minuto y meter un delay de 30 segundos dentro del script.
Y por otro lado, nadie os garantiza que las ventanas de Meteoclimatic sean siempre iguales.
Yo, de todos modos, sigo expectante vuestras conclusiones.
-
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.
-
Si.....probat con
sleep 30
dentro del script
-
Ok. Luego lo haré. Gracias
-
jantoni, la solución es perfecta.
He introducido sleep 30 en root/meteoclimatic.sh, con lo cual queda
#!/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:
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.
-
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:
20-52/15 * * * * root /root/meteoclimatic/meteoclimatic.sh
5 1-23 * * * root /root/meteoclimatic/meteoclimatic.sh
55 23 * * * root /root/meteoclimatic/meteoclimatic.sh
Saludos.
-
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.
-
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
-
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.
-
.....
.....
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.
-
.....
.....
.................... 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.
-
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
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
-
.....
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.
-
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.
-
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.
-
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í:
#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:
*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:
(http://i65.tinypic.com/2nbc74l.jpg)
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:
*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:
(http://i64.tinypic.com/2nv5u12.jpg)
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.
-
En la página Meteoclimatic de la Estación tomé la siguiente imagen:
(http://i64.tinypic.com/2nv5u12.jpg)
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.
::) ::) :o :o
-
Buenas noches jmviper.
Gracias por tu respuesta pero no entiendo que me quieres decir y me interesa mucho saberlo. Quisiera saber tu opinión y de las personas como tú que llevais muchos años trabajando en este tema (yo solo llevo algunos meses) y que me podeis decir con perspectiva si mis conclusiones son erradas o por el contrario van por buen camino. En todo momento he expuesto con detalle los pasos que he dado, mi argumentacion y mis conclusiones para recibir las opiniones de las personas que seguian el hilo.
Saludos.
-
No se si a jmviper le pasaría ayer como a mi.
Pero en lugar de las gráficas, a mi, en mi tableta me salia la fotografía de un anciano.
Ahora, sin embargo, veo las gráficas perfectamente
-
No se si a jmviper le pasaría ayer como a mi.
Pero en lugar de las gráficas, a mi, en mi tableta me salia la fotografía de un anciano.
Ahora, sin embargo, veo las gráficas perfectamente
Menos mal que no fuí yo solo... en vez de citar pensé en hacer captura de pantalla y adjuntarla y al ver el gráfico de nuevo pensé que era una jugarreta de urls de tinypic y luego pensé lo peor... pensé en que IE del que debo de ser de los pocos que aún lo use me puso alguna imagen de su caché... ::)
En fin Amon-K veo que te has puesto manos a la obra para no perder datos del día con weewx por lo que a más de uno que lo use le vendrán muy bien las pruebas que estás haciendo.
Saludos
-
Gracias jmviper y jantoni por responder.
Ah!. Puede ser un problema de tinypic, el servidor de imagenes gratuito que he utilizado. Lo iré comprobando por si volviera a suceder.
Como ahora se ven bien las imágenes me gustaria saber si mis últimas conclusiones son correctas. Creo que podrían ser importantes.
Sin fueran correctas se pueden aplicar a todo el software de gestion de Estaciones.
Saludos.
-
Solo lo podrás saber con tiempo, anotando los datos y viendo como responde Meteoclimatic.
Es una antigua guerra......lástima que de tus conclusiones, solo se podrán beneficiar los usuarios que se pasen al "lado oscuro" de Linux....bueno en Windows se podría hacer.....pero como el envio coincida con un episodio de rascarascarascarasca del proceso svchost....pues apaga y vámonos, ja ja
-
Y sobre todo, las conclusiones vendrán con un episodio majo de lluvias.
-
Gracias jantoni por tus respuestas. Es decepcionante pensar que estas escribiendo y nadie te está leyendo.
Sigo pensando la manera de comprobar qué consideración hace Meteoclimatic del registro de las 00:00 enviado a las 00:00:21 y notificada su aceptación a las 00:00:26, que son los tres momentos recogidos en meteoclimatic.log, para la configuración que tengo actualmente.
Aún no he dado con ella, con la lluvia natural podría ser pero con lo poco que llueve va a ser una lotería. Estoy dándole vueltas a una lluvia artificial. Ya veremos.
Saludos.
-
No, no.
conectado a meteoclimatic no uses la manguera ;D
-
Bueno esta noche a las 00:00 UTC he podido comprobar que (por la presión atmosférica que estaba subiendo por encima de cualquier valor del día, y sin embargo Meteoclimatic no lo ha considerado como máximo del día que termina) que los datos del registro de las 00:00h Meteoclimatic no los tiene en cuenta para el día que termina, los pasa como datos del día que comienza, supongo que es porque considera la hora de esos datos la de envío, las 00:00:21. De hecho esa es la que utiliza como hora de la actualización (cuando el registro de las 00:00 se envía a las 00:01:21, Meteoclimatic informa que la última actualización es de las 00:01)
Weewx, sin embargo, considera que los datos del registro de las 00:00 pertenecen al día que termina y al día que empieza. A esta conclusión se llega del análisis de este registro, del anterior y del siguiente. El máximo de una medida del día que termina está también como máximo en el registro de las 00:00. Cuando una medida está subiendo, el valor del registro de las 00:00 aparece en el siguiente registro como mínimo de esa medida.
Yo creo que Meteoclimatic debería tener las mismas consideraciones que Weewx y además tomar como hora de actualización la hora de cada registro leído, no la hora de envío.
Tal y como está la situación, el problema no es resoluble al 100% sin modificar las consideraciones de Meteoclimatic. Los datos de los últimos 5 minutos del día se perderán irremediablemente (en el supuesto de registros cada 5 minutos).
Saludos.
-
Efectivamente, esa es la conclusión a la que hemos llegado hace tiempo.
El problema es irresoluble y es común a la mayoría de plataformas.
La única solución es que Meteoclimatic estuviera sincronizado con nuestras estaciones en tiempo real. Pero eso, hoy por hoy, es totalmente irrealizable.
Hacerlo "en diferido" implicaría una cantidad de código no justificable para una plataforma no profesional, teniendo en cuenta que con 1.600 estaciones no todas están transmitiendo datos en la franja de 5 minutos.....
Así que siempre queda la solución del ajuste manual. Así nos entretenemos ;D ;D ;D ;D ;D ;D ;D
-
Como mi especialidad son las simplezas, me permito intervenir para aclarar alguna cuestión de base. Y exclusivamente con ánimo de no liar más las cosas.
El tiempo no se superpone, ni "coexiste", como se dijo más atrás.
Como todos sabemos, es una magnitud física sin solución de continuidad.
Cuando termina y se cumple por completo la hora 23:59 comienza la siguiente 00:00
Se acabó un día de 24 horas y comenzó otro que durará lo mismo
Dejémonos de hora 24:00:00, de hora 24:59:60 (intercalar) o de hora 00:00:00, que -si bien pueden formularse teóricamente- no responden a ninguna realidad ni necesidad práctica.
Dice Amon- K "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"
No hay tales puntos más que "gráfica y sutilmente". Y en la norma ISO y en los calendarios, todos imperfectos.
La unidad de medida del tiempo es el segundo, s
Cumplido uno ocurre el siguiente, y así. Dada la incompetencia humana para según qué cosas hemos inventado además el segundo intercalar, etc.
Si Meteoclimatic, Weex o cualquier otro ente interpreta de un modo u otro esta simpleza, que el tiempo es un continuo sin interrupciones, y recopila, o envía, o apunta datos de una u otra manera, es asunto particular de cada uno.
Habrá que adaptar nuestros intereses al formato que cada sistema utilice o establezca.
Muy encomiable tu interés, Amón -K, por el rigor y la perfecta exactitud cronométrica.
Te animo a perseverar en la consecución de tus fines para minimizar la pérdida de datos, y a ser posible eliminarla por completo.
-
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...
-
Efectivamente, esa es la conclusión a la que hemos llegado hace tiempo.
Se ve que nadie escarmienta en cabeza ajena.
El problema es irresoluble y es común a la mayoría de plataformas.
La única solución es que Meteoclimatic estuviera sincronizado con nuestras estaciones en tiempo real. Pero eso, hoy por hoy, es totalmente irrealizable.
Hacerlo "en diferido" implicaría una cantidad de código no justificable para una plataforma no profesional, teniendo en cuenta que con 1.600 estaciones no todas están transmitiendo datos en la franja de 5 minutos.....
Ne es necesario, solo con que Meteoclimatic tenga una consideración especial con el registro de las 00:00. Las datos necesarios estan en ese registro. En ese registro están los acumulados, máximos y mínimos del día que termina sin perder ni un segundo. Es responsabilidad de cada Estación con su configuración enviarselos a Meteoclimatic.
Entiendaseme que todo ello es una sugerencia y no espero nada más porque sé que no es fácil revisar todo el software de Meteoclimatic para tener en cuenta estas consideraciones.
Así que siempre queda la solución del ajuste manual. Así nos entretenemos ;D ;D ;D ;D ;D ;D ;D
Es el remedio que nos queda, y tiene la ventaja de recibir muy de vez en cuando una sorpresita que nos engrasa las neuronas.
Saludos jantoni.
-
Como mi especialidad son las simplezas, me permito intervenir para aclarar alguna cuestión de base. Y exclusivamente con ánimo de no liar más las cosas.
El tiempo no se superpone, ni "coexiste", como se dijo más atrás.
Como todos sabemos, es una magnitud física sin solución de continuidad.
Cuando termina y se cumple por completo la hora 23:59 comienza la siguiente 00:00
Se acabó un día de 24 horas y comenzó otro que durará lo mismo
Estoy de acuerdo, solamente precisar que el tiempo es una dimensión, una de sus características es ser un flujo continuo. Por ser una dimensión es medible y para ello los humanos hemos tomado inicialmente una escala cuya unidad es el dia, posteriormente el día lo dividimos en horas, subdivididas en minutos y estos últimos a su vez divididos en segundos. Todos lo sabemos, pero lo expreso aquí para mostrar que las divisiones están en la escala, no en el tiempo.
Dejémonos de hora 24:00:00, de hora 24:59:60 (intercalar) o de hora 00:00:00, que -si bien pueden formularse teóricamente- no responden a ninguna realidad ni necesidad práctica.
Supongo que se refiere a la expresion:
0d 23:59:59 + 1segundo = 0d 23:59:60 = 0d 23:60:00 = 0d 24:00:00 = 1d 00:00:00.
Quiero expresar que a 23:59:59 le falta un segundo para ser un dia completo y ese segundo no es intercalar.
Por otro lado, lo demás sencillamente es como decir que 60 segundos equivalen a un minuto y que 60 minutos equivalen a una hora. Todo ello efectivamente es una obviedad pero me parece que la expresión nos muestra algo que era oportuno en su momento.
Dice Amon- K "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"
No hay tales puntos más que "gráfica y sutilmente". Y en la norma ISO y en los calendarios, todos imperfectos.
Seguramente no he sabido expresarme, pero para aclarar lo que quiero decir voy a poner un ejemplo:
José tiene un hijo llamado Manuel, quien a su vez tiene un hijo llamado Pedro (no le pongo a cada hijo el mismo nombre que al padre para hacerlo más real, porque en ese caso no nos aclararíamos :) :) :) ).
Cuando José ve a Manuel piensa "Es mi hijo".
Cuando Pedro ve a Manuel piensa: "Qué peñazo, es mi padre". (Pedro tiene 16 años ??? ???)
Pero no cabe duda, ambos están viendo a Manuel, lo mires por donde lo mires y lo mire quien lo mire.
Si Meteoclimatic, Weex o cualquier otro ente interpreta de un modo u otro esta simpleza, que el tiempo es un continuo sin interrupciones, y recopila, o envía, o apunta datos de una u otra manera, es asunto particular de cada uno.
Habrá que adaptar nuestros intereses al formato que cada sistema utilice o establezca.
Muy encomiable tu interés, Amón -K, por el rigor y la perfecta exactitud cronométrica.
Te animo a perseverar en la consecución de tus fines para minimizar la pérdida de datos, y a ser posible eliminarla por completo.
Gracias B.Santiago.
Yo he concluido y he expuesto mis conclusiones, y entiendanse estas como sugerencias. Solo he conseguido minimizar el problema a los 5 últimos minutos del día. Progresar en el camino ya no depende de mí.
Saludos.
-
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.
-
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
-
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.
-
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
-
Bien, lo informaré a esa dirección de correo a ver si allí le ven solución.
Saludos.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
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)
3ª 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.
-
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
-
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.
-
No Amon-K, para mí no es árido el tema y está bastante claro... cualquier programa resetea valores a las 0:00 excepto por lo que estoy viendo weewx. Tanto WD como Cumulus resetean las máx/mín a las 0:00 ya que las 0:00 es hora del nuevo día y si no es así como has expuesto con tu reducción al absurdo me compraré un nuevo reloj o PC que a las 0:00:00 no cambie la fecha (si encuentras algún sistema que a las 0:00:00 no cambie la fecha me lo dices ::)).
No creo que sea cuestión de decirles a Brian (WD) y a Steve (Cumulus) que consideren las 0:00 como todavía del día anterior y no reseteen las máx/mín en ese instante y lo hagan 1 segundo o 1 minuto después...
WD tiene muchas cosas (muchas con bugs ::)) pero por ejemplo en la creación de plantillas puedes poner las horas personalizadas en vez de hacerlo cada intervalo de tiempo. Y por supuesto que he probado a resetear a las 0:00 las máx/mín y salían las de las 0:00 y no las del día anterior por eso hice lo de que WD me generase la última plantilla a las 23:59 y no perder ningún dato del día (excepto si por casualidad se produce entre las 23:59 y las 0:00).
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.
No he dicho que tú lo hayas puesto adrede y también me expresé yo mal ;D. Si la plantilla en el nuevo día pone 13 mm él interpreta que han caído 13 mm y "guarda" lo que recibió en la última plantilla con fecha del día de ayer (en este caso 12.6 mm) y lo suma y si encuentra 0.4 mm en la plantilla también se los suma a los 12.6 mm.
Yo por mi parte no voy a darle vueltas al tema más ni voy a buscar reducciones al absurdo ;D ya que lo tengo meridianamente claro. Si weewx hace lo que tú dices no por ello van a hacer los demás programas lo mismo o hay que cambiar todo el sistema para que lo interprete para tu plantilla.
Es lo que hay y cada uno busca sus mañas para intentar no perder datos en el cambio de día.
Saludos
-
Buenas noches jmviper.
Creo que tienes razón y muchas veces hago extensiva mi visión parcial, ya que desconozco en profundidad otro software que no sea Weewx.
No Amon-K, para mí no es árido el tema y está bastante claro... cualquier programa resetea valores a las 0:00 excepto por lo que estoy viendo weewx. Tanto WD como Cumulus resetean las máx/mín a las 0:00 ya que las 0:00 es hora del nuevo día y si no es así como has expuesto con tu reducción al absurdo me compraré un nuevo reloj o PC que a las 0:00:00 no cambie la fecha (si encuentras algún sistema que a las 0:00:00 no cambie la fecha me lo dices ::)).
Cuando hablaba que era un tema árido lo hacía pensando en que era poco atractivo.
Weewx también resetea a las 00:00 pero antes guarda los datos de ese momento, porque son muy importantes, de hecho toda esta conversación tiene como objetivo no perderlos. Yo también creo que a las 00:00 cambia la fecha, pero lo hace porque las 00:00 es el final del minuto 60 de la última hora del día que termina y coincide que también es el principio del minuto 1 de la primera hora del día que empieza, con todas esas coincidencias es normal que cambie la fecha. Y hago hincapié, las 00:00 es las dos cosas y no solamente la segunda.
WD tiene muchas cosas (muchas con bugs ::)) pero por ejemplo en la creación de plantillas puedes poner las horas personalizadas en vez de hacerlo cada intervalo de tiempo. Y por supuesto que he probado a resetear a las 0:00 las máx/mín y salían las de las 0:00 y no las del día anterior por eso hice lo de que WD me generase la última plantilla a las 23:59 y no perder ningún dato del día (excepto si por casualidad se produce entre las 23:59 y las 0:00).
Aquí me parece que he supuesto que WD funciona de manera similar a Weewx y según parece no es así. Puedo suponer ahora que cuando WD genera la plantilla lo hace leyendo los datos actuales de la Estación y los incluye en la misma. Es verdad, de esa manera solo se perderían los datos del último minuto.
También en WD se puede configurar el momento en el que se resetean los datos. Si quiero leer los datos de las 00:00 no tendré que resetear en ese momento, sino despues, por ejemplo a las 00:01. Quizás, y recalco quizás, entonces podría estar en la plantilla generada a las 00:00 los datos que buscamos y que se pierden.
No he dicho que tú lo hayas puesto adrede y también me expresé yo mal ;D. Si la plantilla en el nuevo día pone 13 mm él interpreta que han caído 13 mm y "guarda" lo que recibió en la última plantilla con fecha del día de ayer (en este caso 12.6 mm) y lo suma y si encuentra 0.4 mm en la plantilla también se los suma a los 12.6 mm.
Si, todo eso hace, pero ¿es lógico que?:
1º A las 00:00 de un día que está comenzando, aparezca que ya han caído 13mm. (13mm en 0 segundos, intensidad de lluvia infinita)
2º A las 00:00 aparezca que el Episodio Precipitación sean 25,6mm cuando solo han caído hasta ese momento 13mm.
3º En el día anterior ponga que han caído 12,6mm cuando han caído 13mm.
No, no es lógico.
Yo por mi parte no voy a darle vueltas al tema más ni voy a buscar reducciones al absurdo ;D ya que lo tengo meridianamente claro. Si weewx hace lo que tú dices no por ello van a hacer los demás programas lo mismo o hay que cambiar todo el sistema para que lo interprete para tu plantilla.
Es verdad, reconozco mi error. No todos los programas tienen que poder hacer lo que yo diga o piense como lógico para conseguir no perder los datos definitivos del día, los del final, pero creo que a todos nos gustaría que no se perdieran. Yo lo estoy intentando. Perdoname por mi insistencia.
Saludos.
-
Desde luego Amon-K se nota que tienes una mente inquieta ;D ;D
Te voy a ir puntualizando aunque yo tenga también visión parcial...
Buenas noches jmviper.
Creo que tienes razón y muchas veces hago extensiva mi visión parcial, ya que desconozco en profundidad otro software que no sea Weewx.
Yo también creo que a las 00:00 cambia la fecha, pero lo hace porque las 00:00 es el final del minuto 60 de la última hora del día que termina y coincide que también es el principio del minuto 1 de la primera hora del día que empieza, con todas esas coincidencias es normal que cambie la fecha. Y hago hincapié, las 00:00 es las dos cosas y no solamente la segunda.
Aquí podríamos debatir sobre el famoso caso de qué es primero el huevo o la gallina....
Te explico...
Cuando pones el cronómetro en tu móvil o en un reloj qué tiempo pone?? 0:00:00.000 (si pone milésimas claro) y ... eso no es el final de nada ... es el principio de algo en este caso la cuenta y en el caso que nos ocupa las 0:00:00 no es el final del día anterior sino el principio del día siguiente sencillamente porque en ese instante cambia la fecha y no pertenece ya al día anterior mires por donde lo mires.
Si por ejemplo meteoclimatic ve que en la plantilla pone por ejemplo "día 12" y lee también "13 mm" interpreta que ese día han caído 13 mm independientemente de si son las 0:00 o las 0:01 o las 3:00.
Si weewex manda una plantilla con el día siguiente "día 13" con hora 0:00 y pone "13 mm" crees que debe interpretar meteoclimatic que son del día 12 ?? Pues no, interpreta lo que es que son del día 13.
Programando se puede hacer de todo hasta considerar que el instante 0:00:00 es del día anterior pero creo que no es lo lógico por lo que ya he expuesto anteriormente (que el instante 0:00:00 no pertenece al día anterior).
También en WD se puede configurar el momento en el que se resetean los datos. Si quiero leer los datos de las 00:00 no tendré que resetear en ese momento, sino despues, por ejemplo a las 00:01. Quizás, y recalco quizás, entonces podría estar en la plantilla generada a las 00:00 los datos que buscamos y que se pierden.
WD no hila tan fino... puedes poner cualquier hora sí pero es hora en punto. No admite minutos.
Lo dicho antes. Cada uno con las características de su programa que haga lo que mejor pueda para no perder datos.
Saludos
-
Buenas noches jmviper.
Cuando pones el cronómetro en tu móvil o en un reloj qué tiempo pone?? 0:00:00.000 (si pone milésimas claro) y ... eso no es el final de nada ... es el principio de algo en este caso la cuenta y en el caso que nos ocupa las 0:00:00 no es el final del día anterior sino el principio del día siguiente sencillamente porque en ese instante cambia la fecha y no pertenece ya al día anterior mires por donde lo mires.
El ejemplo del cronómetro no es comparable con nuestra disquisición. Antes del comienzo de la cuenta del cronómetro no hay nada. Antes del comienzo de un dia hay otro y sin parar.
Siempre me dices que las 00:00 no es el final del día anterior pero nunca me dices donde está. ¿Existe?. Me gustaría que me dieras tu visión razonadamente. Voy a empezar yo a darla.
Vamos a empezar el razonamiento desde el principio.
Creo que podemos estar de acuerdo en que cada día tiene un principio y un final (y en medio, su afán como dice un refrán ;) ;)).
También podemos estar de acuerdo en que el final de un día tendrá que llegar no despues de que comience el siguiente porque en ese caso habría algunos momentos en que no sabríamos en qué día estamos, y sabemos que esto no le ocurre a las personas normales. Es decir solo existen dos posibilidades o llega antes o al mismo tiempo.
Si llegara antes, ¿en medio que hay?, ¿un minuto?, ¿un segundo?, ¿alguna otra cosa?. Si hubiera un segundo o un minuto al hablar de una semana diríamos: son siete días y siete segundos, o son siete días y siete minutos y así no lo expresamos hasta ahora, luego esta opción no parece verosímil. Si hubiera alguna otra cosa, ¿no lo habríamos descubierto?, ¿no habría equipos de investigación trabajando en ello?, tendríamos que decir al referirnos a una semana, son siete días y siete algunas otras cosas. Yo no he oído nunca nada parecido, luego tampoco me parece verosímil, y por otro otro lado quien hubiese organizado la medida del tiempo de esta manera habría sido un torpe.
Luego, por reducción al absurdo (ya sé que no te gusta mucho esta forma de razonar pero es tan válida como cualquier otra), solo queda una opción: que coincidan.
En términos numéricos y de medida del tiempo, y un poco más en serio, podríamos expresarlo de la siguiente manera:
22/10/2016 23:59:60 = 23/10/2016 00:00:00
La primera parte de la igualdad representa el día 22 de Octubre de 2016 en la hora 23 y 59 minutos y 60 segundos, es decir el final del día 22. La segunda parte de la igualdad es el día 23 de Octubre de 2016 a la 0 horas y 0 minutos y 0 segundos, es decir el comienzo del dia 23. Si hacemos las operaciones necesarias en el primer término obtenemos el segundo, ambas términos son por tanto iguales, es decir son el mismo momento, coinciden. Observa también que cambia la fecha en ese momento.
Si despues de saber donde está para tí el final de un día nos ponemos de acuerdo, quizás podamos avanzar, ¿no crees?.
Saludos.
-
La respuesta 41 en este hilo tiene las claves.
Sea magnitud física ponderable, sea dimensión añadible a las demás, las divisiones del tiempo son convencionales.
En este aspecto, Meteoclimatic se atiene a convenciones admitidas universalmente.
O casi.
Otras redes funcionan de otra manera, y tal vez compartimenten el tiempo "mejor" de lo que se hace aquí, y recojan sin pérdida alguna los datos que obtienen,a la perfección.
Si este es el momento en que hay que reconocer que aquí se pierden ínfimas, irrelevantes cantidades de datos, unas pocas veces al año, en unas pocas estaciones en las que puedan darse determinadas circunstancias de lluvia, se hace sin que nos duelan prendas.
Ya hemos llegado a un punto de bizantinismo insomne, que en mi opinión hace inútil y superflua cualquier intervención posterior a esta.
Meteoclimatic funciona como debe, quizá de modo imperfecto, y desde luego perfectible como cualquier obra humana.
Son las lentejas que hay. No se van a cambiar a gusto de uno ( ¿de cada uno?) de los usuarios.
Por mi parte, considero suficientemente debatido el asunto, e irresoluble hoy por hoy, y no intervendré más.
-
Por cerrar el debate.
Ya lo dije al principio.
El trabajo de Amon-K me parece encomiable, pero llega un momento que no puedes avanzar más, por la propia tecnología de Meteoclimatic.
Posiblemente, en un futuro próximo, la actualización, en lugar de cada 15 minutos, será cada 5 minutos.
Pero el tema debe cerrarse. Meteoclimatic no puede cambiar todo el código, por la sencilla razón que tendría que convertirse en un sistema en tiempo real absoluto para 2000 usuarios, y eso es imposible ahora.
Saludos.
-
Teneis razon.
Ya jmviper me hizo ver que el tema no tenía mucho recorrido pero a veces la corriente te arrastra al lugar no deseado, intentando hacer ver aquello que te gustaría que los demás vieran.
Pido vuestra comprensión. No insistiré más. Por mi parte tema cerrado.
Saludos.
-
El tema de la pérdida de datos en los últimos minutos del día se solucionaría añadiendo de forma rutinaria el resumen del día anterior, igual que se incluye el resumen del día en curso, del mes en curso y del año en curso.
Que habría que cambiar cosas en los scripts de Meteoclimatic: Seguro. Pero no hay nada que no tenga solución.
Un saludo.
-
El calendario y los mapas resuelven eso.
-
El tema de la pérdida de datos en los últimos minutos del día se solucionaría añadiendo de forma rutinaria el resumen del día anterior, igual que se incluye el resumen del día en curso, del mes en curso y del año en curso.
Que habría que cambiar cosas en los scripts de Meteoclimatic: Seguro. Pero no hay nada que no tenga solución.
Tienes razon Alcion, es como enviar durante 24 horas lo que yo quería enviar fugazmente.
No hay nada que no tenga solución, y muchas veces más de una.
El calendario y los mapas resuelven eso.
Al consultar los datos atrasados podríamos estar viendo datos erroneos, si coincide con uno de esos días y el observador de la Estación aún no los hubiese corregido manualmente.
Saludos.
-
Podríamos.
Si coincide...
Respondí literalmente a lo que solicitaba alcion: indicando como puede consultarse el resumen del día anterior.
-
Podríamos.
Si coincide...
Respondí literalmente a lo que solicitaba alcion: indicando como puede consultarse el resumen del día anterior.
No estaba preguntando como ver el día anterior.
Si el día anterior está mal se verá mal a menos que el dueño de la estación lo haya subsanado.
Lo que quería decir es que una forma de arreglar el problema de la falta de datos cerca del cambio de fecha sería subir el resumen del día anterior, de la misma forma que se suben los resúmenes del día en curso, del mes en curso y del año en curso.
-
¡Vuelta la burra al trigo!
Claro que el post de alcion no planteaba ninguna pregunta.
Era, por mi parte, una torpe manera de explicar a qué me refería cuando escribí lo de los mapas y el calendario.
El resumen del día anterior es perfectamente accesible, de forma rutinaria, desde siempre, como sabemos.
Que esté bien o mal... Que los datos sean perfectos, exactos, corregidos o no...
Se añade de forma rutinaria, cómo cree alcion que debería hacerse.
Aunque tal vez yo no lo comprenda, y alcion quiera ver por duplicado el resumen del día anterior: donde ya está y también en la ficha mis estaciones...
-
No he querido intervenir en este debate, porque la verdad es que me parece que no "ha lugar". Lo dije al principio y lo repito, con enviar lo más tarde posible se soluciona en gran medida el problema.
Queda claro, el último momento, pero eso es algo que a muchos nos da lo mismo, ya que los que corregimos los datos de lluvia con pluviómetro manual vamos a revisar los datos todos los días, o al menos aquellos en los que llueva.
En definitiva, está muy bien lo que proponéis, pero todo lo que hay que supone a nivel de cambio de código, aumento del tamaño de la base de datos, cambio de plantilla, . . . cuando lo único que hay que hacer es estar pendientes cada uno de su estación durante 5 minutos al mes no sé si realmente compensa.
Está claro, que para el que no se preocupa de corregir inconsistencias, esto sería cojonudo, menos trabajo, pero para los que estamos pendientes de nuestras estaciones, la verdad es que con comprobar el informe de nuestro programa y comparar es suficiente y por lo tanto nos da los mismo que durante unas horas fallen unas décimas en una medida, por la mañana ya las hemos corregido.
Supongo que este problema también ocurre en otras redes. Imagino que habrá que proponer el mismo cambio a todas, . . . a no, que las otras no tienen inconsistencias.
Podemos abrir otro hilo para discutir sobre el sexo de los ángeles, . . pero nos va a dar lo mismo, tendrán el que quieran, eso sí nos habremos entretenido.
Que aunque alguno crea que es un offtopic, pienso que no, porque con el movimiento de las alas de alguna manera afectarán a la circulación del aire. .. . . . . . en fin
-
Ni tienen inconsistencias que señalar al usuario, ni guardan y ofrecen valores extremos de un vistazo, ni te ofrecen el resumen de cualquier día del año en dos clicks...
Por citar una donde es fácil encontrar esas características, citaré PWS. Pero no las ofrece al primer golpe de vista. Y desde luego no repara en inconsistencias.
Cada red tiene sus características e imperfecciones, pero el rigor y la exigencia de calidad que requiere Meteoclimatic no son comparables con los de ninguna otra. Que yo conozca.
Por supuesto que hay fallos y aspectos muy mejorables
Se lleva un par de años, o más bien tres, trabajando en una nueva versión de la web, y un día estará disponible, sin duda, pero se hace cuando es posible, lo que significa que más despacio de lo que a muchos nos gustaría.
Quizá la nueva versión web solucione algunas de estas pequeñas cosas. Habrá que esperar, y mientras tanto soportar esa minucia ( a mí me lo parece) a riesgo de que algunos de los miembros de Meteoclimatic lamenten su existencia.
-
Aunque tal vez yo no lo comprenda, y alcion quiera ver por duplicado el resumen del día anterior: donde ya está y también en la ficha mis estaciones...
Bueno, no sería exactamente lo mismo, lo que propone alción sería modificar sensiblemente la mecánica de trabajo en las bases de datos.
Ahora se va acumulando el dato diario y queden registrados los valores máximos y mínimos de cada día, y de ahí se extraen los máximos y mínimos mensuales y anuales, que al compararlos con los datos que enviamos en la plantilla es cuando se originan las inconsistencias.
Lo que propone Alción, es que los datos que enviamos como datos actuales no se guarden, vamos que con el cambio de día se olviden las máximas y mínimas que se han ido registrando durante el día y sea un grupo nuevo de datos que habría que incorporar a la plantilla la que rellene los datos de cada día para el histórico.
Pongo el ejemplo de Cumulus, este programa presenta en la página web que trae enlatada los datos del día de Ayer. Serían esos datos los que habría que enviar para rellenar los datos de cada día en la base Meteoclimatic.
Haciéndolo así, no habría duplicidad, pero sinceramente y como he dicho en el post anterior, creo que si todos nos preocupamos de revisar nuestras estaciones todo esto sobra.
-
JOJOJOJ nos vamos pisando las respuestas jeje
-
:D
-
Creo que Ubik ha entendido bien la propuesta de alcion y en su Respuesta #73 la ha explicado.
Yo ya he asumido que el codigo no se cambia y por tanto no propongo nada, pero al "Cesar lo que es del Cesar....", la propuesta de alcion es acertada, y creo que, contrariamente a lo dicho, no tiene porqué aumentar necesariamente el tamaño de las bases de datos, ya que los datos que incluye de más en la plantilla solo vendrían a corroborar o a corregir los datos ya almacenados del día anterior. Pero esto ya no tiene importancia porque si hay un nuevo software en preparación seguro que se cubre éste y otros muchos nuevos objetivos, si no, no se prepararía.
Creo que todo este debate no ha sido inútil. Espero que haya servido para aprender algo en el camino, yo si lo he hecho.
Saludos.
-
Muchas gracias Amon-K ;)