revert to setting lastvalue in only success case

[dockSquadron]

fixes bug #2505

[Slider0007]

Be careful: Lastvalue timestamp is also used for data logging faeture. Reverting this only back will distort data logging feature (Multiple lines with same timestamp from last successful reading whenever a "bad" reading is logged).

In my opinion two separate timestamps are required, one for data logging feature to ensure growing timestamps for every reading and one for your need which is only updated on succesful reading.

[caco3]

@Slider0007 What do you think? Nobody else has an issue with it. And as you say, it changes the behaviour, so I would not merge it.

[Slider0007]

@Slider0007 What do you think? Nobody else has an issue with it. And as you say, it changes the behaviour, so I would not merge it.

@caco3: In my opinion, this change is necessary to fulfill the 'self-healing' feature of Rate too high with the RateChange setting, so it is correct in principle. However, the PR would have to be extended to solve both related topics. If only this PR gets merged, the problem of data logging would be open again, which was already addressed in #1839. Therefore, I would suggest using two separate timestamps for the contrary purposes of 'Max Rate Check purpose' (update timepstamp only on a valid reading) and 'Data Logging purpose' (update timestamp on every cycle).

[caco3]

@SybexX Do you think we should add this to the next release?
It sounds as if there is some more work and testing required.

[SybexX]

is fixed: f8eb4db

[caco3]

is fixed: f8eb4db

Does that mean the issue got solved in #3180 and we can close this PR without further work?

[SybexX]

Yes, exactly and @Slider0007's concerns were also taken into account/incorporated.

    time_t timeStampLastValue;     // Timestamp for the last read value; is used for the log
    time_t timeStampLastPreValue;  // Timestamp for the last PreValue set; is used for useMaxRateValue