[werk_ag]

Due to the bug i had the 35th of Oktober written on the Display for example. I don't know which timestamp is saved here, but it can not be good  .
Moreover I'm thinking of the possibility to specify a time range where the data should be kept and the other stuff should be deleted.

For those that are not inside the matter we are talking about, I think its important to say that this strange date (35th of Oktober) referred by engolling, which was also stored on the logger, is a consequence of compiling the weatherduino code using avr boards manager 1.6.22 or 1.6.23, otherwise it would never have happened. At least I never saw it happen before.

[engolling]

@engolling, We both know that this question about wrong or invalid records was started with a problem caused by the use of AVR boards manager 1.6.22 and 1.6.23 which messes the system clock which by turn causes that records on the data logger have a wrong timestamp.

Considering that there are hundreds of bug reports related to avr 1.6.22 I'm not concerned it it. Recommendation on Arduino.cc is: if a software not works with 1.6.22 or 1.6.23 revert back to 1.6.21

So, why are we complicating or creating the idea that WeatherDuino stores invalid records on the logger?

Due to the bug i had the 35th of Oktober written on the Display for example. I don't know which timestamp is saved here, but it can not be good  .
Moreover I'm thinking of the possibility to specify a time range where the data should be kept and the other stuff should be deleted.

For those that are not inside the matter we are talking about, I think its important to say that this strange date (35th of Oktober) referred by engolling, which was also stored on the logger, is a consequence of compiling the weatherduino code using avr boards manager 1.6.22 or 1.6.23, otherwise it would never have happened. At least I never saw it happen before.

Just to clarify:
Of course we know that this was (and still is) a result of a bug in the Arduino AVR board library. It took us a whole evening to find out what happened.  
In my opinion there was never a bug in the WeatherDuino source code causing a data problem and also not in the WeatherDuino logger. This was all a result of the faulty Arduino.

Like I said before, I will have a closer look at all the code especially how the logger works and more important what WeeWx does with the loaded data and then I will decide.

Have a nice day,
engolling

[engolling]

So I studied the behavior of WeeWx and the WeatherDuino logger and I must confess I had an attack of doing things for the sake of doing things.   

You were right, Werk I tried everything and how to cause possible failures and you get rid of most of the problems just in delaying the start of WeeWx.
Moreover, if you have your system battery powered you beat nearly all problems.

So sorry again for making a strom in a teacup. The next weeks I might come up with a tutorial how to use the WeatherDuino best with WeeWx.

Best regards,
engolling

[werk_ag]

... I tried everything and how to cause possible failures and you get rid of most of the problems just in delaying the start of WeeWx.
Moreover, if you have your system battery powered you beat nearly all problems.

Hi Engolling,

I'm grateful for having someone like you playing with the system. I think that most of the times, the person who design a system will never try to run it outside the working conditions for what he was designed (at least happens with me   ). The role of persons who do some tests not observing the ideal working conditions, become even more important on this cases.

Starting the communication between the weather software (Weewx or any other) and WeatherDuino just after the initial screen which says "Don't start weather software until this window closes" disappear is really very important.
For a fail safe and unattended  production system, both WeatherDuino and the machine running the weather software (a PC or a PI) should be powered by the same power supply. In the event of a power failure, WeatherDuino will restart, a delayed start of the weather software will ensure that it will start only after the WeatherDuino ended its initialization sequence (which happens only after he was able to receive data from at least from T/H, Wind and Rain).

Once created the expected working conditions, I'm almost sure you will find a very reliable system.
Take a look here (Weather Station last started, 37 days 1 hours): http://www.crasmontejunto.org/meteo/wxstatus.php

This station runs almost unattended for long periods. WeatherDuino, PI (running CumulusMX) and a 3G/4G modem are all powered via a 600VA UPS, which also protect the system for mains power supply fluctuations.