Welcome to the Cumulus Support forum.

Latest Cumulus MX release 3.8.4 (build 3094) - 14 September 2020 (please see announcement regarding releases since 3.5.0)
Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of the NOAA report and Snow Index drop-down menus to 2030)

Use this Wiki link to Download the Software (Cumulus MX / Cumulus 1 and other related items).

Original release topic

Discussion of the Cumulusutils tool and website generator.

Moderator: HansR

User avatar
laulau
Posts: 640
Joined: Tue 13 Oct 2009 10:52 pm
Weather Station: WeatherDuino Pro2
Operating System: Win 7
Location: Meyenheim, Alsace, FR
Contact:

Re: Cumulusutils

Post by laulau »

Hi Hans,
If i don't use the toggle button the update is ok.
Capture.JPG
but after toggling the gauges looks like this :
Capture2.JPG
Capture1.JPG
You do not have the required permissions to view the files attached to this post.
Laurent

Image

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

@laulau: what client are you running (OS, hardware, age....). I am beginning to think it is a speed issue.

Apparently it loses the path to realtimegauges.txt, but keeps the path to realtime.txt:
200415 LaurentMey issue.png
Before this everything was OK. This does not happen on my site.
What is the path you define for the realtime files? Do the Cumulus graphs load OK when the gauge updates fail?

[Edit:] Yes, it changes back it's path... :( I'll get back.
You do not have the required permissions to view the files attached to this post.
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

@all: don't expect a solution soon, this may take some time.
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

User avatar
laulau
Posts: 640
Joined: Tue 13 Oct 2009 10:52 pm
Weather Station: WeatherDuino Pro2
Operating System: Win 7
Location: Meyenheim, Alsace, FR
Contact:

Re: Cumulusutils

Post by laulau »

The temporary remedy that I use is to fill in the URL to 'realtimegauges.txt' directly in gauges.js!
Capture.PNG
You do not have the required permissions to view the files attached to this post.
Laurent

Image

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

@laulau: And leave the entry in the inifile blank (you have to otherwise it does not work is it?). OK. But if you switch the dashboard five or ten times it will produce an error because somewhere the timers in gauges.js go wrong and things mess up. Entering the path does not alter the code, it will only buy you time. It must be possible to switch endlessly between the boards.

So, no I will have to actually rewrite the gauges to have the timers reset and really reinitialise the realtime reading when switching. Gives me the opportunity to optimise it for my purpose. But this will require some analysis and a lot of time.
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

User avatar
laulau
Posts: 640
Joined: Tue 13 Oct 2009 10:52 pm
Weather Station: WeatherDuino Pro2
Operating System: Win 7
Location: Meyenheim, Alsace, FR
Contact:

Re: Cumulusutils

Post by laulau »

I have the complete URL in the ini file and in gauges.js.
Right , It fails after i toggle more than 20 times :? :oops:
Laurent

Image

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

Yes, was afraid so. 20 times! You have a powerful client 😉

Not even gonna ask. Just do it, that's the fastest way.

Submerge. Emerge when ready 😎
Last edited by HansR on Sat 18 Apr 2020 11:37 am, edited 1 time in total.
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

Version 3.1.0 is online.

