Veamos
En cuanto al reloj falso. No tiene nada que ver con que actualice la hora correctamente.
El reloj falso lo que hace es que, periódicamente, modifica un fichero, indicando la fecha y la hora de ese momento.
En el momento de reiniciar, si el ntp no toma correctamente la hora, asume la hora y fecha grabada en ese fichero como correcta.
ESTO ES UN ERROR GRAVISIMO. Por ese motivo, se indica que hay que eliminarlo.
Si lo vuelves a instalar, debería ser porque sabes lo que conlleva:
- Son las 12 horas del 5-1-2017
- Se va la luz, se apaga la raspi
- Vuelve la luz el 6-1-2017 a las 12 horas
- El router tarda más en sincronizar que lo que tarda la raspi en arrancar
- Weewx en sus últimas versiones compreba que la fecha del sistema sea superior a una fecha concreta.
- El sistema lee el reloj falso.
- Para la raspi son 12 horas del 5-1-2017, pero en realidad ya estamos a 6 de enero
- Weewx lo da por bueno.
- Weewx cambia la hora de la consola (en el caso de las Davis)
- Se empiezan a grabar datos, con fecha 5 de enero.
- UN DESASTRE
Con las versiones 3.50 y superiores, si la fecha del reloj es 1-1-1970, Weewx no arranca y no nos provocará un caos en la base de datos. Con las versiones inferiores a 3.50 había que hacer un apaño en el script que ya publiqué. No dejan de ser apaños, pero evitan males mayores con la base de datos.
En cuanto a lo de que ya esté la hora correcta y Weewx no actulice todo el invento, ya lo hemos comentado muchas veces, estos últimos 15 días.
En la documentación de Weewx tienes un apartado específico
weewx generates HTML pages, but it does not update them
If you are getting a symptom that everything appears normal, that is image and HTML files are generated ((look in the log to be sure) and sent to your webserver (if you have configured FTP or rsync), but the values in the web pages are not being updated, it could be due to clock skew or corrupt station memory.
Clock skew
If the database contains a record with time stamp (the dateTime field) in the future, then records from the station that are older than that future date will be ignored. How can the database contain records from the future? Sometimes the computer clock is not set correctly. For example, the raspberry pi has no clock, so if weewx saves data before the pi has synchronized its clock with internet time servers, the records will have incorrect time stamps, some of which might be in the future.
The solution is to delete any records with time stamp in the future. For a sqlite database, the procedure looks like this:
cp /home/weewx/archive/weewx.sdb /home/weewx/archive/weewx.sdb.backup
sqlite3 /home/weewx/archive/weewx.sdb
sqlite> delete from archive where dateTime > X;
sqlite> .exit
The timestamp X is the current time as unix epoch (number of seconds since 1 January 1970), or a time a minute or two in the future.
Corrupt station memory
If you have a Vantage station, the problem might be because the data on board your console has gotten garbled. The way the Davis Vantage series works is that the software (weewx in this case) asks the console for all archive data "since" some time. The console then downloads the records one at a time. After it gets to the very last one, the memory wraps around, and the timestamp will suddenly jump backwards in time a couple weeks — this how the software knows it has downloaded the last record and so it stops.
However, if the internal memory gets garbled, the console will immediately return archives in the past, and so it looks like the timestamps have decreased in value and so weewx figures that is it: there is no more data.
I have received reports from a couple of users who have had this problem. There seems to be two fixes:
Unplug the console, take out the batteries, and wait a minute or two. This will cause the console software to internally reboot. In one case this has fixed the problem without data loss.
If all else fails, clear the memory of the console using the utility wee_device. This may cause loss of data, but usually works. Adjust paths as necessary:
wee_device --clear-memory
See also the section Dumping the logger memory, which may help you avoid data loss.
