Cumulus Support

Where is Rain this Month pulled from? I have an issue with my ISS last night that sent a ton of erroneous rain. I updated SQL to get rid of all of the junk data, but this rain month keeps coming back. I am thinking it is stored in my Weather Enovy (used to connect the VP2 to my server) but there is no way to remove it from there if so. My hope is I can fix it in one of the ini files.

It is calculated from the daily values in the dayfile.

Awesome thank you. I had updated SQL and used a script to keep it updated. I didn't realize that I needed to update the txt file as well. Fixed now.

Cumulus uses the text files internally - the SQL is "write only".

Mark, I was away for 2 weeks, so sorry for the slow reply. I just looked and there still seems to be a lingering issue. My total rainfall for the year is 20.89" and my rainfall for this month is 0.54". Ignoring SQL (as you mentioned the values are pulled from the dayfile"), I confirmed the dayfile shows values in the Total rainfall for day column adding to 20.89, and the values for the first 5 days of this month adding to 0.54. However, the Cumulus dashboard is showing 0 this month and 19.93 for the year. Might there be somewhere else I need to check and review/confirm?

Mark, to follow up on this, when I had a previous issue with updating Cumulus "breaking" the ability to write to SQL, one of my "fixes" was to create new tables. I created dayfile_new, monthly_new, and realtime_new. I updated Cumulus settings and confirmed the tables were being written to. I then copied all of the data from the old tables to new. I have confirmed everything still looks good. However, I did the math and my yearly rain was at 19.93" the day I made that change. Since (from my understanding) the only values on the dashboard that need the historical data are the monthly and yearly rainfall totals, could the fact that my dayfile is "dayfile.txt" but my db table is "dayfile_new" be the culprit here? If so, I would assume that I could just switch the Cumulus settings back to the original table names, confirm they are being written to, then update them with the last few weeks of data.

Let me know if this makes sense or if my explanation is convoluted....

No connection, the SQL tables are "write only" Cumulus never reads from them. The source of data for MX are the log files.

Got it. Reviewing again, my idea didn't make sense as I actually changed the table names on 6/12, and the rainfall was correct. So, this issue did indeed start on June 20th or 21st. But still, I'm not sure of the next steps. The dayfile is correct. There are no permissions issues or anything with it. I have a server reboot weekly on Sunday nights at 7pm EST. I just checked the mxdiags log and it is loaded with issues. Might you be willing to review it?

Post your log file and I'm sure someone will take a look. Maybe even me if I get a 5 minutes.

Fair enough. It has been updating every single minute since starting Cumulus after the reboot last night. So, I removed the middle 16 hours or so since the file was too large to attach. As an FYI, one of the reoccurring messages points to an FTP issue. However, my entire platform is local, so no data is being sent via FTP anywhere..

I have finished my painting for today, so I will take a look at your diags...
OK you have 2 main errors. The first above is reported just once, but it means MX cannot read past rainfall from the daily summary log file because there is an error on line 1466.

Open the log file in an editor that shows line numbers, you might be able to spot what makes that line different from preceding ones (there may be errors on successive lines, MX only states first line with fault). If you need help, check the line against rules listed in https://cumuluswiki.org/a/Amending_dayf ... ayfile.txt EDIT: updated link

The second error constantly repeats, it means you have not obeyed the rules listed at https://cumuluswiki.org/a/MX_Administra ... e_interval

I'm not solving this for you, you need to look at your set-up and read the rules, but I can give you some pointers. If you are still stuck, in another post, paste a few lines each side of the faulty dayfile.txt line and paste the MySQL part of Cumulus.ini removing first any passwords or other security content.

Local or FTP is totally irrelevant. As Mark keeps saying, Cumulus is not interested in anything outside the CumulusMX data folder, it only writes to (not reads) any local web server.

SFWS, thanks for checking into this so quickly. Regarding the dayfile line error, I found (about an hour ago) a blank line was inserted. I must have inadvertently done this some point recently. This has been fixed and confirmed to have resolved the dashboard, txt files, and SQL rows being correct.

Regarding the SQL delete issue, reviewing the wiki, it appears what you are pointing to is the retention string. Since I created/recreated tables during my update-related troubleshooting about a month ago, I am guessing this is where I went astray... I set up Cumulus four years ago and don't recall this being part of the process nor were there existing strings in the ini file. However, if you wouldn't mind confirming that this is what you are hinting to, I can shoot over any confirming info such as screenshots and whatnot.

To update, for a test, I removed the existing retention string (7 DAYS). I restarted Cumulus and ther SQL error is gone. I'm now down to that existing FTP error which repeats every minute:

2020-07-06 13:44:00.271 Writing log entry for 7/6/2020 1:44:00 PM
2020-07-06 13:44:00.271 Written log entry for 7/6/2020 1:44:00 PM
2020-07-06 13:44:00.271 Writing today.ini, LastUpdateTime = 7/6/2020 1:44:00 PM raindaystart = 20.89 rain counter = 20.89
2020-07-06 13:44:00.333 MySQL: Table Monthly_new 1 rows were affected.
2020-07-06 13:44:02.889 Realtime[3]: Error reconnecting ftp server - The connection was terminated before a greeting could be read.
2020-07-06 13:44:02.890 Error uploading realtime.txt to realtime.txt : Unable to read data from the transport connection: An established connection was aborted by the software in your host machine.
2020-07-06 13:44:32.904 Realtime[4]: Error reconnecting ftp server - The connection was terminated before a greeting could be read.
2020-07-06 13:44:32.904 Error uploading realtime.txt to realtime.txt : Unable to read data from the transport connection: An established connection was aborted by the software in your host machine.

sfws wrote: ↑Mon 06 Jul 2020 5:06 pm Local or FTP is totally irrelevant. As Mark keeps saying, Cumulus is not interested in anything outside the CumulusMX data folder, it only writes to (not reads) any local web server.

Understood. However, I didn't used to see this error in the diags. So, I'm hoping to fix whatever it is, whether or not it's really an issue.

Reply typing beaten by Mark!