This was a deep problem. I will elaborate in the corresponding thread in 'Steelseries Gauges' for those who wish to try similar things (the comment won't be there at the time of this writing but somewhat later).

Thanks to Laurent who helped with the debugging :clap:
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

sfws
Posts: 928
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: --
Operating System: --

Re: Cumulusutils

Post by sfws »

Hans
I am very impressed by what you have done, and have been reading the open document format guide, before I try to install anything.

I have just one question at the moment. In the NOAA display reports module, do you take the naming format from Cumulus.ini? In your documentation you mention you have your own setting for the "Reports" directory, you mention the selection criteria, but you don't say anything about how the month and year should be formatted for monthly reports. I am obviously not reading your exe file, nor am I actually using your project yet. Someone else who has produced a new suite of web pages has assumed everyone names their reports using the default format, and not allowed for anyone selecting another format.

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

sfws wrote:
Sun 19 Apr 2020 8:38 am
In the NOAA display reports module, do you take the naming format from Cumulus.ini? [...] Someone else who has produced a new suite of web pages has assumed everyone names their reports using the default format, and not allowed for anyone selecting another format.
I assume you mean BCJkiwi's new template ;)

Actually, Yes, I did the same. I use the default format and work with it. I shall make a remark in my README. I had actually forgotten the naming can be changed.
Thanks for the note! Well spotted.

BTW: I never understood why the names of these files are modifiable, irrelevant. Location OK, that can be relevant. @mcrossley might consider to fix these filenames to the defaults. Confusing.
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

sfws
Posts: 928
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: --
Operating System: --

Re: Cumulusutils

Post by sfws »

HansR wrote:
Sun 19 Apr 2020 11:26 am
@mcrossley might consider to fix these filenames to the defaults.
That is a unwanted suggestion, when you actually have access to what format has been used because it is specified in Cumulus.ini, so your software could have the ability to adapt to the format anybody may have chosen. You might as well tell people they cannot use their own language, they cannot use comma in CSV files, or cannot have their own systems, they have to do exactly what suits one person best. Cumulus MX could be a lot simpler if all its users had the same instrumentation, but nobody is going to tell Mark to fix that, its value and wide appeal comes from the flexibilities it offers. Cumulus 2 made everybody work in UTC and all times were output in that, that had lots of advantages for coding, but it did not actually meet the client demand so it was one of several factors that forced abandonment of Cumulus 2.


I have 11 years worth of reports in the naming format I started off with, I'm sure there are people with even more. You can't retrospectively fix a format that has been free to change in past. Okay I could rename (12+1) x 11 files, but I would also need to change all the scripts I have written based on that format, my back-up system and perhaps even more I can't intermediately think of. Alternatively, I can abandon my plan to try out your software. No prizes for guessing my decision here.

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

sfws wrote:
Sun 19 Apr 2020 2:01 pm
That is a unwanted suggestion, [etc...]
Well, I think that is an unwanted discussion here in my thread, although there is nou doubt a lot to say about it. And if I remember well, there has been said a lot. So if you really want to work this out, open another thread in the general forum board, I'd rather not have it here.

I can tell you shortly what I do and how I think about it, because it is relevant for understanding and appreciating CumulusUtils.
  1. I think an internal format should have nothing to do with local date or number formats. So, filenames and decimal separators should internally not depend on where on earth you are.
  2. Filenames must be the same everywhere and definitely not be dependent on wherever you are on earth (that is an ultimate horror in my view).
  3. Formatting for presentation should only take place in the display layer. Whatever functional separation you make, data and resulting calculations and dates should be the internal format until just before it is displayed in the format the user wants.
  4. Units in which measurements are made are defined once (at configuration time, by the user/owner of Cumulus) and those units should be maintained until the end. So output should be in the same units as they were configured. Only when the viewer indicates (once) what units he wants to see, conversion should be made. That means that all different procedures should call upon the same unit conversions [in the display layer] when needed. And nowhere else, there is no need for conversion.
  5. There will no doubt be some exceptions (e.g. pwsFWI where the formula's used are in SI-units) but those conversions should only be local and not be propagated.
So basically CumulusUtils reads dayfile.txt - no matter what format - and converts all numbers to an internal format datastructure and does create output in the same units and numbers it finds in the setup of Cumulus (so no conversions even for the display output). Only pwsFWI converts possible imperial units (or e.g. m/s to km/hr) to the SI-units required. The resulting units and index are displayed. For the gauges, I accept no unit settings: only the units as offered in the realtimegauges.txt are used which are exactly as set in Cumulus.

So to put it short: I highly disagree having the functioning of Cumulus dependent on the place of the earth. Don't make life more difficult as it is. Just keep filenames the same everywhere, there is no need to make those names dependent on dateformat. So I use the default of Cumulus and demand the same from those who use CumulusUtils. And those who don't like it must use another tool.
sfws wrote:
Sun 19 Apr 2020 2:01 pm
so your software could have the ability to adapt to the format anybody may have chosen
So my answer is: it could but it won't. Unit is what one sees, internal values you don't see, so you should not care how it looks.

(NB: If you wish to continue this discussion please create a new thread somewhere and copy these two entries so they can be removed here)
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

User avatar
HansR
Posts: 1374
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: Davis Vantage Pro 2+
Operating System: Raspbian GNU/Linux 10 (Buster)
Location: Wagenborgen (NL)
Contact:

Re: Cumulusutils

Post by HansR »

As CumulusUtils grows, this thread become more and more divers in its contents. Remarks, requests and discussions are mixed with release announcements. Well, that's life for the moment. Maybe the forum masters have a suggestion how to deal with this.

I have the following remarks:
  1. I would like to emphasize the fact that CumulusUtils website, which is now out of beta, is not a fixed website but is user expandable and such is a standard template. I made a note in the README (which is rapidly becoming a true manual :) ) describing the technique:
    The user can expand the site through user menu's in whatever way he likes. I believe there are no limitations. An example is found in 'CUsermenu-example.txt' which is found in the distribution.

    Please note that loading text or html in the ReportView is possible using the LoadUtilsReport('filename'); call. The text will be interpreted as HTML and thus you can also execute javascript (via the <script> tag). You can create whichever report you want by whichever technique you prefer. Just remember the file offered to CumulusUtils using LoadUtilsReport('filename'); MUST be legal html/javascript (or just plain text) to be useful.
  2. Future developments will contain and adaptation of colours and setup of the gauges. However, that is not too high on the list.
  3. I intend to split up the graphs because I will be creating the minimum/maximum/average graphs per month for rain and temeperature. This means the graphs.txt report will be split in graph_rain.txt, graph_temp.txt and graph_misc.txt. I will probably change the menu in the website accordingly. If you only use the module you will have three reports to accomodate. I have not decided on the userinterface yet. It may become a mix between menu and in report selection.
  4. I do sometimes read my own README and correct outdated or changed info. If you get bored, you might want to do that as well. I welcome any comments. 8-)
