Cumulus Support

Hi All,

I have been using Cumulus for many years with my good old WH1080 - mostly without any major tweaks. Been updating MX since a while but a release or two ago the summary graphs stopped showing data - namely the Daily Rain and the Daily Temperature. The js just does not load any data anymore - just blank graph. All other graphs are showing fine.

Now the station is getting a bit old and my outside humidity sensor stopped working for some reason during this winter too ... not sure if there is a way to get it going again. But the daily graphs are more concerning. I tried running it also on a fresh install of latest MX with the same result. I checked the js folder but the files are there and the device has internet connectivity, uploading files to ftp with same blank.

Any idea what might be the culprit here?
Thanks a lot!

I can think of two reasons.

This could be the one https://cumuluswiki.org/a/FAQ#My_comput ... t-lined.27 i.e. is your computer hibernating and secondly there is a minimum amount of sensors that Cumulus will work with and I think the lack of a humidity sensor is one that will cause this problem.

It may be worth checking this as well...
https://cumuluswiki.org/a/FAQ#My_temper ... h_is_empty

There may be message in your MXdiags log files about a corrupt line in Dayfile.txt

Thanks for the responses.
The computer is not hibernating but it might have started with the broken humidity sensor - not sure. Also I could not find a way to open the plastic box to see if there is any gunk on the connectors or something else - seems to be sealed. The idea that running a new instance might not show the data is also relevant.

However, I looked at the log file and foudn several entries with dayfile.txt errors.

2020-08-05 08:24:43.855 GetRainfallTotals: Error on line 102 of dayfile.txt: Input string was not in a correct format.
2020-08-05 08:24:43.855 Rainthismonth from dayfile.txt: 0
2020-08-05 08:24:43.855 Rainthisyear from dayfile.txt: 0

or couple of these...

2020-08-05 08:24:44.412 Error at line 102 of data\dayfile.txt : Input string was not in a correct format.
2020-08-05 08:24:44.412 Please edit the file to correct the error

My current dayfile.txt is here - https://www.dropbox.com/s/1o2rsn1np8dte ... e.txt?dl=0

Any idea how to edit the file to correct it?

smintik wrote: ↑Wed 05 Aug 2020 3:14 pm Any idea how to edit the file to correct it?

Try reading https://cumuluswiki.org/a/Dayfile.txt#S ... ummary_log that will tell you the rules, and guide you on what might be wrong.

Dropbox does not provide me with line numbers. I have scanned some of the file, but the error does not jump out at me. It might be a missing field, or an incorrectly expressed field.

Open the admin interface, select dayfile from data logs menu. There are 10 line per screen, so page 11 should show line 102. Look for obvious difference in pattern between that row and previous rows. On that web page, you select a line, click Edit and a modal (dialog) screen pops up for editing. Edit as necessary, click save, then click close. If I have quoted the wrong text for any buttons, sorry, but I have a variant of that page where you edit in-line and it uses different button names. Due to integration issues, mine is not in the public release.

Remember Cumulus only reports first error found, so there may be further errors in later lines. Both the quotes you provide find the same first error. MX has to read the entire file just to find the lines that fall within this month or this year for those respective totals, so if it stopped reading sometime in 2026 or 2017, it is not surprising that it can't find any rain for 2020!

The date format changes at line 102 from...
13/10/16
to
14-10-16

then a line 468 it changes back again...
16/10/17

The current format seems to be slashes...
04/08/20

Okay, sounds like there are lots of hyphens to change to slashes. You need to be careful you don't change any minus signs in front of numbers, so you can't edit in a text editor with replace all (or global replace) functionality.

I suggest you use a spreadsheet package like the Calc feature in Libre Office. Open without selecting "recognition of types". Select date column, in edit menu select Find &Replace, enter "-" in find and "/" in replace, then click Replace All in selection. Finally save as "CSV", but change extension to "txt" and untick automatic extension.
If you use a different package, similar instructions will apply, but it is important to avoid any defaults, do not let the date column be treated as anything other than text, and do save as CSV.

I'd use a decent editor like Notepad++ and use a find/replace with a regex

(VS Code version would be - other editors may be different, always backup your file first!)
Find: ^(\d{2})-(\d{2})-(\d{2})
Replace: $1/$2/$3

Cross-posted with sfws - take your choice of method!

Very much appreciated folks. I'm gonna try your methods and hope for the best. I do wonder why the change, perhaps system settings changes with some upgrades which affected locale. Anyway, I'm better going change some dates ...

Fixed!

Once again, thanks to all chipping in. I think the change in date might have been the system migration I did during that time. What's strange is that the dates affected were quite old and the previous MX releases were displaying it. I guess new code had more stricter formatting rules.

smintik wrote: ↑Wed 05 Aug 2020 6:03 pm the previous MX releases were displaying it. I guess new code had more stricter formatting rules.

That is interesting.

Several users recently have had problems with dates, but before that the problem was not being reported if it did happen.

Mark will no doubt comment in a while, but I am guessing this is related to this text in 3.6.11 release note

I have updated quite a bit of the code to try and streamline it a little - there is always scope for introducing errors when doing this, so watch out for issues.

as that is all I have spotted that might have created this surge in such problems.

It's a coincidence I think, the data parsing has not changed just the efficiency of reading and processing the data.