Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
gemini06720 wrote:which time you should invest in the continued development of Cumulus One...
But generating more data should be part of that, and 1.9.1 does indeed generate a lot more data than 1.9.0. I'm certainly not trying to compete with any other software; I don't care in the slightest how many more 'fields' WD creates than Cumulus does. I'm betting that a large number of those could be generated from the data that Cumulus produces already, without too much difficulty. When it comes down to it, 99% of weather stations only generate a dozen or so statistics.
My time is limited, Cumulus isn't a full time job as it is with other software, and I concentrate on doing things that the user cannot do (or cannot do relatively easily). Actually, I'm not sure that's going to be true for much longer. I'm just going to do the things that I want to do
steve wrote:My time is limited, Cumulus isn't a full time job as it is with other software, and I concentrate on doing things that the user cannot do (or cannot do relatively easily). Actually, I'm not sure that's going to be true for much longer. I'm just going to do the things that I want to do
And that is why, Steve, I have not asked you to add any additional tag or to create any additional data file - you have a life to live ... and Cumulus should just be a pleasant adventure into your life and not consume every free minutes of your free time - do you not have a 'spousal unit' that would appreciate some (more) of your free time?
mcrossley wrote:Why not, if the logfiles are in the right format Cumulus will read them OK, but it will not retrospectively find max/mins etc, but you can extract these from WD and plug them into the editor in Cumulus.
Indeed; or a conversion script could generate the file automatically. If the resulting data is in Cumulus format, then of course Cumulus will be able to read it.
This looks sensible, and encouraging.
I don't see any need to be converting binary files. All my log files are plain text and comma separated. I can't imagine that converting WD's log files will be all that taxing.
I'm posting from work though at the moment, so I haven't had time to digest the full content of this thread yet.
gemini06720 wrote:But, someone has to design a software (and not just a scipt) that would read the data from the files and convert it to something that Cumulus can read ... and without the format of the files readily available, the conversion is almost a non fact...
I don't understand this. The format of both WD's log files, and Cumulus's file format, are both known. It seems to me like a script in PHP or ASP or whatever to convert between the two would be trivially easy to come up with. I've done it loads of times before for non-related reasons.
Let's try to clarify somethinig - and, seing as Steve refuses to discuss it - if I, or anyone else, recreates historical data from WD or ANY other program, you are saying that Cumulus WILL use that data? So, for example, if someone migrates over from - let's say - 2 years of using another program and creates a file called Dec08log.txt - is steve saying that Cumulus will read that data and use it on startup or at any other time? My understanding from steve's previous curt replies on this is that it won;t - the user has to manually enter any extremes. (And before steve goes off at the deep end yet again - I am not, and was not, suggesting that Cumulus shouod be changed to accomodate this type of scenario).
As for 'missing tags' - yes, they might be available in BETA versions of Cumulus - but BETA versions are not and should never be considered production verisons - therefore they are, in fact, missing.
steve - stop being so sensitive - no one was having a shot at you or trying to put you or the program down - it is a fact that certain tags ARE missing. You may have corrected this in a future version - and whilst you rightly say they are in a beta version you should never (or anyone else) be suggesting that these test versions be used in an environment where someone wants stability (regardless of how good the beta version is).
Edit - one other point to clarify - the dayfile.txt log file does NOT contain daily max/min humidity data - regardless of what a future version may have, the current stable release does not. So I don;t know where it is coming from that I am spreading 'mis-truth's' on this.
Punctuation is the difference between 'Let's eat, grandma' and 'Let's eat grandma'
gemini06720 wrote:But, someone has to design a software (and not just a scipt) that would read the data from the files and convert it to something that Cumulus can read ... and without the format of the files readily available, the conversion is almost a non fact...
I don't understand this. The format of both WD's log files, and Cumulus's file format, are both known. It seems to me like a script in PHP or ASP or whatever to convert between the two would be trivially easy to come up with. I've done it loads of times before for non-related reasons.
What am I missing that makes it so difficult?
As pointed out elsewhere, WD data files are not text or ASCII files therefore you can't use ASP or PHP scripts on them - and, have to admit, looking back over my years of data, the years of using WD are causing me the most grief in terms of converting to a usable format. I am not aware of the format of these files being made available anywhere - but I may be wrong on this. Brian did at one point release a small program that supposedly allowed you to view this data but I, and many others, could never get it to work.
Punctuation is the difference between 'Let's eat, grandma' and 'Let's eat grandma'
And as I stated earlier, my log files are plainly and obviously clear text and comma separated. I'm looking at one right now. it gives all the measured weather readings for every minute of every month... in plain, human-readable, comma-separated text... which I can easily use php and asp on.
I've seen the binary data files... why do you think it necessary to convert them when the plain-text log files will do?
As I understand it from previous email correspondence from Brian, the binary files contain more informaiton than is present in the log files. But, you are correct - the log files (and I missed them when I was scanning an old WD directory) do contain enough informaiton to be used. The only question I would ask is whether Cumulus will use old historical data to update its own records. I believe those of us that have imported or used any of this old historical data are usiing it in an external database of some form (MySQL for example) and then generating reports and graphs based on that data not on the Cumulus generated physical files. If this makes sense
Punctuation is the difference between 'Let's eat, grandma' and 'Let's eat grandma'
Correct. And, as I understand it, C2 uses this database method for data storage - hopefully old, historical data will be able to be integrated into it instead of having to have 2 or 3 different files systems around! (mind you the file will get LARGE! - I currently have just over 1.1 million records in the equivalent of the monthly log file....)
Punctuation is the difference between 'Let's eat, grandma' and 'Let's eat grandma'
To reiterate: Any data converted correctly and fully to Cumulus format will of course be used by Cumulus (with the restriction that it has to be from the year 2000 or later, but that's not an issue in this case). Cumulus doesn't know or care where the data came from, how could it possibly? A number of people have converted their data from other software.
Thanks for the advice Steve.
Also, thanks for putting all this together. I'm going to get Christmas out of the way, and then seriously think about making the switch.
Have a great Christmas and New Year.
Cheers
Dave