(And btw: there is no hurry I guess ;) )
https://meteo-wagenborgen.nl / Cumulus 3.6.8 (build: 3084)
Davis Vantage Pro 2+ / Raspberry Pi 3 Model B Plus Rev 1.3
Raspbian Buster / 5.4.51-v7+ armv7l (before: 4.19.118)
Mono JIT compiler version 6.10.0.104 (before: 6.8.0.123)

freddie
Posts: 869
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2
Operating System: GNU/Linux Ubuntu 18.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: Cumulusutils

Post by freddie »

HansR wrote:
Mon 20 Apr 2020 5:23 am
As CumulusUtils grows, this thread become more and more divers in its contents. Remarks, requests and discussions are mixed with release announcements. Well, that's life for the moment. Maybe the forum masters have a suggestion how to deal with this.
I have a suggestion: maybe you could create a new topic when you announce a new release? You have done some good work here, and I agree that the thread has become a bit bloated.
Freddie
Image

freddie
Posts: 869
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2
Operating System: GNU/Linux Ubuntu 18.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: Cumulusutils

Post by freddie »

HansR wrote:
Sun 19 Apr 2020 11:26 am
BTW: I never understood why the names of these files are modifiable, irrelevant. Location OK, that can be relevant.
It is possible that the intention was to make the filenames more meaningful in a worldwide context. Perhaps using the month number would've been better, but it is easy to say in hindsight - and there is always the question of whether one or two digits are expected.
HansR wrote:
Sun 19 Apr 2020 11:26 am
@mcrossley might consider to fix these filenames to the defaults.
So you are asking Mark to change his (established) software to suit your software?
Freddie
Image

Post Reply