Cumulus Support

I seem to have a problem getting data from my Davis data logger after any MX shutdown.
I shut down CMX, copied directories, used InstallCMX to update CMX,, checked install log - no errors and restarted CMX.
Current data collection is fine but the data is missing for the 20 minutes it took me to upgrade to current CMX.
Why is it not going back to when I shutdown and 'catching up' the data?
It did the same thing to me when I had a power outage and I had to go to a backup from a midnight copy.
Is CMX supposed to read the stored data from the time of shutdown? Maybe that is where I am confused.
Thanks,
Wayne

Edit: I am running a five minute collection time on both the logger and CMX.

Hi,

Why is it not going back to when I shutdown and 'catching up' the data?

It should do that. However there was a change back some time ago in the format for the Records Began Date; in Station Settings > General Settings > Advanced Options. Is your settings correct?

Is CMX supposed to read the stored data from the time of shutdown?

Yes, if the data is in your logger it should just continue from the time it was shut down. If you use a \data\backup for a CMX restart then it should catch up from that backup time.

Is there anything in your MXdiags files on reading archive data from logger?

Enjoy,
Paul

Paul,
My settings for the begin date match the YYYY-MM-DD format.

The MXdiags file looks normal until it goes to read the archive, then...

2023-08-25 15:30:20.518 Failed to get the latest build version from GitHub
2023-08-25 15:30:20.521 Failed to get the latest build version from GitHub - Exception Type: System.Threading.Tasks.TaskCanceledException
Message: The operation was canceled.
Inner Exception...
Exception Type: System.ObjectDisposedException
Message: Cannot access a disposed object.
Object name: 'MobileAuthenticatedStream'.


2023-08-25 15:30:21.668 WaitForACK: ACK received
2023-08-25 15:30:21.668 GetArchiveData: Waiting for response
2023-08-25 15:30:21.681 GetArchiveData: Response: 01 02 01 00 2B E5
2023-08-25 15:30:21.681 GetArchiveData: Reading data: 513 pages , offset = 1
2023-08-25 15:30:21.681 GetArchiveData: Downloading entire logger contents!

It does download the entire archive from the logger, including the data that appears to be missing from the graphs.

If the graphs appear flat lined, should I be checking somewhere else in the data logs to verify it did catch up. It looks like it read all the data.

Wayne

Hi,
I don't know why it could not access github to check for latest build, but that should not be an issue for running CMX.
Downloading the full 513 pages from the data logger usually is that the interval settings are different in the logger and CMX, but you say they are the same. Mabe some glitch when you updated... Check what it does the next time you do another CMX restart.

should I be checking somewhere else in the data logs to verify it did catch up

The monthly log files contain all the data CMX has recorded from both catch-up and live running. With your 5-minute interval check dashboard Data Logs > Monthly logs and select a Start Date from 17 days ago (5-minute interval has 17 days of data in the logger) and see if there is an entry every 5 minutes to current.

Enjoy,
Paul

One thing that worked for me was to build in a delay in start of CMX and also ping a host just to ensure the internet is up and running. The start delay is in CMX settings/ program and i used 10 secs and that resolved the cant se GitHub error.

I hope it works for you.

For the first error - what Andy says! CMX is starting before your network has come up.

Please post the full log file and I'll take a look at what went wrong.

Thanks for all the replies.
I looked in the monthly log files. It shows the same gap. I have not changed the logging interval since I started using the Linux machine. I would like to check it though. Is there anyway to view the datalogger settings other than to connect it back to my Windows machine and use WeatherLink?

FYI, I am running CMX as a service on a Raspberry Pi4 using the latest release. I will cycle CMX and see what the diags say about the github and then try a 10 second delay for startup. I did not see this message when I first switched CMX to the Linux box. Might have missed it though.

mcrossley, I will get a copy of the goofy file over to my Windows machine and attach it.

Paul,
Close examination of the diag file shows a line that tells me what the Davis logger is set at. It IS the same as the CMX setting.

Andy,
Put in the 10 second delay and the GitHub message is gone and it appears as if the CMX program is picking up the data between S/D and S/U. Definitely not reading the entire console data. Just started back up after a 20 minute wait and the graph and data logs picked up the console archive at the 5 minute interval. This is the behavior I expected.
The diags file has a line that stating there is no delay even after I entered the 10 second delay. I went back after the latest S/U and checked the setup. It does have 10 seconds stored as delay.

mcrossley,
I have attached the diags file of a startup that still was loading the entire archive. It exceeded the file size limits so I had to Zip it.

Thanks all,
Wayne

Hi Wayne

I have just checked the top of the MX Diags file and see that your system time is 2,700 seconds adrift ie 45 mins. I am sure this will give you all sorts of issues.

This can be corrected at CMX admin/Station settings/Davis Advanced settings/clock and tick "synchronise clock"

Also I see there is no startup delay, this is at CMX admin/Program settings/Startup delay and set to 10 secs.

I would suggest that once you have amended the above items you stop CumulusMX and restart CMX.

Also I am not sure if you haveCMX running as a service, whilst this does not affect the running it does maqke it easier to restart after a reboot of the RPi

Yep, the clock drift is the issue.

At 15:30 CMX requests archive data from 15:15. Because the clock is wrong, the logger only contains data up to 14:45. As it cannot fulfill the request it sends the whole logger contents (that is normal Davis logger behaviour). And of course there is no data loaded during catch-up.

Thanks all!
I have made the suggested changes and testing has been successful.
The explanation makes perfect sense.
I would have never thought of the time being off would be the problem. I did notice that diag line, didn't know how it happened, and thought I would correct it after I fixed the data gap problem. Didn't want to introduce more things to trouble shoot.


Wayne

Glad to help