Cumulus Support

The dayfile readers do not seem to create the output as a file but a webpage which is useless for my use. I need raw data to allow me to create my graphs. I don't use Highcharts and never will. I don't want addons for something I feel should be there already.

This is obviously flogging a dead horse as everyone seems to feel this is unnecessary, apart from me.

Stuart

Stuart,

I have exported data from my dayfile.txt file to Excel where I can create fancy charts for my own use. I’m sure with OpenOffice you could achieve your aims.

Alternatively, Microsoft Office will do much the same. https://mm3digital.com/product/microsof ... oduct-key/

I wouldn't welcome a new column in the data file due to the number of changes required to cater for it. A possible solution may be to dynamically generate it locally from the rain counter column. That should be pretty robust as the counter doesn't get reset (apart from year end).

freddie wrote: ↑Tue 10 Sep 2024 5:24 pm I wouldn't welcome a new column in the data file due to the number of changes required to cater for it. A possible solution may be to dynamically generate it locally from the rain counter column. That should be pretty robust as the counter doesn't get reset (apart from year end).

That's why I suggested the month data file. I believe this is an important statistic which is why I believe it should be saved at month end somehow. I just do not understand why this is not already done!

Stuart

RayProudfoot wrote: ↑Tue 10 Sep 2024 5:20 pm Stuart,

I have exported data from my dayfile.txt file to Excel where I can create fancy charts for my own use. I’m sure with OpenOffice you could achieve your aims.

Alternatively, Microsoft Office will do much the same. https://mm3digital.com/product/microsof ... oduct-key/

I just don't want to do it manually! I want an automated solution.

Stuart

broadstairs wrote: ↑Tue 10 Sep 2024 5:29 pm
That's why I suggested the month data file. I believe this is an important statistic which is why I believe it should be saved at month end somehow. I just do not understand why this is not already done!

For me Mark’s earlier explanation makes perfect sense. Avoid storing a value that can be easily calculated from the existing data. It is just a waste of storage.

SamiS wrote: ↑Tue 10 Sep 2024 5:34 pm

broadstairs wrote: ↑Tue 10 Sep 2024 5:29 pm
That's why I suggested the month data file. I believe this is an important statistic which is why I believe it should be saved at month end somehow. I just do not understand why this is not already done!

For me Mark’s earlier explanation makes perfect sense. Avoid storing a value that can be easily calculated from the existing data. It is just a waste of storage.

For heaven's sake we're talking peanuts here storage is cheap! Who has less than terabyte of storage on their PC.

Stuart

I'm not opposing any additions, but one could end up asking if the same could be done for sunshine hours, evapotranspiration totals, etc

I guess it comes down to how the user is trying to gather their data? I use SQL, so it's pretty straightforward for me. To be honest, I've never really thought about Cumulus storing monthly or yearly totals as webtags.

Mapantz wrote: ↑Tue 10 Sep 2024 5:49 pm I'm not opposing any additions, but one could end up asking if the same could be done for sunshine hours, evapotranspiration totals, etc

I guess it comes down to how the user is trying to gather their data? I use SQL, so it's pretty straightforward for me. To be honest, I've never really thought about Cumulus storing monthly or yearly totals as webtags.

Yes there are probably other things which are missing but also probably not as universally expected in my view as rain data. I do not want or need the overhead ov mysql for one value which CMX does have but not log in a data file. That's the issue here why calculate it and not save it?

Stuart

broadstairs wrote: ↑Tue 10 Sep 2024 5:45 pm

SamiS wrote: ↑Tue 10 Sep 2024 5:34 pm For me Mark’s earlier explanation makes perfect sense. Avoid storing a value that can be easily calculated from the existing data. It is just a waste of storage.

For heaven's sake we're talking peanuts here storage is cheap! Who has less than terabyte of storage on their PC.

It is not the cost or the amount of data. It is just the basic principle of not doing something that is not necessary. Yes, I totally agree that storing one value more probably does not cause any cmx user to end up with full disk despite of the fact that cmx can be run in very low-end IoT hardware with little storage.

I am curious as to why this is such a big issue now when according to your profile you have been a member since 2008 when you must of started on Cumulus 1. Why have you not asked back in the days of Steve Loft?

water01 wrote: ↑Tue 10 Sep 2024 8:50 pm I am curious as to why this is such a big issue now when according to your profile you have been a member since 2008 when you must of started on Cumulus 1. Why have you not asked back in the days of Steve Loft?

Because although I started testing Cumulus back then it did not do what I needed and so stuck with Weather Display which in those days worked well and Linux had not developed to the extent it has now. Only in 2002 did I return to use CMX because WD by then had (and still has) some issue which the author was not fixing despite many requests not only from me but many others as well. One other reason was the lack of support for Linux in WD, yes it has some versions but is very flaky and will not run on many distros and again the author is not really interested in fixing it. My old Windows PC was getting flaky as well and I had no intention of upgrading it or moving from Windows 7 and is now in the scrap bin! By now CMX has become a much better product and does 99.99% of what I need and ran easily on Linux.

It was only when starting to create graphs which use a completely free product that I then discovered the lack of this value. As I said I will not use Highcharts and the graphs it does create do not supply what I feel I need, rainfall average to actual comparison for example. I am just very surprised that this seems to be such an issue for folks who do not agree with me. This was a very minor and simple request to store a value which CMX calculates anyway. I am also surprised about the number of replies which seem to ignore my intention of automating this which I thought I had made clear, running spreadsheets is not an answer nor is dayfile readers which generate a webpage which would be ignored by 90% of my visitors as too complex.

As I said earlier it seems like I am flogging a dead horse on this topic.

Stuart

MX already has a web tag for annual rainfall #AnnualRainfall, which you can optionally specify the year. e.g. <#AnnualRainfall y=2023>

Would a new web tag for monthly rainfall where you can optionally supply the year and month, solve this problem? Something like. <#MonthRainfall y=2023 m=3>, the default being the current months total so far.

This would join the small band of newish tags that summarise over a defined period:

MonthTempAvg
YearTempAvg

proposed: MonthRainfall
AnnualRainfall

mcrossley wrote: ↑Tue 10 Sep 2024 10:18 pm Would a new web tag for monthly rainfall where you can optionally supply the year and month, solve this problem? Something like. <#MonthRainfall y=2023 m=3>, the default being the current months total so far.

I think that's a nice addition regardless.