Cumulus Support

Hi Steve,

I am currently using cumulus V1 for the interface with my WH1080 station and to update in quasi real time a web page. I've coupled the data collected by C1 to Graphweather in order to generate long terms statistics and send them to the web.
Up to now all this has worked pretty fine, but I've got a huge thunderstorm that generated ESD and made the rain counter measurement completely crazy: +6,5 cm of rain within 5 sec (this was the 16th of June)

As the month of June is over, I decided to patch the june10log.txt file and followed also the wiki procedure to reset the day rain value in Julylog and today.ini

The result is that cumulus is consistent in its displays even if june 30th total rainfall counter = 110.2 mm while July's 1rst = 175,2 mm...

The problem is that this situation disturbs the graphweather statistic engine as it is based on the total rainfall counter therefore it finds a false rainfall on the first of July.

I've not found any simple way to fix this problem as the abolute counter is provided by the hardware and as there is no relative rainfall counter (increment from the previous point) in the cumulus log file that graphweather could use too.

Therefore I come to the idea to suggest an improvement to cumulus (I have two options):
1- would it be possible to introduce in the cumulus/preference/calibration menu a way to add an offset to the absolute counter ? This would be a very clean way to get from cumulus a corrected total rain fall counter that graphweather could use. In fact I'm a bit concerned that today, if the total rainfall counter becomes corrupted (bird moving the sensor as seen elsewhere, ESD from storm, others ...) it remains corrupted forever ...
2- another option would be to add a column in the month logs to store the relative rainfall counter. Once there is a bug in the total rainfall counter the user would just need to patch one line in a file (for instance in my case on the Junes 16th 19:02:00 line !)

Well, sorry for this quite long post, I hope those ideas are not too "crazy" and could help to add some robustness in the rainfall counter domain !

Thant you for your nice piece of software and the support to us.
Best regards
Alain

Cumulus 2 solves this (or maybe it doesn't?) as it stores the total for each logger period instead of an incrementing daily counter. The 'total counter' is probably not a good value to use for anything, because as you correctly say, it's simply a straight reflection of the hardware counter, which is completely arbitrary - I don't even know if it ever gets reset in Fine Offset stations until it wraps around.

I'm not sure I fully understand what you mean by this 'relative counter'. Is it not the same as the 'total rain so far today'? And could you not use that instead of the total counter? I only added that to the log to make it easier to recover from the occasions where the counter goes mad.

The relative rainfall counter would only track the quantity of rain collected since the previous data record.
It can be computed from total_raincounter(n+1) - total_raincounter(n)

Here is an example done with excel (see last column)

cur_rain_rate rain today total rainfall counter relative rainfall counter
14/06/2010 09:45 0 2,1 106,2 0
14/06/2010 09:50 0 2,1 106,2 0
14/06/2010 09:55 0 2,1 106,2 0
14/06/2010 10:00 0 2,1 106,2 0
14/06/2010 10:05 0 2,1 106,2 0
14/06/2010 10:10 3,6 2,4 106,5 0,3
14/06/2010 10:15 0 2,4 106,5 0
14/06/2010 10:20 0 2,4 106,5 0
14/06/2010 10:25 3,6 2,7 106,8 0,3
14/06/2010 10:30 0 2,7 106,8 0
14/06/2010 10:35 0 2,7 106,8 0
14/06/2010 10:40 0 2,7 106,8 0
14/06/2010 10:45 0 2,7 106,8 0
14/06/2010 10:50 0 2,7 106,8 0
14/06/2010 10:55 0 2,7 106,8 0
14/06/2010 11:00 3,6 3 107,1 0,3
14/06/2010 11:05 0 3 107,1 0
14/06/2010 11:07 0 3 107,1 0
14/06/2010 11:12 0 3 107,1 0
14/06/2010 11:17 0 3 107,1 0
14/06/2010 11:22 3,6 3,3 107,4 0,3
14/06/2010 11:27 3,6 3,6 107,7 0,3
14/06/2010 11:32 0 3,6 107,7 0
14/06/2010 11:37 0 3,6 107,7 0
14/06/2010 11:42 0 3,6 107,7 0
14/06/2010 11:47 0 3,6 107,7 0
14/06/2010 11:52 0 3,6 107,7 0
14/06/2010 11:57 0 3,6 107,7 0
14/06/2010 12:02 0 3,6 107,7 0
14/06/2010 12:07 0 3,6 107,7 0
14/06/2010 12:12 0 3,6 107,7 0
14/06/2010 12:17 0 3,6 107,7 0
14/06/2010 12:22 0 3,6 107,7 0
14/06/2010 12:27 3,6 3,9 108 0,3
14/06/2010 12:32 0 3,9 108 0
14/06/2010 12:37 3,6 4,2 108,3 0,3
14/06/2010 12:42 0 4,2 108,3 0
14/06/2010 12:47 0 4,2 108,3 0

As you may see in the logs both rain today and total rainfall are cumulative. The only relative value is current rain rate which is probably my relative rain counter time a given factor !

Obviously, I could do the job with and external piece of software to convert cumulus data to relative rain that graphweather would eat, but it would be so simple to get it directly from c1

Thank you for your answer
Alain

Right, I understand; it is the value stored by Cumulus 2, i.e. the amount of rain that fell in the previous logger period. It wouldn't be too hard to add this to Cumulus 1 - to just log it, anyway, without Cumulus actually doing anything else with it. Perhaps you could raise an enhancment request so it doesn't get forgotten?

Thank you Steve.

I will add it to the enhancement requests as you suggest

regards
Alain

Thanks