Ecowitt Api Historic Data

[Box]

You would need to go back to a backup from before "the gap". The logs you posted were from after.
The screen shot showed going back to 22 Feb which was before, but there were no logs from that run.

ok

Strange, I thought I had done that

Maybe I misread the folder

I will try again

[Phil23]

You have the same error as @box was getting "API.GetHistoricData: Exception:"
I have a new build to fix this.

So I assume I can just keep letting things run for the time being & then when the next build is relaeased,
revert to my 9:05am 15/03 data & then restart & let it all process.

Will make sure I have the most relevant level of debugging on when I get to that point.

[Box]

You would need to go back to a backup from before "the gap". The logs you posted were from after.
The screen shot showed going back to 22 Feb which was before, but there were no logs from that run.

ok

Strange, I thought I had done that

Maybe I misread the folder

I will try again

Success!!!

I used a backup from before 'the gap' AND deleted my Mar22log.txt file (backed up first of course ), then ran CMX 3172 and the whole mar22log.txt file was reconstructed with 'the gap' filled in




Many thanks for your help

[Phil23]

You would need to go back to a backup from before "the gap".

I "Thought" I tried my midnight one before the 9:00 last update issue, but maybe the Linux archiver didn't overwrite as expected.

Success!!!

I used a backup from before 'the gap' AND deleted my Mar22log.txt file (backed up first of course ), then ran CMX 3172 and the whole mar22log.txt file was reconstructed with 'the gap' filled in

I may not have that option now due to my backup rotation.
Only have the March 15th 9:05am backup preserved.
Would be no data prior to the above date if I deleted Mar2log.txt

Presently when I restore that I end up with a gap from 9:00am 15th up to the time I start MX after the restore.

Phil.

[Box]

You would need to go back to a backup from before "the gap".

I "Thought" I tried my midnight one before the 9:00 last update issue, but maybe the Linux archiver didn't overwrite as expected.

Success!!!

I used a backup from before 'the gap' AND deleted my Mar22log.txt file (backed up first of course ), then ran CMX 3172 and the whole mar22log.txt file was reconstructed with 'the gap' filled in

I may not have that option now due to my backup rotation.
Only have the March 15th 9:05am backup preserved.
Would be no data prior to the above date if I deleted Mar2log.txt

Presently when I restore that I end up with a gap from 9:00am 15th up to the time I start MX after the restore.

Phil.

If you backed up previous installs before upgrades you should have some older backups squirrelled away if you dig

The one I used was from three version ago

I never delete anything, just bung it in an Old Cumulus folder
Check your recycle bin?

Good luck!

[PaulMy]

The issue with going back too far for historical backup data is that it may miss some of the extremes that are logged with live data. Logger data is recorded at what it is at the logging interval time. While running, Cumulus saves highs and lows from ongoing live data from the station. But at start up Cumulus gets the data provided from the logger, which may have missed some highs and lows between logging times. So in restoring from backup I try to find the latest prior to a data loss/corruption issue - check dayfile and month log files, and also keep in mind how far back the Davis logger has data. This past logged data may not be an issue if Ecowitt data access is unlimited.

Enjoy,
Paul

[Box]

The issue with going back too far for historical backup data is that it may miss some of the extremes that are logged with live data. Logger data is recorded at what it is at the logging interval time. While running, Cumulus saves highs and lows from ongoing live data from the station. But at start up Cumulus gets the data provided from the logger, which may have missed some highs and lows between logging times. So in restoring from backup I try to find the latest prior to a data loss/corruption issue - check dayfile and month log files, and also keep in mind how far back the Davis logger has data. This past logged data may not be an issue if Ecowitt data access is unlimited.

Enjoy,
Paul

Good point

My backup was about 3 weeks old. I guess it might be a good idea to stop/start CMX regularly, say every few days, to generate more backups?

[freddie]

The issue with going back too far for historical backup data is that it may miss some of the extremes that are logged with live data. Logger data is recorded at what it is at the logging interval time. While running, Cumulus saves highs and lows from ongoing live data from the station. But at start up Cumulus gets the data provided from the logger, which may have missed some highs and lows between logging times. So in restoring from backup I try to find the latest prior to a data loss/corruption issue - check dayfile and month log files, and also keep in mind how far back the Davis logger has data. This past logged data may not be an issue if Ecowitt data access is unlimited.

Enjoy,
Paul

Good point

My backup was about 3 weeks old. I guess it might be a good idea to stop/start CMX regularly, say every few days, to generate more backups?

Backups are performed daily as routine. Do you need more frequent than that?

[Box]

The issue with going back too far for historical backup data is that it may miss some of the extremes that are logged with live data. Logger data is recorded at what it is at the logging interval time. While running, Cumulus saves highs and lows from ongoing live data from the station. But at start up Cumulus gets the data provided from the logger, which may have missed some highs and lows between logging times. So in restoring from backup I try to find the latest prior to a data loss/corruption issue - check dayfile and month log files, and also keep in mind how far back the Davis logger has data. This past logged data may not be an issue if Ecowitt data access is unlimited.

Enjoy,
Paul

Good point

My backup was about 3 weeks old. I guess it might be a good idea to stop/start CMX regularly, say every few days, to generate more backups?

Backups are performed daily as routine. Do you need more frequent than that?

Not sure how the backup system works, the named folders are not 24 hours apart but 24 hours is more than enough

[Box]

Good point

My backup was about 3 weeks old. I guess it might be a good idea to stop/start CMX regularly, say every few days, to generate more backups?

Backups are performed daily as routine. Do you need more frequent than that?

Not sure how the backup system works, the named folders are not 24 hours apart but 24 hours is more than enough

Since found the daily backup folders

[mcrossley]

The patched release 3.15.3 is now available.

[Box]

The patched release 3.15.3 is now available.

Many thanks for your help